Препринт RULER-2M появился на arXiv 24 мая. Авторы из NVIDIA, Princeton и DeepMind решили задачу, которую давно обходили стороной: проверить не то, умеет ли модель вообще замечать контент в дальних частях контекста, а то, способна ли она связно рассуждать по фрагментам, разнесённым на сотни тысяч токенов. Задача «найти иголку в стоге» стала бессмысленной — все актуальные модели берут её с точностью 99%+.
RULER-2M строится на семи типах задач. Три самые жёсткие — multi-hop reasoning (факты разнесены на 800K–1,2M токенов, нужно их соединить), coreference tracking (сущность упоминается под разными именами по всему документу) и structural understanding (секции документа перемешаны, надо восстановить логику). Остальные четыре проверяют constraint satisfaction, агрегацию данных и несколько гибридных сценариев. Общее у всех: одним локальным attention-окном задачу не решить.
Что показал leaderboard
Gemini 2.5 Pro занял первое место с 71,8% в агрегированном score по семи задачам. За ним Claude Opus 4.7 — 62,4%, GPT-5o — 58,1%, Llama 4 400B — 52,3%, DeepSeek-V3 — 49,7%. На первый взгляд цифры неплохие, но они маскируют резкое падение при увеличении дистанции между связываемыми фактами.
До 100K токенов между фрагментами все модели работают на 85–95%. На дистанции 500K–1M точность падает до 60–75%. Свыше 1,5M — до 35–55%. То есть формальная поддержка большого окна — это одно, способность рассуждать в нём — совсем другое. Ни одна из протестированных моделей не сохраняет на длинных дистанциях даже 60% качества коротких.
Интересный побочный результат — разрыв между Gemini 2.5 Pro и остальными на верхних дистанциях. При контексте 1,5M+ Gemini держит около 48%, тогда как все остальные модели уходят ниже 40%. Авторы связывают это с тем, что DeepMind целенаправленно оптимизировал под RULER-2M-подобные задачи при разработке Gemini 2.5. Отрыв тут не в базовых способностях — а в специализированном дообучении под конкретный класс задач.
Как устроена задача multi-hop reasoning
Чтобы понять, почему модели проваливаются, полезно разобрать механику самой задачи. В multi-hop сценарии документ содержит три фрагмента, каждый из которых раскрывает лишь часть нужной информации: первый называет персону и роль, второй — организацию и местоположение, третий — событие и дату. Все три разнесены равномерно по документу. Правильный ответ требует одновременного удержания всех трёх в «оперативной памяти» рассуждения.
Человек при работе с большим документом решает эту задачу через явные заметки или закладки: выписал ключевые факты, потом соединил. У языковой модели такого механизма нет — она линейно обрабатывает контекст через механизм attention. При достаточно большой дистанции между фрагментами ранние ключевые точки начинают «тонуть» в весах attention: они технически присутствуют в контексте, но влияние на итоговое рассуждение стремительно падает.
Distractor sensitivity и деградация цепочки мысли
Авторы выделяют два механизма провала. Первый — distractor sensitivity. На длинных контекстах модель начинает «подпирать» рассуждение косвенно связанными фрагментами, которые просто оказались рядом. Если в документе на 1M токенов есть три похожих имени или три похожих события, модель нередко смешивает их, даже когда каждое в отдельности описано точно. Это не лечится просто масштабированием модели — нужна либо архитектурная работа с attention, либо специализированное дообучение под long-range multi-hop.
Второй механизм — chain-of-thought decoherence. Когда reasoning занимает большое число токенов, модель теряет нить: вторая половина рассуждения противоречит первой, потому что та уже ушла за горизонт эффективного attention. На моделях с extended thinking эффект особенно заметен — сам мыслительный процесс вытесняет из окна ключевые части входа. Модель рассуждает «в пустоте», всё меньше опираясь на исходный документ.
Оба механизма указывают на одно: архитектура трансформера с полным attention по контексту сталкивается с фундаментальным ограничением на больших дистанциях. Масштабирование числа параметров этого не снимает — нужны другие подходы: разреженный attention, явные memory-механизмы или гибридные архитектуры с рекуррентными элементами.
Long context и RAG — взаимодополняющие техники
Практический вывод прямой: команды, которые кладут в контекст большие документы в расчёте на то, что модель «разберётся», систематически переоценивают её возможности. Если задача требует связать фрагменты на расстоянии 500K+ токенов, без предварительной обработки не обойтись: семантическое разбиение документа, векторный retrieval релевантных блоков, подача в модель только нужного среза.
Это прямо противоречит нарративу 2024 года, когда активно звучало «long context убьёт RAG». Результаты RULER-2M говорят иное: long-context и retrieval — взаимодополняющие техники. Long-context хорош там, где нужна связность и нет жёстких дистанционных ограничений — анализ книги целиком, обзор кода большого репозитория. RAG — там, где релевантная информация заведомо рассеяна по большому корпусу и её нужно сначала найти и ранжировать.
Для production-систем это означает конкретное архитектурное решение: даже если используемая модель декларирует поддержку 1M+ токенов, задачи с явными дальними зависимостями выиграют от предварительного retrieval. Экономический аргумент тоже работает: прогон через retrieval плюс подача в модель компактного среза дешевле, чем инференс на 1M-контексте при той же итоговой точности.
Что дальше
Авторы анонсировали RULER-10M — следующую версию с контекстами до 10 миллионов токенов. По их словам, для такого масштаба потребуется переработать методологию генерации задач: существующие подходы к синтетическим данным туда не масштабируются. Проблема не только техническая — при 10M токенов даже сам процесс верификации правильного ответа становится нетривиальным. Публикацию ждут в третьем квартале 2026 года.
Параллельно несколько команд уже экспериментируют с архитектурными ответами на ограничения, которые выявил RULER-2M. Среди наиболее активно обсуждаемых направлений — explicit memory augmentation: отдельный компонент, который умеет сохранять и запрашивать факты с произвольными индексами, не зависящими от позиции в контексте. Для задач multi-hop с большими дистанциями это выглядит перспективнее, чем дальнейший рост окна без изменения архитектуры.