1. 执行态稳定性为什么我们需要一个“通用标准”1.1 先聊聊我在实际项目中见到的“翻车现场”做LLM应用这几年我最常被问的一句话不是“效果怎么样”而是“为什么昨天还好好的今天就不行了”。这不是段子是真实现状。某次我们内部把一个客服机器人接进生产环境上线第一周全绿第二周开始出现诡异现象同样一句“我的订单什么时候到”上午回复“您的订单正在配送中”下午就变成“请提供您的订单编号”。用户被搞懵客服系统被投诉淹了。排查了半天模型没换提示词没改数据也没动唯一的变化是上游知识库某条记录被业务方静默更新了格式。更常见的还有这类同样是“帮我总结这篇文章”同一个模型在不同时间调用一次返回300字一次返回1200字一次直接说“我没看懂你的意思”。你说它是错了吗单看每回答似乎都能接受但放在一个对外产品里这种飘忽不定的表现会让用户觉得整个产品不可信。这些问题的本质不是“准确率”不够而是稳定性的问题——同一个系统在相似输入下没有给出一致的行为表现。而我们现有的评测体系几乎都在关心“准确率”“召回率”“BLEU”“Rouge”这类平均值指标它们能告诉你模型好不好但完全没办法告诉你这个LLM应用在真实运行环境里稳不稳。这就是我整理这个标准草案的初衷把“执行态稳定性”从一个模糊的感觉变成一套可以量化、可以复现、可以对比的指标体系和评估流程。1.2 “执行态”到底指什么一个容易被忽略的中间层很多做LLM的朋友会困惑说模型稳定性不是模型训练和推理框架的事吗模型参数固定了输出不应该是确定的吗这个认知对一半。单个模型在离线单次推理时确实是“相对稳定”的但一个真正的LLM应用从来不只是模型本身。它外面套着提示词模板接着知识库检索、工具调用、上下文管理、结果后处理甚至还有多轮对话的状态维护。我把这一整套东西在真实运行环境中的表现称为“执行态”。你可以把模型想象成一个员工。这个员工的能力模型训练结果是固定的但他在不同环境、不同任务、不同压力下的表现可能差异巨大。执行态就是考察“这个员工在工位上实际干活时的状态”而不是“他在面试时的状态”。执行态稳定性和传统意义上的模型稳定性有三点关键不同。第一它关注的是“应用整体”而不是“模型单点”第二它关注的是“多次运行的表现分布”而不是“单次推理的精度”第三它关注的是“异常恢复和边界行为”而不是“理想输入下的主路径表现”。所以这个标准适用的对象不只是算法工程师还包括做Agent开发的人、做LLM应用测试的人、做运维和SRE的人。只要你把一个LLM应用跑在线上你就有执行态稳定性的问题。1.3 这个标准能干什么、不能干什么U-ESS v1.0定位是一套“评估基准草案”不是“模型训练指南”。它试图回答三个问题第一你的LLM应用当前的执行态稳定性是“可接受”还是“不可接受”用什么定量方式判断。第二如果不可接受问题主要出在五个维度中的哪一个后续优化往哪个方向使劲。第三改动提示词、模型、知识库、工具链之后稳定性是变好了还是变差了用同一套标准横向对比。它不解决“怎么把效果调得更好”的问题。举个例子一个代码生成工具生成的代码能不能跑、跑得对不对这是效果问题不在标准覆盖范围内。但同一个需求描述让它生成10次会不会出现风格、结构、关键接口调用的剧烈波动这属于执行态稳定性是这个标准管的。评价一个标准草案能不能用我个人的判断标准很简单能不能让一个不太了解这个项目的人照着文档跑一遍得出一个可复现的结论。U-ESS v1.0就是按这个原则设计的。2. 标准框架U-ESS v1.0 的五个核心维度2.1 维度总览从“稳不稳”到“哪里不稳”起初在做内部评估方案的时候我列过40多个指标覆盖了延迟、Token开销、相似度、格式正确率、工具调用成功率等等。指标多了以后我发现一个特别尴尬的问题拿到报告不知道该看什么。后来我把指标收敛到五个维度每个维度由若干具体指标支撑整体形成一个“由粗到细”的评估结构。如下表所示维度编号维度名称核心关注点典型支撑指标D1输出一致性相同输入下输出是否稳定文本相似度、语义余弦相似度、关键信息覆盖偏差D2响应时效性延迟和吞吐是否可控P50/P95/P99延迟、Token生成速率、超时率D3语义连贯性多轮和长文本下语义是否跑偏上下文召回覆盖度、意图保持率、主题漂移率D4工具链稳定性工具调用、参数拼接是否健壮工具调用成功率、重试率、参数错误率D5恢复韧性异常发生后能否快速恢复错误恢复率、降级触发率、重复异常占比有人会问为什么要把“响应时效性”也算进稳定性我在实际运行中遇到过不止一次同一个Agent在任务复杂的时候延迟能差3倍以上这不是网络波动而是执行逻辑走到了不同的分支有的分支要调用多个工具有的分支直接返回缓存。用户感知到的“卡”“慢”“转圈半天没反应”其实也是稳定性的问题。2.2 每个维度的指标定义与计算方式我先说D1输出一致性。这个维度最常见的实现方式是构造N条标准输入对每条输入重复执行M次然后计算M次输出两两之间的一致性。文本层面可以用Rouge-L或者编辑距离做参考语义层面推荐用embedding计算余弦相似度。以我的经验单纯用文本相似度会误伤。同一个意思“这个东西多少钱”和“价格是多少”字符差异很大但语义一致。所以D1我建议同时输出三个数值文本相似度均值、语义相似度均值、以及“同义改写后的稳定性差值”。最后一个指标的含义是把输入做同义改写观察输出语义是否保持稳定这是对抗“提示词敏感”的有效手段。D2响应时效性关键不是平均值而是分位数。一个系统P50延迟200毫秒看起来挺快但P99延迟如果是5秒说明每100次请求就有一次让用户等到怀疑人生。我在标准里明确建议至少统计P50、P95、P99三档并给出超时率超过阈值时间未返回的请求占比。D3语义连贯性主要针对多轮对话和长文本场景。核心做法是把完整会话切分成片段检查每个片段的“意图保持度”。现实中常见的问题是模型在第三轮之后忘掉了第一轮的约束条件或者当上下文超过一定长度后开始重复之前说过的内容。D3需要结合具体业务场景定义“跑偏”的判定方式否则无法量化。D4工具链稳定性是我个人最看重的一个维度。LLM应用一旦接了工具调用输出就不再只是文本而是结构化的调用指令。模型可能把参数名拼错、把参数类型搞混、或者在一句话里包含多个工具调用时漏掉其中一个。D4的核心指标是“工具调用成功解析率”也就是模型发出的工具调用在语法和参数层面能被执行器正确解析的比例。D5恢复韧性衡量的是一个LLM应用面对异常时的表现。标准里定义了三类场景上游工具超时、知识库返回空结果、模型返回无效格式。恢复韧性的好坏看两件事一是系统能不能主动给出降级策略比如返回兜底话术二是降级后能不能在下一轮恢复正常。常见的不稳定表现是系统一遇到异常就开始连续报错或者直接卡死。2.3 等级划分不要只看一个总分U-ESS v1.0把稳定性划分为四个等级分别是A级稳定、B级基本稳定、C级弱稳定、D级不稳定。等级判定不是简单加权平均而是取各维度中的最低等级。这个设计我在内部讨论时特意坚持的。原因是LLM应用往往存在“木桶效应”D1到D4都很好但D5恢复韧性极差线上三天两头需要人工介入。如果按加权平均算总分这个短板会被其他维度掩盖。用“最低维度定级”的方式任何一个维度不合格都会拉低整体等级这样推动团队去补短板。等级划分的具体阈值不能一刀切因为不同业务对稳定性的容忍度差别很大。一个内部效率工具和一个面向用户的支付助手对延迟和一致性的要求完全不同。因此标准里给出的是“相对基线法”这个我放在下一节实操部分详细说。3. 实操落地一套可复现的稳定性评估流程3.1 测试集与场景设计稳定性测评的地基评估稳定性第一步是准备测试集。但这个测试集和平时做模型效果评估的测试集不一样。效果评估的测试集追求“覆盖更多真实分布”而稳定性评估的测试集追求“同一场景下的可重复采样”。我推荐的做法是构造场景样本库每个场景包含三部分标准输入、同义改写输入、边界输入。以客服系统为例标准输入是“我的订单什么时候到”同义改写输入是“请帮我查一下我的包裹配送到了哪里”边界输入是“我的订单”缺少关键实体、“今天我心情不好”完全无关的输入。标准输入用于测量“基准一致性”同义改写输入用于测量“提示词鲁棒性”边界输入用于测量“异常兜底能力”。一个合格的稳定性测试集每个场景至少要有10组这样的三元组整体场景不少于10个。也就是说最少准备300条样本。补充一句场景来自哪里我的习惯是直接捞线上真实日志。把线上日志里的用户输入按频率排序高频场景优先构造样本。千万不要闭门造车自己拍脑袋编场景否则评估结果和线上表现的相关系数会低得让你怀疑人生。3.2 五次运行法与指标计算测试集准备好之后进入执行环节。U-ESS v1.0推荐“五次运行法”也就是整套测试集完整跑5轮每轮之间清空所有缓存、重置上下文状态、模拟冷启动环境。为什么是5次次数太少统计意义不足次数太多成本过高。5次在多数场景下已经能暴露明显的执行态抖动后续如果资源充足可以加到10次。每次运行会记录原始输出、工具调用日志、延迟明细、异常事件等。基于这些原始数据计算维度指标。我拿D1举个例子假设某条标准输入跑了5次次输出分别是A1到A5。两两计算语义余弦相似度会得到5乘5的相似度矩阵。取上三角的10个数值做平均得到这条输入的“语义一致性得分”。再把测试集所有样本的得分汇总取均值和对P10分位数。为什么一定要看P10因为稳定性问题的本质在小概率事件上。均值能到0.95看起来很好但如果P10只有0.82说明仍然有10%的输入在重复运行时出现了比较明显的语义波动。D2延迟统计更直白。记录5轮中每次请求的响应时间直接算P50、P95、P99。这里有一个特别容易踩的坑LLM首Token延迟和完整生成延迟是两回事。首Token快不代表整体快长文本生成的尾段速度衰减可能非常明显。至少在标准里我建议同时记录首Token延迟和完整响应延迟不要合并成一个值。工具链稳定性D4的计算逻辑是每一次工具调用都会产生一个执行日志标记为“成功”“可解析但执行失败”“不可解析”三种状态。D4得分等于成功次数除以总调用次数重点观察“不可解析”的出现频率。3.3 稳定性评分与等级判定示例我在这里用一张虚拟的表格说明评分和判级的过程。维度实测数据示意相对基线表现维度状态D1 输出一致性语义相似度均值0.93P100.85基线为均值0.90P100.80优于基线D2 响应时效性P50260msP951.2sP993.8s基线为P50300msP995s优于基线D3 语义连贯性意图保持率92%长文本主题漂移率4%基线为意图保持率88%优于基线D4 工具链稳定性调用成功率94%不可解析率2%基线为成功率95%低于基线D5 恢复韧性降级触发率15%恢复率60%基线为恢复率70%显著低于基线这份数据里D1、D2、D3都不错D4略低于基线D5明显低于基线。按“最低维度定级”的原则整体等级只能判为C级“弱稳定”因为恢复韧性维度不达标。这个判定结果看起来很苛刻但在实际线上运行中D5表现差意味着所有其他维度的优势都会在异常发生时被一夜打回原形。恢复韧性差的产品用户遇到一次故障就可能流失前面的“优秀”都变得没有意义。计算过程中有一个细节定义基线时不能拿“最近一次评估的数据”当基线而应该先采一轮“当前生产环境稳定运行时的数据”作为初始基线。每轮迭代评估之后用滑动窗口更新基线但保留历史基线用于对比趋势。这样你能区分“系统确实变稳了”还是“基线本身在漂移”。4. 落地过程中最常见的几个坑4.1 指标全绿但线上体验还是差第一个坑来自我自己的团队。我们按标准跑了一遍评估五个维度全部达到B级以上大家欢欣鼓舞结果上线后用户投诉还在。后来排查发现原因是多模态信息的不一致。标准的输出一致性只评价了最终回复文本但用户真正在意的还有回复里附带的卡片、跳转链接、以及引用来源。系统经常回复内容稳定但推荐的商品卡片时而出现时而消失。这提醒我一件事执行态稳定性的边界必须包含应用层表现不能只看模型的文本输出。所以在实际应用标准时需要额外把“业务侧关键字段的稳定性”纳入D1范畴。比如返回的JSON里某个字段的格式是否恒定引用链接是否有效推荐位是否为空。我在标准草案里专门加了一个补充建议对每个应用明确列出“关键的对外表现元素”这些元素必须纳入稳定性评估范围。4.2 平均分掩盖了长尾问题第二个坑是“只看平均分”。之前内部一次评估里D3语义连贯性的均值分数达到了0.9看起来完全正常。但深挖数据后发现当输入长度超过一定阈值时连贯性得分急剧下降从0.9掉到0.6。均值被大量短文本的优秀表现拉高了长尾问题被掩盖。这也是我特别强调P10分位数的原因。建议所有维度指标在汇报时同时给均值、P50、P10或者P5并且在等级判定时优先看低分位。如果一份报告里P10和均值之间的差距过大说明系统存在“条件性不稳”一定可以找到某个触发边界。找到并标注这个边界比单纯提高均值更有价值。4.3 评估环境和生产环境脱节第三个坑也是最有讽刺意味的越严谨的评估流程越容易脱离真实环境。我们在测试环境里跑得很稳定一上线就波动。原因有很多最典型的是两点。第一测试环境的请求并发极低基本是串行的而线上是高并发LLM服务在高并发下的行为会变特别是上下文缓存命中率、流式输出稳定性、以及工具调用超时概率都会变化。第二测试环境的知识库快照和生产环境的实时数据不一致生产环境检索到的内容更“脏”格式更乱LLM处理这种乱格式时的稳定性明显下降。我的建议是评估环境尽量复用生产环境的配置哪怕是用“影子模式”在晚间低峰期跑一轮评估也比一个完全干净的测试环境可信得多。标准本身是通用的但每个团队落地时要主动做“环境适配”不要天真地以为在测试环境跑出A级就万事大吉。5. 一些补充建议与后续规划5.1 稳定性雷达图和回归监控我最终给团队输出的评估结果是一张雷达图五个维度各占一个轴。这样管理者一眼就能看到短板在哪里。同时我还引入了“回归监控”在每次修改提示词、切换模型版本、更新知识库之后抽取一个精简版测试集大概50到80条样本快速跑一遍确保稳定性没有回退。这个习惯很重要。LLM应用的迭代速度极快很多人改完提示词只看“效果变好没有”根本不看“稳定性有没有变差”。结果就是效果指标上升了线上投诉反而增加了。回归监控的测试集不用很大但必须固定保证每次对比的是同一批样本。5.2 标准当前的边界与未来方向U-ESS v1.0还有一个被很多朋友诟病的地方对多模态输出的覆盖不足。文本之外的语音、图像、视频生成目前只有很粗略的描述没有形成可量化的指标体系。我在后续计划里会把多模态执行态稳定性作为v1.1的重点方向。另一个待完善的方向是“分布式场景下的稳定性”。当LLM应用以多副本方式部署不同副本之间的行为差异如何评估目前标准里没有展开。现实中这部分问题越来越突出——同一个请求被负载均衡到不同副本结果差异如果过大用户体验也会受影响。就我个人的体会而言这套标准最大的价值不在于它的指标有多全面而在于它逼我们把“稳定性”这个模糊的概念拆成了可讨论、可量化、可追责的具体条目。标准在落地时千万不要教条化每个团队都应该根据自身业务特点增删指标项但评估流程和等级判定逻辑建议保持稳定否则就无法做长期趋势对比。最后分享一个小技巧如果团队预算有限先从D1和D4两个维度做起这两个维度是用低成本暴露问题最多的。D1帮你发现输出层面的飘忽D4帮你发现“看起来正常但实际在乱调用工具”这类深藏不露的问题。把这两个维度跑顺了再逐步扩展全套标准。