25 марта 2026 года Google анонсировала Lyria 3 Pro — обновлённую модель генерации музыки, которая умеет создавать более длинные треки и позволяет тонко настраивать результат. Компания расширяет интеграцию ИИ-музыки сразу в несколько продуктов: Gemini, корпоративные сервисы и сторонние платформы. Для выпускника ИТ-направления это не «новость из мира музыки», а сигнал: класс задач «генеративный контент как сервис» окончательно перешёл из научных статей в продакшн. Значит, тема диплома, связанная с интеграцией подобных моделей, оценкой их качества или построением инфраструктуры вокруг них, звучит актуально и легко защищается. Ниже — как превратить эту новость в рабочую структуру ВКР, какие метрики использовать и где чаще всего «сыпятся» студенты.
Актуальность. Lyria 3 Pro встроена в несколько экосистем сразу — это типичный сценарий «одна модель, много потребителей». Значит, востребована архитектура промежуточного слоя: аутентификация, квоты, кэш, обработка длинных задач.
Цель: спроектировать и реализовать сервис-посредник, который принимает запросы на генерацию трека и отдаёт результат асинхронно.
Задачи:
Структура: Глава 1 — анализ генеративных моделей и способов их предоставления как сервиса; Глава 2 — проектирование архитектуры и схемы БД, UML-диаграммы; Глава 3 — тестирование, расчёт экономики внедрения и сравнение с готовыми решениями.
Актуальность. Раз модель стала «более настраиваемой», кто-то должен эту настраиваемость измерять. Задача оценки качества генеративного контента — открытая и хорошо защищаемая ниша.
Цель: построить пайплайн, который автоматически считает объективные метрики качества для набора сгенерированных треков.
Задачи: собрать тестовый датасет промптов; реализовать расчёт метрик (FAD-подобные дистанции, спектральные характеристики, перцептивные оценки); оформить регрессионные тесты и отчёты; описать методику сравнения двух версий модели.
Структура: Глава 1 — обзор подходов к оценке генеративного аудио; Глава 2 — проектирование пайплайна и хранилища артефактов (MLflow, DVC); Глава 3 — эксперименты, статистика, выводы по применимости методики.
Актуальность. Публичный запуск модели у Google почти гарантированно вызовет пики трафика. Для диплома это идеальный полигон: показать, как GPU-нагрузка укладывается в кластер и как считаются затраты.
Цель: разработать конфигурацию развёртывания инференс-сервиса с автомасштабированием и мониторингом.
Задачи: выбрать тип нагрузки (Deployment/StatefulSet), настроить Horizontal Pod Autoscaler по кастомной метрике; подключить OpenTelemetry для трассировки; рассчитать RTO/RPO и стоимость часа простоя.
💡 Если тема уже выбрана, но непонятно, как уложить её в требования кафедры и успеть к сроку — можно обсудить это с нашими архитекторами: бесплатная консультация 30 минут, разбор структуры и подбор метрик. Средний срок сопровождения работы — от 120 часов работы в вашем графике. Поможем с любой темой, включая генеративные модели и инфраструктуру.
Первая глава не должна превращаться в реферат «что такое ИИ». Работает другая логика: вы берёте конкретный кейс (Lyria 3 Pro) как точку отсчёта и сравниваете с ним свои альтернативы. Сравнительная таблица — половина успеха защиты.
| Критерий | Lyria 3 Pro (по статье) | Открытые аналоги | Вывод для проекта |
|---|---|---|---|
| Длина генерации | Увеличенная (треки, а не фрагменты) | Ограничена окном контекста | Проектировать очередь для длинных задач |
| Настраиваемость | Заявлена как ключевая фича | Частично, через промпт-инжиниринг | Нужна валидация параметров на входе |
| Способ доставки | SaaS через Gemini и enterprise-каналы | Self-hosted | Сравнить TCO аренды и развёртывания |
| Лицензирование | Проприетарное | Вариативно | Учесть в разделе рисков |
Логичный ход — обосновать стек через ISO/IEC 25010: производительность, надёжность, сопровождаемость. Тогда фраза «мы выбрали Python» превращается в «выбор обусловлен требованиями по сопровождаемости (пункт 5.3 стандарта) и доступностью библиотек для работы с аудио».
Здесь статья даёт готовый сценарий для sequence-диаграммы. Раз модель генерирует длинные треки, синхронный HTTP-ответ на 30 секунд — плохая идея. Покажите в дипломе асинхронный паттерн:
Клиент → API Gateway → Queue (broker) → Worker (GPU) → Object Storage
↓ ↓
job_id клиенту status: pending → doneДальше — три уровня артефактов, которые ждёт комиссия:
Техническое задание оформляйте по ГОСТ 34.602-89 — это самый частый формальный минус на защите, когда ТЗ есть, но структура не совпадает с ГОСТ.
Фраза «система работает быстро» не защищается. Нужны числа и методика их получения.
| Метрика | Как измерять | Инструмент | Норма |
|---|---|---|---|
| P95 времени ответа API | Нагрузочный прогон, 95-й перцентиль | k6, Locust | Зависит от ТЗ |
| Пропускная способность | RPS при ошибке < 1% | k6 | По нагрузке пилота |
| Полное время генерации | От постановки в очередь до готового файла | OpenTelemetry traces | Отражается в SLA |
| Доступность сервиса | Uptime, число 5xx | Prometheus + Grafana | ≥ 99% за период |
| RTO / RPO | Сценарий отказа узла | Chaos-тест, руками | Задаётся в ТЗ |
Отдельно стоит показать стоимость: если генерация идёт на GPU, посчитайте рубль за минуту аудио. Такой расчёт делает работу инженерной, а не описательной — и часто решает спорные баллы на защите.
1. Путают SaaS и PaaS без обоснования. Пишут «развернём модель в облаке» — и всё. Как избежать: явно укажите модель предоставления услуг, ответственность провайдера и вашу зону контроля, привяжите к таблице сравнения.
2. Нет ни одной измеримой метрики. Оценки «быстрее/удобнее» комиссия не принимает. Как избежать: минимум три числовые метрики с методикой измерения и инструментом.
3. Игнорируют требования ГОСТ 34.602-89 к ТЗ. Разделы стоят не в том порядке, нет подписей, нет ссылок на нормативные документы. Как избежать: возьмите утверждённую структуру ТЗ и просто пройдитесь по пунктам.
4. Забывают связать цели и выводы. Каждая задача из введения должна иметь отражение в заключении. Сверьте списки перед печатью.
Зависит от кафедры. В инженерных программах прототип почти обязателен, но он не обязан быть продакшн-уровня. Достаточно работающего минимального сценария: принять запрос, поставить в очередь, отдать результат. Остальное — схемы и обоснования.
Используйте открытые датасеты музыкальных фрагментов и собственную синтетику. В разделе «Ограничения исследования» честно укажите, что тестирование проводилось на аналоге — это нормальная научная практика, а не минус.
Прототип с асинхронной обработкой — примерно 40–60 часов с нуля. Главы с расчётами и оформление — ещё столько же. Если сроки поджимают, разумно распараллелить: вы делаете содержательную часть, а рутинное оформление и вычитку можно делегировать.
Единый нотатор во всей работе, подписи под рисунками, ссылки на рисунки в тексте. В приложении — исходники диаграмм. Если кафедра требует ГОСТ, проверьте соответствие 19.701-90 до финальной сдачи.
Если вы ещё только выбираете направление и формулировку — начните с малого: возьмите эту новость, посмотрите, какая из трёх тем ближе вашему стеку, и набросайте одну страницу «цель → задачи → метрики». Этого достаточно, чтобы понять, потянете ли вы тему. А дальше либо пишете сами, либо подключаете помощь — в обоих случаях структура у вас уже будет на руках.
Источник: Google launches Lyria 3 Pro music generation model (опубликовано 2026-03-25)