RAGの回答精度を高めるためのセマンティックなPDFチャンキング戦略

PDFチャンキング戦略を見直してRAG精度を改善しよう

約13分で読めます
文字サイズ:
PDFチャンキング戦略を見直してRAG精度を改善しよう
目次

この記事の要点

  • RAG回答精度向上のためのPDFチャンキングの重要性
  • 従来の固定長チャンキングが抱える課題と限界
  • セマンティックチャンキングによる文脈維持と精度改善

実務の現場では、RAG(検索拡張生成)の導入プロジェクトにおいて、共通の課題に直面するケースが多く見られます。

「PoC(概念実証)までは進んだが、回答精度が実用レベルに達しない」
「社内規定のPDFを読み込ませたが、AIが表組みの内容を理解してくれない」
「エンジニアからは『これ以上の精度向上はモデルの限界です』と言われてしまった」

もし現在、このような状況にあるなら、少し立ち止まって考えてみてください。

その精度の低さは、本当にAIモデルのせいでしょうか?

実は、多くのケースにおいて、原因はAI(LLM)そのものではなく、AIに渡すデータの「切り方(チャンキング)」にあると考えられます。特に日本企業の業務マニュアルや就業規則に多い「PDF形式」は、AIにとって最も扱いが難しいデータの一つです。

本記事では、なぜ従来のやり方ではPDFの内容が正しく伝わらないのか、そして「セマンティックチャンキング」という手法がどう状況を打開するのか、実際の検証データを交えて解説します。技術的なコードの話は最小限に、顧客体験の向上と業務効率化へのインパクト、そして解決のロジックに焦点を当てていきます。

ユースケース概要:社内規定RAGの表組み誤読事例

まずは、現場で何が起きているのか、具体的な事例から見ていきましょう。ここでは、社内規定RAGにおける表組みの誤読について説明します。

シナリオ:就業規則に関する質問に答えられないAI

多くの企業で、人事部向けの問い合わせ対応RAGを構築するケースが増えています。その機能の一つに、複雑な就業規則や福利厚生規定をAIが即座に回答するというものがあります。

ユーザー(社員)がこう質問したと仮定します。
「祖母が亡くなった場合の忌引休暇は何日ですか?」

就業規則のPDFには、明確にこう書かれた表があります。

親族 休暇日数
配偶者 5日
父母 5日
祖父母 3日

人間が見れば「3日」だと一瞬で分かります。しかし、RAGが出した回答はこうなることがあります。

「就業規則によると、配偶者の場合は5日ですが、祖父母に関する規定は見当たりません。詳しくは専門家に相談することをおすすめします」

あるいは最悪の場合、表の行がずれて読み込まれ、「祖父母の場合は5日です」と誤った回答をしてしまうこともあります。このような不正確な回答は、ユーザーの顧客体験(CX)を著しく損なう原因となります。

なぜAIは「見えているはず」の情報を間違うのか

この現象は、AIが「文字を読めていない」のではありません。「文脈(コンテキスト)が切断されている」ために起こります。

PDFというフォーマットは、紙に印刷することを前提に作られています。人間にとっては視覚的に分かりやすい「レイアウト」や「ページ区切り」も、テキストデータとして抽出するAIにとっては、意味を分断するノイズになり得ます。

特に問題なのが、以下の要素です。

  • ページまたぎ: 表の途中でページが変わると、AIにとっては全く別のデータとして認識される。
  • 2段組み: 新聞のような段組みレイアウトを、左上から右下へ一直線に読んでしまい、文章が支離滅裂になる。
  • ヘッダー・フッター: ページごとの「2024年度版 就業規則」といった記述が本文中に混ざり込み、文脈を破壊する。

多くのプロジェクトでは、こうしたデータ側の問題を放置したまま、プロンプト(指示文)を工夫したり、より高価なLLM(ChatGPTなど)を使ったりして解決しようとします。しかし、入力データが不適切な状態であれば、どんなに高性能なAIでも正しい答えを出すことは難しいのが現実です。

「Garbage In, Garbage Out(ゴミを入れればゴミが出てくる)」

この古くからの格言は、最新の生成AI時代においても、データドリブンなシステム構築における重要な考え方として認識されています。

課題と背景:機械的分割による文脈喪失

では、具体的にデータの処理方法のどこに問題があるのでしょうか。ここで「チャンキング(Chunking)」という概念が登場します。

固定長チャンキング(Fixed-size Chunking)の限界

RAGの仕組みを簡単に説明すると、膨大なドキュメントを「チャンク」と呼ばれる小さな塊に分割し、質問に関連する塊を探し出してAIに渡す、というプロセスをたどります。

現在、多くのRAG構築ツールやチュートリアルで標準的に採用されているのが「固定長チャンキング」です。これは非常に単純で、「500文字ごと」や「1000トークンごと」に、機械的に文章を区切る手法です。

