Fable5：20美金的顶级设计师登场！
2026-07-08 3386796
2026-07-08 0
别再为大模型的高成本犯愁！小模型在分类、抽取、重排这三个边界清晰的任务上，成本更低、速度更快、效果更稳定。核心内容：1. 小模型在成本、延迟和稳定性上的独特落地优势2. 分类、抽取、重排三大核心任务的应用场景与原理3. 如何将三个方向串联构建高效AI应用流水线
小模型最适合的不是“替代大模型回答所有问题”，而是承担边界清晰、输出稳定、调用高频的基础能力。
过去两年，很多团队接入大模型后都会遇到同一个问题：大模型效果很好，但成本、延迟和稳定性不一定适合所有环节。尤其在生产系统里，真正高频的任务往往不是开放式长文生成，而是分类、抽取、排序、过滤、路由、审核、结构化处理。
这些任务有一个共同特点：输入可以复杂，但输出空间相对可控。因此它们非常适合用小模型落地。
如果把一个 AI 应用拆开看，大模型更像“复杂推理和生成引擎”，小模型更像“数据处理流水线里的专用算子”。其中最容易落地的三个方向是：
这篇文章用数据流图和工作流图讲清楚这三个方向的原理、方法和落地路径。
小模型的优势不是“无所不能”，而是：
分类、抽取、Rerank 正好符合这些条件。
这三个方向不是彼此独立的。很多真实系统会把它们串起来：先分类判断意图，再抽取关键字段，最后对候选知识或商品做 rerank。
分类是最容易落地的小模型任务。它的目标很简单：给定一段输入，输出一个或多个标签。
典型场景包括：
| 场景 | 输入 | 输出 |
|---|---|---|
| 客服意图识别 | 用户问题 | 退款、物流、售后、投诉 |
| 内容审核 | 文章/评论 | 正常、广告、低俗、涉政、辱骂 |
| 工单分派 | 用户反馈 | 产品、技术、财务、运营 |
| 邮件分类 | 邮件正文 | 销售线索、客户投诉、垃圾邮件 |
| Agent 路由 | 用户任务 | 搜索、写作、代码、数据分析 |
分类任务的关键不是让模型“会聊天”，而是让模型在固定标签空间里做稳定判断。
例如客服场景里，模型不需要生成解释，只需要输出：
{
"intent": "refund",
"confidence": 0.92
}分类可以按成本和效果分成四种路线：
| 方法 | 适合阶段 | 优点 | 局限 |
|---|---|---|---|
| Prompt 分类 | 冷启动 | 不用训练，最快上线 | 成本高，稳定性一般 |
| Embedding + 规则 | 少量标签 | 简单、可解释 | 边界复杂时效果有限 |
| 小模型微调 | 稳定业务 | 成本低、速度快、效果稳 | 需要标注数据 |
| 蒸馏大模型 | 标签难、样本少 | 利用大模型生成数据 | 数据质量要控制 |
最常见的落地工作流是：先用大模型和规则冷启动，再积累真实数据，最后训练小分类模型。
分类不是标签越多越好。真正重要的是标签体系要服务业务动作。
一个好分类系统通常满足：
如果某个标签没有对应业务动作，它往往不是一个好标签。
抽取的目标是从文本中提取字段，比如姓名、公司、时间、金额、地址、诉求、风险点、合同条款等。
它是小模型落地的第二个高频方向，因为大量企业流程的本质都是“把文档和对话变成表格”。
典型场景包括：
| 场景 | 输入 | 输出 |
|---|---|---|
| 简历解析 | 简历文本 | 姓名、学校、公司、技能、年限 |
| 合同审查 | 合同条款 | 甲方、乙方、金额、期限、违约责任 |
| 发票/票据处理 | OCR 文本 | 抬头、税号、金额、日期 |
| 销售线索 | 聊天记录 | 公司、联系人、预算、需求、时间 |
| 风控审查 | 申请材料 | 主体、金额、异常描述、风险等级 |
抽取任务和分类不同：分类输出一个标签，抽取输出一组字段。
例如销售线索抽取可以输出：
{
"company": "某某科技有限公司",
"contact": "张先生",
"budget": "20万以内",
"need": "私有化部署知识库问答",
"timeline": "本季度",
"risk": "预算未确认"
}抽取任务常见有三种做法。
| 方法 | 适合场景 | 优点 | 局限 |
|---|---|---|---|
| 序列标注 | 人名、地点、金额、时间等实体 | 快、稳定、可控 | 对复杂字段和跨句关系弱 |
| 生成式抽取 | 多字段、复杂 schema | 灵活，适合 JSON | 需要格式约束和校验 |
| 规则 + 模型 | 财务、票据、合规 | 精度高、可解释 | 规则维护成本高 |
生产级抽取系统一般不会只依赖一次模型输出，而是“模型抽取 + 规则校验 + 置信度判断 + 复核闭环”。
抽取落地最容易踩的坑是只看整体准确率，不看字段级错误。比如金额、日期、合同主体这类字段，错误成本远高于普通描述字段。
因此抽取评估要分字段看：
Rerank 是小模型最容易被低估的方向。它通常出现在搜索、推荐和 RAG 系统里。
一个典型 RAG 链路不是直接让大模型读整个知识库，而是先召回一批候选片段，再用 rerank 模型重新排序，把最相关的证据放进上下文。
Rerank 的价值在于：召回阶段追求“不要漏”，重排阶段追求“排得准”。
向量检索擅长语义相似，但在真实业务里会遇到很多问题：
Rerank 模型会同时读取 query 和 document，判断它们是否真的相关。
相比 embedding 召回，rerank 更慢，但更准。所以通常只对 Top 20、Top 50 或 Top 100 候选做重排。
| 形态 | 优点 | 局限 | 适合阶段 |
|---|---|---|---|
| Cross-Encoder | 精度高，工程成熟 | 候选多时成本高 | 生产常用 |
| Late Interaction | 效率和效果折中 | 系统复杂度更高 | 大规模搜索 |
| LLM-as-Reranker | 零样本能力强 | 成本高、慢 | 冷启动和数据构造 |
| 小模型蒸馏 Rerank | 便宜、快、可定制 | 需要训练数据 | 稳定业务 |
Rerank 的训练数据本质是三元组：query、正样本、负样本。
其中最重要的是难负样本。也就是“看起来很像，但其实不相关”的文档。没有难负样本，rerank 模型很难学会精细区分。
Rerank 的收益通常非常直接：同样的上下文长度下，放进去的证据更相关，大模型回答就更稳；同样的回答质量下，可以减少进入 prompt 的片段数量，降低成本和延迟。
在真实系统里，分类、抽取、Rerank 经常组合出现。
比如一个企业知识库客服系统：
再比如一个销售线索处理系统：
这也是小模型落地的正确姿势：不要试图让一个小模型做所有事，而是把它们拆成多个稳定节点，每个节点解决一个清晰问题。
很多团队一开始没有标注数据，这时可以先用大模型冷启动，再逐步沉淀小模型。
这条路线的关键是：大模型负责探索和造数据，小模型负责稳定、低成本执行。
推荐分三阶段：
| 阶段 | 目标 | 做法 |
|---|---|---|
| 冷启动 | 验证业务价值 | Prompt + 大模型 + 少量规则 |
| 半自动 | 沉淀数据标准 | 大模型打标 + 人工抽检 + 规则校验 |
| 生产化 | 降低成本和延迟 | 小模型微调/蒸馏 + 监控回流 |
三个方向的评估指标不一样。
Mermaid render failed:
分类要重点看：
抽取要重点看：
Rerank 要重点看：
小模型的部署方式更灵活：
| 部署方式 | 适合场景 | 特点 |
|---|---|---|
| API 调用 | 快速上线 | 运维简单，成本随量增长 |
| 自托管 GPU | 中高并发 | 成本可控，需要运维 |
| CPU 推理 | 轻量分类/抽取 | 成本低，延迟可接受 |
| 边缘部署 | 隐私敏感、低延迟 | 模型更小，能力受限 |
| 批处理离线 | 文档处理、数据清洗 | 吞吐优先，不要求实时 |
实践中可以按任务频率选：
很多项目失败不是模型不行，而是业务定义不清。分类标签互相重叠，抽取字段没有标准，rerank 相关性没有判定规则，都会让训练数据变脏。
分类准确率高，不代表业务自动化率高；抽取字段准确，不代表能通过业务校验；rerank 指标提升，也要看最终 RAG 答案是否更好。
小模型适合高频稳定任务，但必须有置信度阈值、人工复核、大模型兜底或规则兜底。
小模型最大的优势是可以持续适配业务。如果没有错例回流和周期训练，它很快会跟不上业务变化。
分类、抽取、Rerank 可以概括为一句话：
分类决定“走哪条路”，抽取决定“拿哪些字段”，Rerank 决定“先看哪些证据”。
它们之所以适合小模型，是因为任务边界清晰、输出可控、调用高频、业务价值直接。
未来很多 AI 应用不会是一个大模型从头做到尾，而是由多个模型组成的流水线：小模型负责判断、过滤、抽取、排序和校验，大模型负责复杂推理和自然语言生成。
真正有效的落地方案，不是简单用小模型替代大模型，而是把大模型能力拆解成一组可训练、可评估、可部署的专用节点。谁能把这些节点串成稳定工作流，谁就能把 AI 应用从“能演示”推进到“能规模化运行”。
登录查看剩余 70% 内容