RAG を作る前に読む地図 — 用語が「どこで牙を剥くか」を先に押さえる

「ChatGPT に社内ドキュメントを参照させたい」「自社の FAQ から正確に答えてほしい」。この要望にもっともよく当てはまる手法が RAG (Retrieval-Augmented Generation) で、検索すれば「RAG 入門」記事は無数に出てきます。けれど、ほとんどは「動くサンプル」で止まります。そして用語のほうも、embedding や reranker や Faithfulness を 定義だけ 覚えても、いざ自分で作り始めると「で、これは結局どこで効くの？」と剥がれ落ちていきます。

この記事は、もう一本の「RAG とは」用語集ではありません。配るのは 「用語 → それが本編のどの工程で、どんな失敗として牙を剥くか」の地図 です。題材にするのは、このブログの連載「使える RAG の作り方 — 測って・直して・運用する」全 5 部。各 Part で実際に手を動かして観察した失敗に、用語を 1 つずつ貼り付けていきます。読み終わったとき、本編のどの回が自分の課題を解くのかを、自分の言葉で選べるようになっているはずです。

そしてこの連載のゴールは、「RAG のサンプルを動かせた」ではありません。「自分の現場で RAG を設計・評価・運用できた」状態まで読者を運ぶことです。だからこの地図は用語集であると同時に、自分の案件のための作業手順書 でもあります。読み終えた翌日に、あなたが自分の案件向けに評価レポートと production readiness checklist を書ける——それを成功条件として設計しています。

この連載の対象読者・できること・扱わないこと

タイトルは入門調ですが、中身は naive 実装から評価・運用へと 初級から中級へ引き上げる実装連載 です。最初に「誰向けで、何ができるようになり、何を扱わないか」を明示しておきます。

この連載の対象読者

• Python は読める（書けなくてもよい）
• LLM API か Ollama のどちらかを触ったことがある
• RAG の概要は知っているが、本番品質との差分 が分からない
• vector DB や embedding の深い理論は未習でもよい

読み終えてできるようになること

• naive RAG が なぜ壊れるか を top-k の中身で説明できる
• 自分の corpus で同じ失敗を 再現 できる
• 次に chunking / hybrid / rerank / eval の どれを入れるべきか判断 できる
• 自分の案件向けに 評価レポートと受入 gate を書ける

この連載で扱わないこと

• 大規模 vector DB のチューニング
• 認証認可つき SaaS 化 / multi-tenant 設計
• agentic RAG・multimodal RAG・fine-tuning（Part 5 末尾で「次の入口」として触れる程度）

連載を読み終えると手元に残るもの（最終成果物）

この連載は「読むもの」ではなく「案件で使うもの」を目指します。コードより設計成果物が実務では効きます。5 部を通読すると、次の成果物セットが手元に残ります。各 Part の末尾には、その回で埋まる成果物をチェックリストで置いています。

この 1〜8 を 1 枚に畳んだものが、この記事の末尾に置く RAG 実務設計の最短ルート（12 手順） であり、設計レビューでそのまま使えるチェックリストです。1〜3 は Part 1-2 に、4〜6 は Part 4 に、7〜8 は Part 5 に、それぞれコピペして埋められるテンプレート（台帳・golden レコード・評価レポート・redact コード）の実物を置いています。

RAG とは「LLM にカンペを渡す」こと — 何で、何でないか

一言で言えば、RAG は 検索 (retrieval) を組み合わせて、生成 (generation) を補強する 手法群の総称です。LLM に質問をそのまま投げるのではなく、関連しそうな文書を先に 探してきて (retrieval)、それをカンペとして渡してから 答えさせる (generation)。用語の原典は Lewis らの論文 (2020)¹ で、いまでは「LLM が訓練時に知らなかった外部知識を、推論時に context として差し込む」汎用パターンの総称として使われます。実装の素朴さの度合いで Naive / Advanced / Modular と分類され²、本編 Part 1 はもっとも素朴な Naive RAG から始めます。

大事なのは、RAG が 万能ではない ことです。RAG が向くのは「答えに事実が必要で、その事実が学習データに含まれていない、または古い」タスク——社内 wiki、製品 FAQ、技術文書のように 更新頻度が高くドメイン特異 な知識です。逆に、創作 (小説・コピー) のように事実より文体が主役のタスク、軽量モデルで足りる分類タスク、1 秒以内の応答が要るリアルタイム用途には向きません (embedding と retrieval と LLM 呼び出しで数百 ms 〜 数秒かかるからです)。判断軸は 「変更頻度 × 正確性要求」をかけたとき、fine-tuning より RAG が割に合うか。毎週変わる社内 wiki なら RAG、年単位のブランドガイドラインなら fine-tuning でも良い、という具合です。

