RAGAS
読み: ラガス
RAGASとはRAG品質を定量評価
かんたんに言うと
料理の味見をシェフの勘に頼るのではなく、塩分濃度や旨味成分を数値化してレシピを修正するためのテイスティングマシンのようなものである。
回答のズレの原因を特定できないRAGの品質問題とRAGASの解剖手法
社内規程を読み込ませたRAGを法務部に納品したとしよう。担当者は「なんか回答がズレてるんだよね」と言う。何がどうズレているのか。検索で引っ張ってきたドキュメントが間違っているのか、それともLLMの要約プロセスでハルシネーションを起こしたのか。原因を特定できなければチューニングのしようがない。RAGASはまさにこのブラックボックスを解剖するために存在する。これまでは開発者がプロンプトを微調整しては目視で確認するという泥臭い作業を繰り返していた。Claude 3.5 SonnetやGemini 1.5 Proを使えばもっと賢くなるのではないかとモデルをすげ替えても、結局は感覚値の域を出ない。RAGASを導入すれば、検索の精度と生成の精度を切り分けて数値化できる。どこにがあるのか一目でわかるようになるのである。
生成AIの回答精度を測定する主要指標と評価プロセス
RAGASが提供する指標は主に4つある。Faithfulness、Answer Relevance、Context Precision、Context Recallである。横文字が並ぶが、要するに「嘘をついていないか」「質問に答えているか」「検索結果の上位に正解があるか」「必要な情報を網羅しているか」を測る。たとえば製造業の工場ラインでトラブルシューティング用のRAGを動かす場合。マニュアルにない手順をでっち上げるのは致命傷になる。ここではFaithfulnessのスコアが絶対的な意味を持つ。評価の仕組み自体はシンプルである。評価用のLLMを用意し、質問、回答、検索されたコンテキストのセットを食わせて採点させる。ただ、この評価用LLMに何を使うかは悩ましい。GPT-4oをフル稼働させれば精度は出るが、APIの請求書を見て経理部門が青ざめることになる。
現場での活用シナリオと連携可能な主要AIツール
開発現場でRAGASをどう組み込むか。LlamaIndexやHaystackといったフレームワークで構築したパイプラインの末尾に、評価プロセスとして接続するのが定石である。最近はDifyのようなノーコードツールでRAGを組むケースも増えたが、裏側のログをエクスポートしてRAGASに流し込む運用も組める。物流部門の配車計画アシスタントを開発した時のこと。ドライバーのシフトや天候データを読み込ませたが、回答の精度が日によってブレる。RAGASで継続的にスコアを計測したところ、特定の気象条件のドキュメントを検索する際のContext Recallが極端に落ちていることが判明した。チャンクの切り方を修正し、ベクトルデータベースの検索アルゴリズムをハイブリッド検索に切り替える。その結果を再びRAGASで測る。このサイクルを回せるかどうかが、実運用に耐えるシステムを作れるかの分水嶺になる。
機械的な評価の利点と運用上の落とし穴
目視テストをなくせるのは大きい。しかし、RAGASを導入すれば万事解決とはいかない。最大の落とし穴は、評価用LLM自体の日本語の解釈能力である。英語のベンチマークでは優秀でも、日本語の微妙なニュアンスや業界特有の専門用語を評価させると、途端にトンチンカンな採点をしてくるモデルは少なくない。CohereのCommand R+あたりは日本語に強いと言われるが、それでも自社のドメイン知識を持たせなければ正確なジャッジは難しい。結局のところ、RAGASのスコアを鵜呑みにしていいのかという疑問は常に付きまとう。高いスコアが出たからといって営業現場で使い物になるとは限らない。現場の肌感覚とRAGASのスコアの乖離をどう埋めるか。ここはエンジニアの腕の見せ所であり、同時に最も判断が分かれる部分でもある。
自社のAIプロジェクトに組み込むべきかの判断基準
すべてのRAG開発にRAGASが必要なわけではない。社内FAQの検索程度なら、利用者のフィードバックボタンで十分である。わざわざ重厚な評価フレームワークを導入してAPIコストを垂れ流す意味はない。だが、人事部の労務相談AIや、経理部の税務処理アシスタントのように、回答の正確性がコンプライアンスに直結する領域では話が別である。ここでは「なんとなく良さそう」は通用しない。PoCの段階から品質を担保する客観的な指標が求められる。導入のハードルは決して低くない。評価用のデータセットをどう用意するのか。誰がその正解データを作るのか。現場の担当者に協力を仰げば「また仕事が増えるのか」と嫌な顔をされるだろう。それでもやる価値はあるのか。自問してみてほしい。
当社の見解
当社はAI長期記憶システムを自社開発・運用している。開発のきっかけは、AIと経営戦略の壁打ちで出した結論がセッション切れで消えたことで絶望を感じた。1日かけて議論してきたことを振り返り、では事業計画書に落とし込むように指示を出したところ、「そのような記録はありません」と言われたことで、強烈な危機感を覚えこれは何としても解決しなければならない問題だと感じた。記憶がないAIは毎朝記憶喪失になる新入社員と同じだ。記憶があるAIは、前提条件を理解した上で本題に入れる。短いプロンプトで済むようになり、「前に言ったように実行して」と曖昧で短いプロンプトでも業務を遂行してくれる。同じことを繰り返し伝える回数も減り、開発業務でも同じミスを繰り返しにくくなり、人間の手戻りが減り、ストレスも減る。AIで本当に業務の質を上げるならば、記憶はマストである。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。