SAP实验室攻克AI"工具失忆症"：让大模型既会找工具又记得住工具

这项由SAP实验室研究人员共同完成的研究，以预印本形式发布于2026年6月22日，论文编号为arXiv:2607.22639，感兴趣的读者可通过该编号查询完整论文。

当一家拥有近四万月活跃用户的企业AI助手，有六成的错误都源于"找错了工具"，这个问题就不再是技术细节，而是真实影响数万人工作效率的头等大事。SAP实验室的研究团队正是从这个痛点出发，打造了一套名为TRACE的训练方案，试图从根本上解决企业AI系统在海量工具库中"认错门"的老毛病。

一、"找工具"这件事，为什么难得出乎意料

在我们日常使用手机的经验里，找一个App并不难——图标长得不一样，名字也各有特色。但对于一个企业级AI助手来说，它面对的是超过八千个功能各异的内部工具接口，而且其中很多工具的名字和描述看起来几乎一模一样，好比一排外观相同的钥匙，你却要在几秒内找出那把唯一能开门的。

SAP的研究团队分析了609个真实用户会话后发现，约82%的工具检索失败，都发生在那些"长得太像"的工具之间。这些工具需要靠企业内部的业务规则才能区分，比如某个API在2024年之后就被新版本取代了，但新旧两个接口的描述文字几乎没有区别，普通的语义匹配方式根本无从分辨。

目前主流的方案是用"嵌入式检索"——把每个工具的描述变成数学向量，再把用户的问题也变成向量，找距离最近的那个。这种方式在小规模场景下还算好用，但在八千多个高度相似的企业工具面前，它的召回率只有可怜的27%左右，也就是说十次里有七次多都会拿错。更要命的是，这种方式永远不会真正"记住"这些工具的含义，只是在做表面相似度的比较。

另一种思路来自ToolGen这一较早的研究——让大语言模型直接把每个工具记在心里，给每个工具分配一个独特的"虚拟令牌"（可以理解为一个独有的暗号），然后训练模型在用户提问时直接生成对应的暗号。这个方法在某些公开数据集上能达到90%以上的召回率，听起来很美好。

但是ToolSense这一诊断框架的研究发现了一个严重问题：当你用这种方式训练模型去"找工具"时，模型原本对工具含义的理解会被大量覆盖甚至彻底抹除。好比你雇了一个博学的图书管理员，专门教他记住每本书放在哪个书架——结果他把书架位置倒是背得滚瓜烂熟，却完全忘记了每本书写的是什么内容。检索能力有了，理解能力没了，这就是研究者所说的"知识-检索解耦"现象。

TRACE正是为了同时解决这两个问题而生的。

二、给AI助手装上"边查边想"的能力

TRACE这个名字是"通过增强思维链和企业规则进行工具检索"的英文缩写，它的核心理念用一句话来说就是：先想清楚再回答，而不是直接蒙一个。

整个训练过程分为两个阶段，可以用学生备考来类比。第一阶段是"死记硬背打基础"，第二阶段是"理解+推理做综合题"。

第一阶段沿用了ToolSense框架中的"多格式记忆"方案。训练并不只是简单地告诉模型"这个描述对应这个工具"，而是从多个角度反复强化记忆。一方面，模型要能根据工具描述说出对应的虚拟暗号；另一方面，它还要能根据暗号反推出工具描述；此外还有一种"多选题"练习，给出一个工具描述和若干个相似工具的暗号，让模型选出正确的那个。这三种练习方式相互配合，确保模型不会只记住表面符号，而是真正把描述和暗号绑定在一起。

之所以用LoRA这种"轻量微调"方式而不是全量更新模型参数，是因为研究表明LoRA能在训练新任务的同时，更好地保留模型原有的知识，就像在原有书本上贴便利贴，而不是直接在书页上涂改。

第二阶段才是TRACE真正的创新所在。这个阶段要训练模型在给出工具答案之前，先生成一段"思考轨迹"——就像侦探在宣布嫌疑人之前，要把推理过程完整说出来一样。这段推理不是摆样子的，它要真正起到引导模型做出正确判断的作用。

