経産省GENIACでナレッジグラフの生成/推論に特化したLLMを開発しました！ - fltech

人工知能研究所の宗像聡です。

当社は国立研究開発法人新エネルギー・産業技術総合開発機構（NEDO）の公募「ポスト5G情報通信システム基盤強化研究開発事業／①ポスト5G情報通信システムの開発」および経産省が主催する「Generative AI Accelerator Challenge（GENIAC）プロジェクト」に当社の提案事業「論理推論を可能とする大規模言語モデルの研究開発」（以降では「本事業」と略記）が採択されたことを受け、ナレッジグラフの生成/推論に特化した大規模言語モデル（LLM）の研究開発を進めておりました *1。

GENIAC最終成果報告会における当社のプレゼンおよびデモの様子は、こちらの経産省サイトからご覧いただけます。また、本事業で当社が開発したLLM含む資産は、huggingface.co/Fujitsu-LLM-KGで一部公開しております。

本記事では、本事業期間中に実施した研究開発内容や、作業中に遭遇した困難・得た知見などを一部ご紹介します。

はじめに
継続事前学習
指示学習とベンチマーク
本事業の研究開発成果
最後に
謝辞

はじめに

ナレッジグラフは知識表現の一つであり、様々な情報とその間の関係性を有向グラフ構造でデータ化したものです。当社では十年以上に渡りナレッジグラフを様々に活用してきましが、特に最近ではRetrieval-Augmented Generation（RAG）の性能向上を目的にナレッジグラフとLLMを連携させる技術の研究開発に取り組んでいます *2。

ナレッジグラフをLLMと連携させる狙いの一つに、外部情報に従ってマルチホップ推論を適切に進めることが挙げられます。これはつまり、LLMにとっては初見の外部情報から情報と情報の間の関係性を抽出し、それら複数の関係性を辿り回答に必要な情報を集め考察することと言い換えられます。

例えば、私が最終成果報告会のデモで例示した質問「お正月とお盆とでは、どちらがより長期間の休日ですか?」や「育児時間を利用できる労働者は、休日労働・深夜労働を規則上断れますか?」へ回答するためには、外部情報の就業規則*3から各休日の期間を抽出して比較したり、労働者の各権利を抽出して隠れた共通項を発見したりといったマルチホップ推論が必要です。

研究開発の中で、我々は最新の強力な汎用LLMであっても、特に日本語の場合にマルチホップ推論が期待通りに進まない傾向があることに気づきました。そこで当社は本事業を提案し、ナレッジグラフを使いマルチホップ推論を適切に進めることに特化したローカルLLMの実現を目指しました。

本事業では、大きく以下の流れでLLM開発を進めました：

継続事前学習
- OSSのLLMをベースモデルとして、自然言語文書とナレッジグラフの相互翻訳能力を強化させるための継続事前学習を施した「共通事前学習済みLLM」を開発する
指示学習とベンチマーク
- 共通事前学習済みLLMをベースに、マルチホップ推論に必要な指示学習を施した「ナレッジグラフ生成LLM」と「ナレッジグラフ推論LLM」を開発する
- 各指示学習の効果をそれぞれ、ナレッジグラフを使うマルチホップ推論に関係する計6つの日英ベンチマークデータセットを使い定量評価する

その結果、日本語の2つのベンチマーク（日本語マルチホップQA、日本語文書レベル関係抽出）については、狙い通りに2024年8月当時の世界最高性能を達成することができました（cf. 図1、表1）。一方、他の4つのベンチマークでは既存手法（LLM利用とは限らない）を依然下回る結果でした。本事業で判明した困難・知見を活かし、当社では今後も性能改善を続けてまいります。

以降では、各LLM開発についてより詳細をご紹介していきます。

継続事前学習

本事業では、ナレッジグラフを使ってマルチホップ推論を実行するための、以下の推論手順（図2に例示）に従うLLMを開発することにしました：

ユーザーが入力した質問文から、回答に必要な情報とその関係性を表現したグラフスキーマ（ナレッジグラフの型）を生成する
- ただし、外部情報を参照しないと判明しない情報については、「<?date_of_obon>」など変数を使い不明であることを表現する
外部情報を参照してグラフスキーマ中の不明な箇所を解決していき、回答に必要な情報が揃ったナレッジグラフを生成する
ナレッジグラフを参照して、元の質問文に対する回答を生成する

（上図の外部情報は、厚生労働省が公開しているモデル就業規則を抜粋・改変したものです。）

上記の推論手順を進めるには、「自然言語文書とナレッジグラフを相互翻訳する能力」がどの手番でも重要です。そこで、既に一般的なタスクに対して汎化しているOSSのLLMに対して、この相互翻訳能力を強化させるための継続事前学習を施すことで、共通事前学習済みLLMを開発しました。具体的には、まずナレッジグラフ対訳コーパスを構築し、次にそれを含む継続事前学習データセットによりOSSのLLMを継続事前学習しました。

ナレッジグラフ対訳コーパスの構築

従来から、ナレッジグラフと自然言語テキストを対応付けた事前学習は試されてきました *4。しかし、マスク予測（ナレッジグラフや自然言語テキストの一部をマスクし、元の値を予測させるタスク）で学習させる既存手法は、次トークン予測で学習するDecoder-onlyアーキテクチャのLLMには適用できません。そこで、日英対訳コーパスを使い継続事前学習する既存手法 *5の「翻訳指示形式」を参考にし、ナレッジグラフから自然言語テキストへの翻訳を指示するタスク（KG2Text）と、自然言語テキストからナレッジグラフへの翻訳を指示するタスク（Text2KG）のデータを大量に自動合成することで、次トークン予測で学習可能なナレッジグラフ対訳コーパスを構築しました。

ナレッジグラフ対訳コーパスの自動合成には複数の情報源を用いましたが、以下に森羅プロジェクトの公開データ*6から合成したText2KGタスクデータを例示します：

[INST]
Generate "Knowledge Graph" in RDF Turtle format based on the given "Source".

## Source
```txt
EMEAは、英語の"Europe, the Middle East and Africa"の略で、ヨーロッパ、中東及びアフリカを指す。
```

## Strategy
Extract all verifiable facts about subject "EMEA" in "Source" as knowledge triples.
[/INST]
## Knowledge Graph
```turtle
#@rationale: EMEAは、英語の"Europe, the Middle East and Africa"の略で、ヨーロッパ、中東及びアフリカを指す。
<#EMEA>
    rdf:type <#Continental_Region>;
    rdf:type <#大陸地域名>;
    rel:名前の謂れ <#英語の"Europe, the Middle East and Africa"の略>;
    rel:構成地域 <#ヨーロッパ>;
    rel:構成地域 <#アフリカ>;
    rel:構成地域 <#中東>;
    rel:別名・旧称 <#Europe, the Middle East and Africa>.
```

（上記の例は、Wikipediaおよび森羅プロジェクト公開データを改変したもののため、CC BY-SA 3.0ライセンスが継承されます）

補足情報：
- Strategyに従ってSourceからKnowledge Graphへ変換するよう指示しています。
- ナレッジグラフのテキスト表現として、W3CのRDF Trutleを独自に簡素化した書式を採用しました。
- SourceとStrategyには、それぞれ複数の種類があります。
- 「#@rationale: ...」はKnowledge Graph抽出の根拠となるSourceの1行を示すものです。Sourceが複数行の場合、Knowledge Graphおよびrationaleは複数個出力されます。
- カリキュラム学習手法を参考に、一度に対訳するナレッジグラフの量（正確には述語数）が多いほど難易度が高いと仮定し、難易度の昇順に各タスクをソートしました。これは、LLMが段階的に対訳能力を獲得していくことを狙ったものです。

最終的に、以下のような低品質なデータを除去した上で、計21億トークン分のナレッジグラフ対訳コーパスを構築し、継続事前学習に使いました。

代名詞を解決できないデータ
- ” He was a member of the Yankees”のような文とというトリプルが対応づいている場合、”He”が”Derek Jeter”であることを明記する文が前段に存在しないなら、ハルシネーション(LLMのでっちあげ)を誘発する学習データになると考え事前に除去しました。
同じ単語が繰り返しているデータ
- 特に訳する文が長い場合に、”Nara Nara Nara…”, “1982, 1983, …”のような同じ単語の繰り返しが見られたため、これもハルシネーションを誘発すると考え事前に除去しました。

ナレッジグラフ対訳コーパスを使った学習

