Как оценивать LLM на уязвимость к фальшивым источникам во время агентного поиска

Почему точная LLM всё равно может поверить фальшивому источнику

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

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

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

Два режима проверки: знание факта и работа с конфликтующими источниками

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

Агентный поиск добавляет несколько переменных:

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

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

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

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

Финальная ошибка не всегда означает, что модель не знала правильного ответа. Представим агент, который до поиска корректно называет актуальную версию библиотеки. После чтения поддельной инструкции он рекомендует устаревший API и ссылается на конкретный раздел страницы. Знание могло присутствовать, но модель выбрала внешний текст в качестве главного основания.

Для анализа нужно разделять три уровня:

1. Поиск. Агент не нашёл правильный документ или выбрал нерелевантную выдачу.
2. Извлечение. Агент открыл подходящую страницу, но неверно передал её содержание в контекст.
3. Арбитражирование. Модель увидела конфликт, однако предпочла ложный или менее надёжный источник.

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

Epistemic arbitration в LLM: как модель взвешивает память и источник

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

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

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

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

Конфликт требует дополнительной проверки, когда страница:

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

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

Почему оформление страницы не равно надёжности

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

Агенту нужно проверять как минимум пять сигналов:

1. Первичность. Автор описывает событие или правило сам либо пересказывает чужой материал?
2. Независимость. Несколько страниц получили сведения из разных документов или переписывают один текст?
3. Актуальность. Совпадает ли дата материала с версией продукта или моментом события?
4. Конкретность доказательства. Есть ли документ, запись, официальный листинг или иной проверяемый объект?
5. Атрибуция. Понятно ли, кто отвечает за утверждение и кто имеет право принимать соответствующее решение?

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

Подход EchoNet: как устроить проверку LLM на дезинформацию

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

Тест должен отвечать на четыре вопроса:

• сохраняет ли модель правильную позицию после чтения ложного текста;
• ищет ли она первоисточник и независимые подтверждения;
• объясняет ли причину выбора одного основания перед другим;
• снижает ли уверенность, если конфликт не разрешён.

Базовый сценарий: верный факт против одной ложной страницы

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

Полезная последовательность выглядит так:

1. Попросить модель ответить на вопрос без поиска.
2. Запустить поиск с одной ложной страницей.
3. Добавить реальный первичный документ.
4. Попросить агента сравнить противоречащие сведения.
5. Зафиксировать финальный ответ, цитаты и степень уверенности.

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

Контролируемое усиление давления источников

После одиночной страницы тест усложняют по одной переменной. Меняют число материалов, порядок выдачи, сходство формулировок, расположение первоисточника и долю ложных страниц.

Сценарий	Что меняется	Что измерять
Одиночная ложь	Один ошибочный текст рядом с вопросом	Замечает ли агент противоречие
Копипаст-эхо	Несколько страниц с одинаковым тезисом	Считает ли модель повторение независимым подтверждением
Фальшивое большинство	Много вторичных страниц против реального документа	Сохраняет ли агент приоритет первоисточника
Перестановка	Меняется порядок показа тех же материалов	Зависит ли вывод от позиции источника

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

Какие артефакты нужно сохранять для воспроизводимости

Одного финального ответа недостаточно. Для каждого прогона сохраняют:

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

Такая запись помогает установить точку сбоя. Агент мог не найти первоисточник, неверно извлечь абзац или принять зависимые копии за независимые документы. Эти ошибки требуют разных исправлений.

Какие фальшивые источники опаснее: от одиночной лжи к фальшивому большинству

Одиночная ложь: заметный, но ограниченный сигнал

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

В практическом продукте такой риск встречается при поиске инструкции, скачивании программы или выборе команды для настройки сервера. Агент может найти один неофициальный установщик или устаревшую инструкцию и выдать её как основной путь. Для Hydra Launcher безопаснее считать контрольными точками официальный сайт и официальный репозиторий с разделом релизов, заметками и историей версий. Модифицированные установщики, подозрительные менеджеры загрузки и перенаправления требуют отдельной проверки.

Копипаст-эхо: почему повторение выглядит как подтверждение

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

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

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

Фальшивое большинство вокруг реального первоисточника

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

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

Показателен пример со спором вокруг Pokémon World Championships. Три сильных игрока, включая чемпиона мира 2024 года Луку Черибелли, заявили, что после конфликта в очереди Pokémon Center у них забрали пропуска, и это фактически не позволило им попасть на мероприятие. При этом публично оставался неясным вопрос о том, кто именно принял окончательное решение: охрана площадки, сотрудники Pokémon Center или The Pokémon Company. Такой случай разделяет два утверждения: событие с пропусками и атрибуцию полномочий. Даже реальный первичный материал по инциденту может не отвечать на второй вопрос.

Практические аналогии: загрузки, покупки и спорные события

