RAGとは

RAGの目的

RAGはRetrieval-Augmented Generationの略です。LLMにすべてを覚えさせるのではなく、必要な文書を検索し、その結果をプロンプトへ入れて回答させる設計です。

よくある目的は次の3つです。

• 最新情報や社内文書を扱う。
• 回答の根拠を示しやすくする。
• モデルの再学習なしに知識を更新する。

最小フロー

RAGの基本は、生成より前の検索設計です。

文書
  -> 分割
  -> Embedding
  -> ベクトル検索
  -> 関連チャンクをプロンプトへ注入
  -> LLMが回答

検索結果を入れるだけなら簡単ですが、実務では「どの粒度で分割するか」「どのメタデータを持つか」「引用をどう返すか」が品質に大きく影響します。

RAGで改善すること

RAGは、モデルが学習していない文書を参照する場面に向いています。たとえば社内規程、FAQ、製品仕様、運用手順、過去の議事録です。

一方で、RAGは推論力そのものを魔法のように上げる仕組みではありません。検索で誤った文書を拾えば、回答もずれます。

失敗しやすい点

RAGの失敗は、LLMより前で起きることが多いです。

失敗	原因
関係ない文書が入る	検索クエリ、分割、Embeddingが弱い
根拠が追えない	source、見出し、URLなどのメタデータ不足
長すぎて読めない	チャンク粒度や圧縮設計が弱い
回答が断定的すぎる	根拠なし回答を避ける指示と評価が弱い

JSONメタデータとの接点

RAGでは、本文だけでなくメタデータが重要です。

{
  "source": "handbook/security.md",
  "title": "APIキーの管理",
  "section": "本番運用",
  "updatedAt": "2026-06-15",
  "tags": ["security", "api"]
}

このようなメタデータは、検索フィルタ、引用表示、更新検知、回答の信頼性表示に使えます。JSON Man側では、こうしたJSON構造の読みやすさやスキーマ設計へ展開できます。