SkillRouter：当技能库突破8万规模，精准路由的正确打开方式

随着大语言模型智能体生态的快速发展，我们正目睹一场静默的技能库革命。从Claude Code、Codex CLI这样的编程助手，到各类个人AI助理，背后都依赖一个规模日益庞大的技能库来扩展自身能力边界。然而，当技能数量从最初的几百个膨胀到数以万计时，一个核心工程问题浮出水面：如何在百万候选中精准捞出当前任务真正需要的那几个技能？这就是「技能路由」（Skill Routing）任务的诞生背景。

核心发现：技能实现体才是关键信号

在深入方法设计之前，有必要先分享论文最具颠覆性的实验发现，因为它直接改变了整个问题的解题思路。研究者系统对比了两种输入配置：nd（仅使用name+description）和full（name+description+body），结果令人震惊——去掉body会导致检索性能灾难性崩溃：BM25在nd配置下Hit@1直接跌到0，稠密编码器Qwen3-Emb-0.6B从58.7%跌到22.7%，足足下降了36个百分点。更反直觉的是，即使换成8B参数的大模型，在nd配置下也只有30.7%，远不如0.6B模型带body的效果。模型规模根本无法弥补缺少body带来的信息损失。

SkillRouter两阶段检索流水线

这一发现直接推翻了业界长期以来的隐性假设——名称+描述已足够判断技能相关性。更进一步，论文通过注意力分析揭示了深层机制：交叉编码器重排器对body字段的注意力占比高达91.7%，name仅占7.3%，description更是只有1.0%。层间分布也很有规律——早期层几乎全在看body（97.3%），进行token级别内容理解；中间层name的注意力逐渐升高，在第19层达到峰值26.3%，进行语义名称匹配；末尾层再次回归body主导，做最终相关性判断。这个发现为SkillRouter的整个设计确立了根本原则：两个阶段都必须使用完整body。

实验结果与性能分析

SkillRouter是一个精心设计的两阶段流水线，总参数量仅1.2B（0.6B编码器+0.6B重排器）。 第一阶段采用双编码器架构（SR-Emb-0.6B），以Qwen3-Emb-0.6B为基座，对查询和所有技能用完整文本分别编码到共享嵌入空间，通过余弦相似度检索将候选规模从~80K压缩到20。训练数据构造上，论文用GPT-4o-mini根据每个技能内容生成合成查询，要求不能直接提及技能名称，确保查询反映的是真实功能需求。负样本挖掘采用四路来源：语义负样本、词汇负样本、同类负样本和随机负样本。这里有一个容易被忽视但至关重要的细节——假负样本过滤：社区技能库里功能几乎完全相同的技能大量存在，必须通过名称去重、body文本Jaccard相似度过滤（阈值0.6）、嵌入余弦相似度过滤（阈值0.92）三层过滤，否则Hit@1会下降4个点。 第二阶段使用交叉编码器重排（SR-Rank-0.6B），对每个（查询，候选技能）对做token级别交叉注意力，输出精细相关性分数。训练时对比了两种损失函数，结果差异巨大：Listwise CE在候选列表上做softmax建模相对排序，而Point

实践启示与未来展望

实验结果印证了方法设计的有效性。在编码器检索阶段，SR-Emb-0.6B以65.4%的平均Hit@1领跑所有基线编码器，包括参数量达13倍的Qwen3-Emb-8B（64.0%），也超过了text-embedding-3-large（62.0%）和gemini-embedding-001（58.7%）。值得注意的是，微调带来的增益（8B基座上+4.0pp）远大于单纯扩大规模的增益（0.6B到8B的+2.6pp），这说明训练方法比模型规模更重要。 端到端流水线（SR-Emb-0.6B × SR-Rank-0.6B，1.2B参数）达到74.0% Hit@1，比最强零样本8B基线高出6个百分点，比编码器单独使用高出8.6个点。更细致的分析显示：重排器在150个查询里修复了19个（12.7%）编码器没排到第一的case，仅破坏了6个（4.0%）原本正确的case，净贡献+8.7pp。还有33个查询（22.0%）两个阶段都没答对，这些基本上属于需要多跳推理才能建立查询-技能连接的情况，是当前检索方法的能力上限。 在效率方面，技能嵌入可以离线预计算存入向量索引，推理时只需对查询做一次0

如有侵权，请联系删除。