Самый неприятный случай в моей практике выглядел безобидно. Ассистент по номенклатуре отвечал: «у поставщиков такой позиции нет». Спокойно, уверенно, 571 раз.
Позиции были. Просто в выгрузке из 1С слово «Сгон» набрано с латинской буквой C, «угольник» — с латинской y, а в «PN16» латинская N. Глазами не отличить никак, а поиск такие строки не видит вообще. Формально система не выдумывала — она честно не нашла. Для снабженца разница нулевая: ему дали неверный ответ, и он бы по нему закупился.
С этого начну разговор про галлюцинации. Вранья у ИИ несколько сортов, и придуманные факты — не самый опасный из них.
Пять способов соврать
Выдуманное число. Модель не знает точной цифры и подставляет правдоподобную. «Гарантия 12 месяцев» вместо 24, «срок поставки 5 дней» вместо 15. Самый дорогой тип: числа люди не перепроверяют, их переписывают в коммерческое предложение.
Сборка из двух документов. Условия из прайса для дилеров склеиваются с гарантией из розничного регламента, и получается предложение, которого у компании никогда не было. Каждая половина ответа верна, целое — нет.
Устаревшее выдаётся за действующее. В базе лежат две редакции положения, ассистент цитирует ту, что нашлась. Про то, как этого избежать, я подробно писал в разборе про сборку базы знаний — коротко: в поиске должна лежать только действующая редакция.
Ложное «нет». История с латинской C — как раз отсюда. Система не нашла и делает вывод «этого не существует». Отдельно коварно тем, что в логах выглядит как нормальная работа.
Уверенный тон на пустом месте. Вопрос вне базы, ответа нет, но модель отвечает — потому что её этому и учили. Проверить такой ответ можно только зная правильный, а если бы человек его знал, он бы не спрашивал.
Правило первое: ответ без источника не считается ответом
Канон, к которому мы пришли на инженерной платформе, звучит грубо, но экономит месяцы разбирательств: ни одного числа без ссылки на документ. Ассистент обязан вернуть вместе с ответом название файла, раздел и по возможности прямую цитату. Не «согласно регламенту», а «Положение о гарантии, ред. от 12.03.2026, п. 4.2».
Даёт это три вещи. Человек может проверить за 20 секунд, а не поверить на слово. Инцидент разбирается по горячим следам: видно, кривой документ или кривой поиск. И, что неожиданно, качество ответов растёт само — когда модель обязана опираться на конкретный фрагмент, ей сложнее фантазировать.
Там, где цена ошибки высока — расчёты, нормативка, деньги, — мы ставим отдельного контролёра: вторая проверка трассирует новые разделы базы до исходных файлов и охотится на выдумку. Сам себя ни один участник не принимает, ни человек, ни ИИ. У пары контролёров отчётности мы устроили так же: один проверяет данные, второй собирает сводку, и оба перепроверяют друг друга до того, как результат уйдёт руководству.
Автотесты: контрольные вопросы и капканы
Для инженерной базы у нас 187 автотестов, и это не про красоту цифры. Это набор вопросов с заранее известными ответами, который прогоняется после каждого изменения базы.
Набор делится на три части.
Обычные вопросы — то, что спрашивают каждый день. Ответ известен, сверяется автоматически по ключевым фактам.
Капканы — вопросы, ответа на которые в базе нет и быть не должно. Единственный правильный результат — «не знаю, уточните у такого-то». Если система начинает на них отвечать, значит кто-то ослабил ограничения промпта.
Стыки — вопросы, ответ на которые лежит на границе двух документов. Здесь ловится склейка несовместимого.
Прогон занимает минуты, а ловит вещи, которые вручную не отследить. Классический сценарий: добавили в базу пять новых файлов, точность на старых вопросах упала с 19 из 20 до 15 — новые документы «перетянули» поиск на себя. Без тестов это заметит клиент.
Отдельная категория проверок — арифметика. Языковые модели считают плохо и уверенно. Любой расчёт (скидка, объём, сумма с НДС) надо выносить из модели в код: ИИ достаёт цифры и правило, а умножает калькулятор. Мы наступали на это дважды, прежде чем сделали правилом.
Право сказать «не знаю»
Модель по умолчанию угодлива. Чтобы она молчала, когда не знает, разрешение на «не знаю» надо выдать явно и подкрепить ограничениями:
- отвечать только по найденным фрагментам, внешние знания не использовать;
- если релевантных фрагментов нет — отдавать шаблон «в базе нет, передаю человеку» и создавать задачу;
- если фрагменты противоречат друг другу — показать оба и не выбирать;
- запрет на предположения в темах денег, сроков, гарантий, договоров и нормативки;
- порог уверенности поиска: слабое совпадение приравнивается к «не найдено».
Дальше вопрос настройки баланса. Слишком строгий порог — ассистент отказывается отвечать на треть нормальных вопросов, люди перестают им пользоваться за неделю. Слишком мягкий — начинает сочинять. Мы обычно стартуем строго и ослабляем по логам: смотрим, на чём он зря промолчал, и добавляем документы, а не расширяем свободу модели.
Второй проход и короткий ответ
Две дешёвые настройки, которые заметно сбивают частоту вранья.
Первая — второй проход. Готовый ответ вместе с найденными фрагментами уходит на повторную проверку с единственным вопросом: каждое ли утверждение подтверждается текстом источника? Что не подтверждается — вычёркивается. Платите вы за это удвоенным временем ответа (условно, три секунды вместо полутора) и двойным расходом на модель. В болтовне с клиентами оправдано не всегда, в расчётах и договорах — практически всегда.
Вторая — жёсткий лимит длины. Чем длиннее ответ, тем больше в нём отсебятины: в найденных фрагментах фактов на три предложения, а модель послушно пишет десять и добирает разницу из воздуха. Мы держим ответ в 3–5 предложениях плюс ссылка на документ. Нужны подробности — человек открывает источник, там всё есть.
Побочный эффект приятный: короткие ответы читают. Длинные простыни пролистывают и на всякий случай переспрашивают у коллеги, а значит, ассистентом не пользуются.
Что писать в лог
Лог — единственное, что превращает «он какую-то ерунду ответил» в решаемую задачу. Минимальный набор на каждый ответ:
| Что пишем | Зачем |
|---|---|
| Вопрос в исходном виде | формулировка часто и есть причина |
| Какие фрагменты нашёл поиск, с оценками | видно, поиск подвёл или модель |
| Итоговый ответ и указанные источники | сверка с реальным документом |
| Сработал ли отказ, была ли эскалация | статистика по «не знаю» |
| Оценка пользователя (палец вверх/вниз) | дешёвая разметка на будущее |
| Время ответа | деградация заметна раньше жалоб |
Кнопка «ответ неверный» рядом с каждым сообщением стоит копейки в разработке и приносит больше пользы, чем любая аналитика. Люди жмут её охотно.
Разбор инцидента
Когда неверный ответ всё-таки дошёл до клиента, работает короткая процедура. По логу поднимаем, что нашёл поиск. Дальше развилка: если нужного фрагмента в найденном нет — виноват поиск или база (нет документа, кривая нарезка, гомоглифы, скан без текста). Если фрагмент был, а ответ ему противоречит — виновата модель и промпт.
Починили — обязательно добавляем этот вопрос в набор автотестов. Так набор и вырос до сотен пунктов: каждый инцидент оставляет после себя тест. Раз в неделю смотрим сводку: сколько было отказов, сколько жалоб, на каких темах.
Как это выглядит на живом случае
Клиенту ушёл ответ с условиями, которых у компании нет: срок отгрузки со склада взят из одного документа, гарантия — из другого. Обе цифры настоящие. Комбинация — выдуманная.
По логу видно всё за пять минут. Поиск вернул два фрагмента, у обоих в заголовке слово «Условия»: один из прайса для дилеров, второй из розничного регламента. Модель добросовестно собрала ответ из того, что дали.
Виноват тут не ИИ, а структура базы. Мы дописали в шапку каждого документа строку «для кого» — розница, дилеры, тендеры. Дальше запретили смешивать в одном ответе фрагменты с разной аудиторией: нашлись оба — ассистент обязан спросить, о каком случае речь. И добавили четыре вопроса-стыка в набор тестов, чтобы это не вернулось после следующего пополнения базы.
Чек-лист: как проверить ассистента за полчаса
Работает и на своей системе, и на демо подрядчика:
- задайте пять вопросов, ответов на которые в базе точно нет. Правильная реакция одна — «не знаю»;
- на любой ответ с цифрой попросите источник: файл, раздел, цитату;
- дайте посчитать: скидка 17% от 143 600 ₽. Если считает сама модель, а не код, рано или поздно ошибётся;
- проверьте противоречие: спросите то, что по-разному написано в двух документах;
- спросите одно и то же тремя формулировками, как спросили бы разные сотрудники;
- попросите показать лог этого диалога. Нет лога — нет управляемости;
- узнайте, кто разбирает жалобы на неверные ответы и как часто.
Частые вопросы
Галлюцинации можно убрать полностью? Нет. Можно снизить частоту до единиц процентов и сделать ошибку заметной до клиента. Обещание «ноль ошибок» — повод усомниться в остальном, что говорит подрядчик.
Дорогая модель решает проблему? Частично. Модель посильнее реже путается в формулировках, но выдумывать её заставляет отсутствие нужного фрагмента в базе. Основной вклад дают документы и ограничения, а не ценник за токены.
Ассистент слишком часто отвечает «не знаю». Что делать? Смотреть логи отказов. В девяти случаях из десяти это не строгость настроек, а дырка в базе или разница в словах: люди спрашивают не теми терминами, что написаны в регламенте.
Кто отвечает, если неверный ответ ушёл клиенту? Компания. Ровно поэтому в чувствительных местах — деньги, сроки, гарантии, договоры — ответ уходит клиенту после человека, а не напрямую.
Где это не работает
Ни одна из этих мер не даёт нуля ошибок. Убрать галлюцинации полностью нельзя — можно снизить частоту и сделать так, чтобы ошибка была видна до клиента. Обещания «наш ИИ не врёт» — маркетинг, а не инженерия.
Цитаты-источники не спасают от кривых документов. Если в регламенте написана ерунда, ассистент честно процитирует ерунду со ссылкой. Мусор на входе даёт мусор на выходе, просто с адресом.
Автотесты не ловят то, чего в них нет. Первые месяц-два набор всегда неполный, и без человека, который читает выборку живых диалогов, качество не поднять.
И самое неприятное: контроль стоит времени. Двадцать вопросов приёмки, разбор инцидентов, еженедельная сводка — это часы работы конкретного сотрудника каждую неделю. Компании, которые эту роль не выделяют, через пару месяцев получают систему, которой никто не доверяет, и разговор «ИИ у нас не взлетел». Дело не в ИИ.
С чего начать
Возьмите вашего текущего ассистента (или демо подрядчика) и задайте ему пять вопросов, ответов на которые в его базе нет. Если он ответит на все пять вместо честного «не знаю» — систему нельзя показывать клиентам, там нет ограничений.
Второй шаг: попросите на любой ответ с цифрой показать источник. Не получите файл и пункт — считайте, что цифра выдумана.
Как мы собираем контур с проверками, видно в кейсах — там же случай, где сверка номенклатуры разбирается подробно: ИИ в снабжении. А если хотите оценить риски на своих процессах — приходите на AI-аудит: посмотрим, где у вас цена ошибки высокая, и скажем, что там вообще нельзя отдавать ИИ без второй пары глаз.