AI

RAGTruthとは何か?LLMのためのRAG向けハルシネーション評価データセットの概要と特徴を詳しく解説

目次

RAGTruthとは何か?LLMのためのRAG向けハルシネーション評価データセットの概要と特徴を詳しく解説

RAGTruth誕生の背景と目的:RAGにおけるハルシネーション問題への挑戦とデータセット開発の経緯

RAGTruthは、Retrieval-Augmented Generation(RAG、検索強化型生成)環境下でのLLM出力のハルシネーション(幻覚)を評価するために開発された大規模データセットです。RAGはLLMに外部知識を提供することで幻覚を減らす有望な手法ですが、それでもなおモデルは提供された資料にない主張をしたり矛盾する回答を生成してしまう課題が残っていました。こうした課題に対処し、RAG環境での幻覚の程度を客観的に測定できる評価基盤を作ることを目的に誕生したのがRAGTruthです。研究者たちは、高品質かつ大規模な評価データセットがなければ、幻覚低減策の効果を正確に比較検証することは難しいと考えました。そのため、RAGTruthでは実際のモデル応答を収集し、人手で精密に注釈を付けることで、RAGにおける幻覚の発生状況を可視化しようとしています。

RAGTruthデータセットの規模と内容:約1.8万件の応答と注釈に見る多様性とLLM間のカバレッジ

RAGTruthデータセットには、約1万8千件にも及ぶLLMの応答が収録されています。その規模は従来の幻覚評価データセットと比べても極めて大きく、応答数の多さが特徴です。収録された応答は多様なドメインタスクにまたがっており、日常的な質問応答からニュースの要約、構造化データの記述まで幅広い内容が含まれています。また、各応答はオープンソースのモデルから商用の最先端モデルまで、複数の異なるLLMによって生成されており、モデルごとの挙動の違いもデータセットに反映されています。実際、単一の情報ソース(質問や記事など)に対して6種類前後のLLMがそれぞれ回答を生成する形でデータを集めており、一つの問いに対する様々なモデルの出力を比較できるよう工夫されています。このようにRAGTruthは、量・質ともに豊富な応答データを備え、LLM間の挙動差異や多様な状況下での幻覚発生を網羅する内容となっています。

多様なLLMから生成された自然応答:オープンソースモデルからGPT-4まで多モデルの回答例を網羅

RAGTruthに収録された応答は、様々な種類の大規模言語モデル(LLM)から生成されています。例えば、Meta社のLlama2やMistralといったオープンソースのLLMから、OpenAIのGPT-4やChatGPTといった高性能なクローズドソースLLMまで、幅広いモデルが含まれています。各モデルには与えられた共通のコンテキスト(関連するドキュメントやデータ)が提示され、それに基づいて回答を生成しました。ポイントは、これらの応答が「自然に発生した幻覚」であることです。すなわち、開発者が意図的に間違った出力を作らせたのではなく、モデルが通常のプロンプトに従って答えた結果として生じた誤情報や不正確な記述が収録されています。これは実運用に近い形で幻覚が起きる状況を捉えているということであり、人工的に捏造された誤りではない分、現実の問題に即した評価が可能です。また一つのコンテキストに対し複数モデルの回答例があるため、「どのモデルがどの程度幻覚を起こしやすいか」「モデル間でどんな間違い方の違いがあるか」といった比較分析もできるようになっています。

単語レベルまでの精密な注釈:ケース単位の強度評価と語彙単位ラベル付与による詳細分析

RAGTruth最大の特徴の一つが、人手による精密なアノテーション(注釈付け)です。各応答にはまずケース全体として幻覚が含まれるか、その強度はどの程度かといった評価が行われています(応答単位の評価)。さらに、それだけに留まらず回答文中の具体的な語句レベルに踏み込んで、どの部分が幻覚に当たるのかを詳細にマーキングしています。アノテーター(人間のラベル付け担当者)は回答テキスト内の誤った情報やコンテキストと矛盾する記述を一つ一つ見つけ出し、その開始位置~終了位置を指定してハイライトしました。そして、それぞれの幻覚部分に対して「どのタイプの誤りか」をラベル付けしています。例えば、事実と明らかに食い違う部分には「明白な矛盾」、文脈にない情報の付加には「根拠のない情報の導入」といった具合にタグ付けがなされます(詳細は後述する4タイプ分類を参照)。さらに注釈には、なぜそれが幻覚と判断できるかといったコメント(メタ情報)も付与されており、例えば「元の文章には含まれていない地名を追加している」といった解説が書き込まれています。こうした二段階(応答全体と単語ごと)の注釈により、RAGTruthは単に正誤を判断するだけでなく、「どの部分が」「どの程度」誤っているかまで踏み込んで分析できるデータセットになっています。

RAGTruthの独自性と他データセットとの差異:自然発生ハルシネーションへの着目と大規模注釈による独自性

以上のような特徴から、RAGTruthは従来のRAG関連評価データセットとは一線を画しています。第一に、実際のモデル出力に基づく自然発生の幻覚を大量に集めている点が独特です。従来はモデルに無理やり矛盾する指示を与えて誤答を引き出す人工的なデータや、小規模な人手注釈コーパスが主流でした。しかしRAGTruthは、多様なモデルが日常的な問いに答える際に生じる幻覚をそのまま収集しており、よりリアルなエラー傾向を反映しています。第二に、注釈の丁寧さと粒度において突出しています。他のデータセットでは回答全体が正しいか否かをラベル付けする程度のものも多い中、RAGTruthでは前述の通り各誤りの種類や位置まで記録されています。この大規模かつ詳細な注釈により、モデルの幻覚挙動を分析する上で非常に豊かな情報を提供します。さらに、QA・データ記述・要約といった複数タスクを横断している点も特徴で、単一タスク特化のデータセットとは汎用性が異なります。総じてRAGTruthは、そのスケール、リアリティ、精密さにおいて他に類を見ない評価基盤と言え、RAGを用いたLLMの信頼性確保に向けた研究開発を強力に後押しする独自のデータセットとなっています。

RAGTruthデータセットの構成要素とは?その含まれるタスクの種類とアノテーションラベルを詳しく解説

RAGTruthに収録されたタスク一覧:質問応答・データ記述・ニュース要約など多領域を網羅しLLMの現実応用を想定

RAGTruthデータセットは、LLMが活用される代表的な3種類のタスクを幅広くカバーするよう設計されています。それらのタスクとは、①オープンドメインの質問応答(QA)②構造化データからの文章生成(データ記述、Data-to-Text)、そして③ニュース記事の要約(Summarization)です。これらは研究者によって「RAGで最も利用されるタスク」として選定されました【参考:研究論文】。例えばQAタスクでは日常生活に関する質問を用意し、RAGの文脈として関連する複数の文書(後述のように上位3件の検索結果など)を提供して、モデルに回答させています。データ記述タスクでは、Yelpオープンデータセットのレストラン情報など構造化データを入力として与え、モデルに客観的な店舗概要の文章を生成させました。さらにニュース要約では、CNN/DailyMailといったニュース記事本文を入力し、モデルに重要点をまとめさせる形式です。これら3タスクはいずれも実ビジネスでLLMが使われる典型例であり、RAGTruthは現実の応用シナリオを想定したデータセットと言えます。タスクごとに内容は異なりますが、すべて「コンテキスト(資料)+それに基づくモデル回答」の組み合わせになっており、多様な領域を網羅しつつもRAGという共通枠組みで幻覚現象を観測できる構成になっています。

各タスクにおけるデータ構造:質問文と検索文脈、構造化データ、記事本文など提供されるコンテキストの形式

RAGTruthに収録されるそれぞれのタスクでは、モデルに与えられるコンテキスト(文脈情報)の形式が異なります。質問応答タスクの場合、コンテキストはユーザーからの質問文と、その質問に答えるために検索で取得した関連文章群です。具体的には、研究者たちは日常的な質問を用意し、検索エンジンや知識ベースから上位3件程度の関連文章を取り出してコンテキストとしました【参考情報:研究設定】。モデルは「質問: …。以下の文章に基づいて答えてください: …」というプロンプトを受け取り、回答を生成します。一方、データ記述タスクではコンテキストとしてJSON形式の構造化データが与えられています。例えば飲食店の名前・住所・営業情報・設備(駐車場の有無やWiFiの有無など)と、補足情報として数件のユーザーレビュー文を含むJSONデータが提示され、モデルはそれに基づき店の概要説明文を書くよう求められました。ニュース要約タスクでは、コンテキストはそのまま一篇のニュース記事本文テキストです。モデルは記事内容を踏まえて主要なポイントを抜き出し短くまとめることが期待されます。このように、タスクごとにコンテキストのデータ形式は様々ですが、RAGTruthではどのタスクでも「与えられた情報を元に回答を生成する」というRAGの前提が守られています。各コンテキストはモデルにとって回答の拠り所となる情報源であり、幻覚(誤情報)は基本的にこの情報源にない内容や矛盾する内容として現れるため、その検出を容易にする工夫と言えます。

RAGTruthの注釈レベル:ケース全体評価と単語単位ラベルの二層構造で精密に記録

RAGTruthでは前述のように、モデル応答に対してケース(回答全体)レベルと単語(スパン)レベルの二層で注釈が付けられています。この二段階構造により、応答ごとの総合的な正確さ評価と、細部の誤り分析の両方が可能になっています。まずケース全体の評価では、その回答に幻覚が含まれるか否か、含まれる場合はどの程度深刻か(幻覚の強度)まで判断されています。例えば「軽微な誤りが一部あるが概ね合っている」や「主要な点で事実と異なる重大な誤りがある」といったレベル感が注釈として付与されています。また、ケースレベルでは回答全体の品質に関するメタ情報(例えば「不必要な拒否応答」や「途中で回答が打ち切られている(トランケート)」など)も記録されています。