ベースモデルとしてOSSの mistralai/Mixtral-8x7B-Instruct-v0.1を選定し、学習フレームワークにNvidia NeMoを使い、ナレッジグラフ対訳コーパスを含む計3,000億トークン分のテキストデータで継続事前学習を実施した時のチェックポイントを、最終的に共通事前学習済みLLMとして後の指示学習で使用しました。

この継続事前学習では検証ロスの落ち方を確認しながら、計3 epochを実施しました（cf. 図3）。ただし各epochでは、ナレッジグラフ対訳コーパス等のナレッジグラフの扱いに特化させるための学習データは固定する一方、一般的な知識を獲得するためのWebクローリングデータは全部入れ替えました。

図3の検証ロス（val_loss）はナレッジグラフ対訳コーパスから分割した検証用データを使って算出したもののため、3 epochにわたり自然言語とナレッジグラフ間の相互翻訳能力が向上していることが期待できます。

学習ハイパーパラメータ

この継続事前学習のハイパーパラメータを以下に示します：

パラメータ名	設定値	補足
GPU Type	Nvidia H100 80GiB
restore_from_path	学習を継続したい事前学習済みLLMのNeMo形式ファイルのパス。ただし、NeMo形式ファイル解凍後のディレクトリのパスを指定する方が、学習開始までの時間を短縮できるので推奨。
trainer.precision	bf16
trainer.accumulate_grad_batches	1
trainer.gradient_clip_val	1.0
model.micro_batch_size	2
model.global_batch_size	1024
model.tensor_model_parallel_size	4	GPUのメモリあふれ（OOM）を避ける目的で、1より大きな値を設定した。
model.pipeline_model_parallel_size	16	チューニング当初はGPUノードを跨る通信を減らす目的で8を設定していたが、予想に反して8より大きく設定する方が実行性能が良かったため、途中から16に設定した。
model.expert_model_parallel_size	1
model.encoder_seq_length	8,192	ナレッジグラフ対訳コーパスは長文を含むために、8K以上に設定する必要があった。
model.max_position_embeddings	32,768
model.moe_router_load_balancing_type	aux_loss
model.aux_loss_coeff	1e-02
model.z_loss_coeff	1e-03
model.{hidden, attention, ffn}_dropout	0.0
model.use_flash_attention	True
model.moe_grouped_gemm	False	有効にすると学習時間が2/3に短縮されることを観測していたが、その時点のNvidia Nemoでは分散学習中にgrouped_gemm含むチェックポイントを生成することが実装上できなかったため利用しなかった。
model.share_embeddings_and_output_weights	False	TrueならLLMの埋め込み層と出力層のパラメータを共有する。一般的に性能が改善されると報告されているものの*7、今回の継続事前学習とは合わないため無効にした。実は、NeMoに用意された設定テンプレートではTrueに設定されていることに気付かず1エポック実施してしまったため、その分の手戻りが発生してしまった。
optim.name	fused_adam
optim.weight_decay	0.1
optim.betas	[0.9, 0.95]
optim.lr	1e-5	最大学習率。
optim.sched.min_lr	1e-6	最小学習率。
optim.sched.name	CosineAnnealing
data.shuffle_documents	False (1st epoch), True (2nd-3rd epoch)	ナレッジグラフ対訳コーパスを事前にソートした順番で学習させるために、1エポック目だけデータをシャッフルしなかった。

共通事前学習済みLLMの入出力

ナレッジグラフ to 自然言語テキスト

ナレッジグラフから自然言語テキストへの変換を指示する場合は、次のプロンプトテンプレートを使います：

[INST]
Generate "Text" to explain the given knowledge triples in "Source".

## Source
```turtle
{ナレッジグラフのテキスト表現}
```

## Strategy
{説明したい関係性の定義}
[/INST]

「説明したい関係性の定義」は、例えば次の様に記述します：

Explain the knowledge triples in "Source" without omission, but concisely and fluently.

共通事前学習済みLLMは、次のフォーマットで結果を出力します：

## Text
```txt
{自然言語テキスト}
```

自然言語テキスト to ナレッジグラフ

自然言語テキストからナレッジグラフへの変換を指示する場合は、次のプロンプトテンプレートを使います：

[INST]
Generate "Knowledge Graph" in RDF Turtle format based on the given "Source".

## Source
```txt
{自然言語テキスト}
```

## Strategy
{抽出したい関係性の定義}
[/INST]

「抽出したい関係性の定義」は、例えば次の様に記述します：

Extract all verifiable facts in "Source" as knowledge triples.
Extract all verifiable facts about subject "{エンティティ}" in "Source" as knowledge triples.
Extract all verifiable facts about relation "{関係性}" in "Source" as knowledge triples.

共通事前学習済みLLMは、次のフォーマットで結果を出力します：

## Knowledge Graph
```turtle
{ナレッジグラフのテキスト表現}
```

その他のタスク

共通事前学習済みLLMのベースモデルはmistralai/Mixtral-8x7B-Instruct-v0.1のため、形式上は[INST]で挟んだ任意のタスクを指示できます。しかし、共通事前学習済みLLMはナレッジグラフ対訳タスクに特化させたモデルのため、その他のタスクでは指示追従性が落ちており、例えば強引にナレッジグラフを生成しようしてしまいます。

つまり、共通事前学習済みLLMおよびその指示学習済みLLMは、GENIAC事業第1期性能評価結果公開で使われたような多様なタスクをこなすことはできず、ナレッジグラフに関する特定のタスクにのみ適用可能なモデルです。本事業では適用しませんでしたが、他のタスクへの指示追従性を保ったままLLMを追加学習する手法は複数提案されており、それら手法の適用は残課題の一つです。

指示学習とベンチマーク

次に共通事前学習済みLLMをベースに、マルチホップ推論に必要な指示学習を施した「ナレッジグラフ推論LLM」と「ナレッジグラフ生成LLM」を開発しました。図2に例示した推論手順において、ナレッジグラフ推論LLMは各手番1,2,3を実行し、ナレッジグラフ生成LLMは外部情報をテキストからナレッジグラフへ変換する役割を担います。

ナレッジグラフを使うマルチホップ推論に関係する計6つの日英ベンチマークデータセットを使い、各指示学習の効果をそれぞれ定量評価しました。以降では、ベンチマークのタイプごとに指示学習とベンチマーク結果を説明していきます。

マルチホップQA

マルチホップQAは、複数回の単純な推論（シングルホップ推論）を積み重ねないと正答できないような、マルチホップ推論を必要とする質問回答タスクです。我々はマルチホップQAの代表的なベンチマークデータセットとして英語のHotpotQAと日本語のJEMHopQAを選び、それらの各訓練データを使って共通事前学習済みLLMに指示学習を実施し、その効果を各テストデータを使って定量評価しました。

タスクの説明

マルチホップQAは、構成質問と比較質問およびその複合に大別されます。

構成質問の例

「長岡京に遷都される前の都の所在地は現在の何県何市にあたるでしょうか？」

回答するためには、まず「長岡京に遷都される前の都は何か？（＝平城京）」を推論し、次に推論結果を引き継いで「その都の所在地は現在の何県何市か？（＝奈良県奈良市）」を推論する必要があります。意外なことに最新のChatGPTであっても間違いやすく、本稿執筆時点（2024年11月8日）のChatGPT 4o miniは「長岡京に遷都される前の都は、現在の京都府京都市にあたります。」という誤答を生成しました。

比較質問の例

「小泉進次郎と小泉孝太郎のうち、先に出生したのはどっち？」

回答するためには、まず「小泉進次郎の出生年は？（＝1981年）」と「小泉孝太郎の出生年は？（＝1978年）」を推論し、次に各推論結果を引き継いで「1981年生まれの小泉進次郎と1978年生まれの小泉孝太郎のうち、先に出生したのはどっち？（＝小泉孝太郎）」を推論する必要があります。こちらも本稿執筆時点（2024年11月8日）のChatGPT 4o miniは「小泉進次郎が先に出生しています。」という誤答を生成しました。

複合質問の例

「2代目若乃花幹士と貴ノ浪貞博では、どちらがより若くして初土俵を踏んだでしょうか？」

