封闭标签分类如何约束解码?
直接提示、思维链、Logit Bias、约束解码方法对比
原题：如何利用大语言模型实现封闭集合标签分类任务（例如从预定义类别中选择输出）？请比较直接提示、思维链、Logit Bias、约束解码等方法的优劣。
Prompt工程
30 秒回答
- 明确四种方法的核心机制差异
- 能对比准确性、延迟、成本、可控性四个维度
- 理解工业落地的关键权衡（如API可用性 vs 自研成本）
- 提及失败回退策略和边界情况处理
回答与解析
答案要点
- 明确四种方法的核心机制差异
- 能对比准确性、延迟、成本、可控性四个维度
- 理解工业落地的关键权衡（如API可用性 vs 自研成本）
- 提及失败回退策略和边界情况处理
四种方法对比
| 方法 | 核心机制 | 适用场景 | 主要局限 |
|---|---|---|---|
| 直接提示 | 在prompt中列出类别，让模型直接选择 | 类别少、简单场景 | 格式不稳定，可能输出不在列表中 |
| 思维链 (CoT) | 先让模型推理分析，再给出结论 | 需要可解释性的复杂分类 | 延迟高、成本高，小模型效果差 |
| Logit Bias | 在logits层对合法token加权/降权 | API支持时首选（如OpenAI） | 受限于API暴露能力，多token类别难处理 |
| 约束解码 | 在解码过程中限制合法token序列 | 自研部署场景，高可控要求 | 实现复杂，需修改推理引擎 |
工业落地关键考量
准确性：约束解码 > Logit Bias > CoT > 直接提示
实现成本：直接提示 < CoT < Logit Bias < 约束解码
延迟开销：CoT明显最高，其余接近
我的实践经验
- 中小规模类别（<100）：优先用Logit Bias，配合
logit_bias参数屏蔽非法token首字，再用字符串匹配校验 - 超大类别或层级分类：改用Embedding检索+小模型二次确认，而非硬枚举
- 必须100%合规的场景（如金融风控）：约束解码是唯一选择，可用
outlines、guidance等库或自研FSM
兜底策略：无论哪种方法，都需加后校验——用正则或模糊匹配检查输出是否在封闭集合，否则触发重试或人工介入。
口语版讲法(约4分钟)
- 本质是让大模型做受限选择，核心在平衡可控与灵活
- 直接提示和CoT适合简单场景，但工业落地不够稳
- Logit Bias是API下的首选，但多token类别有坑
- 约束解码是自研场景的终极方案，但代价高
- 实际落地常混合使用，并做后校验兜底
这道题其实问的是，怎么让大模型这种天生发散的东西，老老实实从你给的一个列表里挑一个答案出来。核心矛盾就是，既要利用模型的语义理解能力，又要严格控制输出范围，不能让它自由发挥。
我一般会按可控性和成本，把方法分成四类来权衡。先说最直接的，就是直接在提示词里把类别列出来，让模型选。这个简单，但问题也很明显，格式不稳定，模型可能自己造个不在列表里的词，或者输出一堆废话。所以它只适合类别少、要求不高的场景，比如给用户评论打个「好评」「中评」「差评」这种。
再一个是思维链，就是让模型先推理再给结论。这个好处是可解释性强，比如客服退款场景，你可以让模型先分析用户退款理由是否合理，再输出「同意」或「拒绝」。但代价是延迟高、成本高，而且小模型推理能力不够，效果反而差。所以一般只在需要审计或解释的业务里用。
接下来是 Logit Bias，这是API场景下我最推荐的做法。比如用OpenAI的接口，可以直接对某些token加权或降权，甚至屏蔽掉非法token的首字。这样模型在生成的时候，第一个字就不可能输出不在列表里的东西。但这里有个坑，如果类别是多token的，比如「退货退款」是四个字，你只锁住首字「退」，模型后面还是可能走偏。所以通常要配合字符串匹配做二次校验。
最后是约束解码，也就是在生成过程中，每一步只允许模型从合法的token序列里选。这可控性最高，但实现最复杂，得自己改推理引擎。比如金融风控场景，输出必须严格匹配「通过」「拒绝」「人工审核」这三个词，那约束解码是唯一选择。可以用 outlines 或 guidance 这些库，也可以自研有限状态机。
实际落地的时候，我很少只用一种方法。比如类别小于100个，我会优先用Logit Bias，再配合正则校验，如果校验失败就重试或降级到直接提示。但如果类别有几千个，或者有层级关系，比如商品分类，那硬枚举就不现实了，我会改用 Embedding 检索加小模型二次确认，先召回候选集再做约束。
这里有个前提，就是不管用哪种方法，上线前一定要做边界测试。比如常见失败场景是用户输入有歧义，模型可能在两个相近类别间犹豫，这时Logit Bias的权重设置就很重要，调不好反而会强制选错。
另外，我最近在关注一个方向，就是当类别本身也在动态变化时，比如电商大促临时加活动标签，怎么让约束解码或Logit Bias能热更新，而不需要重新部署模型。这块其实可以结合 Function Calling 的思路，把类别列表当成外部工具来调用。
所以整体来看，我会把约束解码看成最终保底方案，但日常优先用Logit Bias加后校验，因为它在可控性和实现成本之间平衡得最好。
关键一句:当类别列表动态变化时，如何热更新约束，不重新部署模型。
面试官还可能这样问
- 问法 1 · 场景切入
假设你做一个订单分类系统，要自动把用户反馈归到‘物流延迟’‘质量问题’等20个固定标签里。你试过直接让大模型选，但结果偶尔跑偏。你会怎么确保它只输出这20个标签之一？
- 问法 2 · 层层追问
用大模型做分类任务，你有没有遇到过它输出不在预设列表里的情况？……那你怎么限制它只能从给定的类别里选？……如果类别很多，或者类别名很长，直接提示不好使，还有什么更可控的办法？
- 问法 3 · 直球架构
封闭集合标签分类，就是必须从固定类别列表里选一个输出。直接提示、思维链、Logit Bias、约束解码这四种方法，你对比过它们的准确率、延迟、成本吗？工业落地你会怎么选？