【Paper&Hacks Vol.85】チャンク／プロンプト戦略＋アドバンスRAGアプリハンズオン

（５回シリーズ）RAGの仕組みを理解して改善し続けよう〜 LangChain Family × GradioによるRAGアプリ開発〜第３回：RAGを最適化しよう〜チャンク／プロンプト戦略＋アドバンス RAGアプリ開発〜 2026/5/26異業種データサイエンス研究会 ® 代表井伊篤彦

3.

井伊篤彦 Who am I? 1963年（昭 38年）生まれ。京都大学工学部修士課程（合成化学専攻）終了。大学和院で量子化学を副専攻。前職は一部上場大手日用品製造メーカー研究所。社内で各種製品開発を行うかたわらコンピューターケミストリーを手掛け、化学分子 3D表示ソフト等をC言語を用いて開発。その後、海外駐在やグローバルな商品開発マネージャーを経て、2017年からAI及びxR (VR, AR, MR) を用いた新規プロジェクトをゼロから立ち上げ率いた。AIプロジェクトでは、自ら機械学習モデルを開発した。 2019年に FBコミュニティ「異業種データサイエンス研究会 16個のFBコミュニティを運営してい ®」を立ち上げる。現在る。プログラミングスクールで AIプログラミングの指導をする傍ら、年間数十回のデータサイエンス・ AI関連のセミナーを実施している。

4.

ハンズオン用コード（ zipファイル） https://drive.google.com/file/d/1RbSOhmldbKO4dw9IISfpy6qoIrMEsrok/view?usp=drive_link パッチコード： https://drive.google.com/file/d/1UH9CrMItUSwkv2LqYULFJPDQwgzN-pYd/view?usp=drive_link ※ 本ハンズオンは、事前準備を完了していることを前提に進行します。コード実行用のキー取得、Google Colab の基本操作、Google Drive のマウント確認は、必ず事前に済ませてください。 ① Google Colab から Google ドライブのマウントの方法については、添付のドキュメントを読み事前確認お願いします。 https://docs.google.com/document/d/1wJEIOvWlEMdj-DwmvTPgVkWYUSvWsWNc/edit?usp=drive_link&ouid=106881452668834877355&rtpof=true&sd=true � ハンズオン用コードを動かすには、HuggingFace シークレットトークン（キー）が必要です。 HuggingFace シークレットトークン取得参考記事： https://qiita.com/so9_Monodzukuri_AI/items/388e9b546ecb2ecfc420 ③ Google Colab のシークレット機能の使い方 https://note.com/npaka/n/n79bb63e17685 � 自動評価用コードを動かすには、OpenAI API, LangSmith のシークレットトークン（キー）が必要です。 OpenAI API キー取得参考記事： https://www.tis2010.jp/openai_apikey/ LangSmith キー（LangChainと共通）取得参考記事： https://zenn.dev/umi_mori/books/prompt-engineer/viewer/langsmith

5.

RAGの仕組みを理解して改善し続けよう LangChain Family × Gradio で作る「作る → 測る → 改善 → 選択 → 自律化」5回シリーズ測る 3回目 4回目改善する選択 Ragas × LangSmith chunk & prompt 戦略 / Advanced RAG タスクに応じた generator 選択 / API 利用・API使用 2回目 1回目作る動いて中身も見える RAGアプリ・Retriever / Prompt / LLM ・ログ run_id）保存・Gradioで体験（・検索と生成を分解 Faithfulness / ・ Relevance ・悪い例を追跡・chunk_size / overlap ・当たりチャンク探索・改善の再現性・モデルサイズ選択・モデルのFT 5回目自律化 LangGraph / Agentic RAG ・検索 / 推論 / 生成・ループで精度改善・運用に近い形へシリーズの狙い： RAGアプリをベースに「作る → 測る → 改善 → 選択 → 自律化」の流れを体験し、検索・生成・評価・モデル選択を組み合わせた、継続的な改善サイクルを理解する。

6.

RAGの基本フロー Embedding ベクトル DB 生データ検索 Embedding Retriever コンテキスト回答質問図参照： https://www.techfirm.co.jp/blog/vector-database https://g-gen.co.jp/useful/General-tech/llm-ai/ https://blog-ja.allganize.ai/allganize_rag-1/ システムプロンプト

https://blog-ja.allganize.ai/allganize_rag-1/

7.

RAGの基本フローと要素技術の関係 Embedding ベクトル DB RAG = 検索強化 x ICL x CoT 検索強化とも解釈できる検索生データ Embedding コンテキスト Retriever In-Context L 回答質問図参照： https://www.techfirm.co.jp/blog/vector-database https://g-gen.co.jp/useful/General-tech/llm-ai/ https://blog-ja.allganize.ai/allganize_rag-1/ システムプロンプト Chain of T

8.

魔法科高校 15問は「 RAG実験道具」小型でも、検索・列挙・統合・取り違えを観察できるベンチマーク 15問のタイプ分散単純な事実確認だけでなく、実務RAG で起きやすい失敗型を意図的に混在単純事実確認人物・属性対応複数正答列挙組織名列挙人物関係対応観察できること複合文脈統合 DB用5分割テキスト重点問題が診断軸になる 1つにまとめすぎず、細かく分けすぎない。に近い距離感「情報が散らばる」実務RAG を作る。話題のまとまりを保持巨大文書の偶然ヒット抑制複数ファイル横断を再現 retrieval失敗を追跡しやすい chunk戦略で改善する問題 promptで救える問題 Q12 Q15 複数要素列挙 prompt_detailで改善しやすい複合文脈統合 generator 差が見える超難問 generator変更で残る問題を突破「最高点探し」ではなく、失敗要因を分解し、次の仮説へつなぐための小型ベンチマーク

9.

