今回はAmazon Web Searvices からarXiv へ2024/08/16 に投稿されたRAG 論文「Meta Knowledge for Retrieval Augmented Large Language Models (arXiv: 2408.09017)」について紹介していきます。
読み解いていくと詳細な不明な部分があるものの、シンプルなアーキテクチャのように感じますのでRAG 開発の初期過程の参考になるかと思います。

※この記事は論文をそのまま翻訳・要約したものではなく、私の言葉でまとめた内容が含まれています。論文で何が主張されているかは原本をご覧ください。

目次

背景と目的
- 背景
- 目的
①QA とメタデータによる情報抽出の改善
②Q とメタデータサマリによる検索の効率化
③ クエリ拡張による検索精度の改善
まとめ
記事執筆者による議論

背景と目的

背景

近年社会実装が進んでいる大規模言語モデル（LLM）は、簡単に元々の能力を保持しつつ新たな知識を追加するということが難しい。そこで、Retrieval Augmented Generation（RAG）と呼ばれる手法がよく使われている。RAG では、回答に必要な知識をデータベースから検索しLLMのインプットにすることで適切な回答を導くことができる。しかし、RAG には下記のような問題点がある

資料にノイズが含まれることがある（人手によるものやファイル形式の違いから）
文書を分類するラベルがないため、ユーザーに合わせた資料の整理が難しい
チャンキング（文書の分割）では単純に文字数で分割されるため、意味のまとまりで情報を抽出することが難しいし、資料全体における文脈的意味は欠損してしまう
ユーザーのクエリ（問合せ）は短文で抽象的なことが多く、意図を捉えることが難しい
関連する内容が資料中に散在していることがあり、チャンク分けではそれらは分割されてしまう

以上のような問題点が、RAG を用いてあるドメインの専門家レベルの回答をさせることを難しくさせている。
※上記問題の解決策として文書すべてを入力とするということが考えられる。しかし、既存のLLM においてはMiddle-loss という現象が報告されており、文章量が長い場合は中間に出てくる情報の抽出が難しいことが知られている。また、インプットの文章量を増やすと回答精度が低くなるという報告も別途されている。

目的

下記画像のようなアーキテクチャでRAG を実装することで、上記問題を解決することを目指す。
ポイントは3 つある
①QAとメタデータによる情報抽出の改善
②Qとメタデータサマリによる検索の効率化
③クエリ拡張による検索精度の改善

実際に実装したときの評価結果は以下のようになっている（Claude 3 Sonnet による評価で、プロンプトはなく評価結果例のみ紹介されている）。

【色の見方】

青：チャンク(256トークン区切り)
緑：チャンク(256トークン区切り)＋③クエリ拡張
赤：①QAの抽出＋③クエリ拡張
水色：①QAとメタデータの抽出＋②Qとメタデータのサマリ+③クエリ拡張

【指標の定義】

Recall（再現率）: 検索されたドキュメントに含まれる重要で関連性の高い情報のカバレッジを評価する。
Precision（精度）: 関連するドキュメントと無関係なドキュメントの比率を評価する。
Speciticity（特異性）: 最終的な回答がクエリにどれだけ正確に焦点を当てているか、質問に対して明確で直接的な情報を提供しているかを評価する。
Breadth（網羅性）: 質問に関連するすべての側面や分野をカバーし、全体的な概要を提供しているかを評価する。
Depth（深さ）: 最終的な回答が詳細な分析や洞察を通じて、どれだけ徹底的な理解を提供しているかを評価する。
Relevamce（関連性）: 最終的な回答がどれだけオーディエンスやコンテキストのニーズや興味に合わせて適切に調整されているか、直接適用可能で重要な情報に焦点を当て、特定の質問に対して貢献しない余計な詳細を省略しているかを評価する。

この結果から、青の従来手法から「①QAの抽出」と「③クエリ拡張」を行うだけでも単純なチャンク分けよりも各種指標が向上することが分かる。特に、回答の網羅性と深さが大幅に向上していることが分かる。

