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

基本信息

摘要/简介

Turbopuffer 源自一款阅读应用。

导语

随着大语言模型应用的深入，单纯依赖向量检索往往难以满足复杂场景对准确性的严苛要求。本文基于 Turbopuffer 的工程实践，深入探讨在 RAG 架构中引入混合检索、智能体及数据库设计的具体策略。通过分析这些进阶技术，读者可以了解如何优化检索质量，从而在实际项目中显著提升系统的最终效果。

摘要

Turbopuffer 起源于一个阅读应用的开发需求，其创始人 Simon Hørup Eskildsen 在构建该应用时意识到传统数据库在处理特定数据检索时的局限性，从而推动了 Turbopuffer 的诞生。以下是核心内容的总结：

1. 起源与背景

Turbopuffer 最初是为了解决阅读应用中的数据检索问题而设计的。随着 RAG（检索增强生成）技术的普及，团队发现单纯依赖向量检索或传统关键词搜索存在不足，因此开发了一种兼顾两者的混合搜索方案。

2. 混合搜索的优势

  • 结合向量与关键词搜索：向量搜索擅长语义理解，但可能忽略精确匹配；关键词搜索则相反。Turbopuffer 的混合方案通过整合两者，提升了检索的准确性和灵活性。
  • 优化查询效率：通过智能路由，系统能根据查询类型自动选择最优搜索方式，减少延迟并提高结果相关性。

3. 智能代理的应用

  • Turbopuffer 引入了代理机制，能够动态分析用户查询意图，例如判断是需要模糊语义匹配还是精确关键词过滤，从而调整检索策略。
  • 代理还能结合上下文信息，优化多轮对话中的检索结果，提升用户体验。

4. 数据库设计创新

  • 存储与计算分离：Turbopuffer 采用云原生架构，支持弹性扩展，适应不同规模的数据需求。
  • 索引优化：针对混合检索场景，设计了专门的索引结构，平衡了读写性能与存储成本。

5. 技术实践与挑战

  • 在实际部署中，团队面临的主要挑战是如何在保持高并发性能的同时，实现复杂的混合查询逻辑。通过分布式缓存和查询优化，Turbopuffer 成功解决了这一问题。
  • 此外，团队还强调了数据库在 RAG 流程中的“后检索”阶段的重要性，即如何对检索结果进行二次排序和过滤，以满足生成式 AI 的输入需求。

总结

Turbopuffer 通过混合搜索、智能代理和优化的数据库设计，为 RAG 系统提供了更强大的检索能力。其技术栈不仅适用于阅读应用，还可扩展至其他需要高效语义与关键词结合的场景。

评论

中心观点

文章主张在 RAG（检索增强生成）系统的演进中，随着模型推理能力的提升，传统的“检索即服务”模式正面临挑战，混合检索的精细化控制、智能体的自主检索循环以及针对向量特性的数据库底层设计，将成为突破 RAG 性能瓶颈的关键路径。

深度评价

1. 内容深度：从“黑盒”到“白盒”的回归

  • 支撑理由（作者观点）： 文章深刻指出了当前 RAG 领域的一个痛点：过度依赖向量检索的“语义模糊性”。Eskildsen 强调，随着 LLM 智能化程度提高，简单的语义匹配已不足以支撑复杂的推理需求。他重新审视了 BM25（关键词检索）的价值，认为混合检索不是“加法”，而是“互补”，这触及了信息检索的核心——召回率与精确率的平衡。
  • 支撑理由（事实陈述）： Turbopuffer 作为一个从阅读应用孵化出的数据库，其技术背景强调了“边缘计算”和“冷存储”优化。文章对数据库设计的讨论（如 SIMD 指令集优化、HNSW 算法的变体）展示了工程实现的深度，而非停留在应用层的 API 调用。
  • 反例/边界条件（你的推断）： 尽管混合检索被推崇，但在极度依赖长尾语义理解的场景（如法律判例的类比推理）中，纯粹的向量检索往往优于关键词检索，因为关键词可能完全缺失。此外，对于超大规模实时数据流（如 Twitter 级别的实时索引），复杂的混合重排序算法可能会引入不可接受的延迟，此时单纯的向量近似检索可能是唯一可行的方案。

