Zenn
Closed4

[論文] RuleRAG: Rule-guided retrieval-augmented generation with language models for question answering

LLM
RAG
rulerag
kun432kun432

ここで知った

https://twitter.com/rohanpaul_ai/status/1861502379453207013

論文

https://arxiv.org/abs/2410.22353

Claude-3.5-sonnetによる落合プロンプトの結果

RuleRAG: 質問応答のためのルール誘導型検索拡張生成手法

1. どんなもの？

検索拡張生成(RAG)フレームワークの課題に対処する新しいアプローチを提案。従来のRAGは、クエリのみを考慮して文書を検索し、生成を行うため、検索の優先度や生成時の参照方法が明確でなかった。提案手法のRuleRAGには以下の2つのバリエーションがある：

  • 訓練不要のRuleRAG-ICL：

    • 具体例：「ジャン＝リュック・ゴダールの国籍は？」という質問に対して
    • ルール：「ある人物がある国で生まれた場合、その人物の国籍はその国である可能性が高い」を適用
    • 検索：生誕地に関する情報を優先的に検索
    • 生成：検索された生誕地の情報からルールに基づいて国籍を推論

  • fine-tuningを行うRuleRAG-FT：

    • 具体例：同じ質問に対して
    • 事前準備：生誕地と国籍の関係を含む多数の例からルールベースのfine-tuningを実施
    • 検索：訓練されたモデルが生誕地情報を含む文書を自動的に優先
    • 生成：ルールに基づく推論がモデルに組み込まれ、より正確な回答を生成

2. 先行研究を比べてどこがすごい？

従来のRAGフレームワークには以下の2つの主要な課題があった：

  • 検索コンポーネントの課題：
    • 教師なしテキストやend-to-endで訓練された検索器が、推論に必要な文を十分に取得できない
    • クエリに最も適切で有用な情報を必ずしも取得できない
  • 生成器の課題：
    • 検索された情報をどのように活用すべきかの明確な指示がない
    • 事前学習コーパスで明示的な事実関係の「指摘」や「監督」が不足

本研究の優位性：

  • 人間が自然に使用する論理的ルールを活用
  • ルールによって検索の方向性を明確に指定
  • 生成時の情報活用方法を明示的に指示

3. 技術や手法の肝はどこ？

核となる技術要素は以下の通り：

  • シンボリックルールの表現形式：
    • 「Entity1とEntity2の間にrelation1が成り立つならば、relation2も成り立つ」
  • 検索フェーズでのルール活用：
    • 意味的類似性だけでなく、論理的関連性に基づく文書検索
  • 生成フェーズでのルール活用：
    • 検索文書からの適切な情報抽出と回答生成
  • 2つの学習アプローチ：
    • RuleRAG-ICL：ルールをプロンプトとした文脈内学習
    • RuleRAG-FT：対照学習とinstruction-tuningを組み合わせたRule-guided Fine-Tuning

4. どうやって有効だと検証した？

評価用ベンチマーク：

  • 時間的シナリオ：RuleQA-I, RuleQA-Y, RuleQA-W
  • 静的シナリオ：RuleQA-F, RuleQA-N

各ベンチマークの構成要素：

  • ルールバンク
  • 文書コーパス
  • fine-tuning用データセット
  • テストクエリ

評価指標：

  • 検索性能：Recall@k
  • 生成性能：Exact Match(EM)とToken F1

検証の観点：

  • 複数の検索器（DPR, SimCSE, BM25）との組み合わせ
  • 複数の生成器（ChatGLM2, Mistral, LLAMA2）との組み合わせ
  • fine-tuningデータ量の影響
  • 未学習ルールへの一般化性能

5. 議論はある？

主要なエラーケースの分析：

  • ルールの失敗（5%）
    • 実世界での例外的なケース
  • 検索エラー（55%）
    • コーパスの大きさによる影響
    • 意味的に類似した文書の多さによる影響
  • 帰属エラー（40%）
    • 複雑な論理関係による生成の失敗

fine-tuningに関する知見：

  • ベンチマークの難しさによって学習曲線が異なる
  • RuleQA-Iが最も困難なベンチマーク

6. 次に読むべき論文は？

発展的な研究として以下の論文が推奨される：

  • "In-Context RALM" (Ram et al., 2023)
    • 検索拡張言語モデルの文脈内学習に関する研究
  • "CITADEL" (Li et al., 2023a)
    • 動的な語彙ルーティングによる効率的な検索に関する研究
  • "TLogic" (Liu et al., 2022)
    • 時間的知識グラフにおける説明可能なリンク予測に関する研究
kun432kun432

んー、いまいちピンとこないのでQA

