RAGASとは？RAG評価フレームワークの指標・0.4系の実装手順・導入判断【2026年版】

RAGASは、RAGやLLMアプリの出力をコードから採点するオープンソースの評価フレームワークです。社内文書を読ませたチャットボットの回答が崩れたとき、目視で数十件を読み比べる作業を、Context PrecisionやFaithfulnessといった指標の数値へ置き換えられます。本記事では定義とライセンス・開発状況を押さえたうえで、指標カタログの構成、0.4系でのインストールからevaluate実行までの手順、合成テストセット生成の仕組み、DeepEvalなど他ツールとの守備範囲の違い、そして導入を見送るべき条件までを実装目線で整理します。

まとめ：RAGASの採用条件と、自前の評価スクリプトで足りる境目

先に結論から示します。RAGASはApache-2.0で公開されたPythonライブラリで、2026年8月時点のPyPI最新版は0.4.3、対応Pythonは3.9以上です。中心にあるのはevaluate()という関数ひとつで、質問・検索してきた文脈・回答・正解の4項目を並べたデータセットと、採点したい指標クラスの一覧を渡すと、指標ごとに0から1のスコアが返ります。

採点そのものは、多くの指標で判定用のLLMが担います。つまりRAGASは「採点ロジックを自作せずに済ませる仕組み」であって、何点なら合格かという基準を決めてくれる道具ではありません。ここを取り違えると、スコアは出るのに意思決定が進まなくなります。

導入の線引きも先に述べます。評価対象の質問が50問を超え、月1回以上パイプラインへ手を入れる案件なら、RAGASで回帰検知を自動化する価値があります。逆に質問が数十問未満で設定を一度決めたら触らない案件や、判定用LLMへ本文を送れない機密要件の案件では採用しません。条件は後段の独自章で述べます。

RAGASの定義と、RAG評価をコードで自動化する仕組みの全体像

RAGASの定義と、Apache-2.0で公開されているプロジェクトの現在地

RAGAS（Ragas）は、RAGとLLMアプリケーションの評価を目的としたオープンソースのPythonライブラリです。GitHubのvibrantlabsai配下で開発され、リポジトリの作成は2023年5月8日、ライセンスはApache-2.0、スター数は15,084（2026年8月2日時点のGitHub API実測値）です。PyPIでの配布名はragas。

名前の由来はRAG Assessmentですが、0.4系では守備範囲がRAGの外側まで広がりました。公式ドキュメントの指標一覧には、エージェントのツール呼び出しを採点する指標やSQLクエリの等価性を判定する指標も並びます。RAG専用の道具として紹介されがちなものの、実態はLLMアプリ全般の評価基盤に近い構成です。

評価が動く3要素、入力データと指標クラスと判定用LLMの役割分担

RAGASの実行は、3つの部品の組み合わせで説明できます。1つ目が入力データで、質問・検索した文脈・生成された回答・正解文の集合体。2つ目が指標クラスで、FaithfulnessやLLMContextRecallのように、何を採点するかをオブジェクトとして指定します。3つ目が判定用LLMで、多くの指標はここへ採点を依頼します。

この3要素のうち、品質を左右するのは判定用LLMの選択です。回答を分解して1文ずつ文脈と突き合わせる、といった採点処理をLLMが担うため、小さなモデルを判定側に据えるとスコアが不安定になります。この仕組み自体はLLM-as-a-Judgeとは何か？AIモデルを評価者にする最新の自動評価手法の概要と仕組みを徹底解説で扱った方式そのもので、RAGASは採点プロンプトを指標として型に落とし込んだ実装です。

RAG評価の設計論と、ツールとしてのRAGASが担当する範囲の切り分け

ツールを入れる前に決めることがあります。どのフェーズの品質を、どの粒度で測るのかという設計です。検索フェーズと生成フェーズを分けて測る考え方、指標をどう読んで次の打ち手へつなぐか、評価データセットを何件どう作るかは、RAG評価とは？検索と生成を分けて測る指標・Ragasでの実装・運用への組み込み【2026年版】で整理しました。本記事はその設計を前提に、RAGASというツールの側だけを深掘りします。

