AI News HubLIVE
站内改写

エージェントの可観測性は学習を促進するためにフィードバックを必要とする

LangChainのHarrison Chaseが、エージェントの可観測性はデバッグだけでなく学習ループを駆動するために重要だと論じます。トレースだけでは不十分で、ユーザーフィードバック、間接的なシグナル、LLM-as-judge、ルールなどのフィードバックを組み合わせることで初めて、モデル、ハーネス、コンテキストを体系的に改善できます。可観測性プラットフォームには、トレースの保存、フィードバックの保存、フィードバックの生成という3つの機能が必要です。

記事インテリジェンス

エンジニア中級

要点

  • エージェントの可観測性の真の目的は、デバッグだけでなく学習を促進することにある。
  • フィードバック(ユーザー、間接的、LLM評価、ルール)がトレースを学習信号に変える。
  • 学習はモデル、ハーネス、コンテキストの各レベルで発生し、トレースとフィードバックの両方を必要とする。
  • 効果的な可観測性プラットフォームは、トレースを保存し、フィードバックを保存し、自動的にフィードバックを生成する必要がある。

重要な理由

このニュースが重要なのは、エージェントの可観測性の真の目的は、デバッグだけでなく学習を促進することにあるためです。

技術的影響

モデル選定、推論コスト、プロダクト能力、評価基準に影響する可能性があります。

ほとんどのチームは、エージェントの可観測性をデバッグツールとして考え始めます。何かがうまくいかなかったとき、トレースを開き、ステップを調べ、エージェントがどこで誤った判断をしたかを特定します。これは有用ですが、視野が狭すぎます。

可観測性のより深い役割は、学習を促進することです。しかし、トレースだけではそのループは生まれません。フィードバック、つまりエージェントの行動が有用だったか、受け入れられたか、拒否されたか、非効率だったか、リスクがあったか、間違っていたかを示すシグナルも必要です。この学習は、モデル訓練の意味に限らず、エージェントシステム全体に及びます。モデルが何をすべきか、ハーネスがどのようにモデルを導くべきか、どのようなコンテキストが必要か、どの障害パターンが繰り返し発生するか、どの行動が実際にユーザーにとって機能しているか。

トレースは単なる記録ではなく、フィードバックは最後の評価だけではありません。両者が一体となって、システム改善のための原材料となります。

学習は複数のレベルで発生します。モデルレベル:モデルが特定のリクエストを誤分類したり、間違ったツールを選択したり、ポリシーに従わなかったりする例が見つかるかもしれません。そのようなトレースは、教師あり学習や強化学習を通じてモデルの重みを更新するために使用できます。ハーネスレベル:ハーネスはモデルを取り巻くすべて、つまりプロンプト、ツールスキーマ、権限チェック、制御フロー、メモリ更新ロジック、ルーティング、リトライ、ガードレールです。トレースから、モデルの能力は正しいが足場が間違っていたことがわかるかもしれません。ツールの説明があいまいだった、読み取り前書き込み制約が必要だった、システムプロンプトが間違ったトレードオフをしていたなどです。コンテキストレベル:エージェントは与えられた情報に非常に敏感です。検索されたドキュメント、メモリ、ユーザー設定、ツール結果、以前のターン、環境状態などです。トレースから、モデルが誤ったまたは欠落したコンテキストに対して合理的な判断を下したことがわかる場合があります。その場合、学習ループは、どのコンテキストを検索、保存、圧縮、または破棄するかを改善する必要があります。これは一般的にメモリと呼ばれます。

重要な点は、これらすべての学習ループがトレースによって駆動されることです。エージェントが何を見て、何をし、その結果何が起こったかを知らなければ、何を改善すべきかを確実に知ることはできません。これが、エージェントの可観測性がエージェント評価を促進する理由です。トレースによってエージェントの行動が可視化されます。

学習は手動または自動で行うことができます。手動の場合:開発者がトレースを見て、エージェントが間違ったツールを呼び出したことに気づき、プロンプトやツールスキーマを更新します。プロダクトマネージャーが一連の失敗した会話をレビューし、製品に新しいワークフローが必要だと気づきます。アノテーターがトレースにラベルを付け、チームがより良い評価データセットを構築できるようにします。これも学習であり、人間がループ内にいます。自動化の場合:システムが本番トレースをサンプリングし、オンライン評価を実行し、既知の障害パターンを検出し、データセットに例を追加したり、異常が見られたときにレビューキューをトリガーしたりします。エージェントが自動的に改善する必要はなく、自動化は単にどのトレースが注目に値するかを特定し、それらを構造化フィードバックに変換します。

低トラフィックの単一エージェントであれば手動レビューで十分かもしれません。しかし、多数のエージェントや高トラフィックの本番環境では、これはインフラストラクチャの問題になります。トレースのキャプチャ、フィルタリング、スコアリング、ルーティング、そして重要なものを保持する必要があります。

トレースは必要ですが、十分ではありません。トレースは何が起こったかを教えてくれますが、それが良かったかどうかは教えてくれません。この区別は重要です。エージェントは40ステップでタスクを完了できますが、同じタスクは6ステップで完了すべきだったかもしれません。自信満々の最終回答を生成するかもしれませんが、ユーザーが拒否したかもしれません。エラーを回避しつつも、ユーザーの意図を満たせていないかもしれません。正しいツールを呼び出したものの、引数が微妙に間違っているかもしれません。

