表を見せて質問すると、LLM（Large Language Model、大規模言語モデル）は構造こそ正しく理解していても、肝心の数値を取り違えて答えることがあります。Amazonなどの研究チームが発表した論文「When LLMs Read Tables Carelessly」は、この「データ参照エラー（DRE）」を初めて体系的に測定し、専用の検証モデルで最大12%の精度改善を示しました。ACL 2026（自然言語処理分野で最も権威ある国際会議の一つ）にオーラル採択されています。
背景と文脈
売上表や実験結果の表をLLMに読み込ませ、特定のセルの値を答えさせる場面は、業務でもよくあります。これまでの精度評価は「最終的な答えが合っているか」だけを見ることが多く、モデルが表の構造をどれだけ正しく把握しているかは別問題として扱われてきませんでした。
今回の研究チームは、この2つを切り分けました。表の構造理解自体は保たれているのに、実際にセルを参照する段階で値を取り違えたり、必要な行を読み飛ばしたりするミスがあることを突き止め、これを独立した誤りの種類として定義しています。単なる「知識不足」ではなく「見ているのに読み間違える」現象である点が新しさです。
こうした誤りは、モデルが出す説明文がもっともらしいために発見しづらいという厄介さもあります。表の行数や列名を正しく言い当てられるモデルでも、実際に値を拾う段階でズレが生じるため、開発者が出力をざっと目視するだけでは気づきにくいのです。
技術/ビジネス面
研究チームは17億〜200億パラメータの複数モデルで表読解タスクを評価しました。その結果、データ参照エラーはモデルの規模にかかわらず一貫して発生することが分かりました。パラメータ数を増やすだけでは解決しない、構造的な弱点だといえます。
対策として提案されたのが、答えを出す過程を後から検証する「クリティック（批評者）」の仕組みです。複数の候補回答を生成し、不要な候補をふるいにかける「リジェクションサンプリング」という手法と組み合わせ、データ参照の誤りを検出・除外することで、最終的な正答率を最大12.0%改善しました。
さらに軽量な40億パラメータのクリティックモデルを個別に訓練し、他のモデルが出した答えの誤りを検出させたところ、F1スコア（誤りの見逃しと誤検知のバランスを示す評価指標）で78.2%を記録しています。学習時に見ていないパターンの誤りに対しても一定の検出力を保っており、大きなモデルの補助役として、比較的小さなモデルで運用できる点が実用上のポイントです。
このクリティックモデルは、答えを出したモデル本体とは別に動かす「後段の検査役」として設計されています。本体のモデルを大きくして精度を上げるより、小さな専用モデルを1つ挟むほうが、コストと信頼性のバランスが良いという発想です。これは近年のAI開発で広がりつつある「タスクを分割して専用の小型モデルに任せる」設計思想とも重なります。
これからどうなるか
数値集計や表ベースのレポート生成をLLMに任せている開発者にとって、この研究は無視できない指摘です。最終的な答えの正誤だけをテストして「うまく動いている」と判断していると、たまたま正解にたどり着いただけのケースを見逃す恐れがあります。
実装面では、今回のような軽量なクリティックモデルを社内のRAG(Retrieval-Augmented Generation、検索拡張生成)パイプラインや表計算連携ツールの出力チェック層として組み込むことで、コストを抑えつつ信頼性を底上げできそうです。特に財務データや在庫データなど、数値の取り違えが業務上のミスに直結する用途では、こうした検証層の有無が実運用の可否を分けることになるでしょう。
また、評価用のテストケースを設計する際も「最終回答が合っているか」だけでなく「表のどのセルを根拠にしたか」まで確認する視点が必要になりそうです。単体テストにセル単位の根拠チェックを加えるだけでも、本番投入前に見逃していた誤りを拾える可能性があります。
まとめ
LLMは表の構造を理解していても、値の参照段階で誤りを起こす「データ参照エラー」が規模を問わず存在します。軽量な検証モデルを組み合わせることで、最大12%の精度改善が可能だと示されました。表データを扱うAI活用の設計に一石を投じる研究です。
参考リンク
アイキャッチ画像: Photo by ThisisEngineering on Unsplash
