RAG后的检索：混合搜索、Agent与数据库设计

基本信息

摘要/简介

Turbopuffer 源于一款阅读应用。

导语

Turbopuffer 源于一款阅读应用，其创始人 Simon Hørup Eskildsen 结合实战经验，深入探讨了 RAG（检索增强生成）落地后的进阶技术。文章重点分析了混合检索、Agent 交互模式以及数据库设计在提升检索质量与系统性能中的关键作用。通过阅读本文，读者可以了解如何优化检索架构，从而在复杂场景下更精准地获取信息。

摘要

本文基于 Turbopuffer 联合创始人 Simon Hørup Eskildsen 的分享，总结了关于 RAG（检索增强生成）系统中的检索策略、智能体应用以及数据库设计的核心观点。

1. RAG 的现状与局限

目前的 RAG 系统虽然流行，但常被比作“玩具级”应用。大多数 RAG 仅依赖于基础的语义搜索（向量搜索），这在处理复杂查询时往往不够精确。为了提升检索质量，必须引入更高级的混合搜索和数据库设计。

2. 混合搜索

单纯依赖向量相似度是不够的，混合搜索是关键。它结合了以下技术：

  • 关键词搜索： 确保精确匹配（如专有名词）。
  • 向量搜索： 捕捉语义相似性。
  • 重排序： 在初步检索后，使用更精准的模型（如 Cross-Encoders）对结果进行重新排序，以牺牲一点速度换取显著的质量提升。

3. 智能体在检索中的角色

AI 智能体正在改变传统的检索逻辑：

  • 主动规划： 智能体可以将复杂的用户问题拆解为多个子任务，并自主决定需要检索哪些信息。
  • 工具调用： 它们可以动态调用 SQL 数据库、API 或搜索引擎，而不仅仅局限于向量库。这使得检索过程更加灵活和智能。

4. 数据库设计的演进

为了支持上述功能，底层数据库设计需要创新：

  • 解耦架构： Turbopuffer 主张将存储层与计算层分离。这种设计允许数据独立扩展，降低了成本，并提高了处理海量向量数据时的性能。
  • 性能与成本的平衡： 传统的向量数据库往往昂贵且难以扩展，新型的架构设计旨在以更低的成本提供更快的检索速度。

5. 起源背景

Simon 分享到，Turbopuffer 的技术灵感最初源于一个阅读应用的开发需求，旨在解决在海量文本数据中进行快速、精准检索的痛点。

总结： 未来的 RAG 系统将从简单的“向量匹配”进化为结合混合搜索与智能体的复杂系统。同时，底层数据库架构需要向存算分离和**高性能

评论

中心观点

文章的核心观点在于：随着RAG（检索增强生成）从简单的原型验证走向大规模生产环境，检索层必须从单纯的向量相似度匹配回归到以数据为中心的混合检索架构，并重新思考数据库设计以适应“检索后”的复杂性。（作者观点）

深入评价

1. 内容深度：从“炼丹”回归“工程”

事实陈述：文章指出Turbopuffer起源于一个阅读应用的需求，这奠定了其务实的基础。 评价：Simon Eskildsen 的观点极具深度，因为他切中了当前 AI 应用的痛点——幻觉与上下文管理的矛盾。许多开发者盲目迷信“向量数据库万能论”，认为只要把文本向量化就能解决所有问题。文章深刻地论证了关键词检索与语义检索并非替代关系，而是互补关系。在处理专有名词、ID或特定指令时，传统的 BM25 或倒排索引在召回率和精确度上远优于向量检索。这种对技术边界的清晰认知，体现了作者深厚的工程底蕴。

2. 实用价值：重新定义“检索后”的边界

