Ловим галлюцинации ИИ: 3 ограждения для B2B-команд

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

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

Все три имеют один паттерн: без настоящей опоры модель заполняет пустоту. Проблема в том, что вывод выглядит уверенно — даже когда неверен. "ИИ ошибается" — недостаточно; нужно знать где и почему. Три ограждения ниже это делают.

Три ограждения: источник, правило, человек

1) Цитата источника: модель возвращает каждый ответ с id или номером строки исходного документа. Без источника отвечает «не знаю». Галлюцинации падают на ~80%.

2) Проверка правилами: валидируем вывод по доменным правилам до выдачи — номер заказа 8 цифр? Категория счёта в списке? Формат даты валиден? Эти дешёвые Python-проверки ловят большинство.

3) Человеческое одобрение: рискованные действия (возвраты, подписание договора) предлагает ИИ, одобряет человек. ИИ делает ~95% сам; 5% исключений идут к вам на ревью.

Три вместе: в независимом аудите процент галлюцинаций падает ниже 2%.

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

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

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

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

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

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

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

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

На другом конце шкалы структурированное извлечение по фиксированной схеме — разобрать резюме на имя/email/навыки, классифицировать обращение по одной из 12 категорий, присвоить транзакции код продавца — относительно низкорисково. У модели меньше простора для выдумки, потому что пространство результатов ограничено и легко проверяется механически: можно проверить, что категория существует, что в email есть значок @, что значение входит в число 12 вариантов. Классификация в небольшой закрытый набор ведёт себя так же — даже когда модель ошибается, она ошибается в рамках заданных вами границ, а это принципиально более дешёвый режим сбоя.

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