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

Можно ли автоматизировать проверку готового видео: что показало техническое исследование

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

Мне эта работа показалась интересной прежде всего потому, что значительная часть проверки выглядит формальной.
Цена должна совпадать.
Промокод должен совпадать.
Обязательная фраза должна присутствовать.
Субтитры не должны расходиться с речью.
Текст не должен попадать в запрещённую область кадра.

Если такая работа действительно раскладывается на проверяемые правила, возникает очевидный следующий вопрос:

Можно ли технически собрать систему, которая проверяет готовое видео до человека и возвращает конкретные ошибки с таймкодами?

С этого я и начал.

Я сначала представлял решение слишком просто

Сначала решение представлялось почти так:
загрузить MP4 -> дать нейросети сценарий и правила -> получить список ошибок

То есть будто достаточно одной сильной мультимодальной модели, которая посмотрит ролик целиком и вынесет решение.
После технического разбора я от этой конструкции отказался.

Причина не в том, что модели совсем не умеют анализировать видео. Для производственной проверки важнее другое:

• какие ошибки можно находить детерминированно;
• где нужен вероятностный ИИ;
• где есть эталон для сравнения;
• где система должна честно остановиться и передать случай человеку.

В итоге рабочая архитектура получилась не “одна нейросеть смотрит видео”, а несколько разных слоёв проверки.

Первый слой - то, что вообще не нужно отдавать нейросети

Часть параметров видео уже существует как точные технические данные.
Разрешение.
Соотношение сторон.
Продолжительность.
Кодек.
Частота кадров.
Наличие и параметры аудиодорожки.

Такие вещи нет смысла определять “на глаз” через большую модель.
Например, ffprobe умеет извлекать информацию о контейнере и медиапотоках в машиночитаемом виде. У FFmpeg есть фильтры для анализа громкости, чёрных кадров и других измеримых свойств видео.

Для меня это стало первым архитектурным принципом:

если условие можно проверить точным алгоритмом, не нужно просить ИИ угадывать ответ.

Для проверки качества это особенно важно.
Мне нужен не красивый комментарий модели.
Мне нужен воспроизводимый результат.
Если видео должно быть 1080x1920, система должна сравнить два числа.
Если длительность не должна превышать заданный предел, нужно сравнить длительность.
Если громкость должна находиться в заданном диапазоне, её нужно измерить.
Такой слой хорошо воспроизводим и не требует от модели вероятностного решения там, где ответ уже задан числами.

Второй слой - текст и речь внутри видео

Дальше начинается более интересная часть.

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

Здесь уже нужны распознавание речи и распознавание текста в кадре.
И здесь не требуется изобретать отдельную базовую технологию.

Сервисы распознавания речи умеют возвращать текст вместе с временными отметками слов. Системы распознавания текста (OCR) для видео умеют находить видимый текст, его положение в кадре и время появления.

После этого задача снова становится сравнением.
что должно быть по сценарию

против
что реально произнесено

или
что должно быть написано по брифу

против
что реально найдено в кадре

И вот здесь появляется то, что мне изначально было нужно: ошибка уже может быть привязана к конкретному месту ролика.
Например:
00:07 - ожидаемая скидка 20%, распознано 25%
00:14 - ожидаемый промокод GLOW25, найден GLOW20
00:22 - обязательный дисклеймер не найден

То есть таймкод - не магия мультимодальной модели.
Его можно получать из отдельных технических анализаторов и потом собирать в один отчёт.

Третий слой - положение элементов в кадре

Отдельный класс проверки - геометрия.

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

Здесь я тоже сначала думал о сложном визуальном ИИ.
Но часть задачи снова можно упростить.

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

Чем дальше я разбирал процесс, тем больше видел один и тот же паттерн:

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

Где всё-таки нужен ИИ

Полностью без ИИ такой инспектор тоже не получается.
Даже сравнение текста может быть не буквальным.

В сценарии написано одно предложение, а спикер сказал то же самое другими словами.
Дисклеймер присутствует, но в немного изменённой формулировке.
В кадре виден продукт, но его нужно отличить от похожего объекта.

Нужно понять, относится ли найденная надпись к цене товара или к другому числу на экране.
Здесь уже полезны языковые и мультимодальные модели.

Но после технического исследования я бы не давал им роль финального судьи.
Их задача - помочь интерпретировать то, что нельзя надёжно решить правилом.

Например:

• сопоставить близкие формулировки;
• понять смысл расхождения;
• классифицировать найденную проблему;
• объяснить человеку, что именно нужно проверить;
• определить уровень уверенности.

Это другая роль ИИ.
Не “посмотри ролик и скажи, хороший ли он”.
А “вот конкретный спорный участок, вот правило, вот данные нескольких анализаторов - помоги понять, есть ли нарушение”.

У меня получилась карта из трёх классов проверок

После технического разбора я стал делить возможные проверки не по технологиям, а по степени определённости.

1. Точные проверки

Условие можно описать числом, строкой или геометрическим правилом.

Например:

• размер и формат файла;
• продолжительность;
• соотношение сторон;
• громкость;
• наличие чёрных кадров;
• наличие точного промокода;
• наличие обязательной фразы;
• попадание текста в запрещённую область.

Здесь автоматизация выглядит наиболее надёжно.

2. Проверки по эталону

Есть источник правды, но реальный материал может немного отличаться от него.

Например:

• речь против утверждённого сценария;
• субтитры против речи;
• текст в кадре против брифа;
• наличие нужного продукта или сцены;
• корректность смысловой формулировки призыва к действию (CTA).

Здесь уже нужен вероятностный слой, но результат всё ещё можно привязать к конкретному требованию.

3. Субъективные и высокорисковые проверки

