Токены и контекстное окно

Если из всего раздела про модели запомнить одну вещь, пусть это будет она: у модели нет памяти, а есть только контекст, и он ограничен. Контекст измеряется в токенах, за токены вы платите, и именно нехватка или замусоренность контекста — самая частая причина того, что «агент отупел». Разберёмся по порядку.

Токен — единица текста

Модель видит не буквы и слова, а токены (token): куски текста, на которые специальный алгоритм (токенизатор) режет любой вход. Токеном может быть целое слово, часть слова, знак препинания. Частые слова обычно занимают один токен, редкие разбиваются на несколько: «программирование» может превратиться в «программ» + «ирование».

Для прикидок хватает грубых соотношений:

английский текст: 1 токен ≈ 4 символа, 100 токенов ≈ 75 слов;
страница текста — порядка 500 токенов, среднее письмо — 200–400 токенов;
код токенизируется плотнее обычного текста из-за скобок, отступов и служебных символов.

Русский язык — важная особенность. Токенизаторы обучены преимущественно на английском, поэтому русский текст режется мельче: то же самое содержание занимает примерно в полтора-два раза больше токенов, чем его английский перевод (точный коэффициент зависит от токенизатора конкретной модели). Практические следствия: за русскоязычные промпты вы платите больше, и контекст ими заполняется быстрее. Это не повод отказываться от русского (модели прекрасно его понимают), но это стоит учитывать при подсчёте объёмов и стоимости.

Контекст — всё, что модель видит

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

системный промпт — инструкции харнеса: кто ты, какие у тебя правила, какие есть инструменты;
файлы памяти — CLAUDE.md / AGENTS.md с описанием проекта (см. «Память»);
вся история диалога — ваши сообщения и ответы модели с начала сессии;
содержимое файлов, которые агент прочитал;
результаты инструментов — вывод команд, логи, ответы API, результаты поиска.

flowchart TB
    subgraph W ["Контекстное окно — жёсткий лимит в токенах"]
      direction TB
      SP["Системный промпт"]
      MEM["Файлы памяти: CLAUDE.md / AGENTS.md"]
      HIST["Вся история диалога"]
      FILES["Содержимое прочитанных файлов"]
      TR["Результаты инструментов: логи, вывод команд"]
    end
    W -.->|"не помещается"| OF["Запрос отвергается или срабатывает компакция"]

Всё это конкурирует за один ограниченный объём; шумные логи и лишние файлы вытесняют важное.

Ключевой факт: модель не помнит ничего за пределами контекста. Между вызовами у неё нет состояния: каждый раз харнес заново отправляет ей весь накопленный контекст целиком. «Агент помнит начало сессии» означает ровно одно: начало сессии всё ещё лежит в контексте.

Контекстное окно — жёсткий лимит

Контекстное окно (context window) — максимальный размер контекста в токенах для данной модели. Это не рекомендация, а физическое ограничение: больше модель принять не может. Типичные размеры у современных моделей — от 128 тысяч до миллиона с лишним токенов; для ориентира, 200 тысяч токенов — это порядка 500 страниц текста или средний по размеру кодовый репозиторий.

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

Что происходит при переполнении? API просто отвергает запрос, который не влезает. Харнесы поэтому вмешиваются раньше. Об этом ниже.

Деградация на длинном контексте

Второй, менее очевидный факт: задолго до жёсткого лимита качество начинает падать. Модель с окном в 200 тысяч токенов формально «видит» их все, но внимание распределяется неравномерно: лучше всего модель работает с началом и концом контекста, а информация из середины теряется чаще. Этот эффект называют «потерей в середине» (lost in the middle).

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

Отсюда практическое правило: больше контекста не значит лучше. Вываливать в модель весь репозиторий «на всякий случай» — плохая стратегия; работает подача релевантного минимума.

Компакция: как харнесы борются с переполнением

Харнесы не ждут, пока окно кончится. Типичный механизм — компакция (compaction), она же суммаризация: когда контекст приближается к лимиту, харнес просит модель сжать историю сессии в краткое резюме (что делали, что решили, что осталось) и продолжает работу с этим резюме вместо полной истории.

Это спасает от переполнения, но не бесплатно: резюме теряет детали. После компакции агент может забыть тонкость из ранней части сессии. Поэтому опытные пользователи не полагаются на компакцию, а управляют контекстом сами: начинают новую сессию под новую задачу, фиксируют важные решения в файлах, дробят большие задачи. Этому посвящена страница «Контекст-инжиниринг»: по сути, вся она выросла из фактов, описанных здесь.

Стоимость: платите за токены

Тарификация API устроена просто: вы платите за входные токены (весь контекст, отправленный модели) и за выходные (сгенерированный ответ), причём выходные обычно в несколько раз дороже. Цены сильно различаются между моделями (см. «Провайдеры и семейства»).

Неочевидное следствие для агентов: поскольку контекст отправляется целиком при каждом обращении к модели, длинная сессия дорожает с каждым шагом: каждый следующий вызов несёт всю накопленную историю во входных токенах. Смягчает это кеширование промптов (prompt caching): повторяющаяся часть контекста оплачивается по сниженной ставке. Но общий принцип остаётся: раздутый контекст означает и худшее качество, и большие расходы.

Что дальше

Бенчмарки: как измеряют модели: последняя страница про модели: как читать цифры в анонсах.
Контекст-инжиниринг: практика управления контекстом: главный навык работы с агентами.

Автор учебника — Шахматов Алексей