你的推断：文章标题中的“Retrieval After RAG”暗示了一个行业趋势，即重心从“如何构建大模型”转向“如何喂好大模型”。 评价：对于实际工作，这篇文章具有极高的指导意义。它提醒架构师们，RAG 系统的瓶颈往往不在 LLM 的生成能力，而在检索的质量。文章讨论的 Agents（智能体）与数据库设计的结合，指明了未来的优化方向：数据库不再只是被动存储，而是需要支持智能体的主动查询规划、元数据过滤和多路召回。这直接指导了我们在构建企业级知识库时，不应盲目追求全量向量化，而应保留结构化数据的查询优势。

3. 创新性：架构的务实回归

作者观点：混合检索和精心的数据库设计是解决复杂查询的关键。 评价：虽然“混合检索”并非全新概念，但在向量数据库炒作火热的市场环境下，Turbopuffer 提出将 HNSW（一种流行的向量索引算法）与稀疏向量、关键词检索结合，并强调无服务器架构下的极致性能，这是一种“反共识”的创新。它没有创造新的算法，而是通过优化存储和计算分离，解决了向量数据库在高并发下的成本和延迟问题，这是一种工程层面的降本增效创新。

支撑理由与反例

支撑理由：

  1. 语义鸿沟的存在：[事实] 向量模型擅长理解意图，但弱于精确匹配。例如，用户查询“Python 3.10 的 GIL 修复机制”，向量检索可能召回关于 Python 性能的通用文章，而关键词检索能精准定位到版本号和特定术语。
  2. Agent 的复杂性：[作者观点] 智能体需要多次检索和自我修正。单一的向量检索无法支持这种多步推理，必须依赖结构化查询和元数据过滤来辅助决策。
  3. 成本与性能的权衡：[你的推断] 随着数据量增长，全量向量检索的算力成本不可持续。混合检索可以通过廉价的关键词检索缩小候选集，再进行向量重排序，显著降低成本。

反例/边界条件：

  1. 纯语义理解场景：在某些模糊搜索场景中，如“找一部关于失忆侦探的黑白电影”，用户完全不知道关键词，此时关键词检索失效，纯向量检索的效果远超混合检索。
  2. 超多模态数据：如果数据完全是图像或音频，且缺乏高质量的结构化标签，传统的倒排索引难以构建，此时可能更依赖多模态向量空间的直接检索。

争议点与不同观点

争议点：向量数据库是否需要一个独立的品类？

  • Turbopuffer 视角：[作者观点] 专门的向量数据库通过优化存储层（如分离计算与存储）能提供比传统 PostgreSQL 扩展（如 pgvector）更好的性能和弹性。
  • 反方观点：[行业共识] 引入独立的向量数据库增加了系统架构的复杂度和数据一致性维护的难度。随着 Postgres 扩展的优化（如 HNSW 索引进步），在中小规模数据下，统一数据库栈往往是更优解。

实际应用建议

  1. 不要抛弃关键词：在设计 RAG 系统时，必须保留 Elasticsearch 或 Postgres 的关键词检索通道，使用 Reciprocal Rank Fusion (RRF) 算法融合向量与关键词结果。
  2. 元数据即黄金：在向量化之前，先清洗数据并提取高质量的元数据（如日期、标签、作者）。在检索阶段，利用元数据进行预过滤，比单纯依赖向量相似度更能提升准确率。
  3. 评估重排序：建立一套评估机制，对比“仅向量检索”与“混合检索+重排序”在业务指标（如用户点击率、答案准确率）上的差异。

可验证的检查方式

  1. 指标：Hit Rate@K 与 MRR：
    • 操作：构建包含专有名词的测试集，对比纯向量搜索与混合搜索在 Top 5 结果中的召回率和平均倒数排名。
  2. 实验：AB 测试：
    • 操作：在实际应用中，对 50% 的流量使用混合检索（关键词+向量），50% 使用纯向量检索，观察 LLM 最终生成的答案引用来源的

技术分析

基于您提供的文章标题 《Retrieval After RAG: Hybrid Search, Agents, and Database Design — Simon Hørup Eskildsen of Turbopuffer》 以及摘要 “Turbopuffer came out of a reading app.”，结合 Simon Eskildsen（Turbopuffer 创始人，知名基础设施工程师）的一贯技术观点和近期 RAG 领域的技术演进，以下是对该文章核心观点和技术要点的深度分析。

