从做数仓到做 AI 数据底座，到底该补什么能力？
先说结论。
从数仓走向 AI 数据底座，数据人不需要把自己改造成算法工程师，真正需要补的是六项能力：
多源与非结构化数据工程
业务语义建模
知识与上下文加工
检索与数据服务
AI 评测
持续治理与运营
从数仓到 AI 数据底座的技能架构图
数仓能力没有过时，但只会把数据做成表、指标和报表，已经不够了。
过去，数据团队主要解决“数据能不能算出来、查出来、展示出来”。
现在，还要继续解决：模型能不能找到正确数据，能不能理解业务含义，能不能按权限调用，输出能不能验证，出了错误能不能追溯和修正。
这就是从数仓到 AI 数据底座最核心的变化。
一张表看清两者差异
所以，AI 数据底座不是数仓旁边再加一个向量库，也不是做一个企业知识库。
它是在原有数据体系上，增加一套面向模型和智能体的数据供给能力。
1. 多源与非结构化数据工程
过去数据人主要处理数据库、日志、接口和文件表。
AI 场景里的数据范围更大：制度、合同、邮件、报告、会议纪要、产品资料、图片、扫描件、音视频，都会成为模型的输入。
这些内容不能简单上传到知识库。
还要完成解析、清洗、去重、分段、版本识别、权限标记和增量更新，最终形成可检索、可引用、可维护的知识单元。
数据人需要补的，不只是 OCR、切片和向量化这些工具操作，而是把非结构化内容纳入正式数据工程体系的能力。
最终交付物不再只是一张表，还包括：
可管理的文档集合；
带来源、版本和权限的知识片段；
可持续更新的内容加工链路。
这仍然是数据工程，只是加工对象从表和字段扩展到了企业内容。
2. 业务语义建模
模型看到字段，不等于理解业务。
一张表写“客户类型”，另一张表写“用户等级”，制度里写“重要客户”，销售人员平时说“大客户”。人可以凭经验判断它们之间的关系，模型只能根据已有信息猜。
智能问数项目里，最常见的问题往往不是 SQL 生成失败，而是同一个“销售额”“活跃客户”“新增用户”，在不同主题中使用了不同口径。
模型没换，数据源也没换，把指标定义、适用范围和对象关系整理清楚以后，答案才开始稳定。
因此，语义建模需要明确：
企业有哪些核心业务对象；
指标如何计算；
对象之间是什么关系；
哪些词是同义词，哪些只是看起来相似；
定义在什么时间、组织和场景下有效；
出现口径冲突时，由谁裁决。
过去，这些内容常藏在 SQL、报表说明和老员工经验里。
AI 上线以后，必须把它们变成机器可以读取、系统可以执行的语义资产。
3. 知识与上下文加工
把文档切成块，不等于模型已经得到合适的上下文。
模型回答一个问题时，真正需要的是：
与问题相关的内容；
足够完整的上下文；
正确的版本和来源；
当前用户有权看到的信息；
必要的业务规则和历史背景。
材料不是越多越好。无关信息太多，反而会干扰模型判断。
因此，数据人要从“数据加工”继续走向“上下文加工”：决定什么信息应该进入模型，按什么粒度进入，哪些内容需要组合，哪些内容必须排除。
元数据在这里也会发生变化。
过去元数据主要帮助人找表、看口径、查血缘；现在还要告诉模型：数据来自哪里、指标是什么意思、内容是否有效、谁有权使用。
4. 检索与数据服务
AI 应用不是只查文档。
一个客服 Agent 判断客户能否享受优惠，可能要先查制度，再查客户等级、当前套餐和历史消费，最后调用接口创建工单。
这里既有知识检索，也有结构化查询和业务操作。
数据团队需要补两类能力。
第一类是检索能力：
关键词检索；
向量检索；
混合召回；
排序和过滤；
结构化与非结构化数据的联合查询。
第二类是服务化能力：
指标服务；
查询 API；
实时数据服务；
Agent Tool；
权限校验、日志、重试、超时和回滚。
过去，表建好以后，下游自己查。
现在，数据能力要被封装成模型和 Agent 可以稳定调用的服务。
5. AI 评测
这是很多同类文章最容易漏掉的一项。
数仓上线前要对账，AI 上线前同样需要自己的“对账”。
要检查的，不只是数据本身对不对，还包括：
是否找到正确证据；
是否误用了过期内容；
回答是否真的得到证据支持；
遇到证据不足的问题，能否拒绝回答；
不同权限用户是否得到正确范围的内容；
系统升级后，原来答对的问题有没有变错。
所以，AI 数据底座还要建设评测数据：
标准问题；
正确答案和证据；
边界与越权案例；
线上失败样本；
版本回归测试。
没有评测集的 AI 应用，就像没有对账规则的数仓：能运行，但没人知道它什么时候会错，更不知道改完以后有没有变好。
6. 持续治理与运营
很多 AI 项目的第一版不难，难的是三个月以后。
新文件持续进入，旧制度不断修改，指标口径发生调整，人员权限发生变化，模型和检索组件也会升级。
这时必须回答：
谁确认文件是否仍然有效；
谁维护业务术语和指标；
谁决定哪些数据可以进入模型；
谁分析一次错误到底出在数据、语义、检索还是模型；
谁能阻止一个不稳定的 Agent 进入业务流程；
修正以后，谁负责验证问题真的解决了。
责任不能全部压给数据团队。
业务部门负责场景、规则、例外和结果采信；数据团队负责数据供给、语义资产、质量、来源和追溯；AI 与平台团队负责模型、检索、工具调用和系统运行。
AI 数据底座真正需要的，不是一个部门兜底，而是让这些责任沿着同一条链接起来。
原有能力怎么迁移
数据人不需要抛掉过去重新开始。
真正需要做的，是把原有能力延伸到模型使用数据的那一段。
最现实的三步升级路径
第一步，做一个带评测的企业文档问答。
选一批真实制度或产品资料，完成解析、检索、引用、版本、权限和标准问题集。
验收标准不是“能够回答”，而是能说明为什么答对，错误出在哪一环。
第二步，接入结构化经营数据和语义。
让同一个问题既要查文档，也要查指标和明细，补齐业务术语、指标口径、对象关系和适用范围。
验收标准不是“能够生成 SQL”，而是能发现口径冲突，并说明最终采用了哪个定义。
第三步，加入工具调用和持续治理。
让 Agent 在明确权限下调用查询或业务接口，同时建立日志、失败样本和版本回归。
验收标准不是“Agent 可以执行”，而是权限可控、操作可追溯、系统升级后可以重新验证。
做到这一步，建设的才不只是一个演示型知识库，而是一条可以长期运行、持续纠错的 AI 数据供给链。
最后
从做数仓到做 AI 数据底座，数据人真正要补的，不是几个热门工具，也不是从零学习模型训练。
而是六项能力：
多源数据组织；
业务语义建模；
知识与上下文加工；
检索与服务；
AI 评测；
持续治理与运营。
以前，数据人主要负责把数据做出来。
接下来，还要让机器找得到、看得懂、用得对，出了问题还能查得清。
