Zenn
🤖

【徹底解説】LLMの評価基準と品質向上を支えるRagasの基本_RAGやAIエージェントの評価指標からデータ作成まで

に公開
QAエンジニア
QA
LLM
品質保証
Ragas
tech

皆さんこんにちは、web3やAIなど最先端領域に特化したソフトウェアテストを専門的に行う、DAIJOBU株式会社の代表のふぇね(@0xfene)です。弊社ではAIエージェントに特化した品質保証サービス「AI Agent品質担保くん」にて、LLMアプリケーション(とりわけAIエージェント)の品質保証に精力的に取り組んでいます。実質LLMOpsのBPOサービスですね。

目次
  • はじめに 〜PoC止まり脱出の鍵はLLMの品質向上にある〜
  • 本記事について
  • Ragasとは
  • Ragasの特徴
    1. 客観的な評価指標
    2. テストデータの自動生成
    3. シームレスな統合
    4. フィードバックループの構築
  • 評価指標とフレームワーク
    1. 根本的な評価指標に対する考え方
    2. Ragasの7つのユースケースごとに分類された評価指標/フレームワーク
  • 最後に

はじめに 〜PoC止まり脱出の鍵はLLMの品質向上にある〜

皆さん、AIシステムの品質向上にはどう取り組まれていますか？
2022年のGPTブームから、生成AI受託起業の流行やSler/コンサル事業者のAIシフトと共に、国内でも様々なRAGやAIエージェントが実装されてきました。

しかし、実はPoCの8割は失敗に終わっていると言われています。

PoCから本番開発に移行するには、市場選定から適切なビジネスKPIの設定、技術力など、色々な要因が複雑に絡んでいるのですが、理想的なPoC開発を難しくしているの1つに「LLMの品質が重大な鍵を握るにもかかわらず、その品質向上が難しい」というものがあります。なかでも、LLMの品質向上には、評価指標(Evals)とデータセット(Dataset)の2点が特に重要だと言われています。

もちろん、AIの品質基準は機械学習が旺盛だった時代から議論されており、品質基準は評価方法や指標について多くの論点が、LLMアプリケーションに限らず、機械学習アプリケーション全般に共通しています。

しかし、業界的にLLMの品質保証の方法論や品質基準は、まだ十分に議論し尽くされておらず、現在も様々な事業者や業界団体が議論や研究を重ねている最中です。

本記事では、そのLLMの品質基準や評価方法策定の取り組みの1つとして、RagasというLLMの評価フレームワークについて解説します。LLMの評価ツールはLangsmithやARESなど色々とありますが、Ragasはフレームワークとしてはかなり有名な方だと思います。

本記事について

Ragasとは

Ragasとは、LLMシステムの評価/テストをするためのツールを提供するOSSのライブラリです。LLMの客観的な性能評価に特化した専用のメトリクスが複数用意されています。Ragasを通じて、開発中のLLMによる自動評価(LLM as a judge)だけでなく、評価用テストデータの生成ができます。運用中の監視も他ツールと連携して行えます。

公式ページでは、以下のように説明されています

Ragas is a library that provides tools to supercharge the evaluation of Large Language Model (LLM) applications. It is designed to help you evaluate your LLM applications with ease and confidence.
RagasはLLM(大規模言語モデル)アプリケーションの評価を強化するためのツール群を提供するライブラリです。LLMアプリケーションを簡単かつ安心して評価できるように設計されています。

https://docs.ragas.io/en/stable/

元々Ragasは、RAGに特化した評価フレームワークとして2023年9月に公開されたのですが、その後、Ragas v0.2に2024年10月にアップデートされてからは、対象ユースケースが大幅に増え、RAGだけに留まらずLLM全般の7つのユースケースの評価に適応できるようになりました。引き続きRAGの評価フレームワークとして重要な役割を果たし続けると思いますが、v0.2以降はRAG以外に対しても評価指標として機能し始めているため、Ragas(Retrieval-Augmented Generation Assessment)という名前が似合わなくなってきていますねw

RagasはOSSなので具体的な実装やプロンプト、最新情報を確認したい場合はソースコードを参照してください。ドキュメントやサンプルコードが古いものや、誤りを含んでいるケースも結構あります。実際に使うケースは、GitHubのソースコードを直接参照される方が良さそうです。

公式ドキュメント : https://docs.ragas.io/en/stable/
公開論文 : https://arxiv.org/abs/2309.15217
Github : https://github.com/explodinggradients/ragas

LLMの品質向上には、「評価指標」と「データセット」が重要な役割を占めるのですが、Ragasではその双方を扱えます。