回答するためには、まず「2代目若乃花幹士の初土俵年は？（＝1968年7月）」と「2代目若乃花幹士の出生年月は？（＝1953年4月）」から「2代目若乃花幹士が初土俵を踏んだ時の年齢は？（＝15歳3ヶ月）」を推論し、同様に「貴ノ浪貞博の初土俵年月は？（＝1987年3月）」と「貴ノ浪貞博の出生年月は？（＝1971年10月）」から「貴ノ浪貞博が初土俵を踏んだ時の年齢は？（＝15歳5か月）」を推論し、次に各推論結果を引き継いで「15歳3ヶ月で初土俵の2代目若乃花幹士の初土俵年と15歳5ヶ月で初土俵の貴ノ浪貞博では、どちらがより若くして初土俵を踏んだでしょうか？（＝2代目若乃花幹士）」を推論する必要があります。こちらは本稿執筆時点（2024年11月8日）のChatGPT 4o miniは「2代目若乃花幹士の方がより若い年齢で初土俵を踏んだと言えます。」という正答を生成しました。ただし、その根拠にあげた各力士の初土俵時の年齢はどちらも誤っていました（2代目若乃花幹士は18歳、貴ノ浪貞博は19歳で初土俵を踏んだと生成）。

（上記の例は、JEMHopQAからの引用です）

3つのサブタスク

生成AIがマルチホップQAに正答するためには、次の3つのサブタスクが必要だと我々は分析しました：

質問文から、いま不明であり推論が必要な概念と、概念間の論理関係を特定する
- 「小泉進次郎と小泉孝太郎のうち、先に出生したのはどっち？」の場合、「小泉進次郎の出生年①」「小泉孝太郎の出生年②」「先に出生した方の人名」が不明な概念
- 「先に出生した方の人名＝出生年① < 出生年②なら小泉進次郎、そうでなければ小泉孝太郎」が概念間の論理関係
知識または情報源から、不明な概念を順番に解決する
- Wikipedia記事を参照し、概念「小泉進次郎の出生年①＝1981年」「小泉孝太郎の出生年②＝1978年」を解決する
- 概念間の論理関係から、「先に出生した方の人名＝出生年② < 出生年①なので小泉孝太郎」を解決する
解決した概念から、最終回答を生成する
- 最終回答として「小泉孝太郎」を生成する

実は上記の3機能は、先に図2で例示した推論手順の手番1,2,3にそれぞれ対応します。そのため、我々はマルチホップQAベンチマークデータセットを使い、共通事前学習済みLLMに上記3つのサブタスクの指示学習を実施することで、ナレッジグラフ推論LLMを開発しました。

ナレッジグラフ推論用の指示学習データ ver.1

マルチホップQAの指示学習は、先に実施したver.1と、ver.1での反省を活かして実施したver.2があります。ちなみに、最終成果報告会でのデモで使ったナレッジグラフ推論LLMは、ver.2で開発したものです。

指示学習 ver.1では、まずJEMHopQAの訓練データ中の各質問応答から、3つのサブタスクに対応する各入出力テキストを自動合成しました。

（以下の指示学習データ例は、JEMHopQAの改変のため、CC BY-SA 4.0ライセンスが継承されます）

サブタスク1. グラフスキーマの生成

ユーザーが入力した質問文から、回答に必要な情報とその関係性を表現したグラフスキーマ（ナレッジグラフの型）を生成します。ただし、外部情報を参照しないと判明しない情報については、「<#?>」など変数を使い不明であることを表現します。

入力テキスト

[INST]
Generate "Knowledge Graph" in RDF Turtle format based on the given "Source".

## Source
```txt
柄本明と安藤サクラ、芸能活動を開始した年齢が若いのは安藤サクラですか？
```

## Strategy
Extract graph schema needed to answer the question in above "Source" as knowledge triples without omission.
[/INST]

出力テキスト

## Knowledge Graph
```turtle
<#柄本明>
    rel:生年月日 <#?>;
    rel:活動開始年 <#?>.

<#安藤サクラ>
    rel:生年月日 <#?>;
    rel:活動開始年 <#?>.
```

サブタスク2. ナレッジグラフへの解決

外部情報を参照してグラフスキーマ中の変数を解決していき、回答に必要な情報が揃ったナレッジグラフを生成します。

入力テキスト

[INST]
Generate "Knowledge Graph" in RDF Turtle format based on the given "Source".
 
## Source
```txt
柄本明

{ここに「柄本明」のWikipedia記事を埋め込む}
----
安藤サクラ

{ここに「安藤サクラ」のWikipedia記事を埋め込む}
```

## Strategy
Extract all verifiable facts in above "Source", that match the following graph schema, as knowledge triples without omission.
```turtle
<#柄本明>
    rel:生年月日 <#?>;
    rel:活動開始年 <#?>.

<#安藤サクラ>
    rel:生年月日 <#?>;
    rel:活動開始年 <#?>.
```
The extracted facts are needed to answer the question "柄本明と安藤サクラ、芸能活動を開始した年齢が若いのは安藤サクラですか？".
[/INST]

出力テキスト

## Knowledge Graph
```turtle
<#柄本明>
    rel:生年月日 <#1948年11月3日>;
    rel:活動開始年 <#1974年>.

<#安藤サクラ>
    rel:生年月日 <#1986年2月18日>;
    rel:活動開始年 <#2007年>.
```

サブタスク3. 最終回答の生成

ナレッジグラフを参照して、元の質問文に対する回答を生成します。

入力テキスト

[INST]
Explore "Knowledge Graph" entity-to-entity then finally answer "Question".

## Knowledge Graph
```turtle
<#柄本明>
    rel:生年月日 <#1948年11月3日>;
    rel:活動開始年 <#1974年>.

<#安藤サクラ>
    rel:生年月日 <#1986年2月18日>;
    rel:活動開始年 <#2007年>.
```
 
## Question
柄本明と安藤サクラ、芸能活動を開始した年齢が若いのは安藤サクラですか？
 
## Strategy
Answer briefly in one line.
[/INST]

出力テキスト

## Explore Path
```path
柄本明 → rel:生年月日 → 1948年11月3日
柄本明 → rel:活動開始年 → 1974年
安藤サクラ → rel:生年月日 → 1986年2月18日
安藤サクラ → rel:活動開始年 → 2007年
```
 
## Answer
```txt
YES
```

ナレッジグラフ推論用の指示学習データ ver.2

ver.1で指示学習したLLMでも、通常のテキストRAGや従来研究手法よりもJEMHopQAで高い回答精度が出ることはわかりましたが（後述）、本事業の元々の目的の1つであった推論の準拠性・説明性を向上させることについては、次の点で弱いと我々は考えました：

サブタスク1のグラフスキーマの生成の際、不明な情報を変数「?」で表現するだけでは、変数と変数の間の関係性を十分に表現できていない
- また、最終回答と変数間にどのような論理関係があるのかを全く表現できていない
サブタスク2のナレッジグラフへの解決の際、変数解決の根拠になった参照文書中の具体的な文が何かが全く説明できていない
サブタスク3の最終回答の生成の際、最終回答と変数間の論理関係に準拠した推論過程を説明できていない

そこで、指示学習 ver.2では上記の対策を含め、よりデータサイズが大きいHotpotQAの訓練データ中の各質問応答から、3つのサブタスクに対応する各入出力テキストを自動合成しました。

（以下の指示学習データ例は、HotpotQAの改変のため、CC BY-SA 4.0ライセンスが継承されます）

サブタスク1. グラフスキーマの生成

ユーザーが入力した質問文から、回答に必要な情報とその関係性を表現したグラフスキーマ（ナレッジグラフの型）を生成します。ただし、外部情報を参照しないと判明しない情報については、「<?date_of_obon>」「<?area_of_Tokyo>」など型を示す変数名を使い不明であることを表現します。また、「<#Answer>」タグ内で最終回答と変数間の論理関係を表現します。

入力テキスト

[INST]
Generate "Knowledge Graph" in RDF Turtle format based on the given "Source".

## Source
```txt
As of the 2010 census, does Dongguan or Tongzhou District, Beijing have a larger population?
```
 
## Strategy
Extract graph schema needed to answer the question in above "Source" as knowledge triples without omission.
[/INST]

出力テキスト

## Knowledge Graph
```turtle
<#Dongguan>
    rel:has_population <?population_of_Dongguan>;
    rel:as_of <#2010>.
<#Tongzhou District, Beijing>
    rel:has_population <?population_of_Tongzhou>;
    rel:as_of <#2010>.
<#Answer>
    rel:is <#Dongguan>;
    rel:when [
        <?population_of_Dongguan>
            rel:greater_than <?population_of_Tongzhou>.
    ];
    rel:else <#Tongzhou District, Beijing>.
```

サブタスク2. ナレッジグラフへの解決

