RAG 02：いちばん小さな RAG ― 端から端まで作る

RAG は2つの時間帯に分かれる：準備と本番

RAG を作るとき、最初に頭に入れておきたいのは、仕事が2つの時間帯に分かれていることです。

索引（インデックス）とは、本の巻末の索引のように「すぐ探せるように整えておいたもの」のことです。たとえるなら、図書館です。準備は、本を仕入れて、分類して、目録カードを作って棚に並べる仕事。本番は、利用者に「こういうことを調べたい」と聞かれて、目録から本を探して手渡す仕事です。目録づくりは閉館後にまとめてやればよく、利用者を待たせる必要はありません。

図の上のレーンが準備、下のレーンが本番です。2つをつないでいるのは、上の「保存する」から下の「近いものを探す」に伸びた矢印、つまり保存した索引だけです。

この分け方には実務上の意味があります。準備は時間がかかってもよいので、重い処理（PDF の解析や、大量の文章のベクトル化）はこちらに寄せます。本番は利用者を待たせるので、できるだけ軽くします。次のページから、上のレーンの左から順に見ていきます。

準備①：資料を読み込んで、文字にする

最初の段は、資料を読み込んで、ただの文字に直すことです。

社内の資料は、PDF、Word、Excel、PowerPoint、Web ページ（HTML）、社内 Wiki など、いろいろな形で置かれています。後で使う検索の仕組みも LLM も、読めるのは基本的に文字だけなので、まず中身の文字を取り出します。

このとき、文字と一緒に出典（どのファイルの何ページか）も覚えておきます。後で答えに「就業規則.pdf 3ページ」と添えるための情報です。この段で捨ててしまうと、後から取り戻せません。

素朴な RAG では、形式ごとのライブラリで文字を取り出すだけにします。

実は、ここが一番地味で、一番よく壊れる段です。PDF の表が崩れる、2段組みの文章が混ざる、スキャンした PDF からは文字が1つも取れない…。こうした問題と対処は、次の第3章でまとめて扱います。この章では「とりあえず文字になった」ところから進みます。

準備②：長い文書を、小さな塊（チャンク）に切る

次に、取り出した長い文章を、チャンクと呼ぶ小さな塊に切ります。

なぜ切るのでしょうか。1万字の就業規則を丸ごと1件として扱うと、「休暇は何日？」という質問に対して、就業規則全体が「近い」か「遠い」かしか判断できません。しかも、見つかった後で1万字を丸ごと LLM に渡すことになります。第1章で見たとおり、読ませる量が多いほど高く・遅く・見落としやすくなります。

小さく切っておけば、質問に効く部分だけを拾って渡せます。

素朴な切り方は「決まった長さで切る」です。長さはトークン（第1章で見た、LLM が文章を読むときの単位。「LLM にとっての1語」のようなもの）で数えることが多く、たとえば800トークンずつ切り、切れ目で文が途切れても前後のつながりが残るように、隣のチャンクと100トークンくらい重ねておきます。

この数字は「まず試す値」であって、正解ではありません。見出しで切る、意味の切れ目で切る、といった工夫は第3章で詳しく見ます。

準備③：チャンクを「意味の座標」に変える

切ったチャンクを、1つずつ埋め込みモデル（文章を数の並びに変える専用の AI）に渡して、ベクトル（数の並び）に変えます。これを埋め込み（エンベディング）と呼びます。

ベクトルは、文章の意味を表す座標のようなものです。地図の上で、近い場所は緯度と経度の数字も近くなります。埋め込みも同じで、意味の近い文章は、近い数の並びになるように作られています。「有給休暇は何日？」と「年次休暇の日数」は、使っている言葉が違っても、近い座標になります。

地図は2つの数（緯度・経度）ですが、埋め込みのベクトルは、モデルによって数百から数千個の数でできています。この数の個数を次元と呼びます（地図なら2次元）。それだけ細かく「意味の違い」を表せるということです。

実装としては、埋め込みモデルを提供している会社の API（プログラムから呼び出す窓口。第1章）に、チャンクの文字を送ると、ベクトルが返ってくるだけです。自分のサーバーで動かせる公開モデルもあります。

