TL;DR
Dynamic Context Selection — исследование того, как количество и расположение информации в контексте влияет на качество ответов LLM в RAG-системах (когда модель получает внешние документы для ответа). Главная находка: нерелевантная информация (distractor'ы) резко ухудшает ответы, а позиция релевантной информации в контексте критически важна — середину модель игнорирует.
Для вопросов, требующих 2 шага рассуждений, один нерелевантный документ снижает качество на 26%. Для сложных вопросов (3-4 шага) — на 13-14%. При этом если дать слишком мало контекста — модель упустит важную информацию, если слишком много — утонет в шуме. Это компромисс точности и полноты: больше документов = больше шанс найти нужное, но и больше мусора, который сбивает с толку.
Исследователи создали classifier, который предсказывает сколько документов нужно для конкретного вопроса (2, 3 или 4), и LLM-reranker, который отфильтровывает самые релевантные. Плюс обнаружили: релевантная информация в конце контекста работает лучше, чем в начале или середине — это подтверждает эффект "lost in the middle" (потерялось посередине).
Схема исследования
ПРОБЛЕМА:
Standard RAG → всегда берёт K документов (например, 5)
→ часть нерелевантны (distractor'ы)
→ релевантные теряются в середине
РЕШЕНИЕ:
ШАГ 1: Classifier анализирует вопрос → предсказывает оптимальное k (2, 3 или 4)
ШАГ 2: Retriever достаёт 5 кандидатов
ШАГ 3: LLM-reranker получает вопрос + 5 кандидатов + predicted k
→ отбирает топ-k самых релевантных
→ размещает их в конце контекста
ШАГ 4: Generator получает вопрос + отфильтрованный контекст → даёт ответ
Все шаги — отдельные запросы в pipeline с инфраструктурой (vector DB, retriever models, classifier).
Ключевые находки
1. Количественный вред distractor'ов:
Исследователи взяли вопросы разной сложности (2-hop, 3-hop, 4-hop — это число шагов рассуждений для ответа) и постепенно добавляли нерелевантные документы:
- 2-hop вопросы: 1 distractor → -26% качества, 2 distractor'а → ещё хуже
- 3-hop вопросы: 1 distractor → -13.5%
- 4-hop вопросы: 1 distractor → -14.4%
Простые вопросы страдают сильнее, потому что им нужно меньше контекста — и любой мусор сразу перевешивает полезное.
2. Эффект "lost in the middle" подтверждён:
Исследователи брали 5 документов (релевантные + distractor'ы) и меняли позицию релевантных:
| Позиция релевантных | Exact Match | F1 score |
|---|---|---|
| В конце | 0.5567 | 0.6361 |
| В начале | 0.5447 | 0.6212 |
| В середине | 0.5391 | 0.6126 |
Конец контекста — лучшая позиция. Середина — худшая. LLM приоритизируют недавнюю информацию (recency bias).
3. Динамический выбор k работает (но нужен хороший reranker):
Просто classifier без reranker'а → хуже baseline (потому что отрезает релевантные документы, если они в нижних позициях).
Classifier + LLM-reranker → лучше baseline на всех конфигурациях:
- MuSiQue dataset: 0.171 (baseline) → 0.202 (classifier+LLM)
- 2WikiMultihopQA: 0.488 (baseline) → 0.531 (classifier+LLM)
- MultihopRAG: 0.594 (baseline) → 0.625 (classifier+LLM)
4. Идеальный retriever + classifier >> fixed-k:
В Oracle Study (идеальные условия) показали: если retriever безупречен, classifier с точным k даёт 0.564 EM vs 0.523 у лучшего fixed-k.
Применимые принципы
Хотя исследование про сложную систему с инфраструктурой, можно извлечь три практических принципа для работы с длинным контекстом:
🎯 Принцип 1: Размещай самое важное в конце
Если работаешь с длинным контекстом (Projects в ChatGPT, Artifacts в Claude), самую релевантную информацию размещай ближе к концу.
Пример: Ты анализируешь серию интервью с клиентами для выявления болей. У тебя 10 интервью, но 3 из них — ключевые, с самой ценной информацией.
Ты продакт-менеджер. Нужно выявить топ-3 боли клиентов из интервью.
[7 обычных интервью]
ОСОБЕННО ВАЖНЫЕ ИНТЕРВЬЮ (самые подробные и репрезентативные):
[Интервью №8]
[Интервью №9]
[Интервью №10]
Какие три главные боли повторяются?
🧹 Принцип 2: Убирай нерелевантное агрессивно
Каждый нерелевантный фрагмент снижает качество. Лучше дать меньше контекста, но чистого, чем больше с мусором.
Пример workflow:
ШАГ 1: Найди в [большом документе] все упоминания про [тему X].
Выпиши цитаты списком.
ШАГ 2 (новый запрос): Вот цитаты про [тему X]:
[только отфильтрованные цитаты]
Теперь проанализируй паттерны.
Вместо "вот весь документ, найди тему X и проанализируй" → двухэтапный процесс с очисткой.
📊 Принцип 3: Адаптируй количество контекста под сложность
Простой вопрос — дай минимум контекста. Сложный multi-step вопрос — давай больше, но фильтруй.
Пример:
Простой вопрос:
Вот стенограмма встречи [5 страниц текста].
Какое решение приняли по бюджету?
→ Лучше: попроси сначала выдернуть только фрагмент про бюджет, потом дай инструкцию.
Сложный вопрос:
Вот 5 исследований рынка [прикрепляешь файлы].
Какие три тренда влияют на нашу нишу?
Как они связаны?
Какой из них будет доминировать через год?
→ Здесь нужен весь контекст, но попроси модель сначала извлечь релевантные фрагменты из каждого исследования, потом синтезируй.
Почему это работает
Слабость LLM: Модели не "читают" контекст равномерно. Attention mechanism в трансформерах распределяется неравномерно — начало и конец получают больше внимания, середина "размывается" (особенно в длинных контекстах). Нерелевантная информация создаёт шум в attention weights — модель "отвлекается" на неважные токены.
Сильная сторона LLM: Модели отлично работают с compact, structured, relevant context. Чем чище и яснее сигнал, тем лучше ответ. Recency bias (приоритет недавней информации) — это feature, не bug: последние токены в контексте имеют более "свежие" embeddings в процессе генерации.
Как использовать: 1. Фильтруй контекст жёстко — один проход на извлечение релевантного, второй на анализ 2. Ставь важное в конец — используй маркеры типа "КРИТИЧЕСКИ ВАЖНО:", "ГЛАВНЫЙ КОНТЕКСТ:" 3. Масштабируй контекст под задачу — не давай модели больше, чем нужно
Рычаги управления: - Объём контекста → меньше для простых задач, экономия токенов и выше точность - Позиция информации → переставь блоки — самое важное в конец - Маркеры важности → явно пометь "PRIMARY CONTEXT:", "SECONDARY CONTEXT:" — усиливает attention - Двухэтапный процесс → сначала "извлеки релевантное", потом "проанализируй" — вместо "вот всё, разберись"
Как это работает в Projects/длинных контекстах
Сценарий: У тебя 10 файлов с исследованиями конкурентов. Нужно найти их слабые места для pitch-презентации.
❌ Неэффективно:
[Загружаешь все 10 файлов в Project]
Найди слабые места конкурентов и предложи как нам их обыграть.
→ Модель получает огромный контекст, половина нерелевантна, середина потеряется.
✅ Эффективно (принципы из исследования):
ШАГ 1 (в Project):
Вот 10 исследований конкурентов [файлы].
Для КАЖДОГО конкурента извлеки:
- Ключевые слабости (проблемы продукта, жалобы клиентов)
- Пробелы в функциональности
Выдай таблицей: Конкурент | Слабости | Пробелы
ШАГ 2 (новый чат или продолжение):
Вот слабости конкурентов:
[копируешь таблицу из Шага 1]
НАШИ ПРЕИМУЩЕСТВА (самое важное — в конце):
- [наше УТП 1]
- [наше УТП 2]
- [наше УТП 3]
Как нам обыграть эти слабости в pitch-презентации?
Что изменилось: - Фильтрация (Принцип 2): Шаг 1 извлекает только релевантное, убирает шум - Позиционирование (Принцип 1): Наши преимущества в конце — модель сфокусируется на них - Адаптивный sizing (Принцип 3): Сложная задача → двухэтапный процесс с очисткой контекста
Ограничения принципов
⚠️ Длина контекста: В обычных чатах (без Projects) контекст ограничен. Эти принципы ценны для Projects, Artifacts, длинных диалогов — там где >10k токенов контекста.
⚠️ Субъективные задачи: Позиционирование влияет на factual tasks (анализ, извлечение фактов). Для креатива или brainstorming'а позиция менее критична.
⚠️ Trade-off времени: Двухэтапный процесс (фильтрация → анализ) требует больше запросов. Для простых задач ovеrhead не окупается.
Как исследовали
Команда взяла MuSiQue dataset — коллекцию вопросов, требующих 2, 3 или 4 шага рассуждений (multi-hop questions). Например: "В каком городе родился основатель компании, которая выпустила продукт X?" — нужно найти компанию, потом основателя, потом город рождения.
Для каждого вопроса есть "золотые" документы (правильные ответы где искать) и distractor'ы (похожие, но нерелевантные тексты). Исследователи систематически варьировали: 1. Сколько золотых документов дать (1, 2, 3, 4) 2. Сколько distractor'ов добавить (0, 1, 2) 3. Где разместить золотые документы (начало, середина, конец)
И измеряли качество ответов (Exact Match, F1-score). Результаты удивили масштабом влияния: один distractor роняет 2-hop вопросы на 26% — это огромно! Подтвердилась гипотеза "lost in the middle": середина игнорируется, конец работает лучше.
Затем обучили RoBERTa classifier (87.3% accuracy) предсказывать сколько документов нужно, и интегрировали Mistral Nemo как reranker для финальной фильтрации. Pipeline: ColBERT retriever → reranker (MonoT5 / BGE) → classifier → LLM-reranker → Flan-T5-XL generator.
Ключевой инсайт для практики: Даже с идеальным retriever'ом, distractor'ы в контексте убивают качество. А позиция релевантной информации в контексте — это бесплатная оптимизация, которую можно применить прямо сейчас.
Ресурсы
Dynamic Context Selection for Retrieval-Augmented Generation: Mitigating Distractors and Positional Bias
Датасеты: MuSiQue-Ans, 2WikiMultihopQA, MultihopRAG
Maya Iratni, Mohand Boughanem, Taoufiq Dkaki — Institut de Recherche en Informatique de Toulouse (IRIT), France