NTTドコモR&Dの技術ブログです。

トップ > AI・機械学習 > RAG精度向上を目指したCRAGコンペ上位解法の紹介

RAG精度向上を目指したCRAGコンペ上位解法の紹介

AI・機械学習 自然言語処理 論文・研究紹介 生成AI

TL;DR

はじめに

NTTドコモ クロステック開発部 鈴木明作です！

大規模言語モデル(Large Language Model:LLM)は目覚ましい進歩を遂げましたが、依然としてLLMが事実に基づかない回答を生成する、いわゆるハルシネーション(幻覚)は大きな課題となっています。 ここで、RAG(Retrieval Augmented Generation)は、LLMに外部情報を与えることで、ハルシネーションを軽減するアプローチです。

この記事では、KDDCUP 2024 (2024年3月20日~ 2024 年 6 月 20 日)として開催されたRAG精度向上を目指したCRAGコンペの上位1~3位の解法を紹介します。

CRAGとは

CRAG(Comprehensive RAG Benchmark)は、Metaが考案したRAGシステム評価のためのベンチマークです。 RAGシステムにおける多様な質問応答にどの程度正確に対応できるかを評価することができ、詳細は論文として公開されています。

CRAG データセットは、金融/スポーツ/音楽/映画/百科事典のオープンドメインを含む5つのドメインと、単純な質問/条件付き単純な質問/セット質問/比較質問/ 集計質問/マルチホップ質問/後処理質問/誤った前提の質問の8つの質問カテゴリにわたる多様な質問を包含しています。 また、他のRAGベンチマークと比較してWeb retrieval、KG(Knowledge Graph) search, Mock APIなどRAG検索も充実しています。

Metaの論文によると、CRAGデータセットにおいて、LLM単体での 正解率は最大34%しか得られず、単純なRAGを追加しても 44% であり、また、最新のRAGソリューション(Copilot Pro, Gemini Advanced等)を用いた場合でも正解率は 63%だったとのことです。

CRAGとその他のRAGベンチマークの比較

CRAGコンペ概要

CRAGコンペでは、3つのTaskで構成されており、それぞれ以下を外部情報として与えられた条件下で，RAGを用いて質問に回答する正確性を競うことで、RAG のイノベーション推進を目指すコンペです。

  • 1.質問と、質問に関連する5個のWebサイト
  • 2.質問と、質問に関連する5個のWebサイトと，質問に関連するナレッジグラフ(Mock API)
  • 3.質問と、質問に関連する50個のWebサイトと，質問に関連するナレッジグラフ(Mock API)

Metaが開催しているコンペということもあり、基本的にコンペ参加者はMetaが開発したLLMであるLlama(Meta-Llama-3-8B, Meta-Llama-3-70Bなど)を使う必要がありました。 Llama以外のモデルを使うことも可能ですが、その場合にはモデルのパラメータ サイズが1.5B 未満である必要があります。

コンペ主催者からベースラインコード(Starterkit）が提供されていて、最終的にはGithubからコードを提出します。

評価方法

  • CRAGコンペでは、自動評価と人間による評価 の両方を採用しています。
    • 自動評価: ルールベースのマッチングと GPT-4 を使用して、回答の正確性をチェックします。正解 (1 ポイント)、未回答 (0 ポイント)、不正解 (-1 ポイント) の 3 つのスコアが割り当てられます。
    • 人間による評価: 人間の評価者が、各回答を「完璧(1 ポイント)」、「許容可能(0.5 ポイント)」、「不足(0 ポイント)」、「不正解(-1 ポイント)」として評価します。最終的に、全体のスコアはすべてのドメインにわたるマクロ平均であり、質問はタイプの人気度とエンティティの人気度に基づいて重み付けされます (重みは公開されません)。
  • LLMによる回答には時間制限が設けられています（自動評価では 5 秒以内に始まる回答のみ採点され、トークンは50 個に切り捨てられます。長い回答の完全な評価は、人間による評価の段階で行われます)
  • 質問の種類には、LLMが過去の学習データからだけでは回答することができない質問（例:query:what company in the dow jones is the best performer today?、answer: salesforce）もあり、また、誤った前提の質問に対してはinvalid question、外部情報にも答えがない質問に対しては、I don’t know と回答することが期待されます。