そもそもRAGの仕組み自体が曖昧なら、RAGとは？仕組みとLLM・ファインチューニングとの違い・企業での導入例を解説を先に読むほうが早道です。検索器と生成器が分かれた構造を理解しないまま評価へ入ると、指標名を覚えるだけの作業になります。

指標カタログの構成と、RAG・エージェント・汎用での使い分け基準

検索側と生成側で対になる4指標と、参照データの要否による使い分け

RAG向けの指標は、公式ドキュメントの一覧に8種類が並びます。実務で最初に押さえるのは4つです。検索側がContext PrecisionとContext Recall、生成側がFaithfulnessとResponse Relevancy。この4つで、故障箇所が検索器と生成器のどちらかを切り分けられます。

残る4つは補助的な位置づけです。Context Entities Recallは固有名詞の取りこぼしを見る指標で、製品名や型番が答えの中心になる用途で効きます。Noise Sensitivityは、無関係な文脈が混ざったときに回答が引きずられる度合いを測ります。Multimodal FaithfulnessとMultimodal Relevanceは画像を含む入力の派生版です。

選ぶ際の分岐は、正解文（reference）を用意できるかどうか。作れる場合はContext Recallで取りこぼしを厳密に測れますが、作れないならNVIDIA提供のAnswer AccuracyやContext Relevance、Response Groundednessのように参照データを前提としない指標へ寄せます。正解文の整備は1問あたり数分の人手を要するため、まず参照なしで回し、改善対象を絞ってから作る順序が現実的でしょう。

エージェント評価向けの指標群と、ツール呼び出しの正確性を採点する観点

0.4系にはエージェント向けの指標が4つ並びます。Topic Adherenceは、想定した話題の範囲から逸脱していないかを判定する指標。Tool Call AccuracyとTool Call F1は、呼び出したツールと引数が期待どおりかを採点します。Agent Goal Accuracyは、対話全体でユーザーの目的を達成できたかを見ます。

RAG案件でも必要になる場面があります。検索を関数として持たせたエージェント構成では、検索ツールを呼ばずに答える失敗が起きるためです。この失敗はFaithfulnessでは拾いにくく、Tool Call Accuracyのほうが直接的に検出できます。

LLMを使わない文字列一致系の指標と、費用を抑える場面での使い分け

自然言語比較のカテゴリには、Non LLM String Similarity・BLEU Score・CHRF Score・ROUGE Score・String Presence・Exact MatchなどLLMを呼ばない指標が揃っています。加えてSemantic Similarityは埋め込みモデルのみを使うため、判定用LLMほどの費用はかかりません。

• Exact MatchとString Presence：定型フォーマットの回答や、必須の免責文言が入っているかの確認に使う
• ROUGE ScoreとBLEU Score：要約タスクの回帰検知に使い、絶対値ではなく前回との差分だけを見る
• Semantic Similarity：正解文との意味的な近さを埋め込みで測り、表現ゆれに強い一次スクリーニングとして使う

これらの位置づけは、LLM判定の前段フィルタです。全問をLLMで採点すると費用と時間が膨らむため、まず文字列一致系で明らかな崩れを検出し、残りをFaithfulnessなどへ回す二段構えにすると、1回の評価時間を短縮できます。汎用カテゴリにはAspect Criticやルーブリック採点もあり、独自の観点（社内規程に反する表現が無いか等）を自然文で定義して採点させる使い方も可能です。

0.4系での導入からevaluate実行までの手順と入力データの形式

インストールと、判定用LLM・埋め込みモデルのラッパー設定の手順

公式のクイックスタートはLangChain経由でモデルを差し込む構成で、手順は次の流れです。

