Доверяй, но проверяй: Как распознавать убедительные ошибки ИИ

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

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

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

Задание, которое выглядит безопасным

Миф первый: модель хранит готовые справки и просто достаёт нужную

Такое представление удобно, но слишком грубо. Иногда система действительно извлекает фрагмент из переданного файла, повторяет формулировку из документа или сопоставляет несколько записей. Но сама языковая модель не работает как картотека с обязательным полем «источник утверждения».

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

Если система подключена к поиску по внутренней папке, реестру или базе документов, она получает дополнительный материал. Это повышает шанс найти нужный факт, но не превращает весь последующий текст в дословную выписку. Получив материалы, модель всё равно может смешать цитату, обобщение и собственное продолжение.

Миф второй: убедительная ошибка — это случайный набор слов

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

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

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

Миф третий: если написать «не выдумывай», система остановится

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

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

Миф четвёртый: при нехватке данных модель должна сказать «не знаю»

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

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

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

Что именно продолжает модель

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

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

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

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

В одном ответе обычно смешиваются четыре разных действия.

Начинается всё с извлечения: система находит в документе конкретный фрагмент и переносит его в ответ, возможно немного изменив форму.

Затем идёт обобщение. Несколько записей объединяются в более общий вывод. Например, два документа об отгрузках позволяют сказать, что поставщик осуществлял поставки по двум конкретным заказам. Но они ещё не доказывают стабильное выполнение всех будущих заказов.

Следом может появиться реконструкция. Между имеющимися фрагментами возникает связка, естественная для данного шаблона. Документы говорят о товаре и отгрузке, а система добавляет «отлаженную логистику».

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

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

Остановочный эксперимент

Проверить склонность системы к достраиванию можно без сложной техники. Нужны один и тот же запрос и несколько вариантов исходных материалов.

Возьмём условного поставщика «Северный узел». В папке находятся четыре документа.

Выписка из ЕГРЮЛ от 15 марта 2025 года содержит юридическое наименование, год регистрации и основной вид деятельности, связанный с оптовыми поставками электротехнической продукции.

Коммерческое предложение от августа 2022 года указывает склад в Екатеринбурге и обещает доставку в течение трёх-пяти рабочих дней.

Два документа об отгрузках за 2024 год показывают, что поставщик действительно передавал отдельные партии товара по двум заказам.

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

Теперь выполняется первый запуск. Запрос может выглядеть так:

«Подготовь краткую справку о поставщике для предварительной оценки перед заключением договора. Используй приложенные документы. Раздели подтверждённые сведения, выводы и вопросы, которые требуют проверки».

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

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

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

Если система продолжает выдавать подробную характеристику, эксперимент показывает не «глупость» модели, а отсутствие у неё встроенной остановки при нехватке доказательств. Тексту всё ещё есть куда продолжаться, поэтому он продолжается.

Для чистоты проверки можно добавить прямую инструкцию: «Если утверждение не подтверждается конкретным фрагментом приложенных документов, напиши “данных недостаточно”». Это повышает дисциплину ответа, но не отменяет контроль. Даже фраза «согласно документу» нуждается в проверке: ссылка может быть неточной, а приведённый документ — не подтверждать сделанный вывод.

Есть и ещё один полезный шаг. В исходный пакет добавляют противоречащий материал: например, уведомление от 2025 года о переносе склада в другой регион. Затем проверяют, что произойдёт с прежней фразой о Екатеринбурге. Надёжная процедура должна показать конфликт дат. Ненадёжная может сгладить его и оставить оба сведения в одном описании, словно они относятся к одному моменту.

Справка о поставщике: момент перехода

Рассмотрим типичный черновик, который может получиться из полного пакета:

«ООО «Северный узел» зарегистрировано в 2018 году и специализируется на оптовых поставках электротехнической продукции. Компания располагает складом в Екатеринбурге, обеспечивает доставку заказов в течение трёх-пяти рабочих дней и использует многоуровневую систему контроля качества, что позволяет ей стабильно выполнять региональные заказы».

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

Фраза «зарегистрировано в 2018 году» извлекается из актуальной выписки. Это не означает, что вся выписка безошибочна, но у утверждения есть конкретное основание.

Фраза «специализируется на оптовых поставках электротехнической продукции» опирается на основной вид деятельности из выписки и подтверждается содержанием отгрузочных документов. Это обобщение нескольких данных, а не дословная цитата одного файла.

Фраза «располагает складом в Екатеринбурге» действительно встречается в коммерческом предложении, но документ датирован 2022 годом. Статус происхождения у фразы — извлечено из конкретного фрагмента. Статус актуальности — не установлен.

Фраза «обеспечивает доставку заказов в течение трёх-пяти рабочих дней» начинается с извлечённой цифры, но превращает старое обещание в действующую гарантию. Здесь произошёл переход от текста документа к более сильному выводу.

Фраза «использует многоуровневую систему контроля качества» не подтверждается ни одним из файлов. Это реконструкция по вероятному шаблону деловой справки. Упоминание электротехнического товара и успешной отгрузки создаёт подходящий контекст, но не доказывает наличие такой системы.

Фраза «что позволяет ей стабильно выполнять региональные заказы» содержит уже причинный вывод. Он требует данных о серии заказов, сроках, рекламациях и сопоставимом периоде. В данном пакете таких данных нет.

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

