Бот, который не врет: как работает RAG‑ассистент в реальном бизнесе
Когда клиент пишет в поддержку: «У меня на Земской, 10 сломалась панель Model X50, что делать?» — он ждет не философских рассуждений, а четкой инструкции: кто приедет, когда и что делать до приезда сотрудника компании. Но именно в этот момент большинство умных ботов пасуют.
Почему просто LLM — недостаточно
Мы знаем описанную выше ситуацию не понаслышке. Платформа для создания ИИ‑ботов Robovoice изначально предлагала классических ботов с правилами: много ветвлений, аккуратно прописанные сценарии, нужные формулировки. Они справлялись. Пока не начались сложные запросы — с техникой, региональными отличиями, индивидуальными договорами и всеми теми вещами, которые не прописать в универсальном «если… то…». Тогда стало понятно: без искусственного интеллекта мы не масштабируемся.
Следующий шаг — интеграция LLM (большая языковая модель). Мы протестировали несколько моделей, подключили их к боту и быстро столкнулись с двумя проблемами. Первая — они не знали ничего о наших клиентах. Вторая — они не стеснялись выдумывать. GPT может блестяще объяснить устройство двигателя, но если попросить его рассказать, как у вашей компании оформляется гарантийный обмен, он начнет фантазировать.
Нужен был способ встроить реальные знания компании в мышление языковой модели. Не пересаживать всю логику на промпты. Не писать все руками. А соединить генерацию и поиск. Так мы пришли к архитектуре RAG — Retrieval‑Augmented Generation. Это не просто модный стек — это фундамент, который позволяет боту говорить не то, что «думает GPT», а то, что реально написано в базе знаний, SLA, внутреннем регламенте или карточке клиента.
Дальше — о том, как мы это реализовали. С учетом голоса, скорости, ошибок и настоящих пользователей.
Рассылка: как вести бизнес в России
Пять полезных писем пришлем сразу после подписки. В них — бизнес‑идеи, готовые промпты для нейросетей, советы, как выбрать налоговый режим и получать пассивный доход
Путь Robovoice от rule‑based к LLM+RAG
Изначально Robovoice создавался как low‑code‑платформа для построения голосовых и чат‑ботов на базе rule‑based‑логики. У нас был движок, поддерживающий сценарии с условиями, fallback‑ветками, логикой повторов, интеграцией с CRM, S3‑хранилищами, API. Это работало: заказчики строили в нем роботов для колл‑центров, служб доставки, медицинских центров.
Но любая rule‑based‑система рано или поздно упирается в потолок: сценариев становится слишком много, кейсов — еще больше, а жизнь клиентов отказывается укладываться в заранее прописанные реплики.
Когда стало понятно, что «все руками» больше не масштабируется, мы начали интегрировать LLM. Сначала — как помощь в генерации фраз. Потом — как отдельный обработчик входящих сообщений.
1/2А этот скрин — пример сценария для бота с LLM, реализованного Robovoice для одной из медицинских сетей 
2/2И еще один пример сценария с LLM, которая добавляет системе гибкости
Но мы сразу столкнулись с тем, что просто LLM — это красиво в демо, но не работает в проде.
Большие языковые модели (LLM — Large Language Models) вроде GPT — это мощные алгоритмы, которые умеют работать с человеческим языком: понимать, дополнять, пересказывать, генерировать. Они обучены на гигантских массивах текстов и способны вести диалог почти как человек. Но есть нюанс: они не знают ваших процессов, документов и клиентов. LLM отлично говорит, но не знает, что говорит — если ее не ограничить фактами. Отсюда и появляются «галлюцинации» — правдоподобные, но вымышленные ответы.
Нам нужен был контроль.
Нужна была возможность точно сказать: «Ответ строится не из воздуха, а на основе конкретного документа, в котором сказано, что инженер приедет через 48 часов». LLM не может помнить ваши внутренние процессы — ее нужно вооружить знанием.
Так мы пришли к архитектуре RAG.
Это архитектура, в которой генерация ответа разделена на два этапа. Сначала бот ищет релевантные документы в базе знаний (Retrieval), а уже потом формирует ответ на основе найденного (Generation). Такой подход позволяет использовать мощь языковой модели без риска «выдумывать». Ответ получается и точным, и гибким — особенно в диалогах.
Начали трансформировать Robovoice из rule‑based‑движка в систему с модульной архитектурой:
- модуль извлечения и векторизации базы знаний;
- ретривер релевантных документов по запросу;
- LLM‑контекстный генератор (с configurable prompt logic);
- слой валидации и фильтрации ответа;
- контекстный буфер и история диалога;
- возможность fallback к rule‑based‑сценарию (если RAG дает низкую уверенность);
- поддержка голосовых каналов: с таймингами на генерацию и автообрезку тишины.
Нам пришлось переизобрести многие внутренние модули — особенно пайплайн работы с голосом. Появилась динамическая адаптация ответа к синтезатору речи, ограничение глубины промта, постфильтрация ответов на токсичность и шум.
Мы не заменили правила искусственным интеллектом. Мы научили их работать вместе.
Архитектура RAG в системе
Когда мы внедряли RAG в платформе, перед нами стояла четкая задача: научить бота отвечать не общими словами, а по сути — и при этом не терять темпа разговора. Условно говоря, нам нужно было встроить в голову бота всю корпоративную документацию клиента, но так, чтобы он не захлебывался от этой информации и говорил по делу. Для этого понадобилось собрать несколько ключевых компонентов.
Во‑первых, мы научили ассистента «читать» клиентскую базу знаний — инструкции, регламенты, FAQ, внутренние справочники. Система разбивает эти документы на понятные фрагменты, хранит у себя в индексе и умеет быстро находить нужные по смыслу. Не по ключевому слову, а по сути вопроса. Если человек спрашивает про “порядок замены оборудования”, бот найдет фрагмент, где вообще не используется слово “замена”, но описан нужный процесс.
Во‑вторых, когда пользователь что‑то спрашивает, система не сразу отправляет вопрос в языковую модель. Сначала она ищет ответ — прямо как это делает человек, открывая внутренний портал и вводя запрос в поиске. Только делает это быстрее: за доли секунды подбирает фрагменты, которые действительно могут содержать нужную информацию.
После этого на сцену выходит LLM. Но теперь она работает не «из головы», а на основе фактов, которые мы ей только что подложили. То есть она не придумывает, а оформляет найденное в связный, понятный, разговорный ответ.
При этом Robovoice не слепо доверяет генерации. Если в ответе что‑то не так — например, неполный номер заявки или нарушение формата адреса — работает фильтрация. А если система вообще не уверена в ответе, она либо уточняет вопрос, либо возвращается к заранее прописанным сценариям, где все под контролем.
Последняя, но не менее важная часть — это обновление знаний. Все, что загружено в платформе, можно обновлять на лету. Клиент обновил инструкцию — и через пару минут бот уже отвечает по‑новому, без пересборки и перезапуска.
По сути, RAG стал для нас способом встроить знание в интеллект. Мы оставили за LLM силу понимания языка и гибкость, но убрали главное слабое звено — склонность выдумывать. И теперь бот действительно знает, что говорит, и может это доказать ссылкой на источник.
Особенности голосового применения RAG
С текстом работать проще. Пользователь может подождать пару секунд, перечитать ответ, скопировать ссылку. В голосе все иначе. Там пауза длиннее полутора секунд — уже тревожный звоночек. Модель может быть сколь угодно умной, но если она тормозит или отвечает с ошибками — это раздражает. Голос не про «понимание», голос — про ритм, темп, интонацию и точность.
Когда мы начали внедрять RAG в голосового ассистента, стало понятно: просто вставить языковую модель между вопросом и ответом недостаточно. Архитектура должна работать на миллисекундах.
Первое, с чем мы столкнулись, — задержка. Даже если LLM отвечает быстро, поиск по базе знаний — а он обязательная часть RAG — занимает время. Особенно если данных много и запрос сложный. Мы начали оптимизировать: ускорили индексацию, ввели кэширование популярных запросов, добавили быстрые fallback‑ответы, если система чувствует, что генерация затягивается.
Второй вызов — это длина ответа. В чате длинный текст — не проблема. В голосе он утомляет. Пользователь не слушает три абзаца инструкции, он ждет короткий, четкий ответ, желательно с действием:
- Пользователь: Вызовите техника.
- Robovoice: Мы отправили заявку. Придет во вторник.
Поэтому ассистент автоматически адаптирует длину ответа под формат канала. Мы научили систему сокращать формулировки, опускать лишнее, использовать естественные речевые шаблоны.
Третий момент — это живость речи. Просто зачитывать сгенерированный текст — недостаточно. Синтез речи должен звучать естественно, не роботизировано. Мы внедрили специальные фильтры и редакторы, которые обрабатывают текст перед синтезом: разбивают длинные фразы, расставляют паузы, подбирают синонимы, которые лучше звучат вслух. В некоторых сценариях мы даже переключаем синтезатор в зависимости от стиля речи пользователя — формальный/неформальный.
Наконец, голос требует особого внимания к ошибкам. В чате можно перечитать. В звонке — нет. Поэтому мы добавили «страховочные» уровни: если бот не уверен, он уточняет. Если повторный запрос снова не дает результата — возвращается к скрипту. Лучше немного переспрашивать, чем дать неправильный ответ с полной уверенностью в голосе.
Именно поэтому голосовой Robovoice с RAG внутри — это не просто генератор ответов. Это связка нескольких систем, работающих почти в реальном времени. И чтобы все это звучало как живой человек, нам пришлось научить бота не только думать, но и говорить.
Как это работает на практике: разбор запросов
Чтобы понять, как RAG встраивается в работу голосового ассистента, лучше всего просто посмотреть, как он отвечает на реальные вопросы. Ниже — два типичных диалога: один текстовый, другой — голосовой. В обоих случаях видно, как работает связка поиска и генерации, и как бот удерживает суть разговора.
Пример 1: Текстовый запрос от сотрудника. Пользователь: У меня не открывается форма заявки на замену оборудования. Robovoice: Проверьте, что вы авторизованы под корпоративным логином. Если все верно — форма открывается по ссылке: [ссылка].
Что произошло внутри: система поняла, что речь о типовой проблеме с внутренним порталом. По запросу был извлечен фрагмент из инструкции по работе с ИТ‑порталом, где описаны возможные причины недоступности формы. Бот сформулировал ответ с учетом контекста (авторизация) и вставил ссылку, найденную в документе. Вопрос не эскалировался, оператор не привлекался.
Пример 2: Голосовой запрос от регионального менеджера. Пользователь: Привет, у нас в Тюмени сломалась панель X50. Что делать? Robovoice (через 1,2 секунды): Я зафиксировал обращение. По регламенту ремонт занимает два рабочих дня. С вами свяжется инженер из филиала на улице Республики.
Что произошло внутри: система извлекла:
- модель устройства;
- регион;
- тип обращения.
RAG нашел в базе инструкцию по ремонту техники X50 и политику обработки инцидентов в конкретном филиале. Ответ построен на этих двух источниках. Сформированный ответ адаптирован для синтеза речи: укорочен, без лишних деталей, но с нужными элементами действия и географии.
Оба примера — типовые, но именно в таких мелочах кроется суть. Без доступа к актуальным данным LLM, скорее всего, выдала бы общую отговорку или выдумала ответ. Без RAG бот просто бы не знал, что техника X50 ремонтируется по другой схеме, а в Тюмени действует филиал с отдельным графиком.
Мы тестировали систему на десятках тысяч обращений. И видим: когда генерация работает на основе фактов, а не догадок, пользователи это чувствуют. Они начинают разговаривать с ботом иначе — увереннее, спокойнее. Потому что у них появляется ощущение: он в теме.
Результаты: что изменилось, в цифрах
Мы рассказали об архитектуре, сценариях, пайплайнах и голосе. Но в конце дня бизнесу важно другое: работает или нет. Вот как изменилась производительность и эффективность клиентской поддержки после внедрения Robovoice с RAG‑архитектурой.
Скорость обработки. До внедрения: среднее время ответа оператора — 8–10 минут, включая ручной разбор и эскалации. После внедрения: типовой запрос обрабатывается за 8–15 секунд — от распознавания до генерации и синтеза речи.
Это особенно важно в случае с голосом: задержка между вопросом и ответом сократилась до полутора секунд, что укладывается в комфортный диапазон для живого диалога.
Уровень автоматизации. До внедрения: автоматизировано не более 20% обращений, остальные передавались живому оператору. После внедрения:
- 100% типовых сценариев (ремонт, замена, уточнение заявки) закрываются ботом;
- до 90% всех обращений — без участия человека.
При этом система сама определяет, когда стоит подключить оператора: например, если пользователь говорит о конфликтной ситуации или задает нестандартный вопрос.
Снижение нагрузки на операторов. Количество обращений, обрабатываемых вручную, сократилось в 4–5 раз. Это позволило перераспределить ресурсы: меньше времени на FAQ, больше — на сложные кейсы и обратную связь.
Точность и устойчивость. В 94% случаев ответы, сгенерированные системой, были признаны корректными без доработки. Мы регулярно проводим ручную ревизию с участием клиентов, и система обучается на ошибках — обновляя базу знаний и корректируя приоритеты поиска.
Все эти цифры — результат реального пилота в логистической компании с десятками филиалов и распределенной ИТ‑поддержкой. Но, что особенно важно, такая архитектура масштабируется. Она не привязана к конкретной отрасли — она просто делает поддержку быстрее, умнее и надежнее.
Выводы и перспективы
Встраивание RAG в голосового ассистента — это не «еще один модный апдейт», а ответ на вполне конкретный вызов: как сделать бота не просто говорящим, а знающим. В Robovoice мы решили эту задачу — и увидели, что она масштабируется.
Архитектура, которую мы собрали, работает не только в техподдержке логистики. Она применима в банках, страховых, клиниках, ритейле — везде, где пользователь ждет конкретного ответа, а не имитации внимания. При этом решение остается гибким: его можно развернуть локально, подключить к существующей CRM, адаптировать под нужный канал.
Самое интересное начинается дальше. Мы видим, как на базе RAG можно строить не просто «ботов», а полноценные диалоговые интерфейсы к инфраструктуре компании. Где ассистент не только отвечает, но и инициирует действия: заводит заявку, проверяет статус, предлагает следующее действие. Где разговор становится интерфейсом к процессам.
Такое будущее уже не абстрактное. Оно начинается с простого: чтобы бот говорил не от себя, а на основе ваших знаний. А дальше — вопрос масштаба.
