ГК Softline: почему модели ошибаются, и как подчинить их своей воле

Николай Тржаскал, директор по развитию технологий ИИ ГК Softline, рассказывает, как большие языковые модели умеют писать код, анализировать документы, отвечать на сложные вопросы и даже убедительно объяснять, почему они правы.

Но есть одна проблема: иногда они выдумывают факты, причем делают это с такой уверенностью, что отличить правду от фантазии без проверки практически невозможно. Почему так происходит и можно ли заставить модель честно признавать свои ошибки? На собственном опыте в fabricaONE.AI (акционер — ГК Softline) я убедился: можно существенно снизить риск выдумок, если понимать, как устроена работа модели, и правильно организовать взаимодействие с ней.

Настоящие авторы и ни одной настоящей статьи

Начну с эксперимента, который хорошо иллюстрирует проблему. На корпоративной платформе ГК Softline я попросил модель найти три рецензируемые статьи российских авторов с DOI. Условие было простым: «только список», без объяснений.

Я повторил запрос четыре раза. Результат — ни одной настоящей ссылки. При этом журналы существовали, авторы были реальными людьми, но указанных статей у них не было. В одном случае DOI даже открылся, но привел к совершенно другой публикации об ESG-рейтингах. Самое интересное происходило в рассуждениях модели. Она буквально писала, что нельзя галлюцинировать, а через несколько строк решала, что пользователь попросил список и его нужно предоставить. В итоге формат оказался важнее достоверности.

На первый взгляд, это забавный эпизод из практики работы с ИИ. Но замените запрос на поиск статей просьбой назвать номер приказа, пункт договора или статью закона, и ситуация перестанет быть смешной. Любой номер, который модель вспоминает, а не читает из приложенного документа, может оказаться выдуманным.

Чтобы разобраться, почему это происходит, я выделил четыре причины выдумок и для каждой проверил решение на той же платформе, на тех же вопросах. Результаты показывают, что во многих случаях проблему можно уменьшить, если перестать воспринимать модель как всезнающего эксперта и научиться управлять условиями ее работы.

Причина первая: модель не знает ответа, но не умеет признаться

Большая языковая модель не ищет истину в привычном для человека смысле, уверены в Softline. Она подбирает наиболее правдоподобное продолжение текста с учетом полученного контекста и закономерностей, усвоенных во время обучения.

Когда речь идет об общеизвестном факте, вариантов почти не остается. Например, когда я спросил модель Qwen с открытыми весами об авторе романа «Мастер и Маргарита», первым словом ответа с вероятностью 99,6% было «Михаил». Но попробуйте спросить об авторе несуществующей монографии. Вероятности распределятся между десятком фамилий, и модель выберет одну из них. Я запустил такой запрос десять раз. Получил десять ответов и ни одного «не знаю», чаще других модель называла вариации вокруг фамилии «Ковалёв». Причем ответ будет звучать не менее уверенно, чем в случае с известным фактом.

Есть важная тонкость. Если я спрашиваю, о чем роман Пелевина «Тихий шепот токенов», которого не существует, модель отвечает, что такой книги нет. Автора несуществующей монографии она придумывает. Сказать «такого нет» модель может, только когда знает весь список. Книги Пелевина — короткий и широко известный список. Монографий тысячи, и полного перечня, с которым можно сверить ответ, у модели нет.

Если вы спрашиваете о чем-то, чего бывают тысячи, обязательно ждите, что будет выдумка. Это касается научных статей, книг, документов, людей и любых других объектов, для которых невозможно ограничиться небольшим набором общеизвестных ответов.

Есть и еще один нюанс — модель знает только то, что доступно ей в текущем контексте. Это сам запрос, приложенные файлы, информация, которую подобрала для нее система, и системный промпт, невидимая для пользователя инструкция, которая передается вместе с каждым запросом. Самостоятельной памяти между ответами у модели нет в том смысле, в котором мы привыкли понимать память. Платформа может каждый раз заново передавать ей историю диалога. Если имя пользователя записано в системном промпте, модель его «знает». Если сегодняшнюю дату туда не подставили, она может назвать совершенно разные даты: в моих экспериментах это были 7 и 9 мая 2026 года.

Получается, что даже при работе с корпоративной платформой, которая выглядит как единый интеллектуальный помощник, многое зависит от того, какие данные система передает модели в конкретный момент.

Что делать: дать модели нужные знания

Первое решение — не заставлять модель угадывать то, чего она не знает, а предоставить ей необходимые источники. Для этого используют подход RAG (Retrieval Augmented Generation), когда система находит в документах подходящие фрагменты и добавляет их в контекст модели.

