本周试了一个模型，最有价值的 1 个发现
这周我做了一轮很朴素的小模型实验。任务不复杂，就是把用户问题先分到固定类别里，再交给后面的规则链路处理。我原本只是想验证“小而快”的模型能不能扛住这类基础分类，结果最后最有价值的发现并不是成本更低，而是另一个更值得记住的事实：当问题边界足够清楚时，小模型往往比大家想象中更稳。
当时的任务很像很多团队都会有的第一层网关能力：先判断用户意图，再决定往知识检索、订单查询、人工转接还是普通 FAQ 解释去走。它没有复杂推理，也不追求文风，只要求三件事：标签别漂、格式别乱、延迟别太高。
我测试的其实不是“模型够不够聪明”，而是任务边界够不够窄
一开始我也本能地想用更强的模型兜底，图个省心。可把任务拆开以后发现，这一层根本不需要大模型擅长的那部分能力。它需要的是固定标签空间下的稳定输出，更像“约束内分类”，而不是开放式推理。
我后来会先把这类任务写成很明确的结构，比如：
{
"labels": [
"faq",
"order_status",
"refund_progress",
"human_handoff"
],
"output": {
"label": "one-of-labels",
"confidence": "0-1",
"reason": "short"
}
}
一旦标签空间、输出格式和调用场景都被钉住，实验的重点就不再是“模型能不能想出更聪明的答案”，而是“它能不能稳定地待在边界里”。
真正把结果拖坏的，往往不是模型大小
跑下来以后，我反而更确定了一个判断：很多时候把结果拖坏的，不是模型变小，而是任务定义本身就没收干净。最常见的是这几类问题：
- 标签定义看起来有四类，实际边界互相重叠
- 一条输入里混了两个意图，却还要求模型只能单选
- 输出格式没写死，模型开始自己发挥
- 兜底规则没想清楚，低置信度结果也被硬往后传
换句话说，小模型不稳的时候，第一反应不该总是“它能力不够”，而应该先看你是不是把一个本来就没定义清楚的问题，硬塞给了模型去补抽象。
我现在会怎么判断一个任务该不该先进小模型池
这次实验之后，我会先问自己四个问题：
- 标签空间是不是固定而且边界清楚。
- 输出能不能完全结构化。
- 低置信度时能不能被规则或人工兜住。
- 错一次的代价，是不是可控且可回收。
如果这四个问题里大部分答案都是“是”，那我通常会先把它放进小模型候选池，而不是默认用最大那档模型开路。
小模型真正省下来的，不只是调用费
这次实验里我最在意的收益，其实不是账单，而是系统结构更清楚了。因为一旦你承认“这一层只是稳定分类层”，后面很多东西都会跟着收敛：
- Prompt 会更短
- 输出解析更简单
- 回退规则更明确
- 后续换模型时也更容易做 A/B 对照
很多团队把模型选型理解成一次性的供应商选择，我现在更愿意把它看成任务分层的一部分。先把窄任务收出来，再决定该用哪一档模型，通常比“所有东西都拿大模型兜底”更稳。
这周最有价值的发现，其实是任务定义方法
这周最有价值的发现，最后并不是某个具体模型值不值得买，而是一条更值得长期复用的路线：先把任务边界收紧，再决定模型大小。对固定标签分类、参数抽取、字段补全这种窄任务来说，清晰的问题定义、结构化输出和可靠兜底，往往比更强的模型更能带来稳定收益。