次に単語レベルの注釈では、回答文中の具体的な幻覚箇所(誤情報のスパン)がハイライトされ、その範囲と内容が詳細に記録されています。注釈データには各スパンの開始位置・終了位置、スパン内のテキスト、そしてその幻覚の種類を示すラベルが含まれています。これにより「回答の〇〜〇番目の単語『…』は幻覚である」とピンポイントで特定できるのです。さらに各スパンごとに、人間アノテーターによるコメント(メモ)が付属し、「なぜそれが幻覚と判断されたか」「どういった誤り方をしているか」が説明されています。例えば「元文献に言及のない人物名を創作している」「数値が原文と食い違っており明確な矛盾」といった具合です。これらケース・単語の二層注釈は相互補完的で、ケースレベル注釈で回答全体の評価を把握しつつ、スパン注釈で具体的な問題箇所を洗い出すことができます。結果としてRAGTruthは、LLMの回答を俯瞰から詳細まで多角的に分析できる構成要素を備えています。

ハルシネーション判定のアノテーション基準:明白・微妙な逸脱を識別する統一ルールの策定

RAGTruthで人手注釈を行う際には、統一された判断基準が設けられました。複数のアノテーターがぶれなく幻覚部分を特定し種類を分類できるよう、事前に「どういった場合に幻覚とみなすか」「どのカテゴリに当てはめるか」の詳細なルールを策定しています。例えば、コンテキスト(提示資料)と直接矛盾する記述は「明白な矛盾」として扱う、コンテキストにはないが一般常識で正しいことをモデルが答えた場合は幻覚ではなく特別なタグ(implicit_true)を付ける、といったガイドラインです。また数値や人名のわずかな違いを見逃さず拾い上げること、逆に言い回しの違いで意味が通じていれば幻覚としないことなど、細かな判断基準も共有されました。こうしたルールのおかげで、注釈者間の判断の一貫性が保たれています。実際、各回答は2名の注釈者が独立にラベル付けし、その一致率は応答レベルで約92%、スパンレベルで約79%にも達したとの報告があります【参考:Cobus Greylingの解説】。意見の分かれたケースについては第三者の精査で最終決定するプロセスも取り入れ、データの信頼性を確保しています。このように明確な基準の下で注釈を行うことで、RAGTruthは再現性の高い客観的な幻覚判定データを提供することに成功しています。

アノテーションラベルの種類と意味:Evident ConflictやBaseless Infoなど各ラベルの定義と特徴

RAGTruthでは、各幻覚スパンに対して付与されるラベル(種類)が大きく4つのカテゴリーに分類されています。その内訳は、①「明白な矛盾 (Evident Conflict)」②「微妙な矛盾 (Subtle Conflict)」③「明白な根拠無き情報の導入 (Evident Introduction of Baseless Information)」④「微妙な根拠無き情報の導入 (Subtle Introduction of Baseless Information)」です。明白な矛盾とは、モデルの回答内容が提供されたコンテキストの事実と真っ向から食い違っている場合に付けられます。例えば本文中で「2010年に設立」とあるのにモデルが「2015年設立」と答えたようなケースで、誰が見ても間違いと断定できる類の誤りです。微妙な矛盾は、一見すると間違いに気づきにくい巧妙な齟齬に対して付けられます。例えば「深刻な批判を受けた」というべきところを「非難された程度だ」と回答してしまいニュアンスが軽重逆転している場合など、文脈の意味合いを変えてしまう微妙な逸脱が該当します。明白な根拠無き情報の導入は、コンテキストに書かれていない事実無根の情報をモデルが付け足した場合です。典型例は、元の資料に登場しない人物名や地名をモデルが勝手に創作して述べてしまうケースで、証拠が全くない情報の追加です。最後の微妙な根拠無き情報の導入は、モデルが暗黙の推測や一般知識に基づいてそれらしい情報を補ってしまった場合に付与されます。例えば「このレストランは家族連れにも人気だろう」といった主観的な付加情報や、コンテキストにないものの常識的にはありそうな要素を勝手に述べてしまうようなケースです。これら4種のラベル定義により、幻覚の性質の違いが明確化され、解析や対策の際に「どのタイプの誤りが多いのか」「どのタイプに対応しづらいのか」といった切り口で検討できるようになっています。

なぜRAGTruthがRAG評価に重要なのか?その役割と意義を多角的に考察

RAGシステムに残るハルシネーション課題:既存の対策と評価法の限界

RAGTruthが登場した背景には、RAGを導入してもなお完全には解決できていないハルシネーション問題があります。RAG(検索強化型生成)によりモデルに関連知識を与えることで幻覚はある程度減少すると期待されましたが、実際にはコンテキストにない情報をモデルが作り出してしまうケースは依然として発生しています。従来、この問題に対処するために様々なアプローチが取られてきました。例えば、モデルの出力をルールベースでチェックし既知の誤りパターンを弾く方法や、事実照合システムで回答内容を検証する方法、あるいはLLM自身に回答の正しさを評価させる(自己評価: LLM-as-a-Judge)方法などです。しかしこれら従来手法にはそれぞれ限界がありました。ルールベースや検索照合は、柔軟な言い回しでの誤りや新たなタイプの幻覚を検出しにくく、LLMによる評価は出力が安定しなかったり別の誤りを含む可能性があります。さらには、肝心の「何をもって幻覚とするか」の定義自体が統一されておらず、評価方法ごとに基準が異なるという課題もありました。このようにRAGシステムにおける幻覚検出・評価には従来法の限界があり、信頼性向上にはより客観的で網羅的な評価基盤が求められていたのです。

高品質な評価データセットがもたらす信頼性向上:RAGTruthによる定量的評価の意義

そこで登場したRAGTruthは、LLMの幻覚問題に取り組む上で飛躍的な信頼性向上をもたらす可能性を秘めています。高品質な評価データセットが存在する意義は、モデルや対策手法の性能を定量的かつ客観的に評価できる点にあります。RAGTruthのように多様な状況下での幻覚事例が網羅され、人手で正解ラベルが付けられていれば、新たなモデルをテストした際に「どれだけ幻覚を起こさないか」を数値で測ることができます。それまで曖昧だった幻覚の頻度や深刻度が、PrecisionやRecall、F1スコアといった評価指標によって可視化されるため、モデル改良の効果検証が容易になります。これはモデル開発者にとって非常に重要で、改善策を講じた結果、本当に幻覚が減ったのかをエビデンスに基づき判断できるようになるのです。また、RAGTruth自体が多様なモデル出力を含むため、あるモデルAとモデルBの幻覚耐性の比較といった用途にも使えます。例えば「オープンソースのLlama2とGPT-4では、与えた知識を逸脱せず答えられる率にどれほど差があるか」を公平な条件下で測定できます。このようにRAGTruthは、LLMの幻覚問題に対する共通の評価基盤を提供することで、研究コミュニティ全体の議論や進歩を加速させ、ひいてはより信頼できるAIシステムの構築に寄与すると期待されます。

人手注釈による客観的指標:LLM評価のバイアス解消とRAGTruthの役割

RAGTruthの価値は、人手による客観的な評価指標をもたらした点にもあります。前節で触れたように、これまでLLMの幻覚を評価する際には、しばしばモデル自身や別のAIに判定させる手法(LLM-as-a-Judge)が用いられてきました。しかし、モデルに評価を任せると評価基準がブラックボックスになりがちで、人間の価値観やタスクの文脈に即した細やかな判断ができない場合があります。例えばモデルは事実誤りには厳しい評価を下すものの、微妙なニュアンスの逸脱や情報の過不足については適切に評価できないかもしれません。またモデル評価自体が間違ったり、一貫性を欠いたりするリスク(評価のバイアス)もあります。これに対しRAGTruthは、人間が一件一件検証して幻覚の有無・種類をラベリングしたデータですから、その評価基準が明確で統一されています。人間の厳密なチェックによって担保された評価指標は、モデルから独立しているためバイアスの傾向を分析しやすく、信頼性も高いものです。この人手注釈データを基準にすれば、モデルの出力を評価する際にAI特有の偏りを排除し、より公正な比較ができます。要するにRAGTruthは、LLM評価における「ものさし」を人間の手でしっかり作り上げた点に意義があり、曖昧だった幻覚評価を客観的事実に基づく指標へと格上げしたと言えるでしょう。

開発サイクルへのインパクト:RAGTruthを用いたモデル改善フィードバックループ

高品質な評価データセットは、モデル開発サイクルにも大きな影響を与えます。RAGTruthを活用することで、モデル改善のフィードバックループを構築しやすくなります。具体的には、まず現在のモデルをRAGTruthで評価し幻覚発生のパターンや弱点を洗い出します。その結果に基づいてモデルの改良方針(例えば追加のファインチューニングやプロンプト手法の見直し)を立て、モデルをアップデートします。次に再度RAGTruth評価を実施して改善具合を定量確認し、必要に応じてさらなる対策を講じる——という一連の流れが確立できます。このPDCAサイクル(Plan-Do-Check-Act)の「Check(評価)」部分にRAGTruthがあることで、各イテレーションの成果を明確に測定でき、効率的な改善が可能になります。また、RAGTruthには幻覚の種類や原因に関する情報も含まれるため、「どのタイプの誤りを優先的に減らすべきか」といった施策のヒントも得られます。例えば結果を分析して「明白な矛盾はほぼ解消したが、微妙な情報付加がまだ残っている」と分かれば、それに対応するデータ補強や対策を集中的に行うことができます。このようにRAGTruthは、モデル開発のPDCAに組み込むことで継続的な性能向上をデータドリブンに進める原動力となり、RAGシステム全体の洗練に貢献します。