三、精心设计的"侦探培训数据"

为了训练模型学会这种"推理后再检索"的能力，研究团队需要大量高质量的训练样本，而且每个样本都必须包含完整的推理过程。

样本的来源分为两条线。第一条线是从工具库本身出发，针对每个工具找出它最容易被混淆的"近亲"工具，然后生成三种难度的用户问题：简单的只需要一个工具就能回答，中等难度需要两三个工具配合，困难级别则需要更多工具或者问题本身表述模糊。这种分级设计是为了让模型接触到真实用户提问时可能出现的各种模糊程度。

第二条线则更具企业特色：利用由领域专家手工整理的123条业务规则。这些规则相当于企业内部的"秘密手册"，记录着那些从工具描述文字里根本看不出来的区分方法。比如同一个API下有四个端点，光看名字差不多，但规则规定：查当前状态用A端点，查历史记录用B端点，查明细数据用C端点，其余情况用D端点。研究团队以每条规则为中心，针对"规则中涉及的工具集合"生成三种类型的问题：显式的（问题里有明显线索直接触发规则）、隐式的（需要从上下文推断规则适用）、边界例外的（乍看应该用主要工具，但仔细一想边界情况应该转向其他工具）。这三种问题类型共同覆盖了真实业务场景中规则被触发的各种方式。

有了问题和答案之后，还需要生成配套的"侦探推理过程"。研究团队使用另一个大型语言模型作为"教师"，按照固定的推理框架来生成这段思考轨迹：第一步，梳理用户的访问权限范围，排除用户无权使用的工具；第二步，从语义层面分析哪些工具最相关，先比较整体API服务，再聚焦到具体接口；第三步，如果有业务规则适用，必须在推理中明确引用该规则的内容；第四步，给出最终答案。

在这整个推理过程中，有一个关键细节：工具的名字全部被替换成对应的虚拟暗号。这意味着模型在学习推理的同时，也在持续加深对"暗号←→工具含义"这种绑定关系的认识，让第一阶段建立的记忆不会因为第二阶段的训练而被冲淡。

生成的每条样本还要经过严格的质量检查：答案里的工具必须来自预定的候选池，不能凭空捏造；问题里不能直接出现工具名字（否则就是提前剧透，失去了测试的意义）；答案格式必须规范；对于规则类样本，推理过程里必须明确引用规则内容。通不过程序检查的，还要再经过一个AI评审员打分，评判问题是否自然、推理是否真实有效、答案是否正确。不合格的样本会被退回重新生成，重试五次还不行就直接丢弃。

四、"单束贪心解码"：从实验室走向生产环境的关键一跳

ToolGen那种基于前缀树的"约束束搜索"方法在准确率上表现不错，但速度实在太慢——处理一个用户问题需要约19秒，而且随着并发用户增加，吞吐量几乎不会提升。在真实的企业生产环境里，这个速度根本无法接受。

TRACE采用了完全不同的推理方式：单束贪心解码。用更直白的话来说，就是模型从左到右一个字一个字地输出，不做任何回溯或多路并行搜索。它先输出一段推理思考内容，再输出一个JSON格式的工具令牌列表，就这样一次搞定。

这样做的前提是模型已经通过两阶段训练，把工具知识和推理能力都内化进了参数里，所以它能够在自由生成的过程中自然而然地产出有效的工具暗号，而不需要靠外部的约束机制来"保驾护航"。实测下来，出现无效工具暗号的比例只有3%，完全在可接受范围内。

速度上的差距非常悬殊：在同一台GPU服务器上，推理版TRACE每个用户问题只需约1.9秒，而约束束搜索需要约19秒，足足慢了10倍；当同时有32个用户并发使用时，推理版能稳定处理每秒11.2个请求，而约束束搜索只有每秒0.05个请求，差距约200倍。这意味着TRACE可以真正部署到企业级生产系统中，而不是只能在实验室里运行。

