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