Объём зависит от агента, у нас их несколько и система собирает промпт динамически. У master-агента (основной ассистент в Telegram) получается около 240 КБ, у автономного директора по маркетингу около 70 КБ, у узких субагентов (email, SEO, content, ads) 25-65 КБ.
Структура единая, это конструктор из блоков: роль агента, общие правила проекта, правила по каналам, хвост событий за последние 72 часа из нашей шины, релевантные feedback-правила от CEO, открытые GitHub Issues, негативные сигналы за неделю, индекс доступных скилов. Собирается заново на каждый вызов, с учётом профиля — master получает всё, директор без memory, субагенты получают только свой канал и общие правила. Каждый блок имеет бюджет в символах, лишнее обрезается. Такой подход даёт свежий контекст на каждый запрос и заметно экономит токены и стоимость за счёт того что субагенту не подгружается то что ему не нужно.
Спасибо! 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мс) пока быстрее.
Верно, Asterisk это IP-телефония. В статье речь про облачные АТС (Mango, UIS, Zadarma) и SIP-платформы. MixMonitor с раздельной записью каналов это решение для Asterisk-based систем. Для аппаратных АТС запись стерео зависит от конкретного вендора и его API.
АТС действительно из коробки отдаёт моно — MixMonitor по умолчанию миксует оба направления в один файл. Но Asterisk умеет писать каналы раздельно, нужно только указать флаги r() и t():
Объём зависит от агента, у нас их несколько и система собирает промпт динамически. У master-агента (основной ассистент в Telegram) получается около 240 КБ, у автономного директора по маркетингу около 70 КБ, у узких субагентов (email, SEO, content, ads) 25-65 КБ.
Структура единая, это конструктор из блоков: роль агента, общие правила проекта, правила по каналам, хвост событий за последние 72 часа из нашей шины, релевантные feedback-правила от CEO, открытые GitHub Issues, негативные сигналы за неделю, индекс доступных скилов. Собирается заново на каждый вызов, с учётом профиля — master получает всё, директор без memory, субагенты получают только свой канал и общие правила. Каждый блок имеет бюджет в символах, лишнее обрезается. Такой подход даёт свежий контекст на каждый запрос и заметно экономит токены и стоимость за счёт того что субагенту не подгружается то что ему не нужно.
Да так и происходит по факту ))
Спасибо! 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мс) пока быстрее.
Верно, Asterisk это IP-телефония. В статье речь про облачные АТС (Mango, UIS, Zadarma) и SIP-платформы. MixMonitor с раздельной записью каналов это решение для Asterisk-based систем. Для аппаратных АТС запись стерео зависит от конкретного вендора и его API.
АТС действительно из коробки отдаёт моно — MixMonitor по умолчанию миксует оба направления в один файл. Но Asterisk умеет писать каналы раздельно, нужно только указать флаги
r()иt():r()— входящий поток (клиент),t()— исходящий (оператор). Получаем два отдельных WAV.Дальше post-process скриптом склеиваем в стерео через sox:
На выходе: левый канал = клиент, правый = оператор. Диаризация бесплатно, pyannote не нужен