腾讯 WorkBuddy 基于 AI DLC 打造持续进化的AI Native数据底座

WorkBuddy 首先面对的是数据增长带来的扩展压力。业务进入成长期后，线上业务数据、用户对话、文档、附件和行为日志持续累积，同时伴随大量临时分析和训练需求。固定集群模式下，有任务时容易排队，高峰期可能资源不足，闲时又存在资源占用，因此核心问题逐渐从单次作业性能转向处理能力能否随数据规模持续扩展。

第二个挑战来自数据形态。WorkBuddy 的用户对话和长文档中存在 1 GB+ 的超大字段，如果按照整行读取，即使任务只需要 id、时间、用户、状态等少数字段，也会被大对象拖慢。成本统计、常规报表等任务希望尽量避开正文，而模型训练、多模态解析等任务又需要更高吞吐和临时扩容能力，这要求底层能够针对不同任务选择不同的数据读取和计算方式。

第三个问题是多数据方协作。过去的数据交付依赖人工筛选字段和范围，再通过 COS 或下载链接交付。随着需求方增加，这种方式在效率、权限边界和审计方面都面临压力。因此，底座调整的重点不只是提升单个作业速度，而是让数据处理能力能够随规模扩展，让任务按需获取资源，并将训练、数据管理和数据访问串成一条可追踪的流程。

在超大字段场景中，WorkBuddy 首先调整了存储和读取方式。对于对话正文、长文档等占单条记录绝大部分体积的字段，改用列式存储后，任务可以只读取真正需要的字段，避免为了少量统计字段扫描整条大对象。同时通过冷热分离，把长期数据与近期高频关注的数据拆开，大字段和元数据也可以分开存储，使检索和统计任务更轻。真正需要做复杂解析时，再交给 Xpark 多模态引擎处理。Xpark 提供 SQL-First AI Function 和 50+ 多模态 / LLM 算子，用于承接多模态和大字段解析，并在峰值任务出现时临时扩容。

这套方案是否有效，WorkBuddy 在切换期间做过双跑：同一批数据、同一条管线，用原有方式和 DLC 方案做真实对比。结果显示，同数据处理耗时从 5 小时降到 1 小时，吞吐提升 5 倍；CPU 使用率下降 80%。实测还包括超大字段任务耗时下降 60%、任务成功率提升至 99%、扫描数据量大幅下降，存量 Spark 作业可零改动迁入。对 WorkBuddy 来说，这一阶段最关键的变化，是让超大字段不再成为所有任务的共同负担：不需要大字段的任务可以直接跳过，需要大字段的任务再使用对应算子和弹性资源处理。

但数据处理只是第一步。WorkBuddy 本身还承担特定领域模型的训练需求，过去的训练方式更接近“实验室式”流程：研究人员各自拿资源处理数据，处理完成后再启动训练，数据清洗、训练、评测之间依赖人工衔接。随着数据量增长，这种方式不仅效率低，也难以标准化，更难随着资源扩展获得线性处理能力。

新的做法是把“数据到训练”定义为一条完整流程，而不是几个互相分离的任务。数据统一入湖后，先通过算子完成数据清洗、特征处理和数据配比，再直接进入训练环节；以 SFT / RL 为代表的后训练任务通过 Ray Train 执行，训练完成后进入评估，评估结果和 Agent 轨迹再回流数据湖，继续参与后续数据处理和训练。也就是说，一次任务的边界不再是“一次数据清洗”或“一次训练”，而是从当前场景的数据准备开始，一直到训练、评测和回流结束。

为了把这些环节真正串起来，WorkBuddy 在 DLC API 之上只增加了一层较薄的调度。研究人员仍然可以在自己熟悉的开发环境或方式中调用底层能力，看起来像是在本地发起操作，实际计算会映射到云端 DLC。这样既不要求研究人员改变原有操作习惯，也避免每个团队单独维护一套数据处理和训练基础设施。调整后，数据到训练的交付周期下降 70%，人工搬运下降 90%，流程可以复用。

