撰稿：李文朋

编辑：王一鹏

这两年 AI 发展很快，很多企业遇到的瓶颈也在变化：不再是“算力不够”，而是“数据跟不上”。

2026 年 1 月，IDC 在《边缘进化：从核心到边缘驱动成功》报告中提到：已经部署生成式 AI 的企业里，超过 60%的“实时交互类应用的响应延迟比预期高”。

很多时候，这种延迟不一定是模型慢，也不一定是算力不够，而是数据散在企业内部各处，口径不统一，质量也不稳定，关键时刻更是“找不到、拿不出、对不上、流不动”。

金融行业感受特别明显。一位城商行做数字化建设的负责人公开表示：“我们目前不缺算力，也不缺模型。缺的是能让模型真正跑起来的数据。”

模型训练成本在下降，但把数据整理好、清洗好、能实时用起来的成本反而越来越高。

2026 年初，这个问题已经不只是“体验不好”，甚至会影响商业项目的成败。IDC 在 FutureScape 里提醒称：今年，50%的 AI 驱动应用将会因为数据基础薄弱，达不到原定 ROI 目标。

事实上，数据的重要性远不止如此，更长远一点看，甚至会关系到 AI 到底能走多远。

2025 年云栖大会上，阿里巴巴集团 CEO 吴泳铭谈过一个判断：AGI 大概率会出现，但只是开始。真正的下一步，是走向能自我迭代、持续变强的 ASI。他把过程分成三段：先学会推理，再学会使用工具辅助人类，然后连接现实世界的数据，能自己学习、自己迭代。

说得更直白一点：未来 AI 更像一个“持续在线的系统”，它得不断吃到最新的数据，并把这些数据变成新的能力。数据是否能高效、持续地进入系统，变得愈加重要。

正因如此，很多基础设施厂商开始关注“更适合 AI 使用的数据”方向。数据库不再是“存数据”，而是要让数据更容易被统一管理、被实时取用、被不同类型的模型和应用调用。

2026 年 1 月 20 日，阿里云在 2026 PolarDB 开发者大会上发布了 AI 就绪（AI-Ready）云原生数据库新标准。

它想解决的事情其实很简单：让数据系统不仅能存储、查询多模态数据，还将直接驱动 AI 智能决策，让数据进入模型与业务的路径更短、更稳定，以及更安全。

阿里云资深副总裁、数据库产品事业部负责人李飞飞表示：“未来，AI 原生数据库是技术演进的必然方向。从云原生到 Al 就绪，再到 Al 原生，PolarDB 将持续深化 AI 与数据库的融合创新，加快走向超级人工智能时代。”

从行业视角看，数据库已不只是业务系统的底座，开始逐渐变成智能应用能不能跑顺的关键部分。围绕“数据怎么被组织、被使用、被转化”的变革，已悄然上演。

第一部分：数据困境的背后：是新旧时代的“不兼容”

过去很多年，企业做数据治理的“沉淀逻辑”只有一个：让人更容易做决策。

业务员、分析师、管理层要看的数据，通常得“对得上”“能解释”“表格整齐”。于是传统数据团队投入大量成本做 ETL（清洗、转换、加载），把数据整理成一张张看起来清楚、口径一致的报表。

问题是，现在数据的“主要使用者”变了：很多数据不是给人看，而是给模型用。这就会出现一种情况：对人很友好的数据，不一定对模型有用。

一个常见例子是风控。在传统的数据整理过程中，为了让报表更稳定、更好讲，分析人员往往会把极端交易、可疑行为当成离群点删掉，觉得它们会影响整体判断。

但对模型来说，删掉这些样本的结果是：正常样本越来越多，异常样本越来越少；并导致欺诈、极端风险这些关键模式识别，几乎无法归纳学习。

换句话说，在 AI 时代，“干净数据”并不等于“高质量训练数据”。

今天很多企业说“数据资产不少，但模型效果一般”，背后往往是同一类问题——现有数据的组织方式，跟模型所需要的对不上——本质就是“兼容”问题。

例如，在结构方面，企业现有数据多数是二维表格，字段清晰，适合报表和人工分析。但很多模型更需要的是向量、图结构、时间序列这些形式，用来表达关系、上下文和变化。

传统数据的维度也不够。传统指标体系更强调“少而精”，字段要能解释能展示，但模型训练往往靠大量稠密特征。很多特征单看没什么意义，要组合起来才有价值。

传统数据更新速度也慢。很多系统按天、按周更新数据，这对复盘、报表够用，但推荐、风控、运营决策这类应用，往往希望输入尽量接近实时。

