Upgrade to Pro — share decks privately, control downloads, hide ads and more …

RAGでハマりがちな"Excelの罠"を、データの構造化で突破する

Avatar for harumi harumi
February 25, 2026

 RAGでハマりがちな"Excelの罠"を、データの構造化で突破する

こちらはFindy株式会社様主催のオンラインイベント「「RAG精度の壁を突破する-精度の壁とどう向き合う?」にて発表する資料です。
https://findy.connpass.com/event/383142/

内容:
RAGの精度改善において「データの扱い方」に焦点を絞り、その中でもExcel文書について現場的改善アプローチをして精度向上を計った話

Avatar for harumi

harumi

February 25, 2026
Tweet

Other Decks in Programming

Transcript

  1. 弊社内のRAGの制約と改善アプローチ 制約 • 外製でCMSスタイルの全社RAG基盤 • Naive RAG(BM25ベース検索) • 部署によっては独自RAG内製 •

    専門用語での文書QA用途が多い • RAG知識のある技術者少ない 改善アプローチ データ前処理 プロンプト改善 比較的誰でも行える改善は、この2軸に絞られる
  2. 問題例: 業務フローが正しく答えられない 倉庫 事業管理部 顧客サポート課 ECシステム 顧客 (業務フロー)お問合せフォームからの返品依頼 受 付

    不具合の検知 返品の依頼 ・依頼内容:返品要望 ・理由:パーツ欠品 受付 通知 翌日まで 判断 内容確認 返送依頼 受け付けない お断りの通知 受け付ける 通知 通知 終了 返送 返 品 入荷処理 ・商品 ・返品受付票 …. テキスト抽出後 ・PDFに変換→テキスト抽出 要素間の関係性が維持できない…
  3. Excelデータ解析の具体的アプローチ ◦ Office Open XML直解析 ◦ ClosedXML(C#) ◦ openpyxl/pandas ◦

    Excel Add-In ◦ Excel COM API Excelは蓋を開ければ 超複雑なxmlファイル群をzip圧縮 したもの → COM インタフェースを使えば比較的簡単にアクセス可能 ❌ 地獄 ❌ Drawing 系(図形・チャート等)は弱い ❌ 図形取得非対応 ❌ 処理パイプラインに組み込みづらい ✔ 生データにほぼアクセス可能、楽 → → → → → ※ COM = Compute Object Model
  4. xlwingsでExcel COM APIを操作 import xlwings as xw with xw.App(visible=False) as

    app: wb = app.books.open("sample.xlsx") ws = wb.sheets[0].api # Excel COM Worksheet for i in range(1, ws.Shapes.Count + 1): shp = ws.Shapes.Item(i) name = shp.Name kind = shp.Type box = (shp.Left, shp.Top, shp.Width, shp.Height) # optional: 図形テキスト(取れない形状もある) text = "" try: if shp.TextFrame2.HasText: text = shp.TextFrame2.TextRange.Text except Exception: pass print(name, kind, box, text[:30]) wb.close() ExcelVBAチックな簡単なAPIでほぼ全ての 要素にアクセス可能 ✓ 図形 ✓ グラフ ✓ SmartArt ✓ 印刷範囲 ✓ 条件付き書式 ✓ etc… デメリット: Windows + Excel必須
  5. ① Excel解析して意味構造化データを作る "shapes": [ { "text": "受付", "l": 3, "t":

    87, "kind": "arrow", "begin_arrow_style": 1, "end_arrow_style": 1, "direction": "N" }, { "id": 1, "text": "不具合の検知 ", "l": 445, "t": 110, "kind": "shape", "type": "AutoShape-FlowchartTerminator" }, { "id": 2, "text": "返品の依頼 ", "l": 454, "t": 156, "kind": "shape", "type": "AutoShape-FlowchartProcess" …
  6. ② LLMでMarkdownに変換 "shapes": [ { "text": "受付", "l": 3, "t":

    87, "kind": "arrow", "begin_arrow_style": 1, "end_arrow_style": 1, "direction": "N" }, { "id": 1, "text": "不具合の検知 ", "l": 445, "t": 110, "kind": "shape", "type": "AutoShape-FlowchartTerminator" }, { "id": 2, "text": "返品の依頼 ", "l": 454, "t": 156, "kind": "shape", "type": "AutoShape-FlowchartProcess" … ## (業務フロー)お問合せフォームからの返品依頼 ```mermaid flowchart TD A([不具合の検知 ]) --> B[返品の依頼] B -->|お問合せフォーム \n依頼内容:返品要望 \n理由:パーツ欠品 | C[受付\n顧 客サポート課] C --> D[内容確認] D --> E{判断} E -->|受け付ける| F[返送依頼\n顧客サポート課 ] E -->|受け付けない | G[お断りの通知 \n顧客サポート課 ] G -->|通知| H([終了]) F -->|通知\n商品・返品受付票 | I[返送\n顧客] I --> J[入荷処理\n倉庫] J --> K[検品\n倉庫] K --> L[返品登録依頼 \n倉庫] L --> M[返品登録\n事業管理部] M -->|商品No・返品理由・検品結果 | N[[在庫反映\nECシステム]] N --> O[(在庫\n倉庫)] O --> P{品質判定} P -->|良品| Q[[在庫反映\nECシステム]] P -->|不良品| R([月次「廃棄・メーカー返品」へ ]) Q -->|更新:商品No・販売可能数・販売しきい値 | S[(販売在庫\nECシステム)] S -->|反映:商品No・販売可能数・販売しきい値 | T[[商品ページ\nECシステム]] T --> U([終了]) ```
  7. 文字列一致ではPDF優位、データ欠損耐性では意味構造JSON優位 📝 文字列忠実度 (Exact/Normalized) 指標 PDF 意味構造 JSON 差分 acc

    (Exact) 0.608 0.584 -0.024 acc_norm 0.857 0.836 -0.021 ※ 厳密な文字列マッチではPDFが僅差で上 🛡 データ欠損耐性 (Raw/Precision) 指標 PDF 意味構造 JSON 差分 acc_raw 0.875 0.876 +0.002 raw_precision 0.909 0.934 +0.025 md_precision 0.776 0.796 +0.020 💡 RAGで効くのは「情報の欠損を防ぐ」こと → 構造保持・精度の高さで 意味構造JSON が優位 条件:n=12 Excel documents / methods: exstruct, openpyxl, pdf, html, image_vlm / model: gpt-4o / temperature=0.0 公開:benchmark/public/REPORT.md(再現用)・評価は「文字列一致」と「欠損耐性」の2軸で追跡 (GitHub: harumiWeb/exstruct)
  8. 銀の弾丸ではない(選び分け) 文書タイプで最適解が変わる。ハイブリッドや使い分けが大事。 シンプル文書 ↓ PDFでも十分 画像多め ↓ VLMでMarkdown化 神エクセル 構造が肝

    ↓ COM+構造化 その他検討できる手法: 手法 評価 MarkItDown 図形なしの文書ならかなり使いやすい HTML化 RAGと相性良いが汎用的な最適化に工夫必要 Azure AI Document Intelligence PDFにめっぽう強いがExcel解析は限定的