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

基本信息

摘要/简介

Turbopuffer 源于一个阅读应用。

导语

RAG 技术的落地往往止步于初步的向量检索，而生产环境的复杂性要求我们思考更深远的问题。Turbopuffer 联合创始人 Simon Hørup Eskildsen 将结合实战经验，探讨混合检索、智能体与数据库设计的协同演进。本文将剖析检索阶段的深层挑战，帮助开发者优化架构设计，从而在复杂场景下提升系统的准确性与可靠性。

摘要

这篇文章主要记录了 Turbopuffer 联合创始人 Simon Hørup Eskildsen 关于“RAG 之后的检索”的见解，涵盖了混合搜索、Agents（智能体）以及数据库设计的最新趋势。

以下是内容总结：

1. 混合搜索是目前的最佳实践 单纯依赖向量搜索（语义理解）或关键词搜索（精确匹配）都有局限性。目前业界公认的最佳方案是混合搜索，即结合两者的优势。虽然传统的 BM25 与向量的加权融合很常见，但 Simon 提出了更具现代感的方案——利用学习排序模型来融合结果，这能比简单的线性加权获得更精准的排序。

2. Agents 改变了数据库的使用方式 随着 AI 智能体的兴起，数据库的查询模式正在发生根本性变化。

  • 非结构化查询： 人类写查询通常是极其非结构化的自然语言，这对传统的 SQL 或查询优化器提出了挑战。
  • 高频查询： Agents 可能会对数据库进行成千上万次微小的查询来验证事实或提取细节，这对数据库的并发能力和延迟提出了极高要求。
  • “上下文即新索引”： 传统的数据库索引（B-Tree 等）在处理 AI 的高维向量需求时显得笨重，未来的数据库需要更灵活地适应向量化上下文。

3. 数据库设计的演进：Turbopuffer 的思路 Turbopuffer 最初源于一个阅读应用的需求，旨在解决传统向量数据库的痛点。

  • 解耦存储与计算： 传统的向量数据库（如 Pinecone, Milvus）往往需要复杂的集群维护。Turbopuffer 主张将数据存储在对象存储（如 S3）中，实现存储层的极简和弹性，而计算层则按需启动。
  • 无服务器化： 这种架构使得向量搜索可以像使用静态网站服务一样简单，无需管理复杂的数据库状态，大大降低了运维成本，特别适合初创公司和动态变化的 AI 应用。

总结 RAG 技术正在从单纯的“向量检索”向更精细的“混合检索”和“智能体交互”演进。未来的数据库架构需要适应 AI 的非结构化查询习惯，并向无服务器、存算分离的方向发展，以实现更高的性价比和灵活性。

评论

文章中心观点 当前 RAG（检索增强生成）系统的性能瓶颈已从“模型能力”转移至“数据检索质量”，解决之道不在于盲目增加模型参数，而在于通过混合检索（稀疏+密集）与高效的数据库架构（如针对向量检索优化的存储引擎）来提升信号召回率。

支撑理由与边界分析

  1. 向量检索的语义盲区与混合检索的必要性

    • [事实陈述] 文章指出纯向量检索虽然擅长捕捉语义相似性（如“狗”和“犬”），但在处理精确匹配（如特定产品型号、专有名词缩写）时表现不佳。
    • [作者观点] Eskildsen 强调混合检索（Hybrid Search，即结合 BM25 等关键词检索与向量检索）并非过渡方案，而是生产环境的必选项。
    • [你的推断] 这表明行业正在从对“语义搜索”的盲目崇拜回归到“工程实用主义”，承认传统 IR（信息检索）技术的价值。
    • [反例/边界条件] 对于极度依赖长距离语义推理或抽象概念匹配的任务（如法律判例类比），强语义模型可能优于关键词混合；此外，混合检索引入的评分归一化复杂性在超大规模数据下可能成为新的性能瓶颈。

  2. 数据库架构对检索效率的决定性影响

    • [事实陈述] Turbopuffer 作为一个从阅读应用衍生出的数据库产品，其核心论点在于通用的向量数据库（如 Post文章中心观点 当前 RAG（检索增强生成）系统的性能瓶颈已从“模型生成能力”转移至“数据检索质量”，解决之道不在于盲目增加模型参数，而在于回归信息检索本质，通过混合检索（Hybrid Search）与去中心化的数据库架构来提升信号召回率。

