Применение LLM + RAG для диалоговых систем в службе поддержки

в 11:53, , рубрики: AI, llm, rag, robovoice, ИИ, техподдержка

Автоматизация клиентской поддержки с помощью больших языковых моделей — перспективное направление, но без доработки они не всегда способны дать точные и релевантные ответы. Меня зовут Михаил Крюков, технический директор платформы Robovoice (SL Soft), и в этой статье я расскажу, как усиливать LLM с помощью RAG.

Используя реальный кейс, я расскажу о выборе LLM (сравнивали GigaChat MAX, GPT-4o, LLaMA 3.1 70B, YandexGPT 4 и Gemma 2 9b) и RAG (RagFlow, Dify и LangChain Custom + Vector database). Разберу ключевые сложности при интеграции — подготовку датасетов, настройку RAG, борьбу с «галлюцинациями» моделей, затрону вопросы экономики проекта и способов удешевления стоимости диалога. Статья будет полезна разработчикам и бизнесу, планирующим автоматизировать первую линию поддержки с помощью ИИ. Инфраструктура и железо в материале не освещены.

Применение LLM + RAG для диалоговых систем в службе поддержки - 1

Почему LLM нужно усиливать RAGом

При построении технической поддержки мы должны руководствоваться следующими критериями:

  • качество сервиса (quality service),

  • стоимость (cost),

  • скорость обработки запросов (SLA).

Использование LLM позволяет не просто выдавать ответы на предопределенные вопросы, но и поддерживать диалог, учитывая ход беседы и контекст. Эти параметры могут обеспечить нам выполнение трех вышеуказанных критериев. LLM — это не просто «умный автогенератор текста», ключевое преимущество — способность анализировать запросы в реальном времени, учитывая:

  • контекст диалога (например, если клиент упомянул проблему с доставкой в предыдущем сообщении, то модель не переспросит адрес);

  • стиль общения (формальный или разговорный тон, сленг, многоязычные запросы);

  • скрытые намерения (фраза «мой заказ еще не пришел» может требовать как проверки статуса, так и компенсации за задержку).

Важно понимать, что даже самая продвинутая LLM не способна знать все тонкости корпоративной информации, так как обучалась на общедоступных данных. Для точных ответов, специфичных для конкретной компании (внутренние регламенты, база знаний продукта, история заказов), используется архитектура RAG (Retrieval‑Augmented Generation). Она объединяет генеративные возможности нейросетей с поиском по структурированным данным.

Пример. Сотрудник филиала обращается в поддержку и получает различные варианты ответов:

Ситуация

Без LLM

LLM без RAG

С LLM + RAG

«В филиале на Тверской, 10 сломался принтер Model X200. Что мне делать?»

Бот предложит выбрать пункт меню («Статус заявки», «Новая заявка»), но не поймет запрос целиком, если пользователь отклоняется от шаблона.

Будет опрашивать пошагово сотрудника.

Понимает контекст из одной фразы.

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

Постарается помочь, переведя на оператора.

Понимает контекст из одной фразы.

Модель извлекает номер филиала, модель техники.

Через RAG находит в базе знаний информацию по инструкции этого устройства.

Предлагает инструкцию по починке.

Если ситуация не меняется, то формирует заявку на выезд мастера.

Очевидный эффект для бизнеса из этого примера:

  • связка LLM + RAG сокращает время обработки запросов на 50–70%, а главное — позволяет масштабировать поддержку для бизнесов любого размера;

  • снижается нагрузка на операторов — до 70% типовых вопросов решает бот без перевода на оператора;

  • минимизируется число ошибок за счет прямого доступа к актуальной базе знаний.

Но за кадром остаются ключевые вызовы:

  1. Как выбрать модель под задачи компании и избежать «галлюцинаций» ИИ.

  2. Как интегрировать систему с legacy‑сервисами?

  3. Как создавать уникальные датасеты для дообучения моделей.

Далее я опишу наш подход на примере компании, автоматизировавшей техническую поддержку с помощью платформы Robovoice. Компания масштабная и имеет большое количество филиалов по всей стране (30К+). Обращение в техподдержку может идти по разным каналам: чат, телефон, почта.

Технические характеристики решения

