Почему голосовой AI-менеджер на 1С отвечает 6 секунд, а ChatGPT за 1

Пауза перед ответом не баг

Когда клиент впервые слышит голосового AI-менеджера по телефону, он удивляется паузе. ChatGPT отвечает мгновенно, а тут несколько секунд тишины перед ответом. Я ориентируюсь на паузу порядка шести секунд на первой реплике, и это не ошибка архитектуры. Это синхронные проверки в 1С перед тем, как голос произнесёт: «Да, на складе есть 320 метров такой-то трубы по такой-то цене, отгрузка с понедельника». Клиент получает правду из учётной системы, а не литературную обработку запроса.

Это запись про подход, а не про один проект. Я веду голосовые AI-менеджеры на B2B-входящих в производственно- торговых компаниях, где справочные данные живут в 1С. Стек, инженерные решения и порядок цифр привожу здесь полностью, без привязки к одному заказчику.

Зачем голос, если есть чат

B2B-входящий звонок это не запрос FAQ. Закупщик завода набирает номер, потому что у него отгрузка через сутки, и ему нужны не «информация о товаре», а четыре цифры. Остаток на складе, цена для его сегмента контрактов, срок отгрузки и сумма с НДС. По чату эти четыре цифры он будет получать минут восемь с переключениями между менеджером и 1С. По телефону это полторы минуты разговора. С AI-менеджером минута, в любой час суток, без человека на линии.

Голос даёт ещё один сигнал, которого нет в чате. По паузе слышно, что клиент переваривает цифру и считает в голове. По тону слышно раздражение, когда цена вышла выше ожидаемой, или торопливость, когда горит отгрузка. Эти сигналы LLM-маршрутизатор интерпретирует и выбирает следующий шаг. Например, предложить альтернативную позицию или зафиксировать заявку с примечанием для менеджера.

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

Архитектура. Пять узлов на пути голоса

Каждый звонок проходит пять синхронных узлов. Перечисляю их в порядке движения голоса от клиента к ответу AI.

1. Asterisk PBX + ARI externalMedia. Принимает звонок на SIP-транк, выделяет аудио-поток в WebRTC, отдаёт на STT-сервис через ARI WebSocket. Asterisk я собираю из исходников версии 22 LTS, обновляю по мере выхода точечных релизов. Беру именно LTS-ветку, чтобы у прода был долгий горизонт поддержки безопасности, а не Standard-релиз с коротким окном.
2. STT — faster-whisper Large-v3. Бьёт аудио на чанки по 1.5–2 секунды с VAD-перекрытием 200 мс, гоняет через выделенную под распознавание карту NVIDIA L4 на 24 ГБ. Модель Large-v3 с KV-cache на пару параллельных потоков сюда помещается с запасом. Распознавание русского без LM-довеса, на бизнес-лексике (артикулы, ГОСТы, города) после дообучения точность держится обычно выше 90% по WER.
3. LLM-маршрутизатор. Qwen 2.5 32B Instruct под квантизацией Q5_K_M на отдельной карте. Веса в Q5_K_M весят около 23 ГБ, поэтому 24 ГБ под LLM не беру. На одной карте с whisper это не уживётся, а в одиночку оставит ноль под KV-cache. Под маршрутизатор ставлю L40S на 48 ГБ (или арендую инференс в облаке РФ под пиковую нагрузку). Где бюджет на отдельную карту не тянет, опускаю модель до Qwen 2.5 14B либо до Q4_K_M на 20 ГБ. На прод в РФ я не беру Claude или GPT из-за санкций и риска отзыва API в любой момент. YandexGPT и GigaChat тоже пробую, выбор между ними и Qwen решаю замером на домене конкретного клиента, а не по бенчмаркам. Маршрутизатор разбирает запрос на интенты, тянет контекст через pgvector RAG (история диалога, база FAQ, правила обработки запросов), формирует план вызовов 1С.
4. FastAPI-шлюз в 1С. Endpoints с idempotency-key по каждому, ретраи с экспоненциальным backoff. Шлюз ходит в 1С 8.3 через HTTP-сервисы, проверяет остаток на складе, тянет цену по сегменту контрагента, считает срок отгрузки от логистики, проверяет кредитный лимит. Параллельные вызовы идут там, где это безопасно.
5. TTS — SaluteSpeech (Сбер) с резервом. Синтез речи держу на SaluteSpeech, резерв через Audiogram (MTS AI) на случай падения первого. Где заказчику важна полная автономия от облака, ставлю self-hosted open-source (например, OmniVoice от Xiaomi или Silero) на собственный GPU. Голос мужской, нейтральный, без излишней эмоции. Озвучка идёт стримом в Asterisk и одновременно в архив звонка.

