Языковая модель уверенно называет несуществующий пункт договора, придумывает номер приказа или сочиняет условие возврата, которого у вас нет. Это не сбой и не признак плохой модели — это следствие того, как она устроена. Разберём, откуда берётся выдумывание, почему его нельзя убрать полностью и что реально снижает его долю до приемлемой.
Почему это происходит
Языковая модель не хранит факты в виде справочника и не проверяет их. Она предсказывает продолжение текста, выбирая наиболее правдоподобное. Правдоподобие и истинность — разные вещи, и там, где модель не знает ответа, она всё равно выдаёт нечто похожее на ответ, потому что именно этому её и учили.
Отсюда неприятное свойство: модель не различает «знаю» и «не знаю». Выдуманный ответ подаётся с той же уверенностью, что и верный. Именно это делает проблему опасной — не сама ошибка, а невозможность отличить её по тону.
Пять причин, по которым модель начинает выдумывать
В контексте нет ответа
Самая частая причина в корпоративных системах. Поиск не нашёл нужный фрагмент, но модель всё равно обязана что-то ответить — и составляет ответ из того, что нашлось, плюс общих знаний. Формально она сделала свою работу.
Вопрос сформулирован с ложной предпосылкой
«Какой срок гарантии по пункту 7.3» — если пункта 7.3 не существует, модель склонна принять его существование как данность и придумать содержание. Она не оспаривает вопрос, она на него отвечает.
Знания устарели
Модель обучалась на данных до определённой даты и не знает об этом. О недавних изменениях она уверенно расскажет неверно, потому что для неё они не существуют.
Задача требует точности, а не правдоподобия
Числа, даты, номера, имена — здесь модель ошибается чаще всего. Правдоподобный номер приказа выглядит как настоящий, и именно поэтому такая ошибка проходит проверку глазами.
Инструкция подталкивает к ответу любой ценой
Если в инструкции сказано «дай развёрнутый ответ» и ничего не сказано про «не знаю», модель выберет развёрнутый ответ. Она следует инструкции буквально.
Что реально работает
Отвечать только по найденным документам
Самая действенная мера. Модель получает фрагменты ваших документов и инструкцию отвечать строго по ним. Это радикально сокращает пространство для выдумывания: у неё есть источник, и она работает с ним, а не с памятью.
Требовать ссылку на источник
Ответ без указания фрагмента считается недействительным. Это не только даёт проверяемость, но и меняет поведение модели: необходимость сослаться дисциплинирует. В нашем проекте поиска по корпоративной базе каждый ответ сопровождается первоисточником — юрист проверяет ссылку за секунды вместо того, чтобы искать самому.
Разрешить не знать
Явно прописать в инструкции: если в предоставленных фрагментах ответа нет, корректный ответ — «не нашёл». Это звучит тривиально, но пропускается почти всегда, а эффект даёт заметный. Молчание дешевле уверенной ошибки, и модель надо этому научить.
Проверять ответ отдельным шагом
Второй запрос: «содержится ли это утверждение в приведённом фрагменте». Удваивает стоимость, но ловит существенную часть выдуманного. Для ответственных сценариев — оправданно; для справочного бота — избыточно.
Валидировать то, что проверяемо
Номера, даты, суммы, артикулы, ссылки на пункты можно проверить программно: существует ли такой пункт, есть ли такой артикул в справочнике. Всё, что поддаётся формальной проверке, должно проверяться кодом, а не глазами.
Порядок внедрения по соотношению эффекта и затрат: сначала ответы строго по документам, потом обязательная ссылка на источник, потом явное разрешение не знать, потом валидация проверяемых полей. Отдельная проверка вторым запросом — последняя, она самая дорогая.
Чего делать не стоит
- Надеяться, что более сильная модель решит проблему. Она снижает долю выдуманного, но не устраняет его — и повышает убедительность оставшихся ошибок.
- Писать в инструкции «не выдумывай». Как единственная мера это не работает: модель не знает, что выдумывает.
- Дообучать модель на своих документах ради точности фактов. Дообучение передаёт форму, а не факты, и заодно лишает вас возможности проверить источник.
- Считать задачу решённой после ручной проверки десятка ответов. Выдумывание проявляется на редких и неудобных запросах, а не на типовых.
Как измерить, стало ли лучше
- Соберите набор реальных вопросов с эталонными ответами от ваших специалистов — от полусотни.
- Обязательно включите вопросы, ответа на которые в документах нет. Правильный ответ на них — «не нашёл», и именно на них система чаще всего проваливается.
- Добавьте вопросы с ложной предпосылкой: ссылка на несуществующий пункт, вымышленный продукт. Модель должна возразить, а не подыграть.
- Считайте две метрики отдельно: долю верных ответов и долю выдуманных. Вторая важнее — один уверенно выдуманный ответ обходится дороже десяти «не знаю».
- Перемеряйте после каждого изменения промпта или модели. Улучшение одного часто ухудшает другое.
Реалистичные ожидания
Полностью устранить выдумывание нельзя — это свойство технологии, а не дефект реализации. Задача проектирования в другом: сделать так, чтобы цена оставшихся ошибок была приемлемой. Для справочного ассистента редкая ошибка терпима. Для системы, где ответ идёт клиенту без проверки, — нет, и там нужен человек в контуре.
Это ровно тот вопрос, который стоит задать себе до начала проекта: что произойдёт, когда система ошибётся. Если внятного ответа нет, дело не в модели — не додуман процесс.
Разные виды выдумывания требуют разных мер
Полезно различать типы ошибок: меры против них принципиально разные, и попытка лечить всё одним приёмом не работает.
Выдуманный факт
Модель называет несуществующий пункт, номер или условие. Лечится ответами строго по документам и обязательной ссылкой на источник. Самый распространённый и, к счастью, самый управляемый тип.
Неверная деталь в верном ответе
Опаснее предыдущего: ответ в целом правильный, но дата сдвинута на год или сумма округлена. Проверяющий читает ответ, узнаёт содержание и не замечает подмены в цифре. Лечится программной проверкой всех числовых значений против источника, а не вычиткой.
Правдоподобное обобщение
Модель делает вывод, которого в документах нет, но который выглядит логичным следствием. Формально это не выдумка, фактически — утверждение без основания. Лечится инструкцией отвечать только тем, что прямо сказано, и не делать выводов.
Ответ на несуществующий вопрос
Пользователь спрашивает про пункт, которого нет, и модель придумывает его содержание вместо возражения. Лечится явной инструкцией проверять предпосылку вопроса и набором тестов с ложными предпосылками.
Как это выглядит в разных сценариях
Допустимый уровень риска зависит от того, что происходит с ответом дальше. Полезно рассортировать сценарии по этому признаку — тогда становится понятно, куда вкладывать усилия.
- Ответ читает специалист и проверяет по ссылке. Риск низкий: ошибка будет замечена. Здесь достаточно базовых мер, а перегружать систему проверками нет смысла.
- Ответ читает сотрудник и действует по нему без проверки. Риск средний. Нужны валидация проверяемых полей и явные отказы при неуверенности.
- Ответ уходит клиенту без участия человека. Риск высокий. Нужен либо жёсткий контроль формата с шаблонами на ответственные формулировки, либо человек в контуре.
- На основании ответа выполняется действие в системе. Риск максимальный. Здесь ответ модели вообще не должен быть единственным основанием — нужны подтверждение и обратимость.
Практическое правило: чем дальше ответ от глаз специалиста, тем жёстче должны быть ограничения. Для клиентских сценариев мы обычно фиксируем ответственные формулировки — условия возврата, гарантии, сроки — шаблонами, а модели оставляем подбор нужного шаблона и связный текст вокруг него.
Что говорить пользователям
Отдельная и недооценённая часть работы. Доверие к системе определяется не только её точностью, но и тем, какие ожидания вы сформировали.
- Ассистент должен представляться. Попытка выдать его за человека всегда раскрывается и запоминается хуже, чем сам факт общения с ботом.
- Рядом с ответом должна быть ссылка на источник — не как техническая деталь, а как приглашение проверить.
- Формулировка «проверьте по первоисточнику для ответственных решений» уместна и не снижает ценность инструмента.
- Нужен простой способ сообщить об ошибке. Это и канал доверия, и источник данных для улучшения.
Система, которая честно говорит «не нашёл», воспринимается как надёжная. Система, которая уверенно ошибается пару раз, теряет доверие целиком — и вернуть его сложнее, чем заработать изначально.
Порядок работы над качеством
- Соберите набор реальных вопросов, включая те, ответа на которые нет, и те, что содержат ложные предпосылки.
- Замерьте базовый уровень: доля верных, доля выдуманных, доля корректных отказов.
- Введите ответы строго по документам с обязательной ссылкой — самая результативная мера.
- Разрешите модели не знать, явной инструкцией. Перемеряйте: доля отказов вырастет, доля выдуманного упадёт.
- Добавьте программную валидацию всего проверяемого: номера, даты, суммы, существование пунктов.
- Только если этого мало — вводите проверку ответа вторым запросом. Она удваивает стоимость и нужна не всегда.
Почему проблема не решается сама с ростом моделей
Распространённое ожидание: следующее поколение моделей будет ошибаться реже, и вопрос закроется. Отчасти это верно — доля выдуманного действительно снижается. Но есть два обстоятельства, из-за которых проблема остаётся.
Первое: снижение частоты ошибок повышает их цену. Когда система ошибается часто, люди проверяют. Когда она ошибается редко, проверять перестают — и редкая ошибка проходит насквозь. С точки зрения процесса это может быть хуже, чем частые заметные ошибки.
Второе: модель не может знать того, чего нет в её данных. Ваши внутренние регламенты, номера договоров, условия конкретной сделки — этого не будет ни в одной модели, какой бы большой она ни была. Единственный способ дать ей эту информацию — передать её в момент запроса, то есть построить поиск по вашим документам. Никакой рост качества моделей эту задачу не отменяет.
Практический вывод простой: архитектуру стоит строить так, чтобы она не зависела от того, насколько хороша модель. Ответы по документам, обязательная ссылка на источник и программная валидация работают одинаково и с сегодняшней моделью, и со следующей. А вот решение, которое держится на том, что «модель достаточно умная», сломается при первой же её замене.
Коротко
- Модель предсказывает правдоподобное продолжение, а не проверяет истинность, — выдумывание встроено в технологию.
- Опаснее всего то, что неверный ответ подаётся с той же уверенностью, что и верный.
- Работают: ответы строго по документам, обязательная ссылка на источник, явное разрешение не знать, программная валидация проверяемых полей.
- Не работает: инструкция «не выдумывай» сама по себе и надежда на более сильную модель.
- Измеряйте долю выдуманного отдельно от доли верного и обязательно включайте вопросы без ответа в документах.