なぜ「用語集」ではなく「地図」なのか

用語の定義を 1 行ずつ並べた表は、読んだ直後はわかった気になります。けれど 使う場面と結びついていない知識は、手を動かし始めた瞬間に剥がれます。cosine 類似度 が何かを言えても、「なぜ語が一致しているのに間違った文書が上位に来るのか」を経験していなければ、その対策 (reranker) の必要性は腹落ちしません。

そこでこの地図は、用語を 本編 5 部の 4 つの工程 に貼り付けて並べます。Retrieval (Part 2)、Generation (Part 3)、評価 (Part 4)、運用 (Part 5)。各工程で、その用語が どんな失敗として牙を剥くか をセットにします。だから入門記事でありながら、同時に「自分はどの回から読むべきか」を選ぶ目次にもなっています。

工程 1 Retrieval — embedding・chunking・hybrid が「取りこぼし」で牙を剥く

最初の工程は カンペを探す 部分です。ここで登場する用語が、本編 Part 2 でこう牙を剥きます。

• embedding (ベクトル化): 文を「意味の座標」——数百次元の数値の並びに変換する操作です。近い意味の文はベクトルも近くなる、というのが狙いです。ところが固定長で切った chunk を 1 つの embedding モデルだけで表すと、言い回しの違う同義語を 取りこぼします。原因は、文埋め込みが意味だけでなく表層の構文にも引っ張られる性質です³。
• cosine 類似度 / top-K: ベクトル同士の近さ (cosine) で上位 K 件を取る、retrieval の心臓部です。これだけに頼ると、「ランニング部の練習計画」や「物流倉庫のロールバック」のように 語は一致するが意味は別物 の文書が top-5 に紛れ込みます。
• chunking: 文書を検索単位に切る作業です。素朴に固定長で切ると、見出しや「これは旧版 (archived) です」といった メタ情報が消えます。Part 2 では見出しを保持する splitter で chunk に版・状態を持たせ⁴、status filter で旧版を top-5 から追い出します。
• hybrid search (BM25 + dense): 意味の近さ (dense) だけでなく、語彙の一致 (BM25) も併用する方式です⁵。スコアそのものは合成できませんが、ランクなら合成できる (RRF, k=60)⁶ という発想で両者を束ねます。

Part 2 のゴールは「chunking と hybrid で recall が数値で改善する」こと。ただし——意味的に近い trap は順位が下がらない、という 天井 が残ります。それを崩すのが次の工程です。

→ 詳しくは Part 2: Retrieval を真面目に。

工程 2 Generation — reranker・citations が「trap と根拠」で牙を剥く

次は カンペを見て書く 工程ですが、その前に「どのカンペを最終的に渡すか」を精密に選び直します。

• reranker / cross-encoder: query と文書を 同時に モデルへ入れて関連度を測り、並べ替える手法です。cosine を使う bi-encoder は query と文書を別々にベクトル化するため相互作用を見られませんが、cross-encoder は両者を突き合わせます⁷。本編では top-20 を top-3 まで絞り、Part 2 で残った semantic trap の順位を 2 位から 9 位へ 落とします。
• 多言語 reranker: ただし reranker は モデル選択で結果が逆転 します。英語専用の reranker は日本語で精度が出ず、bge-reranker-v2-m3 のような多言語モデルが要ります⁸。「とりあえず有名な reranker」を選ぶと、かえって悪化することがあります。
• grounding / citations: 回答を「どの文書のどこ」に紐付ける仕組みです。本編では Anthropic Citations API で doc_id 付きの根拠を返させます⁹。ここでも「動く citation」と「使える citation」は別物で、根拠の引用が正しくても主張が正しいとは限りません。
• hallucination: 根拠のない、あるいは誤った生成のことです。purpose-built の法務 RAG でさえ 17〜34% が hallucinate するという報告があり¹⁰、「引用を付けたから安心」とはなりません。だからこそ次の工程 (評価) で 数値にして 確かめます。