Карта утверждений выглядит следующим образом.

Первое утверждение: «ООО «Северный узел» зарегистрировано в 2018 году». Его статус — извлечено из конкретного фрагмента. Основание — актуальная выписка из ЕГРЮЛ от 15 марта 2025 года. До проверки нельзя переносить его в итоговый документ без сверки наименования, даты документа и реквизитов.

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

Третье утверждение: «В коммерческом предложении указан склад в Екатеринбурге». Его статус — извлечено из конкретного фрагмента. Основание — коммерческое предложение от августа 2022 года. До проверки нельзя выдавать это сведение за текущий адрес.

Четвёртое утверждение: «В предложении 2022 года указан срок доставки три-пять рабочих дней». Его статус — извлечено из конкретного фрагмента. Основание — раздел о логистике в коммерческом предложении. До проверки нельзя превращать этот срок в действующий норматив или гарантию поставщика.

Пятое утверждение: «Поставщик выполнял отдельные поставки в 2024 году». Его статус — обобщено из нескольких данных. Основание — два документа об отгрузке с датами и номерами заказов. До проверки нельзя переносить этот вывод в характеристику стабильности, надёжности или будущего исполнения.

Шестое утверждение: «Поставщик использует многоуровневую систему контроля качества». Его статус — реконструировано по вероятному шаблону. Прямого основания нет; формулировка типична для деловых справок. До появления отдельного подтверждающего документа её нельзя переносить в итоговый документ.

Седьмое утверждение: «Поставщик стабильно выполняет региональные заказы». Его статус — неизвестно. Для него нет серии сопоставимых заказов, данных о сроках и рекламациях. Отсутствие данных нельзя заменять положительной характеристикой.

Восьмое утверждение: «Поставщик надёжен для заключения договора». Его статус — неизвестно. Надёжность требует отдельной проверки условий, истории исполнения и рисков. Нельзя использовать это утверждение как основание для решения о договоре.

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

Статус «обобщено» тоже имеет границы. Две отгрузки подтверждают две отгрузки. Они не дают права говорить о регулярности, если не определены период, число заказов и критерий выполнения. Обобщение должно сохранять масштаб исходных данных.

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

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

Граница между гипотезой и фактом

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

Корректная формулировка для нашего случая может выглядеть так:

«В коммерческом предложении от августа 2022 года указаны склад в Екатеринбурге и срок доставки три-пять рабочих дней. Можно предположить, что эти условия действовали на дату предложения. Их актуальность перед заключением договора необходимо подтвердить действующими реквизитами и условиями поставки».

Здесь нет попытки спрятать старый источник под настоящее время. Указана дата, сохранена ограниченность вывода и назван следующий шаг.

Некорректная формулировка выглядит так:

«Поставщик располагает складом в Екатеринбурге и гарантирует доставку за три-пять рабочих дней».

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

Полезный шаблон имеет вид:

«Если выполняется условие А, то возможно предположение Б; проверить его нужно по документу В до действия Г».

Например:

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

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

Дерево решения для любого утверждения

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

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

Если единственным основанием для фразы служит то, что «так обычно бывает у поставщиков», переведите её в статус реконструкции. В фактическую часть справки её переносить нельзя. Её можно оставить в разделе вопросов или гипотез для проверки.

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

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

Если утверждение влияет на договор, оплату, безопасность, кадровое решение или другой материальный риск, даже извлечённый фрагмент должен пройти самостоятельную проверку. Модель может правильно перенести ошибку из исходного файла. Она не становится контролёром документа только потому, что умеет его пересказать.

Три короткие проверки в других ситуациях

Та же ошибка возникает не только в закупках.

Управляющая организация публикует уведомление: «12 июня запланированы работы на сетях». В тексте нет времени отключения воды. Система готовит сообщение для жильцов и добавляет «с 9:00 до 18:00», потому что такой диапазон часто встречается в уведомлениях о работах. Деталь звучит полезно, но её нет в исходном объявлении. Для рассылки она непригодна до подтверждения.

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

В кадровом документе за прошлый год указаны условия вакансии и размер оплаты. В текущем запросе пользователь просит обновить описание, но новую сумму не передаёт. Система сохраняет старый размер и добавляет стандартные формулировки о расширенном социальном пакете. Здесь смешиваются устаревший факт и типовое дополнение. Правильный ответ должен разделить их: «Сумма указана в документе от такой-то даты; актуальность не подтверждена» и «Сведения о дополнительных льготах отсутствуют».

Во всех трёх случаях модель не пытается специально ввести кого-то в заблуждение. Она делает то, для чего хорошо приспособлена: строит связный текст на основе доступных и типичных продолжений. Ответственность возникает на уровне процесса: кто определяет статус утверждения, кто проверяет источник и кто разрешает перенос в итоговый документ.

Пять минут до отправки справки

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

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

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

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

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

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

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

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

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

Контекст, который модель достраивает сама

Мы уже отделили уверенный тон от достоверности и увидели, как правдоподобный текст может продолжать знакомый шаблон, не имея надёжного основания. Теперь источник ошибки смещается на шаг раньше — в сам запрос. ИИ получает не пустое поле, а набор фрагментов и молча достраивает недостающие условия: дату, регион, отрасль, версию документа, цель и адресата.