Агент-исследователь видеоархива

Кратко

Агент-исследователь видеоархива – это единая ИИ-система, которая превращает молчаливую гору записанного видео в нечто, с чем можно общаться на естественном языке: «покажи каждый раз, когда погрузчик подходил ближе чем на два метра к человеку в марте» – и получить точные видеоклипы в качестве доказательства. Она состоит из двух частей, с которыми вы уже познакомились на этой главе: индекса, который строится один раз и недорого по всему архиву (пакетный паттерн из урока об асинхронном ревью), и цикла расследования, запускаемого по запросу, когда кто-то задаёт вопрос (цикл агента из урока про исследователя). Этот финальный проект – место, где восемь предыдущих уроков главы 7 перестают быть отдельными идеями и объединяются в единую систему: цикл агента, примитивы инструментов и памяти, выбор фреймворка, три прикладных агента, дисциплина оценки и безопасности, а также ландшафт фреймворков 2026 года сходятся в одной архитектурной схеме. Сложность здесь не в ИИ: сложно уложиться в бюджет, индексируя данные дёшево и читая их дорого, но редко, обеспечить честность агента через оценку и наблюдаемость и держать всю систему в правовом поле – а для записей видеонаблюдения в 2026 году это означает работу на уровне объектов и событий, а не лиц.

Зачем это нужно

Почти любая организация, у которой есть камеры или хранится записанное видео, обладает архивом, которым на деле не может эффективно пользоваться. Записи есть, но найти нужный момент – тот самый единственный – означает вручную перематывать часы таймлайна. Поэтому большую часть архива никто никогда не просматривает. Агент-исследователь меняет экономику поиска: он один раз обрабатывает архив, строит на его основе поисковое представление и затем отвечает на запросы за секунды вместо часов. Если вы разрабатываете или приобретаете видеопродукт – видеонаблюдение, интеллектуальную видеоаналитику, OTT, видеосвязь, e-learning, телемедицину – этот урок соберёт всю агентную фазу в нечто, что можно реально оценить, заложить в бюджет и запустить. Писать код самому не нужно, но важно достаточно хорошо понимать архитектуру системы, чтобы отличать разумный дизайн от дорогостоящей ошибки, осознавать, какие решения имеют юридическое значение, и задавать инженерной команде правильные вопросы. Это итоговый проект главы 7: он предполагает, что вы изучили предыдущие уроки, и объединяет все их элементы в единую сборку.

Что мы строим – и почему это итоговый проект

Каждый урок этой главы рассматривал одну деталь по отдельности. Этот урок объединяет их воедино. Понять итоговый проект проще всего так: это единственный проект, которому нужны все детали сразу – как рабочему автомобилю необходимы двигатель, коробка передач, тормоза и руль: всё на месте и соединено, не как набор запчастей, а как то, что может ехать.

Вот задача в одном предложении. Вы загружаете в систему массив записанного видео – год записей с камер, десятилетие вещательного архива, очередь на модерацию, библиотеку записанных занятий – и после этого человек может задавать ей вопросы на обычном языке и получать точные ответы, каждый из которых сопровождается клип-доказательством. Человек никогда не перематывает таймлайн. Он печатает или произносит вопрос – система расследует и докладывает, как если бы ассистент-исследователь умел смотреть миллион часов видео и не уставал.

Полезно чётко обозначить границы: это не поиск по именам файлов и ручным тегам – он находит лишь то, что человек уже разметил, а таких данных почти нет. И это не одна гигантская модель, в которую вы загружаете весь архив и задаёте вопрос – ни одна модель в 2026 году не сможет удержать год видео в фокусе внимания сразу, а попытка сделать это обошлась бы в целое состояние. Агент-исследователь занимает промежуточное положение: он заранее строит дешёвое, структурированное понимание архива, а затем рассуждает над этим пониманием в момент запроса, прибегая к дорогим инструментам полного качества лишь в тех редких случаях, когда это действительно важно.

