今更聞けないRAGとは？ その実態や評価手法について深掘りしてみた
こんにちは．技術統括の上野です．DAIJOBUでは，2025年3月に「AI Agent品質担保くん」のサービスをリリースし，AIを活用したプロダクトの品質保証のご支援を開始しました．AI Agentとは目的を持って自律的にタスクを遂行するAIを指しますが，そこまで高度でなくても，人からのタスク指示や対話を通じてタスクを遂行する対話型AIについてのご相談も増えています．少し前に流行ったRAG(Retrieval-Augmented Generation)も依然としてニーズがあり、テストについてよくご相談をいただくようになってきました．
そこで今回は，もう今更聞けないRAGとは何なのか，RAGの評価について，研究論文などをもとに一緒におさらいしていきたいと思います！
RAGとは何か？
RAG（Retrieval-Augmented Generation） はLLMを用いたアプリケーションであることはわかるけれど，最近はAI Agentをはじめとしていろいろなものが流行っていてちょっとごっちゃになってしまった…という方もいらっしゃるかもしれません．そもそも，LLMアプリケーションと一口にいっても，人によってイメージするものは異なっている気がします．
取り扱えるタスクの難易度によってLLMアプリケーションを分類している研究[1]があり，こちらがわかりやすかったので簡単に紹介します．
取り扱えるタスクの難易度によってLLMアプリケーションを分類している研究[1]があり，こちらがわかりやすかったので簡単に紹介します．
| タスクの種類 | 対応技術 |
|---|---|
| Level 1: Explicit Fact Queries 回答をデータソースから直接取得可能な質問を扱う | RAG |
| Level 2: Implicit Fact Queries 直接回答を取得できず，論理的な推論や一般常識などが必要になる質問を扱う | Iterative RAG (Planning-based RAGなど）Graph/Tree-based RAG |
| Level 3: Interpretable Rationales そのドメインを理解し，根拠を積み上げ，文脈に合わせて回答する必要のある質問を扱う | Fine TuningやCoT (Chain-of-Thought)Prompting |
| Level 4: Hidden Rationales 暗黙の前提や深いドメイン知識が必要な質問を扱う | Offline Learning, in-context learning, Fine tuning |
この表は，タスクを難易度によってLevel1~4に分類しており，それらを遂行するための対応技術を右側のカラムに示しています．表を見てわかる通り，RAGはAI Agentのように高度なタスクを遂行するものではありません．
RAGはクエリの入力を受け付け，そのクエリの回答になりうるものをデータソースから検索し，LLMで回答を生成して出力する技術構成です．人間にとって使いやすいように，RAGを用いた上で自然言語による対話型で回答が得られるようシステム化されていることも多いでしょう．
汎用型LLMに用いられる学習データはある時点までのスナップショットであるため，それ以降に発生した事項については回答することができません．LLMに外部の追加リソースを接続し，検索することによってその課題に対処しようとするのがRAGの思想です[1]．初期はRAG専用にLLMをトレーニングすることが考えられていたようですが，今ではデータの元となるドキュメントなどを入力するだけでもそれなりの精度があるとされています[1]．LLMアプリケーションの回答の精度をあげる方法の一つがRAGであるともいえるのですね．
RAGの活用方法として最も多いのは特定ドメインの対話型Q&Aシステムです．最近では，DifyのようなRAGを簡単につくれるツールも登場しています．
RAGの仕組み
RAGの構成は以下のように表されます．
大まかにリソースの検索部分（Retrieval）と生成部分（Generation）にわかれるのが特徴です．
RAGの仕組み概要（[8]をもとに作成）
RAGの評価指標
RAGの構成要素をご紹介しましたが，これらを見て容易に想像できる通り，RAGの精度は大まかに検索部分と回答生成部分に影響されることになります．たとえば，どんな外部のデータソースを使うのか，データソースを正しく前処理して，LLMが扱える形式にできるのか，検索をどのような戦略で行うのか，LLMにどのモデルを使用するのか，どんなプロンプトを入力するのか，回答をどの程度正しく生成できるかなどです[1,2]．
いくつかのRAG研究においては，RAGの回答を評価する指標として以下のような項目が挙げられています．
検索性の評価指標
- Context Relevance
- 提示された文脈が，どの程度適切で与えられた質問に答えるのに役立つ情報を含んでいるかの度合い[2,3,8]
- Accuracy
- 検索できた情報が他の情報と比較してどの程度正確なのかの度合い[8]
- RAGASのContext Recall[9]に近い概念
回答生成の評価指標
- Answer Faithfulness [3,8]
- 回答が情報ソースにどれだけ忠実かの度合い
- Answer Relevance[3,8]
- 提示された回答が，入力クエリに沿っているかの度合い．関連するトピックを支持通りに回答しているか
- Answer Correctness[8]
- 常識的な回答と比較してどの程度事実に沿って適切な回答ができているかの度合い
- Latency[8]
- 情報を検索し応答する速度
- Diversity[8]
- システムが多様な関連文書を検索し、多様な応答を生成するか
- Noise Robustness[8]
- システムが応答の品質に影響を与えることなく、無関係な情報をどれだけうまく処理できるか
- Negative Rejection[8]
- 利用可能な情報が不十分な場合に、システムが応答を控えることができるか
- Counterfactual Robustness[8]
- 潜在的な誤情報について警告された場合でも、システムが誤った情報を識別して無視する能力
評価する生成部分は既存のモデルを使うので，検索の精度向上や十分なデータセットを用意することに注力する戦略をとることも多いと考えられます．
評価の方法
RAGによる回答が期待通りなのかを確認する方法には，以下のようなものがあります．
- 自動判定
- 前述の評価指標を算出し，それに基づく評価を行う方法．
- RAGASやARES，CRAGなどのフレームワークでは自動判定を一部採用[2,3,7]．
- 人間
- 入力クエリに対する回答になっているかを専門家が判断[4]
- LLM-based Evaluation (LLM-as-a-Judge)
- 回答をLLMに入力して判定[3,5,6]
RAGシステムの評価では，人間のエキスパートが評価していたり，LLM-as-a-Judgeと人間の判断を比較していたりする研究も散見されます[7,8]．膨大な入力クエリの回答を確かめなければならないとは，気が遠くなりそうです．
最近では，回答に対する評価スコアを出してくれるlangsmithやlangWatchといったツールが登場してきています．しかし，まだ人間が準備しなくてはいけないことがたくさんあります．たとえば，どのような入力クエリを準備すれば十分なのかは困難な問いです．実際には社内ナレッジのQ&Aシステムのようにユースケースが限定的である場合が多いので，利用シーンに応じた入力パターンを洗い出すことのほうが実用的でしょう．
回答についても，最終的に人の目で確かめることが多いと耳にします．また，何のパラメータを変えるとどのコンポーネントに影響するのかについては，実際の開発では精度向上のためにとても知りたい情報だと思われるのですが，実際にはブラックボックス化しているのが実情のようです．
こういったプロセスを切り出して効率化していくのも大いに役立っていきそうです．
以上，RAGについてここ最近調べてみたことをまとめてみました．紹介した論文はarXivで公開されているものですが，査読が済んでいないものも含まれますので，その点をご了承ください．また，情報が古いものもあると思いますので，随時アップデートしていければと思います．
興味があるのでもっと話を聞いてみたい方，あるいは「素人質問で恐縮ですが」と言いたい方は，ぜひカジュアル面談でお待ちしております．
参考文献)
[1]Zhao, S., Yang, Y., Wang, Z., He, Z., Qiu, L. K., & Qiu, L. (2024). Retrieval augmented generation (rag) and beyond: A comprehensive survey on how to make your llms use external data more wisely. arXiv preprint arXiv:2409.14924.
[2]Es, S., James, J., Anke, L. E., & Schockaert, S. (2024, March). Ragas: Automated evaluation of retrieval augmented generation. In Proceedings of the 18th Conference of the European Chapter of the Association for Computational Linguistics: System Demonstrations (pp. 150-158).
[3]Saad-Falcon, J., Khattab, O., Potts, C., & Zaharia, M. (2023). Ares: An automated evaluation framework for retrieval-augmented generation systems. arXiv preprint arXiv:2311.09476.
[4]Ji, Z., Lee, N., Frieske, R., Yu, T., Su, D., Xu, Y., ... & Fung, P. (2023). Survey of hallucination in natural language generation. ACM computing surveys, 55(12), 1-38.
[5]Zheng, L., Chiang, W. L., Sheng, Y., Zhuang, S., Wu, Z., Zhuang, Y., ... & Stoica, I. (2023). Judging llm-as-a-judge with mt-bench and chatbot arena. Advances in Neural Information Processing Systems, 36, 46595-46623.
[6]Gu, J., Jiang, X., Shi, Z., Tan, H., Zhai, X., Xu, C., ... & Guo, J. (2024). A survey on llm-as-a-judge. arXiv preprint arXiv:2411.15594.
[7]Yang, X., Sun, K., Xin, H., Sun, Y., Bhalla, N., Chen, X., ... & Dong, X. (2024). Crag-comprehensive rag benchmark. Advances in Neural Information Processing Systems, 37, 10470-10490.
[8]Yu, H., Gan, A., Zhang, K., Tong, S., Liu, Q., & Liu, Z. (2024, August). Evaluation of retrieval-augmented generation: A survey. In CCF Conference on Big Data (pp. 102-120). Singapore: Springer Nature Singapore.
[9] Context Recall - RAGAS https://docs.ragas.io/en/latest/concepts/metrics/available_metrics/context_recall/
Discussion