五、实验数据说话：知识保留与检索性能双双提升

研究团队在包含8283个工具的企业级目录上进行了全面测试，工具来自两个业务领域——Domain A是HR领域（918个工具），Domain B是财务领域（7365个工具）。

知识保留方面的测试结果非常清晰。非推理式检索训练（也就是ToolGen那种方式）会让模型在多选题测试中的准确率跌到接近随机猜测的水平——对于四选一的题目，随机猜对率是25%，而非推理训练后的模型得分也差不多就是这个水平，几乎等于什么都不记得了。推理式训练不仅能把这个准确率拉回来，甚至还能比不做第二阶段训练时更高，原因是推理过程本身就在反复强化模型对工具含义的理解。

在由领域专家手工制作的454道专业多选题（MCQexpert）上，这种差异更加突出：不做检索训练时基础准确率是69.2%，非推理检索训练之后跌到33.7%（基本等于随机），而TRACE的推理检索训练能达到61.5%，加上业务规则训练后是56.4%。规则训练带来了一定的"知识代价"（下降约5个百分点），这是因为规则训练数据更专注于特定工具的细粒度区分，对一般性领域知识关注度减少了，但这个代价相当有限，远没有抹掉推理训练带来的知识保留优势。

检索性能方面，TRACE与基线方法的对比同样令人信服。纯嵌入式检索（text-embedding-3-large）在Domain A的top-10召回率只有27.5%，在Domain B是52.7%。TRACE在不使用约束搜索、只用单束贪心解码的情况下，Domain A能达到85.5%的召回率，Domain B是60.2%。

Domain B的召回率偏低有其原因：该领域的123条业务规则中，只有103条覆盖了Domain B，但Domain B有7365个工具，规则覆盖密度远不如Domain A（918个工具配了20条规则）。对于规则覆盖到的那部分工具，召回率能达到很高水平；但对于规则尚未覆盖的大片工具，模型还是只能依靠语义推理，效果自然打折扣。研究团队通过消融实验验证了这一点：当使用不区分域的扁平令牌格式时，增加规则数据对Domain B不仅没有损害，反而略有提升（62.6%→64.2%），说明问题出在规则覆盖不足，而非方法本身有缺陷。

六、规则数量与知识保留之间的微妙平衡

研究团队做了一组专门的消融实验，系统地测试了规则数据量对性能的影响。从每条规则生成0个训练样本，一路增加到12个，再到用规则样本完全替代原有的普通检索训练样本。

对于Domain A，随着规则样本数量增加，检索召回率从55.7%一路爬升到73.3%，完全替换策略下更是达到86.3%，提升了超过30个百分点。这说明业务规则数据对于高相似度工具的区分能力至关重要。

与此同时，专家多选题准确率从59.5%缓慢下滑到55.7%，整个区间内只损失了不到4个百分点。而且这种下降主要体现在通用领域知识上，针对工具本身的理解测试（MCQts和QAts）在统计上没有显著变化。

研究团队还做了一项有趣的验证：分析模型在回答问题时生成的推理轨迹，统计其中引用业务规则的比例。规则训练后，71%的推理轨迹主动引用了相关业务规则；在引用了规则的那些推理轨迹中，最终检索正确率高达94.6%；而没有引用规则的推理轨迹，正确率只有63.2%。这组数据说明模型并不是死记硬背了规则和答案的对应关系，而是真的在推理过程中用上了这些规则。

七、三种令牌格式的全面验证

不同的工具命名方式会影响训练效果，研究团队测试了三种令牌格式。扁平格式只用单一暗号代表整个工具（例如用一个整体标记表示WeatherAPI/GetForecast），裸层级格式把API和端点分成两个独立的暗号，包裹层级格式则在层级结构外面再套一层标记符。

