第十五章 AI/ML 系统的数据架构 - 特征工程与模型服务

导读

人工智能和机器学习正在深刻地改变软件系统的设计。从推荐系统到自然语言处理，从计算机视觉到自动驾驶，AI/ML 应用已经成为数据密集型系统的重要组成部分。

然而，构建一个生产级的 AI/ML 系统远不止训练一个模型。数据获取、特征工程、模型训练、模型评估、模型部署、在线推理、模型监控——每一个环节都需要精心设计的数据架构来支撑。MLOps（Machine Learning Operations）正是为了解决这些工程挑战而诞生的实践。

本章将深入探讨 AI/ML 系统的数据架构：特征存储（Feature Store）、训练数据管道、模型服务（Model Serving）、模型监控与再训练，以及大语言模型（LLM）时代的数据架构变革。

核心概念详解

15.1 ML 系统的数据挑战

15.1.1 数据质量

AI/ML 系统对数据质量的要求极高——"Garbage in, garbage out"（垃圾进，垃圾出）。

数据质量的维度：

• 准确性：数据是否反映了真实世界的状态？
• 完整性：是否有缺失值？缺失的比例是多少？
• 一致性：不同数据源的数据是否一致？
• 时效性：数据是否足够新？是否反映了最新的状态？
• 相关性：数据是否与预测目标相关？

数据质量问题的影响：

• 训练数据有偏差 → 模型预测不准确。
• 特征计算错误 → 训练和服务不一致（Training-Serving Skew）。
• 标签错误 → 模型学习到错误的模式。

15.1.2 数据规模

现代 ML 系统通常需要处理海量数据：

• 训练数据：数百万到数十亿条样本，每条样本包含数百到数千个特征。
• 特征数据：需要从多个数据源聚合和转换，计算量巨大。
• 推理数据：在线推理需要处理高并发的实时请求。

数据规模的挑战：

• 存储和计算成本。
• 数据处理的速度和效率。
• 数据的版本管理和可追溯性。

15.1.3 数据漂移

数据漂移（Data Drift）是指生产环境中的数据分布与训练时的数据分布发生变化的现象。

数据漂移的类型：

• 特征漂移（Feature Drift）：输入特征的分布发生变化。例如，用户行为模式随时间变化。
• 标签漂移（Label Drift）：预测目标的分布发生变化。例如，经济环境变化导致消费模式改变。
• 概念漂移（Concept Drift）：特征与标签之间的关系发生变化。例如，新的竞争对手出现改变了市场格局。

数据漂移的影响：

• 模型性能逐渐下降。
• 预测结果变得不可靠。
• 需要定期监控和再训练模型。

15.2 特征工程与特征存储

15.2.1 特征工程

特征工程（Feature Engineering）是将原始数据转换为模型可以使用的特征的过程。

特征工程的步骤：

特征提取：从原始数据中提取有意义的信息。例如，从时间戳中提取小时、星期几、是否节假日。

特征转换：对特征进行数学变换。例如，对数变换、标准化、归一化。

特征组合：将多个特征组合为新特征。例如，特征交叉（Feature Cross）。

特征选择：选择对预测最有用的特征，去除冗余和无关特征。

特征工程的挑战：

• 领域知识：好的特征需要对业务领域有深入理解。
• 计算成本：复杂特征的计算可能很耗时。
• 一致性：训练和服务时的特征计算必须一致。

15.2.2 特征存储（Feature Store）

特征存储（Feature Store）是 ML 系统中的核心组件，负责特征的存储、管理和服务。

特征存储的核心功能：

特征注册（Feature Registry）：

• 定义特征的元数据：名称、描述、数据类型、计算逻辑。
• 版本管理：追踪特征定义的变更历史。
• 特征发现：帮助数据科学家找到可复用的特征。

离线存储（Offline Store）：

• 存储用于模型训练的历史特征数据。
• 通常使用数据湖或数据仓库（如 S3 + Parquet、BigQuery）。
• 支持大规模批处理查询。

在线存储（Online Store）：

• 存储用于在线推理的实时特征。
• 通常使用低延迟的 KV 存储（如 Redis、DynamoDB）。
• 支持毫秒级的点查。

特征计算管道：

• 从原始数据源计算和更新特征。
• 同时写入离线存储和在线存储。
• 保证训练和服务时的特征一致性。

