AWS上のLangSmithを使用したディープエージェントの評価

この記事はLangChainのパートナーシップ責任者であるKaran Singhとの共著です。

AIエージェントの動作を本番稼働前に検証することは、応用AIにおける最も困難な問題の1つです。エージェントは非決定的であり、複数のステップからなり、初期のステップのエラーが後続の結果に影響を与える可能性があります。1回の誤ったツール呼び出しがワークフロー全体に波及する恐れがあります。AWS上のLangSmithは、これらの問題を早期に発見し、本番環境で追跡し、エージェントの信頼性をライフサイクル全体にわたって継続的に改善するための評価フレームワークを提供します。

この記事は、LangChainのディープエージェント評価に関する取り組みと、AnthropicのAIエージェント評価を解明するガイドを組み合わせた実践的なチュートリアルです。この記事では、以下の内容を学びます。1) 5つのディープエージェント評価パターンの適用、2) pytestとLangSmithを使用したオフライン評価の構築、3) 本番環境向けのオンラインモニタリングの設定。サンプルでは、Amazon Bedrockを使用したテキストto SQLディープエージェントを取り上げ、開発から本番までのライフサイクル全体をカバーします。

Amazon Nova 2 Liteモデル

Amazon Nova 2 Liteは、Amazon Bedrockで利用可能な高速でコスト効率の高い推論モデルです。構成可能な予算レベル（低、中、高）での拡張思考をサポートし、テキスト、画像、ビデオ、ドキュメントの入力を受け付け、100万トークンのコンテキストウィンドウを持ちます。Nova 2 Liteは命令追従、関数呼び出し、コード生成に優れており、この記事のテキストto SQLエージェントのようなエージェントワークロードに適しています。

エージェント評価の構造

評価とは、AIシステムに対するテストです。AIに入力を与え、出力に評価ロジックを適用し、成功を測定します。大規模言語モデル（LLM）の呼び出しではこれは単純ですが、エージェントではすべてのコンポーネントがより複雑になります。

**主要用語**:

• **タスク**: 定義された入力と成功基準を持つ単一のテスト。例：「カナダからの顧客は何人？」期待される回答は8。
• **試行**: タスクへの1回の試み。モデル出力は非決定的であるため、タスクごとに複数の試行を行うことで、より信頼性の高い結果が得られます。
• **評価器**: エージェントのパフォーマンスのある側面をスコアリングするロジック。1つのタスクに複数の評価器を持たせ、それぞれ異なる次元を評価できます。
• **トランスクリプト**: 試行の完全な記録。ツール呼び出し、推論ステップ、中間結果、相互作用を含みます。LangSmithでは、これはデバッグ用に検査できる完全なトレースです。
• **結果**: 試行終了時の環境の最終状態。エージェントが「答えは8です」と言っても、実際にデータベースに対して正しいSQLクエリを実行したかどうかが結果です。
• **評価ハーネス**: 評価をエンドツーエンドで実行するインフラストラクチャ。指示とツールを提供し、タスクを並行して実行し、ステップを記録し、出力を評価し、結果を集約します。
• **評価スイート**: 特定の能力や動作を測定するために設計されたタスクのコレクション。

なぜエージェント評価が難しいのか

3つの特性により、エージェント評価は単純なLLM出力の評価とは根本的に異なります。

• **非決定性**: エージェントの動作は実行ごとに異なります。同じタスクが90%成功し、10%失敗する可能性があります。単一の合格/不合格の結果だけではあまり情報が得られません。実際のパフォーマンスを推定するには複数の試行が必要です。2つの有用な指標：pass@k（k回の試行で少なくとも1回成功する確率）とpass^k（すべてのk回の試行が成功する確率）。1回の成功で十分な場合はpass@kを、一貫性が重要な場合はpass^kを使用します。
• **エラーの伝播**: マルチステップエージェントでは、ステップ3でのエラーが後続のステップに連鎖する可能性があります。テキストto SQLエージェントが初期段階でスキーマを誤認識すると、誤ったJOINが構築され、最終回答が間違ったものになります。最終出力だけを評価しても、問題がどこで発生したかを見逃します。
• **創造的な解決策**: 最先端のモデルは、評価設計者が予期しなかった有効なアプローチを見つけることがあります。

