RAGシステムの評価の課題 と Langfuseを活用したアプローチ

RAGシステムの評価の課題 と Langfuseを活⽤したアプローチ ガオ株式会社 嘉⾨ 延親 (KAMON Nobuchika)

OUR SERVICES 吉積ホールディングスグループ 代表取締役 嘉⾨ 延親 Langfuse 国内/APAC 唯⼀の パートナー企業 GenAIOps / LLMOps ⽣成AIアプリケーションの利 ⽤状況の可視化/改善 2024年10月以降、日本とアジ アで唯一商用ライセンスの 販 売・導入・サポートなど を取り ビジネスのROIを最⼤化させ We’re Hiring !!! Langfuse るための⽣成AI運⽤ 扱う 正規パートナー GenAI Professional Service アイデア創出 , PoC〜本番実装 そして運用まで、生成 AI活用の 全フェーズをカバーするプロ フェッショナルサービス

● 世界中の企業‧開発者から圧倒的な⽀持をもつLLM Engineering Platform ● ⽇本国内でも実績多数、コミュニティが急成⻑中 ● ガオ株式会社 が国内/APAC 唯⼀の再販‧サポートを提供 ● Trace (可視化), プロンプト管理, ⾃動/⼿動評価, データセット管理 etc

RAGにおける評価の課題

課題設定 RAGの評価は難しい、具体的には? ● 既存の評価⼿法の特徴整理 ● それらには何が⽋けているのか ● どのようにそれに対処すべきなのか

RAGシステムの評価 (Human annotation) 評価⼿法 (1) Human annotation (⼈的評価) メリット (Pros) デメリット (Cons) - 最も信頼性が⾼い - ⾼コスト‧低速 - ドメイン知識を前提にニュアンス の判断も可能 - スケールしない （最低でもガイドライン整備が必要） - 複雑な評価もできる - 評価者ごとのバラツキは否めない & 単⼀の評価者 でもミスは出る

RAGシステムの評価 (LLM as as Judge) 評価⼿法 (2) LLM as a Judge メリット (Pros) - ⾼速‧スケーラブル デメリット (Cons) - Retrieveを無視し“知識で回答”する危険性 しかもモデルも間違えてることもある - 定性評価の⾃動化が可能 (LLMにおける⾃ 動評価) - 多数テストの⼀括評価に向く - プロンプトの作り込みは難しい & プロンプト隔離（内部知識禁⽌）の設計が必須 - 何をもってアウトプットが正解は分からない

RAGASとは何か？（RAG評価の⾃動化フレームワーク） RAGAS = RAG Assessment RAGシステムを評価するためのPythonオープンソースライブラリ 1. リファレンスフリー評価 ● ● 正解データ(Ground Truth)が不要 本番環境のトレースをそのまま評価可能 2. モデルベース評価 ● ● LLMを使⽤して⾃動的に品質を評価 多⾓的な評価指標を提供 3. Pythonエコシステムとの統合 ● ● OpenAI、Langchain、LlamaIndexなどと連携 Pytestなどと組み合わせて⾃動評価パイプラインを構築可能

RAGASとは何か？（RAG評価の⾃動化フレームワーク） RAGAS 主要メトリクス ● Context Recall：必要な⽂書を取得できたか ● Context Precision：取得⽂書が質問に関連しているか ● Faithfulness：回答が取得した⽂書に沿っているか ● Answer Relevancy：質問と回答の関連度

RAGASとは何か？（RAG評価の⾃動化フレームワーク） RAGAS 主要メトリクス ● Context Recall：必要な⽂書を取得できたか ● Context Precision：取得⽂書が質問に関連しているか ● Faithfulness：回答が取得した⽂書に沿っているか ● Answer Relevancy：質問と回答の関連度 → そもそも、その⽂書が本当にあっているのか？ RAGASには分からない

