Анти-галлюцинации LLM: как заставить бота отвечать только по фактам

В прошлом году один казахстанский банк запустил AI-бота для консультаций по кредитам. Бот работал отлично – быстро отвечал, вежливо общался, клиенты были довольны. А потом случилось вот что.

Клиент спросил: «Какая ставка по ипотеке для молодой семьи?» Бот уверенно ответил: «Ставка составляет 5% годовых по государственной программе "Баспана Хит"». Проблема в том, что на тот момент ставка была уже 7%, а условия программы изменились полгода назад. Клиент пришёл в отделение, сослался на бота, и менеджеру пришлось объяснять, что «бот ошибся». Представляете реакцию клиента?

Это называется галлюцинацией – когда AI уверенно выдаёт неверную информацию. И это главная причина, почему многие компании боятся внедрять AI-ботов в критически важные процессы. Не потому что технология плохая, а потому что без правильной настройки бот может навредить больше, чем помочь.

Хорошая новость: галлюцинации можно контролировать. Не устранить полностью – это пока невозможно – но свести к минимуму и сделать так, чтобы бот честно признавался, когда не знает ответа. В этой статье разберём, как это сделать на практике.

«Когда мы внедрили принцип "не уверен – не отвечай", количество жалоб на неверную информацию упало в 8 раз. Да, бот стал чаще говорить "уточните у менеджера", но клиенты это оценили. Честность важнее всезнайства.»

Почему AI-боты «выдумывают» – и это нормально

Прежде чем бороться с проблемой, нужно понять её природу. Галлюцинации – это не баг, а особенность того, как работают большие языковые модели (LLM).

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

Представьте, что вы спросили такого собеседника: «Какой телефон у директора компании X?» Он вспомнит тысячи примеров, где номера телефонов упоминались рядом с названиями компаний, и выдаст что-то похожее на правду. Но это будет именно «похожее», а не реальный номер.

А теперь представьте, какие последствия это может иметь для бизнеса. Во-первых, модель не различает «я точно знаю» и «я предполагаю» – она отвечает одинаково уверенно в обоих случаях. Причём галлюцинации грамматически безупречны и логически встроены в контекст – вы не отличите их от правды без проверки.

Хуже того: модель может выдумать конкретные цифры, даты, имена – всё, что выглядит как факт. «Ставка по ипотеке – 5,2%» звучит убедительнее, чем «примерно пять процентов», верно? Только вот первое может быть полной выдумкой. И чем более специфичный вопрос задаёт клиент, тем выше шанс, что модель начнёт «додумывать» то, чего не знает.

И самое важное – это не признак плохой модели. Даже GPT-4, Claude и Gemini галлюцинируют. Просто с разной частотой. Разница в том, насколько хорошо модель «осознаёт» границы своих знаний. Но полностью избавиться от галлюцинаций на уровне модели пока никому не удалось.

Cite or Decline: главный принцип надёжного бота

Cite or Decline – это простая, но мощная концепция: бот либо отвечает со ссылкой на источник, либо честно говорит, что не знает. Никаких «я думаю», «возможно», «скорее всего». Или факт с доказательством, или признание незнания.

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

Как реализовать Cite or Decline технически

Есть несколько уровней реализации, от простого к сложному:

Важный момент: даже базовый уровень даёт ощутимый результат. Простая инструкция «если не уверен – не отвечай» уже отсекает большинство выдумок. Но для критически важных процессов (финансы, медицина, юридические вопросы) нужны все три уровня.

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

Cite or Decline – это философия. Пороги уверенности – это её техническая реализация. Идея в том, чтобы измерить, насколько бот «уверен» в своём ответе, и действовать по-разному в зависимости от этого показателя.

Откуда берётся уверенность? Есть несколько источников:

1. Релевантность найденных документов

Когда RAG-система ищет информацию в базе знаний, она получает не только текст, но и score – число, показывающее, насколько найденный фрагмент похож на вопрос. Если score высокий (например, 0.85 из 1.0) – вероятно, нашли то, что нужно. Если низкий (0.3) – это «притянуто за уши».

