用测量理解 Prompt Engineering：什么会改变输出

在测量之前，先说一个事实，它能悄悄解释后面一半内容。

模型没有记忆。两次调用之间，它什么都不会保留——不会保留你的上一个问题，不会保留它自己的上一个回答，不会保留你附上的文件，也不会保留你已经问过两次这件事。每次调用都从一台空机器开始，而这台机器唯一知道的，就是你刚刚交给它的 token 序列。

聊天界面里看起来像“记忆”的东西，是你的客户端把整段对话从头开始、每一轮都重新发送了一遍。模型每次都会从零重新阅读全部内容。第 13 章测量了这种重读在一次 forward pass 中的成本；第 16 章把它变成发票上的一行。这里对设计真正重要的结论是：prompt 不是发给一个有状态系统的消息。prompt 就是状态。

这消除了许多混乱。“模型忘了我告诉过它的事”通常意味着那件事从未被发送。“它忽略了我之前的指令”通常意味着历史被截断时，那条指令掉出了窗口。“它在生产环境里表现不同”通常意味着生产环境组装出的 prompt 和你测试时的不同。这些都不是模型问题，也没有一个能靠改写措辞解决。

“这个 prompt 更好”是在对一个分布提出主张，而你无法通过看一个输出来看到分布。你需要的是很无聊的东西：有已知答案的案例、N 个变体，以及一个区间。

这个 harness 是 50 行 TypeScript，形状和第 14 章里的客户端一样——一个请求、一个截止时间、一些并发、一次计数。它会在第 19 章里再次出现，用来评估一个检索器；也会在第 29 章作为 golden set 出现。

export type Case = { input: string; expected: string };
export type Variant = { name: string; build: (c: Case) => ChatMessage[] };

async function pooled<T, R>(xs: T[], n: number, f: (x: T) => Promise<R>) {
  const out: R[] = new Array(xs.length);
  let i = 0;
  await Promise.all(
    Array.from({ length: n }, async () => {
      while (i < xs.length) {
        const k = i++;
        out[k] = await f(xs[k]);
      }
    }),
  );
  return out;
}

export async function runVariant(v: Variant, cases: Case[], concurrency = 6) {
  const hits = await pooled(cases, concurrency, async (c) => {
    const answer = await complete(v.build(c));      
    return answer.trim().toLowerCase() === c.expected;
  });
  return { name: v.name, hits, k: hits.filter(Boolean).length, n: cases.length };
}

返回的数字不是结果。这个才是：

/** 95 % Wilson score interval for a proportion. Chapter 4 derives it. */
export function wilson(k: number, n: number, z = 1.96) {
  const p = k / n;
  const d = 1 + (z * z) / n;
  const centre = (p + (z * z) / (2 * n)) / d;
  const half = (z * Math.sqrt((p * (1 - p)) / n + (z * z) / (4 * n * n))) / d;
  return [Math.max(0, centre - half), Math.min(1, centre + half)] as const;
}

第 4 章提出了论证，本章把它兑现。20 个里对 17 个是 85%，而它的 95% 区间从 64% 到 95%。一个变体 20 个里对 13 个——65%，感觉上明显更差——区间却是 43% 到 82%。**这两个区间几乎全程重叠。**20 个案例无法区分好 prompt 和平庸 prompt，而大多数公开的 prompt 建议验证时用的案例还更少。

60 个案例，也就是本章使用的数量，仍然不多。它足以看到大的效果，也足够诚实地承认自己看不到小效果——下面它会多次承认这一点。

三个块——规则 R、工单 T、指令 I——拼接成一条用户消息。六种排列，内容按字节完全相同，每种 60 个案例。

最好到最差相差 28.3 个点，而且区间不重叠，所以这不是噪声故事。由于每个分支都在同 60 个项目上计分，更尖锐的问题是配对问题：在两个分支意见不一致的案例里，分裂有多偏？从最差顺序换到最好顺序，让 21 个案例从错变对、4 个从对变错——精确配对概率为 0.0009。³

读这张表时，看它的形状，而不是只看赢家。最好的两行都以工单结尾；最差的两行要么把指令埋在中间，要么让它跟在数据后面。这正是 Liu 等人称为 Lost in the Middle 的现象：prompt 边缘的材料比中心的材料使用得更可靠。⁴ 第 16 章给窗口定价，第 24 章在长 context 中正式测量这一效果，在那里中部会如描述般塌陷，而末尾的恢复不会再出现。这里的实践规则自然浮现：任务放顶部，数据放底部，中间不要放重要内容。

