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

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

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

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

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

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

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

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

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

Вот почему галлюцинации особенно опасны в бизнес-контексте:

• Уверенность: Модель не различает «я точно знаю» и «я предполагаю» — она всегда отвечает одинаково уверенно
• Убедительность: Галлюцинации грамматически корректны и логично встроены в контекст, их сложно отличить от правды
• Специфичность: Модель может выдумать конкретные цифры, даты, имена — то, что выглядит как факт
• Контекстуальность: Чем более специфичный вопрос, тем выше шанс галлюцинации — модель «додумывает» то, чего не знает

Важно понимать: галлюцинации — это не признак плохой модели. Даже самые продвинутые системы (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: структурированные ответы легче контролировать и валидировать
• Мониторинг: постоянное отслеживание качества и быстрая реакция на проблемы

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

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