首页 > 教程攻略 > ai资讯 >xLAM: 一个赋能AI agent系统的动作大模型家族

xLAM: 一个赋能AI agent系统的动作大模型家族

来源:互联网 时间:2026-08-27 14:10:02

论文标题:xLAM: A Family of Large Action Models to Empower AI Agent Systems
论文链接:https://arxiv.org/pdf/2409.03215
模型地址:https://huggingface.co/collections/Salesforce/xlam-models-65f00e2a0a63bbcd1c2dade4
GitHub 仓库:https://github.com/SalesforceAIResearch/xLAM

先说说几个核心判断。这篇论文介绍了 xLAM 系列——一组专为自主 AI Agent 设计的大型动作模型,参数规模从 1B 一路拉到 8x22B。背后的训练秘诀,是一条可扩展、且相当灵活的数据流水线,专门用来统一、增强和合成各类数据集。

这套多样化的模型阵容,定位也很清晰:1B 和 7B 的小模型主攻设备端部署,8x7B 和 8x22B 的大模型则负责更硬核的任务。除了发布模型本身,论文还从 Agent 模型训练的一线经验中,提炼出了几个值得关注的洞察和教训:

  • 数据处理:

    核心强调数据统一和增强在提升多样性、缓解过拟合方面的关键作用。他们开发的预处理和增强流水线,显著提升了 Agent 模型在不同环境下的泛化能力。
  • 数据合成:

    展示了可扩展且高质量的数据合成对 Agent 模型性能的强大影响。合成的数据集帮助 xLAM 模型在 Berkeley Function Calling Leaderboard 上直接拿下了前 20 名中的 4 个席位,其中还包括了榜首位置。尤其值得留意的是,一些较小的模型凭借合成数据,实现了与更大模型相当的表现,潜力巨大。

论文在公开的 Agent 基准上对 xLAM 系列进行了全面评估,结果在各类 Agent 任务中表现亮眼。通过开源这些模型,团队希望能推动开源 Agent 模型的发展,同时分享在数据处理和合成技术上的宝贵经验,为解决开发能与专有模型抗衡的替代方案这一关键难题,提供一些实在的思路。

一、论文的简单介绍

1.1 论文的背景

自主 Agent 领域这几年进展飞快,大型语言模型(LLMs)在其中扮演的角色越来越重要。研究人员在开发复杂框架和专用环境方面取得了重大进展,极大增强了 Agent 的能力,比如工具使用和网络浏览。与此同时,像 AgentBench、ToolBench、AgentBoard 这样的综合性基准也陆续建立起来,用来严格评估 Agent 在推理、规划和多轮交互中的表现。

不过,虽然行业巨头开发的专有 LLMs 在各类 Agent 任务中表现出了强劲的竞争力,但开源社区在专用模型这一块的选择却少得可怜。这种稀缺性背后,是让开源 LLMs 适应 Agent 任务时所面临的几个现实挑战,核心问题在于:缺乏全面、高质量的数据集,以及现有数据格式的“各自为政”。这些因素让多样化数据集的统一变得异常复杂,也阻碍了跨任务可迁移知识的习得。

最近,Agent 研究社区已经开始在开源 Agent 数据处理和模型训练上加码。然而,这些努力在管理复杂环境和泛化到新场景时,仍然面临不小的困难,根源还是在于收集到的 Agent 数据本身存在局限。一个主要障碍是现有数据集中内容和格式的“同质化”——这直接导致模型在各种任务中缺乏多样性,且在实际应用中很难适应新的或略有变化的数据结构。虽然之前也有人尝试设计统一数据管道,但大多只覆盖了少数场景,或者统一格式的灵活性不够。比如,Lumos 主要处理的是问答、网页 Agent 以及涉及规划和基础能力的数学任务;而 AgentOhana 虽然覆盖了更多样的环境,但其统一格式缺乏扩展性,难以引入新环境。

此外,开源数据集还普遍存在质量问题,比如 Agent 输出错误、幻觉动作,以及轨迹中反复出现的对话轮次。对 Agent 数据缺乏深入的分析和理解,更是加剧了这些挑战,阻碍了稳健且多功能的开源 Agent 模型的开发。解决这些问题,对于推动开源 Agent 模型的发展、缩小与专有 LLMs 在 Agent 任务上的性能差距,至关重要。

