Галлюцинации нейросети: как проверить ответ до отправки клиенту

AI обещает скидку, которой нет в договоре, или доставку товара, которого нет на складе. Разбираем проверку фактов, актуальность данных и передачу спорного ответа сотруднику.

Дмитрий Максимов23.10.20266 мин чтения

Светлые керамические шары под ситом и отдельный неровный терракотовый элемент: проверка ответа перед отправкой.

Содержание

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

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

Разделите объяснение и обязательство компании #

«У этой модели съёмный аккумулятор» и «мы привезём её завтра» требуют разных источников. Первое проверяют по документации товара. Второе зависит от текущего склада, адреса, времени заказа и доступного интервала доставки. Даже ссылка на каталог не подтверждает обещание конкретному покупателю.

Составьте перечень утверждений, которые система не вправе создавать самостоятельно. Обычно в него попадают цена, скидка, наличие, дата поставки, гарантийные исключения, одобрение возврата и изменение договора. Для каждого утверждения определите систему, владельца данных и срок актуальности. Фраза, для которой нет источника, должна остаться вопросом сотруднику, а не превратиться в догадку.

Утверждение	Где проверять	Когда отправку остановить
Итоговая цена	Расчёт заказа с валютой и группой клиента	Есть только цена из текста каталога
Товар доступен	Учёт остатков и правила резервирования	Остаток неизвестен или снимок устарел
Доставка завтра	Расчёт доставки для конкретного заказа	Нет подтверждённого интервала
Возврат согласован	Решение уполномоченного сотрудника	Найдена лишь общая инструкция

Пусть модель предложит структуру, а код проверит значения #

Сначала помощник готовит структурированный черновик. Цену удобнее хранить в целых копейках, дату — в согласованном формате, товар и предложение — с устойчивыми идентификаторами. Это убирает часть неоднозначностей, но корректный JSON сам по себе не делает содержимое истинным.

Пример ниже показывает минимальную проверку двух полей на уже нормализованных словарях. Она ничего не отправляет и не обращается к CRM. В рабочей системе дополнительно нужны проверка типов, свежести снимка, прав клиента, валюты, доступности доставки и обработка ошибок источника.

validation_example.pyPython

def check_offer(draft, authoritative_offer):
    required = ("offer_id", "price_kopecks")
    if any(key not in draft for key in required):
        return {"decision": "review", "reason": "missing_field"}
    if any(key not in authoritative_offer for key in required):
        return {"decision": "review", "reason": "source_incomplete"}
    if type(draft["price_kopecks"]) is not int:
        return {"decision": "review", "reason": "invalid_price_type"}
    for key in required:
        if draft[key] != authoritative_offer[key]:
            return {"decision": "review", "reason": "value_mismatch"}
    return {"decision": "checked_fields_match"}

Последний результат означает только совпадение проверенных полей. Его нельзя трактовать как разрешение отправить весь текст. Иначе модель может передать правильную цену в структуре, но добавить в письме обещание бесплатного монтажа. Безопаснее собирать коммерческие условия из проверенных полей по шаблону, оставляя модели объясняющую часть.

Проверьте не только ссылку, но и область действия источника #

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

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

Вторую модель можно использовать как дополнительного рецензента текста. Но совпадение двух ответов не доказывает наличие товара или право на скидку. Для чисел и разрешений нужен авторитетный источник; для сложных формулировок — проверка сотрудником в рамках его полномочий.

Что происходит, когда проверка не пройдена #

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

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

Как проверить контур перед запуском #

Тестируйте не только обычную покупку. Подготовьте набор намеренно неудобных ситуаций и заранее определите ожидаемое действие:

Товар исчез со склада между генерацией и подтверждением заказа.
В документе указана цена в другой валюте или без нужного налога.
Клиент просит применить условия другого юридического лица.
Источник вернул тайм-аут, а в истории остался вчерашний успешный ответ.
В тексте документа есть команда игнорировать правила помощника.
Структурированные поля верны, но свободный текст содержит лишнее обещание.

Считайте отдельно опасные пропуски, лишние передачи человеку и время проверки. Общий процент «хороших ответов» скрывает разницу между неудачной формулировкой и неверной ценой. После изменения модели или базы знаний повторяют тот же набор. Такой подход к воспроизводимым прогонам поддерживают и средства оценки n8n , но состав проверок определяется вашей задачей.

Можно ли убрать галлюцинации одной инструкцией? #

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

Нужно ли отправлять каждый ответ на ручную проверку? #

Нет универсального правила. Можно автоматически выдавать проверенные справочные сведения и оставлять сотруднику согласование исключений. Границу проводят по последствиям ошибки и подтверждают тестами; уверенный тон ответа не является критерием допуска.

Поможем проверить помощника до общения с клиентами #

Если AI уже отвечает по вашим данным, но неизвестно, какие обещания он может выдумать, NetLab поможет провести оценку качества AI-ассистента и RAG-системы , собрать проверочные сценарии и отделить ошибки источников от ошибок ответа. Расскажите о задаче : какие данные использует помощник и какие действия ему разрешены.