TL;DR
Исследователи измерили, какую часть контекста LLM реально используют для предсказания следующего токена. На документах длиной 1-7k токенов из шести датасетов (Reddit, новости CNN, правительственные отчёты, расшифровки встреч, книги) они обнаружили: 75-80% последовательностей требуют только последние 32-96 токенов для точного предсказания. Это работает даже на "длинно-контекстных" данных типа отчётов на 6-7k токенов — модель всё равно опирается преимущественно на локальный хвост.
LLM демонстрируют short-context bias — склонность полагаться на ближайшую информацию даже когда нужен long-range reasoning. Причина: в обучающих данных большинство токенов действительно предсказуемы из локального контекста (это свойство естественного языка), и модель усваивает этот паттерн. Результат: она завышает вероятности "безопасных" токенов-заполнителей, которые звучат локально связно, но игнорируют информацию из начала документа.
Исследователи разработали метрику LSDS (Long-Short Distribution Shift) — разницу между распределениями вероятностей модели при доступе к последним 32 токенам versus полному контексту. Если LSDS > 0.6 — последовательность требует длинного контекста, если < 0.4 — короткого достаточно. Также создали алгоритм TaBoo, который детектирует long-context последовательности и бустит токены, вероятность которых растёт при доступе к полному контексту. На QA-задачах это улучшает точность.
Схема эффекта
ДОКУМЕНТ (7000 токенов):
[Токены 1-6900: ранний контекст] → [Токены 6901-6968: последние 32-96] → [?]
↑
LLM смотрит сюда
в 75-80% случаев
ПРОБЛЕМА:
Информация в токенах 1-6900 → часто игнорируется
Модель предсказывает → локально связный, но глобально неточный токен
ДЕТЕКЦИЯ (LSDS):
1. Сгенерируй распределение P_short (последние 32 токена)
2. Сгенерируй распределение P_full (весь контекст)
3. Измерь JSD(P_short, P_full)
• JSD < 0.4 → short-context, локальной инфо хватает
• JSD > 0.6 → long-context, нужна инфо из начала
Применимые принципы
Принцип 1: Размещай ключевую информацию ближе к концу
Инсайт: Модель работает как человек, читающий с концентрацией на последнем абзаце. Информация из начала документа имеет меньше шансов повлиять на ответ.
Применение:
❌ Слабая структура:
Контекст: [5000 токенов про компанию]
Вопрос: "Какую должность занимал Иванов в 2020 году?"
(Инфо про Иванова — в токенах 500-600)
✅ Сильная структура:
Вопрос: "Какую должность занимал Иванов в 2020 году?"
Релевантный контекст: [выдержка про Иванова из токенов 500-600]
Дополнительно: [остальной контекст, если нужен]
Практика: В длинных документах (отчёты, расшифровки, обзоры) сначала формулируй задачу, затем давай контекст. Или явно напоминай о ключевых фактах из начала перед вопросом.
Принцип 2: Проверяй long-context reasoning через сравнение
Инсайт: Если модель даёт одинаковый ответ на полный и короткий контекст — она использует только короткий. Если ответы различаются — полный контекст что-то меняет.
Техника — "Short-vs-Full Test":
Задача: Проверить, использует ли модель информацию из всего контекста или только из конца.
Промпт 1 (короткий контекст):
Прочитай последние 200 слов документа:
[последние 200 слов]
Вопрос: {твой вопрос}
Ответь кратко.
Промпт 2 (полный контекст):
Прочитай весь документ:
[полный документ]
Вопрос: {твой вопрос}
Ответь кратко.
Анализ: - Ответы идентичны → модель опирается на локальный контекст, ранняя информация не влияет - Ответы различаются → полный контекст добавляет нюансы, модель учитывает раннюю информацию - Если различаются, но короткий контекст "звучит увереннее" → это short-context bias в действии
Пример применения:
Допустим, ты анализируешь расшифровку встречи на 10 страниц. В начале обсуждали риски проекта, в конце — план запуска. Спрашиваешь: "Стоит ли запускать проект?"
- Запроси ответ на основе последних 2 страниц → получишь оптимистичный ответ про план
- Запроси ответ на весь документ → если модель использует начало, упомянет риски
Разница показывает: учитывает ли модель ранний контекст или "забывает" его.
Принцип 3: Явно ссылайся на ранний контекст
Инсайт: Если информация критична и находится в начале документа — заставь модель вспомнить её через явную инструкцию.
Применение:
❌ Надежда на автоматическое внимание:
[Документ 5000 токенов, ключевая метрика в токене 300]
Вопрос: "Какой вывод?"
✅ Явное напоминание:
Вопрос: "В начале документа (раздел 2) упоминалась метрика X = 45%.
Учитывая эту метрику и остальной контекст, какой вывод?"
✅ Якорная структура (для очень длинных документов):
Прочитай документ и выдели 5 ключевых фактов, включая информацию из начала.
[Документ]
Теперь, опираясь на эти факты, ответь: {вопрос}
Принцип 4: Создавай "контекстные якоря"
Инсайт: В длинных диалогах или документах периодически напоминай модели о ключевой информации из начала.
Техника — "Промежуточные саммари":
Для длинного диалога (>20 сообщений):
Каждые 10-15 сообщений:
Подытожим, что мы выяснили до сих пор:
1. [Ключевой пункт из начала диалога]
2. [Ключевой пункт из середины]
3. [Текущее положение]
Теперь продолжим: {следующий вопрос}
Для анализа длинного документа:
Документ разбит на 3 части. Анализируй последовательно:
Часть 1 (токены 1-2000): Выдели 3 ключевых факта.
Часть 2 (токены 2001-4000): Выдели 3 ключевых факта.
Часть 3 (токены 4001-6000): Выдели 3 ключевых факта.
Теперь, используя все 9 фактов, ответь на вопрос: {вопрос}
Пример применения:
Ты работаешь над стратегией продукта, обсуждаешь с Claude 30 сообщений. В начале диалога определили целевую аудиторию — предприниматели 25-35 лет. Сейчас обсуждаете каналы продвижения.
Вместо:
Какие каналы лучше?
Пиши:
Напомню: наша ЦА — предприниматели 25-35 лет, которые ценят скорость и автоматизацию (обсудили в начале).
Какие каналы продвижения подойдут именно этой аудитории?
Явное напоминание форсирует модель учесть ранний контекст, а не генерировать "локально связный" ответ про "SMM и контент-маркетинг".
Почему это работает
LLM устроены так, что каждый токен может "смотреть" на все предыдущие через механизм attention. Но вес внимания распределяется неравномерно — механизм attention учится во время обучения, на каких токенах фокусироваться. А в обучающих данных (книги, статьи, диалоги) большинство токенов предсказуемы из ближайших 32-96 токенов — это свойство естественного языка. Мы пишем связно, локальная когерентность важнее глобальной структуры.
Результат: модель усваивает паттерн "короткого контекста достаточно" и применяет его по умолчанию. Когда встречается задача, требующая long-range reasoning (например, "сопоставь факт из токена 500 с фактом из токена 5000"), модель склонна генерировать локально связный, но глобально неточный ответ — тот, который "звучит правдоподобно" исходя из последних 100 токенов.
Второй эффект: позиционное затухание. Чем дальше токен от текущей позиции, тем слабее его влияние на предсказание (даже если технически attention может до него "дотянуться"). Это не баг, а следствие обучения — модель училась на данных, где дальние токены редко критичны.
Практический вывод: Если ты хочешь, чтобы модель учла информацию из начала документа/диалога — не полагайся на автоматическое внимание. Либо помести информацию ближе к концу (принцип 1), либо явно укажи на неё (принцип 3), либо создай промежуточный саммари (принцип 4). Модель не "забывает" начало, но её attention-веса естественным образом склоняются к ближайшим токенам.
Ограничения принципов
⚠️ Не универсальная проблема: В некоторых задачах (например, суммаризация, где нужно охватить весь документ) модели обучены лучше использовать полный контекст. Short-context bias сильнее проявляется в генерации следующего токена и ответах на вопросы, где можно "выкрутиться" локально связным текстом.
⚠️ Зависит от модели и обучения: Модели, специально обученные на long-context задачах (например, с контекстом 32k+ токенов), демонстрируют меньший bias. Но даже они склонны опираться на локальный контекст для большинства токенов.
⚠️ Техника сравнения требует двух запросов: "Short-vs-Full Test" удваивает количество токенов и время. Применяй выборочно — для критичных решений или проверки гипотез, не для каждого промпта.
⚠️ Явные напоминания могут перегрузить промпт: Если документ 10k токенов и ключевых фактов 20 — не пытайся впихнуть все в финальный промпт. Используй промежуточные саммари (принцип 4) или chain-of-thought с явным извлечением фактов из разных частей.
Как исследовали
Команда из University of British Columbia и Google DeepMind проверила гипотезу simple: "А действительно ли LLM используют весь доступный контекст?" Взяли 6 датасетов: короткие документы (Reddit, новости CNN, Wikipedia 1k токенов) и длинные (правительственные отчёты, расшифровки встреч, книги 6-7k токенов). Для каждого датасета сэмплировали 10,000 уникальных последовательностей и их ground-truth следующих токенов.
Методология: постепенное усечение контекста. Для каждой последовательности они давали модели сначала последние 32 токена, потом 48, 64... до полного контекста, пока модель не предскажет правильный токен с уверенностью >0.2 (разница вероятностей между топ-1 и топ-2 токеном). Это назвали Minimal Context Length (MCL) — минимальная длина префикса для точного предсказания.
Результат: распределение MCL оказалось heavy-tailed (длинный хвост в логарифмической шкале). 75-80% последовательностей имеют MCL ≤ 32-96 токенов. Даже на "длинно-контекстных" данных типа Government Reports на 6-7k токенов паттерн сохраняется — большинство токенов предсказуемы из локального хвоста. Power-law экспонента b ∈ [-2.5, -1.5] подтверждает сильное затухание — чем длиннее контекст требуется, тем экспоненциально реже такие случаи.
Удивительный факт: даже на специально отобранных long-context датасетах (книги, многостраничные отчёты) — где по идее нужно отслеживать сюжет, персонажей, раннюю информацию — модель всё равно в 75-80% случаев опирается на последние 100 токенов. Это говорит не о слабости моделей, а о свойстве естественного языка: локальная связность доминирует над глобальной структурой в генерации текста токен-за-токеном.
Дальше они разработали DaMCL (Distribution-aware MCL) — версию метрики, которая не требует знания ground-truth токена. Вместо "правильный/неправильный токен" они сравнивали распределения вероятностей при коротком и полном контексте через Jensen-Shannon Distance (JSD). Если JSD < 0.2 — распределения близки, короткого контекста хватает. Результаты DaMCL подтвердили паттерн MCL: short-context dominance сохраняется.
Финальный шаг: детектор long-context последовательностей. Метрика LSDS (Long-Short Distribution Shift) = JSD между распределениями при 32 токенах vs полном контексте. Проверили на контролируемом эксперименте "needle-in-haystack" (ответ либо в последних 32 токенах, либо глубже) — чёткое разделение: short-context последовательности имеют LSDS < 0.4, long-context > 0.6. На реальных данных сравнили с оракулами (которые знают ground-truth токен) — 80-90% long-context последовательностей корректно детектируются при пороге 0.6, ложные срабатывания < 5-10%.
Инсайт для практики: standard training objectives (next-token prediction) и метрики (perplexity) inherently biased в сторону short-range dependencies — потому что это доминирующий паттерн в данных. Это объясняет, почему модели "плохо работают на long-context" — они не плохо обучены, они оптимизированы под реальное распределение, где long-context редок.
Адаптации и экстраполяции
🔧 Техника: Forced Long-Context Reasoning
Если знаешь, что задача требует информации из разных частей документа — форсируй модель явно извлечь факты из каждой части, прежде чем отвечать.
Документ ниже содержит важную информацию в разных разделах.
Шаг 1: Прочитай Раздел 1 (первая треть) и выдели 2-3 ключевых факта.
Шаг 2: Прочитай Раздел 2 (средняя треть) и выдели 2-3 ключевых факта.
Шаг 3: Прочитай Раздел 3 (последняя треть) и выдели 2-3 ключевых факта.
[Документ]
Шаг 4: Используя факты из всех трёх разделов, ответь на вопрос:
{вопрос}
Эффект: Модель не может "соскользнуть" на локально связный ответ из последней трети — она уже зафиксировала факты из начала и середины в рабочей памяти (своём выводе на шагах 1-2).
🔧 Техника: Explicit Dependency Mapping
Для анализа, где нужно сопоставить информацию из разных мест (например, сравнить упоминания персонажа в начале и конце книги, или сопоставить метрики из разных кварталов).
Задача: {твоя задача, требующая сопоставления информации}
Шаг 1: Найди в документе все упоминания/данные о {топик А}.
Шаг 2: Найди в документе все упоминания/данные о {топик Б}.
Шаг 3: Сопоставь найденное и выяви изменения/связи/противоречия.
[Документ]
Теперь выполни все три шага.
Пример: Анализируешь бизнес-план. В начале документа — целевая аудитория "SMB компании". В середине — описание продукта для enterprise. В конце — ценообразование для массового рынка.
Промпт:
Задача: Проверь согласованность целевой аудитории в бизнес-плане.
Шаг 1: Найди все упоминания целевой аудитории в документе.
Шаг 2: Выпиши, какая аудитория указана в каждом разделе (продукт, маркетинг, ценообразование).
Шаг 3: Есть ли противоречия? Если да — какие и как их исправить?
[Бизнес-план]
Выполни все три шага.
Модель вынуждена пройтись по всему документу и явно извлечь информацию, вместо того чтобы ответить на основе последнего раздела.
Ресурсы
Short-Context Dominance: How Much Local Context Natural Language Actually Needs?
Vala Vakilian, Zimeng Wang (University of British Columbia), Ankit Singh Rawat (Google DeepMind), Christos Thrampoulidis (University of British Columbia)
Код: github.com/vala-vakilian/ShortContextDominance