图1:xLAM 数据处理、训练和评估的总体思路。团队根据模型评估结果的诊断反馈,迭代改进数据质量。

图2:xLAM 模型在 Berkeley Function Calling Leaderboard v2(截止 2024 年 9 月 3 日)上的表现。8x22b 模型以明显优势位居榜首。

1.2 数据处理流水线

接下来,我们重点看看训练 xLAM 的数据流水线,包括数据统一、增强、质量验证、通用指令数据合成和偏好数据生成这几个环节。

1.2.1 数据统一

现有的 Agent 数据集来自不同的环境,格式五花八门,这本身就引入了噪声,也让数据增强和验证变得更复杂。像 NexusRa ven、Gorilla-Openfunctions 和 AgentOhana 这些模型在函数调用上的成功说明,一个定义良好的通用格式,能显著提升模型性能。通过标准化现有数据的格式,可以有效减少噪声,并让数据增强和质量验证变得更简单,从而构建一个更高效、更稳健的模型训练和评估框架。更重要的是,标准化的格式确保了一致性,简化了训练过程,也增强了模型跨不同基准的泛化能力。

函数调用格式是模型理解和执行任务的基础,因此论文以函数调用为风格设计了统一的数据格式。这个统一格式由几个模块组成:任务指令、可用工具、格式指令、少样本示例、查询和步骤序列。具体来说,“可用工具”定义了 Agent 的动作空间,“格式指令”指定了模型在生成响应时应遵循的输出格式。在每个步骤中,Agent 的输出、环境的反馈(执行结果)以及用户的后续输入,会被组织成一个字典。当然,用户与 Agent 之间纯粹的对话交互也很常见,这种交互不会触发任何 API 调用,也不会收到相应的观察结果。在这种情况下,相关条目的值会保持为空。

这种统一格式能够兼容各种环境和任务,使得数据处理流程可以适配不同的数据集并扩展到海量数据。此外,模块化设计还允许进行细粒度的数据增强和质量验证,这对提高 Agent 数据质量至关重要。举个例子,通过统一所有可用工具和工具调用,可以轻松检查幻觉和函数调用错误,并应用各种增强技术。

1.2.2 数据增强

数据增强策略的核心,是提高数据的多样性。通过对现有数据集应用各种变换,生成新的合成数据样本。数据统一这一步,大大简化了各种增强技术的应用。标准化的数据格式确保了一致性和易于实现,让增强过程更高效。具体来说,采用的增强技术可以分为两大类:提示格式增强和指令遵循增强。

提示格式增强:

这部分主要专注于基于结构化、统一的数据格式,创建各种灵活的提示格式。格式增强又可以细分为两类:

  • 顺序打乱:

    在统一格式中,可用工具以列表形式提供,每个工具包含名称、描述和参数。为了避免模型对工具的特定顺序产生过拟合,团队会随机打乱工具列表。此外,还会打乱名称、描述、参数的顺序,以及参数内部的顺序,以不同的方式呈现信息。在每一步的工具调用中,也采用了同样的策略。甚至还会打乱输入中不同部分的顺序,比如任务指令、工具、格式指令、少样本示例等。
  • 连接符:

    每个训练数据点都是一对输入和输出序列。为了将结构化的统一格式转换为训练提示,需要使用特殊符号将不同部分连接成一个序列。团队创建了多种不同的特殊符号样式,包括 "ISTART/END OF QUERY]","" 和纯文本。

指令遵循增强:

这一部分专注于增加指令的多样性,以提升模型的指令遵循能力。具体操作包括重新表述现有指令和添加新指令,同时确保不会引入不准确和不一致。因此,新指令的验证是这种增强方式的关键步骤。团队采用了两种方法进行指令遵循增强:

  • 任务指令重新表述:

    使用强大的 LLM 重新表述任务指令,以适应不同的用户输入风格。为了确保重新表述的指令与原始版本一致,会通过使用重新表述的指令提示 LLM,并检查 LLM 是否仍能遵循它们并生成正确的函数调用,来进行验证。
  • 格式指令遵循:

    在统一格式中,输出格式是一个包含思考和工具调用的 JSON 字符串。为了避免模型对 JSON 格式产生过拟合,并使其能够根据不同的格式指令遵循各种输出格式,团队准备了 15 种不同的输出格式及其相应的格式指令和格式转换器。输出格式包括 JSON、XML、YAML、纯文本等。

