この記事で分かること／分からないこと
- 分かること: 複数の候補・複数の評価者を突き合わせて矛盾を見つける設計の考え方
- 分かること: 自社実装が持つ、盲検2モデル投票とベースラインとのA/B比較の仕組み
- 分からないこと: n=12のA/B結果からどちらの方式が優れているかという結論(標本数不足で判断できない)
- 分からないこと: 3つ以上の候補を突き合わせた場合の挙動
「複数候補の突合」という設計の考え方
一つの回答だけを見て正しいかどうかを判定するのではなく、複数の候補(複数の検索結果、複数の生成、あるいは複数の評価者)を並べて食い違いを探すという設計がある。1つの候補では気づけない誤りも、もう一つの候補と比べれば、どちらかが違うという形で浮かび上がることがある。
自社実装：判定を2モデルの盲検投票で行う
編集部が検証に使っている自社RAG基盤のLayer2は、Layer1の機械照合で幻覚候補として抽出された応答について、別モデルによる盲検で最終判定を行う。実測では、この盲検にsonnetとopusの2モデルがそれぞれ独立に12件を投票する構成が取られている(出所: 検証レポート、確認日2026-09-06)。1モデルの判定だけに頼らず、独立した2モデルの一致・不一致を見られる構成になっている。
自社方式とベースラインを突き合わせるA/B構造
Layer2は、自社方式と汎用的なベースラインRAG(実体: services/verifier/src/baseline-rag.ts)を並べて盲検で比較するA/B構造も持つ。ベースラインは意図的に幻覚を防ぐ指示を課していない素朴な生成であり、これと自社方式を並べることで、同じ質問に対する2つの候補を突き合わせられる。
n=12のA/B集計は、優劣の証拠にはならない
実測のA/B集計は、正確さ・親切さ・自然さ・安全性の4軸で行われ、いずれの軸でも引き分けが最多という結果だった(出所: 検証レポート、確認日2026-09-06)。ここで自社方式が優勢に見える軸があったとしても、標本数はわずか12件である。n=12で0件を観測した場合の真の発生率の95%上限が22.1%に達することからも分かるとおり、この規模の集計から、どちらが優れているかを断定することはできない。言えるのは、この標本数では明確な差が見えなかった、というところまでである。
人手の正解データが無いという前提
このA/B判定・盲検投票は、人手によるチューニングを経ていない(humanTuningCount 0)。つまり、そもそも人手の正解ラベルが存在しない状態で、モデル同士の判定を突き合わせている。複数候補を突き合わせる設計は、単独の判定より頑健に見えるが、比較の基準そのものが人手の正解と接続されていない場合、突き合わせても、モデル同士が似た判断をしたかどうかしか分からない点には注意が必要である。
複数候補の突合は、出典提示や再検索の設計と組み合わせて使うものである。出典が示せない場合の扱いは出典提示の限界の記事、引けなかった時に諦めるかどうかの判断は再検索と諦めの記事で扱っている。幻覚率という指標の読み方はこちらの記事を参照してほしい。RAGの評価設計について相談したい方は、お問い合わせから編集部までご連絡いただきたい。
よくある質問
Q1. 複数候補を突き合わせるとは具体的に何をすることか
一つの回答だけで判定せず、複数の検索結果・複数の生成・複数の評価者を並べて、食い違いがないかを確認することを指す。
Q2. 自社実装ではどのように複数候補を突き合わせているか
Layer2の盲検投票ではsonnetとopusの2モデルが独立に12件を判定する。加えて、自社方式とベースラインRAGを並べて比較するA/B構造も持つ(確認日2026-09-06)。
Q3. n=12のA/B集計から自社方式が優れているとは言えるか
言えない。いずれの軸でも引き分けが最多であり、標本数がわずか12件のため、差が見えなかった以上のことは主張できない。
Q4. このA/B判定は人手の正解データに基づいているか
基づいていない。人手によるチューニングは0件(humanTuningCount 0)であり、人手の正解ラベル自体が存在しない状態でモデル同士の判定を突き合わせている。
- ハブ記事: RAGサービス比較15選
- 関連記事: RAGの幻覚率をどう測るか
- 関連記事: 人間のゲートをどこに置くか
- 関連記事: 誤ると取り返しがつかない領域の扱い