Последние месяцы я разрабатывал систему, которую называю «аниме-заводом»: на вход она получает полный эпизод аниме, а на выходе — готовый YouTube Shorts с динамическим кадрированием, субтитрами, постобработкой и метаданными для публикации.

Суть проекта — не просто автоматизировать монтаж, а разложить творческий процесс на инженерные этапы: транскрибацию, анализ аудио и визуальных сцен, поиск сильных моментов, управление «виртуальной камерой» и обратную связь по метрикам.

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

Откуда появилась идея

Любой цифровой продукт без аудитории фактически мёртв. Можно сколько угодно строить бэкенд и автоматизацию, но без канала дистрибуции проект не двигается.

Первые попытки автоматизировать контент появились ещё в 2020 году — вокруг TikTok и Telegram. Но ручная работа быстро упирается в потолок: нарезка, субтитры, оформление, публикация — всё это требует времени и не масштабируется. Один человек делает несколько роликов в день. Система — десятки или сотни.

Я переформулировал задачу: нужен не «скрипт для монтажа», а производственный контур, превращающий длинные видео в поток коротких клипов с минимальным ручным вмешательством.

Из этой идеи и родился «аниме-завод».

Какую задачу решает система

Упрощённо: взять горизонтальный эпизод и превратить его в вертикальный Shorts, который можно смотреть как самостоятельный ролик.

Но при детальном разборе возникает множество инженерных подзадач:

• Найти в эпизоде сильные моменты.
• Отобрать фрагменты, которые работают как микросюжет, а не случайный вырез.
• Адаптировать формат 16:9 в 9:16 без потери фокуса и эмоций.
• Сделать читаемые субтитры, не перегружающие картинку.
• Собрать всё в стабильный batch-пайплайн с возможностью перезапуска отдельных этапов.
• Научить систему анализировать результаты и корректировать отбор.

Это уже не «скрипт», а полноценная инженерная система с артефактами, ошибками, fallback-механизмами и обратной связью.

Почему простая нарезка не работает

На первый взгляд задачу можно решить просто:

• Разбить видео на 30-секундные отрезки.
• Выбрать самые громкие моменты.
• Обрезать по центру.
• Добавить автосубтитры.

На практике такой подход даёт мусор.

Громкий момент не всегда интересный. Сильная реплика может терять смысл без визуального контекста. Лицо может уехать из центра. Сцена с двумя героями разваливается при фиксированном кропе.

Поэтому ключевая идея: не полагаться на один сигнал. Не выбирать моменты только по тексту. Не кадрировать только по центру. Вместо этого — объединить несколько независимых источников данных в единую систему принятия решений.

Архитектура: из каких модулей состоит «завод»

Система состоит из трёх контуров:

1. Production — генерация роликов из эпизода.
2. R&D / Analytics — анализ публикаций и обновление эвристик.
3. Community / Interaction — автоматизация взаимодействия с аудиторией.

1. Production-контур: от эпизода до Shorts

Это сердце системы. Здесь исходное видео проходит все этапы обработки.

Этап 1. Получение исходного материала

На вход поступает видеофайл. Важно — не просто обработать его, а сохранить все промежуточные артефакты: транскрипты, метаданные, кандидаты на клипы, результаты CV-анализа, траектории кропа, финальные рендеры.

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

Этап 2. Транскрибация и работа с речью

Система преобразует аудио в текст с таймкодами. Это даёт:

• Сигнал о содержании сцены.
• Данные для субтитров и привязки фрагментов.

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

Этап 3. Анализ аудио

Параллельно с текстом анализируется аудиодорожка: пики громкости, эмоциональные всплески, переходы, музыкальное давление.

Цель — не выбрать самый громкий фрагмент, а получить дополнительную ось оценки. Часто сильный момент — это сочетание:

• короткой реплики,
• аудиоперехода,
• визуального акцента.

