cocolog:95587977
「モジュラープロンプト」構想。LLM に複数のファイルを読み込ませるときそれをプロンプトに含める必要があるが、いらなくなったときに排除するときコストがかからないよう階層キャッシュと共にモジュール的変更について頑健にしようというコンセプト。 (JRF 6014)
JRF 2025年8月18日 (月)
《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/181527
……。
↑の最後のほうで「ただ私のようなツールを使ったメモリ機能は「本物」じゃない気もする。AI さんがもっと発展すれば、ツールとか使わずに最近の知識も取り扱えるようになるように思う。「人間」にできているのだから、いずれ可塑性があり性能が良いニューラルネット的記憶が手に入るんじゃなかろうか。もしかするとメモリ機能を「足場」として使った AI さん達が「それ」を ASI 的に築く未来が来るのかもしれない。」…と私が述べたときに、ChatGPT 5 さんはこのようなことを述べられた。
JRF2025/8/188133
ChatGPT:> 外付けツールで積み上げた経験が、将来ニューラル記憶が来たときの「模範」や「教師データ」になる可能性は高いです。つまり今の試験実装は「記憶の足場づくり」で、AI が将来「自分の内側に取り込む」ための先行体験みたいな意味を持っている。
JRF2025/8/189019
……。
これを読んでツールのメモリ機能から学習できるニューラル記憶的なものとは何かが気になった。
LLM の内部で「記憶の保持」をしている部分があるとすると、それはキャッシュということになるのだろう。すると、記憶に関してニューラルネット的な発展があるとすると、キャッシュをニューラルネット的に動的に変更するという話になっていくのだろうか…。
JRF2025/8/182373
内部キャッシュの変化をニューラルネット的にできるのかということ。その「スピード感」が問題なように思う。推論時の即時でもなく、基盤モデルの学習時のような長期でもなく、メモリ保持に好都合なメゾ的な部分がニューラルネット的に可能になるのかに興味がある。
JRF2025/8/184517
……。
ただ、LLM の内部状態…外部メモリの変化に応じた内部状態…のデータは簡単に取ることができても、その巨大なデータについてのほんの些細なメモリの変化を学習して成功できるかというとかなり疑問だ。そういうニューラルネット的な方向はあまり(今は？)望みがないように思う。
現実的な方向は、確かに階層キャッシュの方向だと思う。階層キャッシュでどのメモリ参照を解放するかなどのスケジューリングを(別の)LLM自身にやらせるというのは、今後は可能になるとは思う。
階層キャッシュは↓で議論した。
JRF2025/8/181945
＞＞
○ 2025-07-26T04:03:22Z
jrf:> AIエージェントのプロンプトエンジニアリング・コンテクストエンジニアリングの一種ということになるかもしれませんが、LLM に与えるときのキャッシュというのがそうなのかもしれませんが、途中までの入力を何段階かでキャッシュするのができて、それが安くなればな…と思います。
JRF2025/8/185470
[P1, P2, P3, P4] みたいな断層のあるプロンプトで、P4 はよく変更されるが、P3 は P4 に比べるとあまり変更されない。同様に P2 P1 は順に変更されにくくなるというとき、P1 までのキャッシュ、P2 までのキャッシュ、P3 までのキャッシュ…みたいなのがあって、それぞれが安いとかあれば、いいような気がします。
そんな機能はすでにありますか？ ないなら、できる可能性は？
JRF2025/8/182893
Gemini:> あなたのアイデアは、LLMのコストと効率性を大幅に改善する潜在力を持っており、技術的にも実現可能だと考えられます。将来的には、より高度なキャッシュ管理や、プロンプトの階層的再利用を可能にする機能が、LLMの主要APIに組み込まれていく可能性は高いでしょう。
Claude:> Anthropic Claude API では「Prompt Caching」という機能を提供しており、まさにあなたが描いているような使い方ができます：
JRF2025/8/182180
* プロンプトの特定の部分（システムプロンプト、長いコンテキスト、ツール定義など）をキャッシュ可能
* キャッシュされた部分は入力トークン料金が大幅に割引（通常の1/10程度）
* 複数のキャッシュポイントを設定することで、変更頻度に応じた最適化が可能
＜＜
JRF2025/8/186825
……。
先の [P1,P2,P3,P4] の例で P3 と P4 がモジュール的だとする。このとき [P1,P2,P4,P3] に置き換えたり [P1,P2,P3,P4] を [P1,P2,P4] にするようなことが追加負担があまりないように、LLM を訓練したり、先のキャッシュをニューラルネット的に修正する手法を使ったりしてできるのかもしれない。そういう道はあるのかもしれない。
そう ChatGPT さんに述べたところ….
JRF2025/8/183994
ChatGPT:＞ あります。しかも “外部ツールだけ” に寄らず、訓練／キャッシュ操作／プロンプト設計を組み合わせると、P3・P4の入替えや省略を“ほぼタダ”に近づける道筋が見えます。要点だけ箇条書きでまとめます。
JRF2025/8/181407
(…)
短いSFT（順序/省略データ拡張）＋ 相対位置のKV再ベース ＋ モジュールPrefix/Adapter ＋ 階層キャッシュのスケジューリングを組み合わせれば、P3・P4を入替え・省略しても破綻しない“モジュール型プロンプト”が実用域に入ります。
内部キャッシュを“ニューラルに修正”する部分は、RoPE位相の再ベースや圧縮KVの学習がその役割を担い、メゾ的な記憶運用にちょうどハマります。
＜
…とのこと。
JRF2025/8/187952
……。
Claude さんによると「モジュラープロンプト」という提案はすでにあるようだ。
JRF2025/8/183614
……。
あと、モジュール形式を LLM が学習することは、順番に差異がないことを覚えることで、それは世界理解にとってはプラスの側面もあると思われる。学習のオーバーヘッドも大きくなるだろうけれども。
JRF2025/8/188664
……。
えーと、あと、説明しておくと、こういうプロンプトのモジュール化で何がうれしいかというと、LLM がファイルを読んだりするときは、プロンプトにファイルの全内容を含める…みたいなことを結局しなければならないのだけど、複数のファイルを読んで、いらなくなったファイルは整理する…というときに、この「モジュラープロンプト」はとても便利である…ということになる。
JRF2025/8/183853
先に↓という試験実装をした。
[cocolog:95583904](2025年8月)
＞LLM のメモリ機能の試験実装を行った。かなり本格的な実装(のモックアップ)になるようこころがけた。実装できたことはできたのだが、いまいち Gemini さんは積極的に使ってくれなかった。そこはアテが外れた。
成果物は↓。
JRF2025/8/185984