ESC
输入关键词搜索文章
目录

数据 Infra

为什么 AI 系统真正消耗的是数据供应链
模型参数不是唯一知识来源,上下文接入才是系统能力的延伸
3数据生命周期阶段
2知识接入模式
N异构数据源
系列七
模型参数不是唯一知识来源

前面几篇讨论了训练 Infra 和推理 Infra——模型怎么被训练出来,又怎么被服务出去。但一个现代 AI 系统的真实能力,并不只来自预训练参数。它同样依赖训练前的数据供应链,以及推理时对外部知识的接入、检索与约束 #IBM-RAG-VectorDB-2026

这一层往往被简化成“上一个向量数据库”或“搭一个 RAG 管线”,但实际上,数据 Infra 的范围远不止于此。它至少包括:数据采集与清洗、数据版本化与治理、embedding pipeline、检索与排序、vector DB、知识图谱,以及把这些组件串联成稳定生产管线的工程系统。

一、数据供应链:模型吃什么,比模型多大更重要

大模型的预训练数据通常以 TB 甚至 PB 计。但这些原始数据并不能直接喂给模型,它们需要经过一系列工程处理:

  • 采集:从网页、书籍、代码库、对话记录、多模态内容中收集原始语料。
  • 清洗:去重、过滤低质量内容、去除有害信息、处理格式不一致。
  • 标注:为监督微调和人类反馈强化学习(RLHF)准备高质量标注数据。
  • 版本化:数据集不是静态的,它需要像代码一样被版本管理,以便追溯、回滚和复现实验。

这一链条上的每一个环节都有基础设施问题。清洗需要分布式计算框架(如 Spark、Ray Data);去重需要高效的去重算法和存储;版本化需要专门的数据版本管理工具(如 DVC、LakeFS)。

核心判断:训练数据的质量和多样性,往往比模型架构的创新更能决定最终效果。而数据 Infra 的任务,就是确保高质量数据能被稳定、可复现地输送到训练管线中。
二、Embedding:把知识变成向量

当模型需要接入外部知识时,第一步通常是把文本、图像或其他模态内容转换成稠密向量表示,也就是 embedding。这些向量捕捉了内容的语义信息,使得“相似含义”的内容在向量空间中彼此接近。

Embedding pipeline 本身也是一个数据工程问题:

  • 模型选择:不同的 embedding 模型(如 OpenAI text-embedding-3、BGE、E5)在不同语言和任务上表现不同。
  • 批处理与效率:大规模文档集需要高效的批处理 embedding,通常需要 GPU 加速。
  • 更新策略:当源文档更新时,哪些 embedding 需要重新计算?如何增量更新?
  • 维度与质量权衡:更高维度的 embedding 通常保留更多信息,但也带来更大的存储和计算开销。
三、Vector DB:不是数据库的替代品,而是检索的加速器

有了 embedding,下一步是存储和检索。Vector DB 专门优化了高维向量的近似最近邻(ANN)搜索,使得在数百万甚至数十亿向量中快速找到语义最相关的结果成为可能 #IBM-RAG-VectorDB-2026

但 Vector DB 并不是传统数据库的替代品,而是 complements。真实系统通常需要混合检索:

  • 向量检索:基于语义相似度找到相关内容。
  • 关键词检索:基于精确匹配找到特定术语或 ID。
  • 结构化过滤:在语义检索前先按元数据(时间、作者、类别)缩小范围。

这也是为什么许多系统选择混合方案:PostgreSQL + pgvector、Elasticsearch + 向量字段、或专门的 vector DB(如 Milvus、Pinecone、Weaviate)与传统数据库配合使用。

四、RAG:把外部知识注入推理过程

检索增强生成(RAG)是数据 Infra 和推理 Infra 的交汇点。它的核心思想很简单:在模型生成回答之前,先从外部知识库中检索相关上下文,然后把检索结果和原始 prompt 一起送给模型 #IBM-RAG-VectorDB-2026

但 RAG 系统的工程复杂度常常被低估。一个生产级的 RAG 管线至少需要:

  • 文档解析:PDF、Word、网页、表格等不同格式需要不同的解析策略。
  • 分块策略:文档该按段落、按句子、还是按固定 token 数切分?块大小直接影响检索质量和模型理解。
  • 重排序(Re-ranking):向量检索的初步结果往往不够精确,需要更精细的排序模型做二次筛选。
  • 上下文压缩:检索到的内容可能太长,需要压缩或摘要后才能塞进模型的上下文窗口。
  • 评估与迭代:RAG 系统的质量需要持续评估(检索准确率、生成忠实度、答案完整性),并根据反馈迭代优化。

RAG 不是万能药

RAG 解决了“模型不知道最新信息”和“模型不能访问私有数据”的问题,但它引入了新的系统复杂性:检索质量、延迟、知识更新时效、以及检索失败时的降级策略。

五、数据治理:不只是技术问题

数据 Infra 的最后一层是治理。它包括:

  • 数据主权与合规:哪些数据可以采集、存储和用于训练?不同司法管辖区有不同的法规要求。
  • 数据质量监控:训练数据的分布漂移、标注错误率、重复率都需要持续监控。
  • 访问控制:在多租户环境中,不同团队或应用的数据需要被隔离。
  • 血缘追踪:从原始数据到最终模型输出,整个链条需要可追溯。

这些治理问题不是“附加功能”,而是决定 AI 系统能否长期稳定运营的基础能力。

六、数据 Infra 在 AI 系统中的位置

如果把数据 Infra 放在整个 AI Infra 地图中,它处于连接“模型”和“现实世界”的桥梁位置:

  • 向上:为训练提供高质量的燃料。
  • 向中:为推理提供实时、可控的外部知识。
  • 向下:依赖存储、计算和网络基础设施。

没有数据 Infra,模型就是一个封闭的参数体,无法接入新鲜、私有或受控的信息。有了数据 Infra,AI 系统才真正具备了与现实世界持续交互的能力。

七、为下一篇铺路:从数据到平台与治理

数据 Infra 解决的是“模型吃什么”和“上线时查什么”的问题。但 AI 系统要长期稳定运行,还需要回答另一个问题:怎么知道系统在正常运行?怎么控制成本?怎么保证安全?下一篇就会从平台与治理的角度,讨论 AI Infra 的最后一层。

参考来源

  • IBM. What are RAG vector databases? 2026. IBM Think