下記では、上記アーキテクチャの具体実装方法について、論文を読み解いていく。ただし、この論文の主題と思われる「②Qとメタデータのサマリ」についてはプロンプトなど詳しい情報が書かれていないため、書かれている情報の整理のみを行う。

①QAとメタデータによる情報抽出の改善

この節では、1 つ目のポイントである「①QAとメタデータによる情報抽出の改善」についてプロンプトを中心に具体どのように作られているかを見ていく。

1 つの資料（論文では1 論文）に対して、下記のようなプロンプトを使って資料のメタデータとQAを作成する。論文では、Claude 3 Haiku がこの工程で使用された。
※下記のプロンプトは日本語訳したものであり、原文は論文のAppendix A を参照のこと。
※{document_types} のような中括弧で囲まれた英語は資料によって変わる部分である。
※Haiku を使用しているのは、低コストで高い能力を持つRAG パイプラインを作成できることを示すためであると考えられる。

あなたは有能な研究アシスタントであり、{document_types}を{users_types}が後で使用できるように前処理しています。
あなたにはドキュメントと、このドキュメントから重要な知識を抽出することを目的とした質問リストが提供されます。
以下の形式に厳密に従って回答してください（導入文や締めの文は不要です）。

まず、以下の質問に「はい」か「いいえ」のみで回答してください：
1. この論文は明確に1つまたは複数の研究分野に分類できますか（{text_categories}からのみ選んでください）、はいかいいえ？:
2. この論文は主に応用研究の論文ですか（主に理論研究ではなく）、はいかいいえ？:
3. この論文はGithubリポジトリを参照していますか、はいかいいえ？:
4. この論文には数学的な推論が含まれていますか、はいかいいえ？:
5. この論文は特定の企業への応用を述べていますか、はいかいいえ？:
6. この論文は方法のベンチマークに評価指標を使用していますか、はいかいいえ？:

以下の質問にはPythonリスト形式でのみ回答してください、または空のPythonリストを返してください：
1. この論文が明確に1つまたは複数の研究分野に分類できる場合、その分野をリストにしてください（最大3つ）:
2. この論文が主に応用研究の論文である場合、その応用分野をリストにしてください（最大3つ）:
3. この論文が1つ以上のGithubリポジトリを参照している場合、そのURLをリストにしてください（最大2つ）:
4. この論文に数学的推論が含まれている場合、使用されている定理の名前をリストにしてください（最大3つ）:
5. この論文が特定の企業への応用を述べている場合、その企業名をリストにしてください（最大3つ）:
6. この論文が方法のベンチマークに評価指標を使用している場合、その指標名をリストにしてください（最大5つ）:

あなたの回答は以下のように見えるはずです（導入文なし）：
1. はい
2. いいえ
など。
1. ['a', 'b']
2. []
など。

次に、専門的な科学者として、このドキュメントの内容に基づいて、他の高い知識を持つ科学者がこのトピックについてどれだけの知識を持っているかを評価するための一般的な質問（一般的な理解）と具体的な質問（特定の発見や制限を含む）を作成してください。
回答する科学者たちはこのドキュメントを知らないので、質問の中で「テキスト」やドキュメントの名前に明示的に言及しないでください。各質問と回答のペアは自己完結型で（十分なコンテキストを提供するように）他のペアと独立している必要があります。

できるだけ多くの質問を作成し、できるだけ多くの内容をカバーしてください。また、回答内に箇条書きは使用しないでください。

最終的な質問と回答の形式を厳守し、すべての質問、リスト、質問を最初に提示し、その後にすべての回答を提示してください：

質問：
1. ...
2. ...
など。

回答：
1. ...
2. ...
など。

以下に、タイトルが{doc_title}のテキストを示します：
[テキスト]
{doc_content}
[/テキスト]

