continuous evaluationの構築
前の章では、online evalsで使えるWeaveの機能として、Feedback、Dashboards、Guardrails、Monitors、Automationsを見ました。
ここで重要なのは、それぞれの機能を単発で使うことではありません。本番で起きたことを観測し、人の判断やScorerの結果を残し、問題ケースをoffline evalsに戻し、次の改善につなげる流れを作ることです。この流れができると、AI Agentの評価は一度きりのテストではなく、継続的に育つ仕組みになります。
continuous evaluationとは
continuous evaluationは、AI Agentの品質を一度評価して終わりにせず、本番運用の中で継続的に測り、改善に戻していく考え方です。
AI Agentは、ユーザーの入力、業務環境、モデル、プロンプト、外部ツールの状態によって振る舞いが変わります。そのため、リリース前のoffline evalsで良い結果が出ていても、本番でずっと同じ品質を保てるとは限りません。
そこで、次のようなループを作ります。
- 1本番のTraceをWeaveに残します。
- 2FeedbackやMonitorで、良いケースと悪いケースを見つけます。
- 3問題ケースをDatasetやAnnotationに戻します。
- 4offline evalsで再現できる評価ケースにします。
- 5Coding Agentや開発者がAI Agentを改善します。
- 6再評価して、本番へ戻します。
このループを回すことで、本番で得られた学びが次の評価体系と改善に反映されます。
online evalsとoffline evalsをつなぐ
online evalsとoffline evalsは、役割が違います。
| 種類 | 役割 | 使うタイミング |
|---|---|---|
| offline evals | 変更前後の品質を同じ条件で比較する | 開発中、本番投入前、改善後 |
| online evals | 本番で起きている変化や失敗を観測する | 本番運用中 |
offline evalsは、評価DatasetとScorerを固定して、変更が良くなったかを比較するために使います。一方、online evalsは、本番で想定外の入力、品質劣化、コスト増加、安全性の問題が起きていないかを見るために使います。
大事なのは、online evalsで見つけた失敗をその場限りの調査で終わらせないことです。良くないTrace、低スコアのMonitor結果、人手Feedbackが付いたCallを、offline evalsのDatasetに戻していきます。そうすると、次に同じような失敗が起きないかを継続的に確認できます。
評価Datasetを育てる
AI Agent評価の心得でも見たように、評価は最初から完成させるものではなく、運用の中で蓄積していくものです。
たとえば、online evalsでモニタリングしている中で、「このTraceは次回以降の評価Datasetに加えたい」と思うケースが出てきます。Weaveでは、TraceやCallを確認しながら、評価に使いたいケースをDatasetに追加できます。つまり、本番で見つかった失敗や重要な境界ケースを、次のoffline evalsで再現できる評価データとして残していけます。
このような機能はすでにWeaveにあります。Traceを見て終わりにするのではなく、評価に戻すべきものをDatasetへ加え、評価Datasetを少しずつ大きくしていきましょう。
Weave Datasetは、AI Agent評価用のサンプルを整理、収集、追跡、バージョン管理するための仕組みです。さらに、Dataset、Scorer、Prompt、Modelなどの評価に関わる成果物は、WeaveのObject管理によってバージョン付きで管理できます。
このとき重要なのは、DatasetやScorerを単なるファイルとして扱わないことです。どのDatasetで、どのScorerを使い、どのAI Agentのバージョンを評価したのかが追える状態にしておくと、あとから改善の根拠を確認しやすくなります。
WeaveのObjectには、バージョン参照や:latestのようなエイリアスを使えます。また、Object versionに対してタグを追加したり、エイリアスを設定したりするAPIもあります。これにより、今どれが最新のDatasetなのか、どれを本番相当として扱うのか、どのScorerを基準にするのかを分かりやすく管理できます。
たとえば、次のような運用が考えられます。
| 管理したいもの | 例 |
|---|---|
| 最新の評価Dataset | :latestで参照する |
| 本番前チェックに使うDataset | production-candidateのようなエイリアスを付ける |
| 失敗ケースを集めたDataset | failure-casesのようなタグを付ける |
| 今の基準Scorer | baselineやcurrentのようなエイリアスを付ける |
| 実験用のScorer | experimentalのようなタグを付ける |
このようにDatasetとScorerを育てながら、評価体系そのものもバージョン管理していきます。AI Agentを改善するたびに評価Datasetも少しずつ強くなり、次の改善で同じ失敗を見逃しにくくなります。
Weaveを使った基本ループ
Weaveを使う場合、continuous evaluationの基本ループは次のように考えられます。
| ステップ | Weaveで使うもの | 目的 |
|---|---|---|
| 本番実行を記録する | Trace | 入力、出力、tool call、中間処理を残す |
| 人の判断を集める | Feedback、Human Annotation、Annotation Queue | 何が良いか、何が悪いかを言語化する |
| 自動で傾向を見る | Monitor、Dashboard | 品質、安全性、コスト、レイテンシの変化を見る |
| 重大な問題を止める | Guardrail | ユーザーに届く前にブロックまたは修正する |
| 問題を知らせる | Automation | 閾値超過や異常を通知、webhookに接続する |
| 改善に戻す | Dataset、Evaluation、Scorer | 失敗ケースを再評価できる形にする |
このように、Traceを中心にして、人手評価、自動評価、監視、改善をつなげます。
どこから始めるか
最初からすべてを自動化しようとすると、設計が重くなります。まずは、次の順番で小さく始めるのが現実的です。
- 1重要な処理を
@weave.op()でTraceに残します。 - 2本番や検証環境でFeedbackを集めます。
- 3失敗が多い観点を1つ選び、Monitorを作ります。
- 4本当に止めるべきリスクだけGuardrailにします。
- 5低スコアやFeedback付きのTraceをDatasetに戻します。
- 6offline evalsで改善前後を比較します。
たとえば、まず「根拠に基づかない回答が出ている」という問題が見えてきたら、すぐに10個のScorerを作るのではなく、根拠性に関するMonitorを1つ作ります。その結果を見ながら、どのケースをDatasetに入れるべきか、人手評価で何を確認すべきかを決めていきます。
Automationで運用に乗せる
continuous evaluationを続けるうえで、人が毎日すべてのDashboardやTraceを見る運用は長続きしません。そこで、一定の条件を満たしたときに通知やwebhookを動かすAutomationが重要になります。
たとえば、次のような条件を設定できます。
- Monitorの低スコア率が一定以上になったらSlackに通知する
- Safety系のScorerが発火したTraceをレビュー対象にする
- レイテンシやコストがしきい値を超えたら担当者に知らせる
- 特定のFeedbackが付いたTraceを改善候補として集める
Automationは、continuous evaluationを人手の根性論にしないための仕組みです。人が見るべきケースを絞り込み、改善に回すべき情報を見逃しにくくします。
まとめ
continuous evaluationの目的は、AI Agentの品質を本番運用の中で育て続けることです。
offline evalsは、変更前後の比較に強い仕組みです。online evalsは、本番で起きる想定外の変化を見つける仕組みです。この2つを分けて考えつつ、Trace、Feedback、Monitor、Guardrail、Automation、Dataset、Evaluationをつなげることで、評価と改善のループを作れます。
次の章では、こうした仕組みを使いながら、不具合や品質劣化の兆候を拾うbuilt-in Signalsの考え方を見ていきます。