1. pip install ragas でライブラリを導入し、判定用モデルを呼ぶためにlangchain-openaiなど各社のLangChain連携パッケージも入れる
2. 判定用LLM（例ではChatOpenAIのgpt-4o）と埋め込みモデルを、Ragas側のラッパークラスで包む
3. 評価したい質問・文脈・回答・正解をリストの形へ整え、EvaluationDataset.from_list()でデータセットへ変換する
4. 採点したい指標をインスタンス化し、evaluate()にデータセット・指標一覧・LLMを渡して実行する

ラッパーを挟む理由は、指標側が共通のインターフェースでモデルを呼ぶためです。素のクライアントを渡すと型が合わず実行時に落ちます。判定用モデルは本番の生成用と別に指定できるので、生成側を小型モデルへ替える検証でも判定側を固定したまま比較できます。

EvaluationDatasetに渡す4項目と、収集時に崩れやすい形式

データセットの1件はSingleTurnSampleに対応し、user_input（質問）、retrieved_contexts（検索で取得した文脈の文字列リスト）、response（生成された回答）、reference（正解文）の4項目で構成されます。参照なしの指標だけを使うならreferenceは不要です。

実装で崩れやすいのはretrieved_contextsの形です。ここはリランキング後・プロンプトへ実際に差し込んだ順序の文字列リストである必要があり、検索結果のオブジェクトをそのまま渡したり連結して1本の長い文字列にしたりすると、Context Precisionが順位を評価できません。既存パイプラインへ後付けするなら、プロンプト組み立ての直前にログ出力を仕込み、4項目を吸い出す作り方が確実でしょう。

0.3系のサンプルコードが動かない理由と、版を固定する運用手順

ネット上の記事を写経して動かない、という詰まり方が最も多く起きます。原因は版差です。0.3系まではanswer_relevancyのような関数風の指標名や、Hugging Faceのデータセット形式を直接渡す書き方が主流でしたが、0.4系ではEvaluationDatasetとクラス形式の指標に整理されました。同じ「Ragasの使い方」でも、書かれた時期で前提が違います。

運用としては、要件定義の時点で版を固定してください。requirements.txtで0.4系のパッチ版まで指定し、判定用LLMのモデル名・温度・埋め込みモデル・評価データセットも同時に固定します。指標の実装が更新されるとスコアの絶対値が動くため、固定を怠ると「改善したのか、評価器が変わったのか」を判別できません。評価結果には、スコアとあわせてragasのバージョン番号と判定モデル名を必ず残しておきましょう。

合成テストセット生成の仕組みと、評価データ整備で削れる工数の範囲

知識グラフを経由した質問生成の流れと、抽出器・関係構築器の役割

RAGASには、手元の文書から評価用の質問と正解を自動生成する機能があります。LLMへ「質問を作って」と投げる方式ではなく、知識グラフを経由するのが特徴です。

流れは次の通りです。まず文書をドキュメント分割器でノードへ分解し、NERExtractorのような抽出器が各ノードから固有表現やキーフレーズを取り出します。続いてJaccardSimilarityBuilderなどの関係構築器がノード間の関係を張ります。この処理はTransformsとして順序づけて適用でき、Parallelクラスで並列実行も可能。出来上がった知識グラフの上を、クエリ合成器がたどって質問を作ります。

単一文書型と複数文書型の質問の違いと、ペルソナ指定で変わる粒度

生成される質問は、シングルホップとマルチホップに大別されます。前者は1つのノードで答えられる質問で、年号や仕様値を問うSpecific型と解釈を問うAbstract型に分かれます。後者は複数ノードの情報を統合しないと答えられない、比較や横断分析を要求する質問です。

クエリ合成器では、ノード選択に加えて質問の長さ（短・中・長）、質問のスタイル（検索窓へ打ち込む語の羅列か、チャットの会話文か）、そしてペルソナの指定が可能です。ペルソナは「シニアエンジニア」のような読者像で、変えると同じ文書から出る質問の粒度も変わります。社内ヘルプデスク用のRAGなら現場担当者と管理職でペルソナを分け、両方を混ぜたテストセットにすると実運用の分布へ近づきます。