ここで reranker や cross-encoder という語に「BERT? 何それ」となっても大丈夫です。深掘りは不要で、次の 概念階段 だけ押さえれば本編 Part 3 が読めます。

概念階段 — embedding から reranker まで（最小理解）

• encoder: 文章を読んで「数値表現」や「関連度」に変換するモデル。
• Transformer / BERT: encoder 型ニューラルネットの代表的な構造（BERT はその実装の 1 つ）。
• embedding model（= bi-encoder）: query と document を 別々に 読んでベクトル化する。速いが浅い（相互作用を見ない）。Part 1-2 の qwen3-embedding はこれ。
• cross-encoder: query と document を 一緒に 読んで関連度を直接出す。遅いが精密。
• reranker: 最初の検索結果 top-k を cross-encoder で並べ直す 部品。Part 3 の bge-reranker-v2-m3 はこれ。

一言で言うと、embedding は「速く広く集める」係、reranker は「遅く正確に選び直す」係。だから「embedding で top-20 → reranker で top-3」が定石になります。

→ 詳しくは Part 3: Generation を引用付きで書く。

工程 3 評価 — RAGAs 指標と judge バイアスが「測り方」で牙を剥く

ここが連載のクライマックスです。「よくなった気がする」を 客観的な数値 に翻訳する工程で、ここを飛ばすと改善が思い込みのままになります。

まず、検索の良さと生成の良さは 別々に測ります (retrieval / generation / end-to-end の 3 層)¹¹。代表的なツール RAGAs の 4 指標を押さえておくと、本編がぐっと読みやすくなります。

• Faithfulness: 回答の各主張が、渡した context に裏付けられているか¹²。hallucination の数値版です。
• Answer Relevance: 回答が質問にちゃんと対応しているか。
• Context Precision: 取ってきた文書のうち、本当に有用だった割合。
• Context Recall: 答えに必要な事実を、取ってきた文書がカバーできていたか。

評価には正解集合 (golden set) が要りますが、本編では 30 件で「十分」のラインに落ち着きます¹³。そして最大の落とし穴が judge バイアス です。回答を生成するモデルと、それを採点する judge が同じだと、自分の答えを甘く採点する self-preference が避けられません¹⁴¹⁵。本編では「英語 reranker が日本語スコアを下げていた」失敗を、まさにこの測定が炙り出します。何を測ってはいけないか を区別できて、はじめて評価になります。

→ 詳しくは Part 4: 評価 (クライマックス)。

工程 4 運用 — PII・drift・rollback が「本番」で牙を剥く

最後は、offline で良かったものが online で壊れる工程です。

• logging safety / PII redaction: 検索でヒットした chunk を default のままログに残すと、個人情報がそのまま蓄積され、重大インシデントになります。本編では取得・保存・出力の 3 箇所で redact します¹⁶¹⁷。
• embedding drift: コーパスを更新し続けると、ベクトルの分布が少しずつずれていきます。検出と re-index のタイミングを設計しないと、ある日静かに精度が落ちます。
• rollback / incident playbook: 壊れたときに前の状態へ戻す手順です。本編では fault model を 4 つに分け、5 ステップの playbook を用意します。
• OpenTelemetry: 観測を gen_ai.* という標準 attribute に乗せ、特定の監視 backend に縛られないようにします¹⁸。

→ 詳しくは Part 5: 本番運用。

症状から打ち手を引く — 採用判断表

用語と工程が分かっても、自分の案件で「何を、どの順番で入れるか」に変換できなければ設計には使えません。本編の各打ち手を、症状 → まず見るログ → 打ち手 → 入れてはいけない場合 の形に畳んだのが次の表です。この 1 枚が、本連載を「読むもの」から「設計レビューで引くもの」に変えます。

読み方の原則: 上から順に「retrieval を直す → generation を直す → 測る」の順序。reranker を入れる前に golden set を作る（でないと改善か悪化かを判定できません。Part 4 の「英語 reranker の罠」がその実例）のが、本連載が一番伝えたい順番です。

試すなら完全ローカルで — ただし「無料 ≠ 高速」

本編は API キーを 1 つも用意せずに、手元で完全に再現できます。LLM も埋め込みも Ollama に載せたローカルモデル (qwen3:8b と qwen3-embedding:0.6b) で動き、ollama pull だけで同じ数字を再現できます¹⁹。

