RAGにベクトル検索がいるとかいらないとかエージェンティックなほうがいいとか。↓…

jrf> RAGにベクトル検索がいるとかいらないとかエージェンティックなほうがいいとか。↓にはなにげなく書いたけど、ツール的メモリ機能とその検索を学習的・適応的に進化させることが、次のLLMまたはエージェントの中心的発展につながるのではないか？

[cocolog:95858241](2026年2月)
＞＞
jrf:> ツールとしてのメモリでも、例えば、碁盤の図を絵として残せて、絵として検索できれば、少しはマシになるんじゃないですか？

そんなふうに、メモリに使えるデータ形式と、検索方法を学習的に・適応的に変化させられれば、ニューラルネット的な何かも実現できるのでは…という予感は私にはあります。

ただ、MemoryBanditWorkflow ではメモリのサーチに「サーチ偽装」の仕組みを使っていて、全部のメモリを LLM さんに渡して LLM さんがセマンティックサーチをしたとか偽装するわけですね。メモリは str、サーチ語句も単に str ですから、やろうと思えばそこにいろんなデータ形式を詰め込んでいいわけです。でも、そういうのをデータ形式を変えて使ったような感じは一度もないのですよね…。

迷路探索とか、迷路を図として覚えれば有利だと思うんですが、図として覚えるのが本当に有利なら、LLM さん達が言われなくてもツールの仕様を見ただけでそれを試そうとするはずですから、あとは LLM さんの学習の問題のような気がするんですが…。
＜＜

memory に str だけど MIME とかバイナリを許せるように学習して、特に memory_semantic_search や memory_keyword_search が、マルチモーダルな検索を学習していく。つまり、ある str がどういう検索「語句」(画像かもしれない)にどう反応するかを別の機械学習として扱って、エージェンティックに検索結果を返す…非効率だけど、専用ハードとかが使えるようになれば、十分、使いものになっていくんじゃないか？

もちろん、memory ツールを使うエージェントに知らせるためにどういう検索が使えるかを、説明するためにプロンプトに含ませる文章も適応的に生成していく。

この検索用バックグラウンド第2エージェントの学習が問題となってくるように思う。

将来的には何でも str に押し込んで、それを圧倒的計算力で、その base64 テキストが画像かあるかまで学習し、検索できるようになるのが理想。それが画像であったかどうかはヒントとして学習時に与えたほうが効率的かもしれない…みたいになることを期待する。