※ 弊社ではセットアップからその後の運用監視まで丸っと簡単に扱えるLangsmith(※ 最近はお客様の情報セキュリティ上、セルフホストできるLangWatchやLangfuseも試し中)を用いることが多いですが、異なる評価指標を扱ったり、複数の評価データセット作成を行いたい時にRagasのフレームワークも用いることがあります。(LangWatchでは、標準でいくつかのRagasの評価指標が事前構築されています)

※ LLMの評価には、LLMの出力を別のLLMを使って評価する「LLM as a judge」や、エキスパートによる人手での検証やプログラマブルな検証(Heuristic evaluators)など、様々な評価の仕方があります。詳細は別記事にまとめますが、Ragasは「LLM as a judge」を行うフレームワークの1つです。実際の評価では、手作業でアノテーションして評価指標やデータセットを構築したり、Langsmithで別フレームワークを扱うケースも多いです。

Ragasの特徴

次に、Ragasの具体的な特徴に移ります。Ragasの活用には以下の4つのメリットがあります。

  • 客観的な評価指標：
    • LLMベースおよび従来型の評価指標を使って、LLMアプリケーションを正確に評価できます。
  • テストデータの自動生成：
    • 幅広いシナリオを網羅する包括的なテストデータセットを自動で作成します。
  • シームレスな統合：
    • LangChainなどの人気LLMフレームワークや主要な可観測性ツールとスムーズに連携します。
  • フィードバックループの構築：
    • 本番データを活用し、LLMアプリケーションを継続的に改善できます。

それぞれ解説します。

1. 客観的な評価指標

ソフトウェアの品質向上には、まずは正しく評価すること、つまり評価指標が欠かせません。LLM自体には従来のシステムや機械学習と違い、現状だと明確で一律な評価指標が存在しません。この評価指標をさまざまな団体やフレームワークが提供しようと試みてきており、その中の1つがRagasによるこの評価指標です。Ragasの評価指標は客観的で、かつ実態に即して利用しやすいのがポイントで、弊社も実際に評価指標の1つとして利用することがあります。これらの評価メトリクスはLLMやEmbeddingを使って実装されています

2. テストデータの自動生成

また、テストデータ作成も品質向上の大きな鍵なのですが、これをRagasで扱えるのも大きなポイントです。人力での評価用のテストデータ作成は大変な時間とコストがかかるため、LLMを用いてテストデータを作成するケースが多いのですが、RagasでもLLMを用いたテストデータ作成ができます。LLMを用いて生成されたデータを「合成データ(Synthetic data)」と呼ぶのですが、Ragasの場合は単純なプロンプトでの生成よりも実践的なデータにするための工夫がなされています(十分使える合成データか？については賛否両論あります)。大別すると、人力でのテストデータ作成と合成データ、ログから取得してアノテーションしたデータの3タイプのデータセット作成の方法があるのですが、これもまた別記事でまとめたいと思います。

ちなみに、Ragasでは理想的なテストデータセットの特徴を以下のように評価しているようです。

  • Contains high quality data samples
  • Covers wide variety of scenarios as observed in real world.
  • Contains enough number of samples to be derive statistically significant conclusions.
  • Continually updated to prevent data drift.

https://docs.ragas.io/en/stable/concepts/test_data_generation/

やや噛み砕いて説明すると、

  • データサンプルの品質が良く（そもそものデータ品質が高い）、
  • 豊富なシナリオを網羅しており(LLM品質向上にはユースケース整理が命)、
  • 学習や品質向上に必要な十分な量を含んでおり(単純にデータ量が多い)、
  • 継続的な品質改善に使えるように自動更新されていく(LLM品質向上は継続的に行われる)

という4つが大事とされています。最低限これら4つの特徴はテストデータセット作成には必須です。

LLMアプリケーションの品質向上において、テストデータセットは命といっても過言ではないほど重要なのでまた別記事にまとめたいと思います。(Langsmithでも2024年8月から合成テストデータセットの生成機能が追加されており、他ツールでも合成テストデータ作成ができます。そもそも、現時点では合成テストデータだけに頼らず、人がアノテーションしながら作る必要性が高いです)

3. シームレスな統合

また、LangchainやLangsmithなど他ツールと連携しやすい点も良い点です。実際のLLM評価や品質向上には、LangsmithなどのLLMopsツールを用いるケースがほとんどです。この機能のおかげで、実際Ragasの評価フレームワークが使いやすくなっています。

4. フィードバックループの構築