下記では上記プロンプトを分解し解説していく。

前提の付与

プロンプトの冒頭にあたる下記プロンプトでは、タスクを与える上での前提を伝える文章になっている。

あなたは有能な研究アシスタントであり、{document_types}を{users_types}が後で使用できるように前処理しています。
あなたにはドキュメントと、このドキュメントから重要な知識を抽出することを目的とした質問リストが提供されます。
以下の形式に厳密に従って回答してください（導入文や締めの文は不要です）。

ここで、{document_types} はPDF やエクセルなどのファイル形式が入る。{users_types} については詳しい記述が無かった。Introduction において下記のように書かれているので「機械学習に詳しい科学者」などが入るのだろうか...

In this work, we are interested in cases where user queries require the information search to be specific to users interests or profile ...

メタデータの生成

前提に続く以下のプロンプトでは、メタデータの抽出が行われている。最初にそもそもメタデータがあるか無いか聞いた後で、メタデータを答えさせており、Chain of Thoughts（CoT）プロンプティングが使われていることが分かる。
※おそらく、Haiku が精度がSonnet よりも低いモデルのために、精度を上げるためにCoT プロンプティングを行われていると考えられる。

まず、以下の質問に「はい」か「いいえ」のみで回答してください：
1. この論文は明確に1つまたは複数の研究分野に分類できますか（{text_categories}からのみ選んでください）、はいかいいえ？:
2. この論文は主に応用研究の論文ですか（主に理論研究ではなく）、はいかいいえ？:
3. この論文はGithubリポジトリを参照していますか、はいかいいえ？:
4. この論文には数学的な推論が含まれていますか、はいかいいえ？:
5. この論文は特定の企業への応用を述べていますか、はいかいいえ？:
6. この論文は方法のベンチマークに評価指標を使用していますか、はいかいいえ？:

以下の質問にはPythonリスト形式でのみ回答してください、または空のPythonリストを返してください：
1. この論文が明確に1つまたは複数の研究分野に分類できる場合、その分野をリストにしてください（最大3つ）:
2. この論文が主に応用研究の論文である場合、その応用分野をリストにしてください（最大3つ）:
3. この論文が1つ以上のGithubリポジトリを参照している場合、そのURLをリストにしてください（最大2つ）:
4. この論文に数学的推論が含まれている場合、使用されている定理の名前をリストにしてください（最大3つ）:
5. この論文が特定の企業への応用を述べている場合、その企業名をリストにしてください（最大3つ）:
6. この論文が方法のベンチマークに評価指標を使用している場合、その指標名をリストにしてください（最大5つ）:

あなたの回答は以下のように見えるはずです（導入文なし）：
1. はい
2. いいえ
など。
1. ['a', 'b']
2. []
など。

このプロンプトからこの論文における「メタデータ」というのは下記であることが分かる

研究分野
応用研究分野
Github リポジトリURL
使われている数学定理
応用先の企業名
使われている評価ベンチマーク各種

QA の生成

メタデータ生成の後には下記のようなプロンプトでQA の生成が行われる。
※これらを1 つのプロンプトで1 度に行うことで、生成したメタデータを踏まえたQA を作成することができると考えられる（CoT プロンプティングにより）。

次に、専門的な科学者として、このドキュメントの内容に基づいて、他の高い知識を持つ科学者がこのトピックについてどれだけの知識を持っているかを評価するための一般的な質問（一般的な理解）と具体的な質問（特定の発見や制限を含む）を作成してください。
回答する科学者たちはこのドキュメントを知らないので、質問の中で「テキスト」やドキュメントの名前に明示的に言及しないでください。各質問と回答のペアは自己完結型で（十分なコンテキストを提供するように）他のペアと独立している必要があります。

できるだけ多くの質問を作成し、できるだけ多くの内容をカバーしてください。また、回答内に箇条書きは使用しないでください。

