Чат-бот по базе знаний на RAG: как устроен и как избежать выдуманных ответов

Если нужно, чтобы чат-бот по базе знаний отвечал по вашим документам, а не придумывал несуществующие условия, почти наверняка понадобится RAG. Разберём, как он устроен изнутри — от нарезки документов до проверки качества — простым языком, но без упрощений, которые потом выходят боком.

Почему нельзя просто «скормить» документы модели

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

• Вставить все документы в запрос. Работает на паре страниц, но на сотнях документов запрос становится огромным, медленным и дорогим, а нужное в длинном тексте модель находит хуже.
• Дообучить модель. Дообучение хорошо меняет стиль и формат ответов, но плохо подходит для фактов: модель не скажет, откуда взяла ответ, а каждое изменение цены требует нового цикла обучения.
• RAG (Retrieval-Augmented Generation) — перед ответом найти в базе несколько подходящих фрагментов и передать модели только их, с указанием отвечать по ним. Факты обновляются вместе с документами, а у каждого ответа есть источник.

Справедливости ради: если вся база знаний — это пара страниц FAQ, которые редко меняются, RAG может оказаться избыточным. Такой текст проще целиком положить в инструкцию модели. RAG окупается, когда документов много, они обновляются, а пользователю важно видеть, откуда взят ответ.

Сам бот обычно — лишь часть ИИ-ассистента, у которого есть ещё интеграции, ограничения и передача оператору. Общую картину мы описали в статье про ИИ-ассистента для бизнеса, а здесь сосредоточимся на поиске и ответах.

Путь одного вопроса через RAG-систему

1. Пользователь задаёт вопрос. Если это продолжение диалога («а для юрлиц?»), система сначала переформулирует его в самостоятельный: «условия возврата для юридических лиц».
2. Вопрос превращается в эмбеддинг — числовой вектор, который отражает смысл текста.
3. В векторной базе ищутся фрагменты документов с близким смыслом — обычно несколько десятков кандидатов.
4. Реранкер пересортировывает кандидатов по точности соответствия, и дальше идут несколько лучших.
5. Модель получает инструкцию, вопрос и фрагменты с пометками источников и формулирует ответ.
6. Система проверяет, опирается ли ответ на источники, и показывает их пользователю.
7. Всё сохраняется в лог: вопрос, найденные фрагменты, ответ, оценка пользователя.

Качество ответа решается на шагах 3–4 раньше, чем на шаге 5: если нужный фрагмент не нашёлся, даже самая сильная модель ответит плохо.

Чанкинг: как нарезать документы

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

• Резать по смыслу, а не по числу символов. Граница чанка — заголовок раздела или абзац, а не середина предложения.
• Сохранять контекст. Фрагмент «срок — 14 дней» бесполезен без заголовка «Возврат техники». Мы добавляем в каждый чанк путь: документ, раздел, подраздел.
• Небольшое перекрытие. Соседние чанки частично повторяют друг друга, чтобы мысль на границе не потерялась.
• Метаданные. Дата документа, продукт, регион, уровень доступа — по ним потом фильтруют поиск.
• Отдельная обработка таблиц и сканов. Таблицу из PDF нужно превратить в текст, где понятно, к какой строке относится значение; сканы — сначала распознать.

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

Эмбеддинги, векторный поиск и реранкинг

Эмбеддинг-модель переводит текст в вектор так, что близкие по смыслу фразы оказываются рядом: «как вернуть товар» и «оформить возврат» найдутся друг через друга, хотя слова разные. Векторы хранят в отдельной базе или в расширении к привычной СУБД — например, pgvector для PostgreSQL.

У чисто смыслового поиска есть слабое место: артикулы, коды ошибок, номера договоров. Поэтому мы обычно делаем гибридный поиск — векторный плюс полнотекстовый — и объединяем результаты.

Реранкер — отдельная модель, которая смотрит на пару «вопрос — фрагмент» целиком и оценивает, отвечает ли фрагмент на вопрос. Он особенно полезен там, где документы похожи друг на друга. Если в базе есть закрытые разделы, фильтр по уровню доступа применяется до поиска, а не после ответа.

Ответ с источниками и честный отказ

Инструкция для модели — короткая и жёсткая: отвечать только по переданным фрагментам, указывать номер фрагмента для каждого утверждения, а если информации недостаточно — так и сказать и предложить связаться с сотрудником.

Одной инструкции мало, поэтому добавляем проверки в коде:

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

Ссылки на источники полезны и команде: по ним видно, откуда взялась ошибка — из неудачного поиска или из устаревшего документа.

Как держать базу знаний свежей

• Один источник правды. Документы живут в вики, CMS или общей папке, а бот подтягивает их оттуда, а не из копии, загруженной однажды.
• Автоматическая переиндексация. При изменении документа его старые чанки удаляются, новые индексируются. Иначе бот будет цитировать обе версии.
• Даты и версии. При конфликте предпочтение отдаётся свежему документу, устаревшие помечаются или удаляются.
• Ответственные. У каждого раздела есть владелец, который следит за актуальностью.
• Вопросы без ответа. Лог отказов — готовый список того, что нужно дописать в базу.

Проверка качества: набор контрольных вопросов

Без измерений любая настройка превращается в гадание. Перед запуском мы собираем набор контрольных вопросов: реальные формулировки клиентов или сотрудников, правильный ответ и документ, в котором он есть. В набор входят:

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

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

Выбор самой модели для такого бота — отдельная тема, мы разобрали её в статье о языковых моделях для бизнеса в России. А если бот нужен прямо в мессенджере, посмотрите, как встроить ассистента в Telegram.

Частые вопросы

Обсудим проект

Нужна похожая разработка?

Расскажите о задаче — уточним детали, предложим формат запуска и подготовим предварительную оценку. Это бесплатно.

Ваше имя Способ связиTelegramVKMAXТелефонПочта

Контакт

Отправить заявкуНаписать напрямую

Опубликовано 12 октября 2026 г. · Обновлено 12 октября 2026 г.