完整题目
假设你有一个通用大语言模型（LLM），希望将其应用于封闭集合标签分类任务（如情感分类、意图识别等），有哪些有效的方法可以确保模型输出严格限定在预定义标签范围内？请比较不同方法的优劣。
本文目录
答案要点
- 方法全面性（至少覆盖3种以上方法）
- 方法原理清晰，能讲清"如何限制输出"
- 优劣对比有实际考量（如延迟、准确率、灵活性）
- 提及工程落地细节（如缓存、并发）
核心方法对比
1. 提示工程 + 输出解析（最简单）
- 做法：Prompt里明确列出可选标签，要求模型单选；用正则/规则过滤非法输出
- 优点：零改造成本，快速验证
- 缺点：不可靠，模型可能幻觉、格式不统一；需兜底逻辑
2. Function Calling / Tool Use（推荐）
- 做法：在所用模型/API支持时启用strict工具schema，把label声明为enum并校验返回（如
{"label": "positive"}）。 - 优点：正常完成时可约束支持的schema；普通工具调用或JSON mode不等于strict，需查具体模型和端点。
- 缺点：模型需支持该能力；旧模型/小模型可能不支持
3. 约束解码（Constrained Decoding）
- 做法：在解码阶段限制每一步只能生成合法token序列，如用FSM、CFG或Outlines、Guidance等库
- 优点：在文法受支持且正常完成时限制合法标签；仍需检测失败、校验业务含义。
- 缺点：文法编译和掩码计算可能增加开销；支持结构化输出的引擎通常可直接配置，无需自行修改源码，接口以所用版本为准。
4. 分类头微调（SFT/LoRA）
- 做法：加线性层映射到标签空间，改为传统分类任务
- 优点：分类头的输出索引天然落在预定义类别内；是否更快取决于编码器、序列与部署配置。
- 缺点：需要标签数据与训练；该分类接口不负责通用生成，基座是否保留或受影响取决于冻结/微调方式，并非加头必然抹去通用能力。
选型建议
| 场景 | 推荐方案 |
|---|---|
| 快速验证/原型 | 提示工程 + 解析 |
| 生产环境、模型支持 | Function Calling |
| 标签集合必须合法 | 约束解码 + 失败检测 + 业务校验 |
| 极致性能、标签固定 | 分类头微调 |
可以组合提示、strict schema/文法约束与业务校验；strict工具接口本身可能已经封装约束解码，不必重复堆同一层，也不能把格式合法当分类正确。
参考资料
换一种问法，检查是否真正理解
场景切入
假设你做一个电商客服的意图识别，用户说“我想退换货”，你希望模型只输出“退货”、“换货”、“咨询”这几个标签之一。你一般怎么确保模型不会乱说一个不在列表里的词？
层层追问
用大模型做分类任务，你通常是怎么让模型输出固定标签的？……如果模型输出了不在列表里的内容怎么办？……那如果业务要求零错误，比如风控场景，你怎么保证输出绝对合规？
直球架构
给定一个预定义的标签集合，要求LLM输出严格限定在其中。请列出几种实现方案，并对比它们在可控性、延迟、开发成本上的优劣。你会怎么选型？
练习口述回答 · 约4分钟
- 本质问题：如何让生成模型变成分类模型
- 方案一：提示工程，快但不可靠
- 方案二：Function Calling，生产首选
- 方案三：约束解码限制集合，失败与业务校验仍需要
- 方案四：微调，极致性能但通用性差
- 落地组合与风险
这道题其实问的是，怎么把一个通用生成模型硬掰成分类模型，让它只输出我们想要的那几个标签。我做过一些落地，聊一下我的思路。
先说最简单的，提示工程加输出解析。就是在Prompt里把可选标签全列出来，告诉模型只能选一个，然后后面用正则或者规则把输出兜住。这个方案的好处是零改造成本，你甚至不用微调，拿个Prompt就能跑。但说实话，它非常不可靠。模型可能自己造个标签出来，或者格式乱七八糟，你解析的时候就得各种兜底。所以它只适合快速验证或者Demo，真正上线我不太敢只用它。
真正生产环境我比较推荐[[Function Calling]]。先核对具体模型和API的strict能力。你定义一个工具schema，比如{"name": "classify", "parameters": {"type": "object", "properties": {"label": {"type": "string", "enum": ["positive", "negative"]}}}}，这只是schema形状示意；要在支持的端点启用strict并满足required/additionalProperties等规则，不能凭这段普通工具定义承诺严格输出。拒绝、截断和工具未调用需单独处理。而且它还能跟后续的业务逻辑无缝衔接，比如直接解析出标签去触发动作。不过有个前提，就是你的模型得支持这个能力，有些老模型或者小模型可能不行，那就得换方案。
再一个方案是约束解码。这个理解起来很简单，就是在模型生成每个token的时候，用有限状态机或CFG去限制它只能走合法的路径。标签字符串与token边界不一定对齐，约束器按实际tokenizer与前缀屏蔽无法继续组成合法输出的token。正常完成时可限制格式与标签集合，但仍须检测拒绝、截断和业务误判。可以用引擎现成的结构化输出接口，例如所用版本vLLM的structured_outputs，无需一律自行改源码；文法编译和每步掩码的开销要实测。所以它适合那种零容忍错的场景，比如金融风控，你绝对不能输出一个不存在的标签。
最后一个方案是分类头微调。把LLM的最后一层换成线性层，直接映射到标签空间，本质上变成了传统分类模型。类别索引天然在有限集合内，但准确率和延迟仍要测。分类接口不负责通用生成，是否保留基座生成能力取决于冻结与微调方案，并非加头就必然失去通用性；它仍需要标注数据。所以它适合那种标签固定、数据量够、对延迟要求极高的场景，比如电商客服的退款原因分类；响应目标与可达延迟要在实际模型、硬件和负载下验证。
实际落地我很少只用一种方案，往往是组合使用。比如主链路用Function Calling，因为它兼顾了可控性和灵活性，strict工具模式本身可能已使用约束解码，关键路径还要做失败分支和业务校验，避免重复堆叠同一机制。或者对于一些高频但简单的分类，我会用微调好的小模型，只有复杂情况才调大模型。