SQL による RAG 評価
検索拡張生成には、少なくとも 2 つの明確な品質境界があります。1 つは、システムが関連する証拠を検索したかどうか、もう 1 つは最終的な答えがその証拠に基づいたものであるかどうかです。それらを 1 つのスコアに結合すると、変更されたパイプラインの部分が非表示になります。
評価契約のバージョンを作成する
テスト ケースごとに 1 つのターミナル イベントを記録します。 pipeline_version, test_case_id, relevant_document_retrieved, answer_grounded, retrieval_latency_ms, cost_usd、採点者のバージョン、および環境。パイプライン バージョンでは、比較を再現するために、取得者、インデックス スナップショット、リランカー、および回答プロンプトを十分に厳密に識別する必要があります。
パイプライン全体で同じバージョン管理されたテスト セットを使用します。採点ルーブリックを文書化し、人間の採点者とモデルベースの採点者の間の意見の相違を確認します。一般的なテレメトリに、プライベートなソースの一節、生のユーザーの質問、完全な模範解答、秘密、または無制限のツール出力を含めないでください。
品質と制約を比較する
の RAG品質SQLレシピ すべてのパイプライン バージョンの取得関連率、根拠のある回答率、平均取得待ち時間、および評価コストを計算します。その決定論的なフィクスチャは、コストを変更しながらレビューされた品質率の両方を向上させるバージョンを示しています。
列を個別に解釈します。
- 検索の関連性が低い場合は、インデックス作成、チャンク化、フィルタリング、埋め込み、またはランキングに向けられます。
- 根拠が不十分な関連性の検索は、コンテキストの構築、プロンプト、または回答の評価を指します。
- 許容できない遅延やコストを伴うより良い品質は、本番環境に対応できない可能性があります。
- テスト数が少ないと、パーセンテージの陰に隠れるのではなく、リリースの結論が妨げられるはずです。
でフィクスチャを実行します ブラウザ SQL プレイグラウンドを作成し、そのテスト ケースをバージョン管理された評価セットに置き換えます。
リリースゲートを使用する
RAG 評価は通常、オンコール ページではなくリリース レビューに属します。バージョンを比較する前に、最小テスト数、回帰許容値、採点者のバージョン、および必要なスライスを設定します。プロダクション フィードバックは、独自の同意とプライバシー ルールを備えた別個の信号として保持します。
の AI品質評価のユースケース 人間による引き継ぎ、受け入れられた結果、プロンプト バージョンについて説明します。の AIとLLMのレシピ集 モデルのコスト、レイテンシ、キャッシュ、ツール呼び出し、エージェント実行の分析を追加します。