Разработка диалоговой системы на базе LLM и RAG требует четкого соответствия ряду технических критериев, которые определяют ее эффективность в реальных условиях. Рассмотрим ключевые параметры, которые легли в основу нашего решения для компании с распределенной сетью филиалов.

1. Производительность

  • Скорость ответа:

    • голосовые запросы ответ генерируется за ≤1 секунды, чтобы исключить паузы в диалоге;

    • текстовые чаты задержка не превышает 2 секунд даже при обработке сложных запросов.

  • Пропускная способность — система обрабатывает до 500 одновременных запросов без деградации производительности.

2. Поддержка языков и локализация

  • Мультиязычность — базовая поддержка русского и английского языков с возможностью расширения.

  • Локализация ответов — учет региональных особенностей (например, форматы дат, названия филиалов).

3. Работа с контекстом

  • Глубина контекста — модель сохраняет историю диалога в пределах 10 последних реплик (до 8K токенов).
    Пример: если пользователь уточняет детали предыдущего запроса («Какой статус у заявки, о которой я спрашивал вчера?»), система извлекает контекст из истории сессии.

  • Динамическое обновление контекста — при изменении данных в базе знаний (например, обновление инструкции по ремонту) система автоматически актуализирует ответы.

4. Точность и надежность

  • Извлечение сущностей модель идентифицирует ключевые параметры запроса:

    • номера заявок (шаблоны: «№XXXX», «заявка 1234»);

    • модели техники («HP EliteBook 840», «Xerox VersaLink B405»);

    • адреса филиалов («Ленинский проспект, 15», «Филиал № 5»).

  • Классификация намерений — точность определения категории запроса (ремонт, консультация, статус заявки) — 95%.

  • Подавление «галлюцинаций» — RAG‑слой ограничивает ответы данными из базы знаний, а rule‑based фильтры проверяют корректность формата (например, валидация номера заявки через API CRM).

5. Безопасность и развертывание

  • Локальное размещение — возможность деплоя LLM и RAG‑системы на собственных серверах заказчика.

  • Доступ к данным интеграция с внутренними системами через Secure API (OAuth 2.0, TLS 1.3):

  • базы знаний (Confluence, SharePoint),

  • CRM (1С, Bitrix24),

  • системы тикетов (Jira, Zendesk).

  • и т. д.

6. Масштабируемость

  • Горизонтальное масштабирование — добавление новых инстансов LLM и RAG‑сервисов при росте нагрузки.

  • Гибкость настроек — возможность кастомизации под специфику бизнеса: добавление новых типов сущностей, подключение дополнительных источников данных.

Общая архитектура 

Следующий шагом необходимо определиться с архитектурой решения. Диалоговая система на базе LLM и RAG — это сложный многоуровневый конвейер, где каждый компонент решает конкретную задачу. В основе системы лежит гибридная архитектура, объединяющая инструменты оркестрации данных, диалоговый движок и интерфейсы для многоканального взаимодействия. Рассмотрим ключевые компоненты и их взаимодействие.

Архитектура решения в нотации C4

Архитектура решения в нотации C4

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

Группа

Решаемые задачи

Интерфейсные каналы

 

• Telegram‑бот / корпоративный мессенджер.

• Веб‑виджет, встроенный в интранет‑портал компании.

• Телефонный номер.

• Автоматический парсинг вложений из почты (например, скриншотов ошибок).

ETL

Ежедневная синхронизация данных из источников заказчика (1С, Confluence, Jira) с векторным хранилищем RAG.

RAG

Векторное хранилище.

Контекстуализация: перед поиском запрос обогащается метаданными (например, филиал: «Ленинский, 15»).

Гибридный поиск: комбинация семантической схожести и ключевых слов.

Диалоговый движок Robovoice

 

State Machine: управляет сценариями (например, переход от сбора данных к созданию заявки).

Роутинг запросов:

• простые вопросы (статус заявки) → rule‑based модуль;

• сложные (анализ ошибки) → LLM + RAG.

Все каналы коммуникации уже имеют интеграцию к диалоговой платформе Robovoice, который унифицирует входные данные (текст, аудио, PDF) в единый формат. Мы не будем останавливаться на подробном рассказе особенностях интеграции, так как это может потребовать отдельной статьи по каждой интеграции.

На рисунке ниже представлен пользовательский сценарий. Основной UseCase можно представить в виде диаграммы последовательности:

Диаграмма последовательности сценария работы Help Desk

