1. 为什么AI Evals值得你花时间搞明白做LLM应用的人迟早会撞上同一堵墙模型输出飘忽不定今天答得好好的明天换个问法就胡说八道。你改了一版提示词感觉好像好了点但到底好了多少说不清。你换了个更大的模型老板问效果提升多少你只能凭感觉说“好像强一些”。这种状态在传统软件开发里是不可想象的——你改了一行代码跑一遍单元测试就知道有没有把东西改坏。但到了LLM这里测试这件事突然变得模糊了。AI Evals就是来解决这个问题的。它是一套对LLM应用输出质量进行系统化评估的方法论和工具链核心目标是让“模型好不好”这件事从主观感受变成可量化、可复现、可追踪的工程指标。不管你在做RAG知识库、Agentic RAG、LLM驱动的业务系统还是简单的提示词调优只要你的系统里有LLM参与生成Evals就是你绕不开的基础设施。这篇文章适合谁看如果你正在搭建基于LLM的产品或者已经在跑RAG项目但不知道怎么衡量检索和生成的质量又或者你听说过LLM-as-a-Judge但不知道实际怎么落地那这篇内容就是写给你的。我会从整体设计思路讲到具体实操包括评估集怎么建、评估器怎么选、怎么接入CI/CD流水线以及我自己踩过的那些坑。2. AI Evals的整体设计思路与方案选型2.1 先搞清楚你要评估什么很多人一上来就问“用什么工具做Evals”这个问题问早了。你得先想清楚评估对象是什么。一个典型的LLM应用评估维度至少可以拆成三层第一层是检索质量。如果你的系统用了RAG检索环节决定了模型能看到什么上下文。检索质量差后面生成再好也是垃圾进垃圾出。检索评估的核心指标包括召回率、精确率、MRR平均倒数排名等。第二层是生成质量。模型基于给定上下文生成的回答是否准确、是否完整、是否忠于原文、是否有害。这一层是大多数人最关心的。第三层是端到端体验。用户实际使用时的满意度包括响应延迟、格式合规性、多轮对话的一致性等。这三层的评估方法和工具完全不同。检索层可以用传统IR指标生成层需要LLM-as-a-Judge或者人工标注端到端层则需要结合线上监控和用户反馈。如果你把这三层混在一起评估结果就是什么都测了但什么都测不准。2.2 为什么选择LLM-as-a-Judge作为核心方案评估LLM输出的方法大致有三种人工评估、传统自动指标如BLEU、ROUGE、LLM-as-a-Judge。人工评估最准但成本极高没法频繁跑。传统自动指标基于n-gram重叠对于开放式生成任务几乎没用——两句话意思完全一样但用词不同BLEU分可能很低两句话用词高度重叠但意思相反BLEU分反而很高。这在RAG场景下尤其致命因为RAG的回答需要忠于检索到的上下文而不是和标准答案做字面匹配。LLM-as-a-Judge的思路是用一个能力足够强的LLM来充当评委按照给定的评分标准对输出进行打分或排序。它的优势在于语义理解能力强能判断“意思对不对”而不只是“字面像不像”可定制评分维度你可以定义忠实度、完整性、简洁性等任意维度成本可控相比人工评估便宜几个数量级可复现同样的输入和评分标准结果基本稳定但LLM-as-a-Judge也有明显的坑。评委模型本身可能有偏见比如倾向于给更长的回答打高分或者对某些表达风格有偏好。评分标准如果写得模糊不同批次的评分一致性会很差。这些坑我在后面会详细讲怎么处理。2.3 评估集的设计原则评估集是整个Evals体系的地基。地基不牢后面所有指标都是空中楼阁。我见过太多团队随便找几十条数据就开始跑评估跑出来的数字看着漂亮但上线后用户反馈一塌糊涂。评估集的设计要遵循几个原则覆盖核心场景。你的应用支持哪些类型的查询每种类型至少要有足够数量的样本。比如一个RAG知识库查询类型可能包括事实型查询、比较型查询、多跳推理查询、否定型查询等。每种类型都要覆盖。包含边界情况。用户会问什么奇怪的问题输入为空怎么办问题超出知识库范围怎么办问题有歧义怎么办这些边界情况必须出现在评估集里。标注标准答案。对于生成任务你需要一个参考答案ground truth。这个答案不一定是唯一的但必须是对的。标注工作最好由领域专家来做如果实在没有条件至少要有两个人独立标注然后交叉验证。持续迭代。评估集不是建一次就完事了。线上发现bad case就应该把它加进评估集。每次模型或提示词有重大变更评估集也应该相应更新。2.4 工具选型不要重复造轮子Evals工具链这几年发展很快主流的开源方案包括工具定位适合场景RAGASRAG专用评估检索生成联合评估DeepEval通用LLM评估单元测试式评估promptfoo提示词对比测试快速迭代提示词LangSmith全链路追踪评估已有LangChain生态Braintrust评估实验管理团队协作场景选型的关键不是哪个功能最多而是哪个能最自然地融入你现有的开发流程。如果你已经在用LangChain做RAGLangSmith的集成成本最低。如果你想要轻量级的CI/CD集成promptfoo和DeepEval更合适。RAGAS在检索指标上最专业但它的生成评估维度相对固定定制空间有限。我的建议是先用RAGAS或DeepEval快速跑通一个最小可用评估流程验证方法论可行之后再根据实际需求决定是否迁移到更重的平台。3. 核心细节解析与实操要点3.1 检索评估RAG系统的第一道防线RAG系统的评估必须从检索开始。原因很简单如果检索没找到正确的文档生成模型再强也答不对。检索评估的核心是判断“该找到的文档有没有被找到”。具体操作上你需要为每个评估样本标注一组相关文档ID。然后跑检索看返回的Top-K结果里有多少是相关的。常用的指标包括Hit RateKTop-K里是否包含至少一个相关文档MRRK第一个相关文档排在第几位倒数取平均RecallKTop-K里覆盖了多少比例的相关文档PrecisionKTop-K里有多少比例是相关的这些指标的计算不依赖LLM纯靠文档ID匹配所以速度快、成本低、结果稳定。我建议每次代码提交都跑一遍检索评估作为CI/CD的第一道关卡。实操中有一个容易忽略的点分块策略对检索指标的影响极大。同样的文档按512token切和按1024token切检索结果可能完全不同。所以评估检索时一定要固定分块策略否则指标波动你根本不知道是检索算法变了还是分块变了。注意检索评估的相关文档标注需要人工完成这是整个Evals流程中人力成本最高的环节。建议先从100-200条样本开始覆盖主要查询类型即可不必追求大而全。3.2 生成评估LLM-as-a-Judge的落地细节生成评估是Evals中最复杂也最容易出问题的环节。核心思路是让评委LLM按照评分标准对生成结果打分。但“打分”这件事本身有很多讲究。评分标准的设计。不要用“好/中/差”这种模糊标准。每个维度都要有明确的定义和分档描述。比如“忠实度”可以定义为5分回答中所有事实性陈述都能在给定上下文中找到依据4分回答中绝大部分事实性陈述有依据个别细节有轻微偏差3分回答中有部分事实性陈述缺乏依据但核心信息正确2分回答中有明显的事实性错误与上下文矛盾1分回答完全偏离上下文或编造信息这种分档描述看起来啰嗦但它是保证评分一致性的关键。我试过用模糊标准跑评估同一批数据两次评分的一致性只有60%左右换成明确分档后一致性提升到85%以上。评委模型的选择。评委模型的能力必须显著高于被评估模型否则就是让小学生批改高中生的卷子。实操中用GPT-4或Claude 3.5 Sonnet级别的模型做评委是比较稳妥的选择。如果成本敏感可以考虑用更强的开源模型做评委但一定要先验证评分一致性。位置偏见和长度偏见的处理。LLM评委有两个著名的偏见倾向于给排在前面的选项打高分位置偏见以及倾向于给更长的回答打高分长度偏见。处理方法包括对于位置偏见把同一对回答交换顺序评两次取平均分对于长度偏见在评分标准中明确说明“简洁且完整的回答应得高分”或者在评估时控制回答长度差异评分一致性验证。在正式跑评估之前先抽20-30条样本让评委模型评两次中间隔一段时间计算两次评分的一致性。如果一致性低于80%说明评分标准或评委模型有问题需要调整。3.3 评估集的版本管理评估集是代码不是数据。它应该和你的应用代码一起做版本管理。每次评估集有变更都要记录变更原因和影响范围。我习惯用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每次跑评估结果文件按日期和变更描述命名方便回溯对比。如果某次评估结果异常可以快速定位是评估集变了、提示词变了还是模型变了。3.4 评估指标的可视化与追踪光有数字不够你需要能直观看到趋势。我一般会用简单的折线图追踪几个核心指标随时间的变化检索Hit Rate5生成忠实度平均分生成完整性平均分端到端响应延迟P95这些图表不需要多精美用matplotlib或者直接导出到Google Sheets都行。关键是让团队每个人都能一眼看到“这次改动到底有没有让系统变好”。4. 实操过程与核心环节实现4.1 从零搭建一个最小可用Evals流程假设你有一个基于RAG的问答系统现在要从零搭建Evals。以下是我验证过的步骤第一步准备评估数据。收集100条真实用户查询覆盖主要查询类型。对每条查询标注相关文档ID和参考答案。这一步大概需要1-2天取决于领域复杂度。第二步跑检索评估。用RAGAS或自己写脚本计算Hit Rate5和MRR5。如果Hit Rate低于80%先优化检索不要急着评估生成。第三步配置生成评估。选择评委模型写好评分标准提示词。先用20条样本验证评分一致性一致性达标后再跑全量。第四步建立基线。在当前代码版本上跑一次完整评估记录所有指标作为基线。第五步接入CI/CD。每次PR合并前自动跑检索评估生成评估可以按需触发或每天定时跑。4.2 检索评估的代码实现以下是一个简化的检索评估脚本用Python实现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分回答中所有事实性陈述都能在上下文中找到直接依据 4分回答中绝大部分事实性陈述有依据个别细节有轻微偏差但不影响核心信息 3分回答中有部分事实性陈述缺乏依据但核心信息正确 2分回答中有明显的事实性错误与上下文矛盾 1分回答完全偏离上下文或编造信息 【上下文】 {context} 【回答】 {answer} 请先给出评分理由然后输出评分仅输出数字。这个模板的关键在于评分标准分档明确要求先给理由再给分数强制模型思考输出格式固定便于解析。4.4 接入CI/CD流水线Evals接入CI/CD的核心原则是快速反馈分层执行。检索评估跑得快、成本低适合每次PR都跑。生成评估跑得慢、成本高适合每天定时跑或者手动触发。以下是一个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 评估结果的分析与归因跑完评估拿到数字只是第一步更重要的是分析数字背后的原因。我一般会做以下几件事按查询类型分组分析。整体指标可能看起来还行但某个类型的查询可能特别差。比如事实型查询Hit Rate 95%但多跳推理查询只有60%。这种细分分析能帮你精准定位问题。查看bad case。把评分最低的样本挑出来人工看一遍。是检索没找到文档还是找到了但生成模型没用还是评分标准有问题bad case分析往往能发现指标数字掩盖不了的问题。对比历史结果。如果这次评估指标下降了和上次的结果做diff看是哪些样本的评分变了。这能帮你快速定位是哪个改动导致了退化。5. 常见问题与排查技巧实录5.1 评分一致性差怎么办这是LLM-as-a-Judge最常见的问题。同一批数据跑两次评分差异很大。原因通常有三个评分标准太模糊。解决办法是把每个分数档的描述写得更具体最好给出正例和反例。评委模型能力不够。如果评委模型和被评估模型能力接近评分就会不稳定。换更强的评委模型。温度参数没设对。评委模型的temperature应该设为0或接近0保证输出稳定。5.2 评估成本太高怎么控制LLM-as-a-Judge的成本主要来自评委模型的API调用。控制成本的方法包括用更便宜的模型做初筛只对边界样本用强模型复评减少评估频率从每次PR改成每天定时优化提示词长度减少不必要的token消耗对检索评估这种不需要LLM的环节坚决不用LLM5.3 评估指标和线上表现不一致这是最让人头疼的问题。评估集上指标很好但线上用户反馈很差。原因通常是评估集不能代表真实分布。解决办法是持续从线上收集bad case加入评估集。另外评估集的查询分布应该定期和线上查询分布做对比确保没有严重偏移。5.4 常见问题速查表问题可能原因排查方向评分一致性低于80%评分标准模糊/评委模型弱细化评分档描述换更强评委检索Hit Rate突然下降分块策略变更/索引重建检查分块配置和索引版本生成忠实度低但检索指标正常生成模型忽略上下文检查提示词是否强调忠于上下文评估结果波动大评估集太小/样本分布不均扩大评估集检查样本分布CI中评估超时评估样本太多/API限流减少样本量或增加超时时间5.5 几个我踩过的坑坑一评估集泄露。有一次我把评估集里的样本不小心用作了few-shot示例导致评估指标虚高。后来我严格分离了评估集和提示词示例确保没有重叠。坑二忽略检索延迟。早期我只关注检索质量指标忽略了检索延迟。上线后发现P95延迟超过3秒用户体验很差。后来在评估中加入了延迟指标把延迟也作为CI的检查项。坑三评分标准频繁变更。有段时间我频繁调整评分标准导致历史评估结果没法对比。后来我规定评分标准变更必须走版本管理每次变更都要记录变更原因和影响。坑四过度依赖单一指标。曾经有一段时间我只盯着忠实度指标优化结果发现回答变得越来越短、越来越保守完整性大幅下降。后来我建立了多指标联合评估任何单一指标都不能独立决定优化方向。5.6 评估流程的持续迭代Evals不是一次性的项目而是持续迭代的过程。我建议每两周做一次评估流程的回顾评估集是否需要新增样本评分标准是否需要调整评估指标是否还反映真实质量CI/CD中的阈值是否需要更新这个回顾不需要很长时间但能保证Evals体系始终和业务目标对齐。6. 从Evals到持续改进的闭环Evals的最终目的不是生成一堆数字而是驱动系统持续改进。一个完整的闭环应该是评估发现问题 - 分析归因 - 实施改进 - 重新评估验证 - 上线监控。在这个闭环中最容易断裂的环节是“分析归因”。很多人跑完评估看到指标下降就慌了但不知道从哪里下手。我的经验是先看检索再看生成最后看提示词。检索问题通常最容易定位也最容易修复生成问题需要看bad case具体分析提示词问题往往最隐蔽需要对比不同版本的提示词效果。另一个容易忽略的环节是“上线监控”。评估集上的指标再好也不能保证线上没问题。线上监控应该关注用户反馈率、重新生成率、对话中断率等行为指标。这些指标和评估指标结合才能全面反映系统质量。我个人在实际操作中的体会是Evals这件事起步阶段最重要的是跑通流程而不是追求指标多漂亮。先用小规模评估集把检索评估和生成评估跑起来建立起基线然后再逐步扩大评估集、细化评分标准、接入CI/CD。整个过程可能需要几周时间但一旦跑通后续每次迭代都会变得有据可依不再靠感觉做决策。最后分享一个小技巧如果你不确定评分标准怎么写可以先找10条样本自己人工打分然后让评委模型也打分对比两者的差异。差异大的地方就是评分标准需要细化的地方。这个方法我用了很多次每次都能快速定位评分标准的模糊点。
1. 为什么AI Evals值得你花时间搞明白做LLM应用的人迟早会撞上同一堵墙模型输出飘忽不定今天答得好好的明天换个问法就胡说八道。你改了一版提示词感觉好像好了点但到底好了多少说不清。你换了个更大的模型老板问效果提升多少你只能凭感觉说“好像强一些”。这种状态在传统软件开发里是不可想象的——你改了一行代码跑一遍单元测试就知道有没有把东西改坏。但到了LLM这里测试这件事突然变得模糊了。AI Evals就是来解决这个问题的。它是一套对LLM应用输出质量进行系统化评估的方法论和工具链核心目标是让“模型好不好”这件事从主观感受变成可量化、可复现、可追踪的工程指标。不管你在做RAG知识库、Agentic RAG、LLM驱动的业务系统还是简单的提示词调优只要你的系统里有LLM参与生成Evals就是你绕不开的基础设施。这篇文章适合谁看如果你正在搭建基于LLM的产品或者已经在跑RAG项目但不知道怎么衡量检索和生成的质量又或者你听说过LLM-as-a-Judge但不知道实际怎么落地那这篇内容就是写给你的。我会从整体设计思路讲到具体实操包括评估集怎么建、评估器怎么选、怎么接入CI/CD流水线以及我自己踩过的那些坑。2. AI Evals的整体设计思路与方案选型2.1 先搞清楚你要评估什么很多人一上来就问“用什么工具做Evals”这个问题问早了。你得先想清楚评估对象是什么。一个典型的LLM应用评估维度至少可以拆成三层第一层是检索质量。如果你的系统用了RAG检索环节决定了模型能看到什么上下文。检索质量差后面生成再好也是垃圾进垃圾出。检索评估的核心指标包括召回率、精确率、MRR平均倒数排名等。第二层是生成质量。模型基于给定上下文生成的回答是否准确、是否完整、是否忠于原文、是否有害。这一层是大多数人最关心的。第三层是端到端体验。用户实际使用时的满意度包括响应延迟、格式合规性、多轮对话的一致性等。这三层的评估方法和工具完全不同。检索层可以用传统IR指标生成层需要LLM-as-a-Judge或者人工标注端到端层则需要结合线上监控和用户反馈。如果你把这三层混在一起评估结果就是什么都测了但什么都测不准。2.2 为什么选择LLM-as-a-Judge作为核心方案评估LLM输出的方法大致有三种人工评估、传统自动指标如BLEU、ROUGE、LLM-as-a-Judge。人工评估最准但成本极高没法频繁跑。传统自动指标基于n-gram重叠对于开放式生成任务几乎没用——两句话意思完全一样但用词不同BLEU分可能很低两句话用词高度重叠但意思相反BLEU分反而很高。这在RAG场景下尤其致命因为RAG的回答需要忠于检索到的上下文而不是和标准答案做字面匹配。LLM-as-a-Judge的思路是用一个能力足够强的LLM来充当评委按照给定的评分标准对输出进行打分或排序。它的优势在于语义理解能力强能判断“意思对不对”而不只是“字面像不像”可定制评分维度你可以定义忠实度、完整性、简洁性等任意维度成本可控相比人工评估便宜几个数量级可复现同样的输入和评分标准结果基本稳定但LLM-as-a-Judge也有明显的坑。评委模型本身可能有偏见比如倾向于给更长的回答打高分或者对某些表达风格有偏好。评分标准如果写得模糊不同批次的评分一致性会很差。这些坑我在后面会详细讲怎么处理。2.3 评估集的设计原则评估集是整个Evals体系的地基。地基不牢后面所有指标都是空中楼阁。我见过太多团队随便找几十条数据就开始跑评估跑出来的数字看着漂亮但上线后用户反馈一塌糊涂。评估集的设计要遵循几个原则覆盖核心场景。你的应用支持哪些类型的查询每种类型至少要有足够数量的样本。比如一个RAG知识库查询类型可能包括事实型查询、比较型查询、多跳推理查询、否定型查询等。每种类型都要覆盖。包含边界情况。用户会问什么奇怪的问题输入为空怎么办问题超出知识库范围怎么办问题有歧义怎么办这些边界情况必须出现在评估集里。标注标准答案。对于生成任务你需要一个参考答案ground truth。这个答案不一定是唯一的但必须是对的。标注工作最好由领域专家来做如果实在没有条件至少要有两个人独立标注然后交叉验证。持续迭代。评估集不是建一次就完事了。线上发现bad case就应该把它加进评估集。每次模型或提示词有重大变更评估集也应该相应更新。2.4 工具选型不要重复造轮子Evals工具链这几年发展很快主流的开源方案包括工具定位适合场景RAGASRAG专用评估检索生成联合评估DeepEval通用LLM评估单元测试式评估promptfoo提示词对比测试快速迭代提示词LangSmith全链路追踪评估已有LangChain生态Braintrust评估实验管理团队协作场景选型的关键不是哪个功能最多而是哪个能最自然地融入你现有的开发流程。如果你已经在用LangChain做RAGLangSmith的集成成本最低。如果你想要轻量级的CI/CD集成promptfoo和DeepEval更合适。RAGAS在检索指标上最专业但它的生成评估维度相对固定定制空间有限。我的建议是先用RAGAS或DeepEval快速跑通一个最小可用评估流程验证方法论可行之后再根据实际需求决定是否迁移到更重的平台。3. 核心细节解析与实操要点3.1 检索评估RAG系统的第一道防线RAG系统的评估必须从检索开始。原因很简单如果检索没找到正确的文档生成模型再强也答不对。检索评估的核心是判断“该找到的文档有没有被找到”。具体操作上你需要为每个评估样本标注一组相关文档ID。然后跑检索看返回的Top-K结果里有多少是相关的。常用的指标包括Hit RateKTop-K里是否包含至少一个相关文档MRRK第一个相关文档排在第几位倒数取平均RecallKTop-K里覆盖了多少比例的相关文档PrecisionKTop-K里有多少比例是相关的这些指标的计算不依赖LLM纯靠文档ID匹配所以速度快、成本低、结果稳定。我建议每次代码提交都跑一遍检索评估作为CI/CD的第一道关卡。实操中有一个容易忽略的点分块策略对检索指标的影响极大。同样的文档按512token切和按1024token切检索结果可能完全不同。所以评估检索时一定要固定分块策略否则指标波动你根本不知道是检索算法变了还是分块变了。注意检索评估的相关文档标注需要人工完成这是整个Evals流程中人力成本最高的环节。建议先从100-200条样本开始覆盖主要查询类型即可不必追求大而全。3.2 生成评估LLM-as-a-Judge的落地细节生成评估是Evals中最复杂也最容易出问题的环节。核心思路是让评委LLM按照评分标准对生成结果打分。但“打分”这件事本身有很多讲究。评分标准的设计。不要用“好/中/差”这种模糊标准。每个维度都要有明确的定义和分档描述。比如“忠实度”可以定义为5分回答中所有事实性陈述都能在给定上下文中找到依据4分回答中绝大部分事实性陈述有依据个别细节有轻微偏差3分回答中有部分事实性陈述缺乏依据但核心信息正确2分回答中有明显的事实性错误与上下文矛盾1分回答完全偏离上下文或编造信息这种分档描述看起来啰嗦但它是保证评分一致性的关键。我试过用模糊标准跑评估同一批数据两次评分的一致性只有60%左右换成明确分档后一致性提升到85%以上。评委模型的选择。评委模型的能力必须显著高于被评估模型否则就是让小学生批改高中生的卷子。实操中用GPT-4或Claude 3.5 Sonnet级别的模型做评委是比较稳妥的选择。如果成本敏感可以考虑用更强的开源模型做评委但一定要先验证评分一致性。位置偏见和长度偏见的处理。LLM评委有两个著名的偏见倾向于给排在前面的选项打高分位置偏见以及倾向于给更长的回答打高分长度偏见。处理方法包括对于位置偏见把同一对回答交换顺序评两次取平均分对于长度偏见在评分标准中明确说明“简洁且完整的回答应得高分”或者在评估时控制回答长度差异评分一致性验证。在正式跑评估之前先抽20-30条样本让评委模型评两次中间隔一段时间计算两次评分的一致性。如果一致性低于80%说明评分标准或评委模型有问题需要调整。3.3 评估集的版本管理评估集是代码不是数据。它应该和你的应用代码一起做版本管理。每次评估集有变更都要记录变更原因和影响范围。我习惯用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每次跑评估结果文件按日期和变更描述命名方便回溯对比。如果某次评估结果异常可以快速定位是评估集变了、提示词变了还是模型变了。3.4 评估指标的可视化与追踪光有数字不够你需要能直观看到趋势。我一般会用简单的折线图追踪几个核心指标随时间的变化检索Hit Rate5生成忠实度平均分生成完整性平均分端到端响应延迟P95这些图表不需要多精美用matplotlib或者直接导出到Google Sheets都行。关键是让团队每个人都能一眼看到“这次改动到底有没有让系统变好”。4. 实操过程与核心环节实现4.1 从零搭建一个最小可用Evals流程假设你有一个基于RAG的问答系统现在要从零搭建Evals。以下是我验证过的步骤第一步准备评估数据。收集100条真实用户查询覆盖主要查询类型。对每条查询标注相关文档ID和参考答案。这一步大概需要1-2天取决于领域复杂度。第二步跑检索评估。用RAGAS或自己写脚本计算Hit Rate5和MRR5。如果Hit Rate低于80%先优化检索不要急着评估生成。第三步配置生成评估。选择评委模型写好评分标准提示词。先用20条样本验证评分一致性一致性达标后再跑全量。第四步建立基线。在当前代码版本上跑一次完整评估记录所有指标作为基线。第五步接入CI/CD。每次PR合并前自动跑检索评估生成评估可以按需触发或每天定时跑。4.2 检索评估的代码实现以下是一个简化的检索评估脚本用Python实现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分回答中所有事实性陈述都能在上下文中找到直接依据 4分回答中绝大部分事实性陈述有依据个别细节有轻微偏差但不影响核心信息 3分回答中有部分事实性陈述缺乏依据但核心信息正确 2分回答中有明显的事实性错误与上下文矛盾 1分回答完全偏离上下文或编造信息 【上下文】 {context} 【回答】 {answer} 请先给出评分理由然后输出评分仅输出数字。这个模板的关键在于评分标准分档明确要求先给理由再给分数强制模型思考输出格式固定便于解析。4.4 接入CI/CD流水线Evals接入CI/CD的核心原则是快速反馈分层执行。检索评估跑得快、成本低适合每次PR都跑。生成评估跑得慢、成本高适合每天定时跑或者手动触发。以下是一个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 评估结果的分析与归因跑完评估拿到数字只是第一步更重要的是分析数字背后的原因。我一般会做以下几件事按查询类型分组分析。整体指标可能看起来还行但某个类型的查询可能特别差。比如事实型查询Hit Rate 95%但多跳推理查询只有60%。这种细分分析能帮你精准定位问题。查看bad case。把评分最低的样本挑出来人工看一遍。是检索没找到文档还是找到了但生成模型没用还是评分标准有问题bad case分析往往能发现指标数字掩盖不了的问题。对比历史结果。如果这次评估指标下降了和上次的结果做diff看是哪些样本的评分变了。这能帮你快速定位是哪个改动导致了退化。5. 常见问题与排查技巧实录5.1 评分一致性差怎么办这是LLM-as-a-Judge最常见的问题。同一批数据跑两次评分差异很大。原因通常有三个评分标准太模糊。解决办法是把每个分数档的描述写得更具体最好给出正例和反例。评委模型能力不够。如果评委模型和被评估模型能力接近评分就会不稳定。换更强的评委模型。温度参数没设对。评委模型的temperature应该设为0或接近0保证输出稳定。5.2 评估成本太高怎么控制LLM-as-a-Judge的成本主要来自评委模型的API调用。控制成本的方法包括用更便宜的模型做初筛只对边界样本用强模型复评减少评估频率从每次PR改成每天定时优化提示词长度减少不必要的token消耗对检索评估这种不需要LLM的环节坚决不用LLM5.3 评估指标和线上表现不一致这是最让人头疼的问题。评估集上指标很好但线上用户反馈很差。原因通常是评估集不能代表真实分布。解决办法是持续从线上收集bad case加入评估集。另外评估集的查询分布应该定期和线上查询分布做对比确保没有严重偏移。5.4 常见问题速查表问题可能原因排查方向评分一致性低于80%评分标准模糊/评委模型弱细化评分档描述换更强评委检索Hit Rate突然下降分块策略变更/索引重建检查分块配置和索引版本生成忠实度低但检索指标正常生成模型忽略上下文检查提示词是否强调忠于上下文评估结果波动大评估集太小/样本分布不均扩大评估集检查样本分布CI中评估超时评估样本太多/API限流减少样本量或增加超时时间5.5 几个我踩过的坑坑一评估集泄露。有一次我把评估集里的样本不小心用作了few-shot示例导致评估指标虚高。后来我严格分离了评估集和提示词示例确保没有重叠。坑二忽略检索延迟。早期我只关注检索质量指标忽略了检索延迟。上线后发现P95延迟超过3秒用户体验很差。后来在评估中加入了延迟指标把延迟也作为CI的检查项。坑三评分标准频繁变更。有段时间我频繁调整评分标准导致历史评估结果没法对比。后来我规定评分标准变更必须走版本管理每次变更都要记录变更原因和影响。坑四过度依赖单一指标。曾经有一段时间我只盯着忠实度指标优化结果发现回答变得越来越短、越来越保守完整性大幅下降。后来我建立了多指标联合评估任何单一指标都不能独立决定优化方向。5.6 评估流程的持续迭代Evals不是一次性的项目而是持续迭代的过程。我建议每两周做一次评估流程的回顾评估集是否需要新增样本评分标准是否需要调整评估指标是否还反映真实质量CI/CD中的阈值是否需要更新这个回顾不需要很长时间但能保证Evals体系始终和业务目标对齐。6. 从Evals到持续改进的闭环Evals的最终目的不是生成一堆数字而是驱动系统持续改进。一个完整的闭环应该是评估发现问题 - 分析归因 - 实施改进 - 重新评估验证 - 上线监控。在这个闭环中最容易断裂的环节是“分析归因”。很多人跑完评估看到指标下降就慌了但不知道从哪里下手。我的经验是先看检索再看生成最后看提示词。检索问题通常最容易定位也最容易修复生成问题需要看bad case具体分析提示词问题往往最隐蔽需要对比不同版本的提示词效果。另一个容易忽略的环节是“上线监控”。评估集上的指标再好也不能保证线上没问题。线上监控应该关注用户反馈率、重新生成率、对话中断率等行为指标。这些指标和评估指标结合才能全面反映系统质量。我个人在实际操作中的体会是Evals这件事起步阶段最重要的是跑通流程而不是追求指标多漂亮。先用小规模评估集把检索评估和生成评估跑起来建立起基线然后再逐步扩大评估集、细化评分标准、接入CI/CD。整个过程可能需要几周时间但一旦跑通后续每次迭代都会变得有据可依不再靠感觉做决策。最后分享一个小技巧如果你不确定评分标准怎么写可以先找10条样本自己人工打分然后让评委模型也打分对比两者的差异。差异大的地方就是评分标准需要细化的地方。这个方法我用了很多次每次都能快速定位评分标准的模糊点。
