当AI助手需要从八万个技能里挑几个来用，会不会挑出重复技能？

假设你现在要装修房子，找装修队。你打开一个平台，输入"我要装修厨房"，平台给你推荐了十个装修队。你点开一看，发现这十个里有八个都是专门做瓷砖铺贴的，剩下两个是水电改造和橱柜定制。问题来了：厨房装修光有瓷砖师傅是不够的，你还需要水管工、电工、油漆工、橱柜安装工,这些活儿一个都不能少。但平台的推荐算法只会按"跟你需求的匹配度"打分，瓷砖师傅因为都写着"厨房装修专家"所以匹配度最高,结果你的候选名单里全是同质化的选项,真正需要的其他工种反而被挤了下去。

这不是一个虚构的场景,这正是当下大语言模型智能体在调用外部技能时面对的真实困境。

大语言模型智能体：

大语言模型智能体（LLM Agent）指的是基于大语言模型构建的能自主完成任务的系统,它不仅能生成文字,还能调用外部工具、脚本、文档等"技能"来完成更复杂的工作。

想让AI帮你处理一份财务报表、生成一段可视化图表,或者操作一个复杂的自动化流程,单靠语言模型本身的"嘴巴"是不够的,它需要借助外部技能库,就像人类工作时需要打开各种软件工具一样。这几年,随着技能库越做越大,一个新问题冒出来了：从几万个技能里,怎么挑出最合适的那一小把?

问题到底难在哪

早期的工具调用研究,比如让语言模型学会调用API的Toolformer,已经证明了模型可以学会"什么时候该用工具"。后来出现的HuggingGPT让一个大模型充当调度员,把任务拆解成子任务,分配给不同的专家模型去执行。ToolLLM则把这套思路扩展到了上万个真实世界的API上。这些工作都在说一件事：外部工具能极大扩展语言模型的能力边界。

但工具用多了,新的麻烦就来了。

当技能库里躺着几万甚至几十万个技能时,你不可能把它们全部塞进模型的上下文窗口里,那样既浪费资源又会分散模型的注意力,让它更容易做出错误判断。于是"技能路由"这个新的研究方向诞生了,核心问题就是：怎么从海量技能里精准挑出跟当前任务相关的那一小批。

SkillRouter这个基准测试直接把这个问题摆上台面。它构建了一个大约八万个技能的候选池,发现完整的技能实现文本里藏着比单纯名字和描述更丰富的路由信号。另一个叫SkillsBench的工作则进一步验证了：精心挑选的技能确实能提升智能体的表现,但这个提升幅度很依赖任务类型和技能质量本身。

这些发现共同指向一个结论：技能选择正在变成智能体系统里越来越关键的一环。

但现有的技能路由方法几乎都用同一套思路：把每个候选技能拿去跟用户的请求单独打分,按分数从高到低排,取前几个。这套逻辑对付"只需要一个技能就能搞定"的简单任务没问题,因为只要找到那个唯一正确的答案就行。

真正的麻烦出在复合型任务上。一个用户请求往往需要好几个技能配合完成,比如先解析文档,再提取信息,然后做数据转换,最后生成可视化图表。这时候如果还是各打分、各排名,很可能出现这样的情况：几个功能相似、描述相近的技能因为都跟查询"沾亲带故",分数都很高,结果把候选名单挤得满满当当,而那些真正需要但描述风格不同的技能反而被排到了后面,根本挤不进最终的候选名单。

上下文窗口被浪费在了重复功能的技能上,而任务真正需要的互补技能却被漏掉了,这就是问题的本质。

从"排名"到"选集合"：DPP登场

面对这个问题,研究者们想到了一个跳出常规排序思路的办法：既然问题出在"独立打分、各自为战",那就换个角度,把选技能这件事看成一个"选出一组互补且不重复的组合"的问题,而不是简单地"选出分数最高的几个"。

这种思路在信息检索、推荐系统、文本摘要等领域早已有先例,统称为多样性感知检索,核心目标是选出的东西既要个个有用,又要彼此不重复。

行列式点过程（Determinantal Point Process，简称DPP）：这是一种概率模型,专门用来解决"选一组东西,既要质量高又要互相不重复"这类子集选择问题,数学上通过矩阵的行列式来同时刻画"每个元素单独有多好"和"元素之间有多相似"。