Диаграмма последовательности сценария работы Help Desk

Представленный на диаграмме поток обработки запроса можно описать следующим образом:

  1. Сотрудник отправляет голосовое сообщение в Telegram: «Принтер в филиале на Садовой, 7 не печатает с 10 утра».

  2. ETL ежечасно обновляет векторные индексы, включая новые мануалы по принтерам.

  3. Диалоговый движок извлекает сущности (адрес, тип техники) и отправляет RAG‑запрос.

  4. RAG находит в векторной базе раздел «Устранение ошибок печати Xerox VersaLink», LLM генерирует ответ на основе этой статьи.

  5. Ответ проверяется через rule‑фильтр («Есть ли в тексте ссылки на внутренние ресурсы?») и отправляется пользователю.

Когда определись с архитектурой решения и пользовательским сценарием, можно идти далее.

Выбор ETL

В качестве ETL мы выбрали Dagster. Я понимаю, что многие читатели сейчас удивятся, почему Dagster, а не популярный и уже устоявшийся ETL‑tools Airflow. Мы потратили достаточно много времени, сравнивая данные инструменты (если тема интересна — сообщите об этом в комментариях, я могу написать отдельную развернутую статью). Краткое резюме наших поисков в таблице ниже:

Dagster

Airflow

Custom ETL

Скорость разработки: настройка ETL для нового источника данных (например, Jira) занимает 2–3 часа вместо 1–2 дней в Airflow.

Отладка: встроенный Dagster UI показывает не только статус задач, но и качество данных (например, «85% PDF‑файлов не распознаны → проблема с кодировкой»).

Гибкость: возможность запускать конвейеры реактивно (например, при загрузке нового мануала) в дополнение к расписанию.

Отказ от сложных DAG‑ов в пользу декларативных конвейеров. Dagster предоставляет встроенную визуализацию данных, контроль качества (asset checks) и гибкую оркестрацию.

Готовые интеграции с PostgreSQL, S3, API. Например, конвейер для векторизации PDF‑мануалов пишется за 50 строк кода

Выбор LLM

Дальнейший шаг по построению решения технической поддержки — выбор LLM. И, казалось бы, это может быть самая тривиальная задача, но для диалоговой платформы она оказалась достаточно сложной.

Конечно, можно сравнивать LLM по общеизвестным требованиям. Например, можно взять аналитику от самих вендоров. Выбор LLM огромен — на hugging face около 200 000 моделей для генерации текстового инференца. Существуют различные рейтинги https://llmarena.ru/, https://lmarena.ai/?leaderboard

В нашем случае мы решали конкретную задачу, и под специфику требований нельзя было однозначно выбрать LLM.

В таблице ниже приведены наши измерения на количественных результатов замеров нескольких сотен промптов. Внимание: данные замеры были под нашу специфику и не могут выступать как эталонный MMLU.

Модель

Задержка (сек)

Контекстное окно / Понимание контекста (1–5)

Классификация (точность)

Извлечение сущностей (F1-score)

Размещение

GigaChat MAX

1.2

8K / 4

92%

89%

Облако (SberCloud)

GPT-4o

2

128K / 5

96%

94%

Облако (OpenAI)

LLaMA 3.1 70B (Groq)

0.8

8K / 4+

85%

82%

Облако (Groq)

YandexGPT 4

1,5–2

4K / 3+

83%

76%

Облако (Yandex Cloud)

Gemma 2 (9B)

3

8K / 4+

89%

86%

Локально / Приватное облако

Лидерами по скорости оказались GigaChat MAX и LLaMA 3.1 70B (Groq). С GigaChat нам пришлось решать через техподдержку вопрос ускорения. При первоначальном использовании GigaChat показал более высокие задержки.

Вначале теста мы использовали Gigachat с моделью Pro, но он не удовлетворял нашим требованиям. По мере того, как длился тест, появилась GigaChat модель MAX, которая уже полностью корректно отвечала на вопросы. GigaChat Pro нами в таблице не учитывался и в целом показался непригодным для наших задач. GPT-4o удивил тем, что на большом промпте + контекст (~4–5 тыс токенов) он начинает тормозить и скорость ответа может достигать 4 сек. Для чат‑бота такой вариант может устроить, но для голоса он не подойдет.

В таблице ниже приведены качественные требования к LLM.

