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

基本信息

摘要/简介

Turbopuffer 源于一款阅读应用。

导语

检索增强生成（RAG）已成为现代 AI 应用的核心架构，但在实际落地中，单纯的向量检索往往难以满足复杂场景对准确性的严苛要求。本文基于 Turbopuffer 的工程实践，深入探讨了 RAG 实施后的进阶优化路径，涵盖混合检索、Agent 交互模式以及数据库设计等关键议题。通过阅读，读者可以了解如何通过架构调整与数据层面的精细化管理，有效解决检索召回不足的问题，从而显著提升系统的整体性能。

摘要

这是一份关于 Simon Hørup Eskildsen（来自 Turbopuffer）的演讲《RAG 之后的检索：混合搜索、智能体与数据库设计》的中文总结。

核心主题：超越基础 RAG，优化检索架构

演讲主要围绕如何改进检索增强生成（RAG）系统中的“检索”环节，探讨了从单纯依赖向量搜索向更复杂、高效的混合架构及智能体模式演变的趋势。

1. Turbopuffer 的背景与起源

  • 起源： Turbopuffer 最初诞生于一个阅读应用的开发过程中。
  • 动机： 团队在构建阅读应用时，面临处理大量文本数据并进行高效检索的挑战，现有的向量数据库解决方案在性能或成本上无法满足需求，因此他们决定构建自己的高性能向量搜索基础设施。

2. 混合搜索：不只要向量

  • 局限性： 单纯的向量搜索（语义搜索）虽然擅长理解意图，但在精确匹配关键词（如专有名词、ID）方面表现不佳，且存在“幻觉”风险。
  • 解决方案： 混合搜索 结合了向量搜索（语义理解）和关键词搜索（BM25，精确匹配）。
  • 重排序： 混合搜索的关键在于有效的重排序机制。系统首先通过多种方式检索出大量候选文档，然后使用精细的模型对这些文档进行重新排序，以确保返回给大模型（LLM）的上下文是最相关、最准确的。

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

  • 从被动到主动： 传统的 RAG 是被动的（查询-检索），而智能体代表了未来的方向。
  • 自主检索： 智能体可以根据用户的查询，自主决定检索策略、工具调用以及多轮交互。它们不仅能回答问题，还能规划检索路径，处理更复杂的任务。

4. 数据库设计的演进

  • 挑战： 随着数据量的增长，如何设计数据库以支持低延迟、高并发的检索成为关键。
  • 架构优化： 演讲强调了针对 RAG 负载优化的数据库设计的重要性，包括如何高效存储向量、支持过滤操作以及平衡计算资源，以实现实时的用户体验。

总结

Simon Eskildsen �

评论

中心观点

文章核心观点在于：随着 RAG（检索增强生成）技术从原型走向生产，传统的向量检索已不足以满足精准度和召回率的双重需求，行业必须回归“混合检索”与“数据库底层设计”的本质，通过将稀疏检索（关键词）与稠密检索（向量）的深度结合，配合智能体路由，才能解决检索质量与成本的矛盾。（你的推断）

支撑理由与深度评价

1. 向量检索的“语义幻觉”与精度瓶颈 文章指出，单纯的向量检索擅长捕捉语义相似性，但缺乏对专有名词、ID 和精确匹配的控制力。Eskildsen 强调，在处理用户特定查询时，关键词匹配（BM25）依然是不可替代的基石。

  • 评价（事实陈述/作者观点）： 这是一个非常务实且符合当前技术现状的判断。许多早期的 RAG 实践者盲目追求“全向量化”，导致查询“Apple”时召回“Orange”因为它们在语义空间上接近（都是水果）。文章严谨地指出了 Embedding 模型在处理精确实体时的结构性缺陷。
  • 反例/边界条件： 在高度同义词化的场景（如法律文书或医疗诊断）中，用户可能不知道精确的关键词，此时向量检索的语义泛化能力优于关键词检索。

