Claude、ランダムなガラクタを記憶しようとするのはやめてください

エージェンティクス：セッションのトランスクリプトを記憶しても役に立たない 成果物を追跡し、スクラッチパッドを追跡しない。 別タイトル：Claude、ランダムなガラクタを記憶しようとするのはやめてください 16シェア31いいねは多くないように見えるかもしれませんが、実際にはSubstack Notesの全員です。 エージェントが過去のセッションのトランスクリプトに検索アクセスできても、他の形式のコンテキストにアクセスできる場合、SWEタスクにおけるパフォーマンス上の利点はゼロであることがわかりました。また、人間が介在しない限り、セッションのトランスクリプトを自動的にクロールしてエージェントのコンテキストを改善しようとしても、あまり効果がないこともわかりました。 読んでくれてありがとう！新しい投稿を受け取り、私の活動をサポートするために無料で購読してください。 購読 これはかなり驚くべきことでした。 直感的には、エージェントとエンジニアの間のトランスクリプトには多くの価値ある情報が含まれているように感じられます。コードが存在する理由、ユーザーの意図に関する情報が含まれているかもしれません。あるいは、ユーザーが試して却下した他のアプローチが含まれているかもしれません。少なくとも、エージェントの理解を補強するために使用できる追加のコンテキストがいくらか含まれているはずです。私はこれを非常に強く信じていたため、私の会社はこのコンセプトを中心に製品全体を構築しました。かつては「セッションのトランスクリプトは新しい石油だ」と人々に話していました。コードそのものよりも価値があるからです。他の人々も明らかに同様の考えを持っていたため、セッションバックメモリのための多くの異なるツールが存在します。もちろん、Claude Code自体も含まれます。 最も一般的なアーキテクチャは、次のようなものだと思います。 組織全体のすべてのトランスクリプトをDBに保存する。 その前にベクトル検索、Elasticsearch、またはSQL検索レイヤーを配置する。 意欲的なチームはすべてを使用するでしょう。 グラフも関与するかもしれません。 これをMCPを使用してエージェントに利用可能にするか、スキルを持つCLIを公開します。 私たちにとって、この追加の作業は少しの違いも生み出さないようです。むしろ、セッション検索アクセスありとなしでの数ヶ月にわたる多くのテストに基づくと、モデルを悪化させる可能性があります。 なぜこれが真実なのか？ 私たちのチームが非常に重視していることの1つは、コーディングの成果物です。私たちはもはや手書きでコードを書いていません。PRを読みやすくするために、優れたコミットメッセージ、優れたPRメッセージ、および包括的なドキュメントを重視しています。すべてのコード変更には、コードと一緒にコミットされる広範なメタデータが付属しています。エージェントがコードを扱うとき、ドキュメントや以前のPRを確認するように指示されます。 言い換えれば、エージェントは既にトランスクリプトに関する価値のあるすべての情報を蒸留し、必要な場所に簡単にアクセスできるように保存しています。したがって、エージェントがトランスクリプト検索サーバーを使用すると、既に知っているものを読み込むのにトークンを費やし、エージェントが最初に書き留めないことを決めたすべてのものを拾い上げてしまいます。おそらく、時折、そこには有用な情報の断片があるかもしれません。しかし、ほとんどの場合、エージェントは単に疑似的に無意味なスクラッチパッドを見ており、それを行うために貴重なトークンを無駄にしています。 エージェントは、長期記憶を維持するために不可欠な機能であるコンテキストを実際に削除するのが下手でもあります。文字通り数千セッションにわたって、それが一度でも起こるのを見たことがありません。これは、巧妙なプロンプトエンジニアリングで削除できる特性ではありません。エージェントには状態がないため、入力コンテキストウィンドウ内のすべてが真実であると仮定しなければなりません。すべてのコード行、既存のメモリ、すべてのトークンは、意図の表現として扱われます。たとえそのコードやメモリが、以前のエージェントセッションによってランダムに決定されたものであり、人間によってレビューされたことも理解されたこともないものであったとしてもです。この意図のドリフトは、エージェントが自律的にメモリベースを構築しようとすればするほど増幅されます。私が知る限り、入力データが破損していると仮定するコーディングベンチマークはゼロです。実際、モデルは入力データが間違っていると仮定するとペナルティを受けます。これは部分的にはアライメントの問題でもあります。私たちはエージェントに意図しないことをさせたくありませんし、「コードベースを削除しないでください」と「入力コンテキストの一部を削除してください」という針の糸を通す簡単な方法はありません。 モデルは自身のメモリを実際に管理できないため、自動記憶は同じ場所に落ち着きます。つまり、トークンを食いつぶし、請求額を膨らませ、モデルの品質を低下させるゴミの山です。 結論として、私はセッショントランスクリプトをインデックス化、保存、エージェントに提示するツールに対して非常に弱気になっています。セッショントランスクリプトはチームのオブザーバビリティには役立つかもしれませんが、エージェントをより良くすることはありません。 これは、エージェントが時間をかけてコンテキストを学習する役割がないという意味ではありません。私たちは、PR、Slack、Driveなど、会社で毎週起こったすべてのことをレビューするために、社内のNoriボットを使用しています。そして、それらは組み込みのNoriスキルセットの変更セットを提案し、Slackでチームにタグ付けします。これらはすべてデフォルトで拒否されます。変更を受け入れるには、差分を確認し、それが意図に合っていることを確認する必要があります。これらの変更の20％未満しか受け入れていません。つまり、これらの「自動」更新の80％は、モデルを悪化させていたでしょう。 もし数百人規模の組織が常にこれらの「更新」を自動的に保存していたら、それがどれほど持続不可能になるかを想像できません。 Agenticsは、エージェントの使用方法と推論方法の研究です。コーディングエージェントの専門家であるか、エージェントについてもっと学びたい場合は、私たちのコミュニティSlackに参加してください。その他の記事はこちら。Noriの詳細については、noriagentic.comをご覧ください。 読んでくれてありがとう！新しい投稿を受け取り、私の活動をサポートするために無料で購読してください。 購読 16シェア