Длинный контекст — когда выгодно дать документ целиком

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

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

Зачем это знать

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

Длинный контекст простыми словами

Юристу перед встречей кладут на стол папку по сделке. Договор, приложения, протоколы разногласий, переписка — всё под рукой. Он отвечает на вопросы сразу, не бегая в архив за каждой справкой.

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

Размер папки и есть контекстное окно. Длинный контекст — способ им пользоваться: документ не режут, а отдают целиком.

Цифры ниже — расчётные ориентиры для компании такого профиля, а не отчёт по конкретному внедрению. У каждой указана методика, чтобы её можно было повторить на своих данных.

Как это работает

1. Считают объём документа. Публичный ориентир для русского текста: 32 тысячи токенов — примерно 60 страниц, то есть около 530 токенов на страницу. Договор такого размера и занимает эти 32 тысячи.
2. Решают, что уходит в запрос. Весь документ, часть разделов или найденные фрагменты. Это решение и определяет счёт.
3. Отправляют документ вместе с вопросом. Модель видит текст только внутри запроса. Прошлый файл она не помнит: при следующем вопросе его отправляют заново.
4. Кэшируют постоянную часть. Один и тот же регламент уходит в модель по сто раз в день. За повторную отправку поставщик берёт по сниженной цене.
5. Замеряют время и точность. Объём тянет за собой задержку ответа и стоимость запроса. Ответы по середине документа проверяют отдельной выборкой.

Главная ловушка простая. Документ кладут в запрос заново при каждом вопросе. Двенадцать вопросов к одному договору — двенадцать раз по 32 тысячи токенов.

Пример из практики

Отдел закупок сверяет договоры поставки: 40 документов в месяц, в среднем по 60 страниц. К каждому договору задают около 12 вопросов — сроки, штрафы, условия расторжения.

Договор целиком — примерно 32 тысячи токенов по публичному ориентиру. Двенадцать вопросов дают 384 тысячи входных токенов на один документ, около 15 миллионов на месячный поток. Арифметика здесь простая: объём умножен на число вопросов и на поток, замера тут нет.

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

Точность при этом проверяют на общей выборке: 50 вопросов с ответами, размеченными юристом вручную. Прогон делают до и после смены режима.

Что это даёт бизнесу

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

Когда без этого можно обойтись

Короткие обращения длинного контекста не требуют. Вопрос клиента и карточка заказа занимают пару тысяч токенов. Окно на миллион здесь простаивает. Платить за простой не приходится: счёт идёт по факту отправленного объёма.

Не нужен он и там, где ответ всегда лежит в одном известном разделе. Инструкция на три страницы отправляется целиком и стоит дёшево. Выбор режима начинает влиять на деньги примерно с десятков страниц на запрос.

Что важно проверить

Первое: точность по середине объёма. Ответы на вопросы из начала и конца документа обычно ровные, провал приходится на середину. Выборка из 30–50 размеченных вопросов показывает, где именно проходит рабочая граница для конкретных документов.

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

Третье: разбивку одного запроса. У подрядчика просят показать, сколько токенов занимает инструкция, сколько сам документ, сколько история переписки. Отсюда видно, что переносить на кэш, а что на поиск по фрагментам. И насколько подготовка запроса изменит счёт.