第 5 章 评估与运维

学习目标

• 确定可测量的成功标准，构建包含真实分布与边界案例的评估集。
• 为各标准选择适当评分方法，对照人工评分校准LLM评分器。
• 固定模型版本，设计更换前回归评估与分阶段切换流程。
• 保留故障追踪所需日志与追踪信息，同时尽量减少个人信息。
• 从运维问题出发，定义指标、正常范围、告警与负责人措施。

引言

供应商宣布推出速度更快、价格更低的新模型当天，一家公司的管理层就要求下周完成切换。开发团队选了十个有代表性的问题进行测试，得出答案“同样不错”的结论。切换两周之后，客服中心收到了大量投诉。在偶尔才出现的复杂咨询中，新模型经常遗漏一个关键条件；而按照旧模型设置的某个参数，在新模型中被悄悄忽略了。这些问题，单靠十个问题的测试是看不到的。

LLM功能在投入生产运行之后，仍然会不断变化。模型以概率方式运行，供应商持续推出新模型、让旧模型退役，用户输入也会随时间改变。本章介绍如何用数字作出判断，而不是依赖“好像运行得不错”的感觉。我们将依次学习成功标准与评估集、评分方法与评分器校准、结果解读、固定版本与更换流程、日志与追踪、个人信息、运维指标，以及按功能管理成本。

核心概念

运维就是仪表飞行

飞行员在云层中飞行时，看的是仪表盘，而不是窗外。因为感觉容易骗人，仪表却会如实显示规定的测量项目。LLM功能也一样。只读几个答案就作出的判断，容易受到选择偏差影响，也容易遗漏罕见的失败。运维的仪表盘有两类：变更前运行的离线评估，以及生产运行中持续观察的指标。两者都必须从同一套成功标准出发，才能相互比较。

先确定成功标准

Anthropic文档指出，良好的成功标准应具体、可测量、可实现、与目标相关。将“性能要好”细化为“咨询分类准确率”等具体指标，用定量指标或定义明确的量表测量。大多数功能需同时考察多个维度。

每项标准都要事先写明合格线。看到结果后再定标准，就容易让数字迎合想要的结论。

构建评估集

评估集就是生产功能的回归测试。它是一组固定输入、预期结果（或评分标准）以及评分方法的集合。

1. 反映真实分布。 从生产日志中抽取样本，使业务类型、长度和语言的比例与实际情况一致。个人信息要先按照后文介绍的方法处理。
2. 加入边界案例。 Anthropic文档给出的例子包括无关或不存在的输入、过长的输入、有害输入和含糊不清的输入。在此基础上，再加入自身业务的高风险场景（金额较大的业务、出现危机信号的咨询）。
3. 按失败成本加权。 对于出现频率低、但造成损害大的场景，增加样本数量，并单独统计结果。
4. 分开开发集与验证集。 修改提示词时不断查看的输入，与只用于最终判断的输入，必须分开，才能避免对评估集过拟合。
5. 管理版本。 将输入、预期结果与评分代码一起保存在代码仓库中，每次修改都留下记录。

Anthropic文档建议，与其使用少量由人工精细评分的题目，不如使用大量能够自动评分的题目。只有具备一定规模，才能发现细微的回归。

选择评分方法

优先选择快速、可靠、可扩展的方法。Anthropic文档总结如下。

同一文档也举出各标准的指标：与答案精确匹配（分类）、句子嵌入相似度（相似问题答案的一致性）、ROUGE-L（在有参考摘要的评估集中衡量摘要对关键信息的捕捉）、LLM的1～5分量表（语气）、LLM二元判定（是否含个人信息）。每项标准配一种方法，就能立即看出哪个维度恶化。

校准LLM评分器

LLM评分器虽然方便，但它本身也是模型，因此同样存在错误和偏差。在使用之前，需要先进行校准。

1. 具体编写评分标准表（量规）。写明判定条件，例如“第一句话没有说明处理时间安排，就判为不合格”。
2. 限定输出范围。只允许输出“合格／不合格”或1～5分等预先规定的值。叙述式评价很难进行大规模比较。
3. 让评分器先推理，再给出分数。Anthropic文档说明，使用启用了思考功能的评分模型，可以提高复杂判断中的评分表现。
4. 使用与生成模型不同的模型进行评分。Anthropic文档中的示例代码，也将这一点列为推荐做法。
5. 与人工评分样本进行比较。先由人工对50～100条样本评分，再测量一致率。如果评估集中合格或不合格明显偏向一方，还应查看校正偶然一致的指标（如Cohen's kappa），或各等级的精确率与召回率。如果未达到标准，就修改量规。
6. 检查已知偏差。确认是否存在答案越长、给分越宽松的倾向；比较两个答案时，还要调换顺序，检查评分器是否偏爱先出现的答案。
7. 固定评分模型和量规的版本。评分器一旦改变，分数的含义也会发生变化。