传统数据格式也较为分散，不少业务系统以结构化数据为主，图像、音频、视频、传感器流等数据通常分散在各自系统里，管理不在一起，调用也不在一起。

于是看上去数据资产很多，但真正能直接拿来训练、推理的数据，比例并不高。

大家越来越接受一个现实：2026 年，数据本身将决定 AI 模型的能力天花板。为了缓解上面的这些“对不上”问题，“AI 就绪数据”（AI-Ready Data）应运而生。

它想表达的不是一个新概念，而是一件很具体的事：数据要经过专门的整理、特征化和组织，以更小的工程成本直接用于训练、推理和决策。

AI 就绪数据，通常会包含几类要求：首先，特征要够用，不是“有数据”就行，而是要有足够细的维度，让模型有东西可学。

比如做用户行为建模，只保留“总次数”“总金额”通常不够，还需要时间分布、品类偏好、渠道差异、设备类型等细节等。

其次，标签也要准，需要监督学习的场景里，标签相当于“题目答案”。标签粗、标签不一致，都会拉低模型上限。这就要求，图像分割、文本抽取都要尽可能精确。

同时，样本要尽可能覆盖真实世界，因为现实业务不会只落在“平均值”上。所以实践中会强调覆盖长尾：高峰期、极端天气、罕见故障、少数群体、低频行为等。这些数据从报表角度不一定好看，但对泛化能力很重要。

最后，数据也要能跟着变化更新，很多传统的数据质量体系把数据当“静态资产”，但用于智能应用时，数据要像“动态输入”。常见要求包括：按合适频率引入新样本；对明显过时的数据标记或降权；根据线上表现迭代数据集。

过去两年，很多企业在数据库和数仓之外，再搭特征平台；要实时就接流计算；要多模态就加向量库、图系统；最后再用调度、同步、API 网关把这些拼在一起。

这种做法在试点阶段通常能跑起来，但场景一多、频率一高、数据类型一复杂，架构复杂度和运维成本就会上去。因此，越来越多的方法论开始强调：与其在旧框架上不断加组件，不如从底层重新规划面向智能应用的数据底座。

在产品层面，一些云数据库厂商正在调整定位：不只做“关系型数据库”，而是把自己当作智能应用的数据基础设施。

比如阿里云云原生数据库 PolarDB 的产品理念，就强调在云原生架构上，配合湖库一体等能力，去支撑结构化、半结构化以及非结构化数据的统一管理，为“AI 就绪数据”提供底层能力等。

PolarDB 还首次系统定义了“AI 就绪数据库”的 4 大核心支柱，分别是：多模态 AI 数据湖库、高效融合搜索能力、模型算子化服务，以及面向 Agent 应用开发的后端服务。

这是通过将多模态存储、搜索、推理和后端开发套件深度集成到数据库内核，满足企业多模态搜索、问答、数据处理、标注等需求，将复杂的异构架构简化为统一的智能化底座。

从这个角度看，AI 就绪数据会越来越像企业的“基础配置”：这不是为了追趋势，而是为了让后面的应用能更智能、更高效、更安全地跑起来、跑下去。

第二部分：行业正想尽办法，让数据处理实现加速

如果说“AI 数据就绪”解决了数据能不能用，那么“数据处理速度”则决定这些数据能否“实时”产生价值。

经过不少实践后，大家慢慢形成一个判断：同一份信息，发生在“刚刚”和“昨天”，对业务价值可能不是一两倍的差距，而是会差一个数量级。

以淘宝为例，数据显示电商运营数据的实时监控能够让决策效率提升 40%以上。某头部淘宝店铺通过自主搭建实时数据采集和分析系统，将数据延迟控制在 1-5 分钟后，运营效率和业绩直接提升 30%。

风控领域的收益更明显。一次异常交易判断窗口往往只有秒级：秒级识别，损失只是几百元；第二天发现，可能已经数百万。对金融机构来说，实时数据不是“体验优化”，而是成本。

问题在于：今天大多数企业的传统数据链路，并不是为“实时”设计的。最典型数据处理路径就是：从业务数据库，到 ETL，再到特征平台处理，进行特征缓存，最后供模型调用。

这条链路长、环节多，每一步都会带来延迟。所以这两年行业里出现一个变化：大家开始关注能不能少搬点数据，少绕几道弯。因为数据在系统之间来回搬运、复制、同步，本身就是时间和复杂度的来源。

从这个角度看，很多数据“新架构”绕来绕去，其实想解决的是同一件事：让数据尽量留在一个更统一的底座上，把处理、检索、计算尽量在同一套体系里完成，把链路缩短简化。

