RAG之后的检索：混合搜索、Agent与数据库设计——Turbopuffer 的 Simon Eskildsen

摘要

• Turbopuffer 押注 AI 将创造一个15年一遇的数据库窗口，因为模型可以围绕知识进行推理，却无法以完整保真度存储所有知识。 Simon Hørup Eskildsen 的品类判断是，每家公司都会把大型数据集接入 AI，从而催生一个外部事实源：“我们不可能把所有东西都压缩进几TB的权重里。”

• 公司的起点，是一个极其具体、残酷的成本缺口：Readwise 整套基础设施每月约5,000美元，而一个有用的推荐功能预计就要花30,000美元。 Eskildsen 推断，如果成本只有原来的十分之一，Readwise 很可能已经上线该功能；于是他从餐巾纸算式出发，设计了一套以对象存储为先的搜索引擎，而不是先做广泛客户调研。“这件事一直萦绕着我。”

• Turbopuffer 的架构窗口，直到云端 NVMe SSD 在2017年前后出现、S3在2020年12月实现一致性、以及2024年末 S3 支持 compare-and-swap 后才真正打开。 持久状态放在对象存储，热数据上浮到 NVMe 和 DRAM，系统不再需要独立的共识层；Eskildsen 的运行原则很直接：“我不想让状态存在两个系统里。”

• Cursor 和 Notion 提供了早期商业验证：Cursor 用1-2周完成迁移，并将成本削减95%。 当 Notion 需要降低俄勒冈州跨区域约14毫秒的公共交换路径延迟时，Turbopuffer 花约5,000美元购买暗光纤，承担出口流量费用并调优 TCP。Eskildsen 认为，买还是自建如今“已经不太是我们能不能做，而是我们有没有时间做”。

• Agent 式检索把查询量从一次 RAG 查找扩展为单个 Agent 发起的多路并发搜索，迫使数据库重新适配经济模型。 随着客户并行执行语义、全文和正则搜索，Turbopuffer 正将查询价格下调约5倍。主持人的总结是“所有工作负载都是混合型的”，而 Eskildsen 转述 Sualeh 的说法：检索就是“缓存算力”。

• Turbopuffer 能实现盈利，部分原因在于早期基础设施账单直接压在 Eskildsen 的信用卡上，迫使团队在获得机构融资前就从第一性原理出发优化成本。 当前定价仍由存储、写入和查询组成，只是中间靠“胶带和唾沫”勉强粘着；部署方式则覆盖 SaaS、单租户和客户 VPC。Eskildsen 与 Lachy Groom 的融资约定同样反常：如果年底前仍看不到产品市场匹配，“我们就把所有钱都退还给你。”

• 短期上行空间来自从向量搜索拓展到全文搜索，并将数据集规模做到1,000亿条，同时不丢掉创业公司的专注度。 ANN v3 在约40毫秒 P50、200毫秒 P99 下搜索1,000亿个向量；ANN v4 已在推进，ANN v5 正在规划，FTS v3 的功能也在逐步发布。更长期的查询计划可能包括 OLAP、日志、时序和图，但 Eskildsen 认为最可能后悔的是“试图做得太多”。

• Turbopuffer 的执行模式依赖极其挑剔的招聘，而不是不断堆积员工数量。 每名候选人起初都默认被拒，除非面试官愿意“举起双拳”争取录用；团队寻找的 P99 工程师，能够识别餐巾纸算式与现实之间10倍的差距，再让软件向物理极限靠拢。

精读

1. AI 缺失的那一层，是可搜索的外部记忆

• Eskildsen 将今天的 Turbopuffer 严格定义为搜索引擎：提供向量搜索和全文搜索，明显需要更多能力的工作负载可能应该交给其他系统。更大的目标，是成为非结构化数据的搜索引擎，而不是又一个套着 AI 标签的通用数据库。

• 他的前提始于压缩极限：模型可以吸收“数艾字节、数艾字节”的训练数据，并编码出理解世界的推理方式，但“我们不可能把所有东西都压缩进几TB的权重里”。因此，AI 需要一个外部系统，以“完整保真度和真实性”保存知识。