Практическое правило: если лучший найденный фрагмент имеет score ниже порога (обычно 0.5-0.7, зависит от модели эмбеддингов), бот должен либо попросить уточнить вопрос, либо переключить на оператора.

2. Количество подтверждающих источников

Если на один вопрос нашлось 5 релевантных фрагментов из разных документов, и все они говорят одно и то же – уверенность высокая. Если нашёлся только один фрагмент с пограничной релевантностью – лучше перестраховаться.

3. Внутренняя уверенность модели

Некоторые LLM умеют оценивать свою уверенность. Можно попросить модель ответить в формате: {"answer": "...", "confidence": "high/medium/low", "sources": [...]}. Это не идеальный метод (модель может быть уверена в неправильном ответе), но в сочетании с другими сигналами работает.

Валидация данных: двойная проверка критичной информации

Даже с Cite or Decline и порогами уверенности остаётся риск: модель может неправильно интерпретировать найденную информацию или «смешать» данные из разных источников. Для критичных данных нужен ещё один слой защиты – валидация.

Валидация – это проверка того, что ответ бота соответствует реальным данным из вашей системы. Называем это «источник истины». Это особенно важно, когда речь идёт о критичных вещах.

Например, цены и тарифы – их нужно проверять по актуальному прайс-листу или напрямую через API. Наличие товаров? Сверяйте со складской системой в реальном времени. Статусы заказов – только из CRM или ERP, никаких предположений. А уж условия договоров – тут вообще шутки плохи, только юридически актуальные документы.

Как реализовать валидацию

Есть два подхода, и лучше использовать оба:

1. Валидация на входе (pre-generation)

Перед тем как модель сгенерирует ответ, мы обогащаем контекст актуальными данными из систем. Например, клиент спрашивает про цену – мы сначала запрашиваем цену из 1С, и только потом передаём модели для формулирования ответа.

2. Валидация на выходе (post-generation)

После того как модель сформировала ответ, мы извлекаем из него ключевые данные (цены, даты, названия) и проверяем их по источникам. Если нашли расхождение – либо исправляем, либо не показываем ответ.

Второй подход сложнее в реализации, но надёжнее. Он ловит случаи, когда модель «творчески интерпретировала» данные.

Structured Outputs: структурированные ответы вместо свободного текста

Structured Outputs – это техника, при которой мы заставляем модель отвечать не свободным текстом, а в строго определённом формате (обычно JSON). Это даёт нам несколько преимуществ для борьбы с галлюцинациями.

Во-первых, структура ограничивает «творчество» модели. Когда нужно заполнить конкретные поля с конкретными типами данных, модели сложнее придумать что-то несуществующее.

Во-вторых, структурированные данные легче валидировать. Если модель должна вернуть {"price": 720000, "currency": "KZT"}, мы можем автоматически проверить, что цена – число, валюта – одна из допустимых, и значение в разумных пределах.

В-третьих, это заставляет модель явно указывать источники. Мы можем потребовать поле "sources" и проверить, что там не пусто.

Пример схемы для ответа бота

Как внедрить анти-галлюцинации: пошаговый план

Теория – это хорошо, но давайте перейдём к практике. Вот пошаговый план внедрения всех описанных техник.

Шаг 1: Аудит текущих галлюцинаций

Прежде чем что-то исправлять, нужно понять масштаб проблемы. Возьмите 100 последних диалогов бота и честно проверьте: сколько ответов содержат фактические ошибки? Какие типы ошибок встречаются чаще всего – цены, условия, несуществующие продукты? На какие конкретно вопросы бот постоянно ошибается? И есть ли какая-то закономерность – может, определённые темы или формулировки провоцируют галлюцинации?

Этот аудит даст вам baseline – точку отсчёта, от которой вы будете отталкиваться и измерять прогресс после внедрения изменений.

Шаг 2: Обновите промпт

Самый быстрый и дешёвый способ снизить галлюцинации – переписать системный промпт. Добавьте туда явные, недвусмысленные инструкции. Например: «Отвечай ТОЛЬКО на основе предоставленной информации». Или: «Если не нашёл ответ – честно скажи об этом». И обязательно: «Никогда не придумывай цены, даты, имена». Плюс требуйте, чтобы для каждого факта бот указывал источник.

