Retrieval After RAG: Hybrid Search, Agents, and Database Design — Simon Hørup Eskildsen of Turbopuffer

基本信息

摘要/简介

Turbopuffer came out of a reading app.

导语

检索增强生成（RAG）系统的性能瓶颈往往不在于生成模型本身，而在于如何精准地召回上下文。Turbopuffer 联合创始人 Simon Hørup Eskildsen 在本文中深入探讨了 RAG 落地后的进阶挑战，重点解析了混合检索、Agent 协同以及数据库架构设计对系统效果的影响。通过阅读这篇文章，读者可以了解到从原型走向生产环境时，如何优化检索链路以提升最终答案的准确性与可靠性。

摘要

本文基于 Turbopuffer 创始人 Simon Hørup Eskildsen 的分享，对检索增强生成（RAG）系统中的“后检索”阶段进行了深入探讨，主要涵盖混合搜索、智能体架构及数据库设计三个核心领域。

1. 混合搜索：结合语义与关键词 单纯的向量搜索（语义理解）或关键词搜索（BM25）各有优劣。Simon 指出，混合搜索是未来的趋势。它通过结合稠密向量（Dense Vectors，擅长语义匹配）和稀疏向量（Sparse Vectors，擅长关键词匹配），能够同时满足用户对意图理解和精确词汇匹配的需求。这种双重机制能有效解决“词汇鸿沟”问题，并在特定领域（如代码搜索）中表现优异，是提升检索质量的关键。

2. 智能体架构与数据库交互 随着大模型应用的发展，检索方式正从静态转向动态。智能体不再局限于被动接收检索结果，而是能够根据任务需求主动规划检索步骤。

  • 工具使用： 智能体可以决定何时调用搜索引擎、数据库查询或向量检索。
  • 反思与迭代： 智能体能对初步结果进行评估，如果不满足需求则自动生成新的查询词进行二次检索（Re-Ranking 或自我修正）。 这种架构对底层数据库提出了更高要求，不仅要能高效返回结果，还需具备处理复杂、动态查询逻辑的能力。

3. 数据库设计与 Turbopuffer 的理念 Turbopuffer 起源于一个阅读应用的开发需求，旨在解决传统向量数据库在云原生环境下的痛点。

  • 分离存储与计算： Simon 强调利用对象存储（如 S3）作为核心，将存储层与计算层解耦。这不仅降低了成本，还利用了云服务的高可用性。
  • 无状态与快速启动： 传统的数据库维护复杂，而 Turbopuffer 追求无状态架构。由于数据存储在 S3 上，计算节点可以像无服务器函数一样快速启动和销毁，极大简化了运维并提高了弹性。
  • 性能优化： 通过特定的数据结构（如 HNSW 图）和压缩技术，在不牺牲检索速度的前提下降低存储开销。

总结 在 RAG 系统中，高质量的“后检索”环节至关重要。通过采用

评论

中心观点

Simon Hørup Eskildsen（Turbopuffer 创始人）主张：随着 RAG（检索增强生成）从“玩具”走向生产级应用，传统的向量检索已不足以支撑复杂需求，行业必须回归数据库设计的本质，通过混合检索与Agent 化的查询路由来解决精准度问题，而非单纯依赖模型或向量算法。

深度评价与支撑理由

1. 内容深度：从“模型中心”回归“数据工程”

  • 支撑理由（事实陈述/作者观点）： 文章最具洞察力的一点在于指出了 RAG 发展的阶段性。早期 RAG 依赖向量检索的“语义模糊匹配”来弥补关键词的不足，但这在生产环境中会导致“幻觉”或“不可控的精确度”。Eskildsen 提出的观点是，检索不应仅仅是“Embedding + KNN”，而应当包含传统的 BM25、过滤以及 Agent 的动态决策。这触及了信息检索（IR）的本质：召回率与精确率的权衡。
  • 支撑理由（你的推断）： 文章暗示了一个深层趋势，即 AI 基础设施的“数据库化”。向量数据库不再是独立的新物种，而是逐渐与传统数据库能力融合。Turbo puffer 的架构设计（基于 S3 的无服务器架构）反映了这一趋势：存储与计算分离，利用云原生的弹性解决向量检索的高成本和低扩展性问题。
  • 反例/边界条件（批判性思考）： 作者的观点建立在“结构化数据与半结构化数据共存”的场景下。对于纯粹的非结构化创意生成（如基于风格生成图像、长文本的创意续写），传统的 BM25 或精确过滤作用有限，此时语义向量的发散性检索反而是核心优势，过度强调数据库设计可能会限制模型生成的创造力。

