Как делать evaluation для long-context RAG (>100k токенов)?

Краткий тезис

Оценка Context Context long-context RAG (с контекстом >100k токенов) требует специальных метрик и бенчмарков, так как стандартные подходы (например, точность извлечения релевантных фрагментов) становятся непрактичными из-за огромного объёма. Основные методы включают тесты «Needle in a Haystack» (поиск иголки в стоге сена), Multi-needle (несколько зависимых фактов) и продвинутые бенчмарки RULER и LongBench. Ключевая проблема — дороговизна полной эвалюации на реальных данных; необходимы эффективные прокси-метрики и автоматизированные пайплайны.

1. Термин: Long-Context RAG

Context Context Long-Context RAG — это модификация классического Retrieval-Augmented Generation, в которой контекстное окно модели (например, GPT-4-32k, Claude 100k, Gemini 10M) позволяет передавать в промпт не только десятки, но и сотни тысяч токенов. Это даёт возможность подавать на вход несколько полных документов или всю историю чата без агрессивного chunking’а.

Чем отличается от обычного RAG

• Обычный RAG: ретривер отбирает чанки ≤ 4k токенов, генератор видит только их.
• Long-Context RAG: ретривер может вернуть гораздо больше (десятки чанков) или даже почти всю базу; генератор обрабатывает гигантский контекст.

Проблема эвалюации при контексте > 100k токенов невозможно вручную проверить каждый ответ на соответствие всем фактам, поэтому нужны автоматизированные сценарии с контролируемой «иголкой».

2. «Needle in a Haystack» (NIAH) — классический тест

Суть Вставляем один факт («иголку») в случайное место внутри большого нерелевантного текста («стог сена»). Задаём вопрос о факте и смотрим, воспроизводит ли модель ответ.

Метрика Recall (доля извлечённых иголок) в зависимости от позиции иголки в контексте.

Как строят график по оси X — длина контекста (например, 4k, 16k, 64k, 128k), по оси Y — точность ответа на вопрос. Для каждой длины пробуют разные позиции иголки (начало, середина, конец). Идеальная модель — 100% recall на всех позициях.

Результат

• Многие модели «теряют» информацию в середине (эффект lost in the middle).
• Для long-context RAG нужно, чтобы ретривер помещал важные чанки в начало или конец контекста, а не в середину.

Реализация (Python, псевдокод):

def needle_in_haystack(model, haystack_text, needle, position_ratio, question):
    # position_ratio = 0.0 (начало) ... 1.0 (конец)
    insert_pos = int(len(haystack_text) * position_ratio)
    context = haystack_text[:insert_pos] + " " + needle + " " + haystack_text[insert_pos:]
    prompt = f"Контекст:\n{context}\n\nВопрос: {question}\nОтвет:"
    answer = model.generate(prompt)
    return is_correct(answer, expected_answer)  # 1 или 0

Когда использовать Первичная проверка способности модели извлекать единичные факты из длинного контекста.

3. Multi-needle — проверка на рассуждения

Multi-needle — расширение NIAH, где в стог сена помещается несколько связанных фактов (например, «У Алисы рост 170 см», «У Боба рост 180 см»). Вопрос требует объединения информации: «Кто выше: Алиса или Боб?»

Почему это сложнее модель должна не просто прочитать, но и установить логические связи между разнесёнными фактами. Метрика — точность ответа на вопросы, требующие multi-hop reasoning.

Применение в long-context RAG если ретривер возвращает много документов, генератор может «забыть» один из фактов. Multi-needle выявляет эту проблему.

Вариации:

• Needle-in-a-multidoc-Haystack несколько документов, каждый содержит часть нужной информации.
• Cross-document NIAH факты распределены по разным документам, что требует от ретривера собрать их вместе.

4. RULER — продвинутый бенчмарк (2024–2025)

RULER (Retrieval of Understanding Long-context with Entity Recognition) — бенчмарк, который проверяет не только recall, но и точность извлечения определённых сущностей из длинного контекста. Включает тесты с множественными отношениями и дистракторами.

Типы задач в RULER

• Single-token NIAH один факт (как в базовом NIAH).
• Multi-token NIAH факт из нескольких токенов (например, полное имя и дата).
• Variable-token NIAH изменяемая длина иголки.
• Entity Tracking отслеживание изменения состояния сущности (например, «дверь открыта → дверь закрыта»).
• Common Words Extraction извлечение часто встречающихся слов, зашумлённых контекстом.

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

Метрика F1-score или точность на каждом типе задач. Хороший показатель — >90% для Single-token, >80% для Multi-token в контексте 128k.