За всеми пятью узлами стоит ClickHouse-телеметрия. На каждый вызов в каждой стрелке пишется отдельная запись со временем начала, временем ответа, статусом и payload-hash. Это позволяет в любой момент построить flame chart на конкретный звонок и увидеть, где именно ушли миллисекунды.

Где живёт латентность

Тайминги я снимаю с ClickHouse по каждому узлу. Привожу порядок величин на проектах такого масштаба. По первой реплике AI после длинного бизнес-запроса картина обычно такая.

На повторных репликах в том же звонке латентность падает примерно до трёх секунд. Контекст диалога уже в памяти LLM, RAG не ищет с нуля, часть данных по контрагенту 1С уже в кеше шлюза с коротким TTL.

Дальше я разбираю самый жирный узел. Это 1С.

Почему я не убираю 1С из цепочки

Самый частый вопрос на первом разговоре: «А давайте обучим LLM на остатках и не будем ходить в 1С каждый раз, будет быстрее». Технически возможно. На практике это путь к AI-менеджеру, который регулярно врёт клиенту цифрами.

Главная причина держать 1С в цепочке проста. Остатки меняются каждые 5–15 минут, а перестроить RAG на крупном номенклатурном справочнике быстро не выйдет. В окне «после обновления RAG, но до новой синхронизации» AI будет давать данные с задержкой до часа. Для оптовой торговли с дефицитными позициями это приговор. Нельзя назвать клиенту 320 метров остатка, если их час назад уже забрал другой контракт.

Дальше идёт цена сегмента контрагента. У большинства таких клиентов она настроена в 1С через сложное ценообразование с десятком типов скидок, привязкой к категории клиента, объёму заказа, календарю акций. Эту логику в LLM не вынесешь, она меняется через приказ коммерческого директора несколько раз в месяц.

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

Сколько секунд пауза терпима

Я опираюсь на исследования call-центров и на собственные замеры на пилотах. Картина такая. Пауза до восьми секунд воспринимается как «оператор уточняет в системе», это ожидаемое поведение, которое клиент терпит спокойно. От восьми до двенадцати секунд начинается дискомфорт, человек проверяет, не сорвался ли звонок. Свыше двенадцати секунд клиент бросает трубку или начинает говорить «алло, вы тут?».

Поэтому я завожу в LLM-маршрутизаторе wait-marker. Если ожидаемое время ответа больше четырёх секунд, AI произносит короткое «Минутку, проверяю по складу», и клиент получает сигнал, что система работает. Это сдвигает порог восприятия с восьми секунд к четырнадцати-шестнадцати. Внутри семи секунд хвоста P95 я укладываюсь свободно.

На пилоте я слушаю записи звонков ежедневно первый месяц. Типичный сценарий такой. Клиент с заметным акцентом, и AI его переспрашивает чаще нормы. Это решается не общим временем ответа, а отдельной итерацией дообучения STT на размеченных звонках из этого же контура.

Триггеры передачи на человека

AI-менеджер не закрывает все звонки. Обычно он держит 70–80%автономия типовых сценариев. Остальные 20–30% уходят на дежурного менеджера. Я держу четыре триггера передачи:

• Незнакомый интент. LLM-классификатор возвращает confidence ниже порога по намерению. Дежурный менеджер получает звонок с расшифровкой и контекстом.
• Двойное непонимание. AI два раза переспросил клиента по одному и тому же. Третий раз переспрашивать запрещено правилом. Передача с пометкой «клиент говорит нечётко» или «вопрос вне сценариев».
• Эмоциональный триггер. STT отдаёт акустический маркер (повышенный pitch, ускоренный темп речи). LLM подтверждает раздражение по лексике. Передача мгновенно, это пожар, а не звонок.
• Прямой запрос клиента. «Соедините с менеджером», «дайте человека», «не нужен мне ваш робот». Передача без вопросов.

