分块、重排序与混合搜索：让RAG真正发挥作用

大多数RAG实现效果都不好。模型本身没有问题——Claude或GPT-5很乐意根据检索到的文档回答。失败的是检索环节。你提出一个问题，系统返回错误的文本块，模型则根据错误信息生成一份自信的答案。

本文是一份实用指南，介绍修复糟糕检索的三件事：分块策略、重排序和混合搜索。做好这三点，大多数“RAG不适合我们的用例”的抱怨都会消失。

我们略过深奥的技术数学，重点说明实际该怎么做。

检索为什么会失败

默认RAG流水线如下：

1. 将文档拆分成文本块。
2. 对每个文本块进行嵌入。
3. 收到问题时，对问题进行嵌入，并找到最相似的文本块（余弦相似度）。
4. 将这些文本块传给大语言模型（LLM）。

每一步都有相应的失败模式：

分块不当会产生太短而没有用处，或太长而缺乏连贯性的文本块；也可能从一个完整观点中间切开，导致两半都无法被良好检索。

简单粗暴的相似度匹配会找到与查询使用相同词汇、实际却不相关的文本块。查询“如何取消订阅”可能检索到任何提及“订阅”的文本块，包括无关的营销文案。

没有重排序意味着相似度搜索返回什么，大语言模型就会看到什么。最相似的文本块不一定是最相关的文本块。

纯语义搜索会错过重要的精确关键词匹配。查询“错误代码503”时，可能错过包含“错误代码503”原文的文本块，因为查询的语义向量与文本块的整体主题不匹配。

三种修复方式——更好的分块、重排序、混合搜索——分别解决这些问题。

修复1：改进分块

分块是RAG流水线中影响最大的单项决策，也是大多数人直到结果变差才会想到的环节。

多数无代码工具采用的简单默认方案，是按固定token数分块（例如每块500个token，重叠50个token）。这种方式尚可使用，但经常会切错位置。

更好的策略包括：

语义分块

在语义边界——主题发生变化的位置——拆分文档，而不是按任意token数切分。大多数现代框架（LangChain、LlamaIndex）都有语义分块器，可检测主题变化并从相应位置拆分。

好处是：文本块包含完整观点。模型得到的是连贯上下文，而不是半截论述。

结构感知分块

如果文档具有自然结构（Markdown标题、HTML章节、PDF章、代码函数边界），就应加以利用。按章节而非token分块。

对于Markdown：

• 每个H2章节作为一个文本块（前置H1上下文）。
• 较长的H2章节进一步分块，并重复H2标题作为上下文。

对于代码：

• 每个函数或类作为一个文本块。
• 文本块包含文件路径和所有import。

对于任何结构化内容，这都远优于盲目的固定大小分块。

分层分块

这是近期RAG研究中的一种模式。在多个层级创建文本块：

• 用于精确检索的小文本块（200–500个token）。
• 用于上下文的中型文本块（1000–2000个token）。
• 用于高层级匹配的文档摘要（50–100个token）。

检索时匹配小文本块，但返回其所在的中型文本块。这样，大语言模型既能获得精确相关性，又有足够上下文来理解内容。

选择文本块大小

按内容类型划分的粗略经验值：

如果无代码工具隐藏了分块过程，可以进行测试：提出10个你知道答案位于语料库中的问题。如果检索经常找不到正确文本块，问题就在分块。

一种效果良好的模式：“先按页或章节，再以问题为依据”

对于大多数个人RAG用例，以下模式行之有效：

1. 按文档章节（Markdown H2、PDF章等）分块。
2. 对超过约2000个token的文本块，再按段落分块。
3. 在每个文本块前加入文档标题和章节标题作为上下文。
4. 附上一段简短说明，指出该文本块可回答哪些类型的问题（建立索引时由快速的大语言模型自动生成）。

自动生成“此文本块可回答什么问题”的技巧，使用率低得惊人，效果却强得惊人。其原理在于，用户查询经常以问题形式表达，将其与问题形式的元数据匹配，比与原始文档文本匹配更精确。

修复2：重排序

初始检索通常根据向量相似度返回20–50个文本块，随后使用重排序器按与查询的实际相关性重新排列。

重排序器是一个独立模型——通常规模更小且经过专门训练——接收（查询，文本块）对并输出相关性分数。将它应用于前20–50个结果，按新分数排序，再把前3–5个传给大语言模型。

