В памяти агента есть проблема с правдой
Извлечение подходит для кодирования и обходится дешево; он нарушает полноту, последовательность и происхождение. Почему переход к структурированному состоянию труден и как Neotoma предназначена для этого.
Ключевые выводы
- Извлечение доминирует в памяти агента, поскольку оно хорошо подходит для кодирования и требует дешевизны добавления; он ломается, когда агенты обрабатывают текущее состояние (полнота, последовательность, происхождение).
- Крупные проекты (Zep, Mem0, Letta, LangMem) добавляют структуру, но полная конвергенция сталкивается с препятствиями: запросы «сначала схема» или «сначала сходство», детерминированная идентичность, происхождение только с добавлением, локальный контроль.
- Структурированное состояние выигрывает при полных наборах, принципе «тот же ответ на следующей неделе», происхождении, откате и согласованности между инструментами; Извлечение выигрывает за счет исследования, обобщения и низких первоначальных затрат.
- Структурированное состояние имеет реальные затраты (накладные расходы на схему, сложность приема, холодный запуск); Neotoma смягчает их с помощью развивающейся схемы, идентификаторов на основе хэша и двухпутевого приема, но не устраняет их.
- Neotoma является дополнением к поиску, а не заменой: запросы с приоритетом по схеме, канонические идентификаторы, наблюдения только для добавления, межинструментальный MCP, по умолчанию - сначала локальный.
Для локальной и открытой памяти агентов по умолчанию используется извлечение: конвейеры RAG, агентный поиск, встраивание хранилищ и обход графа — это то, к чему большинство разработчиков стремятся в первую очередь. Опрос 2026 года пришел к выводу, что дизайн памяти, а не возможности модели, теперь является ограничивающим фактором для долгоживущих агентов.
Извлечение хорошо работает для кодирования и исследования, но оно перестает работать, когда агенты обрабатывают текущее состояние. Основные проекты (Zep, Mem0, Letta, LangMem) добавляют разрешение сущностей, постоянство и структуру графов, но полная конвергенция к структурированному дизайну сталкивается с барьерами, которые трудно модифицировать: запросы на основе схемы, детерминированная идентичность, происхождение только для добавления и локальный контроль.
Почему доминирует извлечение
Извлечение соответствует варианту использования, в котором агенты появляются на карте: кодирование. Кодовые базы носят исследовательский характер, вы часто не знаете, где что находится, и вам хочется «где мы обрабатываем X?» вместо того, чтобы «перечислять каждую функцию с указанием ее происхождения». Для этого хорошо подходят семантический поиск и специальный обход.
Большинство людей формируют свое интуитивное представление об агентной памяти на основе кодирования, где достаточно извлечения. Проблема в том, что мы обобщаем это. Для рабочего состояния, такого как задачи, контакты, транзакции и обязательства, вам понадобится тот же ответ на следующей неделе, полные наборы и журналы аудита.
Добавление извлечения также обходится дешево. Вы можете встроить свои документы, подключить векторное хранилище и получить рабочую память за полдня, без проектирования схемы, разрешения объектов и отслеживания происхождения. Это настоящее преимущество, а не просто инерция.
Где прерывается извлечение
Разрывы появляются, когда вы зависите от памяти агента в поисках истины.
Непоследовательные ответы. Запрос «Перечислить все задачи для проекта X» возвращает семь результатов в один день и четыре — в следующий. При извлечении каждый раз выполняется повторный вывод. Исследования подтверждают, что агенты объединяют информацию в разных сеансах и выдают противоречивые во времени ответы по мере роста памяти.
Неполное воспроизведение. Системы RAG с запоминаемостью менее 80 % показывают частота галлюцинаций составляет 34 % по сравнению с 20 % для систем с запоминаемостью более 90 %. Поиск на основе встраивания отбрасывает временную и реляционную структуру, и чем больше сущностей, тем хуже становится отзыв.
Происхождение отсутствует. Когда вы спрашиваете: «Откуда взялось это число?» поиск дает вам предполагаемый ответ на основе любых всплывших фрагментов. Между ответом и исходными записями нет никакой связи.
Невосстановимые записи. Когда агент перезаписывает контакт или объединяет задачи, предыдущее состояние исчезает. Версионирования и отката нет.
Смещение различных инструментов. Задача, созданная в ChatGPT, не может быть надежно запрошена в Cursor. Память поставщика непредсказуемо непоследовательна, а настройки открытого извлечения также по умолчанию не являются перекрестными инструментами.
Что обеспечивает структурированное состояние
Структурированное состояние означает хранилище с типизированными сущностями, стабильными идентификаторами, связями и временными рамками. Один и тот же запрос каждый раз возвращает один и тот же результат, и вы получаете происхождение и откат.
Структурированное хранилище может иметь форму графа, и то, которое я создаю, Neotoma, представляет собой локальный, MCP-совместимый уровень памяти, который предоставляет агентам единый источник достоверной информации об сущностях, отношениях и происхождении. Что отличает его от «настроек графов», распространенных при поиске, так это постоянство, канонические идентификаторы и происхождение. Подробнее о том, почему памяти агента нужен слой истины я писал в другом месте.
Куда движется поле
Крупные проекты приближаются к структурированному состоянию со стороны поиска.
Zep/Graphiti строит график временных знаний, который обеспечивает повышение точности на 18,5 % по сравнению с MemGPT и сокращение задержки на 90 %, а также поставляет сервер MCP. Это наиболее близкое к структурированному состоянию в нынешней экосистеме.
Mem0 использует конвейер двухфазного извлечения и консолидации, точность которого на 26 % выше, чем у памяти OpenAI, с вариантом графа для отношений сущностей. Он по-прежнему в первую очередь ориентирован на извлечение, а структурированный слой является аддитивным.
Letta (ранее MemGPT) сохраняет все состояние в базе данных с редактируемыми блоками памяти. Это наиболее явно «структурированное состояние» среди проектов поиска происхождения.
LangMem/LangGraph предлагает SDK постоянной памяти с семантическими, эпизодическими и процедурными типами и консолидацией памяти. Уровень персистентности существует, но шаблон первичного доступа по-прежнему включает поиск.
Hindsight (исследование 2025 года) организует память в четыре логические сети и достигает точности 83–91% в долгосрочных тестах. Это показывает направление: структурированная память с явными сетями сущностей превосходит плоский поиск.
Могут ли поисковые системы полностью сходиться?
Некоторые вещи сходятся естественным образом, но другие структурно сложно модернизировать.
То, что уже сходится. Извлечение сущностей и структура графа реальны в Zep и Mem0g. Сохранение базы данных вполне реально в Letta и LangGraph. Временное отслеживание реально в Graphiti. Они сокращают разрыв.
Сначала сходство или сначала схема. Стандартный шаблон доступа при поиске — «найти похожие вещи». По умолчанию структурированное хранилище использует «запрос по типу, идентификатору, взаимосвязи или времени». Создание схемы поисковой системы в первую очередь означает изменение поверхности API и ожиданий пользователей, а не просто добавление функции.
Неявная и явная идентичность. При извлечении два фрагмента рассматриваются как один и тот же объект, если их вложения близки. Структурированное состояние рассматривает две записи как один и тот же объект, если они имеют общий канонический идентификатор. Модернизация детерминированной идентичности означает изменение каждого пути поступления.
Вставка или только добавление. Системы извлечения обычно перезаписывают, а хранилище только для добавления сохраняет историю. Letta использует изменяемые блоки памяти, а Zep отслеживает временную эволюцию, которая более близка. Большинство поисковых систем не имеют понятия истории записи.
Происхождение посредством консолидации. Когда Mem0 объединяет факты или LangMem объединяет связанные воспоминания, происхождение из первоначальных источников обычно теряется. Провенанс, который выдерживает слияние, требует, чтобы модель хранения поддерживала его с самого начала.
Детерминизм. Извлечение предполагает ранжирование, и результаты варьируются от запуска к запуску. Структурированные запросы детерминированы: один и тот же запрос возвращает один и тот же результат. Удаление функции ранжирования подрывает полезность поиска. Это принципиально разные контракты запросов.
Локальный контроль. Создание действительно локальной системы без зависимости от облака и телеметрии противоречит бизнес-модели большинства компаний, производящих память. Это не технический барьер; это проблема структурного стимулирования.
Поисковые системы могут частично пройти путь к структурированному хранилищу, но последняя миля требует запросов с приоритетом схемы, детерминированной идентификации, происхождения только для добавления, детерминированных результатов и локальных значений по умолчанию. Такой выбор противоречит сути архитектуры, ориентированной на поиск.
Что извлечение все еще делает лучше
Исследование. Если вы хотите найти в своих заметках что-либо о квартире в Барселоне, вы не знаете схему или тип объекта. Извлечение соответствующих битов без предварительного моделирования.
Обобщение. Когда вы спрашиваете, какое решение вы решили с подрядчиком, функция поиска может выполнять поиск, извлечение и обобщение за один сеанс. Вам не нужно, чтобы этот ответ сохранялся или точно соответствовал в следующий раз.
Специальный обход. Когда вы спрашиваете, где обрабатываются веб-перехватчики Stripe, макет варьируется в зависимости от базы кода и документации. Поиск адаптируется без единого графа.
Низкая первоначальная стоимость. Вы можете получить рабочую память уже во второй половине дня. Для всего, что не требует полноты, последовательности или происхождения, поиск достаточен и обходится дешевле.
Пробелы в структурированном состоянии и как Neotoma их устраняет
Накладные расходы на схему. Neotoma использует развивающийся реестр схем, в котором извлечение с помощью LLM предлагает типы и отношения во время приема. Это снижает первоначальные затраты, но не устраняет их. На практике агент со временем проверяет и исправляет результаты извлечения по мере обнаружения несоответствий.
Сложность приема. Neotoma вычисляет канонические идентификаторы на основе хеша на основе идентифицирующих свойств, поэтому один и тот же объект получает один и тот же идентификатор независимо от источника. Это более предсказуемо, чем сходство на основе встраивания, но это зависит от качества извлечения: «Марк» и «Марк Хендриксон» хешируются по-разному, пока вы их не объедините.
Холодный старт. Neotoma поддерживает двойной прием данных: вы можете загружать файлы для пакетного извлечения или постепенно накапливать состояние посредством диалогов с агентами. Это не мгновенно, но быстрее, чем ждать достаточного количества разговоров для построения полезного графика.
Стоимость только добавления. Объем хранилища увеличивается с каждым исправлением, что делает возможным откат и определение происхождения. В личном и оперативном масштабе это осуществимо, но это реальный компромисс: запросы для определения текущего состояния более сложны.
Не заменяет поиск. Neotoma обеспечивает структурный поиск по типу, идентификатору, взаимосвязи, временному диапазону и окрестностям графа и ожидает, что такие инструменты поиска, как агентный поиск и встроенный поиск, будут выполнять исследование. Это дополнение, а не замена.
Почему я создаю Неотому
На практике я достиг пределов поиска. Задачи, контакты и транзакции требуют канонических идентификаторов, происхождения и доступа к нескольким инструментам. Выбор дизайна напрямую реагирует на барьеры конвергенции, описанные выше.
Сначала схема. Запросы выполняются по типу объекта, идентификатору, взаимосвязи или временному диапазону. В пути запроса нет встроенного сходства, а результаты являются детерминированными.
Идентификация на основе хеша. Один и тот же объект получает один и тот же идентификатор независимо от того, какой источник или сеанс его представил.
Только добавление. Каждый факт отслеживается до своего источника. Исправления создают новые записи, возможен откат.
Кросс-инструмент через MCP. Один уровень памяти доступен из любого клиента MCP: Cursor, ChatGPT, Claude или Claude Code. Одни и те же данные и одни и те же идентификаторы доступны везде.
Сначала локально. Все данные хранятся в SQLite и локальных файлах. Нет зависимости от облака и телеметрии. Вы можете проверить все, что делает система.
Неотома рано. Это версия для разработчиков: только локальная, сначала CLI, с эвристическим разрешением объектов, ручной эволюцией схемы и без веб-интерфейса. Он обеспечивает контракт, и аргумент заключается в том, что этот контракт необходим для агентов, которые обрабатывают текущее состояние, и что само по себе извлечение не может обеспечить его.
Поле сосредоточено на структурированной памяти. Вопрос в том, кто создает уровень, которому вы доверяете свои данные, и какие гарантии он предоставляет. Я хочу, чтобы этот слой был структурирован с самого начала, а не закреплялся постфактум. Локальный, открытый, проверяемый и находящийся под контролем пользователя.