AI 数据平台架构设计：从 RAG 到 Agent 的数据基础设施

企业在推进 AI 应用落地时，最先遇到的瓶颈往往不是模型能力不足，而是数据"喂不进去"——传统数据平台的表结构、ETL 管道和权限体系是为人设计的查询接口，不是为 AI Agent 设计的上下文供给管道。构建 AI 就绪的数据基础设施，需要从架构层面重新思考数据平台的角色定位。

从 RAG 到 Context Engine：AI 对数据需求的演进

2023 年 RAG（检索增强生成）成为企业接入大模型的主流方案，其核心思路是将企业文档切片后存入向量数据库，查询时检索相关片段拼入 Prompt。这种模式解决了模型幻觉问题，但暴露了新的瓶颈：当企业有数十万篇文档、多语种、多格式内容时，简单的向量检索召回率不足，上下文窗口利用率低下，回答质量不稳定。

2025 年起，行业开始将 RAG 升级为 Context Engine——不再只是"检索后塞入 Prompt"，而是构建一个能理解查询意图、多路召回、动态排序、压缩去重、自适应拼装的上下文工程系统。Context Engine 需要的数据能力远超传统 RAG：实时流式数据接入、多模态索引、结构化与非结构化数据联合查询、细粒度权限过滤。这些需求推动数据平台从"为人提供报表和查询"向"为 AI 提供高质量上下文"演进。

AI 原生数据平台的分层架构

根据中国信通院《AI 原生数据平台研究报告》的定义，AI 原生数据平台需要在传统数据平台基础上新增三个关键层次。

数据供给层负责全域数据的统一采集和接入。与传统数据平台只关注结构化数据库不同，AI 数据平台需要同时处理日志、消息队列、文档、音视频、API 接口等异构数据源。关键能力包括：CDC（变更数据捕获）实时同步、非结构化数据的元数据提取、跨源数据血缘追踪。这一层的目标是让 AI Agent 能在一个统一的语义层访问所有企业数据，而不需要知道数据物理上存在哪里。

上下文管理层是 AI 数据平台区别于传统数据平台的核心层。它负责将原始数据加工成 AI 可消费的上下文单元。具体包括：文档智能分块（chunk）与标注、向量化索引与混合检索、知识图谱构建与实体关联、时间窗口管理与数据新鲜度控制。这一层的难点在于分块策略——太大的 chunk 会稀释关键信息，太小的 chunk 会丢失上下文。业界实践表明，按语义段落分块配合重叠窗口（overlap 50-100 tokens）在大多数场景下效果最优。对于表格数据，则需要行列级别的结构化索引而非简单的文本化处理。

AI 服务层将加工好的上下文通过标准化接口暴露给各类 AI 应用。2026 年 MCP（Model Context Protocol）协议的普及正在改变这一层的设计范式——AI Agent 不再需要针对每个数据源编写专用适配器，而是通过 MCP 协议的统一 Tool 描述发现和调用数据服务。这意味着数据平台需要将每个数据表、每个知识库、每个实时流都封装为符合 MCP 规范的 Tool，包括清晰的输入参数描述、输出 schema 和调用限制声明。

从报表驱动到意图驱动的数据消费模式

传统数据平台的消费模式是"人写 SQL，系统返回结果"。AI 数据平台的消费模式是"Agent 表达意图，系统自动规划数据获取路径"。这种转变要求数据平台具备语义理解能力——不是匹配 SQL 关键词，而是理解"分析上季度华东区销售下滑原因"这样的自然语言意图，并自动分解为：拉取华东区销售明细、对比同比数据、关联促销活动日历、检索客服工单关键词。

实现意图驱动的关键技术包括：Text-to-SQL 引擎、多步推理规划器（Planner）、数据探查（Data Profiling）自动化。其中 Text-to-SQL 不是独立工作的——它需要高质量的数据字典（包含字段含义、枚举值说明、业务规则注释）作为上下文，否则生成的 SQL 经常逻辑正确但业务语义错误。

架构选型的关键权衡

构建 AI 数据平台面临几个核心权衡。实时性 vs 成本：向量索引的实时更新成本远高于批量重建，需要根据数据变化频率选择增量更新或定时重建策略。通用性 vs 精度：通用向量检索覆盖面广但精度不足，专用知识图谱检索精度高但构建成本大，实践中通常采用混合检索方案。开放性 vs 安全性：MCP 协议的开放生态降低了集成门槛，但也意味着数据访问路径增多，需要更精细的权限控制和审计能力。

另一个容易被忽视的问题是数据质量治理。AI 对数据质量的容忍度远低于人类分析师——一个缺失的字段值在 SQL 查询中会显示为 NULL，用户会自行判断；但在 RAG 检索中，脏数据会直接污染模型输出，且用户难以察觉。因此 AI 数据平台需要在数据入库阶段就建立质量校验机制，包括完整性检查、一致性校验和异常值标记。