8.0 学習チェックリスト：LLM アプリ開発と RAG

このページは印刷用チェックリストとして使います。詳しい説明が必要なときは、第 8 章入口ページに戻ってください。

RAG ポートフォリオ証拠パック

2時間の初回通読

時間	やること	ここまで言えたら止める
20 分	入口ページの RAG アプリループを見る	「RAG の回答は検索証拠と結びついているべき。」
25 分	Tiny RAG スクリプトを動かす	「回答を信じる前に top-k チャンクを確認できる。」
25 分	8.1 RAG 基礎と文書処理をざっと読む	「chunk サイズ、重なり、metadata は検索と引用に効く。」
25 分	8.3 API 実践と tool/関数呼び出しをざっと読む	「LLM アプリには request、response、error、retry の経路が必要。」
25 分	デバッグ階段を読む	「文書、検索、生成、引用、運用の失敗を分けられる。」

証拠	最小版
`chunks.jsonl`	`id`、`source`、`text`、`version` を持つ 5～10 個の chunk
`retrieval_logs.jsonl`	各テスト質問のクエリ、top-k chunk ID、score、source
`eval_questions.csv`	少なくとも10個の固定質問と期待出典または回答ポイント
`failure_cases.md`	少なくとも3つの失敗例。document、chunking、retrieval、generation、citation、deploy に分類
`rag_config.md`	chunk サイズ、overlap、top-k、rerank の有無、Prompt 版
`context_strategy.md`	long context、RAG、memory、hybrid の判断と、不採用案の理由
`rag_app_workshop_output.txt`	8.5.6 実践：第 8 章 RAG アプリ完全ワークショップの出力
`README.md`	実行コマンド、例の質問、引用付き回答、評価結果、次の修正

ゲート	合格条件
引用	すべての事実回答が chunk、source、version を引用する。
空検索	証拠がないとき、システムは回答を拒否する。
回帰評価	chunking、retrieval、reranking、Prompt の変更前後で同じ質問を実行する。
運用	ログにクエリ、top-k、Prompt 版、レイテンシ、token cost、失敗ラベルがある。

期待される結果：第 8 章のプロジェクトフォルダに、chunks、検索ログ、固定評価質問、引用付き回答、失敗ラベル、アプリログ、次の検索または生成の修正を説明する README がそろっている状態です。

確認の考え方と解説

RAG の違いは、まず証拠を検索してから答える点です。長い Prompt は主にモデルの既存知識や推測に頼りますが、RAG は新しい事実、私的な事実、文書由来の事実を答えに取り込めます。
query、top-k chunks、score、source、version を見せると、他の人も検索経路を確認できます。
metadata は source、version、位置情報をチャンクに結び付けたままにするので、引用、デバッグ、回帰分析ができます。
検索が空なら、いちばん安全なのは「回答できない」または「追加情報が必要」と返すことで、推測しないことです。
検索、chunking、reranking の前後で同じ評価質問を使うと、公平に比較できます。

答えがすべて「はい」なら、第 9 章へ進みます。第 9 章では、システムを「回答生成」から、計画し、ツールを呼び、失敗から回復できる Agent へ発展させます。

このページを終えたら、この証拠カードを残します。