完整题目
如何利用大语言模型实现封闭集合标签分类任务（例如从预定义类别中选择输出）？请比较直接提示、思维链、Logit Bias、约束解码等方法的优劣。
本文目录
答案要点
- 明确四种方法的核心机制差异
- 能对比准确性、延迟、成本、可控性四个维度
- 理解工业落地的关键权衡（如API可用性 vs 自研成本）
- 提及失败回退策略和边界情况处理
四种方法对比
| 方法 | 核心机制 | 适用场景 | 主要局限 |
|---|---|---|---|
| 直接提示 | 在prompt中列出类别，让模型直接选择 | 类别少、简单场景 | 格式不稳定，可能输出不在列表中 |
| 思维链 (CoT) | 先让模型推理分析，再给出结论 | 需要可解释性的复杂分类 | 延迟高、成本高，小模型效果差 |
| Logit Bias | 对指定token ID加减偏置 | 具体模型/API暴露该参数时作为辅助 | token偏置不等于完整标签序列白名单，多token类别与共享前缀需处理 |
| 约束解码/严格结构化输出 | 限制合法token序列或schema enum | 自建推理或支持严格schema的托管API | 支持能力、schema范围、拒答与截断须按接口处理；不保证语义分类正确 |
工业落地关键考量
格式合法性与语义分类正确率分开评估。约束只能排除非法形式，仍可能在合法标签中选错；四种方案的正确率、拒答、延迟与实现成本要在相同题集和服务配置下比较，没有通用排名。
我的实践经验
- 中小规模类别：先比较直接提示与支持enum的严格结构化输出；Logit Bias只在所用模型/API支持时作为辅助，不能靠屏蔽首token保证完整标签合法。类别100不是通用选型门槛。
- 超大类别或层级分类：改用Embedding检索+小模型二次确认，而非硬枚举
- 必须属于闭集的输出：可使用完整标签序列约束、支持enum的严格结构化接口或确定性分类器/规则，并单独处理拒答、截断与无合适标签；这不等于业务决定100%正确。
兜底策略：无论哪种方法，都需加后校验——用精确成员检查与schema校验确认输出属于封闭集合；模糊匹配可能把错误输出强制归类，不宜作为严格验收。失败时拒绝结果、有限重试或人工处理。
参考资料
换一种问法，检查是否真正理解
场景切入
假设你做一个订单分类系统，要自动把用户反馈归到‘物流延迟’‘质量问题’等20个固定标签里。你试过直接让大模型选，但结果偶尔跑偏。你会怎么确保它只输出这20个标签之一？
层层追问
用大模型做分类任务，你有没有遇到过它输出不在预设列表里的情况？……那你怎么限制它只能从给定的类别里选？……如果类别很多，或者类别名很长，直接提示不好使，还有什么更可控的办法？
直球架构
封闭集合标签分类，就是必须从固定类别列表里选一个输出。直接提示、思维链、Logit Bias、约束解码这四种方法，你对比过它们的准确率、延迟、成本吗？工业落地你会怎么选？
练习口述回答 · 约4分钟
- 本质是让大模型做受限选择，核心在平衡可控与灵活
- 直接提示和CoT适合简单场景，但工业落地不够稳
- Logit Bias只调整token概率，首token限制不能保证完整标签
- 完整标签约束与托管enum结构化输出限制形式，仍要验证语义
- 实际落地常混合使用，并做后校验兜底
这道题其实问的是，怎么让大模型这种天生发散的东西，老老实实从你给的一个列表里挑一个答案出来。核心矛盾就是，既要利用模型的语义理解能力，又要严格控制输出范围，不能让它自由发挥。
我一般会按可控性和成本，把方法分成四类来权衡。先说最直接的，就是直接在提示词里把类别列出来，让模型选。这个简单，但问题也很明显，格式不稳定，模型可能自己造个不在列表里的词，或者输出一堆废话。所以它只适合类别少、要求不高的场景，比如给用户评论打个「好评」「中评」「差评」这种。
再一个是[[思维链]]，就是让模型先推理再给结论。这个好处是可解释性强，比如客服退款场景，你可以让模型先分析用户退款理由是否合理，再输出「同意」或「拒绝」。但代价是延迟高、成本高，而且小模型推理能力不够，效果反而差。所以一般只在需要审计或解释的业务里用。
接下来是Logit Bias，只有具体模型和API支持时才能用；它调整指定token ID的概率，并不等于完整类别序列的白名单，不能靠首字偏置给出合法性保证。但这里有个坑，如果类别是多token的，比如「退货退款」是四个字，你只锁住首字「退」，模型后面还是可能走偏。所以通常要配合字符串匹配做二次校验。
最后是约束解码，也就是在生成过程中，每一步只允许模型从合法的token序列里选。它限制输出形式，但不保证选对语义标签。可以自建解码约束，也可以用支持enum的严格结构化托管接口，不一定要改推理引擎。比如金融风控场景，输出必须严格匹配「通过」「拒绝」「人工审核」这三个词，可以比较严格enum输出、完整序列约束、确定性分类器与规则，并处理拒答和截断；格式合规不等于风控决定正确。可以用 outlines 或 guidance 这些库，也可以自研有限状态机。
实际落地的时候，我很少只用一种方法。类别不多时，先比较直接提示与严格enum接口，实际测格式合法率和分类正确率；不能用100个作为普适阈值。失败结果应拒绝、有限重试或转人工，不能把更松的提示当严格合规兜底。但如果类别有几千个，或者有层级关系，比如商品分类，那硬枚举就不现实了，我会改用 [[Embedding]] 检索加小模型二次确认，先召回候选集再做约束。
这里有个前提，就是不管用哪种方法，上线前一定要做边界测试。比如常见失败场景是用户输入有歧义，模型可能在两个相近类别间犹豫，这时Logit Bias的权重设置就很重要，调不好反而会强制选错。