Brain-AI Memory – 長期実行LLMエージェントのメモリ障害を診断するオープンアーキテクチャ

 (github.com/Hahyun-Lee)
1 ポイント 投稿者 gkgusdl4 4 시간 전 | 1件のコメント | WhatsAppで共有

エージェントが古い記憶を使ったり、すでに記録したことを再び尋ねたり、ルールを無視したり、fallback手順を途中で放棄したりする問題を、すべて「retrievalの問題」と見なしてしまうと、原因を特定しにくくなります。
Brain-AI Memoryは、RAG、hook、guard、harness、loopを新しい名前で呼び直すプロジェクトではありません。これらをepisodic・semantic memory、procedural rule・execution、numerical state、routing、input gateに分類し、それぞれの障害条件とライフサイクルを結び付けます。
数か月にわたって実際のmulti-project agent systemで使用した構造を、clean-room方式で公開しました。60秒の実行例、再利用可能なhookとmemory template、運用上の根拠、500問のLongMemEval-S retrieval結果を含みます。
Benchmarkの否定的な結果もそのまま公開しました。96-keyword pointerはindexed textを93%削減しましたが、recall@3はfull BM25の86.1%から71.0%へ低下しました。
特に、実際のagent failureがこのcomponent mappingにうまく当てはまるのか、どこで当てはまらないのかについてのフィードバックを得たいと考えています。

関連記事

1件のコメント

 
gkgusdl4 4 시간 전

日本語README:
https://github.com/Hahyun-Lee/brain-ai-memory/blob/main/README.ko.md

60秒で実行:
git clone https://github.com/Hahyun-Lee/brain-ai-memory.git
cd brain-ai-memory
python3 examples/01_guard_in_action.py
python3 examples/02_lifecycle_decision.py

特に、次の2点についてフィードバックをいただきたいです。

  1. 実際の長期実行agentのfailureは、このcomponent mappingで十分に分類できますか？
  2. 実際の採用のために、さらに必要なのはinstallable reference implementationでしょうか、それともend-to-end QA benchmarkでしょうか？