評価結果をもとにW&B SkillsとCoding AgentでAI Agentを改善
評価結果をCoding Agentの入力にする
前の章では、Weaveで自動評価の体系を作る方法や人手評価から始める方法を見ました。評価体系を回すことで、自動評価の結果がWeaveに蓄積されていきます。また、現場の人が残したFeedbackもWeaveのTraceに蓄積されていきます。
次に考えたいのは、その評価結果をどう改善につなげるかです。
人間が評価した結果を眺めるだけでは、改善はなかなか進みません。評価で見つかった失敗をCoding Agentに渡し、原因を調べさせ、改善案を作らせ、実装と再評価までつなげることを考えましょう。ここで役に立つのがW&B Skillsです。W&B Skillsについては、Coding Agentで統合テストを行う / W&B Skillsをご確認ください。
W&B Skillsは、Coding AgentにWeave上のTraceや評価結果を読ませ、改善の材料として使わせるための入口になります。
人手フィードバックをもとに大きな改善をかける
人手評価からは、開発の大きな方向性の変更のヒントを得ることができます。まずは人手評価をもとに変更をすることを考えましょう。人手評価から改善案を作るとき、Coding Agentには次のような情報を渡します。
| Coding Agentに渡すもの | Coding Agentに依頼すること |
|---|---|
| Human Annotationの結果一覧と対応するTrace | 良いポイント、改善ポイント、失敗モードを要約する |
| 評価項目やAnnotation fieldの意味 | どの評価を重視すべきか整理し、改善方針に反映する |
| 低スコアのケースや代表的な失敗ケース | 入力、出力、tool call、中間処理を見て原因を調べる |
| 現在のコード、プロンプト、tool定義 | 変更案を作り、実装前のplanとして提示する |
| 変更後に使うDatasetとScorer | 実装後に再評価し、変更前後の結果を比較する |
例えば、現場の人が「根拠が弱い」「回答が長すぎる」「指示と違う形式で返している」といったFeedbackを残したとします。Coding Agentは、W&B Skillsを使って該当するTraceを取り出し、どの入力で、どの処理を通り、どの出力になったのかを確認できます。
まずCoding Agentには、Human Annotationの結果一覧と対応するTraceを読ませます。そのうえで、現状の良いポイント、改善ポイント、失敗モードを整理し、変更のplanを作らせます。人の評価は曖昧なこともあります。「短い回答がよい」と「説明が足りない」が同時に出ているような場合、どちらを優先するかは自明ではありません。このように変更の方向性が曖昧なときは、Coding Agentに勝手に実装させるのではなく、開発者へ聞き返すようにするなどのフローも考えましょう。
planが固まったら、改善の実装をCoding Agentに任せます。原因がプロンプトにありそうなのか、toolの使い方にありそうなのか、検索結果の扱いにありそうなのか、後処理にありそうなのかを切り分け、必要な変更を行います。
自動評価スコアをもとに次のバージョンの改善を行う
人手評価をもとに改善したあとは、すぐに新しいバージョンに対してもう一度人手評価を行いたくなります。ただし、人手評価には時間がかかります。そこで、評価体系の中に自動的に評価できるスコアがある場合は、まずそのスコアが許容範囲に入るように改善を進めます。
やり方はシンプルです。現在の評価DatasetとScorerを使って自動評価を実行し、その結果をW&B Skills経由でCoding Agentに渡します。Coding Agentには、スコアが低いケースや前回より悪化したケースを分析させ、Traceを見ながら原因を分類させます。そのうえで、改善案を作らせ、実際の変更まで進めます。
このプロセスは一度で終わるとは限りません。いくつかの改善案を試し、同じDatasetとScorerで再評価し、前回の結果と比較します。何度かそのプロセスを繰り返しながら、もっとも良いパターンを選びます。Weaveでは、評価結果やTraceを比較できるため、どの変更でどのスコアが改善し、どこに副作用が出たのかを確認しやすくなります。
ただし、自動評価スコアだけを追いかけると、人手評価で集めた観点が抜け落ちることがあります。例えば、人が「自然で信頼できる」と感じていた表現が、スコア最適化の過程で失われるかもしれません。そのため、新しく作ったバージョンが、実際に集まった人手評価のポイントを守れているかについて、LLM as a Judgeをかけて判断させるプロセスも必要になるでしょう。完全な代替ではなく、人手評価に戻る前の確認として使います。
その後に、あらためて人手評価を行います。自動評価で許容範囲まで持っていき、人手評価で現場の判断を確認する。この順番にすると、人手評価に使う労力を最大限に活かすことができます。
人手評価のサンプルが溜まってくると、人手評価そのものをある程度再現するLLM as a Judgeを作れる部分も出てきます。つまり、人間の判断を完全に置き換えるのではなく、人間の判断に近い目安として自動評価を育てていくイメージです。人手評価、LLM as a Judge、自動改善をつなげることで、自動評価と自動改善で到達できる品質を少しずつ高めていきます。
なお、この領域はまだ実践的なプラクティスが十分に固まっているわけではありません。何がうまくいくのかは、今後も試しながら共有していきたいと思います。実際に一つのケースで実装してみた内容については、別の実践コースで紹介します。