Best-of-N の N¶

このダイヤルは何か¶

Best-of-NのNは、同じ入力に対してLLMに何個の候補を生成させ、最良のものを選ぶかを制御するダイヤルです。N=1は単一の生成結果をそのまま使うことを意味し、N=3なら3つの候補を生成してJudge（評価器）が最も品質の高いものを選びます。

LLMの出力は確率的（F3）であり、同じプロンプトでも実行のたびに品質が変動します。ある回は素晴らしい回答を返し、次の回は重要な情報を見落とすということが普通に起きます。単一生成（N=1）ではこの「ガチャ」の結果をそのまま受け入れるしかありませんが、複数候補を生成すれば確率的なばらつきの中から最良を選ぶことで、期待品質を引き上げることができます。

ただし、NをN倍すればコストもN倍になります。候補生成だけでなく、各候補を評価するJudgeのコストも加算されるため、実質的なコストはN+1倍（N候補＋1Judge）〜2N倍（N候補＋NJudge）になります。このため、Best-of-Nは全リクエストに適用するものではなく、[request_value] と [failure_cost] が高い重要な経路に限定して適用します。

効かなすぎる害 ⇔ 効きすぎる害¶

効かなすぎる害（N=1に固定）¶

N=1（単一生成）では、LLMの確率的なばらつきをそのまま受け入れることになります。

高リスクな判断（契約書の条項生成、医療情報の要約、法的助言の根拠付け）で、たまたま品質の低い出力が返り、それがそのまま最終結果として使われます
ハルシネーションを含む出力が、Judge による検証を経ずに下流に流れます。単一生成ではハルシネーションの発生を確率的に排除する手段がありません
温度が低い（0.0〜0.3）場合、N=1でも安定しますが、温度を上げて多様な出力を得たい場面（ブレインストーミング、創造的タスク）では品質のばらつきが直接結果に反映されます
回答の信頼性に対する定量的な裏付けがなく、「このN=1の出力がどの程度信頼できるか」を客観的に判断できません

効きすぎる害（Nが大きすぎる）¶

Nを大きくしすぎると、コストとレイテンシが急膨張します。

N倍のコスト — N=5で大型モデルを使うと、1リクエストあたりのコストが5倍以上になります。1リクエスト$1のタスクが$5以上に膨れ、月間コストが予算を大幅に超過します
収穫逓減 — N=1→N=3での品質向上と、N=3→N=5での品質向上を比較すると、後者の改善幅は明らかに小さいです。概ねN=3でエラー率が1/3〜1/5に低下するとの報告がありますが、N=5以上での追加効果は限定的です
レイテンシ — 候補生成を直列に行うとN倍のレイテンシがかかります。並列化すればウォールクロック時間は1回分に近づきますが、並列リクエストがプロバイダのレート制限に引っかかるリスクが高まります
Judgeの負荷 — N個の候補を全部評価するJudgeのコストも無視できません。候補が長文の場合、Judge自体のトークン消費が候補生成に匹敵することもあります

決め方¶

このダイヤルは主に [request_value] で決めます。1リクエストの生み出す価値がN倍のコストを正当化できるかが判断基準です。

経済合理性で判断する¶

Best-of-Nの追加コスト（概ねN-1回分の生成コスト＋Judge評価コスト）が、品質向上による価値（エラー削減、手戻り防止、信頼性向上）に見合うかで判断します。

1リクエストが$100の売上を生む → N=3のコスト増（$2→$6）は十分に正当化できます
1リクエストが$0.01の価値 → N=3のコスト増は経済的に成立しません

リスクの高さで判断する¶

[failure_cost] が高い経路（金融レポート、医療文書、法的判断の根拠）では、コスト増加よりもエラー削減の方が価値があるため、N=3〜5を適用する経済合理性があります。逆に [failure_cost] が低い経路（社内チャットの補助、メモの整理）では、N=1で十分です。

Judgeの設計¶

Best-of-Nの効果はJudgeの品質に大きく依存します。Judgeが候補の品質差を正しく見分けられなければ、N個生成しても最良を選べません。

[failure_cost] が低い場合 → 同モデルの別プロンプトによるself-reflectionでも一定の効果があります
[failure_cost] が中程度の場合 → 別モデルによるJudgeを推奨します
[failure_cost] が高い場合 → 決定論的コード（正規表現、データベース照合、計算検証）＋別モデルの二重検証を推奨します

目安値（出発点）¶