15.2.3 特征存储的代表产品

开源特征存储：

• Feast（Gojek/Google）：最流行的开源特征存储，支持离线和在线存储。
• Hopsworks：企业级特征存储平台，包含完整的 MLOps 功能。
• Feathub（蚂蚁集团）：支持流批一体的特征计算。

商业特征存储：

• AWS SageMaker Feature Store：AWS 的托管特征存储服务。
• Google Vertex AI Feature Store：Google Cloud 的特征存储服务。
• Tecton：由 Feast 创始团队创建的商业特征存储平台。

15.3 训练数据管道

15.3.1 训练数据的构建

构建训练数据是 ML 系统中最耗时的环节之一。

训练数据管道的步骤：

数据收集：从多个数据源收集原始数据（数据库、日志、API）。

数据清洗：处理缺失值、异常值、重复数据。

特征计算：根据特征定义计算特征值。

标签获取：获取训练标签（人工标注、自动标注、弱监督）。

数据合并：将特征和标签合并为训练样本。

数据验证：检查数据质量、分布、偏差。

数据存储：将训练数据写入存储（如 TFRecord、Parquet）。

15.3.2 训练-Serving 一致性

训练-Serving 一致性（Training-Serving Consistency）是 ML 系统中的一个关键挑战：训练时使用的特征必须与在线推理时使用的特征完全一致。

不一致的原因：

• 代码差异：训练和服务使用不同的代码计算特征。
• 数据差异：训练使用历史数据，服务使用实时数据，数据源可能不同。
• 时间差异：训练时可以看到未来的数据（数据泄漏），服务时不能。

保证一致性的策略：

• 统一特征计算：使用特征存储，训练和服务从同一个特征存储读取。
• 代码复用：训练和服务使用同一份特征计算代码。
• 时间点特征（Point-in-Time Features）：训练时只使用在预测时间点之前可用的数据。

15.3.3 数据版本管理

ML 实验需要可追溯性——需要知道哪个数据集训练了哪个模型，产生了什么结果。

数据版本管理的工具：

• DVC（Data Version Control）：使用 Git 管理数据版本。
• LakeFS：为数据湖提供 Git-like 的版本管理。
• Delta Lake / Iceberg：内置时间旅行功能，支持数据版本管理。
• MLflow / Weights & Biases：ML 实验跟踪平台，记录数据集和模型的对应关系。

15.4 模型服务

15.4.1 模型服务模式

模型服务（Model Serving / Model Inference）是将训练好的模型部署为在线服务的过程。

常见的模型服务模式：

批量推理（Batch Inference）：

• 定期（如每小时、每天）对批量数据运行模型预测。
• 预测结果写入数据库或数据湖。
• 适合不需要实时预测的场景（如推荐系统的候选排序）。

在线推理（Online Inference）：

• 接收实时请求，立即返回预测结果。
• 延迟要求通常在毫秒到秒级。
• 适合需要实时预测的场景（如搜索排序、风控）。

流式推理（Streaming Inference）：

• 消费事件流，对每个事件进行实时预测。
• 延迟要求在毫秒级。
• 适合实时风控、异常检测等场景。

边缘推理（Edge Inference）：

• 在终端设备（手机、IoT 设备）上运行模型。
• 延迟要求极低，需要模型压缩和量化。
• 适合离线场景和隐私敏感场景。

15.4.2 模型服务架构

典型的在线模型服务架构：

请求路由：

• API Gateway 接收请求，路由到对应的模型服务。
• 支持 A/B 测试、灰度发布。

特征服务：

• 从特征存储的在线存储中获取实时特征。
• 延迟要求在毫秒级。

模型推理：

• 加载模型，执行推理计算。
• 可以使用 GPU 加速。
• 支持模型版本管理和热更新。

结果缓存：

• 缓存常见请求的预测结果，减少重复计算。
• 使用 Redis 或本地缓存。

结果存储：

• 将预测结果写入数据库，供业务系统使用。
• 记录推理日志，用于监控和审计。

15.4.3 模型服务框架

开源模型服务框架：