1. 核心观点深度解读

文章的主要观点

文章的核心观点是：当前的 RAG（检索增强生成）系统过度依赖单纯的向量相似度检索，而忽略了传统搜索（关键词搜索）和数据库设计的精妙之处；未来的方向是“后 RAG 时代”的混合检索与智能代理的结合。

核心思想

作者试图传达“回归本源”的思想。Turbopuffer 诞生于一个阅读应用，这意味着它首先需要解决的是“精确匹配”和“上下文理解”并存的问题，而不仅仅是语义模糊匹配。

  1. 向量不是银弹：单纯的 Embedding 检索在处理专有名词、ID、精确短语时存在天然缺陷。
  2. 混合检索是标配：必须将 BM25（关键词）与 HNSW（向量）结合，才能获得人类级别的检索准确度。
  3. 数据库设计的重要性：在 Agent 时代，数据如何存储、切分和索引，直接决定了 LLM 能否“看到”正确的信息。

观点的创新性与深度

  • 创新性：打破了当前“向量数据库”营销战中“全量向量化”的迷思，提出了“检索之后”的视角——即拿到数据后如何通过 Agent 逻辑去处理，而不仅仅是如何拿到数据。
  • 深度：触及到了 RAG 系统的瓶颈——召回率与精确度的权衡。通过混合检索和精细化的数据库设计（如 Metadata Filtering），试图解决 LLM 幻觉问题的源头（检索不到或检索不准）。

为什么这个观点重要

随着 RAG 落地的深入，企业发现简单的“向量库 + LLM”原型在真实业务中表现糟糕（如查不到最新合同、无法理解用户特定的黑话）。Simon 的观点指出了从“玩具级 Demo”迈向“生产级系统”的关键路径：工程化检索策略。

2. 关键技术要点

涉及的关键技术

  1. 混合检索：
    • 原理：结合稀疏检索（如 BM25，基于关键词统计）和稠密检索（如 Embeddings，基于语义向量）。
    • 实现：通常通过 Reciprocal Rank Fusion (RRF) 算法将两路结果合并。
  2. HNSW (Hierarchical Navigable Small World)：
    • 原理：一种基于图的索引算法，是当前高性能向量检索的工业标准。
    • Turbopuffer 的特性：作为无服务器向量数据库，Turbopuffer 可能利用了独特的存储层优化（如基于 S3 的直接访问或优化的内存结构）来实现低延迟。
  3. 元数据过滤：
    • 原理：在向量搜索之前或期间，通过结构化数据（如时间、标签、用户ID）进行预筛选。
    • 难点：在大规模向量索引上进行高效过滤而不牺牲检索速度。
  4. 代理工作流：
    • 概念：LLM 不再是一次性生成答案，而是作为“大脑”去规划查询路径，调用检索工具，反思结果。

技术难点与解决方案

  • 难点：混合检索的延迟叠加。
  • 解决方案：Turbopuffer 可能通过在边缘节点或优化的存储层并行处理两种检索，或者利用倒排文件索引（IVF）结合过滤技术来加速。
  • 难点：上下文窗口与检索噪音的矛盾。
  • 解决方案：利用 Rerank（重排序）模型。虽然文章可能未详述，但混合检索本身就是一种初级 Rerank，配合 Agent 的多步推理可以过滤噪音。

技术创新点分析

Turbopuffer 的创新可能在于其架构的极简主义。它诞生于阅读应用，说明它不是为了“跑分”而生，而是为了“用户体验”而生。它可能强调：

  • Serverless 优先：无需管理复杂的向量集群。
  • Postgres 友好：可能利用 Postgres 的存储作为源头，而非试图替代 Postgres。

3. 实际应用价值

对实际工作的指导意义

