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

基本信息

摘要/简介

Turbopuffer came out of a reading app.

导语

检索增强生成（RAG）虽然有效，但单纯的向量检索往往难以应对复杂查询。Turbopuffer 联合创始人 Simon Hørup Eskildsen 将探讨 RAG 之后的进阶路径，重点分析混合搜索、智能代理以及数据库设计如何协同工作，以提升信息获取的精准度。本文将深入解析这些技术背后的权衡与实现细节，帮助开发者在构建下一代应用时优化数据架构。

摘要

以下是关于 Simon Hørup Eskildsen（Turbopuffer）演讲内容的总结：

该演讲主要围绕RAG（检索增强生成）系统中的“后检索”阶段展开，深入探讨了如何通过混合搜索、智能代理以及优化的数据库设计来提升检索质量和系统性能。

核心观点： 在构建 RAG 系统时，仅仅依赖单一的检索方式往往不足以应对复杂的查询需求。演讲者主张在检索后引入更精细的处理机制，以确保返回给大模型的信息既准确又具备上下文相关性。

主要内容：

  1. 混合搜索： 演讲强调了结合关键词搜索（基于词频匹配，擅长精确匹配实体）与向量搜索（基于语义相似度，擅长理解意图）的重要性。通过混合这两种方法，可以互补短板，解决单一向量检索在处理专有名词或精确短语时的不足。

  2. 智能代理： 传统的检索往往是静态的，而引入 Agent 可以使检索过程变得动态。Agent 能够根据用户的查询意图，自主决定调用何种工具、执行多次检索或重新规划检索策略，从而在复杂的知识库中更灵活地获取答案。

  3. 数据库设计与优化： 为了支持上述的高级检索功能，底层数据库的设计至关重要。演讲讨论了如何通过高效的数据库架构（如 Turbopuffer 的设计理念）来加速向量检索和过滤操作，确保在海量数据下仍能保持低延迟和高吞吐量。

背景补充： 值得一提的是，Turbopuffer 这一项目最初诞生于一个阅读应用的开发过程中，旨在解决实际场景中遇到的高性能检索难题。

总结： 这场演讲揭示了 RAG 技术演进的方向：从简单的“检索-生成”向更智能的“混合检索与代理驱动”模式转变，同时强调了底层存储设施在支撑这一进化中的关键作用。

最佳实践

最佳实践指南

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

说明: 单纯的向量搜索在处理精确匹配（如产品 ID、特定缩写）时往往表现不佳，而关键词搜索（BM25）在语义理解上存在局限。最佳实践是将两者结合，利用向量搜索处理语义相似性，同时利用关键词搜索处理精确词汇匹配，通过倒数排名融合（RRF）等算法合并结果，以提高召回率和准确度。

实施步骤:

  1. 在数据索引阶段，同时生成文档的向量嵌入和用于关键词检索的倒排索引。
  2. 在查询阶段，并行执行向量搜索和关键词搜索。
  3. 使用 RRF 算法或加权评分对两组结果进行重排序和合并。
  4. 根据业务场景调整向量检索与关键词检索的权重比例。

注意事项: 混合检索会增加计算延迟和系统复杂度，需要评估延迟预算，并确保两种检索结果的归一化处理得当，避免某一类结果主导最终排名。

实践 2：优化数据库架构与索引设计

说明: RAG 系统的性能瓶颈往往在于数据库检索速度。传统的通用型数据库可能无法高效处理高维向量检索。最佳实践是根据检索模式选择专用基础设施，例如使用支持 HNSW（分层导航小世界图）算法的向量数据库，或者利用现代列式存储和 SIMD 指令集优化的数据库（如 Turbopuffer），以减少检索延迟。

实施步骤:

  1. 评估数据量级和查询延迟要求，选择合适的向量索引类型（如 HNSW 适用于平衡速度与精度，IVF 适用于海量数据）。
  2. 确保数据库能够利用硬件加速（如 SIMD 指令集）来加速向量距离计算。
  3. 定期对向量索引进行构建和优化，避免索引碎片化导致性能下降。
  4. 监控查询性能指标（如 P95 延迟），根据瓶颈调整索引参数（如 ef_construction）。

