★ FEATURED ARTICLE 1. 为什么“没有标准答案”才是评估的真正分水岭做LLM应用的人迟早会撞上一堵墙你花了两周把Prompt调到自己满意上线后用户反馈却两极分化。你去翻日志想找问题发现有些回答明明“感觉不太对”但硬要挑毛病又挑不出来——它没有事实错误没有语法问题甚至格式都合规可你就是知道它不够好。这种场景就是评估体系真正开始变难的地方。上一部分我们聊的是有明确参考答案的评估比如分类任务对不对、抽取的字段准不准、数学题答案是否匹配。这类评估本质上是在做字符串比对或者语义相似度计算工程上好落地跑个脚本就能出报表。但现实中的LLM应用绝大多数场景压根不存在一个“唯一正确”的输出。你让模型写一段产品文案、生成一封客户回复邮件、总结一份会议纪要、给一段代码做重构建议——这些东西的“好”是连续的、多维的、带主观判断的你没法用一个标准答案去卡它。这就是标题里说的“当不存在一个简单的正确答案时”。这个阶段的核心矛盾在于评估的可靠性不再来自答案比对而来自评估标准的设计和评估者的一致性。你得从“找正确答案”的思维切换到“定义什么叫好”的思维。前者是工程问题后者是产品问题加工程问题的混合体。我见过不少团队在这一步翻车。他们的做法是让几个同事人工看一批输出凭感觉打个分然后取平均。这种做法的问题不在于“人工”而在于“没有校准的人工”——张三觉得7分算合格李四觉得7分是勉强及格王五打分全凭当天心情。最后你拿到的分数波动巨大根本没法用来判断一次Prompt改动到底是变好了还是变差了。所以这篇内容适合两类人看一类是已经把LLM应用跑起来、正在为“怎么证明它变好了”发愁的开发者另一类是刚开始搭评估体系、想少走弯路的团队。我会把无标准答案场景下的评估设计、自动化测试的落地方式、以及我踩过的坑按实操顺序拆开讲。核心关键词就三个评估标准设计、评估者一致性、自动化回归测试。2. 无标准答案评估的整体设计思路2.1 从“比对答案”转向“定义维度”有标准答案的时候评估逻辑是收敛的输出和参考答案越接近越好。没有标准答案的时候评估逻辑必须发散再收敛先把“好”拆成若干可独立判断的维度再对每个维度分别打分最后加权或者组合。举个具体例子。假设你在做一个“客服邮件自动回复”的LLM功能。你没法说某封回复是“正确答案”但你可以把它拆成几个维度事实准确性回复里提到的订单号、退款金额、时效承诺是否和后台数据一致语气得体度是否礼貌、是否匹配客户情绪、有没有过度承诺信息完整度客户问的三个问题是否都回应了格式规范性称呼、落款、段落结构是否符合模板要求拆完维度之后每个维度单独评估。事实准确性可以走规则校验或者小模型抽取比对语气得体度需要LLM评审或者人工打分信息完整度可以用覆盖度检查。这样一来一个模糊的“好不好”就变成了四个相对可操作的子问题。注意维度不是越多越好。我见过有人拆了十二个维度结果每个维度都要单独跑一遍评估成本翻了几倍最后发现其中六个维度的分数高度相关等于白拆。一般控制在4到6个维度比较合理拆完之后先做一轮相关性分析把冗余维度合并掉。2.2 评估者选型人工、LLM评审、规则引擎怎么配维度拆好之后每个维度要选一个“评估者”。常见的有三类人工评估、LLM作为评审、规则引擎。这三者不是互斥的实际落地时往往是组合使用。人工评估的优点是判断质量最高能捕捉细微的语境问题缺点是慢、贵、不可规模化而且评估者之间的一致性需要专门校准。LLM评审的优点是快、便宜、可批量跑适合做回归测试的日常守门员缺点是存在偏好偏差比如倾向于给更长的回答打高分、对某些表达风格有系统性偏好。规则引擎的优点是确定性、零成本、可解释缺点是只能覆盖结构化程度高的维度对语义质量无能为力。我的建议配置是这样的规则引擎打底LLM评审做主力人工评估做校准和抽检。具体来说能用规则判断的维度格式、字段存在性、长度约束、敏感词全部交给规则引擎这部分零成本且绝对可靠语义类维度交给LLM评审但评审Prompt要经过精心设计和校准人工评估不参与日常回归只在两个时机介入——一是建立基线时人工标注一批样本用来校准LLM评审二是定期抽检LLM评审的结果看有没有漂移。这个配置的逻辑在于日常回归测试追求的是“快速发现退化”不需要绝对精确LLM评审的噪声在批量统计下会被平均掉而基线校准和定期抽检追求的是“评估体系本身可信”这时候人工的判断力不可替代。2.3 评估体系的分层结构把上面的思路落成结构一个完整的无标准答案评估体系大概分三层层级作用评估者频率冒烟层快速拦截明显退化规则引擎每次Prompt改动回归层量化质量变化趋势LLM评审每次版本迭代校准层保证评估体系本身可信人工标注每周或每两周冒烟层跑得最快几秒钟出结果主要检查格式崩坏、字段缺失、长度异常这类硬伤。回归层跑得慢一些但能给出各维度的分数变化用来判断这次改动是整体提升还是局部退化。校准层最慢但它是整个体系的锚点——如果LLM评审和人工判断的偏差越来越大回归层的分数就不可信了必须重新校准。3. 核心细节解析评估标准怎么设计才不飘3.1 评分量表的设计要点无标准答案评估里最容易出问题的地方就是评分量表。很多人直接上“1到10分”的连续打分结果发现评估者不管是人还是LLM的打分分布极其集中大部分落在6到8之间区分度很差。这不是评估者不认真而是连续量表在没有锚点的情况下人的判断会自然向中间靠拢。更可靠的做法是行为锚定量表也就是每个分数对应一段具体的行为描述。比如评估“信息完整度”1分完全遗漏客户核心问题2分回应了部分问题但遗漏了关键诉求3分回应了所有问题但有一处回应不充分4分完整回应所有问题且每处回应都有实质内容5分完整回应所有问题且主动补充了客户未问但相关的有用信息这种量表的好处是评估者不需要自己脑补“7分是什么样”直接对照行为描述选最接近的档位就行。实测下来行为锚定量表的评估者一致性明显高于纯数字量表LLM评审的输出稳定性也更好。提示量表档位建议用4到5档不要用太多档。档位太多会导致相邻档位的行为描述难以区分评估者反而更困惑。4档差、中、良、优在大多数场景下够用需要更细区分时用5档。3.2 LLM评审Prompt的写法用LLM做评审Prompt的设计直接决定评估质量。我总结下来有几个关键点第一评审Prompt里必须包含评分量表本身不能只说“请打分”。要把每个档位的行为描述原样放进去让评审模型有明确的对照标准。第二要求评审模型先给理由再给分数。这个顺序很重要。如果先让模型输出分数它往往会先形成一个直觉判断然后编理由来圆这个分数先输出理由分数是理由的自然结论一致性更好。实测下来要求“先分析后打分”的评审结果和人工判断的相关性明显更高。第三给评审模型提供参考示例。在每个档位上放一两个标注好的样例让评审模型知道这个档位在实际输出里长什么样。这本质上是在做few-shot校准对提升评审一致性很有效。第四控制评审模型的输出格式。要求它输出结构化的JSON包含每个维度的理由和分数方便后续程序解析和统计。不要让评审模型自由发挥写一段话那样解析成本很高。一个评审Prompt的骨架大概长这样你是一个严格的评估员负责评估客服回复的质量。 【评估维度】信息完整度 【评分量表】 1分完全遗漏客户核心问题 2分回应了部分问题但遗漏了关键诉求 ... 【参考示例】 输出A对应2分... 输出B对应4分... 【待评估内容】 客户问题... 模型回复... 请先逐条分析该回复在每个客户问题上的覆盖情况然后对照评分量表给出分数。 输出格式 {reasoning: ..., score: 3}3.3 评估者一致性的度量方法评估体系建好之后你必须回答一个问题这个评估可信吗度量方法就是算一致性。如果是两个评估者比如两个人工标注员或者人工和LLM评审用Cohens Kappa或者Spearman相关系数。Kappa适合分类判断比如档位打分它扣除了随机一致的概率比单纯算一致率更严格。Spearman适合有序打分衡量的是排序一致性。如果是多个评估者用Fleiss Kappa或者Krippendorffs Alpha。后者更通用能处理缺失数据和不同量表类型。实操中的经验阈值是这样的Kappa在0.6以上算可接受0.8以上算良好。如果低于0.6说明要么量表设计有问题档位描述不够清晰要么评估者培训不到位要么这个维度本身主观性太强不适合单独评估。我遇到过某个“创意度”维度的Kappa只有0.3后来发现是量表里“有创意”和“较有创意”的描述太接近评估者根本分不清把这两个档位合并之后Kappa直接上到0.7。注意一致性度量不是做一次就完事了。每次修改量表、更换评审模型、调整评审Prompt之后都要重新算一遍一致性。我见过团队改了评审Prompt之后忘了重新校准结果回归测试跑了两周最后发现LLM评审的标准已经漂了两周的数据全部作废。4. 自动化测试的落地实现4.1 测试集的构建与维护自动化测试的前提是有一个稳定的测试集。无标准答案场景下测试集的构建逻辑和有标准答案时不一样你不需要为每条样本准备“正确答案”但你需要保证测试集覆盖了足够多的场景类型和边界情况。构建方法我一般分三步走。第一步是从真实日志里采样按场景类型分层抽样保证每种典型场景都有代表样本。第二步是人工补充边界样本也就是那些真实日志里少见但一旦出问题就很严重的场景比如客户情绪激烈、问题涉及多个订单、回复需要引用政策条款等。第三步是给每条样本打上场景标签和难度标签方便后续按维度分析退化情况。测试集的规模起步阶段50到100条就够用关键是覆盖度而不是数量。等应用迭代到一定阶段再逐步扩充到几百条。维护上要注意两点一是测试集要版本化管理每次改动都记录改了什么、为什么改二是定期做“测试集审计”把那些所有版本都拿满分的样本剔掉它们已经失去区分度补充新的困难样本。4.2 评估流水线的搭建一条完整的自动化评估流水线大概包含这几个环节加载测试集从版本化的存储里读取样本和标签批量推理用当前版本的Prompt跑一遍所有样本拿到模型输出规则检查跑冒烟层的规则校验标记硬伤LLM评审对通过冒烟检查的输出逐维度跑评审Prompt结果聚合把各维度分数按场景标签聚合算出整体指标和分场景指标对比基线和上一个版本的指标对比标记显著退化生成报告输出可读的评估报告包含分数变化、退化样本清单、评审理由摘要这个流水线用脚本就能搭不需要什么重型框架。核心是把每一步的输出都持久化下来方便回溯。我习惯把每次运行的原始输出、评审结果、聚合指标都存成带时间戳的文件这样任何时候都能回答“上周三那次改动到底影响了哪些样本”。批量推理环节要注意控制并发和重试。LLM接口偶尔会超时或者返回格式异常流水线里要有重试机制和失败标记不能让一条样本的失败拖垮整批。评审环节同理评审模型的输出要严格校验JSON格式解析失败的样本单独标记出来人工看一眼不要静默丢弃。4.3 退化检测与告警策略评估流水线跑出分数之后怎么判断“这次改动是不是引入了退化”直接看平均分是不够的因为平均分可能被少数样本的极端变化拉偏。我一般用三个信号组合判断信号一整体指标变化。各维度平均分和上一个版本对比变化超过预设阈值比如0.3分就标记。阈值不能设太敏感否则每次改动都告警团队会麻木也不能太迟钝否则真退化了发现不了。我的经验是先用历史数据算一下正常波动的标准差阈值设在两倍标准差左右。信号二分场景退化。整体平均分没变但某个场景类型的分数明显掉了这往往比整体退化更值得警惕。比如整体信息完整度持平但“多订单场景”的完整度掉了1分说明改动可能对复杂场景有负面影响。信号三退化样本集中度。如果退化样本集中在某几类输入上说明问题有规律容易定位如果退化样本随机散布可能是评审噪声或者模型本身的随机性需要多跑几次确认。告警策略上我建议分两级冒烟层失败直接阻断发布回归层退化触发人工复核但不阻断。人工复核看的是退化样本的评审理由判断是真退化还是评审噪声。这个复核环节不能省我踩过的坑就是有一次回归层告警团队直接回滚了改动结果后来发现是评审模型那天接口不稳定导致的一批异常分数白折腾一场。5. 常见问题与排查技巧实录5.1 LLM评审分数虚高的排查这是最常见的坑LLM评审给出的分数普遍偏高几乎所有输出都拿4分以上区分度极差。排查思路按顺序走先看评审Prompt里有没有明确的低分档位描述。很多评审Prompt只详细描述了高分档低分档一笔带过评审模型自然倾向于往高分靠。把每个档位的行为描述写得同样具体尤其是低分档要给出明确的“什么情况该打低分”。再看有没有给评审模型“打分偏严”的指令。评审模型默认倾向于礼貌和宽容你需要在Prompt里明确说“请严格评估不要因为回复整体通顺就忽略信息遗漏”。这句话对分数分布的影响比想象中大。最后看参考示例的分布。如果few-shot示例里高分样例占多数评审模型会模仿这个分布。确保示例在各档位上均匀分布低分示例要真实、典型。5.2 评估结果波动过大的处理同一批样本跑两次评估分数差异明显说明评估不稳定。原因通常有三个评审模型的温度参数没设成0、评审Prompt里有歧义表述、样本本身处于档位边界。温度参数是最容易忽略的。评审任务必须用temperature0任何随机性都会引入噪声。歧义表述的排查方法是拿几条波动大的样本人工看评审理由如果理由里出现“可能”“似乎”“倾向于认为”这类词说明Prompt在该维度上的判断标准不够硬。档位边界问题则需要在量表里增加“边界处理规则”比如“当输出同时符合两个档位的描述时取较低档”。5.3 人工校准成本太高的优化人工校准是必要的但成本确实高。优化思路是主动学习式的抽样不要随机抽样本给人工标注而是优先抽那些LLM评审置信度低评审理由里出现犹豫表述、或者LLM评审和规则引擎判断冲突、或者处于档位边界的样本。这些样本的信息量最大少量标注就能有效校准评审体系。另一个优化是复用标注结果。人工标注过的样本进入一个“黄金集”后续每次校准都优先用黄金集里的样本这样标注成本是一次性的后续只是增量补充。黄金集要定期更新把那些评审体系已经稳定的样本移出补充新的困难样本。5.4 常见问题速查表现象可能原因排查动作评审分数普遍偏高低分档描述不具体、缺少严格指令、示例分布偏高分补全低分档描述、加严格指令、调整示例分布两次评估分数差异大温度非0、Prompt有歧义、样本处于档位边界设temperature0、人工看评审理由找歧义、加边界规则整体分持平但用户反馈变差评估维度没覆盖用户真实关切回看用户反馈补充或调整评估维度人工和LLM评审一致性低量表档位描述模糊、评审Prompt缺示例重写档位描述、补充few-shot示例、重算Kappa回归测试跑得太慢评审串行、样本量过大评审并发化、冒烟层和回归层分离、按场景分层抽样6. 我在实操中沉淀的几条经验评估体系这件事最反直觉的一点是它的价值不在于给出一个精确的分数而在于给出一个稳定的方向。你不需要知道这次改动让质量从7.2提升到了7.4你只需要知道它没有让任何维度退化、并且在某个维度上有可感知的提升。追求精确分数会把你拖进无止境的校准泥潭而追求方向稳定才是工程上可持续的。另一个体会是评估维度的设计要跟着产品阶段走。产品早期维度少一点、粗一点没关系重点是快速建立基线、跑通流水线产品成熟期维度要细化因为这时候每一分质量的提升都需要精确定位问题所在。我见过团队在早期就设计了八个维度结果每个维度都没校准好评估结果完全不可信还不如先做三个维度做扎实。最后分享一个具体技巧每次修改Prompt之后先跑冒烟层再抽10条样本人工快速过一遍最后才跑完整回归。这个顺序能帮你用最低成本拦截大部分明显问题避免每次小改动都跑一遍昂贵的完整评估。10条样本的人工过目大概只要五分钟但能拦住八成以上的低级错误。等确认没有明显问题再让完整流水线跑起来这时候你关注的就不是“有没有崩”而是“有没有细微退化”了。
阅读完成 · 觉得有帮助？
