Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Локальная правка документа не требует заново обрабатывать весь контекст LLM, если связанный с ней текст находится рядом. В препринте, который не рецензировали и чьи числа получили сами авторы, локальный ремонт работал в 13–21 раз быстрее полного повторного расчёта. Для систем с изменяемой памятью это даёт дешёвое правило синхронизации кэша, но только в пределах одного связного блока.
Почему важные токены не восстанавливают зависимость
Во время первичной обработки контекста LLM сохраняет состояния ключей и значений (KV-кэш), чтобы не рассчитывать их заново при каждом запросе. Если документ исправили, состояния изменённого фрагмента и всех следующих позиций продолжают отражать старый текст.
Пересчитать только изменённые токены достаточно, когда ответ записан прямо в них. Сложность возникает, если новый факт влияет на неизменённый текст ниже по контексту. Например, правка меняет псевдоним объекта, а нужное значение остаётся в расположенной следом таблице соответствий.
Можно попытаться выбрать отдельные позиции по весам внимания, отличию состояний или структуре документа. Такие правила ищут токены, которые сильнее влияют на ответ, но пропускают промежуточные звенья. Выбранная позиция пересчитывается с опорой на соседние устаревшие состояния и снова получает старую зависимость.
Это объясняет расхождение между переносом и реальным пересчётом. Если скопировать состояние из полностью исправного кэша, оно принесёт информацию, накопленную на всём пути от правки. В рабочей системе такого кэша нет: состояние приходится строить из доступного окружения. Поэтому набор разрозненных позиций может выглядеть достаточным в диагностическом опыте и почти не работать при развёртывании.
Непрерывное окно ведёт себя иначе. Оно последовательно перестраивает цепочку от места правки до текста, который несёт ответ. Здесь важна не индивидуальная значимость токенов, а отсутствие разрывов между ними.
Как проверяли непрерывный пересчёт
В контексты примерно по 5000 токенов вставляли синтетическую запись, а фоном служили перемешанные документы HotpotQA. Для каждого примера создавали прямой вопрос, ответ на который менялся внутри исправленного фрагмента, и производный: его ответ находился ниже и зависел от изменённого факта.
Эксперименты провели на Llama-3.1-8B-Instruct, Qwen3-8B и Mistral-7B-Instruct-v0.3. Все правила всегда обновляли сам изменённый фрагмент, а затем выбирали одинаковый бюджет из 32 следующих позиций. Сравнивали непрерывное окно, структурные разделители, веса внимания, отличие состояний кэша и случайный выбор.
На прямых вопросах различий почти не было: обновления самого фрагмента хватало всем правилам. На производных вопросах непрерывное окно восстановило 94–101% разницы между старым ответом и результатом полного расчёта. Остальные доступные для внедрения правила уступили ему статистически значимо во всех трёх семействах моделей.
Геометрия контекста оказалась определяющей. Когда текст с ответом передвинули на 250 токенов ниже, локальное окно восстановило лишь 1–9% нужного сдвига. Даже окно, поставленное непосредственно вокруг известного места ответа, не всегда достигало полного результата: найти зависимый текст недостаточно, если путь от правки до него остался устаревшим.
Что менять в архитектуре продукта
Для кэша документов, рабочей памяти агента или пользовательского состояния разумно хранить границы смысловых блоков. После правки внутри блока система может без отдельной оценки риска пересчитать изменённый фрагмент и весь остаток блока. Такой подход не требует дополнительного прохода модели для ранжирования позиций.
Отдельный классификатор, который решает, нужен ли ремонт, в исследованном сценарии мало полезен. Изменения, затрагивавшие цепочку ответа, портили поведение устаревшего кэша как минимум в 98,8% случаев, а простые признаки плохо предсказывали тяжесть ошибки. Проверка может стоить сложнее самого локального ремонта.
Если зависимые данные находятся в другом документе или далеко ниже по контексту, это правило применять как гарантию нельзя. Архитектуре понадобится более широкий пересчёт, явный граф зависимостей либо полный повторный расчёт. Работа показывает границу локального окна, но не сравнивает эти варианты.
Проверяли одиночные непрерывные правки, которые не меняли длину текста, и синтетические зависимости с двумя возможными ответами. Модели были плотными и близкими по размеру, а время измеряли на одном RTX 5090 при обработке одного запроса; одинаковый для всех методов расчёт свежего вопроса в замер не входил. Результат пока не переносится напрямую на множественные правки, свободные ответы, разреженные модели и серверную обработку пакетов.
Практическое решение зависит от расположения данных. Если правка и её следствия лежат в одном соседнем блоке, непрерывный пересчёт можно закладывать вместо полного обновления контекста. Если система свободно связывает удалённые фрагменты памяти, локальное окно остаётся базовым методом, а не завершённым механизмом согласования.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