2. 实用价值：混合检索是当前的最优解

  • 支撑理由（事实陈述）： 文章明确指出 Hybrid Search（混合检索）是当前行业的必经之路。在实际案例中（如电商搜索、法律文档检索），单纯依赖向量会导致同义词扩展过度，而单纯依赖关键词则无法处理用户意图的变体。混合检索通过结合语义相似度和关键词匹配，能显著提升 Hit Rate（命中率）和 MRR（平均倒数排名）。
  • 反例/边界条件： 混合检索带来了延迟和成本。维护两套索引（向量+倒排）并进行结果合并，在超大规模数据集（如亿级以上向量）下，对工程架构提出了极高挑战。对于初创公司或 MVP 阶段，直接使用高质量的 Embedding 模型（如 OpenAI text-embedding-3）往往比搭建复杂的混合检索系统更具性价比。

3. 创新性：Agent 作为查询路由器

  • 支撑理由（作者观点）： 文章提出了一个新颖的架构视角：Agent 不仅仅是生成内容的工具，更是数据库的查询优化器。传统的数据库依赖查询优化器决定索引选择，而在 RAG 时代，Agent 可以根据用户意图动态决定：“这个问题需要查元数据（SQL）？”、“需要查语义（向量）？”还是“需要查最新资讯（搜索 API）？”。这打破了传统 RAG 的固定 Pipeline 模式。
  • 反例/边界条件： 这种架构极大地增加了系统的不确定性。将查询逻辑交给 Agent 意味着引入了概率性的决策层。当 Agent 错误判断意图时（例如将精确的 ID 查询误判为语义搜索），排查错误的难度将呈指数级上升，远超传统 SQL 的 Debug 难度。

4. 行业影响：向量数据库的“祛魅”

  • 支撑理由（你的推断）： Turbo puffer 的出现和该文章的传播，标志着行业对“向量数据库”这一独立品类的反思。未来可能不再有单纯的“向量数据库”，而是具备向量扩展能力的全功能数据库。文章批评了现有向量数据库过度追求“写入性能”而忽视“查询性价比”的现状，这可能会推动行业向更轻量、存储计算分离的架构演进。
  • 反例/边界条件： 专用硬件（如 GPU 集群）在极端吞吐量场景下依然不可替代。对于需要毫秒级响应的实时推荐系统，专用的、内存优化的向量数据库（如 Milvus, Weaviate）依然有其生存空间，Turbo puffer 这种基于对象存储的架构可能受限于网络 I/O。

可验证的检查方式

为了验证文章中关于“混合检索”与“数据库设计”观点的有效性，建议采用以下指标和实验进行观察：

  1. RAG 三大指标对比实验（指标）：

    • 构建一个包含 1000 个复杂问题的测试集。
    • 分别测试 Pure Vector Search（纯向量）、Pure Keyword Search（纯关键词）、Hybrid Search（加权混合）。
    • 验证指标： Context Precision（上下文精确度）和 Context Recall（上下文召回率）。如果混合检索在 Precision 上显著高于纯向量，则支持作者观点。

  2. 查询延迟与成本分位数观察（观察窗口）：

    • 在生产环境中观察 P95 和 P99 延迟。
    • 验证方式： 检查当引入 Agent 进行查询路由和混合检索后，P99 延迟是否超过了用户忍耐阈值（通常为 1-2秒）。如果 Agent 带来的智能无法抵消

技术分析

基于您提供的标题、摘要以及对 Simon Hørup Eskildsen（Turbopuffer 创始人）技术背景的深度了解，以下是对该主题“RAG 之后的检索：混合搜索、智能体与数据库设计”的全面深入分析。

深度分析：RAG 之后的检索架构与数据库设计

1. 核心观点深度解读

主要观点： 文章的核心观点在于反驳当前业界对“向量数据库”的盲目崇拜。Simon 认为，单纯的向量搜索不足以支撑生产级 RAG 系统。真正的解决方案不是追求极致的向量算法，而是回归到混合搜索——即结合关键词搜索（BM25）、语义搜索与元数据过滤。此外，他主张通过精心的数据库设计（如 HNSW 索引优化）来替代昂贵的基础设施，并提出未来的检索将由智能体动态驱动，而非静态的查询语句。

