3,583 papers
arXiv:2610.25323 84 18 окт. 2026 г. FREE

TREK: почему LLM с поиском ошибаются не при поиске, а при выборе между противоречивыми источниками

КЛЮЧЕВАЯ СУТЬ
Модель с поиском часто находит нужную страницу и всё равно отвечает неверно: рядом лежат другие страницы с другим ответом. Метод позволяет получать актуальные факты (ставка, версия, рекорд) даже когда выдача забита устаревшими и подделанными текстами. Фишка: модель умеет проверять содержание, но без прямой просьбы не включает эту проверку. Перед ответом заставь её вынести вердикт каждому источнику отдельно: подходит ли он под условия вопроса (регион, период, сущность), не устарел ли, можно ли ему верить. Отвечает она только по тем, что прошли проверку.
Адаптировать под запрос
⚡

TL;DR

TREK — набор тестов и метод диагностики, который разбирает по шагам, где ломается ответ модели с веб-поиском: на запросе, на выдаче или на рассуждении после неё. Главный практический вывод: модель с поиском часто находит нужную страницу, но всё равно отвечает неверно, потому что рядом лежат другие страницы с другим ответом. Лучше всего помогает отдельный шаг, где модель явно оценивает каждый источник (по релевантности, соответствию условиям вопроса и надёжности) до того, как отвечать.

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

Метод простой: перед ответом заставить модель пройтись по каждому документу и проверить три вещи. Подходит ли он под условия вопроса (регион, период, сущность)? Не устарел ли он на нужную дату? Можно ли ему верить? Ответ строится только по тому, что прошло проверку.

🔬

Схема метода

ШАГ 1: Оценить КАЖДЫЙ найденный источник → таблица: релевантность / соответствие условиям вопроса / надёжность / оставить-отбросить
ШАГ 2: Ответить ТОЛЬКО по оставшимся источникам → ответ + на какие источники опирается + что отброшено и почему
(в оригинале это два отдельных вызова модели; в чате можно в одном промпте)
🚀

Пример применения

Задача: Маркетолог готовит рассылку для клиентов банка-партнёра и просит ChatGPT/Perplexity с поиском найти актуальные условия по ипотеке. В выдаче смесь: прошлогодние обзоры, свежие статьи про «семейную ипотеку» (другая программа), перепубликованные тексты с новой датой и сайт-агрегатор неясного происхождения.

Промпт:

Найди в интернете актуальные условия [вставь продукт, например: "ипотека на новостройки, базовые ставки"] в [банк/регион] на сегодня.

Работай в два шага.

ШАГ 1. Для каждого найденного источника заполни строку:
- Источник (сайт, дата публикации, дата, к которой относятся данные)
- Релевантность: говорит ли он именно о моём продукте, регионе и категории заёмщика? (да / нет — чем отличается)
- Соответствие условиям вопроса: совпадают ли программа, срок, регион, «на какую дату» (да / нет)
- Надёжность: первичный источник (сайт банка, ЦБ, закон) или пересказ? Подтверждается ли другими источниками? Нет ли признаков, что старый текст перепубликовали с новой датой?
- Решение: оставить / отбросить

ШАГ 2. Ответь только по источникам с решением «оставить». Если два оставленных источника противоречат друг другу, покажи оба варианта и объясни, какому веришь и почему. Если надёжных источников нет, так и скажи, не угадывай.

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

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

🧠

Почему это работает

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

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

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

Рычаги управления: - Критерии оценки. Добавь свои: «первичный источник», «дата данных не старше N месяцев», «совпадает юрисдикция». - Что делать при конфликте. «Покажи оба варианта» или «выбери один и объясни» — зависит от цены ошибки. - Просьба показать таблицу. Убери её («покажи только итог»), если нужна краткость. Но тогда и контроль слабее. - Подсказка про даты. Фраза «дата публикации ≠ дата актуальности» бьёт именно по ловушке с перепубликацией.

📋

Шаблон промпта

{задача: что нужно найти или установить, на какую дату, для какого региона/категории}

Работай в два шага.

<Шаг_1_оценка_источников>
Для КАЖДОГО источника, который ты нашёл или который я дал, заполни:
- Источник: {название/адрес}, дата публикации, дата, к которой относятся данные
- Релевантность: отвечает ли он именно на мой вопрос? (да/нет — почему)
- Соответствие условиям: совпадают ли {условия: регион, период, категория, версия}? (да/нет)
- Надёжность: первичный источник или пересказ? Подтверждается ли другими? Нет ли признаков перепубликации старого текста или выдуманных данных?
- Решение: оставить / отбросить


<Шаг_2_ответ>
Ответь ТОЛЬКО по источникам с решением «оставить».
Если оставленные источники противоречат друг другу: {действие при конфликте}.
Если надёжных источников нет: скажи об этом прямо, не угадывай.
В конце перечисли, какие источники отброшены и почему.


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

