核心论点：当候选集被软预过滤压到 M=8 时，工具选择本质上是个「语义匹配」问题，不是「推理」问题。BGE embedding + 64 维隐藏层线性头（~1MB）能达到 97.5% 精度，与 Qwen3-1.7B-unified（99.4%）几乎持平，但延迟从 922ms 降到 10ms，且可纯 CPU 部署。

---

问题：LLM 工具选择的代价

在《软预过滤工具选择方案》篇里，我们把候选集从全集压到 Top-K=8，大幅降低了 Function Calling 的负担。但即使 M=8，用 1.5B–1.7B 小模型做工具选择仍有明显代价：

• 延迟：Qwen3-1.7B p95 约束解码 922ms，Qwen2.5-1.5B p95 约束解码 797ms（含模型加载、prefill、decode）
• 部署：必须 GPU，CPU 推理极慢
• 成本：每请求 1.7B 参数的矩阵乘法，Token 消耗是 embedding 路由的数十倍
• 规模敏感：候选集从 8 涨到 40 时，p95 延迟从 422ms 涨到 2813ms，增长 6.7 倍

这些代价在低并发、高延迟容忍的场景下可以接受，但在要求「毫秒级响应、海量并发」的场景下，就成了瓶颈。

关键问题：M=8 时，工具选择真的需要 1.7B 参数的推理能力吗？还是说，这个问题本质上是个「语义匹配」，用更轻量的模型就能解决？

---

方案：embedding 路由的四级流水线

我们的思路是把工具选择拆成四个阶段，每个阶段用不同复杂度的模型：

用户 query
    ↓
[规则过滤] 排除明显不相关的工具（零延迟）
    ↓
[FAISS 语义召回] 从剩余工具里取 Top-K 相似（毫秒级；FAISS 是 Meta 开源的高效向量检索引擎，专为大规模 embedding 检索设计）
    ↓
[线性头精排] 在 Top-K 候选上做最终分类（~10ms）
    ↓
[LLM 兜底] 对线性头不确定的 query 用 Qwen3 做约束解码（~800ms）

为什么这个思路可行

M=8 的场景下，候选集已经被预过滤压缩到很小。此时工具选择的核心挑战不再是「从 40 个工具里大海捞针」，而是「在 8 个高度相似的候选里做细粒度语义区分」——这更接近「分类」而非「推理」。

分类问题用分类模型解决，比用生成模型更高效。

线性头的设计

我们用 PyTorch 实现了一个极简分类头：

• 输入：BGE-small-zh-v1.5 embedding（512 维）
• 结构：两层全连接网络，第一层将 512 维 embedding 压缩到 64 维隐藏层，经激活函数后映射到工具类别数
• 参数量：约 35KB（512×64 + 64×40 = 32,896 + 2,600 = 35,496 参数）
• 训练：QLoRA（Quantized Low-Rank Adaptation，量化低秩适配，一种只训练少量参数的微调技术）数据驱动的 SFT 样本，CrossEntropyLoss（交叉熵损失，分类任务的标准损失函数） + Adam（自适应矩估计优化器），20 epoch
• 推理：单次前向传播，CPU 上 ~10ms

与 1.7B LLM 相比，这个模型的参数量小了 1700 倍，但保留了语义判别能力。

---

实测：M=8 四向对比

固定 40 工具池、M=8（gold 即正确答案工具 + 7 个随机干扰项，Top-K 指取相似度最高的前 K 个候选），同一台 RTX 4070 GPU / CPU，对比四种方案：

方案	模型大小	精度	p95 延迟	部署
A 余弦相似度	~0MB	59.0%	~6ms	纯 CPU
B 线性头	~1MB	97.5%	10.4ms	纯 CPU
C1 Qwen2.5-1.5B-tool-select	1.5B	90.2%	797ms	GPU
C2 Qwen3-1.7B-unified	1.7B	99.4%	922ms	GPU

精度对比

对比	精度差	结论
B vs C1 (Qwen2.5)	+7.3%	线性头不仅更快，精度也更高
B vs C2 (Qwen3)	-1.9%	精度几乎持平，差距在统计误差内
C2 vs C1	+9.2%	Qwen3 比 Qwen2.5 精度高，但慢 15%

延迟对比

方案	p95 延迟	相对速度
A 余弦	~6ms	基准
B 线性头	10.4ms	1.7x（包含 embedding 编码）
C1 Qwen2.5	797ms	77x
C2 Qwen3	922ms	88x