Только текст — можно пропустить такие сцены. Только аудио — собрать бессмысленные крики. Вместе — точнее.

Этап 4. Computer Vision: сцены, лица, события

Система решает несколько задач:

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

Без этого анализ вертикализации получается грубым. Центральный кроп уничтожает смысл: герой может быть слева, а центр — пуст.

Когда система начала отслеживать лица, стало возможно строить «виртуальную камеру» — имитировать операторскую работу в рамках исходного кадра.

Этап 5. Поиск кандидатов на клип

Система не просто режет видео на равные отрезки. Она разбивает его на потенциальные окна, оценивает каждый по нескольким признакам и вычисляет итоговый score.

Оцениваемые сигналы:

• Transcript — плотность и содержательность реплик.
• Audio — эмоциональные пики и динамика.
• Face — наличие героя в кадре.
• Scene — смена сцен и визуальная насыщенность.
• Pacing — темп и ритм фрагмента.

В реальности — штрафы, пороги, фильтрация дубликатов. Но суть — не полагаться на один признак, а комбинировать слабые сигналы в устойчивую оценку.

Важно: система ищет не просто «интересные 20 секунд», а фрагменты, способные выступать как законченный микроэпизод. Пользователь Shorts не обязан знать контекст.

Этап 6. Динамическое кадрирование — «виртуальная камера»

Варианты вертикализации:

• Тупой центральный кроп.
• Статичный фокус.
• Динамическое управление окном.

Первые два быстро показали слабость. Выбран третий путь.

Логика «виртуальной камеры»:

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

Инженерно это ближе к задачам управления состоянием, чем к «магии ИИ». Важны инерция, стабилизация, ограничение скорости и защита от шумных детекций.

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

Этап 7. Субтитры и постобработка

Субтитры — не просто текст на экране. Они влияют на удержание внимания, особенно при просмотре без звука.

Логика упаковки:

• Короткие строки, читаемые на телефоне.
• Осмысленные разрывы по фразам.
• Выделение ключевых слов.
• Синхронизация с речью.

Также выполняется:

• Выравнивание громкости.
• Добавление водяного знака.
• Коррекция скорости и эффектов.
• Финальный экспорт.

Плохие субтитры убивают восприятие. Хорошие — удерживают взгляд.

Этап 8. Метаданные и выпуск

После рендера ролик получает:

• Название.
• Описание.
• Теги.
• Поля для публикации.
• Уведомления.

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

Почему модульная архитектура, а не одна большая модель

Почему не end-to-end? Потому что инженерно это неудобно.

Модульность даёт преимущества:

• Отладка каждого этапа отдельно.
• Замена слабого модуля без переписывания всего.
• Сохранение промежуточных артефактов.
• Понимание причин решений.
• Возможность fallback-сценариев.

Если плохо работает трекинг лиц — улучшаю CV. Если проседает отбор — меняю scoring. Это инженерный подход: меньше магии, больше контроля.

Ключевые архитектурные принципы

1. Независимые стадии

Каждый этап — отдельная стадия. Можно перезапускать только нужное.

2. Сохранение артефактов

Транскрипты, лица, кандидаты, траектории — всё сохраняется. Без этого отладка превращается в ад.

3. Fail-soft вместо fail-fast

Система должна деградировать, а не падать. Нет лица — fallback-кроп. Дергается трекинг — сглаживаем. Нет сигнала — понижаем вес, но идём дальше.

4. Простые эвристики часто лучше «сложной магии»

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

2. Аналитический контур: обучение на результатах

Это не просто генератор. Это система, которая учится на своих публикациях.

Аналитический воркер:

• Собирает данные по успешным роликам.
• Анализирует длину, структуру, словарь, персонажей, темп.
• Обновляет веса и словари триггеров.
• Передаёт обновления в production-контур.

Это не «самообучение» в академическом смысле, а инженерный feedback loop.

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

Это превращает «скрипт» в систему, способную накапливать прикладное знание о домене.

