RMG AI

Исходная проблема

Дмитрий Медников описал собственный опыт спикера: после выступления он уезжает по делам, а затем вручную просит организаторов прислать нужные фрагменты. Запрос проходит через продакшн и согласования; получение материалов могло занимать одну–две недели.

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

≈4 часа до работающего прототипа

Ночью перед первой встречей с заказчиком я примерно за четыре часа самостоятельно с помощью AI собрал работающий end-to-end прототип и 23 декабря 2025 года продемонстрировал его Дмитрию Медникову на реальном видео.

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

Продуктовую концепцию и способ реализации определял я. Сам запускал, проверял и готовил результат к демонстрации; других разработчиков не было. Конкретные coding tools и модели той ночи не установлены.

Что существовало в декабрьской версии

Техническая основа восстановлена read-only аудитом точного snapshot первой демонстрации: Python · FastAPI · faster-whisper · FFmpeg · SQLite. Обработка выполнялась на сервере.

Основная цепочка:

Загрузка MP4 → извлечение аудио → распознавание речи → транскрипт и субтитры → отбор клипов по тексту → горизонтальные и вертикальные видео → скачивание пакета ZIP.

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

В основной цепочке существовали TXT/SRT, видеофрагменты, служебные JSON и пакет скачивания. Текстовое наполнение было базовым: первые сегменты транскрипции и шаблонные поля. Отдельные offline enrichment и validation scripts присутствовали в архиве, но основной pipeline их не вызывал; применение этих инструментов перед демонстрацией не подтверждено.

Распознавание спикеров, diarization, выделение полноценных выступлений, лучшие фотографии, face tracking и Redis относятся к дальнейшему развитию. Их не было в этом первом snapshot. Конкретная GPU и настройки реального декабрьского запуска не установлены.

От проверки гипотезы к финансированию

После успешной демонстрации началась серия встреч о продукте, бюджете и ресурсах. Я сформировал продуктовую концепцию, сценарии развития и исходные экономические допущения: состав команды, CAPEX/OPEX, возможную цену и объём продаж.

Привлечённый мной профессиональный CFO помог перевести эти допущения в финансовую модель. Я подготовил аргументацию и лично защищал business case. Решение о финансировании принимал заказчик; бюджет был одобрен. Закрытые суммы не публикуются.

Разработка с командой

Решение реализовать следующий этап силами команды специалистов принял Дмитрий Медников. Я привлёк технического лидера и через него сформировал команду из пяти человек: Team Lead, Backend, Frontend, DevOps, MLOps.

Моя роль стала Product / Project Owner: требования, приоритеты, задачи на уровне результата, acceptance criteria, сроки, зависимости, блокеры и продуктовая проверка. Основную коммуникацию вёл через Team Lead, регулярно участвовал в общих Zoom-встречах.

После формирования команды я не писал production-код и не реализовывал его части через coding agents. Техническую архитектуру, технологии и реализацию прорабатывали Team Lead и профильные специалисты. Они же отвечали за техническую проверку компонентов и инфраструктуры.

Например, замену faster-whisper на ASR-модель Sber предложила техническая команда. В финальных материалах указана GigaAM; точный вариант модели не установлен.

10 апреля: система принята заказчиком

10 апреля 2026 года рабочая система была продемонстрирована Дмитрию Медникову в офисе РМГ и принята им как готовый результат этапа. Я представлял проект и проверял прежде всего end-to-end поведение и полезность полученного медиарезультата.

После этой демонстрации заказчик решил представить кейс публично. 15 апреля система была использована на конференции «Медиапространство-2026». Медиапакет передал спикеру на телефон сотрудник вручную: процесс получения разрешений на использование контактных данных ещё не был проработан.

Что означает показатель ≈20 минут

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

Отдельно техническая презентация содержит замер параллельной обработки примерно до 20 минут после доступности материала и запуска обработки. Около 22 минут — другой замер последовательной работы reels-worker. Точная длительность входного видео и состав пакета именно в этих замерах не восстановлены.

Это benchmark конкретной конфигурации. Он не устанавливает универсальный SLA и не подтверждает, что на конференции 15 апреля спикер получил пакет через 20 минут. Пост-релиз организатора подтверждает публичное использование системы отдельно от временного замера.

Production-этап и передача проекта

В финальных материалах описаны выделение выступлений, распознавание спикеров, транскрипция, ключевые реплики, хайлайты, лучшие кадры и вертикальные ролики. Для обработки команда использовала отдельные модули, GPU, очереди Redis, Docker и Portainer.

Источник этого описания — финальная техническая презентация; это не аудит недоступного сейчас production-репозитория.

После 15 апреля проект был передан внутренней IT-команде Русской медиагруппы. Я больше не участвую в его развитии. Последующие изменения и текущие эксплуатационные показатели не входят в мой кейс.

Результат

≈4 часа → проверка гипотезы с заказчиком → financial model → одобрение бюджета → команда из пяти специалистов → 10 апреля — принятый результат → 15 апреля — публичное использование → передача внутренней IT-команде.

Кейс показывает два режима моей работы: самостоятельная быстрая сборка AI-assisted MVP и последующее управление продуктом и работой технической команды.