Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 7
Закреплённые комментарии
Спасибо за текст — он редкий в хорошем смысле: не про «я собрал память», а про то, где именно она ломается. Я узнал в этом свою возню с памятью в HALVITA-ARK, только у меня она начиналась не с Postgres, а с вопроса «что вообще считать фактом, который стоит помнить?»
То, что вы показываете на примере «общего токена, который разбудил граф», — это, на мой взгляд, ключевая проблема любой памяти, построенной вокруг сходства. Вектор говорит, что два текста рядом. Он не говорит, что они про одно и то же в одном смысле. В моих документах по памяти это называется «память, которая забывает правильно»: ценность не в том, чтобы удержать всё похожее, а в том, чтобы вовремя не удержать похожее, но нерелевантное. Семантическая близость — это приглашение к кандидату, а не доказательство.
Из вашей архитектуры мне больше всего откликается бюджет на финальную выдачу. Это очень честный ход — считать качество не по тому, что «нашлось», а по тому, что дошло до модели. У меня в экспериментах то же самое: можно иметь красивый граф и правильный факт, но если он не попал в контекст из-за лимита, его для агента не существует. Поэтому я бы добавил в вашу схему ещё один слой: память должна уметь говорить «нет». Не «вот пять похожих штук», а «ни один из кандидатов не подтверждается источником в нужном смысле». Это дисциплинирует и поиск, и извлечение.
По векторной памяти я бы предложил не заменять её, а сделать её подозреваемой. У вас уже есть лексика, граф и морфология — это хороший набор для перекрёстной проверки. В HALVITA-ARK я экспериментировал с фрактальной и ассоциативной моделями памяти, и главный вывод простой: вектор хорош как указатель, плох как судья. Если векторный кандидат не подтверждается ни источником, ни связью, ни точной цитатой — его место не в контексте, а в карантине до уточнения. Иначе память превращается в генератор правдоподобного шума.
И ещё одно, возможно, спорное. Ваш кейс с устареванием («семь — актуально» и «семь — больше не актуально» семантически почти неразличимы) показывает, что память — это не только поиск, но и временная логика. Вектор вне времени. Поэтому я бы хранил не только embedding, но и «срок годности» факта и основание, по которому он был помечен устаревшим. Это не делает память умнее, но делает её честнее.
Если захотите сравнить заметки — у меня в docs/memory лежат наброски по фрактальной и ассоциативной моделям, без претензии на готовое решение. Ваша реализация с транзакциями и дедупликацией событий — как раз то, чего мне не хватает в моих прототипах.
Спасибо за текст — он редкий в хорошем смысле: не про «я собрал память», а про то, где именно она ломается. Я узнал в этом свою возню с памятью в HALVITA-ARK, только у меня она начиналась не с Postgres, а с вопроса «что вообще считать фактом, который стоит помнить?»
То, что вы показываете на примере «общего токена, который разбудил граф», — это, на мой взгляд, ключевая проблема любой памяти, построенной вокруг сходства. Вектор говорит, что два текста рядом. Он не говорит, что они про одно и то же в одном смысле. В моих документах по памяти это называется «память, которая забывает правильно»: ценность не в том, чтобы удержать всё похожее, а в том, чтобы вовремя не удержать похожее, но нерелевантное. Семантическая близость — это приглашение к кандидату, а не доказательство.
Из вашей архитектуры мне больше всего откликается бюджет на финальную выдачу. Это очень честный ход — считать качество не по тому, что «нашлось», а по тому, что дошло до модели. У меня в экспериментах то же самое: можно иметь красивый граф и правильный факт, но если он не попал в контекст из-за лимита, его для агента не существует. Поэтому я бы добавил в вашу схему ещё один слой: память должна уметь говорить «нет». Не «вот пять похожих штук», а «ни один из кандидатов не подтверждается источником в нужном смысле». Это дисциплинирует и поиск, и извлечение.
По векторной памяти я бы предложил не заменять её, а сделать её подозреваемой. У вас уже есть лексика, граф и морфология — это хороший набор для перекрёстной проверки. В HALVITA-ARK я экспериментировал с фрактальной и ассоциативной моделями памяти, и главный вывод простой: вектор хорош как указатель, плох как судья. Если векторный кандидат не подтверждается ни источником, ни связью, ни точной цитатой — его место не в контексте, а в карантине до уточнения. Иначе память превращается в генератор правдоподобного шума.
И ещё одно, возможно, спорное. Ваш кейс с устареванием («семь — актуально» и «семь — больше не актуально» семантически почти неразличимы) показывает, что память — это не только поиск, но и временная логика. Вектор вне времени. Поэтому я бы хранил не только embedding, но и «срок годности» факта и основание, по которому он был помечен устаревшим. Это не делает память умнее, но делает её честнее.
Если захотите сравнить заметки — у меня в docs/memory лежат наброски по фрактальной и ассоциативной моделям, без претензии на готовое решение. Ваша реализация с транзакциями и дедупликацией событий — как раз то, чего мне не хватает в моих прототипах.
Спасибо за такой подробный комментарий и за то, что поделились своим подходом!
Особенно зацепила мысль про вектор как указатель, а не судью. У меня проверка цитаты помогает отсеять неподтвержденные сущности при записи, но сама по себе не доказывает, что система правильно поняла смысл факта. А то, что факт нашелся по нескольким сигналам, еще не гарантирует его релевантность вопросу
Идея карантина интересная. Как вы решаете, какого подтверждения достаточно, чтобы выпустить факт в контекст? И что делаете, если источник есть, но он подтверждает только часть утверждения?
Про устаревание тоже согласен: важно сохранить не только метку, но и основание. У меня старую запись можно пометить устаревшей, оставив ее в истории. Но автоматическое определение срока действия для разных типов фактов пока остается открытым вопросом
Как вы подходите к сроку годности: задаете его по типу факта или пересматриваете запись при появлении новых данных? И где можно посмотреть ваши заметки по фрактальной и ассоциативной памяти? Интересно сравнить подходы подробнее
"не про...а про", "—", "не в том...а в том", "..близость — это .., а не ...", "честный ход", "качество не по тому...а по тому", "Не вот...а ни" - лол в промпте было "добавить негативного параллелизма побольше" или оно само так?
То, какая память предложена и какие обработки текста описаны - все выглядит как вымученный вариант Graphiti. Или что то типа самописного Cognee или Gbrain.
Вопрос к @MatIntellect и @HALVITA пробовали ли их? И какие ощущения?
Вопрос по статье. 10 000 узлов и только 13000 связей это означает что у вас связей как таковых только к ноде и из ноды. Когда есть перелинковка - это повышает количество связей в разы и улучшает качество поиска относительно смысла. Например - имя Нина может вести к персоналиям, а может к событиям, а может к целому пулу документов где встречается это слово. В итоге у вас память выглядит ну крайне неоптимально для поиска или в статье неверно описано ну или, не исключаю, что я совсем ничего не понял.
Спасибо за критику. Вы правильно обратили внимание на связность. Graphiti изучал как вариант для памяти агентов. Cognee устанавливали как плагин на Mac, но при одной из проверок он фактически не работал из-за окружения Python.
По примеру с Ниной согласен: связи человека с событиями, другими людьми и документами могут помочь отвечать на вопросы, для которых одного поиска по словам недостаточно. Но важно не только добавить связи, а проверить, насколько точно они построены и какие из них попадают в контекст. У нас был и обратный случай: поиск зацепился за общее слово, прошел по связям и притащил посторонние факты
Спасибо за конкретные инструменты и повод перепроверить граф. А вы сами пробовали Graphiti, Cognee или GBrain на одной и той же базе? Какой из них лучше справился именно с построением связей и поиском по ним?
Сейчас, из-за особенностей архитектуры моих агентов у меня Gbrain(knowlege в openclaw), он слабее Cognee в поиске, чуть сильнее в разметке при базовых настройках. Размечает норм, но я в ручном режиме все же проверяю новые ноды и связи. Я писал тут немного https://habr.com/ru/posts/1104092/. У меня там на картинке на 1 ноду 3 связи. на самом деле очень часто нода конечная, всего 1 входящая связка и только несколько нод осьминогов.
Увы Graphiti не могу оценить пока в полной мере, не хватает своих мощностей, а облачно не использовал из-за главной идеи "полная" LLM-локальность агентов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Память ИИ агента. Как собрать архитектуру памяти качественно?