--- title: 【Paper&Hacks Vol.85】チャンク／プロンプト戦略＋アドバンスRAGアプリハンズオン tags: author: [松尾研LLMコミュニティ](https://www.docswell.com/user/matsuo-lab_llm) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/GE8DZM2VED.jpg?width=480 description: 本イベントは、原則毎週火曜日20:00から松尾・岩澤研究室 LLMコミュニティが主催するLLMに関する輪読会 & 実装のオンラインイベントです。 【アーカイブはこちら】 https://youtu.be/vYn8-m_Yht8?si=-t9jx5q56j3o4rEl 【イベント概要】 対象: 普段から論文を読んでいる/普段からLLMの実装を行なっている方々 レベル: ★★★★☆　(Expert) 発表者: 井伊篤彦（異業種データサイエンス研究会®︎代表） タイトル: 『チャンク／プロンプト戦略＋アドバンスRAGアプリハンズオン』 発表カテゴリ: やや実践寄り（ハンズオンやコード解説が多め） イベント内容：（５回シリーズ）「RAGの仕組みを理解して改善し続けよう」の第３回目。今回は、RAGの各種設定を最適化する方法を紹介し、実際にRAGアプリのコードを実行して効果を確認してもらいます。 扱う論文：ハンズオンのためなし 【松尾研LLMコミュニティについて】 松尾研LLMコミュニティは、「大規模言語モデルについて知って学べるオンライン空間」として、東京大学松尾・岩澤研究室が運営するコミュニティです。現在、学生を中心とした16,000名以上が、原則無償で参加しています。 ※ 現在、松尾研LLMコミュニティへの新規参加申込み受付を停止しております。 ーーー 【松尾研大規模言語モデル講座開講のお知らせ】 昨年大好評だった松尾研大規模言語モデル講座を今年も完全オンラインにて開講いたします！ 今年は内容をグレードアップし、大規模言語モデル1,2,3の3段階構成でお送りすることになりました。 生成AIの基盤技術である大規模言語モデル（LLM）の原理からアーキテクチャーまで取り扱う実践的な講義となっております。座学のみならず演習を通して、手を動かしながら技術を深く理解し、幅広いトピックを網羅します。 詳細は以下のURLからご覧ください！ 大規模言語モデル1：https://x.gd/Dy8yg ※事前に受講申込が必須 ※参加対象者やその他条件がございますので、必ずHPをご確認下さい。 published: August 04, 26 canonical: https://www.docswell.com/s/matsuo-lab_llm/ZR8YVJ-Paper&HacksVol.85 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/GE8DZM2VED.jpg) # Page. 2 ![Page Image](https://bcdn.docswell.com/page/LELMD32R7R.jpg) （５回シリーズ）RAGの仕組みを理解して改善し続けよう 〜 LangChain Family × GradioによるRAGアプリ開発 〜 第３回：RAGを最適化しよう 〜 チャンク／プロンプト戦略＋アドバンス RAGアプリ開発〜 2026/5/26異業種データサイエンス研 究会 ® 代表井伊 篤彦 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/4JMYPD8PJW.jpg) 井伊篤彦 Who am I? 1963年（昭 38年）生まれ。京都大学工学部修士課程（合成化学専攻）終了。大学 和 院で量子化学を副専攻。 前職は一部上場大手日用品製造メーカー研究所。社内で各種製品開発を行うかた わらコンピューターケミストリーを手掛け、化学分子 3D表示ソフト等をC言語を用い て開発。 その後、海外駐在やグローバルな商品開発マネージャーを経て、2017年からAI及 びxR (VR, AR, MR) を用いた新規プロジェクトをゼロから立ち上げ率いた。AIプロ ジェクトでは、自ら機械学習モデルを開発した。 2019年に FBコミュニティ「異業種データサイエンス研究会 16個のFBコミュニティ を運営してい ®」を立ち上げる。現在 る。 プログラミングスクールで AIプログラミングの指導 をする傍ら、 年間数十回のデータサイエンス・ AI関連の セミナーを実施 している。 # Page. 4 ![Page Image](https://bcdn.docswell.com/page/PJR9145Y79.jpg) ハンズオン用コード（ 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 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/PEXQY2K4JX.jpg) 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アプリをベースに「作る → 測る → 改善 → 選択 → 自律化」の流れを体験し、検索・ 生成・評価・モデル選択を組み合わせた、継続的な改善サイクルを理解 する。 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/3EK93M5PED.jpg) 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/ システム プロンプ ト # Page. 7 ![Page Image](https://bcdn.docswell.com/page/L73WGYK475.jpg) 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 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/87DK1535JG.jpg) 魔法科高校 15問は「 RAG実験道具」 小型でも、検索・列挙・統合・取り違えを観察できるベンチマーク 15問のタイプ分散 単純な事実確認だけでなく、実務RAG で起き やすい失敗型を意図的に混在 単純事実確認 人物・属性対応 複数正答列挙 組織名列挙 人物関係対応 観察できること 複合文脈統合 DB用5分割テキスト 重点問題が診断軸になる 1つにまとめすぎず、細かく分けすぎ ない。 に近い距離感 「情報が散らばる」実務RAG を作る。 話題のまとまり を保持 巨大文書の偶 然ヒット抑制 複数ファイル 横断を再現 retrieval失敗 を追跡しやすい chunk戦略で改善する問題 promptで救える問題 Q12 Q15 複数要素列挙 prompt_detailで改善し やすい 複合文脈統合 generator 差が見える超難問 generator変更で残る問題を突破 「最高点探し」ではなく、失敗要因を分解し、次の仮説へつなぐための小型ベンチマーク # Page. 9 ![Page Image](https://bcdn.docswell.com/page/VJPKQG4DE8.jpg) 魔法科高校 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 一色家の固有魔法「神経電流撹乱（神経撹乱）」について、一条家では誰が使えず、誰がその適性を受け継いでいますか？ 「トーラス・シルバー」に関して、司波達也がその名で製品を世に送り出す際に組んでい る人物と、その正体を確信した第一高校の生徒をそれぞれ答えてください。 説明型（魔法の性質・用途） 一条美登里は使えず、長女の一条茜がその適性を受け継いでいる。 人物関係対応（家系継承） 組んでいる人物は牛山欣治で、正体を確信した第一高校の生徒は中条あ ずさ。 複合文脈統合 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/2EVV56XGEQ.jpg) 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/ どう振る 舞わせる か システム プロンプ ト 制約付き 生成 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/57GL6NRDEL.jpg) LLMは検索コンテクストをどう読んでいるのか？ ユーザー質問 Context Window LLMの出力 「深雪の声優は誰？」 System / 指示 正答にも 質問は短くても、 検索で取れた文脈の質で 答えが変わる。 質問 検索コンテクスト 誤答にも … 必要な文脈が 入っているか なりうる 配置 「何を取ったか」 × Chunk A 深雪 … 司波達也の妹 ノイズ 「どう読んだか」 答えに効く情報が 埋もれていないか 近いが不要な情報が 誤答を誘わないか 出力生成 モデル差 Chunk C 近いが不要な人物情報 LLMは 必要文脈とノイズが 混在する 関連性 差を生むのは Retriever が選んだ 検索コンテクスト Chunk B 声優情報 / キャラクター 紹介 … このあと評価で見ていく論点 同じ文脈でも 解釈力で差が出る この窓の中だけを手掛かりに この場で答えを組み立てる RAGの回答品質は、 「何を取れたか」と「その文脈をどう読めたか」の掛け算で決まる。 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/4EQY4QVXJP.jpg) 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の性能は、「どんな文脈を窓の中に入れたか」と「その場でどう使えたか」で決まる。 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/KJ4WQNM271.jpg) 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回：評 価 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/LE1YP58K7G.jpg) 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回：評価 # Page. 15 ![Page Image](https://bcdn.docswell.com/page/GEWG25ZPJ2.jpg) 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 は「何件取るか」の検索設定 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/47ZLDN16J3.jpg) Chunk size と Overlap は「文脈の切り方」設計 小さく切るChunk サイズ: 300 基準例 Chunkサイズ: 500 大きく切る Chunkサイズ: 1000 chunk overlap chunk chunk chunk overlap chunk chunk overlap 細かい手掛かりは拾いやすいた 必要文脈が 情報はまとまりやすいただし だし必要情報が分散しやすい 1〜数チャンクで取れる状態 不要情報も入りやすい chunk Chunk size / Overlap は、必要文脈を救う効果 と、分散・重複・ノイズの増加 を見比べて調整する。 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/YJ6W18LLJV.jpg) Overlapは「網羅性」と「ノイズ」のトレードオフ Overlapを増やすメリット 境界またぎの情報を救う 重複チャンクが増える 狙いは「最大」では なく「必要十分」 必要文脈が分断されにくい ContextRecall top-kの多様性が下がる 必要文脈を拾い が上がりやすい 「取れない」失敗を減らす 評価で見るポイント Overlapを増やすデメリット ちょうどよい重なり ノイズ比率が上がる 重複が検索枠を ContextPrecision 圧迫しない範囲 が下がりうる Recall Precision top-k LLMの読み 必要文脈を 拾えたか 不要文脈に 埋もれないか 重複で検索枠を 消費しないか ノイズに引っ張ら れないか Overlapは大きければ良いのではない。必要文脈を救う効果 と、重複・ ノイズの増加 を見比べて調整する。 # Page. 18 ![Page Image](https://bcdn.docswell.com/page/GJ5M491MJ4.jpg) 「第２回 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の品質改善に直結 する！ 評価 スコア # Page. 19 ![Page Image](https://bcdn.docswell.com/page/LE3WGY19E5.jpg) ここで、ハンズオン用コードを実行します。 ※ 本ハンズオンは、事前準備を完了していることを前提に進行します。 コード実行用のキー取得、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」のみ # Page. 20 ![Page Image](https://bcdn.docswell.com/page/8EDK15X87G.jpg) 3回目：機能満載 RAG実験用アプリ群 ● 単問回答 / 単問連続回答 / CSV 一括回答 / 履歴表示 / log 保存 ● Embedding：ruri-v3-130m ● Generator: qwen3-8b ● Chunk 戦略 ● Prompt 戦略 ● Advanced RAG # Page. 21 ![Page Image](https://bcdn.docswell.com/page/V7PKQGPWJ8.jpg) 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回：評 価 # Page. 22 ![Page Image](https://bcdn.docswell.com/page/2JVV5629JQ.jpg) 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回：評 価 # Page. 23 ![Page Image](https://bcdn.docswell.com/page/5EGL6NR4JL.jpg) 第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 で 弱点ごとにプロンプトをチューニングしている # Page. 24 ![Page Image](https://bcdn.docswell.com/page/4JQY4QVR7P.jpg) 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) 構造を取って いる # Page. 25 ![Page Image](https://bcdn.docswell.com/page/K74WQNMQE1.jpg) 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回：評 価 # Page. 26 ![Page Image](https://bcdn.docswell.com/page/LJ1YP58LEG.jpg) 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回：評価 # Page. 27 ![Page Image](https://bcdn.docswell.com/page/GJWG25ZQ72.jpg) Advanced RAG はなぜ必要か 基本RAG 検索漏れ 必要文脈が取れない 質問 → 検索 → 弱点ごとに強化ポイントが違う Hybrid Search Reranking 文脈 → 生成 ノイズ混入 候補の並び順を直す Multi-Query 意味検索＋語検索を足す 質問を言い換えて広げる 近いが不要な文脈が混ざる 質問表現が弱い 聞き方が悪くて当 たりに届かない 検索経路の選択ミス 検索経路の 判断がずれる HyDE LLM Route 仮の答えを手掛かり に探す 検索経路を 切り替える Advanced RAG は「全部盛り」 ではなく、弱点に応じて選ぶ # Page. 28 ![Page Image](https://bcdn.docswell.com/page/4EZLDN1373.jpg) アドバンス RAG 全体マップ Reranking Hybrid Search Multi-Query HyDE LLM Route 候補を並べ 替える 異なる検索を 足し合わせる 質問を言い 換える 仮の答えを作っ て検索する 検索先そのもの を切り替える HyDE Route 強化する場所 Rerank Hybrid 検索結果の順位 ◎ 検索漏れ対策 △ 質問表現の弱さ対策 △ △ ◎ ◎ 検索経路への分岐 × × × × ○ ◎ Multi-Q ○ ◎ ○ ◎ Advanced RAG は「全部盛り」ではなく、弱点に応じて強化ポイントが違う △ ○ △ ◎ # Page. 29 ![Page Image](https://bcdn.docswell.com/page/Y76W18LZ7V.jpg) 第3回RAGハンズオン 新5問で体験する RAGチューニ ング・ガイドライン 0/5 → 2/5 → 4/5 を、参加者自身の実行結果として体験する 0/5 岩盤条件 2/5 分岐改善 4/5 限界確認 教材化の狙い 最高点探しではなく 「何が効くか」を見 る # Page. 30 ![Page Image](https://bcdn.docswell.com/page/G75M491974.jpg) 魔法科高校 新５問 新 ５問 新 元 元 Q1 Q5 新 元 Q2 Q9 新 元 Q3 Q11 新 元 Q4 Q12 新 元 Q5 質問 15問 Q15 「魔法科高校の劣等生」で、司波達也と九島光宣はどちらも「精 霊の眼（エレメンタル・サイト）」を持っています。2人の知覚の 得意分野はそれぞれ何ですか？ 「魔法科高校の劣等生」に出てくる戦略級魔法「オゾンサークル」 は誰の魔法ですか？ 正解 司波達也は分解・再成の特性から能動的な知覚に優れ、九島 光宣は仮装行列（パレード）の特性から受動的な知覚に優れ、 意識を向けていない状態でも遠方の魔法の兆候を感じ取れる。 カーラ・シュミットとウィリアム・マクロード 「魔法科高校の劣等生」のキャラクター牛山欣治は社内で司波 達也が「ミスター・シルバー」と呼ばれるのに対し、どのよう ミスター・トーラス に呼ばれていますか？ 『メイジアン・カンパニー』において、司波達也が設立した三 「メイジアン・ソサエティ」 「ステラ・ジェレネーター」 「一般 つの組織・法人の名前をすべて挙げてください。 社団法人メイジアン・カンパニー」 。 「トーラス・シルバー」に関して、司波達也がその名で製品を世 に送り出す際に組んでいる人物と、その正体を確信した第一高 校の生徒をそれぞれ答えてください。 組んでいる人物は牛山欣治で、正体を確信した第一高校の生 徒は中条あずさ。 # Page. 31 ![Page Image](https://bcdn.docswell.com/page/9J29V215ER.jpg) 第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 # Page. 32 ![Page Image](https://bcdn.docswell.com/page/DEY43YZ6JM.jpg) 新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型の問題は未攻略 # Page. 33 ![Page Image](https://bcdn.docswell.com/page/VJNYVPY178.jpg) 魔法科高校 新５問 新 ５問 新 元 元 Q1 Q5 新 元 Q2 Q9 新 元 Q3 Q11 新 元 Q4 Q12 新 元 Q5 質問 15問 Q15 「魔法科高校の劣等生」で、司波達也と九島光宣はどちらも「精 霊の眼（エレメンタル・サイト）」を持っています。2人の知覚の 得意分野はそれぞれ何ですか？ 「魔法科高校の劣等生」に出てくる戦略級魔法「オゾンサークル」 は誰の魔法ですか？ 正解 司波達也は分解・再成の特性から 能動的な知覚に優れ、九島 光宣は仮装行列（パレード）の特性から 受動的な知覚に優れ、 意識を向けていない状態でも遠方の魔法の兆候を感じ取れる。 カーラ・シュミットとウィリアム・マクロード 「魔法科高校の劣等生」のキャラクター牛山欣治は社内で司波 達也が「ミスター・シルバー」と呼ばれるのに対し、どのよう ミスター・トーラス に呼ばれていますか？ 『メイジアン・カンパニー』において、司波達也が設立した三 「メイジアン・ソサエティ」 「ステラ・ジェレネーター」 「一般 つの組織・法人の名前をすべて挙げてください。 社団法人メイジアン・カンパニー」 。 「トーラス・シルバー」に関して、司波達也がその名で製品を世 に送り出す際に組んでいる人物と、その正体を確信した第一高 校の生徒をそれぞれ答えてください。 組んでいる人物は牛山欣治で、正体を確信した第一高校の生 徒は中条あずさ。 # Page. 34 ![Page Image](https://bcdn.docswell.com/page/YE9P63PYJ3.jpg) 第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) ➡ 第４回へ続く # Page. 35 ![Page Image](https://bcdn.docswell.com/page/GE8DZMDKED.jpg) 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アプリをベースに「作る → 測る → 改善 → 選択 → 自律化」の流れを体験し、検索・ 生成・評価・モデル選択を組み合わせた、継続的な改善サイクルを理解 する。 # Page. 36 ![Page Image](https://bcdn.docswell.com/page/LELMD3MP7R.jpg) 4回目：機能満載 RAG実験用アプリ群 ● 単問回答 / 単問連続回答 / CSV 一括回答 / 履歴表示 / log 保存 ● Embedding：ruri-v3-130m / sarashina-embedding-v2-1b / OpenAI Embedding ● Generator: qwen3-8b / 14b / OpenAI APIs ● Chunk 戦略 ● Prompt 戦略 ● Advanced RAG # Page. 37 ![Page Image](https://bcdn.docswell.com/page/4JMYPDY2JW.jpg) 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月予定） # Page. 38 ![Page Image](https://bcdn.docswell.com/page/PJR9149579.jpg) APPENDIX # Page. 39 ![Page Image](https://bcdn.docswell.com/page/PEXQY2QXJX.jpg) Indexing と query_num は役割が違う query_num の流れ Indexing の流れ Chunks Embedding化 登録 質問 検索 Top-k chunks Vector DB に保存 ここは「検索できる土台」を作る処理 ＝ まだ質問していない 段階 Indexing = chunk を埋め込み化して Vector DB に登録すること query_num は、この段階で何チャンク返すか ＝ Retriever の top-k を決める設定 query_num = 検索時に 何チャンク取るか を決めること 登録の話と、検索時に何件取るかの話を分けて考える # Page. 40 ![Page Image](https://bcdn.docswell.com/page/3EK93M99ED.jpg) 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 に残すと分 析しやすい 品質寄りの 検証候補 # Page. 41 ![Page Image](https://bcdn.docswell.com/page/L73WGYW975.jpg) 比較実験は何を見ればよいのか 星取表を見る前に、改善とみなす観点をそろえる 1 正答率 2 検索漏れ 3 ノイズ耐性 4 再現性 最終回答が正しくなったか 「〇が増えたか」だけでなく、誤答の質が 変わったかも見る 必要文脈を取れるようになった か ContextRecall が上がる系の手法かを確認する 不要文脈に引っ張られにくくな ったか Reranking や prompt_detail で誤答の型が 変わるかを見る たまたま当たったのではなく、 狙って改善できたか コードで再実験し、評価アプリで同条件比較する 第3回は「どの手法が強いか」だけでなく、 「何がどう改善したか」を読む回 # Page. 42 ![Page Image](https://bcdn.docswell.com/page/87DK15K8JG.jpg) Advanced RAG：第2回の評価と第 3回の改善はどうつながるか どの手法が、どの評価観点を改善しやすいかを見る 手法 主に効く場所 効きやすい評価 狙う弱点 一言でいうと Reranking 並び順 ContextPrecision 不要チャンク混入 取れた候補を 賢く並べる Hybrid Search 検索漏れ ContextRecall 意味だけ/語だけでは 弱い 意味検索とキーワード検 索を足す Multi-Query 質問表現 Recall / Relevancy HyDE 検索語の弱さ Recall / Relevancy 短い質問で手掛かり 不足 仮の答えを先に 作って探す LLM Route 探索先選択 ケース依存 ローカルかWebかを 誤る 探しに行く先 を先に決める 別名・言い換えに弱い 質問の投げ方を増やす 第3回は、第 2回で分解して見た評価結果を受けて、「どの弱点にどの改善を当てるか」を考える回 # Page. 43 ![Page Image](https://bcdn.docswell.com/page/VJPKQGKWE8.jpg) Reranking：候補の中から、答えに効く文書を前に出す Dense 検索 質問 再評価 候補プール上 位10件など Rerank_v1 「再採点の結果だけで」上位を選び直す • 効く場面：候補は取れているが、不要チャンクが混ざる • 主に改善したい指標： ContextPrecision CrossEncoder 関連度を再採点 並べ 替え 生成 最終文脈上 位 3〜5件 Rerank_v2 Dense上位候補を少し保護しつつ、 再採点と融合して安定化 • v2は「再順位付けしすぎ」を防ぎやすい • 講義では v1 → v2 の進化として見せやすい 考え方の核： 検索そのものを変えるのではなく、 「取れた候補の並び順」を賢くする 回答 # Page. 44 ![Page Image](https://bcdn.docswell.com/page/2EVV56V9EQ.jpg) 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上位を守るため実用上安定しやすい。 # Page. 45 ![Page Image](https://bcdn.docswell.com/page/57GL6NL4EL.jpg) Hybrid Search：意味検索とキーワード検索を足し合わせる Dense 質問 Sparse Dense retrieval 上位 選抜 意味で近い文書 融合 BM25 retrieval RRF または Weighted Sum 語が合う文書 • Denseだけだと、固有名詞や短いキーワードを落 とすことがある • Sparseだけだと、言い換えや意味の近さに弱い 生成 最終文脈 • 両方の長所を足して、検索漏れを減らす • 主に改善したい指標：ContextRecall 考え方の核：「意味で探す」だけでも「語で探す」だけでも足りないので、両方の証拠を束ねる 回答 # Page. 46 ![Page Image](https://bcdn.docswell.com/page/4EQY4QYRJP.jpg) BM25 の要点 ● 概要：Best Matching 25 の略。検索でクエリと文書の関連度を付ける代表的な疎ベクトル手法 。 ● 仕組み ○ TF：語の出現回数。多すぎると効果を飽和させる。 ○ IDF：希少語ほど重みを上げる。 ○ 長さ正規化：文書が長いほど補正して公平に。 ○ スコア式： ■ k1k_1(≈1.2–2.0)：TF飽和度 ■ bb(≈0.5–0.8)：長さ補正の強さ ● 長所：キーワード一致に強く、高速でチューニングも容易。 ● 短所：同義語や文脈を捉えられないため、意味理解が必要な検索ではベクトル検索との併用 検索）が推奨される。 （ハイブリッド # Page. 47 ![Page Image](https://bcdn.docswell.com/page/KJ4WQNWQ71.jpg) Multi-Query：質問を複数の言い方に増やして、検索漏れを減らす LLMで言 い換え 質問 Query 1 Query 2 Query 3 検索 検索 検索 • 1つの聞き方だけでは、欲しい文書に届かない こ とがある • 同じ意味を別表現で投げて、拾える根拠を増やす 取得結果 A / B / C ... A / D / E ... B / F / G ... 統合 重複を整理し 上位を残す 生成 回答 • 効く場面：質問表現があいまい、別名が多い、 言い換えが多 い • 主に改善したい指標：ContextRecall と AnswerRelevancy 考え方の核： 文書を変えるのではなく、質問の投げ方を増やして当たりチャンクを引きやすくする # Page. 48 ![Page Image](https://bcdn.docswell.com/page/LE1YP5YL7G.jpg) HyDE：まず「仮の答え」を作り、その答えを手がかりに検索する まず仮説 質問 LLMが仮の 回答を 1文 仮説を 検索語に で作る • 元の質問が短すぎると、検索語として弱いことがある • 仮説回答を作ると、検索に使う情報量が増える Dense retrieval 仮説に近い文書 根拠 化 生成 取得文脈から 本回答を作る • 効く場面：答えの形がある程度想像できる質問 • 注意点：仮説がズレると、ズレた文書を引く危険もあ る 考え方の核： 先に「それっぽい答え」を作ってから探すことで、検索クエリを豊かにする 回答 # Page. 49 ![Page Image](https://bcdn.docswell.com/page/GEWG25GQJ2.jpg) 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検索そのものより「どこを探すかを先に決める」考え方を押さえれば十分。 # Page. 50 ![Page Image](https://bcdn.docswell.com/page/47ZLDNL3J3.jpg) なぜQ15は難しいのか？ Q15 「トーラス・シルバー」に関して、司波達也がその名で製品を世に送り出す際に組んでいる人物と、 その正体を確信した第一高校の生徒をそれぞれ答えてください。。 登場人物 wiki_01.txt 登場人物 wiki_02.txt 登場人物 wiki_04.txt 技術者・事業側の文脈 第一高校・生徒側の文脈 人物・関連情報の補助文脈 「トーラス・シルバー」と して製品を世に出す枠組み 中条あずさが正体を確信 する手がかり 人物対応を取り違えないための 周辺情報・参照断片 必要な統合 難しさの本質 1 検索だけでは足りない 3ファイルに分散した断片を、同一 質問内で同時に回収する必要があ る。 「牛山欣治」＋「中条あずさ」を 別々の文脈から対応づける 2「誰」と「誰」の対応づけが必要 牛山欣治＝共同開発者／中条あずさ＝正 体を確信した生徒、という役割分担を混 同しやすい。 3文脈統合型の最難問 単一チャンクの引用ではなく、複数 文脈を統合して初めて完全正答にな る。 # Page. 51 ![Page Image](https://bcdn.docswell.com/page/YJ6W18WZJV.jpg) 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の利用制限は動的に変動するため、本スライドは作成日時点の公式情報に基づく整理。将来の仕様変更時は再確認が必要。 # Page. 52 ![Page Image](https://bcdn.docswell.com/page/GJ5M49M9J4.jpg) 配布物リスト 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 による改善と、残る難問の位置づけ」を確認するための参考資料として配布します。 # Page. 53 ![Page Image](https://bcdn.docswell.com/page/9E29V2957R.jpg) 配布アプリコード： ログ一括評価アプリ _v7-2 Ragas の LLM-as-a-judge に 使用する OpenAI API を ・gpt-4o-mini・ gpt-4.1-mini・ gpt-5.4-mini から選択可能とした。 # Page. 54 ![Page Image](https://bcdn.docswell.com/page/D7Y43Y46EM.jpg) RAGの仕組みを理解して改善し続けよう 〜 LangChain Family × GradioによるRAGアプリ開発 〜 第１回：動いて中身も見える RAGを作って触ろう 〜 LangChainで基本RAGアプリ開発 〜 第２回： RAGを測るモノサシを作ろう 〜 Ragas × LangSmithでRAG評価アプリ開発 〜 第３回： RAGを最適化しよう 〜 チャンクとプロンプトの戦略＋アドバンス RAGアプリ開発 〜 第４回： RAGの頭脳を選択しよう（改訂版） 〜 タスクに応じた generator 選択 / API 利用 〜 第５回：進化系 RAGに挑戦 〜 LangGraphでAgentic RAG開発 〜