1. 当图灵奖得主给LLM泼冷水这场争论到底在吵什么Michael Stonebraker 这个名字做数据库的人不可能不知道。Ingres、PostgreSQL、Vertica、VoltDB、SciDB这些系统背后都有他的影子2014年图灵奖得主数据库领域公认的活化石级人物。他最近关于 LLM、智能体和数据库的一番表态在圈子里传得挺广核心意思就一句话别太高估 AI 了。这话从一个数据库老兵嘴里说出来其实一点都不意外。我做了这些年数据系统见过太多XX 要取代数据库的论调从 NoSQL 到 NewSQL 再到现在的 LLM每一波都有人喊革命最后发现真正落地的东西往往是把新能力嵌进老架构里而不是把老架构推倒重来。Stonebraker 的观点之所以值得认真对待不是因为他资历老而是因为他指出的问题非常具体LLM 在数据管理这件事上目前的能力边界比大多数人想象的要窄得多。这篇东西我想聊的不是AI 行不行这种口水话题而是把 Stonebraker 那套逻辑拆开结合 Text-to-SQL、智能体、DBOS 这些具体方向讲讲一个做数据系统的人应该怎么看待 LLM 的介入。关键词里出现的 LLM、智能体、数据库、DBOS、Text-to-SQL基本就是这场讨论的全部战场。如果你正在做智能体开发、在评估 Text-to-SQL 方案、或者在琢磨数据库和 LLM 怎么结合那这些内容应该能帮你少走点弯路。先说结论免得有人看到一半觉得我在唱衰LLM 在数据库领域的价值是真实的但它擅长的事情和很多人以为它擅长的事情不是同一批。搞清楚这个错位比盲目上马一个AI 数据库助手项目重要得多。2. Stonebraker 的核心论点拆解LLM 到底卡在哪2.1 准确率这道坎Text-to-SQL 的真实水平Text-to-SQL 是 LLM 进入数据库领域最直接的入口也是被吹得最狠的方向。你给一句话它给你生成 SQL听起来很美。但实际跑过的人都知道这东西在 demo 里表现惊艳在生产里翻车是常态。问题出在哪SQL 是一种对精确性要求极高的语言一个字段名写错、一个 JOIN 条件漏掉、一个聚合函数的 GROUP BY 少了一列结果就是错的而且往往是那种看起来对、实际错的错。LLM 的本质是概率生成它在最可能的下一个 token这个层面工作而 SQL 需要的是逻辑上唯一正确的答案。这两者之间存在根本性的张力。学术界那些榜单比如 Spider、BIRD顶级模型的执行准确率能到百分之七八十甚至更高。但你要注意几个事第一这些榜单的 schema 是相对干净的字段命名规范表关系清晰第二测试问题的表述方式比较标准第三很多评测用的是执行结果匹配而不是SQL 完全一致宽松了不少。真实企业环境里一个库几百张表字段名是cstmr_id、ord_dt这种缩写还有一堆历史遗留的脏数据准确率会掉得很厉害。Stonebraker 的意思很明确在需要高可靠性的场景下让 LLM 直接生成 SQL 去操作生产库风险太大。这不是模型不够大就能解决的问题是范式本身的限制。2.2 智能体的自主性幻觉智能体Agent是另一个被过度包装的概念。现在满大街的智能体开发智能体搭建很多本质上就是LLM 加几个工具调用加一个循环。给它一个数据库查询工具它就能自主地查数据、分析、给结论。但这里有个被忽略的问题智能体的自主性越强出错时的可控性越差。一个只会生成 SQL 的模型你还能 review 它的输出一个能自己决定查哪张表、自己决定要不要写数据的智能体它的行为链路就变得很难审计了。在数据库这种写错一条就是生产事故的环境里这种不可控性是致命的。我见过一个团队做的数据分析智能体逻辑是让模型自己规划查询步骤。测试环境跑得挺好上线之后有一次它把一个DELETE语句的WHERE条件理解错了差点清掉半张表。后来他们加了人工确认环节但那就等于智能体的自主名存实亡了。这个案例很典型智能体在数据库场景的价值往往被它的风险抵消掉了。2.3 DBOS 的启示把该做的做扎实Stonebraker 近年推的一个方向是 DBOSDatabase-Oriented Operating System思路是把操作系统该干的事下沉到数据库里。这个方向本身就说明了他的立场与其指望 LLM 来智能地管理数据不如把数据系统本身的确定性、事务性、可恢复性做扎实。这个思路对做 LLM 应用的人是有启发的。与其让 LLM 去猜用户想查什么不如把数据的访问接口设计得更清晰、更结构化让 LLM 在一个受约束的空间里工作。约束不是限制是让系统可靠的前提。后面我会具体讲怎么设计这种约束。3. Text-to-SQL 落地时那些没人告诉你的坑3.1 Schema 理解模型看不懂你的表结构Text-to-SQL 第一个大坑是 schema 理解。你把建表语句一股脑塞给模型指望它理解表之间的关系结果它经常搞混。举个例子一个电商库里有orders、order_items、products三张表。用户问上个月卖得最好的商品是什么模型需要知道orders和order_items通过order_id关联order_items和products通过product_id关联卖得最好通常指销量SUM(quantity)而不是销售额。这些常识模型不一定有尤其是当你的表结构有特殊设计时。我的做法是给 schema 加语义层。不是直接把 DDL 丢给模型而是维护一份带业务注释的 schema 描述明确告诉模型每张表是干什么的、关键字段的含义、表之间的关联路径。这份描述可以放在系统提示里也可以用 RAG 的方式按需检索。-- 不要只给这个 CREATE TABLE order_items ( id BIGINT PRIMARY KEY, order_id BIGINT, product_id BIGINT, quantity INT, price DECIMAL(10,2) ); -- 要给这个 -- order_items: 订单明细表一行代表一个订单里的一个商品 -- order_id: 关联 orders.id表示属于哪个订单 -- product_id: 关联 products.id表示是哪个商品 -- quantity: 该商品在此订单中的购买数量 -- price: 下单时的单价注意不是当前售价这个语义层的工作量不小但它是 Text-to-SQL 能不能用的分水岭。没有它模型就是在猜有了它模型才有据可依。3.2 歧义消解用户说的话本身就有问题第二个坑是用户输入的歧义。真实用户不会像评测集那样把问题问得清清楚楚。最近的数据是最近几天大客户是按订单量还是按金额活跃用户的定义是什么这些问题模型没法自己解决因为它不知道你的业务定义。解决方案有两个方向一是把业务口径固化下来做成模型可以查询的指标字典二是在生成 SQL 之前让模型先反问澄清。指标字典的做法更实用。把常用的业务指标定义好比如活跃用户 过去 30 天内有登录记录的用户模型生成 SQL 时优先引用这些定义而不是自己发挥。这本质上还是约束的思路不给模型自由发挥的空间给它明确的规则。3.3 结果验证怎么知道生成的 SQL 是对的第三个坑也是最容易被忽略的你怎么验证生成的 SQL 是对的很多人只看能不能跑通跑通就认为对了。但 SQL 跑通和结果正确是两码事。一个漏了WHERE条件的查询也能跑通只是返回了全表数据。我的经验是加几层验证第一层是语法和 schema 校验确保字段名、表名都存在第二层是解释回译让模型用自然语言解释它生成的 SQL 在做什么看是否和用户意图一致第三层是结果合理性检查比如返回行数是否异常、数值是否在合理范围。这三层里第二层最有用。让模型解释自己的 SQL经常能发现它理解错了意图。这个技巧在智能体场景里同样适用后面会再提到。4. 智能体接数据库能力边界和设计约束4.1 智能体适合做什么不适合做什么先把边界划清楚。智能体在数据库场景里适合做的是探索性、只读、容错的任务数据探查、趋势分析、异常发现、报表生成。这些任务的特点是错了可以重来不会造成不可逆的损失。不适合做的是写操作、事务性、高可靠的任务数据修改、批量更新、关键业务逻辑。这些任务一旦出错代价太大而且智能体的不确定性让审计变得困难。这个边界不是绝对的但它是设计时的默认假设。如果你要让智能体做写操作必须有额外的人工确认或事务回滚机制不能让它自主决定。4.2 工具设计给智能体的不是数据库是接口一个常见的错误是给智能体一个执行任意 SQL的工具。这等于把整个数据库暴露给它风险极高。正确的做法是设计受限的接口。比如不给它execute_sql而是给它query_orders(start_date, end_date, status)这样的语义化函数。智能体只能调用这些预定义的接口每个接口内部是经过审核的 SQL。这样既保留了智能体的灵活性又把风险控制在接口层面。# 不推荐给智能体裸的 SQL 执行能力 tools [{name: execute_sql, description: 执行任意 SQL}] # 推荐给语义化的受限接口 tools [ { name: get_sales_summary, description: 获取指定时间段的销售汇总, parameters: { start_date: 开始日期格式 YYYY-MM-DD, end_date: 结束日期格式 YYYY-MM-DD, group_by: 分组维度可选day/week/month/product/region } }, { name: get_top_products, description: 获取销量最高的商品列表, parameters: { limit: 返回数量默认 10, metric: 排序指标可选quantity/revenue } } ]这个设计的核心思想是把智能留给 LLM 做意图理解和任务规划把执行交给确定性的代码。LLM 负责决定调用哪个接口、传什么参数接口负责怎么安全地查数据。4.3 循环控制别让智能体陷入死循环智能体的执行循环需要严格控制。我见过智能体因为一个查询返回空结果就反复调整参数重试最后烧掉大量 token 还没解决问题。控制手段有几个设置最大迭代次数比如 10 次设置单次任务的 token 预算设置超时时间。更重要的是在提示里明确告诉智能体如果连续两次查询返回空结果应该停止并报告而不是继续尝试。还有一个技巧是让智能体在每次工具调用后做一次反思这次调用的结果是否符合预期如果不符合是参数问题还是任务本身无法完成这个反思步骤能显著减少无效循环。5. 数据库侧的准备让 LLM 能看懂你的数据5.1 元数据治理是前提LLM 能不能用好你的数据库很大程度上取决于你的元数据质量。字段有没有注释、表关系有没有文档、业务口径有没有定义这些平时看起来可有可无的东西在 LLM 场景下变成了刚需。我建议做一次针对 LLM 的元数据梳理重点补三块字段级注释每个字段是什么意思、表级说明这张表存什么数据、更新频率如何、关系说明表之间怎么关联。这三块补齐了Text-to-SQL 的准确率能上一个台阶。5.2 视图和物化视图给 LLM 一个干净的入口如果底层表结构复杂可以考虑为 LLM 场景建专门的视图。把常用的关联、过滤、聚合逻辑封装在视图里LLM 只需要查视图不用自己拼复杂的 JOIN。比如底层有orders、order_items、products、users四张表你可以建一个v_order_detail视图把订单、商品、用户信息都关联好。LLM 查某用户买了什么时直接SELECT * FROM v_order_detail WHERE user_id ?就行不用理解四张表的关系。物化视图适合那些查询频繁、数据实时性要求不高的场景。把结果预先算好LLM 查询时直接读既快又稳。5.3 权限隔离别让 LLM 碰到不该碰的数据这是安全底线。给 LLM 用的数据库账号权限要最小化。只读账号就只给 SELECT需要写操作就单独开账号并加审计。敏感字段手机号、身份证、金额要么脱敏要么通过视图屏蔽。我见过一个案例智能体被问到帮我查一下某个用户的完整信息它直接查了包含敏感字段的表把数据返回给了不该看到的人。这不是模型的问题是权限设计的问题。数据库侧的权限控制是 LLM 应用安全的最后一道防线。6. 从 DBOS 思路看 LLM 与数据库的长期关系6.1 确定性优先智能性其次DBOS 的核心思想是把确定性下沉。这个思路对 LLM 应用同样适用在数据系统里确定性永远优先于智能性。什么意思就是当你要做一个功能时先问这件事能不能用确定性的代码解决。能就别用 LLM。LLM 应该用在那些规则难以穷举、需要理解自然语言的地方而不是用来替代本来就很清晰的逻辑。比如根据用户 ID 查订单这是确定性逻辑写个函数就行不需要 LLM。理解用户用自然语言描述的模糊查询需求这才是 LLM 的用武之地。把这两者分开系统会稳定得多。6.2 LLM 作为翻译层而非决策层我倾向于把 LLM 在数据系统里的角色定位为翻译层把人类的自然语言翻译成结构化的查询意图把结构化的查询结果翻译成人类能理解的自然语言。它不负责决策只负责翻译。这个定位的好处是LLM 的输出始终要经过确定性系统的校验和执行。翻译错了校验层能拦住翻译对了执行层照做。整个系统的可靠性由确定性部分保证LLM 只是让交互更自然。6.3 混合架构LLM 加规则加人工现实中的方案往往是混合的。LLM 处理自然语言理解规则引擎处理业务逻辑校验人工处理高风险操作。三者各司其职。比如一个数据查询系统用户输入自然语言LLM 生成候选 SQL规则引擎检查 SQL 是否符合安全规范有没有全表扫描、有没有敏感字段通过后执行结果再由 LLM 组织成自然语言返回。高风险操作写、删则转人工确认。这个架构不性感但它能跑在生产环境里。那些号称全自动 AI 数据分析的方案要么场景很受限要么背后其实也是这么一套混合逻辑只是包装得好听。7. 实操建议现在就能做的事7.1 先做只读场景别碰写操作如果你要上 LLM 加数据库的项目从只读场景开始。数据查询、报表生成、趋势分析这些场景容错率高出了问题影响可控。跑顺了再考虑更复杂的场景。写操作增删改一定要谨慎。如果非要做加人工确认环节加操作审计加回滚机制。别信模型很聪明不会出错这种话出错是概率问题不是能力问题。7.2 建评测集别靠感觉判断效果Text-to-SQL 的效果不能靠试几个问题感觉还行来判断。建一个评测集覆盖你的典型查询场景每次调整提示或换模型都跑一遍看准确率的变化。评测集不用很大几十到上百个问题就够但要覆盖不同类型的查询简单过滤、多表关联、聚合统计、时间范围、模糊条件。有了这个基线你才知道改动是变好了还是变差了。7.3 日志和可观测性要到位LLM 应用的调试比传统应用难因为它的行为不确定。所以日志要记全用户输入、模型输出、工具调用、执行结果、耗时、token 消耗。出了问题能回溯才能定位。我习惯把每次 LLM 交互的完整链路记下来包括中间的工具调用和模型思考过程如果模型返回的话。这些日志在排查为什么这次查询结果不对时非常有用。7.4 提示工程要围绕约束做给 LLM 的提示重点不是鼓励它发挥而是约束它别乱来。明确告诉它能做什么、不能做什么、遇到不确定的情况怎么办。比如在 Text-to-SQL 的提示里加这些约束只能使用提供的 schema 中的表和字段不确定用户意图时先反问生成的 SQL 必须包含 LIMIT 防止全表返回禁止生成 DDL 和 DML 语句。这些约束看起来琐碎但每一条都能减少一类错误。8. 我踩过的几个坑和一点个人体会说几个具体的。第一个坑是过度信任模型的 schema 理解。早期我直接把建表语句丢给模型结果它经常把相似字段搞混比如created_at和updated_at。后来加了字段注释问题少了很多。这个教训是模型不会理解你的 schema它只是在做模式匹配你给的信息越明确它匹配得越准。第二个坑是忽略了 token 成本。一个复杂的 Text-to-SQL 任务如果把完整 schema 都塞进提示加上多轮对话历史token 消耗很快。后来改成按需检索 schema只给相关的表成本降了不少。这个优化在智能体场景里更重要因为智能体的循环会放大 token 消耗。第三个坑是没做结果缓存。相同的查询反复执行既浪费资源又慢。后来加了查询缓存命中率还挺高因为很多分析场景的查询是重复的。关于 Stonebraker 的观点我的体会是他不是在否定 LLM而是在提醒大家认清边界。数据库这个领域可靠性是第一位的任何新技术的引入都要先过可靠性这一关。LLM 能带来更自然的交互、更低的查询门槛这些都是真实的价值。但它不能替代数据库本身的确定性保证也不应该被赋予超出其能力的自主权。把 LLM 放在它该在的位置上——理解意图、翻译语言、辅助探索——把确定性的工作交给确定性的系统这个分工想清楚了很多问题就迎刃而解了。那些喊着AI 取代数据库的和那些喊着AI 一无是处的其实都错过了重点。重点是怎么让这两样东西各干各擅长的事组合出一个比原来更好的系统。这个问题的答案比争论谁取代谁有价值得多。