Архитектура AI-анализа звонков: очереди и LLM

Автоматический анализ звонка выглядит простой цепочкой: загрузить аудио, получить текст, отправить текст в LLM и показать ответ. Для демонстрации этого достаточно. Для рабочего сервиса — нет.

Production-сценарий должен переживать большие файлы, параллельные загрузки, ограничения внешних API, повторный анализ и частичные ошибки. Поэтому центральная задача здесь не промпт, а устройство конвейера.

Разделение дорогого и изменяемого этапов

Транскрибация и анализ текста имеют разный жизненный цикл.

Аудио транскрибируется один раз, а результат сохраняется.
Критерии оценки, чек-лист и промпт могут меняться.
Готовый транскрипт можно анализировать повторно без повторной обработки аудио.

Такое разделение снижает число обращений к speech-to-text и позволяет улучшать правила оценки независимо от исходного файла.

Аудио
  → объектное хранилище
  → очередь транскрибации
  → транскрипт в базе
  → очередь анализа
  → структурированный результат
  → агрегаты и отчёт

Почему обработка должна быть асинхронной

HTTP-запрос не должен ждать завершения распознавания и LLM-анализа. Пользователь получает идентификатор задачи, а фоновые workers последовательно меняют её состояние.

Практический набор состояний может выглядеть так:

pending → processing → transcribing → analyzing → completed
                                              ↘ failed

Очередь ограничивает число одновременных обращений к провайдерам, повторяет временно упавшие операции, сохраняет наблюдаемое состояние каждой задачи и отделяет пользовательский API от тяжёлой обработки.

В Sales Call Insight для этого используются BullMQ и Redis, а прикладные данные и результаты хранятся в PostgreSQL.

Структурированный ответ вместо свободного текста

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

Перед сохранением ответ проходит техническую проверку:

JSON соответствует ожидаемой структуре;
обязательные поля заполнены;
ссылки на фрагменты транскрипта существуют;
значения оценок находятся в допустимом диапазоне;
ошибка одного критерия не уничтожает весь результат.

LLM здесь является частью pipeline, а не источником истины. Финальный контракт задаёт приложение.

Повторный анализ и версионирование

Если компания меняет скрипт продаж, старые звонки полезно оценить по новой версии. Для этого у анализа должны быть собственные версия, параметры и дата запуска.

Минимальная модель связывает исходный звонок, неизменяемый транскрипт, версию скрипта оценки, конкретный запуск анализа и структурированный результат. Это позволяет сравнивать версии, объяснять расхождения и не перезаписывать историю.

Проверка рабочего сценария

Тестировать нужно не только отдельный промпт. Основной E2E-путь проходит от загрузки файла до появления отчёта в интерфейсе.

Отдельно проверяются:

неподдерживаемый или повреждённый файл;
временная недоступность SpeechKit или LLM;
повторная постановка задачи;
разграничение доступа между пользователями;
batch-загрузка нескольких звонков;
повторный анализ сохранённого транскрипта.

Количественные бизнес-метрики для такого сервиса имеют смысл только после сверки с рабочими данными. До этого корректно публиковать архитектуру, функции, метод проверки и ограничения системы.

Итоговая инженерная рамка

Надёжный AI-анализ звонков строится вокруг управляемого процесса: очередей, состояний, схем данных, повторяемости и проверки. Модель выполняет ограниченную операцию внутри этого процесса.

Подробная реализация и схема компонентов собраны в кейсе Sales Call Insight.

Архитектура AI-анализа звонков: от аудиофайла до управленческого отчёта