RAGASの限界 評価⼿法 (3) RAGAS メリット (Pros) デメリット (Cons) - RAG特化のメトリクス とってきた情報に対して論理的な 判定は⼀定できる - “Retrieveが正しいのに回答が微妙に間違う”ケー スを検知できない - 正解は知らないので、回答の妥当性は評価不可 - CI/CDパイプラインに組み込める - ⾃動化しやすい ● ⼈間の評価はスケールしない、⾼コスト、⼈間なのでうっかり間違うこともある ● LLM as a judgeはモデルがプロンプトに沿った評価であり、事実判定はできない ● RAGASも同様に、回答の妥当性はやはり評価できない

RAGASの限界 評価⼿法 (3) RAGAS メリット (Pros) デメリット (Cons) - RAG特化のメトリクス とってきた情報に対して論理的な 判定は⼀定できる - “Retrieveが正しいのに回答が微妙に間違う”ケー スを検知できない - 正解は知らないので、回答の妥当性は評価不可 - CI/CDパイプラインに組み込める - ⾃動化しやすい ● ⼈間の評価はスケールしない、⾼コスト、⼈間なのでうっかり間違うこともある ● LLM as a judgeはモデルがプロンプトに沿った評価であり、事実判定はできない ● RAGASも同様に、回答の妥当性はやはり評価できない

RAGの精度評価に事実を組み込む

[実ユースケース] RAG 判定に正解のデータを使う⼿法 Langfuseの機能を利⽤ ● Trace: ユーザーの実際のInput / Outputを記録 ● Datasetを構築 a. Input: ユーザーからの問い合わせ内容 や、管理者が想定する質問 b. Expected Output: i. expected_answer: 最終的に期待する答え ii. ground_truth: その根拠となる情報ソース ● ● Datasetを使ってアプリケーションでRAGを実⾏ その結果をRAGASに通して、スコアリング、Traceとして出⼒

1. Trace (LLMアプリの可視化と分析) 処理の可視化 Debug User Input LLM Output

2. Prompt Management (プロンプト管理) 管理者や業務担当者が Agentのコードを触らずにプロ ンプトを更新‧管理 Promptはハードコードではなく 世代管理や性能管理ができるように Langfuse側で保管し、Agent側からFetchして利⽤

3. Dataset (ユーザーインプット + 期待するアウトプットのセット作成) ユーザーのInput を Dataset (Q)に登録 正解例やGround truth (RAGの中にある情報 )を Expected output (A) としてDatasetに登録

3. Dataset を利⽤したRAGアプリケーションの実⾏ ④ ③ ③ ② ① ① Langfuse “Custom experiment” を実⾏ ② 1が、RAG application (API) を実⾏ ③ その際にプロンプト取得、実⾏⽤の INPUT (元データはユーザのTraceなど） や Expected output をDatasetから取得 ④ RAGから③にふさわしいデータをRetrieval して、LLMが回答を⽣成

3. Dataset を利⽤したRAGアプリケーションの実⾏ ⑤ 実⾏結果を Traceに⼊れる ⑥ 実⾏結果を RAGAS に送り、評価 ⑦ Score API で Trace に⼊れる ⑧ 結果を Langfuse UI で確認 ⑤ ⑥ ⑧ ⑦

Dataset 例

Dataset -> Remote experiment (Langfuse外部のAPIなどを実⾏)

実⾏例 (成功: Output が Expected outputの通り)

実⾏例 (失敗: ⼀⾒正しいが、Expected outputと異なる)

Key takeaways

Key takeaways RAGの評価は簡単ではない - ⼈的評価は正確だが属⼈であるが故の課題がある - LLM as a judgeは簡単に活⽤できる⼀次評価として有効 - RAGASは有益、だが事実を持たない評価という点は同じ Langfuseを活⽤した精度評価⼿法 - まずはデータセットを作る - Experimentを実⾏ - 結果をRAGASに渡して、精度測定をする - LangfuseはOSSでほぼすべての機能をカバーしているので直ぐに試せます！