Опубликовано: 17.09.2026 | Источник: TechCrunch

Генеративные модели в ВКР: продуктовые метрики ИИ-сервиса на примере закрытия Sora

24 марта 2026 года TechCrunch сообщил: приложение Sora закрывается. При этом модель Sora 2 — генерация видео и звука — по-прежнему производит сильное впечатление. Разошлись две вещи, которые студенты постоянно путают: качество модели и жизнеспособность продукта. Лента, состоящая только из ИИ-контента, не удержала пользователя, и никакая красота кадров это не компенсировала.

Для выпускника ИТ-направления это подарок, а не повод для грусти. Появляется защищаемая ниша: ВКР, где генеративная модель — не самоцель, а компонент системы, у которой есть стоимость вывода, задержки, модерация, наблюдаемость и метрики удержания. Именно такие работы выглядят убедительно на защите, потому что в них есть расчёты, а не только демонстрация красивого ролика.

Три темы ВКР, которые вырастают прямо из этого кейса

Тема 1. Проектирование архитектуры сервиса генерации видео с контролем стоимости инференса

• Актуальность. Sora показала: генерация видео на GPU — дорогая операция, и без управления себестоимостью продукт не живёт. В открытых источниках и в отчёте TechCrunch это читается как главный технический урок кейса.
• Цель. Разработать архитектуру сервиса генерации, в которой время вывода и стоимость одной генерации ограничены заданными значениями при пиковой нагрузке.
• Задачи. Классифицировать сценарии генерации по «весу»; спроектировать очередь задач и батчинг; обосновать автоскейлинг GPU-подов; рассчитать стоимость одной генерации и точку окупаемости.
• Структура. Глава 1 — анализ моделей и способов их развёртывания (vLLM, Triton, внешние API). Глава 2 — архитектура: API-шлюз, очередь, воркеры, объектное хранилище, кэш. Глава 3 — нагрузочное тестирование, расчёт TCO и выводы.

Тема 2. Подсистема модерации и маркировки синтетического контента

• Актуальность. Заголовок статьи прямо называет приложение «самым жутким на телефоне». Вопрос доверия и модерации — не бюрократия, а условие существования продукта.
• Цель. Спроектировать контур модерации, снижающий долю недопустимого контента в выдаче до заданного порога.
• Задачи. Сравнить подходы (правила, классификаторы, человеческая проверка); реализовать метаданные происхождения и водяные знаки; построить метрики полноты и точности; описать эскалацию спорных случаев.
• Структура. Глава 1 — обзор стандартов маркировки и требований к обработке контента. Глава 2 — проектирование конвейера: предфильтр, классификатор, апелляция. Глава 3 — оценка качества на размеченной выборке.

Тема 3. Продуктовая аналитика ИИ-сервиса: почему лента не удержала пользователя

• Актуальность. Формулировка статьи — «не было устойчивого интереса к ленте, состоящей только из ИИ» — это готовое техническое задание на систему сбора и анализа метрик.
• Цель. Построить подсистему аналитики, позволяющую обнаружить падение удержания до того, как продукт придётся закрывать.
• Задачи. Спроектировать схему событий; собрать когортный анализ; связать технические метрики (p95 задержки, доля ошибок) с продуктовыми (возврат на 7-й день); сформулировать правила алертов.
• Структура. Глава 1 — обзор моделей измерения качества ПО по ISO/IEC 25010. Глава 2 — проектирование хранилища событий и дашбордов. Глава 3 — эксперимент и интерпретация результатов.

Аналитическая глава: как обосновать выбор стека и не повторить ошибку Sora

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

Обратите внимание на последнюю строку таблицы: критерий «что писать в ВКР» — не шутка. Выбирайте вариант, по которому сможете собрать числовые данные. Если стенда с GPU нет — берите внешний API и честно считайте экономику на тарифах, это тоже полноценный результат.

Проектная часть: архитектура и интеграция

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

• Очередь генерации. Тяжёлые задачи нельзя держать в синхронном HTTP-запросе. Асинхронная схема «принял — поставил в очередь — вернул идентификатор — отдал результат по готовности» снимает большую часть проблем с таймаутами.
• Кэширование и дедупликация. Повторные запросы с близкими параметрами — прямой путь к экономии GPU-часов. Опишите хеширование параметров и политику вытеснения.
• Хранилище артефактов. Видео и звук живут в объектном хранилище, а в базе — только метаданные и ссылки. Иначе база станет бутылочным горлышком.
• Контур модерации. Предфильтр промпта, проверка результата, журнал решений. Обязательно предусмотрите апелляцию — иначе получите поток жалоб.

Минимальный фрагмент конфигурации автоскейлинга по метрике очереди — хорошая иллюстрация в приложении к диплому:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: video-worker
spec:
  scaleTargetRef:
    kind: Deployment
    name: video-worker
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Pods
      pods:
        metric:
          name: queue_depth_per_replica
        target:
          type: AverageValue
          averageValue: "5"

Тестирование и метрики: где большинство работ теряет баллы

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

Пример запроса для расчёта 95-го процентиля задержки — его удобно привести в приложении:

histogram_quantile(
  0.95,
  sum(rate(generation_duration_seconds_bucket[5m])) by (le, model)
)

Отдельно опишите процедуру восстановления: целевое время восстановления (RTO) и точку восстановления данных (RPO). Для сервиса генерации разумно держать RPO на уровне метаданных и ссылок, а сами артефакты — восстанавливать из объектного хранилища с версионированием.

Чему вы научитесь на такой работе

• Обосновывать выбор стека числами, а не фразой «широко используется».
• Строить схему развёртывания с учётом стоимости ресурсов, а не только функциональности.
• Настраивать наблюдаемость: метрики, логи, трассировки — и связывать их с продуктовыми показателями.
• Оформлять техническую документацию по ГОСТ 34.602-89 так, чтобы её читал не только научный руководитель.
• Считать экономику внедрения и защищать допущения, а не прятать их.

Частые вопросы

Обязательно ли писать код и разворачивать прототип?

Не всегда, но прототип резко повышает защищаемость. Достаточно одного сквозного сценария: приём запроса, постановка в очередь, генерация через внешний API, запись метаданных и вывод метрик на дашборд. Этого хватает, чтобы подтвердить расчёты третьей главы.

Как измерить производительность, если нет доступа к GPU?

Используйте внешний API и измеряйте задержку по сети, включая ожидание в очереди. Отдельно смоделируйте расчёт стоимости при своём инференсе по открытым тарифам на аренду ускорителей — это корректный сценарий для ВКР, если допущения описаны явно.

Где брать тестовые данные для оценки модерации?

Открытые размеченные наборы плюс собственная выборка из 150–300 примеров, размеченная вручную по заранее описанной инструкции. Обязательно приведите инструкцию разметчика в приложении — это снимает половину вопросов комиссии.

Как оформлять UML-диаграммы для диплома?

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

Источник: OpenAI’s Sora was the creepiest app on your phone — now it’s shutting down (опубликовано 2026-03-24)