Чому бенчмарки пам’яті агентів вводять в оману та як оцінювати їх на власних даних
Критерії оцінки пам’яті агентів вводять в оману через некоректні ключі відповідей та системи оцінювання. Треба тестувати здатність до пошуку окремо від відповідей, додати перевірки актуальності, утримання та забування.
Джерела: Your Agent’s Memory Benchmark Is Measuring the Wrong Thing
Публічні тестові сценарії для оцінки пам’яті агентів не можуть визначити, яка система підійде для конкретної проблеми, а деякі з них взагалі не можуть надійно сказати, яка система краща. Докази цього є очевидними. У всіх узагальнюваних тестах примітивний підхід, який вставляє весь діалог у запит, перевершує спеціалізовані продукти з пам’яттю, як зазначається у самій статті виробника такої пам’яті. Незалежний аудит показав, що близько шести відсотків відповідей у цих тестах є неправильними, а автоматичний система оцінювання приймає приблизно дві з кожних трьох навмисно неправильних відповідей. Розумною реакцією є припинити обирати на основі таблиць лідерів та створити систему оцінювання на основі власних даних.
Розгляньмо, як команда зазвичай обирає систему пам’яті. Вона дивиться на табель лідерів, бере те, що знаходиться на вершині, і впроваджує його. Через три тижні після початку роботи агент помилково використовує цифру, яку користувач виправив минулого вівторка. Він почав суперечити рішенню, прийнятому тиждень раніше. Єдина інформація, яка була потрібна для запиту, потрапляє в списку після чотирьох неактуальних результатів. Бенчмарк називав цю систему найкращою на ринку, проте не згадував про власні проблеми команди.
Під цим стоїть питання, яке виникає після кожної реалізації системи пам’яті: як ви знаєте, що вона працює? Небажаною відповіддю є те, що показники, до яких зазвичай звертаються команди, не можуть на нього відповісти, а деякі взагалі не можуть надати корисної інформації нікому.
Ранг у табелі лідерів свідчить про те, що система добре впоралася з тестом іншої людини, оціненим іншим оцінювачем, згідно з його уявленням про правильну відповідь. Це не вказує на те, чи зможе ваш агент згадати те, про що згадував користувач три тижні тому. Це окремі питання, і лише одне з них стосується вас.
Критерій оцінки, який ви розглядаєте, вимірює щось інше
Основний результат вимагає уваги. Візьмемо найбільш поширений тест на пам’ять для розмов. Метод без системи пам’яті, який просто вставляє повну розмову у запит та відповідає на основі неї, посів перше місце, трохи випередивши спеціалізовані продукти з пам’яттю у цьому порівнянні. Жоден критик цього не помітив. Цей результат наведений у статті після відомої бібліотеки пам’яті Mem0, опублікованій у журналі з рецензуванням; автори повідомляють, що повний контекст перевершив їхню власну систему за чистою точністю, приблизно в десять разів з більшою затримкою на кожну відповідь. Інший постачальник також цитує цей факт з тієї ж статті, тож це не є пропагандою однієї зі сторін.
Це менш ніяково, ніж здається, і важливо читати його правильно. Вставка всього тексту забезпечує точність, оскільки нічого не було пропущено. Однак цей підхід не є масштабованим через переповнення та квадратичні витрати. Тож бенчмарк, згідно з оцінками, переважно віддає перевагу тій системі, яка найкраще наближається до точності при розгляді повного контексту, використовуючи при цьому менше токенів. Це корисно для вимірювання. Це не те саме, що перевірка того, чи може система згадати якусь деталь, надану користувачем місяць тому; будь-хто, хто сприймає рейтинг як ознаку останнього, помиляється через власні припущення.
Факти, на яких ґрунтується оцінка, ще більш сумнівні. Окремий аудит, який був публічним та можливим до відтворення, хоча й не проходив рецензування колег, ретельно перевірив ключі відповідей до тесту та виявив, що близько шести відсотків з них були неправильними: вигадані факти, помилки у часовому міркуванні, відповіді, приписані неправильному учаснику. Коли аудитори подали стандартному автоматичному оцінювачу неправильні, але правдоподібні відповіді, він прийняв близько двох третин з них. Існує одне важливе застереження. Автори аудиту, Пенфілд та інші, також створюють системи пам’яті, тому вони не є нейтральними. Проте їхню роботу можна відтворити, а відкриті проблеми у власному репозиторії тесту свідчать про те саме, тож проблема є реальною, навіть якщо авторів результатів треба сприймати з певною долею скепсису. Наслідки цього дуже серйозні. Бенчмарк із показником похибки у шість відсотків не може розрізнити дві системи, які відрізняються менш ніж на шість відсотків, а інструмент оцінювання, який вважає результати правильними, якщо вони відповідають двом третинам критеріїв, оцінює рівень впевненості, а не точність.
Цифри від різних виробників також суперечать одна одній. Два найвідоміші виробники пам’яті публікують результати того самого бенчмарку, які суперечать один одному, адже кожен перепроводив тести системи іншого та отримав результат, який інший вважає спірним, оскільки результат сильно залежить від того, хто налаштував інтеграцію. Ключова цифра, яка суттєво змінюється залежно від налаштувань, є маркетинговим інструментом, а не методом вимірювання. Усе це не робить системи поганими. Це означає, що таблиця лідерів не може ранжувати їх за вас, та тим більше не для вашої сфери діяльності.
Довгий контекст — це не пам’ять, а бенчмарки змішують ці поняття
Тихіша плутанина псує порівняння ще до їх початку. Довгий контекст та пам’ять — це різні речі, проте багато оцінок розглядають їх як одну вимірну ось. Ситуація «голка в купі сіна», коли одне речення приховане у довгому документі та модель мусить його знайти, перевіряє здатність до уваги до одного фіксованого вхідного даних. Це зручний тест на працездатність без наукового обґрунтування, лише широко копіюваний сценарій. Більш суворий бенчмарк RULER показав, що багато моделей, рекламованих із величезними вікнами контексту, мають ефективний діапазон значно коротший, ніж зазначено в описі. Обидва методи вимірюють ємність, тобто скільки частини запиту модель насправді може використати.
Пам’ять означає безперервність між сеансами. У понеділок агент щось бере, розмова закінчується та вікно очищується, але до п’ятниці він має все ще пам’ятати про це. LoCoMo та LongMemEval – це тестові завдання на пам’ять у розмовах, які демонструють цикл зберігання потім відтворення інформації протягом багатьох сеансів, тому вони належать до однієї групи, незалежно від їхніх недоліків.
Два рівні для тестування
Коли стандартні тестові завдання виявляються недостатніми, альтернативою є створення власних, і першим етапом проектування є вирішення питання про те, як їх структурувати. Їх слід розділити на два рівні. Один рівень – це пошук інформації: чи повернула система пам’яті правильні факти? Інший рівень – це формування відповіді: чи надав агент нарешті правильну відповідь чи дію? Вони можуть працювати незалежно один від одного, а показник точності від початку до кінця обчислюється середнім за обидва рівні, що приховує причини проблем.
Цей підхід не є чимось новим. Фреймворк RAGAS з відкритим кодом, описаний у статті 2024 року, побудований на ньому та розділяє здатність механізму пошуку знаходити релевантний контекст від здатності моделі вірно використовувати цей контекст. TruLens описує ту саму ідею як триаду: релевантність контексту для пошуку, обґрунтованість того, чи відповідь ґрунтується на знайденому контексті, та релевантність відповіді для того, чи було задане питання вирішене. Назви відрізняються, але принцип розділення залишається тим самим.
Обидві шари є необхідними, але саме їх ігнорують команди. Хороший інструмент пошуку все одно може дати неправильну відповідь, оскільки правильні факти потрапляють у контекст, а модель їх ігнорує, робить помилкові висновки або поєднує їх із тим, у що вже вірила. Саме тому поняття „закріпленості“ є окремою метрикою. Поганий інструмент пошуку все одно може дати правильну відповідь, оскільки модель заповнює прогалини за допомогою своїх параметричних знань, і це ще небезпечніший варіант. Оцінка „від початку до кінця“ вказує на „правильність“, приховуючи той факт, що шар пам’яті не знайшов нічого корисного — ця проблема проявиться пізніше при роботі з фактом з певної галузі, про який модель взагалі не знала. Вимірювання лише кінцевої відповіді не дозволяє відрізнити ефективну пам’ять від випадкового вгадування.
Пошук заслуговує на метрики ранжування, а не на думку ШІ
Етап отримання даних — це той рівень, де арифметика може виконувати оцінку, причому арифметика не має власних думок. Метрики походять з класичної системи пошуку інформації та існують вже десятиліття:
- Recall@k — це частка фактів, які мали б бути отримані та дійсно з’явилися серед перших k результатів. Цей показник є корисним, коли наступний модель толерантний до відволікаючих елементів, а основною проблемою є наявність необхідного факту.
- Precision@k — це частка отриманих елементів, які виявилися релевантними. Він має значення, коли простір для контексту обмежений, а кожен марновитий слот коштує токенів або відволікає модель від правильного напрямку.
- Mean reciprocal rank винагороджує розміщення єдиного правильного факту на першому місці, у випадках фактоїдів, де враховується лише перший результат.
Виберіть той варіант, який краще відповідає способу, яким ваш агент ознайомлюється зі своєю пам’яттю.
Майже жодна команда не звертає уваги на наступний момент, який може бути найкориснішим тут. Популярні системи оцінки, такі як RAGAS, TruLens та DeepEval, використовують показники під назвами «пригадування контексту» та «точність контексту», і природно припускати, що це саме ті метрики ранжування, про які йдеться. Але це не так. У більшості цих інструментів суддя у вигляді ШІ читає отримані фрагменти та оцінює їх, замість того щоб порівнювати їх із позначеним набором фактів, які є справді релевантними. Тож команда, яка вважає, що вимірює якість отримання інформації, насправді просить одну модель мовлення оцінити процес отримання інформації іншою моделлю, тим самим успадковуючи всі упередження судді у вигляді ШІ. Для отримання точних цифр потрібен позначений набір, у якому вказано, які збережені факти є релевантними для кожного запиту; після цього показники пригадування@k та інші просто є результатом підрахунків. Створення такого набору — це справжня складність, а ці системи дозволяють її уникнути. Це пояснює, чому чесні показники пошуку є рідкістю, тоді як панелі керування, які виглядають надійними, але не є такими, є поширеними.
Чотири аспекти, які ігнорує загальна оцінка RAG
Якщо ставитися до пам’яті агента так, ніби це звичайний канал RAG, ви оцінюватимете лише якість пошуку та відповіді, а потім зупинитеся. Це не враховує чотири проблеми, які стосуються виключно пам’яті та виникають лише через те, що пам’ять зберігається та змінюється з часом.
Суворість дотримання правил. Чи казав агент щось, що суперечить тому, що він розповідав користувачеві раніше, або власній попередній заяві? Стандартна оцінка RAG не може цього виявити, оскільки кожен запит оцінюється окремо, але пам’ять, яка зберігає два протилежні факти, може підставити їх у різні дні, що створює враження несуворості дотримання правил. Можлива також числова оцінка. Модель NLI може позначити пізнішу заяву як суперечливу до попередньої, застосовуючи це до всієї розмови та до інформації, яку повертає система, що перетворює суперечку на метрику для відстеження, а не на скаргу користувача. Дані, створені для виявлення моментів у діалозі, коли одна частина суперечить іншій, формалізують саме цю ідею.
Нещодавність. Як тільки факт змінюється, чи повертає пам’ять нове значення чи старе? LongMemEval (ICLR 2025) включає темпоральне міркування та оновлення знань до числа п’яти перевірених здібностей, тож це є визнаною характеристикою, а не додатковою опцією. Ефективний дизайн є бі-темпоральним: факт фіксує час свого існування у реальному світі та момент, коли про нього дізналася система, а оновлення скасовує стару версію на основі часової позначки, замість того щоб її перезаписувати. Системи на основі темпоральних графів, такі як Graphiti та Zep, працюють саме так. Тест простий: після оновлення запит повертає нове значення, а система все одно може повідомити, що старе значення раніше було правдивим.
Утримання від відповіді. Якщо певний факт ніколи не потрапляв у систему, чи повинен агент про це сказати, чи вигадувати щось? LongMemEval розглядає утримання від відповіді як окрему здатність, і це правильно: пам’ять, яка вигадує, гірша за ту, що визнає відсутність інформації, адже саме вигадану інформацію клієнт у кінцевому підсумку отримує. Ця ідея існує ще з 2018 року — тоді були створені тести розуміння прочитаного з навмисно нерозв’язними запитаннями. У цьому випадку тест є простим: потрібно запитати про щось, що ніколи не зберігалося; правильна система не знаходить нічого та відмовляється відповідати, а несправна — заповнює тишу вигадками.
Забування. Щодо даних, які мали б зникнути або бути видалені, чи справді вони зникли? Методи машинного навчання, спрямовані на відмову від певних знань, надають для цього моделі. TOFU — один із таких критеріїв — ділить дані на набір для забування та набір для зберігання та перевіряє не лише те, що до забутого матеріалу неможливо отримати доступ, а й те, що його сусіди залишилися недоторканими. Тести пам’яті використовують таку саму структуру: після видалення факт не може бути ні отриманий, ні виведений, а пов’язані з ним факти залишаються. Це не те саме, що принцип свіжості. Якщо значення замінюється, старе навмисно залишається у файлі, тоді як справжнє видалення, таке, яке вимагається для забезпечення приватності, має не залишати жодних слідів. Система, яка лише анулює дані, пройде тест на свіжість, але беззвучно провалить аудит щодо права на забування, і лише оцінка, яка розрізняє ці два підходи, зможе це виявити.
Оцінюйте відповіді з допомогою судді, але не дозволяйте йому визначати істину
Оцінки отримання інформації шляхом підрахунку. Зазвичай це неможливо, оскільки правильну відповідь можна сформулювати багатьма способами, тому більшість команд використовують ШІ як суддю. Цей підхід працює в чітко визначених межах, які легко забувати. У дослідженні 2023 року, яке запропонувало використання ШІ як судді, було зазначено, що ефективний суддя у 80 відсотках випадків давав такі ж оцінки, як і людські оцінювачі, що пояснює популярність цього методу. У дослідженні також були описані способи його невдач: упередженість через порядок, коли суддя віддає перевагу тій відповіді, яку бачить першою; упередженість через об’єм, коли нагороджується довжина тексту більше, ніж його зміст; та упередженість через самопідсилення, коли суддя віддає перевагу відповідям, написаним у своєму власному стилі. Дослідження 2024 року уточнило останній момент, показавши щось неприємне: модель може розпізнавати власний стиль письма, і чим краще вона це робить, тим більше їй він подобається. Ще одна стаття 2023 року під назвою G-Eval показала, що оцінки GPT-4 досить точно збігаються з оцінками людей, але вказала на найважливішу проблему в цьому контексті — судді схильні віддавати перевагу тексту, написаному вільно, впевнено та у належній формі. Саме так виглядає впевнена, але хибна відповідь, через що помилкові дані, які звучать правильно, можуть пройти непоміченими.
Використовуйте суддю, але обмежте його функції:
- Оцінюйте за критеріями, заснованими на відомій правильній відповіді, а не за принципом „що краще“, щоб суддя перевіряв факти, а не суб’єктивні враження.
- Перевіряйте, наскільки часто модель погоджується з зразками, позначеними людьми з ваших власних даних, адже суддя, який не погоджується з вами у вашій галузі, є некоректним інструментом оцінки.
- Усуньте упередження, як це було зроблено у початковій статті: змініть порядок кандидатів та взяйте середнє значення результатів.
- Розглядайте оновлення судді-моделі як міграцію набору засобів оцінки, а не як автоматичне покращення. Оцінки від нової моделі не піддаються порівнянню зі старими, а тихе заміщення змінює ці числа з причин, які не мають жодного відношення до тестової системи.
Суддя — це інструмент для калібрування, а не оракул, якому потрібно підкорятися.
Складання комплексу з власних даних
Усе працює на „золотому наборі“: замороженій, позначеній колекції випадків з вашої власної сфери, де кожен запис поєднує запит із фактами, які необхідно отримати, та відповіддю, яка має з’явитися. Це функціонує як набір засобів для перевірки на регресію, тобто інструмент, який має постійно працювати коректно, адаптований під недетерміністичний результат. Багато команд починають з кількох сотень ретельно підібраних випадків. Цей діапазон є орієнтовним критерієм для фахівців, а не законом, тож сприймайте його як початкову точку, яка буде розвиватися.
Створення набору даних — це не найскладніша частина; справжньою проблемою є збереження його точності. Заморожений золотий набір поступово перестає відповідати реальному трафіку, оскільки продукт, корпус даних та користувачі розвиваються, а повністю оновлений набір на основі застарілих даних створює хибну впевненість — найдорожчу з усіх. Рішенням є циклічний підхід: брати невдачі з реальної експлуатації та включати їх до золотого набору як свіжі, позначені випадки, видаляти ті, що більше не відображають реальність, щоб набір постійно відстежував розвиток продукту, а не був лише його статичним знімком. Синтетичні випадки можуть сприяти покриттю певних сценаріїв, і кілька фреймворків їх створюють, проте генеровані випадки мають обмеження моделі, яка їх створила, тому все одно потрібен набір даних, перевірений людиною.
Цей набір тоді працює в двох місцях, адже офлайн- та онлайн-режими виявляють різні проблеми. В офлайн-режимі, порівнюючи з ідеальним набором даних, він контролює випуск продукту: цей процес є повторюваним та детермінованим, і він підтверджує, що ніщо з того, що вже було зрозуміло, не пошкоджено. В онлайн-режимі, аналізуючи реальні дані з вищою частотою збору, він виявляє те, що неможливо було виявити за допомогою фіксованого набору даних, таке як зміна розподілу, незвичайні запити з довгими результатами, яких ніхто не передбачив, та повільна затримка, що проявляється лише після кількох тижнів накопичення стану системи. Зелений статус офлайн-роботи означає, що відоме залишається недоторканим; онлайн-моніторинг виявляє невідоме. Розглядайте перший варіант як дозвіл на випуск продукту, але ніколи не як доказ його коректної роботи.
Витрати та затримки мають бути в одному показнику ефективності
Витрати та затримки є тими показниками, які зазвичай ігнорують у більшості оцінок, проте для пам’яті вони є обов’язковими. Пам’ять знаходиться на критичному шляху кожного кроку, тому час її звернення, вимірюваний за показником p95 та не приховуваний під середнім значенням, визначає швидкість відповіді агента. Кількість токенів на крок становить основу економічних обґрунтувань: пам’ять існує для того, щоб використовувати менше токенів, ніж при вставці повної історії, тож шар, який використовує більше ресурсів, ніж економить, не виконує своєї основної функції, навіть якщо точність залишається однаковою. Зростання обсягу пам’яті є повільною регресією, яка щотижня додає затримки та відволікаючі фактори, поки швидкість звернення до пам’яті значно не погіршується, причому жоден тест точності у певний момент часу не підняв попередження. Витрати на запис — тобто процес вилучення та узгодження даних — є реальними обчислювальними зусиллями, які не відображаються у показниках точності.
Пам’ять слід створювати з урахуванням ефективності та послідовності, і саме під час оцінки це підтверджується. Вища точність, яка досягається завдяки додатковим півсекунді на кожен крок, при витратах, що перевищують економію, не робить пам’ять кращою, проте таблиця оцінок із лише стовпцем точності так буде стверджувати. Коли поруч із якістю вказуються затримка та витрати, компроміси стають очевидними, а не випадковими.
Як виглядає цей пристрій на практиці
У абстрактному сенсі пристрій складається з двох шарів, чотирьох перевірок пам’яті, каліброваного оцінювача, золотого набору, оновлюваного з серійного виробництва, та витрат, вказаних поруч із точністю. Два скетчі показують, що це означає на практиці.
Припустимо, платформа управління капіталом зберігає свою інформацію у вигляді графа знань із кількома типами ентитетів та взаємозв’язків, який живиться багатоетапною системою вилучення даних, що присвоює кожному факту оцінку достовірності від нуля до одиниці. Команда не буде оцінювати її, запитуючи модель, чи здаються відповіді хорошими. Вона буде прямо тестувати шар пошуку на основі позначених наборів документів, де правильні ентитети та взаємозв’язки вже відомі, тож показники відтворення та точності є конкретними цифрами, а не приблизними оцінками. Нещодавність також підлягає спеціальному тестуванню: якщо новіший документ коригує щось, сказане у старішому, запит має повертати оновлене значення. Та сама система оцінювання графа перед тим, як агенти почнуть ним користуватися, застосовується також до пам’яті агентів.
Тепер уявімо систему юридичного аналізу з кількома десятками агентів, де деякі виконують функції оцінювачів, а інші — аналітиків, які використовують структуровану таблицю оцінок замість обміну текстами документів. У такій системі консистентність стає ключовим показником, адже агент, який суперечить вже встановленій оцінці в спільному стані, є вимірюваним дефектом, а не просто щось, що хтось помітив. Витрати на кожен крок відображаються на тому самому панелі керування, що й якість, оскільки шар маршрутизації, який визначає, які агенти насправді потрібні для обробки документа, та значно скорочує кількість викликів моделі, має сенс зберігати лише тоді, коли оцінка показує збереження якості при одночасному зниженні витрат. Жодна з систем не здобуває довіри, просто перевершуючи стандарти; обидві її здобувають шляхом вимірювань на власних даних, через перевірки на різних рівнях, які відповідають їхній роботі.
Ознаки того, що оцінка є вузьким місцем
Кілька симптомів вказують на сам процес оцінювання, а не на модель, сховище чи механізм пошуку:
- Система пам’яті була обрана з топ-листу, проте результати її роботи постійно не збігаються з показниками у продакшені.
- Єдиним показником є точність відповідей від початку до кінця, тому неможливо приписати невдачу помилці під час пошуку чи неправильному обробленню фактів моделлю.
- Кількісні показники пошуку походять від метрики контекстного запам’ятовування фреймворку, і не існує позначених наборів даних, що означає, що ШІ сам оцінює процес пошуку та вважає це показником.
- Агент суперечить сам собі або надає застарілі факти, проте система ніколи б цього не помітила, оскільки вона тестує лише окремі запити та ігнорує послідовність, актуальність, утримання від дії та забування.
- Ніхто не знає, який вплив мали останні зміни в пам’яті на затримку чи використання токенів, адже єдиним показником, який записують, є точність.
З огляду на цю схему, навіть потужніший модель чи розумніший інструмент для пошуку не допоможуть вирішити проблему, адже те, що не можна спостерігати, не можна покращити. Рішення полягає у наступному: розділити процес пошуку та формування відповіді, оцінити ефективність пошуку за допомогою метрик ранжування на позначеному наборі даних, додати чотири перевірки пам’яті, налаштувати роль оцінювача замість того, щоб довіряти його оцінкам, оновити «золотий» набір даних реальними даними та відображати витрати та затримки разом із точністю.
Це також завершує обґрунтування. Вікно контексту — це не пам’ять. Сховище, створене на його місці, має зчитуватися за допомогою ранжування, а не шукання. Робочий набір даних перед моделлю потрібно керувати, а не просто розширювати, а шлях запису має консолідувати інформацію, а не накопичувати її. Усю цю систему потрібно оцінити на власних даних, враховуючи процес пошуку, формування відповіді та чотири перевірки, які ігноруються у публічних тестах, з урахуванням витрат, затримки та точності, адже табель лідерів справді не може надати інформації, яка вам потрібна. Створіть пам’ять та її оцінку разом, і ви зможете за допомогою цифр дізнатися, чи пам’ятає агент. Якщо пропустити оцінку, ви будете керуватися результатами когось іншого щодо проблеми, яка ніколи не була його проблемою.
Пов’язана література
- Оптимізація Terraform Agent за допомогою DSPy: створіть верифікатор перед оптимізатором — Агенти Terraform створюють схеми. Спочатку потрібно побудувати детерміністичний верифікатор, визначити базові параметри агента, а потім використати DSPy та GEPA для оптимізації його файлу налаштувань з точними результатами.
- Форма онтології проти розміру моделі: скільки коштує дизайн графа для AI-агента — Як три форми одного графа знань у сфері страхування вплинули на точність, кількість викликів інструментів, кількість токенів та витрати для малих та великих моделей у Azure Cosmos DB.