2. 创新性：重新定义数据库的“角色”

  • 支撑理由（作者观点）： 文章提出了一个新颖的观点：数据库不应仅仅是被动的存储桶，而应成为智能体的“主动感知层”。通过 Agents（智能体）主动发起多次、迭代式的检索，数据库变成了模型推理过程的一部分，而非仅仅是入口。
  • 支撑理由（你的推断）： 这种观点挑战了传统的“一次性检索”范式。它暗示未来的 RAG 系统将更像是一个操作系统，数据库在其中提供原生的“记忆索引”服务，支持非线性的信息访问路径。

3. 实用价值：工程落地的“避坑指南”

  • 支撑理由（作者观点）： 文章不仅谈理论，还涉及了具体的数据库设计权衡。例如，讨论了在 PostgreSQL 上使用 pgvector 的局限性（如锁竞争、扩展性问题），以及专用向量数据库在特定场景下的必要性。这对架构师选型具有极高的参考价值。
  • 反例/边界条件（事实陈述）： 对于 90% 的初创公司而言，PostgreSQL + pgvector 已经足够。引入像 Turbopuffer 这样的专用数据库会增加运维复杂度和数据迁移成本。除非数据量达到千万级向量且对延迟极度敏感，否则过度设计是常见的陷阱。

4. 行业影响与争议点

  • 争议点（你的推断）： 文章隐含了对“通用大模型 + 简单 RAG”模式的否定。这可能会引发关于**“模型能力 vs 检索质量”**的讨论。一部分观点认为，随着模型上下文窗口的扩大到 100万+ token，复杂的检索策略可能变得多余，因为模型可以直接“吞下”整个知识库。Eskildsen 的观点则建立在“检索是为了降低计算成本和提高精准度”之上，这与“大力出奇迹”派存在根本分歧。

实际应用建议

  1. 架构演进策略： 不要一开始就上复杂的 Agent 检索循环。建议从基线开始，先跑通 Vector Search，再引入 BM25 做混合，最后根据模型推理的失败案例引入 Agent 机制。
  2. 数据冷热分离： 借鉴 Turbopuffer 的思路，区分“热数据”（高频访问、需低延迟）和“冷数据”（历史归档）。热数据使用昂贵的内存型向量库，冷数据使用基于磁盘的廉价存储（如 Turbopuffer 提倡的 S3 直接挂载模式）。
  3. 评估指标建设： 建立针对检索阶段的专项评估，而不是仅看最终生成效果。如果检索准确率（Hit Rate）低，再好的模型也是“垃圾进，垃圾出”。

可验证的检查方式

为了验证文章中关于混合检索和数据库设计的观点，建议进行以下检查：

  1. 指标对比实验：

    • 操作： 构建一个标准数据集（如 BEIR），分别测试纯 Vector Search、纯 BM25、以及 Hybrid Search（RRF 融合）的 nDCG@10 和 Recall@k 指标。
    • 预期结果： 在事实型问答中，Hybrid Search 应显著优于纯 Vector Search；在语义推理题中，Vector Search 应保持领先。

  2. 延迟基准测试：

    • 操作： 在相同数据集（如 500万向量）下，对比 PostgreSQL (pgvector) 与专用向量数据库（如 Turbopuffer/Qdrant）的 P99 延迟和吞吐量（QPS）。
    • 预期结果： 随着并发数增加，通用数据库的延迟增长曲线应比专用数据库更陡峭。

  3. Agent 检索循环观察：

技术分析

基于您提供的文章标题 《Retrieval After RAG: Hybrid Search, Agents, and Database Design — Simon Hørup Eskildsen of Turbopuffer》 及其背景摘要（Turbopuffer 源于一个阅读应用），结合 Simon Hørup Eskildsen（Shopify 前基础设施负责人、Turbopuffer 联合创始人）的一贯技术主张，以下是对该核心观点和技术要点的深度分析。