生成した質問をそのまま使わない理由と、人手レビューの現実的な量

ここは言い切ります。合成テストセットを、そのまま合否判定の基準に使わないでください。生成された正解文は元文書に強く引きずられ、実際のユーザーが投げる曖昧な質問や複数解釈のある問いをほとんど含みません。合成データだけで「Faithfulness 0.9で合格」と決めると、本番で崩れます。

現実的な使い方は、初期の骨格づくりです。合成で100問ほど作り、1問30秒程度の粗いレビューで不自然なものを捨て、残りへ問い合わせログから拾った質問を混ぜます。レビューを含めても、ゼロから100問を書き起こす工数の半分以下で済むはずです。ハルシネーション検出用に整備されたRAGTruthとは｜RAGのハルシネーションを検出するACL 2024評価データセットを解説のような公開データセットも、指標の挙動を確かめる目的なら併用できます。

DeepEvalやマネージド評価との比較と、実行コストから見た選定基準

RAGChecker・DeepEvalとの守備範囲の違いと、選定時の判断軸

RAG評価の道具は複数あり、守備範囲が少しずつ違います。指標名の見比べでは選べないため、何を前提にした道具かで整理しました。

判断軸は2つです。1つは、評価をアプリのテストコードとして書きたいのか分析用スクリプトとして書きたいのか。テストの作法へ寄せたい場合、DeepEval系との相性は良好です。もう1つは誤答の原因分析にどこまで踏み込むかで、検索と生成へ分解した診断に特化したRAGCheckerとは｜RAGを検索と生成に分けて診断するAmazonの評価フレームワークのような道具は、改善会議の材料づくりで効きます。RAGASは指標の網羅性とテストセット生成を1つのライブラリで賄える点が強みで、迷ったときの標準的な出発点になります。

判定用LLMの呼び出し回数から見積もる、1回の評価にかかる費用

見落とされがちなのが実行コストです。LLM判定の指標は1問1指標につき最低1回、回答を分解して検証する種類なら複数回、判定用LLMを呼びます。100問へ4指標を回せば、単純計算で400回以上のリクエストが飛びます。

設計の分岐はここです。CIのプルリクエストごとに全問を回すと待ち時間と費用が現実的でなくなるため、日次で全問・プルリクエストでは20問程度のサブセットという二段構成にします。サブセットは無作為抽出でなく、過去に落ちた質問を優先して固定するほうが回帰検知は安定します。

RAGASを採用しない方がよい場面と、導入前に固めるべき前提条件

採用してよい条件、回帰検知を前提に改善を継続する開発体制の要件

採用してよいのは、次の3条件がそろう案件です。評価対象の質問が50問以上あり、検索器の設定やプロンプトへ月1回以上手を入れ、変更前後で品質が落ちていないかを継続的に確かめる必要がある。ここまで満たすなら、初期工数（データ整備と組み込みで数人日）は数回の改善サイクルで回収できます。

逆に言えば、一度作って納品したら触らないRAGでは、評価基盤を組む必要はありません。納品前の品質確認は、業務担当者による目視レビューのほうが速く、しかも業務上の妥当性まで見てくれます。

見送るべき場面、質問が数十問未満の案件と外部送信が禁止された環境

見送るべき場面を2つ、条件を添えて明示します。1つ目は評価対象が数十問未満のケース。この規模なら、指標の実装を理解して版を固定する手間より、担当者が全問を読んだほうが早く終わります。スコアを出すこと自体が目的化した評価は、判断材料を増やしません。

2つ目は、社内文書を外部のLLM APIへ送れない案件です。RAGASの主要指標は判定用LLMへ質問・文脈・回答を丸ごと渡すため、評価工程でも本番と同じデータが外へ出ます。ローカルLLMを判定側へ据えるか文字列一致系へ絞る選択肢はありますが、小型モデルを判定に使うとスコアの安定性が落ちる点は織り込んでください。契約上どうしても送れないなら導入は見送り、人手のレビュー体制を設計するほうが誠実です。

