Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Длинные диалоги с LLM научились обслуживать без постоянной пересылки всей истории и без необратимых сводок. В работе Jiangang Chen система Pull сохраняет исходные ходы и раскрывает их по запросу; поскольку препринт не рецензирован, все числа в нём получили сами авторы. Такой маршрутизатор можно поставить между хранилищем сессии и моделью, не меняя саму LLM.
Как Pull превращает историю в адресуемую память
При обычной работе приложение добавляет к каждому запросу всю предыдущую переписку. Контекст растёт линейно, но за полную сессию команда повторно передаёт одни и те же токены, поэтому суммарный объём растёт квадратично.
Сводки и жёсткое усечение уменьшают запрос, но удаляют детали. Это опасно для ассистента разработчика или агента: ранний ход может содержать определение функции, выбранную ветку решения либо реализацию, которую позже заменили. Если сводка потеряла эту связь, следующий запрос её не восстановит.
Pull оставляет исходные сообщения в хранилище, а рядом ведёт два слоя метаданных. M0 содержит короткие извлечённые фрагменты по каждому ходу и даёт модели карту всей сессии. M10 связывает сущности с местами, где их определили, упомянули, изменили или перестали использовать, а также хранит ветки разговора и причинные зависимости.
Метаданные строит локальный компонент Purifier. Он применяет регулярные выражения, правила и компактную модель в формате ONNX, но не вызывает LLM. Для разговоров о коде он распознаёт имена функций и классов, идентификаторы, адреса и другие сущности; для иной предметной области этот извлекатель придётся заменить.
Во время запроса Selector читает вопрос и слой связей, после чего одним вызовом LLM выбирает нужные ходы. Детерминированное правило добавляет пропущенные определения и связанные сообщения. Затем Answerer получает исходный текст выбранных ходов вместе с общим каталогом M0 и формирует ответ вторым вызовом модели.
Невыбранные сообщения не исчезают. Следующий запрос может раскрыть другой участок истории, поэтому набор рабочего контекста меняется вместе с задачей. В этом состоит отличие Pull от фиксированной сводки, сжатия токенов и последних сообщений в окне.
Сокращение контекста проверили на коде и длинных беседах
На LoCoEval проверили 128 разговоров из реальных репозиториев. В одношаговых задачах Pull сократил контекст запроса на 75,1%, а в многошаговых — на 72,0%; разница в качестве по сравнению с полной историей осталась в пределах погрешности.
На BEAM 1M система работала с беседами, которые не помещались в контекст модели. По F1, метрике, которая объединяет точность и полноту ответа, Pull обошёл усечение последних сообщений на 55,2%. В этом опыте использовали упрощённый каталог без слоя жизненного цикла, поэтому результат проверяет прежде всего сам принцип подгрузки по запросу.
Отдельный тест маршрутизации показал, зачем нужен жизненный цикл сущностей. Поиск по словам и векторной близости хуже находил старые изменения, когда между вопросом и нужным ходом лежало много сообщений. Метки определения, изменения и прекращения использования позволяли выбирать ход независимо от его возраста.
Основные проверки относятся к разговорам о разработке: LoCoEval охватывает извлечение сведений и понимание темы, а тест маршрутизации собран из трассировок задач SWE-bench. Генерацию и основную оценку выполняла одна модель, хотя независимая модель-оценщик подтвердила направление результата. С LLMLingua2 сравнивали только многошаговые задачи, а на BEAM использовали выбранную часть набора.
Когда маршрутизатор памяти меняет архитектурный план
Работа не даёт причины менять поставщика LLM или ждать ещё более длинного контекстного окна. Она предлагает вынести управление текущей сессией в самостоятельный слой: приложение хранит полную историю, локально обновляет каталог и перед каждым ответом собирает рабочий контекст под конкретный запрос.
Такой слой имеет смысл для агентов и ассистентов, где разговор продолжается сотни ходов, а старые решения остаются значимыми. Сюда относятся разработка кода, расследование инцидентов и длительные процессы с ветвлениями. Чем чаще приложение повторно передаёт почти неизменную историю, тем больше потенциальный выигрыш по токенам.
Pull не заменяет RAG и долговременную память. RAG ищет знания во внешних документах или прошлых сессиях, а маршрутизатор собирает состояние текущего процесса: какая версия сущности действует, откуда она появилась и какая ветка разговора к ней привела. В рабочей архитектуре эти слои дополняют друг друга.
Для прототипа достаточно разделить неизменяемое хранилище исходных ходов, построение метаданных и выбор контекста. Стоит отдельно измерять долю найденных зависимостей, размер итогового запроса, задержку обоих вызовов модели и частоту перехода к более широкому контексту. Если извлекатель не понимает сущности предметной области, экономия токенов не компенсирует пропущенное состояние.
Практический вывод состоит не в том, чтобы сразу внедрять именно Pull. Командам, которые строят длинные сессии, стоит перестать считать контекстное окно единственным местом хранения рабочего состояния и проверить обратимую подгрузку на собственных трассировках. Для коротких диалогов дополнительный выбор контекста может не окупить усложнение, а для процессов с длинной причинной историей работа задаёт проверяемую архитектурную гипотезу.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