Как устроен скоринг и почему он меняется

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

Поэтому скоринг — слой, допускающий постоянную корректировку:

• Веса сигналов.
• Штрафы за пустые фрагменты.
• Приоритеты триггеров.
• Ограничения по длине.
• Условия дедупликации.

Это не «написал и забыл». Это живой механизм, требующий постоянного пересмотра эвристик.

3. Контур взаимодействия: автоматизация с комментариями

Публикация — не единственная активность. Важна и вовлечённость.

Я создал модуль, генерирующий ответы в естественной манере. Использовались реальные логи переписки как датасет стиля.

Цель — не обмануть, а избежать ботоподобного спама и приблизиться к человеческому паттерну общения.

Это пока эксперимент, но он показал: вокруг контентного производства растёт дополнительная автоматизация — не только для видео, но и для взаимодействия с аудиторией.

Используемые технологии

• Python — основа оркестрации.
• MoviePy + imageio[ffmpeg] — сборка и экспорт видео.
• Whisper — транскрибация с таймкодами.
• OpenCV + MediaPipe — анализ кадров, лица, смена сцен.
• Pillow + Pilmoji — рендер субтитров и эмодзи.
• NumPy — численные операции.
• PyYAML + python-dotenv — конфигурация.
• requests + lxml — загрузка и парсинг.
• google-api-python-client — интеграции с Google.
• Playwright — браузерная автоматизация.
• inference-sdk + OpenAI API — вспомогательные AI-задачи.
• tqdm — отображение прогресса.

Выбор стека обусловлен природой системы: это orchestration-heavy пайплайн. Python обеспечивает гибкость, наблюдаемость и скорость итераций.

Главные проблемы

1. Хороший текстовый момент ≠ хороший визуальный

Решение — комбинировать текст с аудио и CV-сигналами.

2. Лицо есть, но кадр выглядит плохо

Композиция может разваливаться. Решение — дополнительные ограничения и fallback.

3. Слишком активная камера раздражает

Наивный трекинг дергается. Решение — сглаживание, инерция, ограничение скорости.

4. «Инженерно лучший» ролик проигрывает по метрикам

Технически аккуратный ролик может уступать более грубому, но цепляющему. Отсюда — необходимость аналитического контура.

5. Система должна уметь деградировать красиво

Не бывает идеальной детекции. Важно — грамотные fallback-сценарии, чтобы ошибка не убивала выпуск.

Самое неожиданное

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

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

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

Ограничения системы

Система не идеальна. Слабые места:

• Сцены с хаотичным экшеном.
• Моменты, зависящие от длинного контекста.
• Сцены без выраженных лиц.
• Вирусность, определяемая культурным контекстом.
• Риск переобучения на один тип контента.

Это нормально. Важно понимать, где система работает, а где — нет.

Применение за пределами аниме

Архитектура не привязана к аниме. Подходит для:

• Стримов и игровых трансляций.
• Подкастов и интервью.
• Обучающих видео и лекций.
• Музыкального контента.
• UGC-платформ и медиаархивов.
• Внутренних клип-фабрик.

Ценность — не в канале, а в подходе: построить воспроизводимую линию контентного производства.

Результат

Система работает автономно: от анализа эпизода до финального рендера.

Некоторые ролики набирают десятки и сотни тысяч просмотров.

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

И главное — его можно улучшать итеративно, через измеримые изменения модулей.

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

Спрос на короткий контент растёт. Ручной монтаж — медленный и дорогой.

Системы, умеющие:

• Анализировать видео.
• Находить сильные моменты.
• Адаптировать кадр.
• Упаковывать результат.
• Замыкать всё на метрики.

— станут прикладной инженерной задачей, а не хобби.

Это не просто «генерация контента», а построение автоматизированных медиаконвейеров с наблюдаемостью, R&D и управлением качеством.

Заключение