Шаг 3: Настройте пороги в RAG

Если вы используете RAG-архитектуру (а для бизнес-бота это must-have), настройте пороги релевантности:

• Минимальный score для включения документа в контекст
• Максимальное количество документов в контексте
• Логика «ничего не нашли» → переключение на оператора

Шаг 4: Внедрите Structured Outputs

Переведите бота на структурированные ответы. Это потребует изменений в коде, но даст вам контроль над каждым элементом ответа.

Шаг 5: Добавьте постобработку

Настройте слой валидации после генерации ответа:

• Проверка, что цитаты реально есть в источниках
• Сверка цен с актуальным API
• Валидация форматов (даты, телефоны, суммы)

Шаг 6: Настройте мониторинг

Без мониторинга вы не узнаете, работают ли ваши улучшения. Отслеживайте:

• % ответов с низкой уверенностью
• % переключений на оператора из-за «не нашёл информацию»
• Жалобы на неверную информацию
• Результаты регулярного аудита качества

Искусство признать незнание: как бот должен отказывать

Парадокс: чем лучше бот умеет говорить «я не знаю», тем больше ему доверяют. Но важно, как именно он это делает. Сравните два варианта:

Хороший отказ содержит три элемента:

• Честность: бот признаёт, что не знает, а не уходит от вопроса
• Альтернатива: предлагает конкретный следующий шаг
• Эмпатия: показывает, что понимает важность вопроса для клиента

Для разных ситуаций нужны разные шаблоны отказа:

Особенности для казахстанского бизнеса

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

Многоязычность

Боты в Казахстане часто работают на русском и казахском. При этом база знаний может быть на одном языке, а вопрос – на другом. Это увеличивает риск галлюцинаций:

• Модель может неправильно перевести термины
• Поиск по базе может не найти релевантные документы из-за языка
• Одни и те же понятия могут называться по-разному на разных языках

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

Локальная специфика

Казахстанские реалии (Kaspi, БИН/ИИН, тенге, местные банки и компании) хуже представлены в обучающих данных западных моделей. Это означает, что модель с большей вероятностью будет галлюцинировать на локально-специфичных вопросах.

Решение: расширенная база знаний с казахстанской спецификой, более строгие пороги уверенности для локальных вопросов, интеграция с Kaspi и другими локальными системами для валидации.

Регуляторные требования

В финансовом и медицинском секторах неверная информация от бота может иметь юридические последствия. Если бот неправильно сообщил условия кредита или страховки – это потенциальный риск.

Решение: для регулируемых отраслей используйте максимально строгие анти-галлюцинационные настройки, логируйте все ответы, и всегда добавляйте дисклеймер о необходимости проверки у специалиста.

Как измерять успех: метрики для анти-галлюцинаций

Что не измеряешь – тем не управляешь. Вот метрики, которые стоит отслеживать:

Важно: «Graceful Decline Rate» должен быть в балансе. Слишком низкий (менее 5%) – бот, скорее всего, отвечает на вопросы, которые не должен. Слишком высокий (более 30%) – бот бесполезен, потому что на всё говорит «не знаю».

Итог: надёжный бот – это возможно

Галлюцинации – это не приговор для AI-ботов. Да, полностью избавиться от них нельзя, но можно свести к минимуму и контролировать последствия. Главные принципы:

• Cite or Decline: бот либо отвечает с источником, либо честно признаёт незнание
• Пороги уверенности: не все ответы одинаково надёжны, и система должна это понимать
• Валидация данных: критичная информация проверяется по источникам истины
• Structured Outputs: структурированные ответы легче контролировать и валидировать
• Мониторинг: постоянное отслеживание качества и быстрая реакция на проблемы

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

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

Читайте также

• RAG в реальном бизнесе: архитектура, источники данных, метрики
• Fine-tuning vs RAG vs промпт: как выбрать подход для CRM-бота
• Prompt injection: как ломают AI-ботов и как защититься
• Наблюдаемость LLM-систем: логи, трассировка, метрики качества
• Анти-галлюцинации: как заставить LLM отвечать только по фактам