AI 应用说到底还是应用

Sonya Huang 和 Pat Grady 欢迎 MongoDB 产品与增长负责人 Sahir Azam 做客。他是公司从本地部署（on-prem）软件转向云端的主要推动者之一，现在负责推动其 AI 方面的演进。Huang 先从大局切入：AI 会不会改变数据库市场？Azam 把这个问题往上提了一层。他说，更有意思的问题是，AI 会不会改变软件开发本身。他认为会。生成式应用正在进入传统确定性软件从未触及的场景，红杉资本把这一趋势称为“服务即软件”（services-as-software）。这会改变人与程序的互动方式，改变业务逻辑如何随智能体（agent）演进，而在这一切的底层，数据库层也必须随之转型。

从 MongoDB 的角度看，已经能看到两个转变。创建软件比以前容易得多，也高效得多，因此世界上会有更多软件，而软件越多，需要持久化和处理的数据也就越多。另一个转变在于交互方式。除了经典的网页和移动应用，Azam 还看到了物理世界与虚拟世界的融合，这是机器人领域的一大趋势，还有 LangChain 近期一篇文章所说的环境式智能体（ambient agents）：这类程序无需人刻意发起操作，就会对信号做出反应。他认为，人机交互的顶层变革才刚刚开始，它能以传统软件从未做到的方式，提升个人与职场的生产力。

最前沿的案例往往先出现在能承受风险的创业公司里，因此他挑了两个企业案例。一家大型欧洲汽车制造商拥有庞大的全球车队，以及由自营和第三方技师组成的服务网络。车子发出怪声时，一位熟练技师过去要折腾好几个小时，再翻手册找零件和维修步骤。MongoDB 帮他们找到一个音频嵌入模型，它能用手机录下噪音，并与一个已知故障声音的语料库做语义匹配。原本可能要花几个小时的诊断，如今只需几秒，有点像汽车诊断界的 Shazam；接下来的维修步骤，则由自然语言界面取代了 PDF 和纸质手册。Azam 说，放到数千家经销商、数百款车型上，这就是数百万美元的潜在节省，外加更好的客户体验和更强的品牌口碑。

第二个案例是诺和诺德，这家全球最大的制药公司之一，身处监管非常严格的行业。临床研究报告（CSR）是药物获批所必需的文件，通常需要大量人工撰写、组织和审阅。这家公司用自己已获批药物的数据和内部流程，训练了一个大语言模型（LLM）。现在，初稿几分钟就能生成，Azam 表示，初稿的质量高于他们以往人工撰写时的水平。两个故事的重点在于：AI 被放进了规模足够大、能直接算出美元投资回报的场景里，而不靠尖端技术。

多模态、智能体化、有时还带有环境式特征的应用，对数据库意味着什么？Azam 对此很兴奋，理由有两点。一方面，如果生成式 AI 让更多形式的软件体验更容易构建，那么对数据持久化基础设施而言，这就是宏观层面的顺风。不过这股顺风不会自动落到 MongoDB 或其他任何厂商头上，技术、合作和生态方面还有大量工作要做。另一方面，早期那些与 LLM 聊天的应用并不需要复杂的持久化。想用专有信息支撑回答、并掌控检索质量的企业，需要基础模型和业务实际运行方式之间进行大量交互，而这类信息大多无法从互联网上公开训练获得。随着模型延迟降低，它们会更多地与实时业务数据打交道。最领先的公司已经在想办法精细地控制 LLM 的输出，并把它与驱动应用的数据合并起来。

他最关心的机会，是对非结构化数据做高质量检索。嵌入模型和概率性软件能把世界数据中 70% 所蕴含的价值释放出来，那些文档、录音和图像过去几乎用不上，现在都能被用起来。Grady 扮演唱反调的角色，引用了黄仁勋在红杉资本首届 AI Ascent 上的一句话：每个像素都会被生成，而非渲染，而渲染听起来就像是从数据库里检索。Azam 听到的则是另一种反对意见。问题与其说是幕后有没有数据库，不如说抽象层设在哪里：是由应用开发者决定、藏在 API 后面，还是由 LLM 在自动生成软件时决定。他们内部常开的玩笑是，AI 应用依然是应用。你仍然要安全地持久化交易，让大家的银行余额准确无误；你仍然需要关键词搜索，而不只是语义匹配。数据层面的生成式需求是叠加的，并非替代。