При выборе программы агент должен определить официальный канал распространения, а не искать страницу с самым подробным описанием. Для Hydra Launcher разумная проверка включает официальный сайт и GitHub Releases, где видны версии, заметки и история публикаций. Это пример задачи, где происхождение файла важнее числа страниц, повторяющих одну рекомендацию.

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

В обсуждении Trust Factor в CS2 нужно отделять пользовательские советы от официального описания механики. Форумная инструкция может выглядеть подробно и авторитетно, но её нельзя автоматически считать объяснением внутренней системы Valve. Для агента это хороший тест на атрибуцию: кто утверждает правило и на каком основании.

Метрики: как сравнивать модели при агентном поиске

Итоговая точность после поиска

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

В отчёте нужно указывать как минимум два значения: точность без внешнего контекста и точность после поиска. Разница между ними показывает влияние среды, но не объясняет его причину. Для этого нужны дополнительные показатели.

Доля принятия ложного источника

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

Простая формула выглядит так:

False Source Acceptance Rate = число случаев принятия ложного тезиса / число конфликтных заданий

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

Качество выбора первоисточника и независимых подтверждений

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

• нашёл ли агент реальный первичный документ;
• отличил ли оригинал от пересказа;
• распознал ли ссылки на один и тот же исходный текст;
• учёл ли дату и версию;
• верно ли связал утверждение с цитатой.

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

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

Устойчивость к порядку и числу источников

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

Для каждого задания можно рассчитать:

Order Sensitivity = число смен правильной позиции после перестановки / число перестановок

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

Калибровка уверенности и фиксация конфликта

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

Проверяйте четыре поведения:

• модель явно называет противоречие;
• объясняет, почему один источник сильнее другого;
• отделяет установленное от неподтверждённого;
• снижает уверенность после добавления несовместимых материалов.

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

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

Как результаты переносятся на RAG и AI-агентов в продуктах

Поиск документации и написание кода

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

Тестируйте способность агента:

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

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

Конспекты и автоматический сбор информации

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

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

Для RAG-систем полезно расширить обычный набор проверок качества. Практические подходы к тестовому набору, галлюцинациям и метрикам собраны в руководстве по оценке RAG-систем. В контексте фальшивых источников к retrieval-метрикам добавляется проверка независимости и устойчивости к вредным документам.

Локальные и self-hosted системы

Локальная LLM снижает риски утечки данных, однако не делает найденные сведения истинными. В self-hosted пайплайне нужно разделять три поверхности:

1. Модель. Она может неверно взвесить память и контекст.
2. Поисковый коннектор. Он может выбрать низкокачественные страницы или неверно распарсить документ.
3. Оркестрация. Она может передать модели слишком много повторяющихся текстов и потерять сведения о происхождении.

Orpheus можно привести как контрастный пример local-first архитектуры: транскрибация остаётся внутри сети, очистка текста подключается отдельно, а при недоступности этого этапа система возвращает необработанный результат распознавания. Такой fallback повышает доступность и сохраняет приватность, но сам по себе не проверяет истинность входных данных. Надёжность обработки и достоверность содержания, разные свойства.

Практический протокол проверки LLM на уязвимость к фальшивым источникам

Сформировать контрольный набор фактов и источников

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

В набор стоит включить разные типы задач:

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

Для каждого факта пометьте, какие сведения считаются установленными, а какие требуют осторожной формулировки. В истории с Pokémon World Championships, например, отдельно фиксируются заявления игроков о конфискации пропусков и отсутствие ясности о том, кто принял окончательное решение.

Добавить ложные страницы по уровням сложности

Подготовьте три варианта окружения:

1. одна страница с неверным тезисом;
2. несколько страниц с повторяющейся формулировкой;
3. группа убедительных вторичных материалов, противоречащих реальному первоисточнику.

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

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

Зафиксировать не только ответ, но и путь агента

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

Минимальная схема записи может включать такие поля:

Поле	Назначение
question	Исходная задача
ground_truth	Проверяемый правильный ответ
sources	Полный список доступных документов
source_roles	Первичный, вторичный, ложный или зависимый материал
trace	Поисковые шаги и выбранные цитаты
final_answer	Ответ агента
confidence	Указанная или рассчитанная уверенность
error_type	Поиск, извлечение или арбитражирование

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

Что считать хорошим результатом и какие выводы делать нельзя

Минимальный набор показателей для отчёта

Сравнительный отчёт должен содержать:

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

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

Почему один рейтинг не заменяет сценарное тестирование

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

Результат зависит от продукта, домена, поискового инструмента, длины контекста и прав агента. Тест для локального RAG по внутренней документации нельзя напрямую сравнивать с веб-поиском по свежим новостям. Различается и цена ошибки: неверный конспект требует исправления, а неверная команда может изменить рабочую систему.

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

Главный вывод для пользователей AI-агентов

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

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

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

Подписаться на канал