Клиент пишет в чат в полночь с вопросом про возврат оплаты. ИИ отвечает уверенно и подробно: называет срок, которого нет в правилах, или ссылается на акцию, которой не было. Для бизнеса это не баг интерфейса, а репутационный риск: если искусственный интеллект отвечает на вопросы клиентов неточно, человек верит ответу и потом приходит с претензией к оператору или в отзывы.
Отличает надёжного бота от красноречивого вруна не модель сама по себе, а то, как вокруг неё выстроен контроль качества: откуда система берёт факты, как она проверяет собственный ответ и в какой момент передаёт разговор человеку.
База знаний, grounding и эскалация работают как три фильтра подряд. Без них даже сильная модель рано или поздно выдаст уверенный, но неверный ответ, и клиент не узнает, что ему соврали, пока не проверит сам.
Почему искусственный интеллект ошибается, когда отвечает на вопросы клиентов
Языковая модель не хранит факты о вашей компании, она предсказывает наиболее вероятное продолжение фразы. Если в вопросе клиента нет подсказки, откуда брать ответ, модель достраивает пробел тем, что звучит правдоподобно: конкретным сроком, цифрой скидки, названием тарифа. Для читателя это неотличимо от настоящего факта, пока он не проверит.
Ошибка усиливается в трёх типичных ситуациях:
- вопрос касается того, что изменилось позже обучения модели: новый тариф, обновлённые условия доставки, свежая акция;
- клиент спрашивает о чём-то, чего нет в документах компании, а модель вместо честного «не знаю» выдаёт правдоподобную догадку;
- промпт не обязывает модель ссылаться на источник, поэтому молчание выглядит для неё хуже, чем уверенный, но неподтверждённый ответ.
Причины этого механизма подробно разбирали в статье про ИИ-галлюцинации и способы борьбы с ними. Для бизнеса цена такой ошибки выше, чем кажется: клиент, которому соврали один раз, перестаёт доверять боту целиком и начинает дублировать каждый вопрос у живого оператора, а это убивает саму идею автоматизации поддержки.
Исправить это нельзя, просто выбрав «более умную» модель. Нужно дать ей то, на что опереться: базу знаний и механизм, который заставит её сверяться с документами, а не с догадкой.
База знаний: источник правды для ИИ
Grounding работает ровно так, как работает база знаний под ним. Если в ней дубли, устаревшие цены и противоречивые версии одного документа, модель честно процитирует одну из них, и это будет не её ошибка.
Рабочая база знаний для ИИ-поддержки отличается от обычного корпоративного wiki тремя вещами. Во-первых, записи атомарны: один блок текста отвечает на один вопрос, а не на десять сразу, как в большом регламенте. Во-вторых, у каждой записи есть дата обновления и статус: актуальна, устарела, требует проверки. В-третьих, источник один: если тариф описан в трёх местах и в одном из них забыли поправить цифру, рано или поздно именно её найдёт модель.
В базу стоит включить минимум:
- актуальные тарифы, цены и условия их действия;
- политику возврата, отмены и переноса заказа;
- пошаговые инструкции по частым операциям: оплата, доступ в личный кабинет, смена тарифа;
- ограничения продукта: что он не умеет и в каких случаях нужно уточнить у специалиста;
- готовые формулировки для деликатных ситуаций: жалоба, задержка, брак.
Обновлять базу нужно не раз в квартал, а в момент изменения: новая цена появляется в CRM вместе с новой записью в базе знаний, а не через неделю. Разрыв между этими двумя моментами и есть окно, где ИИ отвечает клиенту неправильно, искренне полагая, что прав. Если базой пользуются несколько команд, стоит сразу развести права на редактирование: тарифы правит коммерческий отдел, инструкции по продукту, техническая поддержка, а бот читает итоговую версию, а не черновики.
Grounding и RAG: как ответ привязывается к документам
Grounding, это правило, по которому модель отвечает только тем, что ей передали как подтверждённый контекст, а не тем, что помнит из обучения. Самый частый способ его реализовать, retrieval-augmented generation (RAG): перед ответом система ищет в базе знаний фрагменты, релевантные вопросу, и подставляет их в запрос к модели вместе с инструкцией отвечать только по ним.
Устройство такой схемы подробно показано в статье о том, что такое RAG простыми словами. Здесь важнее практическая часть: grounding работает не потому, что в промпт дописали фразу «отвечай точно», а потому, что у модели физически нет доступа ни к чему, кроме переданных фрагментов и чёткого правила на случай, если фрагментов не нашлось.
Это правило на случай пробела решает половину проблемы с галлюцинациями. В промпт закладывают явную инструкцию: если ответа нет в переданных фрагментах, модель должна сказать об этом прямо и предложить позвать специалиста, а не подбирать наиболее вероятное продолжение фразы. Без этой инструкции RAG снижает число ошибок, но не убирает их: модель всё равно может смешать найденный фрагмент с собственной догадкой, если решит, что контекста «почти достаточно».
Полезная деталь для доверия клиента: если ответ сопровождается ссылкой на документ или пунктом правил, из которых он собран, оператору на эскалации проще проверить диалог, а клиент видит, что ответ не выдуман на ходу.
Это отличается от обычного диалогового бота, который просто поддерживает разговор: такое устройство диалога без привязки к документам разбирали в статье про то, как устроен диалог с нейросетью. Для поддержки клиентов этого недостаточно: нужен не собеседник, а источник, который умеет сослаться на документ и промолчать там, где документа нет.
Как измерять точность ответов в продакшене
Точность ответа нельзя проверить один раз на этапе пилота и забыть: модель, база знаний и вопросы клиентов меняются каждую неделю. В продакшене точность измеряют через несколько метрик, которые считают по каждому диалогу.
- Faithfulness (достоверность): какая доля утверждений в ответе подтверждается найденными фрагментами базы знаний. Низкое значение означает, что модель домыслила факт, которого не было в контексте.
- Groundedness (привязка к контексту): проверяет каждое предложение ответа отдельно, а не весь ответ целиком. Это ловит случай, когда четыре предложения из пяти опираются на документ, а пятое придумано.
- Answer relevance (релевантность ответа): отвечает ли система на заданный вопрос, а не на похожий.
Эти три метрики вместе называют «триадой RAG». На практике их считают моделью-судьёй: отдельный проход сравнивает ответ с переданным контекстом и выставляет оценку. Если оценка ниже порога, ответ не уходит клиенту напрямую: система либо запрашивает документы заново, либо передаёт диалог оператору.
Помимо автоматической оценки полезна ручная выборка: команда поддержки раз в неделю читает срез реальных диалогов и помечает ответы, где модель слегка исказила факт, даже если формально сослалась на документ. Такие пограничные случаи автоматическая метрика улавливает хуже всего, а именно они подрывают доверие клиента быстрее грубых ошибок.
Эскалация на человека: три уровня доверия
Даже отличный grounding не гарантирует, что ИИ справится с любым обращением. Рабочая схема строится не на одном пороге «уверен, не уверен», а на нескольких уровнях с разной степенью контроля.
| Уровень доверия | Что делает ИИ | Роль человека |
|---|---|---|
| Высокая уверенность, ответ подтверждён базой знаний | Отвечает самостоятельно | Выборочно проверяет диалоги постфактум |
| Средняя уверенность, ответ вероятен, но не подтверждён полностью | Даёт предварительный ответ с пометкой «уточняю у специалиста» или предлагает подтверждение | Проверяет диалог до отправки клиенту или сразу после |
| Низкая уверенность либо тема из списка исключений | Передаёт диалог оператору с полной историей переписки | Ведёт разговор сам |
Список исключений важнее порога по уверенности: часть тем должна уходить к человеку независимо от того, насколько уверенно звучит ответ ИИ. Сюда относят споры по оплате и возврату денег, вопросы доступа к аккаунту и безопасности, юридические и договорные формулировки, явную просьбу клиента позвать человека и отмену подписки с явными признаками недовольства.
Отдельный сигнал, тон обращения: резкое, эмоциональное сообщение клиента должно поднимать диалог к оператору, даже если по смыслу вопрос простой. ИИ, уверенно отвечающий раздражённому клиенту шаблонной фразой, раздражает сильнее, чем честное «передаю коллеге, он ответит быстрее, чем я подберу слова».
Частые ошибки при настройке точных ответов
Большинство проблем с точностью появляется не из-за слабой модели, а из-за того, как вокруг неё выстроен процесс.
- Промпт не разрешает модели сказать «не знаю»: тогда любой пробел в базе знаний она закрывает догадкой.
- База знаний живёт в нескольких местах одновременно, в Notion, в PDF и в голове менеджера, и обновляется только в одном из них.
- Пороги эскалации настроили один раз на старте и больше не трогали, хотя вопросы клиентов и каталог за полгода изменились.
- Метрики точности смотрят только на этапе пилота, а после запуска в продакшен faithfulness на реальном потоке диалогов никто не считает.
- Эскалация устроена как один переключатель «ИИ или человек», а не как лестница с промежуточным уровнем проверки.
- Никто не проверял реакцию бота на провокационные вопросы: просьбы раскрыть системный промпт или дать совет вне компетенции, который клиент потом примет за официальную позицию компании.
- Диалоги, которые ушли к оператору, никто не читает: без этого непонятно, правильно ли сработала эскалация и чего не хватает в базе знаний.
Частые вопросы
Можно ли полностью убрать галлюцинации ИИ в ответах клиентам?
Нет. Grounding и RAG заметно снижают долю выдуманных фактов на вопросах, по которым есть документы, но не доводят её до нуля: модель всё равно может смешать найденный фрагмент с собственной догадкой. Рабочий подход, не убрать ошибку полностью, а поставить проверку faithfulness перед отправкой ответа клиенту: если оценка ниже порога, система переспрашивает базу знаний или передаёт диалог человеку вместо непроверенного черновика.
Какой уровень уверенности ИИ считается безопасным для автоответа без оператора?
Распространённая практика: автоматический ответ при уверенности выше 90%, проверка оператором в промежутке от 60 до 90% и прямая передача человеку ниже 60%. Это стартовая точка, а не универсальный стандарт: компании сдвигают пороги по факту разбора ошибок, потому что цена ошибки в описании тарифа и ошибки в вопросе безопасности аккаунта требует разной осторожности.
Какие темы ИИ должен передавать человеку независимо от уверенности в ответе?
Список исключений, которые не зависят от уверенности модели: споры по оплате и возврату денег, вопросы доступа к аккаунту и безопасности, юридические и договорные формулировки, явная просьба клиента позвать человека, отмена подписки и явные признаки недовольства, способные привести к уходу клиента. Эти правила задаются бизнесом заранее и перекрывают любой расчёт уверенности модели.
Чем база знаний для ИИ отличается от обычного FAQ на сайте?
FAQ на сайте пишут для человека, который сканирует страницу глазами и сам достраивает недостающий контекст. База знаний для ИИ состоит из атомарных фрагментов с метаданными: датой обновления, статусом актуальности, темой, чтобы система поиска находила нужный кусок и передавала его модели как единственный разрешённый источник ответа, без лишнего текста вокруг.
С чего начать
Если команда уже обсуждает внедрение ИИ в поддержку, но не знает, с какого шага начать, порядок такой:
- Соберите базу знаний в одном месте: выгрузите тарифы, инструкции и политику возврата, убрав дубли и устаревшие версии.
- Подключите grounding, чтобы модель отвечала только по найденным фрагментам и явно говорила «не знаю» там, где фрагментов нет.
- Задайте пороги уверенности и список тем, которые всегда уходят к оператору, независимо от того, насколько уверенно звучит ответ ИИ.
- Запустите пилот на части обращений, считайте faithfulness на реальных диалогах и расширяйте охват только после того, как метрика стабильна.
Если разбираться в retrieval, промптах и порогах эскалации самостоятельно не хочется, такие сценарии под ключ настраивает агентство Neurounit: создание ботов с базой знаний и контролем точности ответов.
