这一篇讲数据层——所有其他 AI 资产所依赖的基础设施，也是很多企业在过去十年缺乏足够投入的那一层。
到目前为止的四篇文章里，我们从生成式AI堆栈的顶端一路向下——AI 该为业务做什么、它怎么完成工作、以及驱动它的智能。这一篇，我们来到堆栈的最底部：数据层。包括数据湖、管道、目录、治理——你的 AI 所依赖的"机构真相"存在的地方。对大多数业务管理者来说："AI数据"是那种每次开会感觉都在讨论同一件事、但每次又都跑到不同地方去的话题。预训练语料。检索。分析流水线。向量数据库。合成数据。嵌入。这些词，在同一场会议里出现，经常被不同的人用、指的却是不同的东西——其结果就是，关于"AI 数据"的战略讨论，大多数时候没有结果。被笼统地塞进"AI 数据"这个袋子里的，实际上是五件不同的东西——它们的性质以及与贵企业实际工作的关系完全不一样。一旦能把它们区分开来，战略就变得清晰多了。资产组合的框架,同样适用于数据——但有一个关键的"转折"：对大多数企业而言，已经存在数据治理，而AI特定的数据资产，则需要"插入"到这个已有的纪律里，而不是从零发明。
被称为"AI数据"的，其实是五件不同的事
第一，预训练数据
这是用来训练基础模型的庞大语料库——文本、代码、图像、多模态内容。数千亿、甚至上万亿的token，来源包括公开互联网、授权数据集、书籍、科学论文，以及——越来越多的——由其他 AI 模型生成的合成数据。当前的前沿实验室，在实践中大量使用合成数据。这些是那些故意制造出来，专门覆盖"有机数据"照顾不到的地方——例如逐步推理、特定领域知识等。对几乎所有企业而言，你不应该特别关心这些数据。你在租用一家替你处理预训练的实验室的模型。但你需要知道这类数据的存在，原因是——很多关于"AI 是不是在用我们的数据训练"的混乱，就源自这里。当高管们听到"训练数据"这个词，往往会默认自己企业的数据必须被这样用来训练模型。例外的情况是那些选择自托管，并对开源权重模型做预训练或继续训练的企业——这种训练通常基于专有数据。这种情况很少见，需要相当的工程能力，其战略合理性非常有限——通常是数据主权、或者非常专业的领域。对绝大多数企业，你需要知道，预训练发生在你企业的上游。第二，检索数据(RAG)
检索增强生成——通常缩写为RAG——是当下大多数企业数据在生产环境中喂给 LLM的实用机制。其内容包括：贵公司的文档、数据库、知识库、和其他积累下来的信息。当LLM需要回答问题或完成任务的那一刻，你的数据中相关的那部分会被检索出来，作为上下文交给模型。模型结合自己的预训练能力和刚刚检索到的、你公司特定的信息，来生成回应。这个检索机制，通常依靠一种叫做向量数据库的独立基础设施来支撑，通过嵌入模型(embedding model)把文本(或其他内容)转化为数值表示——这样便可以按"语义相似度"来进行高效搜索，而不再依赖"关键词精确匹配"。当模型需要回答"我们上次和 Acme 公司的客户互动谈了什么?"，检索系统按意义找出相关文档——不是匹配"Acme"这个字，而是理解这个问题在概念上最接近的内容是什么。对大多数企业来说，这是大多数实际工作发生的方式。租用模型。工程化运行框架的智能体。但是在检索这一层——什么数据可用、怎么索引、怎么按权限过滤、新鲜度如何、质量怎么维持——这是贵公司独有的任务。同时也是，对大多数企业而言，AI 在实际中能否创造价值的最大单一决定因素。一个出色的模型，在一个杂乱、过期、不完整的数据池里检索——产出的是"听起来出色的错误答案"。一个普通的模型，在一个干净、维护良好的数据池里检索——持续产出有价值的工作。
第三，分析数据，以及现有的机器学习实践
这个领域是成熟企业已经投入了多年的地方。也是关于"AI 战略"最容易混乱的地方。过去十五年，严肃的企业已经构建起数据分析和机器学习能力，覆盖四个大类:- 描述性分析(Descriptive)——发生了什么?
- 诊断性分析(Diagnostic)——为什么发生?
- 预测性分析(Predictive)——接下来可能发生什么?
- 规约性分析(Prescriptive)——我们应该做什么?
这些能力，坐落在远早于当下 AI 时刻的数据基础设施之上——数仓、数据湖、管道、治理。在成熟企业里，数据分析与 ML 实践通常已经是一个规模可观的组织，拥有自己的领导层、工具和纪律。它和我们这个系列在讨论的"基于LLM 的生成式AI"，不是一回事：- 架构不同(传统统计/经典ML模型 vs. 基于 Transformer 的语言模型)。
- 生命周期不同(数据分析通常按计划跑批；LLM推理则发生在被问到的那一刻)。
这两个世界，可以富有成效地交汇。分析的产出——预测值、客户分群得分、异常标记、推荐动作——可以作为输入上下文被 LLM 消费。与此同时，智能体可以把分析流水线当作工具调用，在需要的时候请求一个特定的预测或一段特定的分群切片。分析实践，变成了智能体系统可以"调用的一种服务"——但仍然在技术上、组织上保持独立。
很多企业最有价值的 AI 工作，会从这个交汇点产生——把已有数据实践的深厚分析力量，和基于 LLM 的推理与行动的灵活性结合起来。但是这要求清楚地认识到：两个不同的技术学科正在被结合，不是被混同。第四，微调数据
对那些选择用自己的数据微调模型的企业(上一篇讨论过的自托管场景的一个子集)而言，这是一类独立的数据：精心策划、带标签的"输入—输出"示例集，教模型在特定任务上以特定方式行事。这比预训练数据小得多——通常是几千到几十万条示例——但策划和质量管控要求很高。对大多数企业，这一类数据是空缺的；对那些做微调的企业，这是他们数据战略里最关键的一类。第五，评估数据
这一类数据，能帮助告诉你前面那些是不是在起作用——包括黄金数据集、留出测试集、用来衡量模型表现/检索质量/智能体可靠性的标注示例等。我们会在后面的文章里专门讨论评估。这里只点一下：评估数据是独立的一类，和 AI在生产中消费的数据，不是一回事。把两者混为一谈，也是企业AI项目里相当常见的错误之一。大多数企业会搞混
这个部分还是希望特别强调一下——在我观察过的几乎每一场企业"AI 数据"对话里，这部分内容都会被混淆。这个系列在讨论的、基于 transformer 架构的 LLM 智能，和大多数成熟企业已有的数据分析与 ML 能力，在技术上是相互独立的。
它们共享基础设施——都坐落在同一个数据湖之上、都触及同一套数据治理体制、都从同样的底层业务系统中消费。但它们是不同的学科——不同的团队、不同的工具、不同的生命周期、不同的价值来源。分析实践，是你数据基础设施里"已经住了多年的房客"——有既定的家具、既定的作息、既定的预期。
基于 LLM 的 AI，是一个新的房客——不同的需求(运行时检索、向量索引、嵌入管道、评估架构)、不同的节奏(同步、对话式)、不同的可靠性要求。
两个房客会共用这栋楼。它们可以是富有成效地合作的邻居。但它们不是同一回事。
战略含义便是：企业AI的讨论里，不应该假设"我们有数据实践，所以 AI 工作已经在推进了"——也不应该假设"我们现在做 AI，所以要把数据分析实践从零重建"。这两个假设都是常见错误。正确的姿势是：两个独立的学科，现在坐在同一个数据基础之上，中间有清晰的接口——而那个基础本身，需要足够扎实，以同时承载两者。大多数企业还没做、但AI特别需要的数据工作
如果你想把企业数据工作的精力放在 2026 年最重要的地方，那么下面是实际可行的议程。这其中大部分不是关于已有的数据基础设施——那是分析实践的领地——而是关于 LLM 驱动的AI所需要的"新基础设施"。第一，检索层本身
什么文档、什么数据库，对AI是可用的?谁决定"在范围里"和"在范围外"?如何管理权限——好让一个客服智能体在检索信息时，不会意外暴露另一个客户的数据?新鲜度策略是什么——新信息多快便变得可被检索到，过期信息又怎么被移除?这些不是抽象问题，是今天大多数企业隐性决定、未来需要显性决定的运营决策。第二，嵌入与索引的基础设施
哪些内容被嵌入、用哪个嵌入模型、什么样的更新节奏?向量数据库部署在哪里，容灾设计如何考虑?索引管道怎么被监控，发生了故障该怎么办?大多数企业对自己数仓的相应问题都已有成熟答案；对这套新基础设施，相应的答案还不存在。第三，让检索"变聪明"的元数据层
"能用的AI系统"和"令人失望的AI系统"之间最大的差距，通常不在模型——而在检索能不能为当下被问到的问题找到"对的"内容。这很大程度上取决于元数据：哪些内容是权威版、哪些是草稿，哪些是当前的、哪些是归档的，哪些是全公司适用的、哪些是团队专属的，哪些是高置信度的、哪些是推测性的。大多数企业今天的元数据实践薄弱——而这个弱点，一旦开始严肃的AI工作，就会痛苦地暴露出来。（现在有一类以Palantir的本体论模型为代表的工程实践，尝试建立数据的语义层，以加强LLM检索数据时的效率和准确度。关于这一部分实践，我们未来会在专题文章加以讨论。）第四，AI 特定数据与分析实践之间的连接。
如果你有预测客户流失的模型，面向客户的智能体能在对话的那一刻访问这些预测吗?这些集成，通常在技术上不难——但在组织上很难，因为它们要求分析团队和 AI 团队围绕共享接口协调。把这两个当作"分开的技术栈"处理的项目集，会错过"两者结合所能产生的大部分价值"。数据治理，现在包含 AI
上一篇推理层文章里,我提出了一个观点：组织 AI 资产——提示词、技能、工具、记忆，以及它们所坐落的数据——是一个资产组合，需要有意识地管理。数据层在这里是基础设施。而数据治理，在大多数成熟企业里，是这套"AI 资产管理"中唯一已经以成熟形态存在的纪律。大多数大型企业，普遍已经进行数据治理十年甚至更久——通常被 GDPR、金融监管、或主数据管理工程等需求所推动。角色存在（首席数据官、数据管家、域负责人）。实践存在（数据分级、血缘追踪、访问控制、保留策略）。组织体存在（数据委员会、伦理委员会）。这是一个你不需要重新发明的学科——对大多数严肃企业,它已经在那里了。AI 不要求你从零搭建数据治理。它要求你把已有的纪律，扩展到覆盖 AI 引入的新的数据资产上面。
- 检索索引与嵌入向量。撑起 RAG 的向量数据库本身就是数据资产——它以特定方式编码公司内容、带有特定偏置、以特定模式被访问。它们应该落在与原始文档相同的治理范围内，接受相同的分级、血缘、访问纪律。
- 微调数据集。对做微调的企业,这是高价值、高敏感度的数据资产,需要一流的治理——包括来源可追溯、版本管理、以及"如果数据源变化,有权重训或'反学'"的权利。
- 合成数据。越来越多企业会产出合成数据——由 AI 模型生成、从真实数据派生、用于增强训练或测试。合成数据引入它自己的治理问题：来源是什么、继承了什么偏置、对它可以做什么保证。
- 评估数据集。用来衡量 AI 表现的黄金数据集，本身就是数据资产，经常包含敏感或具有代表性的真实数据样本。它们需要与内容匹配的治理力度。
- AI 与分析之间的接口。当一个 LLM 智能体把分析模型作为工具调用时，数据在两个可能此前各自分开治理的系统之间流动。两个系统的组合，提出了两个系统单独都不会提出的治理问题。
一个2026 年称职的数据治理职能，会用它过去多年应用于传统数据资产的同一套纪律，覆盖以上这些。一个不称职的职能，才会把 AI 当成一个独立的、未治理的领域——而那条路，通往上一篇里讨论过的失败模式：碎片化、负债、丢失。对大多数企业，这一层的正确动作不是为 AI 搭建新的治理机器。把"AI 引入的新类别资产"，通报给已有的数据治理职能，把它们的章程作相应扩展。
这是最高效的路径，而且还有一个好的副作用——避免了一场"既存的数据治理职能"和"另起炉灶的 AI 治理职能"之间的地盘战。安全，简短说一下
同样的逻辑适用于数据安全。大多数成熟企业有成熟的数据安全实践——分级、传输与存储加密、访问控制、审计日志、事件响应。AI 引入的新数据资产类别——检索索引、嵌入向量、微调数据集、评估集——应该落在这些既有实践的范围里，必要时根据其特定风险特征做扩展。嵌入向量可能泄露信息。一份敏感文档的向量表示不是文档本身——但在某些情况下，它可以被反推到足以恢复出有意义的内容。敏感材料的嵌入向量，应当用对待材料本身一样的方式去对待。检索可能绕过权限。一个配置不当的检索系统，可能把一个用户在原始文档库里本来无权阅读的文档，呈现给他。保护源数据的访问控制，需要在检索层得到反映，或至少强制执行。这两件事,对处理过(比如)BI工具引入或自助分析推出的任何数据安全职能,都是熟悉的问题。类别是新的，纪律不是。这一篇留下什么
数据层,是 AI 栈的基础——也是对大多数企业而言，投资历史最长的一层。正确的战略姿势，不是"为 AI 搭建新的数据基础设施"——而是：扩展现有的数据基础以支持 AI 特定的资产，把新的、AI 驱动的工作，连接到已有的分析实践上。AI 是你数据基础设施里最新的房客，不是它的替代者。把它当作一个"需要把房东既有纪律扩展到覆盖它的需求"的房客来对待——而不是当作"重建整栋楼"的理由。
到这里为止，我们沿着参考模型走过四个分层的旅程，便告一段落。接下来，我们的讨论会转向贯穿性的两个关切——评估与基准真值，以及身份、权限与审计。每一个都值得一篇专门的文章——因为它们是让整个栈在实际中真正"可信"的纪律，也是大多数企业投入最少的地方。
夜雨聆风