核心思想： “检索”是 RAG 系统的瓶颈，但解药不是更昂贵的向量数据库，而是更聪明的搜索策略（混合）和更高效的数据结构（Turbopuffer 的无服务器架构）。

创新性与深度： 该观点极具反叛性和实用性。在 AI 炒作将“向量数据库”捧上神坛时，Simon 指出向量检索本质上是“模糊的查找”，而传统的关键词搜索在处理专有名词、精确匹配时依然不可替代。深度在于他探讨了**“查询理解”**的演进：从简单的向量匹配，到智能体通过多步推理来构建复杂的检索查询。

重要性： 这一观点对于构建企业级 AI 应用至关重要。它纠正了“只要向量化就能解决一切”的错误认知，直接决定了 RAG 系统的准确率和响应速度。

2. 关键技术要点

涉及的关键技术：

  1. 混合检索： 结合稀疏向量（关键词/BM25）和稠密向量。
  2. HNSW (Hierarchical Navigable Small World)： 当前最先进的向量索引算法，Turbopuffer 对其进行了极致优化。
  3. 无服务器架构： 将数据库索引与计算分离，利用对象存储（如 S3）存储索引，按需启动计算。
  4. 重排序： 检索后的精排步骤。

技术原理与实现：

  • 混合搜索原理： 纯向量搜索擅长理解语义（如“水果”找“苹果”），但弱于精确匹配（如找具体的型号 “iPhone 15 Pro”）。混合搜索通过同时执行两条路径，将结果集合并（通常通过 Reciprocal Rank Fusion 算法），以此兼顾语义广度和精度。
  • Turbopuffer 的实现： 传统向量数据库需要常驻内存来维护 HNSW 图，成本高昂。Turbopuffer 的创新在于将 HNSW 图直接存储在 S3 上，查询时才加载到内存。这使得存储成本极低，且能轻松处理亿级向量。

技术难点与解决方案：

  • 难点： 混合搜索的延迟叠加，以及 HNSW 图在磁盘上的读取速度。
  • 方案： 利用 SIMD 指令集加速向量计算；通过量化技术减少向量体积；在数据库层面优化 I/O 吞吐。

3. 实际应用价值

对实际工作的指导意义： 不要试图用一种向量索引解决所有问题。如果你的 RAG 系统经常回答不出具体的人名、数据或代码细节，很可能是因为你缺失了关键词搜索能力。

应用场景：

  • 企业知识库： 员工搜索既包含概念（“如何报销”）又包含实体（“Form 1040”）。
  • 电商搜索： 用户搜“耐克红鞋”，需要品牌过滤（关键词）和风格匹配（向量）。
  • 代码分析： 变量名必须精确匹配，但逻辑意图需要语义理解。

需要注意的问题： 混合搜索会增加系统的复杂度。你需要维护两套索引，并调整两者的权重（Alpha 参数）以适应不同业务场景。

实施建议： 在构建 RAG 时，默认开启混合搜索模式。优先选择支持原生混合搜索的数据库，或者在同一数据源上分别建立向量索引和全文索引。

4. 行业影响分析

对行业的启示： 向量数据库赛道正在经历“去魅”阶段。行业将从“专用向量数据库”转向“具备向量能力的通用数据库”或“极致性价比的专用存储”。Turbo puffer 代表了后者：存储与计算彻底解耦。

可能带来的变革：

  • 成本结构变革： 检索层的成本将大幅下降，使得超大规模数据集的 RAG 成为可能。
  • 架构变革： 智能体将不再仅仅调用 LLM，而是频繁调用“检索工具”，检索本身将成为一种可编程的 API。

发展趋势： 未来的数据库将不再区分“向量”和“标量”，而是统一处理多模态数据。同时，Agentic RAG（智能体 RAG）将取代简单的 RAG，智能体会根据用户问题动态决定是搜向量、搜 SQL 还是搜网页。

5. 延伸思考

拓展方向：

  • 动态检索策略： 能否根据查询的复杂度，自动决定是使用向量搜索还是关键词搜索？
  • 多阶段检索： 先用低成本算法筛选，再用高成本模型重排序。

需进一步研究的问题：

  • 如何在混合搜索中自动学习最优的加权系数？
  • 当检索由智能体控制时，如何防止检索循环导致的延迟爆炸？

6. 实践建议