Проект начался как эксперимент: можно ли автоматизировать то, что считается творческой работой?

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

Главный вывод: автоматизация в медиа — это не экономия времени. Это способ превратить разрозненные операции в воспроизводимую производственную линию, которую можно масштабировать, измерять и улучшать.

Именно тогда «канал» перестаёт быть набором публикаций и становится системой.

Привет, Хабр!

Последние месяцы я строил систему, которую внутри называю «аниме-заводом»: на вход она получает исходный эпизод, а на выходе собирает готовый YouTube Shorts с динамическим кадрированием, субтитрами, постобработкой и метаданными для публикации.

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

В статье я покажу, как устроен этот пайплайн, почему я пошел в модульную архитектуру вместо end-to-end black box, где система ломалась и какие решения в итоге сделали ее реально рабочей.

Откуда вообще появилась эта идея

Я давно упирался в одну и ту же проблему: любой цифровой продукт без пользователей фактически мертв. Можно сколько угодно строить backend, автоматизацию, пайплайны, но если у проекта нет канала дистрибуции и нет внимания аудитории, то он почти не двигается.

Первые попытки автоматизации контентных задач у меня начались еще в 2020 году. Тогда это были более простые идеи вокруг TikTok, Telegram и контентного продвижения. Но ручная работа очень быстро упирается в потолок: поиск моментов, нарезка, субтитры, вертикализация, оформление, публикация — всё это забирает слишком много времени и почти не масштабируется. Один человек может собрать несколько роликов в день. Система — десятки и сотни.

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

Именно из этой мысли и вырос «аниме-завод».

Какую задачу на самом деле решает система

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

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

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

И вот в этот момент становится понятно, что это уже не «монтажный скриптик», а вполне взрослая инженерная система со своими артефактами, ошибками, деградациями качества, fallback-механизмами и обратной связью.

Почему простая автоматическая нарезка не работает

Снаружи кажется, что задачу можно решить очень просто. Например:

• разбить видео на равные куски по 30 секунд;
• выбрать самые громкие моменты;
• сделать кроп по центру;
• наложить автосубтитры.

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

Громкий момент не обязательно интересный. Интересный момент не обязательно имеет хороший визуальный фокус. Реплика может быть сильной только в контексте предыдущих 5 секунд. Лицо персонажа может уехать из центрального кропа. Сцена с двумя героями вообще разваливается, если просто зафиксировать окно посередине.

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

Архитектура: из каких модулей состоит «завод»

Назначение

Основной результат

Production

Генерация роликов из исходного эпизода

Готовый Shorts

R&D / Analytics

Анализ опубликованных видео и обновление эвристик

Новые веса и словари триггеров

Автоматизация взаимодействия вокруг канала

Ответы, прогрев, вовлеченность

Верхнеуровнево у меня система распадается на три больших контура:

1. Production-контур— основная линия генерации роликов.
2. R&D / Analytics-контур— анализ уже опубликованных роликов и обновление эвристик.
3. Community / Interaction-контур— дополнительная автоматизация вокруг взаимодействия с аудиторией.

Дальше — подробнее по каждому.

1. Production-контур: от эпизода до готового Shorts

Это сердце всей системы. Именно здесь исходный медиаконтент проходит все стадии обработки и превращается в финальный вертикальный ролик.

Этап 1. Получение исходного материала

Чтобы пайплайн было удобно отлаживать, я изначально пошел не в сторону «один giant script на всё», а в сторону явных промежуточных артефактов.

Эта структура важна не ради красоты. Она позволяет независимо пересчитывать конкретные этапы: например, заново строить crop_path без повторной транскрибации или менять логику субтитров без пересчета анализа сцен.

На вход пайплайна приходит эпизод. Для системы это просто сырье: видеофайл, который нужно разобрать, проиндексировать, оценить и превратить в несколько потенциальных кандидатов на короткие клипы.