2. 数据库架构决定检索上限 文章源自 Turbopuffer（一家 PG 向量扩展/数据库公司）的视角，强调了数据库底层的存储格式（如 HNSW 索引的优化、列式存储）对检索性能的制约。Eskildsen 认为，仅仅在应用层做 RAG 是不够的，必须深入到数据库层面优化数据布局。

  • 评价（作者观点/你的推断）： 这是一个典型的“基础设施决定上层建筑”的论点。目前的 RAG 市场过于关注 Prompt Engineering 和 LLM 本身，而忽视了检索层的 I/O 瓶颈。文章指出了“检索延迟”和“吞吐量”是制约 Agentic Application（智能体应用）落地的关键物理限制。
  • 反例/边界条件： 对于 90% 的中小规模应用（数据量 < 100万条），通用的向量数据库（如 Pinecone, Milvus）或 PostgreSQL 插件已足够，过度强调底层定制可能导致“过早优化”。

3. 智能体作为检索的路由器 文章提到了“Agents”在检索中的作用，即利用 LLM 来判断何时使用向量检索，何时使用关键词检索，甚至何时调用工具。

  • 评价（你的推断）： 这将 RAG 从“静态管道”推向了“动态工作流”。Simon 的观点暗示了未来的检索系统不再是单一的数据库查询，而是一个基于意图理解的决策过程。这增加了系统的灵活性，但也引入了新的复杂性。
  • 反例/边界条件： 引入 Agent 进行路由决策会显著增加端到端延迟（LLM 调用耗时），且路由判断本身可能出错，导致检索链路失败。对于实时性要求极高的问答（如客服机器人），简单的混合检索可能比 Agent 路由更稳定。

维度详细评价

1. 内容深度与论证严谨性 文章具有较高的工程深度。它没有停留在“RAG 是什么”的科普层面，而是深入到了“RAG 在生产环境中为何失效”的深水区。Simon 作为数据库从业者，其论证逻辑非常严密：检索质量 = 精确度（关键词） + 语义度（向量） + 数据库性能。他准确地指出了当前向量数据库市场过热后的理性回归趋势。

2. 实用价值与指导意义 对架构师和 RAG 工程师极具指导意义。它明确告诉开发者：不要迷信单一的向量检索，必须在技术栈中重新引入 BM25 或 SPLADE 等稀疏检索技术，并学会利用重排序模型来平衡两者的结果。这是从“Demo 级 RAG”迈向“生产级 RAG”的必经之路。

3. 创新性 虽然“混合检索”并非全新概念，但文章将其置于“Agents”和“Database Design”的语境下进行讨论，提出了**“检索后处理”**的重要性。它暗示了未来的竞争壁垒不在于你用了什么 Embedding 模型，而在于你如何高效地混合、排序和过滤这些检索结果。

4. 行业影响与争议点

  • 行业影响： 该文章是对当前“向量数据库万能论”的一种有力修正，推动行业重新思考 PostgreSQL 等传统数据库在 AI 时代的价值。
  • 争议点： 文章隐含地推销了 Turbopuffer 的技术理念。有观点认为，随着 LLM 上下文窗口的无限扩大，检索可能变得不再那么重要（Long Context 替代 RAG）。此外，对于是否需要专门的数据库来支持混合检索，社区仍有分歧（支持 PG 扩展 vs 专用数据库）。

实际应用建议

  1. 默认采用混合检索策略： 在构建 RAG 系统时，默认应同时部署 Dense Retrieval（Embedding）和 Sparse Retrieval（BM25/关键词）。不要试图用向量检索解决所有问题。
  2. 引入重排序层： 无论检索源是什么，在送入 LLM 之前，使用 Cross-encoder 进行重排序是提升效果性价比最高的手段。
  3. 关注延迟与成本的平衡： 在设计 Agent 工作流时，评估 Agent 路由带来的额外延迟是否在业务可接受范围内

技术分析

技术分析：RAG 之后的检索架构演进

1. 核心技术观点

Simon Hørup Eskildsen 的技术分析直击当前 RAG（检索增强生成）系统的痛点——过度依赖生成模型而忽视检索质量。他认为，业界陷入了一种误区，试图通过增加 Agent（智能体）的复杂度来弥补基础检索能力的不足。Eskildsen 提出的核心论点是：在优化 LLM 之前，必须先回归检索的本质。

他主张**“检索至上”的工程哲学，强调向量检索并非万能。纯向量搜索在处理精确匹配（如产品 ID、特定专有名词）时存在严重缺陷，往往导致“幻觉”或漏检。因此，未来的方向不是构建更复杂的 Agent，而是构建更强大的混合检索系统**。

