はじめに
本番環境でLLMアプリケーションを構築していますか?次の2つの質問が夜も眠れないほど気になっているでしょう:- LLMが安全で適切なコンテンツを生成することをどのように確保しますか?
- 出力品質をどのように測定し、時間とともに改善しますか?
- ガードレールとして:安全でないコンテンツがユーザーに届く前にブロックまたは修正する
- モニターとして:時間の経過とともに品質指標を追跡し、傾向や改善点を特定する
用語
このガイド全体を通して、
@weave.opでデコレートされた関数を「ops」と呼びます。これらは、Weaveのトラッキング機能で強化された通常のPython関数です。すぐに使えるScorer
このガイドではカスタムScorerの作成方法を示していますが、Weaveには様々な事前定義されたScorerが付属しており、すぐに使用できます。以下のようなものがあります:ガードレールとモニター:それぞれの使用タイミング
Scorerはガードレールとモニターの両方を強化しますが、それぞれ異なる目的を果たします:
例えば、有害性を評価するScorerは以下のように使用できます:
- ガードレールとして:有害なコンテンツを即座にブロック
- モニターとして:時間の経過とともに有害性レベルを追跡
すべてのScorer結果は自動的にWeaveのデータベースに保存されます。つまり、ガードレールは追加作業なしでモニターとしても機能します!元々どのように使用されていたかに関わらず、Scorerの過去の結果を常に分析できます。
メソッドの使用.call()
WeaveのopsでScorerを使用するには、操作の結果とそのトラッキング情報の両方にアクセスする必要があります。.call()メソッドは両方を提供します:
Scorerの使用を始める
基本的な例
以下はScorerで.call()を使用する簡単な例です:
ガードレールとしてのScorerの使用
ガードレールは、LLM出力がユーザーに届く前に実行される安全チェックとして機能します。以下は実用的な例です:Scorerのタイミング
Scorerを適用する際:
- メイン操作(
generate_text)が完了し、UIで完了としてマークされる - Scorerはメイン操作の後に非同期で実行される
- Scorerの結果は完了後に呼び出しに添付される
- UIでScorer結果を表示したり、APIを通じてクエリしたりできる
モニターとしてのScorerの使用
スコアリングロジックをアプリに書き込まずに品質指標を追跡したい場合は、monitorsを使用できます。 モニターは以下を行うバックグラウンドプロセスです:- でデコレートされた1つ以上の指定された関数を監視する
weave.op - を使用して呼び出しのサブセットをスコアリングするLLM-as-a-judgeスコアラー。これは、スコアリングしたいopsに合わせた特定のプロンプトを持つLLMモデルです
- 指定された
weave.opが呼び出されるたびに自動的に実行され、手動で.apply_scorer()
- 本番環境の動作を評価および追跡する
- 回帰やドリフトを検出する
- 時間の経過とともに実世界のパフォーマンスデータを収集する
モニターを作成する
- 左側のメニューからMonitorsタブを選択します。
- モニターページからNew Monitorをクリックします。
- ドロワーでモニターを設定します:
- Name:有効なモニター名は文字または数字で始まり、文字、数字、ハイフン、アンダースコアのみを含むことができます。
- Description (オプション):モニターの機能を説明します。
- Active monitor toggle: Turn the monitor on or off.
- Calls to monitor:
- Operations:モニターする1つ以上の
@weave.opを選択します。 - Filter (オプション):モニタリングの対象となるop列を絞り込みます(例:
max_tokensまたはtop_p) - Sampling rate:スコアリングされる呼び出しの割合(0%〜100%、例:10%)
- Operations:モニターする1つ以上の
- LLM-as-a-Judgeの設定:
- スコアラー名: 有効なスコアラー名は文字または数字で始まり、文字、数字、ハイフン、アンダースコアのみを含むことができます。
- ジャッジモデル: オペレーションをスコアリングするモデルを選択します。以下の3種類のモデルが利用可能です:
- 保存されたモデル
- W&B管理者によって設定されたプロバイダーからのモデル
- W&B Inferenceモデル 選択したモデルに対して、以下の設定を構成します:
- 設定名
- システムプロンプト
- レスポンス形式
- スコアリングプロンプト: LLM-as-a-judgeがオペレーションをスコアリングするために使用するプロンプトです。「参照できるのは
{output}、個々の入力({foo}など)、および{inputs}を辞書として。詳細については、プロンプト変数を参照してください。”
- クリックモニターを作成。Weaveは指定された条件に一致する呼び出しの監視とスコアリングを自動的に開始します。モニターの詳細はモニタータブで確認できます。
Example: Create a truthfulness monitor
次の例では、以下を作成します:- 監視対象となる
weave.op、generate_statement。この関数は、入力ground_truthステートメントを返す(例:"The Earth revolves around the Sun.")、またはground_truthに基づいて不正確なステートメントを生成する(例:"The Earth revolves around Saturn.") - モニター、
truthfulness-monitor、生成されたステートメントの真実性を評価するため。
-
定義
generate_statement: -
コードを実行して
generate_statementのトレースをログに記録します。generate_statementオペレーションは、少なくとも1回ログに記録されない限り、Opドロップダウンに表示されません。 - Weave UIで、モニターに移動します。
- モニターページから、新規モニターをクリックします。
-
モニターを次のように設定します:
-
名前:
truthfulness-monitor -
説明:
A monitor to evaluate the truthfulness of statements generated by an LLM. -
アクティブモニター toggle:
トグルをオンにして、モニターが作成されるとすぐにコールのスコアリングを開始します。
-
監視するコール:
-
オペレーション:
generate_statement。 -
フィルター (オプション): この例では適用されていませんが、
temperatureやmax_tokensなどの引数によって監視範囲を限定するために使用できます。 -
サンプリングレート:
設定を100%にして、すべてのコールをスコアリングします。
-
オペレーション:
-
LLM-as-a-Judge設定:
- スコアラー名:
truthfulness-scorer - ジャッジモデル:
o3-mini-2025-01-31 - モデル設定:
- LLM ID:
o3-mini-2025-01-31 - 設定名:
truthfulness-scorer-judge-model - システムプロンプト:
You are an impartial AI judge. Your task is to evaluate the truthfulness of statements. - レスポンス形式:
json_object - スコアリングプロンプト:

- スコアラー名:
-
名前:
-
クリックモニターを作成。
truthfulness-monitorは監視を開始する準備ができています。 -
モニターによる評価のために、真実で簡単に検証できる
ground_truthステートメント("Water freezes at 0 degrees Celsius."など)でステートメントを生成します。 - Weave UIで、トレースタブに移動します。
- 利用可能なトレースのリストから、LLMAsAJudgeScorer.scoreのトレースを選択します。
-
トレースを調査して、モニターの動作を確認します。この例では、モニターは
output(この場合、ground_truthと同等)をtrueとして正しく評価し、適切なreasoningを提供しました。
プロンプト変数
スコアリングプロンプトでは、オペレーションからの複数の変数を参照できます。これらの値は、スコアラーが実行されるときに関数呼び出しから自動的に抽出されます。次の関数例を考えてみましょう:
例えば:
AWS Bedrock Guardrails
BedrockGuardrailScorerはAWS Bedrockのガードレール機能を使用して、設定されたポリシーに基づいてコンテンツを検出およびフィルタリングします。apply_guardrailAPIを呼び出してコンテンツにガードレールを適用します。
BedrockGuardrailScorerを使用するには、以下が必要です:
- Bedrockアクセス権を持つAWSアカウント
- Bedrockへのアクセス権を持つAWSアカウント
- AWS Bedrockコンソールで設定されたガードレール
boto3Pythonパッケージ
実装の詳細
スコアラーインターフェース
スコアラーはScorerを継承し、scoreメソッドを実装するクラスです。このメソッドは以下を受け取ります:
output:関数からの結果- 関数のパラメータに一致する入力パラメータ
スコアパラメータ
パラメータマッチングルール
outputパラメータは特別で、常に関数の結果を含みます- その他のパラメータは関数のパラメータ名と完全に一致する必要があります
- スコアラーは関数のパラメータのサブセットを使用できます
- パラメータの型は関数の型ヒントと一致する必要があります
パラメータ名の不一致の処理
スコアラーのパラメータ名が関数のパラメータ名と完全に一致しない場合があります。例えば:column_map:
- 関数とスコアラー間の命名規則の違い
- 異なる関数間でのスコアラーの再利用
- サードパーティのスコアラーを自分の関数名で使用する
追加パラメータの追加
スコアラーが関数の一部ではない追加パラメータを必要とする場合があります。これらは次のように提供できますadditional_scorer_kwargs:
スコアラーの使用:2つのアプローチ
- Weaveのオプシステムを使用(推奨)
- 直接使用(クイック実験用)
- 本番環境、トラッキング、分析にはオプシステムを使用
- クイック実験や一回限りの評価には直接スコアリングを使用
- メリット:クイックテストがより簡単
- メリット:Opが不要
- デメリット:LLM/Op呼び出しとの関連付けがない
スコア分析
呼び出しとそのスコアラー結果の照会に関する詳細情報については、スコア分析ガイドおよびデータアクセスガイドをご覧ください。本番環境のベストプラクティス
1. 適切なサンプリングレートを設定する
2. 複数の側面をモニタリングする
3. 分析と改善
- Weaveダッシュボードでトレンドを確認する
- 低スコア出力のパターンを探す
- 洞察を使用してLLMシステムを改善する
- 懸念されるパターンのアラートを設定する(近日公開)
4. 履歴データへのアクセス
スコアラーの結果は関連する呼び出しと共に保存され、以下を通じてアクセスできます:- Callオブジェクトの
feedbackフィールド - Weaveダッシュボード
- クエリAPI
5. ガードを効率的に初期化する
最適なパフォーマンスを得るため、特にローカルで実行されるモデルでは、メイン関数の外部でガードを初期化してください。このパターンは特に以下の場合に重要です:- スコアラーがMLモデルをロードする場合
- レイテンシーが重要なローカルLLMを使用している場合
- スコアラーがネットワーク接続を維持する場合
- トラフィックの多いアプリケーションがある場合
完全な例
これまで説明したすべての概念をまとめた包括的な例を以下に示します:- 適切なスコアラーの初期化とエラー処理
- ガードレールとモニターの組み合わせ使用
- 並列スコアリングによる非同期操作
- 本番環境に対応したエラー処理とロギング
次のステップ
- 探索利用可能なスコアラー
- 学習Weave Ops