Уже на этом этапе важно было сделать не просто «скачал и пошел дальше», а нормальную структуру артефактов. Для каждого эпизода система хранит отдельные промежуточные результаты: метаданные, транскрипт, кандидатов по таймкодам, результаты CV-анализа, найденные лица, параметры кадрирования, финальные рендеры. Это кажется скучной инфраструктурной деталью, но именно она делает систему пригодной для развития.

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

Этап 2. Транскрибация и работа с речью

Следующий слой — это преобразование звука в текст с таймкодами. Здесь система получает не просто сплошной transcript, а сегменты речи, привязанные ко времени. Это важно по двум причинам.

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

Но почти сразу выяснилось, что «взять transcript и искать интересные реплики» недостаточно.

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

Поэтому транскрипт для меня — это один из сигналов, а не единственная истина.

Этап 3. Анализ аудио

Упрощенно один из внутренних проходов по аудио можно представить так:

Разумеется, в реальной реализации всё сложнее: там есть нормализация, пороги, защита от ложных всплесков и комбинация с другими сигналами. Но смысл именно такой: аудио используется не как отдельный оракул, а как еще один слой оценки момента.

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

Смысл этого этапа не в том, чтобы тупо выбрать самый громкий кусок, а в том, чтобы получить дополнительную ось оценки момента. В реальных роликах часто срабатывает именно сочетание:

• сильной короткой реплики,
• выраженного аудиоперехода,
• визуального акцента в кадре.

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

Этап 4. Computer Vision: сцены, лица, визуальные события

Упрощенно детекция полезных визуальных сигналов выглядит примерно так:

На практике здесь важен не сам факт наличия face detection, а то, как эти данные потом используются в downstream-логике: можно ли уверенно строить вертикальное окно, есть ли смысл удерживать одного героя, есть ли переход между персонажами, не разваливается ли композиция.

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

• Определяет смену сцен.
• Понимает, есть ли в кадре лицо и где оно находится.
• Оценивает, насколько кадр пригоден для вертикального фокуса.
• Собирает визуальные признаки, которые потом участвуют в скоринге кандидатов.

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

Когда система начала отслеживать лица и их положение, стало возможно строить «виртуальную камеру» — то есть не просто обрезать видео, а имитировать операторскую работу в пределах исходного кадра.

Этап 5. Поиск кандидатов на клип

Что оценивает

Зачем нужен

Transcript signal

Плотность и содержательность реплик

Понимать, есть ли смысловой крючок

Audio signal

Эмоциональные пики и динамику

Не пропускать сильные аудиомоменты

Face signal

Наличие героя в кадре

Понять, можно ли строить вертикальный фокус

Scene signal

Смену сцен и визуальную насыщенность

Избегать пустых и визуально слабых окон

Pacing signal

Темп и внутренний ритм фрагмента

Отсеивать вязкие или слишком рваные куски

После того как текст, аудио и CV-сигналы собраны, система формирует кандидатов на будущие ролики.

Это не один проход по таймлайну с простым правилом вроде «каждые 30 секунд берем лучший фрагмент». Вместо этого видео разбирается на потенциальные окна, для каждого из которых считается набор признаков, а затем вычисляется итоговый score.

Упрощенно эта логика выглядит так:

Разумеется, в реальной системе всё грязнее: там есть штрафы, пороги, fallback-эвристики, ограничения по длине, проверка на пустые фрагменты, фильтрация дубликатов и переоценка соседних окон. Но сама идея именно такая: не принимать решение по одному признаку, а складывать несколько относительно слабых сигналов в одну более устойчивую оценку.

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

Этап 6. Динамическое кадрирование — «виртуальная камера»

Внутри это больше похоже не на магию, а на state machine с ограничениями на движение окна:

Здесь принципиально важны три вещи:

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

Это, пожалуй, самый интересный и самый капризный кусок всей системы.

Если у нас есть горизонтальное видео и задача собрать из него вертикальный Shorts, у нас есть несколько вариантов.

