Video RAG: мультимодальный RAG по видео-архиву

TL;DR

Video RAG (retrieval-augmented generation по видео) – это подход, позволяющий ИИ отвечать на вопросы, сначала находя несколько релевантных фрагментов в большой видеотеке, а затем анализируя только их, а не весь архив целиком. Его строят так: каждое видео разбивают на поисковые фрагменты, каждый из них преобразуют в числовой вектор – эмбеддинг, – сохраняют эти векторы в базу данных для быстрого поиска по схожести, а при поступлении вопроса извлекают наиболее близкие фрагменты и передают их vision-language модели, чтобы она сформулировала ответ. Такой подход выбирают вместо загрузки всего архива в модель с длинным контекстом из-за стоимости и точности: тысяча часов видео слишком велика для одного запроса, а даже если помещается, внимание модели «расплывается», и качество ответов падает. Этот урок помогает владельцу продукта понять, как устроен конвейер, где возникают затраты и ошибки, и в каких случаях модель с длинным контекстом может стать более простым решением.

Почему это важно

У вас накапливается огромное количество видео: записи вебинаров, съёмки с камер, консультации, лекции курсов, звонки поддержки – и однажды кто-то задаёт очевидный вопрос: «А можно просто спросить у него?» Найти момент, когда дефект впервые появился. Найти каждый клип, где демонстрировалась определённая процедура. Подытожить жалобы клиента по сорока звонкам поддержки. Технология, которая решает эти задачи, – Video RAG, и она становится мостом между vision-language моделями, о которых вы уже читали, и функцией, за которую люди действительно готовы платить.

Этот урок написан для продакт-менеджера, основателя или операционного руководителя, которому нужно оценить такую фичу, понять, во что она обойдётся, где окажется хрупкой и стоит ли выбирать более простой путь. Он опирается на урок про открытые VLM и урок про fine-tuning; если термины «vision-language модель», «веса» и «эмбеддинг» вам незнакомы, начните с урока про video-VLM.

Что такое RAG, на одной простой картинке

Начнём с бытовой версии идеи – версия для ИИ строится по тому же принципу. Когда библиотекарь отвечает на сложный вопрос, он не просматривает каждую книгу в здании. Он подходит к нужной полке, берёт две-три книги по теме, открывает их на нужных страницах и даёт ответ, опираясь на найденное. Retrieval (извлечение) – это поход к полке; generation (генерация) – это сам ответ, составленный на основе найденной информации.

Retrieval-augmented generation, почти всегда сокращаемое до RAG, – это тот же приём, применённый к ИИ-модели. Вместо того чтобы просить модель отвечать по памяти – именно так она выдумывает неверные факты, эту ошибку называют галлюцинацией, – сначала извлекают релевантный исходный материал из собственной коллекции, затем передают его модели вместе с вопросом и просят ответить только на основе предоставленного. Модель перестаёт гадать и начинает «читать». Поэтому RAG – стандартный способ заставить модель надёжно отвечать на основе ваших данных: документов, записей, архива.

Text RAG – извлечение по документам – стало решённой, обычной задачей ещё с 2023 года. Video RAG – более сложный и новый вариант: исходный материал здесь – часы движущихся изображений и звука, а не текстовые страницы. Исследование 2025 года, давшее название этой области, формулирует прямо: большинство RAG-систем сосредоточены на тексте, некоторые работают с изображениями, а видео – самый богатый источник из всех – до недавнего времени почти не использовались. Закрытие этого разрыва и есть тема урока.

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

Почему просто не отдать весь архив модели с длинным контекстом?

Это первый вопрос, который задаёт любой толковый владелец продукта, и он заслуживает настоящего ответа, а не рефлекторного «вам нужен RAG». Современные frontier-модели обрабатывают огромные объёмы входных данных. Семейство Google Gemini способно принимать до двух миллионов токенов – токен – это небольшой фрагмент текста или мультимедиа, который модель обрабатывает как единую единицу. Этого достаточно примерно на девятнадцать часов аудио или несколько часов видео в одном запросе. Google сообщил, что одна из этих моделей смогла найти единственное секретное слово, спрятанное в случайном кадре десятичасового видео. Так если модель может обрабатывать часы видео целиком, зачем что-то резать?

