なぜExpertのメモリは意図からずれてしまうのか
デフォルトでオンになっており、誰かが選んだスコープが適用されている
メモリは「Expertがセッション間で有用なコンテキストを保持できるようにする」ものであり、「スコープ化されたナレッジを共有仮想ファイルシステム（VFS）に保存するため、将来のセッションでは、現在の会話に依存することなく、確立された設定、規約、教訓を適用できます」。
最初の不一致が発生するのはスコープです。「Expertのメモリはそのチームに属し、ワークフローに適したスコープによって分離されます。リポジトリベースのExpertは通常、リポジトリごとに1つのスコープを使用しますが、他のExpertはグローバル、チャンネル、プロジェクト、またはユーザー固有のスコープを使用できます。」
5つの可能なスコープがあり、デフォルトはテンプレートに適合するものです。本来はリポジトリごとに設定すべきExpertがグローバルにスコープされていると、あるチームの規約を学習してそれをあらゆる場所に適用してしまいます。逆に、本来はグローバルにすべきExpertがリポジトリごとにスコープされていると、すべてのリポジトリで同じことを再学習することになります。
2つの書き込みパス、および一方のみが待機する
これは適切に理解しておく価値のあるメカニズムです。なぜなら、何気ない一言がその後のすべてにどのように影響するかを決定するからです。
"Simple memoryはデフォルトです。明示的で高品質な人間のフィードバックを、厳選されたナレッジファイルに直接書き込みます。これは、それ自体が信頼できる設定や恒久的なルールに適しています。"
"Noisy memoryは、証拠ログと厳選されたナレッジファイルを併用します。時間の経過とともに弱いシグナルを組み合わせ、証拠が十分に強くなった後にのみ学習を昇格させます。"
そして、外部からはその違いを見分けられない理由がここに説明されています。「どちらのモデルも、リーダーに対して同じ厳選されたナレッジビューを公開します。違いはそのビューがどのように生成されるかです。simpleメモリは信頼できる事実を直接記録するのに対し、noisyメモリは将来のセッションに提示する前に、繰り返される証拠を抽出します。」
つまり、見た目がまったく同じ可読なナレッジファイルであっても、1つのコメントに裏付けられている場合もあれば、12個の裏付けとなる証拠に基づいている場合もあります。Expertがなぜ何かを信じているのかをデバッグする場合、まずこれを明確にする必要があります。
すべての行動が同じ強さのシグナルになるわけではない
Code Review Memoryはnoisyモデルを実行しており、そのドキュメントでは重み付けについて非常に具体的に説明されています。「明示的な人間のフィードバックは、リアクションや推測された結果よりも重みがあるため、強いフィードバックはすぐに有用なメモリになりますが、弱いシグナルは繰り返される必要があります。」
実質的に3つの階層があります。書かれたコメントはすぐに反映されます。エージェントの発見に対するリアクションや、変更がマージされたという事実は、繰り返しが必要です。システムはフィルタリングも行います。「日常的な承認、ボットの更新、プロセスのみのコメントは除外されます。」
これは賢明な設計です。また、何気ない「はい、大丈夫です」という言葉が中立ではないことも意味します。それは記録される弱いシグナルであり、それらが積み重なると影響を及ぼします。
通知はされているが、ほとんどの人は見ていない
拒否（ベト）ステップがありますが、見落とされがちです。「インタラクティブなセッションでは、何かを記憶したときに通知されるため、修正または拒否することができます。」
ここで重要な言葉は interactive（インタラクティブ）です。バックグラウンドのExpert（Code Review Memoryは明示的に「バックグラウンドのTemplate Expert」です）は、プルリクエストがマージされたときにキャプチャを行うため、そのプロセスに異議を唱える人間は介在しません。
競合を解決するのではなく、表面化させる
読み取りパスにおいて：「関連する作業の開始時に、Expertは現在のスコープのメモリをロードします。一致するガイダンスを適用し、現在の証拠が記憶されたルールと競合する場合は不一致をフラグで示します。」
フラグを立てることは、古いルールを黙って適用するよりも優れていますが、それを修正することとは異なります。古いエントリは誰かが編集するまで残ります。これは、detecting conflicts in AI memoryで扱われている一般的な問題です。
よく試されるアプローチ
メモリをオフにする。 これは可能であり、Advisorにメモリを組み込まないよう指示できますが、ノイズの多い部分と一緒に有用な部分まで捨ててしまいます。進行中の作業から得られる学習こそが、指示（instructions）では捉えきれないものです。
すべてをExpertの指示（instructions）に記述する。 Augmentはこれに直接言及しています。「明示的なワークフローにはスキルまたはExpertの指示を使用し、進行中の作業を通じて学習したコンテキストにはメモリを使用します。」また、レビュー側については次のように述べています。「Code Review Memoryは、すべてのリポジトリに対してスキルを作成することとは異なります。スキルは明示的で再利用可能な指示とワークフローを提供します。メモリは、レビューExpertがレビュー対象のリポジトリに対して自動的にロードする、進化する証拠に裏付けられたコンテキストです。」これらは2つの異なる役割であり、1つのメカニズムに両方を強制すると、どちらのパフォーマンスも低下します。
すべての場所で利用できるように、最も広いスコープを使用する。 公式のガイダンスは逆です。「コードレビュー用のリポジトリやフィードバックのトリアージ用のチャンネルなど、ワークフローに一致する最も狭く安定したスコープを使用してください。」広いスコープを使用しても、Expertの情報が豊富になるわけではありません。検索のノイズが増えるだけです。
より厳密に思えるため、すべてをnoisyメモリに切り替える。 これもドキュメントに反しています。「ワークフローが繰り返し重み付けされた証拠を真に必要としない限り、simpleメモリを優先してください。」Noisy memoryは設計上、学習を遅らせます。あなたのフィードバックが絶対的なワークフローにおいて、その遅延は単なるコストでしかありません。
記憶された内容を確定事項として扱う。 「メモリは疑う余地のないルールではなく、進化するコンテキストとして扱ってください。Expertは現在の証拠を無視するのではなく、矛盾を表面化させるべきです。」メモリは履歴を伴う主張であり、決定事項ではありません。これがmemory provenanceの背景にある区別です。
別のチームのExpertがそれを拾い上げてくれると仮定する。 そうはなりません。「各Expertチームは、別のチームの厳選されたナレッジを修正するのではなく、独自のメモリを所有および維持します。」所有権は境界線であり、回避すべき不便な障害ではありません。
解決策：スコープを設定し、モデルを選択し、書き込まれた内容を読み取る
ステップ1：各Expertに対して最も狭く安定したスコープを選択する
あなたのExpertを確認し、それぞれの作業をカバーできる最小のスコープを書き出してください。Augmentの表現における stable（安定した）という言葉には重要な意味があります。目標は、想像しうる最も狭ススコープではなく、来月になって広げる必要が生じないような、最も狭いスコープです。
ドキュメント自体の例は正しい直感を示しています。「コードレビュー用のリポジトリやフィードバックのトリアージ用のチャンネル」。1つのリポジトリで動作するレビューExpertにグローバルスコープは不要です。1つのチャンネルを監視するトリアージExpertにプロジェクトスコープは不要です。
ほとんどの場合、2つの質問で解決できます。「ここで学習したナレッジは、他の場所では誤りになりますか？」もしそうなら、スコープを狭めてください。「これと同じことを、他の3つの場所で再び教える必要がありますか？」もしそうなら、そのナレッジは実際には特定のExpertに固有のものではないという兆候です。その考えはステップ3まで取っておいてください。
スコープと連動するため、ここで公開範囲（visibility）も決定しておきましょう。「メモリは、Expertの公開範囲に応じて、組織と共有することも、ユーザーのVFS内に保持することもできます。」
ステップ2：シグナルの信頼性にメモリモデルを合わせる
Expertごとに1つの質問をします。「このExpertが受け取るフィードバックは、それ自体で信頼できるものですか？」
人間が修正を入力し、その修正が単に正しい場合は、simple memoryを使用します。設定、恒久的なルール、すでに決定した規約などです。これは「明示的で高品質な人間のフィードバックを厳選されたナレッジファイルに直接書き込み」ます。即時性がその特徴です。
シグナルが混在している場合（リアクション、マージ結果、推論、深刻度の異なるコメントなど）は、noisy memoryを使用し、証拠ログにその役割を任せます。Code Review Memoryがその代表例であり、その理由は次のように述べられています。「レビューコメント、リアクション、エージェントの観察、および変更結果は、それぞれ異なるレベルの信頼性を持っています。」
次に、メカニズムではなく量に関する2つ目の公式フィルターを適用します。「将来の決定や注力分野を変更する可能性がある情報のみを保存してください。」すべてを記録するExpertは、誰も読まないナレッジファイルを生成し、誰も読まないナレッジファイルには古いエントリが残ることになります。
特にレビューパスについては、何が監視されているかを把握し、意図的にレビューを行ってください。それは「有用な人間のコメント、エージェントの発見に対するリアクション、対処された変更要求、および変更の結果を記録」します。エージェントの発見に対するあなたのリアクションはトレーニングデータです。そのように扱ってください。
ステップ3：ナレッジファイルを読み、Expert固有ではない事実を移動する
2つの習慣があり、2つ目が構造的な解決策です。
1つ目は、実際にそれを読むことです。メモリは「独自のVFSディレクトリの下に読み取り可能なMarkdownとして」書き込まれ、レビュー側ではストレージの分割が明示されています。「生のブレッドクラムログはレビューから収集された証拠を保存し、厳選されたナレッジファイルにはレビューExpertが消費する簡潔なガイダンスが含まれます。」Expertが何を信じているかを確認するには厳選されたファイルを読み、その理由を知りたいときはブレッドクラムログを読んでください。月に1回程度スケジュールを設定してください。バックグラウンドのExpertはインタラクティブな拒否ステップなしでキャプチャを行うため、これが唯一のレビュー機会となります。
2つ目は、複数のExpertのファイルに繰り返し現れる内容に気づくことです。アーキテクチャの決定、ドメインの語彙、どのサービスが何を所有しているか、非推奨のものがなぜまだ存在するのか、などです。そのナレッジは、特定の役割が自身の作業を通じて学習したものではなく、組織全体が知っていることです。Expertごとのスコープ設定は、すべてのExpertがそれを個別に学習するか、あるいは間違って学習することを意味します。
Augmentのスコープに関するアドバイスは、それが対象とするナレッジについては正しいですが、真に共有されるナレッジに対する解決策はありません。それは、どのExpertも所有しないレイヤーに属します。MemoryLakeは3つのステップでセットアップできます。
ステップ1：APIキーを作成する
サインインし、ダッシュボードからAPIキーを生成します。これはExpert、チーム、またはリポジトリにスコープされていません。これは、どのExpertが問い合わせているかに関係なく真実である事実にとって重要な特性です。
ステップ2：最初のメモリをアップロードする
Expertのファイル間で繰り返されていることに気づいた内容を入力します。アーキテクチャの決定とその理由、ドメイン用語、サービスの所有権、恒久的な制約、レビューで繰り返し行っている回答などです。
作業を通じて学習した内容はそのままにしておきます。あるリポジトリでフラグを立てるのをやめた誤検知に関するExpertの記録は、まさにそのリポジトリにスコープされたままにすべきものです。
ステップ3：AIとエージェントを接続する
エージェントをストアに向けます。新しいExpertはゼロからではなく、組織の事実から開始され、共有された事実への修正はExpertごとではなく一度で済みます。これがsetting up shared AI memory for a teamのポイントです。
これにより実際に何が変わるか
最初の変化は、狭いスコープ設定によってカバレッジが犠牲にならなくなることです。現在、Expertのスコープを狭めることは、組織について知っている情報が減ることを意味します。共有された事実が別の場所から提供される場合、狭いスコープは単に履歴がクリーンになることを意味します。
2つ目は、モデルの選択が容易になることです。信頼できるフィードバックにはsimple、混在するシグナルにはnoisyを使用します。どちらも背景の事実を保持する必要がないため、人々を広いスコープや過剰な保存へと駆り立てる原因が解消されます。
3つ目は、レビューの習慣が現実的になることです。Expertが真に学習した内容に限定された厳選ファイルは、毎月読めるほど十分に短くなります。これは、auditing what your AI remembersを実際に実行することと、単にそうしようと思うことの違いです。
Cosmos Expertメモリのベストプラクティス
- すでにオンになっていると想定する。 すべてのTemplate Expertsに搭載されており、AdvisorはデフォルトでカスタムExpertにこれを追加します。
- 最も狭く安定したスコープを使用する。 コードレビュー用のリポジトリ、トリアージ用のチャンネルなど、Augment自身の例を参考にしてください。
- Simple memoryを優先する。 シグナルの信頼性が真に異なる場合にのみ、noisyに切り替えます。
- 将来の決定を変更する可能性があるもののみを保存する。 これは公式のボリュームフィルターであり、ファイルを読み取り可能な状態に保つためのものです。
- レビューでのリアクションに注意する。 コメント、リアクション、対処された要求、および結果はすべて、異なる重み付けでキャプチャされます。
- バックグラウンド作業では拒否（ベト）ステップを期待しない。 これはインタラクティブなセッションで表示されます。Code Review Memoryはバックグラウンドで実行されます。
- 厳選されたファイルは毎月読み、驚いたときはブレッドクラムログを読む。 一方は結論を示し、もう一方は証拠を示します。
- 所有権の境界を尊重する。 各Expertチームは独自のメモリを維持し、別のチームのメモリを編集しません。
結論
Augmentは、ほとんどのツールが公開しているよりもはるかに多くのエージェントメモリの制御を提供します。5つのスコープ、まったく異なるセマンティクスを持つ2つの書き込みモデル、文書化されたシグナル階層、および検査可能な読み取り可能なファイルです。
ドキュメントが推奨するようにコントロールを使用し（狭く、デフォルトでsimple、保存する内容を控えめにする）、スコープ設定では対応できない唯一のケース、すなわちすべてのExpertが必要とする事実に適切に対処してください。それらは特定の役割の学習ではなく、共有レイヤーに保持することで、Expertごとのメモリを本来あるべきタイトな状態に保つことができます。