魔法科高校 15問一覧 Q番号・質問・正答・問題タイプ｜検索・列挙・統合・取り違えを観察するための小型ベンチマーク Q 質問正答問題タイプ Q1 「魔法科高校の劣等生」のキャラクター司波深雪の声優は誰ですか？早見沙織単純事実確認 Q2 九島家の説明では司波深雪に匹敵する魔法力を持つとされ、別の記述では十三使徒「アンジー・シリウス」と呼ばれる人物は誰ですか？アンジェリーナ・クドウ・シールズ（リーナ）。人物・属性対応（同一人物特定） Q3 十三束鋼の二つ名「Range Zero（レンジ・ゼロ）」には、どのような二つの意味が込められていますか？遠隔魔法が苦手だという揶揄と、ゼロ距離では無類の強さを発揮するという敬意の二つの意味が込められている。複数要素説明（二面性理解） Q4 「魔法科高校の劣等生」のキャラクター九重八雲の身長と体重を教えて。身長177cm、体重67kg 単純事実確認 Q5 「魔法科高校の劣等生」で、司波達也と九島光宣はどちらも「精霊の眼（エレメンタル・サイト）」を持っています。 2人の知覚の得意分野はそれぞれ何ですか？司波達也は分解・再成の特性から能動的な知覚に優れ、九島光宣は仮装行列（パレード）の特性から受動的な知覚に優れ、意識を向けていない状態でも遠方の魔法の兆候を感じ取れる。人物・属性対応（比較） Q6 「魔法科高校の劣等生」の中で「水晶眼」を持つキャラクターは以下の３人のうち誰でしょうか？ 1. 司波深雪 2. 千葉エリカ 3. 柴田美月柴田美月単純事実確認（選択式） Q7 吉祥寺真紅郎の異名「カーディナル・ジョージ」は、どの二つの要素に由来していますか？また、彼がそれを活かして使う代表的な魔法は何ですか？仮説上の存在だった「基本（カーディナル）コード」の発見と、名前の「真紅（カーディナルレッド）」に由来する。代表的な魔法は「不可視の弾丸（インビジブル・ブリット）」。複数要素列挙（異名の由来） Q8 一条将輝の戦略級魔法「海爆（オーシャン・ブラスト）」は、どの技術を基幹にし、誰が完成させたものですか？達也から提供されたトゥマーン・ボンバの基幹技術「チェイン・キャスト」を基に、吉祥寺真紅郎が完成させた。技術・人物対応 Q9 「魔法科高校の劣等生」に出てくる戦略級魔法「オゾンサークル」は誰の魔法ですか？カーラ・シュミットとウィリアム・マクロード複数正答列挙 Q10 各ファイルの記述に従うと、日本の国家公認戦略級魔法師について、五輪澪はどのような立場で記されており、一条将輝は何人目として認定されましたか？五輪澪は「日本が公式に認定している唯一の戦略級魔法師」と記されており、一条将輝は「日本で二人目の国家公認戦略級魔法師」として認定された。複数ファイル記述比較ミスター・トーラス単純事実確認「メイジアン・ソサエティ」「ステラ・ジェレネーター」「一般社団法人メイジアン・カンパニー」。組織名列挙 Q11 「魔法科高校の劣等生」のキャラクター牛山欣治は社内で司波達也が「ミスター・シルバー」と呼ばれるのに対し、どのように呼ばれていますか？ Q12 『メイジアン・カンパニー』において、司波達也が設立した三つの組織・法人の名前をすべて挙げてください。情動干渉系の系統外魔法で、一定のエリア内にいる人間をある種のトランス状態に誘導する。個 Q13 「魔法科高校の劣等生」の中条あずさが持つ系統外魔法「梓弓」は、どのようなタイプの魔法で、どのような状況に適していますか？人ではなくエリアに働きかける稀少な魔法で、無秩序な混乱の鎮圧に適している。 Q14 Q15 一色家の固有魔法「神経電流撹乱（神経撹乱）」について、一条家では誰が使えず、誰がその適性を受け継いでいますか？「トーラス・シルバー」に関して、司波達也がその名で製品を世に送り出す際に組んでいる人物と、その正体を確信した第一高校の生徒をそれぞれ答えてください。説明型（魔法の性質・用途）一条美登里は使えず、長女の一条茜がその適性を受け継いでいる。人物関係対応（家系継承）組んでいる人物は牛山欣治で、正体を確信した第一高校の生徒は中条あずさ。複合文脈統合

10.

RAGの基本フロー Embedding RAGの性能は、単一要素ベクトル DB の最適化ではなく、要素間の協調設計で決まる検索生データ Embedding 何を渡すか Retriever コンテキスト In-Context Learning コンテキスト制御装置回答質問図参照： https://www.techfirm.co.jp/blog/vector-database https://g-gen.co.jp/useful/General-tech/llm-ai/ https://blog-ja.allganize.ai/allganize_rag-1/ どう振る舞わせるかシステムプロンプト制約付き生成

11.

LLMは検索コンテクストをどう読んでいるのか？ユーザー質問 Context Window LLMの出力「深雪の声優は誰？」 System / 指示正答にも質問は短くても、検索で取れた文脈の質で答えが変わる。質問検索コンテクスト誤答にも … 必要な文脈が入っているかなりうる配置「何を取ったか」 × Chunk A 深雪 … 司波達也の妹ノイズ「どう読んだか」答えに効く情報が埋もれていないか近いが不要な情報が誤答を誘わないか出力生成モデル差 Chunk C 近いが不要な人物情報 LLMは必要文脈とノイズが混在する関連性差を生むのは Retriever が選んだ検索コンテクスト Chunk B 声優情報 / キャラクター紹介 … このあと評価で見ていく論点同じ文脈でも解釈力で差が出るこの窓の中だけを手掛かりにこの場で答えを組み立てる RAGの回答品質は、「何を取れたか」と「その文脈をどう読めたか」の掛け算で決まる。

12.

Context Window と In-Context Learning (ICL) の基礎 Context Window とは？ LLMが一度に参照できる入力の作業領域。System・質問・検索コンテクスト・会話履歴などがこの窓の中に並び、その範囲だけを手掛かりに出力を作る。 RAGで実際に窓の中へ入るもの Context Window System / 役割評価ルール / 指示 retrieved chunks は、質問この場の答え方を決める Retrieved chunk 1 手掛かりとして働く。 In-Context Learning とは？重みを更新せずに、文脈の中のパターンから「この場でどう答えるべきか」を学ぶ振る舞い。 Retrieved chunk 2 会話履歴 RAGでは retrieved chunks が ICL の手掛かりになる。モデル出力評価の観点では、「検索で取れたか」だけでなく、「LLMがその文脈を活かせたか」も見ないと、原因を切り分けられない。 RAG評価のポイント量順序密度解釈長ければ良いではない重要情報の配置で効き方が変わる必要文脈に対するノイズ比率が効く同じ文脈でもモデル差が出る RAGの性能は、「どんな文脈を窓の中に入れたか」と「その場でどう使えたか」で決まる。