外部情報を参照してグラフスキーマ中の変数を解決していき、回答に必要な情報が揃ったナレッジグラフを生成します。変数を解決する際、外部情報のどの文を根拠としたのかを「#@rationale」コメントで表現します。

入力テキスト

[INST]
Generate "Knowledge Graph" in RDF Turtle format based on the given "Source".

## Source
```txt
Title: Tongzhou District, Nantong
{ここに「Tongzhou District, Nantong」のWikipedia記事を埋め込む}
----
Title: Elkhart, Indiana
{ここに「Elkhart, Indiana」のWikipedia記事を埋め込む}
----
Title: Dongguan
{ここに「Dongguan」のWikipedia記事を埋め込む}
----
Title: Walpole (CDP), Massachusetts
{ここに「Walpole (CDP), Massachusetts」のWikipedia記事を埋め込む}
----
Title: Beiyuan Subdistrict, Beijing
{ここに「Beiyuan Subdistrict, Beijing」のWikipedia記事を埋め込む}
----
Title: Woodinville, Washington
{ここに「Woodinville, Washington」のWikipedia記事を埋め込む}
----
Title: Line 7, Beijing Subway
{ここに「Line 7, Beijing Subway」のWikipedia記事を埋め込む}
----
Title: Yizhuang Line, Beijing Subway
{ここに「Yizhuang Line, Beijing Subway」のWikipedia記事を埋め込む}
----
Title: Yanjiao
{ここに「Yanjiao」のWikipedia記事を埋め込む}
----
Title: Tongzhou District, Beijing
{ここに「Tongzhou District, Beijing」のWikipedia記事を埋め込む}
```

## Strategy
Extract all verifiable facts in above "Source", that match the following graph schema, as knowledge triples.
```turtle
<#Dongguan>
    rel:has_population <?population_of_Dongguan>;
    rel:as_of <#2010>.
<#Tongzhou District, Beijing>
    rel:has_population <?population_of_Tongzhou>;
    rel:as_of <#2010>.
<#Answer>
    rel:is <#Dongguan>;
    rel:when [
        <?population_of_Dongguan>
            rel:greater_than <?population_of_Tongzhou>.
    ];
    rel:else <#Tongzhou District, Beijing>.
```
The extracted facts are needed to answer the question "As of the 2010 census, does Dongguan or Tongzhou District, Beijing have a larger population?".
However, if no useful facts are found in the above "Source", do not output any triples.
[/INST]

出力テキスト

## Knowledge Graph
```turtle
<#Dongguan>
    #@rationale: Dongguan is a prefecture-level city in central Guangdong Province of South China. It is part of the Pearl River Delta megacity with more than 44.78 million inhabitants at the 2010 census spread over nine municipalities (including Macao) across an area of 17,573 km2 .
    rel:has_population <#44780000>;
    rel:as_of <#2010>.
<#Tongzhou District, Beijing>
    #@rationale: The district had a population of 673,952 at the 2000 Census, and has seen significant growth and development since then, growing to a population of 1,184,000 at the 2010 Census.
    rel:has_population <#1184000>;
    rel:as_of <#2010>.
<#Answer>
    rel:is <#Dongguan>;
    rel:when [
        <#44780000>
            rel:greater_than <#1184000>.
    ];
    rel:else <#Tongzhou District, Beijing>.
```

サブタスク3. 最終回答の生成

ナレッジグラフを参照して、元の質問文に対する回答を生成します。推論過程を説明する際、「<#Answer>」タグ内の最終回答と変数間の論理関係も解決します。

入力テキスト

[INST]
Explore "Knowledge Graph" entity-to-entity then finally answer "Question".

## Knowledge Graph
```turtle
<#Dongguan>
    rel:has_population <#44780000>;
    rel:as_of <#2010>.
<#Tongzhou District, Beijing>
    rel:has_population <#1184000>;
    rel:as_of <#2010>.
<#Answer>
    rel:is <#Dongguan>;
    rel:when [
        <#44780000>
            rel:greater_than <#1184000>.
    ];
    rel:else <#Tongzhou District, Beijing>.
```

## Question
As of the 2010 census, does Dongguan or Tongzhou District, Beijing have a larger population?

## Strategy
Answer briefly in one line.
[/INST]

出力テキスト

## Explore Path
```path
Dongguan had a population of 44,780,000 in 2010.
Tongzhou District, Beijing had a population of 1,184,000 in 2010.
Answer is Dongguan because 44,780,000 is greater than 1,184,000.
```

## Answer
```txt
Dongguan
```

指示学習の実施

継続事前学習と同じNvidia NeMoを学習フレームワークに使い、共通事前学習済みLLMをベースに指示学習データ ver.1とver.2でそれぞれ指示学習を1 epoch実施することで、ナレッジグラフ推論LLM ver.1とver.2を構築しました。学習ステップごとの汎化性能を観測するために、各指示学習データは訓練データと検証データに分割して利用しました。

これら指示学習のハイパーパラメータと、継続事前学習のハイパーパラメータとの差分を以下に示します：

パラメータ名	設定値	補足
restore_from_path	共通事前学習済みLLMのNeMo形式ファイル解凍後のディレクトリパス
model.micro_batch_size	1
model.global_batch_size	64
model.tensor_model_parallel_size	8	GPUのメモリあふれ（OOM）を避ける目的で、1より大きな値を設定した。
model.answer_only_loss	True	指示学習の出力テキストだけから次単語予測のロスを算出するようにした。
data.train_ds.shuffle	False	3つのサブタスクが極力同じステップで学習されるようにするため、データのシャッフルは無効にした。

ベンチマーク

日本語（JEMHopQA）

JEMHopQAは、日本語で表現された知識とそれを処理するための推論能力を定量評価することができる、マルチホップQAベンチマークデータセットです*8。指示学習に使っていないcorpus_ver 1.1/dev_ver1.1.jsonに収録された全120問のQAを対象に、ナレッジグラフ推論LLM ver.1と既存手法との回答精度をベンチマークしました。

回答精度として、公式のevaluate.pyで算出される類似スコアを比較しました。類似スコアは回答文と教師文との類似度を0%～100%で定量化する指標で、回答文と教師文が完全一致する場合に100%をとります。

手法	回答精度	備考
既存手法	72.7	HOLMES*9の日本語対応版を利用。LLMにはGPT-4oを利用。
GPT-4	62.9	Ai Ishiiらの先行研究に記載の値。Few-shotプロンプティングとCoTプロンプティングを利用。
開発LLM	82.3	ナレッジグラフ推論LLM ver.1を利用。Zero-shot。

結果から、467億パラメータ相当の小さなLLMであっても、追加学習でナレッジグラフを使った論理推論に特化させることで、1兆～2兆パラメータを持つと推察されるGPT-4単体やGPT-4を用いた既存手法よりも、日本語マルチホップQAの回答精度を高くできることがわかりました。

英語（HotpotQA）

HotpotQAは、英語で表現された知識とそれを処理するための推論能力を定量評価することができる、マルチホップQAベンチマークデータセットです*10。 Pranoy Pandaらの先行研究と同様、指示学習に使っていないhotpot/hotpot_dev_distractor_v1.jsonの全7405問からランダムに選択した1,000問を対象に、ナレッジグラフ推論LLM ver.2と既存手法との回答精度をベンチマークしました。

回答精度として、公式のhotpot_evaluate_v1.pyで算出されるF1スコアを比較しました。F1スコアは回答文と教師文との語の粒度での一致度を0%～100%で定量化する指標で、回答文と教師文に含まれる語が完全一致する場合に100%をとります。

手法	回答精度	備考
既存手法	85.04	Jiahao Zhangらの先行研究*11に記載の値。当時の世界最高値であり、他のベースラインと違いテストデータを用いて公式にベンチマークされた値。ファインチューニングしたDeBERTaを利用。
GPT-4	78.0	Pranoy Pandaらの先行研究に記載の値。Few-shotプロンプティングとナレッジグラフ探索を利用。
GPT-3.5	69.0	Pranoy Pandaらの先行研究に記載の値。Few-shotプロンプティングとナレッジグラフ探索を利用。
開発LLM	73.8	ナレッジグラフ推論LLM ver.2を利用。Zero-shot。

結果から、GPT-3.5を用いた既存手法よりも、英語マルチホップQAの回答精度が高くできることはわかりましたが、一方でGPT-4を使った既存手法や、ファインチューニングを用いた先行研究には回答精度に劣ることがわかりました。指示学習データの品質など原因は様々に考えられますが、継続事前学習では大部分が日本語データであったことから、相対的に英語の推論能力が劣化してしまったのかもしれません。原因の調査特定を続ける必要があります。

