Как вы измеряете reasoning degradation с ростом контекста? (curse of length)

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

Reasoning degradation — это ухудшение способности LLM выполнять логические рассуждения по мере увеличения длины входного контекста. Измеряется путём фиксации точности (accuracy) на задачах, требующих многошагового вывода, при искусственном добавлении нерелевантного текста (шума). Хорошая модель теряет не более 10% accuracy при переходе от 1k к 100k токенов; плохая — падает более чем на 30%. Метрика критична для Agentic RAG, где агенты обрабатывают длинные истории диалогов и множество документов.

1. Термины: Reasoning degradation и Curse of length

Reasoning degradation (деградация рассуждений) — снижение качества логических цепочек, которые LLM строит при увеличении длины контекста. Проявляется в пропуске шагов, противоречиях, «забывании» релевантной информации.

Curse of length (проклятие длины) — эмпирическое наблюдение: чем длиннее контекст, тем хуже модель использует информацию из его середины (феномен lost in the middle). Это связано с ограничениями механизма self-attention — квадратичная сложность O(n²) и затухание внимания к дальним токенам.

Контекст — совокупность всех токенов, подаваемых на вход LLM: системный промпт, история диалога, retrieved документы, инструкция пользователя.

2. Почему происходит degradation

Основные причины:

• Self-attention bottleneck: веса внимания распределяются неравномерно; модель «фокусируется» на начале и конце контекста, игнорируя середину.
• Позиционные кодировки (RoPE, ALiBi): при длинах, превышающих обученные, экстраполяция даёт сбои.
• Шум от нерелевантных токенов: лишние детали отвлекают модель, снижая вероятность правильного вывода.
• Ограничения обучения: большинство моделей обучаются на контекстах до 4k–8k токенов; на длинах 32k+ performance падает.

3. Методология измерения

3.1 Выбор задачи для рассуждения

Идеальная задача должна:

• требовать многошагового логического вывода (например, математическая задача, цепочка фактов, multi-hop QA);
• иметь однозначный правильный ответ (для объективной метрики);
• быть чувствительной к шуму.

Примеры:

• GSM8K (математические задачи для начальной школы) — модифицируем, добавляя нерелевантные числа и условия.
• HotpotQA (multi-hop вопросы) — добавляем отвлекающие документы.
• Needle in a Haystack (поиск факта среди шума) — классический тест на recall, но не на reasoning.

Для чистого измерения reasoning лучше использовать задачи, где ответ нельзя получить простым копированием, а требуется композиция фактов.

3.2 Создание контекста с шумом

Берём задачу (например, «У Маши было 5 яблок, она отдала 2 Пете. Сколько осталось?»). Искусственно увеличиваем контекст, добавляя нерелевантный текст:

• Нейтральный шум: случайные предложения из Википедии, не связанные с задачей.
• Тематический шум: текст на ту же тему, но не содержащий ответа (например, описание других фруктов).
• Дистракторы: правдоподобные, но неверные факты, которые могут сбить модель.

Длины контекста: 1k, 2k, 4k, 8k, 16k, 32k, 64k, 100k токенов. Для каждой длины готовим не менее 100 примеров.

3.3 Метрики

Основная метрика — accuracy (доля правильных ответов). Дополнительно:

• F1-score (для ответов с частичным совпадением);
• Consistency (повторяемость ответа при нескольких прогонах с разным шумом);
• Faithfulness (отсутствие галлюцинаций, не подтверждённых контекстом) — измеряется через NLI-модель.

4. Экспериментальный протокол

4.1 Шаги

1. Выбрать бенчмарк (например, 200 задач из GSM8K).
2. Для каждой задачи сгенерировать 7 вариантов контекста с разной длиной шума.
3. Прогнать модель на всех вариантах, зафиксировать ответы.
4. Посчитать accuracy для каждой длины.
5. Построить кривую degradation: accuracy vs. длина контекста.

4.2 Пример кода (Python)

import numpy as np
from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "mistralai/Mistral-7B-Instruct-v0.2"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name, device_map="auto")

