摘要

• AI 领域的每个应用场景都有其独到的挑战。在系统承载了生产环境的流量后，开发者就需要开始监控边界场景和特殊案例

• 系统化视角：将大语言模型看作是系统组件而非独立存在，其性能与可靠性需要完善的可观测体系和防护机制，且要与用户需求和商业目标保持动态对齐

• 构建能及时反应用户问题的指标告警机制，同时建立指标清理流程以淘汰过时监控项

• 围绕业务发展方向构建指标体系，既要匹配当前阶段目标，也要整合历史经验教训

• 不要将事情复杂化。采用渐进式开发模式，先搭建基础指标框架，再完善监控基础设施，最终实现系统成熟度的阶梯式提升

Denys Linkov 在 QCon 旧金山技术大会上发表了题为《构建 LLM 系统评估微观指标的框架设计》的专题演讲。本文整理自该演讲内容，重点探讨大语言模型（LLM）准确性评估所面临的独特挑战，并系统地阐述了如何通过创建、跟踪及动态修正微观指标体系来持续优化 LLM 模型表现。

你是否遇到过这样的场景：修改了系统提示词却导致生产环境出现问题？运行了所有的测试用例，更新模型前也有进行充分的评估，一切看起来都没什么问题，直到有人在 Discord 服务器上 @ 你，抱怨说系统完全挂掉了。

这个关于微观指标的构想，源自于作者在 AI 代理平台 Voiceflow 上修改系统提示词时的亲身经历。仅仅是调整了与模型交互的提示词模板，却意外引发了一个典型案例：某用户在使用德语与模型对话时，前四次交互中模型都能正确使用德语回答，但在第五次对话时，模型却突然切换成了英语的回答。客户对此非常不满，质疑为什么模型在全程使用德语的对话中会突然改用英语。纳闷的不只是用户，作者也摸不着头脑。

LLM 平台的开发，或者说任何类型的平台开发，都是充满挑战的。

如何定义优质的 LLM 回答？

在开发 LLM 应用时，什么才算是优质的模型回答？这个问题颇具哲学以为，因为人们很难在“优质”这方面达成统一的意见。

LLM 迷人的同时也惑人。它们的答案听起来总是那么地令人信服，即使答案本身是错误的。人们不仅仅对“优质回答”的评判标准存在分歧，有时甚至都不会仔细阅读模型输出的内容。为了评估回答的质量，开发者往往会采用正则表达式或精准匹配、与标准数据集的余弦相似度对比、用 LLM 做评判，或者是用传统的数据科学评估指标。

单一指标的局限性

故事从我的一次经验教训开始。首先是单一指标的局限性，以支撑 RAG（检索增强生成）进行相似短语检索的语义相似度为例，用 OpenAI 的最新模型以及两个排名靠前的开源模型来对比，“我喜欢吃土豆（I like to eat potatoes）”和三个短句的匹配度，猜猜看哪个短句的匹配度最高？

对比短句如下：

• I am a potato（我是土豆）

• I am a human（我是人类）

• I am hungry（我饿了）

图一：语义相似度的挑战

三个模型都选择了“我是土豆”。这个结果很神奇，将“我喜欢吃土豆”和“我是土豆”相匹配，暴露了依赖余弦相似度或语义相似度的模型存在的缺陷。从实际的语义来看，“我饿了”甚至是“我是人类”都比“我是土豆”合理。这个案例说明了评估的指标并非在所有场景下都可靠。

让 LLM 来评估

业界普遍利用大语言模型（如 GPT-4）作为自动评估工具，这种做法常见于需要批量处理大模型回答但又不想人工去审核的场景。但这些模型中存在偏见：2023 年的一项研究中发现，在评估简短提示词 GPT-4 与人类判断的一致性较低，但对长段提示词的评估效果却更好。多项研究都印证了这种评估偏见，这种偏见背后的原因在于模型在训练过程中学会了人类的某种思维模式倾向或偏好。

那么让人类来评估是否就会更可靠呢？标准化的测试给出了答案。二十多年前的一篇针对 SAT 作文评分的 研究 显示，仅凭文章长度这一项指标，就能准确预测阅卷人的评分结果。这暴露了人类评判的类似倾向：我们往往更关注文章长度等表面指标，而非实际的内容质量。

“优质”究竟该如何定义？用户是更愿意在油管上看猫咪视频还是 LLM 相关视频？油管上的奶猫视频有 3.6 千万的播放量，而 Karpathy 的技术讲座却只有四百万的播放量，那么我们就能得出结论，“猫猫比 LLM 要更好，我们显然应该只向用户推送猫猫相关的内容”。社媒可能会赞同这种结论，但这也暴露了单纯依赖播放量或准确率等指标的局限性。这些评估标准本身就不完善，仔细想想不难理解。

