Что такое загнивание контекста и как удержать качество

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

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

Что такое загнивание контекста простыми словами

На столе лежит папка. Одна справка находится за секунду. Двести справок лежат там же, но нужную ищут весь вечер, и часть листов просматривают вскользь.

Модель ведёт себя похоже. В контекстное окно помещаются сотни страниц: у Claude лимит в 200 000 токенов соответствует примерно 500 страницам текста. Но помещается только то, что укладывается в лимит, а внимание внутри пакета распределяется неравномерно: деталь из середины учитывается реже, чем та же деталь в коротком запросе.

Отсюда название. Лимит не превышен, ошибки нет, ответ выглядит уверенно — а доля верных ответов ползёт вниз.

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

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

Тонкость про длинные окна: длинный контекст выигрывает время на старте, когда поиск по базе ещё не построен. На потоке выигрывает отбор фрагментов под конкретный вопрос.

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

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

Юридический отдел проверяет входящие договоры на соответствие регламенту. Регламент — 60 страниц, договор — 20–40 страниц, вопросов к каждому договору десять. В первой версии в запрос кладут регламент целиком и весь договор.

Замер строят так. Берут 150 договоров за прошлый квартал с проверенными вручную ответами юриста. Считают долю пунктов, найденных верно, — одна метрика, одна выборка, два режима работы. Первый режим: полный пакет разом. Второй: поиск по регламенту, три-пять релевантных пунктов и нужный раздел договора.

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

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

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

Механику сжатия истории разбирает компакция контекста, а подбор материалов под вопрос — поиск по своей базе.

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

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

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

Отбор фрагментов окупается там, где один и тот же процесс повторяется десятки раз в день на растущем объёме документов.

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

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

Второе: устаревшие редакции документов в базе стоят дороже отсутствующих. Модель находит текст, отвечает уверенно и по недействующему правилу. Регламент версионируют до запуска, а не после первой спорной ситуации.

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