• Eskildsen 认为，一家大型数据库公司需要满足3个前提：最终触达每家公司的工作负载；竞争对手难以改造复制的存储架构；以及一条路径，能够实现客户可能对已存储数据提出的几乎所有查询计划。Oracle 抓住了一个时代，约15年后，Snowflake 和 Databricks 又抓住了另一个时代——或许更久；把大型数据集接入 AI，可能定义下一个时代。

2. 一个30,000美元的功能，先于客户暴露了市场

• 在 Shopify 近10年的经历，让 Eskildsen 学会在极端流量下扩展数据库，包括应对接近每秒100万次请求的事件。最让他头疼的系统，是2015年前后的自托管 Elasticsearch：项目受其限制，而要暴露 Shopify 所需的 Lucene 行为也非常困难。

• 离开 Shopify 后，他实践所谓的“天使工程”，在朋友的公司做约3个月的项目，包括 Readwise、Replicate 和 Causal。在 Readwise，他名义上的工作是改进 Postgres——“归根结底就是调 autovacuum”——直到 ChatGPT 时刻到来，团队开始考虑用文章嵌入做推荐。

• 原型的效果好得近乎令人不安：Readwise 一位联合创始人的推荐结果里出现了关于生孩子的文章，而 Eskildsen 当时还不知道这件事。但 Readwise 整套基础设施每月成本约5,000美元，为这个单一功能嵌入并索引文章，算下来却接近30,000美元。

• Readwise 暂停了这个功能，等成本下降，但 Eskildsen 无法放下：“这件事一直萦绕着我。”他手头唯一的市场数据是：如果成本降到十分之一，公司很可能已经上线该功能。于是他开始研究向量索引和云基础设施，而不是先炮制一套宏观叙事。

3. 对象存储成了数据库本身，而不只是备份

• Eskildsen 的餐巾纸算式是：把持久数据放进对象存储，将活跃部分拉入 NVMe SSD，再把最热的一小部分提升到 DRAM。在他的简化例子里，S3 中1TB每月成本约200美元，可能只有5%-10%需要驻留 NVMe，更少部分需要 DRAM，从而大幅降低“膨胀”存储数据的成本。

• 代价也很明确：每次写入可能需要几百毫秒，第一次查询可能要半秒。因此，Turbopuffer 不适合高事务型工作负载；Eskildsen 后来表示，其写入延迟约100毫秒。他从未假设搜索是纯粹的读密集型场景，因为 Readwise 的内容变化可能带来比实际搜索更多的写入。

• 他的第一个向量设计几乎是刻意保持原始：把聚类元数据放在 clusters.json 文件里，每个聚类存放在独立对象中，先取回最近的聚类，再在本地计算邻居。这样大约只需要两次存储往返，而不是一长串相互依赖的读取。

• 更深层的系统原则，是在轮次之间尽量少做决策、同时发起大规模并发：一次并行发送大约1,000个 S3 请求，处理结果后再重复，且最多不超过约3轮。Eskildsen 认为，以这种方式使用时，NVMe 的带宽可以接近 DRAM，只相差一个较小倍数；对象存储则可以把网卡跑满。

4. 3次云基础设施升级，让这套架构成为可能

• 关键时间线很重要：云端 NVMe SSD 在2017年前后出现；S3 在2020年12月实现一致性；S3 则直到2024年末才获得 compare-and-swap。三者合在一起，让团队可以围绕对象存储构建数据库，而不必维护独立的底层数据库、ZooKeeper 或类似的共识层。

• compare-and-swap 允许多个节点下载 metadata.json，修改后仅在期间没有其他节点改动原文件的情况下写回；发生冲突时直接重试。Turbopuffer 刚开始时，Google Cloud Storage 已经提供了这一原语，多少带有运气成分：Eskildsen 选择 GCP，是因为 Shopify 使用它，而且他认识其加拿大团队。