好处是精确率显著提高。向量相似度速度快，但准确性并不突出；重排序器速度较慢，却准确得多。两者结合，既有快速检索，也有准确排序。

2026年可用的重排序器包括：

• Cohere Rerank——成熟的API重排序器。每1,000次搜索$2.00（标价，核实于2026-07-10）。
• Voyage AI rerank-2——强大的商业方案，在细分领域往往优于Cohere。
• bge-reranker-v2-m3——开源，可在本地或廉价托管环境中运行。
• Jina Reranker——另一个强大的开源方案。

典型流水线如下：

1. 向量搜索返回前50个文本块（便宜、快速）。
2. 重排序器根据查询为全部50个文本块评分（成本更高、速度更慢）。
3. 按重排序分数选出前5个，传给大语言模型。

增加的总延迟约为200–500ms。质量提升：在检索准确率基准测试中通常为20–40%。

对于默认不包含重排序的无代码工具（NotebookLM、大多数基础n8n设置），这是影响最大的单项升级。n8n有Cohere Rerank节点；LangChain和LlamaIndex原生包含重排序器集成。

修复3：混合搜索

向量相似度能找到语义匹配；关键词搜索（BM25或类似方法）能找到精确匹配。两者各自都会漏掉另一种方法能找到的内容。

对于查询“如何修复网关上的HTTP 503错误”：

• 向量搜索会找到有关HTTP错误、网关问题和故障排除的文本块。
• 关键词搜索会找到明确提及“503”的文本块——这可能正是答案所在。

混合搜索同时运行两种搜索并合并结果。合并使用一种称为倒数排名融合（RRF）的方法：给定两种方法的排名，RRF会生成兼顾两种信号的综合排名。

在多数工具中，实现很简单：

• 运行向量搜索 → 获得排名列表A。
• 运行BM25 / 关键词搜索 → 获得排名列表B。
• 对每个文本块计算RRF分数 = 1/(k + rank_in_A) + 1/(k + rank_in_B)（k通常为60）。
• 按综合分数排序并返回前几个结果。

2026年，以下工具原生支持混合搜索：

• Weaviate（向量存储）——开箱即用的混合搜索。
• Qdrant——通过筛选实现混合搜索。
• Pinecone——通过稀疏向量实现混合搜索。
• Elastic / OpenSearch——结合关键词和向量。
• 大多数n8n RAG模板——现代模板默认使用混合搜索。

好处是：对于包含特定标识符、代码、名称或术语的查询，召回率显著提高。对于技术内容（代码、错误代码、产品名称、法规引用），混合搜索几乎是必需的。

就你的用例而言：如果查询经常包含应当精确匹配的特定术语（数字、名称、代码、准确短语），请启用混合搜索。成本低，收益大。

将三者结合

2026年最先进的RAG流水线如下：

查询
  ↓
查询重写器（可选——整理查询、展开缩写）
  ↓
混合检索：向量 + 关键词搜索
  ↓
前30–50个结果
  ↓
重排序器
  ↓
按重排序分数选出的前5个结果
  ↓
大语言模型+ 检索到的文本块 + 查询
  ↓
带引用的答案

每一步单独来看都很便宜。结合起来，其检索质量与“向量相似度 → 前5个 → 大语言模型”有本质区别。

还有一些不太常见但能力强大的补充方法：

查询扩展。 将用户查询重写成多个变体，并分别搜索，以捕获不同表述。

多步检索。 对复杂问题执行多次检索。第一次识别子问题，第二次分别获取各子问题的答案。

对话式检索。 在多轮对话中，利用对话历史指导检索（“对方之前问过X，因此对于这个问题，应优先检索与X相关的内容”）。

来源筛选。 使用元数据筛选器限定检索范围。“仅搜索标记为‘EU regulations’且日期晚于2023年的文档。”

无代码RAG工具越来越多地提供这些功能，但在使用高级功能前，务必先确认三个基础环节已经到位（良好的分块、重排序器、混合搜索）。

如何衡量RAG质量

无法衡量，就无法改进。以下是几种实用评估策略：

“黄金问题”测试。 选择20个你知道正确答案的问题，让RAG逐一回答。评分：是否检索到正确文本块？模型是否生成正确答案？每月执行一次。

K处的检索召回率。 对每个黄金问题，确定哪些文本块包含答案。然后检查：检索系统返回的前K个（5、10、20）文本块中是否包含任意一个正确文本块？计算相应比例。