如果你的团队正在构建 RAG 应用，这篇文章告诉你：不要把所有预算都花在购买昂贵的向量数据库上，应该花时间优化检索策略（混合）和数据清洗（数据库设计）。

应用场景

  1. 企业知识库：员工搜索既包含口语化问题（“怎么报销”），也包含精确代码或条款（“Section 4.2”）。混合检索是必须的。
  2. 电商搜索：用户搜“耐用的红色跑步鞋”（语义），也需要按“Nike”品牌（关键词）过滤。
  3. 阅读应用（如 Readwise Reader 等）：这是 Turbopuffer 的起源场景，需要处理大量非结构化文本，同时支持高亮、标签等结构化查询。

需要注意的问题

  • 复杂性增加：维护两套检索系统（关键词+向量）比一套要复杂。
  • 调优难度：混合检索中，向量结果和关键词结果的权重配比需要根据特定数据集微调。

实施建议

  1. 起步：先实现简单的关键词搜索，确保基础功能可用。
  2. 进阶：引入向量检索，使用 RRF 算法合并结果。
  3. 优化：加入 Metadata Filtering，确保数据权限和时效性。

4. 行业影响分析

对行业的启示

这标志着 RAG 基础设施正在从“单一功能堆砌”转向“专业化分工”。向量数据库不再是万能的，搜索质量重新成为核心竞争力，而不仅仅是向量索引的速度。

可能带来的变革

  • Search-as-a-Database：未来的数据库将原生具备混合搜索能力，开发者不需要手动拼接 ElasticSearch 和 Pinecone。
  • Agent-First 存储：数据存储格式将为了 Agent 的读取习惯而优化（例如，更小的 Chunk，更强的关联索引）。

发展趋势

  • RAG 的消亡？：正如标题“Retrieval After RAG”所暗示，RAG 可能会演变为更通用的“Agent 认知架构”，检索只是其中一个步骤。
  • 长上下文的冲击：随着 LLM 上下文窗口扩大（如 1M+ tokens），简单的向量检索可能被“把所有东西塞进去”取代，但混合检索对于精确定位依然不可替代。

5. 延伸思考

引发的思考

  • Embedding 模型的语义饱和：当前的 Text Embedding 是否已经足够好，以至于 BM25 变得不再重要？事实并非如此，特别是在处理低频词时。
  • 成本与收益：为了 5% 的准确率提升，引入混合检索和复杂 Agent 流程，运维成本是否值得？

拓展方向

  • GraphRAG：结合知识图谱，解决跨文档关联问题。
  • Fine-grained Access Control：在向量检索层直接解决权限问题（Row-level Security），这是目前很多向量库的软肋。

未来趋势

  • 端侧检索：随着设备算力增强，类似 Turbopuffer 这种轻量级、甚至可嵌入端侧的检索引擎可能会兴起。
  • 自适应检索：Agent 能根据 Query 类型自动判断是用关键词搜还是向量搜。

6. 实践建议

如何应用到自己的项目

  1. 评估现状：如果你的 RAG 系统只能回答“大概是什么”，而回答不了“具体是哪个条款”，你需要引入关键词检索。
  2. 数据清洗：这是 Turbopuffer 创始人强调的重点。脏数据比烂模型更致命。确保你的 Metadata 准确无误。

具体行动建议

  • 测试集构建：构建一个包含 100 个问题的测试集，其中 50 个是精确匹配（如 ID、专有名词），50 个是语义查询。分别测试纯向量、纯关键词、混合检索的效果。
  • 采用 RRF：不要简单地加权求和，使用 Rank Fusion 算法合并列表。

需补充的知识

  • 信息检索评价指标：理解 NDCG, MRR, Recall@K，而不仅仅是看 LLM 生成的通顺程度。
  • Elasticsearch/Lucene 基础：理解倒排索引的工作原理。

7. 案例分析

