文書チャンキング

文書を検索単位へ変えても、原文への責任を切断してはならない

数十ページの規程から、検索は数秒で関係する二、三段落を見つける必要がある。文書チャンキングはそのための処理だが、各断片から出典、適用対象、有効性をたどれる状態は失ってはならない。

切分前に原本、解析結果、読み順を確認する

チャンキングは、誤って解析された文書を直してくれるわけではない。ヘッダーの混入、二段組みの逆転、表セルの欠落はそのまま増幅されるため、まず入力品質を切り分けて確認する。

利用可能な chunk には本文だけでなく識別、位置、適用情報が要る

段落をベクトルストアへ入れただけでは、管理可能な検索単位にはならない。企業利用では、所属文書、正確な位置、継承権限、原本変更時に確実に撤回する方法まで必要になる。

1. 安定 chunk ID

   再現可能な規則または管理 ID を使い、再処理で維持、追加、変更、移動、削除を区別する。

   ID 規則、新旧対応、変更一覧

2. 情報源参照

   情報源 ID、文書版、snapshot、checksum を結び、原本、解析版、cleaning 版、切分版の派生関係を明示する。

   来歴、版、checksum

3. 正確な位置

   ページ、節、見出し経路、段落、文字・要素範囲、表、添付 ID を記録し、利用者が該当位置を開いて確認できるようにする。

   locator、原文 anchor、回リンク試験

4. 本文と構造

   原文、追加した上位見出し、表見出し、隣接文脈、生成説明を別項目にし、補足文を引用原文に見せない。

   内容項目、構造項目、派生標識

5. 時間と状態

   文書の公開、発効、失効、撤回、履歴状態を継承する。版間で類似する条項も時間境界を失わない。

   有効区間、状態、置換関係

6. 権限と範囲

   tenant、組織、役割、対象、地域、製品、機密、許可用途を持ち、検索前に絞り込む。

   権限 tag、policy 対応、越権試験

7. 処理版

   parser、chunker、規則・model、tokenizer、parameter、時刻、人手修正を記録し、結果を再構築・比較可能にする。

   処理 manifest、設定版、実行 log

固定長、文段、構造、意味、親子方式は条件により使い分ける

内容を離れて最善の方式は決められない。固定長は基準を作りやすく、構造方式は規程や手順書に沿いやすい。親子方式は精密な検索とまとまった読解を両立できるため、実際の質問で比較して選ぶ。

長さを決める前に文書種類ごとの分けてはならない業務単位を見つける

契約条項、作業手順、価格表では、意味を保つ境界が異なる。条件、例外、単位、前後手順のうち何を一緒に残すべきかを先に決め、文字数やトークン数はその後で調整する。

サイズと overlap は問い、内容密度、model、検索 chain から導く

数百トークンという値は試験の出発点にはなるが、業界標準ではない。小さすぎれば条件を失い、大きすぎれば主題が薄まる。重複は境界を補う一方、重複結果、索引費用、引用の曖昧さも増やす。

理解に必要な構造を保ち、無関係な全文を戻さない

「限度額を超える場合は承認が必要」と読めば、どの限度額か、誰の承認か、例外はあるかが問題になる。良い切分は、その問いに必要な最小構造を残し、孤立断片にも全文返却にも偏らない。

表、画像、コード、添付を通常段落のように切らない

複雑な内容は関係の中に意味を持つ。数値は行列見出し、画像は説明文、コードは周辺スコープ、添付参照は参照先に依存する。長さだけで分けると文字は残っても業務上の意味が消え得る。

来歴、権限、削除義務を全派生 chunk へ伝播する

一つの原本が多数の派生記録になっても、アクセス境界は緩まない。権限、版、有効期間、削除指示を全断片へ引き継がなければ、通常の検索が原本の制御を迂回してしまう。

切分方式は版管理するデータ処理 chain で、一回限りの script ではない

原本が同じでも、解析器、切分規則、埋め込みモデルが変われば検索側が見る内容は変わる。各工程を再構築・比較できる処理系として記録しておけば、品質低下を引き起こした変更までたどれる。

1. 1. 代表文書・実質問を作る

   種類、長さ、言語、layout、機密、risk で sample を選び、質問、関連原文、返してはならない内容、期待引用を登録する。

2. 2. 解析 baseline を検証する

   原本、文字、順序、見出し、表、画像、添付を確認し、可靠に解析できない種類を切分 parameter で隠さず隔離する。

3. 3. 候補方式を作る

   内容種類ごとに構造優先境界、最大・最小長、overlap、親子、表・画像処理、異常 fallback を設定し、比較候補を残す。

4. 4. 監査可能な chunk を生成する

   本文、構造、metadata、来歴、権限、処理版を出し、空、超過、重複、truncate、文字化け、orphan、未coverage を検知する。

5. 5. 検索 chain で評価する

   tokenizer、embedding、index field、件数と切分を分離最適化せず、予定する keyword、vector、hybrid、rerank 設定で候補を試す。

6. 6. 業務・技術確認を得る

   内容所有者が意味・引用、利用者が質問、security が権限、技術が費用・性能・再構築・監視を確認し、組合せ版を固定する。

7. 7. 変更後に増分・全量再構築する

   情報源、parser、規則、tokenizer、embedding、権限方式の影響を分析し、比較不能な旧新 chunk 表現を同一 index に黙って混在させない。

8. 8. 監視・回帰する

   未検出、誤 chunk、truncate、重複証拠、引用切れ、費用を記録し、修正後に影響質問を回帰し、旧結果を残して差を説明する。

受入では chunk、検索、回答、権限、運用を分けて見る

読みやすい断片を数件眺めるだけでは証拠にならない。実際の質問で、必要な根拠を見つけられるか、制限情報を隠せるか、回答から原文へ戻れるか、更新後も安定して再構築できるかを確かめる。

失敗は「大きすぎる・小さすぎる」だけでは説明できない

検索に失敗するたびサイズを変えると、別の質問が悪化しやすい。まず症状を観察し、解析、構造、権限、版、重複排除、文脈組立のどこに原因があるかを見極める。

調達承認規程の切分例

以下は切分方式と検証証拠を説明する架空例で、顧客文書、実在規程、標準サイズ、実測検索結果、技術選定ではない。

企業 AI・RAG では切分が検索単位を決めるが、回答品質を単独では決めない

RAG の回答が誤ると、モデルが見る断片を決めるチャンキングは最初に疑われやすい。しかし原本から回答までには複数の処理層がある。各層を保存して初めて、パラメータ調整ではなく原因診断ができる。

文書チャンキングと隣接概念の違い

チャンキングは解析、索引、検索、文脈組立と一緒に語られるが、それぞれが解く問題は異なる。境界を明確にすると担当と層別試験を定めやすく、一つのパラメータで全工程を代用する誤りも避けられる。