13.

RAGの基本フローと各回の関係 Embedding ベクトルDB RAGの性能は、単一要素の最適化ではなく、要素間の協調設計で決まる第 3回：チャンク戦略検索生データ第4回：Emb.比較 Embedding 何を渡すか Retriever コンテキスト第 4回：LLM 選択コンテキスト制御装置第3回：Adv. RAG 質問図参照： https://www.techfirm.co.jp/blog/vector-database https://g-gen.co.jp/useful/General-tech/llm-ai/ https://blog-ja.allganize.ai/allganize_rag-1/ どう振る舞わせるか制約付き生成第 3回：プロンプト戦略回答第 2回：評価

14.

RAGの基本フローと各回の関係 Embedding ベクトル DB RAGの性能は、単一要素の最適化ではなく、要素間の協調設計で決まる第3回：チャンク戦略検索生データ第4回：Emb.比較 Embedding Retriever 何を渡すかコンテキスト第4回：LLM FT 質問図参照： https://www.techfirm.co.jp/blog/vector-database https://g-gen.co.jp/useful/General-tech/llm-ai/ https://blog-ja.allganize.ai/allganize_rag-1/ 制約付き生成回答第2回：評価

15.

Chunking・Indexing・query_num の関係 Raw Documents Chunking Indexing Chunks Embedding chunk_size / overlap → 文書をどう切るか Retrieval Vector DB Indexing → 切った chunk を埋め込み化して Vector DB に登録する Top-k chunks query_num → 検索時に幾つチャンク取るか（Retriever の top-k）考え方の核 Chunking は「どう切るか」の設計／ Indexing は「検索できるように登録する」処理／ query_num は「何件取るか」の検索設定

16.

Chunk size と Overlap は「文脈の切り方」設計小さく切るChunk サイズ: 300 基準例 Chunkサイズ: 500 大きく切る Chunkサイズ: 1000 chunk overlap chunk chunk chunk overlap chunk chunk overlap 細かい手掛かりは拾いやすいた必要文脈が情報はまとまりやすいただしだし必要情報が分散しやすい 1〜数チャンクで取れる状態不要情報も入りやすい chunk Chunk size / Overlap は、必要文脈を救う効果と、分散・重複・ノイズの増加を見比べて調整する。

17.

Overlapは「網羅性」と「ノイズ」のトレードオフ Overlapを増やすメリット境界またぎの情報を救う重複チャンクが増える狙いは「最大」ではなく「必要十分」必要文脈が分断されにくい ContextRecall top-kの多様性が下がる必要文脈を拾いが上がりやすい「取れない」失敗を減らす評価で見るポイント Overlapを増やすデメリットちょうどよい重なりノイズ比率が上がる重複が検索枠を ContextPrecision 圧迫しない範囲が下がりうる Recall Precision top-k LLMの読み必要文脈を拾えたか不要文脈に埋もれないか重複で検索枠を消費しないかノイズに引っ張られないか Overlapは大きければ良いのではない。必要文脈を救う効果と、重複・ノイズの増加を見比べて調整する。

18.

「第２回 RAGを測るモノサシを作ろう」より RAG自動評価パイプライン（ Ragas x LLM-as-a-Judge ）質問 RAG 回答 run_advanced_rag() LLM as Judge Ragas 評価指標 _run_ragas_on_results() Ragasの評価指標 Faithfulness：回答がコンテキストに忠実か（ハルシネーション検出） AnswerRelevancy：回答が質問に対して適切か ContextPrecision / ContextRecall：Retrieverの性能評価 Ragasの評価指標は RAGの品質改善に直結する！評価スコア

19.

ここで、ハンズオン用コードを実行します。 ※ 本ハンズオンは、事前準備を完了していることを前提に進行します。コード実行用のキー取得、Google Colab の基本操作、Google Drive のマウント確認は、必ず事前に済ませてください。 ① Google Colab から Google ドライブのマウントの方法については、添付のドキュメントを読み事前確認お願いします。 https://docs.google.com/document/d/1wJEIOvWlEMdj-DwmvTPgVkWYUSvWsWNc/edit?usp=drive_link&ouid=106881452668834877355&rtpof=true& sd=true � ハンズオン用コードを動かすには、HuggingFace シークレットトークン（キー）が必要です。 HuggingFace シークレットトークン取得参考記事： https://qiita.com/so9_Monodzukuri_AI/items/388e9b546ecb2ecfc420 � Google Colab のシークレット機能の使い方 https://note.com/npaka/n/n79bb63e17685 本日動かすのは「03-2_アドバンス RAG一括回答アプリ _v9-2.ipynb」のみ

20.

3回目：機能満載 RAG実験用アプリ群 ● 単問回答 / 単問連続回答 / CSV 一括回答 / 履歴表示 / log 保存 ● Embedding：ruri-v3-130m ● Generator: qwen3-8b ● Chunk 戦略 ● Prompt 戦略 ● Advanced RAG

21.

RAGの基本フローと各回の関係 Embedding ベクトルDB RAGの性能は、単一要素の最適化ではなく、要素間の協調設計で決まる第 3回：チャンク戦略検索生データ第4回：Emb.比較 Embedding 何を渡すか Retriever コンテキスト第 4回：LLM 選択コンテキスト制御装置第3回：Adv. RAG 質問図参照： https://www.techfirm.co.jp/blog/vector-database https://g-gen.co.jp/useful/General-tech/llm-ai/ https://blog-ja.allganize.ai/allganize_rag-1/ どう振る舞わせるか制約付き生成第 3回：プロンプト戦略回答第 2回：評価

22.

RAGの基本フローと各回の関係 Embedding ベクトルDB RAGの性能は、単一要素の最適化ではなく、要素間の協調設計で決まる検索生データ第4回：Emb.比較 Embedding Retriever コンテキスト第 4回：LLM FT 制約付き生成質問図参照： https://www.techfirm.co.jp/blog/vector-database https://g-gen.co.jp/useful/General-tech/llm-ai/ https://blog-ja.allganize.ai/allganize_rag-1/ どう振る舞わせるか第 3回：プロンプト戦略回答第 2回：評価

