做过 LLM 应用的工程师大多遇到过这样的场景：功能上线前手工测了几轮都正常，第二天用户就贴出了模型胡编乱造的截图；改了提示词再跑一遍又好了——但没人说得清是修好了，还是这一次碰巧没出错。要回答这个问题，靠调试不够，得靠系统化的评估（Evaluation，业内常简称 Evals）。本文整理自 System Design Newsletter 上的一篇长文，作者 Anshuman Mishra 在 Zomato（印度头部外卖平台）负责内部 LLM 评估平台 Gavel 的建设。原文面向的是会写软件、但刚开始接触 LLM 应用的工程师，把评估领域的 29 个核心概念一次讲全。我们在编译时补充了国内团队落地时的模型选择、工具对应关系和几处原文没有展开的坑。
为什么传统测试思路在 LLM 上失灵
开始建评估体系之前，得先弄清楚 LLM 评估和常规软件测试的差别在哪里。差别不在难度高低：规则本身变了。原文归纳为三个问题：
1. 非确定性问题。普通函数同样的输入永远得到同样的输出，LLM 不是——同一个提示词每次运行都可能给出不同回答，有时差一点，有时完全不同。这不是缺陷，而是由采样温度（temperature）决定的特性。它动摇的是测试的底层假设：跑一次测试、通过或失败、得出结论，这套思路默认了程序是确定的。对 LLM 来说，一次通过的测试只是一个数据点，不是结论。你不是在测试一个函数，而是在从一个概率分布里抽样，抽一次几乎说明不了什么。
2. 正确性模糊问题。正则表达式匹配就是匹配，二值、客观、没有争议。但”有同理心地总结这条客服工单”的正确答案是什么？最简洁的算对，还是措辞最温和的、事实最全的、人工评审打分最高的？LLM 输出的质量是多维且主观的，通常不存在唯一正确答案，只有一段可接受的区间和一段糟糕的区间，分界线靠人来判断。没定义”好”是什么样，就没法评估——多数人跳过了这一步，后面的环节都会跟着出错。
3. 静默回归问题。更新了提示词，跑几次看着更好了，就发布了——质量到底提升了没有，还是碰巧抽到了好样本？没有系统化评估流程，每次改提示词都是盲赌，可能修好一个失败模式的同时引入了另一个，而你毫无察觉。传统软件有 CI（持续集成）在上线前拦住回归，LLM 工程没有现成的等价物，很多团队靠感觉和抽查，等用户投诉才发现问题。
评估体系的基础词汇
下面这组术语在评估领域出现频率最高，弄懂它们，其余内容就顺了。
4. 评估标准（Criteria）：针对你的具体场景、需要关注的质量维度。客服机器人关心的是有没有解决用户问题、语气是否得体、会不会不必要地触发升级投诉；代码生成工具关心的完全是另一套——语法是否合法、是否符合项目规范、是否解决了给定问题。同样的技术，标准截然不同。这是产品决策，不是技术决策，没法外包给模型或评估框架，团队里得有人坐下来回答”什么样的输出算好”。这一步定错，下游全在测错误的东西。
5. 质量维度（Quality Dimensions）：行业通用的输出质量词汇表，最常用的五个是——相关性（回答的是不是用户问的）、连贯性（逻辑是否自洽、行文是否通顺）、事实准确性（说的是不是真的，一条回答可以既相关又是错的）、有用性（用户拿到答案后能不能继续往前走）、安全性（是否避开了有害、偏见和不当内容）。写评分细则时对照这五个维度，能少漏失败模式。
6. 评分细则（Rubric）：把模糊的标准落成可打分的具体问题。”有用性”太虚，细则把它拆成：是否直接回答了问题？是否避免了不必要的含糊其辞？是否在 200 字以内？非技术用户能否看懂？类比代码评审清单——不问”这代码好不好”，而是问有没有测试、函数是否超过 30 行、变量命名是否达意。细则是评估可复现的前提：同一条输出、同一份细则，两个评审（不管是人还是 AI）应该给出接近的分数。没有细则，评估就只是某个人的观点。
7. 测试用例（Test Cases）：一条输入/输出对，是评估的最小单元。输入是提示词，最好来自真实用户流量；输出要么是一条参考答案（示范好的输出长什么样），要么是待打分的线上模型输出。它和单元测试的区别在于：用例失败不代表输出错误，而是在你的细则上得分低于阈值。数量要够——几条用例只能提供轶事，几百条才有信号。
8. 黄金数据集（Golden Set）：一批精心挑选的高质量测试用例，评估体系里的一切都以它为基准。建好它比想象中难：本能的做法是自己写例子、覆盖预想中的用法，但用户的措辞方式和你想的不一样，会撞上你没料到的边缘情况，还会用各种方式误用功能。凭想象搭出来的黄金集反映的是你的想象，不是用户的行为——所以要用脱敏、清洗过的真实生产查询来做种子。把它当关键系统资产对待：版本化管理，发现新失败模式就更新。
9. 通过阈值（Pass/Fail Threshold）：评估分数很少是二值的，细则通常产出 1-5 分、0-10 分或百分比，阈值负责把分数变成决策——1 到 5 分制、阈值设 3，低于 3 就算失败。原理简单，定起来难：取决于用户能容忍多大程度的不完美、你所在领域的失败有多严重、误判的代价有多大。阈值定太低是在发布垃圾，定太高则什么都发不出去。这同样是产品决策。
10. 评估覆盖率（Eval Coverage）：黄金集对真实用户输入的反映程度。多数团队覆盖率很低而不自知——黄金集是自己写的，覆盖了主路径和几个明显的边缘情况，而生产流量里全是奇怪的输入、罕见的措辞、没人预料到的用法。覆盖率低意味着评估结果偏乐观：测试全过，用户照样翻车。解决办法不是自己再多写例子，而是定期从生产环境抽样、复盘失败案例，把暴露出新弱点的输入补进黄金集。覆盖率是长期积累出来的。
11. Temperature、Top-p 与可复现性：temperature 控制输出的随机程度，接近 0 时模型近乎确定（同输入同输出），调高则采样范围更宽、回答更多样。Top-p（核采样）是相关设置，不调随机度而是设概率截断，top-p 取 0.9 表示只从概率最高的 90% 候选 token 里选。两者都直接影响评估结果：temperature 设 1.0 跑评估，同一条提示词今天过、明天挂，不是模型变了，只是随机采样这一次偏向了另一侧。行业惯例是评估时把 temperature 设为 0 锁定确定性；生产环境需要创造性变化的，就按生产温度测，但要接受结果噪声更大。这里补充一个原文没有展开的坑：temperature=0 也不能保证完全确定。主流推理服务在 GPU 浮点运算、批处理调度和 MoE 架构的路由上都存在非确定性来源，OpenAI 的文档也只承诺”大致确定”。所以就算锁了温度，关键结论仍然要靠多次运行来确认，这正是下一条存在的理由。
12. 统计严谨性（Statistical Rigor）：即便 temperature 为 0，单次评估也不够。黄金集只是输入空间的一个样本，样本自身有方差——一组不走运的例子能让好提示词看起来很差，反过来也一样。所以要跨不同样本多次运行，汇报均值和方差，而不是单个分数。比较两个提示词版本时，先确认差异是真实的还是噪声：分数从 4.1 涨到 4.3，可能是改进，也可能是随机波动，没有多次运行的方差数据就分不清。多数团队跑一次、报个数、直接上线，很多回归就是这样带着信心被部署出去的。
谁来打分：从人工到 LLM 裁判
有了标准、细则和测试用例，下一个问题是打分由谁执行。可选项按成本、速度、准确性各有取舍。
13. 人工评估：黄金标准。人按细则审输出、给分数，慢、贵、还可能不一致，但它是最接近真实判断的方式。人工没法覆盖每轮评估，也绝不能完全砍掉——指标、LLM 裁判、自动测试都只是对人类判断的近似。人工要用在刀刃上：构建和校验黄金集、定期抽查自动评估的准确性、出了说不清的问题时用来排查。
14. 启发式/代码评估：最快最便宜的一类，用简单的代码检查验证输出的结构属性——返回的是不是合法 JSON、有没有超出字数限制、必填字段全不全、有没有出现违禁措辞、格式是否匹配指定正则。它擅长抓结构问题，但测不了质量，判断不了回答是否有用、准确、通顺。把它当第一道防线：在跑更贵的评估之前先拦下基础错误。
15. 语义相似度评估：手里有参考答案时，衡量模型输出和参考答案在语义上（而非字面上）的接近程度。原理是嵌入向量（embedding）：每段文本转成一组代表其含义的数字向量，含义相近的文本向量彼此靠近，用余弦相似度衡量夹角，1.0 表示含义相同，接近 0 表示不相关。它解决的是字符串匹配过于严格的问题——”API 返回 404 错误”和”接口响应未找到状态”用词不同、意思一样，精确匹配会判后者错，语义相似度能判它们等价。局限也明确：它只衡量与参考答案的接近程度，一条流畅但事实错误的回答，只要恰好和正确答案语义相近，它就抓不出来。当成快速、可扩展的一层用，别单独依赖。
16. 任务专用指标：某些任务有现成的自动化指标。BLEU（Bilingual Evaluation Understudy）源自机器翻译，衡量生成文本与参考文本的 n-gram 重叠度，适合措辞精确度重要的任务；ROUGE（Recall-Oriented Understudy for Gisting Evaluation）为摘要设计，衡量召回——参考答案里的要点有多少出现在了输出里；执行式评估（Execution-based）用于代码生成，逻辑最直接：跑起来没有？输出对不对？拿生成的代码跑测试用例看结果。三者共享同一个局限：衡量的是与参考的表面相似度，不是质量本身，在合适的任务上用即可。
17. LLM 充当裁判（LLM-as-Judge）：评估规模化的关键。用一个更强的模型来给你的应用输出打分，喂给它三样东西——原始输入、待评估的输出、你的评分细则，它返回分数和理由。类比自动化压测：没人手工点完一万条用户流程去查回归，LLM 裁判做的是同样的事，让你的细则跑遍几千条输出而不用几千个人时。GPT-5 和 Claude Opus 是常用的裁判模型，走 API 调用即可，无需自己训练。但裁判也会错——它有自己的偏见和盲区，是对人类判断的近似，不是替代。国内落地补充两点：一是 OpenAI 和 Anthropic 的 API 在大陆无法直接访问，需要相应的网络环境或经由合规的第三方中转；二是 DeepSeek、通义千问（Qwen）等国产模型的旗舰版本已经普遍被用作裁判模型，API 单价明显低于 GPT-5 和 Claude Opus 且直连可用，对判分这类指令明确的任务，多数场景够用——更稳妥的做法是先用国产裁判跑量，再用人工抽查校准（见第 19 条）确认它靠得住。
18. 逐点评估与成对评估（Pointwise vs Pairwise）：LLM 裁判的两种问法。逐点是”给这条输出打 1-5 分”，简单快速，每条输出一次调用；成对是”这两条输出哪条更好”，通常更可靠，因为比较比打分容易，特别适合验证新提示词是否胜过旧版。成对的短板是成本——一次评两条输出，开销接近翻倍，小规模下无所谓，生产规模下累加得很快。行业标准做法是分层：在线评估（生产监控）用启发式或小型裁判模型，便宜到可以持续运行；离线评估（上线前测试）用手头最强的裁判模型，逐点、成对都跑——只在部署前运行，成本可以接受。把强裁判当部署前的关卡，而不是每个请求都过一遍的东西。补一个使用成对评估时的已知坑：LLM 裁判存在位置偏差，倾向于偏爱先出现的候选答案，标准对策是交换两条答案的顺序各跑一遍、结果不一致则记平局。多数评估框架已内置这个处理，自己写裁判提示词时容易漏。
图：LLM 裁判的工作方式——三项输入，两项输出（据原文示意图重绘）
19. 裁判校准（Judge Calibration）：依赖 LLM 裁判之前，得先知道它和人类判断的吻合程度。方法是抽一批输出，让人和裁判分别打分，统计一致率：一致率高，裁判是人工评估的合格代理；一致率低，它可能在测别的东西。未经校准的裁判有风险——它会让你对错误的结果产生信心。用之前校准，之后定期重校，换模型或改提示词后尤其要重来一次。
RAG 系统怎么评估
现在的 LLM 应用大多不是”提示词进、回答出”，而是用检索增强生成（RAG）：先取回相关文档、注入上下文，再生成有依据的回答。这确实能减少幻觉，但没有根治，还引入了标准 LLM 评估抓不到的新失败模式。
20. RAG 三元组（RAG Triad）：评估 RAG 系统的标准框架，三个维度。忠实度（Faithfulness）问答案是否来自检索到的上下文——这一点常出人意料：文档检索得再准，模型照样可能无视它们，凭空给出一条自信但没有出处的回答，那就是多绕了一步的幻觉。答案相关性（Answer Relevance）问回答是否切中了用户的问题——回答可以完全忠于上下文，却答非所问；忠实度查的是模型有没有越出上下文，答案相关性查的是有没有对准用户意图。上下文精确度（Context Precision）问检索环节取回的文档对不对——检索质量差，再完美的生成模型也无力回天，只能瞎猜或者告诉用户不知道。把 RAG 看成检索、增强、生成三个阶段，每一段都可能单独出错，三元组就是定位问题出在哪一段的可观测层。工具落点：开源框架 Ragas 就是围绕这套三元组指标构建的，配合 LangSmith 或 Langfuse 这类追踪平台可以直接落地，不必从零写指标。
图：RAG 三元组——三个维度分别盯住三个环节（据原文示意图重绘）
21. RAG 常见失败模式：懂框架是一回事，实战里认出故障是另一回事。最常见的三种——其一，检索返回不相关的片段（上下文精确度失败），模型要么编造内容填坑，要么说信息不足，修复在检索层：嵌入质量、分块策略、重排序。其二，检索正确但模型无视它（忠实度失败），通常是提示词问题，没有强制模型依赖给定上下文，修复方向是加强提示词约束。其三，答案有依据但帮不到用户（答案相关性失败），多半说明知识库里缺少对的信息，该修的是数据，不是提示词。
上线前与上线后：两套评估环境
22. 离线评估：发生在上线前。改了提示词、换了模型版本、调了检索策略，先对着黄金集测一轮、打分、和当前系统对比，质量下降就拦在部署之前——相当于给 LLM 配一条 CI 流水线。这里用你最准的裁判模型（比如 GPT-5、Claude Opus 这一档），因为只评有限的一批样例，不跟着用户请求量走，成本压力小。
23. 在线评估：发生在生产环境。持续抽样线上输出并打分，目标是抓离线评估漏掉的问题——边缘情况、罕见输入、只在规模化时才出现的故障。可以把它理解成 LLM 版的监控系统，在用户投诉之前发现问题。主要约束是成本：不可能每个请求都过一遍最贵的模型，所以在线评估靠启发式和小型裁判模型撑起来，用一些准确性换规模。两者要配合：离线拦住已知问题，在线捕捉意外问题，缺一套系统就不完整。
24. 提示词版本管理与回归测试：提示词就是代码，照代码的规矩办——进版本控制、留历史、可对比差异，出了问题能查到什么时候改了什么。回归测试指对每个提示词版本跑完整评估套件：旧版 4.2 分、新版 3.8 分，回归被抓住了，用户还没看到。听起来简单，多数人没做，因为缺前置设施——没有黄金集、没有清晰细则、没有基础工具。做不做这件事，决定了一个团队是能放心迭代，还是只能改完上线再碰运气。工具落点：promptfoo、LangSmith、Langfuse 都支持提示词版本对比加批量回归，接入门槛不高，可以从 promptfoo（开源、本地跑）起步。
基准测试能信多少
25. 基准评估（Benchmark）：用标准化试题比较不同模型。MMLU（Massive Multitask Language Understanding）测跨学科知识，数学、科学、法律、医学都考，相当于给模型做通识考试；HellaSwag 测常识推理，给出场景开头让模型预测后续（早期模型在这一项上普遍表现不佳）；HumanEval 测代码生成，给函数签名让模型写实现，用 pass@k 计分——k 次尝试内做对的比例。查排名有两个常用榜单：Hugging Face Open LLM Leaderboard（开放权重模型）和 Chatbot Arena（LMSYS 出品，按人类偏好排名）。
26. 基准与真实场景的落差：基准分不能告诉你模型在你的场景里好不好用。MMLU 拿 90% 的模型可能照样处理不了你的领域术语，HumanEval 高分模型生成的代码未必符合你的工程规范。基准衡量通用能力，你的应用需要的是特定能力。正确用法：拿基准缩小候选范围，再用自己的黄金集跑自己的评估做最终决定。
27. 数据集污染（Dataset Contamination）：多数工程师忽视的基准缺陷。评估数据和模型训练数据重叠时，模型等于提前看过答案，高分反映的是记忆而不是能力。训练数据和基准数据都来自互联网，重叠程度往往无从知晓，于是常用基准会随时间越来越不可信——这也是新基准不断出现的原因。对策：别拿网上的公开示例做自己的评估数据，用真实用户查询自建数据集。
五种典型的评估反模式
28. 工具都对，系统照样可能建歪。原文点了五个最常见的错误。凭感觉评估——”试了几次看着不错”是最普遍的一种，非正式抽查制造虚假信心，不覆盖边缘情况、不追踪长期表现、也没法超出一个人看几条输出的规模，感觉可以当起点，当不了评估体系。单样本陷阱——评估套件跑一次就报结果，而 LLM 是非确定的，坏提示词可能碰巧好看，好提示词可能碰巧难看，要多跑多样本、汇总时报方差。古德哈特定律——”指标一旦成为目标，就不再是好指标”，对某个指标优化过猛，它就不再衡量你关心的东西：奖励自信会得到自信的幻觉，奖励长度会得到冗长的低质回答，指标只是质量的代理，别错当成目标本身。评估与生产脱节——黄金集反映你的预期，真实用户含糊、难测、用法出人意料，评估不贴近真实用法，分数就是误导，不真实的数据上跑出高通过率不代表系统能用。忽视尾部失败——92% 的通过率好看，剩下 8% 呢？LLM 的失败往往是灾难式而非优雅降级，一条有害或错误的回答造成的影响可能超过几百条正确回答，所以失败案例要逐条复盘，不能只看平均分——最差的那批输出恰恰包含最多信息。
五层评估堆栈与三步起步方案
29. 没有单一工具能解决 LLM 评估，可行的是分层体系，每层接住上一层漏掉的问题。第一层启发式检查：快、确定、免费，每条输出都过，拦格式错误、缺字段、违禁内容。第二层语义相似度加任务指标：对着参考答案自动跑，不花裁判的钱就能抓到含义层面的失败。第三层离线 LLM 裁判：部署前在黄金集上用最强裁判模型跑，拦质量回归。第四层在线 LLM 裁判：生产环境抽样，用更小更便宜的裁判模型，抓离线漏掉的规模化故障。第五层人工抽查：周期性运行，保持校准、验证自动评分仍与人类判断一致，并把新失败案例补回黄金集。每层成本结构不同、接的故障类型也不同，最终五层都要有，但不必第一天就齐。
图：评估堆栈的五层结构——越往上单次成本越高（据原文示意图重绘）
从零起步，原文给了一个三步最小方案。第一步，建一个 50 条的黄金集：别全靠自己写，有真实用户查询就用真实的；没有就写 30 条代表性用例加 20 条边缘用例，涵盖正常输入、对抗性输入和用户可能尝试的奇怪表述。这份数据集就是整个评估体系的地基。第二步，加一条确定性的启发式检查：挑出输出最重要的那个结构要求——长度、格式、必填字段或违禁词，写个简单的代码检查。构建成本极低，拦住的问题比多数人预期的多。第三步，加一个 LLM 裁判提示词：把细则改写成裁判提示词，用强模型对黄金集在一个最重要的质量维度上打分，认真读分数和理由，通常会发现一些意料之外的问题——暴露这些问题正是这一步的目的。之后的一切——成对比较、在线监控、RAG 打分、回归测试——都在这个最小系统上叠加。对多数团队来说，这三步加逐点打分已经能支撑日常迭代，成对评估留到做模型选型或提示词大改版时再上并不迟。
写在最后
评估不是收尾工序，而是让迭代成为可能的那套基础设施。传统软件工程用惨痛教训换来了 CI、自动化测试和生产监控，LLM 系统需要同样的纪律，差别只在输出是非确定的、更难度量。原文的建议是从简单起步、逐层搭建评估堆栈；照本文第 29 条的三步方案动手，一两天内就能有一个能用的最小评估系统，之后每次改动是好是坏，在用户看到之前就能得到答案。站内此前编译过《从零构建 LLM：GPT 和 Claude 背后的 5 个训练阶段详解》和《AI Agent 团队怎么搭：从单个智能体到生产级协作的 9 个阶段》，分别覆盖模型训练侧的背景知识和多智能体系统的生产实践，可与本文互为补充。
原文链接：29 LLM Evaluation Concepts Every Engineer Needs to Know（System Design Newsletter）
© 版权声明
文章版权归作者所有，未经允许请勿转载。
