Как не дать нейросети уверенно наврать: что реально помогает против галлюцинаций ИИ
В основе этого текста не одна чистая научная статья, а собранная база из нескольких разборов и исследовательских блоков: TrueBrief, REFER, PlainQAFact, AgenticSum и общего объяснения того, почему большие языковые модели вообще начинают фантазировать. Поэтому здесь не пересказ одного paper, а связная статья по нескольким подходам сразу. Из основного текста я убрал только мусорные хвосты интерфейса, повторы запроса и обрывки навигации, которые не несут содержания.
Проблема начинается не там, где нейросеть пишет «плохо». Наоборот: самое опасное начинается тогда, когда она пишет гладко, уверенно и профессионально. В материале это разобрано прямо: языковая модель по своей архитектуре не ищет правду, а предсказывает следующий токен так, чтобы текст звучал правдоподобно. Поэтому она может выдать несуществующую дозировку, придуманный диагноз, вымышленного врача, ложную причину падения акций или просто подтащить в ответ что-то из своей статистической памяти, чего в исходном документе не было. Это и есть галлюцинация — не обязательно истерический бред, а часто именно аккуратная, гладкая ложь.
Из базы видно ещё одну неприятную вещь: простые способы обычно ломаются. Попытка засунуть в модель весь длинный документ одним куском и попросить «сделать хорошее резюме» приводит к режиму single pass generation — генерации за один проход. Модель пытается сразу и понять, и выбрать важное, и сформулировать красиво, и не ошибиться. На этом фоне срабатывает феномен lost in the middle — «потеря в середине»: начало и конец текста ещё держатся, а середина размывается. Чем больше шума, тем выше шанс, что модель начнёт закрывать дыры выдумкой.
Отсюда и главный сдвиг, который проходит через весь ваш материал: бороться с галлюцинациями надо не магическим промптом «будь точнее», а разборкой задачи на этапы. Исследователи в разных работах делают это по-разному, но логика одна и та же: сначала сузить поле фантазии, потом отделить факт от добавленного объяснения, потом проверить, не придумано ли лишнее, и только потом выпускать текст дальше.
Что именно предлагают разные исследования
1. REFER: сначала не писать, а считать
В блоке про REFER ключевая мысль очень простая и очень полезная. И человек, и модель плохо работают с абстракциями вроде «сделай объективно» или «учти все мнения». Зато они лучше работают с конкретными частотами. Поэтому REFER заставляет модель сначала посчитать, сколько в тексте позиций за одну сторону и сколько за другую, а уже потом писать итоговое резюме. Идея здесь не в красоте, а в том, что цифры становятся жёстким якорем для внимания модели.
Это важный удар по одной из самых частых поломок. Нейросеть любит обобщать там, где надо было сначала посчитать. Ей сказали «сделай сбалансированно», а она просто написала гладкий усреднённый текст и съела меньшинство мнений. REFER ломает именно это: сначала счёт, потом формулировка.
2. TrueBrief: учить модель видеть разницу между фактом и красивой ложью
В материале про TrueBrief разбирается уже не чатовый трюк, а архитектурный подход. Исследование исходит из ситуации, где крупные компании не могут бездумно гонять документы во внешние сервисы из-за приватности, поэтому им нужны локальные малые модели. Но малые модели тоже галлюцинируют. Тогда авторы строят систему, которая сама генерирует пары «правдивый текст / ложный текст», обучает модель через DPO — прямую оптимизацию предпочтений — и дополняет это детектором лжи в реальном времени.
Самый сильный кусок здесь — контролируемое внедрение галлюцинаций. Внутренние галлюцинации создаются подменой сущностей: дат, сумм, имён, названий компаний. Внешние — добавлением выдуманного контекста, которого не было в документе. Смысл не в том, чтобы нагенерировать любой бред. Наоборот: ложь должна быть структурно похожа на правду, иначе модель выучит не различие между фактом и выдумкой, а различие между стилями текста. В материале это проговорено очень чётко: если плохие примеры будут просто длиннее или стилистически грязнее, модель усвоит неверный сигнал.
Ещё один важный вывод TrueBrief: «больше» не всегда значит «лучше». Авторы пробовали давать модели один правильный текст и сразу несколько плохих, но классическая пара «один хороший, один плохой» оказалась устойчивее. По логике материала, это связано с тем, что при большом числе плохих примеров градиент размывается: модель начинает путаться в разновидностях ошибок вместо того, чтобы держать чёткую границу между правдой и ложью.
Там же вводится метрика BCore, которая соединяет полноту и достоверность. Это важный момент: можно не соврать и при этом написать бесполезную пустоту. Поэтому хорошее резюме должно не только не фантазировать, но и не выбрасывать смысл. А ещё в базе есть наблюдение, что DPO особенно сильно помогает маленьким моделям — на полмиллиарда и полтора миллиарда параметров. Для моделей на 7 млрд эффект уже не такой яркий, потому что у них и без того больше внутренних резервов для сопоставления фактов.
Дальше TrueBrief идёт ещё глубже и пытается ловить ложь прямо в процессе генерации. Для этого используются logit lens и look back lens: один смотрит на изменение уверенности по слоям, второй — на то, куда направлено внимание модели, в исходный документ или уже в её собственные токены. Если модель перестаёт смотреть в источник и начинает опираться на себя же, это выглядит как момент отрыва от реальности. Потом всё это усредняется и отправляется в лёгкий классификатор на логистической регрессии. В материале даже есть эксперимент, где маленькая обученная модель выступает детектором лжи для более крупной системы вроде Llama 2.
3. PlainQAFact: самая опасная ложь часто приходит под видом «пояснения»
Блок про PlainQAFact бьёт в ещё одну проблему. Нейросеть часто не просто искажает факт, а добавляет к исходному тексту «заботливое» объяснение: расшифровку термина, историческую справку, пример, бытовое пояснение. Именно такие elaborative explanations — подробные объяснения — в материале названы одним из основных источников ошибок при пересказе сложных медицинских текстов простым языком. И это действительно коварная поломка: обычная проверка по исходному документу тут слепнет, потому что сравнивать нечего. В исходнике этих добавленных пояснений просто нет.
Поэтому PlainQAFact сначала классифицирует предложения: это упрощение исходного текста или добавленное объяснение. Если это объяснение, дальше подключается внешний источник знаний — в материале приводятся примеры медицинских учебников и клинических баз. Потом идёт двухэтапная QA-проверка: извлекаются ответы, по ним формулируются вопросы, и дальше система проверяет, совпадает ли ответ из сгенерированного текста с ответом из надёжной базы. Для обучения и тестирования авторы собирают отдельный набор PlainFact с ручной разметкой.
Здесь важен не только сам медицинский кейс. Важен принцип: сначала отделить то, что модель пересказала из документа, от того, что она добавила «для удобства читателя». Потому что именно в этом «удобстве» часто и сидит выдумка.
4. AgenticSum: не один автор, а цепочка узких ролей
Материал про AgenticSum показывает ту же идею уже в виде мультиагентной архитектуры. Вместо одного запроса «сделай хорошее резюме» система разбивает работу между несколькими агентами. Focus Agent вымывает из входа шаблонную воду и оставляет сигналы. Draft Agent собирает первый черновик. Detector Agent проверяет его по предложениям, не имея права использовать внешние знания, и опирается на исходник, AURA и семантическую логику. Fix Agent точечно правит только те места, которые детектор пометил как ложь. Clinical Supervisor Agent проверяет итоговый документ перед выпуском.
Самое важное здесь — не само слово «агент», а хирургический принцип исправления. В базе прямо сказано, что переписывать весь текст целиком невыгодно: это плодит новые ошибки. Гораздо лучше вырезать и заменять только проблемные фрагменты. Именно связка Detector + Fix даёт резкий скачок качества: в материале названы и снижение индекса галлюцинаций с 4,2 до 1,8, и рост ROUGE-2 с 5,6 до 7,8.
Что в итоге реально работает, а где метод буксует
Если собрать всё вместе, то из базы вылезает довольно жёсткая картина.
Работает не «умная просьба быть аккуратнее», а дисциплина из нескольких слоёв: сначала убрать шум, потом заставить модель считать, потом выделить опорные факты, потом отделить пересказ от добавленных объяснений, потом проверить каждый рискованный фрагмент и чинить только локально. Это проходит через REFER, PlainQAFact и AgenticSum почти прямой линией.
Сильнее всего исследования бьют по двум видам поломки: когда модель добавляет лишнее и когда она теряет важное. TrueBrief делает на этом акцент через BCore, где полнота и достоверность идут вместе. PlainQAFact ловит лишние пояснения. AgenticSum снижает ложь не общим переписыванием, а через детекцию и хирургическую правку.
Но и границы в материале названы довольно честно. Во-первых, система может лучше ловить сущности, даты и числа, чем поломку причинно-следственной логики. Во-вторых, замкнутая архитектура рискует подтвердить собственную ошибку, если одна и та же модель неверно поняла текст, сама задала по нему вопрос и сама же ответила. В-третьих, большие модели могут лгать более гладко, и тогда внутренние аномалии заметить труднее. И наконец, вся эта история упирается в качество наборов данных и разметки.
Как это реально применять в обычном чате
Дальше — уже прикладная интерпретация вашей базы. Не прямой текст исследований, а перенос их логики в обычный чат без кода.
Шаг 1. Не просить сразу «сделай саммари»
Первый плохой ход — бросить длинный текст в чат и попросить: «Сделай кратко и понятно». Это как раз тот режим, где модель и думает, и сжимает, и украшает одновременно.
Рабочий ход такой:
Вытащи из текста только опорные факты.
Нужны: имена, даты, цифры, ключевые события, причины и следствия, если они прямо есть в тексте.
Ничего не объясняй и не украшай.
Не пиши связный пересказ.
Просто дай список коротких утверждений.
Это практическая версия логики Focus Agent и атомарной декомпозиции.
Шаг 2. Если в тексте есть спорящие позиции — сначала посчитать, потом писать
Это прямое прикладное продолжение REFER.
Сначала посчитай, сколько в тексте аргументов или отзывов поддерживают позицию А, а сколько позицию Б.
Выведи счёт в явном виде.
Только после этого напиши короткое сбалансированное резюме, которое не противоречит этим подсчётам.
Это режет типичную поломку, когда модель делает вид, что «учла всё», а сама просто усреднила шум.
Шаг 3. Собирать связный текст только из уже выделенных фактов
Когда опоры уже вытащены, только тогда есть смысл просить нормальный абзац.
Собери короткий связный текст только на основе списка фактов ниже.
Ничего не добавляй от себя.
Если между фактами нет прямой связи в источнике, не придумывай её.
Это простая чатовая замена идеи strict entailment — строгой привязки к источнику.
Шаг 4. Отдельно заставить модель признаться, что она добавила
Это продолжение PlainQAFact и self-critique.
Теперь проверь свой текст как аудитор.
Для каждого предложения укажи один из статусов:
прямо подтверждается источником;
это добавленное объяснение;
это неподтверждённый вывод.
Если есть добавленные объяснения или неподтверждённые выводы, выпиши их отдельно.
Здесь важно не переписывание, а маркировка риска.
Шаг 5. Разбить ответ на атомарные факты и проверить каждый
Это перенос идеи атомарной декомпозиции и NLI в ручной режим.
Раздели свой ответ на атомарные факты.
Каждый факт должен выражать только одну мысль.
Для каждого факта поставь метку:
— подтверждается источником;
— не найден в источнике;
— противоречит источнику.
Это грубый, но рабочий способ не спорить с целым абзацем, а бить по кирпичам.
Шаг 6. Исправлять только проблемные места, а не переписывать всё
Это уже чистая логика AgenticSum.
Не переписывай текст целиком.
Исправь только те фрагменты, которые помечены как неподтверждённые, противоречащие или добавленные от себя.
Остальной текст не трогай.
Внеси минимально необходимые изменения.
Именно так меньше шанс, что модель починит один кусок и тут же сгаллюцинирует в соседнем абзаце.
Шаг 7. Отдельно проверять причинность и порядок событий
Это особенно важно, потому что именно тут системы часто буксуют.
Отдельно проверь:
— не перепутаны ли причина и следствие;
— не сломан ли порядок событий;
— не поменялись ли местами действующее лицо и объект действия.
Выпиши только места риска.
Это нужно делать даже тогда, когда даты, цифры и имена вроде бы на месте.
Шаг 8. Для рискованных тем сразу включать жёсткий режим источника
Это прямая прикладная версия strict entailment.
Исходный документ — единственный источник правды.
Запрещено додумывать недостающее.
Запрещено использовать внешние знания, здравый смысл и типовые ассоциации.
Если факт не написан прямо, считай его неподтверждённым.
Лучше пропустить, чем придумать.
Для медицины, права, финансов и любых чужих документов это не перестраховка, а нормальный режим работы.
Итог
Главный вывод из вашей базы довольно жёсткий. Галлюцинации не лечатся одной «умной» нейросетью и не исчезают от большой длины контекста. Они гасятся только дисциплиной: считать перед обобщением, вытаскивать факты до написания текста, отделять пересказ от добавленных пояснений, проверять по атомарным утверждениям и править локально, а не переписывать всё с нул