ただし、ここで 1 つだけ誤解を解いておきます。「無料 (0 円)」と「高速」は別物 です。単発のクエリは数秒で返りますが、Part 4 の一括評価 (30 件 × 3 パイプライン) は Apple Silicon でも 1 時間強 かかります。ローカル LLM では一括バッチが律速になるからです。「ローカルだから気軽」と「ローカルだから速い」は違う、と最初に知っておくと、評価の回で待ち時間に面食らわずに済みます。

そしてもう 1 つ。ローカル経路とクラウド API 経路では、再現できることが一部違います。特に Part 3 の Citations API と Part 4 の judge は、経路で挙動が変わります。最初に差分を把握しておくと、自分の案件でどちらを選ぶかを判断できます。

実務では「embedding/rerank はローカル、generation だけクラウド」のような hybrid 構成が現実解になることも多い、という補助線も置いておきます（Part 5 のコスト節で再訪）。

RAG 実務設計の最短ルート（12 手順）

最後に、この連載全体を そのまま使える作業手順 に畳みます。自分の案件で RAG を立ち上げるとき、上から順に辿れば「動く」を「使える」まで運べます。各手順の右に、詳しく扱う Part を添えました。

1. corpus inventory を作る — どの文書があるか棚卸しする（Part 1）
2. active / draft / archived / stale を定義する — 文書の lifecycle を決める（Part 1-2）
3. まず naive RAG を作る — 100 行で動かす（Part 1）
4. top-k の中身をログで見る — 何が拾われているかを観察する（Part 1）
5. failure case を分類する — 表層 / 構造 / 旧版 / 同義語 / 引用喪失（Part 1）
6. chunking と metadata を直す — 出自（status）を chunk に焼き込む（Part 2）
7. hybrid search を試す — ただし自分のドメインで recall を測ってから（Part 2）
8. reranker を入れる前に golden set を作る — 改善か悪化かを判定できるように（Part 4 を先に着手）
9. reranker は単一クエリでなく aggregate で評価する — 「英語 reranker の罠」を避ける（Part 3-4）
10. citations は「claim の正しさ」までは保証しないと理解する — Faithfulness で別途測る（Part 3-4）
11. 本番前に logging / PII / rollback を設計し、受入 gate を通す（Part 4-5）
12. 運用後は drift と regression を監視する — golden set をインシデントごとに太らせる（Part 5）

この 12 手順が頭に入っていれば、本連載は順番に「自分の案件の成果物を作る」ための手順書として再利用できます。

最初の 90 分 — 今日のうちに自分の corpus で着手する

12 手順を「明日やる」と言った瞬間に、たいてい来週になります。そこで、今日この後の 90 分 でできるところまでを時間割にしておきます。モデルのダウンロード (ollama pull qwen3:8b で約 5GB) は最初に裏で走らせておいてください。

1. 0–30 分 — 代表 20 文書に active / draft / archived / stale の仮ラベルを振る（迷ったら「迷った」と書く）。道具は Part 1 の corpus inventory テンプレート
2. 30–60 分 — 訊かれそうなクエリを 10 件書き出す。うち 2 件は corpus に答えが無い negative にする。書式は Part 4 の golden set スキーマに合わせる
3. 60–90 分 — companion repo の corpus/v2/ に自分の文書 5 件を入れ、10 クエリ流して top-k を記録する（Part 1 の naive_rag.py）

90 分後に手元へ残るのは、雑でも「自分のデータの台帳 v0」「クエリ 10 件」「top-k のログ」の 3 点です。台帳の「迷った」が Part 1 の lifecycle 設計課題そのものですし、top-k に変な文書が 1 つでも混ざっていれば、それがあなたの案件の trap 第 1 号になります。本編は、その trap を順に潰していく工程として読めるようになります。

ここから本編へ

地図を手にしたら、あとは順番に手を動かすだけです。まずは Part 1: 素朴な RAG の限界 で 100 行強の RAG を組み、「動く」と「使える」の谷を自分の目で見てください。そこから Retrieval (Part 2)、Generation (Part 3)、評価 (Part 4)、運用 (Part 5) と、この地図のとおりに進みます。

なお fine-tuning・multimodal RAG・agentic RAG は、本連載のスコープ外です。これらは Part 5 の末尾で「次の入口」として触れられています。まずは素朴な 1 本を、評価できて、運用できる 1 本に育てる——その道のりの地図として、この記事を使ってもらえればと思います。

参考文献