解读结果：波动与分组

解读评估结果时，经常遗漏三点。

• 波动。 同一输入每次运行可能不同（第1章）。100条输入中，1条就是1个百分点。1～2个百分点的差异可能只是偶然，应重复运行相同评估集，先测波动范围。
• 配对比较。 与其分别比较两个设置的平均值，不如对同一输入逐项比较，统计新设置获胜与落败的案例。阅读落败案例能看到原因。
• 分组。 平均分提高，重要分组却可能恶化。应按业务类型、长度、高风险与否分别统计，高风险组设独立合格线。

固定模型版本

生产应用应固定到特定的模型版本。OpenAI文档建议，将生产应用固定到某一个模型快照，以保持行为的一致性。根据Anthropic模型列表，从4.6代开始，包括不带日期的ID在内，所有Claude模型ID都是固定快照；更早模型的别名，则是指向带日期ID的便捷名称。每个模型都会公开退役时间（“不早于这个日期”），因此固定版本并不是永久保证，而是为规划更换模型争取时间的机制。

仅仅固定模型ID，还无法解释结果为什么发生变化。应把各项设置作为可复现的配置组合来管理。

更换模型前进行回归评估

是否更换模型，应看它能否超过预先确定的标准，而不是看它“似乎更好”。

1. 先写下标准。 包括整体合格线、高风险场景的合格线、延迟与成本上限、停止条件以及负责人。
2. 用同一个评估集比较现有配置与候选配置。 使用验证集，并通过配对比较，阅读新配置落败的案例。
3. 重新调整参数。 不要直接沿用旧设置。用评估集重新测量推理强度，找出并删除新模型拒绝或忽略的设置（采样参数、预填充、强制工具选择）。token数量也要用新模型重新计算。
4. 进行影子运行。 把一部分生产流量也发送给候选模型，但不向用户展示候选的结果，只用来比较。涉及修改操作的工具，不实际执行。
5. 逐步切换。 先迁移一部分流量，并持续观察指标。一旦达到停止条件，立即回退。
6. 保留记录。 保存比较结果、作出的决定及配置组合，作为下一次更换时的基准。如果将评估运行纳入部署流水线，在未达合格线时阻止部署，那么即使只是修改提示词，也能遵守同样的流程。

日志与追踪

调查故障必须能找回特定请求。Claude API在每个响应中提供唯一request-id头，错误正文也包含request_id，Python与TypeScript SDK可通过响应对象的_request_id读取。向供应商咨询时需要此ID。

一个用户请求若引发多次模型调用与工具执行，逐调用日志无法展示全貌。应为一项业务分配追踪ID（trace ID），将模型调用、工具执行分别记录为子跨度（span）。采用OpenTelemetry等分布式追踪标准及生成式AI约定，便于工具之间统一格式。

默认不记录原始提示词与响应。确有需要时，同时确定较短保留期、访问控制、脱敏措施。

处理个人信息

个人信息从用户输入开始，会被复制到供应商、日志、评估集、批处理文件、缓存等多处。遮住一个姓名不够，必须管理完整流向。

法律原则。 韩国《个人信息保护法》（2026年9月11日施行）第3条规定，仅收集处理目的所需最少个人信息，尽量减少对隐私的侵害；若匿名化可实现目的，应匿名处理，否则采用假名化。第2条将假名化定义为删除或替换部分个人信息，使之在没有附加信息时无法识别特定个人。健康信息等敏感信息依第23条，仅可在取得单独同意等例外情况下处理。第26条规定，委托个人信息处理业务应以书面约定，并公开委托业务与受托方；第28条之8规定，向境外提供、委托处理或存储，须满足法定条件之一。单独同意是典型方式；为履约所需的委托处理、存储，也可通过在隐私政策公开或通知转移事项的方式满足要求（第1款第3项）。第29条要求内部管理计划、访问记录保存等安全措施。实际适用应与个人信息负责人、法务共同确认。

供应商端保留。 政策因供应商与合同而异，应查阅文档。

