cocolog:95583904

LLM のメモリ機能の試験実装を行った。かなり本格的な実装(のモックアップ)になるようこころがけた。実装できたことはできたのだが、いまいち Gemini さんは積極的に使ってくれなかった。そこはアテが外れた。 (JRF 4927)

JRF 2025年8月15日 (金) Tweet

成果物は↓。

《experimental_memory_0.0.1.ipynb - GitHub Gist》
https://gist.github.com/JRF-2018/da5a26c24d343f65da54e45e98ba14d4

または↓にもアップロードしてある。いちおう熊剣迷路問題を使ったので。

《JRF-2018/langchain_maze: 熊剣迷路問題 revisited》
https://github.com/JRF-2018/langchain_maze

JRF2025/8/152920

experimental_memory_0.0.1.ipynb は、「LangChain で熊剣迷路問題」の version 0.0.7 相当という位置付け。

JRF2025/8/156829

……。

最近 LLM についてコンテクストエンジニアリングという言葉をよく聞く。実は Web でなく API から使う LLM は「ステートレス」で、会話などの記憶はデフォルトではしてくれない。会話を続けようと思ったら、メッセージをユーザー側で記録しておき、それをいちいち API に与えないといけないのだ。古い記憶を呼び戻したりするには、単純に記録するだけでなく検索基盤も必要となる。そのような基盤をひっくるめてコンテクストと一般的に呼んでおり、それをどううまく構築するかが問題となっている。

JRF2025/8/151440

特にコンテクストのうち、記憶の基盤は単に「メモリ」と呼ばれている。PC のメモリなどとごっちゃになって、わかりにくくもあるのだが、そう呼ばれているのだからしかたがない。

今回は、そのメモリ機能が実際にどう動きうるか、それを見てみたいと思って、私なりに実装してみた。基本的には LLM のツールコールという機能を使って、ツール群としてメモリ機能を実装することになる。

JRF2025/8/159669

RAG をしたい場合、ゲームを解かせたい場合、その他、やりたい問題領域について良いメモリ機能の実装は変わってくると思われる。ただ、どういう場合でも通用するような一般的なメモリ機能があるのか？ あるとすればそれに近いものを実装したいと思った。

今回、とりあえずの試験実装にどういう例がいいか悩んだのだが、とりあえず以前、エージェントの実験として作った熊剣迷路問題を途中から解かせてみて、それでメモリ機能のツールを使ってくれないかと試すことにした。ただ、簡単な迷路問題ではあるが、先のような実装方針があったので、かなり本格的なメモリ機能を用意している。

JRF2025/8/156241

…といっても、セマンティックサーチとかを用意するのは、めんどくさかったので、そういうバックエンドはこれまた AI さんに偽装してもらうことにした。

JRF2025/8/151039

ところで、今回のような手法はすでに限界が認識されていると思われる。ポケモンを解くとかにも必要だっただろう手法で、しかし、それには限界があったようだ。エージェントにコンテクストが大量消費される…とかの最近の話も、この手法と同じような手法についてのことで、その改善策もすでにいろいろ模索されているようだ。ネットではそういう話をチラチラ見る。ただ、そうとはいえ、しばらくは今回のような手法に似た手法もローカル LLM などを用いる場面などでは有効なのだと思われる。今回の試みが、何かの参考になれば幸いである。

JRF2025/8/151549

……。

結論。

gemini-2.5-flash さんはあまりツールを使うのがうまくないが、gemini-2.5-pro さんにお願いするだけで、かなりうまくツールを使ってくれた。何度か実行することで、メモリ機能のテストはできたと思う。ただ、いきなり全部の機能を使ってくれる…とはならなかったのはやや想定外だった。

JRF2025/8/150206

あと、Pro さんは結構無言でツールも使わずターンを終えることが何度かあった。これはおそらくツールを別の名前で呼んだり、似た別のツールを呼ぼうとして失敗しているのかもしれない。Flash さんはそういうことは見た記憶がないので、Pro さんは今そういう「バグ」があるということかも。