Как использовать запуск на готовом датасете; результаты сравнивают модели. RULER есть на GitHub (https://github.com/nicklashansen/[ruler](/wiki/RULER)).

5. LongBench — комплексный бенчмарк

LongBench — набор из 21 задачи на длинный контекст, охватывающий разные сценарии: однодокументный QA, многодокументный QA, суммаризация, few-shot learning, синтетические тесты (включая NIAH).

Категории задач

Метрики: для каждой задачи своя (F1, ROUGE-L, точность). Общий итог — среднее по всем задачам.

Проблема LongBench даёт стандартизированную оценку, но его задачи могут не отражать специфику конкретного RAG-приложения (например, юридического или медицинского).

Инструмент: библиотека longbench позволяет запускать оценку на своих моделях.

6. Оценка реального long-context RAG: подходы и метрики

Кроме бенчмарков, необходимо оценивать RAG-систему в продакшене. Для long-context RAG (>100k) прямые методы (полный ручной разбор) слишком дороги.

6.1 Прокси-метрики на уровне ретривера

• Recall@k с учётом сегментов разбиваем каждый документ на сегменты по 10k токенов, оцениваем, сколько сегментов, содержащих ответ, попало в контекст.
• Context Coverage доля от всех релевантных фактов, присутствующих в отобранном контексте (не обязательно на них отвечать, достаточно их наличия).

6.2 Оценка генерации с LLM-судьёй

Используем другую LLM (например, GPT-4) для проверки фактов в ответе на соответствие контексту.

Палочка

def faithfulness_score(answer, context, judge_model):
    prompt = f"""Проверь, содержит ли ответ только факты из контекста.
    Контекст: {context}
    Ответ: {answer}
    Оцени faithfulness от 0 до 1, где 1 — все факты из контекста."""
    return float(judge_model.generate(prompt))

Но для контекста >100k токенов это дорого (потребляет много токенов) и может не помещаться в окно судьи. Решение — sentence-level evaluation: разбить контекст на части, проверять каждое утверждение в ответе отдельно, используя только соответствующий кусок контекста.

6.3 Human evaluation на выборке

Случайно выбираем 100–200 вопросов, человек оценивает правильность и полноту ответа. Дорого, но необходимо для валидации прокси-метрик.

7. Проблемы и ограничения эвалюации long-context RAG

1. Стоимость каждый прогон long-context генерации стоит много токенов. Для систем с тысячью запросов в день затраты могут быть неприемлемы.
2. Отсутствие золотого стандарта для реальных данных редко существует полный набор правильных фактов. Приходится полагаться на синтетические данные.
3. Сложность интерпретации если модель плохо отвечает на NIAH-вопросы, это может быть связано как с ретривером (иголка не попала в контекст), так и с самой моделью (не смогла извлечь). Поэтому эвалюация должна быть двухуровневой: сначала проверяем, что ретривер доставил нужные факты, потом — что генератор их использовал.
4. Позиционный bias эффект lost in the middle — модель лучше работает с информацией в начале и конце контекста. При оценке нужно учитывать позицию.
5. Необходимость мульти-игольных тестов одиночные факты слишком просты; реальные вопросы требуют соединения разрозненных деталей.

8. Практический пайплайн оценки long-context RAG

Шаг 1 Выбираем бенчмарк (RULER или LongBench) для baseline-проверки модели.

Шаг 2 Адаптируем NIAH под свой датасет:

• Берём реальные документы как «стог сена».
• Вставляем синтетический факт (например, «Секретный код: 1234»).
• Задаём вопрос про код.
• Измеряем recall для разных длин контекста и позиций.

Шаг 3 Запускаем multi-needle с 2–3 перекрёстными фактами.

Шаг 4 Для продакшен-данных используем прокси-метрики:

• Retrieval success rate доля запросов, где в top-k (например, top-50) есть хотя бы один чанк, содержащий правильный ответ.
• Faithfulness на сэмпле 100 запросов → человек проверяет ответы → корректируем эвристики судьи-LLM.

Шаг 5 Мониторинг дрейфа: регулярно повторяем NIAH на свежих данных, чтобы убедиться, что система не деградировала.

Пет-проект для закрепления

Задача Реализовать эвристическую систему оценки long-context RAG на открытом датасете (например, long-rag-bench или адаптировать needle-in-a-haystack).

Инструменты

• Python, Hugging Face Transformers, LangChain (для RAG-пайплайна).
• БД: Chroma или FAISS для векторов.
• Модель: любая open-source 7B+ (например, Mistral-7B-Instruct, Llama-3-8B-128k для длинного контекста).
• Библиотеки: tqdm, numpy, pandas для анализа.

Шаги:

1. Создать датасет «стогов сена»: набрать 1000 длинных текстов (PDF-книги, статьи) и нарезать в чанки по 512 токенов.
2. Сгенерировать иголки: случайные факты (например, «Имя: Джейн, возраст: 27, город: Бостон»).
3. Для каждого теста: вставить иголку в случайное место случайного документа. Задать вопрос про иголку.
4. Построить RAG-пайплайн:
   • Ретривер (top-k = 50, контекст ~15k токенов).
   • Генератор (модель с окном 128k).
5. Оценить recall@k для разных k (10, 20, 50) и для разных позиций иголки (0%, 25%, 50%, 75%, 100%).
6. Повторить с multi-needle (2 иголки, вопрос на сопоставление).
7. Построить heatmap: длина контекста (x) vs позиция иголки (y) vs recall (цвет).

Ожидаемый результат

• Таблица с recall для разных конфигураций.
• График зависимости recall от позиции иголки — обнаружение «мёртвой зоны» в середине.
• Вывод: как изменение параметров ретривера (k, тип эмбеддинга, chunking) влияет на способность извлекать иголки.
• Пулл-реквест в open-source репозиторий с улучшенной метрикой (например, weighted recall с учётом позиции).

Связь с другими вопросами

Навигация

• Предыдущий: 878
• Следующий: 880
• Индекс: 00. Индекс разборов