Требование

Проблема

Метрика

Выбор

Понимание контекста

LLM часто забывает детали из начала диалога (например, номер заявки).

Способность корректно ссылаться на ранее упомянутые сущности через 10 реплик.

GPT-4o (128K токенов) — сохраняет контекст даже в длинных тикетах.

GigaChat MAX — адаптирован для диалогов, понимает референсы («как в прошлый раз»).

Классификация запросов

Определить тип запроса (ремонт, консультация, статус) для маршрутизации.

>1000 промптов с размытыми формулировками:
«Мой ноутбук не включается, а завтра дедлайн» → категория «Ремонт».

GPT-4o (96%), но GigaChat (92%) дешевле в эксплуатации.

Извлечение сущностей

Извлекаем: Номера заявок, модели техники, адреса филиалов.

Пример:
Запрос: «Нужен ремонт принтера Xerox B205 в филиале № 15»
Сущности: { «тип»: «принтер», «модель»: «Xerox B205», «филиал»: 15 }.

GPT-4o, GigaChat, Groq показывают близкие результаты (89–94%).

YandexGPT путает номера филиалов при распознавании речи.

Размещение провайдера

Безопасность данных, законодательство (ФЗ-152), latency.

Облако провайдера (GigaChat, OpenAI): проще интеграция, но данные у третьей стороны.

Groq: Низкая задержка, но данные уходят за рубеж.

Привожу здесь таблицу в усеченном виде — вообще мы разбивали характеристики на более подробные группы и детализировали их.

Также отмечу, что данный тест уже устарел (мы его делали во второй половине 2024 года), поскольку вышли более совершенные модели: OpenAI 4o1, DeepSeek и др. Но требования к LLM не устареют. Модели совершенствуются и качество их все лучше и лучше.

Какой здесь вывод? Нет универсальной LLM. Ключ к успеху — комбинация моделей под конкретные задачи.

Рекомендуемые критерии выбора модели:

  • для голосовых ботов: GigaChat MAX (задержка ≤1 сек, поддержка русского сленга, определений и др.);

  • для анализа документов: GPT-4o (высокая точность, но дороже);

  • Бюджетные сценарии: LLaMA 3.1 на Groq (дешево, но требует англоязычной донастройки).

Совет: не гонитесь за «топовыми» моделями. Протестируйте 3–4 варианта на своих данных — разница в качестве может быть незначительной, а стоимость эксплуатации — в разы ниже.

Fine tuning LLM

Многие проблемы LLM могут решаться их дообучением через fine tuning. Мы протестировали дообучение на моделях Qwen 2.5 (1B, 1.5B), LLaMA 3.2 (3B) и T5, используя датасет из 5–15K диалогов службы поддержки. К сожалению, результаты себя не оправдали: для того, чтобы эти модели вели диалог качественно, требовался больший корпус данных. Наши исследования по дообучению «маленьких» LLM достойны отдельной статьи (если у вас есть интерес к данной теме — просигнализируйте в комментариях).

Модель

Точность ответов

Задержка (сек)

Потребление VRAM

Qwen 2.5 1.5B

41%

0.3

4 GB

LLaMA 3.2 3B

58%

0.7

8 GB

T5-base

37%

0.2

3 GB

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

  1. Низкая когнитивная способность. Модели с ≤3B параметров не могли удерживать контекст длиннее 3–4 реплик.
    Пример: После вопроса «Как восстановить доступ к аккаунту?» и уточнения «Тот, что привязан к example@domain.com», модель забывала email и просила указать его повторно.

  2. Галлюцинации на ровном месте. Даже после дообучения модели генерировали несуществующие инструкции («Для сброса пароля нажмите Ctrl+Alt+Del на маршрутизаторе»).

  3. Проблемы с русским языком. Ошибки в падежах, игнорирование профессиональной лексики («ЖКУ» → «жидкостный кислородный ускоритель»).

При этом модели, дообученные с большим количеством параметров (Llama-3.1–8B, Qwen2.5–7B‑Instruct), отвечали уже более уверенно, но главный критерий — скорость работы на локальном развертывании для телефонии — был неудовлетворительным. Для телефонии и чатов с высоким RPS (запросов в секунду) дообученные 7B‑модели давали задержки в 5–10 секунд на инференц при больших промптах + контекст ( 2–3 тыс токенов).

