技術概要：BLINKG – LLM 統合型知識グラフ生成のためのベンチマーク

問題定義

異種データソースからの知識グラフ（KG）の構築は、入力データスキーマとオントロジー用語間の意味的対応付けの困難さにより、知識エンジニアにとって依然として労働集約的なプロセスです。宣言的ソリューション（例：RML、SPARQL-Anything）はこのプロセスの一部を一般化しましたが、スキーマ要素をオントロジー概念に整合させるには、依然として複雑な変換と多大な手作業が必要です。

大規模言語モデル（LLM）は KG 構築と意味的整合の自動化にますます適用されていますが、その有効性を評価するための標準化されたフレームワークは欠如しています。既存の研究は多様なシナリオ、パラメータ、指標を用いており、公平な比較を困難にしています。さらに、RODI などの既存のベンチマークは主にリレーショナルデータベースとスキーマレベルの一致に焦点を当てており、SemTab などの課題は、事前構築された KG に対するテーブルの注釈付けに焦点を当てており、未構築のオントロジーへのマッピングには対応していません。多様なデータ形式と異なるレベルのスキーマ整合性において、LLM の明示的かつ宣言的なマッピング能力を評価するベンチマークが緊急に必要とされています。

手法

本論文は、KG 構築における LLM のマッピング能力を評価するために設計されたベンチマーク「BLINKG」を導入します。手法は、3 つの段階的に複雑化するシナリオ、定義された構築タスクのセット、および厳格な評価プロトコルを中心に構成されています。

1. ベンチマークシナリオ

BLINKG は、入力データとターゲットオントロジー間の整合の度合いに基づいて 3 つのシナリオを定義します。

• シナリオ 1（基本）: 単純な入力（CSV、JSON、XML）と最小限のオントロジーを使用した 8 つの原子ケースで構成されます。これらのケースは、クラス識別、主語生成、単純な結合などのコアタスクを分離し、基本的なマッピング動作をテストします。
• シナリオ 2（スキーマ整合）: GTFS-Madrid-Bench を使用して交通分野に焦点を当てます。オントロジーは GTFS 仕様からボトムアップで構築され、高い語彙的および構造的整合性が得られます。このシナリオは、現実的な設定において、LLM がオントロジー固有のモデリング構文（例：クラス階層、制御語彙/SKOS）や変換関数を処理する能力をテストします。
• シナリオ 3（スキーマ遠隔）: 電子調達オントロジー（ePO）とスペインの CODICE プラットフォームからのデータを使用して、公共調達に焦点を当てます。入力データ（深くネストされた XML）とオントロジーは意味的に関連していますが、構造的および語彙的には遠く離れています。このシナリオは、LLM が直接のスキーマ整合なしにマッピングを確立するために深いドメイン専門知識を適用することを要求します。

2. 定義されたタスク

このベンチマークは、エンドツーエンドのブラックボックス評価を超えて、KG 構築を特定のサブタスクに分解します。

• オントロジークラス識別: 入力フィールドをオントロジークラスにマッピングする。
• 主語生成: インスタンス用の一意の URI を作成する（単純キー vs 複合/合成キー）。
• オントロジープロパティ識別: データフィールドをオントロジープロパティにリンクする。
• データ参照識別: 入力データにアクセスする方法を指定する（例：列名、XPath）。
• 関連エンティティクラスと結合: オブジェクトプロパティの条件と複数のソースの結合を定義する。
• 言語およびデータ型注釈: 正しい言語タグと XSD データ型を割り当てる。
• 変換関数: データを正規化するロジックを適用する（例：日付フォーマット、列挙型から分類体系へのマッピング）。

3. 評価プロトコル

• 評価対象モデル: DeepSeek-R1、Gemini 2.5 Pro、GPT-4 Omni、OpenAI o3、LLaMa 3.3 70B Instruct、Mixtral 8x22B Instruct を含む 6 つの最先端 LLM がテストされました。
• 出力形式: 生コードや自然言語の説明ではなく、各タスクのマッピングをリストする構造化された表形式の出力を生成するようにモデルにプロンプトされます。
• 指標: パフォーマンスは精度、再現率、F スコアで測定されます。厳密な文字列一致の限界に対処するため、著者はレーベンシュタイン距離、生テキスト埋め込みのコサイン類似度、オントロジーで言語化された埋め込みのコサイン類似度を組み合わせた類似度ベースの評価を採用しています。
• 評価タイプ: 結果は、専門家評価（手動検証）、生評価（直接指標適用）、ポストプロセッシング評価（出力のヒューリスティックなクリーニング）を通じて分析されます。

