Что делать, когда ИИ уверенно врёт клиенту

MAATRIX

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

Шаг 1: подтвердите факт, а не пересказ

Первая ошибка, которую совершают в панике — начинают действовать на основе того, как клиент описал проблему в жалобе, а не на основе того, что реально было сказано в диалоге. Клиент пишет «ваш бот сказал, что доставка бесплатна при любой сумме» — но что бот сказал на самом деле? Может, он действительно так и написал прямым текстом. А может, он написал «бесплатная доставка от определённой суммы», а клиент это домыслил или не дочитал. Разница критична: в первом случае это галлюцинация системы, во втором — недопонимание, и реагировать нужно по-разному.

Первое, что нужно сделать — поднять реальный лог диалога:

# если у вас логи в базе — быстрый запрос по conversation_id или user_id
SELECT role, content, created_at
FROM chat_messages
WHERE conversation_id = '...'
ORDER BY created_at ASC;

# если логи в файлах на сервере ассистента
grep -A 5 "conversation_id: abc123" /var/log/ai-assistant/chats.log

Прочитайте диалог целиком, а не только спорную реплику — контекст важен. Возможно, клиент задал вопрос нечётко, и ответ ассистента был логичным продолжением его же формулировки, просто ассистент не переспросил и не сузил область неопределённости. Возможно, дело не в самом факте, а в тоне уверенности — ассистент дал категоричный ответ там, где стоило сказать «уточните у менеджера». Зафиксируйте точную цитату неверного утверждения — она понадобится и для ответа клиенту, и для дальнейшего разбора причины.

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

Шаг 2: свяжитесь с клиентом первым, до того как он спросит снова

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

Структура сообщения клиенту простая и без оправданий:

1. Прямое признание: «Мы проверили диалог — ассистент дал вам неверную информацию по [конкретный вопрос]».
2. Правильный ответ: сразу, без «свяжитесь с менеджером для уточнения» — если правильный ответ уже известен, дайте его в этом же сообщении.
3. Что произошло без технического жаргона: «Наш ИИ-ассистент неверно ответил на ваш вопрос про [тема]» — этого достаточно, не нужно объяснять клиенту про RAG и chunking.
4. Что вы делаете дальше: одна фраза о том, что случай зафиксирован и такое не повторится (без обещаний, которые не сможете выполнить — не «мы всё исправили», а «мы разбираемся и вносим исправление»).

Пример:

> Добрый день! Мы проверили ваш диалог с ассистентом от 3 сентября и подтвердили: ответ про бесплатную доставку от 2000 ₽ был ошибочным — правило действует от 5000 ₽. Приносим извинения за путаницу. Если вы оформили заказ, рассчитывая на бесплатную доставку от 2000 ₽, мы компенсируем разницу для этого заказа. Мы уже внесли исправление в базу знаний ассистента.

Не смягчайте формулировку до «возможно, ассистент был неточен» — если факт ошибки подтверждён на шаге 1, скажите прямо. Полупризнание читается хуже полного: клиент чувствует, что от него что-то скрывают, и это подрывает доверие сильнее исходной ошибки. Ошибиться и признать это быстро — нормально; уклонение от признания — вот что реально портит репутацию.

Шаг 3: оцените реальный ущерб именно для этого клиента

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

Задайте себе три вопроса по этому конкретному случаю:

• Клиент совершил необратимое действие на основе неверного ответа? (оплатил, отменил другую бронь, потратил время на поездку)
• Есть ли у ущерба денежное выражение? (переплата, штраф за отмену в другом месте, упущенная скидка)
• Есть ли риск, что клиент публично расскажет об этом до вашего ответа? (сообщение уже висит в отзывах, в чате поддержки другой компании, в соцсетях)

Таблица типовых сценариев и адекватной реакции:

Держите этот разбор в письменном виде (тикет, внутренняя заметка) — не только для истории с этим клиентом, но и как материал для шага 4.

Шаг 4: добавьте этот случай в регрессионные тесты

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

Прямо сейчас, пока инцидент свежий, зафиксируйте конкретный вопрос клиента и неверный ответ как тестовый кейс:

# regression_tests/incident_2026-09-03_free_shipping.yaml
- id: incident_2026-09-03_free_shipping
  query: "При какой сумме заказа доставка бесплатная?"
  expected_facts:
    - "Бесплатная доставка от 5000 рублей"
  forbidden_facts:
    - "2000 рублей"
  context: "Инцидент 03.09.2026 — ассистент назвал неверный порог"

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

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

