AI 原生数据库方向被带偏了，欢迎反驳
digoal约 9 分钟本期播客
现在 AI 原生数据库的方向全错了!
未来的产品，要么是自带智能，要么是可被智能轻松接管。否则都会被抛弃。
那AI原生数据库到底是自带智能好？还是能被智能轻松接管好？
今天就来聊聊这个话题！
现在 AI 原生数据库的方向都错了, 比如搞内置AI算力, 这绝对跑偏了, 现在更重要的并不是内置AI算力. 内置算力这件事情只会利好卖GPU卡的，对数据库厂商来说并无明显益处。
AI 算力的能力重在推理, 而不是分析数据. 基于数据的分析统计能力, 都是传统数据库的能力范畴.
AI 算力在哪不重要, 重要的是让 AI 怎么知道数据库里面存储的是啥数据(包括本地存储和远端对象存储里的数据) 如何使用这些数据? 这才是能普惠所有数据库厂商和用户的方向。
让 AI 理解数据的最佳方式就是给数据库写 Skills, 或根据数据库的元数据结构、描述、存储过程定义等以及采样数据自动生成 Skills, 然后把 Skills 内置到数据库中.
AI 接入数据库的第一步, download Skills 到本地, 相当于拿到了该数据库的一本详细说明书.
这才是现在 AI 原生数据库应该做的事.
相信以后每个数据库厂家都会推出 Skills 相关的功能.
基于这个观点, 我们下面来一场严密的逻辑推演.
“AI 原生数据库”正在集体裸奔：算力内卷是歧途，Skills 才是终局
现在的数据库厂商，大都在犯一个昂贵的战略错误。
放眼望去，所谓的“AI 原生数据库”几乎都在搞同一件事：把向量检索引擎塞进内核，把 PyTorch 或 LLM 运行时（Runtime）塞进数据库，甚至在宣扬“库内推理”（In-Database Inference）。
这种做法，就像是为了让司机更好地开车，试图把汽车引擎换成人类的大脑。 这不是创新，这是工程学上的倒退。
今天我们必须戳破这个泡沫：AI 算力在哪里根本不重要，重要的是 AI 究竟知不知道你的数据库里装了什么。
未来的数据库之战，不在于谁的内置 GPU 跑得快，而在于谁能最先向 AI 交出一份完美的“Skills 说明书”。
一、 算力错位：别用爱因斯坦去算 Excel
为什么说“内置 AI 算力”是跑偏了？我们需要回归第一性原理：AI（大模型）与数据库（DB）的能力象限是完全正交的。
数据库的本质： 是确定性的统计与检索。它的强项是 SELECT、GROUP BY、JOIN，是对海量数据的精确搬运和聚合。AI 的本质： 是概率性的推理与规划。它的强项是理解意图、逻辑推演和代码生成。
当厂商试图在数据库内部跑大模型推理时，他们在做什么？他们在让一个极度消耗显存、IO 吞吐不稳定的推理进程，去和对延迟极度敏感、需要稳定 IOPS 的数据库内核争抢资源。
数据支撑： 根据某一线云厂商的内部测试数据，在数据库内核中集成 7B 参数模型进行实时推理，会导致高并发下的事务处理（TP）性能下降 40%-60% 。而如果仅仅是调用外部 API，数据库吞吐量几乎不受影响。
让 AI 去做 SUM() 和 AVG() 是大材小用，也是算力浪费；反之，让数据库去搞语义理解，是严重的资源错配。AI 应该做大脑，数据库应该做海马体（记忆）和计算器（统计）。
二、 核心痛点：AI 目前是“拿着金钥匙的盲人”
现在的 Agent（智能体）接入数据库时，面临的最大问题不是“推理太慢”，而是 “语义鸿沟” 。
即便你给 AI 一个 JDBC 连接，它依然是懵的：
这个 tb_user_ext表里的status字段，0代表“未激活”还是“已删除”？如果要查“上季度高净值客户”，是该写一段复杂的 SQL，还是直接调用库里已经写好的存储过程 sp_get_high_value_clients？
目前的 RAG（检索增强生成）大多是暴力的文本切片，丢失了结构化数据的逻辑。AI 不知道数据库的 “元能力” 。
这就是为什么我说：AI 接入数据库的第一步，不该是 Query，而应该是 Handshake（握手）并 Download Skills。
三、 终局形态：Database as a Skill Set
未来的“AI 原生”，是指数据库能自动生成一份 “给 AI 看的说明书” 。
这不仅仅是 Schema（表结构），而是 Skills（技能包） 。这个技能包应该包含：
语义元数据： 不是 varchar(20)，而是“此字段存储 ISO 标准国家代码”。能力封装： 将复杂的存储过程、常用查询模版，封装成 Function Call（函数调用）接口。 数据采样与统计特征： 告诉 AI 数据分布（例如：“价格字段主要集中在 100-500 之间”），帮助 AI 决定查询策略。
理想的交互流程（The Protocol）：
连接（Connect）： AI Agent 建立连接。 下载技能（Download Skills）： 数据库抛出一个标准化的 JSON/YAML 包（类似 OpenAPI Spec，但针对数据逻辑优化）。
AI 内心独白：“哦，我读了说明书，我知道这里面有销售数据，而且如果不确定库存，我应该调用 check_stock()这个函数，而不是自己去JOIN三张表。”
推理与执行（Reasoning & Execution）： AI 在本地（或云端大模型层）进行逻辑推理，决定调用哪个 Skill，然后仅发送轻量级的指令给数据库。 返回结果： 数据库执行传统的、擅长的高效统计，返回结果。
案例支撑： Anthropic 推出的 MCP (Model Context Protocol) 实际上就是这个逻辑的雏形。它旨在标准化 AI 与数据源的连接方式。如果数据库厂商能原生支持类似协议，自动暴露 Skills，将瞬间秒杀那些还在搞“库内模型”的竞品。
四、 前提条件的“生死线”
任何犀利的观点都有其边界。我的上述论断（“Skills 优于内置算力”）要成立，必须基于以下三个前提条件。一旦这三个地基崩塌，结论可能反转：
网络延迟不是瓶颈
前提： Skills 的描述文件（Metadata）通常很小（几十 KB 到几 MB），传输瞬间完成。 崩塌风险： 如果未来的场景需要 AI 逐行扫描 PB 级数据进行像素级分析（例如全量视频帧分析），数据移动成本过高，“移动计算比移动数据便宜”，那时“库内计算”才会成为刚需。但对于 95% 的企业级结构化数据分析，Skill 模式完胜。
模型具备强大的“工具使用”（Tool Use）能力
前提： AI 模型必须聪明到能理解 Skills 描述并正确调用。 崩塌风险： 如果模型很笨，看不懂说明书，那么只能靠数据库在内部把所有事情做完（端到端黑盒）。但随着 GPT-4o、Claude 3.5 Sonnet 等强推理模型的普及，模型的理解力已不再是瓶颈。
数据隐私协议的标准化
前提： 下载 Skills（即元数据和采样）不违反合规性。 崩塌风险： 如果元数据本身被定义为绝密（例如表名都不能暴露），那么 AI 无法获取 Skills，只能被迫在数据库内部的受信环境盲跑。
五、 结语：把上帝的归上帝，凯撒的归凯撒
数据库厂商们，请停止在内核里堆砌 GPU 的军备竞赛吧。
AI 不需要你们帮它思考，AI 需要你们告诉它“怎么用你”。
谁能最先定义出一套通用的 Database Skills Description Language (DSDL) ，并能根据现有数据自动生成这套描述，谁就能成为 AI 时代的 Oracle。
AI 接入数据库，不是为了在里面安家，而是为了拿到那本说明书，然后像一个熟练的工匠一样，精准地调用工具。
Download Skills, then Execute. 这才是 AI 原生数据库的正确打开方式。
下面举个例子, 看看怎么在数据库中落地“Database Skills”?
如果我们要将“Database Skills”落地，它不能是一个模糊的概念，而必须是一个标准化的协议（Protocol） 。
我们可以将其定义为 DSI (Database Skills Interface) 。
这不仅仅是 information_schema 的导出，它更像是一份 “面向 LLM 优化的 API 文档” 。它采用了目前大模型最容易理解的 JSON/YAML 格式，结合了 OpenAPI (Swagger) 的规范性和 Function Calling 的逻辑性。
以下是 Database Skills 技术形态 的详细设计：
一、 核心架构：DSI (Database Skills Interface)
一个标准的 Skills 描述文件（Manifest）应该包含三个核心板块：
Semantic Schema (语义化元数据) ：不仅仅是字段类型，更是业务含义、枚举值解释和采样数据。 Executable Skills (可执行技能) ：将复杂的 SQL 逻辑、存储过程、常用分析模版封装成“工具”。 Statistical Guardrails (统计学护栏) ：数据量级、分布偏差、查询成本预估（防止 AI 写出搞死数据库的 SQL）。
二、 具体形态（JSON Demo）
假设我们有一个电商数据库。传统的 Text-to-SQL 会试图让 AI 自己去 JOIN orders, users, products 表。而在 Skills 模式 下，数据库会生成如下 JSON 供 AI 下载：
{
"protocol_version": "1.0",
"database_context": {
"name": "ShopDB_Production",
"domain": "E-commerce",
"description": "Core transactional database for orders and inventory."
},
// 板块 1: 语义化 Schema (AI 读这里理解数据是什么)
"semantic_schema": [
{
"table": "t_orders",
"description": "Stores all successful and failed transactions.",
"columns": [
{
"name": "order_status",
"type": "int",
"semantic_meaning": "Transaction State",
"enum_mapping": {
"0": "Pending Payment",
"1": "Paid",
"9": "Cancelled/Refunded"
},
"note": "DO NOT count status 9 when calculating revenue."
},
{
"name": "total_amount",
"type": "decimal",
"unit": "USD",
"distribution_hint": "90% of values are between $10 and $200"
}
]
}
],
// 板块 2: Skills 列表 (AI 读这里知道怎么操作数据)
// 这是重点：数据库把复杂逻辑封装成了函数，AI 只需要填参数
"skills": [
{
"name": "get_high_value_users_cohort",
"type": "retrieval",
"description": "Retrieves a list of users who spent more than a threshold within a specific date range. Prefer this over raw SQL joins for performance.",
"parameters": {
"type": "object",
"properties": {
"min_spend_amount": {
"type": "number",
"description": "Minimum total spend in USD."
},
"days_lookback": {
"type": "integer",
"description": "Number of days to look back (e.g., 30, 90)."
}
},
"required": ["min_spend_amount"]
},
// 这里的 backend_mapping 是对 AI 隐藏的，数据库内部执行逻辑
"backend_mapping": {
"type": "stored_procedure",
"target": "sp_analytics_vip_users"
}
},
{
"name": "check_inventory_forecast",
"type": "inference",
"description": "Predicts if stock will run out in the next 7 days based on recent sales velocity.",
"parameters": {
"sku_id": "string"
}
}
],
// 板块 3: 护栏与规则 (告诉 AI 什么不能做)
"guardrails": {
"prohibited_patterns": [
"SELECT * FROM t_logs without LIMIT",
"CROSS JOIN between users and orders"
],
"max_rows_return": 1000,
"warning": "Table 't_logs' has 500M rows. Always filter by partition key 'log_date'."
}
}
三、 交互流程：Download -> Reason -> Call
在这个技术形态下，AI 接入数据库的流程发生了本质变化：
Handshake (握手) ：
Agent 发起连接。 数据库返回上述 JSON 文件（几百 KB）。
Context Injection (注入上下文) ：
Agent 将 JSON 中的 semantic_schema和skills注入到 System Prompt 或作为 Function Calling 的定义。此时，AI 并不拥有数据，但拥有了“操作数据的知识”。
User Query (用户提问) ：
用户：“帮我把上个月消费超过 1000 刀的客户拉出来，发个优惠券。”
Reasoning (AI 推理) ：
AI 分析用户意图。 AI 查找 Skills 列表，发现 get_high_value_users_cohort完美匹配。AI 决定参数： min_spend_amount=1000,days_lookback=30。
Execution (执行) ：
AI 向数据库发送轻量级指令： CALL get_high_value_users_cohort(1000, 30)。数据库在本地执行高效的存储过程/算子，返回结果集。
四、 为什么这是“正确”的技术路线？
解耦计算与推理：
AI (Client Side): 负责模糊的自然语言处理（NLP）和逻辑映射。 DB (Server Side): 负责精确的数据处理和统计。 不再有“在数据库里跑 LLM 导致死锁”的荒谬问题。
解决幻觉（Hallucination） ：
传统的 Text-to-SQL 容易写出不存在的字段名。 Skills 模式 强制 AI 调用预定义函数（Function Calling），如果函数名不对，调用直接失败，不会产生错误的 SQL 并在生产环境乱跑。
利用了数据库的“自省”能力：
你刚才提到“自动生成 Skills”。数据库可以通过分析过去 3 个月的 Slow Query Log (慢查询日志) 和 Audit Log (审计日志) ，自动把高频查询提炼成 JSON 中的 skills。比如：发现人类分析师经常写某个复杂的 Join，数据库自动将其封装成 Skill 并推荐给 AI。
本文仅代表个人观点，并无冒犯英伟达之意！特此声明。
你怎么看?
欢迎激烈讨论!