1.2.3 数据质量验证

为了更深入地了解数据质量并彻底排查评估中的错误来源,团队对统一数据集进行了详细分析。他们使用基于规则的方法和 LLM 作为评判标准,识别出了数据中的一系列错误。

  • 未定义函数调用:

    在函数调用场景中,会提供一组可用函数,模型应使用其中之一生成函数调用。然而,他们发现很多情况下,预测的函数调用并不在给定的列表中。通过比较函数名称和参数名称列表,可以匹配预测的函数与给定的函数。当函数调用名称与任何给定函数不匹配时,被视为“未定义函数调用”。当函数名称匹配但参数列表包含未定义参数时,则被视为“未定义参数传递”。当然,也需要考虑可选参数的情况。
  • 参数类型错误:

    除了上述错误,他们还观察到,有时模型生成了正确的参数值,但类型却是错的。例如,当参数期望 [val1, val2, val3] 时,生成的参数是 "[val1, val2, val3]",这是列表的字符串版本。在执行函数调用时,由于数据类型不正确,就会报错。通过比较可用工具中的参数类型和实际参数类型,可以识别出包含参数类型错误的轨迹。值得注意的是,大多数参数类型错误可以通过将参数转换为正确的参数类型来修复。
  • 参数幻觉:

    在检查来自公开来源的统一数据集时,他们发现工具调用中经常包含用户查询或先前步骤中不存在的参数值。这个问题出现的原因在于,这些数据大部分是由容易产生幻觉的 LLMs 生成的,这也是 LLM 生成内容中的一个常见顽疾。团队识别出了两种类型的幻觉:第一,生成的工具名称或参数名称并未出现在提供的工具和参数列表中;第二,参数值与用户查询或先前步骤的观察结果不一致。第一种幻觉的检测相对容易,通过搜索生成的工具调用和参数名称并与提供的工具列表进行匹配即可,因为它们都是以 JSON 结构化的。然而,检测第二种幻觉(参数值不一致)要困难得多,简单的字符串匹配对复杂的查询和任务无效。为了解决这个问题,他们使用 LLMs 作为判断者,进行逐步的参数幻觉检测,找出参数与预期查询或先前观察之间的不匹配。
  • 低质量推理和规划:

    他们还观察到,许多数据轨迹中的推理和规划步骤质量较低,这也是许多 LLM 输出的常见问题。为了解决这个问题,团队首先使用基于启发式的规则方法过滤掉低质量数据,然后提示 Mixtral-8x22b-Instruct-v0.1 和 DeepSeek-V2 等模型对选定数据的整体轨迹和单个思维步骤进行评估。其中一部分评级结果会被抽样出来,由人工进行验证。他们还尝试使用专门微调的模型来迭代优化这一过程。

1.2.4 数据合成

团队注意到,大多数公开可用的数据集存在几个共性局限。首先,这些数据集通常是静态的,由较弱的模型合成,范围有限,更关键的是,它们没有经过执行验证。其次,这些数据集主要集中在单一类型的函数调用类别,即基于提供的工具输出单个函数调用。然而,现实世界的场景可能包含许多其他类型的用例,比如并行函数调用——用户查询包含多个请求,模型需要在单次响应中并行处理这些并发函数调用。

为了解决这两个问题,团队采用了一个名为 APIGen 的系统化数据合成框架。该框架能够根据一组可执行的 API,生成可验证的数据集。其核心理念是一个多阶段的验证过程,以确保生成数据的高准确性和质量。这个过程包括格式验证(如前所述)、执行验证和语义验证。这三道关卡共同协作,能有效识别并过滤掉低质量的数据点,比如那些存在幻觉问题或参数值不准确的数据。

团队利用 ToolBench 中的 21 个类别、共 3,673 个 API,生成了总计 60,000 条高质量数据。这些样本由多个强大的开源语言模型生成,包括 DeepSeek-V2-Chat 和 Mixtral-8x22B-Inst。这个合成框架极大地提高了数据集的鲁棒性和实用性,因为大多数低质量数据都能被多阶段验证过程识别出来。

1.2.5 数据混合

对于有监督微调(SFT)阶段,训练数据集由三个主要来源的样本混合而成:经过清洗和增强的 Agent 数据集、合成函数调用数据集,以及通用指令微调数据集。这些来源共同用于训练通用的 xLAM 模型。