LLM品質向上は、1回きりではなく継続的に品質向上の取り組みを行う必要があります。LLMの品質向上では、「テスト」の再定義が必要で、この継続的な品質向上の重要性や、従来のシステム開発との違いの説明はかなり量が膨れてしまうので、また別記事にまとめようと思います。「テスト」というよりは「LLMOps」と捉えた方が自然かもしれませんね。

評価指標とフレームワーク

Ragasの評価指標で抑えるべきポイントは、次の2つです。

  • 根本的な評価指標に対する考え方
  • 7つのユースケースごとに分類された評価指標/フレームワーク

それぞれ見ていきます。

1. 根本的な評価指標に対する考え方

Metricsとは？
指標(Metrics)とは、AIアプリケーションの性能を評価するために利用される定量的な尺度のことです。アプリやコンポーネントが与えられたテストデータに対してどれほど機能しているか？を評価するのに役立ち、比較、最適化、意思決定のための数値的根拠を示すとされています。

LLMでは従来のシステムと違い、出力が全て動的なため、明確な期待値やテストケースが書けません。その性質により品質を評価することが難しいのですが、Ragasが提供する指標(Metrics)を用いることで、AIアプリケーションの品質を客観的に評価することができます。(くどいようですが、評価指標はRagasが提供する以外にも複数の事業者や団体により提案されています)

LLMOの評価指標は、従来のシステムにおけるテストスクリプトやテストケースに対応していると言っても過言ではないでしょう。

なぜ評価指標が重要なのか？

Ragasでは、次の3つの理由で評価指標が重要だと説明されています。

  1. 最適なコンポーネントの選定ができるから

    • 指標を用いることで、LLM、Retriever、エージェント構成など、AIアプリケーションの異なる構成要素を自分のデータを用いて比較し、複数の選択肢の中から最適なものを選ぶことができるようになる。
    • → AIアプリケーションの各コンポーネントを、評価指標で数値化することで「良い構成を選べる」ようになります。例えば、LLMをGPT-4oにした場合とClaudeにした場合でそれぞれ対比的に評価を行うことで、このAIシステムにおける最適なLLM(パーツ)を選択することができる、ということです。AIアプリケーションは様々なコンポーネントから構成されており、1つ1つの構成要素を比較選択することで総合的に良いAIシステムになります。

  2. エラー診断とデバッグが容易になるから

    • アプリケーションのどの部分がエラーやパフォーマンスの低下を引き起こしているのかを特定するのに役立ち、それによってデバッグや改善がしやすくなる。
    • → AIの出力が間違っていたり品質が悪い時、AIアプリケーションの「どのコンポーネントが悪いのか？」と原因を特定し、効率的に品質を改善できます。この時、評価指標があれば、定量的に品質を評価できるため、勘ではなく本質的な改善ができるのがポイントです。

  3. 継続的なモニタリングと保守が行えるから

    • 時間の経過とともにAIアプリケーションの性能を追跡できるため、データドリフト、モデルの劣化、ユーザー要件の変化などの問題を検知・対応できる。
    • → AIアプリケーションは、「リリースして終わり」ではなく「継続的に育てていく」ことが必要です。ユーザーに使われ続ける中で性能が落ちていないかを見張り続ける必要があります。評価指標を用いることで、継続的なモニタリングが定量的に実現できます。(実際はLangSmith等のダッシュボードを併用するのが一般的です)

評価指標は2つの分類方法がある

  1. 「LLMベース」か「Non-LLMベース」か？
    1. 評価の仕組みによる分類(どう評価するか？の手段による分類)
  2. 「シングルターン」か「マルチターン」か？
    1. 評価対象の対話形式による分類(何を評価するか？の対象による分類)

分類方法①「LLMベース」か「Non-LLMベース」か？

  • LLMベース
    • 評価にLLM（大規模言語モデル）を使用
    • LLMを1回以上呼び出してスコア(評価値)を算出
    • 非決定的（non-deterministic）：同じ入力でも毎回同じ結果とは限らない
    • ただし、人間の評価に近い精度が出るため、信頼性が高い
  • Non-LLMベース
    • LLMを使わず、伝統的な方法（文字列一致、BLEUスコアなど）で評価
    • コストが安く、高速に実行が可能
    • 決定的（deterministic）：同じ入力には毎回同じ結果を返します
    • 一方で、人間の評価との相関が低くなりがちで、補助的に使われるケースが多い

分類方法②「シングルターン」か「マルチターン」か？

  • シングルターン評価
    • ユーザーとAIの1回のやり取りに対して評価を行う
  • マルチターン評価
    • ユーザーとAIの複数のやり取りを通じて評価する
    • 会話エージェントやチャットボットなど、長い対話の品質測定に有効

