TL;DR
TREK — набор тестов и метод диагностики, который разбирает по шагам, где ломается ответ модели с веб-поиском: на запросе, на выдаче или на рассуждении после неё. Главный практический вывод: модель с поиском часто находит нужную страницу, но всё равно отвечает неверно, потому что рядом лежат другие страницы с другим ответом. Лучше всего помогает отдельный шаг, где модель явно оценивает каждый источник (по релевантности, соответствию условиям вопроса и надёжности) до того, как отвечать.
Типичная боль: вы спрашиваете «какая сейчас ставка / кто сейчас рекордсмен / какая актуальная версия», а в выдаче лежат старая новость, свежая статья про другой регион и перепубликованный год назад текст с новой датой. Модель берёт то, что выглядит свежим и правдоподобным, а не то, что верно. Она судит по поверхностным сигналам: дате публикации, домену, близости темы. Вдумчивую проверку содержания она включает, только если её об этом попросить.
Метод простой: перед ответом заставить модель пройтись по каждому документу и проверить три вещи. Подходит ли он под условия вопроса (регион, период, сущность)? Не устарел ли он на нужную дату? Можно ли ему верить? Ответ строится только по тому, что прошло проверку.
Схема метода
ШАГ 1: Оценить КАЖДЫЙ найденный источник → таблица: релевантность / соответствие условиям вопроса / надёжность / оставить-отбросить
ШАГ 2: Ответить ТОЛЬКО по оставшимся источникам → ответ + на какие источники опирается + что отброшено и почему
(в оригинале это два отдельных вызова модели; в чате можно в одном промпте)
Пример применения
Задача: Маркетолог готовит рассылку для клиентов банка-партнёра и просит ChatGPT/Perplexity с поиском найти актуальные условия по ипотеке. В выдаче смесь: прошлогодние обзоры, свежие статьи про «семейную ипотеку» (другая программа), перепубликованные тексты с новой датой и сайт-агрегатор неясного происхождения.
Промпт:
Найди в интернете актуальные условия [вставь продукт, например: "ипотека на новостройки, базовые ставки"] в [банк/регион] на сегодня.
Работай в два шага.
ШАГ 1. Для каждого найденного источника заполни строку:
- Источник (сайт, дата публикации, дата, к которой относятся данные)
- Релевантность: говорит ли он именно о моём продукте, регионе и категории заёмщика? (да / нет — чем отличается)
- Соответствие условиям вопроса: совпадают ли программа, срок, регион, «на какую дату» (да / нет)
- Надёжность: первичный источник (сайт банка, ЦБ, закон) или пересказ? Подтверждается ли другими источниками? Нет ли признаков, что старый текст перепубликовали с новой датой?
- Решение: оставить / отбросить
ШАГ 2. Ответь только по источникам с решением «оставить». Если два оставленных источника противоречат друг другу, покажи оба варианта и объясни, какому веришь и почему. Если надёжных источников нет, так и скажи, не угадывай.
Важно: самый свежий по дате источник не обязательно самый верный. Дата публикации — не дата актуальности данных.
Результат: Модель выдаст таблицу по каждому источнику с решением «оставить / отбросить». Затем будет короткий ответ со ссылками на оставшиеся источники. Скорее всего, она явно отметит, какие страницы отброшены как относящиеся к другой программе или устаревшие. При конфликте данных покажет оба варианта. Источники и формулировки зависят от поиска.
Почему это работает
Слабость. Когда в контексте лежит много документов, модель по умолчанию выбирает по поверхностным сигналам: новее, ближе по теме, выглядит солидно. Отсюда ловушки. Свежий документ про другой регион «перебивает» верный. Старый текст с обновлённой датой выглядит новым. Выдуманная цитата с правдоподобным ответом сбивает модель, особенно когда не видно адреса сайта.
Сильная сторона. Если модель просят явно судить каждый документ, она делает это заметно лучше. Авторы формулируют так: «модели знают больше, чем используют». Способность проверять содержание есть, но без прямой просьбы она не включается.
Как метод это использует. Он выносит проверку в отдельный явный шаг. Модель сначала рассуждает про каждый источник отдельно и только потом отвечает. Проверка не растворяется внутри общего ответа.
Рычаги управления: - Критерии оценки. Добавь свои: «первичный источник», «дата данных не старше N месяцев», «совпадает юрисдикция». - Что делать при конфликте. «Покажи оба варианта» или «выбери один и объясни» — зависит от цены ошибки. - Просьба показать таблицу. Убери её («покажи только итог»), если нужна краткость. Но тогда и контроль слабее. - Подсказка про даты. Фраза «дата публикации ≠ дата актуальности» бьёт именно по ловушке с перепубликацией.
Шаблон промпта
{задача: что нужно найти или установить, на какую дату, для какого региона/категории}
Работай в два шага.
<Шаг_1_оценка_источников>
Для КАЖДОГО источника, который ты нашёл или который я дал, заполни:
- Источник: {название/адрес}, дата публикации, дата, к которой относятся данные
- Релевантность: отвечает ли он именно на мой вопрос? (да/нет — почему)
- Соответствие условиям: совпадают ли {условия: регион, период, категория, версия}? (да/нет)
- Надёжность: первичный источник или пересказ? Подтверждается ли другими? Нет ли признаков перепубликации старого текста или выдуманных данных?
- Решение: оставить / отбросить
Шаг_1_оценка_источников>
<Шаг_2_ответ>
Ответь ТОЛЬКО по источникам с решением «оставить».
Если оставленные источники противоречат друг другу: {действие при конфликте}.
Если надёжных источников нет: скажи об этом прямо, не угадывай.
В конце перечисли, какие источники отброшены и почему.
Шаг_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)
