RAG入門 — chunk・embedding・vector DB・retrieve/generate

Qiita | jagaimo_daisuki | 2026-05 をコンパイル

Abstract

RAG（Retrieval-Augmented Generation）の全体像を初心者向けに解説。Load→Split→Embed→Storeの準備フェーズと、Retrieve→Generateの使うフェーズ。

前提：LLMが知らないこと4つ

1. ハルシネーション（嘘をそれっぽく言う）
2. 最新情報の欠如（knowledge cutoff）
3. 社内文書を知らない
4. 根拠を示せない

RAGはこれら4つを「同じ仕組みで」解決する。

RAGの本質

parametric memory（モデル内知識）+ non-parametric memory（外部文書集）の組み合わせ。

料理本の編集者に例えると、新人ライター（LLM）に原稿を書かせる前に編集者（検索）が関連ページを3つ抜き出して渡す。

2つのフェーズ

用語解説

chunk

長い文書を数段落単位に分割した塊。1000文字＋200文字オーバーラップが例。

• 大きすぎる：複数トピック混在 → 精度低下
• 小さすぎる：意味のまとまりが壊れる

embedding

文章をベクトル（例：1024個の数値の並び）に変換する。意味が近い文章はベクトルとしても近くなる。

「ハンバーグの作り方」→ [0.124, -0.873, 0.456, ..., 0.211]

1024次元の理由：多すぎるとストレージ・計算コスト増、少なすぎると表現力不足。中間として1024 or 1536が多い。

token

AIが扱う文章の最小単位。日本語は1文字≒1〜2トークン。embeddingモデルには入力上限（512トークン等）がある。

Vector Database

ベクトルを保存し、「近いベクトルtop-k」を高速に検索できるDB。Chroma, Pinecone, Weaviate, Qdrant等。

メタデータ（出典・章・ページ等）も一緒に保存でき、検索時の事前フィルタに使える。

コサイン類似度

2つのベクトルの近さを測る指標。1.0=同一方向、0=直角（無関係）、-1.0=反対方向。

使うフェーズの詳細

1. ユーザーの質問も同じembeddingモデルでベクトル化
2. Vector DBからtop-kを取得（retrieve）
3. メタデータで事前フィルタ可能（精度・コスト同時改善）
4. 取り出したchunkを「参考文献」としてLLMのプロンプトに差し込み
5. LLMが出典付きの回答を出力

context window 1M tokens問題

「全部contextに入れればRAG不要では？」→ そうではない。理由：

1. Lost in the Middle：長文の中央部分が読み落とされる（Stanford Liu et al. 2023）
2. コスト（トークン数に比例）
3. ノイズ増加による精度低下
4. セキュリティ（全文書をcontextに入けたくない場合）

See Also

• 検索が自分に還ってくるとき ── 自己引用ループが引き起こす『RAG崩壊』 — 本記事が解説するRetrieve→Generateの仕組みが、自己生成コンテンツを検索で拾い直すことで集合的にどう壊れうるかを扱う応用編
• Hermes Agent運用の教訓 — profiles・config・skill設計 — LLM agent運用の文脈
• Claude Code安全運用 — CLAUDE.md 4原則 — AI開発ツールの文脈
• メモリは目的が決める ── AIエージェントにおける記憶の本質 — メモリと検索の接点
• Web Search & Extract 検索バックエンド選定ガイド — 検索バックエンドの選び方

Sources

• RAGってそもそも何なのか — indexもchunkもretrieveも知らない人のためのRAG入門 — Qiita, jagaimo_daisuki, 2026-05