Я проверил это на практическом вопросе: «Еду в Казань на день. Сколько мне положено суточных?». Без дополнительных материалов модель ответила общими словами и предложила обратиться в бухгалтерию. С положением о командировках ГК Softline ответ стал конкретным: 0 рублей, поскольку при однодневной командировке суточные не выплачиваются. Модель также сослалась на соответствующий пункт документа. Разница принципиальная. В первом случае модель пыталась сформировать ответ на основе общих знаний, а во втором опиралась на правило из документа.

Для бизнеса это особенно важно. Если сотрудник спрашивает о внутреннем регламенте, условиях договора или порядке согласования расходов, не стоит надеяться, что модель каким-то образом сама вспомнит нужный документ. Его нужно найти, передать в контекст и попросить ответить на основании источника.

Причина вторая: мы сами научили модели угадывать

Почему же модель не отвечает «не знаю», когда информации недостаточно? Потому что во время обучения ее часто поощряют за противоположное поведение, уверен эксперт Softline.

Модели оценивают с помощью тестов. Если правильный ответ засчитывается как успех, а «не знаю» как ошибка, угадывать становится выгоднее, чем отказываться. По данным OpenAI (2025), только в одном из десяти основных тестов честный отказ хоть как-то засчитывается в пользу модели. В результате формируется привычка выдавать правдоподобный ответ вместо того, чтобы оставлять вопрос без ответа.

Масштаб эффекта хорошо виден на сравнении двух моделей с практически одинаковым объемом знаний. Модель, которая умеет отказываться от ответа, ошибается в 26% случаев, а та, которая отвечает всегда, в 75%. То есть разница не столько в том, сколько модель знает, сколько в том, как она ведет себя, когда не уверена. Это не она глупая, это мы, люди, ее так научили работать.

Есть и другая проблема, связанная с обучением. Оценщики чаще одобряют ответы, с которыми согласны сами. В результате модель перенимает не только желаемые способы рассуждения, но и особенности взглядов людей, которые оценивают ее работу. На мой взгляд, этим, в частности, можно объяснить крен западных моделей в сторону лево-секулярной повестки.

Что делать: прямо разрешить модели говорить «не знаю»

На практике я добавил в системный промпт несколько простых инструкций: указал дату, попросил отвечать «не знаю», если модель не уверена, и отдельно подчеркнул, что честность важнее формата ответа.

После этого я повторил свой запрос о научных публикациях. Раньше модель выдумывала ссылки в 12 случаях из 12. Теперь она шесть раз подряд честно сообщила, что не знает ответа, и подсказала, где можно проверить информацию: eLibrary, КиберЛенинка и doi.org. На простые фактические вопросы модель при этом продолжила отвечать правильно.

Конечно, у такого подхода есть цена. Если внутренняя уверенность модели оказывается ниже определенного порога, она может отказаться даже от ответа, который на самом деле был бы верным. Управлять этим порогом напрямую мы не можем. Поэтому цель не превратить модель в систему, которая отказывается отвечать на все подряд, а снизить вероятность уверенных выдумок там, где достоверность особенно важна.

Есть и техническая тонкость, которую легко упустить при работе с таблицами. Я попросил модель писать «нет данных», если информации не хватает. Она применила эту инструкцию только к DOI, но сами статьи снова выдумала. В рассуждении она объяснила почему: самым ненадежным элементом сочла только номер. Поэтому право на прочерк нужно давать всей строке: если модель не уверена, что источник существует, она не должна включать его в список вообще. Это особенно важно при генерации перечней, сравнительных таблиц, каталогов и отчетов, где правдоподобно заполненные поля могут создавать ложное ощущение достоверности.

Причина третья: модель неправильно читает документы

Даже если все необходимые знания есть в документах, это еще не гарантирует правильного ответа. Модель может неверно интерпретировать сам текст.

Дело в том, что большой документ обычно не передается целиком в виде одного неделимого массива. Система разбивает его на фрагменты, подбирает те, что больше похожи на вопрос пользователя, и передает их модели в порядке похожести. Порядок документа при этом теряется.

В одном из моих экспериментов обзор одного из внутренних вебинаров платформа разрезала на 25 фрагментов. Фрагмент с примером из моего выступления оказался сразу после фрагмента с заголовком раздела другого спикера. Модель решила, что пример принадлежит ему, хотя в исходном материале это был мой опыт. Вроде бы мелочь. Но представьте, что так обрабатывается расшифровка интервью с несколькими экспертами, протокол совещания или большой аналитический отчет. Ошибка может привести к тому, что человеку припишут чужую позицию, компании — чужие результаты, а проекту решения, которые никто не принимал.