• Сделать тупой центральный кроп.
• Выбрать один статичный фокус.
• Пытаться управлять окном кропа динамически.

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

Логика «виртуальной камеры» примерно такая:

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

Инженерно это оказалось намного ближе к задачам управления состоянием, чем к «магическому AI». Здесь важны инерция, стабилизация, ограничение скорости смещения окна, защита от дрожания детекций и корректная реакция на исчезновение объекта.

Самое неприятное в этом модуле — то, что формально «правильное» решение не всегда выглядит хорошо визуально. Камера может математически точно следовать за лицом, но зрительно ролик будет раздражать. Поэтому пришлось балансировать между точностью слежения и визуальной плавностью.

Этап 7. Субтитры и постобработка

Для субтитров важно не только «что написано», но и то, как именно текст разложен по строкам и таймингам. Упрощенно логика упаковки выглядит так:

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

Плохой вариант

Нормальный вариант

Длинные строки на пол-экрана

Короткие читаемые строки

Случайные переносы

Осмысленные разрывы по фразам

Мелкий текст

Размер, читаемый на телефоне

Равномерная подача

Выделение ключевых слов

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

Здесь уже включаются более привычные этапы:

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

Субтитры, кстати, оказались не декоративной деталью, а частью механики удержания внимания. Плохо сверстанные автосубтитры очень быстро убивают восприятие. Хорошо собранные — наоборот, удерживают взгляд даже тогда, когда человек смотрит без звука или полувнимательно.

Именно поэтому этот слой у меня не сводится к «сжечь transcript на видео». Там есть собственная логика компоновки и оформления.

Этап 8. Метаданные и выпуск

После рендера клип получает оформительские данные: название, описание, набор тегов, вспомогательные поля для публикации и нотификации. Важный момент здесь в том, что производство ролика заканчивается не на mp4-файле. Для нормального потока контента нужен еще и слой упаковки и доставки результата дальше по системе.

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

Почему я пошел в модульную архитектуру, а не в одну большую ML-модель

Когда рассказываешь про подобный проект, почти сразу возникает вопрос: а почему не сделать всё end-to-end? Например, подать на вход видео и попросить модель сразу выдать готовый Shorts.

Ответ очень приземленный: потому что инженерно это было бы намного менее удобно.

Модульная архитектура дает несколько критически важных преимуществ.

• Каждый этап можно отлаживать отдельно.
• Можно быстро заменять слабый модуль, не переписывая всё остальное.
• Можно сохранять промежуточные артефакты и использовать их повторно.
• Можно внятно понимать, почему система приняла конкретное решение.
• Можно добавлять fallback-сценарии и fail-soft поведение.

Если плохо работает поиск лиц — я улучшаю CV-слой. Если проседает качество отобранных моментов — меняю scoring. Если ролики дергаются — дорабатываю виртуальную камеру. Это очень инженерный подход: меньше магии, больше наблюдаемости и контролируемости.

Для production-системы такой путь оказался гораздо практичнее, чем один непрозрачный black box.

Архитектурные принципы, без которых всё это быстро бы развалилось

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

1. Независимые стадии

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

2. Сохранение артефактов

Транскрипты, найденные лица, candidate windows, траектории кропа, финальные таймкоды — всё это должно сохраняться между шагами. Без этого любая отладка превращается в мучение.

3. Fail-soft вместо fail-fast

Для исследовательского конвейера важно не только уметь «красиво падать», но и уметь деградировать в приемлемый результат. Не нашлось лицо — используем fallback-кроп. Дергается трекинг — сглаживаем и ограничиваем скорость. Пропал уверенный сигнал — понижаем вес и идем дальше.

4. Простые эвристики часто полезнее «сложной магии»

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

2. Аналитический контур: как система учится на своих публикациях

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

Для этого появился отдельный аналитический воркер.

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

