跳到主要内容
进阶

能力与可靠性之间的鸿沟

这是一个几乎让每个第一次把 AI 交付给真实用户的人都吃过亏的模式：

模型在你的测试里完美地做成了那件事。它在生产中失败了。你很困惑，因为你亲眼看见它成功过。

你撞上的，就是能力与可靠性之间的鸿沟。

能力指模型能够做一个任务——在某些条件下，它至少产出过一次正确的输出。

可靠性指模型一贯地正确做成那个任务——跨越多样的输入、跨越重复的运行、跨越措辞或上下文的细微变化。

演示证明的是能力。生产要求的是可靠性。这是两种不同的属性，而大多数指南把它们混为一谈。

为什么演示会骗人​

当你测试一个提示时，你通常会：

  • 在你自己设计的输入上运行它
  • 运行寥寥几次
  • 挑出看起来不错的那个输出
  • 不断微调提示，直到它看起来对了

这个过程是在为能力做优化。提示现在在你的例子上能用了。你看到过一个正确的输出。你把它交付了。

问题在于，生产中的用户输入不是你的例子。它们更杂乱、更多样、以你没有预料到的方式措辞。模型从未在它们上面被测试过。你完全不知道它在它们上面表现如何。

单个好的输出不是一个性能估计。它是一则轶事。

方差是那个隐藏变量​

LLM 是随机的。把同一个提示运行两次，你常常会得到不同的输出。这种方差是正常的，通常也无伤大雅。但它意味着相关的问题不是"它成功了吗？"——而是"它有多大比例的时候会成功？"

一个模型 95% 的时候成功的任务，在演示里看起来很棒，却会在大约二十个用户里坏掉一个。一个 60% 的时候成功的任务，当运行它的是你自己时看起来还行。这是非常不同的两种情形，而不去测量，你就分辨不出它们。

实践中的能力—可靠性谱系​

维度有能力但不可靠可靠
测试过的输入作者设计的例子多样的、真实用户的输入
样本量寥寥几次运行在许多例子上重复运行
失败模式的可见性失败在测试中罕见，在生产中常见失败被测量并被理解
你怎么发现它坏了用户投诉你的评测套件
你怎么改进它靠猜并试提示追踪通过率，系统性地排查失败
部署的信心凭感觉凭证据

评测才是真正的护城河​

更好的提示可以提升能力。只有评测才能告诉你你是否提升了可靠性。

一个评测是一项结构化的测试：一组输入、预期的输出或评估标准，以及一种测量通过率的方法。你在那些输入上运行模型，给输出打分，得到一个数字。然后你改动某样东西——提示、模型、温度——再运行一次。现在你有了一个信号。

这并不光鲜。它是 AI 产品工作中大多数教程完全跳过的那一部分。但它是回答那个在你交付时真正重要的问题的唯一办法："这东西在我没见过的输入上多久成功一次？"

一个简单的起步方法​

你不需要基础设施就能开始。这是一个最小可行的评测循环：

  1. 构建一个黄金集。 收集 20–50 个真实或贴近真实的输入。为每一个写下正确输出应该是什么样子（或评判它的标准）。这些就是你的黄金示例。

  2. 运行它 N 次。 在每个示例上把你的提示运行多次。跨运行的方差告诉你提示的稳定性；跨示例的方差告诉你覆盖度。

  3. 追踪通过率。 对每个（输入，运行）对，记录通过或失败。计算整体通过率。这个数字是你可靠性图景的起点。

  4. 把它变成一项回归测试。 每次你改动提示，就再跑一遍评测。如果通过率下降，你就弄坏了什么。如果它上升，你就做出了一个真正的改进。

就这样。一张电子表格就行。纪律比工具更重要。

为什么这是一个工程问题，而不是一个提示问题​

模型失败时的本能是重写提示。有时候那是对的。但它往往是一种为你看到的那个失败案例做优化的方式，代价是在你没核查的案例上发生倒退。

针对 AI 的可靠性工程看起来像这样：

  • 在运行任何东西之前定义"正确"意味着什么
  • 对照一个有代表性的输入分布来测量
  • 用一致的方法学随时间追踪变化
  • 区分"这个模型做不了这个任务"和"这个任务定义得不充分"

提示工程是那个过程之中的一件工具。它不是那个过程的替代品。

诚实的表述​

大多数 AI 能力是真实的。这些模型确实能做出非凡的事。能力与可靠性之间的鸿沟并不是在论证那些能力是假的——它是在论证：知道它们存在还不够。

如果你需要一个任务在 95% 的时候奏效，你就需要它在 95% 的时候奏效的证据。那个证据来自运行结构化测试，而不是来自对演示的信心。

构建出经久耐用的 AI 产品的工程师，未必是那些写出最好提示的人。他们是那些在交付之前就知道"奏效"意味着什么、并且有一个测量来告诉他们它是否为真的人。

相关内容​