大模型输出不符合指令时如何处理？｜字节跳动后端开发面经解析

60 秒回答模板

可以按诊断和治理回答。诊断时先收集失败样本，区分格式错误、内容越界、事实错误、漏字段、语气不符、工具调用错误和安全违规；再检查系统提示、用户提示、上下文顺序、示例、模型参数、检索内容和输出解析器。治理时可以明确优先级更高的系统指令，减少含糊表达，使用 few-shot 示例，限定输出 schema，开启 JSON 模式或函数调用，降低温度，增加生成后校验和自动修复，对高风险结果升级人工。长期要建立评测集，监控指令遵循率和回归风险。

考点 先归因

难度 真实面经高频题

回答目标 讲清机制、边界和追问

深入解析

先分类失败

不符合指令可能是多种问题。格式类表现为 JSON 不合法、字段缺失或类型错误；内容类表现为回答了不该回答的范围；事实类表现为编造或证据不一致；风格类表现为语气、长度和语言不符合要求；工具类表现为参数错误或调用顺序错误。分类越清楚，修复越有针对性。

检查指令设计

很多失败来自提示词本身不够明确，例如同时要求简洁又要求详尽，要求只输出 JSON 却又要求解释原因，或者把关键约束放在很靠后的低优先级位置。提示词应明确任务、输入、输出、禁止事项、优先级和失败时行为。复杂约束最好拆成步骤，而不是堆成一段自然语言。

强化结构约束

如果问题主要是格式不稳定，应优先使用结构化输出能力、JSON schema、函数调用或严格解析器，而不是反复用自然语言提醒。生成后还可以用 schema 校验、字段补齐、类型转换和自动修复循环。结构化约束能把一部分开放生成问题变成可检测、可重试的工程问题。

处理上下文冲突

模型可能因为上下文过长、历史指令冲突、检索材料矛盾或示例不一致而偏离要求。解决方式是清理旧上下文，明确当前指令优先级，删除不相关材料，给证据排序，并让模型只基于可信上下文回答。对于多轮对话，必要时生成当前任务摘要，避免旧目标继续干扰。

建立质量闭环

单次重试只能解决眼前问题，不能保证下次不复发。生产系统应记录不合规输出、输入、模型版本、提示词版本、检索结果和修复结果，形成评测集。每次改提示词、模型、参数或解析逻辑后，用评测集回归指令遵循率、格式通过率和业务正确率。

易错点

把所有不合规都归因于模型差，没有区分格式、事实、上下文和指令冲突。
只在提示词里重复必须、一定、严格，却没有使用 schema、解析器和校验机制。
失败后无限重试，既增加成本又可能产生不稳定结果，没有设置重试上限和降级策略。
没有保存失败样本和提示词版本，导致问题复现困难，优化效果无法量化。

面试官追问

模型不按 JSON 输出怎么办？

优先使用结构化输出、函数调用或 JSON schema，并在生成后做解析校验。失败时可以把错误信息反馈给模型进行一次受控修复，而不是直接把非法内容交给业务。

降低 temperature 能解决指令不遵循吗？

只能解决一部分随机性问题。若指令冲突、上下文噪声大、格式约束弱或任务超出能力，降低 temperature 也不能根治，需要调整上下文和输出约束。

few-shot 示例有什么作用？

示例能把抽象要求变成具体模式，尤其适合语气、结构、边界和分类任务。但示例必须一致且覆盖关键边界，否则模型可能模仿错误模式。

什么时候需要换模型？

如果提示词、结构化约束、检索和校验都已合理，但模型仍在复杂推理、长上下文或工具调用上频繁失败，就应评估更强模型或专门模型，同时用同一评测集比较收益和成本。