Что подставлять: - {задача} — вопрос с явной датой и рамками («на 1 марта», «для Москвы», «версия 3.x»). - {условия} — всё, что отличает нужный ответ от похожих (регион, программа, срок, категория). - {действие при конфликте} — «покажи оба варианта и укажи, какому веришь» или «выбери первичный источник».

🚀 Быстрый старт — вставь в чат:

Вот шаблон двухшаговой проверки источников. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит, на какую дату и для какого региона/категории нужен ответ, и чем «похожий, но неправильный» источник отличается от нужного. Это нужно, чтобы критерии «соответствие условиям» были конкретными, а не общими.

⚠️

Ограничения

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

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

⚠️ Может навредить: у одной из трёх моделей (небольшая открытая) фильтрация на коварных случаях ухудшила результат: видимо, отбрасывала нужное. Слабым моделям не стоит доверять свои «оставить/отбросить» без проверки.

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

⚠️ Готового промпта в статье нет: описана идея фильтра (оценка по релевантности, соответствию требованиям, надёжности), а точные формулировки лежат в приложении. Шаблон выше — реконструкция по описанию, а не цитата.

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

🔍

Как исследовали

Сначала авторы построили диагностику TrekTrace. Она проверяет, нашла ли модель нужный документ. Если нашла, ответ перезапускают дважды: только с правильным документом и с правильным плюс «шумом». Если по одному правильному ответ верен, а с шумом нет, значит, модель отвлекли. Если неверен даже по одному, значит, она неправильно прочитала сам источник. Совпадение с ручной проверкой людей очень высокое (κ = 0,93). Потом прогнали три набора реальных вопросов про быстро меняющиеся факты (FreshQA, InfoDeepSeek, SealQA) на топовых моделях: GPT-5.4, Gemini-3.1-Pro, Claude Opus 4.6 и открытых от 8B до 235B. Лучший результат — около 70 % у GPT-5.4. На самом трудном наборе лучшая модель дала лишь 56 %.

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

Затем авторы собрали контролируемый тест TrekBench-Ctrl: фиксированный набор документов с отвлекающими примесями четырёх видов. Потери точности у GPT-5.4-mini выросли поэтапно: при устаревших документах около 6 п.п., при смеси естественных помех 15, при фабрикациях и перепубликациях с видимым адресом 28, при скрытом адресе 37. Позиция правильного документа и число устаревших не влияли, значит, важен тип помехи, а не объём. Существующие бенчмарки почти целиком состоят из устаревших документов, поэтому там хватает приёма «возьми самый новый» и сложность занижена.

Среди четырёх способов лучше всего показал себя Filter (явная оценка каждого документа). На коварных наборах он поднял точность примерно на 10–14 п.п. у двух моделей из трёх. Простое переранжирование по дате и близости почти не помогло. Вывод для практики: модель умеет проверять содержание, но делает это только по прямой просьбе.

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

💡

Адаптации и экстраполяции

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

Шаг А. Вот один источник: {ключевой_источник}. Ответь на вопрос только по нему.
Шаг Б. Теперь вот все источники: {все_источники}. Ответь на тот же вопрос.
Если ответы разные — скажи, какой из «лишних» источников сбил тебя и почему.

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

🔧 Техника: правило для агента с поиском (системный промпт / CLAUDE.md)

При поиске актуальной информации:
- Не выбирай самый свежий документ автоматически. Сверяй регион, период, категорию и версию с условиями вопроса.
- Дата публикации не равна дате актуальности данных. Старый текст могли перепубликовать.
- Предпочитай первичные источники (официальные сайты, документы). Один неподтверждённый источник — не основание для ответа.
- Перед ответом кратко перечисли, какие источники ты отбросил и почему.
- При противоречии источников покажи оба варианта и скажи, чему веришь.

Это перенос идеи на инструкции агенту. В статье такой текст не проверяли, но он следует из найденных ловушек (свежесть, перепубликация, соседний регион).

🔗

Ресурсы

  • Статья: Where and Why Search-Augmented LLMs Fail When Reasoning over Rapidly Evolving Knowledge
  • Авторы: Tianyi Hu, Bhavyajeet Singh, Niket Tandon, Akhil Arora (Aarhus University, Microsoft Research, TU Darmstadt)
  • Код и тесты: https://github.com/au-clan/TREKBench
  • Наборы вопросов, на которых строили: FreshQA, InfoDeepSeek, SealQA (в том числе LongSeal)

📋 Дайджест исследования

Ключевая суть

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

Принцип работы

Процесс из двух шагов: оценка каждого источника → ответ по оставшимся. На шаге 1 модель заполняет строку по каждому документу: релевантность, соответствие условиям, надёжность, решение «оставить/отбросить». На шаге 2 отвечает только по «оставленным». Если они спорят, показывает оба варианта и говорит, какому верит. Проверка живёт в отдельном шаге и не растворяется внутри общего ответа. Это как судья, который сначала допрашивает каждого свидетеля и только потом выносит приговор. Если дать ему всех сразу, он поверит тому, кто говорит увереннее. В статье это два отдельных вызова модели. В чате хватает одного промпта с двумя шагами.