Передача идёт не отбоем звонка, а warm transfer. AI сообщает клиенту, что соединяет с менеджером, в фоне посылает менеджеру push-уведомление с расшифровкой диалога и идентификатором клиента. Менеджер берёт трубку уже зная, кто звонит и о чём.

Это критично для воспринимаемого качества. Главный источник негатива на ранних A/B-тестах это cold transfer, когда клиент пересказывает менеджеру всё заново.

Экономика. Где на самом деле окупаемость

Честная арифметика начинается с признания, которое не любят интеграторы. На одной экономии ФОТ голосовой AI окупается годами, а не месяцами. Поэтому я не продаю такой проект под лозунгом «сократите операторов».

Посчитаем контур ФОТ прямо. Допустим, на входящем направлении было пять операторов первой линии, после выхода AI осталось два на сложные сценарии и дежурство. По факту замещение даёт 2–3FTEзамещение, не 3–5, как пишут в коммерческих предложениях. Дальше цифры порядком величин на проектах такого масштаба.

Если смотреть только на эту таблицу, окупаемость выходит 4–6летФОТ-контур. CAPEX порядка 3.6–4.8 млн против экономии порядка миллиона в год. Это годы, а не месяцы. Поэтому продавать такой проект экономией зарплат честно нельзя, и я этого не делаю.

Настоящая окупаемость живёт в выручке, а не в ФОТ. В таблице зарплат не видно главного, потерянных обращений. На B2B-входящих часто десятки процентов звонков уходят в пустоту в пиковые часы и в нерабочее время, и каждый такой звонок мог стать отгрузкой. Закупщик с горящим заказом уходит к тому, кто назвал остаток и цену первым, а круглосуточный приём без AI означает расширение штата. Когда я вношу в модель сохранённую выручку от этих эффектов, окупаемость на загруженных направлениях выходит в горизонт месяцев. Но эту часть я считаю по реальной воронке конкретного клиента, а не по шаблону.

Стоимость владения по моим проектам составляет порядка 80–150 тыс./мес для нагрузки 800–1500 звонков в неделю. Граница диапазона зависит от числа интеграций с 1С, от выбора TTS-движка и от того, держим ли мы LLM на собственном GPU или арендуем инференс в облаке.

Что я считаю метрикой качества

Метрик у меня четыре, и я смотрю их еженедельно на стендапе с владельцем:

1. Доля автономно закрытых звонков. Целевой коридор 70–80%. Ниже 65% модель деградирует. Выше 85% почти наверняка теряем сложные сделки на упрощении сценариев.
2. Точность распознавания интента. На размеченной выборке звонков каждую неделю. Целюсь в macro-F1 порядка 90%+ по классам интентов конкретного домена.
3. Среднее время первой реплики. Целюсь в медиану не выше пяти секунд и хвост P95 не выше семи. На пиковых часах смотрю отдельно.
4. Удовлетворённость после звонка. SMS с одним вопросом «оцените от 1 до 5». Целевой уровень держу близко к оценке живых операторов. Небольшой разрыв это плата за «робота на линии», и его я считаю допустимым, когда выручка от круглосуточного приёма перекрывает разницу.

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

Зачем читал

Если у вас B2B-направление с входящими звонками выше сотни в неделю и средний оператор отрабатывает типовые сценарии (проверка остатка, цена, срок отгрузки), голосовой AI имеет смысл считать всерьёз. Считать по выручке, а не по ФОТ. Если звонков заметно меньше сотни, почти никакой AI тут не окупится, и я скажу это прямо на первом разговоре.

Если думаете «нам бы чат, а не голос», посмотрите запись про шесть различий голоса и чата. Там я разбираю, в каком сегменте бизнеса какой канал реально окупается и где AI вообще не нужен.

На первом разговоре через форму контакта я задаю несколько вопросов по нагрузке и сегменту и за полчаса говорю, какой проект у вас имеет смысл. По договорённости подключим демо. Вы услышите AI-менеджера в работе, а после звонка я отдам расшифровку, чтобы вы посмотрели изнутри, как это устроено.