По мере выхода более совершенных open source моделей этот способ улучшения может быть избыточным.

Выбор RAG

Сейчас уже существуют готовые open source решения RAG. Мы на первом этапе решили сравнить по ключевым параметрам их с разработкой под продукт. Выбор между готовыми платформами и собственной разработкой зависит от задач, бюджета и экспертизы.

Для того, чтобы создать базу знаний на основе RAG, необходимо получить текстовую информацию для дальнейшей векторизации. Текст может быть получен из таблиц, текстовой файла, csv, скриншотов, docx, pptx и т. д. В извлечении текста из файлов заключается основная сложность — каким образом извлечь текст из файлов и разбить на чанки?

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

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

Параметр / Решение

RagFlow

Dify

LangChain (Custom) + Vector database

Количество звезд GitHub

30.4K+ (активно развивается)

60.4K+ (лидер по популярности)

99.1K+ (экосистема, не только RAG)

Баги и стабильность

Среднее

Низкое (быстро фиксят)

Зависит от реализации

Текст

Да

Да

Да (через сторонние парсеры)

Таблицы в тексте

Да, ограничено

Да, ограничено

Да (любые форматы через Pandas)

Извлечение заголовков из таблиц

Да, ограничено

Да, ограничено

Да

OCR

Да встроенный OCR)

Нет (требуется внешний API)

Да (через интеграцию с EasyOCR/Tesseract или другой продукт)

Интеграция с LLM

OpenAI‑совместимые API, локальные модели

OpenAI‑совместимые AP, LLAMA, 20+ провайдеров

Любые модели

Сложность настройки

Средняя

Низкая

Высокая

Задержки

Высокие

Высокие

Низкие

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

Название

Плюсы

Минусы

Для кого

RagFlow

Встроенный OCR для работы со скриншотами и сканами.

Поддержка таблиц и иерархических данных.

Упрощенный вариант создания чанков.

Ограниченная документация на русском.

Требует доработки под специфические форматы (например, PDF с графиками).

Команды с базовыми навыками Python, которым нужен OCR «из коробки».

Dify

Low‑code интерфейс: RAG можно настроить за день.

Готовые шаблоны под службу поддержки.

Нет OCR — нельзя парсить скриншоты без интеграции с внешними сервисами.

Слабая работа с таблицами.

Упрощенный вариант создания чанков.

Специалисты, тестирующие RAG в пилоте.

LangChain + Vector database

Свобода выбора компонентов (векторные БД, парсеры, LLM).

Возможность создать сложные пайплайны (например, цепочки «извлечь → проверить → переформатировать»).

Возможность самостоятельно написать гибкой разбиение фрагментов.

Требует экспертизы в NLP и DevOps.

Нет готового UI — все с нуля.

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

Как мы видим, готовые решения вроде Dify и RagFlow — отличный способ начать погружаться в RAG или для небольших задач внутри команд. Но для сложных кейсов (например, анализ технической документации с графиками) кастомный RAG на LangChain даст больше точности. Кроме того, производительность готовых open source решений остается под вопросом.

Подсчет токенов и стоимость диалога

Еще одной задачей было удешевление диалога. Поддержка не должна быть дорогой. Использование больших языковых моделей (LLM) в промышленных масштабах требует четкого понимания их экономики. Токены — система расчета в мире ИИ, и их неэффективное использование может увеличить стоимость системы поддержки в разы. У каждого провайдера свои принципы расчета токенов.

Что такое токены и как их считают?

Токен — фрагмент текста, который модель обрабатывает как единицу. Для английского языка 1 токен ≈ 4 символа, для русского — 3–5 (из‑за сложной морфологии).

Пример:
Фраза «Сбросить пароль для аккаунта example@domain.com» разбивается на токены:
['▁Сбросить', '▁пароль', '▁для', '▁аккаунта', '▁example', '@', 'domain', '.', 'com'] → 9 токенов.

Что учитывается:

  • Входные данные (промпт + контекст RAG).

  • Выходные данные (сгенерированный ответ).

  • Служебные токены (разделители, инструкции).

Ниже приведена сравнительная таблица цен. Цены указаны для 1 млн токенов и приведены к одной единицы (рубли):

Модель

Входные токены (₽/1 млн)

Выходные токены (₽/1 млн)

GigaChat MAX

