Языковая модель выдумывает не потому, что сломалась, а потому, что именно это она и делает всегда. Она подбирает наиболее уместное продолжение текста по вероятностям, а не проверяет утверждения по справочнику. Пока нужный факт лежит в переданном ей контексте, «уместное» и «верное» совпадают, и получается аккуратный пересказ документа. Как только факта в контексте нет, совпадение исчезает, а работа продолжается: модель достраивает фразу тем же ровным тоном, потому что другого режима у неё нет.
Отсюда единственное неприятное свойство, ради которого стоит читать дальше: результат этих двух режимов на выходе неразличим. Ни клиент, ни опытный сотрудник не отличит пересказ от выдумки по формулировке — только сверкой с документом. Разбор конкретных сбоев и их цены мы делали в опорном материале раздела о том, почему ИИ-агент врёт клиентам; здесь речь о механике: что именно происходит внутри и какие пять ситуаций дают почти все выдуманные ответы в реальных проектах.
Числовые примеры ниже — модельный разбор журнала агента поддержки с потоком около 6 000 обращений в месяц и базой знаний из 150 страниц регламентов и прайсов. Это тот же сквозной пример, что и в остальных материалах раздела. Доли по провокаторам — не измеренная константа рынка, а порядок величины, который мы регулярно видим при разборе чужих журналов; на своих данных они будут другими, и считать их надо по своему журналу.
Что модель делает на самом деле
Полезно один раз отказаться от метафор про «понимание» и «сознание модели» — они мешают принимать инженерные решения. Механика проще и скучнее. На вход подаётся длинный текст: инструкция, найденные фрагменты ваших документов, история диалога и сообщение клиента. Дальше модель шаг за шагом выбирает следующий кусочек текста, оценивая, насколько он уместен после всего написанного выше. Так собирается фраза, потом абзац, потом весь ответ.
Модель оценивает не «правда ли это», а «насколько такой текст типичен после такого текста». Фраза «согласно пункту 4.7 регламента возврата» типична для делового ответа и получает высокую оценку независимо от того, существует ли пункт 4.7. Проверки существования внутри механизма нет — она может быть только снаружи, в системе вокруг модели.
Из этого следует первое практическое наблюдение. Уверенный тон не является признаком знания: он является свойством жанра. Модель обучена на текстах, где справочные ответы пишутся утвердительно, поэтому она пишет утвердительно всегда — и когда пересказывает ваш регламент, и когда достраивает его продолжение. Требовать от неё «писать возможно там, где не уверена» бессмысленно: это требование к содержанию, а исполняется оно как требование к стилю. На практике агент начинает писать «возможно» равномерно везде, включая правильные ответы, и различать становится ещё труднее.
Второе наблюдение касается внутренней оценки уверенности. Числа такие у модели есть, но они отражают вероятность конкретной последовательности слов, а не истинность утверждения. Выдуманный пункт с типичной формулировкой может получить оценку выше, чем настоящий пункт с корявой бюрократической фразой из вашего регламента. Поэтому порог по внутренней уверенности работает как грубый фильтр совсем уж бессвязных ответов и не работает как детектор выдумки. Единственный надёжный порог — внешний: есть найденный фрагмент документа или нет.
Схема в две зоны. Сверху три прямоугольника с подписью «Найденные фрагменты документов»: «Регламент возврата, п. 4.3», «Условия отгрузки, ред. 05.2026», «Прайс, лист 2». Снизу горизонтальная лента ответа, разбитая на четыре фразы-блока. От первой, второй и четвёртой фразы вверх идут сплошные стрелки к конкретным фрагментам. От третьей фразы стрелка уходит вверх и обрывается пунктиром, рядом подпись «опоры нет». Под лентой ремарка: «Нажим и тон у всех четырёх фраз одинаковые».
Пять провокаторов: где именно рвётся опора
Выдумки распределены по потоку не равномерно. Они собираются в пяти узнаваемых ситуациях, и это хорошая новость: пять ситуаций можно разобрать по журналу, посчитать и закрыть по отдельности. Ниже — те самые пять, с модельными долями на потоке 6 000 обращений в месяц.
| Провокатор | Как выглядит вопрос | Что происходит внутри | Доля потока | Чем закрывается |
|---|---|---|---|---|
| Вопроса нет в базе | «Есть ли у вас рассрочка на 12 месяцев?» — про рассрочку в документах ни слова | Поиск возвращает пустоту или посторонние фрагменты, но формат ответа требует ответа, и он достраивается целиком | 12 % — 720 диалогов | Запрет отвечать при пустом результате поиска |
| Ответ на стыке двух документов | «Хочу вернуть товар, купленный по акции» | Поиск честно нашёл фрагмент про возврат и фрагмент про акции. Их сочетания нет ни в одном документе, и модель выводит его сама | 4 % — 240 диалогов | Правило не соединять условия из разных документов без явного пункта |
| Документ устарел | «Какая у вас минимальная партия?» | Поиск нашёл верный фрагмент, ответ ему точно соответствует. Фрагмент — из февральской редакции, майскую в базу не загрузили | 3 % — 180 диалогов | Регламент актуализации: владелец, дата пересмотра, отметка «старше 90 дней» |
| Ложная посылка в вопросе | «Почему доставка в Казань идёт неделю?» — по данным системы идёт три дня | Посылка клиента принимается как факт и объясняется. Модель не проверяет её, потому что проверять не умеет | 2 % — 120 диалогов | Проверка фактов вопроса по данным системы до генерации ответа |
| Слишком длинный контекст | Диалог на тридцать реплик с уточнениями и вложениями | Инструкция и найденные фрагменты растворяются среди истории переписки, их вес падает, ответ всё больше опирается на разговор | 3 % — 180 диалогов | Ограничение длины, пересборка контекста, повторная подстановка правил |
В сумме это 1 440 диалогов из 6 000 — 24 % потока попадает в зону риска. Формулировка важна: это не 24 % ошибок, а 24 % обращений, где опора у ответа может отсутствовать. В большинстве этих диалогов агент всё равно ответит правильно, потому что вопрос простой или потому что сработал ограничитель. Но именно здесь живут все выдуманные ответы, и именно эти пять корзин имеет смысл разбирать в первую очередь при любом разборе качества.
Устаревший документ и длинный диалог дают сбои, которые формально не являются галлюцинациями: в первом случае агент честно процитировал документ, во втором — честно опирался на историю разговора. При разборе их регулярно записывают в «бот врёт» и требуют от подрядчика заменить модель. Замена модели не изменит ничего: майскую редакцию прайса она тоже не увидит, если её нет в базе.
Горизонтальная столбчатая диаграмма из пяти полос, ось в диалогах от 0 до 800. Полосы сверху вниз: «Вопроса нет в базе — 720 (12 %)», «Стык двух документов — 240 (4 %)», «Документ устарел — 180 (3 %)», «Длинный контекст — 180 (3 %)», «Ложная посылка в вопросе — 120 (2 %)». Справа общий итог в рамке: «Зона риска — 1 440 из 6 000, 24 % потока». Под диаграммой примечание: «модельный разбор журнала, на ваших данных доли будут другими».
Почему поиск по базе снижает выдумки, но не убирает
Подключение поиска по вашим документам — самое результативное действие из всех возможных, и его эффект хорошо виден на разбивке выше. Первый провокатор — 720 диалогов, ровно половина зоны риска — закрывается им полностью, но не самим поиском, а сопровождающим запретом: если релевантных фрагментов не нашлось, ответа быть не должно вообще. Мы разбирали эту конструкцию подробно как первый из трёх контуров защиты; здесь важно её ограничение.
Ограничение простое: запрет срабатывает по факту пустого результата, а в остальных четырёх провокаторах результат не пустой. На стыке двух документов поиск вернул два фрагмента и уверен, что справился. При устаревшем документе он вернул один точный фрагмент. При ложной посылке он вернул фрагмент про сроки доставки, и тот даже правильный — неверна посылка вопроса, а не документ. В длинном диалоге фрагменты найдены, просто их вес в контексте упал. Во всех четырёх случаях контур честно считает, что опора есть, и не вмешивается.
Остальные три провокатора закрываются дополнительными правилами, но не полностью. Правило «не соединять условия из разных документов, если их сочетания нет в явном виде» снимает примерно половину случаев на стыке, остальные требуют пункта в регламенте, которого у вас пока нет. Проверка посылки вопроса по данным системы снимает половину ложных посылок — те, где посылку вообще можно проверить программно. Ограничение длины и пересборка контекста снимают две трети случаев с длинными диалогами. Устаревший документ не закрывается вообще ничем на стороне подрядчика: это ваш процесс актуализации, и подробно порядок его ведения мы разбирали в материале про обновление базы знаний бота.
Из 420 оставшихся диалогов ошибочными окажутся далеко не все — по нашим замерам на выборках критические ошибки держатся в пределах 0–2 %, а неточности без последствий в пределах 4–8 %. Но принципиально важно другое: эти 420 диалогов невозможно поймать в момент ответа. Система в них уверена, все её проверки пройдены, ограничители молчат. Ловить их можно только постфактум, и это ровно та причина, по которой журнал и выборочная проверка не являются необязательной надстройкой.
Воронка из четырёх ступеней сверху вниз с подписанными числами: «Поток обращений — 6 000», «Зона риска пяти провокаторов — 1 440 (24 %)», «После первого контура — 720», «После трёх дополнительных правил — 420 (7 %)». Справа от второй и третьей ступени вынесены отсечённые объёмы: «−720 закрывает запрет отвечать при пустом поиске» и «−300 закрывают правила про стык, посылку и длину». У нижней ступени пометка: «ловится только журналом и выборочным контролем».
Галлюцинация или промах поиска: два поля журнала
Практическая задача при разборе спорного ответа звучит так: чинить контур, чинить базу или чинить процесс актуализации. Три разных ремонта, три разных исполнителя, разные счета. Различить их можно за минуту, если в журнале есть два поля, и нельзя вообще, если их нет.
| Поле журнала | Что в нём видно | Диагноз | Кто чинит |
|---|---|---|---|
| Найденные фрагменты — пусто | Поиск не вернул ничего, а ответ всё равно отправлен | Галлюцинация при отключённом запрете: дефект первого контура | Подрядчик, за свой счёт |
| Найденные фрагменты — посторонние | Поиск вернул документы не по теме, оценки релевантности низкие | Промах поиска: разные слова у клиента и в документе, плохая нарезка фрагментов | Подрядчик вместе с методистом, 12–30 часов |
| Фрагмент верный, фраза ответа в нём есть | Ответ дословно следует из фрагмента, но фрагмент из старой редакции | Устаревший документ: процесс актуализации на вашей стороне | Владелец документа у заказчика |
| Фрагмент верный, фразы ответа в нём нет | Опора формально есть, но ключевое утверждение из неё не следует | Достраивание поверх найденного: стык документов или длинный контекст | Подрядчик, правило про стык и ограничение длины |
Второе поле — то, ради которого стоит настаивать на журнале отдельным пунктом договора. Проверка «есть ли ключевая фраза ответа в найденных фрагментах» отделяет последнюю строку от третьей, а это два принципиально разных разговора с подрядчиком. Без неё спор превращается в обмен мнениями, где заказчик говорит «бот выдумывает», а подрядчик отвечает «у вас документы старые», и оба отчасти правы.
В расчёте намеренно не учтено главное: без журнала примерно в половине случаев причина так и не определяется, и ремонт делается наугад. Наугад чаще всего чинят модель — как самое заметное место системы, — а причина остаётся в базе знаний или в процессе актуализации. Через месяц тот же сбой возвращается, и его разбирают заново, уже с ощущением, что «ИИ не работает».
Ссылка на источник: что она даёт на самом деле
Практический ответ на всю механику выше — одна строчка в конце ответа: документ, редакция, пункт. Она выглядит мелочью и решает сразу три задачи, из которых только первая очевидна.
- 1Оператор получает возможность проверить ответ за десять секунд вместо десяти минут. Без ссылки проверка означает поиск по всем документам компании, и на практике её просто не делают.
- 2Клиент получает основание доверять или спорить предметно. Спор «ваш бот сказал» превращается в спор «в пункте 4.3 написано так», а это разговор про документ, а не про ответственность компании за реплику в чате.
- 3Правки становятся дешёвыми и локальными. Неверный факт правится в одном документе, а не в двадцати ветках сценария и не в промпте, изменение которого задевает все ответы сразу. Границу между тем, что живёт в тексте инструкции, а что в базе знаний, мы разбирали в материале про системный промпт и код.
Есть и распространённая имитация, о которой стоит знать. Модель генерирует ответ свободно, а ссылку ей подставляют отдельно — ближайшим документом по теме. Внешне это неотличимо от настоящего контура. Проверяется одним действием: откройте документ по ссылке и найдите в нём фразу, на которой построен ответ. Если фразы там нет, ссылка декоративная, и вся конструкция выше не работает.
Что бесполезно
Две меры выглядят логичными и не дают результата. Обе стоят денег и, что хуже, создают ощущение решённой задачи.
- Просьба «не выдумывай» внутри промпта. Это текст, который модель взвешивает наравне с сообщением клиента. Он снижает частоту выдумок и не убирает их: при пустом результате поиска модель всё равно достроит ответ, потому что задача «ответить» никуда не делась. Подробный разбор того, почему запрет в тексте не является запретом, — в соседнем материале раздела о том, почему правила безопасности нельзя записывать в промпт.
- Собственная оценка уверенности модели. Просьба «оцени по шкале, насколько ты уверен» даёт число, которое хорошо звучит в отчёте и слабо связано с правильностью. Модель оценивает связность своего текста, а не соответствие вашему регламенту, поэтому уверенные выдумки получают высокие оценки, а корявые правильные ответы — низкие.
- Вторая модель в роли проверяющей — без источника. Проверяющая модель работает по тому же принципу и оценивает правдоподобие. На складно сформулированной выдумке она поставит галочку. Полезна она в одном сценарии: когда ей дают тот же найденный фрагмент и спрашивают, следует ли утверждение из фрагмента. Это уже обычная сверка с источником, и без источника её нет.
- Более сильная модель. Она реже ошибается на сложных формулировках, но механизм остаётся тем же, а два провокатора из пяти — устаревший документ и ложная посылка — к силе модели вообще не относятся. Сумма денег, потраченная на переезд, чаще всего должна была уйти в базу знаний.
Сравнение в две колонки одинаковой ширины. Левая с заголовком «Не работает»: четыре строки — «просьба «не выдумывай» в промпте», «собственная оценка уверенности модели», «вторая модель без источника», «модель посильнее». Правая с заголовком «Работает»: четыре строки — «запрет отвечать при пустом поиске», «ссылка на документ и редакцию», «регламент актуализации документов», «журнал с найденными фрагментами». Внизу под колонками общая подпись: «Слева меняют модель, справа меняют систему вокруг неё».
Модель не различает пересказ и достраивание — для неё это одна операция. Различать обязана система вокруг неё, и различает она по одному признаку: есть найденный фрагмент или нет.
Когда разбираться в механике не нужно
Есть три ситуации, где всё написанное выше — избыточная сложность, и честнее сказать об этом до того, как компания начнёт строить контуры.
- Ответы берутся из справочника фиксированными шаблонами, а модель вообще не генерирует свободный текст. График работы, адрес, реквизиты, порядок самовывоза — здесь нужен точный поиск и дословный ответ. Выдумывать нечему, и вся конструкция с фрагментами и ссылками вырождается в обычный справочник.
- Результат работы всегда проверяет человек перед отправкой или подтверждением. Классификация документов, извлечение полей, черновик письма, который отправляет сотрудник, — в таких сценариях цена ошибки резко ниже, потому что ошибка ловится на следующем шаге. Журнал и выборочная проверка нужны, полный набор ограничителей — нет.
- Поток меньше 500–800 обращений в месяц. При таком объёме контуры и ежемесячный контроль не окупаются ни при каких ставках: дешевле собрать шаблоны ответов и взять человека на неполный день. Порог, с которого клиентский агент начинает окупаться, — примерно 2 000 обращений в месяц. Как считать этот порог на своих числах, разобрано в материале про замер качества ИИ на своих данных.
И отдельно — про случай, когда механика нужна, но объяснять её команде бесполезно. Если после разбора сотрудники начинают перепроверять каждый ответ агента вручную, вы получили худший из миров: расходы на автоматизацию и полную ручную нагрузку сверху. Правильный вывод из этой статьи для команды формулируется одной фразой: проверять надо не ответы, а наличие ссылки на источник. Всё остальное делают контуры и выборочный контроль.
