【Paper&Hacks vol.99】RAGの基盤を固めよう 〜 評価／検索システム／データ前処理 〜

（９回シリーズ）RAGの仕組みを理解して改善し続けよう 〜 LangChain Family × GradioによるRAGシステム開発 〜 第６回：RAGの基盤を固めよう 〜 評価／検索システム／データ前処理 〜 2026/9/15異業種データサイエンス研 究会 ® 代表井伊 篤彦

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

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

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

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

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

• https://drive.google.com/file/d/1tHj3QmsPmbpPVb48FBjE2ht3FlzBtck-/view?usp=sharing
• https://docs.google.com/document/d/1wJEIOvWlEMdj-DwmvTPgVkWYUSvWsWNc/edit?usp=drive_link&ouid=106881452668834877355&rtpof=true&sd=true
• https://qiita.com/so9_Monodzukuri_AI/items/388e9b546ecb2ecfc420
• https://www.tis2010.jp/openai_apikey/
• https://note.com/npaka/n/n79bb63e17685

RAGの基本フロー Embedding ベクトル DB 生データ 検索 Embedding Retriever コンテキスト 回答 質問 システム プロンプト

RAGの基本フロー Embedding Chroma DB ベクトル DB ベクトルDB Faiss 検索システム 生データ DBに渡す前処理 検索 Embedding Retriever ベクトル検索エンジン OpenSearch 検索システム コンテキスト 評価 回答 質問 システム プロンプト

独自実験評価法の 開発

RAGの基本フロー Embedding Chroma DB ベクトル DB ベクトルDB Faiss 検索システム 生データ DBに渡す前処理 検索 Embedding Retriever ベクトル検索エンジン OpenSearch 検索システム コンテキスト 評価 回答 質問 システム プロンプト

ITミニベンチマーク 5問 質問 正答 ターゲット ファイル ファイ ル種別 問題タイプ 既存データの分析として、ますデータ項目の用語を抽出し整理し、 Q1 用語辞書および語彙を作成するため の工程を具体的に示してください。 データ項目の用語辞書を作成します。続いて、データ項目の値を抽出 pdf 手順説明型 01point.pdf pdf 数値比較型 06_info-services_soft.pdf pdf Yes/No判断型 2023_01benchmark.pdf pdf 条件分岐型 report.pdf pdf 指示遵守・列挙型 して整理し、値の用語辞書（値リスト）を作成します。そして、デー 000096537.pdf タ項目用語の表記と相互の関連性を定義し、用語が取りうる値リスト を定め、語彙を作成します。 企業におけるパーソナルデータの活用状況について、活用していると Q2 日本企業のパーソナルデータ活用率 について、諸外国と比べてどのよう な傾向があるか。 Q3 Q4 Q5 販売する業務システムのマニュアル を外部業者に委託する予定です。こ れは下請法の対象になりますか？ 回答した企業は日本では52.8%でした。一方、米国では活用している 企業の割合は81.9%、ドイツ77.0%、中国92.6%と、日本に比べて 大幅に活用が進んでいます。 商品に付属するマニュアルの印刷を委託することは、製造委託に該 当し、下請法の対象となります。 データセンター事業者ではない所有 建物を貸しているオーナーは、データセンター業のベンチマーク制 者の建物を間借りして、データセン 度の対象外です。一方、建物を間借りしてデータセンター業を営む ター事業を行っています。この場合、 事業者は、原則としてテナント部分についてPUEを算出し報告しま ベンチマーク指標の報告対象になり す。ただし、建物・付帯設備に関するエネルギー管理権原を有して ますか？ いない場合は対象外となります。 AIが社内業務の効率化の活用例とし て、翻訳、文案作成の他に3つの例 文章チェック、効率化、自動化が挙げられます。 を挙げてください。

共通評価基準 5問の合計点を実験条件 （1セット）のスコアとする 5問中何問正解か 人間評価と AI評価共通の 2種類の評価基準を採用

各設問評価基準

実験評価シート例

独自 LLM-as-a-judge アプリ

LLM-as-a-judge アプリスコアリング評価結果

LLM-as-a-judgeアプリ評価と Ragas 指標による回帰予測との比較 gpt-5.5-thinking gpt-5.4 Ragas 指標による回帰予測 * * GradientBoostRegressor Human score Human score Human score Ragas 指標からの回帰予測評価より、LLM-as-a-judgeアプリ評価の方が信頼性が高い

