先这样答
要求输出 JSON 格式却被模型夹带解释文本是一个典型的指令失效案例。我在实际开发中遇到过这个问题。当时系统需要模型提取信息并严格按 JSON 格式输出。模型经常在 JSON 结构前后加上“好的，这是您需要的格式”这类自然语言。这会导致下游解析代码直接报错。
我把问题归结为三个原因。第一是指令过长。提示词里包含大量业务背景和提取规则。这稀释了末尾的格式约束。第二是约束冲突。业务要求提取的信息存在模棱两可的情况。模型试图通过补充解释来合理化自己的输出。第三是模型习惯。预训练数据中问答对通常包含礼貌性回复。格式要求与这种生成习惯产生了冲突。
我采用了三步组合方案解决这个问题。首先是拆分指令。我把信息提取和格式化分成两次请求。前置请求只负责提取内容。后置请求专门负责把内容转为 JSON。其次是引入约束解码。我们在推理层限制模型只能生成合法的 JSON 字符。最后是增加格式校验与错误回传重试机制。代码捕获 JSON 解析错误。系统把报错信息和原始输出拼成新提示词。模型根据错误提示重新生成结果。这套方案让格式输出的成功率发生了变化。
面试官会怎么追问
-
「你提到把提取和格式化拆分成两次请求，这会增加延迟和成本，实际业务中怎么权衡？」 拆分指令确实会增加时间和 token 消耗。我们在对时效性要求高的场景不使用拆分。对于离线数据处理任务，拆分指令能换取更高的稳定性。我们会根据具体业务场景的容错率来决定是否启用这个策略。
-
「约束解码具体是怎么做的？有没有遇到什么限制？」 我们通过配置大模型的响应格式参数来强制输出 JSON。如果使用的是本地部署模型，我们会接入专门的语法引导生成工具。这种方法有时会导致模型生成的内容质量下降。模型为了凑合法格式可能会截断关键信息。
-
「错误回传重试一般设置几次？如果一直重试失败怎么办？」 我们将最大重试次数设置为三次。超过三次依然解析失败的请求会被放入死信队列。人工会定期查看这些失败案例。我们会根据这些极端案例来优化初始的提示词。
回答的坑
编造没有亲历过的业务场景，面试官一追问具体报错日志就会露馅。 只说修改了提示词却不提工程层面的兜底机制，显得缺乏实际工程经验。
同系列的题