AIエージェントの記憶は、ベクトルRAGを捨てて「エージェント検索」へ向かう
We Built an Alternative to Vector RAG for AI Agent Memory
従来のRAGは、文書をチャンクに分割し、埋め込みを生成してベクトルDBから類似箇所を取得する固定パイプラインだった。しかしAIエージェントは、ツールを選び、複数ソースを比較し、多段階のワークフローを実行する。MicrosoftやLangChainが示すように、検索はエージェントが呼び出すツールへと変わりつつある。チャンキングや埋め込みが不要になるわけではないが、すべてのエージェントが最初にベクトル検索基盤を構築すべきではない。Claixは、文書をMarkdownやJSONに変換し、複数文書の比較や直接クエリを可能にする文書レイヤーを提案している。
ベクトル検索は、すべてのAIエージェントの普遍的な基盤ではなく、エージェント型情報システムの中の一つのツールになりつつある。
HNでの議論
10- geuis
サイト全体がClaudeで生成されたように見える。
サイトはスクロールを乗っ取る。
RAGがどう機能するか、そして「現代のエージェント」がドキュメントにアクセスする必要がある方法と比較してどう違うかについて、膨れ上がった反復的な説明の段落を次から次へとざっと読んだ。
しかし、この「RAGの代替」が一体何なのかは、どの時点でも見なかった。
正直なところ、コピー全体がLLMで生成されたように感じる。
- cmenge
最初の1、2段落は読んだが、その後は2つの理由で読むのをやめた：
A) BM25を使った検索とベクトル埋め込みによる検索は、2つの異なる検索方法であり、どちらにも用途があり、多くの実用的なユースケースでは両方を備えていることが有益だ。検索方法は、誰がいつ呼び出すか、つまり静的なパイプラインなのか、検索ツールがそれらを呼び出す動的なものなのかとは独立している。
B) あなたは静的パイプラインをまるでSOTAであるかのように説明している。記憶が正しければ、我々はそれを1年以上前に捨て去った。それが十分なケースもまだあるかもしれないが、一般的に、LLMがツール呼び出しにおいてそこそこ上手くなって以来、エージェント検索はほぼデフォルトになっている。
- ericol
ええ、結構です。あなたにいかなる種類のドキュメントも共有するつもりは絶対にありません。