Достаточно, чтобы хотя бы одна из трёх причин была верна – и RAG выигрывает.

Первая – размер. Окно в два миллиона токенов кажется огромным, пока вы не попробуете загрузить свой архив. Gemini преобразует видео в токены с фиксированной скоростью около 263 токенов за секунду записи при качестве по умолчанию. Проговорим арифметику вслух:

токенов в час = 263 токена/сек × 3 600 сек/час
            = 946 800 токенов/час

То есть один час видео уже занимает почти миллион токенов – примерно половину двухмиллионного окна. Скромный сточасовой архив потребовал бы около девяноста пяти миллионов токенов, чтобы передать целиком. В 2026 году на планете нет модели, способной принять такой объём в одном запросе. Архив просто не влезает, и единственный способ – разбить его на поисковые фрагменты.

Вторая причина – стоимость, и она кусается, даже если контент умещается. По опубликованной ставке Gemini 2.5 Pro – $1,25 за миллион входных токенов для первых 200 000 токенов и $2,50 за миллион сверх этого – отправка одного часа видео обойдётся в:

стоимость одного часа = ~946 800 токенов × $2,50 / 1 000 000 токенов
                     ≈ $2,37 за час, за вопрос

Если вы отправляете весь часовой аудиофайл каждый раз, когда кто-то задаёт вопрос, вы платите $2,37 за обработку заново на каждом запросе. Задайте сто вопросов об одном и том же часе – и вы потратите $237, перечитывая одну и ту же запись сто раз. RAG меняет подход: вы платите разовую стоимость за обработку и индексацию архива, а затем каждый вопрос обрабатывается только на основе нескольких извлечённых чанков – обычно несколько тысяч токенов, что обходится в доли цента.

Третья причина – точность. Даже если длинный контекст помещается и вы готовы за него платить, модели не распределяют внимание равномерно по огромному входу. Практики регулярно отмечают снижение качества внимания после примерно 400 000 токенов, а точность падает ещё сильнее, когда ответ требует связать факты, разбросанные далеко друг от друга в контексте. Извлечение трёх действительно релевантных минут даёт модели чистый, короткий и сфокусированный вход – а сфокусированная модель работает точнее.

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

Главная проблема – видео не находится

Вот препятствие, которое делает Video RAG отдельной дисциплиной. Текст уже состоит из элементов, по которым работает поиск – из слов. Видео же состоит из пикселей и звуковых волн, не несущих смысла до тех пор, пока что-то не извлечёт его. Вы не можете ввести запрос «момент, когда погрузчик въехал в зону погрузки» и ожидать, что сырые пиксели сами с ним совпадут. Сначала нужно преобразовать видео в представление, с которым компьютер сможет сопоставить вопрос.

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

Мультимодальная модель эмбеддингов – это модель, обученная так, что изображения, звук и текст попадают в одно и то же пространство. Именно это и является ключевым: текстовый запрос может найти беззвучный видеофрагмент, потому что оба они представлены в едином координатном пространстве. Модель 2021 года под названием CLIP – Contrastive Language–Image Pre-Training – стала первой широко применённой реализацией этой идеи, а её потомки (SigLIP, X-CLIP, InternVideo и специализированные видео-модели вроде Marengo от Twelve Labs) и сегодня лежат в основе видео-поиска в 2026 году. Мы подробно разбирали это семейство в уроках про CLIP и VLM; здесь нам нужна лишь краткая версия: модель эмбеддингов превращает неиндексируемое видео в индексируемые координаты.

Два честных подхода – визуальные эмбеддинги против text grounding

Есть два основных способа сделать видео поисковым, и выбор между ними определяет всё дальнейшее – стоимость, точность и круг вопросов, на которые сможет отвечать ваш продукт. Инженерный разбор NVIDIA выделяет три теоретических подхода; на практике важны два, и они находятся на противоположных концах компромисса.

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

Второй подход – text grounding (заземление в текст) – и это основа большинства продакшн-систем. Сначала всё видео преобразуется в текст: произнесённые слова – с помощью распознавания речи, текст на экране – с помощью оптического распознавания символов, а каждая сцена описывается письменно с помощью vision-language модели. Затем полученный текст эмбедится и индексируется с помощью обычного, дешёвого и проверенного временем текстового конвейера. Преимущество – простота и низкая стоимость: задача text RAG уже решена, и вы можете использовать все её преимущества. Недостаток в том, что преобразование происходит с потерями – письменное описание сцены теряет детали, которые были видны на пикселях, поэтому вопрос о тонкой визуальной детали, которую автор описания не упомянул, останется без ответа.