トレースから学習するには、フィードバックをトレースに付加する必要があります。フィードバックは、可観測性を受動的な記録から、トレーニングシグナル、デバッグシグナル、製品シグナル、評価シグナルに変換します。フィードバックがなければ、大量の軌跡が積み上がるだけです。フィードバックがあれば、次のような有用な質問ができます。どのトレースが成功を表すか?どのトレースが失敗を表すか?失敗の原因はモデル、ハーネス、コンテキストのどれか?どの失敗を評価に変換する価値があるか?どの行動が時間とともに改善しているか?

これが中核的な要件です。エージェントの可観測性データとともにフィードバックを保存することです。

フィードバックはさまざまなソースから得られます。最も明白なのは直接的なユーザーフィードバックです。いいね、よくない、星評価、テキストによる修正など。このシグナルは理解しやすいですが、通常はまばらです。ほとんどのユーザーは明示的なフィードバックを残しません。次に間接的なユーザーフィードバックがあります。コーディングエージェントの場合、受け入れられたコード行、元に戻された差分、編集後のテスト合格、ユーザーが生成された変更を保持したかどうかなど。サポートエージェントの場合、ユーザーがチケットを再オープンしたかどうか。研究エージェントの場合、ユーザーが回答をコピーしたか、同じ質問を再度行ったかどうか。これらのシグナルは明示的な評価よりもノイズが多いですが、多くの場合はるかに豊富です。

また、LLM-as-judgeを使用してフィードバックを生成することもできます。判定者は、回答が役立ったか、エージェントがポリシーに従ったか、軌道が怪しいかを評価できます。これは大規模に実行できるため、特に本番トレースに対するオンライン評価として有用です。完璧ではなく、キャリブレーションが必要ですが、人間のレビューでは遅すぎる場合に、チームが構造化フィードバックを作成する方法を提供します。

最後に、フィードバックは決定論的であり得ます。ルールと正規表現は過小評価されています。既知の障害パターンがあれば、それをコード化します。エージェントが承認なしに破壊的なコマンドを呼び出すべきでないなら、それをチェックします。応答に引用が含まれるべきなら、検証します。コーディングエージェントがユーザーのフラストレーションの兆候を示したら、それを検出します。

Claude Codeのリークはこれを具体化しました。複数のレポートが、Claude CodeがuserPromptKeywords.tsで正規表現を使用して、ユーザープロンプト内のフラストレーションを表す単語やフレーズを検出していることを明らかにしました。PCWorldは、この正規表現が「wtf」「horrible」「awful」「this sucks」などの用語を探していると報じました。エンジニアリングの観点から、このパターンは示唆に富んでいます。すべてのフィードバックシグナルにモデル呼び出しが必要なわけではありません。安価なルールで有用なシグナルが得られるなら、そのルールを使い、そのシグナルがどのように保存・使用されるかを明確にします。

可観測性プラットフォームには3つの機能が必要です。第一に、トレースを保存すること。これは基本層で、エージェントが行ったすべてのこと(モデル呼び出し、ツール呼び出し、入出力、メタデータ、タイミング、エラー、中間状態)の完全な軌跡が必要です。理想的には、使用しているスタックに関係なくトレースを取り込めること。LangSmithは30以上のフレームワークからのトレースをサポートし、OpenTelemetry互換アプリケーションからも取り込めます。第二に、フィードバックを保存すること。フィードバックはトレースから切り離された別のスプレッドシートや分析システムに置くべきではありません。評価対象のラン、トレース、スレッドに直接アタッチする必要があります。そうすることで、フィードバックによるフィルタリング、良い軌跡と悪い軌跡の比較、実際の失敗からのデータセット構築、変更が重要な行動を改善したかどうかの追跡が可能になります。LangSmithはフィードバックをキャプチャし、トレースに関連付けることをサポートしています。第三に、フィードバックを生成すること。一部のフィードバックはユーザーから得られますが、多くの有用なフィードバックはシステム自体が生成するべきです。これには、ルール、評価器、サンプリング、アノテーションキュー、アラート、過去のトレースへのバックフィルが含まれます。LangSmithは自動化ルールとオンライン評価をサポートしており、本番トレースに対してLLM-as-judge評価器を実行できます。

これがエージェントチームに必要なプロダクトの形です。トレースの保存、フィードバックの保存、フィードバックの生成。

学習ループはトレースとフィードバックに依存します。可観測性の目的は単にトレースを見ることではなく、そこから学ぶことです。トレースは何が起こったかを教え、フィードバックはそれが何を意味するかを教えます。両者が一体となって、モデル、ハーネス、コンテキストを改善できます。手動デバッグと自動評価をサポートします。本番の行動をデータセット、ルール、アラート、リグレッションテストに変換します。

フィードバックのないエージェント可観測性は不完全です。行動を検査できても、体系的に学習することはできません。エージェントの可観測性を最大限に活用するには、トレースとともにフィードバックを保存してください。それがエージェントトレースをログから学習システムに変えるのです。