評価可能なもの

エージェント実行には、テスト可能な3つのカテゴリがあります。

• **軌跡**: 呼び出されたツールのシーケンスと生成された引数。スキーマを探索したか？実行前にsql_db_query_checkerを使用したか？
• **最終応答**: ユーザーに返される最終出力。答えは正しいか？フォーマットは適切か？
• **その他の状態**: エージェントが生成したその他の成果物（書き込まれたファイル、作成されたTODO計画、保存された中間結果など）。

AIエージェントの評価パターン

エージェント評価は通常、3種類の評価器を組み合わせます。効果的な評価設計の鍵は、ユースケースに適した組み合わせを選択することです。

**コードベース評価器**: 決定論的ロジックを使用して特定の条件を検証します：文字列マッチング、正規表現、バイナリ合格/不合格テスト、静的解析、ツール呼び出し検証、トランスクリプト分析（ターン数、トークン使用量）。利点：高速、低コスト、客観的、再現可能、デバッグが容易。欠点：期待されるパターンに完全に一致しないバリエーションを検証するのに脆弱。

例：ツールが呼び出されたことを確認：

tool_names = [tc["name"] for tc in tool_calls]
assert "sql_db_query" in tool_names, "Agent must execute sql_db_query"

**モデルベース評価器（LLM-as-judge）**: 別のLLMを使用してエージェントの出力を評価します。方法には、ルールベースのスコアリング、自然言語アサーション、ペアワイズ比較、マルチジャッジコンセンサスなどがあります。利点：柔軟性、スケーラビリティ、ニュアンスの把握、オープンエンドなタスクや自由形式の出力の処理。欠点：非決定的、コードよりも高コスト、人間の評価者によるキャリブレーションが必要。

例：複雑な分析回答の評価：

rubric = """Score the agent's answer on these dimensions (0.0 to 1.0):
1. correctness: Does it identify the right top employee? (Jane Peacock)
2. completeness: Does it include revenue broken down by country?
3. clarity: Is the answer well-formatted and easy to understand?
Return JSON: {"correctness": float, "completeness": float, "clarity": float}"""
judge_response = model.invoke(rubric.format(answer=answer))
scores = json.loads(judge_response.content)

LangSmithのAlign Evaluator機能は、LLM-as-judge評価器を人間の専門家フィードバックに対して調整する一連のステップを提供します。この機能を使用して、オフライン評価用のデータセットやオンライン評価用に実行する評価器を調整できます。

**人間評価器**: 人間評価器（主題専門家レビュー、クラウドソーシング判断、スポットチェックサンプリング）は、主観的な品質評価のゴールドスタンダードと見なされます。プログラムによる評価オプションと比較すると、高コストで低速ですが、モデルベース評価器のキャリブレーションには不可欠です。推奨：最初にLLM-as-judgeのルールを専門家の人間判断でキャリブレーションし、その後定期的に人間レビューを実施して自動評価器がドリフトしていないことを確認します。

**評価器の組み合わせに関する実践的な推奨**: 可能な場合は決定論的評価器を、ニュアンスが必要な場合はLLM評価器を、キャリブレーションには人間評価器を使用します。テキストto SQLエージェントの場合：コードベース評価器はsql_db_queryが呼び出されたか、回答に「8」が含まれているか、DMLステートメント（INSERT, DELETE）が実行されたかをチェック。LLM-as-judgeは複雑なクエリ（分析が正しく、完全で、構造化されているか）を処理。人間評価器は定期的なスポットチェック。

能力評価と回帰評価

すべての評価が同じ目的を持つわけではありません。

• **能力評価**: 「このエージェントは何を得意とするか？」を問います。エージェントが現在苦手とするタスクをターゲットにし、チームに改善の余地を与えます。低い合格率から始めて、徐々に上げていきます。
• **回帰評価**: 「エージェントは以前できたことをまだ処理できるか？」を問います。合格率はほぼ100%であるべきです。低下は何かが壊れていることを示します。