想像してみてください。小説を読んでいるとき、500文字ごとにハサミでページを切り取られ、その断片だけを渡されたらどうなるでしょうか?

  • ケースA: 「犯人は……」で紙が終わり、次の紙は「……ヤスだ」で始まる。
  • ケースB: 重要な見出し「第3章:セキュリティ対策」が前のチャンクに残り、本文「パスワードは10桁以上で……」が次のチャンクに行ってしまう。

これがRAGの中で起きています。

「見出し」と「本文」が泣き別れるメカニズム

検索システム(Retrieval)は、ユーザーの質問と似た意味を持つチャンクを探しに行きます。

ユーザーが「セキュリティ対策について教えて」と聞いたとき、システムは「セキュリティ対策」という言葉が含まれるチャンクを探します。しかし、先ほどの例のように見出しと本文が分断されていると、以下のようなことが起こります。

  1. 見出しだけのチャンクがヒットする: 「第3章:セキュリティ対策」とだけ書かれたチャンクが見つかるが、中身(本文)がないのでAIは答えられない。
  2. 本文のチャンクはヒットしない: 本文には具体的な手順しか書かれておらず、「セキュリティ対策」というキーワードが含まれていないため、検索漏れ(Recall低下)が起きる。

結果として、情報はドキュメント内に存在するのに、「関連情報が見つかりませんでした」という回答になります。

オペレーション現場への影響

これは、カスタマーサービスや社内ヘルプデスクの現場において、オペレーターの業務効率を大きく低下させる要因となります。

「マニュアルには書いてあるはずなのに、検索しても出てこない」
「AIが不正確な情報を提示するくらいなら、自分でPDFを開いて検索した方が早い」

こうなると、現場はAIを使わなくなる可能性があります。導入したシステムが活用されず、生産性向上という本来の目的が達成されない状況に陥ります。

固定長チャンキングは実装が簡単で初期コストも抑えられますが、ビジネス文書、特に構造化されたPDFにおいては、精度低下とそれに伴う顧客満足度の低下を招く原因となり得ます。

3. ソリューション概要:文書構造と意味を理解する「セマンティックチャンキング」とは

課題と背景:「機械的な文字数分割」が招く文脈の喪失と検索失敗 - Section Image

ここで提案したい解決策が「セマンティックチャンキング(Semantic Chunking)」です。

人間が読むようにAIに読ませるアプローチ

「セマンティック」とは「意味的な」という意味です。文字数で機械的に切るのではなく、文章の意味や構造のまとまりでデータを分割する手法を指します。

人間がPDFを読むとき、文字数で区切って読むことはありません。

  • 「第1章」から「第2章」の手前までが一つのまとまり。
  • 「表」はそれ全体で一つの情報。
  • 「箇条書き」はリスト全体で一つの意味。

このように、ドキュメントが本来持っている論理構造(セクション、パラグラフ、表、リスト)を認識し、その単位でチャンクを作成するのがセマンティックチャンキングです。顧客ジャーニー全体を俯瞰した際、ユーザーが求める情報を正確に提供するための基盤となります。

3つの主要なアプローチ

現在、この分野では主に3つのアプローチが実用化されており、ドキュメントの特性に合わせて選択します。

  1. レイアウト解析ベース:
    PDFの視覚情報を解析し、フォントサイズが大きいものを「見出し」、表組みを「テーブル」として認識します。UnstructuredLayoutParser といったツールが広く利用されています。視覚的に構造化されたマニュアルや規定集に特に有効です。

  2. LLMベース:
    ChatGPTなどの高性能モデル自体に文章を読ませ、「ここで話題が変わったから区切って」と判断させる方法です。精度は極めて高いですが、すべてのデータをLLMに通すため、処理コストと時間がかかる点が課題です。

  3. 埋め込み類似度ベース:
    文ごとのベクトル(意味の数値化)を比較し、意味が大きく変化したポイントを境界線とする手法です。計算コストと精度のバランスが良い手法として採用が進んでいます。

PDFの「見た目」ではなく「論理構造」を抽出する

特に重要なのは、PDF内の「表」の扱いです。

セマンティックなアプローチでは、表を単なる文字列の羅列ではなく、HTMLの <table> タグのような構造化データとして抽出したり、あるいはLLMを使って「この表は〇〇に関する一覧で、項目は××です」という要約テキストに変換してからチャンク化したりします。

これにより、先ほどの「忌引休暇」の例でも、表全体が一つのチャンクとして扱われるため、AIは「祖父母」と「3日」の関係性を正しく理解できるようになります。

検証:固定長とセマンティックの精度比較(シミュレーション)

検証:固定長とセマンティックの精度比較 - Section Image 3

「理屈は分かったけど、実際どれくらい変わるのか」と疑問に思われるかもしれません。ここでは、複雑なレイアウトを含む社内規定PDFを対象とした一般的な検証モデルケースを紹介します。データドリブンな視点で、どのような差が生じるのか定量的なイメージを見てみましょう。