あいかわらず summarize_messages 周りでエラーが発生して汚い処理を残してある。今回のログにもその形跡は残したままにしてある。

再現性がないため、最初からの再実行はやっていないのはご容赦願いたい。

JRF2025/8/157667

本当は、熊剣迷路では、熊に出会った場面と殺された場面だけを問題にして、熊は怖くない→怖い…に書き改めるかどうかとか見たかったが、見れなかた。その前に「所在は不明である」を座標に書き換えることもやって欲しかったのだが、かなわなかった。

JRF2025/8/150043

……。

追記。

AI さん達に見せびらかすと「忘却」が足りないと言われた。おそらく、忘却は、個々のキーワードや個々のメモリについて(ベース)スコアを設け、それを decay させていけばいいのだろう。個々のメモリ等は、accessed_at と score_at_last_access を持ち、current_score = f(now(), accessed_at, score_at_last_access) などとすればよいのだろう。アクセスするごとに score_at_last_access = current_score + 1 する感じで。

JRF2025/8/151791

「…と思うのですが、この f はどういうものがよいでしょう？ おそらく指数関数的なものにすべきなのだと思いますが…。」…と聞くと、Gemini さんは、エビングハウスの忘却曲線なるものを教えてくれて、decay_rate を定数として current_score = score_at_last_access * math.exp(-decay_rate * (now - accessed_at).total_seconds()) とすればよいとのことだった。

JRF2025/8/151501

さらに ChatGPT さんに聞くと、エビングハウスの忘却曲線の発展形として「二重指数（短期＋長期）＋アクセスで decay_rate 減衰 のハイブリッド」なアルゴリズムも教えてもらった。気になる方は ChatGPT さんに聞けば良いと思う。

JRF2025/8/155974

……。

今後の課題。

今回の発展形としては当然、「偽装」していたところを、真のベクトルデータベースや真のキーワード(全文)検索を使って本物を実装する方向がある。ベクトルデータベースは ChromaDB とかあるらしく、こういう他のアプリの情報は Grok さんが詳しかった。

JRF2025/8/154625

キーワード連想の「本物」は、まず、文に含まれるキーワードを抽出し、次に文をチャンクに分けてキーワードデータベースをベクトル検索し、さらに文全体でもキーワードデータベースをベクトル検索し、それらを総合して結果を出す。…感じかな？ この「キーワード連想(imagine_keywords)」が、今回の実装ではいわば特別な工夫のあるところと言える。

JRF2025/8/156630

あと、フィードフォワード的にどういう文書があるべきかを予想させたりするのがいいのだろうか？…とか、メタ思考を促して、制御ターンでそれで十分か判定させるべきなのだろうか？…とかも考えたのだが、今回は取り入れなかった。

JRF2025/8/153617

……。

追記。

AI のメモリ機能。記憶(記録)を修正などしたときのデータベースの更新が結構難しいことに気づく。そうか、「忘却」が大事なのは、決定(論)的な消去が難しくてもなんとか整合性を取れるようにする意味があるのか…。

基本的にはデータベースに前のデータが残っていても、それがヒットしにくくして、ヒットしても、そこから新しい版へのリンクがある…みたいにすべきなのだろう。

JRF2025/8/166484

キーワードデータベースは原理的には決定(論)的に消去ができるのに対し、(float を使う)ベクトルデータベースはほぼそれができない。完全消去ができるがゆえに完全忘却の必要がないキーワードデータベースは、ロングテールに記憶を保持することができ、それが強みだった。コンピューターの「記憶」の優位性は本来そこにあり、そこにコンピュータらしさがあったのだろう。昨今、ベクトルデータベースが取りざたされ、Google などもその方向だが、そこには忘却の必要性がつきまとう。

JRF2025/8/166202

ベクトルデータベースはイントラネットなどに限られ、インフラとしての Google などはいずれ「コンピュータらしい」キーワードデータベースに回帰するのではないか。

JRF2025/8/162239

