ИИ🔥
Проблема деградации внимания в LLM при больших контекстных окнах
Анализ бенчмарков Context Arena: почему 1М контекст часто является фикцией и как деградирует качество ответов моделей при заполнении окна.
1М контекстное окно - прорыв или фикция?
Context Arena забенчмаркали стойкость контекста для GLM 5.2 и Opus 4.8 - значит, это хороший повод нам вспомнить про контекстную инженерию.
На бенчмарке отчетливо видна существенная просадка внимательности моделей на 512к контексте: в среднем, почти в 2 раза в сравнении с 64к контекстом и примерно в 1.5 раз в сравнении с 128к контекстом - грубо говоря, для нас с вами это означает то, что на 512к контексте агент будет терять в полтора раза больше деталей, чем на при 128к заполненности. Для открытых моделей проблема потери контекста особенно актуальна, поэтому практический вывод такой, что по-хорошему, с ними стоит держать заполненность контекстного окна не выше 128к, а лучше даже меньше - ни о каком 1М, конечно, и речи не идет, там просадка будет колоссальной. Кстати, у моделей Kimi K2.6 и, тем более, Minimax M3 дела обстоят еще хуже.
Что еще? Открыв закрытых моделей на большом контексте от открытых все еще впечатляет, хоть уже и не такой драматичный - спасибо DeepSeek за DeepSeek Sparse Attention, которую в GLM-5.2 развили через IndexShare. Кстати, о GLM 5.2 - как видно, моделька действительно на удивление успешная в т. ч. на больших контекстах. Opus 4.8 идет рядышком с GPT 5.5, но последняя все равно сильнее, особенно на совсем больших контекстах. На этом месте вспоминаем интересную деталь - в Codex App по дефолту контекстное окно для GPT 5.5 все еще 256к - то есть, по сути, точность всегда остается где-то на уровне 75%+- (по MRCRv2), а благодаря превосходному алгоритму компактизации, команде Codex удается сохранить все действительно важное так, что эти компактизации обычно и не заметны вовсе - то есть, конкретно в случае с Codex проблему контекстной инженерии ребята здорово решили на уровне модели и на уровне Harness (обвязки), в то время, как Claude Code в этом аспекте требует чуть больше ручной работы - модель на 1M контекста там включается прямо в выпадающем списке (велик соблазн ее включить), но кажется, что простой обыватель зачастую не очень понимает, что переключение на эту модель потребует от него ручного управления контекстом - как только контекст переваливает за условные 200к, начинается зона риска, в которой нужно либо переходить в новый чат, либо, хотя бы, вызывать компактизацию - что и приходилось делать. Что уж говорить, что пользователям открытых моделей за загрузкой контекста все еще стоит следить куда пристальнее. Короче, в 2026-м контекстную инженерию (в которую входит контроль % заполнения контекстного окна) пока никто не отменял - чем больше забит контекст, тем сильнее приходится надеятся на удачу.
И, конечно, не забываем про контроль AGENTS.md, скиллов, MCP, progressive disclosure и т. д. - тоже все составляющие context engineering, с открытыми моделями все это становится еще важнее.
Кстати, современная версия Context Arena прогоняет бенчмарк MRCRv2 от Google DeepMind (GDM-MRCRv2).
Paper про MRCRv2 (Michelangelo)
Датасет MRCRv2
А как вы менеджите контекст? Обращаете ли внимание на % заполнения? Наблюдаете ли просадки в качестве output модели на больших контекстах?
@ai_driven
Кратко (AI)
Автор анализирует результаты бенчмарка Context Arena, показывая, что при увеличении контекста до 512к и выше качество работы моделей (включая GLM и Opus) существенно падает. Делается вывод, что контекстная инженерия остается критически важной, а использование огромных окон без контроля заполнения ведет к потере деталей и ошибкам.