具体来说,为了增强 xLAM 的通用指令能力,团队整合了来自 DialogStudio 和 Data Provenance 的多样化指令调优数据集。他们采用基于规则的技术过滤掉低质量数据,比如重复的词语和对话轮次(这些常见于较弱模型生成的内容)。同时,移除了包含不当内容、响应和非商业许可的数据。此外,还对相似的用户查询进行了去重,并按领域或类别组织数据。随后,团队提示 Mixtral-8x22b-Instruct-v0.1 和 DeepSeek-V2 对所选数据中的整个对话和单个系统响应进行评估。这部分指令数据约占训练集的 20% 到 30%。为了进一步增强模型的鲁棒性,他们还保留了通用指令调优数据的原始格式。

为了增强 xLAM-7b-fc-r 和 xLAM-1b-fc-r 的功能调用能力,团队采用了针对性的训练方法:其中 50% 的训练数据来自他们高质量的合成功能调用数据集,其余 50% 则从训练集中的其他任务中采样。

对于直接偏好优化(DPO),团队提示较弱的模型为每个来源的选定数据生成和评分响应,然后抽取子集进行人工验证。在对模型和提示进行调整后,他们将选定的响应分类为被拒绝的样本。

1.3 模型训练

1.3.1 建模

团队采用监督微调(SFT)方法,并配合 DPO 方法对模型检查点进行进一步对齐,同时充分利用了灵活数据管道的鲁棒性。训练代码基于 HuggingFace Transformers、Accelerate 库以及 PyTorch FSDP。在训练过程中,模型会经历多个 epoch,每次数据集都会随机打乱。在使用多设备数据并行时,他们根据进程 ID 多样化随机种子,通过分区、打乱和交错确保数据分布均衡,从而增强了训练过程的鲁棒性和可重复性。

通用 xLAM 模型的微调在 Nvidia H100 GPU 上进行。对于 SFT,团队使用了全微调框架,采用完全分片数据并行算法。在 xLAM-8x22b-r 的情况下,他们整合了 LoRA,以更好地保留模型的原始能力并防止灾难性遗忘。LoRA 也用于所有 xLAM 模型的 DPO 对齐。此外,他们还使用了带有 100 个预热步数的余弦学习率调度器来优化性能。

xLAM-FC 模型针对不同类别的函数调用 Agent 进行了优化,包括简单、多重、并行和并行多重。这些类别旨在增强模型在不同应用场景下的性能。举个例子,一个简单的查询(如“今天帕洛阿尔托的天气如何?”)可以通过调用 get_weather("Palo Alto", "today") 来处理。多重查询涉及从多个 API 中选择适当的函数,而并行查询则需要同时执行多个函数调用。此外,模型还在相关性检测方面进行了训练,以确保函数调用、执行结果与查询目标之间的一致性。

表1:xLAM 模型系列概览。

1.3.2 xLAM 模型系列

团队推出了一系列针对不同用例定制的 Agent 模型。旗舰模型系列 xLAM 基于 Mixtral Instruct 模型构建,旨在多样化的 Agent 任务中实现平衡性能,从复杂的多轮交互到函数调用应用。为了确保其多功能性,xLAM 在从训练数据集中均匀采样的数据上进行了训练。

除了通用的 xLAM 模型,团队还基于 DeepSeek-Coder-7B-instruct-v1.5 和 DeepSeek-Coder-1.3B-instruct 分别开发了两个专门用于函数调用用例的模型:xLAM-7b-fc-r 和 xLAM-1b-fc-r。较小的模型尺寸提供了更高的可访问性,让用户能够轻松地在单个 GPU 上托管它们,用于解决各种函数调用任务——从简单的用户查询到并发的并行请求。

通过提供一系列不同尺寸和专业化的模型,xLAM 系列满足了从个人开发者到大型企业的广泛需求和计算资源限制,让强大的 Agent 能力变得更加易得,也更容易适应实际应用。

1.4 实验

1.4.1 基准测试