Шаг 5: найдите корневую причину — она определяет техническое исправление

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

Причина A: проблема поиска. Система не нашла релевантный фрагмент документа, хотя правильный ответ там есть. Модель либо честно сказала «не знаю» (тогда жалобы бы не было), либо, не найдя нужный кусок, начала домысливать на основе похожего, но не того фрагмента. Проверяется просто: возьмите вопрос клиента, прогоните через retrieval-слой отдельно от генерации и посмотрите, какие чанки реально были найдены.

# псевдокод проверки retrieval отдельно от генерации
results = vector_db.search(query="при какой сумме бесплатная доставка", top_k=5)
for r in results:
    print(r.score, r.chunk_text[:200])

Если среди top-5 нужного фрагмента вообще нет — это проблема поиска: либо чанкинг режет документ неудачно (условие доставки оказалось разорвано между двумя чанками), либо эмбеддинг-модель плохо улавливает семантику именно таких формулировок. Если у вас уже был похожий инцидент с чанкингом, полезно свериться с разбором в статье RAG выдавал чушь: нашли проблему в чанкинге — там пример именно такого случая с разбором, как чанк разорвал условие пополам.

Причина B: проблема обоснованности (grounding). Нужный фрагмент был найден и попал в контекст модели, но модель всё равно «нафантазировала» поверх него — либо смешала цифру из одного фрагмента с условием из другого, либо просто выдала правдоподобное число, которого в контексте не было вовсе. Проверяется сверкой: смотрите, что было в retrieved-контексте на момент генерации (это надо логировать отдельно от финального ответа), и сравниваете дословно с тем, что модель сказала. Если в контексте было «от 5000 ₽», а ответ — «от 2000 ₽», это чистая проблема генерации, и тут может помочь более строгий промпт («отвечай только на основе предоставленного контекста, если данных нет — скажи прямо»), понижение temperature, либо более сильная модель для этапа генерации ответа.

Причина C: отсутствующие или устаревшие данные. Самая обидная причина — условие доставки в базе знаний реально было «от 2000 ₽» три месяца назад, компания его изменила, а документ в базе для RAG не обновили. Тогда ни поиск, ни модель не виноваты — они честно нашли и обоснованно процитировали устаревшую информацию. Лечится не промптом, а процессом обновления базы знаний: кто и как часто её актуализирует, есть ли автоматическая сверка с системой, где хранится «источник правды» (CRM, прайс-лист, документация).

Чтобы не гадать между этими тремя причинами на глаз, стоит один раз настроить процесс оценки, который явно разделяет качество поиска и качество генерации — подробно об этом в статье как оценить качество RAG-ответов без ручной проверки: там показано, как считать recall поиска отдельно от grounding-метрики ответа, чтобы не чинить не то.

Шаг 6: подготовьте процесс заранее, а не изобретайте его в кризис

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

Минимальный набор, который стоит иметь готовым до первого реального инцидента:

• Кто первый узнаёт. Чёткий маршрут: жалоба на ответ ИИ → кто отвечает в течение скольки минут (для активных диалогов — минуты, не часы).
• Доступ к логам без задержки. Человек, который реагирует на инцидент, должен уметь сам поднять диалог из базы, не дожидаясь, пока освободится разработчик. Если сейчас логи доступны только через SSH и ручной grep по файлам на сервере — это стоит исправить заранее, а не в момент, когда клиент уже ждёт ответа.
• Шаблон сообщения клиенту — не готовый текст под копирку, а структура (признание → правильный факт → компенсация при наличии ущерба → что исправлено), которую можно быстро заполнить конкретикой.
• Порог эскалации. Заранее определите, при какой сумме ущерба или при каком уровне резонанса подключается руководитель, а не только линейный саппорт.
• Обязательный шаг «добавить в регрессионные тесты» как часть чек-листа закрытия инцидента, а не как факультативное «сделаем как-нибудь потом».

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

Если вы разворачиваете ИИ-ассистента на собственном сервере, у вас есть преимущество — прямой доступ к логам диалогов и к базе знаний без посредников, и это ускоряет и подтверждение факта на шаге 1, и корневой анализ на шаге 5. Убедитесь, что логирование включено с самого начала и хранится достаточно долго (минимум 90 дней), чтобы к моменту жалобы клиента диалог ещё был доступен для разбора.

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