• TensorFlow Serving：TensorFlow 模型的专用服务框架。
• TorchServe：PyTorch 模型的专用服务框架。
• Triton Inference Server（NVIDIA）：支持多种框架（TF、PyTorch、ONNX）的通用服务框架。
• Seldon：Kubernetes 原生的模型服务平台。
• BentoML：轻量级的模型打包和服务框架。

商业模型服务：

• AWS SageMaker：端到端的 ML 平台，包含训练和服务。
• Google Vertex AI：Google Cloud 的 ML 平台。
• Azure ML：Microsoft Azure 的 ML 平台。

15.5 模型监控与再训练

15.5.1 模型监控

模型部署后需要持续监控，确保模型性能不下降。

监控的维度：

系统指标：

• 推理延迟（p50、p95、p99）。
• 吞吐量（QPS）。
• 错误率。
• 资源使用率（CPU、GPU、内存）。

数据指标：

• 输入特征的分布（均值、方差、分位数）。
• 特征缺失率。
• 特征异常值比例。

模型指标：

• 预测结果的分布。
• 准确率、精确率、召回率（如果有真实标签）。
• 数据漂移检测（与训练数据的分布比较）。

15.5.2 数据漂移检测

数据漂移检测是模型监控的核心功能。

检测方法：

• 统计检验：使用 KS 检验、卡方检验等比较训练数据和服务数据的分布。
• 距离度量：计算 PSI（Population Stability Index）、KL 散度等距离指标。
• 机器学习：训练一个分类器区分训练数据和服务数据，如果分类器性能好说明分布差异大。

漂移处理的策略：

• 告警：漂移超过阈值时发送告警。
• 自动再训练：检测到漂移后自动触发模型再训练。
• 回滚：如果新模型性能下降，自动回滚到旧模型。

15.5.3 模型再训练

模型再训练是保持模型性能的关键。

再训练的触发条件：

• 定期再训练：按固定周期（如每天、每周）再训练。
• 性能驱动：当模型性能下降到阈值以下时再训练。
• 漂移驱动：当检测到数据漂移时再训练。
• 事件驱动：当有新的训练数据可用时再训练。

再训练的挑战：

• 增量学习 vs 全量训练：增量学习快但可能遗忘，全量训练慢但更准确。
• 数据选择：选择哪些数据进行再训练？全部数据还是最近的数据？
• 模型版本管理：管理多个模型版本，支持回滚。
• A/B 测试：新模型上线前需要 A/B 测试验证效果。

15.6 LLM 时代的数据架构

15.6.1 LLM 应用的数据需求

大语言模型（LLM）的兴起带来了新的数据架构需求：

训练数据：

• LLM 训练需要 TB 级的文本数据。
• 数据来源：网页、书籍、代码、论文、对话。
• 数据质量至关重要——低质量数据会降低模型能力。

推理数据：

• 用户输入（Prompt）需要预处理和后处理。
• 上下文窗口有限，需要检索相关信息（RAG）。
• 对话历史需要存储和管理。

评估数据：

• 需要高质量的评估数据集来衡量模型性能。
• 评估数据需要覆盖各种场景和能力。

15.6.2 RAG（检索增强生成）

RAG（Retrieval-Augmented Generation）是一种结合检索和生成的架构，用于增强 LLM 的知识。

RAG 的工作流程：

索引构建：将知识库文档切分为片段，计算每个片段的向量嵌入（Embedding），存入向量数据库。

检索：用户提问时，计算问题的向量嵌入，在向量数据库中检索最相关的片段。

生成：将检索到的片段作为上下文，与用户问题一起发送给 LLM，生成回答。

RAG 的数据架构：

• 文档处理管道：解析、切分、清洗文档。
• 向量嵌入服务：使用 Embedding 模型将文本转换为向量。
• 向量数据库：存储和检索向量。代表：Pinecone、Weaviate、Milvus、Qdrant。
• LLM 服务：生成最终回答。代表：OpenAI API、Claude API、通义千问。

15.6.3 LLM 的数据治理

LLM 应用引入了新的数据治理挑战：

数据隐私：

• 用户输入可能包含敏感信息。
• 需要在发送给 LLM 之前进行脱敏处理。
• 对话历史需要安全存储和访问控制。

内容安全：

• LLM 可能生成有害、偏见或不准确的内容。
• 需要内容过滤和安全对齐。
• 需要审计日志追踪生成内容。

知识产权：

