初めに
AIのユースケースは、比較的簡単に説明できます。
- RAGで社内文書に回答する
- Agentで問い合わせ対応を自動化する
- 契約書やマニュアルを検索できるようにする
ただ、これだけではAIアプリケーションの設計は決まりません。
たとえば「PDFをRAGに登録して質問に回答する」という要件があったとします。
ここで本当に確認すべきなのは、RAGを使うかどうかではありません。
どのようなデータがあり、どのような質問に答える必要があるかです。
先に結論
AIアプリケーションを設計するときは、次の順番で考えたほうが安定します。
ユースケースを決める
↓
実際のデータを確認する
↓
実際の質問を確認する
↓
回答に必要な証拠単位を確認する
↓
Parser・Chunking・検索方式を決める
↓
評価データで検証する
RAGは、検索対象となる外部知識と生成モデルを組み合わせる仕組みです。つまり、モデルだけではなく、検索可能な形で知識を準備できるかが前提になります。(arXiv)
重要なのは、最初から「Chunk Sizeは500」「Overlapは100」と決めることではありません。
データと質問を見てから、Chunkの境界を決めることです。
1. 同じPDFでも、必要な処理はまったく違う
「PDFをサポートする」という要件だけでは不十分です。
PDFには、次のような違いがあります。
| 確認項目 | 例 | 設計への影響 |
|---|---|---|
| テキスト層 | ネイティブPDF／スキャンPDF | OCRが必要か |
| レイアウト | 1段組み／複数段組み | 読み順を復元できるか |
| 表 | 単一ページ／複数ページ | 行列構造を保持できるか |
| 画像 | 写真／画面キャプチャ | 画像説明が必要か |
| 図 | Flowchart／構成図 | 空間的な関係を理解する必要があるか |
| ヘッダー・フッター | 文書名、版数、機密区分 | 本文と分離するか |
PDFを単純にテキスト化すると、表の列関係、図の矢印、本文と注釈の対応などが失われることがあります。
文書の構造要素を利用したChunkingは、単純な段落分割よりも、財務文書のRAG性能を改善できると報告されています。
また、Microsoftの公式資料でも、文書レイアウトを利用して見出し、段落、表などの構造を抽出し、構造を考慮してChunkを作る方式が説明されています。(Microsoft Learn)
つまり、最初に確認すべき質問は、
PDFに対応できますか？
ではなく、
このPDFの中で、回答に必要な情報はどのように表現されていますか？
です。
2. Excelは「ファイル」ではなく「構造」を見る
Excelも同じです。
次の二つは、どちらも.xlsxファイルですが、RAGでの扱いは異なります。
Excel A
└─ Sheet1：製品一覧
Excel B
├─ Summary：集計結果
├─ APAC：地域別売上
├─ EMEA：地域別売上
├─ Master：製品マスタ
└─ Notes：集計条件
確認すべきなのは、単にExcelを読み込めるかどうかではありません。
- 複数のSheetがあるか
- Sheet間に参照関係があるか
- 1行目がHeaderとは限らないか
- 結合セルや数式があるか
- 非表示Sheetを検索対象にするか
- 一つの質問で複数Sheetを参照するか
表形式データを単純な文字列として分割すると、列名と値の関係が切れやすくなります。
表の行やKey-Value構造を保持したChunkingは、固定長・再帰的Chunkingより検索性能を改善できるという研究結果もあります。(arXiv)
Excelでは、文字数よりも先に、次の単位を考える必要があります。
Workbook
↓
Sheet
↓
Table
↓
Header + Row
↓
Cell
どこまでを一つの「検索可能な証拠」とするかが重要です。
3. Chunkingは文書ではなく、質問から逆算する
Chunkingを考えるときは、実際に回答したい質問を確認します。
例1：単一の記述を探す質問
サービスを再起動するコマンドは何ですか？
必要な情報が、一つの手順やコードブロックに収まっている可能性があります。
この場合は、コマンドと説明を同じChunkに残し、完全一致検索やKeyword検索も利用できるようにします。
例2：複数箇所を組み合わせる質問
経費申請が却下される条件と、例外承認の手順を教えてください。
「却下条件」と「例外承認」が別の章に存在する場合、一つのChunkだけでは回答できません。
複数の証拠を検索し、関係を判断する必要があります。
例3：複数Sheetをまたぐ質問
APAC地域で売上が減少した製品について、製品マスタ上の担当部門も教えてください。
この質問では、売上Sheetと製品マスタを結合しなければ回答できません。
これは単純な類似検索ではなく、複数の情報を段階的に取得するMulti-hop Question Answeringに近い問題です。既存のRAGは、複数の証拠を取得して推論する質問を苦手とすることが報告されています。(ar5iv)
また、取得した情報をすべて長いContextへ入れれば解決するとは限りません。関連情報が長いContextの中央に置かれると、モデルの性能が低下する「Lost in the Middle」も確認されています。(arXiv)
つまり、Chunkingは文書を機械的に分割する作業ではありません。
質問に答えるための証拠を、検索できる単位へ変換する設計です。
4. 実装前に確認したいこと
RAGを作り始める前に、少なくとも次の対応表を作ります。
| 質問 | 必要なデータ | 証拠の場所 | 必要な処理 |
|---|---|---|---|
| 再起動コマンドは？ | 運用手順書 | 1つのコードブロック | Keyword＋Vector検索 |
| 申請の例外条件は？ | 規程PDF | 複数の章 | 複数Chunk取得 |
| 売上低下の担当部門は？ | 売上・製品マスタ | 複数Sheet | Query分解・結合 |
| 承認フローは？ | Flowchart | 画像内の矢印 | Multimodal解析 |
この表を作ると、必要な技術が見えてきます。
OCRが必要なのか
Layout Parserが必要なのか
表構造を保持するのか
Hybrid Searchが必要なのか
複数回検索するのか
AgentにToolを使わせるのか
Agentについても同じです。
「Agentで調査を自動化する」というユースケースだけでは、使用するTool、権限、停止条件、失敗時の処理、評価方法は決まりません。
Anthropicも、最初から複雑なAgentフレームワークを導入するのではなく、単純で組み合わせ可能なパターンから始めることを推奨しています。(Anthropic)
まとめ
AIのユースケースは、短い文章で説明できます。
RAGで文書に回答する
Agentで業務を自動化する
しかし、AIアプリケーションの難しさは、その後にあります。
確認すべきなのは、
- どのようなファイルがあるか
- ファイルの中に何が含まれているか
- どのような質問へ回答するか
- 一つの回答に何個の証拠が必要か
- その証拠をどの単位で検索するか
です。
RAGの設計は、Vector Databaseを選ぶところから始まりません。
実際のデータと、実際の質問を確認するところから始まります。
参考資料
- Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (arXiv)
- Yepes et al., Financial Report Chunking for Effective Retrieval Augmented Generation
- Liu et al., Lost in the Middle: How Language Models Use Long Contexts (arXiv)
- Tang et al., MultiHop-RAG: Benchmarking Retrieval-Augmented Generation for Multi-Hop Queries (ar5iv)
- Microsoft Learn, Chunk and Vectorize by Document Layout (Microsoft Learn)
- Anthropic, Building Effective Agents (Anthropic)