DPP这个工具听起来抽象,但用一个招聘场景就能理解它的价值。假设你要组建一个五人的产品团队,如果你只按"简历打分"挑人,可能会挑出五个背景高度相似的候选人,五个都是做前端开发出身,团队里没人懂产品设计、没人懂用户研究、没人懂后端架构。DPP的思路是,在挑选每一个新成员时,不仅看这个人本身够不够优秀,还要看他跟已经选进团队的人有多"像"。如果这个人和已经在团队里的人技能重叠严重,即使他简历分数很高,也会被适当"打折"；如果他能带来团队里还没有的能力,即使原始分数没那么惊艳,也会被优先考虑。这就是DPP要解决的核心矛盾：单纯的高分排序会让"同质化的强者"扎堆,而适度的多样性考量能让整个团队的综合战斗力更强。

不过,把DPP直接搬到技能路由上,并不是拿来就能用的。这里藏着一个微妙的陷阱：两个技能之间的"相似",可能有两种完全不同的原因。

第一种,它们是真正的功能重复,比如两个都是"翻译文档"的技能,选一个就够了,选两个纯属浪费。

第二种,它们恰好都跟同一个查询相关,但各自负责任务里不同的环节,比如"解析Excel表格"和"清洗数据列"这两个技能,虽然都属于同一个数据分析任务的范畴,乍一看语义上有些接近,但它们分工完全不同,都需要保留。

如果按照标准DPP的做法,对所有的相似性一视同仁地进行惩罚,那第二种情况会被误伤,那些本该共同出现的互补技能反而会被排挤出局。这个陷阱不解决,DPP在技能路由上就是个半成品。

DSR：把"因查询而相似"和"真的重复"分开算

针对这个陷阱,研究团队提出了自己的方案,叫DSR。

Diverse Skill Routing（多样化技能路由，简称DSR）：这是一个基于DPP的重排序框架,核心目标是在挑选技能候选集时,同时兼顾"跟查询相关"和"技能之间不重复"这两个诉求。

DSR的整体流程分成几步走。第一步,用一个编码器检索器从全量技能库里先捞出一批候选技能,这一步纯粹靠语义相似度,速度快但不够精细。第二步,用一个更强大的重排序模型给每个候选技能打一个质量分,这个模型能看到更丰富的信息,比如技能的完整实现代码,不只是名字和简单描述。第三步,也是最关键的一步,不再简单按分数排序取前几个,而是用DPP从候选集里挑出一个既高质量又不冗余的最终子集。

这个三步走的设计本身就体现了一种权衡思路：先用便宜的方法筛出一个不大的候选池,再用贵的方法在小范围内精细打分,最后用DPP做最终的组合优化。如果一开始就对全部八万个技能跑复杂的DPP计算,那计算量会大到无法承受,这就好比在超市里买菜,你不会把整个仓库的货品都搬到收银台前一件件比较,而是先按类别走到对应的货架前(检索),再在有限的几个品牌里精挑细选(重排序和多样性优化)。如果省略了第一步的粗筛,直接在几万个选项里做精细的两两比较,时间成本会呈爆炸式增长,这套系统根本无法在实际场景中运行。

而DSR真正的创新点,在于它怎么定义"两个技能到底有多相似"这件事。

查询残差多样性核（Query-Residual Diversity Kernel）：这是DSR提出的一种计算技能相似度的新方法,核心做法是先把两个技能表示中"跟当前查询相关的那部分"去掉,只在剩下的"残差"部分里计算相似度,这样能避免把"因为都跟查询相关而显得相似"错误地当成"真正的功能重复"。

具体的数学操作是这样的：假设每个技能都有一个向量表示（embedding）,可以理解成用一组数字描述这个技能"长什么样"。DSR先算出这个技能向量里跟查询方向"重合"的那一部分,然后把这部分从技能向量里减掉,剩下的就是"残差"，也就是这个技能里跟当前查询无关的、体现它独特功能的那部分。之后,DSR不是完全只用残差来算相似度,而是把残差和原始向量按一定比例混合（论文里这个混合系数设为0.85,也就是大部分权重给残差,小部分权重保留原始信息以保证稳定性）,再重新归一化。最终用这个混合后的向量算两个技能之间的相似度,作为DPP多样性惩罚的依据。

