目次

1. 結論：RAGは入力がすべて。モデルを変える前に“整える”

2. 前処理（Preprocessing）完全ガイド：5ステップ

3. チャンク（Chunking）ベストプラクティス

4. 推奨パラメータ（2025年版）と失敗あるある

5. 実装の出発点：パイプライン例（NestJS/Node/Python想定）

6. チェックリストと導入の流れ

1. 結論：RAGは入力がすべて。モデルを変える前に“整える”

RAG（Retrieval-Augmented Generation）は、検索で取ってくる材料の質が最終回答の質を左右します。
経験上、前処理（Preprocessing） × チャンク（Chunking）で精度の 7〜8 割が決まると言ってよく、埋め込み（Embedding）モデルを変えずとも、ここを最適化するだけで命中率・再現率・回答一貫性が劇的に改善します。

  • Embedding の前に：テキストを“きれいに・構造的に”
  • 取り出しやすく：チャンクを“論理単位で・重なりを持って”
  • メタデータで：検索 → ランク → 統合の各段で有利に

本記事は、汎用 RAGにそのまま持ち込める形で、前処理とチャンク設計をフル解説します（特定ベンダー固有の記述は省いています）。

2. 前処理（Preprocessing）完全ガイド：5ステップ

前処理の目的はEmbedding に渡すテキストを最大限きれいにし、情報損失なく構造を保持すること。以下の 5 ステップで進めます。

2.1 ノイズ除去（Normalization）

多くのドキュメントは Embedding に向かないノイズを含みます。
やるべき項目

  • 余計な空白を除去（連続スペース → 1 つ）
  • 改行の正規化（CRLF → \n に統一）
  • HTML タグ除去（ただし <h1>〜<h4> 等の見出しは抽出して保持）
  • Markdown の不要記法を整理（記号のゆらぎを一本化）
  • 数式・表の整形（記号が壊れないよう保全）
  • PDF 特有の“単語分断”の再結合（ハイフンや禁則の復元）

例

本日  の   議事録です。  →  本日の議事録です。

2.2 見出し（構造）の抽出

構造があると RAG は飛躍的に精度が上がります。

  • <h1>〜<h4> など階層情報を抽出・保存
  • 抽出した階層を chunk メタデータ に格納
  • 「どの章に属するか」を保持（後段の再ランク・再構成に効く）

メタデータ例

{
  "section": "3.2 APIの認証方式",
  "h1": "APIドキュメント",
  "h2": "認証",
  "h3": "OAuth2"
}

2.3 文の整形（Sentence Segmentation）

文が長すぎる/短すぎると埋め込み品質が落ちます。

  • 句点 。 を基準に文単位で分割
  • PDF 起因の途中改行は再連結
  • 箇条書きの - / • の揺れを統一

2.4 特殊記号・制御文字の除去

  • \t, \r, \0 など制御文字
  • ASCII でない不可視文字
  • 連続ドットや過剰な絵文字（業務文書では多くがノイズ）

2.5 ドキュメントメタデータの付与（必須）

後工程の検索精度に強く影響します。

  • ファイル名 / 拡張子
  • 元のページ番号 / 位置（開始オフセットなど）
  • セクション階層（h1〜h3 等）
  • 作成日時 / 更新日時
  • Document ID (UUID) / ソース URL

メタデータは「検索で絞る → ランクで上げる → 回答で再構成する」全段に効きます。設計の早い段で揺らぎをなくしましょう。

3. チャンク（Chunking）ベストプラクティス

チャンクは RAG の根幹。 取り出したい単位で、意味を壊さず、重なりで文脈を保つのがコツです。

最適チャンクの条件

  • 長さが適切（200〜600 tokens、多くの環境で 350〜500 tokens が中庸）
  • 文の途中で切らない（文終端で切る）
  • 見出し（親情報）をメタデータで保持
  • セクションごとにまとまっている（章を跨いで混在させない）

3.1 方式の比較

① 固定長チャンク（Fixed-size）

  • 300〜500 tokens を基準にシンプルに切る
  • メリット：実装が簡単、埋め込み品質が安定
  • デメリット：セクション途中で切れて意味が途切れやすい