LLM-as-a-judge アプリスコアリング評価結果 評価精度と実行速度から今回は gpt-5.4 が一番バランスが良いと判断

検索システム

RAGの基本フロー Embedding Chroma DB ベクトル DB ベクトルDB Faiss 検索システム 生データ DBに渡す前処理 検索 Embedding Retriever ベクトル検索エンジン OpenSearch 検索システム コンテキスト 評価 回答 質問 システム プロンプト

RAGで使う検索システム： Chroma DB / Faiss / OpenSearch いずれも「質問に関連する文書チャンク」を取り出すために使う 文書 チャンク Chroma DB ベクトルDB Embedding ・ 保存と検索を簡単に扱う ・ チャンク＋ベクトルを保 持 Faiss ベクトル検索エンジン ・ 近いベクトルを高速探 索 ・ 純粋な近傍検索が得意 OpenSearch 検索システム ・ BM25 ＋ベクトル検索 ・ ハイブリッド検索が得意 チャンク化 → Embedding → 検索システムに登録 → 質問に近い候補チャンクを検索 厳密には、Chroma DB はベクトルDB、Faiss はベクトル検索エンジン、OpenSearch はベクトル検索も できる検索システム。 RAGで使う検索システムの共通の仕事 = 「答え」ではなく、LLM に渡す関連文脈候補を取り 出すこと

3種類の検索システムでの実装の違い 1 保持 2 近傍探索 3 検索システム化 Chroma DB は保持、Faiss は近傍探索、OpenSearch は検索システム全体を担う

検索システム切替実装アプリ

データ前処理

RAGの基本フロー Embedding Chroma DB ベクトル DB ベクトルDB Faiss 検索システム 生データ DBに渡す前処理 検索 Embedding Retriever ベクトル検索エンジン OpenSearch 検索システム コンテキスト 評価 回答 質問 システム プロンプト

混在ファイル対応 RAGアプリの読み込み設計 2回目資料 ファイルごとに「最適な読み方」を選び、最後は同じ検索土台にそろえる 入力フォルダ ファイルタイプ別に 最適Loaderを切替 混在ファイル PDF 最後は同じ Document 形式に正規化 共通土台 適材適所 PDF Word Word をそろえる ページ単位で読む source / filename / filetype UnstructuredWord (mode="elements") 段落・要素で読む PPT Excel PPT TXT / MD Excel 種類が違うので同じ 方法で読むと精度も 扱いやすさも落ちる TXT / MD metadata PyMuPDFLoader UnstructuredPowerPoint (mode="elements") 検索に使う単位をそろえる 通常文書 → chunk 分割 Excel行 → そのまま保持 混在ファイルでも 「検索側から見れば同じ箱」にする → ここで初めて Embedding / Vector DB / Retriever を共通化できる スライド要素で読む 1行 = 1 Document 表の行をそのまま保持 そのまま読込み 軽い文書は直読 Embedding Vector DB Retriever 意味で近さを測る 同じ土台で蓄積 質問に応じて探す 「全部同じように読む」のではなく、 「読み方は分ける、検索の土台はそろえる」

混在ファイル対応 RAGアプリの読み込み設計 2回目資料 ファイルごとに「最適な読み方」を選び、最後は同じ検索土台にそろえる 入力フォルダ ファイルタイプ別に 最適Loaderを切替 混在ファイル PDF PDF PyMuPDFLoader Word Word UnstructuredWord (mode="elements") 段落・要素で読む PPT 既に UnstructuredPowerPoint 基本的な (mode="elements") PPT 種類が違うので同じ 方法で読むと精度も 扱いやすさも落ちる Excel 1行 = 1 Document 表の行をそのまま保持 TXT / MD metadata をそろえる source / filename / filetype 検索に使う単位をそろえる 通常文書 → chunk 分割 Excel行 → そのまま保持 混在ファイルでも「検索側から見れ ば同じ箱」にする → ここで初めて Embedding / Vector DB / Retriever を共通化できる 前処理 スライド要素で読む は実装済み TXT / MD 共通土台 適材適所 ページ単位で読む Excel 最後は同じ Document 形式に正規化 そのまま読込み 軽い文書は直読 Embedding 意味で近さを測る Vector DB Retriever 同じ土台で蓄積 質問に応じて探す 「全部同じように読む」のではなく、 「読み方 は分ける、検索の土台はそろえる」