PolarDB 这次讲的“AI 就绪云原生数据库”，基本就是沿着这个思路在做。

过去几年企业反复提“湖仓一体/湖库一体”，说白了是因为两套系统各有短板：数据湖便宜、能存很多、数据类型也更杂，数据库查询强、事务能力好，可一旦规模大、成本就上来了，对大规模非结构化数据也不友好。

结果就是数据经常搬来搬去：为了分析，把业务数据抽到湖里；为了在线服务，又从湖里挑一部分加工后装回库或特征仓。每搬一次，就多一次复制、多一次同步、多一段延迟。

此次，PolarDB 发布的—AI 数据湖库（Lakebase）解决方案，就是专为实现“湖库—体”架构而设计的。

AI 数据湖库尝试把结构化、半结构化，以及非结构化数据，都放在同一个平台里统一存取和处理，减少来回同步，让链路变短。与此同时，它还配了缓存加速能力，针对不同场景做 I/O 和带宽的加速，让海量数据在底座里流转得更顺。

这让数据从“产生”到“能用”的时间缩短，很多场景能从小时级压到分钟级，甚至更低。

这是加速的第一步：少搬数据。但湖库一体更多解决的不止是“搬运成本”，还有个更隐蔽、也更容易被忽略的卡点：推理路径。

传统架构里，数据库只负责存储和查询，推理模型是独立的外部服务。这样做的结果是：应用需要先从数据库取特征，再送给推理服务推理，最后把结果写回或返回业务。

每一步看起来都不慢，但数据序列化、网络传输、排队等待加起来，延迟就会暴增。

PolarDB 这次的思路不太一样：它不是把推理当成“外挂”，而是希望把推理内化为数据库的原生能力。

它的做法是，通过多模态引擎与独有 In-DB 模型算子化的深度集成，开发者可以在 PolarDB 库内直接完成语义检索与推理加工，在效率显著提升的同时，确保数据不出域，保障隐私合规。

具体方面，通过 LLM SQL 接口封装阿里云百炼各类模型构建 PolarDB 模型算子，开发者在 SQL 里可以直接调用推理能力——不用数据出库，不用中间转换，一条查询就完成"找数据→检索语义→推理加工→返回结果"整个流程。

为了支撑这套库内推理，PolarDB 还对底层做了分层优化，创新性地融合了 KVCache、图数据库与向量技术，构建了兼顾长短期记忆与低算力消耗的检索方案。

换句话说，AI 数据湖库不再只是提供"看数据接口"，而是变成"数据和模型直接对话的场所"。

当然，要让推理少绕路，还有个前提：数据库要顶得住 Agent 的高频访问。

Agent 在执行任务时，可能会发起大量查询来验证和规划，如果数据库是“存储和计算绑在一起”，高频查询的计算压力会直接拖垮存储稳定性。

云原生数据库 PolarDB 的设计是通过存算分离来解决这个问题：计算节点独立扩缩，高并发查询主要消耗计算资源，不会拖垮存储。遇到 Agent 高峰期的访问洪峰，可以独立扩计算而不用扩存储，成本和效率都会提升。

除了架构分离，PolarDB 还在应用和功能层做了专门设计。

PolarDB 新增 AgentMemory 能力，提供长短期记忆表结构模板，自动管理对话历史和上下文。开发者不需要自己拼 SQL、维护索引，Agent 每一轮对话都被自动记录，下一轮查询时自动成为上下文的一部分。

在执行层，PolarDB 提供自然语言工具调用（NL2SQL 自动解析与执行），Agent 可以用"问问题"的方式检索复杂知识。同时支持多模态数据融合，让 Agent 能在一次查询里实时融合文本、向量、图关系的检索结果。

结合基于 Supabase 的 Agent 统一部署与托管，PolarDB 为企业提供工业级 Agent 开发框架。从多租户隔离、Serverless 自动扩容、到运维自动化，所有工程复杂度都被打包进框架里，开发者只需专注定义 Agent 的行为和目标即可。

这样一来，开发者收获很明确：存算分离让高并发和性能更容易同时拿到，AgentMemory+NL2SQL+多模态融合让 Agent 的记忆、检索、推理更像是数据库原生支持的事；工程上的托管和 Serverless 减少了部署、扩容、监控这些杂事难题。

整体看下来，数据行业的这轮"加速"并不只是把某个指标做快，而是在做一件更底层的事：让数据少移动，让推理少绕路，让 Agent 的高频快速访问有专门架构支撑。