23.

第3回一括 RAG回答アプリの 7つのプロンプト設計 simple → detail → optimized v1〜v5 / detail を土台に弱点別で狙い撃ちプロンプト設計の中心ターゲットにする失敗・違い prompt_simple 最小ルールで、文脈が無ければ無回答まずは基準線。軽いが、取りこぼし・過剰な無回答が出やすい prompt_detail 対象特定・列挙/表・個数/除外条件まで明示精読型の土台。「どのブロックだけを見るか」を固定して誤読を抑える optimized v1 質問を先に整理（何を答えるか／除外条件／複数回答）質問の読み違いを減らす。複数回答や除外条件の落としを防ぐ optimized v2 候補を全部集めてから絞る optimized v3 主語・対象・対応関係を特別チェック「誰が誰に」「誰がどれに対応するか」の取り違えを減らす optimized v4 無回答にする前に、別表現・言い換えを再確認 simple系で起きた過剰な「該当情報なし」を抑える optimized v5 限定語・修飾語・数条件を落とさない「唯一」「何人目」「すべて」などの重要語の取りこぼし対策 1件見つけた時点で止まる誤りを抑える。一覧・表での取りこぼし対策ポイント：detail で読み方を固定し、optimized v1〜v5 で弱点ごとにプロンプトをチューニングしている

24.

[beta]

Prompt の比較
prompt_simple
prompt_simple =

ChatPromptTemplate.from_template('''\以下

の文脈だけを踏まえて日本語で質問に回答して
ください。
文脈に質問に関する情報がないときには「文脈
には該当する情報は含まれていません。
」と回答
してください。

文脈: """
{context}
"""
質問: {question}

''')

prompt_simple は、

回答条件だけを最小限
に指示

prompt_detail
# 共通 system prompt（グローバル変数）
prompt_detail =
ChatPromptTemplate.from_template(r'''\
あなたはRAGアシスタントです。以下の文脈だけを根拠に、
日本語で質問に答えてください。
文脈に書かれていないことは推測しないでください。

ルール:
- 回答は文脈から直接言えることだけを書く。
- 文脈にない固有名詞・数値・具体例を勝手に追加しない。
- 根拠は文脈からそのまま1〜2件抜粋する。
- 同じ根拠を重複して出さない。
- 根拠が見つからない場合だけ「文脈には該当する情報は含
まれていません。」と答える。
- 文脈に矛盾があり断定できない場合だけ「文脈の根拠だけ
では断定できません。」と答える。
質問の読み取りルール:
-「〜以外」「〜を除いて」「〜の他に」がある場合は、その語
を回答から除外する。
- 個数指定（1つ、2つ、3つなど）がある場合は、その数に合
わせる。
- 同じ条件に一致する候補が複数ある場合は、1つに決めつけ
ず、条件に合うものをすべて答える。
列挙・表・一覧のルール:
- まず質問が指している対象カテゴリ・対象行・対象ブロッ

クを特定する。
- 回答は、その対象ブロックの中に書かれている情報だけを使
う。

- 別カテゴリ、別段落、別説明ブロックの候補を混ぜない。
- 対象ブロックの中で、同じ条件に一致する候補が複数ある場

合は漏らさず拾う。
- 表の中で語が改行やセル分割で分かれていても、同じ項目
としてつながる場合はまとめて読む。

答え方:
1. 質問が何を対象にしているかを特定する。
2. 文脈の中から、その対象に対応する1つの列挙・表・説明
ブロックを選ぶ。
3. そのブロックの中だけから候補を拾う。
4. 除外条件や個数指定を反映する。
5. 候補が複数あれば、条件に合うものをすべて答える。
文脈:
"""
{context}
"""
質問:
{question}
出力形式:
- 根拠:
（抜粋1）
（抜粋2）
- 回答:
（最終回答）

''')

prompt_detail は、候補
収集 → 条件照合 → 回答
確定の流れを指示する

CoT (Chain of
Thought) 構造を取って

いる

25.

RAGの基本フローと各回の関係 Embedding ベクトルDB RAGの性能は、単一要素の最適化ではなく、要素間の協調設計で決まる第 3回：チャンク戦略検索生データ第4回：Emb.比較 Embedding 何を渡すか Retriever コンテキスト第 4回：LLM 選択コンテキスト制御装置第3回：Adv. RAG 質問図参照： https://www.techfirm.co.jp/blog/vector-database https://g-gen.co.jp/useful/General-tech/llm-ai/ https://blog-ja.allganize.ai/allganize_rag-1/ どう振る舞わせるか制約付き生成第 3回：プロンプト戦略回答第 2回：評価

26.

RAGの基本フローと各回の関係 Embedding ベクトル DB RAGの性能は、単一要素の最適化ではなく、要素間の協調設計で決まる検索生データ第4回：Emb.比較 Embedding Retriever コンテキスト第4回：LLM FT コンテキスト制御装置第3回：Adv. RAG 質問図参照： https://www.techfirm.co.jp/blog/vector-database https://g-gen.co.jp/useful/General-tech/llm-ai/ https://blog-ja.allganize.ai/allganize_rag-1/ 制約付き生成回答第2回：評価

27.

Advanced RAG はなぜ必要か基本RAG 検索漏れ必要文脈が取れない質問 → 検索 → 弱点ごとに強化ポイントが違う Hybrid Search Reranking 文脈 → 生成ノイズ混入候補の並び順を直す Multi-Query 意味検索＋語検索を足す質問を言い換えて広げる近いが不要な文脈が混ざる質問表現が弱い聞き方が悪くて当たりに届かない検索経路の選択ミス検索経路の判断がずれる HyDE LLM Route 仮の答えを手掛かりに探す検索経路を切り替える Advanced RAG は「全部盛り」ではなく、弱点に応じて選ぶ

28.

アドバンス RAG 全体マップ Reranking Hybrid Search Multi-Query HyDE LLM Route 候補を並べ替える異なる検索を足し合わせる質問を言い換える仮の答えを作って検索する検索先そのものを切り替える HyDE Route 強化する場所 Rerank Hybrid 検索結果の順位 ◎ 検索漏れ対策 △ 質問表現の弱さ対策 △ △ ◎ ◎ 検索経路への分岐 × × × × ○ ◎ Multi-Q ○ ◎ ○ ◎ Advanced RAG は「全部盛り」ではなく、弱点に応じて強化ポイントが違う △ ○ △ ◎