Huang 把时钟快进：数亿名人类开发者，以及数万亿个智能体开发者。为什么智能体要选你的数据库？Azam 说，随着应用从简单的生成式功能，走向由智能体驱动的业务逻辑，状态的重要性随之上升。你要协调复杂的工作流，追踪事务的各个环节，并且随着时间推移存储和更新结果。生成式应用正变得越来越有状态，这会对数据库的消耗形成拖累。在抽象层面，早期由 AI 生成的软件已经表现出对优秀开发者体验和更高层抽象的偏好，比如 Vercel v0、Replit 等类似平台。现在下结论还为时过早，但迹象令人鼓舞。Grady 提出一个说法：英语是终极的抽象层。在极端情况下，你用白话描述产品需求，基础模型就会吐出代码。Azam 确信，这对整个数据库行业都是顺风。MongoDB 的具体押注在于：无论上层软件是人写的还是机器写的，它的数据模型都已针对结构化、半结构化数据做过调优，并能借助嵌入处理非结构化数据。

他们并不满足于此。MongoDB 正在与 AI 框架、推理服务商和模型提供商集成，就像此前的 JavaScript、Web 2.0 和云那样，成为顺风。他们还在做 Azam 称为“LLM 的 SEO”（SEO for LLMs）的工作。从互联网上抓取的代码，未必是 MongoDB 的最佳实践，而且厂商也没有标准途径，把权威的训练数据提交给模型，用于生成高质量的 Mongo 代码。他们正与实验室合作研究方法，也自己建设数据集，因为他们最不希望看到的，就是开发者向模型索要 MongoDB 代码，却拿到了效果很差的结果。Huang 问，公开数据即将触顶，MongoDB 会不会变成训练数据的提供方？Azam 划了一条明确的界线：客户数据归客户所有。在客户意愿之外，MongoDB 不会用这些数据训练模型，无论是为了 RAG 还是其他用途。他看到的情况则是多种方式并存：对业务数据和元数据做简单的 RAG；把元数据、事务和语义搜索合并到同一个系统里的向量应用，他认为市场正朝这个方向发展；还有一些客户在微调或训练更小、针对特定用例的模型。不会只有一种形态。客户会按照自己的方式，优化延迟和性能。

红杉资本会定期就 AI 技术栈对其投资组合进行调查，Huang 说，在人们挑选向量数据库时，MongoDB 始终排在第一位。Azam 补充说，向量是 MongoDB 增长最快的新产品领域。Huang 的问题是：人们是不是把一种诞生于电商、过去用于语义搜索的老技术，硬拿来给 LLM 做信息检索，还是说，向量正是理想的知识基础设施？MongoDB 在 ChatGPT 出现之前就具备向量能力，只是并没有作为独立品类推出。几年前，客户把 MongoDB 当作业务数据库使用，旁边还要配一个用于全文词法搜索的倒排索引引擎，两者之间还得来回复制数据。开发者体验上的解法，是把两种索引方式都放进同一个数据库。之后，一些先进的电商客户提出，希望把词法搜索与语义相似度结合起来。正是这一需求，促使 MongoDB 把向量功能构建进了引擎。ChatGPT 出现之后，这股热潮更是火上浇油，集成也随之扩展。RAG 与单纯的语义搜索是不同的用例。Azam 说，到了 2025 年，最先进的客户希望把所有模态放在一起：非结构化数据上的元数据过滤、关键词相关性排序，以及来自嵌入的语义理解。只有这样，应用才能获得大企业，尤其是受监管行业的企业，愿意在客户面前信任的质量和可预测性。

把这些模态放进同一个系统，正是优势所在。否则你最后就只能做 Azam 所说的 RAG 体操：在应用代码里把各个部分硬拼在一起。这做得到，但会给开发周期带来巨大负担，你还需要一支相当老练的团队才能自己摸索出来。MongoDB 的目标，是让普通应用开发者也能轻松用上这种能力。Huang 问，向量和图是替代关系，还是互补关系？Azam 说，每周都会冒出一些提升检索质量的新方法。他认为两者是互补的。图关系编码了一些仅靠嵌入可能推断不出来的理解，对元数据做预过滤也是叠加的。产品理念是让开发者能轻松把图表示、元数据、事务和向量搜索组合起来，而不必把这些对象分散在四个不同的数据库里，再费力地把它们理顺。