链路短了，实时能力才更容易稳定下来，也更容易规模化，不至于每个场景都要重新搭一套。

第三部分：当 AI 反哺“数据”，AI-Native 成为可能

从行业看，2026 年很可能会成为多 Agent 协同大规模落地的起点。

这不是因为单个 Agent 的能力突然跃升，而是因为多个 Agent 协同工作能够产生涌现效应——它们可以相互验证、相互纠正、共同规划复杂任务，从而完成单一模型难以胜任的工作。

当 Agent 大规模走向自主决策与协作时，可能在一秒内对数据库发起成千上万次查询——先查一遍，根据结果修正假设，再查一遍，调整策略，反复循环，直到找到满意的答案。

如果要承载 Agent 这种近乎“暴力”的访问模式，就必须引入一种全新的数据库形态——AI-Native 数据库。

AI-Native 数据库也需要从根本上改变与 Agent 的交互方式。最核心的转向是：从 SQL 的"精确匹配"扩展到"语义级检索与推理式访问"。

这意味着数据库不再仅仅回答"这个值是什么"的问题，而是要回答"这个值意味什么"、"这条数据与另一条数据在语义上有什么关联"、"基于这些信息，下一步应该怎么做？"。

而要做到这一点，AI 相关的数据能力不能只做成外挂，而要成为数据库的“内生智能”。例如在存储层支持向量索引，在查询层支持相似度检索，在优化层针对向量查询做专门优化等。

大会上，PolarDB 提出“AI 就绪的云原生数据库”的概念，就是为了推动数据库实现从“外挂式”集成 AI 到“内生智能”的进化，这也是走向 AI-Native 的过渡。

关于 AI-Native 数据库，另一个同样重要、却常被低估的变化，是对数据动态性的重新认知。

在 AI 时代，高质量数据并不是一次性定义出来就能长期使用的：今天仍然有效的数据集，可能因为新的应用场景或模型路线，变得不再匹配。这需要 Agent 持续学习、持续适应新环境，相应的数据特征也会随之变化。

很显然，传统数据仓库“每天一次、每周一次”的更新节奏明显跟不上，AI-Native 数据库需要支持更实时、更持续的数据优化。

好的一面是：被数据“喂养”的 AI，正在获得反过来“反哺数据”的能力。

过去的数据清洗、整理与验证高度依赖人工：工程师写脚本，分析师定规则，QA 定期抽检，流程慢且容易遗漏。现在，具备推理与决策能力的 Agent 已可以把一部分治理工作自动化。

比如，让 Agent 获得对数据库的“写权限”：把自己的思考过程、决策日志写入数据库，沉淀为训练样本；把推理中得到的新知识、新规律固化到数据层。更进一步，当 Agent 在执行任务时发现脏数据、明显错误或不一致，它可以自动触发修正流程，而不是等人工排查。

当这些机制形成闭环，数据库就能更快产出“最新、可用、被校正过”的数据，并把反馈链路压到更短的延迟。

可以想象一个场景：某个 Agent 在做客户风险评估时，发现了一类新的可疑交易特征。它把该特征写入数据库并触发检测规则；规则自动回扫历史数据，标注出相似交易；评分模型读取新标签，更新客户风险等级。整个流程自动闭环，同时数据一致性仍然受到约束与保障。

从更宏观的角度看，这意味着 AI+Data 正在形成一个自循环系统：AI 消费数据、理解数据、改写数据，数据再反过来塑造 AI 的行为与能力。

未来的超级智能（ASI）将不再是一个孤立模型，而更像是一个持续运转的系统：它既是数据的使用者，也是数据的生产者和优化者。数据不再只是被存放的资源，而是一种被不断加工、更新的运行态。

这个循环的速度越快、效率越高，整个系统的智能水平就越高。而承载这个循环的核心基础设施，一定是 AI-Native 的数据库系统。

回到 PolarDB 大会发布的一系列能力：AI 数据湖库（Lakebase）减少数据搬运，多模态多引擎融合扩展可管理的数据类型，模型算子化把推理拉回数据库内部，以及面向 Agent 应用开发的托管能力。它们看起来是分散功能，但放在一起更像一套完整路径——让数据库在 AI 时代重新站到系统中心。

这意味着一次更深的范式转移：从 2025 到 2026，数据库产品、数据架构与 AI 应用之间的边界在变得模糊。企业 IT 也可能从“多个专用系统拼装”转向“围绕一个 AI-Native 数据库组织数据、计算与决策”。

在这个背景下，未来谁能更快完成从云原生到 AI 原生的迁移，谁就更有机会在下一轮基础设施竞争中占据优势。