安全性・信頼性確保への貢献:実システムにおけるRAGTruthの価値

最終的に、RAGTruthの重要性はLLMシステムの安全性・信頼性確保という観点で語ることができます。企業やユーザがLLMを実システムで利用する際、幻覚による誤情報提供は大きなリスクとなります。特に医療や法律、金融などの分野では、事実と異なる回答は甚大な被害を生む恐れがあります。RAGTruthは、このリスクを軽減するための評価・検証ツールとして役立ちます。例えば、新たに開発した社内向けのRAGベースQAシステムがあるとしましょう。そのシステムをリリースする前にRAGTruthで事前評価すれば、どれくらい幻覚が混入しうるか、どういった誤情報が出やすいかを把握できます。問題が見つかれば対処してから展開でき、予防措置になります。また運用中も、RAGTruthの一部を定期的に用いたモニタリング(例えば一定数の問い合わせごとに評価セットを流して結果をチェックする)を行うことで、性能劣化や想定外の幻覚増加を早期に検知できます。さらに、RAGTruthを使って訓練した幻覚検出モデルをシステムに組み込めば、リアルタイムで危うい回答に警告を発することも可能です。このようにRAGTruthは、研究面だけでなく実世界のLLM活用において信頼性の担保・向上に寄与する土台となり、なぜ重要かという問いに対する答えは「安全で正確なAIシステムを実現する鍵だから」と言えるでしょう。

RAGTruthを用いたハルシネーション検出の仕組み:評価データセットが果たす役割と活用方法を詳しく解説

RAGTruth活用によるハルシネーション検出フローの全貌:データ投入から判定まで

RAGTruthは幻覚検出のアルゴリズム開発や評価プロセスにおいて中心的な役割を果たします。その活用フローを概観すると、まずRAGTruthデータを用いて幻覚検出モデルやルールの訓練・調整を行い、その後に実際のLLM応答へ適用して幻覚を判定する、という流れになります。具体的には、RAGTruthの訓練データ(注釈付き応答)をアルゴリズムに入力し、「どんな特徴があると幻覚が起きているか」を学習させます。このアルゴリズムは機械学習モデルであればパラメータの最適化という形で、ルールベースであればしきい値やパターンマッチングの基準調整という形で、RAGTruthから知見を吸収します。次に、未知のLLM応答(現実のユーザ問いに対する回答など)に対し、訓練済みの検出アルゴリズムを適用します。アルゴリズムは回答とその参照コンテキストを入力として受け取り、内部でRAGTruth由来の基準と照らし合わせながら「この回答は幻覚を含むか?」を判定します。その出力は例えばブーリアンの真偽やスコア(幻覚の可能性点数)だったり、あるいはRAGTruth同様に具体的な誤り箇所のハイライトかもしれません。このようにRAGTruthを活用した検出フローでは、学習(Training)と判定(Inference)の2段階でデータセットが使われ、それによって人手基準に基づいた自動幻覚判定が可能になります。最終的に、人間が行っていた注釈作業の一部を機械が肩代わりする形で、現実のLLM出力に対する幻覚チェック体制を構築できるわけです。

評価データでモデルをチューニング:RAGTruthを用いたファインチューニング手法とその効果

上記の流れの中で特に重要なのが、RAGTruthを用いたモデルのファインチューニングです。ファインチューニングとは、既存のモデルに追加訓練を施して特定タスクに適応させる手法です。研究チームは、オープンなLLM(例えばLlama2-13Bなど)にRAGTruthの訓練データを学習させることで、幻覚検出専用のモデルを作り上げました。その結果、GPT-4などの最新LLMにプロンプトで判定させる方法に匹敵する精度を達成したと報告されています【参考:論文】。これは極めて興味深い成果です。従来、高性能な幻覚検出には高コストなGPT-4等を用いるLLMジャッジが有力視されていましたが、RAGTruthを使って比較的小型のモデルを適切にチューニングすれば、同等の性能を自前で持つことが可能だと示されたのです。ファインチューニングに際しては、RAGTruthの各データ(質問+コンテキスト+回答+注釈)を入力とし、モデルに「この回答のどこが幻覚か」を当てさせるよう訓練します。具体的にはモデル出力として幻覚スパンにタグを振るタスクや、回答全体を正しい/幻覚ありで分類するタスクに変換して学習させます。モデルは大量の注釈データを見ることで、幻覚のパターン(例えば「出力がソースにない固有名詞を含むと幻覚の可能性大」等)を内部的に獲得していきます。こうして鍛えられたモデルは、新しい入力に対しても高い再現率・適合率で幻覚を検出できるようになります。要するに、RAGTruthという評価データを教師として用いるファインチューニングによって、幻覚検出に特化した強力なモデルを構築できるということです。

人手評価データを機械判定に活かす:教師あり学習でハルシネーション検知精度向上

RAGTruthの活用はファインチューニングに留まらず、幅広い教師あり学習の文脈で幻覚検知精度の向上に貢献します。教師あり学習とは、人間がラベル付けしたデータ(教師データ)を使ってモデルを訓練する手法で、RAGTruthはまさに高品質な教師データの集合です。RAGTruthが登場する以前、幻覚検知モデルの学習には十分な規模の教師データが不足していました。そのため、やむなくモデルの自己判断(自己教師)やルールベースに頼らざるを得ない場面も多かったのです。しかしRAGTruthが提供されたことで、状況は一変しました。十分な量と多様性を持つ人手ラベルデータを使って素直にモデルを学習させれば、検知精度が大きく改善することが確認されたのです。特に微妙な幻覚(コンテキストの意味を変えるような言い換えや、常識に基づく誤情報)といった検出が難しいケースでも、人間の判断基準が組み込まれた教師データがあればモデルはより正確にパターンを掴めます。例えば、「数字の一致不一致」「固有名詞の有無」「強調表現の違い」といった要素をモデルが重視するよう学習できます。こうした学習の結果、機械判定の網羅性・信頼性が飛躍的に高まったと考えられます。つまりRAGTruthは、人手評価の知見を機械に伝える架け橋となり、教師あり学習の力で幻覚検知性能を底上げするキーデータとして機能しているのです。

RAGTruthベースの検出モデル構築例:Llama2微調整でGPT-4相当の性能を達成

実際の事例として、研究チームはLlama2-13Bという130億パラメータ規模のオープンソースLLMをRAGTruthでファインチューニングし、幻覚検出モデルを構築しました。その性能は驚くべきもので、従来最高峰とみなされていたGPT-4による幻覚判定(プロンプトベース)に匹敵するスコアを達成したと言います【参考:論文結果】。具体的な数値は精度(Precision)・再現率(Recall)・F1スコアで比較されましたが、ファインチューニングしたLlama2検出器はGPT-4ジャッジにほぼ肉薄、場合によっては上回るほどの精度を示しました。この成果は、データ駆動アプローチの有効性を如実に物語っています。つまり「優れた評価データさえあれば、小さなモデルでも大きなモデルに負けない検出力を持ち得る」ということです。Llama2はGPT-4に比べモデル規模・性能共に劣ると考えられていましたが、RAGTruthという適切な教師データで訓練することで幻覚検出という特定タスクにおいて肩を並べることが可能になりました。これは実用面でも朗報で、高価なAPIコール(GPT-4を毎回呼び出す等)に頼らずとも、自前で動作する幻覚検出モデルを運用できることを示唆します。RAGTruthベースの検出モデル構築例は、データセットの威力と、モデルのポテンシャルを引き出すファインチューニング技術の重要性を教えてくれる成功例と言えるでしょう。

評価データの組み込みでシステム改善:RAGTruthが果たす役割と運用上の利点

RAGTruthを用いた幻覚検出の仕組みをシステム全体の観点から見ると、その役割と利点がより明確になります。まず、RAGTruth由来の検出モデルや評価基準をシステムに組み込むことで、LLMの出力品質を常時監視・制御することが容易になります。例えば、ユーザへ回答を返す前に検出モデルがその回答をチェックし、幻覚の疑いが高い場合には警告を出したり回答を差し替えたりする運用が考えられます。これにより、ユーザが誤情報を受け取るリスクを低減できます。またRAGTruthの評価指標をKPIとして設定し、運用中のシステム改善を図ることもできます。具体的には、例えば「幻覚検出のF1スコア90%以上を維持する」といった目標を持ち、モデルアップデート時やデータ追加時にこの指標が悪化しないか確認するのです。RAGTruthがあることで、こうした品質管理が数値に基づいてできるようになります。さらに運用上の利点としては、問題発生時の解析がしやすい点も挙げられます。もしシステムが誤った回答を出してしまった場合でも、RAGTruth的な観点で「それはどのタイプの幻覚だったか」「どの部分が間違っていたか」を検証すれば、原因究明と再発防止策を講じやすくなります。このようにRAGTruthを組み込んだ幻覚検出フレームワークは、システムの信頼性を高めつつ、改善サイクルを回す上でも実践的なメリットをもたらすのです。

RAGTruthで評価されるハルシネーションの種類:4つのタイプを具体例と共に徹底解説

明白な矛盾(Evident Conflict):提供情報と正反対の誤情報例とその特徴