• 训练数据可能包含受版权保护的内容。
• 生成内容可能侵犯他人知识产权。
• 需要数据溯源和许可证管理。

重要知识点

知识点 1：特征存储的架构设计

特征存储的架构需要考虑以下因素：

离线存储：

• 使用数据湖（S3 + Parquet/Iceberg）或数据仓库（BigQuery）。
• 支持大规模批处理查询（如全量训练数据的生成）。
• 支持时间点查询（Point-in-Time Query）——获取某个时间点之前的最新特征值。

在线存储：

• 使用低延迟的 KV 存储（Redis、DynamoDB、Cassandra）。
• 支持毫秒级的点查。
• 数据从离线存储同步到在线存储。

一致性保证：

• 离线和在线存储的数据必须一致。
• 使用 CDC 或事件驱动同步数据。
• 处理延迟和冲突。

知识点 2：ML 系统的可复现性

ML 实验的可复现性是一个重要但经常被忽视的问题。

影响可复现性的因素：

• 数据版本：训练数据是否相同？
• 特征版本：特征计算逻辑是否相同？
• 代码版本：模型代码和超参数是否相同？
• 环境版本：依赖库的版本是否相同？
• 随机性：随机种子是否相同？

保证可复现性的策略：

• 使用 DVC 或 MLflow 追踪数据和模型的版本。
• 使用容器化（Docker）固定运行环境。
• 记录所有超参数和随机种子。
• 使用特征存储确保特征的一致性。

知识点 3：向量数据库

向量数据库是 LLM 应用中的关键组件，用于存储和检索向量嵌入。

向量数据库的核心功能：

• 向量存储：高效存储高维向量（如 768 维、1536 维）。
• 近似最近邻搜索（ANN）：快速检索与查询向量最相似的向量。
• 混合查询：支持向量搜索 + 标量过滤的组合查询。

ANN 算法：

• HNSW（Hierarchical Navigable Small World）：基于图的索引，查询速度快，内存占用大。
• IVF（Inverted File Index）：基于聚类的索引，内存占用小，查询速度较慢。
• PQ（Product Quantization）：向量压缩算法，减少内存占用。

向量数据库的选择：

• Pinecone：全托管的向量数据库，易于使用。
• Weaviate：开源向量数据库，支持混合查询。
• Milvus：开源向量数据库，高性能，支持大规模部署。
• Qdrant：开源向量数据库，Rust 实现，高性能。
• pgvector：PostgreSQL 扩展，适合已有 PG 生态的团队。

知识点 4：MLOps 成熟度模型

MLOps 的成熟度可以分为三个级别：

级别 1：手动流程

• 数据准备、特征工程、模型训练、模型部署都是手动的。
• 代码和数据版本管理不完善。
• 模型监控缺失或有限。

级别 2：ML 管道自动化

• 训练管道自动化（数据准备 → 特征计算 → 模型训练 → 模型评估）。
• 模型部署自动化（CI/CD for ML）。
• 基本的模型监控和告警。

级别 3：CI/CD/CT 自动化

• 持续集成（CI）：自动测试代码和数据处理逻辑。
• 持续部署（CD）：自动部署模型到生产环境。
• 持续训练（CT）：自动检测数据漂移并触发再训练。
• 完整的模型监控、审计和治理。

常见误区

误区 1："模型训练是最重要的，数据不重要"

纠正：在 ML 系统中，数据比模型更重要。一个好的模型在差的数据上表现很差，而一个简单模型在好的数据上可以表现很好。业界有句话："数据是新的石油"——数据的质量和规模决定了模型性能的上限，模型算法只是逼近这个上限。

误区 2："训练一次模型就够了"

纠正：由于数据漂移，模型性能会随时间下降。需要持续监控模型性能，定期再训练模型。在快速变化的领域（如电商、金融），可能需要每天或每周再训练。

误区 3："特征存储只是一个数据库"

纠正：特征存储不仅仅是一个数据库，它是一个完整的特征管理平台。除了存储，还包括特征注册、特征发现、特征计算管道、在线/离线一致性保证等。没有特征存储，ML 团队容易陷入"特征重复开发"和"训练-服务不一致"的问题。

误区 4："LLM 不需要数据工程"