• 因此，Turbopuffer 选择了“all in”：即使关闭所有服务器，也不会丢失数据。Eskildsen 和联合创始人 Justine 更偏好这种方式，而不是双状态运行，因为他们最糟糕的值班经历，都与系统失去同步有关。当被问及为什么选择光纤而不是 ZooKeeper 时，他回答：“当然更愿意。我不想让状态存在两个系统里。”

• Notion 是 AWS 客户，当时希望降低延迟，这一信念也因此付出了代价。由于云服务商的区域在地理上分离，俄勒冈州的流量要经过西雅图，延迟约14毫秒。于是 Turbopuffer 在俄勒冈州的 AWS 和 GCP 区域之间购买暗光纤，经由波特兰交换中心路由，成本约5,000美元；团队自行承担出口流量费用，并接受单线路设计，而行业通常会部署多条冗余线路。

5. Cursor 和 Notion 把架构转化成了产品市场匹配

• Turbopuffer 的上线版本刻意保持简陋：Eskildsen 独自工作到夏天结束后，在一台8核机器上的 tmux 里运行一个 Rust 二进制文件。部署意味着盯着请求日志，在业务安静的时刻按下 Control-C——这是他从 Shopify 带来的规则：基础设施只有在展现出“至少一点 PMF 的迹象”后，才值得获得更多复杂度。

• Cursor 联合创始人 Arvid 先发起了一段简短交流，内容是 QPS、成本和增长预测。后来 Sualeh 提议在太平洋时间凌晨约4:00通话，Eskildsen 从东海岸接了电话，意识到自己需要见这支团队后，便赶到旧金山；当时 Cursor 的 Postgres 正处于宕机状态，他临时建议对 autovacuum 进行调优。

• Cursor 在接下来1-2周完成迁移，Turbopuffer 将其成本降低95%；Eskildsen 认为，这修复了 Cursor 的单用户经济模型。他招来了 Justine——“我在 Shopify 共事过的最优秀工程师”——两人在接下来1-2个月里确保数据库永远不会成为 Cursor 的问题。

• Notion 的内部工程师此前独立画出了几乎相同的存储架构，后来才发现 Turbopuffer 已经把它做了出来。Eskildsen 对这笔采购的解释颇具启发性：AI 已经把买还是自建从“我们能不能做”变成了“我们有没有时间做”。一个表现得像团队延伸的供应商，买到的是速度。

6. 混合检索之所以能存活，是因为不同查询揭示不同事实

• Cursor 使用自有嵌入模型，将完整代码库切块并生成嵌入；据称，这在某项特定评测中带来了25%的提升，而且在更大的代码仓库上尤其有效。它的 Agent 使用语义搜索寻找相似或功能相关的代码，同时也使用 grep；两种机制谁都没有取代谁。

• 主持人追问“既然有 grep，RAG 是否已经死了”，最后落到更广泛的结论：工作负载本来就是混合的。语义搜索、词法搜索和正则表达式，分别回答不同问题。Eskildsen 不愿预测宏观未来——“事实证明，那是巨大的时间浪费”——而是专注于收集具体的客户案例。

• Cursor 也把外部数据库视为一道安全边界：其私有嵌入模型提高了逆向还原的难度，文件路径经过混淆，存放在 Turbopuffer 存储桶中的客户数据则使用 Cursor 自有的加密密钥加密。Eskildsen 认同这些是任何外部数据库都应采取的合理做法，并非 Turbopuffer 特有的让步。

• 按 Eskildsen 的回忆，Sualeh 的框架是：检索就是“缓存算力”。在某个特定时刻，模型聚焦于某个特定上下文，而搜索提供一个针对该状态定制的中间层。Eskildsen 不愿预测其价值将如何随时间变化，但当前工作负载表明，它对特定查询确实重要。

7. Agent 把一次检索变成一阵并发搜索

• Eskildsen 将经典 RAG 与8,000 token 的上下文窗口、以及一次必须精打细算的检索联系在一起。Agent 则把搜索当作工具调用，反复查询并改变工作状态，同时由模型负责推理。

