1. 為什么AI Evals值得你花時間搞明白做LLM應用的人遲早會撞上同一堵墻模型輸出飄忽不定今天答得好好的明天換個問法就胡說八道。你改了一版提示詞感覺好像好了點但到底好了多少說不清。你換了個更大的模型老板問效果提升多少你只能憑感覺說“好像強一些”。這種狀態(tài)在傳統(tǒng)軟件開發(fā)里是不可想象的——你改了一行代碼跑一遍單元測試就知道有沒有把東西改壞。但到了LLM這里測試這件事突然變得模糊了。AI Evals就是來解決這個問題的。它是一套對LLM應用輸出質量進行系統(tǒng)化評估的方法論和工具鏈核心目標是讓“模型好不好”這件事從主觀感受變成可量化、可復現(xiàn)、可追蹤的工程指標。不管你在做RAG知識庫、Agentic RAG、LLM驅動的業(yè)務系統(tǒng)還是簡單的提示詞調優(yōu)只要你的系統(tǒng)里有LLM參與生成Evals就是你繞不開的基礎設施。這篇文章適合誰看如果你正在搭建基于LLM的產品或者已經在跑RAG項目但不知道怎么衡量檢索和生成的質量又或者你聽說過LLM-as-a-Judge但不知道實際怎么落地那這篇內容就是寫給你的。我會從整體設計思路講到具體實操包括評估集怎么建、評估器怎么選、怎么接入CI/CD流水線以及我自己踩過的那些坑。2. AI Evals的整體設計思路與方案選型2.1 先搞清楚你要評估什么很多人一上來就問“用什么工具做Evals”這個問題問早了。你得先想清楚評估對象是什么。一個典型的LLM應用評估維度至少可以拆成三層第一層是檢索質量。如果你的系統(tǒng)用了RAG檢索環(huán)節(jié)決定了模型能看到什么上下文。檢索質量差后面生成再好也是垃圾進垃圾出。檢索評估的核心指標包括召回率、精確率、MRR平均倒數(shù)排名等。第二層是生成質量。模型基于給定上下文生成的回答是否準確、是否完整、是否忠于原文、是否有害。這一層是大多數(shù)人最關心的。第三層是端到端體驗。用戶實際使用時的滿意度包括響應延遲、格式合規(guī)性、多輪對話的一致性等。這三層的評估方法和工具完全不同。檢索層可以用傳統(tǒng)IR指標生成層需要LLM-as-a-Judge或者人工標注端到端層則需要結合線上監(jiān)控和用戶反饋。如果你把這三層混在一起評估結果就是什么都測了但什么都測不準。2.2 為什么選擇LLM-as-a-Judge作為核心方案評估LLM輸出的方法大致有三種人工評估、傳統(tǒng)自動指標如BLEU、ROUGE、LLM-as-a-Judge。人工評估最準但成本極高沒法頻繁跑。傳統(tǒng)自動指標基于n-gram重疊對于開放式生成任務幾乎沒用——兩句話意思完全一樣但用詞不同BLEU分可能很低兩句話用詞高度重疊但意思相反BLEU分反而很高。這在RAG場景下尤其致命因為RAG的回答需要忠于檢索到的上下文而不是和標準答案做字面匹配。LLM-as-a-Judge的思路是用一個能力足夠強的LLM來充當評委按照給定的評分標準對輸出進行打分或排序。它的優(yōu)勢在于語義理解能力強能判斷“意思對不對”而不只是“字面像不像”可定制評分維度你可以定義忠實度、完整性、簡潔性等任意維度成本可控相比人工評估便宜幾個數(shù)量級可復現(xiàn)同樣的輸入和評分標準結果基本穩(wěn)定但LLM-as-a-Judge也有明顯的坑。評委模型本身可能有偏見比如傾向于給更長的回答打高分或者對某些表達風格有偏好。評分標準如果寫得模糊不同批次的評分一致性會很差。這些坑我在后面會詳細講怎么處理。2.3 評估集的設計原則評估集是整個Evals體系的地基。地基不牢后面所有指標都是空中樓閣。我見過太多團隊隨便找?guī)资畻l數(shù)據(jù)就開始跑評估跑出來的數(shù)字看著漂亮但上線后用戶反饋一塌糊涂。評估集的設計要遵循幾個原則覆蓋核心場景。你的應用支持哪些類型的查詢每種類型至少要有足夠數(shù)量的樣本。比如一個RAG知識庫查詢類型可能包括事實型查詢、比較型查詢、多跳推理查詢、否定型查詢等。每種類型都要覆蓋。包含邊界情況。用戶會問什么奇怪的問題輸入為空怎么辦問題超出知識庫范圍怎么辦問題有歧義怎么辦這些邊界情況必須出現(xiàn)在評估集里。標注標準答案。對于生成任務你需要一個參考答案ground truth。這個答案不一定是唯一的但必須是對的。標注工作最好由領域專家來做如果實在沒有條件至少要有兩個人獨立標注然后交叉驗證。持續(xù)迭代。評估集不是建一次就完事了。線上發(fā)現(xiàn)bad case就應該把它加進評估集。每次模型或提示詞有重大變更評估集也應該相應更新。2.4 工具選型不要重復造輪子Evals工具鏈這幾年發(fā)展很快主流的開源方案包括工具定位適合場景RAGASRAG專用評估檢索生成聯(lián)合評估DeepEval通用LLM評估單元測試式評估promptfoo提示詞對比測試快速迭代提示詞LangSmith全鏈路追蹤評估已有LangChain生態(tài)Braintrust評估實驗管理團隊協(xié)作場景選型的關鍵不是哪個功能最多而是哪個能最自然地融入你現(xiàn)有的開發(fā)流程。如果你已經在用LangChain做RAGLangSmith的集成成本最低。如果你想要輕量級的CI/CD集成promptfoo和DeepEval更合適。RAGAS在檢索指標上最專業(yè)但它的生成評估維度相對固定定制空間有限。我的建議是先用RAGAS或DeepEval快速跑通一個最小可用評估流程驗證方法論可行之后再根據(jù)實際需求決定是否遷移到更重的平臺。3. 核心細節(jié)解析與實操要點3.1 檢索評估RAG系統(tǒng)的第一道防線RAG系統(tǒng)的評估必須從檢索開始。原因很簡單如果檢索沒找到正確的文檔生成模型再強也答不對。檢索評估的核心是判斷“該找到的文檔有沒有被找到”。具體操作上你需要為每個評估樣本標注一組相關文檔ID。然后跑檢索看返回的Top-K結果里有多少是相關的。常用的指標包括Hit RateKTop-K里是否包含至少一個相關文檔MRRK第一個相關文檔排在第幾位倒數(shù)取平均RecallKTop-K里覆蓋了多少比例的相關文檔PrecisionKTop-K里有多少比例是相關的這些指標的計算不依賴LLM純靠文檔ID匹配所以速度快、成本低、結果穩(wěn)定。我建議每次代碼提交都跑一遍檢索評估作為CI/CD的第一道關卡。實操中有一個容易忽略的點分塊策略對檢索指標的影響極大。同樣的文檔按512token切和按1024token切檢索結果可能完全不同。所以評估檢索時一定要固定分塊策略否則指標波動你根本不知道是檢索算法變了還是分塊變了。注意檢索評估的相關文檔標注需要人工完成這是整個Evals流程中人力成本最高的環(huán)節(jié)。建議先從100-200條樣本開始覆蓋主要查詢類型即可不必追求大而全。3.2 生成評估LLM-as-a-Judge的落地細節(jié)生成評估是Evals中最復雜也最容易出問題的環(huán)節(jié)。核心思路是讓評委LLM按照評分標準對生成結果打分。但“打分”這件事本身有很多講究。評分標準的設計。不要用“好/中/差”這種模糊標準。每個維度都要有明確的定義和分檔描述。比如“忠實度”可以定義為5分回答中所有事實性陳述都能在給定上下文中找到依據(jù)4分回答中絕大部分事實性陳述有依據(jù)個別細節(jié)有輕微偏差3分回答中有部分事實性陳述缺乏依據(jù)但核心信息正確2分回答中有明顯的事實性錯誤與上下文矛盾1分回答完全偏離上下文或編造信息這種分檔描述看起來啰嗦但它是保證評分一致性的關鍵。我試過用模糊標準跑評估同一批數(shù)據(jù)兩次評分的一致性只有60%左右換成明確分檔后一致性提升到85%以上。評委模型的選擇。評委模型的能力必須顯著高于被評估模型否則就是讓小學生批改高中生的卷子。實操中用GPT-4或Claude 3.5 Sonnet級別的模型做評委是比較穩(wěn)妥的選擇。如果成本敏感可以考慮用更強的開源模型做評委但一定要先驗證評分一致性。位置偏見和長度偏見的處理。LLM評委有兩個著名的偏見傾向于給排在前面的選項打高分位置偏見以及傾向于給更長的回答打高分長度偏見。處理方法包括對于位置偏見把同一對回答交換順序評兩次取平均分對于長度偏見在評分標準中明確說明“簡潔且完整的回答應得高分”或者在評估時控制回答長度差異評分一致性驗證。在正式跑評估之前先抽20-30條樣本讓評委模型評兩次中間隔一段時間計算兩次評分的一致性。如果一致性低于80%說明評分標準或評委模型有問題需要調整。3.3 評估集的版本管理評估集是代碼不是數(shù)據(jù)。它應該和你的應用代碼一起做版本管理。每次評估集有變更都要記錄變更原因和影響范圍。我習慣用Git管理評估集目錄結構大概是這樣的evals/ datasets/ retrieval_eval_v1.jsonl generation_eval_v1.jsonl configs/ ragas_config.yaml judge_prompts/ faithfulness_v1.txt completeness_v1.txt results/ 2024-01-15_baseline.json 2024-01-20_prompt_v2.json每次跑評估結果文件按日期和變更描述命名方便回溯對比。如果某次評估結果異?？梢钥焖俣ㄎ皇窃u估集變了、提示詞變了還是模型變了。3.4 評估指標的可視化與追蹤光有數(shù)字不夠你需要能直觀看到趨勢。我一般會用簡單的折線圖追蹤幾個核心指標隨時間的變化檢索Hit Rate5生成忠實度平均分生成完整性平均分端到端響應延遲P95這些圖表不需要多精美用matplotlib或者直接導出到Google Sheets都行。關鍵是讓團隊每個人都能一眼看到“這次改動到底有沒有讓系統(tǒng)變好”。4. 實操過程與核心環(huán)節(jié)實現(xiàn)4.1 從零搭建一個最小可用Evals流程假設你有一個基于RAG的問答系統(tǒng)現(xiàn)在要從零搭建Evals。以下是我驗證過的步驟第一步準備評估數(shù)據(jù)。收集100條真實用戶查詢覆蓋主要查詢類型。對每條查詢標注相關文檔ID和參考答案。這一步大概需要1-2天取決于領域復雜度。第二步跑檢索評估。用RAGAS或自己寫腳本計算Hit Rate5和MRR5。如果Hit Rate低于80%先優(yōu)化檢索不要急著評估生成。第三步配置生成評估。選擇評委模型寫好評分標準提示詞。先用20條樣本驗證評分一致性一致性達標后再跑全量。第四步建立基線。在當前代碼版本上跑一次完整評估記錄所有指標作為基線。第五步接入CI/CD。每次PR合并前自動跑檢索評估生成評估可以按需觸發(fā)或每天定時跑。4.2 檢索評估的代碼實現(xiàn)以下是一個簡化的檢索評估腳本用Python實現(xiàn)import json from typing import List, Dict def hit_rate_at_k(retrieved_ids: List[str], relevant_ids: List[str], k: int) - float: top_k retrieved_ids[:k] return 1.0 if any(doc_id in relevant_ids for doc_id in top_k) else 0.0 def mrr_at_k(retrieved_ids: List[str], relevant_ids: List[str], k: int) - float: for rank, doc_id in enumerate(retrieved_ids[:k], start1): if doc_id in relevant_ids: return 1.0 / rank return 0.0 def evaluate_retrieval(eval_data_path: str, retriever, k: int 5) - Dict: with open(eval_data_path, r) as f: eval_samples [json.loads(line) for line in f] hit_rates [] mrrs [] for sample in eval_samples: query sample[query] relevant_ids sample[relevant_doc_ids] retrieved retriever.search(query, top_kk) retrieved_ids [doc[id] for doc in retrieved] hit_rates.append(hit_rate_at_k(retrieved_ids, relevant_ids, k)) mrrs.append(mrr_at_k(retrieved_ids, relevant_ids, k)) return { hit_ratek: sum(hit_rates) / len(hit_rates), mrrk: sum(mrrs) / len(mrrs), num_samples: len(eval_samples) }這個腳本很簡陋但足夠跑通流程。實際使用中你需要處理檢索失敗、文檔ID不匹配等異常情況。4.3 LLM-as-a-Judge的提示詞模板以下是我在實際項目中驗證過的忠實度評分提示詞模板你是一個嚴格的評估專家。你的任務是判斷【回答】是否忠實于【上下文】。 評分標準 5分回答中所有事實性陳述都能在上下文中找到直接依據(jù) 4分回答中絕大部分事實性陳述有依據(jù)個別細節(jié)有輕微偏差但不影響核心信息 3分回答中有部分事實性陳述缺乏依據(jù)但核心信息正確 2分回答中有明顯的事實性錯誤與上下文矛盾 1分回答完全偏離上下文或編造信息 【上下文】 {context} 【回答】 {answer} 請先給出評分理由然后輸出評分僅輸出數(shù)字。這個模板的關鍵在于評分標準分檔明確要求先給理由再給分數(shù)強制模型思考輸出格式固定便于解析。4.4 接入CI/CD流水線Evals接入CI/CD的核心原則是快速反饋分層執(zhí)行。檢索評估跑得快、成本低適合每次PR都跑。生成評估跑得慢、成本高適合每天定時跑或者手動觸發(fā)。以下是一個GitLab CI配置示例stages: - test - eval retrieval_eval: stage: eval script: - python evals/run_retrieval_eval.py --dataset evals/datasets/retrieval_eval_v1.jsonl rules: - if: $CI_PIPELINE_SOURCE merge_request_event artifacts: paths: - evals/results/retrieval_latest.json generation_eval: stage: eval script: - python evals/run_generation_eval.py --dataset evals/datasets/generation_eval_v1.jsonl rules: - if: $CI_PIPELINE_SOURCE schedule artifacts: paths: - evals/results/generation_latest.json關鍵點是設置閾值告警。如果檢索Hit Rate比基線下降超過5個百分點CI應該直接失敗阻止合并。生成評估的閾值可以寬松一些但也要有告警機制。4.5 評估結果的分析與歸因跑完評估拿到數(shù)字只是第一步更重要的是分析數(shù)字背后的原因。我一般會做以下幾件事按查詢類型分組分析。整體指標可能看起來還行但某個類型的查詢可能特別差。比如事實型查詢Hit Rate 95%但多跳推理查詢只有60%。這種細分分析能幫你精準定位問題。查看bad case。把評分最低的樣本挑出來人工看一遍。是檢索沒找到文檔還是找到了但生成模型沒用還是評分標準有問題bad case分析往往能發(fā)現(xiàn)指標數(shù)字掩蓋不了的問題。對比歷史結果。如果這次評估指標下降了和上次的結果做diff看是哪些樣本的評分變了。這能幫你快速定位是哪個改動導致了退化。5. 常見問題與排查技巧實錄5.1 評分一致性差怎么辦這是LLM-as-a-Judge最常見的問題。同一批數(shù)據(jù)跑兩次評分差異很大。原因通常有三個評分標準太模糊。解決辦法是把每個分數(shù)檔的描述寫得更具體最好給出正例和反例。評委模型能力不夠。如果評委模型和被評估模型能力接近評分就會不穩(wěn)定。換更強的評委模型。溫度參數(shù)沒設對。評委模型的temperature應該設為0或接近0保證輸出穩(wěn)定。5.2 評估成本太高怎么控制LLM-as-a-Judge的成本主要來自評委模型的API調用?？刂瞥杀镜姆椒òㄓ酶阋说哪Ｐ妥龀鹾Y只對邊界樣本用強模型復評減少評估頻率從每次PR改成每天定時優(yōu)化提示詞長度減少不必要的token消耗對檢索評估這種不需要LLM的環(huán)節(jié)堅決不用LLM5.3 評估指標和線上表現(xiàn)不一致這是最讓人頭疼的問題。評估集上指標很好但線上用戶反饋很差。原因通常是評估集不能代表真實分布。解決辦法是持續(xù)從線上收集bad case加入評估集。另外評估集的查詢分布應該定期和線上查詢分布做對比確保沒有嚴重偏移。5.4 常見問題速查表問題可能原因排查方向評分一致性低于80%評分標準模糊/評委模型弱細化評分檔描述換更強評委檢索Hit Rate突然下降分塊策略變更/索引重建檢查分塊配置和索引版本生成忠實度低但檢索指標正常生成模型忽略上下文檢查提示詞是否強調忠于上下文評估結果波動大評估集太小/樣本分布不均擴大評估集檢查樣本分布CI中評估超時評估樣本太多/API限流減少樣本量或增加超時時間5.5 幾個我踩過的坑坑一評估集泄露。有一次我把評估集里的樣本不小心用作了few-shot示例導致評估指標虛高。后來我嚴格分離了評估集和提示詞示例確保沒有重疊?？佣雎詸z索延遲。早期我只關注檢索質量指標忽略了檢索延遲。上線后發(fā)現(xiàn)P95延遲超過3秒用戶體驗很差。后來在評估中加入了延遲指標把延遲也作為CI的檢查項?？尤u分標準頻繁變更。有段時間我頻繁調整評分標準導致歷史評估結果沒法對比。后來我規(guī)定評分標準變更必須走版本管理每次變更都要記錄變更原因和影響。坑四過度依賴單一指標。曾經有一段時間我只盯著忠實度指標優(yōu)化結果發(fā)現(xiàn)回答變得越來越短、越來越保守完整性大幅下降。后來我建立了多指標聯(lián)合評估任何單一指標都不能獨立決定優(yōu)化方向。5.6 評估流程的持續(xù)迭代Evals不是一次性的項目而是持續(xù)迭代的過程。我建議每兩周做一次評估流程的回顧評估集是否需要新增樣本評分標準是否需要調整評估指標是否還反映真實質量CI/CD中的閾值是否需要更新這個回顧不需要很長時間但能保證Evals體系始終和業(yè)務目標對齊。6. 從Evals到持續(xù)改進的閉環(huán)Evals的最終目的不是生成一堆數(shù)字而是驅動系統(tǒng)持續(xù)改進。一個完整的閉環(huán)應該是評估發(fā)現(xiàn)問題 - 分析歸因 - 實施改進 - 重新評估驗證 - 上線監(jiān)控。在這個閉環(huán)中最容易斷裂的環(huán)節(jié)是“分析歸因”。很多人跑完評估看到指標下降就慌了但不知道從哪里下手。我的經驗是先看檢索再看生成最后看提示詞。檢索問題通常最容易定位也最容易修復生成問題需要看bad case具體分析提示詞問題往往最隱蔽需要對比不同版本的提示詞效果。另一個容易忽略的環(huán)節(jié)是“上線監(jiān)控”。評估集上的指標再好也不能保證線上沒問題。線上監(jiān)控應該關注用戶反饋率、重新生成率、對話中斷率等行為指標。這些指標和評估指標結合才能全面反映系統(tǒng)質量。我個人在實際操作中的體會是Evals這件事起步階段最重要的是跑通流程而不是追求指標多漂亮。先用小規(guī)模評估集把檢索評估和生成評估跑起來建立起基線然后再逐步擴大評估集、細化評分標準、接入CI/CD。整個過程可能需要幾周時間但一旦跑通后續(xù)每次迭代都會變得有據(jù)可依不再靠感覺做決策。最后分享一個小技巧如果你不確定評分標準怎么寫可以先找10條樣本自己人工打分然后讓評委模型也打分對比兩者的差異。差異大的地方就是評分標準需要細化的地方。這個方法我用了很多次每次都能快速定位評分標準的模糊點。