核心发现
方法论
论文构建Mastercard内部原型ScaleCall，比较Embedding-based Tool Retriever（ETR）、基于LLM的Tool Retrieval with Re-ranking（TRR）及混合架构。ETR以all-MiniLM-L6-v2离线编码工具、在线编码查询，并按余弦相似度取Top-k；TRR先取Top-10，再由LLaMA 3.1-8B或3.2-3B进行generative listwise重排。评估同时覆盖query-only与query+instruction。
关键结果
- ToolRet复现实验使用观察到的7,961个任务和44,453个工具。加入instruction后，ETR在Code子集的N@10由14.26%升至32.38%，Custom由24.78%升至33.29%，说明查询上下文对工具选择极其关键。
- TRR在研究条件下可改善消歧，但在企业本地部署中频繁遭遇超时和高延迟。以LLaMA 3.1-8B为例，Web的N@10从15.92%升至34.90%；然而运维开销会触发fallback，削弱实际收益。
- 数据集差异明显：Web整体最好，Code最难；LLaMA 3.1-8B在复杂Custom工具上优于3.2-3B。ETR通常更适合大型工具库和低延迟流程，方法不存在跨场景绝对优越性。
研究意义
该研究把工具调用从开放互联网场景推进到受监管金融企业，明确展示准确率、延迟、合规和可运维性之间的真实权衡。它回应了数百个私有API名称相近、文档不统一、权限严格等长期痛点。对学术界而言，论文强调工具检索不是单纯的信息检索问题，而是受领域语义、授权逻辑和基础设施共同影响的系统问题；对产业界而言，研究提供了可部署的选择依据，而非只追求离线排行榜。
技术贡献
ScaleCall将离线工具索引、候选检索、LLM重排、执行门控、权限验证及错误恢复置于可适配架构中。与ToolRet采用的pointwise cross-encoder不同，TRR让LLM联合比较候选工具，捕捉工具间关系。研究还将float32 LayerNorm用于CPU嵌入计算，以提升跨硬件数值稳定性，并以ChatGPT自动语法检查结合领域专家复核，形成面向企业语境的评估流程。
新颖性
核心新意不是提出全新的嵌入模型，而是将ETR、listwise重排及混合策略放入Mastercard监管、本地化环境进行系统比较。相较LangChain、ToolLLM、RankGPT和ToolRet主要关注通用或离线检索，ScaleCall把延迟、超时、fallback、权限与部署合规纳入同一设计视角，揭示算法优劣高度依赖企业领域。
局限性
- 实验模型受许可证、成本、硬件和内部审批限制，仅使用all-MiniLM-L6-v2、LLaMA 3.1-8B与3.2-3B，不能代表所有更强模型。
- 论文报告了TRR的超时和延迟问题，但提供的正文材料未列出完整Table III/IV数值、吞吐量或真实错误率，因而难以复现全面的成本—收益曲线。
- ToolRet与企业内部基准并不完全等价，公开数据中的工具文档和任务分布可能低估真实权限与业务语境复杂度。
未来方向
后续可研究按工具库规模、重叠度和查询类型动态路由ETR/TRR，建立延迟预算感知的级联检索与缓存机制；同时引入权限过滤、审计日志、置信度校准和真实业务成功率。还需在更大企业基准上比较量化模型、专域嵌入、MCP适配及多轮错误恢复。
AI 总览摘要
当金融机构让大型语言模型调用内部API时，问题并不只是“模型会不会调用函数”。数百个私有服务可能名称相近、文档不完整，却拥有不同的授权逻辑、地域限制和业务含义。错误选择可能造成静默失败，甚至违反政策；本地部署又限制了云端模型、硬件和外部服务的使用。
Mastercard团队因此开发ScaleCall，比较三类工具检索策略。Embedding-based Tool Retriever（ETR）使用all-MiniLM-L6-v2计算查询与工具描述的余弦相似度，适合大规模、低延迟检索；Tool Retrieval with Re-ranking（TRR）先取Top-10候选，再由LLaMA 3.1-8B或3.2-3B进行listwise比较。实验基于ToolRet，观察版本含7,961个任务和44,453个工具，并测试只给query与同时提供instruction两种条件。
结果显示，没有一种算法普遍胜出。加入instruction后，ETR在Code上的N@10从14.26%升至32.38%，在Custom上从24.78%升至33.29%；TRR在Web上也取得明显提升，如LLaMA 3.1-8B由15.92%升至34.90%。然而本地部署中的重排经常超时、延迟过高并触发fallback，使离线优势难以转化为生产收益。论文的主要启示是：企业工具调用必须把检索精度、语义消歧、权限验证、合规审计和基础设施稳定性联合设计。ScaleCall的价值正在于这种可配置、面向现实部署的系统视角。
深度分析
研究背景
LLM工具调用已从信息生成扩展到API编排。RAG系统通常用嵌入检索工具，LangChain和OpenAI function calling体现了这一范式；ToolLLM、RankGPT等工作进一步引入LLM重排。但ToolRet显示，面对功能重叠工具时，传统检索仍会失误。金融企业还必须处理本地化、遗留系统、角色权限和监管审计。
核心问题
给定自然语言query、可选instruction和大型工具库，系统需选出正确API，必要时覆盖全部相关工具。难点包括数百个相似名称、领域隐含语义、文档缺失、查询不充分，以及重排模型带来的延迟和超时。错误工具调用不仅降低任务成功率，还可能造成权限违规。
核心创新
- ��ScaleCall：面向Mastercard内部feature-store API和数据工程流程的可部署框架。
- ��方法比较：统一评估ETR、LLM listwise TRR和混合策略，强调领域条件而非算法排名。
- ��评估创新：使用ToolRet、synthetic query、ChatGPT自动检查和专家复核。
- ��工程适配：仅采用获批模型，并以CPU float32 LayerNorm保障数值稳定，结合fallback应对重排故障。
方法详解
- ��输入：ToolRet任务含Query、Instruction、工具名称、描述、输入/输出schema和ground-truth ID。
- ��ETR：工具描述离线嵌入，查询运行时嵌入；用cosine similarity排序并输出Top-k。
- ��TRR：接收ETR的Top-10候选，由LLaMA 3.1-8B或3.2-3B一次性比较候选并重排；这区别于ToolRet的pointwise cross-encoder。
- ��评估：报告P@1、R@1/R@10、P@1/P@10、C@10和nDCG@10。
- ��部署：vLLM服务本地模型，加入合规筛选、权限验证、执行门控和超时fallback。
实验设计
实验覆盖ToolRet的Web、Code、Customized及总体数据，并比较query-only与query+instruction。观察版本含44,453个工具、7,961项任务，其中Web 5,230、Code 1,749、Custom 982。ETR使用all-MiniLM-L6-v2；TRR使用LLaMA 3.1-8B和3.2-3B，候选数k=10。所有CPU LayerNorm嵌入计算采用float32。
结果分析
instruction带来稳定提升：ETR的Code N@10为14.26%→32.38%，Custom为24.78%→33.29%。TRR中LLaMA 3.1-8B平均N@10为13.82%→15.80%；Web为15.92%→34.90%，3.2-3B为14.35%→30.35%。Web最容易，Code最困难；TRR的语义优势受到本地延迟和超时限制。
应用场景
ScaleCall适用于账户聚合、Open Banking API编排、内部feature store查询和数据工程自动化。生产前需准备工具元数据、角色权限、审计日志、隔离执行环境和fallback策略。ETR适合大库实时调用；TRR可用于候选高度相似但风险较高的场景。
局限与展望
结果受模型审批和硬件约束，不能直接外推至更大模型。公开ToolRet不完全反映真实金融权限、司法辖区和业务流程；正文材料也未给出完整延迟、吞吐和表格数据。未来应建立真实任务成功率基准，发展动态路由、缓存、量化模型、权限感知检索和MCP兼容接口。
通俗解读 非专业人士也能看懂
把ScaleCall想成一家大型银行的仓库。客户说“请把这批货送到指定地点”，仓库里有几百个工具：有些负责普通配送，有些只服务某个国家，有些需要特殊许可证，而且货架标签还可能几乎一样。
ETR像一个快速目录管理员：先根据关键词和意思，把最像的十个工具找出来。它速度快，仓库越大越有价值，但可能把两个“看起来相似、实际权限不同”的工具混在一起。TRR像一位经验丰富的主管：他同时比较这十个候选，思考哪个真正符合任务、地区和授权要求，所以更会辨别相似工具。
研究发现，给管理员更多说明很重要。加入instruction后，Code任务的排序指标从14.26%提高到32.38%，Custom任务从24.78%提高到33.29%。但主管需要更多时间；在银行自己的电脑上，他有时会超时。因此最现实的做法不是永远选快的或聪明的，而是按任务风险、工具数量和时间要求灵活组合，并在真正执行前检查许可证。
简单解释 像给14岁少年讲一样
想象你在游戏里对队友说：“帮我打开那个宝箱。”地图上可能有一百个宝箱，其中几个名字都叫“奖励箱”，但有的属于森林关卡，有的属于活动关卡，还有的需要管理员权限。AI如果只看名字，很容易点错。
ScaleCall像一个会分工的游戏助手。ETR先用快速搜索找到最像的十个选项，就像输入关键词后立刻得到搜索结果；TRR再让一个更会推理的AI比较这十个候选，判断任务到底需要哪一个。前者快，后者更会处理“长得像但用途不同”的选项。
研究人员在ToolRet数据集上测试了7,961个任务和44,453个工具。给AI更完整的说明后，Code类别的N@10从14.26%升到32.38%，Custom类别从24.78%升到33.29%。这说明你给队友的任务描述越清楚，选对工具的机会越大！
不过，聪明的检查员也会花时间。在真实的金融机构电脑上，TRR常常延迟或超时，所以系统必须准备备用方案。论文真正想说的是：优秀AI不只要“想得对”，还要“跑得稳、权限正确、过程可追踪”。
术语表
Tool Retrieval（工具检索）
从工具库中为用户请求选出最相关API或函数。它是LLM实际调用工具前的关键步骤。
论文比较ETR、TRR及混合检索。
Embedding-based Retrieval（嵌入检索）
将查询和工具描述转换为向量，再用余弦相似度衡量语义接近程度。它通常速度快，但难处理细粒度功能差异。
ETR采用all-MiniLM-L6-v2。
Listwise Ranking（列表式排序）
模型同时观察一组候选并进行相对排序，而不是逐个独立打分。这样可以利用候选之间的差异。
TRR使用LLaMA进行Top-10联合重排。
nDCG@10
衡量前十个结果排序质量的指标，越相关且排名越靠前，得分越高。它比单纯命中率更关注顺序。
论文用它比较不同数据集和提示条件。
ToolRet
专门评估LLM工具检索的公开基准。它包含Web API、代码函数和自定义工具任务。
ScaleCall以其数据和指标进行复现。
开放问题 这项研究留下的未解疑问
- 1 如何根据工具库规模、功能重叠、风险等级和延迟预算，自动决定使用ETR、TRR还是级联方案，论文尚未给出统一决策模型。
- 2 公开ToolRet指标能否预测真实金融任务成功率仍不明确，需要包含权限、地域限制、审计和多轮恢复的企业级基准。
- 3 MCP如何与遗留API、角色访问控制及本地合规系统稳定结合，仍缺少长期生产证据。
应用场景
近期应用
内部API智能路由
数据工程师可用自然语言描述账户聚合或feature-store任务。系统先用ETR快速缩小候选，再进行权限验证；只有工具高度相似且风险较高时才调用TRR，并设置超时fallback。
Open Banking流程自动化
在调用consent管理和Open Banking API前，ScaleCall可依据业务语境、司法辖区和授权状态筛选相近端点，减少误调用、静默失败和政策违规，同时保留审计记录。
远期愿景
合规的企业代理平台
未来可将动态检索、权限感知规划、沙箱执行、错误恢复和审计统一为可复用平台，支持银行在本地安全运行多步骤代理工作流。
原文摘要
While Large Language Models (LLMs) excel at tool calling, deploying these capabilities in regulated enterprise environments such as fintech presents unique challenges due to on-premises constraints, regulatory compliance requirements, and the need to disambiguate large, functionally overlapping toolsets. In this paper, we present a comprehensive study of tool retrieval methods for enterprise environments through the development and deployment of ScaleCall, a prototype tool-calling framework within Mastercard designed for orchestrating internal APIs and automating data engineering workflows. We systematically evaluate embedding-based retrieval, prompt-based listwise ranking, and hybrid approaches, revealing that method effectiveness depends heavily on domain-specific factors rather than inherent algorithmic superiority. Through empirical investigation on enterprise-derived benchmarks, we find that embedding-based methods offer superior latency for large tool repositories, while listwise ranking provides better disambiguation for overlapping functionalities, with hybrid approaches showing promise in specific contexts. We integrate our findings into ScaleCall's flexible architecture and validate the framework through real-world deployment in Mastercard's regulated environment. Our work provides practical insights into the trade-offs between retrieval accuracy, computational efficiency, and operational requirements, contributing to the understanding of tool-calling system design for enterprise applications in regulated industries.