Почему называть это итоговым проектом, а не просто очередным прикладным агентом? Потому что это первый урок, в котором нужно принять все решения главы 7 в одном месте. Вам нужен цикл агента, чтобы определить, как он проводит расследование (урок про цикл агента). Вам потребуются примитивы инструментов, памяти и планирования, чтобы дать ему «руки» и «блокнот» (урок про примитивы). Необходимо выбрать фреймворк, чтобы надёжно собрать систему (урок про выбор фреймворка). Вы будете переиспользовать агента форензик-поиска для работы с живыми вопросами (урок про исследователя) и агента асинхронного ревью для разовой индексации (урок про асинхронное ревью). Вы запускаете его под контролем оценки, безопасности, стоимости и наблюдаемости (урок про AgentOps). И выбираете конкретные инструменты из ландшафта фреймворков 2026 (урок про Manus / Claude Agent SDK / Google ADK). Восемь уроков – одна схема.

Нажмите, чтобы увеличить

Две половины – индексировать один раз, расследовать по запросу

Самая важная идея всей сборки – в том, что она состоит из двух половин, работающих по совершенно разным принципам, и спутать их – самый частый способ испортить такой проект. Одна половина медленная: она запускается один раз и затрагивает всё. Другая – быстрая: работает по запросу и затрагивает почти ничего. Держите их раздельно в голове – и остальная архитектура встаёт на свои места.

Первая половина – индекс – представляет собой однократный, неспешный проход по всему архиву, в ходе которого сырое видео преобразуется в структурированное, пригодное для поиска представление. Представьте разницу между морским контейнером с неподписанными коробками и складом с каталогом: индекс – это как раз этот каталог. Его не ждут – он строится асинхронно, по аналогии с паттерном асинхронного ревью из предыдущего прикладного урока: флот воркеров обрабатывает архив в своём темпе, используя самые доступные и дешёвые модели. Что именно он записывает – разберём через минуту.

Вторая половина – расследование – это то, что происходит, когда человек задаёт реальный вопрос. Это агент поиска по следам из урока про исследователя: он берёт вопрос на естественном языке, планирует, как на него ответить, ищет в индексе, просматривает несколько перспективных фрагментов, анализирует найденное и представляет вывод с доказательствами. Здесь человек ждёт, поэтому эта часть оптимизирована под скорость и точность, а не под минимальную стоимость, которую мог себе позволить индекс.

Почему это разделение так важно – дело в стоимости, и разрыв в ней огромен. Чтение видео моделью «видение-язык» – моделью, которая анализирует кадры и описывает их словами; назовём её читателем – самая дорогая операция во всей системе. Если пропустить индекс и заставлять агента читать сырое видео каждый раз, когда кто-то задаёт вопрос, каждый запрос будет просматривать архив с нуля, и вы платите полную стоимость читателя за каждый вопрос – и так на протяжении всего срока жизни продукта. Постройте индекс один раз – и трудоёмкая работа читателя выполняется единожды; далее каждый запрос ищет в дешёвом каталоге и читает лишь несколько клипов, прошедших отбор. Индекс – это разовая плата; альтернатива – постоянная оплата за каждый запрос на всём протяжении жизни продукта.

Нажмите, чтобы увеличить

Что на самом деле хранит индекс

Индекс – это не одна сущность, а три слоя понимания, наложенные на одни и те же записи: каждый отвечает на свой тип вопросов. Построение всех трёх позволяет агенту отвечать на широкий спектр вопросов в ходе реального расследования. Рассмотрим их – от самого простого к самому сложному.

Первый слой – детекция и трекинг – основан на 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 моделирует агента в виде графа – набора шагов, соединённых стрелками, которые показывают, какой шаг следует за каким. Его ключевая особенность – чекпоинты: состояние агента сохраняется после каждого шага. Мы сравнивали 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 – как запускать такой флот и доверять ему.