「明白な矛盾 (Evident Conflict)」は、モデルの回答内容が提供されたコンテキスト情報と真っ向から矛盾しているケースを指します。このタイプの幻覚は、比較的発見しやすく、誰が見ても明らかな誤りです。具体例として、コンテキストに「2010年に設立された会社」と書いてあるのに、モデルが「この会社は2015年に設立されました」と答えた場合などが当てはまります。年号や人数、名称などの事実が資料中の記述と食い違っているため、一読すれば間違いと判明します。他にも、「原文で肯定されている事柄をモデルが否定して述べる」「AとBが逆転している」といったケースも明白な矛盾です。例えば元の記事が「X氏は昨年ノーベル賞を受賞した」と明記しているのに、回答が「X氏はノーベル賞を受賞していない」と断言する場合です。このようなEvident Conflictタイプの幻覚は、特徴として表面的な照合で検出可能な点が挙げられます。言い換えれば、該当部分をコンテキストと突き合わせればすぐに不一致が分かるため、人間・機械を問わず比較的扱いやすい誤りと言えます。RAGTruthでもこうした明白な矛盾はしっかりラベル付けされており、多くの場合数字や固有名詞の不一致、事実関係の取り違えとして報告されています。

微妙な矛盾(Subtle Conflict):文脈を歪める巧妙な改ざんの例と検出の難しさ

「微妙な矛盾 (Subtle Conflict)」は、一見しただけでは分かりにくい巧妙な文脈のすれ違いに分類される幻覚です。このタイプでは、モデルの回答は一部コンテキストと食い違っているものの、明白な誤数字や名前間違いのように簡単に指摘できない場合が多いです。具体例を挙げると、原文には「その製品は多少の不具合が見られた」とあるのに、モデルは「深刻な欠陥が見られた」と回答したケースです。一言で言えばニュアンスや程度のすり替えであり、元の意味合いが微妙に変えられてしまっています。他には、原文が「AとBは関連がない」と述べているのに、回答が「AとBは多少関連がある可能性がある」と示唆するようなケースも考えられます。このようにSubtle Conflictでは、文章全体としてはもっともらしく見えつつ、実は重要なポイントで事実とは異なるニュアンスになっているのが特徴です。検出の難しさはここにあり、人間でも注意深く読まないと気づけない場合があります。単語レベルでは違う表現でも文脈上は大きな差となるような、いわば「行間」での矛盾が潜んでいるのです。機械的なチェックでは見逃されやすく、高度な理解が必要なため、RAGTruthでのラベル付けや評価が特に重要になるタイプです。Subtle Conflictが多数発生するモデルは、より精緻な理解や忠実性向上が求められると言えるでしょう。

明白な事実無根の情報追加(Evident Introduction of Baseless Info):文脈外の新情報を付加した例と影響

「明白な事実無根の情報追加 (Evident Introduction of Baseless Information)」は、モデルがコンテキストに全く存在しない新たな情報をでっち上げて回答に含めてしまった場合を指します。このタイプの幻覚は、言わば根拠ゼロの創作であり、追加された情報が不適切かつ明らかに確認不能なものです。具体例として、与えられた資料に出てこない人物名や地名をモデルが勝手に盛り込むケースが典型です。たとえば原文に「そのイベントはヨーロッパ各国で開催された」としかないのに、モデル回答が「そのイベントはフランス・ドイツ・スペインなどヨーロッパ各国で開催された」と具体的国名を挙げてしまう場合です。列挙された国名は一見もっともらしいですが、元情報には無かったためモデルの創作と判断できます。その他、「新製品の価格」に関する質問で、資料に価格情報が無いにも関わらずモデルが「価格は$999です」と断定するようなケースも明白な根拠無き情報追加です。このタイプの幻覚はその名の通り明白で、追加された事実にエビデンスがないことが容易にわかります。影響としては、ユーザがその虚偽の詳細情報を信じてしまう可能性があり、特に具体的な数字や固有名詞だと誤解を生みやすいです。RAGTruthではこうしたケースに対して「Evident Baseless Info」ラベルが付与され、注釈コメントには「オリジナルには記載のない情報を導入している」といった指摘がなされています。

微妙な事実無根の情報追加(Subtle Introduction of Baseless Info):推測や暗黙知による付加情報の例と検出ポイント

「微妙な事実無根の情報追加 (Subtle Introduction of Baseless Information)」は、モデルがコンテキストに書かれていないことを推測で補完したり、暗黙の知識を付け足したりするケースです。明白な場合と異なり、その追加情報自体は一見すると突飛ではなく、むしろ「そうかもしれない」と思わせる微妙な内容であることが多いです。例えば、元のデータに料理店の営業時間が載っていないにも関わらず、モデルが「この店は週末も営業しています」と述べる場合です。週末営業は一般的にはありそうですが、資料に明示されていないため検証不能です。また、レビューに「子供連れ客が多い」とは書いてないのに、モデルが「この店は家族連れにも人気です」と言及するケースも挙げられます。元情報にない主観的・推測的な情報をあたかも事実のように付け加えてしまうのがこのタイプです。Subtle Baseless Infoの検出ポイントは、その付加情報が資料から本当に導けるかどうかを見極めることです。人間でも「まぁそうだろう」と思ってしまいがちな常識的推測が含まれるため、見過ごしやすいですが、厳密には幻覚と言えます。RAGTruthにおいても、このタイプの幻覚はしっかりマークされています。ラベル付け者は「暗黙知による補足」「コンテキストに根拠の無い推定」といったコメントを残し、モデルが勝手に補完した部分を指摘しています。このカテゴリーは、モデルが自信ありげにもっともらしい嘘をつく典型例とも言え、現実で誤情報が紛れ込む厄介なケースだけに、注意深い検出が求められます。

4タイプ分類の意義:各ハルシネーション種別に応じた対策と検出ポイント

以上の4種類のハルシネーション分類には、それぞれ異なる対策と検出上のポイントが存在します。この分類を設けた意義は、幻覚にも様々な形態があり、一律の方法ではなくタイプに応じた対処が必要であると示すことにあります。例えば「明白な矛盾」はパターンマッチや検索照合で検出しやすいため、対策としては回答とソースを突き合わせるアルゴリズムが有効でしょう。一方「微妙な矛盾」は文脈理解が不可欠なので、高度な言語モデルによる精査や、人間によるレビューが依然重要となるかもしれません。「明白な事実無根情報追加」に対しては、回答内の固有名詞や数字を一度ソースと照合し、出典のない情報を弾くフィルタリングが考えられます。これに対し「微妙な情報追加」は、常識知との境界線に位置するため、モデルに余計な推測をさせないプロンプト設計(例えば「与えられた情報以外は答えに含めるな」と指示する)や、検出モデルでの詳細チェックが必要です。RAGTruthで4タイプそれぞれの事例が蓄積されたことで、研究者や開発者はどのタイプの幻覚が自分のシステムで多発しているかを分析できます。そして弱点となっているタイプに絞った対策(追加のデータ収集やモデル改良)を講じることができます。要するに、この分類は単なる整理ではなく、幻覚問題へのアプローチを精緻化する道しるべです。RAGTruthに沿って各種別ごとの検出精度を評価すれば、どの領域に改善の余地があるか明確になります。そうした洞察を得る上でも、4タイプ分類は非常に有意義な枠組みと言えるでしょう。

RAGTruthを使ったベンチマーク結果と評価指標(Precision/Recall/F1など)から見える課題

主要LLMに対するハルシネーション頻度の比較:RAGTruthが明らかにした性能差

RAGTruthを用いたベンチマークによって、各種LLMのハルシネーション頻度の違いが初めて包括的に比較されました。データセットにはGPT-4やChatGPT、Llama2、Mistralなど様々なモデルの出力が含まれていますが、これらを人手注釈基準で評価することで、どのモデルがどの程度幻覚を起こしにくいかが定量化されました。例えば、OpenAIのGPT-4はRAG環境下で幻覚発生率が極めて低く、提示された文脈に忠実な回答を生成する傾向が確認されました。一方で、小型のオープンソースモデルやチューニングが不十分なモデルほど、文脈にない情報を補ってしまったり矛盾した内容を出力したりする頻度が高いことも明らかになりました。具体的な数値としては(仮の例ですが)、GPT-4の幻覚含有率が数%程度だったのに対し、ある7億〜70億規模のパラメータモデルでは20〜30%の回答に何らかの幻覚が含まれる、といった差異が観測されたとのことです【参考:論文の結果概要】。RAGTruthによる比較分析は、モデル選定や運用において貴重な指針を与えます。つまり「信頼性重視なら現状GPT-4が優位だ」「オープンモデルを使うなら幻覚検出との組み合わせが必須だ」といった判断がデータに基づき可能になるわけです。このように、RAGTruthが明らかにした性能差は、単なる学術的興味に留まらず、実践面でもLLMの性能評価と選択基準に影響を及ぼす重要な知見となりました。

既存検出手法の評価結果:Precision/Recallで見る強みと弱み