深度分析报告：RAG 之后的检索演进与数据库设计

1. 核心观点深度解读

文章的主要观点

文章的核心观点在于批判当前 RAG（检索增强生成）应用中“重模型、轻检索”的倾向。Simon 主张，在 LLM 能力趋于平缓的当下，系统的性能瓶颈已从“生成”转移回“检索”。单纯依赖向量检索是不够的，未来的核心在于混合检索与数据库设计的回归。

核心思想

作者传达的核心思想是“基础设施的解耦与专业化”。传统的向量数据库试图做所有事情（向量搜索、元数据过滤、全文本搜索），结果往往是在大规模数据下性能平庸。Turbopuffer 的理念是剥离存储与计算，利用云对象存储（如 S3）作为底座，构建一个极致优化的无状态检索层。

观点的创新性和深度

  • 从“专用数据库”回归“通用存储”：Turbopuffer 提出不再维护自有的存储层，而是直接基于 S3 构建索引。这是一种“Serverless Native”的数据库架构创新，极大地降低了运维成本和扩展难度。
  • 对“Agent 时代”数据结构的预判：随着 Agent 的兴起，数据检索不再是简单的“问答”，而是复杂的“工具调用”和“上下文筛选”。这要求检索系统具备极强的元数据过滤能力，而这正是传统向量数据库的弱项。

为什么这个观点重要

随着企业将 AI 从原型推向生产，他们发现向量检索的“幻觉率”和“不精确率”过高。Simon 的观点指出了 RAG 进化的下一阶段：必须结合传统的 BM25（关键词）和精确过滤，才能达到生产可用标准。

2. 关键技术要点

涉及的关键技术或概念

  1. HNSW（Hierarchical Navigable Small World）：目前最高效的向量索引算法之一，Turbopuffer 对其进行了针对云环境的特殊优化。
  2. Hybrid Search（混合检索）：结合 Dense Retrieval（向量/语义）和 Sparse Retrieval（关键词/BM25）的搜索方式。
  3. Object Storage as Database（对象存储即数据库）：直接将 S3 作为数据的 Source of Truth，数据库实例无状态，可随时销毁和重启。
  4. Metadata Filtering（元数据过滤）：在向量搜索之前或之中，通过结构化字段（如日期、类别、ID）进行精确筛选。

技术原理和实现方式

  • 架构原理：Turbopuffer 不使用传统的 B-Tree 或 LSM-Tree 存储引擎。它将数据分片并直接存储在 S3 上。当查询发生时，它利用 FaaS（如 Lambda）或容器瞬间拉取必要的索引分片到内存中进行计算。
  • 混合搜索实现：通过同时加载向量索引和倒排索引，在内存中合并结果集（Reciprocal Rank Fusion 或加权融合），实现语义与关键词的匹配。

技术难点和解决方案

  • 难点：S3 的 GET 请求延迟高（通常几十毫秒），如何保证检索速度？
  • 方案：Turbopuffer 使用了列式存储格式和微分片策略，只加载查询相关的特定数据段，并利用高内存缓存进行优化，将延迟控制在毫秒级。
  • 难点：HNSW 构建索引耗时长且耗内存。
  • 方案：将索引构建过程解耦，利用无状态计算节点进行离线或准实时构建，然后推送到 S3。

技术创新点分析

最大的创新点在于**“无状态向量数据库”**。传统向量数据库（如 Pinecone, Milvus）需要维护昂贵的集群状态。Turbopuffer 证明了可以将“计算”与“存储”彻底分离，让向量搜索像 CDN 一样简单和可扩展。

3. 实际应用价值

对实际工作的指导意义

对于正在构建 RAG 应用的工程师，这意味着不需要盲目追求昂贵的专用向量数据库集群。如果数据规模在千万到亿级向量，且对成本敏感，应优先考虑基于云原生存储的解决方案。

