AI没有杀死SQL，先捅了确定性一刀
📋 总体概括
从AI代理生成SQL跑DuckDB，到向量库的真实持有成本，再到Polars 2.0默认流式引擎牺牲行序，2026年数据基础设施的三条主线指向同一件事：AI改写的是数据接口层，而不是查询引擎层。确定性与性能的取舍、调用费之外的隐性账单，才是这一轮变革的真正胜负手。
📄 正文
2026年，数据基础设施圈最有意思的三件事，都和同一个词有关：确定性。
InfoQ 刊出了一篇讲 AI 代理加 DuckDB 灾备分析工作流的文章 [^1]；微博博主「大Token」摊开算了一笔向量存储的账 [^2]；Polars 2.0 默认切换流式引擎，让无数管道悄悄丢掉了行序保证 [^3]。三件事看似不相关，其实指向同一个判断——AI 改写的是数据的接口层，而不是查询引擎层。谁在写查询变了，怎么算、算多准、算多少钱，老问题一个都没少。
🧭 AI 不该碰计算，只该碰语言
先讲一个场景。某企业做灾备恢复演练，数据团队最怕的不是数据丢了，而是恢复出来的分析结果没法复现——你说损失是 300 万，审计问一句「怎么算的」，没人答得上来。
InfoQ 上 Peihao Yuan 的文章给出的解法很「反潮流」：不让 AI 大包大揽，而是把活儿拆开。AI 代理负责理解意图、生成受约束的 SQL 或 Python；真正的计算交给 DuckDB，直接在 Parquet 文件上跑，产出可复现的事实（facts）；AI 再回头解释这些结果 [^1]。
这就是所谓「确定性切分」（determinism split）：把不确定性关在语言层，把确定性留在计算层。大模型生成 SQL 可能每次不一样，但 DuckDB 对同一份 Parquet 跑同一条 SQL，结果必须一模一样——这条「可重放」（replayable）的底线，恰恰是传统 BI 和数仓花了二十年建立的信任基础。
很多数据团队的私下共识是：AI Agent 可以进分析流程，但绝不能成为「黑盒计算器」。一旦查询结果不可复现，整个数据体系的公信力就塌了。
产业逻辑也很清楚：AI 改变的是谁在写查询——从分析师写 SQL，变成代理生成 SQL。但底层引擎的核心价值主张没变：快、便宜、可复现。那些宣称「AI 让数据引擎过时」的叙事，要么没做过灾备演练，要么在卖别的东西。
🔋 向量的账单：调用费只是首付款
做知识库的朋友，大多数只算过一笔账：embedding 调用费。很少有人算第二笔——向量本身占多少地方。
微博博主「大Token」用 Python 3.13 标准库写了个纯算术脚本，把账摊开了 [^2]：场景是 100 万条文本块，每块 500 token。按 OpenAI 官方文档，text-embedding-3-small 默认输出 1536 维，text-embedding-3-large 默认输出 3072 维，两者也都支持 dimensions 参数做降维 [^4]。
先把最直观的两笔算清楚：
调用费：100 万块 × 500 token = 5 亿 token。按 OpenAI 官方定价，text-embedding-3-small 为 $0.02 / 百万 token，合计约 $10；换 text-embedding-3-large（$0.13 / 百万 token）则约 $65 [^4]。这个数字确实不吓人——所以人人都只算这一笔。
存储量：一个 1536 维向量，按 float32 存储，每维 4 字节，单个向量约 6 KB；100 万条就是约 6 GB 裸数据。若用 3072 维的 large 模型，直接翻倍到约 12 GB。
水面之下的部分才是重点。裸向量 6 GB 只是下限：主流向量库的 HNSW 类索引通常要额外占 1.5–3 倍空间，且为了检索延迟往往要求常驻内存——这意味着 6 GB 裸数据在真实部署里很容易变成 15–20 GB 的内存持有成本，云上按量算，一个月就是几十美元起步，而且随数据量线性增长。再叠加重复嵌入：换一次模型，$10 的调用费是小头，全量重算的时间、迁移期间的新旧双份存储、以及检索结果的一致性验证，才是真正看不见的开销。
这笔账的关键不是某个具体数字，而是成本结构的转变。传统数据分析里，存储是资产、计算是流量；到了向量检索这里，很多人下意识把 embedding 当成「一次调用、一次付费」的流量生意。但 100 万个 1536 维向量是要长期持有、反复检索、还要随源数据同步更新的——它是一笔持有成本，而且是复利的那种。
更隐蔽的是「重复嵌入」陷阱：一旦你换了 embedding 模型，或者调整了分块策略，全量重算的调用费和存储迁移成本会再来一遍。据不少做过大规模 RAG 落地的工程师反映，这类隐性成本在项目预算里几乎从不出现，上线后却经常成为压垮 ROI 的最后一根稻草。
产业判断：随着 RAG 从尝鲜走向生产，向量存储正在从「AI 的周边问题」变成存储架构的一等公民。向量该放专用向量库、对象存储、还是干脆放进湖仓统一管理，会成为未来两年数据平台选型的高频争论点。只看调用费做预算的团队，账本迟早对不上。
⚠️ Polars 2.0 的默认值，捅了很多管道一刀
如果说前两件事是「新问题」，Polars 2.0 干的这件事，是往老问题上补了一刀。
10 月 6 日，Polars 2.0 发布。创始人 Ritchie Vink 在发布文章里用一句话描述了核心变化：LazyFrame.collect() 现在默认运行流式引擎（streaming engine），带来「巨大的内存和性能收益」[^3]。听起来全是好消息，直到你看细节——
2.0正式发布
collect默认流式引擎
join等不保证行序
约占RAM80%触发溢写
磁盘预算默认64GB
对于 join、group_by 和 unpivot 这三类操作，流式引擎不再保证输入行序，除非你显式设置 maintain_order。这不是文档里的脚注级小事。发布团队自己在 polars 2.0.0 上做了验证：一个 200 万行的 inner join，默认配置下返回的行就是乱的；加上 maintain_order，顺序才保住 [^3]。
对很多管道来说，行序是「依赖了但自己不知道」的隐式契约。如果你的代码逐行比对输出，或者写出一个文件、下游按位置读取——那么换一台机器跑，结果就可能不一样。这就是典型的静默 breaking change：不报错，只是悄悄给错。
还有两个默认值值得注意：out-of-core 处理默认开启，内存用到约 80% 就开始向磁盘溢写，磁盘预算默认 64 GB [^3]。对内存紧张的机器，这是救命的；对磁盘配额敏感的环境（容器、Serverless），这是新的故障点。
顺便提一句克制的好习惯：发布文章里那组亮眼 benchmark 是厂商自测，脚注明确写了结果不可与官方 TPC 成绩对比 [^3]。看厂商跑分，先看脚注。
产业逻辑很直白：Polars 用行序确定性，换了内存效率和吞吐——这在批处理场景几乎是一笔好交易。但性能与确定性从来是一枚硬币的两面，引擎默认值的每一次切换，都是在替全体用户重新谈判这条边界。数据团队真正该做的是把「隐式契约」显式化：哪些管道依赖行序、哪些结果必须可复现，写进测试和契约里，而不是祈祷上游别改默认值。
📊 没有万能引擎，只有场景匹配
把三件事放在一起，结论浮出水面：2026 年的数据引擎市场，不是「谁替代谁」的故事，而是场景匹配的故事。
Peihao Yuan 的文章里提到，判断「嵌入式引擎够用还是该上托管湖仓」有四个信号 [^1]。虽然原文未逐一展开，结合行业实践可以推演出一个务实的判断框架：
| 判断维度 | 嵌入式引擎（如 DuckDB / Polars） | 托管湖仓（如 **Snowflake** / **Databricks**） |
|---|---|---|
| 数据规模 | 单机内存到磁盘溢写可覆盖 | 超大规模、多租户并发 |
| 确定性要求 | 强，本地可复现、可重放 | 依赖平台版本管理 |
| 运维投入 | 近零运维，嵌进应用 | 换钱买托管、弹性与治理 |
| 成本结构 | 固定计算资源，边际成本低 | 按量付费，规模化后需精细治理 |
用四象限看更直观：
左边一列的引擎赢在「轻」：零运维、嵌进应用就能跑、结果本地可复现——这正是 AI 代理生成 SQL 后需要一个确定性计算底座的场景。右边一列的平台赢在「重」：治理、弹性、多团队协作，这些不是嵌入式引擎能扛的。
一个不太被说透的事实是：AI Agent 的普及反而利好嵌入式引擎。因为代理生成的是受约束的、小而精的查询，单机引擎跑 Parquet 绰绰有余；真正需要托管湖仓的，是企业级的数据治理和规模化，那从来不是 AI 的锅，也不是 AI 的功。
小结
AI 没有杀死 SQL，也没有干掉查询引擎——它只是把「谁在写查询」换成了代理，然后把三个老问题重新拍在桌上：结果可不可复现（确定性切分）、向量这笔持有成本怎么算（存储账单）、引擎默认值变了管道还稳不稳（静默变更）。
把数字落回日常决策，其实各有一句可以带走的口诀。确定性：凡是要给审计看的数，计算层必须可重放，AI 只许碰语言层；向量账单：$10 的调用费背后站着 6 GB 起步、索引放大后 15 GB 以上的长期持有成本，预算按「存量 + 复利」算，别按「流量」算；静默变更：引擎升级说明里每一行「不再保证」，都对应着你管道里一行没人写下来的依赖——把行序、可复现性、磁盘配额这些隐式契约，显式地写进测试和 CI 里。
接下来一两年，值得盯的方向有三个：向量存储与湖仓的融合路径、嵌入式引擎与托管平台的混合架构、以及围绕「可重放分析」的新一代数据契约工具。接口层的革命很热闹，但胜负手，仍在引擎层那点笨功夫里。
参考资料
[^1]: Peihao Yuan, Building an AI Agent–Driven Disaster Recovery Analytics Workflow with DuckDB, InfoQ, 2026. （AI 代理与 DuckDB 灾备分析工作流、「确定性切分」及嵌入式引擎四信号均出自该文）
[^2]: 微博用户「大Token」：用 Python 3.13 标准库测算 100 万条向量知识库的存储与隐性成本，2026. （本节成本结构的原始测算思路来源）
[^3]: Ritchie Vink, Polars 2.0 release: default streaming engine, Polars 官方博客， 2026-10-06. （collect() 默认流式引擎、join/group_by/unpivot 不保证行序、80% 内存溢写、64 GB 磁盘预算及厂商自测 benchmark 脚注均出自该文）
[^4]: OpenAI, Embeddings 官方文档与 Pricing 页面， 2026. （text-embedding-3-small 默认 1536 维、text-embedding-3-large 默认 3072 维及 $0.02 / $0.13 每百万 token 定价均出自该文档，具体数值以官方最新页面为准）
本文由本站 AI 辅助聚合生成，原始来源如下：