• 架构变化在于单个用户会话内部的并发，而不只是跨用户批处理：“一个 Agent 驱动多个。”Notion 每轮往返都会发起 Eskildsen 所称的“荒谬数量”的查询；Cursor 的 Agent 也越来越并行。目标与 Turbopuffer 的内部机制一致：用大量搜索命中热数据集，同时尽量减少串行轮次。

• 主持人提到 Cognition 会并行执行8次快速上下文搜索，并追问 Agent 如何避免把同一个请求发出8次。他们的答案是查询多样性：混合检索提供根本不同的搜索模式，而不是对同一个语义请求做表面变化。

• 搜索次数增加后，单位经济模型也随之变化。Turbopuffer 正将查询价格下调约5倍，未来还可能进一步下调，以支持这类突发并发。Eskildsen 表示，写入量相对读取仍然极高，但如果客户全面采用 Agent 式并行，二者比例可能发生变化。

8. 透明融资强化了第一性原理经济学

• 最初的定价“非常凭感觉”：Eskildsen 先估算物理成本，再加上一点利润。当 Cursor 的使用量加速增长时，它的账单仍低于 Turbopuffer 的 GCP 账单，于是他和 Justine 不断优化，努力在云端负债压在个人信用卡上的同时，实现约5%的利润率。

• 这种压力帮助 Turbopuffer 实现盈利，也让其 VC “大为懊恼”。当前定价仍拆分为存储、写入和查询，但 Eskildsen 称，这是原有结构靠“胶带和唾沫”粘起来的版本，后续还会继续调整。客户可以选择 SaaS、专用单租户集群，或部署在自有 VPC 内的 BYOC。

• 在竞争对手准备发布产品的同时，Eskildsen 进行融资。他选择 Lachy Groom，而不是数据库专业投资人，因为他可以不做准备就打电话，直接坦率沟通：如果年底前没有 PMF，“我们就把所有钱都退还给你。”面对陌生游戏，他的规则很简单：“我就把牌摊开来打。”

• Groom 缺乏数据库专业知识，反而成了优势而非障碍：创始人和员工提供深度，Groom 则帮助寻找候选人和客户，但从不假装自己懂得更多。接受这笔支票，也意味着 Eskildsen 有意让公司“成为我人生旅程的一部分”；一旦员工和投资人依赖于公司，他就会全力投入。

9. Turbopuffer 只有在搜索赢得下一幕后才会扩大边界

• 第一幕是向量搜索，第二幕是全文搜索。Turbopuffer 声称，在 Common Crawl 规模数据集上处理异常长、由 LLM 生成的查询时，性能优于 Lucene；同时，它也在补齐成熟词法搜索引擎用户期待的大量功能，并吸引传统搜索产品的客户迁移。

• 即便是极短的人类查询，全文搜索仍然有价值：在 Command-K 中输入“si”，嵌入可能会把结果引向西班牙语或意大利语里表示“是”的词，而字面前缀搜索则可能找出一份以“These are all the reasons I hate Simon”开头的文档。混合搜索同时映射语义和用户的精确意图。

• 规模是另一项短期优先任务。ANN v3 在约40毫秒 P50、200毫秒 P99 下搜索1,000亿个向量；ANN v4 正在推进，ANN v5 正在规划；全文搜索则将逐步改进，最终推进到 FTS v3。Eskildsen 还希望打造一个具备 phpMyAdmin 实用性的数据库控制台，而不是继续堆积一个运行了2年的创业公司仪表盘。

• 长期来看，一家大型数据库必须支持聚合、连接以及几乎所有查询计划。可能的下一幕包括更简单的 OLAP、链路追踪、日志、时序和图，全部建立在 Turbopuffer 底层键值系统之上；Simon 提到一份报告称，Cursor 将约20TB从 Postgres 迁出，以推迟分片。但今天，搜索必须仍然是客户采用它的首要理由：“到年底，我们最可能后悔的，就是试图做得太多。”