TRACE: Business Rule-Grounded Reasoning Curriculum for Knowledge-Preserving Parametric Tool Retrieval in Enterprise LLMs
Sai Shruthi Sistla, Ashutosh Hathidara, Christopher Toukmaji, Mayank Shrivastava, Karthikeyan Asokkumar
cs.AI
2026-06-23
TRACE 给参数化工具检索加一条规则接地的推理链,A 域召回从嵌入基线 27% 提到 86%,并用单束贪心解码换掉束搜索,吞吐约 200 倍。
企业里的 LLM 助手要把用户的话路由到正确的 API,而 API 动辄几千个。基于嵌入的检索(对工具描述做向量相似度)是主流,但作者在 SAP 的生产数据(约 3.9 万月活)里发现,它占了约 60% 的「选错工具」错误。更糟的是,这些错误里约 81.7% 牵涉到 10 个以上语义高度重叠的工具,得靠业务规则(API 弃用、版本变更、领域路由)才能区分,而规则是嵌入模型抓不到的。
参数化检索(ToolGen / ToolSense)本来是想解决这个的:给每个工具一个唯一虚拟 token(如 «WeatherAPI/GetForecast»),训练模型直接生成它。但 ToolSense 暴露了两个毛病:检索训练目标会把模型原有的工具知识灾难性地冲掉,而且受限束搜索的解码慢到没法实时上线。要么检索准但忘了工具,要么懂工具但没法部署。TRACE 就是来同时修这两个的。
两阶段课程,在 Gemma4-E4B-it 上用 LoRA(r=64, α=128)训练,工具目录共 8,283 个(A 域 HR 918 个,B 域 Finance 7,365 个)。
第一阶段:多格式记忆 SFT(沿用 ToolSense 的配方),用 LoRA 把参数化工具知识种回去。训练 desc→虚拟 token 和反向映射,外加一个 MCTS 目标。选 LoRA 是因为它比全量微调遗忘得少。
第二阶段(核心贡献):推理增强检索。训练模型在产出 JSON 工具 token 列表之前,先吐一段思考轨迹。两个数据来源:ToolSense 的 RRB(现实检索基准)对,以及针对 123 条领域专家整理的业务规则合成的查询(混淆工具集 + 自然语言消歧规则,配难负样本池和易/中/难分级,再用程序过滤和 LLM judge 校验)。
为什么要先吐轨迹:让模型在 commit 到某个 token 之前先想清楚适用哪条规则,而且因为没直接重训检索目标,第一阶段的知识保住了。更关键的是,先吐轨迹 + JSON,就能扔掉受限束搜索,改用普通贪心单束解码,快到能上线。
Stage 2 的模式记成 R 轴:∅ 无、n 非推理、r 推理、R 规则数据,作者做了消融。
知识保留(MCQexpert 探针,随机基线 29.3%):∅ 拿到 69.2,n 掉到 33.7,r 回到 61.5,r+R 是 56.4。非推理检索(n)把工具知识冲到接近随机,加上推理轨迹(r)又拉回 61.5,说明保住知识的是那条轨迹。第二阶段还顺手超过第一阶段:MCQ +3.2 个点,QA 探针 +9 个点。
检索(单束贪心 R@gen):
| A 域 | B 域 | |
| 嵌入(text-embedding-3-large) | 27.5% | 52.7% |
| TRACE(c, m, r+R) | 85.5% | 60.2% |
规则接地有用:A 域从每规则 0 条查询的 55.7% 涨到 12 条查询的 73.3%。引用了规则的轨迹召回 94.6%,没引用的只有 63.2%,只要轨迹真的请出一条规则,几乎总是对的。
延迟:单束自由解码约 1.9 秒,受限束-10 约 19 秒(单用户);并发 32 时 11.2 qps 对 0.05 qps,约 200 倍吞吐。这是能部署的那一下。
对企业 LLM 的建设者:一套让参数化工具检索既准又实时的具体配方,这是上一代(ToolSense)做不到的。两个值得偷的点,哪怕不在一模一样的场景:推理轨迹放在工具 token 之前,能保住被裸检索训练冲掉的知识;这条轨迹换来贪心解码代替束搜索,延迟从没法用到能上线。规则接地的数据合成(混淆集 + 专家规则 + 难负样本)对任何「在重叠工具里做检索」的问题都能搬。
得说清:这是篇工业界的论文,跑在拿不到的 SAP 私有目录上,还建在一个本身匿名、疑似在审的 ToolSense 上。所以它是一份配方和一份内部数据上的结果,不是你能复现的 benchmark。