支撑理由与边界分析

  1. 向量检索的语义盲区与混合检索的必要性

    • [事实陈述] 文章指出纯向量检索虽然擅长捕捉语义相似性（如“狗”和“犬”），但在处理精确匹配（如特定产品型号、专有名词缩写）时表现不佳。
    • [作者观点] Eskildsen 强调混合检索（Hybrid Search，即结合 BM25 等关键词检索与向量检索）并非过渡方案，而是生产环境的必选项。
    • [你的推断] 这表明行业正在从对“语义搜索”的盲目崇拜回归到“工程实用主义”，承认传统 IR（信息检索）技术的价值。
    • [反例/边界条件] 对于极度依赖长距离语义推理或抽象概念匹配的任务（如法律判例类比），强语义模型可能优于关键词混合；此外，混合检索引入的评分归一化复杂性在超大规模数据下可能成为新的性能瓶颈。

  2. 数据库架构对检索效率的决定性影响

    • [事实陈述] Turbopuffer 作为一个从阅读应用衍生出的数据库产品，其核心论点在于通用的向量数据库（如 Postgres + pgvector）在处理大规模向量检索时存在性能瓶颈。
    • [作者观点] 作者主张通过专门优化的存储格式（如分离存储与计算、利用对象存储）来降低检索延迟，而非依赖传统的单机数据库架构。
    • [你的推断] 这是对当前“把所有数据塞进向量数据库”这一行业惯用做法的批判，指出了基础设施层面的“木桶效应”。
    • [反例/边界条件] 对于中小企业或数据量级在百万级以下的场景，传统数据库（如 PostgreSQL）的维护成本远低于引入新的专用架构，专用架构的边际收益在此类场景下并不明显。

  3. Agent 时代的检索复杂性

    • [事实陈述] 文章提到了 Agent（智能体）场景下的检索需求，指出 Agent 的行为具有不可预测性，对检索系统的灵活性要求更高。
    • [作者观点] 数据库设计需要适应 Agent 的多轮对话和工具调用特性，而非仅仅是简单的问答对检索。
    • [你的推断] 未来的 RAG 系统将不再是线性的“检索-生成”管道，而是动态的“检索-验证-修正”循环，这对数据库的写入吞吐量和实时性提出了挑战。
    • [反例/边界条件] 如果 Agent 的任务流程高度结构化（例如基于严格的 Workflow 编排），那么简单的参数化查询可能比复杂的向量检索更有效。

维度评价

  1. 内容深度 文章没有停留在 LLM 应用层的表面探讨，而是深入到了数据存储与索引的底层逻辑。Eskildsen 作为基础设施构建者，其观点切中了当前 RAG 系统中“重模型、轻检索”的痛点。论证较为严谨，特别是关于向量检索在精确匹配上的缺陷分析，符合信息检索的科学原理。但文章在具体的算法实现细节（如 HNSW 参数调优对混合检索的具体影响）上略显保留，更多是产品导向的叙述。

  2. 实用价值 极高。对于正在构建 RAG 应用的工程师而言，文章明确指出了“不要只依赖向量检索”这一避坑指南。混合检索是目前提升 RAG 准确率最直接的手段。此外，关于数据库选型的讨论也为技术决策者提供了除主流向量数据库之外的另一种思路（利用云原生对象存储构建向量库）。

  3. 创新性 文章的观点在学术上并非全新（混合搜索是 IR 领域

技术分析

技术分析

1. 核心观点深度解读

主要观点

文章的核心观点在于**“检索质量决定了 RAG 系统的上限，而通用向量数据库并非检索的终极形态”**。Simon 认为，当前业界过分迷信“向量检索”和“通用 Agent”，而忽视了检索的基础——即数据本身的存储结构和索引效率。

核心思想

作者传达的核心思想是**“回归数据本质”**。

  1. RAG 的瓶颈在 R（Retrieval）： 生成模型（LLM）的能力已经很强，但检索系统往往无法给模型提供精准的上下文，导致幻觉或答非所问。
  2. 混合搜索是妥协而非最优解： 现在的“向量+关键词”混合搜索是因为向量无法完美处理精确匹配（如 SKU 号、专有名词）而做出的妥协。真正的解决方案应从数据存储层入手，而非在应用层打补丁。
  3. 数据库架构决定性能： 传统的数据库架构（如基于磁盘的 HNSW）在云环境下存在延迟瓶颈，Turbopuffer 提出的基于分离式存储和无服务器架构的设计，是为了实现极致的检索速度和并发能力。

观点的创新性与深度

  • 创新性： 提出了“向量检索即表扫描”的理念。不同于传统数据库维护复杂的索引图，Turbopuffer 尝试利用现代 SSD 的高吞吐量和 SIMD 指令，通过暴力扫描或更轻量的索引结构来实现低延迟，从而简化架构并提高一致性。
  • 深度： 跳出了“算法模型”的视角，从“系统架构”的视角重新审视 RAG。指出了向量数据库在处理高基数过滤和实时更新时的结构性缺陷。

为什么这个观点重要

随着 RAG 从实验走向生产，开发者发现“能跑通”和“好用”之间隔着巨大的鸿沟。检索延迟、成本高昂以及混合搜索的复杂性是目前落地的最大痛点。Simon 的观点为构建高性能、低成本的 RAG 系统提供了新的工程路径。

