多工具评分排序机制

这道题其实问的是，当多个工具都能完成同一个子任务时，我们怎么选。本质上是个多目标优化问题，要在功能匹配度、执行成本、历史表现之间找平衡。我会从评分机制、动态优化、还有落地时容易踩的坑这几个角度来说。

先说评分。我倾向用分层评分加模型化打分两条腿走路。分层评分就是算一个加权和：语义匹配分我用 [[Embedding]] 模型算工具描述和任务 query 的余弦相似度，历史绩效分用[[滑动窗口]]统计近 N 次调用的成功率，再加时间衰减让旧数据权重降低，成本项就是延迟和费用归一化后做负向惩罚。权重 α、β、γ 一开始可以凭经验设，但线上要用数据调。

光靠分层评分还不够，因为它只能捕捉显式规则。所以我还会训练一个轻量级路由模型，比如用 [[LoRA]] 微调 BERT，输入任务上下文和工具元信息，输出各工具的概率分布。这个模型能学到隐式偏好，比如地图场景下实时路况工具比历史统计工具更受青睐，但模型只在数据充足时才有效。

举个例子。在订单异常处理场景里，用户说“我的外卖超时了”，系统可能同时有“查订单状态”、“查配送轨迹”、“联系商家”三个工具。分层评分下，“查订单状态”语义匹配最高，但历史数据显示“查配送轨迹”在超时场景下用户满意度更高，这时候路由模型就能把“查配送轨迹”的分数拉上去。

这里有个坑：新工具上线时历史数据为零，直接打分会偏低，导致永远没机会被选。我会上线 乐观初始化，给新工具一个较高的先验分，让它有机会被试用。同时用 汤普森采样 在探索和利用之间平衡，说白了就是每次选工具时按概率随机抽，抽到新工具的几率跟它的置信度挂钩。

再一个关键是反馈闭环。工具执行后，结果质量，比如下游任务是否成功、用户有没有投诉，要回流更新评分。如果发现某个工具连续失败，我会降低它的分，甚至暂时下线。异常案例我会定期人工标注，用来重训路由模型。

还有一个兜底策略：设置置信度阈值。如果所有工具的分数都低于阈值，就不让模型自己选了，要么组合多个工具的结果，要么转人工。这能避免模型硬选一个不靠谱的工具导致整体失败。

不过说实话，这套东西能不能跑通，前提是数据要够。如果工具调用日志稀疏，或者工具本身经常变更，像 API 版本升级、服务下架，那评分和模型都得频繁重训。我上线前会特别关注数据质量，比如每个工具至少要有几百次成功和失败的样本，否则我会先用规则兜底。

所以我的取舍是：优先用分层评分做冷启动，等数据积累到一定程度再上路由模型。而且路由模型我倾向用轻量级的，避免推理延迟太大。面试官如果想了解更具体的实验设计，比如怎么确定 α、β、γ 的初始值，我可以展开说说。