通过观察人类指使人类干活的方式，我们会发现不同任务的指令精确度存在着显著的差异。以我在麦当劳打工的经历为例（一段塑造了我性格的经历），炸鸡块的流程说明极其详尽，操作指南中详细规定了烹饪时间，没有在规定时间内取出鸡块，还会有计时器哔哔响。但像是“拖地”这样的任务，说明就相对较为模糊。如果你不知道什么是拖地又不去追问具体步骤，那你大概会把地弄得一团糟。现实中的任务指令往往会界于这两种之间。

图二：麦当劳的操作指南

这些例子都反映了人类指令的模糊性：有些笼统概括，有些精准详尽，更多的则是界于这二者之间。

在进行模型性能评估时，提供具体的反馈很重要。这一点在很多团队管理相关的项目讲座中经常被强调。以麦当劳为例，绩效评估经常会涉及“冰激淋甜筒转了几圈”这类的详细问题，我经常会因为转了太多圈而被找麻烦，这也可能是冰激凌机常出故障的原因，谁知道呢。

这些反馈有时很具体，有时又很模糊。LLM 的评估指标中也存在类似情况，不是因为 LLM 人性化了，而是反馈框架的工作原理相同。绩效评估中“干得不错”这种模糊的反馈对如何改进毫无作用，LLM 评估也是如此。如果只是说“模型出现了幻觉”，那我大概会觉得“好吧，那这条信息又有什么用？”

将模型视作是系统

让我们从系统视角来看待模型。如果你从事过可观测性相关工作（例如编写指标、追踪和日志），就会明白监控的重要性。这一点同样适用于大语言模型系统，模型不是部署了就可以撒手不管的，不然告警通知就足够让你喝一壶的。可观测性主要涉及三种事件类型：日志、指标和追踪。

• 日志：发生了什么？

• 指标：程度如何？

• 追踪：问题为什么会出现？

这些监控手段的粒度从粗到细依次为：指标、日志、追踪。对 LLM 来说，指标可以重点关注模型性能衰减和内容审核等维度；在模型性能衰减方面，延迟等指标能快速地识别服务提供商或推理节点的问题，但对模型回答的评分则需要更长的时间（几秒甚至几分钟）。在企业环境中，挑选最佳模型这类离线任务可能会需要花费数周甚至数月时间来完成。

生成内容的审核指标则需要实时的响应。面对垃圾信息攻击时，下周才会运行的批量任务毫无意义；你需要清楚地明白指标的用途，可接受的延迟范围，以及后续要如何行动。

将应用划分为实时和异步两类，指标设计也可以如下划分：

• 实时指标：用于检测需要立即处理的问题，如模型性能衰减、事件超时或模型返回无效输出

• 异步指标：适用于模型选择等任务，可能涉及运行评估或技术讨论

• 防护机制：根据具体场景，既可采用实时模式也可采用异步模式

图三：实时指标、异步指标，以及防护机制

你可以使用并定义的指标没有上限，但归根结底，你是要用这些指标为未来三个月的业务决策或技术决策提供支持。从数学角度来说，优秀的指标应该能同时提供量级和方向信息——就像向量既有大小又有方向一样。

构建用户问题预警指标体系

无论是即时风险还是长期隐患，构建能够预警用户问题的指标体系至关重要。对于任何成功产品而言（无论是内部工具还是对外服务），系统失效都意味着用户流失。

回到前面讲到的 LLM 回答用错了语言的例子，是用户主动报告了这个问题，我们才能在其影响到企业级用户之前及时完成验证。虽然问题很难复现，但通过对日志的分析，我们定位到了一次异常响应的记录。对此的解决方案是添加一套防护机制，在毫秒级的时间窗口内检测回答的语言种类，如果和问题语言不匹配则立即触发重试机制。这种实时处理方案的效果远超传统的异步处理模式。

在决定指标到底是用实时还是异步时，要结合具体的场景进行判断。以内容审核为例，实时标记或过滤不当内容是个很好的策略。在指定指标时，应始终与业务场景结合，思考其可能带来的结果。

无论是内部还是对外产品的开发，核心都在于要赢得用户的信任。最基础的要求时保障产品的基本可用性，再进一步是创造卓越的使用体验。客户信任如同岛屿，只要产品稳定运行且持续创造价值，企业就能在这片陆地上稳步发展。

图四：客户的信任如同岛屿

系统故障（比如前文提到的回答语言错误）会导致客户信任的流失，客户会因为他们客户的投诉而愤怒，此时的你可以选择以下这些补救措施：提供补偿方案以消减用户不满的情绪、部署自动重试等修复机制、编写根因分析（RCA）报告说明故障根源与解决方案。虽然能否重建信任取决于客户态度，但核心目标始终是通过确保产品功能正常来修复信任关系。

