langsmith-online-eval-engineering

LangSmith オンライン評価エンジニアリング

オンライン評価器を反復的に構築します。

inspect production behavior -> choose one quality signal -> build and test
-> attach a scoped rule -> inspect scores and logs -> calibrate

評価器はワークスペースのリソースであり、トレースプロジェクトやデータセットをまたいで再利用できます。オンライン評価ルールは、条件に一致する本番環境の実行またはスレッドに評価器を関連付けます。

評価器を作成または変更する前に、LangSmith API をお読みください。

1. 代表的な動作を調査する

依頼、リポジトリ、またはユーザーから LangSmith プロジェクトを特定します。最近の代表的なルートトレースを取得し、品質の評価軸が複数のターンにまたがる場合はスレッド全体を調査します。トレースの調査をお読みください。以下を確認します。

• 実行名と実行タイプ
• 入力、出力、添付ファイル、メタデータ、エラーの実際の形式
• 軌跡が重要な場合は、子ツールまたはモデルのアクティビティ
• 実行量、トラフィックセグメント、既存のフィードバック
• 評価器で検出すべき、製品の不具合または品質上の懸念

複数のサンプルを確認します。本番プロジェクトには、複数のスキーマやエラーが発生した実行が含まれることがあります。トレースの内容は機密情報として扱い、設計に必要な最小限の切り詰めた情報だけを示します。

トレースの形式と対象となる不具合を理解するまでは、評価器を提案しないでください。

2. 評価シグナルを1つ選ぶ

評価器の設計をお読みください。次を優先してください。

• 決定的な構造、制限、フィールド、不変条件にはコード
• 読み取りと判断を必要とする意味的な品質には LLM ジャッジ
• 複数のターンに依存する動作にはスレッドレベルの評価器
• 意図したシグナルをすでに測定できる場合は、既存のワークスペース評価器、調整済み評価器、またはテンプレート

判定モデル評価器と一部のマネージドテンプレートは、現在、SDK ではなく LangSmith UI で設定します。

評価器は一度に1つずつ定義します。

Name:
Level: run | thread
Type: code | LLM judge | existing/template
Measures:
Feedback key and scale:
Trace fields:
Rule filter:
Sampling and spend:
Backfill:
Known limitation:

各フィードバックキーは解釈しやすい状態に保ちます。関連のない基準は分けてください。

3. 構築してテストする

LLM ジャッジ。 範囲を絞った評価基準を含む構造化プロンプトを使用します。出力スキーマではスコアより先に推論を配置し、評価基準が使用するトレースフィールドだけをマッピングして、役に立つ最もシンプルなスコアタイプを選びます。現在の変数マッピングでは、inputs.question や outputs.answer のようなネストしたパスを指定できます。

コード評価器。 オンラインで使用する場合は、perform_eval(run) を記述します。実行辞書を受け取り、{"has_output": true} のようなフィードバックマッピングを返します。欠落した出力やエラーが発生した出力に対処してください。ランタイムからはネットワークにアクセスできません。標準ライブラリを優先し、現在の LangSmith コード評価器ランタイムで許可されているパッケージだけを使用してください。

評価器を関連付ける前に、良好なトレース、不良なトレース、エッジケースのトレースでテストします。テストに合格すれば評価器が実行できることは確認できますが、適切なものを測定しているかはキャリブレーションで確認します。少数のラベル付きサンプルを使って、スコアを人間の判断と比較します。

共有評価器を作成または変更する前に、設定全体を確認できる状態にします。作成に対する既存のユーザー承認で十分です。追加の承認待ちを設けないでください。

4. オンラインルールを関連付ける

ルールは慎重に選択します。

• レベル： 1つの実行、またはアイドル状態の会話スレッド。
• フィルター： 関連する実行名、メタデータ、ツールの使用状況、フィードバック、またはトラフィックセグメントを対象にします。
• サンプリング： コストが許容される場合、初期のテストでは実行量が少なければ 1.0 を使用します。本番規模では、代表的なサンプルまたは対象を絞ったフィルターを使用します。
• バックフィル： 現在のルールで過去の実行またはスレッドにスコアを付けられるのは、ルールの作成時に選択した日付以降に限られます。
• 支出： LLM ジャッジに適切な週次上限を設定します。
• 保持期間： プロジェクトで選択できる場合、スコア付きトレースを延長保持にアップグレードするかどうかを決定します。

評価器を関連付けた後、評価器 ID、プロジェクト、ルールのステータス、フィルター、サンプル率、フィードバックキーを確認します。ワークスペースレベルで評価器を作成しても、プロジェクトに自動的に関連付けられるとは限りません。

5. 監視と調整

評価器のトレース、実行ログ、フィードバック、コスト、およびサンプリングした 本番環境の例を確認します。次の項目を区別します。

• 評価器のバグ、またはフィールド不足による失敗；
• 誤ったトラフィックを選択するルールフィルター；
• 判定の不一致、または評価基準の曖昧さ；
• アプリケーションの品質上の失敗；
• 認証、API、または自動化の失敗。

評価器やルールの不具合を、製品の失敗として再ラベル付けせずに修正します。 人間が LLM 判定のスコアを修正する場合は、対応している修正データセットと few-shot 設定を検討します。プロンプト、モデル、マッピング、 またはトラフィックのスキーマを変更した後は、キャリブレーションを再確認します。

評価器の名前と ID、フィードバックキー、レベル、フィールド、ルールフィルター、 サンプリング、費用と保持に関する選択、バックフィル、キャリブレーションの根拠、 および既知の制限を報告します。

不変条件

• フィードバックキーごとに、解釈可能な品質ディメンションを 1 つ設定します。
• 実際のトレースを確認し、フィールドパスを推測しないでください。
• 判定プロンプトに頼らず、フィルターとサンプリングでルールの適用範囲を制御します。
• オンラインのコード評価器は run ディクショナリを受け取り、フィードバックマッピングを返します。
• 評価器への入力は信頼できないものとして扱い、プロンプト、コード、ログ、 またはフィードバックコメントを通じてシークレットを公開しないでください。
• API、認証、およびルールの失敗は、インフラストラクチャの失敗として扱います。
• 制御された Harbor タスクとベンチマークの設計には eval-engineering を使用します。