三种格式在非推理训练下都呈现出同样的知识崩塌现象，证明这个问题不是某个特定命名方式导致的，而是非推理检索训练本身的固有缺陷。推理训练也在三种格式下都能有效恢复知识，但包裹层级格式在不做检索训练时的基础知识准确率最高（69.2%），论文主体因此选用这种格式展示主要结果。

裸层级格式表现相对最弱，在各项指标上都落后约10个百分点。这可能是因为两个分离的令牌之间的绑定关系更难建立，导致模型更难同时记住API层和端点层的含义。

另一个值得关注的发现是"亡羊补牢"式训练的局限性。研究团队尝试先用非推理方式训练，再叠加推理训练，结果发现这种补救效果因格式而异。对于扁平格式，补救训练能部分恢复知识（专家多选题准确率从34.8%提升到49.8%），但仍然远低于一开始就做推理训练的水平（59.5%）。对于两种层级格式，补救训练几乎没有效果，准确率依然停留在随机猜测附近。这说明非推理检索训练造成的损伤，对于结构更复杂的令牌格式是几乎不可逆的，从一开始就选择推理训练路线才是正确的。

归根结底，TRACE想解决的是一个听起来很技术性但实际上非常朴实的问题：怎样让一个AI助手在记住几千个工具怎么用的同时，也能快速准确地找到正确的那一个？传统方案只能二选一——要么记得住但找得慢（约束束搜索），要么找得快但忘了含义（非推理检索训练），或者压根找不准（纯嵌入式检索）。TRACE给出的答案是：让模型养成"边推理边检索"的习惯，同时把企业内部那些只有专家才知道的业务规则也教给它。

这套方案在SAP自己的生产系统里对应的现实意义相当直接：一个服务近四万用户的企业AI助手，如果能把工具检索错误率大幅降低，就意味着每天有更多员工能得到准确的回答，而不是被一个找错了门的AI助手耽误时间。随着越来越多的企业开始构建自己的AI助手系统，"工具库规模增大后如何保持高准确率"这个问题会越来越普遍，TRACE提供了一条经过实际验证的路径。

当然，这项研究也坦承了若干边界：目前只在HR和财务两个领域、单一模型规模上做了验证，更大的模型或其他行业领域是否同样有效还需要进一步探索。财务领域因为规则覆盖密度不够，召回率还有明显提升空间——研究者指出，每条规则至少需要约6个训练样本才能显现效果，这个"足够密"的标准目前还是经验判断而非精确公式。此外，目前的123条业务规则全部依赖领域专家手工撰写，自动化提取规则的可行性尚未被验证。

对于未来有志于做企业AI系统的研究者或工程师来说，一个值得深想的问题是：在你自己的业务场景中，有多少这样的"隐性知识"——那些从产品文档里完全看不出来、但每个资深员工都心知肚明的规则——正在悄悄拖累你的AI系统的准确率？也许把这些规则整理出来，才是提升AI助手能力最直接、最有效的路径。如果想深入了解TRACE的技术细节，可以通过arXiv编号2607.22639查阅完整论文。

Q&A

Q1：TRACE方法为什么不直接用嵌入式检索，而要专门训练模型记住工具？

A：嵌入式检索只做语义相似度匹配，在工具描述高度相似的企业场景里，召回率只有27%左右，而且它无法利用企业内部的业务规则来区分相似工具。TRACE让模型把工具知识记在参数里，并在推理时引用业务规则，Domain A的召回率因此能达到约86%。

Q2：TRACE的业务规则训练会不会让模型忘掉其他通用知识？

A：会有轻微影响。专家多选题准确率从约59.5%下降到约55.7%，损失不到4个百分点。但针对工具本身理解的测试（工具多选题和判断题）在统计上没有显著变化，这个代价相对于检索性能提升超30个百分点来说是可接受的。

Q3：TRACE部署时推理速度有多快？

A：单束贪心解码模式下，一个用户问题约1.9秒就能得到答案，32个用户并发时每秒能处理11.2个请求。相比之下，ToolGen使用的约束束搜索需要约19秒，并发32时每秒只能处理0.05个请求，两者吞吐量相差约200倍。