Q: 検索と生成に分けて考えたいです。検索については、ルールを踏まえてquery rewritingするという理解でいいですか？

いいえ、RuleRAGの検索プロセスはquery rewritingとは異なるアプローチを取ります。
論文の図1と3節の説明によると、以下のような仕組みになっています：

  1. 標準的な検索：
    • クエリq: "ジャン＝リュック・ゴダールの国籍は？"
    • 文書内の単語レベルの類似性に基づいて検索
    • "ゴダール"や"国籍"という単語が含まれる文書を取得するだけ
  2. RuleRAGの検索：
    • クエリqとルールrを連結（q ◦ r）して検索
    • s(di, q ◦ r) = Ed(di) · Eq(q ◦ r) という形式で関連度を計算
      • Ed：文書エンコーダー
      • Eq：クエリエンコーダー
      • di：文書
    • 各ルールについて個別に検索を行い、結果を統合

つまり、クエリを書き換えるのではなく、クエリとルールを一緒にエンコードして意味空間で検索を行っています。これにより：

  1. RuleRAG-ICLの場合：
    • ルールを検索時の文脈として利用
    • ルールが示す論理的な関連性に基づいて文書をスコアリング
  2. RuleRAG-FTの場合：
    • 検索器自体をルールと教師データで微調整
    • ルールに基づく検索が検索器のパラメータに組み込まれる
      このアプローチの利点は：
    • クエリ書き換えよりも柔軟な検索が可能
    • 複数のルールを組み合わせやすい
    • fine-tuningによって検索性能を向上できる
Q: クエリqとルールrを連結（q ◦ r）して検索、というのは具体的にはどういう感時になりますか？

論文のFigure 1(b)の具体例を用いて説明します。

検索時の入力は以下のようになります：

  1. クエリq:
What is the nationality of Jean-Luc Godard?
  1. ルールr:
[Entity 1, born in, Entity 2] leads to [Entity 1, has nationality, Entity 2]
  1. 連結後(q ◦ r):
What is the nationality of Jean-Luc Godard? [Entity 1, born in, Entity 2] leads to [Entity 1, has >nationality, Entity 2]

このように連結された文字列が検索器に入力され、ベクトル化されます。検索器（DPRやSimCSEなど）はこの連結文字列全体を考慮して、文書との関連度を計算します。

この結果、論文の例では：

  • 単なる"nationality"や"Godard"という単語の一致ではなく
  • "Jean-Luc Godard was born in Paris, France"のような、生誕地に関する情報を含む文書が
  • 高いスコアで検索されるようになります

この手法の特徴は：

  1. シンプルな文字列連結で実装可能
  2. 既存の検索器アーキテクチャをそのまま利用可能
  3. 複数のルールがある場合は、各ルールごとに検索を行い結果を統合

ただし、論文では実装の詳細な部分（トークナイズの方法など）は明示されていません。

なるほど、それならクエリのコンテキストにセマンティックさが追加される気はしますね。とはいえ、そのルールを用意するのは大変ではないですか？

はい、その通りです。論文ではルールの取得方法について以下のように説明されています：

  1. ルールの取得方法：
    • 静的知識グラフと時間的知識グラフから自動的に抽出
    • 具体的には以下のアルゴリズムを使用：
      • 静的KG向け：AMIE3アルゴリズム
      • 時間的KG向け：TLogicアルゴリズム
    • 頻繁に共起する関係性からconfidenceの高いルールを抽出
    • 抽出したルールを自然言語形式に変換
  2. ルールバンクのサイズ（Table 1より）：
    • RuleQA-I：557ルール
    • RuleQA-Y：99ルール
    • RuleQA-W：78ルール
    • RuleQA-F：367ルール
    • RuleQA-N：234ルール

しかし、以下のような課題も残されています：

  1. ルールの質の保証：
    • 自動抽出されたルールの正確性や一般性の検証が必要
    • 例外的なケースへの対応（論文では5%のルール失敗が報告）
  2. ドメイン依存性：
    • 新しいドメインごとに知識グラフとルールの準備が必要
    • 知識グラフが存在しない/不完全なドメインでの適用が困難
  3. スケーラビリティ：
    • ルール数が増えると検索コストが増大（各ルールで個別に検索を実行）

これらの課題に対して、論文ではRuleRAG-FTによる未学習ルールへの一般化性能を示していますが、ルールの準備や管理に関する根本的な課題は今後の研究課題として残されているように見えます。

なるほど、、、

  • 人間が自然に使用する論理的ルールを活用
  • ルールによって検索の方向性を明確に指定

を明示的にやる感じってことかな。うーん、ドメインごとに前処理が必要にはなりそうだけど、うまくやれれば、字面だけじゃない暗黙のコンテキストを反映できる可能性はありそう。