这个设计如果换成一个更贴近生活的类比来理解,会更清楚它解决的问题所在。想象你在给一个家庭聚会挑选菜品,你已经知道这次聚会的主题是"川菜"。如果你只看"这道菜是不是川菜"这个维度去判断两道菜有多像,那么水煮鱼和麻婆豆腐都会显得"很像",因为它们都属于川菜,都辣。但如果你把"是不是川菜"这个共同属性先剥离掉,只看剩下的部分,水煮鱼是水产类,麻婆豆腐是豆制品类,它们其实是完全不同的菜品,搭配在一起才是一桌丰富的宴席。查询残差核做的正是这件事：先把"都跟这次查询相关"这个共性剥离掉,再看剩下的功能差异有多大。如果不这么做,直接拿原始向量算相似度,水煮鱼和麻婆豆腐会因为"都是川菜"被系统误判为冗余,其中一个会被踢出候选名单,结果你的餐桌上可能同时出现两道鱼、却漏掉了豆制品这个品类。

实验说了什么

DSR团队在SkillRouter这个基准测试上做了系统的验证,这个测试集包含75个经过专家验证的查询,覆盖55个领域、8个大类,技能候选池大约八万个。查询分成两类，24个是单技能查询(只需要一个正确答案),51个是多技能查询(需要两到五个技能配合)。

召回率（Recall）：衡量在返回的前k个结果里,真正需要的目标技能被找到了多少比例。

完全覆盖率（Full Coverage）：衡量一个查询所需要的所有目标技能是否都被完整地包含在了前k个结果里,这个指标比召回率更严格,因为漏掉任何一个必需技能都算不合格。

为什么完全覆盖率格外重要?因为在多技能任务里,少一个环节整个流程就断了。就像做菜的时候,少了一味调料可能不影响能不能吃,但少了一道关键工序,这道菜可能就做不出来。

实验结果显示,在全部75个查询上,DSR相对于强力的SkillRouter基线（这个基线本身已经用了一个学习出来的重排序模型,不是简单的向量匹配）,在前20个结果里把召回率从0.754提升到了0.768,完全覆盖率从0.560提升到了0.573。这个提升幅度看起来不算惊艳,但要注意,DSR并没有改变底层的检索模型和打分模型,只是改变了"怎么把打好分的候选组合起来"这一步,单靠这一步就能拿到提升,说明选择策略本身确实存在优化空间。

真正让差距拉开的是更长的候选列表。在前50个结果里,DSR把整体召回率从0.754提升到了0.808,完全覆盖率从0.560提升到了0.633，多出7个百分点。而在多技能查询这个子集上,差距更明显：完全覆盖率从0.458提升到了0.551,提升了将近10个百分点。

这个数据背后的含义是：当任务越复杂、需要的技能越多样,DSR相对传统方法的优势就越大。这跟设计初衷是吻合的,因为单技能任务本身就不存在"冗余"问题,只有一个正确答案要找,DSR和普通排序方法在这种任务上表现几乎一样(前10个结果里,两者的召回率和完全覆盖率完全相同,都是0.875)。

研究团队还做了细致的消融实验,用来验证"查询残差核"这个设计到底有多关键。他们把DSR里的多样性计算换成最普通的原始余弦相似度核（也就是不做任何残差处理,直接拿两个技能的原始向量算相似度）,结果在多技能查询上,前10个结果的完全覆盖率从0.441狠狠跌到了0.254,几乎打了对折。

这组对比数据说明了一件很重要的事：如果直接套用标准的多样性算法,不做残差处理,效果反而比不用DPP还要糟糕。因为标准余弦核会不分青红皂白地惩罚所有相似性,把那些"因为都跟查询相关而略显相似,但功能完全互补"的技能一并踢出局,这正是前面提到的那个陷阱在实验数据里的具体体现。

如果把这个消融实验换个角度理解会更直观。假设你在挑选团队成员时用了错误的"多样性"标准,比如你觉得"性别不同就算多样",于是刻意避开跟你性别相同的候选人,结果可能选出一群性别各异但专业能力高度雷同的人。这种表面上的"多样性"完全没有解决实际问题,反而可能因为矫枉过正把真正合适的人选给排除了。DSR的查询残差核想解决的,正是"用错误的维度去衡量多样性"这个陷阱。