用户标识符。 为检测滥用行为而发送用户标识符时，应使用不透明的值。Anthropic建议，不要在metadata.user_id中放入姓名、电子邮箱或电话号码，而应使用UUID或哈希值；OpenAI则建议将用户名或电子邮箱哈希后，作为safety_identifier发送。这样，在发生政策违规时，就能够追踪到具体用户，而不是只能追踪到整个组织。

定义运维指标

只收集指标，会让它成为故障结束后才打开的记录本。应从运维问题出发，将指标、正常范围、告警、负责人措施串在一行。

技术指标（错误率、延迟）与业务指标（自动处理率、人工修改率）应并存。即使响应全为200且速度快，人工仍需每次重写，这个功能就失败了。

按功能拆分成本与限额

当多个功能共用一个账户时，一个功能的流量失控，就可能让其他功能也停止运行，而且仅看账单无法知道原因。因此，应利用供应商提供的隔离单位。Anthropic允许为每个工作区设置低于组织限额的支出上限和速率限制（默认工作区不能设置，组织限额始终适用）。通过响应中的anthropic-workspace-id头，可以确认用量计入了哪个工作区。OpenAI则在组织和项目两个层级设置速率限制。再结合日志中的功能标签与客户标签，就能计算每个功能、每家企业客户的成本。

深入阅读

避免绑定评估工具

评估数据与评分标准是公司的资产，但如果只把它们放在某个平台内部，就会受制于该平台的生命周期。现实中就有这样的例子。根据OpenAI文档，OpenAI Evals平台从2026年10月31日起，对现有用户改为只读，并计划在11月30日关闭。OpenAI也正在停止支持仪表盘中的可复用提示词对象，并建议将生产提示词保存在应用程序代码中。

这个经验与使用哪一家供应商无关。应把评估输入、预期结果、评分代码与量规、提示词及配置组合保存在代码仓库中进行版本管理，并把评估运行器设计成只需更换供应商适配器就能运行。托管评估工具可以用于执行与可视化，但原始资料应留在代码仓库。只有这样，在更换模型时，才能持续保留以同一标准比较更换前后结果的记录。

将反馈回流到评估集

只有把生产运行中发现的失败，转化成下一版评估集中的题目，才能避免相同的失败再次发生。

1. 收集信号。 记录明确反馈（赞、踩、举报），以及间接信号（重新生成答案、客服人员修改了草稿的大部分内容、用户立即关闭窗口）。
2. 进行分类。 按照原因，将失败案例分为事实错误、格式问题、语气问题、工具误用等类别。
3. 转化为评估题目。 处理其中的个人信息后，附上预期结果，加入评估集，并提升评估集版本。
4. 定期运行。 即使没有修改设置，定期运行评估，也能及早发现输入分布的变化或未曾预料到的行为变化。

工作场景

海谈福利基金会：平均分提高，遗漏却更多

社会福利法人“海谈福利基金会”运行着一项功能：对咨询人员填写的咨询记录进行摘要，并标出危机迹象（提到自伤、疑似虐待、紧迫的生计危机）。基金会为了节约费用，考虑换用更便宜的模型，由信息系统负责人廉组长承担回归评估。

评估集是从过去半年咨询记录中抽取的320条记录。记录已经过假名化处理，并特意增加了含有危机迹象的记录，共纳入70条。摘要质量由LLM评分器按1～5分评分，危机迹象的标记则通过代码，与社会工作者标注的正确答案进行比较。评分器使用了不同于候选模型的模型，并在与两位社会工作者评分的60条记录比较、确认一致率为0.86之后，才投入使用。

评估结果出现了分歧。摘要质量的平均分从4.1分升到4.3分，但危机迹象的召回率却从96%下降到88%。通过配对比较阅读遗漏的案例后，发现新模型经常漏掉委婉的表达（“最近想把一切都放下”）。而事先确定的高风险场景合格线，是95%。

廉组长暂缓了全面更换，提出将功能分成两条路径：危机迹象判定继续使用现有模型，只有摘要生成迁移到新模型。同时，将被遗漏的表达类型加入评估集，用于下一次候选模型的评估。仅根据平均分就更换模型的意见，以及只凭评分器分数作判断的意见，都被否决。部分切换后，费用减少了35%，危机迹象召回率则保持不变。

洁衣坊：取件备注中的入户密码

洗衣取送应用“洁衣坊”会将客户填写的取件备注生成摘要后传给配送员，并对请求类型分类。一次安全检查发现了问题。客户会在备注中填写入户密码和联系方式，而这些原文在应用日志中保留90天，在评估集CSV中则无限期保留。评估集还被分享给了外部质量审核公司。

