「社内文書のRAGを構築したが、ExcelやPDFの表データにある数値について質問すると、なぜか間違った回答が返ってくる」
「表の構造が複雑になると、LLMがどの列のデータを読めばいいのか混乱しているようだ」
RAG（検索拡張生成）の実装において、こうした表データの扱いに頭を抱えている開発者や担当者は非常に多いのが現状です。
通常のテキストデータであれば高精度に回答できるシステムでも、表形式になった途端に精度がガタ落ちしてしまうことは珍しくありません。
本記事では、なぜRAGにとって表データの処理が難しいのかというメカニズムから、認識精度を劇的に改善するためのデータ加工テクニック、検索手法、そしてプロンプトのコツまでを網羅的に解説します。
数多くの生成AI導入支援を行ってきた経験に基づき、現場ですぐに試せる実践的なノウハウをまとめました。
表データの認識課題を解決し、実務で真に使えるRAGシステムを構築するために、ぜひ本記事の内容をお役立てください。
なぜRAGは表データの認識が苦手なのか？精度が下がる根本原因
RAGシステムにおいて、表データに関する質問への回答精度が低くなるのには、明確な技術的理由が存在します。
人間が見れば一目で理解できる表であっても、コンピュータ、特にテキストとしてデータを処理するLLMや検索エンジンにとっては、非常に解釈が難しい形式だからです。
ここでは、一般的なRAGのプロセスにおいて、表データがどのように処理され、どこで情報が欠落してしまうのか、その根本的な原因を3つの観点から解説します。
RAGの主要なユースケースであるChatGPTでの社内文書検索について、導入メリットから具体的な事例まで、こちらの記事で詳しく解説しています。 合わせてご覧ください。
一般的なテキスト分割（チャンク化）で表の構造が崩れてしまう理由
RAGでは通常、長いドキュメントを一定の文字数ごとの塊（チャンク）に分割してベクトル化し、データベースに保存します。
文章であれば、句読点や段落で区切ることで意味をある程度保つことができますが、表データの場合、この単純な分割処理が致命的な問題を引き起こします。
例えば、100行ある売上データの表を考えてみてください。
単純に文字数で分割すると、表のヘッダー（項目名）が含まれるのは最初のチャンクだけで、それ以降のチャンクには「数値の羅列」だけが含まれることになります。
これでは、2つ目以降のチャンクが検索されても、その数値が「4月の売上」なのか「5月の利益」なのか、LLMには判断する術がありません。
また、PDFからテキストを抽出する際、表の横並びのレイアウトが崩れ、セル内のテキストが改行によってバラバラに配置されることもよくあります。
隣り合う列の情報が離れ離れになったり、逆に行の順序が混ざったりすることで、本来の「行と列のマトリクス構造」という重要な情報が失われてしまうのです。
PDFやExcelの表データがLLMに正しく伝わらないメカニズム
私たちがPDFやExcel上の表を見るとき、罫線や背景色、文字の配置といった視覚情報を頼りにデータの関係性を理解しています。
しかし、標準的なテキスト抽出ツールを使ってこれらのファイルを読み込むと、それらの視覚情報はすべて削ぎ落とされ、単なる文字列として出力されます。
特にPDFは「印刷するためのフォーマット」であり、内部的にはデータ構造を持っていません。
そのため、プログラムがPDFを解析する際、それが「表である」ことすら認識できず、単なる段落の一部として処理してしまうケースが多々あります。
Excelの場合も同様で、見た目を整えるために「セルの結合」や「空白行の挿入」が行われていると、プログラム的にはデータの連続性が途切れていると判断されたり、関係のないデータが紐づいてしまったりします。
LLMは基本的に「左から右、上から下」へと流れるテキストを予測・理解するモデルです。
二次元的に配置された表データを無理やり一次元のテキストストリームに変換して渡されると、どの数値がどの項目に対応するのかという位置関係のコンテキストを正しく掴むことが極めて困難になるのです。
数値の羅列や複雑なセル結合がハルシネーションを引き起こすリスク
表データ特有の問題として、LLMがもっともらしい嘘をつく「ハルシネーション」を誘発しやすいという点も挙げられます。
これは、表データが文脈の希薄な「数値や単語の羅列」になりがちであることが関係しています。
通常の文章であれば、前後の文脈から内容を推測することが可能です。
しかし、表の中にある「100」「200」「300」といった数値だけを見ても、そこに論理的な必然性や文脈はありません。
LLMが回答を生成する際、本来参照すべきセルが「3行目の2列目」であるにもかかわらず、表の構造が崩れて認識されているために、誤って「3行目の3列目」の数値を拾ってしまうことが頻発します。
特に複雑なセル結合がある場合、1つの親項目に対して複数の子項目がぶら下がっている構造をテキストだけで表現するのは至難の業です。
LLMは「この数値はこの項目のものだろう」と確率的に推測を行いますが、構造情報が曖昧な状態ではその推測が外れる確率が高くなります。
結果として、ユーザーには自信満々に間違った数値を回答してしまい、業務利用における信頼性を大きく損なう原因となります。
LLMがもっともらしい嘘をつく「ハルシネーション」を防ぐ具体的なプロンプトや対策について、こちらの記事で詳しく解説しています。 合わせてご覧ください。
RAGで表データを正しく認識させるためのデータ加工・前処理テクニック
表データの認識精度を高めるために最も重要なのが、検索システムにデータを入れる前の「前処理」の工程です。
LLMが理解しやすい形に表データを整形してあげるだけで、回答精度は飛躍的に向上します。
ここでは、RAG開発の現場で実際に効果が出ている、表データ処理の具体的なテクニックを紹介します。
最も推奨される手法！表データをMarkdown形式へ変換するメリット
現在、表データをテキストとしてLLMに渡す際、最も推奨されているのが「Markdown形式」への変換です。
Markdownの表記法（パイプ | とハイフン – を使う形式）は、トークン数を比較的抑えつつ、表の構造（行と列の関係）をテキスト上で明確に表現できるため、LLMにとって非常に理解しやすいフォーマットです。
CSV形式もシンプルで良いのですが、カンマ区切りだけでは列の位置関係が視覚的にわかりづらく、データ内にカンマが含まれる場合の処理も複雑になりがちです。
一方、Markdown形式であれば、LLMはそれが「表である」ことを明確に認識でき、ヘッダー行とデータ行の対応関係も保持されやすくなります。
実装する際は、PDFやExcelからデータを抽出した後、ライブラリ等を使ってMarkdown形式に変換してからベクトルデータベースに格納することをおすすめします。
このひと手間を加えるだけで、「A列の項目に対するB列の値」を問うような質問への正答率が格段に安定します。
特にGPT-4oやGPT-5といった高性能なモデルはMarkdownの解釈能力が高いため、非常に相性の良い手法と言えます。
GPT-5の最新情報やGPT-4との違いについては、こちらの記事で詳しく解説しています。 合わせてご覧ください。
表の構造を維持するために「行単位」ではなく「意味単位」で分割する
前述の通り、表データを機械的に一定の文字数で分割（チャンク化）してしまうと、情報が分断されてしまいます。
これを防ぐためには、表の構造を意識した「意味単位」での分割戦略が必要です。
具体的には、表の各行をバラバラにするのではなく、「1つの表全体」あるいは「意味的なまとまり」を1つのチャンクとして扱うのが理想です。
もし表が非常に大きく、1つのチャンク（モデルの入力制限）に収まらない場合は、分割したそれぞれのチャンクに必ず「ヘッダー行（項目名）」を付与するという処理を行います。
例えば、100行ある表を50行ずつ2つに分割する場合、後半の50行のデータの先頭にも、本来の表にあったヘッダー行をコピーして付け加えます。
これにより、検索によって後半のチャンクだけがヒットした場合でも、LLMは「この数値がどの項目のものか」を正しく理解できるようになります。
また、表が含まれるセクションの見出しや、表のタイトルも合わせて各チャンクに含めることで、検索時のヒット率と回答精度をさらに高めることができます。
表の内容を要約したテキストをメタデータとして付与する手法
表データそのものを検索対象にするだけでなく、その表が何を表しているのかという「要約テキスト」を作成し、メタデータとして付与する手法も非常に有効です。
表の中には数値や記号しか入っていないことも多く、ユーザーが自然言語で質問した際に、キーワードマッチやベクトル検索でうまく引っかからないことがあります。
そこで、LLMを使って事前に「この表は〇〇年度の部門別売上推移を示しており、特に第3四半期に××部門が大きく成長している」といった要約文を生成しておきます。
そして、この要約文をベクトル化してインデックスに登録し、実際の数値データ（Markdown形式の表など）はそのチャンクに紐づく生のデータとして保持させます。
ユーザーからの検索クエリは、まずこの「要約文」との類似度で検索を行い、ヒットした場合は紐づいている「元の表データ」全体をLLMに渡して回答を生成させます。
これにより、表の中の具体的な数値そのものを検索クエリに含めなくても、「売上が伸びている部門を知りたい」といった抽象的な質問で適切な表を見つけ出すことが可能になります。
【比較】表データを「画像」として扱うか「テキスト」として扱うか
最近のマルチモーダルモデル（GPT-4o、GPT-5など）の進化により、表をテキストデータとして抽出するのではなく、表のスクリーンショットそのものを「画像」としてLLMに見せるというアプローチも現実的になってきました。
それぞれの方法にはメリットとデメリットがあります。
テキスト（Markdown等）として扱う手法は、トークン消費量が少なく、計算コストや速度の面で有利です。
また、具体的な数値の検索や、データベース的な処理には依然としてテキスト形式が適しています。
しかし、レイアウトが極めて複雑な表や、セル結合が多用されている表の場合、テキストへの変換過程で構造が崩れるリスクがあります。
一方、画像として扱う手法は、人間が見ているのと全く同じ情報をLLMに入力できるため、複雑なレイアウトや色分けされた情報の理解において圧倒的に有利です。
ただし、画像処理はトークンコストが高くなりがちで、大量の表データを含むドキュメント全てを画像として処理するのはコスト的に見合わない場合があります。
現状の最適解としては、基本はテキスト（Markdown）変換を行い、テキスト化が困難な複雑な表に限って画像として処理する、あるいはその両方をハイブリッドで活用するのが賢明です。
こちらは視覚的な表やUIを理解するためのGoogleのマルチモーダルモデルについて解説した論文です。画像処理のアプローチとして合わせてご覧ください。 https://arxiv.org/abs/2210.03347
検索漏れを防ぐ！表データに特化した検索手法とインデックス設計
データを綺麗に加工しても、ユーザーの質問に対して適切な表データが検索（Retriever）されなければ意味がありません。
表データの検索は通常の文章検索とは異なる難しさがあります。
ここでは、表データを見つけ出し、LLMに届けるための検索ロジックやインデックス設計の工夫について解説します。
キーワード検索とベクトル検索を組み合わせたハイブリッド検索の実装
RAGでは意味検索（ベクトル検索）が主流ですが、表データの検索においては、従来の「キーワード検索」の重要性が高まります。
なぜなら、表の中にある固有の商品名、型番、具体的な数値といった情報は、ベクトル化による意味空間への変換よりも、完全一致などのキーワードマッチングの方が正確に捉えられることが多いからです。
例えば「型番A-123の価格は？」と聞かれた場合、ベクトル検索では「型番」や「価格」といった意味の近さで検索を行いますが、肝心の「A-123」という記号的な文字列の特定が甘くなることがあります。
キーワード検索であれば、「A-123」という文字列が含まれるドキュメントをピンポイントで拾い上げることができます。
そのため、表データを扱うRAGシステムでは、ベクトル検索とキーワード検索を並行して実行し、それぞれの結果を統合して再ランク付け（Reranking）する「ハイブリッド検索」の実装がほぼ必須と言えます。
これにより、抽象的な質問にはベクトル検索が、具体的な値や名称を含む質問にはキーワード検索が機能し、検索漏れを大幅に減らすことができます。
表全体を親ドキュメントとして保持する「Parent Document Retriever」の活用
表データの検索において特に効果的なのが、「Parent Document Retriever（親ドキュメント検索）」という手法です。
これは、検索用のデータ（小さなチャンク）と、LLMに渡す回答生成用のデータ（大きなチャンク）を分けて管理する仕組みです。
大きな表データをそのままベクトル化すると情報が埋もれてしまい検索精度が落ちるため、まずは表を行単位や小さなセクションごとに細かく分割してベクトル化し、インデックスを作成します。
しかし、回答を生成する際には、その細かい断片だけでは文脈が不足してしまいます。
そこで、細かいチャンクが検索でヒットしたら、そのチャンク単体ではなく、紐づけられている「元の表全体（親ドキュメント）」を取得してLLMに渡すのです。
こうすることで、検索時は「表の中の特定の行」にピンポイントでヒットさせつつ、LLMには「表全体の構造と前後の文脈」を提供できるため、全体を見渡した正確な回答生成が可能になります。
表データ特有の「部分と全体」の問題を解決する非常に強力なアプローチです。
小さな表データ（Small-to-Big）と大きな表データの扱い方の違い
表のサイズによって、最適な処理方法は異なります。
スライド資料に含まれるような小さな表であれば、前後の文章と同じチャンクの中にMarkdown形式で埋め込んでしまっても問題ありません。
この場合、文脈と表がセットになっているため、LLMは自然に内容を理解できます。
一方、Excelファイルのような巨大な表データの場合、そのままではコンテキストウィンドウ（入力可能な文字数制限）を圧迫あるいは超過してしまいます。
このような「大きな表データ」に対しては、前述の「要約メタデータ」による検索や、Pandasのようなデータ分析ライブラリと連携させる「エージェント型」のアプローチが有効です。
エージェント型のアプローチでは、LLMに表の全データを渡すのではなく、まず「この表にはどんな列があるか（スキーマ情報）」だけを伝えます。
そしてLLM自身に「2023年の総売上を計算するPythonコード」などを生成・実行させ、その実行結果だけを受け取って回答を作成します。
RAGの一部として、こうしたコード実行環境（Code Interpreter的な機能）を組み込むことで、巨大な表データに対する高度な分析や回答が可能になります。
こちらは推論と計算を分離し、Pythonコードで計算を行う手法について解説した論文です。より深い技術的な理解のために合わせてご覧ください。 https://arxiv.org/abs/2211.12588
パターン別解説！この表データならどう処理するのが正解か
一口に「表データ」と言っても、その形状や複雑さは千差万別です。
すべての表に同じ処理を適用するのではなく、データの特性に合わせて処理フローを使い分けることが成功の鍵です。
ここでは、よくある3つのパターンについて、それぞれの最適な処理方針を解説します。
パターン1：記号や結合のないシンプルな表データの場合
財務諸表やスペック表のように、セル結合がなく、1行が1つのレコードとして完結しているシンプルな表の場合、処理は比較的容易です。
このパターンでは、Markdown形式への変換またはCSV形式への変換が最も効率的かつ高精度です。
具体的には、PDFやWordから表部分を抽出し、Markdownのテーブル記法に変換してテキストとして保存します。
この際、各行にヘッダー情報を紐付ける工夫も有効ですが、表自体がシンプルであれば、そのままチャンク化してもLLMは高い確率で構造を理解できます。
データ量が少ない場合は、JSONL形式（各行をJSONオブジェクトとして記述）に変換するのも一つの手です。
キー（列名）と値の関係が明示的になるため、プログラム的な処理もしやすくなります。
コストパフォーマンスと精度のバランスが最も良いのはMarkdown形式ですので、まずはここから始めるのが定石です。
パターン2：セル結合やヘッダーが複雑な表データの場合
日本のビジネス文書でよく見られる、複雑に入り組んだセル結合や、ヘッダーが2段・3段になっている多層ヘッダーの表は、RAGにとっての難関です。
これを単純にテキスト変換すると、結合されていた情報が剥がれ落ち、データの意味が崩壊します。
このパターンの最適解は、HTMLテーブルとして解析・保持するか、画像解析（マルチモーダル）を利用することです。
HTMLの<table>タグであれば、rowspanやcolspanといった属性でセルの結合情報を表現できるため、構造を保ったままテキスト化できます。
LLMはこのHTML構造を読み解く能力も持っています。
もしHTML化が難しい場合、あるいはそれでも解釈を間違える場合は、表の画像をGPT-5やGPT-4o等のビジョンモデルに渡し、「この表の構造を保ったままMarkdown形式に書き起こして」や「JSON形式に変換して」と指示して、構造化テキストを再生成させるプロセスを挟むのが強力です。
コストはかかりますが、人間が手入力する手間を考えれば十分にペイする手法です。
パターン3：図表やグラフが混在している資料の場合
プレゼンテーション資料やホワイトペーパーなどでは、表とグラフ、図解が混在しているケースが多々あります。
グラフ内の数値やトレンドは、通常のテキスト抽出（OCR）ではほとんど取得できません。
この場合、アプローチは**「画像キャプション生成」**一択となります。
図表が含まれるページや領域を画像として切り出し、マルチモーダルLLMに入力します。
そして、「このグラフは何を示していますか？具体的な数値やトレンドを含めて詳細に説明してください」というプロンプトで詳細な解説テキストを生成させます。
RAGのデータベースには、画像そのものではなく、生成されたこの「解説テキスト」を格納します。
これにより、ユーザーが「〇〇のシェア推移はどうなっている？」と質問した際に、グラフの内容を言語化したテキストが検索にヒットし、回答に使われるようになります。
図表の中身を「検索可能なテキスト」に変換してしまう、という発想です。
表データの内容を正確に回答させるプロンプト作成のコツ
データの準備ができたら、最後に重要なのがLLMへの指示出し、つまりプロンプトエンジニアリングです。
表データに基づいた回答を生成させる際、漫然とした指示ではハルシネーションが起きやすくなります。
LLMの思考をガイドし、表を正しく読み取らせるための具体的な指示の出し方を紹介します。
プロンプトエンジニアリングの基本や、そのまま使える日本語のテンプレートについては、こちらの記事で詳しく解説しています。 合わせてご覧ください。
抽出した表形式（Markdown等）であることを明示して解釈させる
LLMに対して、渡されたコンテキストの中に表データが含まれていることを明確に意識させることが第一歩です。
プロンプトの冒頭やシステムプロンプトで、データの形式を宣言します。
例えば、「以下の情報はMarkdown形式の表データを含んでいます。表の各行は1つのレコードを表し、パイプ（|）で区切られています」といった注釈を加えます。
これにより、LLMはこれから処理するテキストが自然言語の文章ではなく、構造化データであることを認識モードとして切り替えることができます。
また、「表のヘッダー行を必ず確認し、各列の意味を理解した上で数値を参照してください」と指示することも有効です。
当たり前のように思えますが、この一言があるだけで、列の参照間違い（一つ隣の列を見てしまうなど）を減らす効果があります。
特定の行や列に注目させて正しい数値を拾わせる指示の出し方
ユーザーの質問に対して、表の中のどこを見るべきかをLLM自身に考えさせるステップ（Chain of Thought）をプロンプトに組み込みます。
具体的には、「回答する前に、まず質問に関連する列名と、条件に合致する行を特定してください」という指示を与えます。
思考プロセスを出力させることで、LLMは「ユーザーは2024年の売上を聞いている→『年度』列が2024の行を探す→『売上』列の値を取得する」という手順を踏むことになり、いきなり答えを出力させるよりも精度が向上します。
また、曖昧な検索を避けるため、「数値が見つからない場合は、推測せずに『データがありません』と答えてください」という制約も重要です。
表データにおいて「だいたいこのくらい」という推測は致命的な誤りになるため、厳格さを求める指示をセットにします。
こちらは表データを段階的に加工して推論するプロンプティング手法について解説した論文です。プロンプト設計の参考として合わせてご覧ください。 https://arxiv.org/abs/2401.04398
回答の根拠となった表データの一部を引用させる出力制御
ハルシネーション対策として最も効果的なのが、回答に使ったデータの一部を引用させることです。
「回答とともに、参照した表の行（Markdown形式）をそのまま出力してください」と指示します。
ユーザーは、回答された数値が正しいかどうかを、同時に表示された引用データを見て即座に確認できます。
また、LLM側にとっても、根拠となるデータを提示しなければならないという制約がかかることで、適当な数値を生成する確率が下がります。
引用形式は、ユーザーが見やすいように整形しても良いですし、デバッグ目的であれば生のMarkdownを表示させるのも良いでしょう。
「根拠の提示」を義務付けることは、RAGシステムの信頼性を担保する上で必須のプロンプトテクニックです。
表データの構造化・抽出に強いおすすめツールとライブラリ
RAG開発において、これらすべての処理をスクラッチ（ゼロから）で実装するのは大変な労力です。
幸い、表データの処理に特化した優秀なツールやライブラリが登場しています。
ここでは、開発現場でよく使われている、信頼性の高い5つのツールを紹介します。
LlamaIndex（構造化データのインデックス作成に特化したライブラリ）
RAG開発フレームワークとして有名なLlamaIndexですが、特に構造化データの扱いに長けています。
「PandasQueryEngine」などの機能を使えば、DataFrame（表データ）に対して自然言語でクエリを投げることが容易に実装できます。
また、ドキュメントの構造を解析し、表とテキストを適切に結びつける機能も豊富です。
再帰的な検索（Recursive Retriever）の仕組みも整っており、表の要約から元データへアクセスするような高度なRAG構築を強力に支援してくれます。
こちらはRAG向けに最適化されたドキュメントパーサー「LlamaParse」などの詳細が記載された公式ドキュメントです。合わせてご覧ください。 https://docs.cloud.llamaindex.ai/
Unstructured.io（PDFや画像から表を綺麗に抜き出すツール）
Unstructured.ioは、PDF、Word、PowerPoint、HTMLなど、あらゆる非構造化データからテキストや表を抽出するためのオープンソースライブラリ（およびSaaS）です。
このツールの強みは、ドキュメント内の要素を「タイトル」「本文」「表」「画像」といったカテゴリに自動で分類して抽出してくれる点です。
表データを検出すると、自動的にHTMLやCSV形式に整形して出力してくれるため、前処理の工数を大幅に削減できます。
多くのRAGプロジェクトで、データ取り込みパイプラインの最初のステップとして採用されています。
こちらは非構造化データの処理ツール「Unstructured.io」の公式サイトです。具体的な機能や導入方法について合わせてご覧ください。 https://unstructured.io/
LangChain（表データの解析に適したパーサー機能の活用）
LLMアプリ開発のデファクトスタンダードであるLangChainも、表データ処理のためのパーサーやローダーを多数備えています。
CSVローダーはもちろん、Excelファイルを読み込むためのローダーや、HTMLテーブルを解析する機能などがあります。
また、LangChainのエージェント機能を使えば、「CSVデータを読み込んで分析し、グラフを描画する」といった高度なタスクも自動化できます。
汎用性が高く、他のツールとの組み合わせも容易なため、まずはLangChainで基本的な処理を試してみるのが良いでしょう。
Allganize（表形式を維持したまま認識する独自技術を持つAIツール）
エンタープライズ向けのAIソリューションを提供するAllganizeは、特に金融機関や保険会社など、複雑な帳票を扱う企業での導入実績が豊富です。
彼らの提供するLLMソリューションは、独自のパーサー技術により、崩れやすい表データを構造的に正しく認識することに特化しています。
自社開発で限界を感じた場合や、高いセキュリティと精度が求められる企業ユースにおいては、こうした特化型ベンダーのツールを採用するのも賢い選択です。
こちらはオールインワンLLMソリューションを提供する「Allganize」の公式サイトです。企業向けの活用事例について合わせてご覧ください。 https://www.allganize.ai/ja/
Azure AI Search / Google Vertex AI（エンタープライズ向け検索基盤）
クラウドベンダーが提供する検索サービスも、表データ対応を急速に強化しています。
Azure AI Searchは、ドキュメント解析機能（Document Intelligence）と連携し、PDF内の表を構造化データとして抽出・インデックス化する機能を備えています。
Google Vertex AI Searchも同様に、エンタープライズデータを丸ごと投げ込むだけで、表や図を含めた高精度な検索が可能です。
インフラ管理の手間を省き、スケーラビリティを確保したい場合は、これらのマネージドサービスを活用するのが近道です。
こちらはMicrosoftの構造化抽出サービス「Azure AI Document Intelligence」の公式ページです。機能の詳細について合わせてご覧ください。 https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/
実装後の確認！表データの回答精度をどう評価すべきか
RAGシステムを構築した後、本当に表データが正しく処理できているかをどうやって検証すればよいでしょうか。
感覚的な評価ではなく、定量的な指標や具体的なチェック方法を用いて精度を管理することが重要です。
最後に、表データRAGの評価ポイントについて解説します。
検索結果に「正しい表」が含まれていたかを測定する指標
まず評価すべきは、回答生成の前段階である「検索精度（Retrieval Accuracy）」です。
質問に対して、回答の根拠となる「正しい表が含まれるチャンク」が上位にヒットしているかを確認します。
これには、「Hit Rate（ヒット率）」や「MRR（Mean Reciprocal Rank）」といった指標を用います。
テスト用の質問セットと、それに対応する正解ドキュメント（表）のIDを用意し、システムが正しくその表を見つけ出せているかを自動テストします。
表データの場合、キーワード検索とベクトル検索の重み付け調整によってこの数値が大きく変動するため、チューニングの際の重要な指標となります。
抽出された数値が元の表と一致しているかを確認する方法
次に、生成された回答の「正確性（Faithfulness）」を確認します。
特に数値データの場合、一桁でも違えば誤りとなります。
これを評価するには、LLMを使って評価を行う「LLM-as-a-Judge」のアプローチが効率的です。
「元の表データ」と「生成された回答」を評価用LLM（GPT-4oなど）に入力し、「回答に含まれる数値は、表データの数値と完全に一致していますか？」と判定させます。
また、単純な文字列一致ではなく、例えば「100万円」と「1,000,000円」を同じ意味として正しく扱えているかなど、意味的な一致もチェックする必要があります。
RAGの回答精度が上がらない時に見直すべきチェックリスト
もし評価結果が思わしくない場合は、以下のポイントを順に見直してみてください。
- データ抽出: PDFから表テキストを抽出した時点で文字化けやレイアウト崩れが起きていないか？
- チャンク戦略: 表が途中で分断されていないか？ヘッダー情報は各チャンクに含まれているか？
- 検索手法: キーワード検索（BM25など）を併用しているか？メタデータは活用できているか？
- プロンプト: 「表形式であることを意識せよ」という指示は入っているか？
- モデル性能: 推論能力の低い軽量モデルを使っていないか？（表計算には高性能モデルが必須）
表データのRAG構築は一筋縄ではいきませんが、適切な前処理とアーキテクチャを選定すれば、必ず実用的なレベルまで精度を高めることができます。
まずは「Markdown変換」と「ハイブリッド検索」の導入から始めてみてください。
RAGの精度を決める「AI視点」のデータ整形術
RAG構築において表データが鬼門となるのは、人間とAIの「見え方」の違いを根本的に理解していないことが大きな原因です。人間は罫線や配置といった視覚情報で表の構造を瞬時に把握しますが、テキストとしてデータを処理するLLMにとって、前処理されていない表データは文脈のない単なる文字や数字の羅列に過ぎません。
記事で紹介されているMarkdown変換や画像認識の活用は、いわばAIに「人間の視覚」を補助する眼鏡を与えるようなアプローチと言えます。重要なのは、単に既存のツールを適用するだけでなく、「どうデータを渡せばこの表の意図がAIに正確に伝わるか？」というAI視点を持って前処理工程を設計することです。
例えば、Microsoftの研究チームによる報告でも、表の構造情報やスキーマを明示的にプロンプトに含めることで、LLMの推論能力が有意に向上することが示唆されています。AIが理解しやすいデータ形式を能動的に提供してあげる「配慮」こそが、結果としてハルシネーションを防ぎ、回答精度を劇的に向上させる鍵となるのです。
引用元：
Microsoft Research Blog, “Improving LLM Understanding of Structured Data: Tables and Beyond”, 2024.
まとめ
本記事で解説したように、RAGを活用して社内ドキュメントを検索可能にするシステム構築は、特に表データの取り扱いにおいて高度な専門知識と複雑なチューニングが必要となります。自社でゼロから開発環境を整え、精度を維持するには、技術的なハードルが高く、多くの時間とリソースを割くことになります。
そこでおすすめしたいのが、Taskhubです。
Taskhubは、難しい技術開発や複雑な設定なしで、すぐに実用的な生成AIを活用できるプラットフォームです。日本初のアプリ型インターフェースを採用しており、日々のメール作成や議事録の要約、そしてデータに基づくレポート生成など、200種類以上の業務タスクがあらかじめパッケージ化されています。
Azure OpenAI Serviceを基盤としているためデータセキュリティも万全で、機密情報が含まれる社内データの扱いにも適しています。さらに、経験豊富なAIコンサルタントによる導入サポートがついているため、「専門知識がない」という企業でも安心してスタートできます。
「RAGの構築は難しそうだが、業務効率化は進めたい」という企業でも、直感的な操作ですぐに導入効果を実感できるのが大きな魅力です。
まずは、Taskhubの具体的な活用事例や機能を詳しくまとめた【サービス概要資料】を無料でダウンロードしてください。Taskhubを導入して、手軽かつスピーディーに社内のDXを一気に加速させましょう。
