𝗛𝗼𝘄 𝗜 𝗦𝗲𝘁 𝗨𝗽 𝗥𝗔𝗚 𝗘𝘃𝗮𝗹𝘀 𝗶𝗻 𝗖𝗜/𝗖𝗗 𝘁𝗼 𝗖𝗮𝘁𝗰𝗵 𝗥𝗲𝗴𝗿𝗲𝘀𝘀𝗶𝗼𝗻𝘀

リグレッションを検知するためのCI/CDにおけるRAG評価のセットアップ方法

PRが届く。RAG評価は1分で完了し、緑のチェックマークが表示される。コードをマージする。

12時間後、サポートチケットが届く。

特定のクエリタイプに対して、リトリーバーがトップ1のチャンクを変更してしまった。あなたの30個のサンプルデータセットには、そのケースが含まれていなかった。テストスイートは間違った箇所をチェックしていたため、緑のままだった。

ほとんどのRAGゲートは、単なるスモークテストに過ぎない。小さなデータセットと固定の閾値を使用している。平均値が一定の数値を上回れば、パスする。しかし、データセットが代表性を欠いており、閾値がノイズを考慮していないため、これは失敗する。

優れたゲートには、スピード、低コスト、統計的有意性の3つが必要だ。通常、得られるのは2つだけである。

以下は、信頼できるRAGゲートのための私のフレームワークである。

3層構造

1. すべてのプッシュ（PRゲート）

• NLIによる忠実性（faithfulness）や主張の裏付け（claim support）のような、安価な分類器を使用する。
• 引用の妥当性やレイテンシに対して、決定論的なチェックを行う。
• 3分以内に100〜200個の例を実行する。
• これによりマージをブロックする。

2. 夜間のメインブランチ（フルスイープ）

• バージョン管理されたデータセットに対して、フルLLMジャッジ・スタックを実行する。
• これには15〜30分かかる。
• これにより、次のカナリアリリースへの昇格をブロックする。

3. カナリア（本番モニタリング）

• 本番トラフィックの5〜10%に対して、同じルブリックを実行する。
• 移動平均のドリフトに対してアラームを設定する。

5つのコア・ルブリック

システムがどこで壊れているかを正確に特定するために、ルブリックをレイヤーごとに分割する：

• Context Relevance（コンテキストの関連性）：これが低下し、Groundedness（根拠性）が高いままなら、リトリーバーがリグレッションを起こしている。
• Groundedness（根拠性）：これが低下し、Context Relevanceが高いままなら、ジェネレーターがリグレッションを起こしている。
• Answer Relevance（回答の関連性）
• Citation Validity（引用の妥当性）
• Retrieval Recall（検索リコール）

注：検索リコールをスコアリングするには、正解のドキュメントID（expected_chunks）を使用する必要がある。これがないと、検索のバグを見つけることができない。

統計的ゲート

単に固定値でゲートをかけない。固定の閾値では、緩やかなドリフトを見逃してしまう。2つの閾値を使用する：

• 明らかな破損に対する絶対的な下限値（例：Groundedness ≥ 0.85）。
• 7日間の移動ベースラインに対するデルタゲート。

ウェルチのt検定のような統計的検定を使用する。低下が統計的に有意であり、かつ無視できないほど大きい場合にのみ、PRを失敗させる。これにより、誤検知（false alarms）によって開発者がゲートを無視してしまうのを防ぐ。

最も重要なルール

ベースラインは、固定された数値ではなく、ローリング形式のプロダクション・ウィンドウである必要があります。

プロダクションデータが変化すれば、データセットも変化しなければなりません。失敗しているプロダクションのトレースを抽出し、それらをクラスタリングして、評価セット（eval set）へと昇格させます。これにより、ゲートが学習システムへと進化します。

出典: https://dev.to/kartik-nvjk/how-i-set-up-rag-evals-in-cicd-so-they-actually-catch-regressions-46hb

オプションの学習コミュニティ: https://t.me/GyaanSetuAi