RAGTruthはまた、既存の幻覚検出手法を客観的に評価するベンチマークとしても機能しました。従来提案されている様々な検出アプローチ(例えば、前述のRAGASのような自動評価指標、LLMによる自己評価、ペア比較法など)を、RAGTruthの注釈データに照らして精度検証したのです。その結果、各手法のPrecision(適合率)Recall(再現率)が算出され、それぞれの強みと弱みが浮き彫りになりました。例えば、LLMにCoT(Chain-of-Thought)推論させて判断させるG-Evalのような手法は、比較的高いRecallを示しました。つまり幻覚を見逃しにくく、多くの誤りを検出できる傾向にありました。しかし一方で、正しくない箇所まで幻覚と誤判定してしまうことも多く、Precisionは低めだったと報告されています。逆に、回答内の事実を文献と照合するFaithfulnessスコアなどの手法はPrecisionは高い(誤検知は少ない)が、微妙な逸脱を見逃すケースが多くRecallが低い、といった結果になりました【参考:Cleanlabのベンチマーク結果】。このようにRAGTruthは、各検出法を共通の土俵で比較することで、「どの手法がどんなエラーに強く、どんなエラーに弱いか」を示してくれました。これらの知見は新しい検出手法の改良にも役立ち、例えば「高いRecallを維持しつつPrecisionを上げるにはどうすべきか」といった課題設定が明確になります。

RAGTruthで計測した検出モデルのF1スコア:全体精度と誤検知のバランス分析

幻覚検出の性能を総合的に判断する指標として、F1スコアもRAGTruth評価で重視されました。F1はPrecisionとRecallの調和平均であり、検出モデルの全体的な有用性を示す尺度です。RAGTruth上で様々な検出モデル・手法のF1が比較された結果、前述の通りLlama2ベースのファインチューニングモデルやGPT-4ジャッジが高いF1を叩き出した一方、単純なベースライン手法のF1は低く、検出漏れか誤検知のどちらか、あるいは双方の問題を抱えていることが分かりました。具体例としてある従来手法XはPrecision 0.8/Recall 0.5程度でF1が約0.61、一方ファインチューニングモデルYはPrecision 0.75/Recall 0.75でF1が0.75、といった具合です(値は概念説明用)。このF1の差は、実運用での有用性の差でもあります。F1が低いモデルは、幻覚を見逃したり逆に誤報警戒しすぎて正しい回答を誤フラグしてしまったりするため、信頼して任せるには難があります。高F1のモデルはバランス良く検出できており、現場導入にも適しています。RAGTruthがあったからこそ、こうした検出モデルの全体力を数値で比較検討できました。ただし、一口にF1が高いと言っても、その内訳(Precision/Recallのバランス)を見ることが重要です。例えばあるモデルはPrecisionもRecallも7〜8割でF1が高いのに対し、別のモデルはPrecision 9割/Recall 6割でF1は7割台という場合、運用上の性質が異なります。前者は安定したオールラウンダー、後者は誤警報が少ないが見逃しが多いタイプです。RAGTruth評価ではそのあたりのバランス分析も可能になり、単純なスコア競争に留まらない細かなモデル特性の議論が行えるようになりました。

評価結果から浮かび上がった課題:False Positive/False Negativeの要因と改善可能性

RAGTruthを用いたベンチマーク結果からは、幻覚検出に関する残る課題も明確になりました。特に議論されたのは、False Positive(誤検知)とFalse Negative(見逃し)の原因です。例えば、検出モデルがFalse Positiveを出すケースとして、「コンテキストには無いが事実としては正しい情報」を幻覚と誤って判定してしまう問題が指摘されました。RAGTruthではこれに対応するためimplicit_trueというメタタグが導入されていましたが、モデルにはそれが難しく、結果として本当は正しい記述まで誤報扱いすることがあります。またFalse Negativeの例としては、「微妙な矛盾」や「微妙な情報追加」の検出漏れが挙げられます。これらは判断が難しいため、モデルが見逃してしまいがちです。さらに、コンテキスト自体が不完全でモデルが推測を交えた場合に、それを幻覚とみなすかどうかの線引きも課題となりました。評価者間でも意見が割れたケースがあるように、境界事例の扱いは自動検出でも難しいのです。こうした課題に対し、RAGTruthの結果分析は改善の糸口を示しています。例えばFalse Positiveを減らすには、モデルに「幻覚ではないがソースに無い情報」を識別させる追加タグの学習が必要かもしれませんし、False Negativeを減らすには、微妙なケースをもっと含んだ訓練データの拡充が有効かもしれません。RAGTruthから得られたエラーパターンの知見は、このように次の改良ステップを具体化する助けとなっています。

精度指標の限界と現実的な判断基準:数値が示さない背景を読み解く

最後に、RAGTruthで得られたPrecision/Recall/F1といった精度指標を見る中で浮かび上がったのは、数値指標だけでは捉えきれない評価の難しさです。例えばF1スコアが多少高いモデルでも、出力結果を人間が確認すると「この誤りは捕捉できていないのか」と意外な盲点が見つかることがあります。逆にスコア上劣るモデルでも、一部の重要な誤りタイプに関しては全く見逃しが無かったりと、評価軸によって印象が変わる場合もあります。要するに、単一の指標で良し悪しを判断するのは危険であり、定性的な分析やタスク重要度に応じた基準も考慮しなければなりません。RAGTruthは詳細な注釈付きデータを持つため、検出モデルがミスした具体例を容易に洗い出せます。数字の差に現れない質的な違い——例えば「モデルAは重要事実の矛盾は必ず捉えるが、枝葉の誤りをよく見逃す」「モデルBは軽微な誤りも検出するが、そのせいで冤罪も増えがち」といった背景——を読み解くことができます。現実のシステムでは、ユースケースに応じて何を重視するか(重大な幻覚の防止か、とにかく幻覚皆無にすることか等)の判断基準が異なるため、評価結果もそれに沿って解釈する必要があります。RAGTruthにより私たちは、多面的なデータに基づいて評価指標を総合的に判断する視点を得ました。結局のところ、数値は客観的指標として重要ですが、それを正しく意味付けして活用するためには、データの中身を深く理解することが不可欠だという教訓が得られたのです。

RAGTruthとLLM-as-a-Judgeや従来手法との比較:データ駆動型アプローチの有効性を徹底検証

ルールベース・情報照合型検出法の例:従来アプローチの概要と課題

まず、RAGTruth以前から存在した従来型の幻覚検出アプローチにはどのようなものがあったかを振り返ります。典型的なのはルールベースの方法で、これはモデルの回答文に対して特定のパターンやキーワードを検知し、怪しい場合は警告を出すものです。例えば「〜と思われます」「〜かもしれません」といった曖昧な表現が含まれる場合に信頼性低下とみなす、あるいは回答中の名詞が提示資料中に一つも出現しなければ幻覚の疑いとするといったルールを設定します。またもう一つは情報照合型(ファクトチェック型)の方法で、回答の主要な事実を検索エンジン等で再検索し、出てこない場合は幻覚と判断する、あるいは回答内の各文をソース文献と比較して矛盾が無いか検証する、といったアプローチです。これら従来手法は実装が容易で一部の問題に有効でしたが、課題も多くありました。ルールベースでは未知の表現や複雑な文脈変化に対応できず、単純なif-thenルールをすり抜ける幻覚表現が後を絶ちませんでした。照合型では、モデル回答がうまく言い換えられていると検出できなかったり、そもそも検索や照合自体が完璧ではないため漏れが生じました。またルールや検索では、モデルが「答えようとして間違えた」のか「嘘を生成した」のかの意図区別までは困難です。総じて、従来アプローチは精度の限界とカバー範囲の限界があり、RAGTruthのような包括的データに照らすと、かなりの幻覚ケースが見逃されていたことが分かっています。

LLM-as-a-Judge手法の特徴と限界:人間評価エミュレーションの課題

次に、近年注目されていたLLM-as-a-Judge(大規模言語モデル自身による評価)手法について見てみます。これはChatGPTやGPT-4のような高性能LLMに対し、「この回答は質問と与えられた情報に照らして正しいか?」といった評価タスクを与え、モデル自身に他のモデルの回答を採点させるアイデアです。LLMは文章理解力が高いため、人間の評価者に近い判断を下せるのではないかと期待されました。実際、この手法は一部の研究で人間評価と高い相関を示すという報告もあり、特に迅速に大量の回答を評価できる点は魅力的でした。しかし限界も顕在化しています。まず、LLMジャッジは絶対的な正解を知っているわけではないため、与えられた情報内に答えが無い場合に誤った判断を下すことがあります。たとえばGPT-4ですら、巧妙な誤情報に騙されたり、自信ありげに誤判定をすることが完全には防げません。また、モデルが書いた回答をモデルが評価するという構図上、出力の癖や偏りが評価にも影響してしまう可能性があります。さらに、LLM-as-a-Judgeの評価基準はプロンプトに依存するため、人間の基準と完全一致させるのは難しく、評価内容の説明責任(なぜそう判断したか)がブラックボックスになりがちです。こうした課題から、LLMジャッジ単独で幻覚を完全に見抜くのは困難であり、人間の厳密な注釈に匹敵する信頼性を得るには不安が残ると考えられています。

データセット駆動アプローチの強み:RAGTruth活用による客観的評価と検出精度向上

それに対し、データセット駆動型アプローチ(データ中心主義)の強みがRAGTruthの登場によって明確になりました。このアプローチでは、人手で作成した大量の評価データ(RAGTruth)に基づいてモデルを訓練したり検証したりします。強みの第一は、評価基準がデータとして明示されているため客観性と再現性が高いことです。誰が実行しても同じ結果になる評価セットがあることで、公平なモデル比較ができます。第二の強みは、ファインチューニングの項で述べたように、小〜中規模モデルでも十分なデータがあれば高性能な検出器を作れる点です。データが質・量ともに揃っていることで、モデルは幻覚検出の複雑なパターンを学習でき、GPT-4等に頼らずとも高い精度を発揮できます。第三に、データ駆動であればエラー分析が容易で、継続的な改善サイクルを回せる点も見逃せません。間違えたケースのデータを追加で注釈して再学習させる、というように、モデルが誤る度にデータを充実させていくことで、理論上無限に性能向上を図れます。これはルールベースが個別対応に追われがちなのと対照的です。以上のように、RAGTruthを活用したデータセット駆動型アプローチは、幻覚検出の分野に客観的で強力な解決策を提示しました。人間の知見をまとめたデータセットを中心に据えることで、従来法の弱点を補い、LLMジャッジの不確実性をも克服する道が開けたのです。

