ИИ-чатбот, который не врёт

Главная причина, по которой бизнес боится ставить ИИ-бота к клиентам, — он уверенно выдумывает факты: цены, сроки, условия, которых нет. Разберём, почему так происходит и как сделать бота, который отвечает только по вашим документам, ссылается на источник и честно говорит «не знаю», когда ответа нет.

Почему обычный ИИ выдумывает

Языковая модель (LLM) не хранит ваши документы и не «знает» вашу компанию. Она предсказывает правдоподобный текст. Если спросить про ваш тариф или политику возврата, модель сгенерирует похожий на правду ответ — но это догадка, а не факт. Для болтовни это нормально, для поддержки клиентов — катастрофа: бот назовёт несуществующую цену, и отвечать перед клиентом будете вы.

Решение: RAG — сначала найти, потом ответить

RAG (retrieval-augmented generation) переворачивает логику. Бот не отвечает «из головы». На каждый вопрос он сначала находит релевантные фрагменты вашей базы знаний, а затем модель формулирует ответ строго по найденному. Три опоры, без которых это не работает:

• Поиск по вашим документам. База — это ваши регламенты, FAQ, каталог, инструкции. Поменяли документ — поменялся ответ. Ничего не «зашито» в модель.
• Ответ только по найденному + ссылка на источник. Модель получает фрагменты как контекст с жёсткой инструкцией: отвечай только по нему. К ответу прикладывается, из какого раздела он взят — это можно проверить за секунду.
• Честный «не знаю». Если релевантного фрагмента нет — бот так и говорит, а не фантазирует. Это и есть главный антигаллюцинационный механизм.

Честный «не знаю» — почему это фича, а не баг

Большинство демо ИИ-ботов прячут отказы: бот всегда что-то отвечает. Это и опасно. Правильный бот при отсутствии ответа в базе не вызывает модель вообще — он сразу отвечает, что информации нет, и предлагает оставить заявку. Выдумать ему просто неоткуда. Для бизнеса это снимает главный риск: бот не подставит вас неверным фактом.

«Какой у вас адрес офиса в Париже?» → «В базе знаний нет ответа на этот вопрос. Бот отвечает только по загруженным документам и не выдумывает.»

→ Хотите такого бота по вашим документам? Спросите живого бота на странице кейса →

Лексический поиск против семантического

Простейший поиск — лексический (по словам, алгоритм BM25, то, что внутри Elasticsearch). Он быстрый, детерминированный и не требует модели — на нём удобно показывать качество выдачи. Его потолок: не находит ответ, если вопрос сформулирован другими словами, чем документ. Семантический поиск (эмбеддинги + векторное хранилище pgvector/Qdrant) понимает смысл и находит ответ при иной формулировке. В реальном проекте обычно используют связку обоих.

Какая модель отвечает

Сам ответ формулирует LLM — и она не привязана намертво, меняется конфигом:

• Облачные — Claude, GPT, Gemini: максимальное качество ответа, подключение по API.
• Российские — GigaChat, YandexGPT: оплата в РФ, данные в российском контуре.
• Self-hosted — Llama, Qwen, DeepSeek на вашем сервере (vLLM/Ollama): данные не покидают вас, без платы за токены.

Выбор — это компромисс «качество ↔ стоимость ↔ приватность». Часто начинают на облаке и при необходимости переезжают на self-host.

Частые грабли

• Слишком крупные фрагменты. Если резать базу на огромные куски, модель «тонет» в контексте. Нужна аккуратная нарезка (chunking) по смысловым блокам.
• Нет защиты от «не по теме». Без порога релевантности бот цепляется за одно общее слово и отвечает мимо. Нужны гейты: минимальная релевантность и покрытие вопроса базой.
• Нет аналитики пустых ответов. Вопросы, на которые бот не нашёл ответ, — это готовый план, чем пополнять базу знаний. Без этого бот не улучшается.

Проверьте на живом примере

Мы собрали открытый движок такого бота и поставили его на странице кейса: там можно задать вопрос боту прямо в браузере и увидеть ответ со ссылкой на источник, а на вопрос вне базы — честный отказ. Код открыт, запускается одной командой.