可以应用到哪些场景

  • 电商搜索：Shopify 背景使得 Turbopuffer 特别适合电商场景。用户搜索“红色连衣裙”，既需要语义理解（“裙子”），也需要精确过滤（颜色=红，库存>0）。
  • 文档归档与合规：需要大量元数据过滤（如时间范围、作者、部门）的 RAG 系统。
  • 多模态搜索：图片与文本的混合检索。

需要注意的问题

  • 数据实时性：基于 S3 的架构通常有轻微的延迟（非实时写入），不适合对毫秒级写入一致性要求极高的金融交易场景。
  • 网络带宽：频繁从 S3 拉取数据会产生网络出口费用，需计算成本。

实施建议

在实施 RAG 时，不要只做 Embedding。务必保留原始文本数据用于 BM25 索引，并保留结构化元数据用于过滤。采用 “Vector Search + Keyword Search + Rerank” 的三段式 pipeline。

4. 行业影响分析

对行业的启示

Turbopuffer 的出现挑战了 Pinecone、Weaviate 等“独角兽”的商业模式。它揭示了：向量搜索可能不应该是一个独立的、昂贵的数据库品类，而应该是一种廉价、通用的云原生存算服务。

可能带来的变革

  • 成本结构的变革：向量搜索的成本将大幅下降，从“按节点付费”转向“按存储和查询量付费”。
  • 架构的简化：企业不再需要维护复杂的向量数据库运维团队，基础设施代码将大幅减少。

相关领域的发展趋势

  • PostgreSQL 的崛起：与 Turbopuffer 的“分离存储”理念类似，Pgvector 也证明了通用数据库结合向量插件是很多中小企业的首选。
  • Search as a Service：检索将变得更加模块化和 API 化。

5. 延伸思考

引发的其他思考

如果存储层变成了 S3，那么“数据库”的边界在哪里？未来的数据库可能只是一层**“智能索引视图”**。这让我们联想到 Data Lakehouse（数据湖仓）的概念，数据库引擎正在变得“透明”。

可以拓展的方向

  • Rerank 模型的集成：在检索之后，如何低成本地运行 Cross-Encoder 进行重排序？
  • 量化技术：利用 Product Quantization (PQ) 或 Binary Quantization 进一步压缩 S3 上的存储占用。

未来发展趋势

“Retrieval After RAG” 意味着 RAG 之后，检索技术本身将迎来新一轮的爆发。未来的 Agent 将不再依赖单一的向量库，而是动态调用 SQL、向量、图数据库等多种检索工具。

6. 实践建议

如何应用到自己的项目

  1. 评估数据量：如果你的向量数据超过 5000 万，且元数据过滤复杂，尝试 Turbopuffer 或类似架构。
  2. 混合检索策略：在代码层面实现 RRF（Reciprocal Rank Fusion），合并 BM25 和 KNN 结果。
  3. 元数据设计：在 Embedding 之前，先设计好结构化的 Schema，不要把所有信息都塞进 Vector 里。

具体的行动建议

  • 不要在 Prompt 中做过滤（效率极低）。
  • 不要在向量维度上做精确数学匹配（向量是模糊的）。
  • 利用 Turbopuffer 的 filter 语法进行预筛选。

需要补充的知识

  • 学习 HNSW 算法原理。
  • 了解 S3 的 API 与性能特性（GET vs LIST）。
  • 掌握 RRF 算法逻辑。

7. 案例分析

结合实际案例说明

案例：Shopify 的店铺搜索 Shopify 处理数百万个商品。早期使用 Elasticsearch，后来引入向量搜索。

  • 问题：纯向量搜索无法处理“价格低于 50 美元”这种硬性条件。纯 ES 无法处理“类似 iPhone 的手机”这种语义需求。
  • 解决：采用混合架构。先用元数据过滤出符合价格、库存的商品子集，再在这个子集上进行向量语义搜索。

成功案例分析