RAGTruthで明らかになった手法間の性能差:エラー検出率の比較と分析

実際にRAGTruthを用いて、従来手法・LLMジャッジ・データ駆動型モデルの三者を比較した結果、明確な性能差が確認されました。前述したように、ルールベースや単純な照合は高精度とは言えず、LLMジャッジは善戦するものの完全ではない、という状況の中、RAGTruthで訓練したモデルは総合的に最も優れた検出率を示しました。例えばある検証では、RAGTruthファインチューニングモデルが幻覚スパン検出でF1スコア0.75を記録したのに対し、LLMジャッジは0.70、ルールベースは0.50未満だったといったデータが報告されています【仮想データ例】。また、エラータイプ別に見ても、データ駆動モデルは明白な誤りから微妙な誤りまでバランス良く検出できているのに対し、LLMジャッジは微妙なケースでの見逃しがやや多い、ルールベースは明白なケース以外ほぼ対応できていない、という分析結果も得られました。これらの比較から分かるのは、包括的なデータを用いたモデル学習がいかに強力かということです。RAGTruthで網羅的に鍛えられたモデルは、個別のトリックに頼ることなく幅広い幻覚を捕捉できています。一方、LLMジャッジはモデルの持つ一般知識に依存しているためか、一部の巧妙な幻覚を見落とす傾向が残りました。ルールベースは言わずもがな、限界が明白でした。総じてRAGTruthが示した手法間性能差は、今後の方針として「データを制する者が幻覚検出を制す」ことを強調する結果となりました。

ハイブリッド活用の可能性:LLMジャッジとRAGTruthデータの相互補完による相乗効果

もっとも、LLM-as-a-Judgeや従来手法が全く不要になったというわけではありません。RAGTruthを基盤としつつ、他の手法とハイブリッドに活用することでさらなる相乗効果も期待できます。例えば、RAGTruthで訓練した検出モデルをファーストフィルターとし、微妙なケースだけをGPT-4のようなLLMジャッジに回す、といった二段構えのシステムです。これにより大半の単純な幻覚は自動モデルが処理し、難しい判断は大規模モデルが人間さながらに検討するため、精度とコストのバランスが取れます。また、LLMジャッジのフィードバックを逆にRAGTruthデータにフィードして強化することも考えられます。GPT-4に評価させた結果を参考に、人間が見落とした幻覚を追加注釈する、といったループです。このように互いの長所を補い合う形で運用すれば、システム全体としてより堅牢になるでしょう。さらに、ルールベースも完全に廃れるわけではなく、例えば明白な矛盾を見つけたら即座に回答をリジェクトするような安全装置的ルールは依然有用です。総じて、RAGTruthによってデータ駆動型のアプローチが軸足となったものの、LLMジャッジやルールも適材適所で組み合わせれば最高の結果が得られる可能性があります。重要なのは、RAGTruthという客観的指標を土台に据え、複数手法を評価・統合しながらシステムを設計することです。その意味で、RAGTruthは単独で有用なだけでなく、他手法との協働においても指針と基準を提供する中核的存在だと言えるでしょう。

RAGTruthを活用したモデル学習・運用フロー:ハルシネーション低減に向けた実践的活用法を徹底解説

RAGTruth導入によるモデル開発手順:データ前処理から学習・評価までの流れ

RAGTruthを現場で活用するにあたり、モデル開発の具体的な手順は次のようになります。まず、データ前処理の段階では、RAGTruthコーパスから自社システムに関連するタスクやドメインのデータを抽出します。例えば自社がQAシステムを開発中なら、RAGTruth内のQAタスク部分を重点的に選び出すといった具合です。次に、抽出した注釈データをモデルが学習しやすい形式に整形します。多くの場合、質問・コンテキスト・回答・ラベルをセットにして機械学習用データセットとするでしょう。ラベルとは回答内の幻覚スパン位置や種類、あるいは回答全体の正誤タグです。整形の際、一部形式はmodel.add_linear_constraint(x + y <= 10)のようにコード内でルール化したり、テンソルデータに変換したりします。

準備ができたらモデル学習に入ります。ここでは例えば、Transformerベースの分類モデルやシーケンスタグ付けモデルにRAGTruthデータを与え、幻覚検出タスクで訓練します。現実には数エポックにわたりGPU上で学習させ、開発セットでのPrecision/Recallが十分高くなるようハイパーパラメータを調整します。モデル学習後、RAGTruthのテストセットを用いてモデル評価を行います。ここで得られる各種指標(Precision/Recall/F1、タイプ別精度など)を確認し、必要ならモデルアーキテクチャの見直しや追加学習を実施します。良好な評価結果が得られたなら、モデル開発フェーズは完了です。

次にデプロイ前の最終チェックとして、RAGTruthに含まれない社内固有の検証データがあればそれでも試験します。例えば社内FAQの回答で幻覚が出ないか人手で確認するなどです。問題なければ本番環境へモデルを組み込みます。この際、モデル単体だけでなくシステム全体のフローを考慮します。ユーザーから質問が来たら検索で文脈取得→LLM回答生成→検出モデルでチェック→必要に応じて修正 or フラグ付け、といった一連のパイプラインを構築します。

最後に運用に入りますが、運用中もRAGTruthは役立ちます。定期的に本番システムに対しRAGTruthの質問を投げてみて、きちんと幻覚が抑制されているかモニタリングするのです。こうして、データ前処理→学習→評価→展開→モニタリングまで、一貫してRAGTruthを活用したモデル開発フローが完成します。

ハルシネーション検出モデルの訓練:RAGTruthを用いた教師あり学習と検証方法

先述のフローの中で中心となるハルシネーション検出モデルの訓練について、もう少し詳しく解説します。RAGTruthを用いる場合、その訓練は教師あり学習の典型です。たとえば、あるLLM回答に対し「幻覚あり/なし」を二値分類するモデルを作るなら、RAGTruthの注釈からその回答が幻覚を含むかどうかのラベルを取得します(少しでも幻覚スパンがあれば「あり」とする等)。それを全訓練データに適用してラベル付きデータセットを構築し、BERTやRoBERTaなどの分類モデルに学習させます。また、どの部分が幻覚かを特定するシーケンスラベリングモデルを訓練するなら、RAGTruthのスパン注釈をBIOタグ(B=開始、I=内部、O=非幻覚)形式に変換して各単語にラベルを割り振り、モデルに学習させます。

訓練に際して重要なのは、モデルがコンテキストも入力として考慮できるようにすることです。幻覚判定は回答文だけ見ても困難で、出典情報との突合せが必要だからです。そのため、訓練時には質問+コンテキスト+回答をセットでモデルに与え、例えばTransformerのエンコーダーに「[質問][コンテキスト][回答]」のシーケンスを入力し、回答部分に対応するラベルを出力する、といった工夫をします。こうすることでモデルは回答とコンテキストの関係性を学習し、「コンテキストに無い情報を回答が含んでいればラベル=幻覚」といったルールを自動で獲得します。

訓練後の検証方法としては、まずRAGTruthの分割しておいた検証セット・テストセットで前述のPrecision/Recallなどを算出します。さらに、可能であれば人間がモデルの判定結果をサンプリングして目視チェックすることも有用です。自動評価指標で良くても、見てみると「このケースは検出すべきなのに見逃している」等の気づきが得られる場合があるからです。また、訓練中にバリデーションデータでのスコア推移を監視し、過学習していないか(例えば特定モデルの癖だけ捉えて汎用性能を損なっていないか)確認するのもポイントです。以上のようにRAGTruthによる教師あり訓練と多角的な検証を経て、高品質な幻覚検出モデルが出来上がります。

継続的学習とモニタリング:運用環境でのRAGTruth活用による性能維持

モデルを本番運用した後も、RAGTruthは継続的学習とモニタリングに活かせます。LLMの環境は時間と共に変化し、モデルの性能も劣化したり新種の幻覚が発生する可能性があります。そこで、RAGTruthを定期的に用いて性能をチェックし、必要に応じてモデルを再訓練(継続学習)します。例えば毎月、RAGTruthテストセットで検出モデルのF1を計測し、もし基準値を下回るようであれば直近の対話ログ等から新たな幻覚事例を抽出・注釈してRAGTruthデータを拡充、モデルに追加学習させるといった運用です。このプロセスにより、モデルは環境変化や新しいユーザ質問パターンにも適応を続け、性能を維持できます。

またモニタリング面では、RAGTruthのサブセットをカナリアテストのように使うこともできます。これは、システム稼働中に定期的に既知の質問を投げ、期待通り幻覚が出ないか確認する方法です。RAGTruthには人手評価結果があるため、実際のモデル回答を比較すればすぐに異常を検知できます。たとえば、ある質問に対し以前は正しく答えていたのに、ある時期から幻覚混じりの回答をするようになった、といった変化があれば、モデルやデータの何らかの変化を疑うことができます。モニタリングにより早期に問題兆候を掴み、対処することで、大きな事故(ユーザへの誤情報提供)が起こる前に手を打てます。

