【要約】AWSでRAGシステムを構築する（前編）— 全体設計とIngestionパイプライン [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
[WARN: Partial Data] 本記事は全2編のうちの前編であり、設計とIngestionパイプラインに特化している。
// Problem
開発者が、実務で多用される複雑なレイアウトのPDFをRAGに活用しようとした際、情報の欠落という問題に直面した。
- ・単純なテキスト抽出では、表の数値と項目の対応関係が崩れる。
- ・グラフや図は画像データであるため、文字情報が取り出せない。
- ・数式がテキストとして正しく認識されず、意味が失われる。
- ・ページ全体をVLMに渡すと、解像度不足で細部が読み取れない。
// Approach
開発者は、PDFの各要素を構造的に解析し、Markdown形式へ変換するパイプラインを構築した。
- ・RapidLayoutを用いて、ページ内の要素（表、図、数式等）を検出する。
- ・要素ごとに切り出し、Claude Haiku 4.5等のVLMでMarkdown化する。
- ・節単位で分割し、breadcrumbを付与して文脈を保持する。
- ・Amazon Titan Text Embeddings V2でベクトル化し、OpenSearchへ投入する。
- ・画像ハッシュを用いたキャッシュ機構により、VLMの呼び出しコストを抑制する。
- ・Step Functionsにより、解析からインデックス投入までの工程を自動化した。
// Result
本設計により、図表や数式を含む難解な文書でも、検索可能な高精度なデータセットを自動生成できるようになった。
- ・要素ルーティングにより、図表や数式の構造を正確に保持した。
- ・VLMキャッシュの導入により、再実行時のコストと時間を大幅に削減した。
- ・ハイブリッド検索の基盤を整え、後編での精度評価に向けた準備を完了した。
- ・サーバーレス構成により、データ量に応じたスケーラビリティを確保した。
Senior Engineer Insight
> 実務における「PDFの読み取り精度」という急所に正面から向き合っている。特に、ページ全体ではなく要素単位でVLMに渡す手法は、解像度とコストのトレードオフを合理的に解決している。Step Functionsによる管理やVLMキャッシュの実装も、運用コストを重視する現場の要件を満たしている。ただし、VLMのプロンプト依存度が高いため、モデル更新時の回帰テストが運用の鍵となる。