それぞれの実装方法や継承しているクラスなどは公式ドキュメントを参照ください。これら複数の評価指標を用いることで、LLMアプリケーションの品質を多角的に評価できます。

次に浮かぶ自然な思考の流れとしては、「なぜその2つの分類方法があるか？どういう使い分けをするのか？」なのですが、次のように私は整理しています。

どういう時に、「LLMベース」と「Non-LLMベース」の評価指標を使い分けるのか？を考えると、それぞれの得意不得意で使い分けます。ここで深く関連している、LLM as a judgeの概念やEmbeddingの説明はまた別記事で行いたいと思います。

  1. LLMベースのメトリクスは、「意味の正しさ・人間らしさ」など主観的・文脈依存の評価が得意。ちなみに、LLMベースでも評価できない複雑なものは人間がそのまま行います。現時点だと人間が行う評価も多くの割合を占めます。
    • 例：「この回答は本当に文脈に合ってる？」「人が納得できる説明になってる？」
  2. Non-LLMベースのメトリクスは、「表面的な一致や形式の整合性」など機械的・定量的な評価が得意。ルールベースで単純な処理を高速で行えます。
    • 例：「文字列が何%一致してる？」「正解と似た単語が何個ある？」

また、「LLMベース」か「Non-LLMベース」かは評価システムの設計や実行に影響します。LLMベースだと、評価にもOpenAIやAnthropicなどのAPI設定やPrompt設計が必要ですが、Non-LLMベースなら、ローカル実行できて自動化しやすく、デバッグも簡単です。

次に、「シングルターン」か「マルチターン」を使い分ける状況は単純に評価したいユースケースが全く異なるためイメージが湧きやすいですが、なぜ使い分けるのかという話です。

これも実は結構単純で、「必要なデータ構造や評価方法が異なるから」なんです。それゆえ、それぞれが継承するクラスもメソッドも異なります。

  • シングルターンは単純な{"question": ...,"answer": ...}の形式で評価できる。
  • 一方、マルチターンは{"turns": [{"user": ...,"ai": ...},...],"goal": ...}のように会話履歴と全体目標を持つ。

という風に評価関数(スコアリングメソッド)も違い、single_turn_ascore()とmulti_turn_ascore()が分かれています。

また「評価軸が異なるため、適切なメトリクスも変わる」という理由もあります。

例えば、FAQ応答やRAG回答アプリでは、シングルターン評価で、FactualCorrectness, AnswerRelevanceといった評価指標が重要になります。

一方、カスタマーサポート、タスクエージェントでは、マルチターン評価で、AgentGoalAccuracy, Coherence, Helpfulnessといった評価指標が重要になります。

たとえば、「この会話は目的を達成したか？」というような評価は、シングルターンでは絶対に測れません。雑にいうと、各個別のコンポーネントを見るUnitテストと、ITやE2Eで全体のシナリオを見るテストの違い、みたいなイメージですね。

これらの分類に関しても、1度実際に手を動かしてみるとすぐに理解できるので、ぜひ1度触ってみてください。