1 950

1 950

GPT-4o

250

1 000

LLaMA 3.1 70B

59

79

YandexGPT 4 Pro

1200

1200

Ниже в таблице приведен расчет стоимости одного диалога (до 3000 токенов или 5–7 реплик с оператором) для популярных моделей в рублях:

1 диалог = 2000 входных токенов (история, контекст, промпт) + 1000 выходных токенов (ответ бота).

Модель

Входные токены (₽)

Выходные токены (₽)

Итого за диалог

GigaChat MAX

3, 90

1,95

5,85

GPT-4o

0,50

1,00

1,50

LLaMA 3.1 70B

0,12

0,08

0,20

YandexGPT 4 Pro

2,40

1,20

3,60

Если использовать модели как есть, то наиболее дорогая модель — Gigachat MAX, самая дешевая — LLaMA 3.1 70B. Но, как мы узнали из предыдущего обзора, модели различаются качеством работы и скоростью. Таким образом каждая модель может выбираться под конкретную задачу. При этом для оптимизации стоимости мы предлагаем стратегии затрат, которые заключаются в следующем:

  1. Кеширование частых ответов

Как работает: ответы на популярные вопросы («Как сбросить пароль?») сохраняются и выдаются без обращения к LLM. Эффект: снижение нагрузки на модель на 25–40%.

  1. Оптимизация промптов

Плохо

Хорошо

Ты — оператор поддержки. Ответь на вопрос: «Как создать заявку на ремонт принтера?».

Учти, что филиал находится на Ленинском проспекте, 15. Ответ должен быть вежливым. → 45 токенов.

[Роль]Оператор[Филиал]Ленинский 15[Запрос]Создать заявку на ремонт принтера → 15 токенов (экономия 67%).

  1. Гибридный подход

  • Мультиагентный диалог. Используйте под разные задачи разные LLM. Например, для ведения диалога может подойти GigaChat. Для классификации и извлечения — LLaMA 3.1 70B.

  • Простая логика — используем Rule‑based: извлечение номера заявки, статуса дешевле обрабатывать через регулярные выражения.

  • Сложные запросы — используем LLM: анализ нестандартных проблем, требующих контекста.

  1. Учитываем скрытые расходы, возникающие в процессе эксплуатации:

  • Контекстное окно: использование 128K токенов в GPT-4o увеличивает стоимость входа в 16 раз по сравнению с 8K.

  • Ошибки RAG: если система извлекает нерелевантные данные, LLM тратит токены на «прогрев» контекста.

  • Повторные генерации: при проверке ответов через цепочку промптов («Переформулируй короче») затраты растут.

Грамотная настройка LLM + RAG, оптимизация промптов и гибридный подход снизят расходы в 2–3 раза. Возможность гибкой оптимизации мы уже внедрили к себе в платформу Robovoice на уровне продукта.

Подитог по выбору решений

По результатам проведенной работы нам удалось выработать набор критериев, когда основные параметры поддержки (cтоимость, качества, сервис) будут на высоком уровне при внедрении LLM + RAG. Все эти критерии и наработки были заложены на уровне архитектуры продукта.

Внедрение LLM и RAG‑систем для автоматизации поддержки — сложная многослойная задача даже для опытных команд. Эти задачи требуют:

  1. Экспертизы в AI.

  2. Времени на исследования.

  3. Ощутимого бюджета на исследования и инфраструктуру.

Для малого и среднего бизнеса, а также крупных компаний вне ИТ‑сектора (розничные сети, банки, производство) такие ресурсы часто недоступны.

Применение LLM в службе поддержки с помощью Robovoice

Мы с командойRobovoice уже прошли этот путь и решили описанные выше проблемы, поэтому предоставляем готовую экосистему для автоматизации поддержки с использованием LLM и RAG.

Встроенный диалоговый движок:

Мультиагентная‑LLM

RAG без кода

Low‑Code редактор

Поддержка голосовых и текстовых каналов (Telegram, сайт, телефония) из коробки.

Гибкие сценарии: комбинация rule‑based логики и LLM.

Подключение GigaChat, OpenAI, YandexGPT и других моделей через единый интерфейс.

Автоматический выбор LLM под тип запроса (например, Groq для голоса, GPT-4o для анализа документов).

Загрузка баз знаний через веб‑интерфейс (PDF, Excel, Confluence).