数据传输本身也被纳入优化范围。过去常见做法是先在一台机器上处理数据，再传到 COS，随后从训练集群重新拉取。新的流程中，数据处理和训练可以自动衔接；训练读取数据时也不必先全量下载，而是采用 prefetch 和缓存方式，训练一批、拉取一批，把数据读取时间尽量隐藏在训练周期内。这样一来，数据流转不再是训练流程之外的额外动作，而成为同一条流水线的一部分。

当数据、训练和评估被串成一条流程后，另一个问题随之出现：如何知道一次训练到底用了什么数据、经过了哪些处理、最终影响了哪个模型。WorkBuddy 没有重新建设一套独立系统，而是在 DLC 能力上增加一层自身关注的元数据存储和关联关系。数据加工、特征工程、模型训练、模型服务以及 Agent 轨迹/记忆等对象可以直接注册元数据与运行状态，把数据对象和 AI 对象放在同一条血缘中。

对于算法研究人员，这意味着一次训练所使用的数据、数据配比、每条数据从哪里产生、在哪一步合并、经过了哪些算子，以及最终进入哪个训练任务，都可以追踪和回溯。在这套体系下，血缘覆盖率达到 95%+，问题排查时间下降 80%，额外成本约为 0。更重要的是，这种做法没有要求团队另外维护一套重型血缘系统，而是在现有计算和训练流程上直接沉淀元数据。

同一套思路也被用于算力扩展。WorkBuddy 希望数据量增长时，处理能力能够同步增长，而不是数据到达某个规模后再临时补系统。为此，数据处理算子从设计时就考虑可扩展性，CPU / GPU 异构算力统一纳管并动态调度，每个任务根据处理量和时效独立申请资源，用完释放。Serverless 模式让临时需求不再长期占用固定集群，任务增加时扩容，闲时收缩。这一方案的收益包括峰值处理时延下降 65%、启动速度达到分钟级、闲时算力成本约为 0。在数据持续增长的测试过程中，处理效率和整体耗时仍然维持在相对固定的范围内，这也是团队最初希望验证的线性扩展目标。

数据处理效率提升之后，数据怎么安全地交付给不同团队仍然是必须解决的一环。WorkBuddy 的数据需求方覆盖算法/模型训练、BI 分析、风控、运营/数据科学等角色，不同团队能看到的数据范围并不相同。新的方案把已经入湖并完成处理、脱敏的数据交给统一权限体系管理，授权可以细化到库、表、行、列，并结合数据的可用范围和时效性进行控制。

对合作团队而言，获得授权后可以直接通过 DLC 提供的 API 和 SDK 获取数据，也可以在 DLC 上使用自己的流水线直接引用被授权的数据继续开发和分析。这样，数据不再需要由内部人员手工筛选、下载、上传、发送链接，再由对方二次下载。权限交付从一次次人工操作，变成由统一权限中心控制的数据访问过程。

与此同时，数据的下载和使用过程都可以被记录和审计。这一部分的结果是：授权到位达到分钟级，越权风险可控，操作审计全程留痕。对于 WorkBuddy 来说，这一变化和前面的弹性计算、训练流水线并不是三个相互独立的优化点，而是同一个数据底座的不同侧面：数据需要按需处理，也需要按需训练，还要能够按权限交付给不同角色，并且整个过程都能被追踪。

WorkBuddy 这次实践的核心，并不是再增加一套独立的数据系统，而是把原本分散的数据处理、后训练、资源申请、元数据和权限管理重新串到同一底座上。面对超大字段，先通过列式读取、冷热分离和多模态算子降低无效扫描；面对训练流程，把数据清洗、配比、SFT / RL、评估和回流做成可复用流水线；面对持续增长的数据量，用 Serverless 弹性和可扩展算子让处理能力随资源同步扩展；面对多团队协作，再用统一权限和审计把数据交付闭环补齐。

最终形成的并不是一条只服务单次训练的管线，而是一套从数据产生、处理、训练、评估、回流到再次使用的连续流程。Agent 的轨迹和反馈可以沉淀入湖，进入下一轮数据处理和后训练；训练过程产生的元数据和血缘又继续留在同一体系内，资源和权限则根据任务动态分配。对 WorkBuddy 而言，“持续进化”的落点，正是在这条能够反复运行、可追踪、可复用的数据与训练闭环上。