Ragasはこれらの評価指標を設計してきましたが、それには次の「メトリクス設計原則(Metric Design Principal)」という基本的な考え方が影響しているようです。自社LLMアプリケーションを評価する際には、そのプロダクトの目的や種類によって、Ragasなどの評価指標を参考にしながらも、自分で評価指標を選択し、時には作り出す必要があります。その評価指標を定める際に参考になる原則なので、少しだけ紹介しておきます。

  • ① 単一側面にフォーカスする（Single-Aspect Focus）
    • 1つのメトリクスは、AIアプリケーションの性能における特定の1つの側面だけを測定するべきです。そうすることで、そのメトリクスが何を意味しているのかが明確になり、行動につながる示唆が得られます。
    • → よくやってしまいがちなものですが、例えば「回答の正しさ」と「自然さ」を一緒に評価しないことが重要ということです。1つの軸(例：関連性、忠実性、簡潔さなど)に絞ることで、改善すべきポイントが明確になります。
  • ② 直感的で解釈しやすいこと（Intuitive and Interpretable）
    • メトリクスは、わかりやすく・解釈しやすい形で設計されるべきです。直感的なメトリクスは、評価結果を関係者に伝えるのが容易になり、正しい意思決定にもつながります。
    • → のものも至極当たり前のことを言っていて、なるべく評価指標はシンプルにしようね、と言っているだけですね。
  • ③ 効果的なプロンプトフローを設計する（Effective Prompt Flows）
    • LLMを使ってメトリクスを設計する場合は、人間の評価に近づけるために賢いプロンプト設計を行いましょう。複雑なタスクは、小さなサブタスクに分けて、それぞれ専用のプロンプトで処理することで、精度と妥当性が向上します。
    • → たとえば「この回答は正しいか？説明は十分か？」という複合評価を、「正確性は？」「網羅性は？」など分解して個別に評価する方が精度が高まります。「困難は分割せよ」の原則に従い、AIアプリケーションの一連の流れをフローに表現し、それぞれ細かく見ていく必要性があります。
  • ④ ロバスト性を持たせる（Robustness）
    • LLMベースのメトリクスでは、望ましい出力例（few-shot）を十分に含めることで、LLMの判断を安定させましょう。文脈や判断基準が明示されることで、より一貫した結果が得られます
    • →「正しい例」「間違った例」を提示しておくことで、モデルが曖昧に解釈せずに適切な評価をしやすくなります。評価の揺れ（non-determinism）を抑える効果もあります。事前に求める答えがあるならば、それを事前に伝えておけば期待値がずれないよという考えですね。アノテーションと同じ考えですね。
  • ⑤ スコアの一貫性と比較可能性（Consistent Scoring Ranges）
    • メトリクスのスコアは、0〜n点など決まった範囲に正規化する（normalize）か、少なくとも一貫した基準に揃えることが重要です。こうすることで、複数のメトリクス間での比較がしやすくなり、フレームワーク全体の整合性も保たれます。
    • → メトリクスAは0〜100点、メトリクスBは−1〜1などだと、比較も可視化も難しくなります。スコアが「高ければ良い／悪ければ悪い」と一目でわかるようにすべきです。これは、実際のLLMアプリケーションは複数の評価指標を用いる他、ドメインエキスパートやPM、QA、開発、あのデータと複数の人間が開発プロセスに関わります。スコアに一貫性を持たせて比較できる状態にしておかないと、複数の人間の中でのコミュニケーションが煩雑になってしまう恐れがあります。

Ragasでは、これらの分類方法や根本的な考え方に基づいた上で、次のように実際にユースケースごとに評価指標を整理しています。

2. Ragasの7つのユースケースごとに分類された評価指標/フレームワーク

現在では、7つのユースケースに対してそれぞれの評価指標やフレームワークが提供されています。

ここまで具体的にLLMの評価指標を具体的に落とし込み、実装方法からサンプルコードを提供している点で、Ragasは非常に意義のあるライブラリだと思います。

各個別ページでは、具体的な実装方法からサンプルコードまでが記載されており、ある程度実践的な内容となっています。指標は随時追加されていっているようです。

7つのユースケースごとに分類された評価指標

https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/

実装やサンプルコードについては量がかなり膨らんでしまうため、次回の記事に譲ります。
次回の記事では、代表的なRAGの評価指標をサンプルとして評価指標を見ていきます。

最後に

箇条書きでまとめます。

  • LLMシステムの成功はLLM品質が鍵を握っており、その品質向上には評価指標とデータセットが大事
  • Ragasはその評価フレームワークの1種で、RAGなど合計7つのユースケースに対して評価指標を提供する他、評価指標に対する根本的な考え方も提供している
  • RagasはLLMによる合成テストデータセット出力にも対応している

次回は、実際にRagasの評価指標を用いてRAGの評価実践や、Ragasの別機能である合成テストデータ生成を一緒にできる記事を執筆する予定です。

DAIJOBUではLLMの品質向上サービス「AI Agent品質担保くん」に力を入れており、AI QAエンジニアやLLMエンジニアを絶賛募集中です。「AI Agent品質担保くん」はすでに大手上場企業やメガベンチャーによる導入が決まっています。新しい品質メトリクス策定や品質向上の仕組み作りは、すごく楽しいです！ぜひ一緒に未来のQA領域を切り開きませんか？

XのDMでもPittaでも超カジュアルにご連絡ください…!!
https://pitta.me/matches/UnCbTvNsdqTY

DM : https://x.com/0xfene

また、弊社では「AI Agent品質担保くん」というBPOサービスで、LLMやAIエージェントのLLMOps、品質保証支援をしております。少しでもご興味がある方は、ぜひお気軽にお問い合わせください！

https://daijobu.io/aiagent/contact

参考文献)
https://docs.ragas.io/en/stable/

https://zilliz.com/blog/rag-evaluation-using-ragas

Discussion