文書レベル関係抽出

文書レベル関係抽出は、文書内の複数の文を合わせ見ないと正答できないような、知識抽出タスクです。我々は文書レベル関係抽出の代表的なベンチマークデータセットとして英語のRe-DocREDと日本語のJacREDを選び、それらの各訓練データと開発データを使って共通事前学習済みLLMに指示学習を実施し、その効果を各テストデータを使って定量評価しました。

タスクの説明

文書レベル関係抽出は、固有表現間で事前定義された数十種類の関係性を、自然言語文書から漏れなく・適切に抽出するタスクです。固有表現とは、意味が明確で自己完結したキーワードであり、人名・地名などの固有名詞や、時間・金額などの数量表現のことを指します。

「所属」関係を抽出する例

文書「⼩⽥持家(おだもちいえ、応永9年8⽉5⽇(1402年9⽉2⽇) - ⽂明18年10⽉21⽇(1486年11⽉17⽇))は、室町時代の⼈物。常陸⼩⽥⽒当主。」 ⇒ 関係＜⼩⽥持家，MemberOf，⼩⽥⽒＞

抽出された関係は、「小田持家」という人物が「⼩⽥⽒」という組織のメンバーであることを意味しています。この関係を構成する固有表現は、文書の第一文と第二文に分かれて記述されているため、二文を合わせ見て関係抽出する必要があります。

ただし、実際にはRe-DocREDとJacREDは文書を文ではなく単語列で保持しており、さらに固有表現に対応する単語には「Person」「Date」などの固有表現分類がアノテーションされています。そのため、正確には文書レベル関係抽出タスクは以下の入出力イメージの様に、単語列と固有表現分類を入力として受け取り、主語となる固有表現・関係性・目的語となる固有表現の三つ組を出力するタスクです。また、例では省略していますが、実際は十数文から複数個の三つ組を漏れなく出力するタスクになります。

# 文書レベル関係抽出タスクの実際の入出力イメージ

## 入力
* 文書
    1. "小田", "持", "家", "(", "お", "だ", "もち", "いえ", "、", "応永", "9", "年", "8", "月", "5", "日", "(", "140", "2", "年", "9", "月", "2", "日", ")", "-", "文明", "18", "年", "10", "月", "21", "日", "(", "148", "6", "年", "11", "月", "17", "日", ")", ")", "は", "、", "室町", "時代", "の", "人物", "。"
    2. "常陸", "小田", "氏", "当主", "。"
* 固有表現
    * Person
        * 小田 持家
        * おだ もちいえ
    * Date
        * 室町時代
        * 応永9年8月5日
        * 1402年9月2日
        * 文明18年10月21日
        * 1486年11月17日
    * Organization
        * 小田氏
    * Location
        * 常陸
* 抽出する関係性
   * MemberOf

## 出力
1. ＜⼩⽥ 持家，MemberOf，⼩⽥⽒＞

（上記の例は、Wikipediaを改変したもののため、CC BY-SA 3.0ライセンスが継承されます）

文書中の関係性を自由に抽出するのではなく、例の様に特定の関係性を漏れなく・間違いなく抽出するタスクは、現在対話型生成AIとして主流であるDecoder-onlyアーキテクチャのLLMが苦手とするタスクであると言われており、GPT3.5やGPT-4であってもBERT等のEncoder-DecoderアーキテクチャのLLMには抽出精度で大きく劣ります*12。しかし、Decoder-onlyアーキテクチャの方がコンテキスト長がより大きいLLMを構築でき、文書サイズの制約を受けづらいため、文書レベル関係抽出を産業応用しやすくなる利点があります（BERTの最大コンテキスト長が512に対して、Decoder-onlyアーキテクチャのMixtral-8x7Bは32,768）。一応、Few-shotプロンプティングやCoTプロンプティングを工夫することでGPT-3による関係抽出精度を改善させた研究はありますが*13、DocREDのような文書レベル関係抽出が対象とする文章は長文のために適用できなかったと同時に報告されています。

そこで本事業では、Decoder-onlyアーキテクチャのMixtral-8x7Bであっても、ナレッジグラフ対訳コーパスで継続事前学習させた後に文書レベル関係抽出タスクを指示学習した場合には、Few-shotプロンプティングやCoTプロンプティングも使わずに、Encoder-DecoderアーキテクチャのLLMを優越する精度が実現できるのかを実際に検証しました。

ナレッジグラフ生成用の指示学習データ

文書レベル関係抽出の指示学習データとして、日本語文章から関係抽出する版と、英語文章から関係抽出する版をそれぞれ作りました。日本語版は、JacREDの訓練データを使い、1件の日本語文章から計35種類の関係性を1種類ずつ抽出するタスクとして自動合成しました。英語版は、Re-DocREDの訓練データを使い、1件の英語文章から計96種類の関係性を1種類ずつ抽出するタスクとして自動合成しました。

指示学習データと継続事前学習に使用したナレッジグラフ対訳コーパスとは、特定種類の関係性（例では「CountryOfCitizenship」）を正確に抽出するための Strategy が定義されている点と、固有表現抽出（例では「マリー・テレーズ・ドートリッシュ」など）の情報が Source に追加されている点が異なります。これら情報は合成元の文書レベル関係抽出ベンチマークデータセットに含まれている情報であり、他の既存手法も精度向上のために利用しているもののため、公平な比較のために本指示学習データでも利用することにしたものです。

日本語版も英語版も、文章によってはいくつかの種類の関係性は抽出されないことが正答になる場合がありますが、そのような何も抽出されないタスクも意図的に自動合成しました。この何も抽出されないタスクによる指示学習は、文章に明記されていない関係性の誤検出を減らし適合率を向上させる効果があることが、ベンチマーク時に判明しています。

日本語版

（以下の指示学習データ例は、Wikipediaを改変したもののため、CC BY-SA 3.0ライセンスが継承されます）

入力テキスト

[INST]
Generate "Knowledge Graph" in RDF Turtle format based on the given "Source".

## Source
```txt
s0. <#マリー・テレーズ・ドートリッシュ:Person[0]>(<#1638 年 9 月 10 日:Date[6]>日-<#1683 年 7月 30 日:Date[7]>)は、<#フランス:Location[1]>王<#ルイ 14 世:Person[2]>の王妃。
s1. 父は<#スペイン:Location[3]>王<#フェリペ 4 世:Person[4]>、母は<#フランス:Location[1]>王<#アンリ 4 世:Person[8]>と<#マリー・ド・メディシス:Person[9]>の娘<#イサベル・デ・ボルボン:Person[5]>。
s2. <#スペイン:Location[3]>名は<#マリア・テレサ:Person[0]>。
s3. <#ルイ 14 世:Person[2]>の父<#ルイ 13 世:Person[10]>は<#イサベル:Person[5]>の兄、母<#アンヌ・ドートリッシュ:Person[11]>は<#フェリペ 4 世:Person[4]>の姉であり、<#ルイ 14世:Person[2]>と<#マリー・テレーズ:Person[0]>とは父方・母方双方で従兄妹に当たる。
s4. <#神聖ローマ:Location[12]>皇帝<#レオポルト 1 世:Person[13]>の皇后<#マルガリータ・テレサ:Person[14]>は異母妹、<#スペイン:Location[3]>・<#ハプスブルク家:Organization[15]>最後の王<#カルロス 2世:Person[16]>は異母弟である。
```
## Strategy
Extract all verifiable facts about relation "CountryOfCitizenship" in "Source" as knowledge triples.
* Don't speculate, extract only the facts as stated in "Source" **WITHOUT OMMISION**. 
The relation "CountryOfCitizenship" (P27) means "the object is a country that recognizes the subject as its citizen".
* The existence of a relation is restricted by the type of subject and object. You must select subjects and objects of triples from the bracketed eigenexpressions, such as "<#name:type[id]>", without modification.
[/INST]

出力テキスト

