Как заставить RAG-бота не выдумывать цены: пять технических решений
Интеграция нейросетей в корпоративные чат-боты требует строгой проверки на фактоискривление. Автор статьи описывает пять инженерных приемов — от принудительного вывода ответа к серверной валидации цифр — которые обеспечивают точность ответов бота при работе с каталогами цен.
# Как сделать RAG-чат для сайта, который не выдумывает цены
С ростом популярности искусственного интеллекта компании стремятся внедрить чат-боты на свои ресурсы. Однако стандартные модели часто склонны к «галлюцинациям», выдумывая цены, сроки или условия, которых нет в реальности. Для бизнеса это критично: неверная информация приводит к потере доверия клиентов.
В данной статье рассматриваются пять ключевых решений, основанных на практическом опыте разработки чат-бота для B2B-платформы в финтехе, которые гарантируют, что нейросеть будет работать исключительно с проверенными данными, а не с её собственными внутренними знаниями.
Жесткая схема ответа и обязательные поля
Одной из наиболее распространенных ошибок является разделение текста ответа и технической разметки. Если нейросеть просто вставляет тег, например [SHOW_PRICING], в поток текста, фронтенд может интерпретировать это как часть обычного сообщения, особенно при ошибках в коде или сценарии.
Для решения этой проблемы необходимо сделать текстовое поле обязательным в схеме вызова инструмента (schema). Нейросеть должна быть вынуждена генерировать ответ словами независимо от того, вызывает ли она вспомогательную функцию или просто отвечает на вопрос. Это устраняет неустойчивость, когда бот иногда молча показывает карточку, а иногда пишет вводящий в заблуждение текст перед ней.
Централизация чисел и цифр
Нейросети обучены на огромных массивах текстов, включая неактуальные данные о ценах. Попытка доверять модели расчет скидок или тарифов чревата катастрофическими ошибками. Единственный надежный способ — исключить числа из текстового вывода модели.
Реализация выглядит следующим образом: 1. Вывод модели: Нейросеть выбирает только тип компонента (например, «карточка тарифов») и идентификаторы элементов каталога. 2. Серверная логика: Сервер получает запрос и выгружает реальные цены из базы данных или каталога по полученным идентификаторам. 3. Валидация: Любые попытки модели добавить числовые значения прямо в ответ жестко блокируются валидатором (например, с помощью Zod). Если в ответе от модели присутствуют лишние поля с ценами, они автоматически отбрасываются.
Таким образом, источником правды всегда остается база данных, а нейросеть выступает лишь в роли проводника, формирующего структуру взаимодействия.
Интеллектуальный сбор контекста
Качество ответа RAG-системы напрямую зависит от того, какой фрагмент базы данных попадает в промпт (запрос к модели). Перебор всей базы данных неэффективен, а поиск векторов иногда дает неточные результаты.
Эффективным подходом является предварительная очистка и обход сайта для сбора реальных противоречий до загрузки в систему. Если на сайте указано «скидка 90%» в одном месте, но «скидка 10%» в другом, эти противоречия должны быть разрешены заранее, либо нейросеть должна иметь четкую инструкцию игнорировать устаревшие данные.
Оптимальная практика показала, что для качественного ответа достаточно передать модели от 40 до 80 кусков наиболее релевантной информации. Попытка увеличить объем контекста без отбора часто приводит к ухудшению качества, так как модель начинает терять фокус и «затеряется» в лишнем тексте.
Очистка потока от технической разметки
При генерации ответов в режиме стрима (по мере появления символов) нейросеть может случайно «просочиться» в текст служебные данные. Это могут быть строки вызова инструментов, специфические токены или даже случайные фрагменты обучающих данных, которые не соответствуют формату ответа.
Решением является внедрение фильтра на уровне сервера, обрабатывающего поток данных перед отправкой клиенту. Этот фильтр в реальном времени отслеживает появление паттернов, характерных для вызова инструментов (например, специфических токенов или конструкций вызова функций), и блокирует вывод первых 48 символов потенциально опасного фрагмента, дождавшись завершения генерации ответа или подтвердив его валидность.
Тестирование на ложное согласие
Стандартные тесты часто не замечают тонких ошибок, когда модель соглашается с запросом, но с оговоркой, которую пользователь может пропустить в начале длинного ответа. Например, ответ «Да, можем сделать... но 3 метра не делаем» может быть воспринят как полное согласие.
Для обнаружения таких случаев требуется специализированная проверка на ложное согласие. В логике тестирования необходимо анализировать не только сам факт согласия, но и последующее отрицание или уточнение ограничений, содержащихся в том же сообщении. Использование регулярных выражений для корректного распознавания границ слов в русском языке также играет ключевую роль, чтобы тесты не давали ложных результатов из-за особенностей кодировки и обработки текста.
Заключение
Создание ответственного и точного чат-бота требует смещения акцента с возможности генерации на строгий контроль данных. Внедрение обязательных текстовых полей, серверной валидации цифр, тщательного отбора контекста, фильтрации потока и продвинутого тестирования позволяет превратить нейросеть из непредсказуемого источника информации в надежного сотрудника, который не выдумывает факты.