2. 关键技术解析

混合搜索

这是 Eskildsen 强调的基石技术。它并非简单的功能叠加，而是稠密检索与**稀疏检索（BM25）**的深度结合。

  • 稠密检索：擅长理解语义模糊的查询（如“如何修复损坏的文件”）。
  • 稀疏检索：擅长精确匹配关键词（如“错误代码 0x80040”）。
  • 技术实现：通过倒数排名融合（RRF）或加权打分算法，将两者的结果合并，确保既“懂意思”又“不丢词”。

HNSW 索引优化

作为 Turbopuffer 的创始人，Eskildsen 特别关注**层次化可导航小世界图（HNSW）**在实际工程中的表现。

  • 元数据过滤：技术难点在于如何在保证检索速度的同时进行精准的元数据过滤。Eskildsen 提倡在索引构建阶段优化图结构，避免“先搜后滤”导致的召回率下降。
  • 性能平衡：通过量化技术压缩向量维度，在内存占用和检索精度之间寻找最佳平衡点，以适应无服务器或边缘计算环境。

重排序

虽然检索是基础，但为了进一步提升相关性，技术架构中必须包含重排序环节。即在粗排（混合检索）获得大量候选集后，使用精度更高的 Cross-Encoder 模型进行精细打分。这是在“找全”和“找准”之间做的必要权衡。

3. 架构演进与工程实践

从“重生成”转向“重检索”

传统的 RAG 架构往往将 80% 的算力用于生成，而 Eskildsen 呼吁将重心前移。一个设计精良的检索层可以大幅降低对 LLM 推理能力的要求，从而降低成本和延迟。

数据库设计的回归

技术选型应回归数据库设计的本质。不要被“向量数据库”这一营销术语束缚，而应关注系统是否支持高效的混合查询、ACID 事务以及水平扩展。对于生产环境，传统的 BM25 倒排索引与现代的 HNSW 向量索引缺一不可。

4. 应用场景与价值

电商与搜索

在电商场景中，用户搜索“耐克红鞋”，纯向量搜索可能召回所有红色鞋子，而忽略了“耐克”这一强关键词；混合搜索则能确保品牌匹配的同时兼顾语义。

知识库管理

企业内部文档通常包含大量缩写、型号和特定术语。混合架构能确保在理解用户意图的同时，精确命中文档中的关键实体，避免 AI 瞎编。

总结

Simon Hørup Eskildsen 的分析为当前的 AI 热潮提供了务实的冷思考。RAG 系统的下一步进化，不在于让 Agent 变得更聪明，而在于让底层的检索引擎变得更精准、更高效。混合搜索是通往生产级 RAG 的必经之路。

最佳实践

最佳实践指南

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

说明: 单纯的向量搜索（语义搜索）在处理精确匹配（如专有名词、ID或特定术语）时往往表现不佳，而传统的关键词搜索（BM25）在处理语义理解时存在局限。Simon Eskildsen 强调，将两者结合（混合搜索）是 RAG 系统的基础。通过结合关键词的精确匹配能力和向量嵌入的语义理解能力，可以显著提高检索的相关性和覆盖面，减少因单一算法缺陷导致的检索失败。

实施步骤:

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

注意事项:

  • 需要调整向量搜索与关键词搜索的权重比例，以适应具体的数据分布和业务场景。
  • 确保向量数据库和搜索引擎之间的同步性，避免数据一致性问题。

实践 2：优化数据库设计以支持高并发检索

说明: RAG 系统的性能瓶颈往往在于数据库的检索速度，特别是在高并发场景下。传统的数据库设计可能无法有效处理大规模向量检索的吞吐量需求。最佳实践包括采用专门的向量数据库或优化现有存储架构，以减少延迟并提高并发处理能力，确保用户查询能够快速返回结果。

实施步骤:

  1. 评估并选择支持水平扩展和高性能向量检索的数据库（如 Turbopuffer, Pinecone, pgvector 等）。
  2. 对数据进行分片处理，根据业务逻辑（如用户群体、文档类别）分散存储压力。
  3. 实施适当的缓存策略，将高频查询的结果缓存起来，减少直接击中数据库的次数。
  4. 监控数据库查询性能，定期优化索引配置。