成功案例：Turbopuffer 的诞生（阅读应用）

  • 背景：在阅读应用中，用户可能记得文章中的一句话，但不记得标题。
  • 问题：纯关键词搜索如果用户输入有错别字会失败；纯向量搜索可能搜出大量相关但不是用户想要的那句原话。
  • 解决：混合检索允许用户即使有错别字（向量容错）也能找到精确的原文片段（关键词匹配）。

失败案例反思：过度依赖向量检索的客服机器人

  • 现象：用户问“退款政策在哪里”，机器人回答了关于退款的一般知识，却没给出公司具体的退款链接 PDF。
  • 原因：向量检索认为“一般知识”与 Query 语义最相似，忽略了“具体文档”这个 Metadata 属性。
  • 教训：必须引入 Metadata Filtering（强制只搜索官方文档）和关键词匹配（匹配“政策”一词）。

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

中心命题

在生产级 RAG 系统中，混合检索结合精细化的数据库设计，优于单纯的向量相似度检索。

支撑理由与依据

  1. 理由 1：语义模糊性。向量检索擅长理解意图，但弱于精确匹配。
    • 依据：在搜索特定 ID、产品代码或极少见的专有名词时，Embedding 往往会产生语义漂移。
  2. 理由 2：互补性。关键词检索（BM25）是稀疏的，向量检索是稠密的，二者覆盖的解空间不同。
    • 依据：TREC 等信息检索竞赛多年的数据表明，混合方法通常能获得最高的召回率。
  3. 理由 3：用户体验的根源。Turbopuffer 源于阅读应用，阅读需要精确引用。
    • 依据：用户在阅读场景下，往往是在寻找“原话”，而不仅仅是“意思”。

反例与边界条件

  1. 反例 1：极短上下文或口语化问答。例如“你好吗？”这类寒暄，关键词检索毫无意义，向量检索更优。
  2. 反例 2：超长上下文窗口模型。如果 LLM 能处理 1000 万字，可能不需要检索，直接全量输入（虽然目前成本和延迟仍不可行）

最佳实践

最佳实践指南

实践 1：采用混合搜索策略

说明: 单纯依赖语义搜索（向量搜索）在处理精确匹配关键词（如专有名词、产品ID或特定行话）时往往表现不佳。混合搜索结合了关键词搜索（BM25）和语义搜索的优势，既保留了语义理解的灵活性，又确保了精确匹配的召回率。这是提升 RAG 系统准确性的最直接手段之一。

实施步骤:

  1. 在数据入库阶段，同时生成向量 Embedding 和建立全文检索倒排索引。
  2. 在查询阶段，同时执行向量搜索和关键词搜索。
  3. 使用倒数排名融合（RRF）或加权分数合并算法来整合两组结果。
  4. 调整混合比例参数，根据具体业务场景（偏向精确查找还是语义理解）进行优化。

注意事项:

  • 需要确保向量数据库同时支持高性能的向量索引和全文索引。
  • RRF 算法通常比简单的加权求和更稳健，因为它不需要对分数进行归一化处理。

实践 2：优化数据库设计与分片策略

说明: 随着数据量的增长，单一的向量索引可能会遇到性能瓶颈。合理的数据库设计，特别是基于租户或文档组的分片策略，可以显著减少每次搜索的扫描范围，从而降低延迟并提高吞吐量。将相关性强的数据物理上存储在一起，可以避免“大锅饭”式的全局搜索。

实施步骤:

  1. 分析数据访问模式，确定自然的隔离边界（例如：按客户ID、项目ID或文档类别）。
  2. 在数据库层面实施分片，确保查询路由能够直接定位到相关的分片，而不是扫描整个数据库。
  3. 为每个分片建立独立的索引，以保持索引大小在可控范围内。
  4. 监控查询延迟，确保分片策略有效地减少了查询的扫描数据量。

注意事项:

  • 避免过度分片，以免增加管理复杂度和查询路由的开销。
  • 确保分片键的选择能够均匀分布数据负载，防止热点问题。

实践 3：利用智能体进行查询路由与重写

