完整题目
假设你有一个大型语言模型（LLM），希望其输出严格限定在一个预定义的封闭标签集合内，应采用哪些技术手段（如提示工程、解码约束、微调等）来确保输出的准确性和一致性？
本文目录
答案要点
- 提示工程（Few-shot + 格式约束）是基础手段
- 约束解码（Constrained Decoding）是核心保障
- 微调/SFT提升指令遵循能力
- Function Calling/JSON Schema是工程实践标准方案
- 后处理校验作为兜底机制
核心思路
封闭标签输出本质是可控生成问题，需多层防护：提示工程 → 模型能力 → 解码约束 → 后处理校验。
技术手段（按优先级）
1. 提示工程（基线）
- Zero-shot：明确指令 + 标签列表 + "只能从以下选择"
- Few-shot：提供输入→标签的示例，稳定输出格式
- 加格式约束："输出必须是以下之一：[A, B, C]，不要解释"
2. 约束解码（强保障）
- 原理：在解码每一步，只保留合法标签token的logits，非法token概率置-∞
- 实现：用FSM（有限状态机）或CFG（上下文无关文法）定义合法输出空间
- 工具：Outlines、Guidance、lm-format-enforcer等库
- 优势：在支持该约束且正常完成时限制输出属于允许集合；拒绝、截断、超时和分类语义错误另行处理。
3. Function Calling / JSON Schema（工程标准）
- 核对具体模型/API，启用其支持的strict schema模式；普通工具调用并不一律保证schema匹配，JSON mode也不保证枚举。
- API可封装约束解码，但不要据接口名称推断所有厂商的内部实现或保证。
- 可附标签与理由；模型自报置信度不等于已校准概率，应另做校准评估。
4. 微调/SFT（能力强化）
- 构造指令-标签数据对，训练模型指令遵循能力
- 配合LoRA高效微调，适合领域标签（如医疗诊断分类）
- 注意：单独SFT无法100%保证封闭性，需配合解码约束
5. 后处理校验（兜底）
- 完整解析并校验标签成员资格；非法、拒绝或不确定结果进入明确的待复核/失败状态或有界重试，不能静默伪装成一个有效业务类别。
- 多标签场景用投票或一致性检查
选型建议
| 场景 | 推荐方案 |
|---|---|
| 快速验证 | Few-shot + 后处理 |
| 生产部署 | Function Calling / 约束解码库 |
| 领域定制 | SFT + 约束解码双层保障 |
| 动态标签 | 约束解码（无需改模型） |
参考资料
换一种问法，检查是否真正理解
场景切入
假设你做电商客服，需要把用户问题分类到“售后/物流/退货”等十几个固定类别里，怎么确保LLM只输出这些标签，不会乱说别的？
层层追问
让LLM输出固定标签，你一般怎么做？……如果模型偶尔输出不在集合里的词怎么办？……有没有办法从解码层面强制它只生成合法标签？
直球架构
设计一个系统，要求LLM输出严格限定在预定义的封闭标签集合内，你会从提示工程、解码约束、微调、后处理这几个层面分别怎么设计？优先级怎么排？
练习口述回答 · 约4分钟
- 一句话定位：封闭标签输出本质是可控生成问题
- 提示工程：基线手段但不够可靠
- 约束解码限制合法集合，但要区分正常完成、失败与语义正确性
- 微调与后处理：辅助和兜底
- 选型取舍与风险提醒
这道题其实问的是，怎么让大模型输出严格限定在我们指定的几个标签里，比如客服场景里，用户问退款问题，模型只能输出“退款中、已退款、退款失败”这几个状态，不能自由发挥。这本质上是可控生成问题，我有几层手段，从轻到重，但真正落地的时候，我不会只依赖一层。
先说提示工程，这是最基础的。我会在[[系统提示]]里明确给出标签列表，加上类似“只能从以下选择，不要解释”的指令。再给几个例子，就是 [[Few-shot]]，让模型模仿。但说实话，这层只能管住大部分情况，模型还是可能跑偏，尤其面对复杂表述或者对抗性输入时，它可能会自己发明一个标签。所以提示工程只是基线，不能当唯一保障。
再一个，约束解码，这是核心。原理很简单：在模型生成每一步，只保留合法标签对应的 token 概率，其他 token 的概率直接置成负无穷。标签往往由多个token组成，token也可能跨多个字符；约束器需要按实际tokenizer和已生成前缀保留所有仍能组成合法标签的token，不能把一个汉字等同一个token。正常完成时可约束标签集合，但截断、拒绝与语义误判仍要处理。实现上可以用 有限状态机 或者上下文无关文法来定义合法输出空间，有现成的库比如 Outlines、Guidance。生产环境我一般会用这层做主力。
然后微调，也就是 [[SFT]]，可以提升模型对指令的遵循能力。比如我收集一批指令-标签对，让模型学会在特定格式下输出。但注意，单独微调也不能保证百分之百，尤其模型没见过的新变体。所以我会把微调和约束解码结合起来，微调让模型更听话，约束解码兜住最后的底线。
另外还有 [[Function Calling]]，应核对具体模型和API，并启用支持的strict schema模式；不能认为只传工具schema就一定严格匹配，也不能用JSON mode替代枚举约束。如果标签需要附带理由，可以放进schema；模型自报置信度还需另做校准，不能直接当真实正确概率。
最后是后处理校验，先完整解析并验证标签在集合内，失败后进入明确的失败/待复核状态或有界重试，不把解析失败静默变成某个有效业务标签。这层是兜底，不能依赖它，但加上去能提高鲁棒性。
选型上，我的经验是分场景。快速验证，用提示工程加后处理就够了。生产部署，我会优先用约束解码库或者 Function Calling，因为可靠性高。如果领域很特殊，比如医疗诊断分类，我还会加一层微调，让模型更理解领域语义。每次请求需要确定允许的有限标签集合；它可以在请求之间动态变化，更新schema/文法即可，不一定要重训模型。
常见集成错误是文法与tokenizer不兼容，或允许集合无法完成到终止状态。正确实现会在采样前屏蔽非法token；是否允许前导空白取决于消费方协议，不应为绕过错误随意放宽标签语法。还有，如果标签本身有歧义，比如“退款中”和“退款处理中”语义相近，模型可能混淆，那就需要靠微调或者更好的标签设计来区分。
另外，如果标签集特别大，比如上千个，约束解码的性能会下降，因为每一步要过滤的 token 太多。这时候我会考虑用分层标签，先输出大类再输出小类，或者用向量检索先缩小候选集，再让模型从候选中选。这其实变成了检索加精排的思路。