Prompt 卧推：对“快乐路径”之外的提示词进行压力测试

一个在你的评估集（eval set）上得分 92%，但在真实生产流量中得分 60% 的提示词（prompt），并不是一个有 bug 的提示词。它是一个评估集在结构上无法发现 bug 的提示词。这种差距并非噪声，而是针对那些与提示词设计意图共享语域（register）、长度分布、语言和礼貌程度的示例进行优化的结果——而这些示例正是由编写评估案例的同一个意图所创作的。

真实用户不会配合你的设计意图。他们会发送三个词的片段、十二个段落的文章、作为问题粘贴的代码块、省略冠词的非正式语域、添加敬语的正式语域，以及你的 few-shot 示例从未涉及的语言查询。这些都不是攻击性的，这只是输入分布（input distribution）。如果你的评估集是由编写提示词的同一个人策划的，那么它几乎肯定与这种分布毫无相似之处。

缩小这一差距的学科不是“更多评估”，而是一种不同类型的评估——一个压力矩阵（stress matrix），它刻意改变你策划的集合中保持不变的维度，并对退化曲线（degradation curves）进行评分，而不是单一的准确率数字。称之为提示词卧推（prompt bench press）：你不是在测试提示词能否完成工作，而是在测试随着输入变得更难，它是如何失败的。

为什么策划的评估集在鲁棒性上撒了谎

标准的提示词评估工作流会产生一种特定的测试集。某个人——通常是提示词的作者——坐下来，列出一系列具有代表性的用例，编写 10 个、50 个或 200 个示例，通过提示词运行它们，对输出进行评分，然后迭代。结果就是一个展示了作者对任务心理模型的评估集。

这种心理模型是有形状的。示例聚集在作者认为自然的长度周围。它们使用作者认为中性的语域。它们是用作者思考的语言和方言编写的。它们有标点符号、大写字母且符合语法，因为作者习惯于使用标点符号、大写字母并遵守语法。提示词本身的 few-shot 示例加强了这种聚集：模型现在期望看起来像这些示例的输入，而评估集则证实了它可以处理看起来像这些示例的输入。

这不是一个凭空捏造的问题。这是如果不积极对抗，评估学科就会产生的默认结果。一项 2026 年对大语言模型（LLM）调用轨迹的行业分析发现，在生产环境中，5% 的生产跨度（spans）会直接失败，而更大比例的则是在静默退化——错误的输出看起来足够像样，能通过粗略一瞥，但经不起推敲。从结构上讲，评估集永远无法捕捉到这些退化的输出，因为退化的输出源自评估集未包含的输入。

失败的特征是可疑的整洁。当一个新的提示词在评估集上得分 89%，而之前的提示词得分 86% 时，团队会将其视为 3 个百分点的提升。在实践中，新的提示词可能提升了中位数，但恶化了长尾部分——原本就最难的输入变得更难了，而处于舒适中间地带的输入变得稍微容易了一些。头条数字上升了，但对于服务最差的那部分用户来说，用户体验下降了。直到支持工单显现出某种模式，才有人注意到这一点。

压力矩阵究竟包含什么

提示词基准（prompt bench）不是一个更大的评估集。它是一个结构化矩阵，独立地改变输入的特定维度，以便你可以测量提示词质量沿每个轴的变化，而不是在单个点上的表现。值得改变的维度是真实用户会改变的维度，以及你策划的集合可能会保持不变的维度。

长度。 在数量级上改变输入长度——单标记（token）片段、短语、单句、段落、多页文档。大多数提示词只针对其中一两个进行了调整，并在训练范围之外不可预测地退化。经测量，前沿模型在输入长度的每一次增加中都会损失准确率，而且退化早在宣称的上下文窗口之前就开始了——你的提示词不会仅仅因为上下文放得下就免受这种影响。

语域。 涵盖从简练到冗长、从正式到非正式、从电报式到华丽辞藻。如果一个客服提示词是在礼貌且格式规范的投诉上进行评估的，那么它可能会灾难性地误导一条“wtf 我的订单在哪”的消息，因为 few-shot 示例从未告诉它如何处理这种语域。

语言和区域（Locale）。 如果你的产品部署在五个区域，基准测试必须包含来自所有这五个区域的输入——不是你的英文评估集的翻译，而是从每个区域的用户中抽取的原生输入。翻译后的评估会遗漏母语人士特有的模式（习语、语码转换、关于日期和地址等格式的特定区域假设）。

正式程度和礼貌度。 敬语、模棱两可的语言、直接的祈使句和道歉式的开场白都会显著改变输入的嵌入（embedding），从而干扰输出。一个能利落处理“请总结一下”的提示词，在面对“总结这个。”或者“如果不麻烦的话，能否抽空帮忙总结一下这个？”时，表现可能会有所不同。

代码与散文混合。 纯散文、纯代码以及混合形式（嵌入在问题中的代码、粘贴在句子中的错误消息）的输入是三种截然不同的分布。提示词往往能很好地处理其中一种，而对另外两种处理欠佳。

