Содержание статьи +
- Кратко
- Зачем это нужно
- Что мы строим – и почему это итоговый проект
- Две половины – индексировать один раз, расследовать по запросу
- Что на самом деле хранит индекс
- Архитектура от начала до конца
- Сборка агента на фреймворке
- Разбор одного расследования
- Безопасная эксплуатация – оценка, наблюдаемость, стоимость
- Самое сложное – что закон не разрешит агенту
- Где здесь Фора Софт
- Ключевые выводы
- Что почитать дальше
Кратко
Агент-исследователь видеоархива – это единая ИИ-система, которая превращает молчаливую гору записанного видео в нечто, у чего можно спросить обычным языком – «покажи каждый раз, когда погрузчик подходил ближе двух метров к человеку в марте» – и получить ответ с точными клипами в качестве доказательства. Он собран из двух половин, которые вы уже встретили в этой главе: индекса, который строится один раз и дёшево по всему архиву (пакетный паттерн из урока про асинхронное ревью), и цикла расследования, который запускается по запросу, когда кто-то задаёт вопрос (цикл агента из урока про исследователя). Этот итоговый проект – место, где восемь предыдущих уроков главы 7 перестают быть отдельными идеями и становятся одной собранной системой: цикл агента, примитивы инструментов и памяти, выбор фреймворка, три прикладных агента, дисциплина оценки и безопасности и ландшафт фреймворков 2026 года сходятся на одной схеме архитектуры. Сложное здесь не ИИ: сложно удержать стоимость в рамках, индексируя дёшево и читая дорого, но редко, удержать агента честным через оценку и наблюдаемость и удержать всю систему по правильную сторону закона – что для записей видеонаблюдения в 2026 году означает оставаться на уровне объектов и событий, а не лиц.
Зачем это нужно
Почти любая организация, у которой есть камеры или хранится записанное видео, сидит на архиве, которым на деле не может пользоваться. Записи есть, но найти тот единственный момент, который важен, означает, что человек вручную перематывает часы таймлайна, – и поэтому бóльшую часть архива никто никогда не смотрит. Агент-исследователь меняет экономику этого поиска: он один раз прочитывает архив, строит по нему поисковое понимание и затем отвечает на вопросы по запросу за секунды вместо часов. Если вы строите или покупаете видеопродукт – видеонаблюдение, интеллектуальную видеоаналитику, OTT, видеосвязь, e-learning, телемедицину – это урок, где вся агентная фаза собирается в нечто, что вы реально можете оценить, заложить в бюджет и выпустить. Писать код самому не нужно, но нужно понимать форму системы достаточно хорошо, чтобы отличить здравый дизайн от дорогой ошибки, знать, какие решения несут юридический вес, и задавать инженерной команде правильные вопросы. Это итоговый проект главы 7: он предполагает, что вы прочитали предыдущие уроки, и собирает каждый из них в одну сборку.
Что мы строим – и почему это итоговый проект
Каждый урок этой главы учил одной детали по отдельности. Этот собирает их вместе. Понять итоговый проект проще всего так: это единственный проект, которому нужны все детали сразу, как рабочему автомобилю нужны двигатель, коробка, тормоза и руль – все на месте и соединены, не как каталог запчастей, а как то, что едет.
Вот задача в одном предложении. Вы наводите систему на массив записанного видео – год записей с камер, десятилетие вещательного архива, очередь на модерацию, библиотеку записанных занятий – и после этого человек может задавать ей вопросы на обычном языке и получать точные ответы, каждый из которых несёт клип-доказательство. Человек никогда не перематывает таймлайн. Он печатает или произносит вопрос; система расследует и докладывает – так, как делал бы ассистент-исследователь, если бы умел смотреть миллион часов видео и не уставать.
Полезно очертить границу против двух вещей, которыми это не является. Это не поиск по именам файлов и ручным тегам – он находит только то, что человек уже разметил, а это почти ничего. И это не одна гигантская модель, в которую вы загружаете весь архив и задаёте вопрос – ни одна модель в 2026 году не удержит год видео во внимании сразу, а попытка стоила бы целое состояние. Агент-исследователь стоит между ними: он заранее строит дешёвое, структурированное понимание архива и затем рассуждает над этим пониманием в момент вопроса, обращаясь к дорогим инструментам полного качества только в те немногие моменты, которые важны.
Почему называть это итоговым проектом, а не просто очередным прикладным агентом? Потому что это первый урок, который требует принять каждое решение главы 7 в одном месте. Нужен цикл агента, чтобы задать, как он расследует (урок про цикл агента). Нужны примитивы инструментов, памяти и планирования, чтобы дать ему руки и блокнот (урок про примитивы). Нужно выбрать фреймворк, чтобы собрать его надёжно (урок про выбор фреймворка). Вы переиспользуете агента форензик-поиска для живого вопроса (урок про исследователя) и агента асинхронного ревью для разовой индексации (урок про асинхронное ревью). Вы запускаете его под дисциплиной оценки, безопасности, стоимости и наблюдаемости (урок про AgentOps). И вы подбираете конкретные инструменты из ландшафта фреймворков 2026 (урок про Manus / Claude Agent SDK / Google ADK). Восемь уроков, одна схема.
Две половины – индексировать один раз, расследовать по запросу
Самая важная идея во всей сборке в том, что у неё две половины, которые работают по совершенно разным часам, и спутать их – самый частый способ загубить такой проект. Одна половина медленная, работает один раз и затрагивает всё. Другая быстрая, работает по запросу и затрагивает почти ничего. Держите их раздельно в голове – и остальная архитектура встаёт на место.
Первая половина – индекс – разовый, неспешный проход по всему архиву, который превращает сырое видео в структурированное, поисковое понимание. Думайте о нём как о разнице между морским контейнером с неподписанными коробками и складом с каталогом: индекс – это каталог. Никто не ждёт, пока он строится, поэтому он работает как паттерн асинхронного ревью из предыдущего прикладного урока – флот воркеров, перемалывающий архив по своему графику и на самой дешёвой доступной цене модели. Что именно он записывает, посмотрим через минуту.
Вторая половина – расследование – то, что происходит, когда человек реально задаёт вопрос. Это агент форензик-поиска из урока про исследователя: он берёт вопрос на обычном языке, планирует, как ответить, ищет в индексе, читает те немногие клипы, что выглядят многообещающе, рассуждает о найденном и докладывает с доказательствами. Здесь человек ждёт, поэтому эта половина оптимизирована под скорость и точность, а не под минимальную цену, которую мог позволить себе индекс.
Почему это разделение так важно – дело в стоимости, и разрыв в стоимости огромен. Чтение видео моделью «видение-язык» – моделью, которая смотрит на кадры и описывает их словами; будем называть её читателем – самая дорогая операция во всей системе. Если пропустить индекс и заставлять агента читать сырое видео каждый раз, когда кто-то задаёт вопрос, каждый запрос пересматривает архив с нуля, и вы платите полную цену читателя на каждом вопросе вечно. Постройте индекс один раз – и дорогая работа читателя сделана единожды; дальше каждый вопрос ищет в дешёвом каталоге и читает лишь горстку клипов, переживших поиск. Индекс – это цена, которую вы платите один раз; альтернатива – цена, которую вы платите на каждом запросе всю жизнь продукта.
| Индекс (строить один раз) | Расследование (на каждый вопрос) | |
|---|---|---|
| Когда работает | Один раз по всему архиву, затем по новому видео | Каждый раз, когда кто-то задаёт вопрос |
| Кто ждёт | Никто – работает по своему графику | Человек, ждущий ответ за секунды |
| Какой паттерн | Агент асинхронного ревью (пакет, флот, воронка) | Агент-исследователь (живой цикл агента) |
| Оптимизируется под | Минимальную цену за час видео | Скорость и точность ответа |
| Какая цена модели | Batch API – −50%, оборот за 24 часа | Стандартная realtime-цена |
| Что затрагивает | Всё в архиве | Только те немногие клипы, что нашёл запрос |
Что на самом деле хранит индекс
Индекс – это не одна вещь, а три слоя понимания, уложенных поверх одних и тех же записей, каждый отвечает на свой тип вопроса. Построить все три – вот что позволяет агенту отвечать на широкий спектр вопросов реального расследования. Пройдём их от самого дешёвого к самому богатому.
Первый слой – детекции и треки – результат CV-примитивов из главы 2. Детектор находит объекты в каждом выбранном кадре («тут человек, там транспорт»), а трекер сшивает эти детекции во времени в одну движущуюся сущность («это человек №7, и вот его путь по сцене»). Линейку детекторов мы разобрали в уроке про YOLO, а шаг сшивания – в уроке про трекинг множества объектов. Этот слой дёшево считать, и он отвечает на вопросы счёта и движения – сколько, где, когда, как быстро.
Второй слой – эмбеддинги – и это слой, который делает возможным поиск на обычном языке, поэтому стоит замедлиться. Эмбеддинг – это список чисел, который схватывает смысл фрагмента контента так, что близкие по смыслу вещи лежат рядом. Представьте каждый клип и каждую поисковую фразу как булавку, воткнутую в огромную карту, где «красный грузовик сдаёт назад» приземляется рядом с другими клипами сдающих назад грузовиков и далеко от пустого коридора. Чтобы искать, вы втыкаете булавку для вопроса и собираете ближайшие клипы. Место, которое хранит эти булавки и быстро находит ближайшие, – векторная база данных (вектор – это и есть список чисел, а база построена так, чтобы отвечать «что рядом с этой точкой?» среди миллиардов точек). Как это работает для видео, подробно в уроке про мультимодальный video RAG, а саму идею эмбеддинга – в уроке про CLIP. В 2026 эти видео-эмбеддинги можно посчитать выделенной видеомоделью – например, Marengo 3.0 от Twelve Labs даёт Embed API именно для этого, – а общие мультимодальные модели вроде Gemini Embedding от Google помещают текст, изображение и видео на одну общую карту, так что текстовый вопрос находит видеомомент напрямую.
Третий слой – описания – короткие текстовые сводки того, что происходит в каждом значимом сегменте, созданные читателем. «Подъезжает фургон доставки к погрузочной зоне; двое разгружают коробки четыре минуты; фургон уезжает». Это самый богатый и самый дорогой слой, поэтому индекс делает его только для сегментов, которые дешёвые слои пометили как интересные, и никогда для пустоты. Модель понимания видео вроде Pegasus от Twelve Labs, которая умеет описывать клипы и отвечать на вопросы по ним, создана ровно для этого шага, и в 2026 её эндпоинты анализа берут клипы до двух часов за раз. Эти описания сами эмбеддятся и хранятся, так что агент может искать по смыслу произошедшего, а не только по присутствующим объектам.
Сложите три – и архив станет отвечаемым. Слой детекций отвечает «сколько людей вошло после 22:00». Слой эмбеддингов отвечает «найди записи, похожие на это». Слой описаний отвечает «что случилось у погрузочной зоны во вторник». Хороший агент-исследователь использует все три, выбирая самый дешёвый слой, способный ответить на каждую часть вопроса.
Архитектура от начала до конца
Теперь можно нарисовать всё целиком. Не пугайтесь числа блоков – каждый блок вы уже встречали, и данные текут в одном направлении по двум ясным линиям. Читайте слева направо: входит сырое видео, линия индекса превращает его в каталог, линия расследования отвечает на вопросы по этому каталогу.
Сырые записи входят через приём – невзрачный, но необходимый шаг, который снимает видео с камер, файлов или стрима и нормализует его в стандартную форму, понятную остальной системе. От приёма берёт верх линия индекса: дешёвый фильтр сбрасывает пустоту, выбор кадров берёт кадры, достойные взгляда, CV-индексеры дают детекции и треки, эмбеддер даёт векторы, а читатель даёт описания для помеченных сегментов. Всё приземляется в два хранилища: вектор-хранилище для эмбеддингов (для поиска «найди похожие клипы») и хранилище событий для структурированных детекций, треков и описаний (для запросов «сколько, когда, что»). Эта линия – флот асинхронного ревью, запущенный один раз и затем инкрементально по новому видео.
Линия расследования – это агент. Приходит вопрос человека, и агент крутит свой цикл: планирует, как ответить, вызывает инструменты, чтобы искать в двух хранилищах и читать конкретные клипы в полном качестве, рассуждает над тем, что вернулось, держит рабочую память о найденном и собирает ответ с доказательствами – вывод плюс точные таймкоды и клипы, которые его подтверждают. Важно: ответ не идёт прямо в действие. Он проходит через контроль человека: для всего значимого человек проверяет вывод агента, прежде чем тот станет решением. Агент предлагает; человек распоряжается.
Две сквозные системы оборачивают всю схему, и о них легко забыть, пока они не укусят. Первая – фреймворк – софт, который собственно собирает цикл агента и, что не менее важно, делает его надёжным, так что упавшее на полпути расследование продолжается, а не начинается заново. Вторая – наблюдаемость и оценка – инструментовка, которая записывает каждый вызов инструмента и шаг рассуждения, чтобы систему можно было отлаживать, считать и доверять ей. Каждой посвящён свой раздел ниже, потому что в реальной сборке именно туда уходит бóльшая часть инженерных усилий.
Сборка агента на фреймворке
Цикл агента – это концепция; фреймворк – то, что делает её реальным кодом, переживающим контакт с продакшеном. В 2026 году выбор по умолчанию для такой работы – LangGraph, и стоит понять, почему он по умолчанию, потому что причина – ровно то свойство, которое этой сборке нужно больше всего.
LangGraph моделирует агента как граф – набор шагов со стрелками, какой шаг за каким может идти, – и его определяющая черта – чекпоинты: он сохраняет состояние агента после каждого шага. Мы сравнивали его с CrewAI и AutoGen в уроке про выбор фреймворка; здесь важны именно чекпоинты. Расследование может быть длинной цепочкой вызовов инструментов – поиск, чтение, рассуждение, снова поиск, снова чтение, – и если процесс падает на девятом шаге из пятнадцати, чекпоинты означают, что он продолжается с десятого, а не перезапускает восемь дорогих чтений, за которые уже заплачено. На практике вы используете простой in-memory-чекпоинтер при разработке и чекпоинтер на базе БД, например на Postgres, в продакшене, где состояние должно пережить перезапуск сервера.
Честная оговорка, потому что инженерная пресса спорила об этом весь 2026 год: чекпоинты – не то же самое, что полноценное надёжное исполнение (durable execution), более сильная гарантия, что весь длительный воркфлоу переживёт любой сбой и продолжится ровно с места обрыва. Для живого расследования, которое идёт секунды, чекпоинтера фреймворка хватает с запасом. Для линии индекса, которая работает часами по огромному архиву, нужна более сильная гарантия – и тут своё место зарабатывает движок надёжного исполнения вроде Temporal, переигрывающий свой журнал событий, чтобы продолжить недоделанную индексацию, а не начать её заново. Это тот же хребет надёжности, что мы строили в уроке про асинхронное ревью; здесь он защищает индекс, а более лёгкие чекпоинты фреймворка защищают каждое расследование.
Как агент на самом деле вызывает инструменты? Через небольшой, острый набор инструментов, выставленный в 2026 через общий стандарт под названием Model Context Protocol (MCP) – открытый протокол, введённый в конце 2024 и теперь курируемый структурой под Linux Foundation, который стандартизирует, как агент находит и вызывает внешние инструменты. К 2026 он стал почти повсеместным: крупные провайдеры моделей поддерживают его нативно, а крупные фреймворки, включая LangGraph, считают его способом по умолчанию подключать инструменты. Практическая выгода в том, что инструменты исследователя – search_events, search_clips, read_clip, get_track – определяются один раз как MCP-инструменты и переиспользуются между фреймворками и моделями, а не переклеиваются к каждому. «Руки» агента становятся переносимыми.
Держите набор инструментов намеренно маленьким. Искушение в итоговом проекте – дать агенту все инструменты в здании; дисциплина – дать ему те четыре-пять, что реально нужны, и ничего больше. Маленький набор модель использует правильнее, он дешевле в работе и куда проще для аудита, когда что-то пойдёт не так – а в системе, которая трогает записи реальных людей, рано или поздно пойдёт.
Разбор одного расследования
Абстракции становятся конкретными, когда проводишь один реальный вопрос через систему, следя за стоимостью на каждом шаге. Возьмём запрос о промышленной безопасности по году записей с сорока камер: «Покажи каждый раз, когда погрузчик подходил ближе двух метров к человеку пешком в прошлом месяце». Вот что происходит и сколько это стоит.
Сначала арифметика, которая делает индекс оправданным. Год записей с сорока камер при тридцати кадрах в секунду – астрономическое число кадров: сорок камер × тридцать кадров × ~31 536 000 секунд в году ≈ 38 миллиардов кадров. Прочитать каждый читателем невозможно ни при каком бюджете. Но индекс уже отработал. Дешёвый фильтр и выбор кадров оставили лишь кадры, где что-то двигалось, и лишь несколько в секунду из них, срезав объём в сотни раз ещё до того, как читатель его увидел; и индекс работал на batch API за полцены, потому что никто не ждал. Дорогой проход случился один раз, офлайн, по минимальной доступной ставке. Точные цифры в долларах мы держим в живом справочнике по стоимости ИИ, потому что они меняются; важна структура – миллиарды кадров, сведённые к поисковому каталогу, оплаченному один раз.
Теперь живой вопрос, который дёшев, потому что тяжёлую работу сделал индекс. Агент планирует: это вопрос о пространственной близости двух типов объектов в окне времени, значит, хранилище событий ответит на бóльшую часть. Он вызывает search_events для треков погрузчиков и треков людей пешком в окне прошлого месяца – быстрый запрос к БД по индексу, а не пересмотр видео. Он рассуждает над вернувшимися треками, вычисляя, где путь погрузчика и путь человека были ближе двух метров в один момент – простая геометрия по данным, которые индекс уже извлёк. Это даёт, скажем, четырнадцать кандидатов. Только теперь срабатывает дорогой инструмент: агент вызывает read_clip на этих четырнадцати клипах, чтобы подтвердить, что каждый – настоящее сближение, а не артефакт трекинга. Четырнадцать чтений, а не 38 миллиардов кадров. Он собирает ответ: «Одиннадцать подтверждённых сближений; вот одиннадцать клипов с таймкодами, два помечены как самые близкие». И направляет это в контроль человека, потому что вывод о безопасности значим.
Урок разбора – это воронка, та же, что из урока про асинхронное ревью, теперь наведённая на один запрос: дешёвый структурный поиск сужает миллиарды кадров до четырнадцати кандидатов, а дорогой читатель подтверждает только их. Частая и дорогая ошибка – пропустить структурный поиск и заставить агента читать клипы на всё подряд: «читатель ведь умеет смотреть видео, пусть смотрит». Он умеет; ваш счёт – нет. Читатель – последнее средство, срабатывающее на горстке клипов, никогда не первый ход.
Безопасная эксплуатация – оценка, наблюдаемость, стоимость
Демо, отвечающее на один сценарный вопрос, – это легко. Система, которой вы доверяете искать по реальному архиву день за днём, – нет, и разница целиком в дисциплине из урока про AgentOps. Три вещи отделяют игрушку от продукта.
Первая – оценка – измерение, действительно ли ответы агента верны, целенаправленно и повторяемо, а не вера в то, что они выглядят верными. Для агента-исследователя это значит отложенный набор вопросов с известными ответами – золотой набор – который вы перезапускаете при каждой смене модели, промпта или инструмента, чтобы поймать день, когда «улучшение» тихо заставило агента пропускать половину реальных событий. Здесь важнее всего два режима отказа. Пропущенное событие (агент говорит, что ничего не было, когда что-то было) опасно в задачах безопасности и охраны. Ложное срабатывание (агент помечает то, чего не было) подрывает доверие и тратит время ручной проверки. Вы измеряете оба и решаете, какой ваш продукт может позволить себе меньше всего, потому что настройка агента под снижение одного обычно поднимает другой.
Вторая – наблюдаемость – запись каждого шага агента, чтобы видеть, что он сделал и почему. Агент – не один вызов функции; это цепочка планов, вызовов инструментов и рассуждений, и когда ответ неверен, нужно видеть всю цепочку, чтобы понять, какое звено отказало. В 2026 это устоявшаяся дисциплина с вендоронезависимым стандартом: конвенции проекта OpenTelemetry для генеративного ИИ теперь определяют, как записывать шаги агента, инструмента и модели как структурированные трейсы, а инструменты вроде LangSmith, Langfuse и AgentOps строят на этом проигрываемый вид каждого расследования. Практическое правило простое: если вы не можете проиграть расследование шаг за шагом постфактум, вы не можете его отладить, посчитать или защитить.
Третья – контроль стоимости, который в основном уже виденная вами архитектура, но за ней надо следить. Индекс использует batch-цену; живой агент использует воронку, так что читатель срабатывает редко; наблюдаемость отслеживает трату на расследование, чтобы один разогнавшийся запрос – агент, читающий двести клипов вместо четырнадцати, – был пойман и ограничен, а не обнаружен в счёте. Стоит назвать ловушку: агент без бюджета на запрос и с инструментом-читателем на расплывчатом вопросе с радостью прочитает куда больше, чем нужно. Поставьте потолок на число вызовов инструментов на расследование и заставьте агента задать уточняющий вопрос вместо слепого чтения, когда запрос слишком широкий.
Самое сложное – что закон не разрешит агенту
Самый важный раздел этого урока – не про инженерию. Агент-исследователь видеоархива по своей природе – софт, который смотрит записи реальных людей, и в 2026 это помещает его прямо внутрь AI Act Европейского союза – всеобъемлющего закона об ИИ, основные положения которого стали применяться 2 августа 2026 года. Сделать инженерию правильно, а закон – неправильно, не меньший провал; это тот провал, который не даёт продукту выйти. Ничто из нижесказанного не юридический совет – относитесь к этому как к карте, где проходят красные линии, а к конкретике зовите юриста.
Начнём с самой яркой линии. Список запрещённых практик AI Act, действующий с 2 февраля 2025 года, запрещает удалённую биометрическую идентификацию в реальном времени – узнавание конкретных людей по лицу или телу в публичных местах по мере происходящего – для правоохранительного использования, с лишь узкими, заранее санкционированными исключениями. Агент-исследователь, ищущий по записанному архиву, не делает идентификацию в реальном времени, что держит его в стороне от этого конкретного запрета. Но соседнее правило – то, что формирует дизайн: постфактумная удалённая биометрическая идентификация – узнавание конкретных названных людей в ранее записанном видео – не запрещена, но классифицирована как высокорисковая и для правоохранительных расследований требует предварительной санкции судебного органа. Обязательства, привязанные к высокорисковым биометрическим системам, несут свой более поздний срок соответствия. Практическое следствие для вашей сборки – правило дизайна: по умолчанию агент работает с объектами и событиями, а не с личностями. «Погрузчик подошёл ближе двух метров к человеку» – это вывод уровня события и не несёт того веса. «Этот человек – Джейн Доу» – это биометрическая идентификация и затягивает всю систему в высокорисковый режим. Глубже о биометрической линии – в уроке про обнаружение лиц.
Ещё два обязательства применяются широко. Прозрачность (Статья 50 Акта) требует, чтобы людям сообщали, когда они взаимодействуют с ИИ, и чтобы ИИ-сгенерированный или изменённый контент был раскрыт – это важно в тот момент, когда ваша система резюмирует записи или генерирует синтетический клип. И принцип, которым заканчивается каждый прикладной урок этой главы, здесь юридический не меньше, чем инженерный: человек остаётся в контуре на значимых решениях. Агент выкладывает доказательства; человек решает, что они значат и что делать. Стройте контроль человека как жёсткое требование, а не настраиваемую опцию, и держите аудит-трейл, кто что решил, чтобы система могла показать свою работу.
Дизайн, который удовлетворяет всему этому, – тот самый, что мы строили всю дорогу: индексировать объекты и события, а не лица, держать идентификацию вне пути по умолчанию, чтобы продукт проходил самые яркие линии по конструкции, а не по настройке, раскрывать ИИ там, где требует закон, пропускать каждое значимое действие через человека и логировать всё. Здравая архитектура и соответствующая закону – здесь одна и та же архитектура.
Где здесь Фора Софт
Мы строим видеопродукты в видеонаблюдении, интеллектуальной видеоаналитике, видеосвязи, стриминге, OTT, e-learning, телемедицине и AR/VR, и агент-исследователь архива опирается на бóльшую часть этого опыта сразу – CV-индексацию из нашей работы по аналитике, поиск и дизайн агентов из ИИ-работы и стриминг с приёмом из OTT-практики. Когда клиент хочет сделать архив отвечаемым, наша дисциплина – та, что в этом уроке: индексировать дёшево и один раз, искать по структурированным данным до обращения к читателю, давать агенту маленький острый набор инструментов, держать его на уровне объектов и событий по умолчанию и ставить контроль человека на каждый значимый вывод. Красные линии EU AI Act мы рассматриваем как ограничения дизайна с первой схемы, а не как проверку, прикрученную в конце, – так продукт проходит их по построению. Тот же скелет служит архиву видеонаблюдения, развёртыванию интеллектуальной видеоаналитики или OTT-бэк-каталогу – меняются только индексеры и набор вопросов.
Ключевые выводы
- Итоговый проект собирает все восемь уроков главы 7 в одну систему: индекс, расследование, рамка, управление.
- Разделите на две половины – разовый дешёвый индекс и цикл расследования по запросу.
- Индексируйте три слоя: детекции и треки, эмбеддинги для поиска по смыслу, описания для богатых случаев.
- Структурный поиск сужает миллиарды кадров до горстки; дорогой читатель подтверждает только их.
- Сделайте систему надёжной, наблюдаемой и оценённой – демо легко; доверяемая система – это работа.
- Индексируйте объекты и события, а не лица, чтобы пройти красные линии EU AI Act по построению.
Что почитать дальше
- Агент асинхронного ревью видео – паттерн архива – пакетный паттерн, который строит индекс.
- Агент-исследователь видео – кейс видеонаблюдения – живая половина форензик-поиска подробно.
- Оценка, безопасность, стоимость и наблюдаемость агентов – AgentOps – как запускать такой флот и доверять ему.