使用 SQL 進行 RAG 評估
檢索增強生成至少有兩個不同的品質邊界：系統是否檢索到相關證據以及最終答案是否以該證據為基礎。將它們組合成一個樂譜會隱藏管道中發生更改的部分。
評估合約版本
使用 pipeline_version、test_case_id、relevant_document_retrieved、answer_grounded、retrieval_latency_ms、cost_usd、分級機版本和環境記錄每個測試用例一個終端事件。管道版本應足夠準確地識別檢索器、索引快照、重新排序器和答案提示，以重現比較。
跨管道使用相同版本的測試集。記錄評分標準並審查人類評分者和基於模型的評分者之間的分歧。不要將私人源段落、原始使用者問題、完整的模型答案、秘密或不受限制的工具輸出放入一般遙測中。
比較品質和約束
RAG品質SQL配方 計算每個管道版本的檢索相關率、接地答案率、平均檢索延遲和評估成本。其確定性夾具展示了一個在改變成本的同時提高審查品質率的版本。
分別解釋各列：
- 較差的檢索相關性意味著索引、分塊、過濾、嵌入或排名。
- 基礎較差的相關檢索指向上下文建置、提示或答案評估。
- 更好的品質和不可接受的延遲或成本可能無法投入生產。
- 少量的測試計數應該阻止發布結論，而不是隱藏在百分比後面。
在 瀏覽器 SQL 遊樂場 中執行夾具，然後用版本化的評估集替換其測試用例。
使用釋放門
RAG 評估通常屬於發布審查而不是待命頁面。在比較版本之前設定最小測試計數、迴歸容差、分級器版本和所需切片。將生產回饋作為單獨的訊號，並具有自己的同意和隱私規則。
AI品質評估用例 涵蓋人工切換、可接受的結果和提示版本。 AI和LLM食譜合集 新增了模型成本、延遲、快取、工具呼叫和代理執行分析。