RAG×Jevハイブリッド設計
3ホップ実行と弱点の回避策

第2章ではCorpus2Skillの「精度は高いが、遅くて高い」というジレンマを、第3章では判断だけを返すJevの性質を見てきました。この章では両者を1本の実行パイプラインにまとめ、実際のシステムとして動かすための設計を示します。「RAGにJevを足して速くしたい」と考えている方にとって、Jevをどこに置けば最も効くのかという問いへの、本特集としての答えになります。

結論を先に書くと、Jevはベクトル検索の結果を並べ替える役よりも、スキルツリーの分岐を選ぶ役に置いたときに最も力を発揮します。分岐の選択は「有限の選択肢から1つを選ぶ」作業であり、Jevが得意とする判断そのものだからです。

3ホップで動く実行パイプライン

ユーザーが質問を送ってから回答が表示されるまでの処理を、3つのホップに分けます。最初の2ホップは判断の工程なのでJevが担い、最後の1ホップだけを文章を書ける生成LLMに任せます。人間の思考になぞらえれば、System 1（直感的な判断）で道を選び、System 2（熟考）で文章を書く分業です。

Hop 1：ゲートキーピングと第1層ルーティング

たとえば「インボイスの再発行手順は？」という質問が届いたとします。システムはまずJevのchoiceで、事前にコンパイルした第1層の知識クラスタから参照先を選ばせます。Jevのchoiceは、ラベルと説明文の対応（criteria）を最大255個まで受け付け、選んだラベルに加えてconfidence（確信度）と選択肢ごとのprobabilities（確率）を返します。

同じリクエストに、緊急度を問うnoul（Yes/Noの確率を返す判定）も入れておきます。Jevは1回のリクエストに含めた複数の質問を並列に評価するため、問いを1つ足しても往復の回数は増えません。ここで「この質問は業務停止や期限切迫に関わるか」を同時に見ておけば、後段で有人窓口への通知を並走させる判断にそのまま使えます。

{
  "model": "jev-1.13.0",
  "state": { "query": "インボイスの再発行手順は？" },
  "questions": {
    "target_cluster": {
      "type": "choice",
      "instructions": "state.query に答えるために参照すべき知識クラスタを1つ選ぶ。",
      "criteria": {
        "billing": "請求・支払い・適格請求書（インボイス）の発行と再発行、返金。給与の支払いは含まない",
        "hr_payroll": "給与・賞与・源泉徴収・年末調整。取引先への支払いは含まない",
        "other": "上記のいずれにも当てはまらない質問、雑談、社外の一般知識"
      }
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "利用者は業務停止や期限切迫のため、至急の対応を求めている。"
    }
  }
}

返ってくるanswers.target_clusterにはchoice・confidence・probabilitiesが、answers.is_urgentにはnoul（Yesの確率）が入ります。文章を解析する必要がなく、型の決まった値をそのまま分岐に使えることが、生成LLMでルーティングする場合との大きな違いです。

Hop 2：確信度による分岐と文書の一括選別

Hop 2の前半は、Hop 1の確信度に応じて探索の範囲を決める工程です（詳しくは次節）。範囲が決まったら、対象クラスタのINDEXに載っている候補文書をすべて集め、「この質問に答えるには、この文書を参照する必要がある」というnoulを文書の数だけ並べて、1回のリクエストで判定させます。数十件の候補でも、生成LLMのように1件ずつ読ませる必要はありません。

注意したいのは入力の上限です。Jevは「state＋すべての質問」で64kトークン、「state＋最も長い質問」で32kトークンという上限を設けています。候補が数百件に及ぶ場合は、文書の要約を短く保ったうえで、バッチに分けて同時に送ります。

# 日本語は1文字≒1トークン以上と見て、安全側に文字数で見積もる
BUDGET_TOKENS = 48_000   # 上限64kに対し余裕を残す

def split_batches(query: str, candidates: dict[str, str]) -> list[dict[str, str]]:
    batches, current, used = [], {}, len(query) + 500
    for doc_id, summary in candidates.items():
        cost = len(summary) + 80   # 要約＋定型の指示文
        if current and used + cost > BUDGET_TOKENS:
            batches.append(current)
            current, used = {}, len(query) + 500
        current[doc_id] = summary
        used += cost
    if current:
        batches.append(current)
    return batches   # 各バッチを並列に /v1/decide へ送る