混在ファイル対応 RAGアプリの読み込み設計 ファイルごとに「最適な読み方」を選び、最後は同じ検索土台にそろえる 入力フォルダ ファイルタイプ別に 最適Loaderを切替 混在ファイル PDF PDF PyMuPDFLoader Word Word PPT TXT / MD 段落・要素で読む 実装済み PPT 種類が違うので同じ 方法で読むと精度も 扱いやすさも落ちる metadata をそろえる source / filename / filetype 検索に使う単位をそろえる 通常文書 → chunk 分割 Excel行 → そのまま保持 UnstructuredWord (mode="elements") UnstructuredPowerPoint 前処理 (mode="elements") スライド要素で読む Excel 1行 = 1 Document 表の行をそのまま保持 画像データ 共通土台 適材適所 ページ単位で読む Excel 最後は同じ Document 形式に正規化 TXT / MD そのまま読込み 画像 OCR＋LLM整形 データ 文字化 → 文章化 混在ファイルでも「検索側から見れ ば同じ箱」にする → ここで初めて Embedding / Vector DB / Retriever を共通化できる Embedding 意味で近さを測る Vector DB Retriever 同じ土台で蓄積 質問に応じて探す 軽い文書は直読 「全部同じように読む」のではなく、 「読み方 は分ける、検索の土台はそろえる」

混在ファイル対応 RAGアプリの読み込み設計 ファイルごとに「最適な読み方」を選び、最後は同じ検索土台にそろえる 入力フォルダ ファイルタイプ別に 最適Loaderを切替 混在ファイル PDF 適材適所 PDF PyMuPDFLoader ページ単位で読む Word Word PPT Excel TXT / MD UnstructuredWord (mode="elements") 段落・要素で読む 種類が違うので同じ 方法で読むと精度も 扱いやすさも落ちる OCR＋LLM整形 データ 混在ファイルでも 文字化 → 文章化 「検索側から見れば同じ箱」にする 実装済み PPT UnstructuredPowerPoint 前処理 (mode="elements") スライド要素で読む Excel 1行 = 1 Document 表の行をそのまま保持 画像データ 画像 TXT / MD そのまま読込み 画像 OCR＋LLM整形 データ 文字化 → 文章化 軽い文書は直読 OCR処理（文字化）の後に LLMで整形（文章化）する場合は、 事前に入念なチェックが必要。 誤った整形は、RAGの根拠を ゆるがしかねない。

OCR後LLM整形：読みやすさと根拠忠実性の比較 主評価軸：最終回答ではなく、retrieval context が元PDFに準拠しているか OCR 画像PDF LLM整形 文章化 文字化 documents RAG回答 読みやすさ ≠ 忠実性 A LLM整形なし B gpt-4.1-mini 整形 C gpt-5.4-mini 整形 監査用ベースライン 読みやすいが注意 配布用第一候補 元PDF準拠性：高い Q1〜Q4：非常に読みやすい 本文：読みやすく、保守的 OCRノイズ・誤字が残る Q4：活用率表は正しく整理 Q4：主要数値を正しく保持 図表数値は残るが、並びは崩れる Q5：多系列棒グラフを単一表に潰す Q5：無理に数値表を作らない LLM由来の根拠汚染はない 元の値と異なる数値対応が発生 情報量は少し落ちるが、誤対応を避ける 用途：監査・比較基準として保持 用途：通常本文の整形例／警告例 用途：第6回配布documents候補 第6回配布用 documentsは gpt-5.4-mini 整形版を第一候補 。 図表数値を扱う場合は、元 PDF照合済み summaryを同梱する。 実務メッセージ： AI前処理で作った documents は、RAGの根拠になる前に忠実性を検証する。

画像化PDFデータセット作成 文字を埋め込んだ PDF 画像化したPDF

今回の実装では、3ページの画像化 PDFのOCRに5分以上かかった ➡ OCR前処理は、RAG回答アプリ本体から切り離し事前実行する方が実用的

