⬅️ Сперва прокомментирую графики из прошлого поста!
На нижней половине вроде всё понятно, поясню за верхнюю.
По оси X: на сколько структурированными хранятся знания. Закинули PDF в агента, на выходе у вас что? Саммари? Папка с десятком MD файлов? Или 100+ узлов в графовой БД, по 3-4 связи на каждый?
По оси Y: автономия — сколько супервизии от человека требуется, чтобы решение не «разъехалось» и агент не начал галлюционировать с памятью больше, чем делал бы это без неё.
Левая нижняя часть: небольшой набор Markdown файлов, линковка ссылками на другие документы. Такое отлично работает для более статичных файлов типа тех же
CLAUDE.md, MEMORY.md, ..., SKILL.md и т. п. В каждом файле ВЫ явно инструктируете агента как пользоваться этим, зачем он нужен и что сюда писать. Даёте агенту какие-то MCP ручки для чтения построчно, для векторного поиска или Ctrl+F с помощью grep.НО в таком режиме вы должны активно принимать участие в наполнении этих файлов и время от времени их валидировать. LLM Wiki = Personal Knowledge Management (PKM). В OpenClaw это самая базовая память, но очевидно из-за её недостатков они добавляют альтернативные движки типа Honcho.
А что если хотим долгоживущий процесс, автономного агента а-ля Jarvis?
Правая верхняя часть: проекты типа Vestige: 29 модулей, микс из биологии, техник интервального повторения, в общем полный фарш. Чисто теоретическия такая система при корректной настройке будет поддерживать себя сама, но настройка и обвязка вокруг агента требуется приличная.
Недавно хайпанувший MemPalace, хотя и где-то рядом, совсем о другом — полностью базируется на идее мнемотехники «Дворец памяти», вы могли видеть её подобие в игре Alan Wake 2 (превьюха). Идея дворца памяти эксплуатирует тот факт, что у кожаных по умолчанию лучше работает географическая память — она тупо нужна для выживания. Так можно выдумать некое место и «расставлять» воспоминания там как предметы. Но каким образом это должно помогать LLM... Почему метрики на бенчмарках хорошие? ❓
Что общего во всех работающих подходах
😓 Гибридный поиск — используем векторный, полнотекстовый (BM25), и графовый поиск. Один просто не покрывает эффективно все кейсы. Прогоняем несколько видов — результаты объединяем, например, методом Reciprocal Rank Fusion. Здесь же часто добавляют реранкинг отдельной моделью, HyDE, фильтрации по Mean Reciprocal Rank. Но если тут сильно упарываться, скорее всего вы переизобретёте QMD.
🔄 Иерархические мета-индексы — поверх сырых данных строятся отдельные слои, которые связывают информацию на более высоком уровне. Не «ещё одна таблица», а отдельный проход с помощью LLM для выявления паттернов и неочевидных связей. Тут хорошо помогают reasoning модели, но важно грамотно заварить для них контекст, иначе будет искать связи там, где их нет.
💀 Механизм забывания — память не должна жить вечно. Что-то должно забываться, что-то объединяется или суммаризируется. Без этого — контекст взрывается через пару месяцев. Самый ходовой вариант — взять известную кривую забывания Эббингауза как функцию «важности» знания от времени. Не забывайте, что кривую Эббингауза абьюзят студенты с флеш-карточками Anki, чтобы напротив — не забывать информацию. Поэтому в идеале каждое «вспоминание» должно бафать релевантность. Так сделано в том же Vestige и Hebbs.
🍆 Самообслуживание — система должна сама подсвечивать и устранять противоречия в данных. Раньше вы писали на Python, а теперь на Rust — идеальный агент должен знать что было до и после, что актуально сейчас. Веб-поиск вернул одну фамилию первого автора статьи, а у вас в данных другая? — Надо подсветить это и связать оба варианта, позже в отдельном режиме методично устранить расхождение.
📸 История изменений — если факт обновился, важно понимать, что было раньше. Не просто перезаписать, а сохранить исторический лог. Карпатый предлагал append-only лог-файл, в Hebbs такое реализуется через Graph посредством
CausedBy связи, но прошлые версии по умолчанию не попадают в выдачу.