Почему работает

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

Когда применять

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

Мини-рецепт

1. Задай рамки вопроса: дата («на 1 марта»), регион, программа, версия. Без них модель не поймёт, чем «похожий» источник отличается от нужного.
2. Потребуй таблицу по каждому источнику: сайт, дата публикации, дата данных, релевантность, соответствие условиям, надёжность, решение.
3. Спроси про перепубликацию: добавь «нет ли признаков, что старый текст выложили с новой датой?». Этот пункт бьёт именно по главной ловушке.
4. Реши, что делать при споре: «покажи оба варианта» или «выбери первичный источник». Если ошибка дорого стоит, бери первое.
5. Запрети угадывать: «если надёжных источников нет, скажи прямо».
6. Добавь свои критерии: «данные не старше 3 месяцев», «только сайт банка или ЦБ».
7. Не знаешь, как сформулировать: вставь шаблон в чат и напиши «задавай вопросы, чтобы заполнить поля».

Примеры

[ПЛОХО]: `Найди актуальные условия по ипотеке на новостройки в Сбере` [ХОРОШО]: `Найди актуальные условия по ипотеке на новостройки (базовые ставки, не семейная) в Сбере на сегодня. Работай в два шага. ШАГ 1. Для каждого источника заполни: сайт, дата публикации, дата, к которой относятся данные; релевантность (говорит ли именно о моём продукте и категории заёмщика); соответствие условиям (программа, срок, дата); надёжность (сайт банка или пересказ, подтверждается ли другими, не перепубликован ли старый текст); решение: оставить или отбросить. ШАГ 2. Ответь только по источникам с решением «оставить». Если они противоречат друг другу, покажи оба варианта и скажи, какому веришь. Если надёжных источников нет, так и скажи. Помни: самый свежий источник не обязательно самый верный, дата публикации не равна дате актуальности данных.` [ПЛОХО]: `Какая сейчас последняя версия библиотеки?` [ХОРОШО]: `Какая последняя стабильная версия библиотеки X на сегодня? Сначала оцени каждый найденный источник: официальный ли он, к какой дате относится, не про бета-версию ли. Потом ответь только по надёжным и перечисли, что отбросил и почему.`
Источник: Where and Why Search-Augmented LLMs Fail When Reasoning over Rapidly Evolving Knowledge
ArXiv ID: 2610.25323 | Сгенерировано: 2026-10-20 16:50

Проблемы LLM

ПроблемаСутьКак обойти
Среди противоречивых источников модель выбирает по внешним признакам, а не по содержаниюПросишь найти актуальный факт: ставку, версию, рекорд. В выдаче лежат старая статья, свежий текст про другой регион и старый текст, перепубликованный с новой датой. Модель берёт то, что выглядит свежим и солидным. Нужную страницу она могла найти, но ответ строит по соседней. Особенно плохо, когда не видно адреса сайта. Ошибка выглядит уверенной и правдоподобнойНе проси просто «найди и ответь». Добавь отдельный шаг: сначала оценить каждый источник, потом отвечать. Явно напиши: «дата публикации — не дата актуальности данных». Указывай в вопросе дату, регион и версию, чтобы было с чем сверять

Методы

МетодСуть
Оценка каждого источника до ответа — отсев похожих, но неверныхРаздели работу на два шага. Шаг 1: для каждого источника модель заполняет строку. В ней: откуда источник, дата публикации, дата самих данных, подходит ли он под условия вопроса (регион, период, версия), надёжность (первичный источник или пересказ, есть ли подтверждение), решение «оставить/отбросить». Шаг 2: ответ строится только по оставленным. Если они противоречат друг другу, покажи оба варианта и объясни выбор. Если надёжных нет, скажи прямо, а не угадывай. В конце перечисли, что отброшено и почему. Почему работает: способность проверять содержание у модели есть, но без прямой просьбы она не включается. Отдельный шаг заставляет рассуждать про каждый документ отдельно. Проверка не растворяется в общем ответе. Настройка: добавляй свои критерии («первичный источник», «данные не старше N месяцев», «та же юрисдикция»). При высокой цене ошибки проси показать оба варианта. Для краткости можно убрать таблицу, но контроль ослабнет. Когда да: много документов, есть похожие, но разные по региону, программе или дате. Когда осторожно: слабая или небольшая модель может отбросить нужное, проверяй её «отбросить». Если в выдаче только устаревшие документы, отсев почти не помогает. Полностью проблему метод не снимает, он только уменьшает потери. В чате оба шага можно дать одним запросом
📖 Простыми словами

Where and Why Search-AugmentedLLMsFail When Reasoning over Rapidly Evolving Knowledge

arXiv: 2610.25323

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

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

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

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

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

Работа с исследованием

Адаптируйте исследование под ваши задачи или создайте готовый промпт на основе техник из исследования.

0 / 2000
~0.5-2 N-токенов ~10-30с
~0.3-1 N-токенов ~5-15с