主な貢献

本論文は、5 つの主要な貢献を概説します。

1. C1: KG 構築における LLM の動作を評価するために設計された、複数のシナリオ、ゴールドスタンダード、指標を備えた包括的かつドメイン非依存のフレームワーク。
2. C2: 現実世界の課題を反映する段階的に複雑化する 3 つのシナリオで、典型的なマッピングタスクの代表的なセットを網羅。
3. C3: 再現性とコミュニティへの採用を促進するための、オープンで再利用可能なリソース（オントロジー、データセット、ゴールドスタンダード）。
4. C4: 6 つの最先端 LLM の包括的な評価。追跡可能性と透明性に焦点を当てた、パフォーマンスと一般化能力の分析。
5. C5: （半）自動化された LLM 駆動型 KG 構築を進展させるための実用的な推奨事項と特定された研究方向。

結果

実験的評価は、シナリオ全体で明確なパフォーマンスパターンを明らかにしました。

• シナリオ 1（基本）: LLM は、単純で語彙的に整合したタスクで良好に機能します。エンティティクラスの識別とオントロジープロパティの識別は高い類似度スコア（多くの場合 0.95 超）を達成します。しかし、結合条件の生成は依然として困難であり（スコア範囲 0.37–0.69）、言語注釈にはモデル間で大幅なばらつきが見られます。
• シナリオ 2（スキーマ整合）: モデルはエンティティとデータ参照の整合をうまく処理します（類似度 0.90 超）。しかし、構造的推論タスクではパフォーマンスが大幅に低下します。結合条件は依然として困難です（どのモデルも 0.60 を超えません）、関数関連タスク（命名と出力生成）は poor であり（多くの場合 0.20 未満）、抽象化とドメイン固有のロジックとの格闘を示しています。ポストプロセッシングは構文エラーのスコアを大幅に向上させますが、意味的ギャップは解消しません。
• シナリオ 3（スキーマ遠隔）: 全タスクでパフォーマンスが急激に低下します。どのタスクも平均類似度 0.53 を超えません。エンティティクラスの識別が依然として最も強力なタスクですが、結合、データ型、関数などの構造的に複雑なタスクは 0.40 未満のスコアです。プロンプトエンジニアリング（ゼロショット対ファウショット）は「ローカル」タスク（例：クラスの選択）のパフォーマンスを向上させますが、結合や変換に必要な複雑な推論を誘発することはできません。

意義と主張

本論文は、BLINKG が KG 構築における LLM の断片的な評価を超えて進むために必要な標準化されたフレームワークを提供すると主張しています。このベンチマークは、現在の LLM が整合性の取れた制御されたシナリオには有望な解決策を提供する一方で、深いドメイン推論と構造的ロジックを必要とする複雑でスキーマ遠隔の環境ではパフォーマンスが限られていることを示しています。

著者が強調する主な教訓は以下の通りです。

• ハイブリッドアプローチの不可欠性: 汎用 LLM 単独では、高度に複雑な意味環境で有効な解決策を生み出す可能性は低いです。著者は、LLM を記号的推論（例：OWL ベースの推論）または人間ループ検証と組み合わせることを提案しています。
• 追跡可能性: エンドツーエンドのパイプラインとは異なり、BLINKG のタスクレベル評価は、システムが成功または失敗する箇所を透明化し、結合などの複雑なタスクにおけるエラーが単なるフォーマットの問題ではなく、根本的な推論のギャップであることを浮き彫りにします。
• 既存ベンチマークの限界: 著者は、既存のベンチマークが公共データセットの記憶に依存していることを認めています。BLINKG の将来のバージョンは、データ漏洩から真の推論能力をよりよく分離するために、合成オントロジーとデータを利用すべきだと提案しています。

本論文は、LLM が初期のマッピング草案を生成できる一方で、特に複雑な現実世界のアプリケーションにおいて、マッピングの検証と意味的な健全性の確保には人間の専門知識が依然として不可欠であると結論付けています。