На практике этот слой решает примерно такие задачи:

• собирать успешные ролики из канала;
• анализировать длину, структуру и словарь субтитров;
• смотреть, какие персонажи, слова, типы сцен и темпы чаще встречаются в удачных публикациях;
• обновлять внутренние веса и словари триггеров;
• передавать эти обновления обратно в scoring production-контура.

Здесь важно подчеркнуть: это не «полноценное самообучение» в академическом смысле. Скорее это инженерный feedback loop, который позволяет системе становиться менее статичной.

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

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

По сути, у меня получился контур вида:

И вот этот цикл лично для меня оказался одной из самых интересных частей проекта, потому что именно здесь «скрипт для монтажа» превращается в систему, которая начинает накапливать прикладное знание о своем домене.

Как устроен скоринг и почему он постоянно меняется

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

Поэтому scoring у меня изначально строился как слой, допускающий постоянную корректировку.

Там меняются:

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

Это, кстати, сильно отличается от ощущения «один раз написал пайплайн и забыл». На самом деле подобная система — это живой механизм, который постоянно требует пересмотра эвристик.

3. Контур взаимодействия: автоматизация вокруг комментариев и прогрева

Отдельным направлением я экспериментировал с модулем взаимодействия с аудиторией. Идея здесь была в том, что публикация роликов — это не единственная активность вокруг канала. Для новых аккаунтов и вообще для роста вовлеченности имеет значение и поведение в комментариях.

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

Для этого использовались реальные логи переписки как датасет стиля. Задача была не в том, чтобы «обманывать пользователя», а в том, чтобы избежать типичного ботоподобного спама и сделать ответы ближе к нормальному человеческому паттерну короткого общения.

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

Какие технологии использовались

С точки зрения стека это не один монолитный «AI-продукт», а композиция из нескольких практичных инструментов, каждый из которых решает свою часть пайплайна.

• Python— основной язык оркестрации всего конвейера. Он связывает между собой анализ видео, транскрибацию, постобработку, генерацию субтитров и вспомогательные интеграции.
• MoviePy + imageio[ffmpeg]— сборка клипов, работа с видеофрагментами, склейка, экспорт и базовая постобработка. На низком уровне вся история, разумеется, опирается на FFmpeg.
• Whisper— транскрибация аудио и получение сегментов речи с таймкодами. Этот слой потом используется и для смыслового анализа, и для рендера субтитров.
• OpenCV + MediaPipe— анализ кадров, поиск лиц, работа со сменой сцен и сигналы для динамического кадрирования. Именно этот слой помогает системе понять, где находится герой и как лучше адаптировать горизонтальный кадр под вертикальный формат.
• Pillow + Pilmoji— рендер субтитров, оформление текста поверх видео, работа с эмодзи и визуальной упаковкой финального ролика.
• NumPy— базовые вычисления, работа с массивами, численные операции для анализа сигналов и промежуточной обработки.
• PyYAML + python-dotenv— конфигурация пайплайна, хранение параметров обработки и управление окружением.
• requests + lxml— получение и разбор исходных данных, работа с внешними источниками и автоматизация этапа загрузки контента.
• google-api-python-client + google-auth + google-auth-oauthlib— интеграции с внешними сервисами Google для сопутствующей автоматизации вокруг пайплайна.
• Playwright— браузерная автоматизация там, где удобнее не API, а управляемый сценарий через интерфейс.
• inference-sdk + OpenAI API— отдельные AI-слои и вспомогательные inference-задачи, связанные с анализом и принятием решений в пайплайне.
• tqdm— операционная мелочь, но полезная: прогресс длительных batch-процессов и более удобная отладка длинных прогонов.

Почему именно такой стек? Потому что эта система по своей природе — orchestration-heavy пайплайн. Здесь очень много «склейки» модулей, промежуточных артефактов, пакетной обработки, исследовательских итераций и быстрых изменений логики. Для такого режима Python оказался естественным выбором.

