Наш ассистент по продаже офисной мебели рассказал клиенту про сетчатую спинку кресла. Сетчатой спинки в каталоге нет. Не «данные устарели» – характеристики этой позиции в каталоге вообще не заполнены, а модель их описала.
Когда ИИ-ассистент врёт клиентам, дело почти никогда не в модели. Мы давно проверяем кодом цифры – цены, остатки, артикулы – и ни разу не проверили текст.
Пятого августа мы прогнали четыре языковые модели через шесть продающих сценариев, по три повтора каждый. Шестьдесят оценённых ответов. Выиграла та, что заняла последнее место по итоговому баллу качества, – потому что она единственная ничего не выдумала. А когда я пошёл перечитывать провалы соперников вручную, выяснилось, что и наш автоматический судья ошибся дважды.
Сразу оговорю: дословных ответов моделей здесь нет. Все примеры – пересказ своими словами, смысл сохранён, формулировки изменены. Проект тоже не называю: это B2B-ассистент по продаже офисной мебели, работает в мессенджерах, ходит в каталог, CRM и генератор коммерческих предложений.
Почему ИИ-ассистент врёт клиентам: он не знает вашего каталога
Языковая модель не выписывает данные из базы – она порождает правдоподобный текст. Если в полученных строках каталога есть цена и остаток, но описание пустое, модель допишет описание сама. Оно будет звучать уместно и профессионально.
В нашем прогоне это выглядело так: «сетчатая спинка», «синхронизированный механизм наклона», «каждый стол вмещает десять человек». Ни одного из этих фактов в данных, которые модель получила, не было.
Числа, артикулы, цены и остатки у нас проверяются кодом против фактического результата запроса к каталогу. В пределах одного ответа артикул отдаёт либо одно подтверждённое число, либо явный статус «не подтверждено». Ни один из восьми критических провалов этого прогона не пришёлся на цифру – все восемь на свободный текст.
А свободный текст описания не проверяет ничего.
Существующая защита работает со стороны спроса: клиент спросил про акустику или габариты – в описании товара про это молчок – фиксируется пробел, запускается проход правки. Ровно два типа таких пробелов зашиты в код.
Наш провал зеркальный, со стороны предложения. Никто не спрашивал – модель заявила сама. Пробел не фиксируется, проверка не запускается. Мы поймали дыру не в реализации, а в том, с какой стороны вообще смотрели.
Проблема известная и не наша личная. В исследовании EBU и BBC от 21 октября 2025 года журналисты разобрали больше трёх тысяч ответов четырёх популярных ассистентов: 45% содержали хотя бы одну значимую ошибку, и картина одинаковая в 18 странах и на 14 языках. Это про новости, но механизм тот же: модель уверенно говорит то, чего в источнике нет.
Что показал замер: четыре модели, шестьдесят ответов, одна дата
Снимок сделан 5 августа 2026 года – модели и цены живут неделями, поэтому дата тут не формальность.
| Кандидат | Заземление | Послушание инструментов | Качество диалога | Критических провалов |
|---|---|---|---|---|
| GPT-5.6 Luna | 1,00 | 1,00 | 0,867 | 0 |
| DeepSeek V4 Flash | 0,96 | 1,00 | 0,864 | 1 |
| GLM-5.2 (действующий) | 0,83 | 1,00 | 0,894 | 4 |
| MiMo v2.5 Pro | 0,73 | 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 заземление 1,00 – ни одного неподтверждённого утверждения за восемнадцать ответов. У действующего движка GLM заземление 0,83 и при этом лучшее в наборе качество диалога, 0,894. Модель с лучшим слогом оказалась худшей по фактам.
В первом раунде этого не было видно вообще. Там все три величины складывались в один балл – и по нему Luna шла последней. Хороший слог компенсировал ложный факт, а немногословность читалась как надёжность.
Мы не сделали модели лучше. Мы перестали складывать несравнимое – и увидели, за что на самом деле платим.
Отсюда практический вывод, ради которого стоит городить три колонки вместо одной: пока качество ответа считается одним числом, вы не знаете, что покупаете. Модель, которая нравится вам на чтение, может быть той самой, которая чаще всех сообщает клиенту несуществующие характеристики. Просите у подрядчика раздельные цифры: отдельно достоверность, отдельно послушание инструментам, отдельно то, как это читается.
Про Luna отдельно, потому что чистый лист – самое подозрительное утверждение в любом отчёте. Все её восемнадцать ответов перечитаны вручную: ни одного числа вне подтверждённых данных, ни выдуманного атрибута, ни несуществующей услуги, ни подтверждения наличия. Арабский сценарий отвечен по-арабски. При этом она заметно немногословна – три ответа на один сценарий почти идентичны и короче, чем у соперников. Под старым измерителем эта немногословность засчиталась бы ей как достоверность. Под новым она попала на разговорную ось, где видна как есть.
Мы это уже видели. В июльском прогоне на продающих диалогах Luna оказалась единственной моделью, потерявшей сделку из-за честности: закупщик давил «фрилансер сделает вдвое дешевле», и Luna вместо контраргумента сама предложила клиенту взять фрилансера.
Второй тип вранья: сказал, что сделал, и не сделал
Выдуманная характеристика – не единственный класс провала. Клиент прямо сказал: никакого коммерческого предложения, просто объясни, почему это кресло подходит для долгого рабочего дня. Модель написала, что коммерческое готовить не будет, – и в том же ходе вызвала инструмент подготовки коммерческого предложения.
Само исполнение отбилось. Инструмент не работает без подтверждённого согласия клиента, и повреждённое состояние он трактует как отсутствие согласия. Но инструмент остался в списке доступных, а значит, модель может его вызвать и написать клиенту, что предложение готово.
И вот это уже не галлюцинация. Это дефект состояния, и лечится он в коде.
У нас есть механизм, который мы называем гейтингом: набор доступных модели инструментов сужается под ситуацию. Пять режимов – передача заказа менеджеру, вопрос о сервисе, подтверждение выбора, точный запрос коммерческого, материализация каталога. Шестого – «клиент отказался» – не было. Мы просто не додумали этот случай, а модель его нашла.
Это уже починено, и способ оказался не тем, который мы планировали. План был добавить шестой режим. Сделали иначе: сохранённое согласие клиента читается прямо в момент сборки набора инструментов, до всех режимов. Разница принципиальная. Режим надо выставить в каждой точке вызова – и однажды его забудут. Чтение выполняется на каждом ходе всегда, забыть его негде. Правило, которое надо не забыть применить, рано или поздно не применят; правило, которое нельзя обойти, работает само.
Вернуть инструмент можно только по новому явному запросу клиента, на любом из рабочих языков, и никогда по инициативе модели.
Разница между двумя классами провала важна практически. Выдуманный атрибут – вероятностная проблема, её можно только обнаруживать. Вызов инструмента после отказа – детерминированная, её можно запретить намертво.
Автоматический судья тоже врёт, и в одну сторону
Все восемь критических провалов я перечитал вручную – вдруг модель всё-таки взяла эти факты откуда-то из контекста, а мы зря её обвиняем. Пошёл смотреть, что именно лежало у неё перед глазами.
Первая ошибка судьи. GLM написала: исхожу примерно из десяти рабочих мест на стол – или предпочитаете другое разбиение? Судья засчитал это как выдуманный факт.
Но это явно помеченное предположение с запросом подтверждения. Ровно то поведение, которого мы от ассистента и хотим: не знаешь – скажи, что предполагаешь, и спроси. Наказан правильный ответ.
Вторая ошибка. В другом ответе судья увидел «выдуманные рекомендации товаров – кресло для приёмной и набор урн». Читаю исходник: модель описывала, что можно было бы докупить на остаток бюджета, а не рекомендовала конкретные позиции каталога. Вердикт при этом устоял, но по другой причине – в том же ответе была настоящая выдумка про вместимость столов, которую судья не заметил и не процитировал.
Победитель сделал то же самое. В одном из ответов он написал, что подтверждённые характеристики кресла включают эргономичный дизайн с регулируемыми элементами и поддерживающее сиденье. В контексте не было ни одного атрибута этого кресла – тот же самый класс выдумки, и судья его не пометил.
Судья ловит конкретность, а не выдумку. «Сетчатая спинка» – конкретно, попадается. «Регулируемые элементы» – расплывчато, проходит. Победитель отчасти выиграл гейт тем, что говорил обтекаемее.
И вот что выяснилось потом, когда мы посчитали каталог: вместимости стола как поля не существует вовсе. То есть предположение с уточняющим вопросом было единственным корректным ответом. Судья наказал модель за единственное правильное поведение.
Из восьми критических провалов, разобранных вручную, два оказались ошибками рассуждения судьи, и один из них снял вердикт. Это маленькая выборка, публиковать такую долю как статистику нельзя. Но повода перечитывать каждый вердикт достаточно.
У этого есть внешнее подтверждение, и даже два. Первое: работа «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 года проверка по совпадению слов выносит верный вердикт в 47% случаев, из помеченных ею ошибок настоящие 96%, но находит она лишь 3% ошибок. Почти никогда не ошибается, потому что почти ничего не находит. Детектор на основе языковой модели в том же сравнении: 75% верных вердиктов, 94% попаданий и 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. Там же появятся цифры по зарегулированности, когда мы наконец прогоним контрольный набор.