このようにRAGTruthはモデル稼働後も性能維持と品質保証のツールとして役立ちます。継続学習でモデルの鮮度を保ち、モニタリングで信頼性をチェックする——データ駆動の利点を運用フェーズにも活かし、常に低幻覚率をキープする仕組みが構築できるのです。

人間フィードバックとの連携:RAGTruth注釈手法を組み込んだ改善サイクル

RAGTruthの運用活用において、人間のフィードバックとの連携も極めて重要です。RAGTruth自体、人間注釈者の努力によって構築されましたが、運用フェーズでも新たな幻覚が見つかれば都度人間が評価・注釈を行い、それをデータセットに反映させることでモデルをアップデートするというサイクルが考えられます。このような人間を交えた継続的学習(Active Learning的手法)により、システムは時間とともにより頑健になっていきます。

具体例として、モデルが検出し損ねた幻覚がユーザ報告などで発覚した場合、そのケースをRAGTruthの形式にならって注釈し、新たな学習サンプルとして追加します。そして次回モデル再訓練時に含めれば、その種のミスは今後減るでしょう。また、LLMから見てグレーゾーンのケースでモデルが自信を持てなかった場合、人間が判定してあげてデータを補強する、という形もあります。たとえば検出モデルが「70%の確率で幻覚あり」と不確かなときに人が判断し、その結果を教師データにするやり方です。

このように人間フィードバックを反映することで、RAGTruthのデータ自体も徐々に進化していくことができます。初期RAGTruthでは網羅できなかった特殊なドメインや表現も、運用からのフィードバックを取り込むことでカバー範囲が広がります。その結果、モデルも一層賢くなり、ユーザとの信頼関係も深まります。最終的には、人間とデータとモデルが三位一体となって幻覚低減に取り組む体制が築かれ、RAGTruthが目指した「信頼できるRAGモデル」の実現に近づいていくでしょう。

現場でのハルシネーション低減策:RAGTruthに基づくアラートとフォローアップ

実運用の現場では、RAGTruth由来のモデルやデータを活用した具体的な幻覚低減策がいくつか考案されています。まず、一つはアラートシステムの導入です。前述の検出モデルを用いて、もしモデル回答に幻覚の兆候があれば即座に管理者やユーザに知らせる仕組みを組み込みます。例えばチャットボットが答えを返す際、「この回答は自信度が低いため事実確認が必要です」とユーザに断りを入れる、あるいは内部ログにフラグを立てておき運営者が後で点検できるようにするなどの対応です。こうしたアラートは、幻覚による致命的ミスを未然に防ぐセーフティネットとなります。

次にフォローアップですが、幻覚と判定された回答に対して後処理を行う方法です。たとえば自動的に追加の検索クエリを発行し、正しい情報を取得してから再回答させる、といったステップを踏むことが可能です。あるいは、幻覚を含む箇所をユーザにハイライトで示し「この部分の信頼性は低い可能性があります」と注記することも考えられます。さらに、幻覚を出したモデル自体にもフィードバックを与える試みもあります。RLHF(人間フィードバックによる強化学習)の一環として、幻覚を起こした出力には低い報酬を与え、モデルがそうした回答を避けるよう調整するのです。このようなモデル内フィードバックループにもRAGTruthの知見が活きます。具体的には、RAGTruthで得られた「どんなパターンが幻覚か」という情報を報酬モデルに組み込み、モデル訓練時に参照させることも考えられるでしょう。

以上のように、RAGTruthに基づいた幻覚低減策は多岐にわたります。単なる検出を超え、アラート発報、再回答誘導、モデル調整といった流れで総合的に幻覚を抑え込むことができます。現場ではこれらを組み合わせ、「幻覚が出にくく、出てもすぐ訂正される」システムを目指すことが可能です。そしてその根底には常にRAGTruthで得られたデータと洞察があり、データ駆動で練り上げられた対策だからこそ実効性が高いと言えるでしょう。

日本語RAGへRAGTruthを適用する際のポイント:言語固有の課題と効果的な対応策を具体例も交えて解説

英語中心データセットを日本語へ転用する壁:文化的背景や言語表現の違い

RAGTruthは主に英語のデータセットですが、これを日本語のRAGシステムに適用しようとする際にはいくつかの壁が存在します。まず第一に、言語そのものの違いです。英語と日本語では文法構造や表現方法が異なるため、同じ幻覚現象でも表れ方が変わる可能性があります。例えば、日本語では主語を省略することが多く、コンテキスト次第で意味が変わるケースが多々あります。英語のRAGTruthで想定された「明白な矛盾」も、日本語では主語省略により微妙な意味のブレとして現れるかもしれません。また文化的背景の違いも無視できません。英語圏の常識では幻覚と判断される記述が、日本の文脈では受け入れられる表現だったり、その逆もあります。例えば敬語や婉曲表現が多用される日本語では、直接的な断定よりも柔らかな言い回しになるため、幻覚であっても表面的には丁寧に聞こえてしまうかもしれません。このような言語・文化の差異が、英語版RAGTruthをそのまま日本語に適用する際の大きな壁となります。

日本語特有のハルシネーション傾向:敬語や曖昧表現で生じる誤解の例

日本語には日本語特有のハルシネーションの傾向も存在します。例えば敬語や丁寧語の乱用により、事実をぼかしてしまうケースです。モデルが「〜かと存じます」「〜のようです」といった曖昧な表現を多用すると、一見丁寧ですが実質的に何も根拠を示していない回答になりがちです。ユーザから見るとそれが幻覚なのか単なる婉曲表現なのか判断しにくく、誤解を招きます。また日本語では主語が省略されるため、モデルが勝手に主語を補って誤解させることもあります。例えば文脈上「彼」が指す人物が特定できていないのに、モデルが誤って別人を指す主語を補って話を続けるような場合です。これはHallucinationの一種と言えます。他にも、カタカナ英語や和製英語の扱い、漢字の読み間違いなど、日本語特有の要因で生じる幻覚があります。例えば「ロバスト」(頑健な)という言葉をモデルが「ロボット」と誤認して回答に混入させるなどのケースです。英語RAGTruthでは想定しにくいこうした日本語の現象に対応する必要があります。

日本語版RAGTruthの構築に向けて:データ収集と注釈で留意すべきポイント

日本語のRAG評価データセット(いわば日本語版RAGTruth)を構築するには、いくつかの重要ポイントがあります。まずデータ収集では、日本語の大規模コーパスから幻覚事例を集める必要があります。具体的には、日本語のQAデータやニュース記事、日本語のレビューや知識ベースを使い、RAG環境でモデル(日本語対応のLLM)に回答させてデータを蓄積します。この際、質問内容や文脈は日本の文化・社会に沿ったものを選ぶことが大切です(例:日本の地理や歴史に関する質問、国内ニュース記事など)。次に注釈では、英語版RAGTruthの基準を参考にしつつ、日本語独自の判断基準も追加します。例えば敬語表現による不確かな言い回しをどう扱うか、主語省略による曖昧さを幻覚とみなすか否か、といったルールを決めておきます。また注釈者には日本語に堪能で、できればAIモデルの癖にも理解のある人材が望ましいでしょう。英語版と同様に二重チェック体制を敷き、判断の統一に努めます。さらに、英語には無かったカテゴリーが必要か検討します。場合によっては、「敬語誤用型幻覚」や「翻訳ミス由来幻覚」といったラベルを加えることも考えられます。つまり、日本語版RAGTruth構築では、英語版のフレームワークに日本語言語固有の観点を取り入れることがポイントになります。こうして完成したデータセットは、日本語LLMの幻覚問題に対処する上で強力な武器となるでしょう。

日本語RAGでのハルシネーション検出精度向上策:モデル調整と評価

日本語RAGシステムで幻覚検出精度を上げるためには、モデルと評価両面で調整が必要です。モデル面では、可能であれば日本語対応の検出モデル(多言語モデルや日本語特化モデル)を用意し、日本語版RAGTruthでファインチューニングします。例えばXLM-RoBERTaのような多言語モデルに日本語の注釈データを学習させれば、日本語における幻覚検出能力を高められます。また、日本語では形態素(単語)分割が必要なので、その点も考慮したモデル設計や前処理が求められます。評価面では、日本語特有の幻覚をきちんと測定できる指標を検討します。Precision/Recall自体は変わりませんが、例えば「敬語誤用による幻覚の割合」「固有名詞の読み間違いによる幻覚検出率」といった細分類で分析すると、有用な知見が得られるかもしれません。

さらに、モデルの出力言語が日本語の場合、検出モデルが参照するコンテキストも日本語になります。そのため、コンテキスト文と回答文の類似度計算や矛盾判定ロジックも日本語対応が必要です。英語版で使われていたテキスト類似度モデル(例えばembeddingでのコサイン類似度など)が英語向けなら、日本語向けの同等モデルを準備しなければ精度が出ないでしょう。以上のようなモデル調整と評価指標のチューニングを行うことで、日本語RAG環境でも幻覚検出の精度向上が期待できます。

言語固有の評価指標の検討:日本語でのPrecision/Recallの意味合い

最後に、日本語RAGにおける評価指標の解釈について触れておきます。PrecisionやRecallといった指標そのものは言語非依存ですが、日本語環境に適用する際にはその意味合いを正しく捉える必要があります。例えば、日本語では微妙なニュアンスの誤りが多い分、検出モデルが高Recallでもそれは「ごく僅かな表現揺れも幻覚と判定してしまった結果」かもしれません。つまりRecall向上が必ずしも実用上良いとは限らず、日本語では適度なバランスが重要ということです。またPrecisionについても、日本語特有の常識や背景知識をモデルが持たない場合、やたら慎重に構えて幻覚を見逃さない代わりに何でもかんでも幻覚扱いしてPrecision低下、という可能性もあります。