说明: 并非所有用户的问题都需要复杂的 RAG 流程。引入 Agent（智能体）机制，可以在执行昂贵的向量搜索之前，先对用户意图进行分类和路由。Agent 可以判断问题是需要检索外部知识，还是只需要简单的逻辑推理，或者需要对查询进行改写以获得更好的检索效果。

实施步骤:

  1. 构建一个轻量级的 LLM 路由层，接收用户的原始 Query。
  2. 训练或提示 LLM 识别查询意图（如：闲聊、精确数据查询、语义摘要等）。
  3. 根据意图将查询分发到不同的处理管道：对于模糊查询进行语义扩展，对于精确查询触发关键词搜索。
  4. 实现“自我修正”循环，如果初次检索结果不理想，Agent 可以自动重写查询并重试。

注意事项:

  • 路由层本身会增加轻微的延迟，需要权衡路由带来的收益与成本。
  • Agent 的决策逻辑需要足够透明，以便调试和优化。

实践 4：实施重排序机制

说明: 检索阶段通常追求召回率，会返回较多的结果（如 Top 20 或 Top 50），但这其中可能包含很多噪音。在检索之后、生成答案之前，引入一个重排序模型，可以精细地评估这些结果与问题的相关性，筛选出最准确的 Top K 结果喂给 LLM。这能显著减少幻觉并提高答案质量。

实施步骤:

  1. 在初步检索阶段获取比最终所需更多的文档（例如取回 Top 20）。
  2. 将这批文档与用户查询一起输入到专门的重排序模型中。
  3. 根据重排序模型的新分数，重新排列文档并截取最终的 Top 5 或 Top 10。
  4. 将经过精炼的上下文传递给生成模型。

注意事项:

  • 重排序模型会增加计算开销和推理延迟，通常适合对准确性要求极高的场景。
  • 选择与业务领域相关的重排序模型，或使用微调后的模型以获得最佳效果。

实践 5：精细化的元数据过滤

说明: 向量搜索返回的是数学上最相似的向量，但不一定符合业务逻辑（例如：时间范围、作者、权限状态）。仅仅依赖向量相似度是不够的，必须结合元数据进行预过滤或后过滤，以确保返回的内容不仅语义相关，而且在业务属性上是合法和有效的。

实施步骤:

  1. 在构建索引时，为每个文档块附加结构化的元数据（如创建时间、标签、访问权限）。
  2. 在查询构建中，除了向量输入外，同时附加严格的元过滤条件。
  3. 确保数据库引擎支持在向量搜索之前或同时应用这些过滤条件，以避免无效计算。
  4. 对于时间敏感的数据，强制实施时间范围过滤。

注意事项:

  • 某些向量数据库对“预过滤”的支持有限，可能导致性能下降，需测试具体数据库的表现。
  • 确保元

学习要点

  • RAG 系统的检索质量严重依赖于底层数据库设计，特别是将文档切分为更小的、语义独立的块（chunking）比保留长文档更能提高检索的精准度。
  • 混合搜索（结合关键词的精确匹配与向量搜索的模糊语义理解）是目前解决 RAG 幻觉和召回率低的最有效方案。
  • 专用的向量数据库（如 Turbopuffer）通过利用 SIMD 指令集和列式存储，在向量检索性能上远超通用的向量索引插件（如 pgvector）。
  • 智能体（Agents）不应仅被视为生成工具，更应作为检索系统的“路由器”，根据查询意图动态选择最合适的数据源或搜索策略。
  • 纯粹的向量相似度检索往往无法满足特定需求，必须引入关键词过滤（BM25）以处理专有名词、缩写及精确匹配的场景。
  • 在构建 RAG 应用时，应优先考虑“检索后处理”（如重排序 Rerank），这比单纯增加模型参数或扩大上下文窗口更能提升最终答案的质量。
  • 现代数据库架构需要从单纯的存储转向“计算与存储分离”，以便在云端环境中实现弹性扩展和更低的查询延迟。

引用

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

站内链接

相关文章