Контекстное окно и агенты: почему миллион токенов не спасает

С чего всё началось

За 2024 год разработчики моделей соревновались в длине контекстного окна*. Google заявил для Gemini 1.5 Pro окно на 1 000 000 токенов с возможностью расширения до 2 000 000. Anthropic для Claude держит 200 000 токенов на большинстве тарифов. OpenAI у GPT-4o и семейства o1 объявляла 128 000 токенов. На бумаге это выглядит так, будто теперь в модель можно загрузить целую книгу или весь код проекта и получить связный ответ.

На практике агенты, которые опираются на весь этот объём разом, ведут себя хуже, чем ожидают их авторы. Модель с окном на миллион токенов уверенно теряет данные, которые лежат в середине запроса, и путается на длинных цепочках рассуждений. Длина окна и качество работы агента — не одно и то же, и разрыв между ними определяет, взлетит ваш продукт или будет выдавать правдоподобную чушь.

Что такое контекстное окно на самом деле

Контекстное окно — это максимальный объём текста, который модель обрабатывает за один запрос: и то, что вы прислали, и то, что она генерирует в ответ. Считается в токенах, а не в символах. Один токен для английского — примерно 4 символа или 0,75 слова; для русского текста токенов на тот же текст уходит заметно больше, потому что кириллица дробится на более мелкие куски.

Важное следствие: окно на 200 000 токенов — это не 200 000 токенов под ваш вопрос. Часть съедает системный промпт, часть — история диалога, часть резервируется под ответ. Для агента, который ведёт многошаговый диалог и подтягивает документы, реально доступный бюджет всегда меньше заявленного максимума.

Проблема «потерянного в середине»

Ключевая находка исследователей: модели с длинным окном обрабатывают начало и конец запроса лучше, чем середину. Эффект описан в работе «Lost in the Middle» (Liu et al., 2023): когда нужный факт лежит в середине длинного контекста, точность ответа падает по сравнению с тем же фактом в начале или в конце. Форма графика точности — буква U.

Длинное окно не значит, что модель одинаково внимательна к каждому токену внутри него. Внимание распределено неравномерно, и середина проседает первой.

Для агента это критично. Если вы сложили в контекст десять извлечённых документов и релевантный оказался пятым, модель может его просто не заметить — не потому что не поняла, а потому что не «дочитала» с должным вниманием. Отсюда парадокс: агент с меньшим, но чистым контекстом нередко точнее агента, которому скормили всё подряд.

Сравнение по окну и поведению

Цифры ниже — заявленные вендорами максимумы на конец 2024 года. Проверяйте актуальные значения в документации: они меняются с новыми версиями.

Само по себе большее окно не делает модель «умнее» — оно лишь снимает ограничение на объём входных данных. Качество внутри окна измеряется отдельными тестами вроде «needle in a haystack» (поиск факта-иголки в длинном стоге текста), и результаты у разных моделей отличаются даже при формально одинаковом окне.

Как окно влияет на агента

Агент** отличается от простого чат-бота тем, что действует в несколько шагов: планирует, вызывает инструменты, читает результаты, корректирует план. Каждый шаг дописывается в контекст. И тут окно бьёт по агенту с трёх сторон.

• Раздувание истории. После десятка вызовов инструментов история занимает десятки тысяч токенов. Ранние важные инструкции уезжают в ту самую середину и теряют вес.
• Стоимость и задержка. Вы платите за входные токены. Агент, который таскает за собой весь контекст на каждом шаге, обходится дороже и отвечает медленнее — латентность растёт с длиной входа.
• Отвлечение. Лишние документы в контексте не нейтральны: они конкурируют за внимание модели и повышают шанс, что ответ уедет не туда.

Что делают вместо гонки за длиной

Практика сместилась от «залей всё в окно» к управлению контекстом. Основные приёмы:

1. RAG вместо полной загрузки. Retrieval-Augmented Generation*** подтягивает только релевантные фрагменты под конкретный запрос, а не весь корпус. Меньше шума — выше точность.
2. Сжатие истории. Старые шаги диалога сворачиваются в краткое резюме, а не тащатся дословно.
3. Размещение важного по краям. Критичные инструкции ставят в начало и повторяют в конце запроса, обходя провал в середине.
4. Отбор документов по релевантности. Вместо десяти фрагментов подают три-четыре самых близких, отсортированных по оценке.

Кому это пригодится и кому нет

Пригодится: тем, кто строит агента для работы с большими наборами документов — юридические базы, техдокументация, поддержка клиентов. Здесь понимание, что окно не спасает от потери данных в середине, напрямую влияет на архитектуру: вы заранее закладываете RAG и отбор фрагментов, а не надеетесь на объём.

Пригодится: разработчикам многошаговых агентов, где история диалога растёт. Знание про раздувание контекста экономит деньги на токенах и держит стабильность на длинных сессиях.

Не критично: для коротких разовых запросов — «перепиши абзац», «объясни термин». Там весь ввод помещается в начало окна, провал середины не задевает, и переусложнять архитектуру нет смысла.

Не заменит проверку: длинное окно не делает модель фактически точной. Если данные в контексте противоречивы или устарели, большое окно лишь аккуратнее пересказывает ошибку.

* Контекстное окно — максимальный объём текста в токенах, который модель обрабатывает за один запрос, включая ваш ввод, историю и её собственный ответ.

** Агент — система на базе модели, которая решает задачу в несколько шагов: планирует действия, вызывает внешние инструменты и корректирует план по их результатам, а не отвечает одним сообщением.

*** RAG (Retrieval-Augmented Generation) — подход, при котором модель перед ответом получает не весь корпус данных, а только релевантные фрагменты, найденные поиском по запросу.