论文还比较了不同排序策略的表现，包括纯向量检索、零样本大模型重排序（直接让Qwen3-8B这个模型对候选技能打分排序,不做额外训练）、学习出来的SkillRouter重排序模型,以及DSR。结果显示零样本大模型重排序的效果反而不如专门训练过的重排序模型,说明单纯依靠通用大模型的判断力,在面对成千上万个高度相似的候选技能时,精细辨别能力还是不够的。

这套方法留下的问题

DSR的整套方案建立在一个前提之上：检索阶段已经把真正需要的技能捞进了候选池里。如果一开始的粗筛就漏掉了某个关键技能,后面无论多样性算法设计得多精妙,都没办法把它捞回来。这就好比你去菜市场买菜,如果你压根没有走到卖豆腐的那个摊位,那不管你在已经走到的摊位前怎么精心搭配,豆腐永远不会出现在你的菜篮子里。DSR解决的是"从已有候选里怎么选"的问题,不是"候选池本身够不够全"的问题,这两者是不同层面的挑战。

另外,论文用的评估指标是召回率和完全覆盖率,这些都是"技能有没有被找到"层面的指标,并不直接衡量智能体最终任务完不完成。就算所有需要的技能都被正确检索出来了,智能体在实际执行时仍然可能因为工具用错了顺序、规划出了问题,或者技能之间的指令产生冲突而失败。这中间还隔着一层没有被这篇论文覆盖的距离。

从更早期的工作看,这个研究方向的演进路径其实挺清晰。2023年的Toolformer和HuggingGPT解决的是"模型要不要用工具、怎么用一个工具"的问题,规模都不大。2023年底的ToolLLM把工具数量扩展到了上万个,开始触及规模化的门槛。而SkillRouter把这个规模又提高了一个量级到八万,同时明确指出了"完整技能实现比名字描述更有信息量"这个此前被忽略的细节。DSR站在这些工作的基础上,往前迈的这一步是把"选技能"从单纯的相关性排序问题,重新定义成了一个需要兼顾多样性的组合优化问题。这个思路上的转变,可能比某个具体的技术实现更值得记住。

写在后面

读这篇论文时,最触动我的其实是那个"查询残差"的设计细节,它解决的不是一个高深的数学难题,而是一个非常朴素的认知陷阱：我们太容易把"因为相关而相似"和"因为重复而相似"混为一谈。这个陷阱不只存在于技能路由里,几乎存在于任何需要"挑选一组东西"的场景中,比如你在Netflix上被推荐了五部风格接近的电影,系统可能觉得它们都"符合你的口味",却没意识到你可能只是最近看了一部悬疑片,系统把"悬疑"这个共性当成了你的核心偏好,反而漏推了你真正想看的其他类型。

论文里那组消融实验的数据也值得单独说一说：完全覆盖率从0.441掉到0.254,几乎是腰斩。这说明"加了多样性算法"这件事本身不一定带来提升,如果多样性的衡量标准是错的,反而可能比什么都不做还糟糕。这个反直觉的结果提醒人,好的想法如果实现细节出了岔子,效果可能比原始方案更差,这在很多工程实践里都是容易被忽视的一课。

这套思路还留下一个没被回答的问题：当技能库继续膨胀到百万级、千万级规模时,现在这套"先粗筛再精排"的两阶段流程还能撑住吗?候选池的粗筛环节本身要不要引入多样性考量,而不是只在最后一步做?这个问题目前还没有答案,但顺着这篇论文往前想,似乎是个绕不开的方向。

Q&A

Q1：Diverse Skill Routing（DSR）是什么？

A：DSR是一种面向大语言模型智能体的技能路由框架,它用行列式点过程（DPP）在候选技能中挑选出既跟用户查询相关又互相不重复的技能组合,而不是像传统方法那样只按相关性分数排序取前几个。

Q2：DSR相比传统的技能排序方法有什么优势？

A：在SkillRouter基准测试上,DSR在多技能查询的完全覆盖率上比传统重排序方法高出近10个百分点,尤其在需要多个技能配合完成的复杂任务上优势更明显,单技能任务上两者表现基本一致。

Q3：查询残差多样性核解决了什么问题？

A：它解决了"因为都跟查询相关而显得相似"和"真正功能重复"被混淆的问题。如果直接用普通相似度算法惩罚所有相似技能,会把本该保留的互补技能误删,实验显示这会让完全覆盖率从0.441跌到0.254。