テキスト埋め込み PDF : 従来前処理

画像化PDF : OCR未対応版（従来前処理のみ）

画像PDF : OCR対応版

第6回RAGハンズオン 画像版データセットを用いて OCR機能を確認しよう ハンズオン用アプリ 00_RAG単問回答アプリ_OCR未対応版.ipynb 01_RAG単問回答アプリ_OCR対応版_T4_high_mem.ipynb

第6回RAGハンズオン 実行計画：文字埋め込み PDFと画像化PDFからRAG回答 従来 前処理 Documents RAG回答 文字埋め込み PDF 固定条件： qwen3-8b / ruri / basic rag / prompt_detail / 300 / 50 / 5 ＋ 画像化 PDF OCR ➡ LLM整形 Documents

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

APPENDIX

Chroma DB は何をしているのか？ ベクトルを保存し、意味が近い文書チャンクを返す保管庫 Chroma DB は 文書チャンクとそのベクトルを保持する ベクトル DB。 質問も Embedding し近いベクトルを高速検索する。 返すのは 答えではなくLLM に渡す 関連文脈候補。 チャンク化 → Embedding → 保存 → 類似検索 セミナーコードでは、 build_vector_index() 関数内で collection.add(...) を用いて文書チャンクと埋め込みベクトルを登 録。検索時には embed_query() 関数で質問文をベクトル化し、そ の結果を使って collection.query(...) を実行。 RAGでの Chroma DB の仕事 = 「意味が近い文書片を、 素早く取り出せる形で保持すること」

Faiss は何をしているのか？ ベクトルを高速に近傍検索する検索エンジン Faiss 文書 チャンク 近い ベクトル ベクトル化 Faiss は、ベクトル検索に特化 したライブラリ。大 規模なベクトル集合の高速検索に強い 。 質問Embeddingに近いベクトル を高速に探す。 Embedding 返すのは答えではなくLLMに渡す関連文脈候補 。 Embedding → Index作成 → 類似検索 セミナーコードでは、文書チャンクをEmbeddingして Faiss インデックス に登録。 similarity_search(...）な 検索時には質問をEmbeddingし、 どで近いチャンクを取り出す。 RAGでの Faiss の仕事 = 「近いベクトルを、高速に探せる形で保持すること」

TomSuzuki氏作成資料

OpenSearch は何をしているのか？ 意味検索とキーワード検索を同じ基盤で扱う検索システム OpenSearch 文書 チャンク Embedding キーワード BM25 knn_vector HNSW / Filter 文書＋ベクトル＋メタデータ → 保存 → 複合検索 OpenSearch 意味が近い チャンク はキーワード検索だけの道具ではない。 knn_vectorでEmbeddingに近いベクトルを検索できる。 さらにBM25・フィルタ・メタデータ・Hybrid Searchを同じ 基盤で扱う。 セミナーコードでは、チャンク本文・Embedding・メタデ ータをOpenSearchのindexに登録。 検索時にはBM25とベクトル類似度を組み合わせ、必要な文 脈を取り出す。 RAGでの OpenSearch の仕事 = 「意味で拾い、言葉そのものも落とさない検索をすること」

Hybrid Search の RRF と Weighted Sum の違い RRF は ”順位” で混ぜる。Weighted Sum は “スコア” を重み付きで混ぜる。

PaddleOCRとは 画像PDF・スキャンPDFから文字を取り出し、RAGで検索できる形にするためのOSS OCRツール 通常PDFと画像PDFの違い 通常PDF 画像PDF テキストレイヤーあり 文字は画像の中 RAG投入までの流れ 画像PDF PaddleOCR 文字列 Document スキャンPDF 文字検出・認識 OCR結果 RAGの土台へ 見た目は同じでも 内部構造が違う PyMuPDFLoaderだけでは、画像として存在する文 字は検索対象になりにくい。 そこで、文字レイヤーが十分に取れないページだけ OCRに回す。 ページ単位で分岐 最終的には同じ Document 形式へ正規化し、 Embedding・Vector DB・Retrieverへ渡す。 目的：完全な文書解析ではなく、画像 PDFから最低限 RAGに投入可能な文字情報を得ること ※ 縦書き・複雑な表・図表内ラベル・低解像度スキャン・手書き文字では誤認識が起こり得る