Встроенные инструменты для чанкинга и векторизации

Визуальное создание диалоговых сценариев с перетаскиванием блоков.

Готовые шаблоны под типовые кейсы (обработка заявок, консультации).

Robovoice (https://robo‑voice.ru/) — это Low‑/No‑Code платформа для создания голосовых и чат‑ботов на базе искусственного интеллекта, которая упрощает процесс автоматизации клиентской поддержки. В основе платформы лежат современные технологии, включая обработку естественного языка (NLP), машинное обучение (ML), большие языковые модели (LLM), а также RAG.

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

Пользователи платформы могут комбинировать два типа блоков при разработке блок‑схемы работы бота.

  1. Rule‑based блоки — традиционные модули с фиксированной логикой, которые подходят для обработки простых запросов. Например, бот может озвучивать заранее заданную реплику на определённом этапе разговора или отвечать на конкретную реакцию клиента в строгом соответствии с установленными правилами.

  2. GPT‑блоки — интеллектуальные модули, которые обеспечивают более естественное взаимодействие с клиентами. Эти блоки позволяют ботам решать более сложные задачи, обращаться к базе знаний компании, чтобы находить нужную информацию или анализировать историю диалога.

Сочетание rule‑based и ИИ‑блоков дает возможность создавать гибкие и функциональные решения. При этом ресурсы LLM используются рационально — интеллектуальные модули подключаются только там, где их применение действительно необходимо.

Для настройки RAG‑подхода в Robovoice уже предусмотрены все базовые инструменты, включая возможность интеграции с внешними базами данных. Такой подход упрощает внедрение технологий ИИ, делая их доступными даже для компаний без серьезной технической экспертизы и ресурсов на разработку.

Вся настройка сценария c GPT‑ботом происходит через Low‑Code дизайнер. Аналитик может настроить gpt‑блок, добавив его на полотно диалога. Один блок — один агент:

Применение LLM + RAG для диалоговых систем в службе поддержки - 4

Внутри блока аналитик (специалист по настройке диалоговой платформы) прописывает нужный промпт для ведения диалога внутри агента:

Применение LLM + RAG для диалоговых систем в службе поддержки - 5

Далее специалист настраивает провайдера, выбирая из списка доступных: Gigachat, Yandex, Groq, OpenAI. Также корректируются температура для более корректной работы LLM и максимальное количество токенов:

Применение LLM + RAG для диалоговых систем в службе поддержки - 6

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

Применение LLM + RAG для диалоговых систем в службе поддержки - 7

Платформа Robovoice предоставляет встроенную систему учета токенов, которая:

  1. Агрегирует данные от разных провайдеров (GigaChat, OpenAI, Groq) в единый отчет.

Применение LLM + RAG для диалоговых систем в службе поддержки - 8
  1. Детализирует затраты по проектам/каналам:

  • телефония: 45% бюджета.

  • чат‑боты: 30%.

  • email: 25%.

Применение LLM + RAG для диалоговых систем в службе поддержки - 9
  1. Предоставляет детальную трассирову токенов.

Применение LLM + RAG для диалоговых систем в службе поддержки - 10

Результаты проекта

Внедрение RAG + LLM в Robovoice принесло экономический эффект, подтвержденный данными реального пилотирования. Для оценки мы использовали эталонный датасет из 300 000 обращений службы поддержки заказчика. После фильтрации шума (дубликаты, нерелевантные запросы) и классификации на 12 категорий, система показала следующие результаты:

  • скорость обработки запросов сократилась с 10+ минут до 8–15 секунд;

  • 100% автоматизация для шаблонных задач (ремонт, замена оборудования);

  • для сложных заявок (например, кастомизация услуги) бот сократил время заполнения формы с 10 до 2–3 минут.

  • 90% кейсов решаются без перевода на оператора (против 20% в старой системе).


RAG + LLM — это мощный инструмент для автоматизации клиентской поддержки, который может дать большие преимущества для бизнеса. Хотя он еще не идеален, его потенциал для роста и развития открывает новые возможности для компаний.

Даже частичная автоматизация (30–40% запросов) сократит нагрузку на операторов и повысит лояльность клиентов. Главное — не пытайтесь охватить все сразу. Начните с простых сценариев, а потом масштабируйте.

Автор: mmikeles

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js