def measure_accuracy_at_length(tasks, noise_text, target_length):
    acc = 0
    for task in tasks:
        # Добавляем шум до target_length
        padded_context = task["question"] + noise_text[:target_length - len(tokenizer.encode(task["question"]))]
        inputs = tokenizer(padded_context, return_tensors="pt").to(model.device)
        output = model.generate(**inputs, max_new_tokens=50)
        answer = tokenizer.decode(output[0], skip_special_tokens=True)
        if task["correct_answer"] in answer:
            acc += 1
    return acc / len(tasks)

lengths = [1000, 2000, 4000, 8000, 16000, 32000, 64000, 100000]
accuracies = []
for L in lengths:
    acc = measure_accuracy_at_length(tasks, noise, L)
    accuracies.append(acc)
    print(f"Accuracy at {L}: {acc:.3f}")

4.3 Контрольные точки

• Базовый уровень: accuracy без шума (только задача).
• Порог деградации: длина, при которой accuracy падает ниже 80% от базового.
• Сравнение моделей: на одном бенчмарке.

5. Анализ результатов

5.1 Типичные паттерны

Интерпретация:

• Падение <10% при 100k → отличная устойчивость.
• Падение 10–30% → приемлемо для многих задач.
• Падение >30% → модель непригодна для длинных контекстов.

5.2 Визуализация

График: ось X — длина контекста (логарифмическая шкала), ось Y — accuracy. Кривая degradation позволяет быстро оценить, на какой длине модель «ломается».

6. Факторы, влияющие на degradation

• Архитектура attention: Flash Attention, sliding window attention (Mistral) улучшают обработку длинных контекстов.
• Позиционные кодировки: ALiBi (BLOOM) и RoPE (LLaMA) по-разному экстраполируют; YaRN (Yet another RoPE extensioN) улучшает extrapolation.
• Обучение на длинных контекстах: модели, дообученные на 32k+ токенов (например, LongLLaMA, Mistral Large), деградируют медленнее.
• Количество шума: не только длина, но и плотность дистракторов влияет на degradation.

7. Методы mitigation (смягчения)

• Re-ranking: перед подачей в LLM отфильтровывать нерелевантные чанки (с помощью cross-encoder).
• Selective attention: механизмы Attention Sink (StreamingLLM) или H2O (Heavy Hitter Oracle) для удержания важных токенов.
• Context window management: разбивать длинный контекст на окна и обрабатывать последовательно (например, RecurrentGPT, MemWalker).
• Fine-tuning на длинных контекстах: дообучение с примерами, где ответ находится в середине (против lost in the middle).
• Agentic RAG: агент может сам решать, какие документы читать, и не перегружать контекст.

8. Связь с Agentic RAG

В Agentic RAG агент:

• накапливает историю взаимодействий (длинный контекст);
• одновременно держит несколько retrieved документов;
• выполняет многошаговые рассуждения (planning, tool use).

Reasoning degradation напрямую влияет на качество агента: если модель «забывает» предыдущие шаги или документы, агент принимает неверные решения. Поэтому измерение degradation — обязательный этап при выборе backbone LLM для агента.

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

Задача: Сравнить degradation трёх open-source моделей (Mistral 7B, LLaMA 3 8B, Qwen 2 7B) на задаче multi-hop QA с шумом.

Инструменты:

• Python, Hugging Face Transformers, Datasets (HotpotQA).
• Библиотека для генерации шума: nltk или wikipedia-api.
• Визуализация: matplotlib.

Шаги:

1. Загрузить 200 вопросов из HotpotQA (требуют двух фактов).
2. Для каждого вопроса сгенерировать 6 вариантов контекста: без шума, +1k, +4k, +16k, +64k, +128k токенов шума (текст из Википедии на случайную тему).
3. Прогнать каждую модель на всех вариантах, записать accuracy.
4. Построить график degradation для трёх моделей.
5. Определить, какая модель лучше всего сохраняет reasoning при 128k.

Ожидаемый результат: Вы получите количественную оценку degradation и сможете аргументированно выбрать модель для Agentic RAG.

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

Навигация

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