最終的な質問と回答の形式を厳守し、すべての質問、リスト、質問を最初に提示し、その後にすべての回答を提示してください：

質問：
1. ...
2. ...
など。

回答：
1. ...
2. ...
など。

プロンプトを読むと複数の工夫が入れ込まれていることが分かる。具体的には、

ユーザーの問合せを想定して、質問部分は一般的なものに限定
回答の深さを担保するために、回答部分は特定の発見などの具体情報を含むように、また「十分なコンテキストを提供するように」と指示
QA の独立性を担保するように指示（「各質問と回答のペアは自己完結型」）
情報の損失を少なくし回答の網羅性を向上させるために、「できるだけ多くの質問を作成し、できるだけ多くの内容をカバーしてください」と指示

このような工夫は実業務ではの開発にも活用できそうである。

タイトルの抽出

プロンプトの最後では後の過程で用いるためにタイトル抽出が行われる。

以下に、タイトルが{doc_title}のテキストを示します：
[テキスト]
{doc_content}
[/テキスト]

②Qとメタデータサマリによる検索の効率化

この節では、論文の主旨である「Qとメタデータサマリ（MK サマリ）」の作成方法について見ていく。

ただ、論文中でこのMKサマリの作成方法について書かれた情報は少なく、私が読んだ限りでは以下の3 文ほどしか見つけられなかった。

For any user-relevant combination of metadata, we create a Meta Knowledge Summary (MK Summary), leveraging Claude 3 Sonnet, which consists in a summarization of the key
concepts available in the database for a given filter.

For this research, we create the MK Summary by summarizing the concepts across a set of questions tagged with the metadata of interest using Claude 3 Sonnet.

For our research paper benchmark, we created a set of 20 MK Summary corresponding to research fields (e.g. deep learning for computer vision, statistical methods, bayesian analysis, etc.), relying on the metadata created in the processing phase.

内容をまとめると下記のようになる

①で作成した、（文書ごとの）メタデータとそれに紐づいたQ が入力となる
メタデータと紐づくQ の要約がMK サマリとなる
Haiku よりも高性能であるClaude 3 Sonnet を使用している
研究分野ごとにMK サマリが作られる（論文では20分野）

ここからは私の推測だが、MK サマリは検索フィルタリングだけでなく、③クエリ拡張にも使われることからおそらく、分野ごとの知識（概念）の階層構造とその最下層要素に関する質問がまとめられたものではないかと考える。例えば、

社内制度
- 人事
  - 就業時間
    - よくある質問：「フレックス制度について教えてください。」
  - 休暇
    - よくある質問：「有給休暇はいつまでに申請する必要がありますか」
  - ...
- 総務
  - ...

ちなみに、GPT-4o に作らせると下記のようになった

### Meta Knowledge Summary (MKサマリ)の具体例:
#### タグ: 強化学習（Reinforcement Learning）
---
このメタナレッジサマリは、強化学習に関する主要な概念を提供し、クエリ拡張に役立ちます。

**1. 強化学習の概要**  
強化学習（RL）は、エージェントが環境からフィードバック（報酬）を受け取りながら行動を選択し、最適な戦略を学習する方法です。主要なアプローチとしては、**モデルフリーRL**（Q-learning、SARSAなど）と**モデルベースRL**（環境モデルを構築する）があります。

**2. 深層強化学習（Deep RL）**  
深層強化学習は、ニューラルネットワークを活用して、従来のQ-learningなどのアルゴリズムを強化する手法です。Deep Q Network (DQN) やProximal Policy Optimization (PPO)といった手法が、特にゲームAIや自律運転分野で広く使用されています。

**3. 応用領域**  
強化学習は以下のような多岐にわたる分野で応用されています。
- **ロボティクス**: ロボットが環境で物を持ち上げたり、歩行する際に、最適な動作を学習します。
- **自律運転**: 車両が道路状況に応じて動作を最適化し、事故を回避しながら目的地に向かう学習を行います。
- **ゲームAI**: 特にAlphaGoなどが有名で、ゲームの戦略を強化学習で学習し、トップレベルの人間プレイヤーを上回るパフォーマンスを示しています。