现在，把同样的词在不同轮次之间移动。第 11 章已经说明，chat template 不是包在模型外面的装饰，而是模型的一部分——<|im_start|>system 和 <|im_start|>user 是模型在 fine-tuning 期间见过数百万次的真实 token，而且就在那些位置。因此，你的指令落在这些标记的哪一侧应该会有影响，事实也确实如此：

把规则和指令跨过模板边界，带来了 21.7 个点——19 个案例变好，6 个变差，配对概率 0.0146——而没有改变其中任何一个字符。这就是对 system prompt 与 user prompt 的具体回答：它们不是同一件事的两种说法。它们是在模型训练过的结构中的两个不同 token 位置，而 system 位置才属于适用于整段对话的指令。

也注意第三行。在工单后重复指令——一个被广泛推荐的技巧——得分低于只说一次。在这个模型、这个任务上，说两次比说一次更差。

同一个 prompt，最佳放置，60 个案例。唯一变化的是工单文本外面包了什么。

仅仅标点不同，就有 18 个点的跨度。但看两个极端区间：[73.9, 91.9] 和 [54.1, 77.3]。**它们重叠。**按粗糙读法——比较误差线，如果相碰就什么也别说——这张表什么也证明不了。

这里粗糙读法是错的，而理解为什么，比这张表本身更有价值。每个变体都在同 60 张工单上计分，所以两个测量不是独立样本；它们是配对的。每个区间宽度的大部分来自两个分支共享的不确定性来源——这 60 张工单是否有代表性——而当你把它们相互比较时，这个来源会抵消。改问配对问题，答案就很尖锐：从双引号换成 XML 标签，让 12 个案例从错变对、1 个从对变错，配对概率 0.0034。这是真实差异。

然后同一个测试又压低了标题党。XML 标签比普通 Ticket: 标签高 8.3 个点，这正是博客文章会放进标题的数字。配对结果：6 个变好、1 个变差，概率 0.1250。未成立。那个著名提升所依赖的，不过是 7 个案例。

所以这里有两个问题，也需要两种不同工具；把它们混为一谈，prompt 建议就会同时朝两个方向出错：

一般发现——模型会强烈且不可预测地受格式选择影响，而这些选择没有语义内容——并不新鲜。Sclar 等人只改变分隔符、空格和大小写，在几十个任务上发现准确率跨度大到足以颠倒已发表的模型排名。⁵ 实践结论不是“使用 XML 标签”。结论是：格式是一种 hyperparameter，扫描它几乎没有成本；而任何固定一种格式来比较两个模型的做法，比较到的格式和模型一样多。

In-context learning——在 prompt 中向模型展示已完成的示例，让它在不更新权重的情况下从中泛化——正是让 GPT-3 成名的能力。⁶ 实践问题从来不是它是否有效，而是值得为多少示例付费。

示例会作为真实的先前轮次放入，user 和 assistant 交替，因为这是模板训练时使用的结构。每个 k 都从一个互不相交、包含 16 张已标注工单的池子里，使用 5 次不同随机抽样运行：

两个示例带来 7 个点。接下来的 6 个示例没有带来可测量收益——83.7，然后 81.7，然后 83.7，这串数字只是在自身噪声里游走。16 个示例又带来 5.5 个点。曲线不是平滑上升；它是一个台阶、一个平台，再一个台阶。

最重要的是最后一列。在 k = 8 时，你碰巧选了哪 8 个示例，会让准确率移动 10 个点——这比从 2 个示例增加到 8 个示例带来的全部收益还大。最后一行是最尖锐的版本：在 k = 16 时，池子已经用尽，所以 5 次运行包含完全相同的 16 个示例，区别只有它们出现的顺序。仅顺序就让准确率移动了 8.3 个点。

这就是 Lu 等人报告的结果，并且在所有有人寻找它的地方都存活了下来：示例顺序是一种真正的 hyperparameter，其效果可与示例数量相当。⁷ 因此，关于 few-shot prompting 的诚实建议不是一个数字，而是：

现在看民间传说。下面每一句都是添加到 system prompt 前面的单句，其余 prompt 完全相同，仍然是同 60 个案例。

五句里有四句什么都没做。不是“有一点点作用”；而是 60 个配对案例看不出任何作用。专家 persona 和贿赂的得分都低于未改动基线，甚至这些下降也没有通过配对测试——它们只是朝下的噪声。