CRAGコンペ上位1~3位の解法（Task1~3）

  • ここから本題の上位解法を紹介します。
  • CRAGコンペの上位解法はこちらで論文として公開されているため、その中からTask1~3の上位1~3位の解法を紹介します。
  • 論文タイトルと解法のユニークなポイントに絞って解法を箇条書きで記載していきます。

Winning Solution For Meta KDD Cup’ 24

  • Task1-3の全てで優勝したチームの解法です。論文ではTask1, Task2&3にわけて解法紹介されています。
  • 実装はGithubで公開されています　

Task1

  • 外部情報取得の2つのパス(1.Web検索パス, 2.Public Dataパス)を用意することで、精度高く外部情報を取得。
  • 最終的にはFine-tuningしたLLM(De-Hallucination Tuned LLM)に2つの経路からの情報を入力して回答を生成。

外部情報取得の2つのパス

  • 1.Web検索パスでは、2stage（検索、リランキング）で外部情報を取得（2stageでは、LLamaではなくパラメータサイズが小さいモデルである bge-base-en-v1.5 を利用）。
  • 2.Public Dataパスでは、CRAGコンペデータセットのドメイン（movieなど）に関する「公開データ(Public Data)」を用意して、RAGによる取得してコンテキスト情報と結合。

Fine-tuning

  • 概要:「コンテキストに関連事実がない場合は I don’t know、誤った前提に基づく質問にはinvalid question 」と回答するようにモデルをFine-tuningする。
  • ラベルを生成（gpt 4でアノテーション）：
    • まず、無効な質問として特定された質問については、invalid questionというラベルを設定する。
    • 次に、学習セットの各質問に対し、ベースモデルを使って回答を生成する。
    • 別のLLM（例: GPT-4）を用いて、その回答が正解かどうかを判定する。
    • 正解と判定されたものは、その質問の教師ラベルに「正解（元の正解）」を割り当てる。
    • 誤りと判定されたものに対しては、さらに「コンテキストからは正解が導けるか」を判定。正解が導けるなら正解ラベルを、そのコンテキストとして、回答不可能ならI don’t knowを割り当てる。
  • 学習：上記のラベル付きデータでLoRA (Low-Rank Adaptation) によりベースモデル（Llama-3-8B）をFine-tuning。
  • 結果：モデルの回答形式がより短く直接的なものになりやすく、ハルシネーションを抑制する。また、I don’t know と判定すべきケースや、前提が間違った前提を含む質問に対して invalid question を返せる。

Task2 & Task3

  • Task2とTask3では、ナレッジグラフ（Mock API）が利用でき、ナレッジグラフはWebページよりも信頼性の高い情報を提供できるため、 Task2ではナレッジグラフを用いて質問に対する正確な回答を提供し、Task3ではWeb検索とナレッジグラフを組み合わせて回答。
  • 「APIの正規化」と「パース」により、APIを汎用的に活用。
  • LLMによるAPI生成のために、LoRAを活用したFine-tuning。

APIの正規化（Regularized API）とパース（Parser）

APIの使いやすさを向上させるため、正規化されたAPIを設計。 従来のAPIは情報を取得しにくい構造だったため、SQL風のシンプルなAPI設計を導入。 この設計により、LLMがAPIを自動生成しやすくなり、API検索の精度が向上。

例：従来のAPIと正規化APIの比較

  • 従来のAPI（複雑で扱いが難しい）

    • get_movie_info(movie_name) -> { title, release_date, rating, genres, cast, crew }

  • 正規化API（シンプルで汎用性が高い）

    • get_movie("Inception")["release_date"]

    • get_movie_person_cast("Inception", "Leonardo DiCaprio")["role"]