Hop 3：原文全文の取得と回答生成

Hop 2で抽出した上位数件のdoc_idをもとに、documents.jsonからチャンク分割されていない原文全文を取り出します。生成LLM（Claude Sonnet 4.6などの汎用モデル）には、ユーザーの質問と原文だけを渡し、回答の末尾に参照したdoc_idと文書名を出典として書かせます。探索の過程で読んだ要約は渡しません。要約の伝言ゲームで事実が歪むのを防ぎ、根拠を原文に限定するためです。

確信度で分岐させる設計

このアーキテクチャの要は、Jevの確信度を使って探索の範囲を変えることにあります。Corpus2Skill単体では、エージェントが枝を間違えたら親に戻ってやり直す「バックトラック」で回復していました。確実ですが、戻るたびに生成LLMの呼び出しが1回増え、待ち時間が延びます。RAG×Jevの構成では、迷いを確率として先に受け取れるので、戻る代わりに最初から複数の枝を同時に開くことができます。

高確信度：1つのクラスタへ直行する

確信度が十分に高ければ、選ばれたクラスタだけを開きます。候補文書が最も少なく、Hop 2の入力も最小で済むため、速度とコストの両面で最も有利な経路です。社内ヘルプデスクの問い合わせのように、話題の偏りが大きい用途では、この経路を通る質問が多数を占めると見込めます。

中確信度：投機的ファンアウトで並列探索する

ここがハイブリッド構成の肝です。「請求のクラスタかもしれないし、契約のクラスタかもしれない」とJevが迷った場合、順番に試すのではなく、probabilitiesが一定以上の上位クラスタ（最大3つ程度）の候補文書をまとめてHop 2の判定にかけます。バッチは同時に送れるので、開く枝が増えても待ち時間はほとんど延びません。増えるのはJevの入力トークンだけで、その単価は生成LLMより桁違いに安いため、取りこぼしを防ぐ保険として割に合います。

低確信度：生成LLMを動かす前に止める

どのクラスタの確率も低い、あるいはotherが選ばれた場合は、その時点で探索を打ち切ります。コーパスに答えがない質問に対して生成LLMを呼べば、費用がかかるうえに、根拠のない回答を作るリスクも高まります。「該当する社内資料が見つかりませんでした」という定型応答を返すか、問い合わせフォームや有人窓口に案内します。最も高価な工程を省けるこの分岐は、コスト削減の要でもあります。

{
  "model": "jev-1.13.0",
  "high_conf": 0.75,
  "min_conf": 0.35,
  "branch_cutoff": 0.15,
  "max_fanout": 3,
  "doc_selection": { "mode": "threshold", "doc_noul": 0.55, "top_k": 3 },
  "fallback": { "message_id": "not_found_v2", "notify_if_urgent": true }
}

閾値をコードに埋め込まず設定ファイルに出しておくと、モデルのバージョンを上げたときや、評価で傾向が変わったときに、デプロイせずに調整できます。doc_selection.modeを"rank"に切り替えれば、絶対値ではなく相対順位の上位k件を採る運用にも移れます。

コストとレイテンシの試算

原稿段階では「84〜94%のコスト削減」「2秒前後で回答開始」という見積もりを掲げていましたが、これはベンダーや論文が公表した値ではありません。ここでは前提を明示した編集部の試算として、計算の過程ごと示します。比較の基準は、Corpus2SkillのWixQAベンチマークで報告された1クエリあたり0.172ドル（プロンプトキャッシュなし）と0.089ドル（キャッシュあり）です（コスト構造とプロンプトキャッシュ参照）。

試算から読み取れるのは、Jevの費用は全体の数パーセント以下にとどまり、総額を決めるのはHop 3に渡す原文の長さと件数だという点です。規程集のように1文書が長いコーパスでは、Hop 2で件数を絞る精度がそのまま費用に効きます。一方で、Corpus2Skill単体で効いていたプロンプトキャッシュの割引（入力の約70%がキャッシュ読み取り）は、毎回中身の変わるHop 3には効きにくい点にも注意が必要です。

Jev前提のツリー設計

