cocolog:95531341
AI(LLM) に「連想記憶機構」は必要か？ 基本的には LLM 自身が持つ連想を活かし、RAG やツールコールで対応していくのだろうが、エージェントなどはその作業に必要な資料やその要約を自律的に生成・保存・検索できるようになる必要があるのだろう。 (JRF 9075)
JRF 2025年7月10日 (木)
これがポケモンぐらいの長大(?)なゲームになると、要約では不十分で「連想記憶」的機構が必要になるのだと思う。コンテクストに記憶を用意しておき、状況も示されてるプロンプトを「改良」して、連想したこともプロンプトに含めるような機構が必要なのかもしれない。
JRF2025/7/109033
ただ、連想記憶をどう作るかは結構難しい。行動やプロンプトをじゃんじゃん記憶して、それを再生するだけではおそらく不十分で、その付近(?)の文脈も記憶されてる必要があり、場面・場面ごとの要約などが必要なように思う。
しかし、思い返せば、LLM 自体にも連想の機能はデフォルトとしてある。それを外部連想記憶で補助するという方向なのだが、LLM 自体の連想を殺さず、どこまで補助ができるのか。LLM自体の連想をメインに考えるなら、そこに渡される「連想記憶」は、むしろ、「連想」を促すような「資料」でいい、RAG で十分ではないか、という方向が考えられる。
そこから考えていった考察が↓になる。
JRF2025/7/102285
……。
○ 2025-07-09T16:52:50Z
今の AI さん達に「連想記憶機構」が必要か？
● まず、LLM 自体はその内部で連想的なことはすでにやっているはず。
● RAG やツールコールではダメなのか？
● 連想資料の自律生成や検索は可能なのか？ 効率的なのか？
…という点を少し詳しく考える。
JRF2025/7/104886
まず、LLM 自体はその内部で連想的なことはすでにやっているはずで、外部に連想記憶機構を作るとしたら、その性能はおそらく劣化せざるを得ないだろうと私は思う。
連想はマルチモーダルであることが求められる。文章(要約)による記憶の生成では不十分だろう。例えば、ロボットの細かい動作などは本来ニューラルネット的に学習することが求められるが、それを文章で補うには限界があるのだ。
JRF2025/7/108970
ただ、そういったことを補うとすれば報酬関数などの戦略的記述からの RLRMDiffusion (RL Result Model Diffusion, [cocolog:95459644](2025年5月))のようなものになるだろう。または、どこかの映像からの模倣を指示することになるだろう。
それは基本的にはツールコール、または RAG 的なものになるということだ。将棋の一手などもツールコールで専用 AI から得るということで、連想はツールコールや RAG で十分で、あとは LLM さん内部の連想にまかせればいいという文脈がある。
JRF2025/7/100979
それとも、そこから漏れるものがあるのか？ 例えば、エージェントが人間の仕事を覚えるときは、RAG のためには、文章化されていない・ビデオ化されていない資料が必要になる。それを AI さん達自身が作るという話になるのかもしれない。漏れるものがあるとして、それを AI さん達が自律的に生成して残す…要約のタイミングなどを自律的に知り、それを検索するタイミングを知ることができるのか…が問題になるだろう。
JRF2025/7/107881
もちろん、バックグラウンドで強制的に別の AI を立ち上げ要約(や要約の要約…、画像や映像を使った…)を生成しながら、適宜プロンプトに含める方向もあるのかもしれないが、それは最初に戻るが、そういうバックグラウンドな外部の機構は、LLM 自体の内部の連想の機能には劣ることになるだろう。
JRF2025/7/108591
……。
……。
追記。
現実的な妥協をして連想記憶を要約を適宜に生成することでで構成するとき、ある要約 X1 がすでに生成されていたとしよう。それを想起してアクションしたときの要約 X2 を新たに作るとき、X2 によって X1 が想起されたことを後方参照として X1 に残すと良いのかもしれない。もちろん、X1 を想起して X2 が作られたことを文章的に言及しておくべきだろう。前方参照もあったほうがいい。Gemini さんに言わせると重みをつけてもいいということだった。ページランクみたいに。
これは、↓で述べたことに近い。
JRF2025/7/246885
[cocolog:95475426](2025年6月)
＞私の「ひとこと」ブログは、[cocolog:95466253] みたいに書くとそこにリンクが張られたり日付を書くとリンクが張られたりする。keyword を書くと自分のサイトの google 検索にリンクが張られる。こういったものが脳のリンクに模したものであるという認識が私にはある。もちろん、ハイパーリンクの考え方にも影響されている。ただ、それが、今の AI (LLM) さんたちにはあまり役に立ってなさそうなのが、ちょっと意外である。＜
JRF2025/7/247238
この「ひとこと」ブログは以前、トラックバックの機能が使えたころは、4半期末に後方参照リンクをトラックバックの機能を使って付けてもいたのだった。
このような後方参照は、[cocolog:95538601](2025年7月)で述べたような、注意機構的なミニプログラムの記憶(記録)でできるのなら、モアベターな気がする。もちろん、前方参照の記録もミニプログラムでできるようでなければならないが、どうもそれが難しく、LoRA みたいなものを最低限必要とするのだろう…という見立てだった。
JRF2025/7/247324
……。
……。
追記。
私の「ひとこと」ナレッジベースシステムには keyword 文がある。
keyword 文は、直接参照(URL 的参照)に比べ、実質的に未来もリンクできるところに特徴がある。
keyword 文を AI がどう使うか考える。キーワードリストを表示できるだけではキーワードの量が膨大になったときに意味をなさない。文章(例えば、ユーザーの要求などに応じて AI が検索用に生成した文章)に含まれる(または連想される)キーワードをランクを付けて返すツール機構が必要なのだろう。
JRF2025/8/11415
キーワードが抽出(または連想)できれば、私の「ひとこと」ナレッジベースシステムのように、そのキーワードでメモリ内を(セマンティック)検索すればいい。
AI 自身がキーワードの(基礎)ランクを(一時的に)上げたり下げたり、キーワードを登録／削除できるようにすべきかもしれない。超大規模なシステムではランクの上げ／下げが有効で、中小規模な問題では、キーワードの削除などが有効なのだと思う。
JRF2025/8/14216
キーワードをメモリから機械的に抽出することも可能ではあるだろう。しかし、そうせず、メモリに保存する文の中に keyword 文で指定させたり、キーワードを登録させたりするほうがよいのだと思われる。なぜなら、そこに LLM の「個性」が出るからであり、LLM 内部の連想記憶にとって有利なキーワードが選ばれるだろうから。
JRF2025/8/14440
……。
あと、連想のために要約を随時していくシステムを考えるのであるが、長大な文をすべてプロンプトに含めていくのは限界があるので、プロンプトに含めるときに圧縮が必要なら、その文脈での要約をして圧縮していくようなことをする必要があるのだろう。とても高コストになるが。
JRF2025/8/15038
熊剣迷路問題([cocolog:95524118](2025年7月))の実験では、(その「ひとこと」の最後のほうに書いたのだが、)今の AI なら一般的な「人工知能的手法」を用いるだけで迷路に特別な要素なく、迷路を解くことができることがわかったが、そういった手法で解けたのは、問題が小さく、必要な記憶が「要約」で十分に表せる範囲に届まっていたからではないかと思ったのだった。
JRF2025/7/103537