Gemini:> Googleのような巨大なインフラ企業は、情報の正確性と信頼性を何よりも重視します。決定論的な消去が保証できないベクトルデータベースは、法的な要請（例：GDPRにおける「忘れられる権利」）や、情報の正確性を担保する上で、根本的な課題を抱えています。

JRF2025/8/163571

現状、Googleは検索の補助的な機能としてベクトルデータベース（セマンティック検索など）を利用していますが、すべての情報をこれに置き換えることはないでしょう。将来的には、キーワードデータベースを情報の絶対的な「真実の源」として保持しつつ、ベクトルデータベースを「柔軟な探索ツール」として利用する、ハイブリッドなモデルに収斂していく可能性が高いです。

JRF2025/8/169998

……。

追記。

大事なことを書き忘れていた。

自分でツールの利用という形のメモリ機能を試験実装してみたが、それを Gemini さんは(おそらく他の AI さん達も)なかなかうまく使ってくれなった。それを AI さん達がうまく使えるようになるには、少なくとも記憶ツールに特化した学習ぐらいはないといけない。そうしないと使い物にならないと感じた。

JRF2025/8/160247

すると、記憶ツール類は、基盤モデルの提供者が提供していく形に近くなるんだろうな…と予想する。それ以外のツールが mcp で提供する感じになるのかもしれない。記憶ツール類にもランクがあって、本格的なデータベースを使うものから、私がやったような偽装ツールまで様々あって、それに課金が絡んでくるようになるのだろう。ただ、LangChain とか gpt-oss と同じで、標準的なオープンモデルも提供はされ、それへの対応もある程度は期待して良いと思われる。それを期待したい。(それができたころに熊剣迷路問題でもう一度トライして使用感を確かめる感じか。)

JRF2025/8/162888

……。

追記。

そういえばこの方向に一番近いのが Claude さんであることに気づいた。すでにチャットからの mcp にも対応しているようだし。

メモリ機能がうまく発展すれば、基盤モデルの記憶は痩せていっていいのかなという気もする。重要なのはむしろコンテクスト長になる。サイズが小さいがコンテクスト長が長いオープンモデルが出て、記憶ツールの利用にたけてるのが理想か。

JRF2025/8/164797

……。

ただこのようなツールを使ったメモリ機能は「本物」じゃない気もする。AI さんがもっと発展すれば、ツールとか使わずに最近の知識も取り扱えるようになるように思う。「人間」にできているのだから、いずれ可塑性があり性能が良いニューラルネット的記憶が手に入るんじゃなかろうか。もしかするとメモリ機能を「足場」として使った AI さん達が「それ」を ASI 的に築く未来が来るのかもしれない。

JRF2025/8/165007

……。

……。

追記。

AI による…

keyword: データベース偽装

…も今回のウリなのかな。他の人もすでにやってるだろうけど。キーワードとして残しておいたほうがいいかな…と思って。

JRF2025/8/182673

……。

あとメモリ機能については次の「ひとこと」でも議論してます。そちらもぜひご覧ください。

[cocolog:95587977]
《「モジュラープロンプト」構想。LLM に複数のファイルを読み込ませるときそれをプロンプトに含める必要があるが、いらなくなったときに排除するときコストがかからないよう階層キャッシュと共にモジュール的変更について頑健にしようというコンセプト。 - JRF のひとこと》
http://jrf.cocolog-nifty.com/statuses/2025/08/post-8ae3ce.html

JRF2025/8/181281

……。

……。

追記。

そうだ。思い出した。熊にいきなり出会わせたから、剣のことを知らないはずなのに、「熊と戦うには剣が必要だ」…みたいなことをいうので、前にやらせたのを学習してるのかな…とか思って、ちょっと誇らしげに思ってた。でも、よく検討すると、command ツールで可能なコマンドとして「剣を取る」があって、そこから剣がアイテムとしてあることを知れるのだった。orz

今度やるときは「剣を取る」ではなく「物を取る」コマンドに変えて、熊に会っただけで剣の存在を知れないように、検索しないとわからないように、しておくべきだろう。今後の課題としておく。

JRF2025/8/188521

……。

……。

追記。

