Increasing the Accuracy of LLM Question-Answering Systems with Ontologies
| 項目 | 内容 |
|---|---|
| 論文ID | P33 |
| 区分・分類 | 論文・スキーマ・オントロジー |
| 著者・所属 | Dean Allemang（data.world AI Lab）、Juan F. Sequeda（data.world AI Lab） |
| 発表先 | The Semantic Web – ISWC 2024（LNCS, pp.324–339） |
| 発表日 | 2024-11-26 |
| 引用数 | 31（OpenAlex 2026-10-06時点） |
| 言語 | 英語 |
| URL | https://doi.org/10.1007/978-3-031-77847-6_18 |
| あり（arXiv 2405.11706v1。技術報告版「Increasing the LLM Accuracy for Question Answering: Ontologies to the Rescue!」） | |
| 読んだ範囲 | 全文（arXiv版 v1、16ページ）。出版版（ISWC 2024）は有料のため要旨のみ |
論文タイプ
新技術。LLMが生成したSPARQLをオントロジーで検査・修復する手法（OBQC＋LLM Repair）を提案し、ベンチマークで評価しているため。
研究の目標
- 背景：企業のSQLデータベースへの自然言語質問応答では、ナレッジグラフ表現を介す方式（Text-to-SPARQL）の方が直接SQLを生成する方式（Text-to-SQL）より精度が高い。著者らの前研究では GPT-4 ゼロショットで 16.7%→54.2% に上がったが、企業が導入するにはさらに高い精度が要る
- 前研究で観察された誤り：オントロジー上の正しいパス（A→B→C）を飛ばす「誤ったパス」と、プロパティの向きを逆にする「誤った向き」
- 到達点：オントロジーで誤りを決定的に検出し、LLMに修復させて精度を上げる。RQ1「どこまで精度が上がるか」、RQ2「LLM生成SPARQLに多い誤りの種類は何か」
技術的なやり方
Ontology-based Query Check（OBQC）：LLMを使わない決定的な検査。生成SPARQLのWHERE句から Basic Graph Pattern（BGP）を取り出し、変数を予約名前空間 qq: のリソースに置き換えてRDF化する。:query と :ontology の2つの名前付きグラフからなる conjunctive graph を作り、SPARQLで書いたルール（RDFS意味論の一部）で違反を検出し、英文テンプレートで説明文にする。
| 対象 | ルール | 検出内容 |
|---|---|---|
| WHERE句 | Domain / Range | 主語・目的語のクラスがプロパティの rdfs:domain / rdfs:range に合わない |
| WHERE句 | Double Domain / Double Range / Domain Range | 同じ変数を共有する2トリプルのdomain・rangeが両立しない |
| WHERE句 | Incorrect Property | オントロジー（とrdf/rdfs/owl/skos）に無いプロパティを使っている |
| SELECT句 | IRI Output / Subject Output | 人が読めないIRIを返す変数を選んでいる |
LLM Repair：「We have a query {query} with some issues outlined here {issues} Please re-write it.」というプロンプトで、誤ったクエリと説明文だけをLLMに渡す（質問とオントロジーは再送しない）。修復結果を再びOBQCにかけ、最大3回で通らなければ「unknown（I don't know）」としてDBに送らない。
実験：前研究の Chat with the Data benchmark（OMG Property and Casualty Data Model ベースの保険ドメインSQLスキーマ、質問の複雑さ×スキーマの複雑さの4象限、OWLオントロジー＋R2RMLマッピング）。GPT-4 へのゼロショットSPARQLプロンプトで、data.world の仮想化ナレッジグラフ上で実行。指標は Spider の Execution Accuracy。
結果
arXiv版 v1 の数値（Average Overall Execution Accuracy）：
| 区分 | 初回正答 | 修復後正答 | unknown | 正答＋unknown | 誤り率 |
|---|---|---|---|---|---|
| 全質問 | 42.88% | 72.55% | 8% | 80.56% | 19.44% |
| 質問低／スキーマ低 | 51.19% | 76.67% | 12.87% | 89.54% | 10.46% |
| 質問高／スキーマ低 | 69.76% | 75.10% | 6.02% | 81.12% | 18.88% |
| 質問低／スキーマ高 | 17.20% | 76.33% | 3.45% | 79.79% | 20.21% |
| 質問高／スキーマ高 | 28.17% | 60.62% | 8.40% | 69.03% | 30.97% |
- 前研究との比較：SQL直接 16.7%、ナレッジグラフ 54.2%（誤り率45.8%）→ 本手法 72.55%（誤り率19.44%）
- 初回で誤ったもののうち修復できた割合（Achievable Improvement）は全体で 55.57%
- ルールの使用率：Double Domain 37.47%、Domain Range 22.78%、IRI Output 18.40%、Subject Output 11.91%、Domain 4.69%、Incorrect Property 4.26%、Range 0.43%、Double Range 0.06%。WHERE句の検査が70%、SELECT句が30%
- 出版版（ISWC 2024）の要旨では「精度が 21.59% 上がり全体で 65.63%」とあり、arXiv版と数値が異なる（出版版本文は未読）
限界・課題
- SELECT句（IRIの2ルール以外）、サブクエリ、FILTER、UNION、OPTIONAL、NOT は検査対象外で今後の課題
- domain・rangeがIRIでない場合（OWLのunion等）は扱えない。OWLの論理全体をSPARQLで実装するのは一般に不可能
- 明示的なサブクラス関係にないクラスを互いに素とみなしており、OWLの開世界仮定では保証されない
- 修復できたのは約半分で改善余地がある。正しい列の一部しか返さないクエリが残っていると推測し、SELECT句の検査ルール追加やより表現力のあるオントロジーが必要かもしれないと述べている
- 質問高／スキーマ低で改善が最小（5.34%）だった理由は不明
要点
LLMが書いたSPARQLを、オントロジーのdomain・range定義で決定的に検査し、違反の説明文でLLMに直させる。直せないものは「分からない」と返す。 arXiv版では正答率が前研究の54.2%から72.55%、誤り率が19.44%に下がり、検出ではdomain関連のルールが最も多く使われた。