先这样答
我不会把规则、小模型和 LLM 看成互斥选项，而是根据意图是否明确、意图集是否稳定、流量大小以及延迟和成本要求来分层。通常让规则处理高置信的明确意图，让小模型承接流量大的稳定意图，再让 LLM 处理长尾、新增和边界模糊的请求。实际落地中，规则快路径加 LLM 兜底是常见的两级架构；头部流量足够大、标注数据也比较稳定时，可以再引入小模型。
规则主要是关键词和正则匹配，优点是速度快、行为可控，也容易解释，适合命令式表达、固定入口等高频明确意图。但它的覆盖面窄，用户换一种说法就可能漏掉，而且意图越多，规则冲突和维护成本越高，所以不适合单独承担开放表达。小模型分类器延迟和成本较低，适合类别稳定、流量大的场景，但依赖标注数据；新增意图或类目定义变化时，通常需要补数据并重新训练。LLM 可以直接通过 zero-shot 或 few-shot 分类，加意图时主要修改提示词，不必先积累完整标注集，但它的延迟和成本更高，输出也存在随机性。
如果类目定义清楚、意图之间差异明显，可以先用 zero-shot 验证；遇到相似问法对应不同意图，或者类别边界容易混淆，就用 few-shot。示例不能只放典型样本，还要成对覆盖边界案例，并在提示中写清每个类目的定义，强制模型只返回允许的枚举值。对于单句信息不足的输入，要结合多轮上下文和前文实体判断，仍然无法区分时就追问澄清，而不是强行分类。
评估上，我会先构造人工标注测试集，计算准确率并查看混淆矩阵，重点分析容易混淆的意图对；上线后再看转人工率和下游任务成功率，因为分类正确不等于任务完成。标注数据少时，可以让 LLM 先做预标注，再由人工抽查和修正，用于扩充数据。面试时我会收束为一句：按流量、稳定性、成本和边界复杂度分层选择，离线看分类是否分对，线上看任务是否真正完成。
面试官会怎么追问
-
「zero-shot 和 few-shot 具体怎么选？」 先看类目定义能否直接把边界说清，如果类别差异明显，可以用 zero-shot 快速验证。若存在大量相似表达、不同意图，或者模型经常在固定几类之间混淆，就加入 few-shot，对照展示边界案例。无论哪种方式，都要限制输出为预定义枚举值。
-
「标注数据很少，怎么保证分类稳定？」 先把类目定义、判断条件和容易混淆的边界写清楚，再补充成对的对照示例。可以让 LLM 对未标注数据做预标注，由人工抽查、纠错并逐步扩充测试集和训练集。评估时持续查看混淆矩阵，优先补充易混意图对的数据。
-
「同一句话可能对应不同意图，你怎么判？」 不只看当前句子，还要使用多轮上下文和前文出现的实体。例如相似问法在不同上下文中可能指向不同任务，需要结合之前谈论的对象来判断。上下文仍不足时，应追问用户补充信息，不要为了返回一个类别而猜测。
回答的坑
- 只比较三种方案谁更准确，忽略流量、意图稳定性、延迟、成本和维护方式，正确方向是先明确业务约束，再采用规则、小模型与 LLM 的分层组合。
- 只报一个整体准确率，掩盖易混意图和线上失败，正确方向是同时查看混淆矩阵、转人工率和下游任务成功率。
同系列的题