1つ大事な決まりがあります。準備で使った埋め込みモデルと、本番で質問をベクトルにするモデルは、同じものにすることです。モデルが違うと、座標の決め方そのものが違うので、近いかどうかを比べられません。モデルを変えたら、準備をやり直します。埋め込みの仕組みと選び方は第4章で見ます。

準備④：本文・ベクトル・出典を一緒に保存する

最後に、チャンクごとに次のものをまとめて保存します。

よくある勘違いは、「ベクトルにしたら、本文は要らない」というものです。ベクトルは座標であって、そこから元の文章を読み戻すことはできません。探すのはベクトルで、読ませるのは本文です。

保存先は、最初は何でもかまいません。数千件くらいなら、JSON ファイルに書き出して、起動時にメモリに読み込むだけで十分です。件数が増えたり、複数のサーバーから使ったりするようになったら、ベクトル DB（ベクトルを保存して近いものを速く探せるデータベース）を使います。

ID の付け方は、後で効いてきます。「就業規則の3番目のチャンク」のように、元の資料と順番から決まる ID にしておくと、資料が改訂されたときにどのチャンクを差し替えればよいかが分かります（第3章）。

本番①②：質問もベクトルにして、近いチャンクを探す

ここから下のレーン、利用者が質問するたびに動く「本番」です。

まず、質問の文を、準備と同じ埋め込みモデルでベクトルにします。次に、保存しておいた全部のチャンクのベクトルと比べて、近い順に並べ、上位 k 個を取ります。図では、上位3つが休暇の資料、4番目の経費の資料は遠いので取りません。

「近さ」の測り方として一番よく使われるのが、コサイン類似度です。ベクトルを、地図の基準点から座標へ向かう矢印だと考えてください。2本の矢印が同じ向きを向いているほど1に近く、関係ないほど0に近くなります（詳しくは第4章）。図の左の数字（0.91 など）が、そのイメージです。

k を大きくすると、答えの載ったチャンクを取りこぼしにくくなりますが、LLM に渡す量が増えて、高く・遅く・見落としやすくなります（第1章）。小さくすると逆です。

「全部と1件ずつ比べる」のは素朴ですが、数千件なら一瞬で終わります。数百万件になると遅すぎるので、近似最近傍探索（全部と比べる代わりに、少しの誤差を許して「だいたい一番近いもの」を素早く見つける方法）を使います（第5章）。

本番③：資料と質問を並べて、頼み文を組む

探したチャンクを、質問と一緒に並べて、LLM への頼み文（プロンプト）を組み立てます。素朴な形は、図のようなものです。

次の資料だけを根拠に答えてください。
資料に無いことは「資料には書かれていません」と答えてください。
答えの文ごとに、使った資料の番号を [1] のように付けてください。

[1] 勤続年数に応じて最大20日…
[2] 有給は入社6か月で10日…
[3] 慶弔休暇は…

質問：休暇は何日もらえる？

短い文ですが、第1章で見た LLM の弱点への対策が詰まっています。

資料に番号を振っておくのがコツです。LLM が「[2]」と書けば、それがどのチャンクか、プログラムの側で分かります。

資料を並べる順番（大事なものを先頭に置く、など）や、指示の書き方の工夫は、第8章で詳しく見ます。

本番④⑤：LLM に答えさせ、出典を添えて返す

組み立てた頼み文を LLM に送ると、答えが返ってきます。図の例では「入社6か月で10日です [2]。勤続年数に応じて、最大20日まで増えます [1]。」となりました。

最後に、答えの中の [1] や [2] を、元の出典に戻して画面に出します。準備の段で保存しておいた出典（就業規則.pdf 3ページ）が、ここで生きてきます。利用者は、気になった答えについて、元の資料を開いて確かめられます。

ここで1つ注意があります。LLM が付けた番号が、本当にその資料の内容に基づいているかは、保証されていません。LLM は、資料 [1] の内容を書いたのに [2] と書いてしまうこともありますし、資料に無いことを書いて、それらしい番号を付けてしまうこともあります。

素朴な RAG では、形の確認だけでもしておくとよいでしょう。答えを画面に流しながら表示する（ストリーミング）場合も、出典の一覧は最後にまとめて付ける、という作りが扱いやすいです。

