能力探测：在用户发现之前绘制模型的能力边界

大多数团队发现模型局限性的方式和用户一样 —— 在生产环境中，通过工单。客户反映提取流水线悄悄丢失了嵌套地址。内部用户注意到摘要器在超过 8,000 个 token 后开始虚构日期。合规审查发现分类器自信地为模糊案例打上标签，而不是选择放弃判断。

这些都不是意外。它们是一直存在的能力边界，只是在等待合适的输入来暴露它们。你要么在部署前绘制这些边界，要么让用户替你绘制 —— 一次一个事故。

系统性地发现这些边界的方法就是能力探测 —— 语言模型的故障注入。你不会在没有对接缝进行负载测试的情况下交付一座桥梁。同样的逻辑适用于任何面向用户的模型。

与衡量预期任务平均性能的标准评估不同，能力探测有针对性地瞄准出问题的地方。你在受控条件下对特定能力施加压力，让故障出现在你的测试套件中，而不是客户的工作流中。

为什么基准测试给你虚假的安全感

MMLU、HumanEval 和 MATH 分数告诉你的是标准化任务上的通用推理能力。它们完全没有告诉你模型能否解析你发票中的日期格式、处理你领域的缩写，或者在用户在文档中途切换语言时保持准确性。

一个在通用提取基准上得分 90% 的模型，在你的特定文档布局上可能只达到 40% —— 合并单元格的表格、跨页脚注、非拉丁文字的标题。这个差距不是模型缺陷，而是基准衡量的内容与你的流水线实际需要的内容之间的不匹配。

基准测试优化的是广度。生产环境需要的是在窄任务分布上的深度。失败集中在特定能力和异常输入的交叉点 —— 恰好是基准跳过的区域。

在你针对实际数据分布进行探测之前，基准分数只是装扮成信心的噪音。

构建能力探针套件

探针套件是一个结构化的测试用例集合，旨在发现失败边界而非确认预期行为。构建探针套件需要对自己的用例进行对抗性思考。

从失败开始，而非成功。 最好的探针用例来自真实的生产事故、工单和人工 QA 环节。如果用户报告模型错误处理了某个特定输入，该输入应永久保留在你的探针套件中。在编写任何评估基础设施之前，先收集 20–50 个失败案例 —— 小到可以仔细策展，大到足以揭示跨输入类型的模式。

将任务分解为原子能力。 "文档摘要器" 实际上需要几个不同的能力：提取关键论点、保持数值精度、处理多节文档、识别信息缺失以及维持事实一致性。每个能力都是一个独立的探测维度。

当你这样分解时，你经常会发现 80% 的失败集中在一两个你从未明确测试过的能力上。

同时测试正面和负面案例。 对于每个能力，探测模型应该做什么和不应该做什么。如果你的分类器应该对模糊输入放弃判断，测试它是否真的放弃了 —— 而不仅仅是它能正确分类清晰案例。单向探测会产生盲点：模型通过过度自信得高分，因为你从未测试它说 "我不知道" 的能力。

系统性地变化输入特征。 对于每个能力，创建沿最可能导致退化的维度变化的测试用例：

• 输入长度（短、中、上下文窗口边界）
• 语言和文字变体
• 格式不规则（缺失字段、意外分隔符、混合编码）
• 领域特定术语和缩写
• 测试鲁棒性的对抗性措辞

目标不是穷举覆盖 —— 而是找到性能急剧下降的悬崖边缘。

能力矩阵：让边界可见

有了探测结果后，将它们组织成能力矩阵。这是一个行是特定能力、列是输入条件的网格。每个单元格包含该组合的模型通过率。

文档提取系统的能力矩阵可能如下所示：

能力	标准格式	扫描 PDF	手写体	多语言
姓名提取	97%	82%	41%	73%
日期解析	94%	78%	35%	68%
金额提取	96%	85%	29%	71%
地址解析	88%	61%	22%	54%
缺失字段检测	72%	48%	31%	44%

这个矩阵使以下几点一目了然：

• 地址解析在所有条件下都表现不佳
• 手写体文档几乎是完全的失败模式
• 缺失字段检测 —— 知道数据何时不存在 —— 即使在理想条件下也是最弱的能力
• 组合多个退化因素（如手写体 + 多语言）很可能完全失败

没有矩阵，这些边界就保持不可见。系统处理 80% 的流量没有问题，而剩余的 20% 产生了稳定的静默错误流，需要数月才能浮出水面。

能力矩阵只是一个快照。提供商更新、提示词调整和检索流水线的变更都可能悄悄移动边界 —— 这就是金丝雀提示词的用武之地。

金丝雀提示词：捕获部署间的漂移

静态探针套件在部署时捕获问题。但上周正常工作的能力可能在一个看似无关的变更后悄悄退化。金丝雀提示词将你的覆盖范围扩展到部署之间的间隙。

金丝雀提示词是固定的、不变的输入，你按计划 —— 每小时、每天或每次部署时 —— 针对模型运行。每个金丝雀针对你已经映射的特定能力边界。当金丝雀的输出发生漂移时，你的流水线中有某些东西发生了变化 —— 你可以在用户注意到之前进行调查。

有效的金丝雀具有三个属性：