導入前に決める合否ラインと、人手判定を残す領域の線引きの決め方

導入前に決めるべきは、合否ラインの置き方です。Faithfulness 0.8といった絶対値を最初から置くと、指標の実装や判定モデルが変わるたびに基準が揺れます。現行構成で1度全問を回し、その値を基準線に「前回比マイナス0.05を下回ったら調査」という相対運用から始めましょう。

そして、人手に残す領域を明文化します。法令解釈の誤りや契約条件の取り違え、社外へ出せない情報の混入といった業務上の致命傷はスコアが高くても起こり得るため、自動評価の合格を出荷判定に代えない運用にしてください。改善の実行手順はRAG構築の手順とは？データ整備から精度向上・本番運用までの進め方で扱っています。評価の設計から改善までを自社だけで回しきるのが難しい場合は、RAG構築支援で、指標の選定と合否基準の設計を含めてご相談いただけます。

よくある質問

RAGASの導入検討でよく挙がる質問を、実装と運用の観点からまとめました。

RAGASとRAG評価は何が違うのですか？

RAG評価は、検索フェーズと生成フェーズを分けて品質を測る考え方や工程そのものを指します。RAGASは、その工程を実行するためのオープンソースのPythonライブラリです。どの指標をどんな基準で見るかを決めずにライブラリだけ入れても、数値が出るだけで改善は進みません。設計の考え方は本文中のリンク先で扱っています。

RAGASの利用に費用はかかりますか？

ライブラリ自体はApache-2.0のオープンソースで、利用料はかかりません。費用が発生するのは判定用に呼び出すLLMのAPI利用分です。LLM判定の指標は1問1指標あたり1回以上のリクエストを伴うため、100問を4指標で評価すれば400回超の呼び出しになります。BLEUやExact Matchなど文字列処理だけの指標なら、この費用は生じません。

日本語のドキュメントでも精度よく評価できますか？

判定用LLMが日本語を十分に扱えるモデルであれば、実用に足るスコアが得られます。注意点は、回答を文単位へ分解する指標で、句点の少ない長文や箇条書き中心だと分解が崩れ、スコアが不安定になる点です。まず10問ほどを人手の判定と突き合わせ、傾向に納得できてから全問へ広げてください。

0.4系へ上げたら既存の評価コードが動かなくなったのはなぜですか？

0.3系と0.4系では、データセットの渡し方と指標の指定方法が変わっています。0.4系はEvaluationDatasetへ変換し、クラス形式の指標をevaluate()へ渡す構成です。ネット上の記事は執筆時期で前提の版が異なるため、公式ドキュメントのマイグレーション項目を確認し、requirementsで版を固定してから移行してください。

テストセットは自動生成だけで用意してよいですか？

骨格づくりには使えますが、合否判定の基準をそれだけで作るのは避けてください。合成された質問と正解文は元の文書へ強く依存し、実際のユーザーが投げる曖昧な質問を含みにくいためです。合成した100問を人手で粗くレビューし、問い合わせログから拾った質問を混ぜると、本番の分布へ近づきます。

関連記事

• RAG評価とは？検索と生成を分けて測る指標・Ragasでの実装・運用への組み込み【2026年版】：指標の読み方と評価データセットの設計、運用への組み込み方を扱っています
• RAGとは？仕組みとLLM・ファインチューニングとの違い・企業での導入例を解説：評価の前提になるRAGの構造と導入例をまとめています
• RAG構築の手順とは？データ整備から精度向上・本番運用までの進め方：スコアが落ちたときに手を入れる工程側の記事です
• LLM-as-a-Judgeとは何か？AIモデルを評価者にする最新の自動評価手法の概要と仕組みを徹底解説：RAGASの採点を支えるLLM判定方式の解説です
• RAGCheckerとは｜RAGを検索と生成に分けて診断するAmazonの評価フレームワーク：比較対象になる別フレームワークの守備範囲を確認できます