Здесь нет простой формулы правильного ответа.

Например:

• хороший ли хук;
• достаточно ли убедительно выглядит актёр;
• соответствует ли ролик ощущению бренда;
• насколько удачный темп монтажа;
• допустимо ли юридически конкретное рекламное утверждение в данном контексте.

Эти задачи я бы не ставил в первый автономный контур.
Именно здесь человек пока остаётся не исключением, а нормальной частью процесса.

Почему PASS / FAIL недостаточно

Если строить систему для реальной работы, двух состояний мне оказалось мало.
PASS
FAIL

звучат удобно, пока не появляется неопределённость.

Речь распознана с низкой уверенностью.
Надпись частично закрыта объектом.
В сценарии несколько допустимых вариантов формулировки.
Правило клиента сформулировано двусмысленно.
Два анализатора дали разные результаты.

Если в такой ситуации система всё равно обязана выбрать PASS или FAIL, она начинает выдумывать уверенность.
Поэтому рабочий контур для меня выглядит так:
PASS - формальные правила пройдены с достаточной уверенностью

FAIL - найдено конкретное нарушение понятного правила

REVIEW - данных недостаточно или случай неоднозначный

Это принцип закрытого отказа (fail-closed): сомнительный материал не получает автоматический PASS.
Для меня это не техническая мелочь.
Это сама граница ответственности цифрового исполнителя.

Что я бы включил в минимальную первую версию

После исследования набор первой версии стал довольно скромным.
Я бы не пытался сразу проверять “качество ролика вообще”.

Я бы начал с 7 вещей:

1. технические параметры файла;
2. базовые аудиопараметры;
3. безопасные зоны для текста;
4. точные значения цены, промокода, URL и других обязательных строк;
5. речь против утверждённого сценария;
6. орфография в найденном тексте;
7. наличие обязательных дисклеймеров.

Это уже достаточно широкий контур, чтобы проверить саму идею, но ещё не обещание заменить редактора, продюсера или юриста.

Что я сознательно не стал бы обещать в первой версии

Техническое исследование помогло не только понять, что можно сделать.
Оно помогло вычеркнуть то, что слишком рано включать в продукт.

Например:

• точное определение шрифта и всех правил брендбука;
• глубокая юридическая проверка рекламных утверждений;
• оценка синхронизации губ и речи;
• субъективная оценка настроения, стиля и креативной силы ролика;
• полностью автономное финальное решение без человека.

Каждый такой пункт резко увеличивает сложность и ответственность, но не обязательно увеличивает ценность первой версии.

Это ещё один полезный результат технического этапа.

Хорошее техническое исследование должно не только показать, что возможно, но и сузить обещание продукта.

Главный технический барьер оказался не в видео

Чем глубже я разбирал архитектуру, тем сильнее менялся главный вопрос.

Сначала казалось, что самая сложная часть - научить систему смотреть видео.
Но видео само по себе не знает, что в нём правильно.

Системе нужен эталон:
Какая цена актуальна сегодня?
Какой промокод должен быть в этой версии?
Какой CTA утверждён?
Какой дисклеймер обязателен?
Какая версия сценария финальная?
Какие правила относятся именно к этому клиенту и именно к этой кампании?

Если всё это хранится в переписке, старом PDF, комментариях, голове продюсера и нескольких версиях Google Docs, качество самого анализа видео уже не решает проблему.

Поэтому архитектура постепенно стала выглядеть так:
актуальные требования проекта -> структурированный набор проверяемых правил -> анализ видео -> сравнение -> PASS / FAIL / REVIEW

А не так:
видео -> умная нейросеть -> ответ

Это принципиальная разница.
Центральным объектом становится не модель, а источник правды.

Технически такую систему собрать можно

После этого этапа я перестал считать технологию главным риском гипотезы.

Отдельные строительные блоки уже существуют:

• инструменты анализа медиапараметров;
• распознавание речи с таймкодами;
• распознавание текста в кадре с координатами;
• компьютерное зрение;
• языковые и мультимодальные модели;
• обычный движок правил.

Вопрос уже не в том, можно ли физически получить эти данные.
Вопрос в точности на реальных роликах, стоимости обработки, количестве ложных срабатываний и качестве исходных требований.

То есть технический результат исследования для меня оказался положительным, но очень ограниченным:

автоматический первый слой проверки готового видео технически реалистичен, если проверять формализованные требования и оставлять неоднозначность человеку.

Именно первый слой.
Не полную замену человека.

Но это всё ещё ничего не говорит о хорошем продукте

После такого результата очень легко перейти к разработке.
Технологическая схема понятна.
Первая версия понятна.
Граница человека понятна.

Но после предыдущих исследований я как раз пытаюсь не путать эти вещи.
Технически выполнимая работа может оказаться слишком дешёвой.
Человек всё равно может смотреть ролик целиком.
Формальные ошибки могут встречаться редко.
Настройка правил для каждого клиента может съесть всю экономию.
А часть проверок уже может быть встроена в другие инструменты рабочего процесса.

Поэтому после технического ответа “да” для меня началась более важная часть исследования.

Кто сегодня реально выполняет эту работу, сколько её существует и исчезает ли человеческий труд после автоматической проверки?

Именно это я стал проверять дальше.

Источники по техническим возможностям

• Документация ffprobe - получение данных о контейнере и медиапотоках в машиночитаемом виде.
• Документация FFmpeg Filters - детерминированные фильтры для анализа аудио и видео.
• Google Cloud Video Intelligence: Text Detection - OCR текста в видеокадрах с координатами и временными отметками.
• Google Cloud Speech-to-Text: word timestamps - распознавание речи с временными отметками слов.