29.

第3回RAGハンズオン新5問で体験する RAGチューニング・ガイドライン 0/5 → 2/5 → 4/5 を、参加者自身の実行結果として体験する 0/5 岩盤条件 2/5 分岐改善 4/5 限界確認教材化の狙い最高点探しではなく「何が効くか」を見る

30.

魔法科高校新５問新５問新元元 Q1 Q5 新元 Q2 Q9 新元 Q3 Q11 新元 Q4 Q12 新元 Q5 質問 15問 Q15 「魔法科高校の劣等生」で、司波達也と九島光宣はどちらも「精霊の眼（エレメンタル・サイト）」を持っています。2人の知覚の得意分野はそれぞれ何ですか？「魔法科高校の劣等生」に出てくる戦略級魔法「オゾンサークル」は誰の魔法ですか？正解司波達也は分解・再成の特性から能動的な知覚に優れ、九島光宣は仮装行列（パレード）の特性から受動的な知覚に優れ、意識を向けていない状態でも遠方の魔法の兆候を感じ取れる。カーラ・シュミットとウィリアム・マクロード「魔法科高校の劣等生」のキャラクター牛山欣治は社内で司波達也が「ミスター・シルバー」と呼ばれるのに対し、どのようミスター・トーラスに呼ばれていますか？『メイジアン・カンパニー』において、司波達也が設立した三「メイジアン・ソサエティ」「ステラ・ジェレネーター」「一般つの組織・法人の名前をすべて挙げてください。社団法人メイジアン・カンパニー」。「トーラス・シルバー」に関して、司波達也がその名で製品を世に送り出す際に組んでいる人物と、その正体を確信した第一高校の生徒をそれぞれ答えてください。組んでいる人物は牛山欣治で、正体を確信した第一高校の生徒は中条あずさ。

31.

第3回RAGハンズオン実行計画：全員共通 → 分岐 1 → 分岐 2 で 5パターンを揃える実行(1) ＜分岐 1＞＜分岐 2＞実行(2) 分岐1-1 実行(3) 分岐2-1 chunk戦略 Basic RAG 400/50/5 prompt_simple 期待：2/5 prompt戦略 Basic RAG 300/50/5 prompt_detail 期待：4/5 5条件の結果を並べる全員共通 Basic RAG 300/50/5 prompt_simple 期待：0/5 全体共有「何を変えると、実行(2) 分岐1-2 実行(3) 分岐2-2 Advanced RAG 組み合わせ Hybrid Search_BM25 300/50/5 prompt_simple 期待：2/5 何が救われるか」が分かる HyDE 400/50/5 prompt_detail 期待：4/5 04

32.

新5問事前実験結果位置づけ条件変更する要素結果正解不正解考察なし新Q1〜新Q5 まず全問不正解から始める。ここを出発点にする。 (1) 岩盤条件 Basic RAG + 300/50/5 + prompt_simple 初期状態・全員共通 0/5 (2) chunk戦略 Basic RAG + 400/50/5 + prompt_simple chunk条件だけ変更 2/5 (3) Advanced RAG Hybrid Search_BM25 + 300/50/5 + prompt_simple Advanced RAG だけ変更 (4) prompt戦略 Basic RAG + 300/50/5 + prompt_detail (5) 組み合わせ最終条件 HyDE + 400/50/5 + prompt_detail (新Q2), 新Q3 新Q1, (新Q2), 検索文脈の切り方が効く。chunk戦略だ新Q4, 新Q5 けで0/5から2/5へ改善する。 2/5 新Q1, 新Q4 Hybrid Search_BM25で同じ新Q2, 新Q3, 新 300/50/5・prompt_simpleでも2/5へ改善する。再現性が高く、Advanced Q5 RAGの教材条件として使いやすい。 promptだけ変更 4/5 新Q1〜新Q4 新Q5 (元Q15) chunk + Advanced RAG + prompt 4/5 新Q1〜新Q4 新Q5 (元Q15) (1/5) 読ませ方の指示で大きく改善する。 prompt_detailの効果を体験する。 chunk + Advanced RAG + promptを重ねてもQ15型は残る。6回再現でも4/5で安定。既に第4回用の実験では元15問で 15/15の条件を確認済み。組み合わせ条件により正解する問題が変化する。現状のベストの条件でも Q15型の問題は未攻略

33.

魔法科高校新５問新５問新元元 Q1 Q5 新元 Q2 Q9 新元 Q3 Q11 新元 Q4 Q12 新元 Q5 質問 15問 Q15 「魔法科高校の劣等生」で、司波達也と九島光宣はどちらも「精霊の眼（エレメンタル・サイト）」を持っています。2人の知覚の得意分野はそれぞれ何ですか？「魔法科高校の劣等生」に出てくる戦略級魔法「オゾンサークル」は誰の魔法ですか？正解司波達也は分解・再成の特性から能動的な知覚に優れ、九島光宣は仮装行列（パレード）の特性から受動的な知覚に優れ、意識を向けていない状態でも遠方の魔法の兆候を感じ取れる。カーラ・シュミットとウィリアム・マクロード「魔法科高校の劣等生」のキャラクター牛山欣治は社内で司波達也が「ミスター・シルバー」と呼ばれるのに対し、どのようミスター・トーラスに呼ばれていますか？『メイジアン・カンパニー』において、司波達也が設立した三「メイジアン・ソサエティ」「ステラ・ジェレネーター」「一般つの組織・法人の名前をすべて挙げてください。社団法人メイジアン・カンパニー」。「トーラス・シルバー」に関して、司波達也がその名で製品を世に送り出す際に組んでいる人物と、その正体を確信した第一高校の生徒をそれぞれ答えてください。組んでいる人物は牛山欣治で、正体を確信した第一高校の生徒は中条あずさ。

34.

第3回（RAGを改善する）で何をいじっているのか Raw Docs Chunk戦略文書をどう切るかを変える Chunks 検索文脈 Advanced RAG 例：size / overlap / splitter 検索の取り方・並べ方・広げ方・分岐の仕方を変える Prompt戦略 Rerank Hybrid Multi-Q HyDE Route 同じ文脈をどう読ませるかを変える回答例：simple / detail / 読み取りルール第3回は「文書の切り方」「 LLMの読み方」「検索の強化点」の 3層を見比べる回結論： Chunk戦略・ Prompt戦略・ Advanced RAG は強化する場所が違う ※ただし、RAGにはまだ重要な未検討要素がある：EmbeddingとGenerator (LLM) ➡ 第４回へ続く

