别太高估AI了图灵奖得主Stonebraker谈LLM、智能体与数据库的未来先说个最近在圈子里传得挺广的事儿图灵奖得主、数据库界的老前辈Stonebraker在一次访谈里直接泼了盆冷水大意是“LLM被高估了智能体也没那么智能你们这些人是不是把数据库忘了”。这句话在AI圈和基础设施圈同时炸了锅——搞大模型的人觉得他落伍搞数据的人觉得他说得太客气了。我自己的第一反应倒挺平淡因为做数据系统做久了大概都会对“万能模型”这类叙事本能地警惕。今天这篇文章不打算替任何一方站台也不打算复读新闻稿就想从工程视角认真拆两件事第一Stonebraker的批评到底有没有道理道理在哪第二如果他说的是对的那我们在做AI应用、做智能体、做数据基础设施的时候到底应该怎么调整姿势。这篇文章适合正在做LLM应用落地、搞智能体开发、或者维护数据平台的工程师和架构师看。如果你是刚入门的技术同学也能从中看到一套相对稳妥的AI系统设计思路——毕竟真正落到生产环境里的AI拼的不是提示词写得有多花哨而是“出错的时候系统会不会崩”。1. 先搞清楚这位图灵奖得主说话的分量1.1 他凭什么对AI指指点点Stonebraker这个名字可能做应用开发的年轻朋友不太熟但你每天都在用的PostgreSQL血缘就来自他主导的Ingres项目。后来他还做了Vertica、VoltDB、SciDB基本上数据库圈子里每一次大的技术转向他都在场。图灵奖颁给他的时候官方口径就是“对现代数据库系统的概念与实践做出的奠基性贡献”。所以他说“你们别高估AI”不是那种不懂技术的传统行业大佬在发表感言而是一个手把手把数据库可靠性做到了金融级别的老工程师站在五十年工程经验的角度对当前这股AI热潮给出自己的判断。我特别欣赏他的一点是他很少说“AI没用”这种粗暴的话他的核心态度一直是AI很有潜力但你们现在的用法和预期离工程可靠还差得远。回到他最近的那段观点中心思想大致是数据库花了五十年才解决了并发、崩溃恢复、一致性问题让企业敢把钱和用户数据交给系统而LLM到现在连“稳定输出”都做不到却有人想把它们包装成可以全权代理业务的“智能体”这不合理。这句话的关键词是“可靠”不是“能力”。Stonebraker并不否认大模型能写诗、能总结文档、能聊天他质疑的是另一个层面你敢不敢把一个必须“说一不二”的业务逻辑完全交给一个概率模型去执行。1.2 LLM与数据库一场不公平的“可靠性比赛”数据库的可靠是有明确标准的ACID事务、主从复制、崩溃恢复、权限控制、审计日志。每一条数据的读和写要么成功要么回滚绝不允许出现“中间状态”。你在银行转账从A账户扣了钱、B账户还没入账的时候系统崩了数据库必须保证重启后两边都是对的。LLM呢同一个问题同样的提示词它这次答的和上次答的可能就差十万八千里。它不是坏它天生就不是一个确定性系统。Stonebraker拿这两样东西放一起比听起来像欺负人但实际上是在提醒大家我们花了五十年才建立起“数据可信”的信任基础现在一个生成模型跑过来就能直接在数据库之上发号施令了吗答案显然是不能。但这里有一个很重要的延伸为什么大家会想把LLM和数据库放在一起因为用户真正想要的不是“数据库”本身也不是“大模型”本身而是“我能用自然语言安全准确地操作我的数据”。这个需求是真实存在的。所以这不该是一场替代赛而是一场接力赛——LLM负责理解人的意图数据库负责保证操作不出错。Stonebraker真正反对的是把接力赛跑成“LLM一个人全包”。2. LLM的“不可靠”到底出在哪2.1 回答流畅不等于事实正确我在实际项目里遇到过太多次这样的场景让GPT生成一段SQL它语法完全正确表名也对逻辑也通顺但查出来的结果跟业务方自己手工算的对不上。后来一查发现它把“最近30天”翻译成了“DATEDIFF(day, order_date, GETDATE()) 30”看起来没毛病但业务方那边对“最近30天”的定义是从当月初开始算压根不是滚动窗口。这不是一个Bug这是LLM的阅读理解问题。它读到的“最近30天”是一个自然语言描述而它要映射到的目标世界里有各种各样的潜规则、隐含约定、边缘条件。这些规则不会写在表结构里也不会出现在文档里模型只能猜。问题是它猜得再合理对业务来说也是错的。更麻烦的是模型的工作机制决定了它对自己的错误“毫无感知”。它不知道哪些内容是它查证过的哪些是根据上下文概率糊出来的。在聊天场景下这种“自信的胡说”最多让人尴尬一下但一旦放到数据库操作层面代价就是真实的数据污染和业务误判。2.2 生成式系统的本质局限从数学视角看LLM每一次生成token的过程都是在词汇表上做一次条件概率抽样。哪怕你固定了输入只要温度参数不为0输出就会有一定随机性。就算把温度设为0很多模型也只是选择了“最可能”的那条路径不代表“正确”的那条。数据库处理的是确定性的数据映射SELECT之后返回什么是数据内容决定的不是概率决定的。LLM没有这种“物理级保证”它所谓的推理路径更像是一个人在脑子里快速做联想而不是每一步都经过验证。Stonebraker说“LLM被高估”本质上就是在说你不能用概率过程去替代确定性过程的职责。我见过很多产品设计上来就是“用户输入一句话LLM自动改数据库”。这种方案Demo阶段通常惊艳四座因为演示数据简单、规则少、模型踩不到坑。但一到生产环境业务规则稍微复杂一点LLM生成的更新语句就会在某个角落里埋雷。它不是每次都被炸但只要炸一次业务人员的信任感就清零了。2.3 幻觉不是Bug是特性很多不懂技术的人听到“幻觉”这个词以为这是一个能通过优化修掉的缺陷。但实际上幻觉是生成式模型的一个内禀属性。因为模型根本没有“记忆存储”和“事实数据库”的概念它的所有知识都体现在参数里。参数是一种压缩过的经验不是精确的记录。这就带来一个工程意义上的结论凡是要求“绝对事实正确”的任务就不应该让LLM单独承担。不是它不够聪明而是它的工作方式决定了它“天生会编”。我们需要的是一个外部的、确定性的核查层去把模型输出里不合法的、不准确的、自相矛盾的部分拦下来。我团队里现在有一条很死的规矩LLM只负责提出“建议”任何涉及入库、下单、改配置的操作都必须经过数据库层面的约束校验或者人工审批闭环。听起来很保守但半年跑下来这条规矩救了我们不止一次。3. 智能体被过度包装的“自动执行者”3.1 所谓智能体很多只是LLM加了一个循环“智能体”这个词最近几乎要被用烂了。你问他是什么他会给你一套听起来很玄的定义感知、记忆、规划、工具调用、自我反思。但实际上生产环境里能跑的智能体百分之八十的架构是同一个一个LLM做决策外面套一个“反复调用工具直到任务完成”的循环。问题就出在这个循环上。当一个智能体要完成一个多步操作时它需要在自己生成的每一步里都保持正确。如果每步的成功率是90%五步下来整个任务的成功率就只有59%。看起来每一步都“还行”到最后失败的概率其实非常高。这件事用小白的语言解释就是你让一个人连续帮你办五件事他每件事都有九成把握办好但五件事里只要有一件办砸整件事就算失败那么综合成功率已经不到六成了。数据库里管这个叫事务的“原子性”——要么别干要干就全干成。现在的智能体框架基本没有这个概念。3.2 没有“事务”和“回滚”的智能体等于在悬崖边开车我在前面做智能体项目的时候遇到过特别典型的事故。一个客服智能体需要先查用户订单再创建一个退单申请最后给用户发消息。系统设计得挺完整但有一次它在创建退单申请成功后、准备发消息之前遇到了上游接口超时。结果就是退单默默建好了但用户没有收到任何通知跑来投诉说根本没退。单看每一步它都“成功”了但从业务角度看整个流程处于一个“半完成”状态。这就是标准的缺乏事务性。真实世界的事务系统是怎么解决这类问题的靠日志、靠补偿、靠回滚。要么你把这个多步流程放进一个可靠的编排器里每一步都记录状态出错了能回滚或补偿要么你从设计上就避免让智能体直接执行不可逆的关键操作。所以Stonebraker对智能体的批评我完全认同当前大部分智能体产品做的只是“把LLM的调用循环包装了一下”根本没有底层的事务保障。你在上面跑简单问答还可以跑真正的业务心理素质得多强才敢撒手不管。3.3 记忆、规划与工具的可靠性问题智能体三大卖点——记忆、规划、工具调用——在工程上其实都还是半成品。记忆方面现在主流方案就是向量数据库存对话历史或者业务知识。向量检索有个天然短板“语义相似”不等于“事实准确”。它可以把一条不相干但措辞相似的历史记录捞出来当依据然后把整段推理带偏。我见过一个销售智能体因为向量检索到了一条促销活动的旧消息把已经下架的优惠信息当作现行政策推荐给了客户差点造成客诉。规划方面LLM生成的“计划”在简单任务里像模像样但任务一旦涉及分支条件、异常处理计划就变得非常脆弱。它可能会遗漏一个重要的回滚分支或者在一个死循环里出不来。你没法把这种脆弱性归咎于某个Bug因为整个规划能力就是概率性的。工具调用方面最经典的坑是“工具参数格式不对”。让LLM调用一个日期处理工具它在JSON里填了一个“2025/02/30”工具侧一解析就崩。这不是偶发是必然因为LLM并不理解日期合法性它只负责生成“长得像日期”的字符串。这些问题的共同根源在于智能体把“决策”和“执行”合在了一个概率模型里而工程经验告诉我们决策可以概率化执行必须确定化。4. 数据库仍然是可靠系统的地基4.1 为什么LLM替代不了数据库有一个问题经常被问既然LLM这么能打我们还需要数据库吗问出这句话的人大概率没经历过一次生产事故。数据库解决的不是“能不能算出来”而是“算错了怎么办、数据没了怎么办、两个人同时改数据怎么办”。LLM没有存储能力。你让它记住一个亿级用户的交易记录它连零头都记不住。很多人说“用上下文窗口硬扛”但你只要算一下token成本就知道这在工程上根本不成立。数据库的价值不只是存它还包括索引、查询优化、事务、并发控制、备份恢复、权限体系这些能力是LLM完全不具备的。我们做一个极端的假设如果让LLM直接管理用户余额当两个并发请求同时来修改同一个账户时LLM根本不会处理锁和冲突。这不是它不够强而是它的架构里压根就没设计这一层。所以Stonebraker说“数据库仍然是未来AI系统的核心”这句话一点都不夸张。真正合理的架构是LLM做交互和意图理解数据库做存储、查询和事务。两者各司其职而不是让模型去当数据库。4.2 语义层与Schema给LLM一个“事实框架”LLM不认识你的库表但它知道你Schema里的一堆英文表和字段名也“看”过很多SQL的例子。这带来一个关键工程实践与其让LLM裸写SQL不如给它一个清晰的语义层。什么是语义层就是把你数据库里的物理表、字段翻译成业务可理解的逻辑模型。比如底层是一张user_order_statistics表语义层可以定义成“用户订单统计”并写明“统计口径是已支付且未取消的订单”。然后告诉LLM你只需要在这个语义层上回答用户问题不要自己去猜口径。实际效果很明显。加了语义层之后我这边Text-to-SQL的正确率从大概60%提到了接近85%而且剩下的错大多是边界条件问题不再是口径问题。因为模型不再需要“知道”业务规则它只需要按给定规则做翻译难度大幅下降。数据库在这里充当的就是那个“事实框架”你允许模型说什么、不允许模型说什么都由库表结构和语义定义来约束。这是把不可控的生成过程变成可控映射过程的最有效方式。4.3 向量数据库与数据的“里子”向量数据库这两年借着AI东风火得不行但我想提醒一句向量检索解决的是“语义召回”问题不是“事实存储”问题。你可以用向量库做推荐候选、做RAG召回、做内容去重但如果你的业务底层是一堆需要精确计算的钱、货、库存向量库只能做前置粗筛真正的精确计算还是要回到传统数据库。我见过有人把订单数据也塞进向量库理由是“这样AI能直接理解”。这个做法非常危险向量检索的召回结果天然存在误差如果拿这个结果去做订单状态判断等于在不确定性之上再叠加不确定性。正确做法是向量库管“找到可能相关的文档或上下文”关系型数据库管“事实与事务”两者配合谁也不要越位。从我自己的实操经验看做RAG类系统时元数据过滤的作用比很多人想象的大得多。你可以在向量库里给每个文档打上“业务线”“时间范围”“有效状态”三个标签检索时先过滤再向量匹配。这个技巧能把召回准确率显著提高成本却几乎为零。4.4 数据治理喂给模型的数据决定了AI的赛道宽度这个话题和Stonebraker的批评其实一脉相承。他反复强调AI未来的真正瓶颈不是算法而是数据基础设施。你喂给LLM的数据如果是脏的、乱序的、口径不统一的那你做出来的智能体、RAG系统只会把这些脏东西以更流畅的方式呈现给用户。我举一个很常见的例子一家公司有CRM里的客户信息、客服系统里的沟通记录、财务系统里的订单状态三套系统里的“客户地址”格式完全不同有的带省市区有的只有一行文本。把它们不加处理地交给LLM做RAG模型就会在同一个答复里有时用新地址、有时用旧地址有时还混着拼写错误。表面上它在认真回答实际上它只是在忠实地反射数据的混乱。所以做AI应用第一条前置工作永远不是选模型、调提示词而是把数据整理干净。数据库的角色不只是“存”它还承担着治理定义字段格式、建立一致性约束、保证维度表与事实表的关系可靠。这些是AI能准确回答问题的“地基”。5. 实操搭一个“LLM数据库”的可靠系统5.1 核心架构生成-校验-兜底聊了这么多理论落到工程上我推荐一套我自己反复用的架构核心原则就六个字生成、校验、兜底。生成层就是LLM负责把用户的自然语言转化为结构化的操作请求比如SQL查询语句、工具调用参数、订单操作指令。校验层是数据库和规则引擎负责检查这个请求是否合法、是否符合业务规则、是否触碰权限红线。兜底层是事务和审计负责在出错时回滚、记录日志、触发人工审批。这套架构最大的价值是把“创造性的部分”和“确定性的部分”做了隔离。LLM再怎么胡说到了校验层都会被拦住而不是直接落库。这不是降低效率而是保证系统在一个可控的边界内运作。接下来用一个实际场景演示用户说“帮我查一下上个月华东区销售额”系统完整流程应该怎么走。5.2 用数据库约束给LLM“戴上手铐”先看第一层LLM生成请求。这一步我们不做特别复杂的处理但会要求LLM输出一个结构化的JSON而不是直接让它写SQL。因为JSON更利于后续校验而且不容易被SQL注入类的内容干扰。# 伪代码LLM生成结构化查询请求 user_input 帮我查一下上个月华东区销售额 llm_response llm_generate( system_prompt你将用户查询转换为JSON查询请求。只允许使用以下维度区域、时间、金额。 输出格式{\dimensions\: [], \metrics\: [\sales_amount\], \filters\: []}, user_contentuser_input ) # 期望的合理输出: # {dimensions: [region,month], metrics: [sales_amount], filters: [{field:region,op:,value:华东},{field:month,op:last_month}]}然后进入校验层。这一步的核心是用数据库的元数据Schema来校验LLM输出的字段名是否真的存在枚举值是否正确。# 伪代码数据库元数据校验 from jsonschema import validate query_schema { type: object, properties: { dimensions: {type: array, items: {enum: [region, month, product_category]}}, metrics: {type: array, items: {enum: [sales_amount, order_count, profit]}}, filters: {type: array} }, required: [dimensions, metrics, filters] } try: validate(instancellm_response, schemaquery_schema) except Exception as e: # 校验失败触发行人复核或返回重新生成 log_and_review(llm_response, reasonschema validation failed, user_inputuser_input) raise BusinessException(查询条件不合法请重新描述)你可能觉得这是不是太死板了但实际效果恰恰相反。Schema校验能把LLM输出中80%以上的“幻觉错误”拦截在数据库门外。因为你限制了它只能使用真实存在的字段和枚举值它的自由发挥空间被大幅压缩出错的概率也就大幅降低。5.3 校验通过之后才交给数据库执行这一层就是“确定性执行”。我们基于校验通过的JSON拼装成SQL然后交给数据库去执行。但注意这里拼装SQL不是用字符串拼接而是用参数化查询或者查询构建器防止注入。查询执行的结果再返回给LLM做最后的自然语言包装。# 伪代码将校验后的JSON翻译成SQL并执行 sql query_builder.build_query( dimensionsllm_response[dimensions], metricsllm_response[metrics], filtersllm_response[filters] ) # 假设生成的SQL: # SELECT region, month, SUM(sales_amount) AS sales_amount # FROM fact_sales # WHERE region 华东 AND month DATE_TRUNC(month, CURRENT_DATE - INTERVAL 1 month) # GROUP BY region, month result database.execute(sql) # 执行结果落审计日志 audit_log(user_queryuser_input, sqlsql, result_hashhash(result), created_byllm_agent)这一步的核心是“可审计”。不管最后结果是正确还是错误整个过程都有记录出了问题能回追。数据库在这里不仅仅是一个执行引擎更是一个审计层。最后一步是被很多人忽略的“结果解释”。数据库返回的是一个冷冰冰的聚合数字LLM要做的是把这个数字转成用户能看懂的话而不是自己重新计算。这里有一个很重要的纪律LLM只能复述数据库返回的值绝对不能“根据我理解”额外补充数字。我们给LLM的系统提示里会写明所有数字必须来自提供的data字段不得自行推算。5.4 再加一个“防呆”设计多模型确认与缓存如果你对可靠性要求更高比如是财务对账、大额交易这类场景可以再做两层加固。第一层是多模型确认。同一个查询请求让两个不同的LLM独立生成JSON请求然后对拍。如果两个模型生成的结构高度一致可信度会高很多如果不一致就触发人工审核。这个做法在Text-to-SQL场景下尤其有用因为它可以明显过滤掉纯语法性错误。第二层是查询缓存与限流。同一类问题在短时间内被重复问没必要每次都重新走一遍LLM生成流程。我们会在数据库侧做一个“查询指纹”表把标准化后的SQL存下来命中直接用。这能同时解决成本问题和性能问题。这两层都不复杂但能把系统的尾部风险压得很低。我始终觉得可靠系统不是靠某一个天才设计撑起来的而是靠一层一层“防呆”累积出来的。6. 常见问题与避坑技巧实录6.1 让LLM自己生成SQL结果“看起来对、实际错”这是所有做自然语言查数最常遇到的坑。现象很统一LLM生成的SQL能跑通结果也是某个数字但跟业务方口径不符。我的排查步骤一般是先查语义层有没有被明确使用再查它是否遵守了“指标口径”的定义最后查过滤条件里有没有隐含的时间范围假设。前一阵同事反馈“近一周成交额”查错了最后发现是LLM把“近一周”翻译成了自然周周一到周日而业务方要的是“最近7天滚动”。解决方式就是往语义层里加一个明确描述“近一周今天往前推7天含今天”。6.2 智能体的记忆混乱把旧信息当成新结论智能体带着向量库记忆跑业务最容易出现的问题就是“记忆污染”。当向量检索召回了一批过期的上下文模型分不清新旧信息就会给出混合型错误答案。我的解决方式是给向量库里的每条记忆加上“时间戳”和“状态”两个元数据字段。检索时先过滤“状态有效”再按时间倒序加权。这一步能让明显过期信息带来的错误减少很多。另一个技巧是在把检索结果提交给LLM之前先让一个固定的规则脚本把过期内容排到后面或者直接裁掉不让模型有机会误读。6.3 向量检索召回精度不够RAG答非所问如果你发现RAG系统答非所问先别急着调向量模型。先检查数据切分再检查元数据过滤最后才考虑换Embedding模型。业界有个大致感受很多召回质量问题其实出在数据切片上——一个完整的业务段落被切得七零八落语义自然对不上。我建议优先把数据按“篇章级”切分并且允许重叠。这样即使切分点选得不准重叠部分也能保住上下文完整性。实操下来这个优化比换向量模型便宜得多效果却肉眼可见。6.4 Token成本和延迟失控智能体越跑越贵智能体多步推理会不断消耗Token每多一步规划、多次工具调用费用就涨一次。很多团队做完Demo才发现真实流量下根本烧不起钱。我的建议是三层省钱的思路第一层能用规则解决的路由就不要让LLM做第二层复杂的工具调用尽量走“一步调用、批量执行”减少来回对话第三层对高频相似查询做结果缓存。这三层做完成本往往能降一半以上而且可靠性不降反升。6.5 数据库直连权限给太高LLM一跑就是全表扫描有些团队为了图方便让LLM直接用高权限账号连生产库结果一个模糊的查询触发了全表扫描把线上事务拖垮了。这个是绝对要避免的。给LLM执行查询的账号必须遵循“最小权限原则”。只给它只读账号限制超时时间限制返回行数禁止访问敏感字段。这些约束通过数据库的权限体系实现比在应用层过滤要可靠得多。我自己在做这类系统时会专门建一个“查询账号”并用数据库的查询超时参数设置硬性上限一旦超时就自动中断。我在这类系统上踩过的坑确实不少但每一个坑都让我更认同Stonebraker那句“别高估AI”背后真正的含义——不是拒绝新东西而是用工程纪律去驾驭它。LLM负责把人的意图翻译给机器数据库负责把机器的执行变回可信的事实这俩配合得当你才能得到一个既聪明又可靠的产品。至少到目前为止所有让我放心交付的场景靠的都是这个组合。