Большинство сильных систем 2026 года – гибридные: для основной части извлечения используется text grounding, потому что он дешёвый и эффективный, а визуальные эмбеддинги добавляются там, где важны чисто визуальные вопросы. Решение не является догматичным. Оно зависит от бюджета и типа запросов, поэтому схему ниже стоит показать вашему инженеру.

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

Конвейер, этап за этапом

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

Этап 1 – чанкинг: режем видео на поисковые фрагменты

Вы не можете искать «видео» – вы ищете его кусочки. Разделение видео на фрагменты называется чанкингом (chunking), и это этап, который тихо определяет, будет ли работать вся система. Чанк – это единица, которую извлекают и показывают пользователю, поэтому его размер – это реальное продуктовое решение: слишком большой – и нужный фрагмент из двух секунд теряется в двух минутах нерелевантного контента, тратятся токены, модель сбивается; слишком маленький – и чанк теряет контекст, делавший его осмысленным, из-за чего извлечение становится фрагментированным.

Наивный подход – чанкинг фиксированной длины: разрезать видео каждые тридцать секунд, независимо от содержания. Его легко реализовать, и именно его применяют в большинстве первых прототипов. Главный недостаток, описанный в исследованиях 2025 года, – он разрезает прямо посередине осмысленных моментов: предложение делится на две части, действие отделяется от своего результата. Лучший подход – чанкинг по сценам: разрезать там, где видео естественно меняется – новый кадр, новый говорящий, новая тема. Классические методы компьютерного зрения определяют границы сцен по резким изменениям изображения; современные системы используют языковую модель, анализирующую транскрипт, чтобы разрезать по смысловым границам, так что каждый чанк представляет собой одну цельную мысль. Такой семантический чанкинг требует больше вычислительных ресурсов, но обеспечивает гораздо более точное извлечение информации. Правило: выравнивайте чанки по смыслу, а не по времени.

Этап 2 – извлечение смысла из каждого чанка

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

Речь превращается в текст с помощью автоматического распознавания речи (ASR) – технологии, лежащей в основе всех функций субтитров. Продакшн-системы используют Whisper и его ускоренные версии, подробно рассмотренные в уроке про WhisperX. Ключевой момент: ASR выдаёт не только содержание, но и таймкоды – то есть фиксирует, что было сказано и когда. Именно это позволяет финальному ответу перенаправить пользователя на точную секунду видео.

Текст, отображаемый на экране – заголовки слайдов, вывески, встроенные в изображение субтитры – становится доступным для поиска благодаря оптическому распознаванию символов (OCR). А чисто визуальное содержимое каждой сцены преобразуется в текстовое описание с помощью vision-language модели, которой задают задачу описать увиденное.

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

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

Этап 3 – отбор кадров: не обрабатывайте каждый кадр

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

Начните с даунсемплинга – оставьте лишь часть кадров. Снижение с 60 кадров в секунду до 4 кадров в секунду сокращает одну минуту видео с 3 600 кадров до 240, поскольку соседние кадры почти идентичны и почти не несут новой информации.

кадров после даунсемплинга = 240 кадров  (с 3 600)

Затем отберите ключевые кадры – несколько кадров, которые действительно что-то новое несут, определив это по степени отличия каждого кадра от предыдущего и оставив только те, что меняются осмысленно. В рабочем примере NVIDIA этот шаг сокращает 240 кадров примерно до 40 – итоговое сокращение составляет около девяносто раз по сравнению с исходными 3 600. Описывать или эмбеддить 40 кадров в минуту – задача недорогая; 3 600 – уже нет. Идея отбора кадров – именно та, которую исследование VideoRAG называет ключевой: длинные видео содержат больше кадров, чем модель может обработать, и не все кадры одинаково значимы.

Этап 4 – индексация: храним координаты для быстрого поиска