例：質問に対するAPI生成の流れ

  • 質問：「walt beckerが監督した最新の映画は？」

  • LLMが生成したAPI：get_movie_person_crew(None, "Walt Becker", eq(job, "Director"))、sort(None, -year)["movie_name"]

  • APIの出力（パース後の結果）："Clifford the Big Red Dog"

  • 最終的なLLMの回答：「walt beckerの最新映画は 'Clifford the Big Red Dog' です。」

MARAGS: A Multi-Adapter System for Multi-Task Retrieval Augmented Generation Question Answering

  • Task1で2位、Task 2で3位となったチームの解法です。
  • RAGの4つの処理（Webpage Processing、API Call Generation、Candidate Ranking、Retrieval Augmented Generation)からなるパイプラインです。

API Call Generation

  • Task2,3のMock APIをうまく活用するためにLlama 3 8BのLoRaを活用し、適切なAPIエンドポイントと引数を予測できるようにFine-tuningを行う(LoRaのコンフィグはllama-recipes repository をベースとして参考)
  • Llama 3に最初の予測を行わせ、正解したAPIコールのみをターゲットラベルとする。
  • Llama 3による予測が失敗した場合は、人手で修正し、学習データのターゲットラベルに反映。
  • 正しく修正できない質問については、ターゲットラベルを「None」に設定。

Candidate Ranking

  • 以下の4つの手法を比較した結果、最も高い精度を示したクロスエンコーダー (ms-marco-MiniLM-L-6-v2) を使用。並列処理を導入し、30秒以内の処理時間制限にも対応。
  • ランキングの評価 はLlama 3 8Bのベースモデルを使用し、取得した候補を用いた際の精度を測定。LLMの生成結果をGPT-4oで評価し、正しい回答が含まれているかを確認。

Retrieval Augmented Generation

  • プロンプト設計:最初は「質問→コンテキスト→回答」の順番だったが、質問が埋もれる問題が発生。このため、「コンテキスト→質問→回答」の順番に変更することで改善。
  • LoRaによる最適化: タスクごとに個別のLoRaを学習し、最適な応答を生成。Task 1, Task 2, Task 3, APIコール生成の4種類のLoRa学習したモデルを用意。
  • ハルシネーション抑制のための「ターゲットリラベリング」:取得したコンテキストに正解が含まれていない場合、学習ターゲットを I don’t knowに変更（ターゲットリラベリング）。
  • 実験結果: LoRaの学習によりAccuracy(正解率)は向上したがハルシネーションが増加。一方で、「ターゲットリラベリング」を行うことで、既知の知識を過度に抑制(I don’t knowと答えてしまう)する副作用も確認されたが、ハルシネーションは改善。

A Hybrid RAG System with Comprehensive Enhancement on Complex Reasoning

  • Task 1で3位、Task 2では7種類の質問のうち5種類で1位を獲得した解法です。
  • 6つの主要モジュール（Web Page Processing、Attribute Predictor、Numerical Calculator、LLM Knowledge Extractor、Knowledge Graph Module、Reasoning Module、Handling Corner Cases）で構成されており、以下ではその中の4つを紹介します。
  • 実装はGithubで公開されています。

属性予測モジュール(Attribute Predictor)

  • 質問を以下の3つのカテゴリに分類して、適切な処理を選択することで、ハルシネーションを削減。
    • ドメイン分類: ファイナンス、スポーツ、音楽、映画、オープン
    • 質問タイプ: シンプル、条件付き、セット、比較、集約、マルチホップ、後処理、誤前提
    • 時系列分類: 静的（Static） vs 動的（Dynamic）（動的質問にはI don’t knowと回答）
  • 分類手法は、 LLM（Llama3-70B）を用いたIn-Context Learning（ICL）、SVM（サポートベクターマシン）を利用