个人信息负责人河经理与开发负责人奇经理，先画出了数据流图。备注沿着应用→订单DB→模型API→日志、评估集、每周批处理文件的路径不断复制。随后采取了以下措施。

1. 在入口处遮蔽信息。向模型发送备注之前，将电话号码和疑似密码的数字串替换成占位符，再检查摘要结果中是否原样保留了这些占位符。在配送员应用中，订单DB中的原文只向有权限的配送员展示。
2. 日志不保留原文，只记录元数据：追踪ID、供应商请求ID、模型ID、token数量、分类结果和校验结果。
3. 用经过假名化处理的样本重新构建评估集，并确定保留期限。回收、删除原有CSV及共享副本，在CI中加入检查：如果评估集出现个人信息模式，就判定检查失败。
4. 检查供应商一侧的设置与合同。关闭对话状态存储，更新隐私政策中有关委托处理的事项，并与法务一起审查是否构成个人信息跨境转移。

在系统提示词中添加“不要输出个人信息”的方案被否决，因为它不能解决输入被复制到日志和评估集的问题。彻底关闭日志的方案也没有采用，因为那样就无法追踪故障。一个月后的复查发现，仍保留原始个人信息的副本只剩生产DB这一处。

易错点

• 使用指向最新模型的别名，就会自动变好。 这样可能在未经验证的情况下改变行为。生产环境应使用固定版本，更换模型则通过评估决定。
• 固定版本，就可以永远使用同一个模型。 模型有退役日程。固定版本只是为了争取规划模型更换的时间。
• 测试几个有代表性的问题就足够了。 这样会遗漏罕见高风险案例和边界案例的回归。需要反映实际分布的固定评估集。
• 平均分提高了，就可以更换模型。 重要场景的表现仍可能变差。应为各个分组分别设置合格线。
• LLM评分器可以直接信任。 必须与人工评分样本进行对照和校准，并管理评分器的偏差与版本。
• 为了调试，应把全部原文长期保存。 这样会增加个人信息风险。日志应以元数据为主，原文只在必要范围与必要期限内保存。
• 供应商不把数据用于训练，就没有个人信息问题。 数据保留、滥用监测、委托处理、跨境转移，以及我们自己的日志和评估集，都是需要分别处理的问题。

要点速览

• 成功标准：具体、可测量、可实现、相关。合格线在看结果前确定。
• 评估集：真实分布＋边界案例＋高风险加权，开发与验证分离，仓库版本管理。
• 评分：按代码→LLM→人工选择，LLM评分器必须对照人工样本校准。
• 解读：测波动范围、配对比较、分组统计。
• 版本：固定快照＋配置组合。Anthropic从4.6代起所有ID都是固定快照。
• 更换：先标准→同集比较→重新调参→影子运行→分阶段切换→记录。
• 日志：追踪ID、供应商请求ID、配置版本、用量、停止原因。默认不留原文。
• 个人信息：最少收集、假名化，确认供应商保留政策，审查委托与跨境转移，使用不透明用户标识。
• 指标：问题→指标（分母）→正常范围→告警→负责人措施，同时关注业务指标。

查阅官方文档

• Anthropic — Define success criteria and build evaluations：阅读成功标准、评估设计原则、评分方法与LLM评分技巧。
• Anthropic — Models overview：确认模型ID与快照、退役时间、Models API。
• Anthropic — API and data retention：确认ZDR范围与各功能适用情况。
• OpenAI — Data controls in the OpenAI platform：阅读训练用途、保留期限、ZDR、数据存储区域。
• 韩国国家法令信息中心 — 个人信息保护法：阅读第2、3、23、26、28条之8及第29条。

自测

5-1. 列出良好成功标准的四个条件，并按照这些条件，将“回答质量要好”改写为至少两项可测量的标准。

5-2. 按顺序写出在将LLM评分器投入生产评估之前，必须完成的校准步骤。

5-3. 根据Anthropic文档，分别说明4.6代及之后的模型ID，与更早模型的别名具有怎样的性质，并解释即使固定了版本，仍然需要模型更换计划的原因。

5-4. 写出韩国《个人信息保护法》中假名化的定义，并说明在制作LLM功能的评估集时，可以如何应用这一概念。

5-5. 一个候选替换模型提高了评估集的平均分，却降低了高风险场景的分数。请写出应通过什么流程判断，以及可以作出哪些选择。

5-6. 选择一个正在生产运行的LLM功能，确定五个运维问题，并为每个问题设计一张表，包含指标（含分母）、正常范围、告警条件、负责人和第一步处理措施。

实操练习