原始标题: Retrieval After RAG: Hybrid Search, Agents, and Database Design — Simon Hørup Eskildsen of Turbopuffer
发布日期: 2026-03-12 | 来源频道: @latent-space
📝 深度摘要
1. 核心技术主旨 (The TL;DR)
本期节目揭示了 RAG 范式从「单次检索」向「并行 Agent 检索」演进的底层逻辑。Simon Eskildsen 作为前 Shopify 基础设施工程师，用「 napkin math 」思维推导出一个核心洞察：AI 时代的数据连接工作负载（connecting very large amounts of data to AI）需要全新的存储架构——全栈 NVMe SSD + S3 强一致性 + 无共识层。TurboPuffer 正是基于这三大支柱构建的向量+全文搜索引擎，其本质是成为 AI 与海量非结构化数据之间的「外部记忆层」。当 LLM Context Window 突破百万 token、Agent 并行搜索成为常态，传统数据库的读写比与延迟模型已彻底失效。Simon 断言：未来每家公司都会直接或间接地将全部数据接入 AI，这正是构建下一个 Oracle/Snowflake 级别数据库公司的历史性窗口。
2. 嘉宾背景与当前技术栈 (Guest & Tech Stack)
嘉宾身份： Simon Hørup Eskildsen，TurboPuffer 联合创始人兼 CTO，前 Shopify 基础设施工程师。18 岁加入 Shopify，在其数据中心工作近十年，后以「天使工程师」身份游走于 Readwise、Replicate 等初创公司。
核心产品/架构： TurboPuffer 是一个专注于搜索的数据库，同时提供向量搜索（Vector Search）和全文搜索（Full-Text Search）。其架构完全构建在对象存储（S3/GCS）之上，摒弃传统共识层（Zookeeper/etcd），利用 NVMe SSD 实现热数据缓存，借助 S3 强一致性（2020年12月上线）实现数据持久化。典型客户包括 Cursor、Notion、Anthropic 等 AI 原生公司。
3. 底层架构与技术深潜 (Hardcore Architecture & Engineering)
a. 系统架构与硬件交互 (Infra & System Design)
存储架构的三次技术跃迁： Simon 提出构建伟大数据库公司的两大条件——新工作负载 + 新底层存储架构。他指出，NVMe SSD 进入云端（约2017年）和 S3 强一致性上线（2020年12月）是两个关键里程碑。之前无法实现「全栈对象存储 + 无共识层」的架构，因为没有强一致性保证就无法放弃 Zookeeper 这样的协调组件。
无状态架构的工程哲学： TurboPuffer 的核心设计原则是「可以关掉所有服务器但不丢失任何数据」。所有数据完全存储在 S3/GCS 上，计算层完全无状态。这意味着没有 Zookeeper、没有 etcd、没有传统意义上的「主节点」。Simon 认为多系统间的状态同步是运维梦魇（worst outages are the ones where you have state in multiple places that’s not syncing up），因此彻底放弃状态层。
Compare-and-Swap (CAS) 元数据管理： 在 S3 支持 CAS 之前（2024年底），TurboPuffer 只能在 GCS 上使用 CAS 做元数据管理。Simon 提到：「你可以把 metadata.json 想象成一个文件，一百个节点同时想修改它。CAS 的原理是：下载文件、做修改、写回——仅当文件在你修改期间未发生变化。如果变了，就重试。」这个看似简单的机制替代了复杂的分布式共识算法。
裸光纤降低跨云延迟： 经典案例：Notion 当时运行在 AWS，而 TurboPuffer 部署在 GCP，俄勒冈州的 GCP 和 AWS 数据中心相隔约 200 公里，公网交换要经过西雅图，延迟达 14ms。Simon 团队选择购买「暗光纤」（dark fiber）直连，费用仅 $5,000。他们还调优 TCP window、预热连接，用一切手段把延迟往下压。Simon 说：「我们不愿意在 S3 上做元数据层，因为我们对此有强烈信念（high conviction）。」
读写路径设计： 写入路径上，每次写入到 S3 约增加几百毫秒延迟，但这是唯一真正的 downside。读取时采用「最多三次往返」策略：第一轮请求获取 cluster 列表，第二轮下载最相关的 cluster 文件，第三轮在本地运行近邻搜索。Simon 强调：「NVMe SSD 可以驱动接近 DRAM 带宽的吞吐量，S3 可以跑满网卡带宽，但之前的数据库没有按这个模式设计。」
b. AI 范式与工作流重构 (AI Paradigms & Workflows)
从 RAG 到 Agentic Search： Simon 观察到工作负载的根本变化。两年前，RAG 只是在 LLM 查询开始时做一次搜索来构建 context（8,000 token 窗口）。现在，Agent 模式下，模型边写代码边搜索，结果再被搜索，形成循环。更关键的是并行性（concurrency）：Notion 和 Cursor 的 Agent 会在单次 round trip 中发起「巨量查询」。Cursor 一次会做 8 个并行搜索。这与 TurboPuffer 数据库的设计理念高度吻合——最大化每次往返的并发请求数。
混合搜索（Hybrid Search）策略： Simon 明确反对「只押注单一查询模式」。他认为所有 workload 都是 hybrid 的——你需要语义搜索（embedding）、你需要全文搜索（full-text regex）、你需要精确匹配（SQL exact match）。Cursor 的实践最具代表性：他们使用自研 embedding 模型做语义搜索，用 grep 做精确模式匹配。Simon 引用 Swale（Cursor 联创）的比喻：「这就像 cache compute——你在某个时间点关注某个特定的 context chunk，就像神经网络在特定层的 activation。」
Agent 并行查询的工程挑战： 当一个 Agent 同时发起 8 个并行搜索时，如何避免重复请求？Simon 认为混合搜索是天然的多样化手段——不同类型的搜索不会产生相同的请求。他透露，TurboPuffer 正在将查询定价降低 5 倍，以适应这种「巨量查询」的工作模式。
c. 评估体系与工程阻力 (Evals & Engineering Bottlenecks)
Cursor 的 25% 提升： Cursor 在特定 eval 上实现了 25% 的准确率提升，部分归功于 TurboPuffer 提供的语义搜索能力。他们自研 embedding 模型，并在公开博客中详细介绍了训练方法。Simon 强调：「我们不做 thought piece（宏观预测），我们收集 case studies。只有case study 才能验证技术价值。」
最大工程阻力：[未提及具体细节] 播客中未详细讨论 Agent 幻觉控制、内部 Evals 评估集构建逻辑或系统回归问题的调试方法。Simon 主要分享了架构层面的决策，对具体工程阻力的讨论较为简略。
安全实践： Cursor 在 TurboPuffer 上实现了 exceptional 的安全姿态——使用自研 embedding 模型（难以逆向工程）、混淆文件路径、用客户自己的加密密钥加密数据。Simon 表示：「这是最佳实践，任何数据库都该这样做。」
4. 产品哲学与商业化博弈 (Product Philosophy & GTM Strategy)
a. 颠覆性反共识洞察 (Contrarian Hot Takes)
1. 数据库公司每 15 年才出现一次窗口期： Simon 认为要构建伟大的数据库公司，需要两个条件同时满足：(1) 新工作负载（AI + 数据连接），(2) 新存储架构（NVMe SSD + S3 强一致性）。这两个条件的交汇只在特定历史时刻出现。
2. 不做「功能齐全」的数据库： Simon 对「什么都能做」的数据库持批判态度：「如果你试图在 TurboPuffer 上做 search 之外的事情，现在可能不是正确的选择。」他认为创业公司的唯一模式是 focus，TurboPuffer 目前只专注搜索。他提到看到很多同行「overextend themselves」，这是他最担心的事情。
3. 不迷信知识图谱： 播客中 Simon 未直接批判知识图谱，但他对混合搜索的强调暗示了对单一查询范式的否定态度。他认为所有 workload 都是 hybrid 的，押注单一技术路线风险极高。
b. 商业模式与成本经济学 (Business Model & Unit Economics)
Vibe Pricing → First Principles Pricing： TurboPuffer 早期的定价完全是「vibe pricing」——Simon 用一张纸算了一下「如果 TurboPuffer 做得很好，应该收多少钱」，然后加了点 margin。Cursor 成为客户后，Simon 发现自己的 GCP 账单比 Cursor 的账单还高，于是被迫优化定价以实现 5% 利润率。他坦言：「我现在对 VC 们很抱歉（to the chagrin of the VCs），因为我们早期定价压力导致我们现在盈利了。」这种「从第一性原理出发但实际靠生存压力倒逼优化」的定价历程，堪称创业公司的经典案例。
定价结构： TurboPuffer 目前的定价基于三个维度——存储（storage）、写入（writes）、查询（queries）。Simon 表示这是「用 duct tape and spit（胶带和口水）勉强拼凑出的定价」，今年会持续优化。他特别提到查询定价正在降低 5 倍，以适应 Agent 并行搜索的工作负载。
Buy vs. Build 决策： Simon 认为 AI 改变了买与造的逻辑：「现在的问题不是’能不能自己造’，而是’有没有时间自己造’。」Notion 的工程师曾对他说：「我们自己在 napkin 上画过——为什么没人做这个？然后我们看到了 TurboPuffer——就是这玩意儿。」
客户分层： TurboPuffer 提供三种部署模式：(1) SaaS（Cursor 使用）、(2) 单租户集群（Notion 使用）、(3) BYOC（Anthropic 使用，客户数据完全在自有 VPC 内）。
5. 极客文化、组织构建与野史 (Hacker Culture, Team & Lore)
a. 人才密度与招聘哲学 (Talent & Hiring)
P99 工程师定义： Simon 内部定义了「P99 工程师」概念，意为「top 1% 的工程师」。他有一份 traits of the P99 engineer 文档，每次面试后都会对照检查。他的招聘哲学非常硬核：「默认应该是不招这个人。如果没有人站出来说’我愿意为这个候选人赌上我的职业生涯’，我们就拒绝。」
P99 工程师的两个核心特质：
- 曾将轨迹掰向自己的意志（bent trajectory to their will）： 某个时刻，他们让计算机做了它本来做不到的事。典型案例：TurboPuffer 首席架构师 Nathan 在 6-8 周内将 ANN V3 优化到可以搜索千亿向量（P50 ~40ms，P99 ~200ms）。
- ** obsession（ obsession ）：** Simon 半开玩笑地说：「P99 工程师喜欢看地图。」他的灵感来自一次 IOI 金牌得主的采访——被问及业余爱好时，回答是「看地图」。Simon 认为这是一种「weaponized autism」——对某个领域的极度痴迷。
招聘流程： TurboPuffer 的面试会刻意筛选这些特质。Simon 强调人才密度（talent density）的重要性，并认为 Cursor 创始团队是这方面的典范——他们从第一性原理出发，坚持只招最优秀的人。
b. 硬核极客日常与轶事 (Geek Lore & Quirks)
暗光纤事件： 为解决 Notion 的跨云延迟问题，Simon 团队购买了连接 AWS 俄勒冈区域和 GCP 俄勒冈区域的暗光纤。Simon 说：「GCP 的销售从未见过创业公司这么做。我们告诉他们：我们六个月后可能会从你们这儿搬到 AWS，但现在我们要这么做。」
创始阶段的「 Scrabby 」部署： TurboPuffer 刚发布时，就是一个 Rust binary 运行在 GCP 的 8 核 tmox 实例上。Simon 部署的方式是「看着请求日志，手动执行命令升级 binary」。他故意这么做：「在 Shopify 我们也这样——在产品有 PMF 之前先用 tmox 跑服务。」
与 Cursor 的深夜 P0 级支持： Cursor 是 TurboPuffer 的第二个大型客户（第一个是 Notion）。Simon 回忆：「他们迁移过来的那几周，我们简直往死里干（worked like hell）。Swally 凌晨 4 点给我发邮件问能不能通话——我当时在东海岸，是早上 7 点，我说当然可以。」他当天就飞到旧金山拜访他们办公室，到了才发现他们的 Postgres 正在 down 机。
茶道极客： Simon 是资深茶爱好者拥有一个收录 200 种茶的 AirTable。他展示了从日本静冈县进口、按中国工艺制作的 Yabukita 煎茶。他还有个专门的旅行茶具包，包括温度计（因为不同茶需要不同水温）。他打趣道：「你们应该开一个 YouTube 频道，不讲搜索，只讲茶和其他 rant。」
与 Lucky 的坦诚对话： Simon 在融资时给投资人 Lucky 打电话说：「如果年底还没 PMF，我把你的钱退回去。」Lucky 是唯一没被吓到的人。Simon 说：「我问他：你投过数据库公司吗？他说没有。我当时觉得自己是不是太蠢了。但后来发现他的价值恰恰是不懂数据库——他只懂人和客户。」
6. 未来推演与终局思考 (Future Outlook & Endgame)
a 短期技术前瞻 (Next 12-18 Months)
TurboPuffer Act 2（当前阶段）： 全栈全文搜索（Full-Text Search）。Simon 透露 TurboPuffer 在某些 benchmark 上已经超越 Lucene，尤其是 LLM 生成的长查询场景。今年的核心任务是「feature grind」——持续添加全文搜索功能，并推动更多客户从传统搜索引擎迁移。
Scale 提升： 客户需求已指向「Common Crawl 级别」的数据集——百亿向量、百亿文档。Simon 正在推进 ANN V4 和 V5 的研发，目标是在保持延迟的前提下进一步降低成本。
Dashboard 重写： Simon 吐槽现有 Dashboard「看起来就像两年前某个创始人随手写的」——今年会进行大幅度改进，包括 SSO 等企业级功能。
b. 长期演进形态 (The Endgame)
TurboPuffer Act 3-5 规划： Simon 明确表示不会现在就决定 Act 3 的具体内容，因为创业公司需要 focus。但他列出几个可能方向：简化 OLAP 查询、traces/logging、时间序列。他认为最终目标始终是「连接 AI 与海量数据的数据库」。
客户驱动的路线图： Simon 的策略是让 P99 客户告诉他下一步需要什么——「我们的客户是 P99，他们会告诉我们他们最在乎什么。」他提到已经有人在用 TurboPuffer 做图查询（graph queries），因为 TurboPuffer 本质上是个 KV 存储，parallel queries 可以模拟图遍历。
Simon 的核心信仰： 「做数据库公司，你最终必须实现几乎所有查询模式——aggregation、join。但创业公司的唯一模式是 focus。你必须有序地做事情，什么顺序是正确顺序？这就是好 startup 的核心。」
7. 原汁原味金句 (Based Quotes)
- “We don’t have a consensus layer. In fact, you could turn off all the servers that TurboPuffer has, and we would not lose any data because we are completely all in on S3 storage.” 我们的架构没有共识层。实际上，你可以关掉 TurboPuffer 的所有服务器而不会丢失任何数据，因为我们完全基于 S3 存储。
- “The worst outages are the ones where you have state in multiple places that’s not syncing up.” 最糟糕的故障是那种多地有状态但不同步的情况。
- “If you’re trying to do much more than search, this might not be the right place yet. But TurboPuffer is all about search.” 如果你想在搜索之外做太多事情，现在可能不是正确的选择。但 TurboPuffer 专注的就是搜索。
- “We want to see people fight for this candidate… The default should not be we’re going to hire this person. The default should be we’re definitely not hiring this person.” 我们希望看到有人为候选人据理力争……默认不应该是「我们要录用这个人」，而应该是「我们坚决不录用这个人」。
- “When I don’t know how to play a game, I just play with open cards.” 当我不知道怎么玩这个游戏时，我就把牌摊开打。
本摘要基于播客转录稿整理，未引入任何外部信息。部分技术细节（如具体 benchmark 数据、工程阻力讨论）在原文中未展开，已如实标注。
📺 播客地址
播客时长: 61分钟