Телефонный звонок → структурированный JSON: строим STT + LLM пайплайн на Python

[temadiary]

АТС не отдаёт стерео, ну совсем не отдаёт.
стерео не так работает

[SmartAgent]

АТС действительно из коробки отдаёт моно — MixMonitor по умолчанию миксует оба направления в один файл. Но Asterisk умеет писать каналы раздельно, нужно только указать флаги r() и t():

MixMonitor(${fname}.wav,r(${fname}-in.wav)t(${fname}-out.wav),/usr/local/bin/stereo-encode.sh ${fname})

r() — входящий поток (клиент), t() — исходящий (оператор). Получаем два отдельных WAV.

Дальше post-process скриптом склеиваем в стерео через sox:

sox -M ${fname}-in.wav ${fname}-out.wav ${fname}-stereo.wav
lame -b 32 -m s ${fname}-stereo.wav ${fname}.mp3

На выходе: левый канал = клиент, правый = оператор. Диаризация бесплатно, pyannote не нужен

[temadiary]

астериск это компьютерная телефония
указывайте лучше домен применения
есть ещё нормальных программно-аппаратных атс на свете много используемых повсеместно

[SmartAgent]

Верно, Asterisk это IP-телефония. В статье речь про облачные АТС (Mango, UIS, Zadarma) и SIP-платформы. MixMonitor с раздельной записью каналов это решение для Asterisk-based систем. Для аппаратных АТС запись стерео зависит от конкретного вендора и его API.

[freejoins]

Покрайней мере на Asterisk есть MixMonitor и к примеру такая конструкция:

 same => n,Set(__REC_FILENAME_IN=${ASTSPOOLDIR}/monitor/${STRFTIME(${EPOCH},,%Y/%m/%d)}/${AUDIO_FILE}-in.${RECORDING_FORMAT})
 same => n,Set(__REC_FILENAME_OUT=${ASTSPOOLDIR}/monitor/${STRFTIME(${EPOCH},,%Y/%m/%d)}/${AUDIO_FILE}-out.${RECORDING_FORMAT})
 same => n,Set(AUDIO_FILE_AI=${STRFTIME(${EPOCH},,%Y%m%d%H%M%S)}-${UNIQUEID}-${CALL_TYPE_LABEL}-${CALL_SOURCE}-${CALL_DESTINATION})
 same => n,Set(__REC_FILENAME_AI=${ASTSPOOLDIR}/monitor/${STRFTIME(${EPOCH},,%Y/%m/%d)}/${AUDIO_FILE_AI}.${RECORDING_FORMAT})
 same => n,MixMonitor(,r(${REC_FILENAME_IN})t(${REC_FILENAME_OUT}),/usr/bin/sox -M ${REC_FILENAME_OUT} ${REC_FILENAME_IN} ${REC_FILENAME_AI && rm ${REC_FILENAME_IN} && rm ${REC_FILENAME_OUT})

Которая делает два файла с раздельной записью звонящего и отвечающего и еще 1 файл в котором звонящий/отвечащий так же разбиты на левый и правый каналы. В принципе ради любопытсва собирал стенд. С RTX5090+RTX5070Ti + n8n + ollama (qwen3.5:27b) + speaches.io (Whisper large-v3) и похожий промт давали вполне приемлемый результат и JSON никогда не ломался. После обработки все это складывалось в БД.

[ioleynikov]

Мне кажется в вашем пайплайне не хватает RAG (генерация с дополненной выборкой) компоненты. Это позволит гибко адаптировать систему к конкретным сервисам: банки, коммерция, медицина, страховка, ... Каждая область имеет свою специфику, терминологию, протокол общения. Модифицировать LLM очень накладно, а вот затраты внедрения RAG не велики и в смысле желез, софта и работы. Интересная статья. Спасибо Удачи ! p.s. Теоретически можно попробовать подставлять на вход RAG + мультимодальной модели нейросети не сгенерированный ASR текст (возможно искаженный), а сами вектора эмбеддингов фраз? Точнее и текст с промтами и вектор аудиосигнала.

[SmartAgent]

Спасибо! RAG рассматривали на практике — собрали 12 000+ пар «контекст→ответ» из реальных разговоров операторов, сделали embedding search (sentence-transformers, 384-dim). Результат: поиск находит похожие по словам фразы, но не понимает контекст разговора. Например, «не работаю с агентами» → retrieval выдаёт «До свидания» (самый частый ответ), а нужно убеждать: «Комиссию платит клиент».

Корневая проблема — retrieval не знает, на каком шаге разговора мы находимся и какой следующий логический ход. LLM это понимает из коробки, видя всю историю диалога.

По стоимости: Groq (Llama-3.3-70B) ~$0.003 за звонок (10 реплик × 500 токенов), латентность 300-500мс. RAG потребовал бы vector DB + embedding model + логику ранжирования — и всё равно не дал бы нужного качества.

По поводу подачи аудио-эмбеддингов напрямую в мультимодальную модель — идея интересная, но пока реальные мультимодальные модели с audio input (Gemini, GPT-4o) имеют слишком высокую латентность для real-time телефонии (~2-5с). Связка Deepgram STT (200мс) + текстовый LLM (400мс) пока быстрее.

[ioleynikov]

Я вас понял, Молодцы! Очень интересный проект и направления мысли. Контекст разговора надо иметь глобальный (общий для данной предметной области) и частный для конкретных пользователей. RAG надо скорее всего переделать на GraphRAG. У меня есть наработки интеграции LLM с классическим ИИ на основе логического вывода типа Prolog, экспертная система CLIPS. Это позволяет полностью сделать прозрачной, верифицируемой логику выводов, уйти от необходимости использовать сверхтяжелые нейросети рассуждений. В комбинации с глобальным и персональными контекстами это должно существенно повысить точность ответов. У меня так же есть опыт оптимизации скоростей работы мультимодальных сетей и я думаю, что удастся найти локальное решение со скоростью реального времени для не вверх сложных задач. Я бы мог подключиться к решению этих проблем в рамках разумного бюджета, но только с оплатой на международные карточки если это вам интересно и нужно. Еще раз спасибо за статью, ответ и Удачи !