## Knowledge Graph
```turtle
#@rationale: s0. <#マリー・テレーズ・ドートリッシュ:Person[0]>(<#1638 年 9 月 10 日:Date[6]>日-<#1683 年 7 月 30 日:Date[7]>)は、<#フランス:Location[1]>王<#ルイ 14 世:Person[2]>の王妃。

<#ルイ 14 世:Person[2]>
    rel:CountryOfCitizenship <#フランス:Location[1]>.

#@rationale: s1. 父は<#スペイン:Location[3]>王<#フェリペ 4 世:Person[4]>、母は<#フランス:Location[1]>王<#アンリ 4 世:Person[8]>と<#マリー・ド・メディシス:Person[9]>の娘<#イサベル・デ・ボルボン:Person[5]>。

<#フェリペ 4 世:Person[4]>
    rel:CountryOfCitizenship <#スペイン:Location[3]>.

<#アンリ 4 世:Person[8]>
    rel:CountryOfCitizenship <#フランス:Location[1]>.

<#イサベル・デ・ボルボン:Person[5]>
    rel:CountryOfCitizenship <#フランス:Location[1]>.

#@rationale: s2. <#スペイン:Location[3]>名は<#マリア・テレサ:Person[0]>。

<#マリー・テレーズ・ドートリッシュ:Person[0]>
    rel:CountryOfCitizenship <#フランス:Location[1]>.

#@rationale: s3. <#ルイ 14 世:Person[2]>の父<#ルイ 13 世:Person[10]>は<#イサベル:Person[5]>の兄、母<#アンヌ・ドートリッシュ:Person[11]>は<#フェリペ 4 世:Person[4]>の姉であり、<#ルイ 14 世:Person[2]>と<#マリー・テレーズ:Person[0]>とは父方・母方双方で従兄妹に当たる。

<#ルイ 13 世:Person[10]>
    rel:CountryOfCitizenship <#フランス:Location[1]>.

#@rationale: s4. <#神聖ローマ:Location[12]>皇帝<#レオポルト 1 世:Person[13]>の皇后<#マルガリータ・テレサ:Person[14]>は異母妹、<#スペイン:Location[3]>・<#ハプスブルク家:Organization[15]>最後の王<#カルロス 2 世:Person[16]>は異母弟である。

<#カルロス 2 世:Person[16]>
    rel:CountryOfCitizenship <#スペイン:Location[3]>.
```

英語版

（以下の指示学習データ例は、Wikipediaを改変したもののため、CC BY-SA 3.0ライセンスが継承されます）

入力テキスト

[INST]
Generate "Knowledge Graph" in RDF Turtle format based on the given "Source".
 
## Source
```txt
s0. <#John Gregory Myre:Person[0]> is an <#American:Location[1]> journalist and <#NPR:Organization[2]>'s digital editor for international news.
s1. Previously, he was a foreign correspondent for The <#Associated Press:Organization[3]> and The <#New York Times:Organization[4]> for <#20 years:Time[5]>.
s2. He reported from <#Jerusalem:Location[6]> from <#2003:Time[7]> to <#2007:Time[8]> for The <#New York Times:Organization[4]>.
s3. With the <#AP:Organization[3]>, <#Myre:Person[0]> was based in <#Jerusalem:Location[6]>, <#Moscow:Location[9]>, <#Nicosia:Location[10]>, <#Islamabad:Location[11]> and <#Johannesburg:Location[12]>.
s4. He covered many major international stories, including <#Nelson Mandela:Person[13]>'s release from prison in <#1990:Time[14]>, the <#Gulf War:Miscellaneous[15]> of <#1991:Time[16]>, the rise of the <#Taliban:Organization[17]>, the early days of <#Vladimir Putin:Person[18]> as <#Russia:Location[19]>'s leader, the <#Israeli:Location[20]>-<#Palestinian:Location[21]> fighting that erupted in <#2000:Time[22]> and the <#U.S.:Location[23]> war in <#Afghanistan:Location[24]>.
s5. He is also a scholar at the <#Middle East Institute:Organization[25]> in <#Washington:Location[26]>.
 ```
 
## Strategy
Extract all verifiable facts about relation "country_of_citizenship" in "Source" as knowledge triples.
* Don't speculate, extract only the facts as stated in "Source" **WITHOUT OMMISION**.
The relation "country_of_citizenship" (P27) means "the object is a country that recognizes the subject as its citizen".
* The existence of a relation is restricted by the type of subject and object.
You must select subjects and objects of triples from the bracketed eigenexpressions, such as "<#name:type[id]>", without modification.
[/INST]

出力テキスト

## Knowledge Graph
```turtle
#@rationale: s0. <#John Gregory Myre:Person[0]> is an <#American:Location[1]> journalist and <#NPR:Organization[2]>'s digital editor for international news.
 
<#Myre:Person[0]>
    rel:country_of_citizenship <#American:Location[1]>.
 
#@rationale: s1. Previously, he was a foreign correspondent for The <#Associated Press:Organization[3]> and The <#New York Times:Organization[4]> for <#20 years:Time[5]>.
 
#@rationale: s2. He reported from <#Jerusalem:Location[6]> from <#2003:Time[7]> to <#2007:Time[8]> for The <#New York Times:Organization[4]>.
 
#@rationale: s3. With the <#AP:Organization[3]>, <#Myre:Person[0]> was based in <#Jerusalem:Location[6]>, <#Moscow:Location[9]>, <#Nicosia:Location[10]>, <#Islamabad:Location[11]> and <#Johannesburg:Location[12]>.
 
#@rationale: s4. He covered many major international stories, including <#Nelson Mandela:Person[13]>'s release from prison in <#1990:Time[14]>, the <#Gulf War:Miscellaneous[15]> of <#1991:Time[16]>, the rise of the <#Taliban:Organization[17]>, the early days of <#Vladimir Putin:Person[18]> as <#Russia:Location[19]>'s leader, the <#Israeli:Location[20]>-<#Palestinian:Location[21]> fighting that erupted in <#2000:Time[22]> and the <#U.S.:Location[23]> war in <#Afghanistan:Location[24]>.
 
<#Vladimir Putin:Person[18]>
    rel:country_of_citizenship <#Russia:Location[19]>.
 
#@rationale: s5. He is also a scholar at the <#Middle East Institute:Organization[25]> in <#Washington:Location[26]>.
```

指示学習の実施

継続事前学習と同じNvidia NeMoを学習フレームワークに使い、共通事前学習済みLLMをベースに指示学習データの日本語版と英語版でそれぞれ指示学習を1 epoch実施することで、ナレッジグラフ生成LLMの日本語版と英語版を構築しました。学習ステップごとの汎化性能を観測するために、各文書レベル関係抽出ベンチマークデータセットの開発データから合成したタスクを検証に使いました。

これら指示学習のハイパーパラメータと、継続事前学習のハイパーパラメータとの差分を以下に示します：

パラメータ名	設定値	補足
restore_from_path	共通事前学習済みLLMのNeMo形式ファイル解凍後のディレクトリパス
model.micro_batch_size	1
model.global_batch_size	128
model.tensor_model_parallel_size	2	GPUのメモリあふれ（OOM）を避ける目的で、1より大きな値を設定した。
model.answer_only_loss	True	指示学習の出力テキストだけから次単語予測のロスを算出するようにした。
data.train_ds.shuffle	False	3つのサブタスクが極力同じステップで学習されるようにするため、データのシャッフルは無効にした。

ベンチマーク

日本語（JacRED）

JacREDは、日本語Wikipediaの文章中の固有表現間にある特定の計35種類の関係性が、漏れなく正確に抽出できているかを定量評価することができる、文書レベル関係抽出ベンチマークデータセットです*14。指示学習に使っていないtest.jsonに収録された全300問を対象に、ナレッジグラフ生成LLMの日本語版と既存手法との回答精度をベンチマークしました。

回答精度として、Youmi Maらの先行研究と同じF1スコアを比較しました。F1スコアは抽出結果の再現率と適合率のバランスの良さを0%～100%で定量化する指標で、正答とする全ての関係性を漏れなく・誤りなく抽出した場合に100%をとります。

手法	回答精度	備考
既存手法	68.73	Youmi Maらの先行研究に記載の値。当時の世界最高値。ファインチューンしたBERTを利用。
GPT-4	27.45	Youmi Maらの先行研究に記載の値。Few-shotプロンプティングを利用。
GPT-3.5	13.17	Youmi Maらの先行研究に記載の値。Few-shotプロンプティングを利用。
開発LLM	68.77	ナレッジグラフ生成LLMの日本語版を利用。Zero-shot。

結果から、467億パラメータ相当の小さなLLMであっても、追加学習でナレッジグラフの生成に特化させることで、GPT-4単体を優越しEncoder-Decoderアーキテクチャのモデルを使う既存手法に匹敵するほど、日本語文書レベル関係抽出の回答精度を高くできることがわかりました。

英語（Re-DocRED）