したがって、日本語版RAGTruthで評価する際には、単純な数値比較以上に背後の要因分析が欠かせません。たとえば、英語モデルではRecall重視が良かったとしても、日本語ではPrecisionを優先すべき場面もあるでしょう。それはユーザが日本語の曖昧表現に慣れており多少の曖昧さは許容すると考えられるため、誤検知(False Positive)を減らす方がユーザ体験的に重要かもしれない、といった判断です。このように評価指標の運用も日本語環境に合わせて最適化することが求められます。総合すると、日本語RAGへのRAGTruth適用では、言語固有の課題を理解しつつ、データ収集・モデル調整・評価の各段階で適切な対応策を取ることが成功の鍵となるでしょう。

RAGTruthと他のRAG評価データセット(DROPやCovidQA等)との違い:特徴や用途の比較と考察

代表的RAG評価データセットの概要:DROP・CovidQA・PubMedQAなどの特徴

RAGTruth以外にもRAGに関連する評価データセットはいくつか存在しています。その代表例としてしばしば挙げられるのが、DROPやCovidQA、PubMedQAなどです。まずDROPですが、これは元々2019年に公開された読解テスト(QA)データセットで、Discrete Reasoning Over Paragraphsの略称です【参考】。質問文と文章を与えて数値推論などを行わせるタスクで、RAGが注目される前から存在したため幻覚検出を直接目的としたものではありませんが、RAGシステムの評価にも流用されてきました。CovidQAは、COVID-19に関する科学論文からのQ&Aデータセットで、専門的な内容のQA対話を含んでいます【参考】。こちらも特定領域(医学)のQA性能を見るためのセットですが、RAGシステムにこのデータを入れて回答の正確さを評価するなどに使われます。PubMedQAは医学文献を元にしたQ&Aデータセットで、Yes/No/Maybe形式で論文の結論に関する質問に答えるものです。これもRAGの評価で引用されることがあります。

その他にも、FinQA(金融分野)、TriviaQA(オープンドメインQA)、Wizard of Wikipedia(対話における知識活用)など、RAG関連で言及されるデータセットは複数あります。ただ多くは「回答の正確さ」や「知識検索の有無」を評価するもので、RAGTruthのように幻覚そのものを網羅的に注釈しているものは稀です。それぞれ目的や形式が異なるため、まずは主要データセットの特徴を把握しておく必要があります。

規模とカバレッジの比較:RAGTruthの大規模性と多領域性

RAGTruthと他データセットを比較する際にまず目につくのは、その規模とカバー範囲の違いです。RAGTruthは約1.8万件という非常に大規模な応答数を持ち、しかもQA・要約・データ記述と3つのタスク領域をまたいでいます。一方、例えばCovidQAは300程度のQAペアから成り、ドメインもCOVID関連に限られます。DROPは約5千問のQAですが、その多くは算術推論付きで、ジャンルはWikipedia文章内の事実に限られます。PubMedQAも1千数百問で医学論文ドメイン固定です。つまり、RAGTruthは規模においても領域の広さにおいても他を圧倒しています。この大規模性は、単一モデル・単一領域では測れないような普遍的傾向を明らかにできるという利点があります。例えばRAGTruthは複数モデルの比較ができましたが、小規模データでは標準的なモデル1〜2種でしか試せないことも多いでしょう。また多領域に跨がるため、「どのタスクで特に幻覚が起きやすいか」といった分析も可能です。他データセットではそのデータ自身の評価はできても、一般化された議論には結びつけにくい場合があります。RAGTruthのスケールメリットは、より包括的なRAG評価を可能にした点で突出しています。

アノテーションの深さと粒度の違い:RAGTruthの詳細ラベル付けがもたらす利点

次に注目すべきは、アノテーションの深さと粒度の違いです。RAGTruthの最大の特徴は単語レベルの詳細な注釈であり、4タイプ分類など豊富なラベリング情報を持つ点です。一方、多くの他データセットは「回答が正しいか否か」「質問に答えられたか否か」といったラベルしか持ちません。例えばDROPやCovidQAでは基本的に正解のテキストやYes/No答え合わせがあるだけで、回答内のどの部分が間違いかまでは示されません。幻覚検出という観点から見ると、RAGTruthほど細かな誤り分析ができるデータは他にほぼ無いと言えます。この違いがもたらす利点は、前述してきたようにモデルの詳細なエラー解析や検出器の精密な訓練が可能になる点です。他データセットではモデルが不正確な回答をした場合でも、「どこがどう間違ったか」を知るには人手で分析する必要がありました。しかしRAGTruthでは初めからそれがマークアップされているため、モデルとデータの双方を容易に結び付けられます。例えば「モデルXはSubtle Conflictタイプの誤りを10件犯したが、モデルYは2件だけだった」等の定量比較もRAGTruthならではです。このようにRAGTruthの精細な注釈は、他データセットにはない診断力を評価に与えており、それが評価手法開発の加速にも繋がっています。

タスク多様性と現実性:RAGTruthの自然生成応答 vs 合成データセットの構成法の違い

さらに比較ポイントとして、タスクの多様性とデータの現実性があります。RAGTruthは先述の通り複数タスク・複数ドメインにまたがり、モデルの応答も実際のLLMが自然に生み出したものです。一方、他の評価データセットの中には、モデル出力ではなく人間が作成した「正解」データをもとに合成的に評価シナリオを作っているものもあります。例えば、TruthfulQAというデータセットではモデルが嘘をつきやすい質問を人手で設計してテストしています。Longform QAベンチマークでは、人間が書いた長文回答とモデル回答を比較評価する形式になっています。これらは幻覚を誘発するような状況を意図的に作っていますが、データ自体は人工的です。それに対してRAGTruthは、あくまで実際のモデルが通常のプロンプトで回答した内容を集めているため、より現実に近い誤りの傾向を反映します。この現実性の違いは、得られる知見にも影響します。人工データでは見つからなかった予期せぬ幻覚パターンがRAGTruthには含まれていたり、逆に人工データで重視されたケースが実際には稀だったりします。RAGTruthの自然生成応答という性質は、評価結果の実用上の信頼性を高めており、研究から実装への橋渡しをスムーズにしていると言えます。一方で人工的な評価セットは特定の局面を重点テストできる利点があるため、RAGTruthと使い分けるとより良いでしょう。

用途と評価シナリオの相違:研究ベンチマーク向けか実世界応用検証かの違い

もう一つの違いは、それぞれのデータセットの想定用途や評価シナリオです。RAGTruthは主に研究コミュニティ向けのベンチマークであり、様々な手法やモデルを比較検討するために作られました。それに対して、DROPやCovidQAなどは特定タスクでのモデル性能を測るためのベンチマークです。例えばDROPなら「複雑な数値推論が必要なQAにモデルがどれだけ答えられるか」というモデル能力評価が目的です。CovidQAは「コロナ関連文献から正しく質問に答えられるか」という実応用に近い検証が目的でした。このように各データセットは微妙に目的が異なります。幻覚検出という観点では、RAGTruthが直接的なベンチマークで、他は間接的な指標という位置付けです。従って、RAGTruthを用いた研究は主に幻覚検出モデルの開発や評価に焦点が当たりますが、他データセットを用いる研究はRAGシステム全体の性能評価(正答率やユーザ満足度)に焦点があることが多いです。どちらが優れているということではなく、評価したい対象が違うのです。実世界応用の検証にはドメイン特化のCovidQA等が適し、汎用的な幻覚検出技術の検証にはRAGTruthが適します。

RAGTruthが埋めるギャップ:他データセットで不足していた観点の補完

総合的に見ると、RAGTruthは他のRAG評価データセットにはなかった観点を補完する存在です。従来は、モデルの回答の正解率やリコールは測れても、その中で「幻覚がどれだけ含まれているか」を直接測る仕組みが不足していました。RAGTruthはそのギャップを埋め、モデルが答えを間違えたときに「知識不足で答えられなかった」のか「知識はあったのに幻覚を混ぜた」のかといった内訳分析を可能にしました。また、RAGTruthの詳細な注釈によりエラー分析の精緻化が進み、新しい検出アルゴリズムの開発にデータ面から貢献しました。これは他のQAデータでは難しかったことです。さらに、RAGTruthの結果を他のデータセット結果と組み合わせることで、「モデルは正解率は高いが幻覚率も高い」といった評価が可能になり、モデル選択や改良の指針がより明確になりました。

考察すると、RAGTruthと他データセットは競合するものではなく、むしろ相互補完的です。他のベンチマークがあって初めて、RAGTruthでの幻覚評価が活きますし、その逆も然りです。例えば、まずDROPでモデルのQA性能を測り、その上でRAGTruthで幻覚率を測れば、「知識推論力はあるが幻覚癖があるモデル」なのか「推論力は低いが幻覚はしないモデル」なのか等、立体的な評価ができます。このように複数のデータセットを組み合わせて用いることで、LLMの挙動を多面的に理解できるでしょう。結論として、RAGTruthは他のRAG評価データセットにはない特徴(大規模・詳細注釈)を持ち、それによって幻覚検出という新たな軸を評価に加えました。それは従来データセットの価値を減じるものではなく、全体としてRAGシステム評価をより豊かにする方向に機能していると言えます。

資料請求

RELATED POSTS 関連記事