法務エージェント向けの効率的な検証器の設計

*著者：Vivek Trivedy (LangChain), Jake Broekhuizen (LangChain), Harrison Chase (LangChain), Niko Grupen (Harvey), Gabe Pereyra (Harvey), Spencer Poff (Harvey), Julio Pereyra (Harvey)* 今月初め、Harvey は [LAB](https://www.harvey.ai/blog/introducing-harveys-legal-agent-benchmark) をリリースしました。これは複雑な法的業務におけるエージェントを評価するためのオープンソースベンチマークです。[初期結果](https://www.harvey.ai/blog/legal-agent-benchmark-initial-results) によると、今日のエージェントでは法的業務は全く飽和しておらず、まだ多くの余地があることが示されています。 Harvey と共同で、私たちは以下の問いに取り組みました： **どのようにすれば、法的エージェントの作業の正しさをより効率的に検証できるでしょうか？** なぜこれが重要なのでしょうか？法的業務は、文書が多くコンテキストを埋め尽くすこと、専門知識が必要であること、そして出力が許容されるためには厳格な基準に従う必要があることから、エージェントにとって特に困難なドメインです。 LAB ベンチマークの検証アプローチは、人間のレビューアーが行うものと同様です。データセット内のすべてのタスクには、タスクが合格するために満たさなければならない一連の**基準 (criteria)** が設定されています。各基準は、個別の LLM 判事によって検証モデルを使用して評価されます。各基準について、検証器はエージェントの出力と測定すべき match_criteria を取得します。そして、各基準ごとに verdict（判定）を出力します。多くのタスクでは、50 以上の個別の基準を検証する必要があります。これらの各基準に対して LLM API コールを行うことは、最先端モデルを用いてスケールする際にコストが高騰します。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a1f044145b463f7820679bc_LAB_verification_dark%201.png) ## より効率的な検証は可能か？ フロンティア・バーフィア（最前線の検証モデル）を実行するコストは、法的エージェントの評価を実施したり、強化学習（RL: Reinforcement Learning）を用いて法的エージェントを訓練したりするチームにとって、実用的な課題を生み出しています。 **どのようにすれば、最前線のパフォーマンスにほぼ近い状態を保ちながら、バーフィアのコストを最大限削減できるでしょうか？** 私たちは、より効率的な検証を行うための 2 つの異なる方法を研究しました： - トークン数を減らす - より安価なトークンを使用する まず最初に検討した方法は、トークン数を減らすことです。トークン数を減らすために、私たちはバッチ処理でバーフィアを実行することを提案します。つまり、各基準ごとに独立して LLM（大規模言語モデル）呼び出しを行うのではなく、単一のバッチ呼び出しで完全な評価基準を判断させるのです。 - 基準ごとのスコアリング：評価基準の各要件に対して 1 つの判定呼び出しを実行する。 - バッチスコアリング：タスクに対して 1 つの判定呼び出しを実行し、すべての評価基準の要件を同時にラベル付けするように判定者に指示する。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a1f045a98613576e1bed6d9_score_modes_dark%201.png) 次に検討した方法は、より安価なトークンを使用することです。より安価なトークンを利用するために、検証段階でより安価なモデルを試すことができます。私たちは Opus 4.7 を基準ごとのスコアリングの参照として使用し、GPT-5.5、Sonnet 4.6、DeepSeek v4 Flash、Claude Haiku 4.5 を、基準ごとのスコアリングとバッチスコアリングの両方で比較しました。 ## Verifier デザイン間での効率性を測定するための実験 Verifier の実験を実行するには、まず verifier が評価する一連の出力を作成する必要があります。これらの出力を作成するために、Kimi K2.6 を搭載したエージェントを、以下の実務分野にわたる 40 の公開 LAB タスクに対して実行しました：企業 M&A（Mergers and Acquisitions）、税務、新興企業/ベンチャーキャピタル（VC）、および信託・遺産継承。 これら 40 のタスク全体で、2,348 の個別のルブリック基準が存在します。各基準は verifier によって合格/不合格として採点されます。まず、Opus-4.7 をすべての基準に対して実行し、ベースラインとしました。これにより、GPT-5.5、Sonnet 4.6、Haiku 4.5、および DeepSeek-V4-Flash を他の verifier オプションとしてテストする際に比較するためのベースラインが得られます。各 verifier の実行は、同じ 2,348 の基準スコア（合格/不合格）を生成し、これらを用いて相互の比較を検討できます。 各 verifier の実行において、以下の項目を測定しました： - 合意率：Opus の各基準ラベルと一致する頻度。 - 偽陽性（False pass）：Opus が不合格とした基準を合格として判定した頻度。 - 偽陰性（False fail）：Opus が合格とした基準を不合格として判定した頻度。 - コスト：40 タスクの verifier 実行における観測されたトークンコスト。 私たちは特に偽陽性に注意を払いました。現実の世界の設定では、不合格となった基準はさらに精査のためにエスカレーションされます。これは通常、法律のような分野において、不合格であるべき基準を合格として認めるよりも好ましい措置です。 エージェントシステムの設計と同様に、検証もパフォーマンス、コスト、時間の間のトレードオフです。基準ごとの検証は審査官の判断範囲を狭めますが、多くの呼び出しを必要とします。一方、バッチ検証はより安価で高速ですが、審査官は一度に完全な評価基準を追跡する必要があります。 以下のチャートは、コストとラベルのドリフト（ズレ）の関係を示しています。横軸は 1,000 の評価基準あたりの検証者コストです。縦軸は Opus の基準ごとのラベルとの不一致率、すなわち「100% - 一致率」です。左下に行くほど良好です。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a1f04746dd6a554378535b6_cost_drift_dark%201.png) いくつかの重要な知見： - 検証コストが低いほど、Opus との不一致も少なくなる傾向があります。 - 評価基準の数が増えると、バッチ処理の方がコスト効率に優れます。 - 個別の基準ごとの検証は、精度を高める一方で、コストと時間がかかるというトレードオフがあります。 - 全体的に、バッチモードでの実行は、各基準ごとの実行と比較して一致率が低くなります。しかし、同じモデルを使用する場合でも、バッチ実行は繰り返し入力トークンのコストを節約するため、実行コストが桁違いに安価になります。 - GPT-5.5 や Opus といった最先端モデルでさえもラベル付けにおいて意見が分かれており、その一致率は 95.7% に過ぎません。これは、一部のデータポイントが専門家と同様に一貫して適用できるほど十分に明確化されていないことを意味します。また、100% の一致率を目標とすることは現実的ではなく、95.7% の一致率が合理的な上限値である可能性を示唆しています。 - DeepSeek は、 verifier（検証者）として Opus と同等の強力な近似モデルであり、いずれも一度に一つの基準を実行し、バッチモードで動作します。さらに、DeepSeek は実行コストが 3 桁分安価であるため、大規模データやトレーニングドメインにおいてスケールして検証を行う必要がある場合に優れた候補となります。 - Haiku は Opus や Sonnet よりも安価でしたが、非常に寛容な傾向がありました。その誤って合格させる率（false-pass rates）は、各基準ごとで 48.4%、バッチモードで 34.7% であり、これは法的検証において望ましくない失敗モードです。 コスト削減：ポストトレーニング後 Verifier は評価（evals）だけでなく、ポストトレーニングにも使用されます。この場合、タスクごとの複数ロールアウトにより検証コストが増幅されます。LLM-as-judge システムはタスクのルブリックを報酬信号に変換し、より安価な報酬信号によって、より多くの実験の実行、より多くのロールアウトの監査、およびより迅速な反復が可能になります。 コストを推計する簡易的な計算では、DeepSeek はスケールした場合でも最先端の検証器に比べて 60〜1000 倍も安価に実行可能であることが示されました。これは、プログラムによる検証が容易ではなく、報酬信号を生成するためにある程度の LLM（大規模言語モデル）を Judge（判定者）として必要とするドメインにおいて、特に重要となります。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/6a1f061d65308641c267aeae_rl_cost_dark%201.png) ## トレーシングから検証器の動作を調整する 結果は、モデルおよび各検証アーキテクチャ（基準別 vs バッチ処理）ごとにプロンプトを固定したものです。さらにテストした追加のレバーとして、ターゲットを絞ったプロンプトチューニングがあります。 プロンプトチューニングの影響を検証するため、DeepSeek と Opus の過去の結果に基づいて自動研究ループを実行しました。なぜ、どのように DeepSeek が乖離したのかを検討し、複数の実行を通じてプロンプトを微調整しました。その際、偽通過率（false-pass rate）の最適化を指示しました。 デフォルトのプロンプトにおける DeepSeek の一部の誤りの主な原因の一つは、DeepSeek が回答が要件に関連している場合、すべての重要な部分を満たしていなくても基準に合格させようとしすぎることでした。最終的なプロンプトでは、検証器に対して各基準の各要素をより明示的にチェックリストとして分解し、提示された情報が完全に明確でない場合は慎重になるよう指示しました。これにより、DeepSeek の偽通過率は両方のスコアリングモードで低下しました：基準別では 10.7% から 9.5% に、バッチ処理では 15.6% から 14.2% に減少しました。 データのためのトレースのマイニングや、プロンプティングを通じた行動のターゲット型蒸留は、検証器およびエージェント全般の改善に向けた効果的な戦略であり続けています。 ## 法務ドメインにおけるより優れたエージェントとより効率的な検証システムの構築 検証器は、世界クラスの法務エージェントを構築するためのパズルの一部に過ぎません。オープンモデルによる検証器は、コストと性能のトレードオフを提供し、チームが評価（evals）を実行したり、RL 事後トレーニングを何桁も安価に行ったりすることを可能にし、多くの場合、まず試みること自体を現実的なものにします。また、バッチ処理のような単純な手法でも検証作業は十分に機能し、コストをさらに一桁削減できることがわかりました。 オープンモデルは、企業にとって最も重要なドメイン向けに独自に微調整された検証器を作成する機会も提供します。多くの研究では、最先端のクローズドモデルが蒸留すべきゴールドスタンダードであると仮定されていますが、本研究においてさえ、Opus、GPT-5.5、Sonnet はラベルの約 4〜5% で意見が一致していません。この信念をさらに挑戦するためのさらなる研究が必要だと私たちは考えています。 私たちは、大規模なより良い検証システムに関する研究を推進するために Harvey と提携することに興奮しています。今後の研究では、検証器の微調整とその大規模な事後トレーニングおよび評価実行への影響について研究することを楽しみにしています。

法務エージェント向けの効率的な検証器の設計

背景や根拠まで確認しますか？

調べる

選ぶ

サイト