Токены и контекстное окно ИИ: как оценить объём запроса

Токен — не слово, а контекстное окно — не память навсегда

Токен — это элемент, на который модель разбивает входные данные перед обработкой. Он может соответствовать короткому слову, части длинного слова, знаку препинания или отдельному символу. Поэтому число страниц, слов и символов не переводится в токены по одной универсальной формуле. Русский текст, программный код и таблица одинакового объёма в символах могут занимать разное место. Контекстное окно — предельное число токенов, доступное модели в рамках одного запроса. В него, в зависимости от конкретного API и модели, входят инструкции, текущий вопрос, переданная история, документы, результаты инструментов и пространство для ответа. Это рабочий лимит запроса, а не доказательство постоянной памяти пользователя.

Что именно расходует контекст

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

Вход, выход и рассуждение нужно различать

Входные токены представляют сведения, переданные модели. Выходные токены образуют создаваемый ответ. В моделях с рассуждением часть общего бюджета может занимать внутреннее рассуждение, хотя оно не обязательно отображается пользователю как обычный текст. У разных платформ возможны дополнительные категории и разные правила учёта, поэтому переносить лимит из документации одного сервиса на другой нельзя. Даже внутри одной платформы модели различаются по максимальному входу, выходу и устройству общего окна. Практическое правило простое: проверяйте карточку конкретной модели и официальную статистику запроса, а не случайное число из обзора.

Почему ИИ может потерять начало длинного разговора

Если переписка приближается к лимиту, приложение должно как-то управлять историей. Оно может прекратить запрос, сократить ранние сообщения, выполнить сжатие или передать модели только выбранные фрагменты. Конкретное поведение задаёт не только сама модель, но и сервис вокруг неё. Даже когда текст технически помещается, большой объём лишних примеров и противоречивых требований усложняет поиск нужного условия. Поэтому важные правила не стоит оставлять единственным сообщением в начале многодневного диалога. Для новой сложной задачи соберите актуальные ограничения в компактный блок и свяжите их с конкретным результатом. Если нужно разобраться в механике генерации, полезен материал о том, как работает большая языковая модель.

Как оценить объём до отправки

Точная оценка начинается с выбранной модели и официального счётчика. OpenAI предлагает токенизатор для проверки конкретной строки, а Gemini API предоставляет метод подсчёта токенов до генерации и статистику использования после ответа. При оценке учитывайте не только основной документ, но и инструкции, историю, примеры, вложения, схемы функций и требуемый объём результата. Оставляйте запас: если вход почти занял всё окно, ответ может быть сокращён или запрос окажется неполным. При этом ориентир для английского текста из документации OpenAI — лишь приблизительное правило, а не формула для русского языка, кода или смешанного документа.

Рабочий пример: документ с приложениями и таблицей

Представим вымышленный отчёт из основного текста, таблицы показателей и трёх приложений. Задача — найти сроки, исключения и противоречия. Неправильный подход: загрузить все версии файлов вместе с длинной перепиской и попросить «проанализировать всё». Проверяемый подход начинается с перечня материалов: «Отчёт — версия 3; таблица — данные на 15 октября; приложения A–C». Затем формулируется результат: таблица с полями «утверждение», «источник», «раздел», «противоречие», «неизвестно». После этого официальный счётчик применяется к полному пакету, включая инструкцию. Если пакет близок к пределу, сначала строится карта разделов, затем извлекаются только относящиеся к вопросу части.

Допустим, в первом проходе модель должна вернуть лишь оглавление и указатели на разделы, где встречаются сроки и исключения. Во втором проходе ей передают эти разделы и требуют выписать точные условия. В третьем сравнивают формулировки и отмечают расхождения. Так пользователь не просит модель удерживать одинаковое внимание ко всему архиву одновременно. Для каждого вывода сохраняется ссылка на раздел документа, а неизвестные значения не заменяются догадками. Общий подход сочетается с ясной постановкой задачи: заранее составьте промпт с результатом и критериями.

Как делить большой материал без потери смысла

Механическое разрезание по одинаковому числу символов способно отделить определение от исключения или таблицу от пояснения. Лучше делить по смысловым границам: раздел, договорное условие, глава, функция программы или законченная тема. Каждый фрагмент снабжайте названием документа, версией, датой и местом внутри исходника. Сначала можно построить карту всего материала, затем выбрать релевантные части, а после объединения проверить, не потерялись ли определения и перекрёстные ссылки. Если вывод зависит от нескольких фрагментов, передавайте их вместе или явно указывайте связь. Финальное резюме нужно сверять с исходниками, а не с промежуточным пересказом.

Большое окно не гарантирует точный ответ

Возможность передать много токенов означает вместимость, а не равное качество поиска каждого факта. Документация Google предупреждает, что производительность длинного контекста зависит от содержимого и может снижаться, когда нужно найти много отдельных фактов. Лишние версии, журналы, повторяющиеся страницы и неотносящиеся примеры увеличивают стоимость и конкурируют за внимание. Поэтому полезно удалять дубли, определять один актуальный вариант документа и ставить конкретный вопрос после переданного контекста. Важный ответ всё равно следует проверить по первоисточникам и критериям.

Как проверить результат

После ответа убедитесь, что модель рассмотрела все обозначенные материалы, сохранила даты и единицы измерения, отделила цитируемые сведения от вывода и отметила пробелы. Выберите несколько критичных фактов и вручную найдите их в исходных разделах. Если в резюме появился срок, которого нет в документе, или исчезло исключение, результат нельзя считать готовым. Повторите проверку с более узким набором фрагментов и явным требованием перечислять неизвестное. Для повторяемого процесса сохраните модель, способ подсчёта, использованный набор файлов, инструкцию и фактическую статистику токенов. Тогда следующий запуск можно сравнить с предыдущим, а не оценивать по впечатлению.

Короткий порядок действий

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