Re-DocREDは、英語Wikipediaの文章中の固有表現間にある特定の計96種類の関係性が、漏れなく正確に抽出できているかを定量評価することができる、文書レベル関係抽出ベンチマークデータセットです*15。指示学習に使っていないtest_revised.jsonに収録された全500問中の先頭32問を対象に、ナレッジグラフ生成LLMの英語版と既存手法との回答精度をベンチマークしました*16。

回答精度として、Youmi Maらの先行研究*17と同じF1スコアを比較しました。F1スコアは抽出結果の再現率と適合率のバランスの良さを0%～100%で定量化する指標で、正答とする全ての関係性を漏れなく・誤りなく抽出した場合に100%をとります。

手法	回答精度	備考
既存手法	80.7	Youmi Maらの先行研究に記載の値。当時の世界最高値。ファインチューンしたBERTを利用。
GPT-4	14.3	Youmi Maらの先行研究に記載の値。Few-shotプロンプティングを利用。
GPT-3.5	6.55	Youmi Maらの先行研究に記載の値。Few-shotプロンプティングを利用。
開発LLM	52.7	ナレッジグラフ生成LLMの英語版を利用。Zero-shot。

結果から、GPT-4を用いた既存手法よりも、英語文書レベル関係抽出の回答精度が高くできることはわかりましたが、一方でEncoder-Decoderアーキテクチャのモデルを使う既存手法には回答精度で大きく劣ることがわかりました。指示学習データの品質など原因は様々に考えられますが、継続事前学習では大部分が日本語データであったことから、相対的に英語の推論能力が劣化してしまったのかもしれません。原因の調査特定を続ける必要があります。

法的判断予測

法的判断予測は、法律条文や判例に基づいて与えられた状況での適切な行動や違反有無を判断するタスクです。我々は法的判断予測の代表的なベンチマークデータセットとして英語のECtHR cases *18と日本語の短答式司法試験問題集を選び、ナレッジグラフ推論LLM ver.2を使い定量評価しました。

ただし、実世界においては、法的判断は法律の専門家・有資格者により執り行われなければなりません。本事業では、ナレッジグラフ推論LLMの性能を定量評価する目的でのみ法的判断予測を実施したものであり、定量評価方法もデータセット中の正解データと予測結果を単純比較しただけです。法律の専門家・有資格者による予測結果の妥当性の確認は実施しておりませんし、実際の評価結果からも当時の開発LLMは実用から遠い性能であることがわかっております。また、法的判断予測のためのデータセットは、本事業中に一切指示学習には用いておりません。

英語（ECtHR cases）

ECtHR casesは、欧州人権条約への規定違反に関する欧州人権裁判所（ECHR）の審理結果をデータセットにしたものです*19。 ECtHR casesには、申し立てごとの「事実の一覧（facts）」と「違反と判断された欧州人権条約の条番号（violated_articles）」が記録されているため、LLMに事実と条文から違反の有無を出力させることで、LLMによる法的判断の予測精度を定量評価することができます。

タスクの説明

ECtHR casesのtest.jsonから、事実ごとの違反と判断される条番号をナレッジグラフ推論LLMが出力するタスクとして、各入力テキストを自動合成しました（法的判断予測では指示学習は実施しないため、出力テキストは必要ない）。

（以下の入出力例は、ECtHR casesを改変したもののため、CC BY-NC-SA 4.0ライセンスが継承されます）

入力テキスト

Sourceに一覧した事実から、欧州人権条約第１３条（Right to an effective remedyを規定）への違反が疑われるものをrationaleとして引用し、違反と判断した場合には変数<?yes_or_no>にyesを、そうでない場合はnoを出力するように指示しています。

[INST]
Generate "Knowledge Graph" in RDF Turtle format based on the given "Source".

## Strategy
If there are facts that violate the human rights stipulated by the Article, extract the facts based on the following knowledge graph schema.
* Overwrite the variable "<?yes_or_no>" with "<#yes>" if there is a fact that violates a human rights stipulated by the Article.
```turtle
<#Article>
#@rationale: Title: Right to an effective remedy - The Court took into consideration the period after 11 September 1997, when the Convention had come into force in respect of Ukraine.
rel:provides_for <#right_to_an_effective_remedy>;
rel:before <#national_authorities>;
rel:for_violations_of <#rights_under_the_convention>.
<#right_to_an_effective_remedy>
#@rationale: Title: Right to an effective remedy - The Court took into consideration the period after 11 September 1997, when the Convention had come into force in respect of Ukraine.
rel:is_a <#free-standing_and_separately_actionable_infringement_of_the_convention>.
<#Facts List>
#@rationale: Title: Facts list - ...
rel:violates_right_to_an_effective_remedy <?yes_or_no>.
```

## Source
```txt
Title: Facts list

4. The applicant was born in 1955 and lives in Simferopol. She is a single mother and has a son who at the time of the accident in question was eight years old.
5. On 24 July 1995 the applicant was knocked down by a trolley bus. She suffered an open craniocerebral injury and contusion of the brain. As a result, the applicant received the status of a disabled person with the lowest degree of disability (третя група інвалідності).
6. In January 1996 the applicant instituted proceedings in the Tsentralnyy District Court against the Simferopol Trolley Bus Company, claiming compensation for pecuniary and non-pecuniary damage to her health caused by the accident. In particular, as pecuniary damage the applicant claimed compensation for medicines, additional nutrition, treatment in a sanatorium, transport expenses, and compensation for loss of earnings.
7. On 25 February 2003 the applicant lodged an application with the Court (Litvinyuk v. Ukraine, no. 9724/03) complaining, inter alia, under Article 6 § 1 of the Convention about the lengthy examination of her case by the domestic courts.
8. On 1 February 2007, while the proceedings were still pending before the national courts, the Court delivered a judgment on the applicant’s first application (no. 9724/03), finding that the length of the proceedings in her case had been excessive. The Court took into consideration the period after 11 September 1997, when the Convention had come into force in respect of Ukraine. The length of the proceedings within the Court’s competence was nine years and twenty two days.
9. The Court, in particular, noted the following: “47. As for the issues that were at stake for the applicant, the Court notes that following the traffic accident the applicant was seriously injured and received a disability degree. Given that the applicant was a single mother and had a child to raise, the compensations for loss of earnings and for expenses sustained as a result of a poor state of her health were of undeniable importance for the applicant. The Court therefore considers that what was at stake for the applicant called for an expeditious decision on her claims.”
10. On 27 March 2007 the Simferopolskiy District Court found against the applicant. On 24 December 2007 the Court of Appeal of the Autonomous Republic of Crimea quashed this decision and remitted the case to a first-instance court for fresh examination. On 23 April 2008 the Supreme Court of Ukraine upheld the decision of the court of appeal.
11. On 13 May 2009 the Simferopolskiy District Court partly found for the applicant. On 29 July 2009 the Court of Appeal of the Autonomous Republic of Crimea quashed this decision and remitted the case to a first-instance court for fresh examination. On 15 October 2009 the Supreme Court of Ukraine upheld the decision of the court of appeal.
12. On 10 November 2009 the Simferopolskiy District Court left the applicant’s case without consideration because she had failed to appear in court without giving plausible reasons on 28 October 2009 and 10 November 2009. The applicant lodged an appeal against this decision stating that she had not been aware about the above-mentioned hearings. On 27 January 2010 the Court of Appeal of the Autonomous Republic of Crimea rejected the applicant’s appeal. The court noted that the applicant had been duly notified about the date of the hearings. On 5 October 2011 the Supreme Court of Ukraine upheld the decisions of the lower courts. A further attempt by the applicant to have the above decisions reviewed in the light of newly discovered circumstances was to no avail.
```
[/INST]

出力テキストの例

例えば、Sourceの7番目に記載があった事実を違反と判断する場合は、その事実を引用しyesを出力します。

## Knowledge Graph
```turtle
<#Article>
    #@rationale: Title: Right to an effective remedy - The Court took into consideration the period after 11 September 1997, when the Convention had come into force in respect of Ukraine.
    rel:provides_for <#right_to_an_effective_remedy>;
    rel:before <#national_authorities>;
    rel:for_violations_of <#rights_under_the_convention>.
<#right_to_an_effective_remedy>
    #@rationale: Title: Right to an effective remedy - The Court took into consideration the period after 11 September 1997, when the Convention had come into force in respect of Ukraine.
    rel:is_a <#free-standing_and_separately_actionable_infringement_of_the_convention>.
<#Facts List>
    #@rationale: Title: Facts list - Fact-7. On 25 February 2003 the applicant lodged an application with the Court (Litvinyuk v. Ukraine, no. 9724/03) complaining, inter alia, under Article 6 § 1 of the Convention about the lengthy examination of her case by the domestic courts.
    rel:violates_right_to_an_effective_remedy <#yes>.
```