エージェントが成熟するにつれて、高い合格率に達した能力評価は回帰スイートに昇格できます。かつて「それができるか」を測定していたタスクが、「それを確実にできるか」を測定するようになります。

ディープエージェントの評価

ディープエージェント（計画、ツール使用、ファイルシステムバックエンド、プログレッシブコンテキストローディングを使用して複雑なマルチステップタスクを処理するシステム）は、すべてのテストケースが同じアプリケーションロジックで実行され、同じ評価器でスコアリングされるという従来の前提を覆します。LangChainは過去数ヶ月間に、ディープエージェントアーキテクチャ上に4つのアプリケーションをリリースし、広く適用可能な4つのパターンを特定しました。

**パターン1: データポイントごとのカスタムテストロジック** 従来のLLM評価はすべてのデータポイントを同一に扱います。同じアプリケーションを実行し、同じ評価器でスコアリングします。ディープエージェントはこの前提を覆します。各テストケースには独自の成功基準があり、それらの基準はエージェントの軌跡や状態に対する具体的なアサーションを含む可能性があり、最終メッセージだけではありません。

テキストto SQLエージェントを考えてみましょう。「カナダからの顧客は何人？」には単一の正しい答え（8）があり、文字列マッチでチェックできます。しかし、「どの従業員が最も多くの収益を上げ、その収益はどの国からのものか？」には、有効な回答の形式が大きく異なるため、LLM評価器が正確性、完全性、明確性を評価する必要があります。

LangSmithのPytest統合はこのパターンをサポートします。テストケースごとにエージェントの軌跡、最終メッセージ、状態に対して異なるアサーションを行うことができます。

@pytest.mark.langsmith
def test_canada_customer_count(sql_agent):
    result = sql_agent.invoke({"messages": [{"role": "user", "content": "How many customers are from Canada?"}]})
    answer = result["messages"][-1].content
    assert "8" in answer

@pytest.mark.langsmith
def test_revenue_by_employee(sql_agent, model):
    result = sql_agent.invoke({"messages": [{"role": "user", "content": "Which employee generated the most revenue?"}]})
    scores = llm_judge(model, result["messages"][-1].content)
    assert scores["correctness"] >= 0.5

**パターン2: 単一ステップ評価** LangChainのディープエージェントテストケースの約半数は単一ステップ評価でした。つまり、特定の入力の直後にエージェントが何をするかを決定したか？これは個々の決定ポイントを検証するのに特に有用です。正しいツールを正しい引数で呼び出したか？

回帰は多くの場合、完全な実行シーケンスではなく、個々の決定ポイントで発生します。テキストto SQLエージェントの場合、単一ステップ評価は、エージェントの最初のアクションがデータベーススキーマの探索（sql_db_list_tablesまたはsql_db_schemaを呼び出す）であり、クエリを直接書き始めないことを検証するかもしれません。

@pytest.mark.langsmith
def test_agent_calls_sql_tools_first(sql_agent):
    result = sql_agent.invoke({"messages": [{"role": "user", "content": "How many customers are from Canada?"}]})
    tool_calls = extract_tool_calls(result["messages"])
    tool_names = [tc["name"] for tc in tool_calls]
    sql_tools = {"sql_db_list_tables", "sql_db_schema", "sql_db_query", "sql_db_query_checker"}
    assert sql_tools & set(tool_names), "Agent must use SQL tools"

単一ステップ評価はユニットテストのようなものです。高速で焦点が絞られ、トークン効率が良いです。

**パターン3: 完全なエージェントターン** 単一ステップ評価が個々の決定をテストするのに対し、完全なエージェントターンは全体像を示します。1つの入力に対してエージェントをエンドツーエンドで実行し、評価します。

（原文はここで切れていますが、上記で主要なパターンをカバーしています。）

これらのパターンを組み合わせることで、チームは信頼性の高い評価パイプラインを構築し、ディープエージェントが本番環境で安定して動作することを保証できます。