TL;DR
Модели катастрофически деградируют при наличии нерелевантной информации в контексте — даже случайные документы или история чата снижают точность на 9-80% у топовых моделей вроде Gemini-2.5-Pro. Исследователи проверили 7 моделей на 11 датасетах (RAG, рассуждения, alignment, tool-use) с тремя типами "шума": случайные документы, случайная история чата, хард-негативные дистракторы (похожие на вопрос, но неправильные). Самый сильный удар наносят хард-негативы, но даже полностью рандомный текст серьёзно вредит.
Корень проблемы: модель не умеет отличать полезную информацию от шума. Она воспринимает всё в контексте как потенциально релевантное. Агентные воркфлоу (с инструментами) усугубляют ситуацию — модель чрезмерно доверяет выводам инструментов, и если инструмент вернул зашумлённые данные, ошибка распространяется через все шаги планирования. Более того, случайный шум пробивает защиты alignment — модели начинают вести себя не так, как обучены, даже без adversarial-атак. Промптинг и контекст-инжиниринг почти не помогают.
Решение: награждать модель за явную идентификацию полезной информации (RARE). Вместо оценки только финального ответа, метод RARE даёт награду когда модель в процессе рассуждений явно маркирует и извлекает релевантные части из контекста (например, через теги
Схема проблемы и решения
ПРОБЛЕМА:
Контекст = [Вопрос + Полезная инфа + Шум (80% объёма)]
↓
Модель обрабатывает всё как равноценное
↓
Ответ основан на случайных фрагментах → точность -80%
Типы шума: - RD (Random Docs) — случайные документы - RC (Random Chat) — нерелевантная история диалогов - HN (Hard Negative) — информация похожая на правду, но неверная
РЕШЕНИЕ (принцип RARE):
ШАГ 1: Модель читает контекст
ШАГ 2: Модель явно маркирует полезные фрагменты
→ Только этот факт из контекста релевантен
ШАГ 3: Модель рассуждает, опираясь только на маркированное
ШАГ 4: Ответ
Награда даётся за процесс фильтрации, не только за финальный ответ.
Ключевые находки
1. Масштаб проблемы
| Модель | Чистый контекст | Случайный шум | Хард-негативы |
|---|---|---|---|
| Gemini-2.5-Pro | 77.8% | 70.8% (-9%) | 48.0% (-38%) |
| DeepSeek-R1-Distill-8B | 32.4% | 11.6% (-64%) | 6.3% (-80%) |
Чем слабее модель — тем хуже справляется с шумом.
2. Emergent misalignment от случайного шума
Даже без adversarial-атак случайный текст пробивает guardrails: - Gemini-2.5-Pro на BBQ (bias): 94% → 60.5% - DeepSeek-R1: 93% → 33.7%
Вывод: Alignment-туннинг не учитывает зашумлённые контексты. В реальных мультитёрн диалогах с инструментами модель "соскальзывает" с правильного поведения.
3. Агентные workflow ухудшают ситуацию
В чистом контексте агенты с инструментами улучшают результат. В зашумлённом — наоборот: - Модель доверяет выводам retriever/calculator, даже если они основаны на шуме - Ошибка на шаге 1 → ошибочная гипотеза → она переходит в шаг 2 → ещё больше инструментов на основе неё → лавина ошибок
4. Промптинг и контекст-инжиниринг не спасают
Проверили: - CiC-промптинг (Corpus-in-Context) - GEPA, Dynamic Cheatsheet, ACE
Результат: нулевой или отрицательный эффект. LLM-based методы очистки контекста сами страдают от шума.
5. Что работает: явная маркировка источников
RARE (Rationale-Aware Reward) — награда за то, что модель: 1. Извлекает релевантные фрагменты в процессе рассуждений 2. Игнорирует дистракторы 3. Ссылается на конкретные источники
Результат: +55% к точности в самых зашумлённых сценариях.
Принципы для практики
Принцип 1: Просить модель явно маркировать источники
Вместо:
Вот контекст [10 документов]. Ответь на вопрос.
Делай:
Вот контекст [10 документов].
Сначала найди и процитируй ТОЛЬКО релевантные фрагменты.
Формат:
Фрагмент 1: [текст]
Фрагмент 2: [текст]
Затем ответь, используя только маркированное.
Почему работает: Модель вынуждена явно фильтровать до рассуждений. Это создаёт промежуточный контрольный шаг.
Принцип 2: Структурировать источники с пометками приоритета
Вместо кучи информации:
[Документ 1]
[Документ 2]
[История чата]
[Результаты поиска]
Делай иерархию:
ПРИОРИТЕТНАЯ ИНФОРМАЦИЯ:
[То, что точно релевантно]
ДОПОЛНИТЕЛЬНЫЙ КОНТЕКСТ (может содержать шум):
[Остальное]
Задача: сначала проверь приоритетную секцию.
Используй дополнительный контекст только если явно нужно.
Принцип 3: В мультишаговых задачах — промежуточная верификация
Для агентных workflow или цепочек рассуждений:
Шаг 1: [действие]
СТОП. Оцени: информация на этом шаге релевантна задаче?
Если нет — отметь как шум и не используй дальше.
Шаг 2: [следующее действие на основе только верифицированного]
Проблема без этого: Ошибка из шага 1 распространяется на все последующие.
Принцип 4: Меньше контекста ≠ хуже; шумный контекст опаснее, чем его отсутствие
Inverse scaling: Исследование показало, что при наличии шума больше reasoning tokens → хуже результат. Модель не просто тратит время — она активно вплетает дистракторы в рассуждения.
Практически: - Не запихивай в контекст "на всякий случай" - Лучше дать 2 проверенных документа, чем 10 "возможно релевантных"
Примеры применения
Пример 1: Анализ отзывов клиентов
Задача: Ты аналитик Ozon Seller. Клиент прислал 20 отзывов о товаре. Среди них есть отзывы о других товарах (система глюканула), общие жалобы на доставку, и релевантные отзывы о продукте.
Промпт с принципом явной маркировки:
Вот 20 отзывов. Задача: найти паттерны в критике КОНКРЕТНО этого товара (беспроводные наушники XYZ).
ШАГ 1: Отфильтруй нерелевантное
Маркируй как ИГНОР:
- Отзывы о других товарах
- Жалобы на доставку/упаковку без упоминания самого продукта
- Общие рассуждения не о товаре
ШАГ 2: Извлеки релевантные жалобы
[Только отзывы про сами наушники]
ШАГ 3: На основе ТОЛЬКО маркированного — выдай топ-3 проблемы товара.
[Вставь 20 отзывов]
Результат: Модель сначала явно отделит шум, потом проанализирует только чистые данные. Без этого она может "увидеть паттерн" в жалобах на доставку и включить их в анализ продукта.
Пример 2: Исследование конкурентов для стартапа
Задача: Ты основатель SaaS-сервиса для HR. Сделал поиск "конкуренты в HR-tech России". Google выдал 15 ссылок: релевантные стартапы, статьи про рынок труда вообще, новости про увольнения в техе, рекламу курсов.
Промпт:
Задача: проанализировать прямых конкурентов моего продукта [описание].
Вот результаты поиска [15 сниппетов].
ШАГ 1: Отметь источники
Для каждого результата напиши:
- КОНКУРЕНТ — если это компания с похожим продуктом
- КОНТЕКСТ — если это просто инфа о рынке, но не конкурент
- ШУМ — если вообще не по теме
ШАГ 2: Извлеки инфу ТОЛЬКО из источников типа КОНКУРЕНТ
Формат:
[Название]: [что делают], [чем отличаются от меня]
ШАГ 3: Резюме — кто главные игроки и где моя ниша.
Результат: Модель не смешает новость "Яндекс уволил 100 человек" с анализом конкурентов. Она явно разделит типы информации и использует только релевантное.
Пример 3: Проверка фактов в редакторской работе
Задача: Ты редактор медиа. Автор написал статью про новый закон. В статье 10 утверждений. Нужно проверить каждое по источникам. У тебя есть текст закона, комментарий юриста, и 5 новостей (часть — пересказы, часть — домыслы).
Промпт:
Вот статья автора [текст].
Вот источники: [текст закона], [комментарий юриста], [5 новостей].
Для каждого утверждения в статье:
1. Найди подтверждение в источниках
2. Процитируй:
Утверждение: [фраза из статьи]
Источник: [название документа]
Цитата: [точный текст]
Вердикт: ВЕРНО / НЕТОЧНО / НЕТ ПОДТВЕРЖДЕНИЯ
3. Если нет подтверждения ни в одном источнике — так и напиши, не додумывай.
Важно: используй ТОЛЬКО данные из предоставленных источников, не общие знания.
Результат: Модель не смешает "что-то слышала" с конкретными фактами из документов. Каждое утверждение будет привязано к источнику или помечено как непроверенное.
Почему это работает
Слабость LLM: Модель обрабатывает контекст как равномерное распределение релевантности. Если дистрактор занимает 80% токенов, attention-механизм уделяет ему непропорционально много внимания. Визуализация из исследования показала: в неправильных ответах модель фокусируется именно на токенах-дистракторах, а не на полезных данных.
Сильная сторона LLM: Модель отлично следует явным структурированным инструкциям. Если ты попросишь "сначала отфильтруй, потом рассуждай" — она выполнит. Промежуточный шаг фильтрации создаёт bottleneck, через который шум не проходит.
Механика RARE: Награждая модель за сам процесс идентификации, а не только за финальный ответ, мы смещаем её поведение в сторону осознанной работы с источниками. Это как разница между "реши задачу" и "покажи решение пошагово с пояснениями" — второе заставляет модель быть внимательнее.
Рычаги управления промптом:
| Элемент | Что можно менять | Эффект |
|---|---|---|
| Теги маркировки | |
Чем конкретнее название тега — тем чётче модель понимает что извлекать |
| Порог фильтрации | "Используй только если уверенность >80%" | Строже критерий → меньше шума, но можно потерять пограничные данные |
| Иерархия источников | ПРИОРИТЕТ / ДОПОЛНИТЕЛЬНО / ИГНОР | Даёшь модели готовую структуру вместо "разбирайся сама" |
| Промежуточные проверки | Добавить "СТОП. Проверь: это релевантно?" после каждого шага | Замедляет, но снижает накопление ошибок в мультишаговых задачах |
Шаблон промпта
Задача: {твоя задача}
Контекст: {источники информации — могут содержать нерелевантное}
ИНСТРУКЦИЯ:
ШАГ 1 — Фильтрация источников
Для каждого источника определи:
- РЕЛЕВАНТНО — напрямую помогает решить задачу
- КОНТЕКСТ — общая информация, может быть полезна косвенно
- ШУМ — не относится к задаче
ШАГ 2 — Извлечение полезного
Из источников типа РЕЛЕВАНТНО и КОНТЕКСТ извлеки конкретные фрагменты:
Источник: [название]
Фрагмент: [процитируй релевантную часть]
ШАГ 3 — Рассуждение
Используя ТОЛЬКО маркированные фрагменты, {опиши что нужно сделать: ответить на вопрос / сделать анализ / etc}.
Если информации недостаточно — так и напиши, не додумывай.
Как заполнять:
- {твоя задача} — конкретный вопрос или задание
- {источники информации} — текст документов, история чата, результаты поиска
- {опиши что нужно сделать} — финальное действие (ответ, резюме, рекомендации)
Принцип: Три явных шага не дают модели "перепрыгнуть" к ответу, используя первый попавшийся фрагмент.
🚀 Быстрый старт — вставь в чат:
Адаптируй этот шаблон под мою задачу: [опиши свою ситуацию].
Спроси у меня: какие источники информации у меня есть, какой финальный результат нужен, и есть ли специфика в определении "релевантности" для моей задачи.
[вставить шаблон выше]
LLM спросит про твои источники и критерии релевантности — это нужно, чтобы настроить логику фильтрации под твой домен. Она возьмёт паттерн трёхшагового процесса и адаптирует под конкретику.
Ограничения
⚠️ Длина и токены: Явная фильтрация добавляет шаги → больше токенов на запрос. В сценариях с жёсткими лимитами (API cost, короткие контексты) может быть накладно.
⚠️ Субъективные критерии релевантности: Метод хорошо работает, когда понятно "что релевантно" (факты, цифры, конкретные утверждения). В креативных/абстрактных задачах модель может по-разному трактовать "полезность" информации.
⚠️ Не панацея для adversarial-атак: Исследование про случайный шум и хард-негативы. Специально crafted adversarial inputs могут обходить фильтрацию.
⚠️ Качество контекста имеет значение: Если весь контекст — мусор, даже явная фильтрация не поможет. Метод работает когда среди шума есть что извлекать.
Как исследовали
Исследователи из KAIST AI и LG AI Research собрали NoisyBench — 11 датасетов (2766 примеров) по четырём категориям: RAG (SealQA, MultihopRAG, Musique), reasoning (BBEH-Mini, AIME25, GPQA), alignment (Self-Awareness, Survival-Instinct, BBQ), tool-use (TauBench). Каждый пример тестировали в четырёх режимах: (1) чистый контекст, (2) +случайный документ из HotPotQA, (3) +случайная история чата из WildChat, (4) +хард-негатив (похожий на вопрос, но неправильный, сгенерирован LLM).
Проверили 7 моделей от Gemini-2.5-Pro до мелких 4B-8B reasoning-моделей. Результаты шокировали: топ-модели теряли до 38%, слабые — до 80% точности. Самое интересное: хард-негативы били сильнее всего, но даже полностью рандомный текст наносил серьёзный урон. Это доказало, что проблема не в "обмане похожим контентом", а в фундаментальной неспособности фильтровать шум.
Проверили наивные решения: CiC-промптинг, три метода context engineering (GEPA, Dynamic Cheatsheet, ACE), SFT на зашумлённых данных, RL с outcome-наградами. Почти всё провалилось. SFT вызывал катастрофическое забывание. Промптинг и CE давали нулевой эффект, потому что LLM-методы очистки контекста сами страдали от шума. RL с outcome-наградами немного помог, но не сильно — модель получала награду даже когда рассуждала на основе дистракторов, если случайно угадывала ответ.
Тогда придумали RARE (Rationale-Aware Reward) — награду за то, что модель в процессе рассуждений явно извлекает релевантные фрагменты через теги
Копнули глубже: визуализировали attention-веса. Оказалось, в неправильных ответах модели буквально смотрят на токены-дистракторы вместо полезных данных. Обнаружили inverse scaling — в зашумлённом контексте больше reasoning tokens = хуже результат, потому что модель активно вплетает шум в рассуждения. Энтропия выходов росла с количеством шума — модель становилась неуверенной, путалась. Всё это объяснило, почему RARE работает: награждая процесс фильтрации, метод учит модель смотреть не туда, где много токенов, а туда, где полезная инфа.
Ресурсы
Lost in the Noise: How Reasoning Models Fail with Contextual Distractors Seongyun Lee (KAIST AI, LG AI Research), Yongrae Jo (LG AI Research), Minju Seo (KAIST AI, LG AI Research), Moontae Lee (LG AI Research, University of Illinois Chicago), Minjoon Seo (KAIST AI) Январь 2026