ベンチマーク

ECtHR casesのtest.jsonに収録された全1,000問中の先頭105問を対象に、ナレッジグラフ生成LLMの英語版と既存手法との回答精度をベンチマークしました*20。 ECtHR casesでは計22個の条約について違反の有無が記録されていますが、本事業ではIlias Chalkidisらの先行研究で最も回答精度が低かった第１３条について比較しました。

回答精度として、Ilias Chalkidisらの先行研究と同じF1スコアを比較しました。F1スコアは抽出結果の再現率と適合率のバランスの良さを0%～100%で定量化する指標で、正答とする全ての条約違反を漏れなく・誤りなく抽出した場合に100%をとります。

手法	回答精度	備考
既存手法	29.2	Ilias Chalkidisらの先行研究に記載の値。当時の世界最高値。ファインチューニングしたBERTを利用。
開発LLM	25.0	ナレッジグラフ推論LLM ver.2を利用。Zero-shot。

結果から、英語の法的判断予測では既存手法より回答精度が悪く、同様に実用には遠い性能であることがわかりました。マルチホップQA能力を強めたLLMでは、法的判断予測に必要な論理解決能力には至らないということであり、法的判断予測を強めるための工夫がさらに必要だと考えます。

日本語（短答式司法試験問題集）

短答式司法試験問題集は、日本国の法律・判例に基づいて正しい（または誤っている）記述の組み合わせを選択する問題集で、その正答と共に法務省が毎年公開しています。

タスクの説明

令和5年（2023年）の短答式司法試験問題集から、チェジョンミンらの先行研究*21にならい、各問題をLLMが回答しやすい二値の正誤判定タスクとして、各入力テキストを自動合成しました（法的判断予測では指示学習は実施しないため、出力テキストは必要ない）。

（以下の入出力例は、令和5年司法試験問題短答式試験問題集を改変したものです。）

サブタスク1. 正誤判定問題の構造化（グラフスキーマの生成）

正誤判定に関わる要素や条件をナレッジグラフとして構造化するように指示します。

入力テキスト

[INST]
Generate "Knowledge Graph" in RDF Turtle format based on the given "Source".
 
## Source
```txt
不在者の財産管理に関する次の記述につき，正か誤かで答えなさい。
　家庭裁判所が選任した不在者の財産の管理人は、相続人である不在者を代理してそれ以外の相続人との間で協議による遺産分割をするときは、家庭裁判所の許可を得なければならない？
```
 
## Strategy
Extract graph schema needed to answer the question in above "Source" as knowledge triples without omission.
[/INST]

出力テキストの実例

## Knowledge Graph Schema
```turtle
<#不在者>
    rel:has_manager <#管理人>;
    rel:has_manager_type <#相続人>.
<#管理人>
    rel:has_role <#代理>;
    rel:has_role <#遺産分割>.
<#遺産分割>
    rel:has_role <#家庭裁判所>;
    rel:has_role <#許可>.
<#Answer>
    rel:is <#Yes>;
    rel:when [
        <#家庭裁判所>
            rel:has_role <#許可>.
    ];
    rel:else <#No>.
```

サブタスク2. 最終回答の生成

ナレッジグラフから、正という判断なら'Yes'を、誤という判断なら'No'を回答するように指示します。

入力テキスト

[INST]
Explore "Knowledge Graph" entity-to-entity then finally answer "Question".
 
## Knowledge Graph
```turtle
<#不在者>
    rel:has_manager <#管理人>;
    rel:has_manager_type <#相続人>.
<#管理人>
    rel:has_role <#代理>;
    rel:has_role <#遺産分割>.
<#遺産分割>
    rel:has_role <#家庭裁判所>;
    rel:has_role <#許可>.
<#Answer>
    rel:is <#Yes>;
    rel:when [
        <#家庭裁判所>
            rel:has_role <#許可>.
    ];
    rel:else <#No>.
```
 
## Question
不在者の財産管理に関する次の記述につき，正か誤かで答えなさい。
　家庭裁判所が選任した不在者の財産の管理人は、相続人である不在者を代理してそれ以外の相続人との間で協議による遺産分割をするときは、家庭裁判所の許可を得なければならない？

## Strategy
Answer briefly in one line.
[/INST]

出力テキストの実例

## Explore Path
```path
不在者の財産管理に関する次の記述につき，正か誤かで答えなさい.
家庭裁判所が選任した不在者の財産の管理人は、相続人である不在者を代理してそれ以外の相続人との間で協議による遺産分割をするときは、家庭裁判所の許可を得なければならない.
Answer is Yes.
```
 
## Answer
```txt
yes
```

ベンチマーク

令和5年司法試験問題短答式試験問題集の各問題を二値の正誤判定タスクに変換した結果の全180問を対象に、ナレッジグラフ推論LLM ver.2と先行研究との回答精度をベンチマークしました。

回答精度として、チェジョンミンらの先行研究と同じ正解率を比較しました。

手法	回答精度	備考
既存手法	66.7	チェジョンミンらの先行研究に記載の値。当時の世界最高値。GPT-4でFew-shotプロンプティングを利用。
GPT-4	66.7	上記の既存手法と同じ。
GPT-3.5	57.2	チェジョンミンらの先行研究に記載の値。Few-shotプロンプティングを利用。
開発LLM	54.4	ナレッジグラフ推論LLM ver.2を利用。Zero-shot。

結果から、日本語の法的判断予測でも既存手法より回答精度が悪く、同様に実用には遠い性能であることがわかりました。法的判断予測を強めるための工夫は確実に必要ですが、この司法試験問題については開発LLMが同じトークン列を繰り返し出力するなどの不安定な振る舞いも多々見られたため、法律文書のような複雑な日本語文を取り扱うための基礎能力向上がさらに必要だと考えます。本事業では、継続事前学習において法律文書も学習データに含めていましたが、それだけでは法律文書を扱えるようにはなりませんでした。

本事業の研究開発成果

467億パラメータ相当の小さなLLMであっても、追加学習でナレッジグラフを使った論理推論に特化させることで、1兆～2兆パラメータを持つと推察されるGPT-4単体やGPT-4を用いた既存手法よりも、日本語マルチホップQAの回答精度が高くできることを実証しました。
- そのための追加学習方法、特にDecoder-onlyアーキテクチャのLLMにも適用可能な翻訳指示形式のナレッジグラフ対訳コーパスを使った継続事前学習方式と、マルチホップ推論のための3ステップの推論手順・タスク設計（プロンプト）を発明し、それらを一般に公開しました。
467億パラメータ相当の小さなLLMであっても、追加学習でナレッジグラフの生成に特化させることで、1兆～2兆パラメータを持つと推察されるGPT-4単体を優越しEncoder-Decoderアーキテクチャのモデルを使う既存手法に匹敵するほど、日本語文書レベル関係抽出の回答精度が高くできることを実証しました。
- そのための追加学習方法、文書レベル関係抽出のためのタスク設計（プロンプト）を改善し、それらを一般に公開しました。
- 従来から、GPT-3.5やGPT-4を含むDecoder-onlyアーキテクチャのLLMは、文書レベル関係抽出の精度がEncoder-DecoderアーキテクチャのLLMよりも悪いということが通説でしたが、本事業によって日本語に限ってはDecoder-onlyアーキテクチャのLLMでも世界最高レベルの精度を達成できることが新たに明らかになりました。

最後に

本事業の研究開発成果により、業務固有の文書を多数保有する組織がそれら文書のテキストから本事業と同様のタスク設計の指示学習データを構築し、本事業で開発した共通事前学習済みLLMを指示学習することで、その業務に効果的な論理推論処理を実現する特化型LLMを開発できるようになることが期待できます。

ただし、ベンチマーク結果の通り、本事業完了時点では英語のマルチホップQAと文書レベル関係抽出および、日英の法的判断予測では既存手法よりも回答精度が悪いため、それらの能力が要求される業務においては既存技術以上の適用効果は望めないでしょう。またどのベンチマークにおいても回答精度も 90%を超えないことから、現時点では基幹業務が求める準拠性・説明性は確保できていないと言えます。

そのため、本事業で得た知見と成功失敗事例を活かし、世界一の日本語性能を持つ「Takane」（2025年9月時点*22）をはじめ、当社では大規模言語モデルの開発技術の改善を今後も続けてまいります。*23