Как выявлять галлюцинации ИИ: 3 защитных механизма для B2B-команд

Как выглядят галлюцинации ИИ в реальных процессах B2B

Галлюцинация возникает, когда модель генерирует уверенно звучащий, но неверный ответ. В B2B это проявляется в трёх типичных формах: (1) модель выдумывает несуществующий номер заказа в ответе на обращение в поддержку, (2) при подготовке резюме договора «цитирует» дату, которой в нём нет, (3) при классификации счетов создаёт категорию, отсутствующую в заданном списке.

Во всех трёх случаях механизм один: без опоры на реальные источники модель заполняет пробел. Результат выглядит убедительно, даже если он неверен. Недостаточно сказать: «ИИ ошибается»; нужно знать, где и почему. Для этого предназначены три защитных механизма ниже.

Три защитных механизма: источник, правило, человек

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

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

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

Выстраивание процесса оценки перед запуском

Частоту галлюцинаций нельзя определить на глаз — нужен тестовый набор. Соберите эталонный набор из 50–200 реальных примеров с известными правильными ответами. Включите пограничные случаи: отсутствующие данные, неоднозначные запросы и обращения вне предусмотренной области применения. После каждого изменения инструкции или модели проверяйте новую версию на этом наборе до её запуска в эксплуатацию.

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

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

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

Какие задачи несут наибольший риск галлюцинаций

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