最近RAGについて勉強しています。
今回はRAGアプリケーションの開発フローについて勉強してみようと思います。
RAG開発でありがちなこと
初期実装の後の改善で躓く
RAGでそれっぽい応答ができるようにするのは、実はそれほど難しくありません。 LangChainやLlamaIndexを使用すればそれほど大きくない量のコードで構築することができます。
一度作ったRAGを改善しようと思う際には、さまざまなことを考える必要があります。
- そもそも今のどれくらい良い？
- RAGの良さってどんな指標で測ればいいのか？
- どうやってその指標を測定したら良い？
- 評価用のデータセットをどうやって準備する？
上記のような一つずつ解決して、ようやく改善が始まります。 改善を始めてからも悩みはつきません。
- 応答を改善するにはどこに手を入れれば良い？
- たくさん修正を入れてしまったけど、今の精度はどれくらい？
- あのときどんな精度だったっけ？
- いろいろ実験してみたけど結局どれが一番良いんだっけ？
あくまで例ではありますが、似たようなことを考える人も意外といるんじゃないでしょうか。
「あっちで作ったときはうまくいったよ？」
RAGアプリケーションを1つだけ作るのであれば問題にならないかもしれませんが、異なるユーザー・異なるコンテキストに対して別々にRAGを作る場合には問題が起きるかもしれません。
ユーザーや扱う文書の形式によって、RAGの応答品質は大きく変動します。 ユーザーがどんな文書を扱っているか、その量がどれくらいなのかによって、ドキュメントの前処理やchunk分割を考えることになりますし、ユーザーがどんな質問をするかによっても応答品質は左右されます。
どこかで作ったRAGアプリケーションでの工夫が、別のところでは全く役に立たないなんてことにもなりかねません。 「あっちで作ったときはうまくいったよ？」みたいな話を聞くことがあるかもしれませんが、それを鵜呑みにしてうまくいくことは少なくとも現段階ではそこまで多くないと思います。
RAGの良さを測る必要性
このように、RAGアプリケーションを継続して改善していくにはRAGアプリケーションの良さを開発者サイドで理解・定義し、測定し、その指標が良くなる方向に向かって改善を行うのが良さそうだと考えられます。
現在でもRAGの改善手法をネットを探せばたくさん出てきますし、現在も世界中で盛んに新しい手法が研究開発されたりしています。 ただし、それらが目の前で開発しているドメインに適するかはわかりません。 見つけた最適化テクニックを適用した際に、それで本当に自分で作っているRAGが良くなったのかを評価するフェーズがやってきます。
そのため、RAGの開発ではその性能の評価が一つのポイントになると考えられます。
Metrics-Driven Development
RAG開発で起きがちなケースについて紹介したところで本題のMetrics-Driven Development (MDD)について紹介していきたいと思います。
明示的にMDDの文言を表明しているのは探したところRagasだけではあるものの、至る所で似たような主張・議論が行われているので、呼び方こそ違えど考え方は同じと考えて良さそうです。
メトリクスを測り、改善する
Ragasでは重要なメトリクスを長期にわたって継続的に測定し、それに基づいて改善を行う Metrics-Driven Developmentの考え方を取り入れ、継続的な開発を促進することを目指しています。
おそらくMDDで肝になってくるのは下記の2点です。
- 評価: RAGアプリケーションについて精度を定義し、数値評価する
- モニタリング: 評価した結果を継続的に記録・監視する
これらを通じて、評価結果が良くなる方向に向かって改善を進めるのがRagasで想定されている開発の進め方のようです。
Test early and often
LangSmithのドキュメントでも似たような話が推奨されています。
早期に頻繁にテストを行うことで想定されるユースケースを満足することを確認しながら開発を進めることができるため、こうした継続的な評価を行うことを推奨しています。
この評価ですが、すべてのアプリケーションで統一的なものではなく、使用するドメインによって評価する指標も異なる可能性があります。 RAGで使用するデータセットやドメインによって何を重視するか異なる場合がありますし、場合によっては「絶対に間違えてはいけない」パターンなどがあったり、テストケースによって重要度が異なる場合もあるかもしれません。
こうしたテスト設計を早期に行い、開発と合わせて評価も頻繁に行うことが想定されているようです。
MDDの流れ
おおよそMDDの流れはこのような形になると思います。
- メトリクスのアイデアを作成
- テストデータセットの調達
- 採点基準（採点プロンプト）の作成
- LLMを使ったLLMサービスの採点
- 上記の反復を通じた評価基準の見直し
多分こんな感じで精度改善と並行して評価評価の見直しを並行して行う形になるんだと思います。
このような開発をチームで行うことを考えると、評価用のデータセットや評価結果を共有管理して誰でもアクセス・再現できるようにしておくことも同時に求められます。 こういったときに、LangSmithなどのサービスが真価を発揮するんだと思います。
テストデータセットの調達
上記のフローで難しいのはテストデータセットの調達でしょう。 これもドメイン次第としか言いようがありませんが、ある程度の指針は定めることができます。
評価にはおおよそ下記情報が必要になります。
- 問題と回答
- ユーザーのクエリ
- 真実の答え
- RAGの出力
- 検索されたコンテキスト
- 生成されたレスポンス
これを踏まえて、代表的なユーザーのクエリとしては下記のようなものになると思います。
- 頻度の高い質問
- RAGのユースケースで最も利用される質問
- コンテキスト依存の質問
- retrieveの結果が正しくないと回答できない質問
- 外れ値の質問
- 「回答できない」と回答するのが正しい質問
- その他
- 数、キーワードに関する質問など、ドメインに依存した質問
こういった切り口で無作為ではなく設計されたテストデータセットを調達し、それらを満たすように改善を行うのが良いと考えられます。
参考文献
この記事を書くにあたって下記の文献を参考にさせていただきました。
- 社内Slack Botを改善するためにRagasでRAGを評価する｜QunaSys
- Metrics-Driven Development | Ragas
- Recommendations | 🦜️🛠️ LangSmith
- Metric-Driven Development of a RAG system
- Gather blog
感想
テスト駆動開発ならぬメトリクス駆動開発が一部で言われているので、その紹介でした。 「評価が重要」という話はRAGに関わらずLLM全般に言えると思いますが、だからこそ評価を含めた開発を行っていこうという雰囲気が界隈でも求められているように感じるので、今後もこういったところが整備されていくんだろうなと思いました。
