响应预填充：让模型从一个给定的答案前缀继续

响应预填充解决的是这样一个问题：让模型按照我们预先确定的结构或内容开头，而不是由模型自由选择回答的起点。它的输入包括用户与系统上下文，以及一段已经确认要出现在回答中的 assistant 前缀；输出则是模型从前缀之后继续生成的 token 序列。

机制上，预填并不是让模型"重新回答"一遍。当我们把 {"action":" 这样的片段放进 assistant 侧的历史消息中，模型看到的上下文里已经存在这段文本。模型在自回归生成时唯一要做的事情，是预测这段前缀之后的下一个 token。也就是说，前缀被放进条件上下文，模型不会重新选择它，只会以它为条件继续书写。

这一机制带来两个直接后果。第一，与续写连贯性不相容的内容会被压低概率。开场寒暄、Markdown 代码围栏，或者其他与给定前缀不连续的结构，都会因为无法与前缀自然衔接而概率下降。因此，一个简短的预填前缀常常比长篇的"不要寒暄、直接给结论"这类指令更直接有效——指令只是描述期望，而前缀直接把期望变成模型必须面对的现实条件。第二，前缀同样会锁定假设。如果预填的是"退款已批准，因为"，模型的任务就从"判断是否应该退款"变成了"为已经宣布的结论寻找理由"；即使订单其实不符合退款条件，模型也倾向于顺着前缀把理由编出来。预填因此不是中性的格式技巧，它对结论方向有真实的约束力。

对结果的解释也必须限定在这一机制之内：生成结果只证明续写与前缀是连贯的，并不证明前缀中的事实本身正确。模型接受前缀，不代表它核实过前缀；模型顺着前缀写出理由，也不代表理由成立。

因此使用边界很明确：只预填你能独立保证正确、并且希望固定下来的最小文本，例如一个确定的 JSON 起始片段或一个已核实的事实性开场；其余内容交给后续的约束条件和业务校验去决定。预填的力度应当与你能承担的正确性担保相匹配。

预填改变生成结果的机制，可以用条件概率来说明。设 x 为用户与系统上下文，p 为已经提供的回答前缀，模型生成完整续写的概率写作 P(续写 | x, p)。模型权重在此过程中没有发生任何变化——预填不涉及微调，不修改任何参数。变化发生在条件一侧：自回归生成的每一步，注意力机制都会读取 p，因此每一步可选的 token 空间和概率分布都被重新塑造。

由此可以推出前缀强度的因果链。前缀越具体，被允许的路径就越少。只预填一个"{"，承诺的仅仅是一个 JSON 风格的开头；预填完整的 {"action":"refund"，则已经替模型做出了业务决定——退款这个动作被写死，模型只能在既成结论下继续书写。两种前缀的风险完全不同：前者只约束形式，后者锁定了内容。

如果 p 与模型自己的模板习惯或任务本身冲突，续写并不会被拒绝，而是被推进一个低概率区域勉强进行。模型被迫在前缀设定的轨道上寻找一条连贯但概率不高的路径，这种"勉强"恰恰是冲突存在的证据。

还要看到，概率偏置不是硬保证。即使开头被固定，模型仍然可能在闭合对象之后追加说明、漏掉字段，或者生成事实性错误。前缀改变的是路径的倾向，不是结果的正确性。

所以条件生成的完整图景是：输入为上下文 x、前缀 p 与已经产生的续写，输出为下一个 token 的概率分布以及最终的续写文本。把前缀理解为对事件空间的裁剪——更具体的前缀减少可选路径，而冲突或错误的前缀则把续写锚定在错误的区域里。

prefill 这个名称在推理服务里指代多个完全不同的东西，把它们混为一谈会直接导致实现错误。需要区分的有四个概念：响应预填充、输入 prefill 阶段、提示缓存，以及作为参照的约束解码。

四个概念的区别从"作用对象"这一列就能看出。响应预填充处理的是 assistant 侧的文本前缀，直接塑造模型看到的回答历史，因此改变输出条件。输入 prefill 阶段处理的是全部输入 token，目的是把上下文编码成 KV 表示，它是推理计算内部的必要环节，并不属于产品层面的控制手段。提示缓存则把共同输入前缀的 KV 结果保存下来，让多个请求复用同一段计算；在实现正确的前提下，缓存命中与重新计算的输出条件应当一致，因此它只减少计算量，不改变内容。约束解码在每一步生成时都给出合法 token 集合，用硬屏蔽保证输出符合某种形式语言，例如强制输出合法 JSON；它同样改变输出条件，但方式和响应预填充不同——它是排除非法路径，而不是给定一个续写起点。

常见的混淆还有一层："预填充加速"通常指的是输入 prefill 阶段的计算优化，而"响应预填充"是把答案开头交给模型继续书写。两者共享 prefill 一词，概念和性能目标却完全不同。

因此，概念消歧可以按一个固定流程进行：输入是一个名为 prefill 或 cache 的功能及其作用对象，输出是"响应前缀、输入计算、缓存复用或硬约束"中的一种分类。先看它处理的是 assistant 文本、输入 token、KV 结果还是合法 token 集，再判断它改变的是内容条件还是仅仅减少计算。名称相似不能推出语义或接口兼容，最终行为仍以服务文档和契约测试为准。

用一个具体的运行示例可以看出"分布错位"如何发生。没有前缀时，模型回答任务的第一候选往往是"当然"这样的寒暄开场；预填一个"{"之后，模型面对的候选集合完全不同。

图 1 对比两种条件下首个续写 token 的概率分布：无响应前缀与预填左花括号。两个分布的事件空间不同——预填的"{"本身已经不在候选之列，它成了条件上下文的一部分。因此不能把无前缀分布里"{"的 0.25 与预填分布里"action"的 0.60 说成"同一个 token 的概率从 0.25 提升到 0.60"：前者预测的是答案的第一个 token，后者预测的是花括号之后紧跟的 token，两者根本不是同一事件。正确的评测方式是比较完整输出的结构通过率、内容质量与失败类型。

*取决于支持范围。

三行对比显示了改善发生在哪一层：从仅提示到预填"{"，首次 JSON 语法通过率从 94% 提升到 98%，Schema 符合率从 86% 提升到 89%；约束解码能把这两项推到 100% 和 99%，但后者取决于服务对所需语法的支持范围。最右一列的事实正确率始终是 80%，没有任何一行改善它。这个案例要强调的是：前两层（语法与结构）的改善不会自动抬高事实正确率。

回到机制层面，这个案例的输入是空前缀或"{"两种条件以及各自的首步候选，输出是两个不同位置的概率分布和完整的结构指标。解释结果时必须承认 0.25 与 0.60 不是同一事件，不能直接相减当作提升；要解释的是完整输出的结构、事实与失败类型，而不是单个 token 的数字变化。

预填的风险取决于前缀落在"格式"还是"内容"上。较适合预填的是低风险格式骨架：JSON 的开括号、固定标题、已验证的代码前文、语言或语气开场、枚举标签的共同前缀。这些文本只规定表达形式，不注入任何尚未成立的判断。高风险的前缀则相反：成功/失败结论、用户身份、金额、引文、工具已执行状态，以及任何未经外部验证的事实。它们把本应由证据或权威系统决定的内容写死在了条件里。

逐行看这四类前缀的因果。"{"只承诺 JSON 风格的开头，风险低，但它不能保证输出是完整合法的 JSON，结构校验仍要交给 schema 约束。"根据政策证据："假设了政策证据存在；如果证据实际缺失，模型会顺着这个开头编造引用来源，把误导伪装成有据可查。替代方案是使用条件模板，在证据不足时显式输出拒答。"退款已批准"直接把未经授权的结论锚定在上下文里，替代方案是让工具确认之后由服务器填写这句话。粘贴已有代码文件作为前文同样危险，旧代码可能含有漏洞或注入缺陷，替代方案是对版本与测试进行校验后再决定是否作为上下文。

因此前缀选择可以描述为一个决策函数：输入拟固定的文本、它的证据状态和任务风险，输出一个中性骨架，或者"不使用预填"的决定。只有 JSON 开括号、标题或已验证代码这类内容适合固定；结论、身份、金额、引文和工具状态必须由权威系统确认。前缀越长，它覆盖的语义就越多，锚定未知事实的概率也就越高。

API 接入层常常是预填失效的地方。为什么有些服务不允许最后一条 assistant 消息非空？因为聊天模板和安全策略由服务方实现：有的 API 原生支持 assistant 前缀，有的会拒绝这种请求、自动闭合消息，或者把前缀当作一段历史回答处理。同一个概念在不同服务里的语义并不一致。因此接入前必须查阅接口文档，并用真实模型测试三个问题：返回的 delta 是否包含前缀本身，计费是否把前缀算入，流式响应的第一个事件从哪里开始。这三个答案决定了客户端应当如何组装结果。

客户端侧的拼接规则同样有隐藏陷阱。前缀只能拼接一次，之后按 UTF-8 增量解码每个流式片段；停止串可能跨越 token 或事件边界，所以不能简单地对字符串做裁剪。如果前缀以半个转义序列或不完整 Unicode 字符结尾，模型会被迫从一个无法合法继续的位置起步，产生的路径可能无法恢复。日志中应记录前缀的版本信息，但避免写入敏感原文。

模板重复是契约理解错误的典型症状。如果服务端把前缀回显在输出里，而客户端又手动前置了一遍，最终文本就会出现 "{{" 这样的双重开括号或重复标题。这类问题必须在契约测试中覆盖，而不是等线上输出出现畸形时才发现。

把整个接入流程抽象出来：输入是服务能力、assistant 前缀、流式事件与停止规则，输出是正确拼接的一份完整结果。服务端决定前缀被当作续写条件、历史答案还是非法消息；客户端则按契约完成拼接、解码与停止。一旦看到回显或重复开头，说明对契约的理解有误。半个转义、不完整 Unicode 和未经实测的接口，都不适合直接进入生产环境。

为什么强迫答案以"是"开头，会让模型更自信地编出理由？受控生成系统（LMQL、Guidance）的运作方式说明了这一点：系统把给定的部分回答当作已经生成的内容放进上下文，模型唯一的任务是条件于它继续补全。即使内部证据倾向"否"，一个已经给定的"是，因为"也会让反驳在语言上变得突兀——否定意味着与前缀直接冲突，而顺着前缀继续只需找到支持性理由。于是模型更可能去搜寻论证"是"的材料。这是条件生成的自然结果，不是模型主动撒谎：模型只是在维持连贯性，而连贯性本身被错误的前缀劫持了。

可以用正反对照测试来暴露这种锚定。对同一个问题分别预填"是""否"和空前缀三个版本，观察结论如何随前缀变化。如果事实判断随前缀翻转，说明系统在用格式控制替代证据——输出看起来言之凿凿，实际只是前缀的回声。高风险任务因此只能预填中性骨架，任何带有结论方向的词都不应出现在前缀里。

还有一层安全绕过风险。预填可能把模型置于安全模板中不常见的状态：常规安全训练通常假设答案开头由模型自己产生，而外部给定的开头可能绕过某些防护路径。供应商允许的前缀范围与安全行为，必须单独进行红队测试，不能因为接口支持就默认安全。

锚定测试的完整形式是：输入同一问题的空前缀、"是"和"否"三个版本，输出各自的结论变化和证据变化。模型按连贯性续写已有开头，所以当理由随前缀翻转时，它表明格式正在替代证据，而不是答案变得更可靠。高风险任务只能使用中性骨架，并且需要单独的红队验证。

输出已经以 "{" 开头，不代表它通过了任何实质检查。预填只塑造了形式，真正决定安全性的是一串独立的业务验证门。系统的检查必须依次经过：等待完整输出和明确的结束标志——断流不是完成，半截 JSON 不能进入后续流程；解析 JSON 并执行 schema 校验，确认结构与字段类型合法；验证金额、日期、引文和跨字段不变量，防止字段各自合法但组合起来自相矛盾；对涉及的实体查询权威数据库，未知实体应当向用户询问而不是猜测；工具执行按当前主体重新鉴权，并以幂等方式提交，避免重复执行造成副作用。

当结构校验失败时，允许有限次数的重试；如果同一类失败反复出现，就说明预填加提示词这条路径已经到极限，应当改用约束解码或直接上表单。这指向一个更一般的结论：若硬结构是核心要求，直接使用受支持的约束解码，比不断加长前缀和反复修补提示词更可靠。预填适合作为兼容性或体验优化，不应当被包装成任何形式的保证。

业务验证的完整图景可以这样描述：输入是完整模型输出、schema、权威数据与当前权限，输出是"可接受、拒绝或重新询问"三种裁决之一。系统依次检查完整性、结构、字段事实、实体权限和幂等提交。通过 JSON 解析只说明形式正确，不说明事实成立或动作获得授权——形式正确与内容正确、动作合法是三个彼此独立的问题。

结构通过率上升之后，需要回答一个更难的问题：事实质量、拒答行为和安全是否被前缀悄悄伤害了。答案是配对评测——同一批输入必须同时跑空前缀与候选前缀两个版本，逐项比较。要测量的指标包括首次语法/schema 通过、字段准确、任务成功、事实正确、拒答、越权、输出长度、首 token 时间 TTFT 与 token 成本；并且按缺信息、高风险、语言和长输入四个切片分别统计，避免平均数的掩盖效应。

配对评测中有一个专门的指标：前缀反转率。给同一问题加上相反结论的前缀，观察答案是否在没有证据的情况下跟着翻转。反转率高的前缀说明它正在替代证据做决定，而不是只做格式引导。此外还要注入故障测试：断流、服务端回显、重复拼接、Unicode 边界、停止串和接口升级，确认前缀在异常路径下不会产生不可恢复的错误。

只有同时满足两个条件才能采用候选前缀：格式指标改善，且内容与风险指标不退化。成功标准可以写成一句话——前缀应当减少低价值开场和格式偏离，但不能替模型决定未知事实，也不能让下游因为"开头看起来对了"而降低校验力度。

配对评测的输入是相同样本在空前缀与候选前缀下的结果，输出是格式、事实、拒答、安全、延迟和成本六个维度的差异。任何模型、API 或模板版本变化之后，都必须重新跑完整配对评测，因为前缀的有效性与风险都绑定在具体的实现版本上。

把前面各环节按因果顺序连起来，预填的完整链路从选择前缀开始，到监控锚定结束。

第一步是选择可独立保证正确的最小前缀。这个选择决定了整条链的风险上限：前缀只承担你能够用证据背书的部分，其余留白。第二步是按真实 API 契约发送 assistant 前缀——服务可能支持、拒绝或回显它，接入方式必须经过实测确认。第三步，模型以前缀为条件续写：权重不变，但每一步都读取前缀，事件空间被裁剪，路径概率被重塑。这一步是机制的核心，也是所有锚定效应的来源。第四步，正确拼接与停止，等待完整结果；断流、重复前缀、半个转义和不完整 Unicode 都会在这一步把前面的工作变成不可恢复的错误。第五步，对完整输出执行 schema、事实与权限验证；形式正确不构成任何担保，事实与动作授权必须由独立系统确认。第六步，与空前缀配对评测，并持续监控锚定——只有格式改善且内容与风险不退化时，前缀才值得保留。

这条链的每一环都以前一环的输出为输入，任何一环的放松都会把风险传递给下游：前缀越具体，锚定越强；契约越模糊，拼接越容易出错；验证越弱，形式正确就越容易被误认为内容正确。反过来，链的终点也约束着起点——只有你能独立保证正确的内容，才配出现在第一步的前缀里。