Гайд · TNWS AI
Как расшифровать аудио через Deepgram API и проверить точность результата
Практический запрос к /v1/listen для локального WAV и файла по URL: Nova-3, smart_format, структура JSON, confidence и критерии приёмки.
Что решает этот материал
Статья отвечает на запрос «как расшифровать аудио Deepgram API». Параметры и ограничения сверены 12 сентября 2026 года с первичной документацией Deepgram. Цель — получить воспроизводимый результат на контрольном аудио и доказать его пригодность, а не принять любой HTTP 200 за успех.
Применимость и версия
Предзаписанное аудио через REST endpoint /v1/listen. Пример использует явно выбранную nova-3; если убрать model, документация указывает default base, поэтому модель лучше фиксировать.
Перед запуском проверьте страницу Models and Languages: доступные языки, голоса и сочетания функций меняются. Зафиксируйте endpoint, model id, язык, формат входа и версию SDK в журнале теста. Постоянный ключ храните только на backend как DEEPGRAM_API_KEY; не помещайте его в браузер, мобильный пакет, репозиторий или скриншот.
Факты из официальной документации
- Локальный WAV передаётся бинарным телом с корректным Content-Type, а удалённый файл — JSON-объектом с полем url.
- Официальный пример вызывает POST
https://api.deepgram.com/v1/listen?model=nova-3&smart_format=true. - Текст находится в
results.channels[0].alternatives[0].transcript; слова содержат start, end и confidence. - Максимальный размер предзаписанного файла — 2 ГБ; Deepgram советует извлекать аудиодорожку из больших видео.
Эти параметры решают разные задачи. Модель распознаёт речь, formatter меняет представление текста, diarization присваивает словам номера говорящих, а utterances формирует смысловые сегменты. Включение одной функции не означает автоматическое включение остальных, кроме явно документированных связей.
Подготовка контрольных данных
- Сделайте короткую синтетическую запись без персональных данных. Запишите точный эталон текста и ожидаемые границы реплик.
- Измерьте реальный контейнер, кодек, sample rate и число каналов через
ffprobe; расширение файла само по себе ничего не гарантирует. - Для сравнения функций используйте один и тот же файл. Меняйте ровно один query parameter, иначе нельзя объяснить разницу.
- Определите машинные проверки до запроса: непустое поле, допустимый язык, отсутствие секрета, множество speaker id или совпадение ключевого термина.
- Храните исходный JSON целиком вместе с request id. Производный TXT или субтитры не заменяют ответ API.
Пример карточки входа:
file: control.wav
container: wav
codec: pcm_s16le
sample_rate: 16000
channels: 1
expected_phrase: "контрольная фраза"
contains_real_personal_data: false
Не копируйте характеристики этого шаблона вслепую: значения обязаны совпадать с вашим файлом. Для streaming добавьте размер audio chunk, частоту отправки и момент намеренного разрыва соединения.
Пошаговая настройка
- Создайте отдельный ключ для тестовой среды и экспортируйте
DEEPGRAM_API_KEY. Не выводите переменную командой, которая попадёт в общие логи. - Сверьте поддержку функции для выбранных модели, языка и batch/streaming режима. Особенно внимательно проверяйте языковые ограничения intelligence и redaction.
- Выполните минимальный запрос ниже без собственных retry и middleware. Так видны исходные HTTP-код, заголовки и тело ошибки.
- Проверьте Content-Type входа и фактический формат байтов. Для URL-входа удостоверьтесь, что ссылка доступна серверу и отдаёт именно медиа.
- Разберите документированное поле ответа; не ищите текст рекурсивно и не подставляйте пустую строку вместо отсутствующего объекта.
- Сравните результат с эталоном: Для контрольной записи «Заказ сорок два готов к выдаче» JSON содержит непустой transcript, слова с временными метками и request_id; номер и ключевая фраза сверяются с эталоном.
- Проведите отрицательный тест: испорченный ключ, неподдерживаемая комбинация, неверный формат либо контрольный секрет. Ожидаемая ошибка должна быть обработана явно.
Рабочий шаблон
curl --request POST \
--header "Authorization: Token $DEEPGRAM_API_KEY" \
--header "Content-Type: audio/wav" \
--data-binary @control.wav \
--url 'https://api.deepgram.com/v1/listen?model=nova-3&language=ru&smart_format=true' \
--output result.json
jq -e '.results.channels[0].alternatives[0].transcript | length > 0' result.json
Шаблон не содержит настоящего ключа. Файлы и model id должны быть проверены в текущей документации. Команда jq -e важна: она завершает сценарий ошибкой, когда бизнес-условие ложно, даже если транспортный запрос прошёл.
Контрольный вход и ожидаемый результат
Используйте запись с заранее известным текстом, а не случайный подкаст. Для терминов подготовьте несколько произнесений разными дикторами; для diarization — известный порядок двух голосов; для redaction — только синтетические номера. Оценка на одном красивом примере не показывает устойчивость.
Ожидаемый результат: Для контрольной записи «Заказ сорок два готов к выдаче» JSON содержит непустой transcript, слова с временными метками и request_id; номер и ключевая фраза сверяются с эталоном.
Для распознавания посчитайте word error rate или хотя бы долю совпавших обязательных фраз. Для сегментации проверьте временной порядок и потерянные слова. Для TTS техническая валидность файла не заменяет прослушивание. Для summary отдельно проверяйте факты: модель может создать связный, но неточный пересказ.
Критерии приёмки
- HTTP 200 и JSON
- request_id сохранён
- transcript не пуст
- ключевая фраза совпала
- низкоуверенные слова отмечены
Также сохраняйте HTTP-код, request id, model metadata, длительность исходного аудио и время обработки. Порог качества определяйте на своей размеченной выборке. Универсальное число confidence не гарантирует правильности бренда, суммы или фамилии.
Типичные ошибки и что не делать
- Отправлять путь к локальному файлу в JSON как будто это публичный URL.
- Считать общий confidence доказательством правильности каждого термина.
- Не сохранять единственный API-ответ: документация предупреждает, что транскрипты сервисом не хранятся.
Не включайте сразу все параметры. Сначала получите baseline, затем добавляйте diarization, utterances, formatting или intelligence по одному. Иначе регрессия не локализуется. Не повторяйте запросы с ошибкой 400: это ошибка конфигурации, а не временный сбой. Для 429 и 5xx используйте ограниченный backoff с jitter и сохраняйте идемпотентность собственной обработки.
Нельзя считать номер спикера личностью, автоматически публиковать низкоуверенные имена или полагаться на redaction как на единственный уровень защиты. Минимизируйте исходные данные до передачи, ограничивайте доступ к аудио и удаляйте временные файлы по своей политике хранения.
Готовый промпт для аудита результата
Ты проверяешь результат Deepgram для сценария «как расшифровать аудио Deepgram API».
Используй только приложенные: эталон, параметры запроса и JSON-ответ.
Верни таблицу: проверка | ожидается | фактически | PASS/FAIL | исправление.
Не восстанавливай отсутствующие слова. Отдельно отметь низкий confidence,
несовместимость model/language/feature и любое появление контрольного секрета.
HTTP 200 сам по себе не является PASS.
Перед отправкой JSON в другую модель удалите ключи, реальные персональные данные и лишние фрагменты разговора. Итоговый PASS должен вычисляться кодом по заданным правилам, а не мнением второго генератора.
Проверка на серии реальных данных
Соберите 20–50 обезличенных примеров из целевого канала: тихая и шумная запись, разные микрофоны, короткая пауза, перебивание, редкий термин и пустой звук. Храните эталон отдельно от ответа API. После смены model id, языка, форматтера или SDK прогоняйте весь набор заново.
Отдельно измеряйте технический успех и содержательный: долю HTTP 200, долю валидных JSON, полноту финальных сегментов и точность обязательных полей. Полезная метрика — стоимость и задержка одного принятого результата с учётом повторов и ручной проверки, а не скорость одного удачного запроса.
FAQ
Достаточно ли HTTP 200?
Нет. Нужно проверить структуру JSON или аудиофайл и конкретное бизнес-условие.
Можно ли ориентироваться только на confidence?
Нет. Калибруйте порог на собственной размеченной выборке и отдельно проверяйте критичные сущности.
Где хранить API-ключ?
В backend-секрете или менеджере секретов; не в клиентском коде и не в публикации.
Нужно ли фиксировать model id?
Да. Иначе смена значения по умолчанию может незаметно изменить качество и формат результата.
Официальный источник
Частые вопросы
Достаточно ли HTTP 200?
Нет, проверьте структуру и бизнес-условие.
Можно ли хранить ключ в браузере?
Нет, постоянный ключ хранится на backend.
Нужно ли тестировать один и тот же файл?
Да, для A/B меняйте ровно один параметр.
Где проверять совместимость?
В актуальной официальной документации Deepgram.
Читайте также
Как настроить streaming в Deepgram API без потери финальных реплик
WebSocket-транскрибация Deepgram: параметры кодека, interim_results, is_final, завершение потока, сбор финального текста и тест на обрыв.
Как определить язык аудио в Deepgram и проверить language_confidence
detect_language=true для предзаписанного и streaming-аудио: detected_language, confidence, многоканальные записи и отличие от multilingual.
Как озвучить текст через Deepgram TTS и сохранить корректный аудиофайл
POST /v1/speak, Aura-2, MP3 или WAV, Content-Type, потоковый ответ, fail-with-body и техническая проверка файла через ffprobe.
Комментарии
Пока тихо. Скажите первое слово