Q: なるほど、この５つのルールバンクはどういう違いがあるのでしょうか？具体的な各ルールのサンプルも教えてほしいです。

論文のSection 2から、5つのベンチマークの違いを整理します：

  1. 時間的シナリオ（3つ）：
    • RuleQA-I (ICEWS14ベース)
      • 557ルール：最大のルールセット
      • 国際的な出来事や政治的関係に関するルール
      • 例：「[Entity1, 協力を要請する, Entity2] → [Entity1, 訪問する, Entity2]」
    • RuleQA-Y (YAGOベース)
      • 99ルール：比較的小規模
      • 歴史的な出来事や人物関係に関するルール
      • 時系列データが豊富
    • RuleQA-W (WIKIベース)
      • 78ルール：最小のルールセット
      • 一般的な事実や出来事に関するルール
      • Wikipediaの時系列データに基づく
  2. 静的シナリオ（2つ）：
    • RuleQA-F (FB15K-237ベース)
      • 367ルール：静的では最大
      • Freebaseからの一般的な知識関係
      • 例：「[Entity1, 生まれた場所, Entity2] → [Entity1, 国籍を持つ, Entity2]」
    • RuleQA-N (NELL-995ベース)
      • 234ルール
      • ウェブから学習した一般的な関係性
      • より多様なドメインの知識を含む

各データセットの特徴（Table 1より）：

データセット ルール数 文書数 検索学習用 生成学習用 テスト
RuleQA-I 557 77,508 6,594 7,440 1,559
RuleQA-Y 99 243,633 28,153 22,765 1,864
RuleQA-W 78 584,364 50,996 62,375 2,065
RuleQA-F 367 49,088 8,082 9,645 1,233
RuleQA-N 234 18,177 4,351 4,764 815

興味深い点として：

  1. ルール数と文書数に必ずしも相関がない
  2. 時間的シナリオの方が一般的により多くの学習データを持つ
  3. RuleQA-Iは多くのルールを持つが、比較的少ない文書で構成される

また、論文では特にRuleQA-Iが最も難しいベンチマークとされており、これは時間的な推論と多様なルールの組み合わせが必要とされるためと説明されています。

kun432kun432
Q: じゃあ次に生成について。生成時にこれらのルールはどういう風に活用されるのか具体的に説明して。

RuleRAGの生成プロセスについて、論文の3.1節とFigure 2を元に具体的に説明します。

生成時の入力は以下の3つの要素から構成されます：

  1. クエリq（質問）
  2. Rq（関連するルールのセット）
  3. Dq（検索された関連文書群）

具体例として、以下のケースを考えてみましょう：

# 入力
クエリq：
「ジャン＝リュック・ゴダールの国籍は？」

ルールRq：
「[実体1が 実体2で生まれた] ならば [実体1は 実体2の国籍を持つ可能性が高い]」

検索文書Dq：
「ジャン＝リュック・ゴダールはパリ、フランスで生まれた」
「ジャン＝リュック・ゴダールは映画監督として知られる」
...

生成時のプロンプト構成：

# INSTRUCTION
以下の質問に、提供された文書とルールを使って答えてください：

# 検索された文書：
[関連文書群を提示]

# 適用するルール：
[ルールを提示]

# 質問：
[質問を提示]

この構成により：

  1. 生成モデルは明示的にルールの存在を認識
  2. 検索文書からの情報抽出時にルールを参照基準として使用
  3. ルールに基づいて論理的な推論を行い回答を生成

RuleRAG-ICLとRuleRAG-FTの違い：

  1. RuleRAG-ICL：
    • ルールを含むプロンプトを直接使用
    • 文脈内学習でルールを適用
    • 追加学習なしで即座に利用可能
  2. RuleRAG-FT：
    • ルールと回答のペアで事前にfine-tuning
    • ルールに基づく推論がモデルのパラメータに組み込まれる
    • より安定した生成が可能

論文によると、このアプローチにより：

  • 検索された情報の中から関連する事実を適切に選択可能
  • ルールに基づいて論理的な推論を行える
  • 説明可能な回答生成が可能

結果として、標準的なRAGと比較して生成精度で+103.1%の向上を達成しています。

kun432kun432

ある特定のドメインにおける人間の暗黙的な「考え方」を「ルール」として明示的にする、それが単なるテキストだけではわからない背景のコンテキストを補完するって感じかな。
ある程度一般化ができるなら・・・というのはあるけど、果たしてどこまで一般化できるのか、一般化できないような特定ドメインの場合にはそれを作れるか、というところかなぁ。

前処理とか運用が大変そうというのが個人的な感想・・・

このスクラップは25日前にクローズされました