以大语言模型作为评判者的评估。 更高级的版本是让强模型（Claude Opus、GPT-5）评价答案是否正确、引用是否准确、内容是否完整，以及是否有充分依据。对一批具有代表性的问题运行。我们另有一篇专门介绍评估的文章。

用户感知质量。 对于团队或生产环境RAG，为每个答案添加赞成 / 反对按钮。观察反对意见的模式，它们会集中在特定问题类型上——修复这些问题。

最大的错误是完全跳过衡量。“感觉还行”不等于衡量。如果不衡量，就无法知道改进是否有效。

完整示例：改进表现不佳的RAG

假设你为公司内部文档构建了个人RAG，但质量平平——只有约60%的问题能得到实用答案。应按以下顺序改进：

先审查检索。 对十个低质量答案，查看检索到了哪些文本块。是否检索到正确文本块？如果是，问题在模型或提示词；如果不是，问题在检索。

如果问题在检索：

1. 检查分块。 文本块是否连贯？分块器是否从重要观点中间切开？改用语义或结构感知分块。

2. 添加重排序器。 如果使用基础向量搜索和前5个结果，应在检索与大语言模型之间加入Cohere Rerank或bge-reranker-v2-m3。提升通常立竿见影——请在自己的评估集上衡量，而不是相信任何人的通用百分比。

3. 添加混合搜索。 查询包含特定术语（产品名称、错误代码、行业术语）时尤其如此。

4. 检查索引。 文本块是否带有元数据标签（文档类型、章节、日期）？在检索中使用元数据筛选器。

如果问题在模型（检索到正确文本块，却回答错误）：

1. 收紧提示词。 明确告诉模型：“仅根据所提供的上下文回答。如果上下文未涵盖问题，请直接说明。”

2. 添加引用。 要求模型引用所使用的具体文本块。这既有助于调试，也能减少幻觉。

3. 使用更强的模型。 如果正在使用小型快速模型，尝试Claude Sonnet 4.5或GPT-5。

经过两三轮这样的调查和修复，大多数RAG实现都能达到85–90%的实用答案率。这是用户真正开始采用并信任系统的门槛。

常见错误

以下几类问题经常让人踩坑：

索引错误内容。 营销页面、过时文档、低质量博客内容。模型无法区分，索引中的一切都会被视为权威内容。务必严格筛选。

文档变化后忘记更新索引。 内容过时的RAG会自信地给出错误答案。应定期重建索引，或使用自动同步系统。

忽视评估。 大多数RAG上线时没有衡量，之后也从未改进。“感觉还行”的阶段永远不会结束。从第一天起就纳入评估。

将检索视为黑箱。 “就是不能用”并非诊断。打开检索过程，看看返回了什么。几乎每次查看结果后，问题都会变得显而易见。

过早进行过度工程。 无需一开始就采用最先进的流水线。先使用NotebookLM或基础向量搜索，只有在发现具体瓶颈后再增加复杂度。

何时重要

三种修复方式——更好的分块、重排序、混合搜索——在以下情况下最为重要：

• 语料库是技术内容，包含特定术语。
• 查询要求精确匹配（代码、名称、ID）。
• 用户重视精确性（法律、合规、客户支持）。
• 系统大规模使用（每天调用10,000次时，微小的质量提升也意义重大）。

在以下情况下重要性较低：

• 语料库较小（少于100份文档）且组织良好。
• 查询是开放式的（“我们对X有何看法”）。
• 用户容错度高，愿意通过多轮尝试寻找答案。
• 用例侧重探索，而非精确。

对于大多数个人和小团队RAG，从基础向量相似度改为向量 + 重排序器，就是投入产出比最高的升级。下一步是加入混合搜索。分块在任何规模下都很重要。

要点

糟糕的RAG几乎总是源于糟糕的检索，而糟糕的检索几乎总是归结为三件事：分块、重排序和搜索方法。修复这三项，大多数RAG质量问题都会消失。

无需成为搜索工程师也能应用这些方法。Weaviate、Pinecone、Qdrant、n8n模板、LangChain集成等工具已让这些技术触手可及。如今的瓶颈主要在于知道它们存在，并有意识地加以应用。

如果RAG无法正常工作，不要责怪模型。查看返回的文本块，修复检索，然后重新评估。