LLMのメモリをプログラム解析に変えた話
I accidentally turned LLM memory into program analysis
脆弱性調査中にLLMが事実を忘れたり、誤った前提で推論を続けたりする問題に直面した著者は、LLMのメモリ管理をデータベースに任せることを思いつく。LLMは自然言語やコードを構造化された事実に変換し、Datalogエンジン「Lemmalog」がその事実から結論を導き、依存関係を追跡して、観察結果が変わったときに自動的に結論を無効化する。このアプローチは、プログラム解析のインクリメンタル評価と似ており、LLMの幻覚を減らし、結論の根拠を遡ることも可能にする。
LLMはファジーな部分を担当し、Lemmalogは決定的な部分を担当する。
HNでの議論
83- sim04ful
私も同じ結論に達しました。LLMは本当にリクエスト処理の末端にだけ置くべきです。
1. ユーザーリクエストの理解: 自然言語 -> より厳密な表現、私の場合はDatalog。
2. 結果の解釈: 事実と導出された事実 -> 自然言語。
これらの末端の間では、作業はオントロジーや形式化された知識構造に対する機械的な推論であるべきです。
これは私が「風化」と呼んでいる別の原則にもつながります。有用な推論はシステムの形を変えるべきです。LLMがすでに関係、マッピング、ルール、抽象化を推論しなければならなかった場合、繰り返し使用することでその推論がシステムに刻み込まれ、次に同様のリクエストが来たときに最初から再発見する必要がなくなります。
使い続けることで、風化可能なシステムは繰り返しの作業に対して必要な確率的知能がますます少なくなるはずです。言い換えれば、知性の産物が後で再利用・機械的に評価できる構造に硬化するため、認知の限界費用は逓減するはずです。
- akkad33
私はClaudeから長期記憶を得ようと試みたことがあります。ノートにキーワードをインデックス付けしてSQLiteデータベースに入れ、Claudeが全文検索でクエリするという方法です。それがどの程度良いかはわかりませんが、物事をうまく見つけているようです。私の目標はコンテキストを小さく保ち、Claudeが必要なものだけを要求するようにすることでした。Datalogは素晴らしいアイデアだと思います。ぜひ試してみます。
- Animats
つまり彼はLLMを使って「is_a」表現で保存されたデータを生成しているのです。
それはとても古典的なAIです。
すぐに、彼は量化子が必要だと気づくでしょう。そして「すべての」は時には強すぎるので、「ほとんどの」が必要だと。その先にはCycがあります。
悪いアイデアではありません。しかし、歴史があります。
- keeda
とてもクールです。同様のことをしたHNの投稿を思い出します（残念ながら今は見つけられませんが）。それはLLMを使って記事を一連のステートメントに分解し、それを使って事実とイベントのエンティティ・リレーションシップグラフを構築していました。そして、それを従来のグラフクエリ手法でクエリしていました。ここで使われているDataLog / Lemmalogとよく似ています。特に、当時のLLMが苦手だったタイムラインに基づくクエリに効果的だったのを覚えています。
（Cycも参照: https://en.wikipedia.org/wiki/Cyc）
このようなアプローチは、権威あるデータソースへのLLM応答の効果的なグラウンディングの基盤になるだろうと思います（あるいはすでになっているかもしれません）。エラーを誤ったトラバーサルや誤った「事実」に特定できるはずです。ただし、これは具体的で曖昧さのない事実に最もよく機能します。曖昧で不明確な情報や意見に基づく情報は、おそらくLLMの領域のままになるでしょう。
- iamflimflam1
これは、Claudeを使った長期の研究プロジェクトでの私の経験と本当に一致します。
情報を除去するのは非常に難しいです。Claudeはあらゆる場所に物事を記録する癖があり、反証された後でも平気で事実として扱います。
現在真実であることが、古い「事実」で簡単に汚染される可能性があります。