У каждого чанка теперь есть эмбеддинг – точка на карте смысла. Вы храните их в векторной базе данных – системе, созданной для одной цели: по запросу-точке быстро находить ближайшие хранимые точки, даже среди миллионов. Pinecone, Weaviate, Milvus и Qdrant – названия, которые вы услышите; у урока про открытые VLM и у вашего инженера будет свой фаворит. Рядом с каждым эмбеддингом вы храните метаданные – исходное видео, таймкод, текст чанка – ведь именно они позволяют финальному ответу указать: «см. минуту 14 записи от 3 марта», а не ограничиваться расплывчатым пересказом. Метаданные – не второстепенная деталь; это то, что делает функцию заслуживающей доверия.

Это конец первой половины индексации, которая выполняется один раз на видео. До сих пор всё происходило, когда видео попадало в архив. Далее мы переходим ко второй, быстрой половине – «на вопрос».

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

Этап 5 – извлечение: найти важные чанки

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

Обычно следует второй, более дешёвый шаг – переранжирование (reranking). Быстрый векторный поиск хорош, но не идеален, поэтому более точная (и чуть медленнее) модель пересчитывает оценки нескольких кандидатов и оставляет только по-настоящему лучшие – два-три. Переранжирование на коротком списке обходится дёшево, потому что обрабатывается всего несколько вариантов: вы доводите до совершенства горстку кандидатов, а не просматриваете архив заново.

Этап 6 – генерация: пишем ответ, опираясь на архив

Наконец извлечённые чанки – релевантные фрагменты транскрипта, описания сцен или сами кадры – передаются vision-language модели вместе с исходным вопросом, и модель формирует ответ, опираясь исключительно на предоставленные данные. Поскольку метаданные сопровождают каждый чанк, ответ может содержать ссылки на источники: «процедура показана на 12:40 в записи онбординга». Такая привязка к источнику – ключевое отличие между просто полезной функцией и тем, на что можно положиться операционной команде, поскольку позволяет проверить информацию одним кликом. Ответ, который пользователь может проверить, – это ответ, которому он доверит.

Частая ошибка – разбивка по часам вместо смысла

Самый частый провал в первых версиях систем video RAG – чанкинг фиксированной длины, и он заслуживает отдельного внимания, потому что в демо выглядит нормально, а в продакшене разваливается. Команда режет видео каждые тридцать секунд, потому что так проще реализовать: демо на аккуратном двухминутном клипе работает, и фичу выкатывают в релиз. Затем реальный пользователь задаёт вопрос о событии, которое произошло на границе чанка – например, вопрос задан на 28-й секунде, а ответ – на 34-й, – и система находит чанк с вопросом, но без ответа, или наоборот, и уверенно возвращает что-то неверное.

Исправление не экзотично: режьте по границам сцен и реплик, чтобы каждый фрагмент был цельной смысловой единицей, и пусть фрагменты слегка перекрываются – тогда момент, попавший на границу, сохранится хотя бы в одном из них. Исследование SceneRAG 2025 года показало, что сегментация по сценам, согласованным с нарративом, а не по временным интервалам, заметно улучшает извлечение информации. Урок для владельца продукта: если инженер говорит «мы просто будем резать каждые N секунд», спросите, что станет с моментом, охватывающим два фрагмента, – и продумайте стратегию чанкинга с учётом сцен заранее, до запуска, а не после первой волны плохих ответов.

Строить самим или купить эмбеддинги?

Как и в большей части курса, перед вами два пути – «строить» и «покупать». Честный ответ таков: большинству команд стоит начать с покупки сложной части. Сложный, дорогой и легко портящийся компонент – это модель видео-эмбеддингов, то есть то, что превращает видео в удобные для поиска координаты. Вы можете самостоятельно хостить открытые модели (CLIP, SigLIP, InternVideo и их аналоги) и контролировать весь стек – это разумный выбор, если данные не могут покидать ваши серверы (например, в системах видеонаблюдения или с медицинскими записями) или если масштаб архива делает поминутную оплату API слишком дорогой.