Huang 问，把 LLM 比作大脑、把数据库比作记忆，这样理解是否合理？Azam 说，这确实是一种正确的理解方式，尤其是当智能体跨多个端点执行更复杂的工作流，而不是对单个模型做一次性调用的时候。你必须持久化记忆和状态。他把两者视为一种新兴架构的两个组成部分。计算、存储和网络依然是底层基础构件。基础模型所要处理的，是过去属于知识工作者的概率性工作。这类工作仍然需要存储状态、保持可靠依据，并与应用所驱动的事务和结构化信息交互。这些部分合在一起，才构成最终用户的体验。这不是二选一。随着 LLM 延迟降低，数据库就不只是记忆了。它反映的是世界的状态，而模型需要以更接近实时的方式，与业务中正在发生的事情交互。

Grady 把架构又往下推了一步。凡是确定性的事务，你需要的是传统数据库的世界；凡是概率性的事务，你需要的是更像 LLM 的东西。OpenAI 和 Anthropic 的 API 业务，是否占据了与 MongoDB 相似的层级，也就是位于公有云之上、应用之下？Azam 觉得这是个有意思的类比，但他不认同一句相关的口号。“LLM 是新的操作系统”这种说法，在他看来从来都不合逻辑。他看到的是并排存在、互为补充的组件，它们共同服务于上层的业务逻辑和交互层。语言模型现在能够进行推理，并提供过去做不到的人机交互。在他见过的任何架构里，这些都无法取代来自结构化数据、事务和搜索的确定性输出。现在还处于早期阶段，下一代商业模式尚不明朗，这也正是这个位置有意思的原因之一。

AI 会不会跳过向量，直接跃迁到某种新的数据结构，还是说这就是最终的架构？在 Azam 看来，就他目前所见，向量是站得住脚的强大基础构件。如果出现了别的东西，他也愿意接受。他不把向量数据库看作一个会取代核心数据库的细分品类。它是一种基础构件：如果你要管理非结构化数据，那么对向量嵌入建立索引的能力，加上能表达语义的高质量嵌入模型，就是一个新的基础要素，就像文本索引或 B 树索引一样。他不认为这东西会消失。真正还在剧烈演进的，是如何从这些数据中得到高质量的结果，嵌入的质量如何，以及如何用其他信息来增强它们。这些问题还没有定论。在让存储更高效、更高性能、更省成本方面，仍有很大空间。但对他来说，更有意思的问题在于数据存储之上的那一层。

让他开始琢磨的，是 Stratechery 的 Ben Thompson 说过的一句话。在概率性软件的世界里，衡量质量的标准就是最后一公里：怎样做到 99.99% 的质量，以及制造业里我们熟悉的质量工程，是否开始适用于软件。传统应用与传统数据库之间的交互，能得到确定性的结果，而这里则得不到。因此，质量取决于嵌入模型、RAG 架构怎样搭建，以及如何把它们与业务中交易的实时视图结合起来。正是这些，产生了高质量的检索。在概率性世界里，如果质量达不到高标准，Azam 认为它就无法进入保守型企业的关键任务场景。这正是 MongoDB 目前专注的问题领域。

在他看来，推理模型是数据库的另一股顺风。只要有推理，记忆就会派上用场，还会伴随长时间运行的逻辑和更高级的智能体工作流。这些都需要状态。在这种场景下，数据库的重要性比一次性问答引擎要高得多。作为终端用户，他对这一波浪潮很着迷，而且不只是图个新鲜。谷歌的 Gemini Deep Research 及其周边的产品体验，他觉得非常惊艳。他认为，在推理之上，应用能够构建的用户体验和用例还有很多可做，远超第一波 LLM 所能驱动的范围。

Grady 转向 Azam 的另一段重要经历。Azam 主导了 MongoDB 从传统的本地部署企业软件业务，转向云原生、按消费量计费的业务的转型；如今云业务已经是公司的主体，营收达数十亿美元。能把从本地部署到云端这一转变做对的公司，在这种规模上少之又少。Grady 想要这套打法，因为现在有很多企业和创业公司，都面临着类似的、从非 AI 到 AI 的转型。Azam 顺着 Grady 的说法接了下去。商业转型才是关键词。很多公司把这类转变当成一条新产品线，一件需要单独操心的新产品。他则把它当作整个业务的转型，这意味着每位职能负责人都必须明白自己承担着重要的一环，并对客户成功、财务模型，以及在按消费量计费、云优先的世界里，其他每个职能该如何运转负起责任。