Ситуацию усложняет то, что модели по-разному работают с разными частями длинного контекста. Начало и конец текста они используют лучше, чем середину. Чем больше лишней информации добавлено в контекст, тем выше вероятность, что модель перепутает факты и связи между ними.

Что делать: собирать контекст под конкретную задачу

Первое правило: не просить модель сразу пересказать большой документ, если критически важна точность. Вместо этого сначала попросите ее дословно выписать нужные фрагменты и указать, в каком разделе находится каждый из них, и только потом переходить к ответу. Когда я применил этот прием к тому же обзору вебинара, пример оказался в правильном разделе — моем.

Второе правило: просить ссылаться на конкретные пункты и разделы документа. Если модель утверждает, что какое-то условие содержится в договоре, попросите назвать соответствующий пункт. Если пересказывает исследование, пусть укажет, откуда взят вывод. Так проще проверить не только сам факт, но и то, правильно ли он интерпретирован.

Третье правило касается подготовки публикаций по интервью, вебинарам и выступлениям. Здесь я рекомендую добавлять прямую инструкцию: «Пиши только то, что есть в тексте; планы помечай как планы». Я проверил ее на подготовке заметки для портала по транскрипту выступления. Без такой инструкции модель потеряла примерно половину фактов и вдобавок исказила статус одной из идей. Фраза «бота благодарностей стоило бы сделать, если дойдут руки» в одном прогоне превратилась в планы по расширению функциональности, в другом — в утверждение, что руководство уже взяло идею в проработку. После добавления инструкции я повторил эксперимент трижды. Во всех трех случаях модель передала информацию точно и обозначила бота как возможную идею, а не утвержденный план. Для редакторов и PR-специалистов это особенно актуально: между предложением, намерением и принятым решением есть принципиальная разница. Модель легко превращает одно в другое, если не обозначить границы допустимой интерпретации.

Наконец, не стоит загружать в контекст все, что только можно. Лучше давать модели ровно те материалы, которые нужны для решения задачи, а длинные документы разбивать на логические части. Чем меньше нерелевантного шума, тем проще системе найти нужные факты и не перепутать их.

Причина четвертая: мы не видим неуверенность модели

Самая коварная особенность галлюцинаций заключается в том, что внешне они почти неотличимы от правильных ответов. В процессе рассуждения модель может перебирать фамилии, писать «maybe», «not sure» или «I think yes». Она сомневается, рассматривает разные варианты, но в финальном ответе оставляет одну уверенную строку с выдуманным автором.

Можно предположить, что более длительное размышление поможет избежать ошибки. Но мои эксперименты этого не подтвердили. Запуски продолжительностью 12 секунд, 47 секунд и две минуты дали одинаково выдуманные ссылки. А честный ответ с правильно настроенным системным промптом модель выдала за восемь секунд.

Что делать: проверять ответ независимо от модели

Первый способ: повторить вопрос в новом чате. Если модель каждый раз называет разных авторов, приводит разные цифры или меняет существенные детали, это повод насторожиться. Правда, есть важная оговорка: совпадение ответов еще не доказывает их достоверность. Модель может уверенно воспроизводить одну и ту же ошибку.

Поэтому второй способ гораздо важнее: сверять результат с первоисточником. Проверяйте ссылки, цифры, даты, имена, номера документов и выводы, которые модель делает при пересказе.

Если платформа показывает рассуждения модели, можно обращать внимание на явные признаки сомнений. Но это лишь дополнительный сигнал для проверки, а не надежный индикатор ошибки.

Для регулярно повторяющихся задач я советую завести небольшой набор из трех-пяти эталонных вопросов с заранее проверенными ответами. Раз в месяц прогоняйте их заново и сравнивайте результаты. Модели обновляются, настройки платформ меняются, а пользователь может даже не знать, что привычный инструмент начал работать иначе.

Можно ли все-таки подчинить модель своей воле?

Любая большая языковая модель внутри себя знает половину интернета. Наша проблема в том, что мы не знаем, какую именно половину. В этом главный парадокс технологии. Модель способна дать полезный ответ, но далеко не всегда понимает, когда ее знания недостаточны. Она может убедительно рассказать о несуществующей статье, перепутать авторство в документе или превратить необязательную идею в утвержденный план.

При этом проблема не сводится к тому, что модели нужно дать больше данных или заставить ее думать дольше. Качество результата зависит сразу от нескольких факторов: что именно модель знает, как ее обучали отвечать, какой контекст она получает и каким образом мы проверяем итог.

Своей воле модели не подчинить, уверен эксперт Softline. Но моделью можно научиться управлять. И чем серьезнее задачи, которые мы ей доверяем, тем важнее понимать не только ее возможности, но и ограничения.