注意事项: 索引构建会消耗额外的内存和存储资源。在更新频繁的场景下，需要权衡索引重建的频率与实时性。

实践 3：实施查询重写与多路查询

说明: 用户的原始查询往往表述模糊或信息不足。直接使用原始查询进行检索可能导致结果不理想。最佳实践是在检索前利用 LLM 对查询进行改写、拆解或生成多个相关的子查询，从而从不同角度获取上下文信息，显著提升检索的召回率。

实施步骤:

  1. 在 RAG 流程中插入一个“查询理解”层。
  2. 提示 LLM 将用户复杂的问题拆解为多个独立的子问题。
  3. 对每个子问题或改写后的查询并行执行检索。
  4. 汇总所有检索到的文档片段，去重后送入生成阶段。

注意事项: 多路查询会显著增加后端检索的负载和 Token 消耗。需要设置合理的并行度限制，并对检索回的内容进行严格的去重和相关性过滤。

实践 4：构建代理式工作流

说明: 传统的 RAG 往往是“一次性检索”，即检索一次后直接生成答案。对于复杂问题，最佳实践是引入 Agent 机制，让模型具备“检索-评估-再检索”的能力。Agent 可以根据当前上下文判断信息是否充足，如果不满足则自主规划下一步的检索动作，形成推理循环。

实施步骤:

  1. 定义工具，包括向量搜索、SQL 查询或 Web 搜索接口。
  2. 设计 ReAct（推理+行动）提示词框架，引导 LLM 先思考需要什么信息，再调用工具。
  3. 允许 LLM 根据检索结果的质量决定是继续深入检索还是生成最终答案。
  4. 实现对话历史管理，确保 Agent 能够基于前序步骤进行迭代检索。

注意事项: Agent 模式会导致更高的 Token 成本和更长的端到端延迟。必须对 Agent 的思考过程进行限制，防止陷入无限循环或产生无效的检索动作。

实践 5：细化数据分块与上下文窗口管理

说明: 检索的质量取决于数据分块的质量。过大或过小的分块都会影响检索的相关性和 LLM 的理解能力。最佳实践是根据文档结构（如段落、章节）进行语义分块，并保留每个分块的上下文信息（如父级标题、摘要），以便在检索时能提供更完整的背景。

实施步骤:

  1. 分析文档结构，使用语义断点而非固定字符数进行切分。
  2. 为每个分块添加元数据（如标题、作者、时间戳）。
  3. 实施“父子索引”策略：检索时匹配小的子分块，但返回给 LLM 的是包含该子块的大块上下文。
  4. 在检索结果中包含前后文的重叠部分，确保语义连贯性。

注意事项: 增加上下文窗口大小会直接增加 Prompt 的 Token 消耗并可能引入噪声。需要在上下文丰富度和干扰信息

学习要点

  • RAG 系统的检索性能主要取决于数据库的查询吞吐能力而非单纯的模型推理速度，因此专用的高性能向量数据库是提升系统整体效率的关键。
  • 混合检索（结合关键词 BM25 和语义向量搜索）能显著弥补纯语义检索在处理专有名词或精确匹配时的不足，是提升召回准确性的最佳实践。
  • 采用重排序模型对检索结果进行二次打分和筛选，是在保证检索召回质量的同时降低向量嵌入维度和存储成本的有效手段。
  • 智能体架构通过自主迭代检索和自我反思修正，能够有效解决复杂查询中单次检索信息不足的问题，但需权衡由此带来的延迟与成本。
  • 数据库设计应针对 RAG 工作负载进行优化，例如利用量化技术减少显存占用并提升检索速度，以适应大规模生产环境的需求。
  • 查询理解与转换是检索前的重要步骤，将用户自然语言转化为结构化的数据库查询语言往往比直接进行非结构化向量检索更有效。
  • 随着模型上下文窗口的不断扩大，RAG 的重点正从单纯的“填补知识空白”转向通过精准检索来减少模型幻觉和降低推理成本。

引用

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

站内链接

相关文章