2. 关键技术要点

涉及的关键技术

  • HNSW (Hierarchical Navigable Small World) 与其替代方案： 传统向量数据库的核心，但在更新和删除时存在性能瓶颈。
  • SIMD (Single Instruction, Multiple Data)： 利用 CPU 硬件指令集并行计算向量距离，是提升“暴力扫描”性能的关键。
  • Columnar Storage / Separated Storage： 将计算与存储分离，利用对象存储（如 S3）作为不可变数据源，实现无状态服务。
  • Quantization (量化)： 将浮点向量转化为整数（如 1-bit, 8-bit），以减少内存占用并加速计算。

技术原理与实现方式

  • 混合搜索的融合： 在传统的 RAG 流程中，通常需要分别跑向量检索和关键词检索（BM25），然后在应用层进行 RRF（Reciprocal Rank Fusion）重排序。Simon 提倡的架构是在数据库层面原生支持这种混合，利用倒排索引与向量索引的共享存储，减少网络往返。
  • 过滤下推： 在进行语义搜索前，先利用元数据过滤掉大量无关数据。Turbopuffer 强调在执行向量计算前完成过滤，这与许多传统向量数据库的“先搜后滤”逻辑不同，能显著提升多租户场景下的性能。

技术难点与解决方案

  • 难点： 实时索引更新。HNSW 图很难动态更新。
  • 方案： 采用 Append-only（仅追加）的日志结构或不可变块，每次更新生成新的数据段，后台合并旧数据。
  • 难点： 精确匹配与语义搜索的权重平衡。
  • 方案： 不在应用层加权，而是在打分阶段通过数学公式（如结合 BM25 分数与余弦相似度）统一计算。

技术创新点分析

Turbopuffer 最大的创新在于去中心化的无服务器架构。它不维护主节点，不依赖复杂的分布式一致性协议（如 Raft），而是将数据完全放在 S3 上，计算节点无状态伸缩。这解决了向量数据库“运维复杂”和“写入瓶颈”的问题。

3. 实际应用价值

对 RAG 开发的启示

对于正在构建 RAG 应用的开发者，这一分析指出了优化方向：不要盲目堆砌模型参数，而应关注检索系统的吞吐量和延迟。通过采用无服务器向量数据库，可以显著降低基础设施的运维负担，使开发者能专注于业务逻辑的优化。

对 Agent 架构的影响

在 Agent（智能体）架构中，工具调用的频率和准确性至关重要。高效的混合检索能力意味着 Agent 能更准确地调用外部知识库，减少“幻觉”现象。Turbopuffer 的架构表明，通过优化数据层的存储格式，可以提升 Agent 决策的实时性和准确性。

对数据库选型的建议

企业在进行数据库选型时，应考虑未来的扩展性和云原生特性。传统的单机向量数据库可能难以应对海量数据的实时更新需求。基于云对象存储的分离式架构（如 Turbopuffer）提供了更好的弹性和成本效益，特别适合多租户 SaaS 应用和大规模数据处理场景。

产业意义

Turbopuffer 的技术实践挑战了现有的向量数据库市场格局，证明了在特定场景下，简化的架构配合现代硬件（CPU SIMD、NVMe SSD）可以击败复杂的索引算法。这推动了行业向更轻量、更高效的方向发展。

最佳实践

最佳实践指南

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

说明: 单纯的向量搜索在处理特定关键词或精确匹配时往往表现不佳。混合搜索结合了向量搜索（基于语义理解）和关键词搜索（基于精确词汇匹配，如 BM25）的优势。通过结合这两种方法，可以在保持语义理解能力的同时，提高对专有名词、缩写和特定术语的召回率，弥补单一检索方式的缺陷。

实施步骤:

  1. 在数据入库阶段，同时生成向量 Embedding 和建立倒排索引。
  2. 在查询阶段，并行执行向量搜索和关键词搜索。
  3. 使用倒数排名融合（RRF）或加权分数融合算法合并两个结果集。
  4. 调整融合参数（如 RRF 中的 K 值或权重比例），以优化特定业务场景的相关性。

注意事项: 需要监控两种检索方式的召回情况，避免某一种方法完全主导结果，导致多样性降低。

实践 2：优化数据库设计与索引策略

说明: RAG 系统的性能瓶颈往往在于数据库的检索延迟而非 LLM 的生成速度。传统的数据库设计可能无法满足高频向量检索的需求。最佳实践包括使用专门优化的向量数据库或支持高效向量索引的扩展（如 pgvector），并根据查询模式调整索引参数（如 List 的数量），以在召回精度和查询速度之间取得平衡。