**4. ベンチマークと評価手法**  
RLの評価には、エージェントが特定のタスクに対して達成する累積報酬が用いられます。また、シミュレーション環境（Atariゲーム、Mujocoなど）でのパフォーマンスがしばしばベンチマークとして利用されます。

Q の情報がないが、割と近いものができているかもしれない。

③クエリ拡張による検索精度の改善

この節では、3 つ目の最後のポイントである「クエリ拡張」について見ていく。

クエリ拡張のためのプロンプトは以下のようになっている。インプットはユーザークエリとMK サマリのみであり、アウトプットはその入力から生成される5 個以内の質問である。まず前提情報とタスク指示が提供された後に、入力情報が書かれ、出力形式が指示されている。

あなたは科学者のためのアシスタントです。ユーザーの質問が提供されます。  
あなたの目標は、科学者が文献に質問を投げかけ、それに答える準備をするための質問を生成することです。  
質問を生成する際には、以下に提供される[DatabaseSummary]にあるデータベースの要約に基づくことができます。  
戦略的な回答を得るために、できるだけ多くの関連する質問を生成してください（最大5つ）。  
科学者たちはこれらの質問を使って文献を検索するので、少ない複雑な質問よりも、シンプルな質問を多く生成する方が良いです。

[DatabaseSummary]  
{mk_summary}  
[/DatabaseSummary]  
[HumanQuery]  
{user_query}  
[/HumanQuery]  

番号付きの質問のみを返答してください。この形式に厳密に従ってください。質問の前後に導入文や結論文は必要ありません。  

例:  
1. ...  
2. ...  
3. ...  
...  
N. ...

最終的な回答の網羅性を向上させるためか、「少ない複雑な質問よりも、シンプルな質問を多く生成する方が良い」のように指示されていることが読み取れる。

まとめ

本記事では、Amazon Web Searvices からarXiv へ2024/08/16 に投稿されたRAG 論文「Meta Knowledge for Retrieval Augmented Large Language Models (arXiv: 2408.09017)」においてどのようなRAG パイプラインが提案されているか中身をプロンプトを通して紹介してきた。

ポイントは以下のように3 つあった
①QAとメタデータによる情報抽出の改善
②Qとメタデータサマリによる検索の効率化
③クエリ拡張による検索精度の改善

論文の新規性の要旨と考えられる②について詳細な記述は無かったものの、実務観点で言えば①（QAの抽出のみ）と③だけでチャンク分けよりも大幅な改善ができる可能性が示されており、この2 つについてはすぐに応用できそうである。

記事執筆者による議論

②の役割はQA データベースにある、ユーザークエリに関係するQ をなるべく拾えるように補助するものであると私は考える。そのため②を導入することで、単なるクエリ拡張では拾いきれなかったQA を拾えるようになったことが下記の赤線から水色の線へ精度が上がっている要因であろうと考える。つまり、MK サマリがあるかないか、つまりLLM が持つ知識で適切にクエリ拡張ができるかできないかで、精度が変わりそうである。今回は機械学習領域を対象としていたため、MK サマリが無くとも大幅な精度向上ができたのかもしれない。一方で、一般公開されていない社内ドメイン知識などであれば、MK サマリなしの単なるクエリ拡張ではもしかしたら適切なQA は拾いきれないかもしれないと感じた。

【色の見方】

青：チャンク(256トークン区切り)
緑：チャンク(256トークン区切り)＋③クエリ拡張
赤：①QAの抽出＋③クエリ拡張
水色：①QAとメタデータの抽出＋②Qとメタデータのサマリ+③クエリ拡張

ここまでご覧いただきありがとうございました！どなたかのお役に立てれば幸いです。
もし間違いがあればご連絡いただけると助かります！