AI21、検証モデルによる検索精度向上と低コスト化を報告
本文の状態
日本語全文を表示中
詳細モードで約16分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
AI21 Engineering
AI21 Engineering は、大規模生成モデルの購入ではなく、独立した検証器（verifier）を追加することでエージェント検索の精度を向上させる手法を発表し、8B モデルの訓練済み検証器が SOTA を上回る結果を示した。
AI深層分析を開く2026年8月19日 21:33
AI深層分析
キーポイント
生成より選択がボトルネックである事実
安価なエージェントモデルでも正解を生成する確率は高いが、それを適切に選定できないことが精度向上の阻害要因となっている。
独立した検証器による性能向上
候補回答を再調査して誤りを拒否する独立した検証器（verifier）を導入することで、既存のアーキテクチャの性能が劇的に向上する。
低コストで高効率な検証システムの実現
8B パラメータの検証器を独自に訓練すれば、コストはほぼゼロとなり、あらゆる生成モデルプールや検索ツールと互換性を持つ。
生成より検証の難易度が低い
複雑な検索と合成が必要な質問に対し、特定の主張を検証して正誤を判断する方がはるかに容易である。
多数決投票の限界
多くのモデルが同じ誤った回答に自信を持って投票する場合、多数決は誤りをフィルタリングできずむしろ確定させてしまう。
重要な引用
The problem is that it didn't pick it.
So the binding constraint on agentic search is selection, not generation.
Adding an independent verifier that re-researches each candidate and vetoes the wrong ones beats published SOTA on FACTS-Search.
Verifying a proposed answer is far narrower: research one claim and rule on it.
編集コメントを表示
編集コメント
生成モデルの性能競争が激化する中、いかにして既存リソースを最大限に活用するかという視点の転換は非常に示唆に富む。特に低コストな検証器で SOTA を達成した事実は、実運用における導入障壁を大幅に下げる可能性を秘めている。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
要点
アジェンシー・サーチにおいて、安価なモデルは正解を導き出すことはできても、それを最終的に選択できないケースが頻発します。多数決投票では、誤った回答が多数派になった場合、その誤りを覆すことができません。そこで各候補に対して独立した検証者が再調査を行い、誤ったものを却下する仕組みを導入すると、FACTS-Search ベンチマークで既存の最良結果（SOTA）を突破できます。さらに、独自に 8B パラメータ規模の検証者を訓練すれば、コストはほぼゼロとなり、あらゆる生成モデルプールと互換性を持ち、新しいベンチマークや検索ツールにも汎化します。
図 1: 生成モデルのプールは固定され、検証者のみが変更されます。多数決投票のみではスコアが 83.3 に留まり、既存の SOTA を下回ります。未学習の Qwen3-8B 検証者を使用すると 84.8 となり、依然として SOTA に届きません。Claude Opus の検証者を導入するとスコアは 10.1 ポイント向上し、コストは$2.94 かかりますが、我々が訓練した 8B パラメータ規模の検証者を使用すれば、検証者を全く使わない場合と比べてわずか 1 セント増で 92.9 を達成できます。
アジェンシー・システムの精度を高めるデフォルトの方法は、より高性能な生成モデル（フロンティアモデル）を購入することです。確かに効果はありますが、これは利用可能な選択肢の中で最も高価な手段です。
本稿では異なる視点から論じます。重要なのは「どのモデルを使うか」ではなく、「どのようにモデルを実行するか」です。以下のシステムは、あらゆる AI アーキテクチャに不可欠なコンポーネントである「検証者（verifier）」を追加します。このコンポーネントにより、フロンティアモデルのアンサンブルであっても安価なオープンソースモデルであっても、すべてのアーキテクチャのパフォーマンスが向上します。
なぜアジェンシー・サーチには検証者が必要なのか
あなたの安価なエージェントはすでに正解を見つけ出している可能性が高いのです。問題は、それを最終的に選択できていない点にあります。
モデルの実行結果は確定的ではありません。同じエージェント、同じ質問でも、ある試行では失敗し、別の試行では成功します。テストしたすべての生成器において、pass@k（複数回試行時の成功率）は単一ショットの精度（pass@1）よりも大幅に高い値を示しています。正解が回答候補群に含まれていることは珍しくなく、単に選ばれなかっただけです。つまり、エージェントによる検索における最大のボトルネックは生成ではなく、選択にあります。
選択が可能なのは、検証の方が生成より容易だからです（少なくともエージェントによる検索 QA においては）。*「『Little Sister』が含まれるスティーヴ・アール盤で、『Johnny Come Lately』を演奏したバンドはどれか？」*という問いに答えるには、一連の検索、行き詰まり、そして統合が必要です。一方、提案された回答を検証するのははるかに狭い範囲に限定されます：一つの主張を調査し、それに対して判断を下すだけです。
ではなぜ、アンサンブル学習を使う際に単純な多数決を採用しないのでしょうか？ 多数決では、広まっている誤った回答を覆すことはできないからです。候補の半分が同じ誤ったエンティティを自信を持って繰り返している場合、多数決はエラーをフィルタリングするのではなく、その誤りを認定することになります。安価なプールでは、正解が相対的に少ないため、このように失敗することが最も多くなります。
Figure 2: FACTS-Search の質問に対する 3 つの段階からなるループ。生成器が k 個の候補を出力し、検証器はそれぞれを独立して調査して判定を下します。アグリゲーターは検証済みの回答のみを対象に投票を行います。ここでは多数派の答えが残りますが、このループの真価が発揮されるのは、多数派の答えが生き残らないケースです。
検証は機能する
まずはコストを無視し、利用可能な最高の検証器を実行してみましょう。
本稿で扱うのは Google DeepMind が提供する「FACTS-Search」ベンチマークです。これはウェブ検索を必要とする難易度の高い多段推論型の事実確認問題セットです。本記事に登場するすべてのモデル（生成器・検証器のいずれも）は、同じ Brave Search API を利用しているため、測定される性能差はツールの違いではなく、モデル自体のスキルによるものです。
閉鎖型と開放型の複数のモデルをアンサンブル化し（Claude Haiku, Sonnet, Opus および Qwen3-Coder-30B-A3B）、k=4 で試した結果、単純な多数決投票では 83.3 のスコアでしたが、その上に Claude Opus を検証器として追加すると 93.4 まで向上しました。これは既存の最先端である 89.4（GPT-5.6 Sol）を大きく上回る結果です。この事実は Figure 1 でも確認できます。
低コスト側でこそ余地は大きい
最先端モデル同士を比較する実験でも、このメカニズムの有効性は証明されました。しかし実務において重要なのは「安価な生成器」の領域であり、ここでは性能向上の余地が縮小するどころかむしろ拡大します。ノイズの多い候補群であっても正解は必ず含まれており、単に数が少ないだけです。まさにその「少数派の中に正解がある」という状況こそが、検証を行う最大のメリットとなります。
Qwen3-14B と Qwen3-Coder-30B-A3B（k=4）というオープンソースモデルのプールだけで投票させた場合、正答率は 60.1% に留まります。しかし、同じ候補群に対して Claude Opus を検証者として投入すると、スコアは80.4%に跳ね上がり、質問あたりのコストは1.76 ドルになります。プール内にはすでに 20 ポイント分の正解が眠っており、それを引き出すのに十分な性能を持つ検証者が待っている状態です。
検証者がコストの大部分を占めるため、私たちは独自に訓練しました
最先端モデルによる検証者（frontier verifier）は、各候補に対して完全なウェブ検索ループを実行します。最適な設定では、質問あたり 16 ループ、生成器の数とサンプル数（k）を乗じた計算量になります。これにかかるコストは、検証対象となるすべてのものを生成するコストよりも高くなります。93.4% の結果を出すための実行コストは質問あたり 4.26 ドルですが、その大部分が検証者のコストです。
明らかな解決策は、小規模なオープンソースの検証モデル（verifier）ですが、これだけでは不十分です。標準的な Qwen3-8B を検証器として使用すると、安価なプールでのスコアは 60.1 から 62.5 にわずかに向上するのみです。一方、同じ候補回答に対して Opus は +20.3 の改善を示しており、両者の差は実に 18 ポイントに及びます。この大きなギャップが示すのは、検証能力というスキルはパラメータの規模が大きくなるだけで自動的に付随するものではない、という訓練上の課題です。
学習プロセス
検証器は、与えられた質問と候補回答を受け取ると、独自で Brave-search を用いた ReAct ループを実行し、最終的な判定（verdict）を出力します。報酬は正解ラベルとの完全一致（binary exact match）に基づいて算出されるため、外部の報酬モデルに依存せず、完全に客観的に検証可能です。
学習データは、生成器によるロールアウトから得られた約 6,000 組の triple（質問、回答、VALID/NOT_VALID のラベル）で構成されています。これらは重複を除去し、クラスバランスを整えた上で、質問単位でトレーニングセットとテストセットに分割されます。
学習手法は SFT（Supervised Fine-Tuning）に続く RL（Reinforcement Learning）の組み合わせです。これは DeepSeek-R1 と同じ理由によるものです。冷たい状態（cold start）から直接 RL を開始しても、探索できる有能な方策が存在しないため失敗します。
検証タスク特有の失敗モードが 2 つあります。まず、RL のみでは報酬ハッキングが発生し、クラス不均衡を悪化させます。具体的には、ツール使用率が 9 ステップで 94% から 0% に急落してしまいます。データバランスを整えることでこの近道は塞げますが、根本的な問題は解決しません。方策が一つの限られた探索行動に収束し、そこから脱出できなくなるため、学習開始地点のどこかで検索品質が頭打ちになってしまいます。
一方、SFT のみでは検索スキルは習得できますが、判定精度が低下します。なぜなら、模倣学習では損失関数が長いトジェクトリ（trajectory）内のすべてのトークンに分散してしまう一方で、検証信号はたった 1 つのトークンのみに依存しているからです。
これらを組み合わせることで、ツール使用率は高い水準を維持しつつ適応性も生まれ、方策が崩壊することなく判定精度も鋭くなります。
これらを検証するには、2 つの条件が必要です。各チェックポイントで完全なループを再実行するのは遅すぎるため、検証器のバリアントは事前に生成されたロールアウトの固定プールに対してオフラインで評価されます。候補は不変であり、評価者（ジャッジ）のみが変化します。また、指標は質問ごとに計算した後に平均化する必要があります。なぜなら、ロールアウトレベルの判定指標（精度、適合率、再現率、F1 スコアなど）はシステム全体の性能が悪化している間も、常に変化し続けていたからです。
Figure 4 に示す 4 つの量を追跡します。pass@1 と pass@k は、検証器なしでのランダムな選択とオラクル上限（最良の結果）を表し、pass@1(v) と pass@k(v) は検証済み候補のみに対する同じ 2 つの指標です。
3 つのギャップが責任所在を特定します。そのうち 2 つは検証器に、残りの 1 つは集約アルゴリズム（アグリゲータ）に帰属します。
- *Verification lift := pass@1(v) − pass@1* は検証器の適合率です。これを最大化する必要があります。
- *Aggregator headroom := pass@k(v) − pass@1(v)* は、検証済み候補からさらに回復可能な余地であり、これはより賢いアグリゲータが実現できる領域ですが、ここでは別のトピックとして扱いません。
- *The recall cap := pass@k − pass@k(v)* は、解けるはずの質問のうち、検証器がすべての正答を拒否した割合です。これを最小化する必要があります。
*Figure 4: 各質問ごとに計算された後、平均化される代理指標。健全な検証器は、これらがこの順序でネストされるように保ちます。
Results*
100 問の公開テストサンプルと公式評価結果です。コスト計算は、一般的な推論プラットフォームの価格を想定しています。
SOTA（State-of-the-Art）構成のコンポーネントを一つ入れ替えるだけで劇的な変化が生まれます。Claude Opus を検証する代わりに、自社で訓練した 8B モデルに置き換えると、92.9というスコアを1.34 ドルで達成できます。これは品質が半分ポイント低下しただけで、コストは3.2 倍も削減されたことになります。それでもなお、公開されている SOTA を大きく上回る結果です。システム内で最も高価だったコンポーネントが、最安級のコンポーネントへと変貌したのです。
さらに、プロプライエタリ（独占的）なモデルを完全に排除することも可能です。Qwen3-14B と Qwen3-Coder-30B-A3B を k=4 で組み合わせ、その上に自社訓練の検証器を載せた場合、1 問あたり 0.017 ドルでスコア77.0を記録します。これは同じデータセットでの多数決投票（60.1）や、Opus 検証器を使用した場合（80.4）と比較して顕著な成果です。生成モデルのコストはほぼゼロに等しいため、システム全体のコスト構造において検証器が主役となります。この構成は、単一の Claude Haiku 呼び出し（スコア 76.3、コスト 0.043 ドル）を2.5 倍の低コストで上回り、単一の Claude Sonnet 呼び出し（スコア 81.2、コスト 0.1 ドル）にも4.2 ポイント差をつけながら、コストは6 分の 1という圧倒的な効率を実現します。
一般化能力も備えている
私たちはあえて一つのベンチマークと一つのツールのみで訓練を行いました。その理由は、実務では顧客が独自の環境を持ってやってくるケースが多いためです。BrowseComp-Plusベンチマークは、この状況をシミュレートするために設計されています。タスクの形状は同じですが、エージェントがオープンウェブを検索するのではなく、固定されたコーパスから情報を取得するという点で、両方の要素を同時に変化させています。
検証器（verifier）をそのまま転用すると、下流の投票精度は 39% から 51% に向上します。ただし、その代償として再現率（recall）が低下し、解けるはずの問題の 27% ですべての候補を却下してしまいます。その後、約 85 問の保持領域（held-out domain）の問題に対してわずか 15 ステップの微調整（SFT）を行うと、この欠陥は 27% から 4% に縮小し、下流の性能は69%まで引き上げられます。
Figure 5: FACTS で訓練された検証器を、保持領域のベンチマークかつ検索ツールである BrowseComp-Plus に転用した結果。展開予算（rollout budget）ごとの精度と再現率の変化を示します。精度はそのまま転用可能で（中央パネル）、k=32 の時点で 39% から 51% に向上しています。一方、再現率は改善されず、検証器が解けるはずの問題の 27% で候補プールを空にしてしまいます（右パネル）。しかし、85 問の保持領域データに対して約 15 ステップの SFT を行うことで、この欠陥は 4% にまで削減され、実システムのパフォーマンスは 69% に引き上げられます。
検証器を追加しても、あらゆる展開予算においてシステムの費用対効果への影響は最大でも 5% です。ここでは最良性能（SOTA）を主張するつもりはありません。なぜなら生成モデルは単一のオープンソースモデルだからです。ここで重要なのは「レシピ」です。精度の一般化は無料で実現でき、再現率のギャップを埋めるコストも極めて低いのです。
まとめ
エージェント型検索において、正解はすでに候補プールに含まれていることがほとんどです。しかし、多数決投票ではそれを引き出すことはできません。なぜなら、多数決は「人気のある誤答」を覆す力を持たないからです。ボトルネックは「選別」にあります。
独立した「調査と拒否（ベリファイ）」を行う検証モデルが、FACTS-Search ベンチマークで 83.3 から 93.4 へとスコアを引き上げました。これは既存の最上位性能（SOTA）を凌駕する結果です。ただし、このシステムにおける最大のボトルネックはコストでした。
標準的な 8B モデルでは、その性能向上のほとんどを再現できません。しかし、訓練済みであれば、同じ 8B モデルで 92.9 のスコアを達成可能です（コストは$1.34）。これは Claude Opus ベリファイヤーと半ポイント差以内でありながら、コストは約 3 分の 1 で済みます。さらに、プロプライエタリなモデルを一切使わずに、$0.017 という驚異的な低コストで 77.0 のスコアも達成できます。
このアプローチはベンチマークやツールの種類を超えて一般化します。精度の転移は無料で行え、少量の適応学習で再現率（リコール）の格差を埋めつつ、さらに精度を高めることができます。
*注意*: 両方のベンチマークは 100 問のサンプルに基づいて評価されています。訓練ラベルには自動採点ノイズが含まれており、両方の SFT（教師あり微調整）段階ではクローズドソースモデルからの知識蒸留が行われています。また、検証プロセスには追加のレイテンシが発生します。ただし、この遅延は制限可能です。生成ロールアウトに比べて検証のトランザクションは短く、取得した文書をコンテキストとして引きずる生成プロセスとは対照的です。さらにループ間で状態を共有しないため、16 回の検証にかかる時間は、実質的に 1 回の処理時間と同じです。
原文を表示
In brief
*On agentic search, cheap models usually produce a correct answer and then fail to pick it. Majority voting cannot fix that, because it cannot overturn a popular wrong answer. Adding an independent verifier that re-researches each candidate and vetoes the wrong ones beats published SOTA on FACTS-Search, and once you train your own 8B verifier it costs almost nothing, works with any generator pool, and generalizes to a new benchmark and retrieval tool.*
The default way to make an agentic system more accurate is to buy a better generator – a frontier model. It works, but it is the most expensive option available.
This post is making a different argument: how you run your models matters more than which model you run. The system below adds an important component to any AI architecture: a verifier. This component increases the performance of every architecture, whether it’s an ensemble of frontier models or cheap open source models.
Why agentic search needs a verifier
Your cheap agent probably already found the right answer. The problem is that it didn’t pick it.
Model runs are not deterministic. The same agent, same question, fails on one attempt and succeeds on the next. Across every generator we tested, pass@k sits far above single-shot accuracy (pass@1): correct answers are routinely present in the pool and simply not selected. So the binding constraint on agentic search is selection, not generation.
Selection is tractable because checking is easier than generating (at least for agentic search QA). Answering *“Which band played ‘Johnny Come Lately’ on the Steve Earle album that includes ‘Little Sister’?”* takes a chain of searches, dead ends, and synthesis. Verifying a proposed answer is far narrower: research one claim and rule on it.
So why not just take the majority vote when using an ensemble? Because voting cannot overturn a popular wrong answer. When half the pool confidently repeats the same wrong entity, voting does not filter the error, it certifies it. Cheap pools fail this way most, because correct answers are less frequent.
Verification works
First, ignore cost and run the best verifier available.
We work on FACTS-Search, Google DeepMind’s benchmark of hard multi-hop factual questions that require web search to answer. Every model in this post, generator or verifier, uses the same Brave Search API, so measured differences are model skill and not tooling.
Generators ensemble of closed-source and open-source models (Claude Haiku, Sonnet, Opus, Qwen3-Coder-30B-A3B at k=4) scores 83.3 under plain majority voting and 93.4 with a Claude Opus verifier on top, past the published state of the art of 89.4 (GPT-5.6 Sol), as can be seen in Figure 1.
The headroom is larger at the cheap end
Frontier-on-frontier proves the mechanism. The regime that matters in practice is cheap generators, and there the headroom grows rather than shrinks: a noisier pool still surfaces correct answers, they are just outnumbered, which is exactly when identifying them pays.
Our all-open-source pool (Qwen3-14B and Qwen3-Coder-30B-A3B at k=4) votes to 60.1. Put a Claude Opus verifier on those same candidates and it scores 80.4 at $1.76 per question. Twenty points already sitting in the pool, waiting for a verifier good enough to claim them.
The verifier is the expensive part, so we trained our own
A frontier verifier runs a full web-research loop on every candidate: k samples times the number of generators, sixteen loops per question in our best configuration. That costs more than generating everything it checks: the 93.4 result runs $4.26 per question, most of it the verifier.
The obvious fix is a small open-source verifier, and it does not work. A stock Qwen3-8B verifier moves the cheap pool from 60.1 to 62.5. Plus 2.4 points against Opus’s plus 20.3 on the same candidates. That 18-point gap is the training problem: the verification skill does not come free with the parameters.
Training
Given a question and a candidate answer, the verifier runs its own Brave-search ReAct loop and emits one verdict. The reward is a binary exact match against the ground-truth label, so it is fully verifiable, no reward model. Training data is about 6K (question, answer, VALID/NOT_VALID) triples from generator rollouts, deduplicated, class-balanced, and split at the question level.
The recipe is SFT then RL, for the same reason as DeepSeek-R1: RL from a cold start has no competent policy to explore from. Two failure modes here are specific to verification. RL alone reward-hacks the class imbalance, with tool-use rate falling from 94% to 0% in nine steps. Balancing the data closes that shortcut but not the underlying problem: the policy settles into one narrow search behavior and cannot climb out of it, so search quality plateaus wherever the cold start happens to land. SFT alone teaches the search skill and dilutes the verdict, because imitation spreads its loss over every token of a long trajectory while the verification signal lives in one token. Composed, tool use stays high and becomes adaptive, and the verdict sharpens without the policy collapsing.
Measuring any of this needs two things. Re-running the full loop for every checkpoint is too slow, so verifier variants are scored offline against a fixed pool of pre-generated rollouts: the candidates never change, only the judge does. And metrics have to be computed per question and then averaged, because rollout-level verdict metrics (accuracy, precision, recall, F1) routinely improved while the system got worse. We track four quantities (Figure 4): pass@1 and pass@k, one random pick and the oracle ceiling with no verifier, and pass@1(v) and pass@k(v), the same two over verified candidates only. Three gaps assign blame – two to the verifier, one to the aggregator:
- Verification lift := pass@1(v) − pass@1 is the verifier’s precision: maximize it.
- Aggregator headroom := pass@k(v) − pass@1(v) is what a smarter aggregator could still recover from verified candidates – a separate thread we don’t pursue here.
- The recall cap := pass@k − pass@k(v) is the fraction of solvable questionswhere the verifier rejected every correct answer: minimize it.
結果
100-question public test sample, official grading. Costs assume the prices of common serving platforms.
Swap one component in the SOTA configuration. Replacing the Claude Opus verifier with our trained 8B verifier holds 92.9 at $1.34: half a point of quality for 3.2x lower cost, still way above published SOTA. The most expensive component in the system became one of the cheapest.
Remove proprietary models entirely. Qwen3-14B and Qwen3-Coder-30B-A3B at k=4 with our trained verifier on top scores 77.0 at $0.017 per question, against 60.1 majority voting on the same pool and 80.4 for the Opus verifier on it. The generators are nearly free, so the verifier is the system. It beats a single Claude Haiku call (76.3 at $0.043) at 2.5x lower cost and lands within 4.2 points of a single Claude Sonnet call (81.2 at $0.1) at 6x lower cost.
It generalizes
We trained on one benchmark and one tool on purpose, because the practical case is a customer arriving with their own setup. The BrowseComp-Plus benchmark changes both at once: same task shape, but the agent retrieves from a fixed corpus instead of searching the open web.
The verifier transfers out of the box and lifts the downstream vote from 39% to 51%. What it loses is recall: on 27% of solvable questions it rejects every candidate and forfeits the question. A final tiny SFT on about 85 held-out-domain questions, roughly 15 optimizer steps, collapses that gap from 27% to 4% and pushes downstream to 69%.
verification adds at most 5% to system cost at every rollout budget. We do not claim SOTA here, since the generator is a single open-source model. The claim is the recipe: precision generalizes for free, and the recall gap is cheap to close.
まとめ
- On agentic search, correct answers are usually already in the pool. Majority voting cannot surface them, because it cannot overturn a popular wrong answer. The bottleneck is selection.
- An independent research-and-veto verifier took a frontier pool from 83.3 to 93.4 on FACTS-Search, past published SOTA. It was also the dominant cost of that system.
- A stock 8B recovers almost none of that lift. Trained, the same 8B holds 92.9 at $1.34, within half a point of the Claude Opus verifier at 3.2x lower cost, and delivers 77.0 at $0.017 with no proprietary model in the stack.
- It generalizes across benchmark and tool: precision transfers for free, and a small adaptation closes the recall gap while lifting precision further.
*Caveats: both benchmarks are evaluated on 100-question samples, training labels inherit automated-grader noise, both SFT stages distill from closed-source models, and verification adds a round of latency. That last one is bounded: verification trajectories are short next to generation rollouts, which drag retrieved documents through context, and the loops share no state, so sixteen verifications cost the wall clock of one.*
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み