实施步骤:

  1. 评估数据规模和查询延迟要求，选择合适的向量存储方案（如专用向量库或向量扩展）。
  2. 根据硬件资源（内存大小）调整索引参数（例如 HNSW 索引的 m 或 ef_construction）。
  3. 实施元数据过滤，确保在向量计算前尽可能通过结构化字段缩小搜索范围。
  4. 定期对索引进行 vacuum 或分析，以保持查询性能。

注意事项: 避免盲目追求高精度的索引设置，这会显著增加内存消耗和索引构建时间；应根据实际测试结果进行权衡。

实践 3：利用 Agent 机制进行多步推理与验证

说明: 简单的“检索-阅读”流程在处理复杂问题时容易产生幻觉或遗漏信息。引入 Agent 机制，可以让模型自主判断是否需要检索、检索什么内容以及是否需要重新检索。Agent 能够拆解复杂问题，通过多轮对话和工具调用（如搜索不同数据源）来验证信息的准确性，从而显著提升 RAG 系统的可靠性。

实施步骤:

  1. 设计 Agent 的工具集，包括不同的检索接口（如向量库、API、搜索引擎）。
  2. 定义明确的 Prompt 策略，指导 Agent 何时停止检索并生成最终答案。
  3. 实施“自我修正”循环，让 Agent 检查生成的答案是否被检索到的上下文支持。
  4. 记录 Agent 的推理轨迹，以便调试和优化决策逻辑。

注意事项: Agent 模式会增加 Token 消耗和端到端延迟，需要设置严格的超时和最大迭代次数限制。

实践 4：重排序检索结果

说明: 初始检索（如 Top-K）往往是为了召回尽可能多的相关文档，但这其中可能包含许多噪音。引入重排序模型，在初始检索结果的基础上进行精细化的相关性打分，可以剔除不相关的内容，确保送入 LLM 上下文窗口的信息质量更高，从而直接提升最终答案的准确度。

实施步骤:

  1. 在第一轮检索中返回较大的文档集合（例如 Top 50 或 Top 100）。
  2. 将查询和检索到的文档对输入到专门的重排序模型（如 Cross-Encoder）中。
  3. 根据重排序分数重新排列文档，并截取 Top-N 个文档。
  4. 将经过筛选的高质量文档传递给 LLM 进行生成。

注意事项: 重排序会增加计算开销和延迟，建议仅在初始检索结果相关性不稳定时使用，并考虑使用较小的重排序模型以加快速度。

实践 5：精细化的分块与上下文构建

说明: 数据库中的文档切分方式直接影响检索效果。过大的块会导致包含过多噪音信息，过小的块则可能丢失语义上下文。最佳实践是根据内容类型（如代码、Markdown、纯文本）采用动态分块策略，并利用“父子索引”技术，即检索小子块但返回大父块，以兼顾检索的精准度和上下文的完整性。

实施步骤:

  1. 分析数据集特征，为不同类型的文档定义不同的分块逻辑（例如按段落、代码函数或语义边界分割）。
  2. 实施滑动窗口技术，确保块与块之间有重叠，保留关键信息的连续性。
  3. 考虑为每个块添加摘要或元数据描述，以辅助检索匹配。
  4. 在检索时，利用元数据过滤或摘要匹配来定位最相关的上下文范围。

注意事项: 分块大小没有通用标准，必须通过 A/B 测试结合具体的 LLM 上下文窗口大小来确定最佳切分粒度。

实践 6：建立

学习要点

  • 基于 Simon Hørup Eskildsen (Turbopuffer) 关于 RAG 检优化的分享，以下是总结出的关键要点：
  • 混合检索是 RAG 的最佳实践**：单纯依赖向量检索会导致语义理解偏差，必须结合关键词检索（BM25）以弥补精确匹配能力的不足，从而兼顾语义理解与事实准确性。
  • 关键词检索的权重往往需要更高**：在混合检索中，开发者常犯的错误是过度依赖向量，实际上为了减少幻觉和确保事实准确，关键词检索的权重通常应设置得比向量检索更高。
  • 重排序是提升效果的关键环节**：在初步检索（召回）之后使用专门的交叉编码器模型进行重排序，能显著优化最终结果的相关性，是性价比极高的优化手段。
  • 数据库设计应优先考虑“行”而非“列”**：在构建 RAG 向量数据库时，应将每个文本块视为独立的行进行存储和索引，这种扁平化设计更利于检索效率与扩展性，而非受限于传统表格思维。
  • Agent 智能体本质上是复杂的检索工具**：Agent 的核心价值在于通过多步推理来决定检索什么内容，而非仅仅生成文本，其表现上限取决于底层数据库的检索质量。
  • 向量数据库的扩展性面临挑战**：随着数据量的增长，向量检索的性能会显著下降，因此数据库架构设计必须优先考虑水平扩展能力，而非仅仅关注单节点的性能。

引用

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

站内链接

相关文章