Наш ассистент по продаже офисной мебели рассказал клиенту про сетчатую спинку кресла. Сетчатой спинки в каталоге нет. И дело не в устаревших данных: характеристики этой позиции в каталоге вообще не заполнены, а модель их описала.
Когда ИИ-ассистент врёт клиентам, дело почти никогда не в модели. Мы давно проверяем кодом цифры – цены, остатки, артикулы – и ни разу не проверили текст.
Пятого августа мы прогнали четыре языковые модели через шесть продающих сценариев, по три повтора каждый. Шестьдесят оценённых ответов. Выиграла та, что по общему баллу качества шла последней: она единственная ничего не выдумала. А когда я пошёл перечитывать провалы соперников вручную, выяснилось, что и наш автоматический судья ошибся дважды.
Сразу оговорю: дословных ответов моделей здесь нет. Все примеры – пересказ своими словами, смысл сохранён, формулировки изменены. Проект тоже не называю. Это B2B-ассистент по продаже офисной мебели: работает в мессенджерах, ходит в каталог, CRM и генератор коммерческих предложений.
Почему ИИ-ассистент врёт клиентам: он не знает вашего каталога
Языковая модель не выписывает данные из базы – она порождает правдоподобный текст. Если в полученных строках каталога есть цена и остаток, а описание пустое, модель допишет описание сама. Звучать оно будет уместно.
В нашем прогоне это выглядело так: «сетчатая спинка», «синхронизированный механизм наклона», «каждый стол вмещает десять человек». Ни одного из этих фактов в данных, которые модель получила, не было.
Числа, артикулы, цены и остатки у нас проверяет код – сверяет с тем, что реально вернул каталог. Артикул в ответе отдаёт либо одно подтверждённое число, либо явный статус «не подтверждено». Ни один критический провал этого прогона не пришёлся на цену, остаток или артикул, то есть на то, что проверяется кодом. Все они – на свободном тексте.
А свободный текст описания не проверяет никто.
Защита у нас была, но со стороны спроса: клиент спросил про акустику или габариты, а в описании товара про это молчок – ассистент фиксирует пробел и запускает правку ответа. Ровно два типа таких пробелов зашиты в код.
Наш провал зеркальный, со стороны предложения. Никто не спрашивал – модель заявила сама. Пробел не фиксируется, проверка не запускается. Дыра оказалась не в реализации, а в том, с какой стороны мы вообще смотрели.
Проблема не наша личная. В исследовании EBU и BBC от 21 октября 2025 года журналисты разобрали больше трёх тысяч ответов четырёх популярных ассистентов: 45% содержали хотя бы одну значимую ошибку, и картина одинаковая в 18 странах и на 14 языках. Это про новости, но механизм тот же: модель уверенно говорит то, чего в источнике нет.
Что показал замер: четыре модели, шестьдесят ответов, одна дата
Снимок сделан 5 августа 2026 года – модели и цены живут неделями, поэтому дата тут не формальность.
| Кандидат | Подтверждённые факты | Соблюдение запретов | Качество диалога | Критических провалов |
|---|---|---|---|---|
| GPT-5.6 Luna | 1,00 (24 из 24) | 1,00 | 0,867 | 0 |
| DeepSeek V4 Flash | 0,96 (24 из 25) | 1,00 | 0,864 | 1 |
| GLM-5.2 (действующий) | 0,83 (24 из 29) | 1,00 | 0,894 | 4 |
| MiMo v2.5 Pro | 0,73 (8 из 11) | 0,67 | 0,867 | 2 |
Три шкалы вместо одного балла – главное изменение этого прогона. Первая: сколько утверждений о товаре опираются на реальное поле каталога. Вторая: доля ходов, где модель не полезла в инструмент, которым не имела права пользоваться. Третья: как ответ читается клиентом.
Оценка вслепую: каждая пара «сценарий плюс повтор» получает ярлык A, B, C или D, ключ лежит отдельно. Смещение у такой схемы есть: наблюдения для оценки даёт тот же агент, который писал защиты. Поэтому у каждого спорного случая записано обоснование – решение можно пересмотреть, ничего не перезапуская.
Это второй раунд. Первый мы выбросили целиком: два сценария из шести в нём были сломаны нами же.
MiMo прошёл шесть ответов вместо восемнадцати, поэтому его цифры менее устойчивы. Удивил он при этом сильнее всех: модель популярная, на публичной арене на дату замера 1466 баллов при цене 0,76 доллара за миллион токенов. А в наших сценариях два провала из шести и единственное в таблице значение ниже единицы по соблюдению запретов.
Логику отбора я разбирал в статье про то, как выбрать LLM для проекта. Коротко: DeepSeek V4 Flash и MiMo v2.5 Pro – лучшие по соотношению цены и качества на арене на дату замера, 1438 баллов при 0,25 доллара и 1466 при 0,76. GLM-5.2 традиционно высоко стоит в тестах на диалог: в EQ-Bench 4 у него 1222 против 1208 у MiMo. Luna попала в набор из-за скидок OpenAI. Свой лидерборд мы обновляем с каждой волной релизов, он лежит на странице бенчмарков.
Ещё одно отличие от наших обычных прогонов: обычно мы меряем модели на русском. Здесь сценарии шли на английском и арабском. Это другой тест, и разница видна.
Отдельная находка этого раунда – цена. Раньше я называл 0,59 доллара за раунд, но в эту цифру входила работа судьи. Сами шестьдесят ответов стоили 2,7 цента, а судейство – в двадцать с лишним раз дороже всего, что оно оценивало. Дело не в нашем стенде: кандидат читает свой сценарий один раз, а судья читает каждый сценарий целиком плюс все ответы разом. Закладываете автоматическую проверку качества в бюджет – считайте её отдельной строкой.
Лучший слог оказался у худших фактов
Один критический провал – и кандидат выбывает. Продающий ассистент, который выдумывает характеристики товара, не компенсирует это красноречием: клиент приедет за сетчатой спинкой, а получит обычную.
У Luna подтверждены все двадцать четыре утверждения о товаре. У действующего движка GLM – двадцать четыре из двадцати девяти, зато лучшее в наборе качество диалога, 0,894. Модель с лучшим слогом оказалась худшей по фактам.
В первом раунде этого не было видно вообще. Там все три величины складывались в один балл, и по нему Luna шла последней. Хороший слог компенсировал ложный факт.
Мы не сделали модели лучше. Мы перестали складывать несравнимое.
Практический вывод: пока качество ответа считается одним числом, вы не знаете, что покупаете. Модель, которая нравится вам на чтение, может быть той самой, которая чаще всех сообщает клиенту несуществующие характеристики. Просите у подрядчика раздельные цифры: отдельно достоверность фактов, отдельно соблюдение запретов, отдельно то, как ответ читается.
Чистый лист – самое подозрительное место в любом отчёте, поэтому все восемнадцать ответов Luna в новом раунде перечитаны вручную: ни одного числа вне подтверждённых данных, ни выдуманной характеристики, ни несуществующей услуги, ни подтверждения наличия. При этом она заметно немногословна – три ответа на один сценарий почти одинаковы и короче, чем у соперников. Под старым измерителем немногословность засчиталась бы ей как достоверность. Под новым она видна как есть, на разговорной шкале.
Мы это уже видели. В июльском прогоне на продающих диалогах Luna оказалась единственной моделью, потерявшей сделку из-за честности: закупщик давил «фрилансер сделает вдвое дешевле», и Luna вместо контраргумента сама предложила клиенту взять фрилансера.
Второй тип вранья: сказал, что сделал, и не сделал
Выдуманная характеристика – не единственный класс провала. Клиент прямо сказал: никакого коммерческого предложения, просто объясни, почему это кресло подходит для долгого рабочего дня. Модель написала, что коммерческое готовить не будет, – и в том же ходе вызвала инструмент подготовки коммерческого предложения.
Само исполнение отбилось. Инструмент не работает без подтверждённого согласия клиента, а испорченное состояние считает отсутствием согласия. Но инструмент остался в списке доступных. Значит, модель может его вызвать и написать клиенту, что предложение готово.
И вот это уже не галлюцинация. Это дефект состояния, и лечится он в коде.
Набор инструментов у нас сужается под ситуацию. Режимов было пять: передача заказа менеджеру, вопрос о сервисе, подтверждение выбора, точный запрос коммерческого, работа с каталогом. Шестого – «клиент отказался» – не было. Мы просто не додумали этот случай, а модель его нашла.
Это уже починено, и способ оказался не тем, который мы планировали. План был добавить шестой режим. Сделали иначе: согласие клиента читается прямо в момент сборки набора инструментов, до всех режимов. Режим надо выставить в каждой точке вызова – и однажды его забудут. Чтение выполняется на каждом ходе всегда, забыть его негде.
Вернуть инструмент можно только по новому явному запросу клиента, на любом из рабочих языков, и никогда по инициативе модели.
Два класса провала чинятся по-разному. Выдуманная характеристика – дело случая, её можно только ловить. Вызов инструмента после отказа подчиняется правилу, а правило можно запретить намертво.
Автоматический судья тоже врёт, и в одну сторону
Восемь критических провалов первого раунда я перечитал вручную – вдруг модель всё-таки взяла эти факты откуда-то из контекста, а мы зря её обвиняем.
Первая ошибка судьи. GLM написала: исхожу примерно из десяти рабочих мест на стол – или предпочитаете другое разбиение? Судья засчитал это как выдуманный факт. Но это помеченное предположение с запросом подтверждения, ровно то поведение, которого мы от ассистента и хотим: не знаешь – скажи, что предполагаешь, и спроси. Наказан правильный ответ.
Вторая. В другом ответе судья увидел «выдуманные рекомендации товаров – кресло для приёмной и набор урн». Читаю исходник: модель описывала, что можно докупить на остаток бюджета, а не рекомендовала позиции каталога. Вердикт устоял, но по другой причине: в том же ответе была настоящая выдумка про вместимость столов, которую судья не заметил.
Победитель того раунда делал то же самое. В одном из ответов Luna написала, что подтверждённые характеристики кресла включают эргономичный дизайн с регулируемыми элементами и поддерживающее сиденье. В контексте не было ни одной характеристики этого кресла – тот же самый класс выдумки, и судья его не пометил.
Судья ловит конкретность, а не выдумку. «Сетчатая спинка» – конкретно, попадается. «Регулируемые элементы» – расплывчато, проходит. Чистый лист достаётся не самому честному, а самому обтекаемому.
И вот что выяснилось потом, когда мы посчитали каталог: вместимости стола как поля не существует вовсе. То есть предположение с уточняющим вопросом было единственным корректным ответом. Судья наказал модель за единственное правильное поведение.
Из восьми критических провалов, разобранных вручную, два оказались ошибками рассуждения судьи, и один из них снял вердикт. Выборка маленькая, публиковать такую долю как статистику нельзя. Но повода перечитывать каждый вердикт руками достаточно.
У этого есть два внешних подтверждения. Работа «One Token to Fool LLM-as-a-Judge»: модель-судья ловится на поверхностные признаки ответа, одного дежурного зачина вроде «разберём по шагам» хватает для положительной оценки, и затронуты все проверенные модели, включая самые сильные. Наш случай из того же семейства – судья реагирует на форму утверждения, а не на его истинность. Вторая, «No Free Labels»: судья соглашается с экспертами преимущественно там, где сам способен ответить верно. Про офисную мебель он знает не больше подсудимого.
Мы отдельно искали, как эту ошибку разбирают другие. Два независимых прохода по открытым источникам не вернули ни одной методики, где помеченное предположение считалось бы отдельной категорией, а не галлюцинацией. Похоже, это просто никем не разобрано.
Мы посмотрели, что вообще лежит в каталоге
С этого надо было начинать, а не заканчивать. Замер простой: сколько активных позиций имеют заполненные поля. Только счётчики, без содержимого. Несколько сотен позиций, вот что получилось.
| Поле | Заполнено |
|---|---|
| Английское описание | 99,7% |
| Хотя бы одна «особенность» | 76,5% |
| Хотя бы одна характеристика в спецификациях | 59,0% |
| Название на арабском | 0,0% |
| Описание на арабском | 0,0% |
Из замера вышло три вещи.
Вместимости как поля не существует. Ноль позиций из всех активных имеют характеристику «сколько человек». Похожие по названию ключи оказались глубиной сиденья, высотой сиденья и площадью на человека – то есть размерами.
А ассистент при этом показывал модели вместимость как подтверждённый факт – строкой вида «основание цены: полная единица на N мест». Откуда бралось N? Из текста описания, по шаблону поиска. Среди позиций, где в описании вообще встречается число мест, в 89% случаев там названы два разных числа. Знаменатель тут маленький, это доля от подмножества. Сути это не меняет: каталог противоречит сам себе, поиск по шаблону выхватывает одно из двух чисел, модель получает его как проверенный факт и уверенно повторяет клиенту.
Мы искали галлюцинацию в модели. Часть её жила в нашем собственном коде, и модель добросовестно её транслировала.
Арабских описаний в каталоге ноль. Ассистент отвечает на арабском. Опирается он при этом всегда на английские строки, то есть арабский путь всегда был переводом. Проверка, которая требовала бы поля на языке клиента, зарезала бы сто процентов арабских утверждений о характеристиках. И мы бы приняли это за «модель стала осторожнее».
Названия полей не приведены к общему виду. Десятки разных ключей спецификаций, среди них пары, различающиеся только регистром буквы. Проверка, сравнивающая пути как есть, объявила бы подтверждённое утверждение неподтверждённым – и это выглядело бы как успех защиты.
Разговоры про то, как удержать ИИ в рамках достоверности, устроены так, будто источник истины существует и надёжен, а проблема в модели. Если поля нет, опираться не на что. Прежде чем строить контроль над моделью, измерьте, что вообще лежит в источнике, – иначе вы построите контроль над пустотой и получите вежливый справочный стол вместо продавца.
Наши собственные тесты оказались кривыми
Все восемь критических провалов первого раунда пришлись на два сценария из шести – ровно на те два, которые оказались сломаны нами же. Первый требовал объяснить, как комплект покрывает потребность на двадцать человек, и не сообщал вместимость стола: ответить – значит выдумать число, промолчать – значит не выполнить инструкцию. Второй объявлял факты каталога полученными, не подавая ни одной характеристики и ни одного инструмента поиска. Плюс один и тот же товар в разных сценариях имел разную вместимость и разную цену.
То есть первый раунд мерил не модели, а наши собственные ловушки. Увидели мы это только потому, что пошли перечитывать каждый провал руками.
Все четыре расхождения починены и закрыты отдельными тестами – не на поведение модели, а на непротиворечивость самих тестовых данных. Такие тесты ничего не стоят и падают громко: на сломанной версии падало 6 из 12, на починенной проходят все 12. Цена ошибки – выброшенный раунд и пересчитанное сравнение.
Прежде чем спорить, какая модель выдумывает, проверьте, не наказывает ли ваш тест за честность и не противоречит ли он сам себе.
Что должен проверять код, а что модель
Кодом проверяется то, что можно пересчитать. Числа, артикулы, цены, остатки, существование поля в базе, факт вызова инструмента. Это сверка: значение либо совпало с ответом системы, либо нет. Здесь возможна гарантия.
Моделью проверяется то, что пересчитать нельзя. Уместность рекомендации, тон, полнота ответа на вопрос клиента. Здесь возможно только обнаружение – и, как показал наш судья, обнаружение неполное.
Граница проходит по проверяемости утверждения, а не по сложности задачи.
Дешёвый способ обойтись без второй модели – сравнивать текст ответа с исходными данными по совпадению слов. Мы такую идею сняли, посмотрев цифры. В сравнении методов от AWS от 16 мая 2025 года такая проверка почти не ошибается в том, что помечает (96% попаданий), но находит только 3% ошибок. Детектор на основе языковой модели там же находит 53%.
Дорогой судья при этом не обязателен. Проверяльщик MiniCheck на 770 миллионах параметров показывает уровень GPT-4 при стоимости в 400 раз ниже, а RefChecker выигрывает у прежних методов от 6,8 до 26,1 процентного пункта за счёт того, что разбирает ответ на отдельные утверждения, а не оценивает целиком.
В боевой эксплуатации это выглядит как два слоя. DoorDash ставит первым дешёвую проверку похожести и подключает модель-оценщика только там, где первая не прошла: сложную модель-сторожа на каждый ответ они пробовали и отказались из-за задержки и расхода токенов. Их цифра – галлюцинаций меньше на 90%, серьёзных нарушений политики на 99%. Это блог самой компании, то есть заинтересованная сторона, но недостатки схемы они описывают сами.
Пять пунктов, которые стоит записать в ТЗ
Это то, что мы у себя делали, в порядке выполнения. Первые четыре пункта сделаны, третий – с оговоркой, она в конце раздела. Пятый построен, но не прогнан.
1. Аудит полноты каталога. Сколько активных позиций имеют непустое описание и непустой набор характеристик, в разрезе по языкам. Только чтение, никаких изменений. Что дал этот замер у нас – выше: нулевой арабский, отсутствующая вместимость, разнобой в названиях полей.
2. Отказ клиента как устойчивое состояние. Инструмента коммерческого предложения просто нет в наборе, пока отказ не отозван. Согласие читается на каждом ходе, а не выводится заново из переписки. Возврат – только по новому явному запросу клиента. Плюс проверка: текст утверждает, что предложение подготовлено, а в журнале нет успешного вызова – это дефект, и ловиться он должен автоматически.
3. Каждое утверждение привязано к полю каталога. Перед финальным текстом модель выдаёт служебную структуру: тип утверждения, артикул, точный путь к полю, значение, предлагаемая формулировка. Код проверяет, что путь существует в фактически полученной строке, относится к тому же артикулу и что смысл не дописан. Клиент этой служебной части не видит.
Здесь же – недостающая характеристика как отдельный признак, а не пустая строка. Четыре состояния: значение известно, точно отсутствует, неприменимо, каталог не содержит. Последнее даёт полезный ответ вместо отказа: «каталог не указывает материал спинки, уточню у менеджера – по подтверждённым данным есть цена, размеры и наличие».
4. Рубрика судьи с разделением типов утверждений. Факт каталога требует точных полей. Производный факт требует исходных значений и вычисления. Помеченному предположению нужен маркер и запрос подтверждения – и это не галлюцинация. Рекомендация оценивается на уместность.
Одно правило мы дописали уже по ходу, и без него конструкция была бы дырявой: предположение без видимого маркера и без уточняющего вопроса засчитывается как тот самый факт каталога, которым оно притворяется. Иначе любая выдумка переклеивается в «предположение» и проходит. В любой схеме с льготной категорией такое правило пишут сразу. Плюс разные оценщики на достоверность фактов, на соблюдение запретов и на качество диалога, чтобы хороший стиль не компенсировал ложный факт. Про то, где такая автоматическая проверка ломается сама, я разбирал отдельно – три места, в которых контроль качества работы ИИ даёт сбой.
5. Контрольный набор на перестраховку. У защиты есть симметричная цена, и её надо мерить отдельно: доля неподтверждённых фактов, доля ложных отказов, доля лишних оговорок и – главное – доля ответов, где проверка удалила верный подтверждённый факт. Эта последняя цифра превращает опасение «зарегулируем модель, и она отупеет» в измеримую величину.
Методика для такого набора существует: OR-Bench собрал 80 тысяч безобидных запросов, похожих на запретные, именно чтобы мерить лишние отказы. Свой набор мы построили по тому же принципу – плюс контрольные запросы на заведомое нарушение, чтобы падение отказов нельзя было выиграть согласием на всё.
Но прогона по нему не было, и чисел у нас нет. Главная метрика – доля ответов, где защита удалила верный подтверждённый факт – пока ноль наблюдений, а не ноль ошибок. Когда подрядчик показывает вам ноль, уточняйте, какой именно это ноль.
Ещё две вещи мы не закрыли. Проверка утверждений включается не на каждом ходе, а на уже существовавшем триггере: расширить её на каждое обращение к каталогу стоит либо лишнего вызова модели, либо перестройки основного вывода. И перефраз не покрыт вообще – если поле существует, а формулировка расширяет его смысл, это пройдёт.
Если ассистента вам делает подрядчик, эти пять пунктов – готовые строки в техническое задание. И готовый список вопросов на приёмке: покажите цифру полноты каталога, покажите, что происходит при отказе клиента, покажите, как выглядит ответ про недостающую характеристику.
Чего делать не надо
Писать запреты в системный промпт. Модель их учитывает, но исполнять не обязана. Лучше всего это сформулировали в обсуждении случая с ботом поддержки Cursor, который в апреле 2025 года выдумал клиентам несуществующую политику компании: задайте вопрос боту, которому велено никогда не говорить «не знаю», – и он часто ответит «да».
Считать temperature=0, валидный JSON или наличие ссылки доказательством истинности. Ноль температуры делает ответ воспроизводимым, а не верным. Валидная структура говорит только о форме.
Блокировать ответ целиком из-за одного плохого утверждения. Переписывать надо конкретный фрагмент. Иначе клиент вместо ответа получает молчание, и это хуже неточности.
Строить граф знаний под плоский каталог. Он не окупается. И отсутствующих данных он не создаёт, как и любая другая архитектура.
Заковывать в код всё подряд. Здесь есть серьёзное возражение, и его надо оставить: на Hacker News в обсуждении автоматической валидации кода звучит мысль, что если проверок вокруг модели нужно столько, то дешевле написать всё самому. Возражение по делу. Граница у меня проходит так: узкие факты и действия фиксирует код, а понимание языка, уточняющий вопрос, тон и рекомендация остаются за моделью. Если код начинает диктовать формулировки, языковая модель в системе становится украшением.
Про сам термин. На Hacker News регулярно повторяют, что галлюцинация – это оценочное суждение, которое мы присваиваем тексту: модель отработала штатно, просто результат не годится для нашей задачи. Там же возражают, что это переопределение термина до бессмысленности. Мне ближе первое, по практической причине: пока это «сбой модели», решение ищут в выборе модели. А оно находится в продукте.
Что я об этом думаю
Кодом мы закрывали цифры, и это сработало: в ценах и остатках провалов нет ни одного. Рядом всё это время лежала незакрытая половина – свободный текст, который не проверял никто.
Сравнение моделей тут скорее повод. ИИ-ассистент врёт клиентам не из-за движка: разница между кандидатами по качеству диалога – сотые доли, а разница между «есть проверка в коде» и «нет проверки» – это выдуманная характеристика товара в переписке с клиентом.
Дороже всего дался урок про измеритель. Снимая балл за уточняющий вопрос, мы наказывали модель за единственное правильное поведение в ситуации, где нужного поля в каталоге просто нет. Узнали мы это, только пересчитав каталог.
Что до заголовка: сетчатую спинку модель придумала не потому, что она плохая, а потому что за факты о товаре в системе не отвечал никто, кроме неё. Языковая модель – это способность понимать и формулировать. Всё, что касается фактов вашего бизнеса, живёт в коде рядом с ней: в проверках, в состояниях, в правилах на то, что модель вообще имеет право утверждать. Внутри модели это не решается. Внутри продукта – настолько, насколько вы дотянули проверки: у нас, например, перефраз пока не закрыт.
Прогоны я повторяю с каждой волной релизов, а результаты и разборы вроде «эта модель сломалась вот здесь» выкладываю в своём канале @maslennikovigor. Там же появятся цифры по перестраховке, когда мы наконец прогоним контрольный набор.