テスト条件(モデルケース)

  • ドキュメント: 一般的な企業の「就業規則および福利厚生規定」(2段組み、表組み、箇条書き多数)
  • 固定長チャンキング: 500文字区切り、オーバーラップ(重複)50文字
  • セマンティックチャンキング: レイアウト解析を用い、セクション単位で分割。表は構造化テキストへ変換。
  • 評価モデル: ChatGPT(最新モデル)
  • 質問数: 30問(単純な事実確認から、複数の条項を組み合わせる推論まで)

結果比較:Retrieval(検索)精度の向上傾向

AIが回答するために必要な「正解の情報」を正しく検索できたか(Recall @5)を比較すると、多くの検証で以下のような傾向が見られます。

  • 固定長チャンキング: 60%前後
  • セマンティックチャンキング: 90%以上

約30ポイント近い向上が期待できます。特に差がつくのは、やはり「表の中の数値」を問う質問と、「条文の但し書き」に関する質問です。

回答品質のBefore/After事例

質問: 「退職時の有給休暇の買い取りは可能ですか?」

  • 固定長(Before)の回答例:
    「退職時の有給休暇については、原則として消化することが推奨されています。買い取りに関する具体的な規定は見当たりません。」
    (※解説: 買い取りに関する条項がページまたぎで分断され、検索にヒットしないケース)

  • セマンティック(After)の回答例:
    「原則として買い取りは行いません。ただし、第24条3項に基づき、会社が業務命令により消化を認めなかった場合に限り、例外的に買い取りの対象となる場合があります。」
    (※解説: 「原則」と「例外」が同じチャンクに含まれているため、正確な回答が可能になる)

この差は、ビジネスにおいては「リスク」の差に直結します。前者のような回答では、ユーザーとの間で無用なトラブルを引き起こし、顧客満足度を低下させる可能性があります。

5. 実装へのロードマップとコスト・パフォーマンスのトレードオフ

検証レポート:固定長 vs セマンティック 精度比較実験 - Section Image

ここまでセマンティックチャンキングの優位性を説明してきましたが、すぐにすべてのデータをこれで処理すべきというわけではありません。コスト削減と顧客体験向上の両立を目指し、バランスを見極めることが重要です。

処理時間とコストの増加について

セマンティックな解析は、単純な文字切りに比べて計算リソースを消費します。

  • 処理時間: 固定長なら一瞬で済みますが、レイアウト解析やLLM解析を入れると、1ページあたり数秒〜数十秒かかる場合があります。
  • APIコスト: LLMを使って構造化する場合、ドキュメントのインデックス作成(前処理)にかかるコストが増加します。

段階的な導入戦略:すべての文書に適用すべきか

ドキュメントの重要度に応じた段階的なAI導入戦略を推奨します。

  1. Tier 1(最重要・複雑): 就業規則、製品仕様書、契約書など。

    • 戦略: フルスペックのセマンティックチャンキング。表組み解析やLLMによる要約生成も実施。
    • コストはかかりますが、回答ミスが許されない領域には投資が必要です。
  2. Tier 2(中重要・一般的): 一般的なお知らせ、日報、議事録など。

    • 戦略: 簡易的なセマンティック分割(改行や空行での分割)や、少し長めの固定長チャンキング。
  3. Tier 3(低重要・大量): 過去のログデータなど。

    • 戦略: 従来の固定長チャンキングで十分な場合が多いです。

エンジニアチームへの具体的な依頼方法

プロジェクトを推進する際は、エンジニアチームに対して次のような観点で相談することが有効です。

「RAGの精度向上のために、モデルの変更だけでなくデータパイプラインを見直したい。特にPDFの『表』や『セクション』を認識して分割するライブラリ(UnstructuredやLlamaIndexなどのツール)の導入を検討できないか? まずは就業規則のPDFを対象に、パイロットテストをしてみたい」

コードの詳細はエンジニアに任せつつ、「構造を維持する」という目的を共有することが成功の鍵です。

まとめ:データの前処理こそがAIの知能を決める

RAGプロジェクトにおいて、私たちはつい「どのLLMモデルを使うか」という議論に注目しがちです。しかし、料理と同じで、どんなに優秀なシェフ(AI)でも、下処理されていない食材(前処理されていないデータ)を渡されれば、美味しい料理を作ることはできません。

  1. 精度低下の原因はPDFの「切り方」にあることが多い。
  2. 固定長チャンキングは文脈を破壊し、検索漏れを引き起こすリスクがある。
  3. セマンティックチャンキングで「意味のまとまり」を保持すれば、精度は大幅に向上する。

まずは手元のドキュメントを一つ選び、その切り方を変えるだけでどれほどAIの回答が変わるか、シミュレーションしてみてください。その小さな改善の積み重ねが、プロジェクト全体の品質向上と、優れた顧客体験の実現につながるはずです。

PDFチャンキング戦略を見直してRAG精度を改善しよう - Conclusion Image

コメント

コメントは1週間で消えます
コメントを読み込み中...