注意事项:

  • 避免过度索引，这会降低写入速度并增加存储成本。
  • 在进行分片设计时，要考虑查询模式，避免跨分片的大量聚合查询。

实践 3：利用 Agent 机制处理复杂查询逻辑

说明: 对于简单的问答，直接的 RAG 流程即可胜任。但对于复杂的、多步骤的推理问题，引入 Agent（代理）机制是必要的。Agent 可以根据查询内容自主决定检索策略、调用工具或进行多次检索迭代。这种动态的检索后处理能够弥补静态检索在逻辑推理上的不足，使系统能够回答更深层的问题。

实施步骤:

  1. 设计能够解析用户意图的 Agent 路由层，判断问题是直接检索还是需要推理。
  2. 为 Agent 配置工具集，包括搜索引擎、数据库查询接口和计算器。
  3. 构建反馈循环，允许 Agent 根据初次检索结果判断是否需要进一步检索或修正查询。
  4. 使用思维链提示引导 Agent 进行逐步推理。

注意事项:

  • Agent 的引入会增加系统的延迟和 Token 消耗，需要设置合理的超时和步数限制。
  • 需要严格限制 Agent 的工具使用权限，确保安全性。

实践 4：实施细粒度的检索与重排序

说明: 初次检索往往是为了召回尽可能多的相关文档（广度），但这会引入噪音。最佳实践是在初次检索后，利用更精确的模型进行重排序。Simon Eskildsen 指出，从大量文档中选出 Top K 个结果后，使用专门的重排序模型进行二次打分，可以显著提升最终生成内容的质量，确保上下文的高度相关性。

实施步骤:

  1. 设定较高的初次召回数量（例如 Top 50 或 Top 100）。
  2. 将检索到的文档片段与用户查询一起输入到高精度的交叉编码器重排序模型中。
  3. 根据重排序模型的得分重新排列文档，选取最终的 Top N（例如 Top 5-10）输入给 LLM。
  4. 评估并选择适合业务语言和领域的重排序模型。

注意事项:

  • 重排序模型会增加推理延迟，需在准确性和速度之间寻找平衡。
  • 确保重排序步骤与提示词工程紧密结合，确保 LLM 能够有效利用排序后的上下文。

实践 5：针对检索内容进行上下文优化与压缩

说明: 检索到的文档块可能包含大量无关信息，直接将其全部塞入 LLM 的上下文窗口会导致“迷失中间”现象或增加 Token 消耗。最佳实践是在将检索结果传递给生成模型之前，对其进行清洗、去重和压缩。这不仅能提高响应速度，还能让模型更专注于关键信息。

实施步骤:

  1. 去除检索结果中的重复内容或高度相似的冗余段落。
  2. 提取文档块中的核心句子或关键词，使用专门的上下文压缩模型进行摘要。
  3. 重新组织被选中的文档块，确保逻辑连贯性。
  4. 在提示词中明确指示 LLM 仅依据提供的优化后上下文生成

学习要点

  • 混合搜索（结合关键词与语义向量）通常优于单纯的向量搜索，能有效弥补语义理解在精确匹配专有名词或特定短语时的不足。
  • RAG 系统的性能瓶颈往往不在生成模型，而在检索质量，因此应优先优化数据索引和检索策略而非盲目升级大模型。
  • 查重与去噪是构建高质量向量数据库的关键，通过剔除重复或低质量文档可显著减少“幻觉”并提高检索准确度。
  • Agent（智能体）架构通过自主规划检索路径和迭代查询，能比静态 RAG 流程更有效地处理复杂、多步骤的推理任务。
  • 数据库设计（如分块策略 Chunking Strategy 和元数据过滤）对检索结果的影响甚至超过嵌入模型的选择。
  • 稀疏向量（如 SPLADE）与稠密向量的结合是提升检索召回率的前沿技术，能同时兼顾语义理解与关键词匹配的精确度。
  • 随着模型能力的发展，未来的 RAG 系统将更侧重于如何让模型自主决定“何时检索”以及“检索什么”，而非固定的检索触发机制。

引用

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

站内链接

相关文章