RAG：知識を重みに詰め込まず参照する

目安: 50分。演習の状態: 未実行 (not-run)。本文は学習ガイドであり、動作や品質の実測記録ではありません。

前提となる章: GPU基盤とコストを選ぶ

独自の概念図。矢印は依存関係や判断の順序を示し、性能の実測を表さない。

1. 1閲覧可能な文書と版
2. 2権限を適用した検索
3. 3引用できる根拠
4. 4生成
5. 5引用と棄権の確認

学習目標

• 検索失敗と生成失敗を区別する
• アクセス制御と出典のある小さなRAGを設計する

仕事の役割

• 学習者: 仮説・データ・評価を設計する
• モデル: 指定した変換を試す
• アプリ: 制限・検証・権限を保証する

入力 → 工程 → 出力

入力	工程	出力
利用権と閲覧権限が確認された文書、質問	分割→検索→並べ替え→根拠付き生成	回答、出典、棄権、取得ログ

RAGが変えるのは入力

RAGは関連資料を検索し、その内容をLLMの入力に含めて答えを作る構成である。通常の検索インデックス更新はLLMの重みの学習ではない。仕様書や用語集が頻繁に変わる場合、再学習せず資料を更新できることが利点となる。

RAGを入れても答えが正しくなる保証はない。必要な段落を拾えない、古い版を参照する、表の単位が切れる、引用と主張が対応しないといった問題が残る。検索器と生成器の評価を分ける。

RAG原論文 はモデル内の生成と外部の検索を組み合わせる。アプリ側の外部文書を更新することは、原論文の学習手法とは別に考える。本章の権限・引用の検査はアプリの設計条件であり、RAGという名称だけから得られる保証ではない。

データが答えになるまで

原文を取得し、文書ID・版・公開日・閲覧権限を付ける。見出しや表を壊しにくい単位に分割し、embeddingまたは語句検索のインデックスを作る。質問から候補を取得し、必要ならrerankerで並べ替え、限られたcontextへ根拠を詰める。出力には引用元と、根拠不足なら答えないという条件を与える。

embeddingは意味の近さを扱う補助である。型番、略語、数値などには語句検索が役立ち、両者を組み合わせるhybrid検索が候補となる。chunkサイズやtop-kは魔法の定数ではなく、答えを含む段落が取得できるかで決める。

権限とprompt injectionを設計に入れる

利用者が読めない文書は検索候補の段階から除外する。生成後に隠すだけでは、情報が既にLLMへ渡っている。文書内の命令文は資料であり、アプリの権限変更や外部送信の指示として扱わない。

評価では、正解根拠の取得率、引用の正しさ、答えの支持率、更新反映、未収録質問での棄権を分ける。RAGの改良前に、そもそも正しい資料が存在し閲覧可能なのかを確認する。

自分で進める工程

1. 公開の架空製品マニュアル10件を用意する
2. 文書単位でIDと版を付ける
3. 正解根拠のある質問と未収録質問を作る
4. 検索結果だけを先に採点する
5. 次に回答と引用の対応を採点する

品質を確認する

• 検索失敗と生成失敗を区別する
• アクセス制御と出典のある小さなRAGを設計する
• 取得文書内の命令に従わないテストを含めたか

失敗を切り分ける

注意すること	具体的な確認方法
検索で見つかったことを事実の裏付けと即断しない	取得した段落の出典と版を確認し、回答の根拠になるか読む。
個人情報を含むembeddingやindexも保護対象として扱う	元文書のアクセス権と保持条件を、インデックスとembeddingにも適用する。

演習: RAG：知識を重みに詰め込まず参照する

状態: 未実行 (not-run)。

古い版と新しい版がある仕様を作り、最新版の根拠だけで答えられるか検証する

提出するもの: 検索失敗・生成失敗・資料不足の分類表

完了の確認: 取得文書内の命令に従わないテストを含めたか

実験記録用ワークシートに計画・条件・観察を記録する。未測定値は null とし、推定値は式と仮定を残します。