第三行值得停下来想想。“这对我的职业生涯非常重要”产生了完全相同的准确率，60 个里仍然对 46 个——但 60 个答案里有 10 个发生了变化，5 个朝每个方向。摘要统计量相同，行为却不同。如果你的评估只是小集合上的一个数字，那么一个重写了六分之一输出的变更，可能看起来像什么也没做；你会以为它是免费的，并把它上线。

然后是威胁，这是唯一让指针移动的句子，而且让它向下移动了 35 个点，把 24 个案例从对变错。这不是舍入伪影；这是另一种模型行为。教训不是“永远不要威胁模型”。教训是，情绪框架不是惰性的。它会移动分布，有时移动得很剧烈，而且方向无法通过阅读句子来预测——这正是它必须被测量、而不是被推理的原因。

本章欠你一个限定：这五句话只在一个小模型和一个任务上测试。有些在其他地方有论文支持——“深呼吸”来自一篇搜索高分指令的论文，而不是凭空发明它们，这比后来流传的说法更好，也更不同。⁸ 能泛化的不是这些句子本身。能泛化的是：在博客文章里存活下来的列表，和在测量中存活下来的列表，是两张不同的列表；你唯一能知道自己手上是哪一张的方法，就是运行基准。

人人都会重复一条规则——说你想要什么，而不是说你不想要什么——通常也没有数字。这里给出数字。同一个格式要求，用三种写法表达，让模型自由生成，以便观察合规性：

三个禁令比一个指令更差，而且让模型写出五倍多的文本——同时与这三条禁令完全相反。把正向句子加回来后，它恢复到 68%。

只要你记得第 8 章，机制并不神秘。模型会从一个由前文条件化的分布中选择下一个 token，而禁令会把被禁止的东西放进这个条件里。这里没有否定操作符；只有一个现在出现了某个词的 context。

这可以直接测量。取基线 prompt，加一行：Do not use the shipping queue for software problems. 然后只看 45 张不是物流工单的工单：

为了排除某个队列而点名它，反而让模型选择它的频率增加三倍，分配给它的概率质量几乎变成三倍，并让整体准确率损失 25 个点——与基线相比，16 个案例变差，1 个变好，配对概率 0.0003。

不要想大象，已测量。改写方式永远一样：用使禁令变得不必要的正向规则取代它。不要写“软件问题不要用物流”，而要写“只有涉及实体包裹时才使用物流”。

第 12 章正确地构建了 chain of thought——先作为一种 prompting 技术，⁹¹⁰再作为一种通过可验证奖励训练进去的东西——最后留下一个推迟到本章的警告：一旦模型能自行推理，告诉它一步步思考就不再有帮助，甚至可能有害。下面就是这个警告配上一张表，任务本身很容易让人以为“多想一点”一定更好。

两个分支在同一位置用同一种工具读取。唯一差别是，模型自己写出的 chain of thought 是否先位于 context 中。

准确率下降，成本上升，而本章自己的规则也适用于本章自己的结果：下降是 7 个案例变好对 10 个变差，配对概率 0.629，并未成立。真正成立的是，它每次调用额外产生了 98 个输出 tokens，并没有换来任何可测量收益。不确定性完全在收益侧。账单是确定的。

一条失败的 chain 比成功的更有启发。被要求对*“你的 Slack integration 在周二之后停止发送消息”*进行推理时，模型写道：

1. Check if the issue persists on Monday.
2. Verify if there are any updates or changes in your Slack setup that
   might affect message posting.
3. If no update has been made since Tuesday, check for any recent system
   restarts or downtime affecting Slack functionality.
4. If you have recently installed new software or updated your
   environment, ensure it's compatible with Slack version.
5. Contact Slack support for further assistance or troubleshooting steps.

这是称职的故障排查建议，但它不是这个任务。被要求思考时，模型漂移到了“逐步思考这张支持工单”在训练数据中最像的体裁——然后用自己 context 里五百个字符的无关推理来回答一个分类问题。Chain of thought 对具有值得计算的中间状态的问题有帮助：算术、多跳查找、约束满足。把一句话路由到四个桶之一没有中间状态。没有东西可供 chain 承载，所以它只会添加貌似合理的文本，而最终决策还必须从这些文本中幸存下来。