如何应用到项目：

  1. 评估现有 RAG： 检查你的系统日志，统计哪些查询失败了。如果是专有名词查询失败，加入 BM25。
  2. 架构选型： 如果数据量在百万级以下，PostgreSQL + pgvector 是性价比之王；如果数据量上亿，考虑 Turbopuffer 或 Pinecone 等云原生方案。
  3. 数据清洗： 无论用什么数据库，高质量的数据切片比算法更重要。

具体行动：

  • 实施 RRF（Reciprocal Rank Fusion）合并你的搜索结果。
  • 为你的元数据建立专门的过滤索引，不要把所有信息都塞进向量里。

7. 案例分析

成功案例：

  • Read Reader (Turbopuffer 的前身)： Simon 在开发阅读应用时发现，用户搜索书中的内容往往既记得“大概意思”（语义）又记得“只言片语”（关键词）。纯向量搜索导致找不到书名，纯关键词搜不到内容。混合搜索完美解决了这个问题。

失败反思：

  • 过度工程化： 许多初创公司在只有几万条数据时就引入了庞大的 Milvus 或 Weaviate 集群，导致运维成本高于业务价值。实际上，简单的内存检索或 SQLite 就能解决问题。

8. 哲学与逻辑：论证地图

中心命题: “在生产级 RAG 系统中，混合搜索与优化的数据结构比单纯的向量算法更接近检索的真理。”

支撑理由:

  1. 语义的局限性: 向量检索本质上是基于概率的模糊匹配，无法处理需要精确匹配的场景（如 ID、特定术语），这导致 RAG 产生幻觉或遗漏关键信息。
  2. 效率的必要性: 传统的常驻内存向量数据库成本过高且扩展性差，Turbopuffer 证明了通过分离存储与计算可以极大地降低检索门槛。
  3. 智能体的需求: 未来的检索是动态的，智能体需要结合元数据过滤和语义理解来构建复杂查询，单一维度的向量搜索无法满足这种组合逻辑。

反例/边界条件:

  1. 纯语义探索: 当用户的查询意图非常模糊，且不包含特定关键词，旨在探索“相关概念”时（例如“给我一些关于后现代主义解构的灵感”），纯向量搜索往往能提供更发散、更有创意的结果，混合搜索可能会引入噪音。
  2. 超小规模数据: 在数据量极小（如 < 1000 条文档）时，简单的全文搜索加上 LLM 的长上下文窗口可能比构建复杂的向量索引更有效、更廉价。

命题分类:

  • 事实: 关键词搜索在精确匹配上优于向量搜索；对象存储比内存存储便宜。
  • 价值判断: “混合搜索是更好的工程选择”。
  • 可检验预测: 随着模型上下文窗口的增大，简单的检索方式可能会被淘汰，但复杂的、多跳的检索将更加依赖混合索引。

立场与验证: 我支持 Simon 的观点。验证方式： 构建两个 RAG 管道，A 为纯向量搜索，B 为混合搜索。使用包含“专有名词查询”和“概念查询”的混合测试集进行评估。指标：Hit Rate（命中率）和 MRR（平均倒数排名）。预测 B 组在涉及具体实体的查询中准确率显著高于 A 组。

最佳实践

最佳实践指南

实践 1：实施混合搜索策略

说明: 单纯的向量搜索在处理精确匹配（如产品ID、特定缩写）时表现不佳，而传统的关键词搜索（BM25）在处理语义理解时存在局限。混合搜索通过结合稠密向量（语义理解）和稀疏向量（关键词匹配），能够互补两者的不足，显著提升召回率和准确度。

实施步骤:

  1. 在数据索引阶段，同时生成文本的 Embedding 向量和用于倒排索引的词频统计。
  2. 在查询阶段，并行执行向量搜索和关键词搜索。
  3. 使用倒数排名融合（RRF）或加权评分算法合并两个结果集。
  4. 根据业务场景调整稠密检索与稀疏检索的权重比例（例如 50:50 或 70:30）。

注意事项: 混合搜索会增加计算延迟和存储成本，需要评估检索性能与结果质量之间的平衡。

实践 2：优化数据库架构以支持高效检索

说明: 传统的通用向量数据库在面对大规模数据或特定查询模式时可能遇到性能瓶颈。根据数据访问模式和查询需求设计数据库架构（例如利用专门的列式存储或优化的索引结构），可以大幅降低检索延迟，提高吞吐量。

