Почему эталоны для оценки памяти агентов вводят в заблуждение и как проводить оценку на собственных данных
Критерии оценки памяти агентов вводят в заблуждение из-за некорректных ключей ответов и систем оценки. Тестируйте способность к извлечению информации отдельно от ответов, добавьте проверки свежести данных, воздержания и забывания.
Источники: Your Agent’s Memory Benchmark Is Measuring the Wrong Thing
Общедоступные тесты на память агентов не могут указать, какая система подойдёт для конкретной задачи, причём некоторые из них вообще не способны надёжно определить, какая система лучше. Доказательства этого очевидны. В тесте, который все цитируют, примитивный вариант, при котором вся беседа вставляется в запрос, превосходит специализированные решения для работы с памятью, как указано в собственной статье одного из поставщиков таких решений. Независимая проверка показала, что примерно шесть процентов ответов в этом тесте неверны, а его автоматический оценщик принимает примерно два из трёх умышленно неверных ответов. Разумным решением будет перестать опираться на рейтинги и создать систему оценки на основе собственных данных.
Рассмотрим, как команда обычно выбирает систему хранения данных. Она смотрит на топ-лист, берет первый попавшийся вариант и приступает к использованию. Через три недели после внедрения агент с ошибкой использует цифру, которую пользователь исправил ещё в прошлый вторник. Он начинает противоречить решению, принятому на предыдущей неделе. Единственный необходимый факт в результате поиска оказывается внизу списка среди четырех несущественных результатов. Тестирование называло эту систему лучшей на рынке, однако не упоминало собственных проблем команды.
Под этим стоит вопрос, который возникает при любой разработке системы хранения: откуда известно, что она работает? Неудовлетворительный ответ заключается в том, что показатели, к которым обычно обращаются команды, не могут дать на него ответ, а некоторые вообще не могут помочь никому.
Ранг в табличке лидеров указывает на то, что система хорошо справилась с тестом кого-то другого, оцененным кем-то другим по критериям, установленным кем-то другим. Это не говорит о том, сможет ли ваш агент вспомнить то, что пользователь упомянул три недели назад. Это разные вопросы, и только один из них касается вас.
Критерий оценки, который вы рассматриваете, измеряет что-то другое
Результаты, приведенные в заголовке, заслуживают более внимательного рассмотрения. Возьмем наиболее часто цитируемый тест на работу с конверсационной памятью. Метод, не использующий систему памяти, который просто вставляет полную конверсацию в запрос и отвечает на основе нее, занял первое место, немного опередив специализированные решения с системами памяти в ходе сравнения. Ни один критик этого не отметил. Этот результат приводится в статье после описания известной библиотеки памяти Mem0, опубликованной в журнале с процедурой рецензирования; авторы сообщают, что использование полного контекста обеспечивает более высокую точность по сравнению с их собственной системой, при этом время обработки каждого ответа увеличивается примерно в десять раз. Другой поставщик также приводит тот же факт из этой статьи, поэтому это не является односторонней интерпретацией.
Это менее неловко, чем кажется, и важно правильно его прочитать. Вставка всего содержимого обеспечивает точность, поскольку ничего не было опущено. Однако такой подход неэффективен из-за проблем с переполнением и квадратичных затрат. Поэтому критерии оценки в основном отдают предпочтение той системе, которая наилучшим образом приближается к точности полного контекста, тратя при этом меньше токенов. Это полезно для измерения. Это не то же самое, что проверка способности системы вспомнить какую-то деталь, указанную пользователем месяц назад; те, кто интерпретирует рейтинг именно в этом смысле, вводятся в заблуждение собственными предположениями.
Подлинная картина ситуации ещё более неопределённа. В ходе отдельной проверки, результаты которой были опубликованы и могут быть воспроизведены, хотя и не проходила рецензирование, были тщательно изучены ответы стандарта оценки, и было обнаружено, что примерно шесть процентов из них неверны: выдуманные факты, ошибки в временных рассуждениях, ответы, приписанные неверному участнику. Когда проверяющие предоставили стандартной автоматической системе оценки неверные, но правдоподобные ответы, она приняла около двух третей из них. Существует одно важное ограничение: авторы проверки, Пенфилд и его коллеги, также разрабатывают системы памяти, поэтому они не являются нейтральными. Однако их работу можно воспроизвести, а открытые проблемы в собственном репозитории стандарта указывают на то же самое, так что проблема реальна, даже если авторы выводов субъективны. Последствия этого весьма серьёзны. Критерий оценки с погрешностью в шесть процентов в ключевых тестах не может отличить две системы, отличающиеся менее чем на шесть процентов, а инструмент оценки, считающий правильными две трети результатов, полученных случайным образом, измеряет уровень уверенности, а не точность.
Цифры, приводимые производителями, также расходятся между собой. Два самых известных производителя памяти публикуют результаты одного и того же теста, противоречащие друг другу: каждый из них перезапускал систему другого и получал результат, который второй оспаривает, поскольку исход во многом зависит от того, кто настроил интеграцию. Крупные цифры, меняющиеся на десятки единиц в зависимости от настроек, являются частью маркетинговой стратегии, а не результатом объективных измерений. Все это не делает системы плохими. Это означает, что таблица лидеров не может отсортировать их за вас, тем более в контексте ваших конкретных задач.
Длинный контекст — это не память, и критерии оценки смешивают эти понятия
Более тихая форма путаницы портит сравнения ещё до их начала. Длинный контекст и память — это разные вещи, однако многие методы оценки рассматривают их как единый параметр. Задача «игла в стоге сена», при которой одно предложение скрыто в длинном документе и модель должна его найти, тестирует способность к вниманию к одному фиксированному входному данныху. Это удобный пробный тест, не имеющий научной основы, — лишь широко распространённый скрипт. Более строгий критерий оценки, RULER, показал, что у многих моделей, рекламируемых с огромными окнами контекста, фактический диапазон обработки значительно меньше, чем указано в характеристиках. Оба метода измеряют емкость, то есть то, сколько информации из одного запроса модель действительно может использовать.
Память обеспечивает преемственность между сессиями. В понедельник агент что-то берет, чат заканчивается, окно очищается, но к пятнице он должен всё ещё помнить об этом. LoCoMo и LongMemEval — это тесты на память в диалогах, которые проверяют цикл «хранение затем воспроизведение» в течение множества сессий; поэтому они относятся к одной группе, независимо от их недостатков.
Два уровня тестирования
Когда стандартные тесты оказываются недостаточными, альтернативой является разработка собственного теста, причем первым шагом при его проектировании является определение того, что нужно разделить. Его следует разделить на два уровня: первый — это поиск информации: смогла ли система памяти восстановить правильные факты? Второй — это ответ: дал ли агент наконец правильный ответ или действие? Они работают независимо друг от друга, а показатель точности в целом рассчитывается как среднее по обоим, что скрывает причину сбоя.
Такое разделение не является чем-то новым. Фреймворк RAGAS с открытым исходным кодом, описанный в статье 2024 года, построен на этом принципе, разделяя способность механизма поиска находить релевантный контекст и способность модели верно использовать этот контекст. TruLens описывает ту же идею через концепцию тройки: релевантность контекста для поиска, обоснованность ответа на основе найденной информации и релевантность ответа к поставленному вопросу. Названия различаются, но принцип разделения остается прежним.
Оба слоя необходимы, но именно этот этап часто игнорируются командами. Хороший инструмент поиска информации всё равно может дать неверный ответ, поскольку правильные факты оказываются в контексте, который модель игнорирует, делает ошибочные выводы или смешивает их с тем, во что она уже верила. Именно поэтому показатель основанности на реальных данных является отдельной метрикой. Плохой инструмент поиска может всё равно дать правильный ответ, так как модель заполняет пробелы с помощью своих параметрических знаний, и это ещё более опасный сценарий. Оценка «правильно» может отражаться при наличии слоя памяти, который не смог найти ничего полезного, что приведёт к ошибкам при обработке фактов из конкретной области, о которых модель вообще не знала. Оценка только окончательного ответа не позволяет отличить работающую память от удачного угадывания.
Для поиска информации необходимы метрики ранжирования, а не усмотрение больших языковых моделей
Этот слой предназначен для оценки с помощью арифметических операций, при этом арифметика не имеет собственных мнений. Метрики происходят из классической теории поиска информации и существуют уже десятилетиями:
- Recall@k — это доля фактов, которые должны были быть найдены и действительно появились среди первых k результатов. Она подходит в случаях, когда последующая модель терпима к отвлекающим факторам, а главная задача — наличие необходимого факта.
- Precision@k — это доля найденных элементов, которые оказались релевантными. Она важна, когда пространство контекста ограничено, и каждый потраченный ресурс стоит дорого или может сбить модель с правильного пути.
- Средний обратный ранг поощряет размещение единственного правильного факта на первом месте, особенно в ситуациях, когда учитывается только первый найденный результат.
Выберите тот вариант, который лучше всего соответствует способу, которым ваш агент обрабатывает свою память.
Почти ни одна команда не обращает внимания на следующий момент, который, возможно, является самым важным здесь. Популярные рамки оценки, такие как RAGAS, TruLens и DeepEval, предусматривают показатели под названием воспроизведение контекста и точность контекста, и естественно предполагать, что это и есть вышеупомянутые метрики ранжирования. Однако это не так. В большинстве этих инструментов судья в виде большой языковой модели читает полученные фрагменты и оценивает их, вместо того чтобы сравнивать их с маркированным набором, указывающим, какие факты действительно были релевантны. Следовательно, команда, которая считает, что она оценивает качество извлечения информации, на самом деле просит одну большую языковую модель высказать мнение о процессе извлечения информации другой модели, тем самым унаследовав все предубеждения судьи-БЛМ. Для получения реальных чисел необходим маркированный набор, в котором указаны, какие сохраненные факты релевантны для каждого запроса; после этого показатели вроде recall@k просто представляют собой подсчёт. Создание такого набора — вот что действительно требует усилий, а эти рамки позволяют обойти эту задачу. Это объясняет, почему честные показатели поиска встречаются редко, в то время как панели управления, кажущиеся надежными, но на самом деле ими не являющиеся, — частое явление.
Четыре аспекта, которые игнорирует стандартная оценка RAG
Если рассматривать память агента как обычную систему RAG, то будут учитываться только показатели качества поиска и ответа, и на этом всё заканчивается. Это приводит к упущению четырех проблем, связанных исключительно с памятью, которые возникают из-за того, что память сохраняется и меняется со временем.
Согласованность. Говорил ли агент что-то, что противоречит тому, что он сказал пользователю ранее, или собственному предыдущему заявлению? Стандартная оценка RAG не может выявить это, поскольку каждый запрос оценивается отдельно, но память, хранящая два противоположных факта, может показать их в разные дни, что создаст впечатление несогласованности. Возможно использование чисел. Модель NLI может помечать более позднее заявление как противоречащее более раннему, применяя это к всему ходу диалога и к информации, возвращаемой системой, что позволяет рассматривать противоречия как измеряемый показатель, а не как жалобу пользователя. Наборы данных, созданные для выявления случаев, когда один этап диалога противоречит другому, формализуют именно эту идею.
Недавность. Когда факт меняется, возвращает ли память новое значение или устаревшее? В исследовании LongMemEval (ICLR 2025) к числу пяти проверяемых способностей относится также временной рассудок и обновление знаний, поэтому это признанная характеристика, а не дополнительный элемент. Успешный дизайн должен быть би-временным: факт фиксирует момент своего существования в реальном мире и момент, когда система узнала о нем, причем обновление аннулирует старую версию на основе временной метки, а не перезаписывает её. Системы на основе временных графов, такие как Graphiti и Zep, работают именно так. Тест прост: после обновления запрос возвращает новое значение, но система всё равно может сообщить, что старое значение ранее считалось истинным.
Воздержание. Если какой-либо факт никогда не попадал в хранилище, говорит ли об этом агент или выдумывает что-то? LongMemEval рассматривает воздержание как отдельную способность, и это справедливо: память, которая выдумывает информацию, хуже той, что признаёт отсутствие данных, поскольку именно выдуманная информация в итоге попадает к пользователю. Эта идея существует ещё с тестов на понимание прочитанного 2018 года, в которых использовались намеренно неразрешимые вопросы. В таких случаях тест прост: задаётся вопрос о чём-то, что никогда не хранилось; корректная система не находит ничего и отказывает в ответе, а неисправная заполняет пустоту выдумками.
Забывание. Что происходит с данными, которые должны были стереться или быть удалены? Действительно ли они исчезли? Методы машинного обучения на принципе забывания позволяют выявить такие закономерности. Один из таких критериев — TOFU, который делит данные на группу для забывания и группу для сохранения, проверяя не только то, что к забытым данным невозможно получить доступ, но и то, что соседние данные остаются нетронутыми. Тесты памяти следуют той же логике: после удаления факта невозможно ни восстановить его, ни вывести на основе других данных, при этом связанные факты остаются. Это не то же самое, что принцип свежести. Замена значения предполагает намеренное сохранение старого значения в архиве, тогда как настоящее удаление, требуемое, например, по запросу на защиту конфиденциальности, должно не оставлять никаких следов. Система, которая лишь аннулирует данные, проходит тест на свежесть, но не проходит аудит права на забывание, и только оценка, способная различить эти подходы, сможет её выявить.
Оценивайте ответы с помощью эксперта, но не позволяйте ему определять истину
Оценка результатов путем подсчёта. Обычно это невозможно, поскольку правильный ответ может быть сформулирован множеством способов, поэтому большинство команд используют ЯЗЫК БОЛЬШОГО МАСШТАБА в качестве судьи. Этот подход работает в рамках хорошо задокументированных, но легко забываемых ограничений. В статье 2023 года, в которой был предложен метод использования ЯЗЫКА БОЛЬШОГО МАСШТАБА в роли судьи, сообщалось, что качественный судья в восьмидесяти процентах случаев давал такие же оценки, как и люди, что и объясняет популярность этой техники. В статье также были перечислены причины неудач: предвзятость из-за порядка рассмотрения ответов, при которой судья отдаёт предпочтение первому увиденному варианту; предвзятость из-за объёма, при которой ценится длина текста больше, чем его содержание; и предвзятость самоусиления, при которой судья предпочитает ответы, написанные в его собственном стиле. Следующая статья 2024 года усугубила последнюю проблему: модель может распознавать свой собственный стиль написания, и чем лучше у неё это получается, тем больше она склонна отдавать предпочтение таким ответам. Ещё одна статья 2023 года под названием G-Eval показала, что оценки GPT-4 в целом согласуются с оценками людей, но выделила наиболее значимую проблему в данном контексте — судьи склонны отдавать предпочтение плавному, уверенному и правильно оформленному тексту. Именно так выглядит уверенный неверный ответ, благодаря которому воспоминание, звучащее правильно, но содержащее ошибку в цифрах, может пройти незамеченным.
Используйте судью, но ограничьте его действия:
- Оценивайте по критериям, основанным на известном правильном ответе, а не по принципу «что лучше», чтобы судья проверял факты, а не субъективное восприятие.
- Проверяйте, с какой частотой модель соглашается с примерами, помеченными людьми из ваших собственных данных, поскольку судья, не соглашающийся с вами в вашей области, является неисправным инструментом.
- Устраняйте предвзятость в выборе позиции, как это было сделано в первоначальной статье: меняйте порядок кандидатов и берите среднее значение результатов.
- Рассматривайте обновление судьи-модели как миграцию набора инструментов оценки, а не как автоматическое улучшение. Оценки новой модели несопоставимы с оценками старой, а бесшумная замена ведет к изменению чисел по причинам, не связанным с тестируемой системой.
Судья — это инструмент для калибровки, а не источник истин, которому следует подчиняться.
Сборка комплекса на собственных данных
Все работает на «золотом наборе»: замороженной, помеченной коллекции случаев из вашей собственной области, при этом каждая запись связывает запрос с фактами, которые необходимо извлечь, и ответом, который должен получиться. Это функционирует как набор инструментов для тестирования регрессии, то есть системы, которая должна постоянно проходить тесты, адаптированная для неоднозначных результатов. Многие команды начинают с нескольких сотен вручную отобранных случаев. Этот диапазон является ориентиром для практиков, а не строгим правилом, поэтому рассматривайте его как отправную точку, которая будет расширяться.
Создание набора данных — не самая сложная часть; сложно сохранять его точность. Замороженный золотой набор постепенно перестаёт соответствовать реальному трафику по мере развития продукта, корпуса данных и пользователей, а полностью обновлённый набор на основе устаревших данных порождает ложную уверенность, самую дорогостоящую из всех. Решением является циклический процесс: брать примеры с реальной работы, включать их в золотой набор в качестве свежих, маркированных случаев, удалять те, которые больше не отражают реальность, тем самым набор будет следовать за развитием продукта, а не оставаться его «снимком» прошлого. Синтетические примеры могут способствовать покрытию данных, их генерируют несколько фреймворков, но сгенерированные примеры несут в себе ограничения модели, которая их создала, поэтому всё равно требуется набор данных, проверенный человеком.
Этот набор инструментов работает в двух режимах: офлайн и онлайн, поскольку они обнаруживают разные ошибки. В офлайн-режиме, с использованием «золотого набора» данных, он контролирует процесс выпуска: процедура является повторяемой и детерминированной, и она подтверждает, что ничто из уже известного не нарушено. В онлайн-режиме, на основе реальных данных с высокой частотой отбора, он выявляет то, что невозможно было обнаружить с помощью «замороженного набора» данных, такое как смещение распределения, необычные запросы с длинным хвостом, которые никто не предвидел, а также медленное устаревание данных, проявляющееся только спустя недели накопления информации. Зеленый статус офлайн-режима означает, что известное в порядке; онлайн-мониторинг показывает неизвестное. Рассматривайте результаты офлайн-режима как разрешение к выпуску, но никогда не как доказательство корректной работы системы.
Затраты и задержки должны учитываться в одном показателе
Стоимость и время задержки — это параметры, которые обычно игнорируются при оценках, тогда как для памяти они крайне важны. Память находится на критическом пути каждого хода, поэтому время её доступа, измеряемое по показателю p95 и не скрываемое средним значением, определяет скорость ответа агента. Количество токенов за ход составляет основу экономического анализа: память существует для того, чтобы использовать меньше токенов, чем при вставке полной истории, так что слой, потребляющий больше ресурсов, чем экономит, не выполняет свою основную функцию даже при одинаковой точности. Рост объёма хранимой информации приводит к постепенному увеличению задержек и отвлекающих факторов с каждой неделей, пока скорость доступа к данным значительно не ухудшится, причём ни один тест точности в определённый момент времени не выявил проблемы. Стоимость процесса записи, то есть работы по извлечению и согласованию данных, представляет собой реальные вычислительные затраты, которые не отражаются в показателях точности.
Память должна создаваться с учётом эффективности и последовательности, и именно в процессе оценки это подтверждается. Более высокая точность, достигаемая за счёт дополнительных полусекунды на каждый ход, при расходах, превышающих экономию, не делает память лучше, но таблица с результатами, содержащая только столбец с точностью, будет утверждать обратное. Когда рядом с качеством указываются задержка и стоимость, компромиссы становятся очевидными, а не случайными.
Как выглядит устройство на практике
В абстрактном смысле устройство состоит из двух слоёв, четырёх проверок памяти, калиброванного судьи, золотого набора, обновляемого из производственных образцов, и указания стоимости рядом с точностью. Два скетча показывают, что это означает на практике.
Предположим, платформа управления активами хранит свою информацию в виде графа знаний, включающего несколько типов сущностей и связей, при этом данные поступают из многоэтапной системы извлечения, которая присваивает каждому факту оценку достоверности от нуля до одного. Команда не будет оценивать качество результатов, задавая модели вопрос о том, кажутся ли ответы хорошими. Вместо этого она будет тестировать слой поиска непосредственно на наборе маркированных документов, в которых уже известны соответствующие сущности и связи, так что показатели воспроизводимости и точности являются конкретными цифрами, а не приблизительными оценками. Также проводится специальный тест на актуальность информации: если более новый документ корректирует данные, указанные в более старом, запрос должен возвращать обновленные значения. Та же система оценки, используемая для анализа графа перед тем, как агенты начнут им пользоваться, применяется и к памяти агентов.
Теперь представим систему юридического анализа, в которой есть несколько десятков агентов: некоторые выполняют функции оценщиков, а другие — аналитиков; они используют общую структурированную таблицу оценок вместо обмена текстами документов. В такой ситуации единообразие становится ключевым показателем, поскольку агент, противоречащий установленной оценке в общем состоянии, представляет собой измеримый дефект, а не просто что-то, что кто-то заметил. Стоимость одного этапа обработки отображается на том же панели управления, что и качество, поскольку слой маршрутизации, определяющий, какие агенты действительно нужны для обработки документа и значительно сокращающий количество вызовов модели, имеет смысл сохранять только в том случае, если оценка показывает сохранение качества при снижении затрат. Ни одна из систем не завоевывает доверие, просто превосходя стандарты; обе завоевывают его за счёт измерений на собственных данных, с учётом всех уровней обработки и проверок, соответствующих их задачам.
Признаки того, что оценка является узким местом
Несколько симптомов указывают на сам процесс оценки, а не на модель, хранилище или механизм поиска:
- Система памяти была выбрана из списка лидеров, но в реальных условиях её показатели постоянно не совпадают с ожидаемыми.
- Единственным критерием является точность ответа от начала до конца, поэтому неудачу невозможно связать с ошибкой поиска или с тем, что модель неправильно обработала полученные данные.
- Показатели поиска берутся из метрики воспроизведения контекста фреймворка, и не существует никакого маркированного набора данных, что означает, что большая языковая модель сама оценивает процесс поиска, считая это метрикой.
- Агент противоречит сам себе или предоставляет устаревшие данные, но система этого никогда не заметит, поскольку она тестирует только отдельные запросы и игнорирует вопросы согласованности, свежести, отказа от ответа и забывания.
- Никто не знает, как последние изменения в памяти повлияли на задержку или использование токенов, поскольку единственной записываемой метрикой является точность.
Учитывая эту закономерность, более мощная модель или более умный механизм поиска не смогут спасти ситуацию, поскольку то, что невозможно наблюдать, невозможно улучшить. Решение заключается в следующем: разделить процесс поиска и формирование ответа, оценить качество поиска с помощью метрик ранжирования на наборе с метками, добавить четыре проверки памяти, калибровать работу оценщика вместо того, чтобы полагаться на его мнение, обновлять «золотой набор» данными из реальных условий, а также указывать стоимость и задержку вместе с точностью.
Это также завершает обсуждение данной темы. Окно контекста — это не память. Хранилище, созданное вместо неё, должно считываться с использованием алгоритмов ранжирования, а не поиска. Рабочий набор данных, находящийся у модели, необходимо управлять, а не просто расширять, а механизм записи должен консолидировать информацию, а не накапливать её. Всю систему потом нужно оценить на собственных данных, учитывая процессы поиска, формирования ответа и четыре проверки, которые игнорируются в общедоступных тестах, причем необходимо учитывать не только точность, но и стоимость и задержку, поскольку таблицы лидеров действительно не могут дать информацию, необходимую для принятия решений. Если сразу создать память и способ её оценки, то на основе цифр можно будет понять, запоминает ли агент информацию. Если пропустить оценку, то придётся полагаться на результаты кого-то другого по проблеме, которая никогда не была его проблемой.
Связанные материалы
- Оптимизация агента Terraform с помощью DSPy: сначала создайте верификатор, затем оптимизатор — Агенты Terraform формируют схемы. Сначала необходимо создать детерминистичный верификатор, установить базовый уровень для агента, а затем использовать DSPy и GEPA для оптимизации его файла с параметрами, что позволяет получить точные результаты.
- Форма онтологии против размера модели: сколько стоит дизайн графа для ИИ-агента — Как три варианта формы одного графа знаний в сфере страхования повлияли на точность, количество вызовов инструментов, количество токенов и стоимость работы как небольших, так и крупных моделей в Azure Cosmos DB.