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