シナリオ	N	補足
一般的なリクエスト（低〜中リスク）	1	Judgeのみ（生成1＋検証1）で十分
高 `[request_value]`・高 `[failure_cost]`	3〜5	概ねN=3で品質が有意に向上する
最高リスク（金融・医療・法務の最終出力）	3〜5 + 多数決	多数決（合意率のチェック）を組み合わせる
創造的タスク（高温度での生成）	3〜5	多様な候補から最良を選ぶ価値が高い

N>5は収穫逓減が顕著であり、推奨しません。N=5で品質が十分でない場合は、Nを増やすよりもプロンプトの改善やJudgeの精度向上に投資する方が効果的です。

候補生成時のtemperatureの目安：

構造化出力（JSONなど）：0.0〜0.3
対話・要約：0.5〜0.7
創作・ブレインストーミング：0.8以上

温度を上げるほど候補の多様性が増し、Best-of-Nの恩恵が大きくなります。温度0.0ではN個の候補がほぼ同一になるため、Best-of-Nの意味がありません。

具体的なシナリオ¶

シナリオ1：契約書条項の生成¶

法務部門が使うエージェントで、契約書の特定条項を生成するタスクです。[failure_cost] が極めて高く、不正確な条項が法的リスクに直結します。

N=3（3つの候補を生成）
temperature=0.3〜0.5（構造化された法的文章のため低〜中温度）
Judge: 別モデル（大型）＋法的チェックリストの決定論的検証
評価基準: 法的正確性、条項の完全性、既存条項との整合性
全候補不合格時: 法務担当者にエスカレーション

シナリオ2：マーケティングコピーの生成¶

広告やSNS投稿のコピーを生成するタスクです。創造性が求められ、温度を上げて多様な候補を生成する価値があります。

N=5（5つの候補を生成し、最も魅力的なものを選ぶ）
temperature=0.8〜1.0（創造的なバリエーションを期待）
Judge: 同モデルの別プロンプト（「どのコピーが最も効果的か」を評価）＋ブランドガイドライン適合チェック（決定論的）
評価基準: 訴求力、ブランドトーンとの整合性、文字数制約
全候補不合格時: 別の切り口のプロンプトで再生成

このシナリオではNを上げることの効果が大きいです。温度が高いため候補間の多様性が大きく、Best-of-Nの恩恵を最大限に受けられます。

シナリオ3：翻訳タスク¶

技術文書の翻訳です。[failure_cost] は中程度で、多少の不自然さは許容されますが、技術的な正確性は必要です。

N=1（Judge のみ）
Judge: 別モデルによる品質チェック（原文との対照、技術用語の一貫性）
判定: Judgeのスコアが閾値以上なら採用、未満なら1回再生成
全候補不合格時: 人間の翻訳者にエスカレーション

翻訳タスクではN>1の効果が限定的です（温度が低い構造化タスクのため候補間の差が小さい）。代わりにJudgeによる品質チェックに投資する方がコスト効率が高いです。

シナリオ4：コスト制約下でのN動的調整¶

予算残量に応じてNを動的に変える戦略です。A7 予算カスケードと組み合わせます。

予算の80%以上が残っている場合: N=3
予算の50〜80%が残っている場合: N=2
予算が50%以下の場合: N=1（Judge のみ）

これにより、セッション全体の予算内でBest-of-Nの品質向上効果を最大限に活用しつつ、予算枯渇を防ぎます。

実践的なアドバイス¶

全リクエストにBest-of-Nを適用しないでください。N=1とN>1を経路ごとに切り替えるルーティング機構を設け、高リスク経路のみNを上げます。これにより全体コストを抑えつつ、重要な場面での品質を向上させます。
候補生成は可能な限り並列化してください。直列にN回呼び出すとレイテンシがN倍になりますが、並列呼び出しならウォールクロック時間は概ね1回分に収まります。ただしプロバイダのレート制限に注意が必要です。
Judgeの評価基準（ルーブリック）を明示的に定義してください。「どちらが良いか」だけでは曖昧すぎます。事実性、論理的整合性、完全性、スキーマ適合など、測定可能な軸とスコアリング基準を与えます。E4 検証済み構造化出力でJudgeの出力自体を構造化すると、集約ロジックを決定論的に実装できます。
全候補が不合格のケースを設計してください。Judgeが全候補を棄却した場合のフォールバック（人間エスカレーション、別モデルでの再生成、リトライ上限）を事前に決めておきます。フォールバックなしだと「全滅で何も返せない」という最悪の事態が発生します。
Judge自体の精度を評価してください。Judgeが間違った候補を「最良」と判定するリスクがあります。G4 評価ハーネスでJudgeの偽陽性率・偽陰性率を定量評価し、Judgeが信頼できることを確認した上でBest-of-Nを本番投入します。