• 它们针对接近失败边界的能力，在这些边界上，模型行为的微小变化就会导致可检测的偏移。
• 它们具有确定性的预期输出，因此你可以使用精确匹配或简单的语义比较，而不是 LLM-as-judge 评估。
• 它们运行成本低 —— 你的整个金丝雀套件应该在一分钟内执行完毕。

上述提取系统的实用金丝雀集可能包括：

• 一个包含已知棘手地址格式的扫描 PDF（测试 61% 的能力）
• 一个故意缺失字段的文档（测试 72% 的检测率）
• 一个双语发票（测试多语言列）

如果这些金丝雀中的任何一个在部署后从通过变为失败，你就获得了一个比聚合指标更具可操作性的早期警告。

探针到回归的流水线

探针和回归测试服务于不同的目的，但它们具有自然的生命周期关系。

一个新探针开始时是探索性的 —— 你在寻找你不知道存在的失败。当你发现一个失败并修复它（通过提示词变更、检索改进或护栏），该探针就升级为回归测试。它从 "模型能处理这个吗？" 转变为 "模型仍然能处理这个吗？"

这种升级很重要，因为两个集合服务于相反的目标。探针应该有低通过率 —— 如果一切都通过了，你的探测不够激进。回归测试应该有接近 100% 的通过率 —— 如果先前修复的失败复发，说明有东西坏了。

并行维护两个集合：

• 活跃探针：你知道模型会失败或不可靠的案例。这些指导改进优先级。预期通过率为 30–70%。
• 回归套件：模型之前失败但在变更后现在成功的案例。这些防止回归。目标通过率超过 95%。

当活跃探针达到饱和 —— 持续高通过率 —— 要么问题确实已修复，要么你的探针已经过时。将容易的成果退役到回归套件中，添加更难的变体，并继续向外推动边界。

这个生命周期将一次性评估工作转变为持久的质量实践。没有升级的探针会变得陈旧。没有新鲜探针的回归套件会变得自满。两个集合相互馈送 —— 系统在每次迭代中变得更加敏锐。

在没有真实标签的情况下评分探针

金丝雀和回归测试假设你知道正确答案。但对于没有标注数据的新能力探测怎么办？

一个常见的反对意见是探测需要每个案例都有真实标签。事实并非如此 —— 几种评分策略在没有标签的情况下也能很好地工作：

• 一致性检查：对同一输入运行多次。高方差表示不确定性 —— 你正处于能力边界上。
• 扰动测试：进行不应改变输出的小输入变更。如果重新措辞问题或添加无关上下文改变了答案，模型就处于其可靠性极限。
• 约束验证：在不判断内容的情况下检查结构属性。JSON 能解析吗？必填字段存在吗？日期是否落在合理范围内？机械检查能捕获大量的失败。
• 自一致性探测：通过不同的框架提出同一个问题。矛盾标志着一个边界。

这些方法不能替代高风险决策的人工评估。但它们让你能大规模探测，并将昂贵的人工审查集中在自动检查标记出模糊性的确切边界上。

部署前探针清单

在将模型部署到生产环境或升级到新版本之前，执行以下清单：

• 边界探针：测试能力矩阵中的每个已知能力边界。任何退化在调查之前都是部署阻断因素。
• 金丝雀套件：运行所有金丝雀提示词并与存储的基线进行比较。标记任何语义变化 —— 问题不是新输出是否好，而是它是否发生了变化。
• 格式稳定性：如果你的系统解析模型输出（JSON、XML、结构化文本），请在新版本下验证格式一致性。格式变更是模型升级中最常见的静默回归。
• 拒绝行为：测试拒绝的边缘案例。模型升级经常移动拒绝阈值 —— 以前有效的查询现在可能被拒绝，反之亦然。
• 延迟和 token 用量：测量相同输入的 token 数量。变化表示行为偏移，即使输出看起来相似。

这个清单需要几个小时，而不是几周 —— 只是调查时间、紧急补丁和在生产中发现回归后被侵蚀的信任的一小部分。

从探测到产品决策

能力探测的最高杠杆成果不是捕获 bug —— 而是用数据而非直觉来指导产品决策。

交付可靠 AI 产品的团队将能力边界视为一等产品约束。在实践中，这看起来像：

• 一个随每次模型变更更新的活跃能力矩阵，而不仅仅是在部署时
• 金丝雀提示词在生产中持续运行，而不仅仅是在 CI 中
• 用户报告的失败在几天内而非几个季度内反馈回探针套件

最重要的是，他们使用探测结果来做产品决策，而不仅仅是工程决策。当能力矩阵显示手写输入的准确率为 41% 时，产品决策可能是排除该输入类型、添加人工审核步骤，或通过置信度指标设定用户期望。如果不知道边界在哪里，这些决策是不可能的。

替代方案 —— 通过用户投诉发现边界 —— 更慢、更贵，并且侵蚀难以重建的信任。一个自信的错误答案会让用户怀疑未来的每一个输出，即使是正确的输出。

先绘制局限性，然后据此设计。边界不会消失 —— 但它们从不可见的风险转变为你可以推理、沟通和围绕构建的工程约束。交付最可靠 AI 产品的团队不是拥有最好模型的团队。他们是确切知道模型在哪里出问题的团队 —— 并围绕这些知识设计了他们的系统。

从小处开始：拿出你最近三个生产事故，把它们变成探针，然后从那里开始构建。