系统架构越复杂，可观测性建设就越具挑战性。采用 RAG 等前沿技术构建的复杂 LLM 管道，会明显增加调试与监控的难度，但如果将 RAG 拆分为检索和生成两个组件，将会有效简化监控工作。针对检索环节，重点在于上下文优化：确保提供相关信息的同时剔除可能干扰回答生成的冗余内容，在已知排序的情况下平衡查准率与召回率。生成环节的指标则需关注格式正确性、答案准确性以及多余信息的控制，还可进一步细化出准确度、回答长度、角色一致性等维度，甚至设置“禁止使用‘delve’等特定词汇”的硬性规则。RAG 的多组件特性决定了不同环节需要差异化的评估指标。

聚焦业务指标

至此，你可能已经为自己的应用场景构想了若干指标，但说到底，这些指标是必须要能创造商业价值的。举例来说，如果 LLM 生成了敏感内容，那这会对业务造成多少损失？不同企业的风险承受能力差异明显，取决于目标客户群体和应用场景，业务团队需要评估具体的损失参数。同理，法律咨询用的 LLM 若是给出错误建议（例如鼓动用户"起诉邻居"），将会引发严重的后果。我们需要将这些错误量化成经济损失，进而决定指标体系的投入规模、安全机制的追加成本，以及在线检测可容忍的延迟阈值。例如前文提到的错误翻译案例，其潜在损失该如何评估？

构建指标体系和部署 LLM 的根本目的，归根结底是为了节省人力时间成本。所有的自动化系统和前沿应用，核心价值都在于提升效率。当然，社交媒体类应用除外，这类应用目标是尽可能延长用户在线时间。或许你会觉得业务逻辑完全不在自己的职责范围内，开发者只要负责写好代码就成。但这种观点存在两个误区：首先，理解业务背景是技术决策的前提，开发者必须清楚自己构建的系统要解决什么问题；其次，虽然业务团队承担主要的价值评估工作（这本就是他们的职责），但技术团队也需要主动与业务团队保持战略对齐。

业务团队需要明确使用场景、理解功能如何与产品集成、评估投资回报率（ROI），并选择合适的模型。虽然开发者不该在这类讨论中置身事外，但指标体系的建设也不仅仅是技术团队的责任。在 LLM 广泛应用于各类产品的今天，业务团队也必须投入时间以定义适合自身产品的评估指标。

确保指标体系与当前目标保持一致，并整合实践中的经验教训。在 LLM 应用上线过程中，团队必然会积累大量新认知，因此我们需要建立指标清理机制，及时淘汰过时的评估标准。

小步快跑

最后分享一些更具实操性的建议。不要一开始就追求完美，采用"小步快跑"的渐进式策略。这同样适用于指标体系的建设。我们首先需要深入理解使用场景，确保业务和技术团队达成共识。这就是我对于评估 LLM 成熟度和指标体系成熟度的基本思路。

图五：LLM 指标体系的小步快跑策略

在刚刚起步阶段，想要实施指标体系就需要完成一些准备工作。首先，明确构建的目标及其价值定位。准备好评估数据集，如果没有现成的，那就需要投入时间创建。同时，建立基础的评分标准和日志系统，这样才能跟踪系统运行状态、理解系统行为，并判断哪些是正常现象哪些是异常情况。可以从内容审核或基于评估数据集的准确率指标开始，这些初始指标可能不够完美，但能为后续优化提供了基础。

到了中期，我们对系统所面临的挑战有了深入理解，知道薄弱环节、有效机制和问题点都有哪些。此时的我们对如何解决或至少如何进一步调查这些问题形成了明确假设。我们需要建立反馈闭环来验证假设、通过日志或用户数据收集反馈，从而解决这些问题。理想情况下，我们已经尝试使用基础指标，现在是时候引入更细化的指标了。例如，可以加入召回率指标（如净折扣累计增益）、答案一致性指标来优化温度设置和评估权衡，或者实现语言检测功能。这些更具体的指标需要更多基础设施支持才能有效实施。

在“快跑”的阶段，我们已经可以自信地展示成果了。内部不仅有构建的大量优质自动化工具（如自动提示词调优），指标体系也与具体目标高度对齐；此时得我们可能已经积累了高质量数据用于微调（虽然这也算是业务决策）。在这个阶段，指标体系完全可以根据需求定制，因为我们已经充分理解了系统和产品，能够准确识别所需的微观指标。

总   结

本文中我们探讨了五个关键要点：单一指标可能存在缺陷，“我是土豆”这个例子能清楚地表明这一点。模型不仅仅是独立的 LLM，它们是更广泛系统的一部分，特别是随着 RAG、工具使用或其他集成功能的增加，复杂性也在增长。构建能够预警用户问题的指标至关重要，要聚焦于影响产品表现且与业务目标一致的维度。在使用 LLM 改进产品时，保持简单很重要。遵循"小步快跑"的方法论。最不可取的做法是用二十来个无后续行动的指标填满系统仪表盘，最终让自己不堪重负。不要过度复杂化：坚持"小步快跑"的渐进策略。