Путь «купить» возглавляет Twelve Labs, чья модель Marengo генерирует видео-эмбеддинги, а модель Pegasus отвечает на вопросы о клипах и способна рассуждать по временной шкале видео продолжительностью до двух часов. В 2026 году эти решения доступны как через собственные API Twelve Labs, так и через AWS Bedrock, и интегрируются с теми же векторными базами, которые вы и так используете. Обратите внимание на темп изменений: 30 марта 2026 года Twelve Labs вывели из эксплуатации модель Marengo 2.7, и на её место пришла Marengo 3.0 – напоминание о том, что API-слой этого стека развивается стремительно, и любой номер версии в контракте требует оговорки о завершении жизненного цикла. Frontier-модели общего назначения (Gemini, GPT, Claude) отлично справляются с генерацией и могут использоваться как полноценная система для небольших архивов благодаря длинному контексту, но в 2026 году они не являются самым экономичным способом индексировать большой архив для последующего поиска.

Решение зеркалит то, что в уроке про стоимость build-vs-buy: покупайте, чтобы быстро получить работающую фичу и узнать, что ваши пользователи реально спрашивают; возвращайтесь к самостоятельному хостингу, когда объём, правила резидентности данных или поминутная стоимость оправдают владение конвейером.

Куда реально уходят деньги

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

Дешёвая работа – на запрос, и она остаётся дешёвой по замыслу: эмбеддинг короткого вопроса обходится почти бесплатно, векторный поиск – это быстрый запрос к базе, занимающий доли секунды, а этап генерации использует лишь несколько извлечённых чанков – порядка нескольких тысяч токенов, а не весь архив. Сравните с наивным подходом с длинным контекстом: $2,37 за перечитывание одного часа видео на каждый вопрос. Запрос с извлечением, использующий три чанка по две тысячи токенов, обрабатывает шесть тысяч токенов – за небольшую часть цента. Именно этот разрыв – заплатить один раз за индексацию и почти ничего – за каждый последующий запрос – и составляет всю экономическую выгоду от video RAG. Эта выгода только растёт с каждым новым вопросом и каждым дополнительным часом в архиве.

Таблица 1. Форма стоимости каждого подхода. RAG заменяет разовую стоимость индексации на почти бесплатные запросы; длинный контекст заменяет нулевую настройку на высокую стоимость за каждый запрос. Перелом наступает быстро по мере роста объёма архива и числа запросов.

Где здесь Фора Софт

Мы строим системы, описанные в этом уроке, внутри реальных продуктов: поисковые архивы для OTT- и интернет-ТВ-платформ, функции «спроси у записи» для e-learning и видеоконференц-систем, инструменты расследования по записям видеонаблюдения, где ответ должен сопровождаться проверяемым таймкодом. Через видеоконференции, OTT, e-learning, телемедицину и видеонаблюдение проходит один и тот же запрос – превратить растущую кучу записей в то, что не-инженер может задать на обычном языке. И video RAG – это архитектура, которая обеспечивает это без безудержного расхода ресурсов на перечитывание всего при каждом запросе. Наша работа в этих сферах с 2005 года позволила нам понять, какие аспекты (чанкинг, метаданные с таймкодами, резидентность данных) определяют, станет ли функция доверенной или её просто тихо отключат.

Ключевые выводы

• Video RAG сначала находит пару релевантных клипов, а затем формирует ответ, опираясь на ваш архив, а не на внутреннюю память модели.
• Используйте его вместо длинного контекста, если архив слишком велик, слишком дорогой для полного перечитывания при каждом запросе или превышает объём, который модель может обработать.
• Поиск видео невозможен, пока модель эмбеддингов не преобразует клипы и вопросы в точки на единой карте смыслов.
• Два подхода: дешёвый текстовый grounding (ASR + OCR + описания) и более ресурсоёмкие визуальные эмбеддинги; большинство систем комбинируют оба.
• Разбивайте видео по сценам и смыслу, а не по фиксированным временным интервалам – резка по часам – главная причина ошибочных ответов.
• Сохраняйте таймкоды и метаданные источника для каждого чанка, чтобы ответы можно было проверить одним кликом.

Что почитать дальше

• Fine-тюнинг видео-ВЛМ на домене – способ специализации модели и критерии выбора между его использованием и альтернативами.
• Открытые ВЛМ – LLaVA, Qwen-VL, InternVL – выбор модели для этапа генерации.
• Реальная стоимость ИИ в видео-продуктах – математика «сделать самому или купить» и стоимость токенов, определяющая архитектуру решения.