AI 没换引擎，却把数据栈的账算穿了

AI 代理写 SQL、DuckDB 算数、Polars 2.0 改默认值、向量库悄悄吃掉十几个 GB——过去几个月，数据工程圈发生的这几件事看似不相干，其实指向同一个结论：AI 没有更换查询引擎，但它重构了数据的接口层、成本结构和确定性边界。

账单不会说谎，确定性也不会。看清这三件事，比追任何一个新概念都值钱。

🤖 代理来了，查询引擎却没换

先看一个正在真实发生的场景。InfoQ 刊载的 Peihao Yuan 的文章描述了一条灾难恢复分析工作流：AI 代理理解分析需求，生成带约束的 SQL 或 Python 脚本，DuckDB 在 Parquet 文件上执行计算，产出可复现的事实结果，最后再由代理来解读这份数字。

这条链路的关键，不在于代理有多聪明，而在于计算被锁死在了确定性引擎里。

文章把它称为"确定性切分"：大模型负责意图理解和结果叙述，但真正产出数字的那一步，必须交给一个可重放、可审计的引擎。分析要能重放，结论才有信用——这是 LLM 时代数据分析的第一性原理。

产业逻辑也很直白：过去十年数据栈的演进，是在换引擎——从 Hive 到 Spark 到各家湖仓；而 AI 带来的变化是在引擎之上加了一层"接口"。SQL 还是那个 SQL，Parquet 还是那个 Parquet，变的只是谁来发起查询、谁来解释结果。

据多位接近一线数据平台团队的人士反馈，今年许多团队接 AI 代理的第一件事不是买新数据库，而是把历史查询封成约束模板、把数据落到对象存储上的 Parquet——接口先行，引擎殿后。

🧾 向量的账单，藏在调用费后面

给知识库算成本，几乎所有人第一反应都是 embedding 调用费。博主 大Token 做了一次摊开式的实测：用 Python 3.13 标准库纯算术测了 100 万条文本块、每块 500 token 的向量到底占多少地方。

OpenAI 官方文档写明，text-embedding-3-small 默认 1536 维。按 float32 存储推算，单条向量约 6KB，100 万条原始向量就要吃掉约 6GB；换 text-embedding-3-large，体量直接翻倍。这还没算索引结构、元数据和原文本身。

这笔账的产业含义是：向量是资产，更是负债。每一次维度升级、每一次重建索引，存储成本都会跟着抖动。很多团队建完知识库才发现，检索系统的长期持有成本结构，和当年数据仓库的"存储便宜查询贵"完全相反——它是"算一次、存一辈子、越存越贵"。

因此，面向 AI 的数据架构设计，第一张表不该是模型对比表，而是存储与索引的容量规划表。建库之前，先把 1536 维和 3072 维的账摆在桌上。

⚠️ Polars 2.0 把确定性调成了默认关闭

2026 年 10 月 6 日发布的 Polars 2.0，改了一个很多数据管道"依赖着却不知道"的默认值：对 LazyQuery 调用 collect() 时，默认跑流式引擎，而流式引擎不再保证 join、group_by、unpivot 的输入行序，除非显式设置 maintain_order。

实测很扎心：在 polars 2.0.0 上，一个 200 万行的 inner join 默认返回的行序已经乱了；加上 maintain_order 后顺序恢复。外存计算也默认打开——内存用到约 80% 就开始落盘，磁盘预算默认 64GB。

Ritchie Vink 在发布文章里用一句话概括了这次切换：collect() 默认流式，带来大幅的内存与性能收益。这句话没错，但水面之下是另一件事——性能是用确定性换的，只是这笔交易没找用户签字。

如果你的管道在做逐行比对，或者写出的文件会被下游按位置读取，同一份代码在不同机器上可能给出不同结果。发布基准还是厂商自跑的，脚注里也写明不可与官方 TPC 结果比较——选型时，这类数字要打个问号再放进 PPT。

🗺️ 四个信号，决定引擎去留

把前两件事合起来看，会出现一个经典的选型问题：什么时候嵌入式引擎（DuckDB、Polars 这类单机利器）就够了，什么时候必须上托管湖仓？

Peihao Yuan 的文章给出了"四个信号"的判断框架。结合业界实践，这四个信号可以归纳为：数据体量是否超出单机内存与磁盘的舒适区、并发分析人数是否从个位数涨到团队级、数据更新频率与协作流程是否需要统一的目录与权限、以及合规与 SLA 是否要求托管的高可用与审计能力。

四象限的读法很朴素：左下角是今天就能落地的高性价比区，右上角是规模逼出来的必选项，左上角是潜力但尚未证明协作能力的新玩家。

一个务实的路线是：先嵌入式起步，把数据接口规范好（Parquet + 受约束 SQL），AI 代理跑通分析闭环；四个信号亮起两个以上，再迁移到托管湖仓。迁移成本最低的架构，恰恰是接口层标准化做得最彻底的那个。

🧭 确定性正在变成新的治理指标

三条线索串起来，能看到同一个趋势的不同侧面。

AI 改变了数据接口——代理不再直连 BI 工具，而是通过受约束查询直达计算引擎；AI 同时抬高了隐性成本——向量让"存储"从后台成本变成知识库的核心负债；AI 还放大了确定性的风险——流式引擎默认放弃行序，在人类分析师手里是小事，在自动化代理管道里就是连锁事故：代理读到一份行序错乱的结果，解读出的结论会被无限放大和复用。

所以接下来两年，数据团队真正该补的课不是再学一个新引擎，而是把"确定性"当成一等公民写进治理规范：哪些查询必须可重放、哪些管道必须断言行序、哪些存储决策要过成本评审。

引擎会一直换，接口会一直变，但可复现的数字，永远是数据团队最硬的通货。

小结： AI 没有淘汰 SQL 和查询引擎，它做的是三件更隐蔽的事：重构接口、抬高隐性成本、放大确定性的风险。嵌入式引擎与托管湖仓之间不存在唯一答案，四个信号才是决策依据。下一步值得盯的是：当代理成为数据的主要消费方，"结果可重放"会从工程美德变成产品刚需——谁先把它做成默认能力，谁就拿到了 AI 数据栈的入场券。