Как настроить голосовой диалог через Gemini Live API и безопасно прерывать ответ

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

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

Пошаговая настройка

1. Выберите архитектуру: server-to-server для контроля на бэкенде или client-to-server с ephemeral token. Никогда не встраивайте постоянный API-ключ в браузер.
2. Настройте захват mono PCM 16 kHz little-endian и воспроизведение PCM 24 kHz. Проверьте длительность и амплитуду тестового тона.
3. Откройте stateful WebSocket, отправьте конфигурацию сессии и только затем аудиофреймы.
4. Реализуйте barge-in: при новой речи пользователя остановите локальное воспроизведение старого ответа и очистите очередь звука.
5. Сохраняйте транскрипты входа и выхода с session_id, но не сырое аудио без явной политики. Тестируйте разрыв сети и повторное подключение как новую сессию.

После вызова сохраняйте request ID, HTTP-статус, model id, версию инструкции и usage, если он доступен. Таймаут не означает, что операция не произошла: перед повтором проверьте фактическое состояние.

Копируемый шаблон

Роль: голосовой помощник магазина.
Отвечай максимум двумя предложениями.
Перед заказом запроси артикул и количество.
Никогда не подтверждай оплату без tool result.
При прерывании останови текущий ответ и обработай последнюю реплику.
Неизвестный факт -> «уточню по базе».

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

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

Пользователь спрашивает цену, затем на середине ответа говорит «стоп, нужен другой артикул B-17». Ожидается мгновенная остановка старого аудио и новый запрос по B-17. Одновременное проигрывание двух ответов — провал.

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

Проверка результата по уровням

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

Создайте таблицу с колонками case_id, expected, actual, source, status, error_type. Размечайте format_error, unsupported_claim, wrong_action и security_error отдельно. Иначе красивый средний процент скроет критический вызов не той функции.

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

Контроль в рабочей системе

Разделите вход, сетевой вызов, разбор ответа и бизнес-валидацию. Сначала проверяются размер, тип и права, затем выполняется API-запрос, потом структура и только после неё значения. Невалидный ответ не передаётся следующему узлу.

В журнал кладите hash входа, case_id, модель, версию промпта, request ID, длительность и решение валидатора. Не сохраняйте ключ, персональные данные и полный документ без необходимости. Для операций записи используйте idempotency_key.

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

Приёмка на конкретных данных

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

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