纠正：LLM 应用同样需要精心设计的数据架构。RAG 需要文档处理管道、向量嵌入服务、向量数据库。微调需要高质量的训练数据。评估需要全面的评估数据集。数据治理在 LLM 时代更加重要——隐私、安全、版权问题都需要认真处理。

误区 5："MLOps 只是 DevOps 的延伸"

纠正：MLOps 比 DevOps 更复杂，因为 ML 系统有额外的维度：数据版本、特征管理、模型版本、实验跟踪、数据漂移监控等。传统的 DevOps 工具（如 Jenkins、GitHub Actions）不足以覆盖这些需求，需要专门的 ML 工具链（MLflow、Kubeflow、Feast 等）。

实践应用

实践 1：设计特征存储

设计特征存储的步骤：

识别特征：与数据科学家合作，识别需要的特征。

定义特征 Schema：为每个特征定义名称、类型、描述、计算逻辑。

选择存储：离线存储使用数据湖（S3 + Parquet），在线存储使用 Redis 或 DynamoDB。

构建计算管道：使用 Spark 或 Flink 计算特征，写入离线和在线存储。

提供 SDK：为训练和服务提供特征读取的 SDK。

监控：监控特征计算管道的延迟、数据质量、存储成本。

实践 2：构建训练数据管道

构建训练数据管道的最佳实践：

数据源管理：统一管理多个数据源的连接和认证。

数据验证：在管道的每个阶段验证数据质量（Schema、范围、分布）。

特征计算：使用特征存储保证训练和服务的一致性。

标签管理：管理标签的来源、质量和版本。

数据版本：使用 DVC 或 LakeFS 管理训练数据的版本。

实验跟踪：使用 MLflow 或 W&B 记录数据集、模型、指标的对应关系。

实践 3：部署模型服务

部署模型服务的步骤：

模型打包：将模型、依赖、预处理/后处理代码打包为容器镜像。

选择服务模式：根据延迟需求选择在线推理、批量推理或流式推理。

部署到 K8s：使用 Seldon 或 KServe 部署模型服务到 Kubernetes。

配置自动扩缩容：根据 QPS 或 GPU 使用率自动扩缩容。

A/B 测试：使用流量分割测试新模型。

监控：监控系统指标、数据指标、模型指标。

实践 4：构建 RAG 系统

构建 RAG 系统的步骤：

文档处理：解析 PDF、Word、HTML 等格式，切分为合理大小的片段。

向量嵌入：使用 Embedding 模型（如 OpenAI、通义千问）将文本转换为向量。

向量存储：将向量和原文存入向量数据库。

检索优化：调整检索策略（Top-K、相似度阈值、混合检索）。

Prompt 工程：设计 Prompt 模板，将检索到的上下文和用户问题组合。

评估：使用评估数据集测试 RAG 系统的准确性和相关性。

本章小结

本章深入探讨了 AI/ML 系统的数据架构：

数据挑战：

- 数据质量、数据规模、数据漂移是 ML 系统的核心挑战。

- 需要专门的数据架构来应对这些挑战。

特征工程与特征存储：

- 特征工程是将原始数据转换为模型输入的过程。

- 特征存储管理特征的存储、计算和服务，保证训练和服务的一致性。

- 离线存储用于训练，在线存储用于推理。

训练数据管道：

- 从数据收集到训练数据生成的完整流程。

- 训练-Serving 一致性是关键挑战。

- 数据版本管理保证实验的可复现性。

模型服务：

- 批量推理、在线推理、流式推理、边缘推理。

- 模型服务框架：TensorFlow Serving、Triton、Seldon。

- 需要监控延迟、吞吐量、错误率。

模型监控与再训练：

- 监控系统指标、数据指标、模型指标。

- 数据漂移检测触发模型再训练。

- MLOps 成熟度从手动流程到全自动化。

LLM 时代的数据架构：

- RAG 结合检索和生成，增强 LLM 的知识。

- 向量数据库是 RAG 的核心组件。

- 数据治理在 LLM 时代更加重要。

AI/ML 系统的数据架构是一个快速发展的领域。理解特征存储、训练管道、模型服务、模型监控等核心概念，是构建生产级 ML 系统的基础。随着 LLM 的兴起，数据架构的重要性进一步提升——好的数据架构是 AI 应用成功的基石。