Длинный контекст: 200 000 токенов и что с ними делать

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

Что происходит при заполнении окна

Три последствия, и все три работают против вас одновременно.

Цена. Оплачивается весь вход, независимо от того, какая его часть пригодилась. Отправить сто тысяч токенов ради ответа в одно предложение технически можно; вопрос в том, сколько раз в день вы готовы за это платить.

Скорость. Время до первого символа растёт вместе с длиной входа. Разница между коротким запросом и почти заполненным окном заметна невооружённым глазом.

Точность. Это самое неприятное. Чем больше в запросе постороннего, тем выше вероятность, что нужный фрагмент останется без внимания. Модель не «читает внимательнее», получив больше материала — скорее наоборот.

Что с этим делают

Простой путь — всё в контекст — оправдан, пока массив невелик и меняется редко. Разбор одного договора, работа с техническим заданием, вопросы к отчёту за квартал: здесь строить индекс избыточно. Размер окна стоит уточнить для конкретной модели — у anthropic api он отличается от версии к версии.

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

Практические приёмы для длинных запросов

Если вы всё-таки отправляете много, порядок имеет значение.

Ставьте вопрос после материала, а не перед ним. На длинных запросах это даёт заметную разницу: модель сначала видит предмет, потом задачу.

Размечайте фрагменты. Нумерация и заголовки позволяют попросить ссылку на источник в ответе — а значит, проверить его, не перечитывая весь материал.

Явно разрешите ответ «в материалах этого нет». Без такого разрешения модель склонна собрать правдоподобный ответ из того, что есть, и отличить его от настоящего будет сложно.

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

Что сокращать первым

Когда запрос перестаёт помещаться, сокращают обычно не то.

История диалога — единственная часть, которая растёт сама и почти никогда не нужна целиком. Держать последние несколько реплик и краткое резюме предыдущих дешевле и часто точнее, чем тащить всю переписку.

Фрагменты, найденные поиском, стоит отсекать по релевантности, а не брать фиксированным числом. Пять хороших фрагментов лучше двадцати, из которых пятнадцать — шум.

Системная инструкция обычно сокращается легче всего и почти безболезненно — просто на неё редко смотрят.

Сколько это стоит в цифрах

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

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

Как проверить, что материал вообще прочитан

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

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

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

Гибридный подход

На практике редко выбирают одну из двух схем целиком. Работающая середина выглядит так: поиск отбирает фрагменты, но не самые точные пять, а десяток-полтора с запасом, включая соседние куски документа — они дают контекст, который поиск отбрасывает.

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

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

Что происходит при переполнении

Запрос, не помещающийся в окно, отклоняется целиком. Это лучше, чем тихое обрезание, но означает, что обработка такой ситуации должна быть предусмотрена заранее.

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

Чанкинг: скучный, но решающий этап

Качество ответов на большом массиве определяется не моделью, а тем, как нарезан материал. Фрагмент, разрезанный посреди таблицы, бесполезен. Фрагмент без заголовка раздела теряет контекст. Фрагмент размером в страницу забивает запрос, размером в предложение — не несёт смысла.

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

Коротко

Большое окно — это возможность, а не стратегия. Заполнять его целиком дорого, медленно и вредно для точности. Пока массив помещается и меняется редко, отправляйте как есть; как только перестаёт — стройте поиск, и объём запроса отвяжется от размера базы. Вопрос ставьте после материала, фрагменты размечайте, а сокращать начинайте с истории диалога.