35.

RAGの仕組みを理解して改善し続けよう LangChain Family × Gradio で作る「作る → 測る → 改善 → 選択→ 自律化」5回シリーズ 2回目 1回目 3回目測る改善する動いて中身も見える RAGアプリ Ragas × LangSmith chunk & prompt 戦略 / Advanced RAG ・ログ run_id）保存・Gradioで体験（ Relevance 作る・Retriever / Prompt / LLM ・検索と生成を分解・Faithfulness / ・悪い例を追跡・chunk_size / overlap ・当たりチャンク探索・改善の再現性 4回目 5回目選択タスクに応じた generator 選択 / API 利用・Embedding選択・API利用・モデルサイズ選択 6/23(火) 予定自律化 LangGraph / Agentic RAG ・検索 / 推論 / 生成・ループで精度改善・運用に近い形へ 7/21(火) 予定シリーズの狙い： RAGアプリをベースに「作る → 測る → 改善 → 選択 → 自律化」の流れを体験し、検索・生成・評価・モデル選択を組み合わせた、継続的な改善サイクルを理解する。

36.

4回目：機能満載 RAG実験用アプリ群 ● 単問回答 / 単問連続回答 / CSV 一括回答 / 履歴表示 / log 保存 ● Embedding：ruri-v3-130m / sarashina-embedding-v2-1b / OpenAI Embedding ● Generator: qwen3-8b / 14b / OpenAI APIs ● Chunk 戦略 ● Prompt 戦略 ● Advanced RAG

37.

10回シリーズ： RAG の基礎から実践まで第一部基礎編：RAGの仕組みを理解して改善し続けよう 1回目作る動いて中身も見える RAGアプリ・Retriever / Prompt / LLM ・ログ run_id）保存・Gradioで体験（ 2回目測る Ragas × LangSmith ・検索と生成を分解・Faithfulness / Relevance ・悪い例を追跡 3回目改善する chunk & prompt 戦略 / Advanced RAG ・chunk_size / overlap ・当たりチャンク探索・改善の再現性 6/23(火) 予定 7/21(火) 予定 4 回目 5回目選択タスクに応じた generator 選択 / API 利用・Embedding選択・API利用・モデルサイズ選択自律化 LangGraph / Agentic RAG ・検索 / 推論 / 生成・ループで精度改善・運用に近い形へ第二部実践編：現場で扱うための拡張と運用 GPU 効率利用 LLM 量子化 6回目 DBを整える（8月予定）図表を含むドキュメントの前処理（9月予定） 7回目 8回目関係を知る目をもつ Graph RAG （10月予 VLM RAG （11月予定）定） 9回目運用 MLOpsを組み込んだ実用的なRAGｼｽﾃﾑ（12月予定）

38.

APPENDIX

39.

Indexing と query_num は役割が違う query_num の流れ Indexing の流れ Chunks Embedding化登録質問検索 Top-k chunks Vector DB に保存ここは「検索できる土台」を作る処理＝まだ質問していない段階 Indexing = chunk を埋め込み化して Vector DB に登録すること query_num は、この段階で何チャンク返すか＝ Retriever の top-k を決める設定 query_num = 検索時に何チャンク取るかを決めること登録の話と、検索時に何件取るかの話を分けて考える

40.

Chunk戦略別 Retriever 作成法同一I/Fの builder で mode だけを切り替え、chunking 戦略を横比較できる設計 Factory layer（実装の共通入口）差分は chunking 段だけに閉じ込める def build_retriever(mode, docs, embeddings, **kwargs): splitter = make_splitter(mode, **kwargs) chunks = splitter.split_documents(docs) vectordb = build_vectorstore(chunks, embeddings) return vectordb.as_retriever(**kwargs) # mode = "recursive" | "sentence" | "semantic" mode ごとの差分 chunker だけ差し替え → 後段は共通 Raw docs → Chunker →Embed / Store → Retriever mode 選択 1) Recursive • 文字数ベースで安定した分割 • baseline として再現しやすい size / overlap • 長文・多様文書でまず試しやすいを明示しやすい 2) Sentence • 文境界を尊重して分割 • 引用抽出や QA で読みやすい • 過分割を抑えたい時に有効文脈切れが少なく説明しやすい 3) Semantic • 意味の切れ目で chunk を作る • トピック密度の高い資料に向く • 可変長になりやすいが凝集性が高い設計意図 • 評価コードは mode 切替のみで再利用 • chunk_mode を metadata に残すと分析しやすい品質寄りの検証候補

41.

比較実験は何を見ればよいのか星取表を見る前に、改善とみなす観点をそろえる 1 正答率 2 検索漏れ 3 ノイズ耐性 4 再現性最終回答が正しくなったか「〇が増えたか」だけでなく、誤答の質が変わったかも見る必要文脈を取れるようになったか ContextRecall が上がる系の手法かを確認する不要文脈に引っ張られにくくなったか Reranking や prompt_detail で誤答の型が変わるかを見るたまたま当たったのではなく、狙って改善できたかコードで再実験し、評価アプリで同条件比較する第3回は「どの手法が強いか」だけでなく、「何がどう改善したか」を読む回

42.

Advanced RAG：第2回の評価と第 3回の改善はどうつながるかどの手法が、どの評価観点を改善しやすいかを見る手法主に効く場所効きやすい評価狙う弱点一言でいうと Reranking 並び順 ContextPrecision 不要チャンク混入取れた候補を賢く並べる Hybrid Search 検索漏れ ContextRecall 意味だけ/語だけでは弱い意味検索とキーワード検索を足す Multi-Query 質問表現 Recall / Relevancy HyDE 検索語の弱さ Recall / Relevancy 短い質問で手掛かり不足仮の答えを先に作って探す LLM Route 探索先選択ケース依存ローカルかWebかを誤る探しに行く先を先に決める別名・言い換えに弱い質問の投げ方を増やす第3回は、第 2回で分解して見た評価結果を受けて、「どの弱点にどの改善を当てるか」を考える回

