先说结论：在垂直业务场景里，4B 小模型 + 精准业务数据，能打赢 14B 通用模型。我们在同一套评测集上做了对照，4B 微调版 90 分，14B 通用版 80 分。
下面是完整方法和数据，包括没用的部分。
一、为什么要做小模型
起因很实际：调用通用大模型做业务问答，有三个绕不过去的问题。
- 成本。 业务量大之后，每次调用都在烧钱，而且降不下来。
- 可控性。 通用模型不知道你的业务规则，答得"通顺但不对"，还很难纠正。
- 数据。 涉及客户资料、内部制度的场景，数据不能出内网。
所以方向定为：小参数 + 垂直数据 + 可本地部署。代价是通用能力会下降——这是有意的取舍，我们只要求它在业务题上准。
二、基座与训练方式
| 项 | 选择 | 原因 |
|---|---|---|
| 基座 | Qwen3-4B | 4B 参数量级在单卡可训、可推理；中文能力足够做业务问答 |
| 微调方式 | LoRA | 不动全量参数，训练快、显存省，改坏了能回滚 |
| 硬件 | 单机 RTX 5070 Ti | 消费级显卡能跑通，意味着客户也能本地部署 |
| 评测集 | 20 道业务题 | 人工出题、人工判分，覆盖真实工作场景 |
评测集只有 20 题——这是有意为之。20 题不追求统计显著性，只求"每一题都能说清为什么对/错"。样本多了反而看不清问题在哪。
三、五版迭代的真实数据
| 版本 | 业务评测 | 改了什么 |
|---|---|---|
| 基线（未微调 Qwen3-4B） | 80% | — |
| v0.1 第一版 | 85% | 加入业务问答对，格式统一 |
| v0.2 定版 | 90% | 补充边界案例 + 重写答案风格 |
| v0.3 尝试 | 90% | 继续加数据，无提升 |
| 对照：14B 通用模型 | 80% | 不微调，直接问 |
三个值得说的点：
1. 从 80 到 85 靠"格式"，从 85 到 90 靠"边界"
第一版提升主要来自答案格式统一（要求分点、给依据）。第二版的 5 个点全部来自边界案例——那些"看起来该这么答，实际该那么答"的题。这类数据最贵，也最有用。
2. 第三版加数据没提升
v0.3 继续堆数据，还是 90%。说明在这个任务上，数据质量已经到顶，再加同质数据没有边际收益。这时候应该改任务定义或换方向，不是继续喂。
3. 14B 通用模型只有 80
这个结果最有说服力：参数量大 3.5 倍，业务题上并没有更好。因为它不知道你的业务规则——它答的是"一般情况下的正确答案"，不是"你们公司该这么答"。
四、数据怎么构造
这块是核心，也是我们不太想公开细节的部分（涉及具体业务）。但结构可以讲：
- 从真实工作流里抽题，不是编题。每道题都对应一个真实发生过的场景。
- 答案分两层：结论 + 依据。只有结论的样本会让模型"给答案不说理由"，业务上不可用。
- 专门构造"陷阱题"：看起来像 A 类问题、实际是 B 类的场景。这类题决定模型能不能用。
- 统一拒答策略：不知道就说不知道，不猜。这条写进训练数据，比写在提示词里管用。
五、评测怎么设计（这部分最容易被糊弄）
很多"模型评测"是自己出题自己答，分数好看但没有意义。我们的做法：
- 题目先定，训练数据后做。 先写 20 道题和标准答案，再去构造训练集，避免"照着答案出题"。
- 人工判分，不看 BLEU/ROUGE。 业务题的对错不是字面相似度，是"这个回答能不能直接用"。
- 记录每题的判分理由。 不记理由的分数，下次没法复现。
- 对外公开评测方法和数据构成。 具体数据不能给（涉密），但方法可以。
六、哪些做法没用
诚实列一下，省得别人再走一遍：
| 尝试 | 结果 |
|---|---|
| 继续增加同质训练数据 | 无提升（90 → 90） |
| 把 temperature 调到很低求稳定 | 答案变呆板，业务可用性反而下降 |
| 用更大基座（14B 不微调） | 业务题 80 分，不如 4B 微调 |
| 纯提示词工程（不训练） | 能到 85 左右，再往上要靠数据 |
七、能复用到别的场景吗
能，但有前提：
- 任务边界清楚。 "什么算答对"必须能定义，否则没法评测。
- 有真实数据源。 没有真实业务问答，就只能编，编的数据训出来的模型不能用。
- 接受通用能力下降。 小模型微调后，闲聊和开放创作会变差。如果你的场景两者都要，得做路由。
一句话总结：垂直场景里，"知道你的业务"比"参数多"重要。前提是你真的把业务摸清楚了——这部分没法用算力换。
RELATED · 相关阅读
- 一个人推 14 个项目 — 为什么做小模型
- AI 短剧 5 个坑 — 内容侧实践