数値計算モジュール (Numerical Calculator)

  • LLMが苦手とする数値計算の精度を向上させ計算ミスを防ぐため、計算処理をLLMではなく外部Pythonインタプリタにて実施
  • LLMに対して「計算ステップをPython式で出力する」ように指示し、計算ミスを最小化。

LLM知識抽出モジュール (LLM Knowledge Extractor)

  • LLMが外部情報を参照せず、内部パラメータに保存されている知識のみで回答できるようプロンプト設計(LLMの事前学習知識を活用)。
  • 推論能力を強化するため、「ステップバイステップで考えよう」という形式で回答させる、ゼロショットChain-of-Thought を導入。
  • LLMの知識を「参考情報の1つ」として利用し、過信しないように出力結果の制御。

推論モジュール (Reasoning Module)

  • プロンプトエンジニアリングとして、モデルに対して「中間推論結果を逐次出力」させるようにし、ハルシネーションを回避。

Revisiting the Solution of Meta KDD Cup 2024: CRAG

  • Task 2およびTask 3において、2位となった解法です。
  • 動的適応型のルーティングを導入して、質問分類ごとに処理を分けることで、ハルシネーションを抑止しています。
  • 実装はGitHubで公開されています。

ルーター（Router）

  • ドメイン ルーターと動的ルーターという 2 つのルーターを設計。
  • Llama3-8B-Instructをベースに、MLP (Multilayer Perceptron) を追加 してドメイン分類。
    • ドメインルーター: 質問のドメイン（金融、スポーツ、音楽、映画、オープンドメインの5 クラス分類子）を分類し、ドメインに応じて適切な処理を実施(例: 金融ドメインは Mock API のみ利用、オープンドメインはWebページのみ、利用など)
    • 動的ルーター: 質問の時間依存性（静的、緩慢な変化、急速な変化、リアルタイムの4 クラス分類器）を分類し、適切な処理を適用。
  • ルータ導入により、各ドメインに適したデータソース (Web検索 / Mock API) を使用できるため、不要な情報を削減し、検索結果の品質を向上。
    • 例: 金融・スポーツドメイン では、時間依存性の高いデータが求められるため、Web検索よりもMock APIの情報を優先することで、正確なデータを取得可能。

検索（Retrieval）

  • Web検索: HTMLページを解析し、BM25およびbge-m3エンコーダを用いた再ランキングを実施。
  • Mock API:Named Entity Recognition (NER) によるエンティティ識別、時間情報抽出、適切なAPIの選択を実施。　
    • 固有表現抽出 (Named Entity Recognition :NER) : Llama3-70B を使用して、質問内の名前エンティティを各ドメインに固有の定義済みカテゴリに分類。
    • エンティティ マッチ: 抽出されたエンティティを API 入力パラメータと一致させる (例: 金融 API の会社名をティッカー シンボルに変換)
    • 時間情報の抽出 : ユーザー入力から時間情報を抽出し、質問時間に基づいて相対時間を計算。
    • API 選択: 手動で設計されたルールを使用して、特定の質問に関連する API を選択。
    • Json から Markdown: API からの JSON 出力を Markdown 形式に変換し、LLM による処理を改善。

生成（Generation）

  • Chain-of-Thought（CoT）推論による複雑な問題への対応。
  • In-context Learning（少数ショット学習）により、誤った質問を特定し適切な回答を生成。
  • 後処理（Post-processing）により、ハルシネーションリスクの高い質問にはI don’t knowと回答

最後に

  • 上位チームは、RAGにおけるRetrival, Augmention, Generationの全ての処理フェーズで工夫が施されており、実務におけるRAGシステムでの精度改善に役立てられる手法も多くあると感じました。
  • 2025年に開催されているKDDCUP 2025では、マルチモーダルなCRAGコンペが開催されているため、そちらも興味があれば参照してみてください。