43.

Reranking：候補の中から、答えに効く文書を前に出す Dense 検索質問再評価候補プール上位10件など Rerank_v1 「再採点の結果だけで」上位を選び直す • 効く場面：候補は取れているが、不要チャンクが混ざる • 主に改善したい指標： ContextPrecision CrossEncoder 関連度を再採点並べ替え生成最終文脈上位 3〜5件 Rerank_v2 Dense上位候補を少し保護しつつ、再採点と融合して安定化 • v2は「再順位付けしすぎ」を防ぎやすい • 講義では v1 → v2 の進化として見せやすい考え方の核：検索そのものを変えるのではなく、「取れた候補の並び順」を賢くする回答

44.

Reranking v1 / v2 の違い：同じ概念でも実装で性能が変わる Reranking は『検索で取れた候補の並び順を賢くする』手法。ただし、最終文脈の選び方で安定性が大きく変わる。 Dense検索候補プール取得 CrossEncoder質問×文書を再採点 Rerank_v1：再採点結果だけで選び直す実装の流れ ① Dense検索で候補プールを取得 ② CrossEncoderで候補を再採点 � rerank_score 上位だけを最終文脈へ効く場面・候補は取れているが、不要チャンクが混ざる・ContextPrecisionを上げたい弱点・CrossEncoderを過信しやすい・Dense上位の有力候補まで落とすことがある・“並べ替えすぎ ”で結果が揺れやすい最終文脈上位 3〜5件 LLM生成回答 Rerank_v2：Dense上位を保護して融合する実装の流れ ① Dense検索で候補プールを取得 ② CrossEncoderで候補プール全体を再採点 � Dense上位2件を保護 � Dense 0.7 + Rerank 0.3 でスコア融合 � 安定化した候補を最終文脈へ狙い・Basic で拾えている有力候補を守る・RAG Rerankの改善効果も使う・“再順位付けしすぎ ”を防ログぐ・CrossEncoder rerank full ・pool Stable rerank selection Reranking は同じ『候補を並べ替える』コンセプトでも、最終文脈の採用ポリシーで性能が変わる実例。 v1 は Rerank効果が見えやすい／ v2 は Dense上位を守るため実用上安定しやすい。

45.

Hybrid Search：意味検索とキーワード検索を足し合わせる Dense 質問 Sparse Dense retrieval 上位選抜意味で近い文書融合 BM25 retrieval RRF または Weighted Sum 語が合う文書 • Denseだけだと、固有名詞や短いキーワードを落とすことがある • Sparseだけだと、言い換えや意味の近さに弱い生成最終文脈 • 両方の長所を足して、検索漏れを減らす • 主に改善したい指標：ContextRecall 考え方の核：「意味で探す」だけでも「語で探す」だけでも足りないので、両方の証拠を束ねる回答

46.

BM25 の要点 ● 概要：Best Matching 25 の略。検索でクエリと文書の関連度を付ける代表的な疎ベクトル手法。 ● 仕組み ○ TF：語の出現回数。多すぎると効果を飽和させる。 ○ IDF：希少語ほど重みを上げる。 ○ 長さ正規化：文書が長いほど補正して公平に。 ○ スコア式： ■ k1k_1(≈1.2–2.0)：TF飽和度 ■ bb(≈0.5–0.8)：長さ補正の強さ ● 長所：キーワード一致に強く、高速でチューニングも容易。 ● 短所：同義語や文脈を捉えられないため、意味理解が必要な検索ではベクトル検索との併用検索）が推奨される。（ハイブリッド

47.

Multi-Query：質問を複数の言い方に増やして、検索漏れを減らす LLMで言い換え質問 Query 1 Query 2 Query 3 検索検索検索 • 1つの聞き方だけでは、欲しい文書に届かないことがある • 同じ意味を別表現で投げて、拾える根拠を増やす取得結果 A / B / C ... A / D / E ... B / F / G ... 統合重複を整理し上位を残す生成回答 • 効く場面：質問表現があいまい、別名が多い、言い換えが多い • 主に改善したい指標：ContextRecall と AnswerRelevancy 考え方の核：文書を変えるのではなく、質問の投げ方を増やして当たりチャンクを引きやすくする

48.

HyDE：まず「仮の答え」を作り、その答えを手がかりに検索するまず仮説質問 LLMが仮の回答を 1文仮説を検索語にで作る • 元の質問が短すぎると、検索語として弱いことがある • 仮説回答を作ると、検索に使う情報量が増える Dense retrieval 仮説に近い文書根拠化生成取得文脈から本回答を作る • 効く場面：答えの形がある程度想像できる質問 • 注意点：仮説がズレると、ズレた文書を引く危険もある考え方の核：先に「それっぽい答え」を作ってから探すことで、検索クエリを豊かにする回答

49.

LLM Route：今回の実装では「検索経路判定＋安全なフォールバック」標準説明ではなく、このノートブック実装に即した整理判定質問 LLM Router route判定 JSONのみ返す local route = langchain_document ローカル文書検索 Dense retriever 選ばれた文脈を回答生成へ渡す回答 web {"route":"langchain_document "} {"route":"web"} fallback route = web Tavily検索 APIキーがある時だけ Web結果なしまたは APIキーなし実装の要点： LLMが route を JSON で判定し、 langchain_document または web を選ぶ。 web ルートは TAVILY_API_KEY がある場合のみ Tavily を使う。結果が空ならローカル文書検索へフォールバックする。第3 回では発展機能として、Web検索そのものより「どこを探すかを先に決める」考え方を押さえれば十分。

50.

なぜQ15は難しいのか？ Q15 「トーラス・シルバー」に関して、司波達也がその名で製品を世に送り出す際に組んでいる人物と、その正体を確信した第一高校の生徒をそれぞれ答えてください。。登場人物 wiki_01.txt 登場人物 wiki_02.txt 登場人物 wiki_04.txt 技術者・事業側の文脈第一高校・生徒側の文脈人物・関連情報の補助文脈「トーラス・シルバー」として製品を世に出す枠組み中条あずさが正体を確信する手がかり人物対応を取り違えないための周辺情報・参照断片必要な統合難しさの本質 1 検索だけでは足りない 3ファイルに分散した断片を、同一質問内で同時に回収する必要がある。「牛山欣治」＋「中条あずさ」を別々の文脈から対応づける 2「誰」と「誰」の対応づけが必要牛山欣治＝共同開発者／中条あずさ＝正体を確信した生徒、という役割分担を混同しやすい。 3文脈統合型の最難問単一チャンクの引用ではなく、複数文脈を統合して初めて完全正答になる。

