<<
1-s2.0-S1570826824000441-main.pdf
---
## Page 1
[](/attach/d189179a09d40f61b3d26b37023eb7c67c1afb768923c302994b7090eed869dc_p001.png)
### 和訳
Web Semantics: Science, Services and Agents on the World Wide Web 85 (2025) 100858
ScienceDirectで見れる論文リスト
Web Semantics: Science, Services and Agents on the World Wide Web
ジャーナルのホームページ: www.elsevier.com/locate/websem
ナレッジグラフがLLMを使った企業向け質問応答システムの信頼性の源になるって話
Juan Sequeda ∗, Dean Allemang, Bryon Jacob
data.world AI Lab, テキサス州オースティン, USA
論文の情報
要約
キーワード:
ナレッジグラフ
LLM
大規模言語モデル
生成AI
質問応答
ナレッジエンジニアリング
SPARQL
SQL
OWL
R2RML
1. はじめに
生成AIってな、知識やデータを管理するのにめっちゃ革新的でワクワクする方法なんよ。小さいプロジェクトから企業レベル、さらにはワールドワイドウェブ規模まで、どんなスケールでも使えるねん。「生成AIがあったら、他の知識ベースの技術って全部時代遅れになるんちゃう？」って思いたくなるやん。知識ベースのシステムとか、ナレッジグラフとか、エキスパートシステムでやりたかったこと全部、生成AIでできるんちゃうかって。でもな、わしらの立場はそれとは逆なんや。
実際に企業向けの質問応答システムを生成AIで作ってみた経験からするとな、ナレッジグラフっていろんな面でこのインフラを支えてくれるねん。LLMが生成したクエリが正しいかどうかを評価するための形式的なフレームワークになるし、結果を説明するための基盤にもなるし、ガバナンスが効いた信頼できるデータにアクセスする手段にもなるんや。このポジションペーパーでは、わしらの経験を共有して、業界のニーズを示して、今後の研究でどんな貢献ができるかの機会を概説するで。
質問応答、つまり自然言語で質問してデータとやり取りして正確な結果を得るってやつな、これ50年以上も前からコンピュータサイエンスでずっと課題になってきた難問なんや[1-4]。この分野は過去数十年で進歩してきてな[5-7]、Text-to-SQLっていうアプローチが出てきたんや。SQLデータベースに入ってるデータとチャットできるようにするためのやつやな[8-13]。2023年初頭に生成AIと大規模言語モデル（LLM）が台頭してきて、関心がめちゃくちゃ高まったんや[14]。こういう質問応答システム、つまり構造化されたデータとチャットできるやつな、これが企業内でのセルフサービスとかデータ駆動の意思決定のやり方をガラッと変える可能性を秘めてるんやで。
今日の組織でのセルフサービスとデータ駆動の意思決定って、主にBI（ビジネスインテリジェンス）と分析レポートを通じて行われてるやん。データチームが元のデータを集めて、データを統合して、SQLデータウェアハウス（スタースキーマっていうやつやな）を構築して、BIダッシュボードとレポートを作るわけや。それをビジネスユーザーとかアナリストが使って特定の質問（指標とかKPIとか）に答えて意思決定するんやな。このアプローチのボトルネックは何かっていうと、ビジネスユーザーは既存のダッシュボードの範囲内でしか質問に答えられへんってことなんや。新しい質問が必要になって、それがレポートで答えられへん場合、新しいレポートを作るか既存のレポートを拡張せなあかん。さらにな、データがウェアハウスにあっても、そのデータにアクセスするダッシュボードがなかったら、ビジネスユーザーはそのデータを使われへんのや。結局、データが既にあったとしても、セルフサービスは今あるダッシュボードの範囲内でしかできへんってわけ。最終的に、ビジネスユーザーとか経営幹部が欲しいのは、自分らのビジネスを理解してて、いつでも質問できて、信頼できる答えをくれるエキスパートなんやで。
大規模言語モデル（LLM）は、チャットベースの体験を動かすための主要なツールになってきてるな。自然言語の入力に基づいて会話的な応答を返してくれるんや。でもな、このアプローチには明らかな限界があるねん、特に信頼性があって説明可能な回答を提供するのが目的の場合はな。
最初のシナリオとして、ユーザーがチャットインターフェースを通じて質問するやん。そしたらLLMに問い合わせが行くわけや。そのLLMは企業データで学習されたりファインチューニングされたりしてるかもしれんし、RAGアプローチでベクトル化されたストアにアクセスして直接的な応答を生成するかもしれん。この構成には以下の問題があるんや：
• ハルシネーション（幻覚）の可能性：LLMが情報を捏造してまう可能性があるんや。もっともらしく聞こえるけど、事実としては間違ってる応答を返してまうことがあるねん。
• 検証手段がない：その答えが正しいかどうか、あるいはモデルがその質問に正確に答えるのに必要な知識を持ってるかどうかを確認する仕組みがないんや。
• 出所が不透明：ユーザーは、その答えがどこから来たのか、なぜ信頼すべきなのかがわからへん。せやから、その応答を説明したり検証したりすることができへんのや。
∗ 責任著者
メールアドレス：
juan@data.world (J. Sequeda), dean.allemang@data.world (D. Allemang), bryon@data.world (B. Jacob).
https://doi.org/10.1016/j.websem.2024.100858
2024年11月25日受領; 2024年12月20日改訂版受領; 2024年12月23日受理
2025年1月15日オンライン公開
1570-8268/© 2025 著者ら。Elsevier B.V.より出版。これはCC BY-NC-NDライセンス（http://creativecommons.org/licenses/by-nc-nd/4.0/）の下でのオープンアクセス論文です。
---
## Page 2
[](/attach/d189179a09d40f61b3d26b37023eb7c67c1afb768923c302994b7090eed869dc_p002.png)
### 和訳
J. Sequeda ら
Journal of Web Semantics 85 (2025) 100858
2つ目のシナリオやねんけど、LLMがユーザーの質問を構造化されたクエリに変換して、それをちゃんと管理されたデータベースかナレッジグラフに対して実行するっていう仕組みやねん。このやり方やと、いくつかええことがあるで：
• 読めて検証できるクエリ：よう分からん中身が見えへん回答と違って、生成されたクエリは見直せるし、合ってるかどうかチェックできるし、スキーマやオントロジーと照らし合わせられるねん。
• 説明できる可能性：生成されたクエリを見れば、どういう関係性を扱おうとしてるか透明にわかるから、LLMがどう質問を解釈して、なんでその答えが正しいんかを説明できるようになるねん。
• 管理されたデータソース：回答がちゃんとキュレーションされたデータから来てるから、正確さを評価できるし、データソースを直接参照できるんや。
**ポジションステートメント**。うちらの立場はこうや：生成AIが出てきた後でも、ナレッジグラフは依然として有用で重要やねん。なんでかっていうと、**信頼の源**やからや。うちらが言う「信頼」は3つの側面に基づいてるで：(1) LLMはハルシネーション（でっち上げ）するから、回答の正確さを担保せなあかん、(2) LLMはブラックボックスな性質があるから、答えがどっから来てるか説明できるようにせなあかん、(3) 間違った情報が使われるリスクがあるから、ガバナンス（管理統制）を確保せなあかん。ナレッジグラフは正確さ、説明、ガバナンスを提供するねん。もっと言うたら、生成AIがある時代やからこそ、知識ベースのシステムは今まで以上に重要やって言いたいわ。
以下では、まずうちらの立場を裏付ける研究を要約するで。最初は正確さに焦点当てるわ。その後、学んだ教訓を共有して、最後に今後の研究の考察で締めるで。
## 2. SQLデータベース上のLLM駆動質問応答の正確さを上げるためのナレッジグラフ
ナレッジグラフ（KG）は、ビジネスコンテキストのギャップを埋めてハルシネーションを減らすための有望な解決策として注目されてて、それによってLLMの正確さが向上するって言われてるねん[15]。業界の視点から言うと、Gartnerが2023年7月にこう言うてるで：「ナレッジグラフは、高い正確さと正当性の閾値を達成せなあかんLLMベースのソリューションに対して、完璧な補完を提供する」って。1
うちらの仮説は、ナレッジグラフがSQLデータベース上のLLM駆動質問応答システムで重要な役割を果たすっていうことやねん。ただ、2023年7月にこの研究を始めた時点では、どの程度なんかはっきりせえへんかったんや。うちらの出発点は、ハルシネーションが業界で最大の懸念の一つになったことを踏まえて、正確さにおけるナレッジグラフの役割を理解することやったんや。
うちらの最初の貢献は、保険ドメインのデータと知識を使ったベンチマークと、実験結果やねん。この実験で分かったんは、企業のSQLデータベースをナレッジグラフで表現したものに対して、ゼロショットプロンプトを使ったGPT-4駆動の質問応答システムが企業の自然言語の質問に答えると、SQLデータベーススキーマだけを使った場合と比べて**3倍正確な結果**が返ってくるっていう証拠やで[16]。
その後の研究では、LLMが生成したSPARQLクエリの意味的エラーをオントロジーを使って特定して、その後LLMでクエリを修復するっていうアプローチを取ったら、ナレッジグラフを全く使わへん場合と比べて合計で**4倍の正確さ改善**になったっていうことを実証したで[17,18]。図1がうちらのアプローチの概要を示してるわ。
この研究成果は製品化されて、data.worldのAI Context Engine2（AICE）製品の一部になってるねん。これはエージェントベースでAPI駆動のシステムで、お客さんのデータとメタデータを生成AIと接続して、構造化データとメタデータに対する信頼できる会話を実現するもんや。
**図1. うちらのアプローチの概要**
ナレッジグラフという形で、データの明確に定義された構造化された理解を作ることは、データ管理全体を強化して、異なるアプリケーションやレポート間で一貫した解釈を可能にするだけやなくて、企業におけるLLMの正確さを改善するための基盤にもなるねん。うちらの研究は、この新しいAI時代にセマンティクスとナレッジグラフに投資する必要性を、より広いデータ業界に認めさせる影響を与えたで。ベンチマークと結果は、まずdbt Labsによって独自に再現・検証されたんや。3 いくつかのセマンティックレイヤーベンダーがさらにうちらの結果を検証してくれてるで。4,5,6,7,8,9 Neo4jによるGraphRAGマニフェストでは、ベクトルのみのRAGと比べてGraphRAGの利点の一つがより正確な回答やって主張してて、うちらのベンチマークと結果を引用してくれてるわ。10
## 3. 学んだ教訓
### 3.1. 知識工学が正確さの鍵やねん
分かってきたんは、知識工学って実務ではあんまり強調されへんけど、組織内のいろんな役割の潜在的な部分を形成してるっていうことやねん。経験的に言うと、この作業はしばしば散発的で体系的やないから、一貫したデータ理解を妨げてしまってるんや。知識工学の作業はいろんな役割（データエンジニア、データスチュワード、アナリティクスエンジニア、データアナリスト）の間で行われてて、それぞれが自分の前提を押し付けるから、不整合につながることがあるねん。
例えばな、「ポリシー」の定義が部門によって違うことがあるねん。期限切れステータスのポリシーはまだポリシーと見なされるんか？それともアクティブなステータスのものだけがポリシーなんか？さらに言うと、「policy」っていうテーブルが存在するかもしれへんけど、それは全ての行が
---
3 https://roundup.getdbt.com/p/semantic-layer-as-the-data-interface
4 https://www.atscale.com/blog/semantic-layers-make-genai-more-accurate/
5 https://www.wisecube.ai/blog/optimizing-llm-precision-with-knowledge-graph-based-natural-language-qa-systems/
6 https://blog.kuzudb.com/post/llms-graphs-part-1/
7 https://delphihq.substack.com/p/delphi-at-100-dbt-semantic-layer
8 https://cube.dev/blog/semantic-layers-the-missing-piece-for-ai-enabled-analytics
1 「Adopt a Data Semantics Approach to Drive Business Value」、Gartner Report by Guido De Simoni, Robert Thanaraj, Henry Cook, July 28, 2023.
2 https://data.world/ai/
9 https://www.stratio.com/blog/stratio-business-semantic-data-layer-delivers-99-answer-accuracy-for-llms/
10 https://neo4j.com/blog/graphrag-manifesto/
2
---
## Page 3
[](/attach/d189179a09d40f61b3d26b37023eb7c67c1afb768923c302994b7090eed869dc_p003.png)
### 和訳
おう、聞いてや！
このテーブルはな、保険のポリシー（契約）を表してんねん。ポリシーテーブルにはステータス列があって、いろんなコードが入っとるわけや。ほんで「どのコードがアクティブな状態を表すん？」って話になるやろ？開発者がな、全部の答えを知ってるわけちゃうから、結局自分の思い込みで意味を決めてコード書いてまうねん。
ここで大事なことに気づくわけや：**ナレッジエンジニアリング**っちゅう作業、つまりデータが本当は何を意味してるんか突き止める作業、これめっちゃ重要やねん。ほんまは組織の標準的なやり方にせなあかんのよ。
ほんで、もう一個学んだことがあんねんけど、これちょっと議論になりそうな話やで：**オントロジー（データの構造定義みたいなもんや）は、LLM（大規模言語モデル、ChatGPTみたいなやつな）がうまく動くように設計せなあかん**ってことや。「正しい」オントロジーでも、LLMが混乱して間違ったSPARQLクエリ（データベースに質問する言語やな）を作ってまうことがあんねん。
例えばな、「お客さんが住所を持ってて、その住所に市区町村がある」ってモデル化するとするやん。最初のやり方はこうや：
:Customer a owl:Class.
:Address a owl:Class.
:hasAddress a owl:ObjectProperty;
rdfs:domain :Customer;
rdfs:range :Address.
:city a owl:DatatypeProperty;
rdfs:domain :Address.
二つ目のやり方はこうや：
:Customer a owl:Class.
:city a owl:DatatypeProperty;
rdfs:domain :Customer.
「オースティン市の全部のお客さん返して」って質問されたとするやん。最初のやり方やと、LLMはこんなSPARQLクエリを作らなあかん：
SELECT *
WHERE {
?c a :Customer;
:hasAddress ?a.
?a a :Address;
:city "Austin".
}
二つ目のやり方やったらこうなる：
SELECT *
WHERE {
?c a :Customer;
:city "Austin".
}
どのモデリング方法やったらLLMが正確なクエリ作れるか、これを理解するんが大事やねん。最初のやり方はベストプラクティスに従ってるけどな、もし二つ目のオントロジーでLLMが一貫して正しいクエリ作れるんやったらどうする？せやから、**精度を上げるために、LLMの反応に合わせてオントロジーを調整する**っちゅうアプローチもあんねん。これはめっちゃテストして（下で説明するで）、LLMの出力見ながらオントロジーを改良して学んだことやねん。
## 3.2. 説明可能性
うちのシステムはエージェントベースやから、答えを出すまでに複数のステップ踏むねん。経験上、そのプロセスの各ステップ、自動修正も含めて見せると、**ユーザーの信頼が上がる**んや。この透明性のおかげで、ユーザーは答えがどうやって導き出されたか理解できるっちゅうわけ。図2にうちのシステムの思考プロセスの例を載せてるで。
さらに説明可能性を高めるためにな、生成されたSPARQLクエリ、参照されたオントロジーとマッピングの部分、適用された具体的なビジネス用語、ほんで結果として生成されたSQLクエリ、これ全部ユーザーに見せとんねん。これらの要素が全部、信頼構築に貢献してるわけや。このレベルの説明可能性があると、技術系のユーザーはプロセスの各部分を検証できて、最終的な答えへの信頼が高まんねん。
図2. 思考プロセスの例
## 3.3. ガバナンス
ガバナンスっちゅうのはな、システムで使われてる用語が組織のビジネス用語集と合ってるかどうか確認することや。この用語集はデータスチュワード（データ管理の責任者みたいな人）が管理してんねん。これらの用語と定義は処理中に追加のコンテキストとして渡されるんや。ガバナンスは特定の指標を定義したり、一貫性を保ったり、クエリで使う用語が承認されたビジネス定義と合ってるか確認するのにもめっちゃ大事やねん。経験上、ユーザーは特定の概念や指標の定義について詳しく調べるためにビジネス用語集の用語を辿ってくれてるわ。
例えばな、**ロス・レシオ（損害率）**っちゅう指標は「経費支払いと損害支払いの合計をプレミアム（保険料）で割ったもの」って定義されてんねん。この定義はビジネス用語集にあって、データスチュワードが管理してるわけや。せやから、ロス・レシオについての質問が来たら、管理されたビジネス用語集の内容を追加のコンテキストとしてLLMに渡せんねん。
## 3.4. 「海を沸かす」のを避ける
学んだ重要な教訓の一つはな、**一度にたくさんの質問に取り組もうとせんこと**や。これ「海を沸かす」って言われる状況やな（要は無謀なことすんなってこと）。代わりに「**ペイ・アズ・ユー・ゴー**」方式、つまり小さく始めて徐々に積み上げていくやり方を採用してんねん[19]。このアプローチはな、まず小さなビジネス質問のセットを特定して、それらの質問をモデル化するためのオントロジーとマッピングを構築すんねん。学んだ教訓は、**これは新しい技術やから、ステークホルダーは結果を早く見たがってる**っちゅうことや。せやから毎週結果を見せて、繰り返し改善していかなあかんねん。
これらの質問は技術的やなくてビジネス志向やないとあかんし、明確なコンテキストが必要や：誰が質問してる？なんで質問してる？正しい質問を選ぶために、[16]の4象限フレームワークを使ってんねん。これは質問をスキーマと質問の複雑さで分類するやつや。
質問は低複雑度か高複雑度に分類されるで：
・**低い質問複雑度**：ビジネスレポートのユースケースに関するもので、日々のビジネス運営を円滑にすることが目的や。
・**高い質問複雑度**：組織内のメトリクスやKPI（重要業績評価指標）の文脈で生じるもんや。これらの質問は組織の成功に不可欠な戦略的意思決定を行うために出されんねん。
質問はまた、答えを出すのに必要なテーブルの数にも依存するで：
・**低いスキーマ複雑度**：テーブル数が少ない（0〜4個）、非正規化されたスキーマ
・**高いスキーマ複雑度**：テーブル数が多い（5個以上）、正規化されたスキーマ、多対多の結合テーブルとかがあるやつ
この二つのアプローチを組み合わせると、質問を分類する4象限ができるんや：(1) 低質問/低スキーマ複雑度、(2) 高質問/低スキーマ複雑度、(3) 低質問/高スキーマ複雑度、(4) 高質問/高スキーマ複雑度。これで
---
## Page 4
[](/attach/d189179a09d40f61b3d26b37023eb7c67c1afb768923c302994b7090eed869dc_p004.png)
### 和訳
J. Sequeda et al.
Journal of Web Semantics 85 (2025) 100858
この象限図使うと、どの質問から先に取り組むか戦略的に選べるようになるねん。
3.5. テストケースがめっちゃ大事やねん
最後に強調しときたいんやけど、包括的なテストケースを作ることがほんまに大事やねん。これは質問と回答のペアをテストする仕組みを作って、システムの応答がちゃんと合ってるか検証することやな。ペアは(1)自然言語での質問と、(2)正確な答えを出すSPARQL/SQLクエリで構成されてるねん。この作業やってると、質問に曖昧なとこが出てきて、答えが複数パターンあり得ることがよくあるんよ。
例えばな、「先月一番パフォーマンス良かったエージェントは誰？」って質問考えてみ？「一番パフォーマンス良い」ってどういう意味やねん？契約数が一番多いエージェント？それとも保険料の合計が一番高いエージェント？さらに「先月」って何やねん？直近のカレンダー月のこと？それとも今日から過去30日間のこと？こういう曖昧さを見つけて対処するのが、システムを磨き上げる上でめっちゃ重要なポイントやねん。さらにテストケースは、オントロジーやマッピングを拡張しても精度が落ちへんように確認するための土台にもなるねん。オントロジーを修正したり追加したりするたびに、このテストケースを継続的に実行して、システムの機能がちゃんと維持されてて、変更が前の実装を壊してへんか確認するわけや（いわゆるリグレッションテストやな）。
4. 業界のニーズと今後の研究貢献
研究が貢献できる業界ニーズの主要な分野をいくつか挙げとくわ：
4.1. ナレッジエンジニアリングをもっとシンプルに
ナレッジグラフを作るには、ターゲットとなるオントロジーを定義して、ソースのリレーショナルデータベースからターゲットオントロジーへのマッピングを作らなあかんねんけど、これがまだまだ複雑な社会的プロセスやねん。ナレッジエンジニアリングはもっとシンプルにせなあかんわけで、より効果的なツールと方法論が求められてるってことやな。
ツールの観点からやと、表形式データで似たような課題をうまく乗り越えてきたETL（Extract、Transform、Load）ツールみたいな確立された手法から学べることがあると思うねん。例えばオープンソースのData build tool（dbt）11は、SQLアナリストがデータを素早く変換（つまりマッピング）できるようにして、変換コードにソフトウェアエンジニアリングの手法を適用してるねん：gitワークフローとバージョン管理、モジュール化、テスト、CI/CD（継続的インテグレーション/継続的デプロイメント）とかな。
方法論の観点からやと、従来のオントロジーエンジニアリング手法にはデータマッピングのタスクが含まれてへんことに気づくねん[20-22]。うちらの立場としては、オントロジーエンジニアリングの手法は既存のデータソースへのマッピングも考慮するように拡張せなあかんと思うねん[19,23-25]。
最後に、LLM（大規模言語モデル）は、技術者にも非技術者にも使いやすいコパイロット的なアプローチでナレッジエンジニアリングのプロセスを効率化できる有望な新しい仕組みやねん[26-28]。これはすぐに研究の重点分野になりつつあるで。12 例えば、(1)ドメインエキスパートにインタビューする際に会話を要約してオントロジーの初稿を生成することでナレッジ獲得の手間を減らす、(2)マッピングとして実装できそうなSQLやアプリケーションコードをリバースエンジニアリングする、とかな。
オントロジーエンジニアリング、データマッピング、LLMの相互作用が、うちらの成功を形作る上でめっちゃ重要になると信じてるねん。
4.2. ユーザー中心の説明可能性
説明可能なAIは学術界で重要な研究テーマやねん[29,30]。ナレッジグラフは説明可能性を提供する手段として研究されてるねん[31-34]。
11 https://docs.getdbt.com/
12 https://kastle-lab.github.io/llms-and-kg-engineering/index
うちらの立場としては、「誰に対して説明可能なんか？」にも焦点を当てなあかんと思うねん。ユーザーが説明可能性に関して具体的に何を求めてるかをもっとよく理解することが研究の機会やな。説明可能性を提供する方法はいろいろあるけど、それを異なるユーザーグループの要件と期待に合わせてカスタマイズすることがめっちゃ重要やねん。ユーザー中心の説明可能性アプローチっていうのは、ビジネスアナリストから技術エキスパートまで、いろんなユーザーがどのレベルの詳細度やどんなタイプの説明を必要としてるかを理解することやな。例えば、損害率について質問する非技術系ユーザーは、その指標がどう定義されてるか理解するためにビジネス用語集を見たいかもしれへん。技術系ユーザーはマッピングコードを見たいかもしれへん。
こういう説明があると信頼を築けて、LLMを活用した質問応答システムをより幅広い人にとってアクセスしやすく理解しやすいものにできるねん。
4.3. 非決定的システムをテストする新しいアプローチ
うちらは非決定的システム（つまりLLM）と一緒に仕事する時代に入ってるねん。従来のテストアプローチはシステムが決定的やと仮定してて、同じ入力に対して毎回同じ出力が出ることを前提にしてるねん。こういう非決定的システムをテストするための新しいフレームワークやアプローチを探求せなあかんねん。例えば、自然言語の質問を入力として与えると、LLMを活用したシステムは実行するたびに異なるクエリを生成するかもしれへん。結果として出てくるクエリは、正しいかもしれへんし（期待通りの結果が返ってくる）、間違ってるかもしれへんし（結果がおかしい）、部分的に正しいかもしれへん（結果が期待される結果の一部だけ）。やから、これらのテストは結果のばらつきを追跡せなあかんねん。
堅牢なテスト戦略を開発することが、一貫性と信頼性を確保して、脆さを減らすために不可欠やで。
4.4. 小さいセマンティクス vs 大きいセマンティクス
セマンティクス（意味論）という概念は、特にビジネスインテリジェンスや分析ツールにおける「セマンティックレイヤー」の文脈で、業界でますます言及されるようになってるねん。セマンティックレイヤーのアイデアは新しいもんちゃうで；Business Objects13やLookerのLookML14みたいな以前のツールにさかのぼるもんで、分析を容易にするために各カラムが何を意味するかの定義を提供することを目指してたねん。
現在、多くの企業やツールは「控えめなセマンティクス」と呼べるものを採用してて、主にデータウェアハウスのファクトテーブルやディメンションテーブルから来る指標とディメンションのモデリングが必要な分析ユースケースに焦点を当ててるねん。セマンティックレイヤーの例としては、Snowflake、15 dbt、16 Cube、17 AtScale18とかがあるな。
こういうシナリオでは、軽量なセマンティクスで十分かもしれへんし、より表現力豊かなオントロジーやナレッジグラフのアプローチを採用する必要がないかもしれへん。でもな、ユースケースの複雑さが増すにつれて、これらの軽量なセマンティクスアプローチの限界が明らかになってくるねん。より表現力のあるセマンティクスや高度なナレッジマネジメントのニーズへのサポートが不足してることが多いねん。
うちらは、ファクト/ディメンション向けに現在使われてるシンプルなセマンティクスと、より高度なセマンティクスアプローチが必要になるポイントとの間のギャップを理解することに未来があると信じてるねん。
これには、基本的なセマンティックレイヤーからナレッジグラフやオントロジーのようなより包括的なセマンティクスソリューションへいつ移行すべきかを慎重に評価する必要があるねん。研究やツールの観点からは、既存の「軽量」セマンティクスツールの能力と限界を調査して、それらがいつ十分で、いつ不足するかをより良く理解することを意味してるねん。
13 https://patents.google.com/patent/US5555403
14 https://cloud.google.com/looker/docs/what-is-lookml
15 https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst/semantic-model-spec
16 https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl
17 https://github.com/cube-js/cube
18 https://github.com/semanticdatalayer/SML
4
---
## Page 5
[](/attach/d189179a09d40f61b3d26b37023eb7c67c1afb768923c302994b7090eed869dc_p005.png)
### 和訳
4.5. マルチエージェントベースの質問応答システムと問題の分解
データの利用可能性について
なぁ、質問に答えてくれるエージェントシステムを作るときな、めっちゃ大事なんが「どうやって問題を小さく分けるか」っていう話やねん。1つのエージェントに「質問に答える」のと「曖昧さを処理する」の両方やらせるんか、それとも別々のエージェントに分けるんか、ここがポイントやな。
例えばな、1つのエージェントは曖昧さ専門で、「ちょっと何言ってるかわからへん質問」とか「いろんな解釈ができそうな質問」を受け取るねん。前に出した「先月一番成績良かったエージェントって誰？」っていう質問あったやろ？これをユーザーとやり取りしながら「今日から過去30日間で一番保険を売ったエージェントは誰？」っていう具体的な質問に変換するわけや。ほんで別のエージェントは、もう曖昧さがない、はっきりした質問だけに答える専門っていう感じやな。
こういうエージェントたちがユーザーと対話しながら、質問をもっと具体的で扱いやすい形に磨き上げていくわけや。
最近のトレンド見てたらな、モジュール式のエージェントシステムに向かってるのがわかるねん。それぞれのエージェントが特定のタスクに特化することで、システム全体の精度とユーザーとのやり取りの質が上がる可能性があるわけや。でもな、そのぶんシステムが複雑になるし、もっとしっかりテストせなあかんようになるねん。例えば「曖昧な入力を明確な質問に変換するエージェント」のテストケースってどうやって定義すんねん？って話やな。
5. 最後のまとめ
質問応答システムを信頼できるかどうかっていうんは、いろんな要素の組み合わせで決まるねん。最終的な答えを出すエージェントは「説明責任を果たせるやつ」やないとあかんのよ。LLM単体じゃその資格ないねん。でもデータベースやナレッジベースは、ちゃんと管理されてて説明責任を果たせるリソースやから大丈夫や。ナレッジグラフをデータソースとして使うときは、オントロジー（知識の構造を定義したやつな）を使ってクエリが正しいか形式的に検証できるし、間違ったクエリを見つけて修正するのにも役立つねん。結果として精度が上がるし、なんでその答えになったか説明できるし、ガバナンス（管理体制）もしっかりするわけや。
ナレッジグラフがデータカタログの役割も果たしてる場合な、オントロジーの中のクラスとかプロパティが、カタログに登録されたデータリソースと紐づいてるねん。ほんでそれらはデータガバナンスのワークフローの一部になってて、カタログはデータの品質（ちゃんと時間通りに更新されたか、とか）、出どころ（どこから来た情報か、他のデータソースのビューから作られたもんか、とか）、データの管理者（誰がこのデータの責任持つんか）を追跡してるねん。こういう要素――管理されたデータソース、形式的な検証、標準化されたドキュメント、データガバナンス――を統合することで、ナレッジグラフはLLMを使った企業向け質問応答システムの信頼性の土台をめっちゃしっかり提供してくれるわけや。
CRediT 著者貢献表明
Juan Sequeda：査読と編集、原稿執筆、方法論、調査、コンセプト設計。Dean Allemang：原稿執筆、方法論、調査、コンセプト設計。Bryon Jacob：リソース提供、調査、コンセプト設計。
利益相反の宣言
著者らは以下の経済的利益／個人的関係を申告するで。これらは潜在的な利益相反とみなされる可能性があるねん。Juan Sequedaはdata.worldから管理サポートを受けてて、data.worldと雇用関係にあるって報告してるわ。他の著者については、この論文に報告された研究に影響を与えた可能性のある、知られている経済的利益や個人的関係はないって宣言してるで。
データの利用可能性
この論文で説明した研究には、データは使用されてへんで。
参考文献
[1] B.F. Green, A.K. Wolf, C. Chomsky, K. Laughery, Baseball: 自動質問応答システム, 1961年5月9-11日開催のWestern Joint IRE-AIEE-ACM Computer Conferenceの論文集, IRE-AIEE-ACM '61 (Western), Association for Computing Machinery, New York, NY, USA, 1961, pp. 219–224, http://dx.doi.org/10.1145/1460690.1460714.
[2] C.C. Green, B. Raphael, 質問応答システムにおける定理証明技術の使用, 1968年第23回ACM全国会議議事録, ACM '68, Association for Computing Machinery, New York, NY, USA, 1968, pp. 169–181, http://dx.doi.org/10.1145/800186.810578.
[3] W.A. Woods, 自然言語解析のための遷移ネットワーク文法, Commun. ACM 13 (10) (1970) 591–606, http://dx.doi.org/10.1145/355598.362773.
[4] G.G. Hendrix, E.D. Sacerdoti, D. Sagalowicz, J. Slocum, 複雑なデータへの自然言語インターフェースの開発, ACM Trans. Database Syst. 3 (2) (1978) 105–147, http://dx.doi.org/10.1145/320251.320253.
[5] D.A. Dahl, M. Bates, M. Brown, W. Fisher, K. Hunicke-Smith, D. Pallett, C. Pao, A. Rudnicky, E. Shriber, ATISタスクの範囲拡大：ATIS-3コーパス, Proc. Work. Hum. Lang. Technol. (1994) 43–48, URL: http://dl.acm.org/citation.cfm?id=1075823.
[6] J.M. Zelle, R.J. Mooney, 帰納論理プログラミングを用いたデータベースクエリのパース学習, 第13回人工知能全国会議議事録 - Vol. 2, 1996, pp. 1050–1055, URL: http://dl.acm.org/citation.cfm?id=1864519.1864543.
[7] L.R. Tang, R.J. Mooney, データベースインターフェースの自動構築：意味解析のための統計学習と関係学習の統合, 2000 Joint SIGDAT Conference on Empirical Methods in Natural Language Processing and Very Large Corpora, 2000, pp. 133–141, URL: http://www.aclweb.org/anthology/W00-1317.
[8] N. Yaghmazadeh, Y. Wang, I. Dillig, T. Dillig, SQLizer: 自然言語からのクエリ合成, International Conference on Object-Oriented Programming, Systems, Languages, and Applications, ACM, 2017, pp. 63:1–63:26, http://dx.doi.org/10.1145/3133887.
[9] F. Li, H.V. Jagadish, リレーショナルデータベース用のインタラクティブな自然言語インターフェースの構築, Proc. VLDB Endow. 8 (1) (2014) 73–84, http://dx.doi.org/10.14778/2735461.2735468.
[10] S. Iyer, I. Konstas, A. Cheung, J. Krishnamurthy, L. Zettlemoyer, ユーザーフィードバックからのニューラル意味パーサーの学習, Proceedings of the 55th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), 2017, pp. 963–973, URL: http://www.aclweb.org/anthology/P17-1089.
[11] A.-M. Popescu, O. Etzioni, H. Kautz, データベースへの自然言語インターフェースの理論に向けて, Proceedings of the 8th International Conference on Intelligent User Interfaces, 2003, pp. 149–157, URL: http://doi.acm.org/10.1145/604045.604070.
[12] A. Giordani, A. Moschitti, 自然言語質問に対するSQL由来の回答の自動生成と再ランキング, Proceedings of the Second International Conference on Trustworthy Eternal Systems Via Evolving Software, Data and Knowledge, 2012, pp. 59–76, http://dx.doi.org/10.1007/978-3-642-45260-4_5.
[13] V. Zhong, C. Xiong, R. Socher, Seq2SQL: 強化学習を用いた自然言語からの構造化クエリ生成, 2017, CoRR abs/1709.00103.
[14] J. Li, B. Hui, G. Qu, J. Yang, B. Li, B. Li, B. Wang, B. Qin, R. Geng, N. Huo, et al., LLMはすでにデータベースインターフェースとして機能できるか？大規模データベースに基づくtext-to-SQLのビッグベンチ, Adv. Neural Inf. Process. Syst. 36 (2024).
[15] S. Pan, L. Luo, Y. Wang, C. Chen, J. Wang, X. Wu, 大規模言語モデルとナレッジグラフの統合：ロードマップ, IEEE Trans. Knowl. Data Eng. (2024).
[16] J. Sequeda, D. Allemang, B. Jacob, 企業SQLデータベースに対する質問応答における大規模言語モデルの精度に対するナレッジグラフの役割を理解するためのベンチマーク, O. Hartig, Z. Kaoudi (Eds.), Proceedings of the 7th Joint Workshop on Graph Data Management Experiences & Systems (GRADES) and Network Data Analytics, NDA, Santiago, Chile, 14 June 2024, ACM, 2024, pp. 5:1–5:12, http://dx.doi.org/10.1145/3661304.3661901, URL: https://arxiv.org/abs/2311.07509.
[17] D
[...テキスト省略...]
---
## Page 6
[](/attach/d189179a09d40f61b3d26b37023eb7c67c1afb768923c302994b7090eed869dc_p006.png)
### 和訳
J. Sequeda et al.
Journal of Web Semantics 85 (2025) 100858
[26] B.P. Allen, L. Stork, P. Grothの研究やねんけど、「大規模言語モデル使った知識工学」っていうテーマで書いてはるねん。Trans. Graph Data Knowl. 1巻1号（2023年）の3:1から3:19ページに載ってるで。DOIはhttp://dx.doi.org/10.4230/TGDK.1.1.3 で、URLはhttps://drops.dagstuhl.de/entities/document/10.4230/TGDK.1.1.3 やな。
[27] L. Meyer, C. Stadler, J. Frey, N. Radtke, K. Junghanns, R. Meissner, G. Dziwis, K. Bulert, M. Martinの論文は「LLMを使ったナレッジグラフ工学：ChatGPTでの実験」っちゅうタイトルやねん。C. Zinke-WehlmannとJ. Friedrichが編集した、2023年6月29日から30日にドイツのライプツィヒで開催された「持続可能な明日のためのAI開発に関する第1回ワーキングカンファレンス（AI Tomorrow 2023）」の会議録に収録されてるで。Informatik AktuellシリーズでSpringerから出版、103から115ページやな。DOIはhttp://dx.doi.org/10.1007/978-3-658-43705-3_8 やで。
[28] P. MateiuとA. Grozaの「大規模言語モデルを使ったオントロジー工学」は、2023年9月11日から14日にフランスのナンシーで開催された「科学計算のための記号・数値アルゴリズムに関する第25回国際シンポジウム（SYNASC 2023）」で発表されてん。IEEEから出版されて、226から229ページやで。DOIはhttp://dx.doi.org/10.1109/SYNASC61333.2023.00038 やな。
[29] A.B. Arrieta, N. Díaz-Rodríguez, J. Del Ser, A. Bennetot, S. Tabik, A. Barbado, S. García, S. Gil-López, D. Molina, R. Benjaminsらの「説明可能なAI（XAI）：責任あるAIに向けた概念・分類体系・機会・課題」っちゅう論文やねん。Inf. Fusion 58巻（2020年）の82から115ページに載ってるで。めっちゃ重要な論文やな。
[30] A. AdadiとM. Berradaの「ブラックボックスの中を覗く：説明可能なAI（XAI）のサーベイ」は、IEEE Access 6巻（2018年）の52138から52160ページやで。
[31] I. Tiddi, F. Lécué, P. Hitzlerの「説明可能なAIのためのナレッジグラフ：基礎・応用・課題」は、IOS Pressから2020年に出版された本やねん。
[32] F. Lecueの「説明可能なAIにおけるナレッジグラフの役割」は、Semant. Web 11巻1号（2020年）の41から51ページやで。
[33] I. TiddiとS. Schlobachの「説明可能な機械学習のためのツールとしてのナレッジグラフ：サーベイ」は、Artificial Intelligence 302巻（2022年）の103627やな。
[34] E. RajabiとK. Etminaniの「ナレッジグラフベースの説明可能なAI：システマティックレビュー」は、J. Inf. Sci. 50巻4号（2024年）の1019から1029ページやで。
[19] J.F. Sequeda, W.J. Briggs, D.P. Miranker, W.P. Heidemanの「リレーショナルデータベースから企業向けナレッジグラフを設計・構築するためのペイ・アズ・ユー・ゴー方法論」やねん。なんでかっていうと、C. Ghidini, O. Hartig, M. Maleshkova, V. Svátek, I.F. Cruz, A. Hogan, J. Song, M. Lefrançois, F. Gandonが編集した「セマンティックウェブ - ISWC 2019 - 第18回国際セマンティックウェブ会議」の会議録に収録されてるねん。2019年10月26日から30日にニュージーランドのオークランドで開催されたやつや。Lecture Notes in Computer Scienceシリーズの11779巻でSpringerから出版、526から545ページやで。DOIはhttp://dx.doi.org/10.1007/978-3-030-30796-7_32 やな。
[20] E.F. KendallとD.L. McGuinnessの「オントロジー工学」は、Synthesis Lectures on the Semantic Web: Theory and Technologyシリーズで、Morgan & Claypool Publishersから2019年に出版されてるで。DOIはhttp://dx.doi.org/10.2200/S00834ED1V01Y201802WBE018 やな。
[21] C.M. Keetの「オントロジー工学入門」は2020年の本で、URLはhttps://people.cs.uct.ac.za/%7Emkeet/files/OEbook.pdf やで。
[22] A. Gómez-Pérez, M. Fernández-López, Ó. Corchoの「オントロジー工学：知識管理・電子商取引・セマンティックウェブ分野からの事例付き」は、Advanced Information and Knowledge ProcessingシリーズでSpringerから2004年に出版されてるねん。DOIはhttp://dx.doi.org/10.1007/B97353 やで。
[23] D. Chaves-FragaとA. Dimouの「ナレッジグラフ構築自動化の宣言的記述：現状と課題」やねん。D. Chaves-Fraga, A. Dimou, P. Heyvaert, F. Priyatna, J. Sequedaが編集した「第3回ナレッジグラフ構築ワークショップ（KGCW 2022）」の会議録に収録されてるで。これは2022年5月30日にギリシャのヘルソニソスで開催された第19回拡張セマンティックウェブ会議（ESWC 2022）と併催やったんや。CEUR Workshop Proceedingsの3141巻でCEUR-WS.orgから出版されてるで。URLはhttps://ceur-ws.org/Vol-3141/paper5.pdf やな。
[24] D. Fragaの博士論文「宣言的マッピングルールを活用した異種データソースからのナレッジグラフ構築」は、スペインのマドリード工科大学で2021年に出されたもんやで。URLはhttps://oa.upm.es/67890/ やな。
[25] J. SequedaとO. Lassilaの「企業向けナレッジグラフの設計と構築」は、Synthesis Lectures on Data, Semantics, and KnowledgeシリーズでMorgan & Claypool Publishersから2021年に出版されてるで。DOIはhttp://dx.doi.org/10.2200/S01105ED1V01Y202105DSK020 やな。
6
---
![]()
1 / 1