使用 SQL 進行 RAG 評估
分別評估檢索效果和回答品質。系統是否檢索到相關證據？回答是否基於這些證據？只用一個分數，會看不出哪個階段發生了變化。
評估合約版本
使用 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 組合只記錄一筆最終紀錄。將範例篩選條件替換為實際比較的識別碼。衝突紀錄會單獨報告並排除，空值評估仍表示未知。查詢只統計已觀察到的案例；宣稱涵蓋完整之前，應另行檢查預定案例清單。
比較品質和約束
RAG品質SQL配方 計算每個管道版本的檢索相關率、接地答案率、平均檢索延遲和評估成本。其確定性夾具展示了一個在改變成本的同時提高審查品質率的版本。
分別解釋各列：
- 較差的檢索相關性意味著索引、分塊、過濾、嵌入或排名。
- 基礎較差的相關檢索指向上下文建置、提示或答案評估。
- 更好的品質和不可接受的延遲或成本可能無法投入生產。
- 少量的測試計數應該阻止發布結論，而不是隱藏在百分比後面。
在 瀏覽器 SQL 遊樂場 中執行夾具，然後用版本化的評估集替換其測試用例。
使用釋放門
RAG 評估通常屬於發布審查而不是待命頁面。在比較版本之前設定最小測試計數、迴歸容差、分級器版本和所需切片。將生產回饋作為單獨的訊號，並具有自己的同意和隱私規則。
AI品質評估用例 涵蓋人工切換、可接受的結果和提示版本。 AI和LLM食譜合集 新增了模型成本、延遲、快取、工具呼叫和代理執行分析。