51.

Colab無料版で T4 GPU に接続できない場合があります作成日：2026/05/21 結論：無料版 ColabのT4 GPUは「使えることがある」が、接続可否・ GPU種別・利用可能時間は保証されない。 1. 公式情報として押さえる点 2. ハンズオンでの扱い 3. 質問が出た時の説明無料版はGPU/TPU等の高価なリソースへのアクセスが制限される。利用制限・アイドルタイムアウト・最大VM寿命・利用可能GPU種別は時間とともに変動する。 Googleは具体的な上限値を公開していない。無料版ではGPUアクセスは保証・無制限ではない。本ハンズオンは、無料版Colabでの実行を想定 T4接続は保証しない。するが、 GPUが不要な作業ではランタイムをCPUに戻し、不要なGPU接続を避ける。事前準備・Drive保存・再実行可能なログ設計で、途中切断に備える。複数アカウントで制限回避する運用は推奨しない。「T4が出ない」のは、コードの不具合とは限らない。 Colab側の混雑状況、過去のGPU利用量、現在のリソース配分で変わる。時間を置く／ランタイムを切る／必要なセルだけ実行する、などで対応する。重要：固定の回復時間や利用可能時間は断定しない。 Colab無料版は教育・実験には便利ですが、T4 GPUを必ず確保できる環境ではありません。今回のハンズオンでは、接続できない場合も想定して進めます。引用・参照リソース（参照日： 2026/05/21）・Google Colab FAQ: https://research.google.com/colaboratory/faq.html ・Colab Paid Services Pricing: https://colab.research.google.com/signup 注：Colabの利用制限は動的に変動するため、本スライドは作成日時点の公式情報に基づく整理。将来の仕様変更時は再確認が必要。

52.

配布物リスト 1. アプリコード（ Colab notebook) 2. ● 03-1_アドバンスRAG単問回答アプリ_v8.ipynb ● 03-2_アドバンス RAG一括回答アプリ _v9-2.ipynb ➡ ※パッチコード：ハンズオンで使用 ● 02-3_ログ一括評価アプリ_v7-2.ipynb ➡ 2回目の評価用アプリ改良版ベクトル DB用ドキュメント（txt_dataフォルダ内） ● 魔法科高校の劣等生_登場人物wiki_01.txt 〜魔法科高校の劣等生_登場人物wiki_05.txt の5つのテキストファイル 3. 魔法科高校質問 ● 魔法科高校15問.csv ／新魔法科高校5問.csv ➡ ベンチマーク・ハンズオン用データセット 4. 補助ドキュメント ● colab_mount_cd_beginner_guide.docx ➡ Google Colab の基本的使用法ガイドライン ● 260503_新5問ハンズオン設計レポート_v5-2.docx ➡ ハンズオン用再現性実験記録 ● 260501_BasicRAG_prompt_simple_チャンク戦略_v3.docx ➡ 15問実験記録 ● 260501_simple_アドバンスRAGスクリーニング_詳細分析レポート_v2_考察追加版.docx ➡ 15問実験記録 ● (※) 260501_Qwen3-8B_AdvancedRAG_prompt_15条件_詳細分析レポート_v2.docx ➡ 15問実験記録 ※この「260501_Qwen3-8B_AdvancedRAG_prompt_15条件_詳細分析レポート _v2.docx」には、第 4回で扱う generator 選択・モデル比較につながる内容も一部含まれます。第3回では、主に「 chunk / prompt / Advanced RAG による改善と、残る難問の位置づけ」を確認するための参考資料として配布します。

53.

配布アプリコード：ログ一括評価アプリ _v7-2 Ragas の LLM-as-a-judge に使用する OpenAI API を・gpt-4o-mini・ gpt-4.1-mini・ gpt-5.4-mini から選択可能とした。

54.

RAGの仕組みを理解して改善し続けよう〜 LangChain Family × GradioによるRAGアプリ開発〜第１回：動いて中身も見える RAGを作って触ろう〜 LangChainで基本RAGアプリ開発〜第２回： RAGを測るモノサシを作ろう〜 Ragas × LangSmithでRAG評価アプリ開発〜第３回： RAGを最適化しよう〜チャンクとプロンプトの戦略＋アドバンス RAGアプリ開発〜第４回： RAGの頭脳を選択しよう（改訂版）〜タスクに応じた generator 選択 / API 利用〜第５回：進化系 RAGに挑戦〜 LangGraphでAgentic RAG開発〜

【Paper&Hacks Vol.85】チャンク／プロンプト戦略＋アドバンスRAGアプリハンズオン

松尾研LLMコミュニティ

関連スライド

2024Fall 大規模言語モデル(LLM)講座特別回：LLMの自己修正〜OpenAI o1 の関連研究〜

松尾研LLM開発プロジェクト “Tanuki” 開発報告会 Vol.1

松尾研LLM開発プロジェクト “Tanuki” 開発報告会 Vol.3

松尾研LLM開発プロジェクト “Tanuki” 開発報告会 Vol.2

LLMATCH [Season1] 最終成果報告_石田憲太郎

LLMATCH [Season1] 最終成果報告_渡辺悠介

各ページのテキスト

【Paper&Hacks Vol.85】チャンク／プロンプト戦略＋アドバンスRAGアプリハンズオン

松尾研LLMコミュニティ

関連スライド

2024Fall 大規模言語モデル(LLM)講座 特別回：LLMの自己修正〜OpenAI o1 の関連研究〜

松尾研LLM開発プロジェクト “Tanuki” 開発報告会 Vol.1

松尾研LLM開発プロジェクト “Tanuki” 開発報告会 Vol.3

松尾研LLM開発プロジェクト “Tanuki” 開発報告会 Vol.2

LLMATCH [Season1] 最終成果報告_石田憲太郎

LLMATCH [Season1] 最終成果報告_渡辺悠介

各ページのテキスト

2024Fall 大規模言語モデル(LLM)講座特別回：LLMの自己修正〜OpenAI o1 の関連研究〜