核心发现：Arm B（线性头）在精度只比 Qwen3 低 1.9% 的前提下，延迟降低 88 倍，且可纯 CPU 部署。

这些数字回答了"精度够不够"的问题，但还不够——我们还关心"在哪些难度上靠谱、哪些难度上会翻车"。下一节按五级难度拆开看。

---

逐难度分析

难度	说明	A 余弦	B 线性头	C1 Qwen2.5	C2 Qwen3
精确匹配	query 与工具名/描述直接重合	高	100%	97.5%	100%
隐含匹配	用户未明说工具名，但意图唯一对应	中	~95%	~95%	100%
混合意图	一句话包含多个意图，主意图可识别	中高	~90%	~92%	~98%
同义表达	用近义词/口语化说法描述同一工具	高	~85%	86.2%	~97%
歧义（最难）	多个工具都相关，需上下文/推理消歧	低	~75%	85.0%	~99%

规律：

• 余弦在歧义场景上最弱（近义工具区分需要训练）
• 线性头在同义和歧义场景上显著优于 Qwen2.5，说明 64 维隐藏层已经能学到近义区分
• Qwen3 在歧义场景上最强，但付出了 88 倍延迟的代价

逐难度分析揭示了线性头的强项与弱项，但实际系统不会只跑一种模型。下一节讨论：什么时候该用线性头，什么时候该升级到 LLM。

---

什么时候该用 LLM，什么时候该用线性头

不是所有场景都应该用线性头替代 LLM。我们的结论是分工，不是替代：

用线性头的场景

• 候选集已被预过滤到 M≤10：这是关键前提。如果候选集很大（M≥20），线性头的分类能力不足以覆盖近义混淆
• 延迟敏感：要求 p95 < 50ms
• 成本敏感：无法承担 GPU 推理成本
• CPU 部署：边缘节点、无 GPU 环境
• 工具集稳定：工具上线频率低，训练数据不需要频繁更新

⚠️ 重要前提：线性头的训练数据是静态快照，在频繁新增/修改工具的场景下会快速过时。如果工具集变化频繁，必须配套自动训练流程——当工具集变化时，自动生成增量训练数据、增量训练、评估并热更新模型，否则线性头的精度优势会被工具漂移快速侵蚀。

用 LLM 的场景

• 候选集较大（M≥20）：需要更强的语义判别力
• 复杂参数抽取：工具选择的同时需要抽取结构化参数（此时 LLM 的生成能力是必要的）
• 分布漂移快：新工具频繁上线，需要 LLM 的 few-shot 泛化
• 多轮/多工具：单轮单工具之外的复杂场景

最佳实践：组合使用

在实际系统中，我们建议四级路由：

P0 规则过滤命中 → 直接采用（零延迟）
P1 FAISS 高置信（相似度 >= 0.85）→ 直接采用（~10ms）
P2 线性头高置信（softmax >= 0.90）→ 直接采用（~10ms）
P2 线性头中置信（0.5 <= 得分 < 0.9）→ 升级到 LLM 精排（~800ms）
P2 线性头低置信（得分 < 0.5）→ 人工兜底或降级
P3 LLM 兜底 → 必须返回结果（~800ms）

这样既保留了线性头的高吞吐，又用 LLM 兜住了线性头不擅长的歧义边界 case。

有了"什么时候用什么"的判断标准，接下来看怎么把线性头真正落地到训练和部署。

---

核心要点

• M=8 时工具选择本质是语义匹配，不是推理：1MB 线性头已足够，不需要 1.7B LLM 的推理能力
• 精度差距可接受、部署成本天差地别：线性头 97.5% vs Qwen3 99.4%，差 1.9%，但延迟快 88 倍，且可纯 CPU 部署；Qwen2.5 在 M=8 反而不如线性头（90.2% < 97.5%），说明 1.5B 小模型在分布外场景下表现不佳
• 最佳实践是组合，不是替代：线性头扛大部分流量，LLM 兜歧义边界 case
• 频繁新增工具时，静态训练数据会快速过时：线性头和 LLM 都面临这个问题。更好的方案是设计自动训练流程——工具集变化时自动检测、增量生成数据、增量训练/微调、自动评估并热更新。这样模型精度才能跟上业务演化，否则无论 1MB 还是 1.7B，都会随时间推移而失效。