Мультимодальный AI-поиск в дипломе: архитектура голосового ассистента, которую защитит любой рецензент
Google раскатал Search Live на 200+ стран и десятки языков — теперь пользователь наводит камеру на полку из IKEA, спрашивает вслух «как это собрать», и получает голосовой ответ со ссылками на источники. За этим стоит не «магия LLM», а связка потокового распознавания речи, мультимодального поиска по изображению и синтеза ответа с жёстким бюджетом задержки. Для выпускника ИТ это готовый каркас ВКР: здесь есть распределённая архитектура, метрики качества, вопросы приватности и вполне измеримая эффективность. Ниже — как превратить новость из The Verge в защищаемую работу, а не в реферат «про искусственный интеллект».
Вопросы, которые студенты задают первыми
Мне дадут реальные данные Google для обучения модели?
Нет и не нужно. В ВКР по этому поддомену вы работаете с открытыми датасетами (Common Voice, VoxCeleb, Visual Genome, Flick30k/COCO для image-text) либо формируете собственный небольшой корпус запросов. Обучение с нуля не требуется — достаточно воспроизвести пайплайн на предобученной модели и показать, что вы умеете измерять качество.
Какой стек выбрать, чтобы не утонуть?
Минимальный рабочий набор: Python + FastAPI для оркестрации, Whisper или Vosk для ASR, CLIP/BLIP для мультимодального эмбеддинга, Qdrant или pgvector для векторного поиска, TTS-движок для озвучки. Всё это разворачивается локально или в Docker Compose — рецензенту важен не масштаб, а воспроизводимость.
Как считать эффективность, если нет пользователей?
Считайте технические метрики: WER для распознавания, MOS или PESQ для синтеза, Time-to-First-Token и p95 end-to-end latency, Recall@k для поиска. Плюс экономэффект — стоимость одного запроса при разных вариантах кэширования. Этого достаточно для третьей главы.
Что делать с нормоконтролем, если в работе много кода и схем?
Код — в приложения, схемы — по ГОСТ 19.701-90 или в нотации C4/UML с расшифровкой. Основной текст не должен превращаться в листинг. Соблюдайте ГОСТ 34.601-90 для этапов проектирования и ISO/IEC 25010 для модели качества — это снимает половину замечаний.
Темы ВКР: три вектора на базе новости
-
Тема 1. Мультимодальный поисковый ассистент с голосовым интерфейсом.
Актуальность: Google масштабирует Search Live на десятки языков — значит, задача потокового мультиязычного распознавания и генерации ответа реальна и востребована.
Цель: разработать прототип ассистента, принимающего аудио и изображение и возвращающего озвученный ответ со ссылками.
Задачи: анализ моделей ASR и их задержек; проектирование пайплайна «аудио → текст → запрос → поиск → ответ → TTS»; реализация на открытых компонентах; измерение WER, MOS и p95 latency.
Структура: Глава 1 — обзор мультимодальных архитектур и метрик; Глава 2 — проектирование и реализация пайплайна; Глава 3 — тестирование, замеры, сравнение конфигураций.
-
Тема 2. Оценка качества и задержки голосового AI-ассистента на открытых данных.
Актуальность: глобальная экспансия поднимает вопрос: как язык и акцент влияют на точность и скорость ответа?
Цель: построить методику оценки мультиязычного ассистента по ISO/IEC 25010.
Задачи: сформировать тестовый набор на 3–5 языках; выбрать метрики (WER, BLEU, Recall@k, TTFT); провести серию замеров; визуализировать деградацию качества по языкам.
Структура: Глава 1 — теория оценки качества AI-систем; Глава 2 — стенд и методика замеров; Глава 3 — результаты и рекомендации по оптимизации.
-
Тема 3. Безопасность и приватность мультимодального поиска с камерой.
Актуальность: пользователь показывает камерой личные вещи и помещения — а Google отправляет кадры на сервер. Это класс задач из OWASP LLM Top 10.
Цель: спроектировать схему обработки, минимизирующую утечку персональных данных.
Задачи: классифицировать угрозы (prompt injection через изображение, утечка метаданных, перехват потока); предложить меры (локальный препроцессинг, обрезка EXIF, TTL хранения); реализовать прототип с шифрованием транспорта.
Структура: Глава 1 — анализ угроз и нормативка; Глава 2 — проектирование защищённого пайплайна; Глава 3 — тесты на проникновение и оценка остаточных рисков.
Как встроить кейс Search Live в главы работы
Глава 1: от новости к аналитической модели
Не пересказывайте The Verge — стройте таблицу сравнения. Возьмите Search Live, Google Lens, Apple Visual Intelligence и любой открытый аналог, разложите по осям: способ ввода, модель, поддержка языков, задержка, политика хранения данных. Так вы получаете обоснование актуальности без единой клишированной фразы. Диаграмму — в нотации C4 (уровни Context и Container), это компактно и понятно комиссии.
| Метрика | Что показывает | Инструмент замера | Ориентир для ВКР |
|---|---|---|---|
| WER | Ошибки распознавания речи | jiwer, Whisper eval | < 15% на чистом аудио |
| TTFT | Время до первого токена ответа | OpenTelemetry spans | < 800 мс |
| p95 latency | Задержка 95% запросов | Prometheus + Grafana | < 3 с end-to-end |
| Recall@5 | Качество поиска по изображению | собственный eval-скрипт | > 0.7 |
| MOS | Естественность синтеза речи | экспертная оценка, 5+ человек | > 3.8 |
Глава 2: пайплайн, который реально собирается за семестр
Ключевая мысль: ассистент — это не модель, а конвейер. Разбейте его на четыре сервиса и опишите каждый отдельным разделом. Ниже — скелет конфигурации для инструментирования задержек, его можно вставить в приложение и защищать как «средство сбора метрик».
# otel-collector-config.yaml — сбор метрик пайплайна ассистента
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
processors:
batch:
timeout: 5s
exporters:
prometheus:
endpoint: "0.0.0.0:8889"
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [prometheus]
# Псевдокод оркестратора: audio + image -> ответ
# 1. asr_text = whisper.transcribe(audio_chunk) # потоково, чанки 320 мс
# 2. img_vec = clip.encode(frame) # 1 кадр на запрос
# 3. hits = qdrant.search(asr_text, img_vec) # гибридный поиск
# 4. answer = llm.generate(asr_text, hits[:5])
# 5. tts_out = tts.synthesize(answer) # стриминг по предложениям
# span.set_attribute("ttft_ms", first_token_time - start)
Глава 3: тестирование и цифры, которые не стыдно показать
Соберите стенд на 100–300 запросах, прогнав их через 3 конфигурации: без кэша, с кэшем эмбеддингов, с батчингом ASR. Покажите таблицу «конфигурация → p95 latency → стоимость запроса». Именно такой формат превращает диплом из «я что-то сделал» в «я оптимизировал и измерил». UML-диаграмму последовательности для одного запроса — обязательно в главу 3, она снимает вопросы о понимании потоков данных.
Чему вы научитесь на этой теме
- Проектировать распределённый пайплайн с разделением на stateless-сервисы.
- Считать и интерпретировать метрики качества ML-компонентов, а не только accuracy.
- Инструментировать систему через OpenTelemetry и строить дашборды задержек.
- Оценивать экономику решения — стоимость запроса при разных стратегиях кэширования.
- Оформлять архитектурные схемы по C4/UML и требования по ГОСТ 34.
- Задачи из введения дословно совпадают с выводами по главам.
- Все метрики из таблицы реально замерены, а не взяты из статей.
- Диаграммы подписаны и пронумерованы, есть ссылки в тексте.
- Код вынесен в приложения, в основном тексте — только ключевые фрагменты.
- Оформление соответствует ГОСТ 7.32 и требованиям кафедры.
- Проверена уникальность текста, ссылки на источники оформлены корректно.
- Есть раздел с ограничениями исследования — рецензенты это ценят.
- Обучение модели с нуля «чтобы было серьёзно». Студент месяц гоняет 100 МБ данных и получает WER 60%. В кейсе Search Live ценность не в весах, а в оркестрации. Берите предобученные модели и фокусируйтесь на пайплайне.
- Отсутствие замеров задержки. Мультимодальный ассистент без p95 latency — это презентация идеи, а не инженерная работа. Google строит экспансию именно на latency-бюджете, значит и вы обязаны его считать.
- Игнорирование приватности. Камера и микрофон — чувствительные каналы. Если в ВКР нет ни слова про хранение кадров и обработку персональных данных, вопрос от комиссии придёт гарантированно.
Источник: Google’s ‘live’ AI search assistant can handle conversations in dozens more languages (опубликовано 2026-03-26)