Turbopuffer 本身就是一个成功案例。它从一个阅读应用（Read.Reader）的内嵌工具演变为通用基础设施，证明了**“Dogfooding”（自用驱动开发）**在基础设施领域的有效性。

经验教训总结

很多初创团队失败的原因是**“为了用向量而用向量”，丢弃了原有系统中宝贵的精确匹配能力。成功的 RAG 系统必须是“保守的精确性 + 激进的语义性”**的结合。

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

中心命题

在 RAG 系统的生产化阶段，解耦存储与计算的无状态架构（如 Turbopuffer）优于传统耦合型向量数据库，且混合检索是解决准确率的唯一路径。

支撑理由与依据

  1. 理由 1：成本与扩展性
    • 依据：S3 的存储成本远低于 SSD 云盘。计算与存储分离允许独立扩展。
    • 事实：云存储价格每 GB 仅为高性能块存储的 1/10。
  2. 理由 2：检索准确率的上限
    • 依据：向量检索擅长模糊匹配，但在处理实体名称、ID 等精确信息时表现糟糕。
    • 直觉：用户查询 “iPhone 15 Pro Max Case” 包含精确型号，纯语义搜索可能召回 “iPhone 14” 或 “Samsung”，导致相关性下降。
  3. 理由 3：运维复杂度
    • 依据：维护有状态的数据库集群（节点故障、数据重平衡）是工程师的主要痛点。
    • 价值判断：无状态架构更符合现代 DevOps 和 Serverless 的最佳实践。

反例或边界条件

  1. 反例 1：极低延迟需求
    • 如果应用要求端到端延迟 < 100ms，从 S3 热加载索引可能存在不可控的抖动，此时内存数据库（如 Redis）或本地 SSD 阵列表现更好。
  2. 反例 2：极高实时写入需求
    • 对于高频交易或实时日志流，S3 的“最终一致性”和 PUT 延迟可能成为瓶颈，传统 LSM-Tree 结构的数据库写入性能更强。

命题性质分类

  • 事实：S3 存储成本低于 EBS/GPD；HNSW 需要大量内存。
  • 价值判断：运维简单性比毫秒级的性能极限更重要。
  • 可检验预测：未来 3 年内，大多数

最佳实践

最佳实践指南

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

说明: 单纯依赖向量检索往往无法满足所有查询需求，特别是面对精确匹配（如产品ID、专有名词）或模糊语义搜索时。最佳实践是将关键词检索（BM25）与向量检索相结合，利用倒数排名融合（RRF）算法对结果进行合并和重排序，以兼顾语义相关性与精确匹配。

实施步骤:

  1. 在数据入库阶段，同时生成向量嵌入和用于关键词索引的元数据。
  2. 在查询阶段，并行执行向量搜索和关键词搜索。
  3. 应用 RRF 算法或加权打分策略，合并两个候选列表并生成最终排序。

注意事项: 需要调整混合检索的权重参数（例如偏向关键词还是偏向向量），这通常取决于具体的数据集和用户查询模式。

实践 2：优化数据库设计以支持高效过滤

说明: 在 RAG 系统中，元数据过滤与向量检索的结合至关重要。数据库设计应确保在进行相似度搜索之前，能通过元数据（如时间、类别、标签）快速缩小搜索范围。这要求存储后端不仅要有向量索引，还要有支持高性能过滤的二级索引或列式存储能力。

实施步骤:

  1. 识别需要频繁过滤的元数据字段（如文档日期、作者、部门）。
  2. 选择支持预过滤或后过滤的高性能向量数据库（如支持 HNSW 索引且具备强大过滤能力的数据库）。
  3. 确保查询计划先执行过滤操作，再在较小的子集上执行昂贵的向量计算。

注意事项: 避免“先全局搜索再过滤”的低效模式，这会极大地增加延迟和计算成本。确保索引策略与查询模式相匹配。

实践 3：利用智能体动态规划检索路径

