RAGASとは

RAGAS
読み: ラガス

RAGASとは、企業が独自に構築したRAGシステムの回答精度や検索品質を定量的に測定

読み: ラガス

企業が独自に構築したRAGシステムの回答精度や検索品質を定量的に測定し、どこに問題があるのかという改善点を可視化するためのオープンソース評価フレームワークである。

かんたんに言うと

料理の味見をシェフの勘に頼るのではなく、塩分濃度や旨味成分を数値化してレシピを修正するためのテイスティングマシンのようなものである。

回答のズレの原因を特定できないRAGの品質問題とRAGASの解剖手法

社内規程を読み込ませたRAGを法務部に納品したとしよう。担当者は「なんか回答がズレてるんだよね」と言う。何がどうズレているのか。検索で引っ張ってきたドキュメントが間違っているのか、それともLLM要約プロセスでハルシネーションを起こしたのか。原因を特定できなければチューニングのしようがない。RAGASはまさにこのブラックボックスを解剖するために存在する。これまでは開発者がプロンプトファインチューニングしては目視で確認するという泥臭い作業を繰り返していた。Claude 3.5 SonnetGemini 1.5 Proを使えばもっと賢くなるのではないかとモデルをすげ替えても、結局は感覚値の域を出ない。RAGASを導入すれば、検索の精度と生成の精度を切り分けて数値化できる。どこにがあるのか一目でわかるようになるのである。

RAGASの評価フロー

生成AIの回答精度を測定する主要指標と評価プロセス

RAGASが提供する指標は主に4つある。Faithfulness、Answer Relevance、Context Precision、Context Recallである。横文字が並ぶが、要するに「嘘をついていないか」「質問に答えているか」「検索結果の上位に正解があるか」「必要な情報を網羅しているか」を測る。たとえば製造業の工場ラインでトラブルシューティング用のRAGを動かす場合。マニュアルにない手順をでっち上げるのは致命傷になる。ここではFaithfulnessのスコアが絶対的な意味を持つ。評価の仕組み自体はシンプルである。評価用のLLMを用意し、質問、回答、検索されたコンテキストのセットを食わせて採点させる。ただ、この評価用LLMに何を使うかは悩ましい。GPT-4oをフル稼働させれば精度は出るが、APIの請求書を見て経理部門が青ざめることになる。

現場での活用シナリオと連携可能な主要AIツール

開発現場でRAGASをどう組み込むか。LlamaIndexHaystackといったフレームワークで構築したパイプラインの末尾に、評価プロセスとして接続するのが定石である。最近はDifyのようなノーコードツールでRAGを組むケースも増えたが、裏側のログをエクスポートしてRAGASに流し込む運用も組める。物流部門の配車計画アシスタントを開発した時のこと。ドライバーのシフトや天候データを読み込ませたが、回答の精度が日によってブレる。RAGASで継続的にスコアを計測したところ、特定の気象条件のドキュメントを検索する際のContext Recallが極端に落ちていることが判明した。チャンクの切り方を修正し、ベクトルデータベースの検索アルゴリズムをハイブリッド検索に切り替える。その結果を再びRAGASで測る。このサイクルを回せるかどうかが、実運用に耐えるシステムを作れるかの分水嶺になる。

機械的な評価の利点と運用上の落とし穴

目視テストをなくせるのは大きい。しかし、RAGASを導入すれば万事解決とはいかない。最大の落とし穴は、評価用LLM自体の日本語の解釈能力である。英語のベンチマークでは優秀でも、日本語の微妙なニュアンスや業界特有の専門用語を評価させると、途端にトンチンカンな採点をしてくるモデルは少なくない。CohereのCommand R+あたりは日本語に強いと言われるが、それでも自社のドメイン知識を持たせなければ正確なジャッジは難しい。結局のところ、RAGASのスコアを鵜呑みにしていいのかという疑問は常に付きまとう。高いスコアが出たからといって営業現場で使い物になるとは限らない。現場の肌感覚とRAGASのスコアの乖離をどう埋めるか。ここはエンジニアの腕の見せ所であり、同時に最も判断が分かれる部分でもある。

自社のAIプロジェクトに組み込むべきかの判断基準

すべてのRAG開発にRAGASが必要なわけではない。社内FAQ自動化の検索程度なら、利用者のフィードバックボタンで十分である。わざわざ重厚な評価フレームワークを導入してAPIコストを垂れ流す意味はない。だが、人事部の労務相談AIや、経理部の税務処理アシスタントのように、回答の正確性がコンプライアンスに直結する領域では話が別である。ここでは「なんとなく良さそう」は通用しない。PoCの段階から品質を担保する客観的な指標が求められる。導入のハードルは決して低くない。評価用のデータセットをどう用意するのか。誰がその正解データを作るのか。現場の担当者に協力を仰げば「また仕事が増えるのか」と嫌な顔をされるだろう。それでもやる価値はあるのか。自問してみてほしい。

当社の見解

当社はAI長期記憶システムを自社開発・運用している(2026年4月現在、1,655件の記憶データを蓄積)。この仕組みにより、AIが過去3ヶ月分の経営判断や設計方針を文脈ごと保持し、「前にも同じ話をしましたよね」という手戻りが激減した。セッションが切れても議論の続きから再開できるため、壁打ち相手としてのAIの価値が根本的に変わった。技術的にはCognee MCPサーバーによる記憶保存と、FastEmbed(ONNX Runtime)+ LanceDBによる非常駐型ベクトル検索(検索レイテンシ8ms、GPU不要)を採用。Hindsight(LongMemEval 91.4%精度)やomega-memoryなど複数の既製品を実環境で検証・棄却した上での選定であり、「個人PCでもエンタープライズでも負荷なく動く軽量さ」を最優先に設計している。

同じ失敗を二度としないAIエージェント

今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。

当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。

古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。

相談する