Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Полезность внешней памяти LLM нельзя надёжно оценить, если поиск никогда не показывает конкретную запись модели. В препринте Arman Behnam и Binghui Wang обычная схема не смогла оценить 54% нужных записей на LongMemEval, а CMP повысил качество их отделения от ненужных с 0,54 до 0,66 по площади под ROC-кривой; работа не рецензирована, а числа получили сами авторы. Для систем, которые удаляют память по оценке полезности, случайность нужно добавлять в поиск, но даже после этого одной такой оценки недостаточно для автоматического удаления.
Поиск превращает «не проверено» в нулевую полезность
Система с внешней памятью сначала выбирает несколько записей, помещает их в контекст и только затем строит ответ. Запись влияет на результат лишь тогда, когда проходит этот отбор: само присутствие в хранилище ничего не меняет, если ранжировщик постоянно оставляет её за пределами контекста.
Из-за этого эксперимент на уровне хранилища может оказаться фиктивным. Система по очереди сохраняет и удаляет запись, но в обоих случаях передаёт модели одинаковый контекст. Ответы совпадают, оценка полезности стремится к нулю, хотя запись ни разу не получила возможности помочь.
Такой результат смешивает два разных случая. В первом запись попала в контекст и не улучшила ответ. Во втором поиск её не выбрал, поэтому эксперимент ничего о ней не установил. Политика удаления видит одинаковый ноль и рискует принять отсутствие наблюдений за доказанную бесполезность.
Работа описывает вклад памяти как произведение двух величин: вероятности попасть в контекст и пользы после попадания. Для причинной оценки каждая проверяемая запись должна хотя бы иногда оказываться внутри и снаружи контекста. Детерминированный поиск этого не гарантирует, а увеличение числа логов не помогает записи, вероятность выбора которой равна нулю.
CMP случайно подмешивает записи в контекст
Causal Memory Policy резервирует часть контекста для контролируемого эксперимента. Остальные места заполняет обычный ранжировщик, а экспериментальные — записи из заданного набора, выбранные со заранее известной вероятностью. В основной схеме под эксперимент отводили два из шести мест.
Распределение сбалансировано: за весь период каждая запись получает запланированное число показов. При включении она вытесняет последнюю запись обычной выдачи, а при исключении освободившееся место занимает следующий кандидат. Поэтому размер контекста не меняется, и сравнение не смешивает эффект записи с эффектом дополнительного текста.
Полезность рассчитывают через самонормированное взвешивание, обратное вероятности включения. Проще говоря, известные вероятности показа позволяют скорректировать вклад наблюдений и сравнить результат задачи с записью и без неё. Авторы применили один и тот же расчёт к обычным логам, случайным изменениям хранилища и случайным изменениям поиска, чтобы отделить пользу нового экспериментального дизайна от пользы формулы.
Случайные изменения хранилища оставляли итоговый контекст прежним в 52,2% попыток. На LoCoMo поиск не давал оценить 67% записей, которые требовались для ответа. Когда анализ ограничили записями, которые поиск действительно показывал, оценки двух методов практически совпали: проблема возникала не в расчёте, а в отсутствии наблюдаемых вариантов.
Метод проверяли на LongMemEval с длинными диалогами, на многосессионном LoCoMo, на задачах рассуждения HotpotQA и MuSiQue, а также на Mem0 как примере действующей системы памяти. Генератор во всех опытах получал только вопрос и тексты выбранных записей, поэтому вывод относится к архитектуре, где влияние хранилища полностью проходит через поиск.
Планы меняются для политик, которые удаляют память по полезности
Если система хранит записи по давности или частоте обращения, найденный сбой не меняет саму логику такой эвристики: она не пытается измерять причинный вклад. Проблема возникает у политик, которые ранжируют записи по влиянию на ответы и освобождают место снизу списка.
Для такой политики недостаточно логировать итоговый контекст. В эксперимент нужно включить управляемый показ кандидатов, сохранить вероятности включения и различать нулевую пользу с достаточным числом наблюдений и запись, которую поиск не проверил. При необратимом удалении CMP также предлагает воздерживаться от решения, если оценка остаётся неопределённой: ошибочно сохранённую запись можно удалить позже, а восстановить забытую обычно нельзя.
Однако CMP пока не даёт готового правила хранения. Оценка для конкретного вопроса достигла AUC 0,78, но её связь с вкладом записи в будущие, отложенные вопросы не превысила 0,10. Запись может быть критичной для редкого запроса и бесполезной для остальных, поэтому усреднение размывает сигнал, а максимум заставляет сохранять почти всё.
Практический вывод уже уже области удаления памяти. CMP подходит для проверки ранжировщика и измерения вклада записей в известные типы запросов. Если в плане продукта есть автоматическая очистка памяти по «полезности», между измерением и удалением нужен отдельный прогноз будущего спроса; случайный показ исправляет эксперимент, но не предсказывает, какая информация понадобится пользователю позже.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
