従来方式より280倍高速なローカルAIメモリエンジン

민

민현진

Mar 11, 20267m ago

今日、AIエージェントを話すとき、ほとんどはモデルのパフォーマンスや自動化の流れに焦点を当てています。ところが実際にぶつかるボトルネックは意外とメモリーの場合が多いです。最近海外ではこの地点を掘り下げた事例が出てきました。

GitHubとRedditで公開されたSynrix Memory Engineは、ベクトルDBの代わりに、構造化されたローカルメモリエンジンで、従来の方法より280倍速いと主張して注目を集めました。

興味深いのは、 AIメモリを必ずベクトル検索で解くべきかという質問を再び取り出したという点でさらに注目を集めました。

ベクトルDBだけでは足りないメモリもあります

これまでAIメモリといえば、ベクトルDBを先に思い浮かべることが多かったです。しかし、エージェントが実際に頻繁に取り出す情報は、必ずしも意味ベースの検索だけが必要なわけではありませんでした。

ベクトル検索と構造化エージェントのメモリの違いを示す概念図

ユーザー好み、以前の作業状態、保留中のタスクのように、すでに構造が決まった記憶も多いんですよ。 Synrixはこの点を狙っています。文書の意味を同様に見つける方法ではなく、名前と規則が定められた情報をすばやく取り出すローカルメモリに近いです。

Synrixが掲げる鍵は、固定サイズノード、prefix query、mmapインフラストラクチャです。簡単に言えば、全体を盗むのではなく、必要な結果だけすぐにアクセスする方法です。

Redditの開発者は、10kノードで280倍高速であると説明し、埋め込みや外部API呼び出しなしでローカルで直接検索されることを強調しました。

これが注目された理由も明らかです。エージェントのメモリをクラウドではなくデバイス内で直接保持して取り出すことができるという点からです。特に、エッジ環境やオンデバイスAIなど、ローカル持続性が重要な場合は、かなり魅力的な方法です。

レディットの反応は思ったより分かれていた。ある人は構造化メモリ用に意味のある試みだと見て、他の人は結局速いKey/value + prefix lookupに近いと指摘しました。

実際に作者もセマンティック検索をするわけではなく、そのような検索が必要な場合は、ベクトルDBを使うのが正しいと認めました。

そこで、この事例の核心は「ベクターDBに勝った」というより、比較対象が異なるメモリ構造を持ち出したということにあります。むしろこの議論のおかげで、AIメモリも目的に応じて分けて設計しなければならないという点がより明らかになりました。

AIエージェントのメモリは、ドキュメントの検索、ユーザーの好み、作業状態、セッションの記録はすべて記憶のように見えますが、実際には同じ方法で扱いにくく、設計が重要になりました。

将来的には、ベクトルDBと構造化メモリを分割して書き込む方法がより自然になる可能性があります。非定型文書はベクトル検索で、状態値と task memory はローカル構造化メモリに取り込むように使うことができるということです。

Synrixは完成型正解というより、その方向を先に見せた事例で見たほうがより合って見えます。

Synrixが本当に既存の方法を完全に置き換えるかどうかはまだ見守る必要があります。ただし、今後AIエージェントメモリは単に多く保存する問題ではなく、どの記憶をどのように取り出すかという問題になる可能性が大きいという点です。今回のケースは、その変化を先に示した信号のように見えます。

「AI Native百科事典」を購読する

サイトを購読すると、新しい投稿などの最新のアップデートを通知やメールで最初に受け取ることができます。
Slashpageに参加して「AI Native百科事典」を購読してください！