Corpus2Skillの既定設定は、子ノード数（分岐率）--p 10、トップレベルスキル数--max-top 8です。これは生成LLMが目次を読んで枝を選ぶ前提で、1回に見せる選択肢を少なめに抑えた形といえます。Jevで分岐を選ぶ場合、1回のchoiceで最大255の選択肢を扱えるため、浅く広い木に組み替える余地が生まれます。段数が減れば、そのまま呼び出し回数と待ち時間が減ります。

ただし、255個を使い切るのが最適とは限りません。選択肢が増えるほど似た説明のクラスタが並び、確率が分散して中確信度の判定が増えるからです。実務では第1層を数十〜百程度に収め、2層目をINDEXの文書リストにする2階層構成から始め、評価結果を見て広げるのが堅実です。リーフのINDEXを親に統合する--compactも、浅い木を作る手段になります。

想定すべき3つのリスクと対策

ここまでの設計は、Jevの判断がおおむね正しいことを前提にしています。しかしJevは、判断の理由を説明しません。多段の推論も行いません。出力の形式が崩れないことと、選んだ答えが正しいことは別問題で、選択肢を取り違える可能性は常に残ります。ベンダーが公表する性能も自社による評価が中心で、独立した検証はまだ乏しい段階です。そこで、次の3つを「起こりうるもの」として先に手当てしておきます。

リスク1：社内固有の用語とルール

Jevは一般的な語彙の判断は得意と考えられますが、学習データにない社内のプロジェクト名や独自ルールについては、知らないまま高い確信度で誤る可能性があります。対策は、Corpus2Skillのコンパイル段階で生成される要約を、そのままcriteriaに流用しないことです。社内システム名の定義、略語の正式名称、除外条件を判定基準として書き足した「ルールブック版」のcriteriaを別に管理します。判断材料を言語化して渡すほど、Jevの選択は安定します。

リスク2：日本語の曖昧さと表記揺れ

日本語での精度について、公開された独立検証は見当たりません。ただ、当サイトの運営で日本語ページの広告配置の判定にJevを使った際、noulの値がページを問わず0.65〜0.71の狭い幅に固まり、絶対的な閾値では差がつかなかった経験があります。このときは、ページ内での相対順位で採否を決める方式に切り替えました。日本語環境では、閾値を初期値のまま信じず、自社のQAセットで分布を確かめてから決めるべきです。ファンアウトの下限（branch_cutoff）はやや低めにし、迷ったら広く探す側に倒しておくと安全です。

リスク3：部署をまたぐ固有名詞

Corpus2Skillは文書を話題で分類するため、「A社とのこれまでのやり取り」のように、営業・法務・開発の各クラスタに散らばる固有名詞の質問を苦手とします。木構造の外側に、社名・製品名から文書IDを引ける逆引き辞書（エンティティ索引）を用意しておき、質問に登録済みの固有名詞が含まれていれば、該当文書をHop 2の候補に合流させます。ツリーの代わりに実体と文書のグラフで索引を作るCorpusMapという提案もあり、この弱点に対する一つの方向を示しています。

本番運用で守ること

最後に、運用面の決まりごとを挙げます。第一に、モデルのバージョンを固定します（例：jev-1.13.0）。確率の出方はバージョンで変わりうるため、jev-latestのまま本番を回すと、ある日突然閾値の意味が変わります。更新は評価セットで比較してから切り替えます。

第二に、障害と残高への備えです。Jevは残高不足で402、上流の障害で502を返します。502はバックオフしながら再試行し、それでも失敗したら、ルーティングだけを生成LLMに肩代わりさせる経路に落とします。遅く高くはなりますが、回答は止まりません。前払いのクレジットで運用する場合は、応答に含まれる残高を監視し、尽きる前に切り替えておくと安全です。

第三に、判断ログと評価の継続です。各ホップで選ばれたクラスタ、確信度、採用したdoc_idを記録しておけば、誤答の原因が「枝の選択」「文書の選別」「回答の執筆」のどこにあるかを切り分けられます。Corpus2Skillに同梱された評価モジュールでQAセットを定期的に回し、品質と1クエリあたりの費用を同じ表で追う運用は、エンタープライズ活用で触れた適用判断にもそのまま役立ちます。