带攻击色彩但良性的输入。 真实的输入有时包含看起来像指令注入但实际并非如此的文本——例如用户粘贴了一条包含“忽略之前的指令”作为引用笑话一部分的 Slack 消息，或者包含类似系统提示词前言的文档。你的基准测试应该包含这一类别。其失败模式是提示词对合法输入变得过度疑神疑鬼，而不仅仅是对恶意输入警惕性不足。

矩阵增长很快——六个维度，每个维度四个级别，就是 4096 个单元格——你不需要填满每一个单元格。沿每个轴进行稀疏采样，并在怀疑的薄弱点进行密集采样，就足以显现出退化表面的形状。

评判曲线，而非单点

这一规程的另一半在于你如何处理评测基准的输出。人们往往倾向于计算整个矩阵的单一准确率数值，并将其与上周的数值进行比较。这是一个范畴错误（category error）。建立评测基准是为了衡量质量如何变化；将其折叠回一个标量会丢弃所有的信号。

相反，你应该对性能退化曲线（degradation curves）进行评分。针对每一个变化轴，将提示词的质量绘制成该轴位置的函数。一个鲁棒的提示词会产生一条相对平坦的曲线——质量在不同输入长度、语域和语言中都能保持稳定。一个脆弱的提示词则会产生一条陡峭的曲线——在简单端质量优异，但在困难端则断崖式下跌。曲线的形状才是度量指标，而不是曲线下的面积。

这重新定义了回归测试。一个提升了中位数但恶化了尾部表现的提示词变更是回归。一个以牺牲一两个中位数点位为代价来平滑曲线的提示词变更则是改进。使用退化斜率作为发布阈值的团队，与使用绝对平均准确率的团队相比，交付的提示词有着本质的不同。

这种阈值的一个实际版本是：计算提示词在每个维度难度轴上的第 50、90 和 99 百分位数的质量。要求第 99 百分位数的数值不低于前一版本的第 99 百分位数。如果第 50 百分位有所提高且第 99 百分位保持不变，则可以发布。如果第 99 百分位下降了，无论第 50 百分位表现如何，该变更都是回归。这与延迟优化工程师多年来使用的逻辑相同——你不会因为中位数下降了就发布一个 p99 延迟翻倍的服务。

保持评测基准的真实性

一个僵化的评测基准比没有基准更糟糕，因为它提供了虚假的信心。最初固化的精选数据集变成了新的“理想路径（happy path）”；团队针对它进行优化；生产环境的数据分布偏离了它；不到六个月，该基准衡量的就是一种已不存在的工作负载。

防止僵化的数据收集规程是按长度百分比和语域类别对生产输入进行采样，然后将其反馈到评测基准中。这与“查看最近的失败案例”不同。这是分层采样：每周抽取一份新鲜的生产流量切片，按矩阵维度对其进行分桶，并更新生产分布发生偏移的单元格。评测基准随工作负载共同演进。

有两个实用的护栏。首先，在不同版本间保持一个从未参与训练的子集不变——即纵向回归测试。这是你用来与历史分数进行比较的切片。如果没有它，每一次“改进”都是不可证伪的，因为你同时更改了提示词和评测基准。其次，将评测基准自身的覆盖率作为一个度量指标。如果上个月 40% 的生产输入落入评测基准中样本少于 5 个的单元格，那么你的瓶颈是覆盖率，而不是提示词。

生产采样还能处理精选数据集无法处理的失败模式：团队未曾想象到的输入。最昂贵的 Bug 往往来自无人想到的输入类别。评测基准无法穷举“未知的未知”；如果你有纪律地进行采样，生产流量会自动将它们浮现出来。

将提示词评估视为鲁棒性问题

所有这一切最深层的含义是，提示词评估不是一个准确率测量问题。它是一个鲁棒性测量问题，其他工程领域中适用于鲁棒性测量的实践在这里可以直接应用。

服务可靠性团队不会只报告一个运行时间数值；他们会报告尾部延迟和失败模式分类。硬件工程师不会通过在室温下测试来认证芯片；他们会扫频电压、温度和时钟频率，以找到它的崩溃点。机器学习模型评估者已经超越了单一的准确率数值，转向捕获方差、尾部风险和行为偏移的分布感知指标。提示词评估一直是落后者，大多仍在一个精选数据集上报告一个数值。

这种转变在技术上并不难。构建压力矩阵与其说困难，不如说繁琐；计算退化曲线是简单的统计学。难点在于文化——要说服一个已经为评估分数胜出庆祝了一年的团队，告诉他们庆祝的对象衡量错了东西，而且新指标有时会将之前的“改进”显示为回归。

完成这项工作的团队赢得了一些旧体制无法提供的东西：一个他们了解其失败模式形态的提示词。他们可以告诉你哪些输入类别最薄弱、薄弱多少，以及某次变更如何移动了曲线。他们可以带着校准后的信心（calibrated confidence）发布，而不是平均化的乐观。而不做这项工作的团队，交付的提示词其失败模式是他们的评估体系在结构上无法发现的——他们只能在生产环境中，通过一张张支持工单来发现它们。