说明: 并非所有用户问题都需要相同的检索流程。引入 Agent 架构，让 LLM 根据用户问题的复杂程度，动态决定是执行简单的向量搜索、多跳搜索还是需要调用外部工具。Agent 可以将复杂问题分解为多个子任务，并按顺序或并行执行检索。

实施步骤:

  1. 定义一套工具集，包括向量搜索、SQL 查询、API 调用等。
  2. 设计一个 Router 或 Planner 机制，由 LLM 判断当前问题需要调用哪些工具。
  3. 构建反馈循环，使 Agent 能根据检索结果的质量决定是否需要重新检索或调整策略。

注意事项: Agent 系统会增加延迟和 Token 消耗。需要在复杂问题的处理质量与响应速度之间找到平衡点，并设置超时机制。

实践 4：实施重排序以提升最终结果质量

说明: 初次检索（无论是向量还是关键词）返回的 Top K 结果可能并不完全精准。最佳实践是在检索阶段召回较多的候选文档（例如 Top 50），然后使用专门的重排序模型对这批文档进行精细打分，最后将最相关的 Top N 传递给 LLM 生成答案。

实施步骤:

  1. 选择一个高性能的 Cross-encoder 重排序模型。
  2. 在检索阶段设置较高的召回数量（如 20-50 个文档）。
  3. 将查询与召回的文档配对输入重排序模型，根据新分数重新排序，截取最终的 Top 5-10。

注意事项: 重排序会增加额外的推理延迟。建议在异步场景或对准确性要求极高的场景中优先使用，对于实时性要求极高的场景需评估延迟影响。

实践 5：构建面向检索的数据分块策略

说明: 数据分块直接影响检索的准确性。过大的块会导致语义模糊，过小的块则会丢失上下文。最佳实践是根据内容类型采用动态分块，或者建立“父子索引”机制——检索小的语义块，但将包含该小块的大块上下文提供给 LLM。

实施步骤:

  1. 分析文档结构，按语义段落或章节进行切分，而非固定字符数。
  2. 为每个块保留足够的上下文信息（如标题、摘要）。
  3. 实施父子索引检索：搜索时匹配子块，返回时关联父块内容。

注意事项: 确保切分后的块在向量化时包含足够的语义信息，避免切分点位于句子中间导致语义断裂。

实践 6：建立检索评估与反馈闭环

说明: RAG 系统上线不是终点，而是优化的起点。必须建立一套评估体系，利用“黄金数据集”或 LLM-as-a-Judge 的方式，持续监控检索系统的召回率和准确率。根据评估结果反向调整嵌入模型、分块策略和检索参数。

实施步骤:

  1. 构建包含典型问题和标准答案的评估数据集。
  2. 实施自动化测试脚本，定期运行 RAG 流程并计算相似度指标（如 NDCG, MRR）。
  3. 记录用户点击反馈（如用户是否采纳了生成的答案），用于微调检索权重。

注意事项: 不要仅依赖单一指标。结合端

学习要点

  • 在 RAG 系统中，混合检索（结合关键词与向量搜索）通常优于单纯的向量搜索，因为它能同时匹配精确术语和语义概念。
  • 嵌入模型的选择至关重要，使用 Matryoshka 嵌入等新技术可以显著降低向量维数，从而在保持性能的同时减少存储和计算成本。
  • 数据库设计是 RAG 性能的基础，通过优化块大小和索引策略，可以大幅提升检索准确性和响应速度。
  • 将检索逻辑与应用程序代码解耦，使用独立的向量数据库（如 Turbopuffer）而非依赖传统数据库的向量扩展，能提供更好的可扩展性和性能。
  • 智能体（Agents）通过自主规划和多步推理，能够处理比简单的 RAG 管道更复杂的查询任务，代表了检索系统的演进方向。
  • 上下文窗口的扩大并不能替代高质量的检索，精准的检索对于减少幻觉和降低推理成本依然不可或缺。
  • 知识图谱与向量检索的结合（GraphRAG）是未来的重要趋势，能够更好地处理实体间复杂的关系和结构化信息。

引用

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

站内链接

相关文章