在考虑了环境的稳定性和研究预算限制后,团队在四个严格的基准测试中评估了模型性能:Webshop、ToolQuery、ToolBench 和 Berkeley 函数调用基准测试。每个基准测试都旨在评估模型在不同设置和约束下的不同能力。

  • Webshop:

    一个交互式网络环境,旨在模拟在线购物体验,测试 Agent 在电子商务任务中的导航和协助能力。包含大约 250 个测试用例。
  • ToolQuery:

    评估 Agent 在跨领域使用工具检索和处理信息的能力。提供了 60 个测试用例,分布在三个不同的设置中:天气、电影和学术。

团队使用 AgentBoard 的测试配置来评估 Webshop 和 ToolQuery。这些配置通过成功率和进展率来评估整体性能,其中成功率是更为关键的指标。

他们还评估了 ToolQuery-Unified:这本质上就是 ToolQuery,但要求 Agent 按照增强提示格式(见 1.2.2 节)摄取任务指令和工具,并按照统一格式解决任务。在这种设置下测试 Agent 的目的是评估其在结构化格式上的推理和工具使用能力。

  • ToolBench:

    专门为通过 RapidAPI 实时评估多轮推理和交互能力而开发,包含约 1,000 个测试用例。它使用通过率作为指标:轨迹和最终响应会被发送给 GPT-4-0125-preview,由其判断 Agent 的最终响应是否成功解决了给定的用户查询。评估涵盖了领域内和领域外的设置,包括:用熟悉的工具处理不熟悉的指令、在先前已知的类别中使用未见过的工具,以及完全全新的、未见过的工具类别。
  • Berkeley Function-Calling Leaderboard (BFCL) Benchmark:

    提供了一个全面的评估框架,用于评估 Agent 在各种编程语言和应用领域中推理和执行函数调用的能力。该基准包含超过 2,200 个测试用例,挑战模型处理复杂场景,比如在 Ja va、Ja vaScript 和 Python 等语言中的并行和多重函数调用。评估指标包括:针对非可执行测试查询的抽象语法树(AST)准确性、通过运行 API 获取结果的可执行准确性,以及一个相关性检测分数,该分数衡量 Agent 区分相关和不相关查询的能力。

需要特别指出的是,评估使用了截至 2024 年 9 月 3 日的最新 BFCL v2 版本。v2 版本引入了实时函数调用和用户贡献的真实场景,通过利用用户提供的数据,解决了数据污染、偏见和公平性等常见问题。这个更新后的数据集更好地反映了现实世界的数据分布,表现为在多个函数中选择的需求增加,而对并行函数调用的需求减少。例如,分析表明,与 v1 数据相比,v2 基准测试中可用函数的平均数量增加了一倍,而函数调用的平均数量却减少了一半。需要记住的是,团队的所有模型都是在 BFCL v2 实时数据发布之前训练的。

1.4.2 实验结果

1.4.2.1 Webshop 和 ToolQuery

Webshop:

表 2 展示了在 Webshop 和 ToolQuery 环境中,最先进的通用语言模型和 Agent 模型之间的详细对比,结果有力地说明了 xLAM 模型在性能上的稳健和强大。在 Webshop 环境中,xLAM-7b-r 不仅以 0.414 的成功率达到了最高分,超越了 GPT-4-0125-preview、GPT-4o-2024-0523 和 Claude2 等通用 LLM,还优于 AgentOhana-8x7b 和 Lemur-70b 这样的专用 Agent 模型。这充分展示了 xLAM 模型在网页交互环境中导航和执行任务的卓越能力。

ToolQuery:

在更复杂、更陌生的 ToolQuery 环境中,xLAM-8x7b-r 和 xLAM-8x22b-r 也表现出了高水平的性能,以 0.683 的成功率排名第二。这相较于其基础模型 Mixtral-8x7b-inst 和 Mixtral-8x22b-inst(分别为 0.167 和 0.400)的性能,提升非常显著。值得关注的是,所有三个 xLAM 模型都超过了 Mixtral-8x22B-Instruct 模型。尽管 Mixtral-8x22B-Instruct 拥有海量的参数和针对高级功能(如函数调用、推理和复杂工具使用)的专门调优,但其性能仍不及 xLAM 模型。此外,与其他通用 LLM 一样,它缺乏关于数据收集、统一过程和其他关键细节的透明性,这与 xLAM 的开源目标形成鲜明对比。这些结果有力地验证了论文提出的数据统一和合成数据管道的有效性。

ToolQuery-Unified:

当以统一格式向模型呈现 ToolQuery 的系统提示,并要求其遵循提供的格式指令生成结构化输出时,团队观察到 xLAM 模型的表现比 GPT 模型更为稳定,如表 3 所示。尽管 GPT-4o 在 ToolQuery 上的表现相比原始非统一格式下降了 42%,但最佳的 xLAM-8x22b 模型仍保持了几乎一致的水平。这可以归因于 xLAM 在遵循统一格式的轨迹上进行了训练,使其在推理过程中能够保持一致性。同期进行的其他研究也观察到,当 LLMs 被强制以特定格式生成输出时,在推理任务上的表现会出现下降。深入分析表明,这种性能下降不仅仅是由于输出格式错误本身,更反映了模型自身推理能力的减弱。

1.4.2.2 ToolBench

表 4 展示了 ToolBench 的结果,xLAM 模型表现非常出色。它们在所有测试设置中均超过了 ToolLlama-V2 和 GPT-3.5-Turbo-0125。此外,xLAM 模型在涉及未见过的指令和未见过工具的场景中,表现优于 AgentOhana-8x7b,同时在未见过的工具设置中达到了与 GPT-4-0125-preview 相当的性能。这些结果凸显了 xLAM 模型在多轮推理和复杂工具使用方面的强大能力,能够有效处理领域内和领域外的任务。

1.4.2.3 Berkeley Function-Calling Benchmark

表 5 展示了在 BFCL v2 基准(截止 2024 年 9 月 3 日)上的实验结果,xLAM 模型系列在函数调用任务中的表现堪称卓越。更具体地说,xLAM 模型占据了前二十名中的四个席位,这本身就是对团队数据流水线和训练方法在不同模型规模上有效性的有力证明。

旗舰模型 xLAM-8x22b-r 以 87.31% 的总体准确率拿下了榜首,超越了所有其他模型。这一结果直接验证了数据处理和模型训练流程在提升模型功能调用能力方面的有效性。紧随其后的是 xLAM-8x7b-r,排名第六,表现优于包括 GPT-4o-mini 和 Claude-3 在内的多数知名模型。

同时,模型性能表现出清晰的“规模扩展”关系。这一趋势在 xLAM-7b-r 上得到体现:它以 80.33% 的准确率排名第 14 位,优于多个更大、更消耗资源的模型,包括多个 GPT-4 和 GPT-4o 版本。这再次验证了小型模型在 Agent 领域的巨大潜力。

也许最令人印象深刻的是最小的模型——xLAM-1b-fc-r,它以 75.439% 的准确率排名第 32 位,超越了像 Claude-3-Opus(FC)和 GPT-3.5-Turbo 这样更大的模型。这一表现强有力地证明了论文数据合成框架的能力——它能生成高质量、多样化的数据集,即使是较小的语言模型,也能通过它显著增强函数调用的效果。

同样值得注意的是,BFCL v2 基准测试包含了一个在模型训练日期之后才发布的实时数据集。这些新鲜数据来自团队模型完全未见过的真实用户查询。即便如此,模型在处理这些实际用例时仍表现出了强大的泛化能力。从 8x22B 到 1B 参数的一系列模型中,持续强劲的表现展示了方法的可扩展性和多功能性。这种可扩展性意义重大:它不仅让小模型在资源受限的环境中取得好成绩成为可能,也支持了大模型在更苛刻的应用中发挥作用。更重要的是,小型模型能够与更大的替代方案竞争,这暗示着在各类现实场景中进行高效部署的巨大潜力。

1.4.3 消融研究

团队对 7B 模型进行了消融研究,以衡量数据管道中各个步骤的真实影响。为此,他们准备了三个数据集:原始数据、增强数据、以及增强+清洗数据。原始数据代表数据统一前的数据集,而另外两个则是统一后的数据。图表展示了在这三个数据集上训练出的模型的评估结果。用于此评估的指标来自 ToolBench 的 G1 指令,以及 Webshop 和 ToolQuery 的成功率。

结果表明:仅使用增强数据,就在 ToolBench 上带来了 2.3% 的提升,在 Webshop 上提升了 5.8%,在 ToolQuery 上更是提升了 18.3%——这是一致的正向改进。而当加入数据清洗步骤后,效果更为显著:ToolQuery 的性能又大幅提升了 23.4%。这些结果清晰地凸显了数据增强和清洗过程在整个数据管线中的关键价值。