エージェントのメモリにOpenTelemetryの瞬間が来る

いや、そうではない。LLM分野ではまだ多くのイノベーションや変化が起きており、万能のソリューションはない。私の知る限り、ソリューションは速度、精度、コストという3つの主要な関心事の間でトレードオフを取らざるを得ない。メモリをファイルとして扱うことすらまだ確定していないと思う。この分野にはまだ多くのイノベーションと進歩の余地がある。

ブログ記事全体がLLMの臭いがする。LLMのテキストを検出する十分に信頼できる方法があれば、それを完全にフィルタリングするブラウザ拡張機能を作るのだが。

一般的な前提には同意する。しかしその瞬間は今日ではないし、まだ訪れていないと思う。コンテキストとメモリへの正しいアプローチや、それらがどれだけ持続すべきかをまだ理解していない。ましてや、SOAPやSGMLのようになってしまう抽象化を早まって標準化するなど論外だ。

本当にこれが必要なのか…？LLMが得意なのは自然言語の解釈だ。だから特定のプロジェクトで使われるどんなフォーマットにも適応するスポンジのようなものだ。事前定義されたフォーマットは実際には必要ない。それに、ユーザーAのエージェントのメモリがユーザーBのメモリと共存することを本当に望むのか？そうではない。だからコラボレーションや共有の論拠は、少なくともコーディングエージェントに関してはかなり薄弱だ。リポジトリ固有のコンテキストは、エージェント以前の時代と同様に、docs/やarchitecture/ディレクトリにエンコードできる。デプロイされたエージェントの監視については、まあありかもしれない。そのために（またしても）メモリ管理ツールslivingdoc.devを作った。これを使えば全エージェントの永続的なコンテキストを引き出せる。しかしここでの問題は分散システムの問題であり、メモリのフォーマットではない。

エージェントメモリの場合、統一フォーマットや仕様の必要性は大幅に減る。なぜなら定義上それはエージェントによって読まれ、エージェントはすでに異なるフォーマットのメモリファイルを読むように指示・プログラムされているからだ。たとえそのような指示がなくても、エージェントは必要なコンテキストを得るためにファイルをたどるのが極めて得意だ。

この問題に対して標準化を主張するのは時期尚早だ。Otelはこの分野での数十年の経験の後に開発され、無数のソリューションを探求し、それらから学んでOtelを開発した。今のエージェントメモリソリューションで十分に探求したから標準化してさらなる実験に摩擦を加えようと言うのは、誤りだと思う。

これは問題を見つけようとしているソリューションだ。メモリ、そして実際にはストレージ層全体が、エージェントや日常のワークロードにとって不可視である必要がある。誰も素晴らしいストレージのためにエージェントを構築・販売しているわけではなく、それで何ができるかが重要だ。誰もメモリのためにエージェントを構築しているのではなく、その上に構築している。ユーザーが実際のビジネス問題に集中できるようにソリューションを簡素化する、それ以上ではない。小さな宣伝だが、私はhttps://github.com/Polign/recallをいくつかの本番ワークフローで動かしており、最もよく聞くのは「ただ動く」ということだ。