互联网用户行为数据处理

业务场景

多模态数据的爆发让AI数据管线同时面临两大核心痛点：一是“跑得稳”的工程底座亟需构建——视频、图像、音频与文本的混合涌入，使传统单机脚本与手动编排迅速陷入GPU/NPU空转、内存溢出、调度崩溃的运维泥潭，算力效率与工程稳定性成为规模化处理的第一道硬约束；二是“选得准”的数据策略亟待落地——海量数据驱动的大模型训练已触及边际收益天花板，决定模型上限的Hard Samples淹没在常规样本中，标注预算大量消耗于简单样本，高价值难例的挖掘与回捞能力严重缺失。工程底座与数据策略，一个是规模化处理的基础保障，一个是模型效果的价值杠杆，二者并行不悖、缺一不可，共同定义着AI数据管线从“粗放吞吐”迈向“精准供给”的核心能力边界。

传统架构面临如下痛点：

表1 传统架构方案的痛点
传统方案痛点	说明
异构资源调度低效	识别“高质量难例”需引入小模型对海量语料进行数据打标，推理环节需要NPU加速。传统批处理系统难以精细调度NPU资源，导致昂贵的NPU在数据I/O与解码阶段大量空闲，利用率常不足20%。
数据打标链路断裂	传统方案需将海量语料导出至独立的推理服务进行打标，跨系统复制中间数据造成巨大I/O开销，且无法形成紧耦合Pipeline，开发效率低下。
扩展集群难	集群新增NPU节点慢，集群内不支持多代次异构NPU节点，资源无法利旧。

方案架构

为解决上述问题，我们利用Ray构建端到端的Hard Samples数据生产流水线，核心架构如下：

异构数据统一加载：通过Ray Data API直接从对象存储读取原始语料。Ray Data自动根据文件数量和集群资源进行分区，实现分布式并发拉取，避免单点I/O瓶颈。
难例实时打标：利用Ray Data API的map_batches函数调用HuggingFace小模型对语料进行打标。
流式算子融合执行：Ray Data采用流式执行引擎，将“语料读取→数据打标→难例过滤”三个算子融合为单一Pipeline，避免中间结果物化落盘，有效控制内存峰值并缓解OOM。

通过Ray，我们为多模态数据Hard Samples数据生产提供了一站式解决方案。

图1 解决方案架构图
点击放大

与传统方案对比：

异构资源精细化调度：在同一Pipeline中为不同算子指定CPU/NPU资源（解码用CPU、打标用NPU），NPU利用率显著提升，空转成本大幅降低。
Python原生分布式透明化：无需修改核心Python逻辑，Ray Data自动将单机函数分布式并发执行，支持百TB级数据集线性扩展。
AI生态原生整合：允许在预处理阶段直接调用大模型打标，实现数据处理与模型推理的紧耦合。

流式处理降低内存压力：Ray Data采用流式执行模型，数据以Block为单位在算子间流转，无需将整个数据集物化到内存中，适合处理TB/PB级大规模语料。

表2 与传统方案的对比
对比维度	传统方案	Ray方案	优势说明
异构资源	CPU/NPU分离，跨任务执行时需数据落盘存储。	同一Pipeline中CPU/NPU混合调度，数据传递不落盘。	计算资源利用效率高。减少重复I/O，成本更优。
统一编程	需要维护多套框架，运维复杂度高。	一套Ray API覆盖全流程。	有效降低工程复杂度。
Hard Samples筛选	需导出至独立推理服务，链路割裂。	批量推理集成，HuggingFace Pipeline直嵌。	打破“先全部处理完，再全部推理”的阻塞。

方案流程

技术实现流程：

环境准备
- 在AI DataLake管理控制台创建工作空间，用于提供独立的作业运行环境。
- 在AI DataLake管理控制台创建计算资源池，为作业的运行提供计算资源。
- 在AI DataLake管理控制台创建Ray Cluster端点，配置Ray引擎与计算资源池的关联关系。
数据与模型准备
- 准备数据预处理、推理标注Ray Job代码脚本，并上传至存放作业代码的OBS桶；
- 将离线推理小模型及模型数据上传至存放模型的OBS桶，确保作业运行时能够加载。
执行作业并查看结果
- 通过Rest API提交Ray Job作业至Ray Cluster端点运行。Ray Job会读取原始语料，通过内存直接传递至CPU完成数据预处理、NPU完成推理标注的全流程处理，最终结果以图片格式存储。