实施步骤:

  1. 分析查询模式，确定是更需要低延迟还是高吞吐量。
  2. 选择支持高效过滤和向量检索的存储后端，避免在向量检索前进行昂贵的行级过滤。
  3. 考虑将元数据与向量分离存储或使用支持 SIMD 指令集的优化数据库。
  4. 对数据库进行基准测试，确保在海量数据下仍能保持亚秒级的响应速度。

注意事项: 不要盲目追随流行技术栈，应根据实际数据量级和读写比例选择底层存储引擎。

实践 3：采用代理模式处理复杂查询

说明: 用户的查询往往无法通过一次简单的检索就得到答案。引入代理模式，利用 LLM 的推理能力将复杂问题分解为多个步骤，自主决定使用何种工具（如搜索引擎、数据库查询、API 调用）以及何时进行检索，可以解决更复杂的任务。

实施步骤:

  1. 定义代理可用的工具集，包括检索器、计算器和外部 API。
  2. 设计提示词，赋予 LLM 规划和决策的能力。
  3. 建立反馈循环，允许代理根据中间结果调整检索策略。
  4. 实施记忆机制，使代理能够记住上下文中的关键信息。

注意事项: 代理链路的调用成本较高且延迟较大，建议仅在处理需要多步推理的复杂问题时使用，简单查询应直接路由。

实践 4：在检索前进行查询重写与扩展

说明: 用户的原始查询可能存在歧义、信息缺失或表达不清晰。在执行检索之前，利用 LLM 对查询进行改写、澄清或扩展，能够使其与文档库中的内容更加对齐，从而提高检索的相关性。

实施步骤:

  1. 检测用户查询是否包含足够的上下文信息。
  2. 如果查询模糊，利用 LLM 生成多个可能的变体或更具体的描述。
  3. 将历史对话的上下文融入当前查询中。
  4. 使用重写后的查询执行向量或关键词检索。

注意事项: 查询重写会增加额外的 LLM 推理时间，对于追求极致低延迟的场景，可以考虑使用小模型或缓存常见改写结果。

实践 5：精细化处理元数据与过滤条件

说明: 向量相似度搜索往往会返回语义相近但在逻辑上无效的结果（例如时间不符、权限不符）。利用元数据进行预过滤或后过滤，是确保 RAG 系统返回准确且合规信息的关键。

实施步骤:

  1. 在文档分块时，提取并结构化存储关键元数据（如创建时间、作者、标签、摘要）。
  2. 在构建查询时，附带必要的过滤条件（例如“只查找 2023 年后的文档”）。
  3. 优先选择支持“预过滤”的向量数据库，即先过滤再计算向量距离，以提高效率。
  4. 对于复杂的权限控制，在检索结果返回后再次进行严格的权限校验。

注意事项: 过于严格的预过滤可能会导致没有足够的结果进行向量计算，需要设置合理的过滤阈值或回退机制。

实践 6：评估与优化重排序机制

说明: 初始检索（如 Top-K）返回的结果可能包含不相关的文档。在检索后引入重排序模型，对召回的文档进行更精细的相关性打分并重新排序，可以显著提升最终生成内容的质量，减少幻觉。

实施步骤:

  1. 确定初始检索的召回数量（例如 Top 30 或 Top 50），为重排序留出空间。
  2. 选择适合业务领域的重排序模型，可以是基于 BERT 的交叉编码器。
  3. 将用户查询和召回的文档一起输入重排序模型进行打分。
  4. 截取重排序后得分最高的 Top-K 结果（例如 Top 5）

学习要点

  • RAG系统的核心瓶颈在于检索而非生成，提升检索质量比优化模型本身更能显著改善最终答案的准确性。
  • 混合检索（结合关键词BM25与语义向量）优于单一的向量检索，能同时精准匹配专有名词并理解语义意图。
  • 查询重写是提升检索召回率的关键技术，通过将用户问题改写为更适合搜索的形态来弥补语义鸿沟。
  • 智能体通过自主规划检索路径、多次调用工具并整合结果，能够处理单一检索无法回答的复杂问题。
  • 数据库设计（如分块策略和元数据过滤）对检索性能的影响往往被低估，合理的结构化存储能大幅提升效率。
  • 现代向量数据库应优先优化写入吞吐量和实时性，以适应RAG应用中数据频繁更新的需求。

引用

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

相关文章