Если бы задача сводилась к одному узкому высоконагруженному медиасервису, часть компонентов, возможно, имело бы смысл уносить в более низкоуровневую реализацию. Но на стадии активного R&D для меня была важнее скорость развития системы, наблюдаемость и возможность быстро менять отдельные стадии пайплайна, чем академическая «идеальность» стека.

Какие проблемы стоили мне больше всего времени

Снаружи подобные проекты выглядят эффектно: «система сама монтирует видео». Но реальная работа там в значительной степени состоит из борьбы с краевыми случаями.

Проблема 1. Хороший текстовый момент не всегда хороший визуальный момент

Одной транскрибации оказалось мало. Система регулярно находила сильные реплики в сценах, которые плохо работают как клип без визуального контекста. Решение — комбинировать текст с аудио- и CV-сигналами.

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

Наличие детекции лица еще не означает, что ролик будет хорошо смотреться в 9:16. Иногда объект найден, но композиция всё равно разваливается. Пришлось вводить дополнительные ограничения и стратегию fallback.

Проблема 3. Слишком активная виртуальная камера раздражает

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

Проблема 4. «Инженерно лучший» ролик не всегда лучший по метрикам

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

Проблема 5. Любая полностью автоматическая система обязана уметь деградировать красиво

Не бывает идеальной детекции, идеального трекинга или идеального выбора моментов. Вопрос не в том, чтобы никогда не ошибаться, а в том, чтобы ошибка не разрушала весь выпуск. Поэтому значительная часть устойчивости системы — это не accuracy в вакууме, а именно грамотные fallback-сценарии.

Что в этой системе было самым неожиданным для меня

Наверное, главный неожиданный вывод оказался таким: значительная часть «творческого» контента на самом деле состоит из повторяемых, формализуемых операций.

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

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

Где система пока ограничена

Было бы нечестно делать вид, что такой конвейер уже умеет всё.

У него есть понятные слабые места:

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

И это, на мой взгляд, нормально. У системы не должно быть притворства всемогущества. Гораздо полезнее понимать, где она работает уверенно, а где еще требует улучшений.

Где такую архитектуру можно применять кроме аниме

Хотя проект вырос на аниме-эпизодах, сама архитектурная идея вообще не привязана только к этому домену.

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

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

То есть сама ценность здесь не только в конкретном канале, а в подходе: построить не «один скрипт под один ролик», а воспроизводимую линию контентного производства.

Что получилось на выходе

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

Некоторые ролики собирали десятки и сотни тысяч просмотров.

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

И что еще важнее — этот пайплайн можно улучшать итеративно. Не интуицией в вакууме, а через измеримые изменения отдельных модулей.

Почему мне кажется, что такие системы станут отдельным инженерным направлением

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

На этом фоне системы, которые умеют автоматически:

• анализировать исходный медиаматериал,
• выделять потенциально сильные моменты,
• адаптировать кадр под нужный формат,
• упаковывать результат,
• и замыкать всё это на метрики,

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

То есть это уже не только про «генерацию контента», а про построение автоматизированных медиаконвейеров с наблюдаемостью, R&D-циклом и управлением качеством.

Заключение

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

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

Главный вывод для меня такой: автоматизация в медиа — это не просто экономия времени. Это способ превратить разрозненные творческие операции в воспроизводимую производственную линию, которую можно масштабировать, измерять, дебажить и улучшать.

Именно в этот момент «канал с роликами» перестает быть набором случайных публикаций и становится системой.

Если будет интересно, в следующем материале могу отдельно разобрать технические детали одного из самых сложных модулей — динамического кадрирования / «виртуальной камеры»: как именно выбирается зона фокуса, как сглаживаются движения, какие fallback-режимы используются и где подобные алгоритмы чаще всего ломаются.

Видео-демонстрация

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

Посмотреть демонстрацию системы на YouTube