コードで書くと（準備）

ここまでの準備の流れを、TypeScript で書くと次のようになります。枠組み（ライブラリ）を使わない、素朴な書き方です。

type Chunk = { id: string; text: string; source: string };
type Indexed = Chunk & { vector: number[] };

// 長い文章を size 文字ずつ、overlap 文字重ねて切る（トークンの代わりに文字数で近似）
function split(doc: { name: string; text: string }, size = 800, overlap = 100): Chunk[] {
  const out: Chunk[] = [];
  for (let start = 0, n = 0; start < doc.text.length; start += size - overlap, n++) {
    out.push({ id: `${doc.name}#${n}`, text: doc.text.slice(start, start + size), source: doc.name });
  }
  return out;
}

const docs = await loadFiles("./docs");             // PDF・HTML → { name, text }
const chunks = docs.flatMap((d) => split(d));
const vectors = await embed(chunks.map((c) => c.text)); // 埋め込み API を呼ぶ
const index: Indexed[] = chunks.map((c, i) => ({ ...c, vector: vectors[i] }));
await writeFile("index.json", JSON.stringify(index));

上から順に、次のことをしています。

埋め込み API には一度に送れる件数の上限があるので、実際には数十〜数百件ずつに分けて呼びます。切る長さは、実際には文字数よりトークン数で数えるほうが正確です（第1章）。

コードで書くと（本番）

本番の流れです。準備で作った index を読み込んでおき、質問のたびに次を実行します。

// 2つのベクトルの向きの近さ（コサイン類似度）
function cosine(a: number[], b: number[]): number {
  let dot = 0, na = 0, nb = 0;
  for (let i = 0; i < a.length; i++) { dot += a[i] * b[i]; na += a[i] ** 2; nb += b[i] ** 2; }
  return dot / (Math.sqrt(na) * Math.sqrt(nb));
}

async function ask(question: string, index: Indexed[]) {
  const [qv] = await embed([question]);
  const hits = index
    .map((c) => ({ ...c, score: cosine(qv, c.vector) }))
    .sort((a, b) => b.score - a.score)
    .slice(0, 4);
  const context = hits.map((h, i) => `[${i + 1}] ${h.text}`).join("\n\n");
  const answer = await llm(
    `次の資料だけを根拠に答えてください。資料に無いことは「資料には書かれていません」と答えてください。\n` +
    `答えの文ごとに、使った資料の番号を [1] のように付けてください。\n\n${context}\n\n質問：${question}`,
  );
  return { answer, sources: hits.map((h, i) => ({ no: i + 1, source: h.source, id: h.id })) };
}

温度（答えのぶれ）は低めにしておくとよいでしょう（第1章）。

これで、いちばん小さな RAG が完成です。準備と本番を合わせても、補助の関数を除けば数十行です。第0章で「作るのは簡単」と言ったのは、このことです。

枠組みを使うか、自分で書くか

RAG を作るための枠組み（フレームワーク）も、たくさんあります。代表的なのは次の2つです。

保存先（ベクトル DB）の選択肢も多くあります。PostgreSQL にベクトルを扱う機能を足す pgvector、手元ですぐ試せる Chroma、ベクトル検索専用の Qdrant、サーバーの管理を提供会社に任せられるマネージド型のサービスなどです。

どれを使うかより大事なのは、中で何が起きているかを知っていることです。枠組みを使うと、数行で RAG が動きます。でも、うまく答えられないとき、「どのチャンクが拾われたのか」「LLM に何が渡ったのか」が見えないと、直しようがありません。

おすすめの進め方は、次のとおりです。

どこで壊れるか：この本の残りの地図

いちばん小さな RAG は、デモではよく動きます。でも、本物の資料と本物の質問で試すと、あちこちで壊れます。図の赤い箱は、どれも壊れうる段です。

最後の行が特に大事です。素朴な RAG を作ったら、実際にありそうな質問と、その正しい答えを数十個用意して、試してみてください。どの質問で、どの段が失敗したのかを1つずつ見ていくと、次に何を直せばよいかが分かります。測り方は第12章で詳しく扱います。