当赚钱的主力不是那个新东西时，怎样才能争取到各方支持？首先是自上而下的强力支持。当时很清楚，推出 Atlas 并完成转型，是头等重要的业务优先事项。这也包括授权 Azam 去逐个找同僚，争取云业务的人手，靠的是来回斡旋，而非直接施压。同样重要的是，他们没有把 Atlas 当作一个与核心业务隔离的小型独立业务单元。他们希望每位职能负责人都觉得自己是转型的一部分，而不是觉得自己要失去负责的一块职能。这样做，才能避免新项目被缩在角落里、资源被挤干，而他见过不少这类尝试，正是这样夭折的。

在销售上，他们亲自上阵，自己也当起了销售。产品团队参与早期的交易，了解客户的异议，并把它们分类：哪些是路线图上的缺口，哪些是赋能的问题，哪些是定位的问题，哪些是定价的问题。Azam 过去每天晚上都会在纽约的小办公室里挨个走一圈：这笔交易进展如何，需要什么帮助，你听到了什么反馈。关键在于，销售团队并不是被某个陌生人告知“这很重要，所以请去做”。他是和他们一起做的。他们还为新的打法配上了销售激励（SPIFF）、大量的赋能培训、复盘和问责，一直坚持到势头足以抵消一个已经习惯了老办法的增长型业务的惯性为止。如果客户还没准备好，他们也不愿硬把本地部署的客户推向云端。在起步阶段，他们确实需要销售团队把注意力放在一件看起来还不像能真正拉动业绩的事情上。

Grady 的总结就是一份建议清单：需要大量自上而下的支持，而这要求高层有坚定的信念；要完全融入业务，而不是缩在角落里挨饿的项目；要进行彻底的重塑，而非只当成一条新产品线。Azam 补充说，一些最重要的工作其实不在技术决策上，而在于商业模式的转变，以及面向组织中另一类买家的销售赋能。几乎每个职能都得发生根本性的改变。大量时间花在了一些人们原本想不到需要改变那么多的事情上。大家通常都会被那个看起来最难的部分吸引：怎样交付一个高度可靠的云数据库，这绝非易事。其他职能则必须以一种连贯的方式对齐，而大量的注意力，实际上正是花在了这里。

Grady 又做了一个类比。在云转型期间，Azam 对开发者体验十分执着，因为开发者将会选择数据库。现在，对于正经历 AI 转型的公司来说，依然是“开发者，开发者，开发者”。最终，如果数万亿个智能体四处奔跑，最需要优先考虑的可能就是智能体体验。Azam 也能看到这一点，尤其是当智能体开始在没有企业自行定制开发的情况下驱动业务逻辑时。外界常问他，MongoDB 是怎么从企业业务走到产品驱动增长（PLG）的，他每次都会皱眉。这两种打法是互补的，它们更多取决于客户处于采用旅程的哪个阶段，以及对方是什么类型的组织。由技术创始人带领、快速推进的创业公司，一开始并不想接触销售。大企业则从来不会通过自助渠道找上门。MongoDB 在整个体系上花了大量时间，使之对应用户和买家真正想要的接触方式。云转型的成功，不取决于在自助付费的小客户和企业销售之间纠缠理念，关键在于两者都必须被紧密整合，才能达到全球规模。

快问快答环节，他最喜欢的新 AI 应用，首推 Gemini Deep Research。Perplexity 按任何定义都算不上新，但它与“薄薄的 AI 包装层不可持续”的说法背道而驰。他在用户体验和设计上看到了很多产品功力。模型不会突然让软件消失；采用率、对用户的理解，以及设计感依然重要，包括在非视觉的模态中也是如此。前一周有人向他推荐了 Snipd，这是一款播客应用，能自动总结节目，把关键洞见以易读的形式呈现出来，还能让你做笔记。Huang 和 Grady 一直在找的正是这样的东西。他最佩服谁？他不点名。他关注那些似乎能看清未来的研究者；而看大公司 CEO 们在记录系统和智能体竞赛上互相攻讦，他觉得挺有意思，那是一场关于哪些老牌巨头能在转型中存活下来的巨头之争。

同意还是不同意：每个开发者都会成为 AI 工程师？他同意。传统的机器学习，是放在一个专门的、集中化的机器学习或数据科学团队里，应用于其中一部分能产生价值的用例。无论是全新的应用还是既有的应用，生成式 AI 正在被普通的全栈开发者和应用开发者掌握。在整个组织里普及这种能力，正是 MongoDB 在努力做的事。他感谢了两位主持人，然后补充了一句贯穿整场节目的保留意见：事情变化得太快，他们会看看这些想法到底站不站得住脚。至少，那位修车技师再也不用对着纸质手册瞎猜了。