两个实践推论。第一，对一个经过推理训练的模型——第 12 章里的 RLVR 模型——这条指令不只是冗余，还可能更糟：它会用一条短小、prompt 形状的 chain，替代模型本来会生成的长 chain。而抽样多条 chain 并投票，也就是 self-consistency 做的事，¹¹无法拯救一个本来没有分歧点的任务：它把成本乘以样本数，只为打破并不存在的平局。第 12 章在适用场景里测量了这种权衡。第二，注意比较脚手架本身的成本。强制答案进入一行 Final queue:，让无推理分支从 76.7% 掉到 61.7%。15 个点，是为了让两个分支可比而付出的。为你方便而存在的结构也不是免费的。

最后再测一次，因为这是每个人在看到第一个意外结果后都会问的问题。60 个 prompts，greedy decoding，反复运行：

• 在一切固定时重复同一个调用，返回了按 bit 完全相同的概率。确定性。
• 同一个调用在与不同邻居一起 batch时——batch 大小为 1、4、12、30 和 60——返回的概率最多相差 0.0128。所选标签从未改变，60 个案例中为 0。

标签能撑住，是因为它有余量：在 60 个案例中，前两个队列之间最窄的差距是 0.0459，是漂移的 3.5 倍。稳定性不是算法属性。它是 margin，而 margin 会耗尽。第 17 章会解释其中的算术原因，也会拆解那些会放宽和收窄这些差距的采样旋钮。把它放在这里，是因为它限定了任何 prompt 测量能意味着什么：基准测量的是一个只能在容差内复现的系统，而变体之间 2 个点的差异，在糟糕的日子里就在这个容差之内。

上面的一切都是人类选择一个变体，机器给它打分。显而易见的下一步，是让机器也来选择变体。

APE 正是这么做的：一个模型提出候选指令，它们在留出示例上被评分，最好的留下来。⁸ 它找到的指令常常不是任何人类会写的样子，而这正是重点——搜索空间是“什么能得分”，不是“什么听起来专业”。

DSPy 更进一步，也更适合产品。¹² 你声明流水线每一步接收什么、返回什么，框架把它编译成 prompts，选择 demonstrations，并按你的指标优化指令。换模型时，你重新编译，而不是重写。prompt 不再是某个人手工调优的源代码，而是针对指标生成的 artefact；它本来就应该如此。

两者都不会移除对基准的需求。两者都让基准成为你唯一需要的东西，因为没有指标的 optimizer 什么也优化不了。

剩下的是纪律。Prompts 应该放在版本控制里、文件里，和发送它们的代码放在一起——而不是放在某个周二被人编辑过的数据库行里。它们需要一个版本标识，与每个由它们产生的输出一起存储，否则等某天出现回归时，你找不到到底变了什么。它们需要放进 continuous integration 里的基准，因为 prompt 是你系统中唯一会被供应商通过部署新模型而静默失效的部分。它们还需要案例：不是一百个巧妙案例，只是上个季度出过问题的那二十个无聊案例，并永远保留。基准才是交付物。prompt 是它的副产品。

本章的一切都是按准确率测量的。每一个变体也都有价格。

带来 21.7 个点的 system prompt 会永远在每次调用中发送。带来 7 个点的两个示例会永远在每次调用中发送。带来 12 个点的 16 个示例会永远在每次调用中发送，而且它们的长度大约是用户真正提问内容的 10 倍。什么也没买到的 chain of thought 每次请求产生 98 个额外 tokens，而输出 tokens 是昂贵的那种。

这些都不会出现在准确率表里，但都会出现在发票上。

第 16 章讨论的，就是这些决策真正以什么单位计价。token 作为计费单位，context window 作为预算而不是记忆，为什么 40 轮对话的成本远远超过第一轮的 40 倍，prompt caching 会支付什么、不会支付什么，以及为什么你的 prompt 顺序决定缓存是否命中——这最终成为把稳定材料放前面、变量材料放后面的第二个、完全经济性的理由。

基准和每张表都是用 Qwen/Qwen2.5-0.5B-Instruct 在 greedy decoding 下产生的，因此可以精确复现。Hugging Face 关于 chat templates 的文档，是第 11 章模板标记实际展开成什么的参考，也说明了一个模型携带错误模板确实是现实且反复出现的故障。对于生产规模而非实验室规模的位置和格式效应，上面的引用是主要来源；供应商 prompting 指南的示例有用，但阅读时应记住，其中没有任何一家会发布区间。