MLOps

RAG評価基盤の作り方：精度・再現率・運用コストを同時に最適化する実践手順 RAG（Retrieval Augmented Generation）は導入が進んでいますが、運用で最も難しいのは「改善したつもり」が頻発する点です。embedding モデルを変えた、chunk サイズを変えた、reranker を追加した。どれも良さそうに見えるのに、ユーザー満足は上がらない。このギャップを埋めるのが評価基盤です。 本記事では、RAG を継続改善するための評価パイプラインを、データセット設計から CI 統合まで具体的に解説します。 RAG評価で見るべき3層 RAG の品質は 1 指標では測れません。最低でも次の3層を分けて評価します。 Retrieval層: 正しい文書を取れているか Generation層: 回答が正確で有用か System層: レイテンシ・コスト・安定性 この分離がないと、生成品質低下の原因が retrieval なのか prompt なのか判別できません。 ステップ1：評価データセットを設計する 1-1. 問い合わせカテゴリを分割 例として次の5カテゴリに分けます。 定義確認（用語説明） 手順質問（How-to） 例外対応（エラー解決） 比較検討（A vs B） 根拠提示（出典必須） カテゴリごとに難易度と重要度を持たせ、偏りを防ぎます。 1-2. 正解の持ち方 正解は「理想回答1つ」では不十分です。RAGでは表現揺れが自然なので、次を保存します。 期待要素（必須ポイント） 禁止要素（誤情報、過剰断定） 参照すべき文書ID この形式にすると、自動評価と人手レビューを両立できます。 ステップ2：Retrieval評価を自動化 代表指標: Recall@k MRR nDCG 例えば、正解文書IDを持つ場合は次のように計算します。 1 2 3 def recall_at_k(retrieved_ids, gold_ids, k=5): topk = set(retrieved_ids[:k]) return 1.0 if len(topk.intersection(gold_ids)) > 0 else 0.0 運用では平均値だけでなく、カテゴリ別分布を見ることが重要です。手順質問だけ recall が低い場合、chunk 戦略や見出し抽出に問題がある可能性が高いです。 ...