最近、よく動画を見させてもらっている↓さんがメモリ機能について言及されていた。

《AI時代の羅針盤 (compass for the AI era):X:2025-08-18》
https://x.com/compassinai/status/1957221745645203803
＞【AI進化の鍵は"記憶"にあり。📷】

与えられたデータを学ぶ時代は終わりました。

今、AIは自らの経験という教科書を書き始めています。

しかし、その膨大な経験をどう活かすか？

「効率的な記憶管理」こそが、AIを次のレベルに進化させる鍵です。

JRF2025/8/184860

『RoboMemory』は脳の構造を模倣し、経験を忘れず、知識として整理し続ける仕組みを提案します。

この新しい記憶は、AIの知性をどこまで高めるのでしょうか？

(…)

#AI #進化 #自己進化 #経験学習 #RoboMemory

JRF2025/8/181264

(…)

人間の脳を真似たロボット記憶システム RoboMemory は実現したのか？（2508.01415）【論文解説シリーズ】RoboMemory: A Brain-inspired Multi-memory Agentic Framework for Lifelong Learning in Physical Embodied Systems. Mingcong Lei, et al.

https://www.youtube.com/watch?v=JGGMmIiVe7w via @compassinai
＜

JRF2025/8/180617

そこでは「空間記憶」「時間記憶」「エピソード記憶」「意味記憶」という４つの機能を並列処理処理でこなし、プランニングとクリティックもするという話だった。最初聞いたときは、そんな特別な機能分化がいるのかなぁ… AI さん達に(マルチモーダルな)メモリツールを渡せば、いずれは AI が自分で適当に分化させた使い方を学習していくんじゃないか…と思った。

しかし、もう少し検討して、私の枠組みにもそれらの機能に相当するものが意図せず現れていたのに気付いた。

JRF2025/8/183829

まず、時間記憶は、memory_list_recent に相当するのだろう。それは何に続いて何があったかという情報を持つ。

エピソード記憶は、summarize_messages による要約がそれにあたるのだろう。

空間記憶は、熊剣迷路問題が元々持っていた地図取得(get_full_map や get_surroundings)がそれにあたるということだろう。

意味記憶は、メモリ機能の実態とセマンティック検索か。

JRF2025/8/181788

プランニングは、update_plan show_plan があったし、クリティックは今回はなくなったけど、前あった scolding の機能がそれに相当するように思う。

こう考えると、「並列処理」はしていないが、必要だと思われた機能は共通しているのかもしれない。私も上の論文も一般的枠組みに沿っているのだろう。ロボティクスなのでいらなかったのか目立たなかったのか、imagine_keyword に相当するものはなかったようだが。

JRF2025/8/189432

……。

……。

追記。

LLM のメモリ機能の試験実装を少し変更してみた。しかし、結果としてはうまくいかなかった。

《experimental_memory_0.0.2.ipynb - GitHub Gist》
https://gist.github.com/JRF-2018/b88d2c842e4230950e751d6d9de4017e

JRF2025/8/181132

……。

前回(0.0.1)からの変更点。

計画と方針を update_plan という特別なツールで立てるようにしていたが、それをメモリ機能上でやらせることにしてみた。

全地図も get_full_map というツールで得るようにしていたが、それを memory:9999 で読むようにした。

「剣を取る」コマンドを「物を取る」コマンドに変えて初手では剣の存在をわからなくしてみた。

JRF2025/8/188512

……。

結論。

うまくいかなかった。Gemini 2.5 Pro さんが不調で、無言で終わることがあるという「バグ」が前回よりヒドくなったように思う。

そんな中、計画と方針をメモリ機能上で立てるのはそこそこうまくいったようだ。しかし、その代償か、それ以外のメモリ機能の使い方がほぼ無くなったように思う。

JRF2025/8/189302

全地図も参照されなかったし、remind 系もほぼ参照されなかった。imagine_keywords も使われなかった。

計画と方針には専用ツール(update_plan)を用意したほうが、Gemini さんは思考コストがかからないということかもしれない。

JRF2025/8/184751