② オーバーラップチャンク（Overlap）

  • 例：chunk=350 tokens, overlap=50 tokens
  • メリット：境界の情報損失を低減、文脈の連続性が向上
  • デメリット：ストレージ/インデックスが微増
  • 推奨：現行 RAG ではほぼ必須

③ セクションベース（Structure-aware）

  • Markdown や見出し階層を使って論理単位で切る
  • 章/節/項でまとまりを保ちつつ、300〜600 tokensに再分割
  • 見出しとパス（h1/h2/h3）を必ずメタデータ化
  • メリット：論理一貫性が高く、命中率・回答品質が顕著に向上
  • デメリット：実装の一手間（AST/DOM の活用が近道）

4. 推奨パラメータ（2025年版）と失敗あるある

項目推奨値
chunk size350〜500 tokens
overlap50〜80 tokens
max chunk length600 tokens
min chunk length80 tokens
構造化チャンク有効（h1〜h3 基準）
メタデータ付与必須

失敗あるある

  • 境界で文を切る（→ 回答の支離滅裂化。文終端で切る）
  • セクション混在（→ 章を跨いだ誤回収。章単位を守る）
  • 改行/空白の揺れ（→ 埋め込みが分散。正規化の徹底）
  • 表・数式の破損（→ 数値 QA が弱体化。レンダリング前に整形）
  • メタデータ不足（→ ランク不能。最低限の軸＝章・ページ・日付）

5. 実装の出発点：パイプライン例（NestJS/Node/Python想定）

5.1 前処理パイプライン（擬似コード）

  1. 変換：Markdown / HTML / PDF → テキスト（+ 構造抽出）
  2. 見出し抽出：AST/DOM から h1/h2/h3 をパス化
  3. ノイズ除去：空白・改行・制御文字・記号揺れを正規化
  4. 文整形：文単位の分割と PDF 改行の再連結
  5. セクション割当：テキストを章ごとにマッピング
  6. チャンク投入：下記の設定でチャンク化
chunk({
  text,
  maxTokens: 500,
  minTokens: 80,
  overlap: 60,
  preserveHeadings: true,
  headingDepth: 3,
});

5.2 チャンクに添えるメタデータ例

{
  "doc_id": "xxx-uuid",
  "filename": "manual.pdf",
  "page": 32,
  "section_h1": "ログイン方法",
  "section_h2": "二要素認証",
  "chunk_index": 12,
  "text": "この章では2FAの詳細について説明します…"
}

重要：検索・再ランク・回答再構成の全工程でこのメタデータが効くため、早期にスキーマを固定して運用しましょう。

6. チェックリストと導入の流れ

チェックリスト（前処理）

  • 空白・改行・制御文字・不可視文字の正規化
  • PDF の単語分断を復元 / 表・数式の崩れを修正
  • 見出し階層（h1〜h3）の抽出とメタ化
  • 文単位の分割（文途中で切らない）
  • ファイル名/章/ページ/日付/UUID などのメタデータ付与

チェックリスト（チャンク）

  • 350〜500 tokens を中心に設定
  • overlap 50〜80 tokens を付与
  • 章を跨がない構造化チャンクを採用
  • max 600 / min 80 tokens を遵守
  • チャンク順序・章パスをメタデータで保持

導入の流れ

  1. 前処理・チャンクのスキーマを決める（メタ項目を固定）
  2. AST/DOM 処理を先に作る（構造化チャンクの土台）
  3. 小規模で A/B 比較（固定長 vs 構造化、overlap あり/なし 等）
  4. ログを可視化（ヒット元チャンクと章パスを UI で確認）
  5. 定期メンテ（辞書・正規化ルール・表/数式処理を更新）

🔚 まとめ：まず“入れる前”を磨けば、RAG は必ず強くなる

  • RAG の精度は、前処理 × チャンク設計で大半が決まります。
  • 構造化チャンク＋オーバーラップは、2025 年時点の最有力解。
  • メタデータは検索・ランク・回答の三段で効く“潤滑油”。
  • Embedding を変える前に、入力を整えるところから始めましょう。

OpenBridge にお任せください

OpenBridge では、前処理・チャンク・メタ設計の“効くところ”から着手し、既存の RAG 環境でも検索精度を短期間で底上げします。
小さな PoC からの改善も歓迎です。ドキュメントサンプルを数点いただければ、最適な正規化ルールとチャンク設計をご提案します。