RAG Pipeline 前処理 — 能力境界の説明
本ドキュメントは、RAG Pipeline 前処理システムの能力範囲、既知の制限、およびリスク閾値を参考用として定義します。
1. ファイルタイプ対応マトリクス
1.1 直接対応しているファイルタイプ
| ファイルタイプ | 拡張子 | 解析ステップ | 備考 |
|---|
| PDF | .pdf | PDF_CONTENT_EXTRACTION / TEXTIN / AZURE_DI / ALI_OCR / LLM_CONTENT_EXTRACTION | 基本解析はテキスト型 PDF のみに適用され、スキャン文書は OCR ステップが必要 |
| Word 文書 | .docx | DOCX_CONTENT_EXTRACTION | pypandoc により Markdown へ変換し、段落/表/埋め込み画像をサポート |
| 旧版 Word | .doc | 先に FILE_CONVERT_WITH_SPIRE または FILE_CONVERT_WITH_LIBREOFFICE で変換が必要 | 直接解析不可、必ず .docx または .pdf に変換する必要あり |
| Markdown | .md | MD_CONTENT_EXTRACTION | ネイティブ対応 |
| プレーンテキスト | .txt | TXT_CONTENT_EXTRACTION | ネイティブ対応 |
| Excel | .xlsx .xls | TABULAR_CONTENT_EXTRACTION | 行数・列数の制限あり、§2 を参照 |
| CSV / TSV | .csv .tsv | TABULAR_CONTENT_EXTRACTION | — |
| PowerPoint | .pptx .ppt | 先に FILE_CONVERT_WITH_SPIRE または FILE_CONVERT_WITH_LIBREOFFICE で変換が必要 | 直接内容抽出は不可、先に PDF へ変換する必要あり |
| 画像 | .png .jpg .jpeg .gif .webp .svg | IMAGE_CONTENT_EXTRACTION | Vision LLM（例: GPT-4o）を使用して画像内容を記述、上限 300 語 |
| 動画 | .mp4 .avi .mkv .mov | VIDEO_CONTENT_EXTRACTION | 音声トラックを抽出 → テキストへ文字起こし |
| 音声 | .mp3 .wav .flac .aac | AUDIO_CONTENT_EXTRACTION | 60 秒ごとの断片に分割して順次文字起こし |
1.2 非対応 / 明示的に禁止されているファイルタイプ
| タイプ | 説明 |
|---|
.exe | ハードコードされたブラックリスト（_UNSUPPORTED_EXTENSIONS） |
.zip / .rar などの圧縮ファイル | 解凍ステップがなく、Pipeline では処理しない |
.html / .xml | 専用の解析ステップなし |
.json / .yaml | 専用の解析ステップなし |
.eml / .msg メール | 非対応 |
.dwg / .dxf CAD ファイル | 非対応 |
.rtf | 専用ステップなし（LibreOffice による変換は試行可能だが保証なし） |
| 暗号化 / パスワード保護ファイル | すべての形式で暗号化ファイルは処理不可 |
2. ファイルサイズとリソース制限
2.1 事前チェック制限（file_limit_checker）
アップロード時に軽量な事前チェックが実行され、制限超過ファイルはアップロード拒否または警告付きでマークされます：
| 次元 | デフォルト閾値 | 設定可能 | 説明 |
|---|
| 文字数 | 15,000 文字 | ✅ FILE_LIMIT_CHECK_CONFIG 環境変数で設定 | PDF/DOCX/TXT/MD/CSV/XLSX などのテキスト系ファイルに適用 |
| ページ数 | 25 ページ | ✅ 同上 | PDF は物理ページ数、Excel は Sheet 数、PPT はスライド数で計算 |
⚠️ ナレッジベースのファイルソース一括インポートはこの事前チェック制限の対象外ですが、ファイルが大きすぎる場合は依然として OOM リスクがあります。
2.2 Pipeline 処理内のリソース閾値
| リソース次元 | 閾値 / 設定 | リスク |
|---|
| PDF 並列ページ変換 | 1 バッチあたり 50 ページ（PDFConversionDefaultOptions.CHUNK_SIZE） | 超大規模 PDF（500+ ページ）は pdf2image 変換時のメモリ使用量が高く、OOM を引き起こす可能性あり |
| 表の行数 | 1 Sheet ≤ 20,000 行 | 超過時は直接エラーとなり解析拒否 |
| 表の列数 | 1 Sheet ≤ 200 列 | 超過時は直接エラーとなり解析拒否 |
| 表の画像 | 1 ファイル ≤ 150 枚（_MAX_IMAGES） | 超過分の画像は無視 |
| ベクトル化バッチ | 1 バッチあたり 100 セグメント（batch_size） | — |
| セグメント画像密度 | 1 セグメント ≤ 5~8 枚の画像 | 超過時は token オーバーフロー回避のため早期分割を実施 |
| 音声スライス | 60 秒 / セグメント | 長時間の音声/動画では大量の文字起こし API 呼び出しが発生 |
| TextIn OCR | API レベル設定で最大 1,000 ページ | クォータ枯渇時はエラー |
2.3 OOM / リソース過負荷リスクのシナリオ
| シナリオ | リスクレベル | 原因 | 推奨 |
|---|
PDF > 200 ページ + pdf2image | 🔴 高 | pdf2image は 300 DPI で各ページをメモリ上の bitmap としてレンダリングし、200 ページ ≈ 数 GB のメモリ | 基本解析の代わりに OCR ステップ（TextIn/Azure DI）を使用 |
| Excel 単一 Sheet > 10,000 行 | 🟡 中 | 全量をメモリに読み込み、大量の段落を生成 | ファイルを事前分割するか worker メモリを増やす |
| 動画 > 2 時間 | 🟡 中 | ffmpeg による音声抽出 + 120 回の 60s 文字起こしリクエスト | 動画長を制限するか事前に分割 |
| 単一ファイルに 100+ 枚の埋め込み画像 | 🟡 中 | 各画像ごとに Vision LLM 呼び出しが必要で、時間とコストが高い | 重要な画像のみ抽出 |
| 1,000+ ファイルの一括インポート | 🟡 中 | Celery worker キューが滞留し、gevent の並列上限は 100 | 分割してインポートし、キュー深度を監視 |
3. ファイル解析能力のレベル分け
3.1 解析エンジン比較
| エンジン | 解析方式 | 適用シナリオ | 不適用シナリオ | 依 存関係 |
|---|
| Basic（pypdf / pdfplumber） | テキストレイヤーを直接抽出 | ネイティブテキスト PDF（Word 出力、LaTeX 生成など） | スキャン文書、画像 PDF、複雑なレイアウト | 外部依存なし |
| TextIn OCR | クラウド OCR + レイアウト解析 | スキャン文書、伝票、混在レイアウト PDF | — | TEXTIN_APP_ID / TEXTIN_APP_SECRET |
| Azure Document Intelligence | クラウド Layout/Read モデル | 表構造の保持、複数カラムレイアウト | — | azure_ocr_endpoint / azure_ocr_key |
| Ali OCR | Alibaba Cloud OCR | 中国語シナリオのスキャン文書 | — | Alibaba Cloud API 認証情報 |
| LLM 解析（PDF LLM） | ページスクリーンショット → Vision LLM 認識 | 極めて複雑な版面、図文混在 | 大容量ファイル（高コスト・低速） | Vision LLM（GPT-4o など） |
| pypandoc | Pandoc 形式変換 | DOCX → Markdown | 複雑なマクロ、ActiveX コントロール | Pandoc バイナリ |
| LibreOffice / Spire | 形式変換エンジン | .doc→.docx、.ppt→.pdf | — | LibreOffice または Spire ランタイム |
3.2 各ファイルタイプの解析能力詳細
PDF
| 特性 | Basic | TextIn | Azure DI | LLM |
|---|
| プレーンテキスト抽出 | ✅ | ✅ | ✅ | ✅ |
| スキャン文書 / 画像 PDF | ❌ 空を返す | ✅ | ✅ | ✅ |
| 表構造の保持 | ❌ 書式喪失 | ✅ | ✅（Layout モード） | ✅ |
| 複数カラムレイアウト | ❌ テキストが乱れる | ✅ | ✅ | ✅ |
| ハイパーリンク抽出 | ✅（pdfplumber） | ❌ | ❌ | ❌ |
| 埋め込み画像抽出 | ✅（PNG に変換） | ✅ | ✅ | ✅ |
| 処理速度 | ⚡ 高速 | 🐢 中 | 🐢 中 | 🐌 低速 |
| コスト | 無料 | 💰 ページ課金 | 💰 ページ課金 | 💰💰 token 課金 |
DOCX
| 特性 | 対応状況 |
|---|
| 段落テキスト | ✅ |
| 表 | ✅（Markdown 表へ変換） |
| 埋め込み画像 | ✅（独立ファイルとして抽出 + Markdown マーク） |
| 目次 / ブックマーク | ⚠️ 一部対応（Pandoc 変換時に失われる可能性あり） |
| マクロ / VBA | ❌ 無視 |
| 変更履歴 / コメント | ❌ 消失 |
| 複雑なネスト表 | ⚠️ Pandoc の挙動は不安定 |
表形式ファイル（Excel / CSV）
| 特性 | 対応状況 |
|---|
| 複数 Sheet | ✅ Sheet ごとに処理 |
| 数式 | ⚠️ 計算後の値のみを読み取る（data_only=True） |
| グラフ / ピボットテーブル | ❌ 無視 |
| 埋め込み画像 | ✅（上限 150 枚 / ファイル） |
| 結合セル | ⚠️ データずれを引き起こす可能性あり |
| 20,000 行超過 | ❌ 解析拒否 |
| 200 列超過 | ❌ 解析拒否 |
音声・動画
| 特性 | 対応状況 |
|---|
| 音声文字起こし | ✅（60s ごとの分割文字起こし） |
| 多言語認識 | 文字起こしサービスのモデルに依存 |
| 話者分離 | ❌ |
| 背景音楽 / ノイズ | ⚠️ 文字起こし品質に影響 |
| 動画画面内容の認識 | ❌ 音声トラックのみ抽出 |
| 字幕 / CC 抽出 | ❌ |
| 特性 | 対応状況 |
|---|
| 画像内容の記述 | ✅ Vision LLM による記述（≤ 300 語） |
| OCR 文字認識 | ⚠️ Vision LLM の能力に依存し、専門 OCR ではない |
| グラフ / フローチャート理解 | ⚠️ 限定的（LLM の理解力に依存） |
| SVG ベクター画像 | ⚠️ LLM がレンダリング可能かに依存 |
4. セグメンテーション（Segmentation）能力と制限
| セグメンテーション方法 | 適用シナリオ | パラメータ | 制限 |
|---|
固定文字数（FIXED_SIZE） | 汎用テキスト | chunk_size=1024 | 文の途中で切断される可能性あり；1 セグメント ≤ 5~8 枚の画像 |
ページ単位（PAGE） | PDF 文書 | — | PDF のみ有効；ページごとの差が大きい場合、段落品質が不均一 |
見出し単位（TITLE） | Markdown 文書 | chunk_size=1024 | # / ## / ### 見出しのみ認識；見出しがない場合は文書全体が 1 セグメントに退化 |
表形式（TABULAR） | Excel / CSV | — | 表形式ファイル専用 |
LLM インテリジェント（LLM） | 意味的一貫性が必要なシナリオ | — | 低速・高コスト；大容量ファイルには非経済的 |
細分化（REFINE） | 粗分割結果の二次最適化 | — | 上流の粗分割ステップと組み合わせて使用する必要あり |
共通制限：
- 分割時に表 / コードブロックが切断されないよう保護（
RecursiveCharacterTextSplitter のフォールバック区切り文字）
- 超長セグメント（> 65% chunk_size）は spaCy を用いて文単位で細分化
- 1 セグメント内の画像が多すぎる場合（> 5 枚）は強制分割を実施
5. フィールド抽出能力
| ステップ | 機能 | 依存関係 | 制限 |
|---|
METADATA_EXTRACTION | 文書レベルのメタデータ（タイトル/著者/日付など） | LLM | Schema は事前定義が必要 |
SEGMENT_METADATA_EXTRACTION | 段落レベルのメタデータ | LLM | 各段落ごとに 1 回の LLM 呼び出しが必要で、大容量ファイルでは高コスト |
KEYWORDS_EXTRACTION | キーワード抽出 | LLM | — |
SEGMENT_SUMMARY | 段落要約 | LLM | 各段落ごとに 1 回の LLM 呼び出し |
DOCUMENT_SUMMARY | 全文要約 | LLM | 長文書では切り詰めまたは分割集約が必要 |
TABLE_CAPTIONING | 表の説明生成 | LLM | — |
TABLE_CAPTIONING_ADVANCED | 表レベル要約 + 行レベル叙述のグループ化 | LLM | 複雑な表の 効果は LLM の理解力に依存 |
IMAGE_CAPTIONING | 画像説明生成 | Vision LLM | 各画像ごとに 1 回の LLM 呼び出し |
6. 後処理（Postprocessing）能力
| ステップ | 機能 | 設定 | 制限 |
|---|
EMBEDDING | テキストのベクトル化 | batch_size=100 | Embedding モデルに依存；画像プレースホルダーは自動的に除去 |
TOKENIZER | 全文インデックス用トークン化 | spaCy 言語モデル | PostgreSQL tsvector の長さ制限 |
EMBEDDING_STORE | ベクトルを VectorDB に書き込み | — | バッチ書き込みで、VectorDB の性能に依存 |
TOKENIZER_STORE | トークンを PostgreSQL に書き込み | — | — |
7. 形式変換能力
| 入力形式 | 出力形式 | 変換エンジン | 制限 |
|---|
.doc | .docx / .pdf | LibreOffice / Spire | サーバー側に対応ランタイムのインストールが必要 |
.ppt | .pdf | LibreOffice / Spire | アニメーション/トランジション効果は失 われる |
.pptx | .pdf | LibreOffice / Spire | 同上 |
8. 外部サービス依存
| サービス | 環境変数 | 用途 | 未設定時の影響 |
|---|
| TextIn OCR | TEXTIN_APP_ID / TEXTIN_APP_SECRET / TEXTIN_APP_ENDPOINT | PDF/画像 OCR | 対応 OCR ステップが利用不可 |
| Azure Document Intelligence | azure_ocr_endpoint / azure_ocr_key | PDF Layout 解析 | 対応ステップが利用不可 |
| Ali OCR | Alibaba Cloud 認証情報 | 中国語 OCR | 対応ステップが利用不可 |
| Embedding モデル | LLM Gateway 設定 | テキストのベクトル化 | EMBEDDING ステップが利用不可 |
| Vision LLM | LLM Gateway 設定 | 画像説明 / LLM PDF 解析 | IMAGE/LLM ステップが利用不可 |
| 汎用 LLM | LLM Gateway 設定 | 要約/キーワード/メタデータ抽出 | フィールド抽出ステップが利用不可 |
| LibreOffice | サーバー側バイナリ | 形式変換 | .doc/.ppt を処理不可 |
| Pandoc | サーバー側バイナリ | DOCX → Markdown | DOCX 解析が利用不可 |
| ffmpeg | サーバー側バイナリ | 動画音声トラック抽出 | 動画処理が利用不可 |
| spaCy | Python パッケージ + 言語モデル | トークン化/文分割 | TOKENIZER ステップお よび細分化機能が利用不可 |
9. 既知の境界ケース一覧
| # | シナリオ | 挙動 | 推奨処理方法 |
|---|
| 1 | スキャン文書 PDF + Basic 解析 | 抽出内容が空 | TextIn / Azure DI / LLM ステップへ切り替え |
| 2 | 複数カラム PDF + Basic 解析 | テキスト順序が乱れ、段落が交差 | Azure DI Layout モードを使用 |
| 3 | PDF 内の複雑な表 + Basic 解析 | 表構造が失われ、データが散文化 | TextIn / Azure DI を使用 |
| 4 | 暗号化 / パスワード保護 PDF | pypdf が例外を送出 | 前処理でパスワード保護を解除 |
| 5 | .doc（旧版 Word）の直接アップロード | ネイティブ解析器なし | Pipeline にファイル変換ステップを含めることを確認 |
| 6 | Excel が 20,000 行超過 | 解析拒否、エラー送出 | 複数ファイルに分割 |
| 7 | Excel の結合セル | データがずれる可能性あり | アップロード前に結合を解除 |
| 8 | Excel の数式 | 結果値のみを読み取り、数式自体は対象外 | 想定どおりの挙動 |
| 9 | 動画は音声トラックのみ抽出 | 画面内容は認識不可 | 画面情報が必要な場合はキーフレームを切り出して別途処理 |
| 10 | 画像 OCR 精度 | Vision LLM は専門 OCR ではなく、精度に限界あり | OCR 要件が高いシナリオでは TextIn を使用 |
| 11 | 大容量ファイル + LLM 解析 | コストが非常に高い（ページ/token 課金） | 重要文書にのみ LLM 解析を使用 |
| 12 | 見出し構造のない Markdown + TITLE 分割 | 文書全体が 1 段落になる | FIXED_SIZE 分割へ変更 |
| 13 | PPT アニメーション/動画埋め込み | PDF 変換後に消失 | 解決策なし |
| 14 | マクロ/VBA/ActiveX を含む DOCX | すべてのマクロ内容を無視 | 想定どおりの挙動 |
| 15 | DOCX の変更履歴/コメント | 消失 | アップロード前にすべての変更を承認 |
10. 容量計画の推奨
| ファイルタイプ | 推奨上限（単一ファイル） | 理由 |
|---|
| PDF（Basic 解析） | ≤ 50 ページ | pdf2image のメモリ消費；50 ページ超で OOM リスクあり |
| PDF（OCR 解析） | ≤ 100 ページ | OCR サービス API 制限とコストの影響 |
| DOCX | ≤ 20,000 文字 | Pandoc 変換時のメモリ |
| Excel | ≤ 20,000 行 × 200 列 / Sheet | ハード制限 |
| CSV | ≤ 20 MB | 全量をメモリに読み込むため |
| 音声 | ≤ 60 分 | 60 回の文字起こし API 呼び出し |
| 動画 | ≤ 30 分 | ffmpeg 抽出 + 文字起こし；長時間になるほど失敗確率が高い |
| 画像 | ≤ 10 MB / 枚 | Vision LLM 入力制限 |
本ドキュメントはコード分析に基づいて生成されており、実際の動作はデプロイ環境（メモリ / CPU / ネットワーク）および外部サービスの状態によって異なる場合があります。本番環境で使用する前に、対象に応じた負荷試験を実施することを推奨します。