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