RAG技术在实际应用中，常被当作一个“黑盒”来使用——将文档输入其中，期望它能自动输出精准的答案。然而，实际效果往往与预期存在差距。

本文将深入剖析RAG的核心链路，从文档分块、索引增强、编码、混合检索到重排序，逐一揭示每个环节可能成为瓶颈的原因。只有对这些关键节点有更清晰的认知，才能更高效地诊断问题、定位优化方向。

核心要点包括：

1. RAG技术常见的实践误区与优化策略
2. 文档分块、索引增强等关键环节的技术深度解析
3. 召回率与精确率的平衡策略及实用建议

希望这些内容能为正在实践RAG技术的开发者提供有价值的参考。

重新认识RAG

RAG的核心功能非常明确：针对用户的Query，补充与Query相关但模型自身未能包含的信息。同时，它需要在两个关键维度上满足要求：召回率（确保能召回最相关的信息）和精确率（过滤掉无关信息）。

换句话说，RAG技术及其相关实践设计，主要目标就是围绕这两个维度进行优化。但在实际应用中，两者之间存在一个权衡——找到相对合适的平衡点即可，追求两者都达到极高水平，代价过高且不现实。

RAG是Retrieval Augmented Generation三个词的缩写，分别对应三个核心行为：检索（Retrieve）、增强（Augment）以及生成（Generate）。此外，还有一个重要的环节——编码（Embedding），具体流程如下图所示：

Fig2.RAG链路图-细粒度版

接下来，我们将针对实践中可能影响RAG效果的关键技术点，进行详细阐述。

文档分块——Chunking

兵马未动，粮草先行。想要获得高质量的检索结果，首先需要从知识文档的优化开始。实践中，大家通常很重视知识文档的内容沉淀，但在文档结构组织、段落划分，以及知识点的内聚性和正交性上，关注度往往不够。

我们来看一下一份文档在语义Chunking下的处理过程。以一篇论文为例，进行Chunking时，设置了min_split_tokens（最小Chunk的Token数）和max_split_tokens（最大Chunk的Token数），完成后会输出统计结果。

输出的统计信息中，有几个关键指标值得关注：

• 整体Documents（可简单理解为句子数）：474
• 切分出的Chunk数量：46，其中41个Chunk基于相似度阈值（按语义正常划分），4个因达到500 Tokens而被切分，最后1个Chunk是文章末尾部分
• 最大Chunk的Token数：495，最小Chunk的Token数：54，最后一个Chunk可能出现小于min_split_tokens的情况
• Similarity Chunk Ratio：89%的Chunk是按语义切分出来的（41/46）

这个比例能较好地反映当前外部文档的Chunking质量。试想，如果大部分Chunk都是因max_split_tokens限制而被切分的，后续语义检索的效果就会大打折扣。实践中，需要根据文档的实际情况，调整Split的Token大小，在Chunk的数量和相关性比例之间找到平衡。

除了Chunk的大小，还有两个参数需要关注：

• Threshold：相似度的下限，值越大，Chunk内的相关性越好
• Window Size：计算时使用的Document数量大小，默认值为5。值设得越大，上下文切分的相关性越好，但计算量和耗时也会增加，Chunk的体积也会相对更大

此外，论文《Meta-Chunking: Learning Text Segmentation and Semantic Completion via Logical Perception》提供了基于逻辑和语义的Chunking方法，值得参考。同时，还有面向多模态的Modality-Specific Chunking（针对不同内容类型采用不同策略）和Agentic Chunking（让能力强的LLM阅读全文后给出切分策略）。这些方法都可以纳入工具箱，但需要结合自身场景、知识现状和成本进行权衡选择。

索引增强——Indexing

索引增强方面，主要介绍两种类型：语义增强和反向HyDE。

语义增强

语义增强的做法是：将Chunk及其所在的文档内容（比如整篇论文）一起传给LLM，让LLM结合整个文档对这段Chunk进行概述，然后将这个概述信息附加到Chunk内容中，从而增强后续语义检索的精确性。

需要注意的是，这里需要选择能力较强的LLM，最好能支持Prompt Cache功能，这样可以大幅降低模型调用成本。另一种做法是增加前后两个Chunk的内容，对于整体文档较长、前后文本关联度较大的场景，会有一定的增强效果。

反向HyDE

HyDE（Hypothetical Document Embeddings）原本是正向Query检索增强的一种方式，即针对用户Query生成一些假设答案或进行Query扩写，然后通过这些中间内容去检索召回。反向HyDE则正好相反：针对Chunk（可视为Answer）生成该Chunk可能对应的Question，然后针对这些Question构建索引，关联到具体的Chunk内容。

反向HyDE的优势在于可以离线处理，不会影响实时调用的响应时间。它特别适合问答型知识场景，比如有明确问题和答案的答疑内容，也可以作为后续Hybrid Search中关键词扩写的一部分，提升混合检索的整体效果。

编码——Embedding

Embedding 环节大家应该比较熟悉了。核心过程包括：将文本切分为Token，每个Token在词汇表中对应一个ID，每个Token ID都会对应一个同等维度的向量（不同模型维度不同）。

影响编码效果的因素主要有以下几点：

• 编码模型的语言问题：不同语言有不同的分词方式和词汇表。例如，某些英文编码模型在处理中文时效果较差（会出现大量不可识别的Token）。中文场景需要选用相应的中文Embedding模型。但并非所有语言都有对应的编码模型，语种较多，部分语种语料较少，不足以训练出合适的模型。
• 词汇表大小：词汇表小会导致一些词无法表示，只能使用兜底Token ID代替，影响后续处理效果。词汇表大能精准标识文本输入，但也会增加编码后的Token大小。主流模型的词汇表大小通常在5万以上，有些甚至超过10万。
• 语义空间：不同的编码模型有自己的词汇表和向量语义空间。空间效果取决于模型训练所用的数据集。目前用于文本编码的模型，基本都基于通用语义空间，偏日常、大众化的关联。如果需要在特定领域下拥有特殊的语义空间，就需要寻找使用该领域数据训练的Embedding模型，或者自己进行微调（SFT）。

顺便提一下图知识处理的问题：当图片作为知识源时，处理过程可能涉及OCR提取或LLM对图片的理解描述。但中间环节的干扰会很大——提取的文本是否符合预期，描述的维度是否准确，都需要仔细把控，否则后续检索召回的效果会大打折扣。

检索——Hybrid Search

Hybrid Search（混合搜索），本质上是结合了Term-based（基于关键词）和Semantic-based（基于语义）两种模式的检索特性。它融合了两种算法来提升检索的准确性和相关性，具体包括：

• Sparse Vector（稀疏向量）相似度计算：基于关键词匹配，核心是BM25算法
• Dense Vector（稠密向量）相似度计算：基于语义匹配，核心是基于Transformer的Embedding模型

最后，对两种方式找出的Chunk进行综合筛选。常用的方法是：先分别对Sparse和Dense计算出的Top N结果的分值进行归一化，然后针对同一个Chunk，按照一定权重（例如Sparse 0.2，Dense 0.8）计算最终分值，并返回Top N个Chunk。

如果当前场景需要兼顾关键词匹配和语义理解，混合搜索是一个值得考虑的选项。相比纯关键词匹配，它能降低查询编写的规范性要求，提升查询的容错性（即使有拼写错误或不恰当的表述，也能获得不错的效果）；相比纯语义检索，它能增强对领域专有信息的精准匹配能力。

重排——Re-Ranking

检索在速度和覆盖面上具有明显优势，可以在海量知识中快速找到与用户Query相关的内容块。但这些返回的Docs，实际上可能有一部分与用户Query的关联度并不高。此时，就需要通过Re-Ranking进行一轮精排，最终筛选出最相关的Top K个结果作为上下文补充。

在RAG链路中，Re-Ranking常用的技术是Cross-Encoder（交叉编码器），本质上是一个基于BERT的Encoder-only Transformer架构。它会计算Query和每一个Doc的相关性，返回0到1之间的分数（1代表最相关）。最后根据得分排序，选取Top K个结果补充到Context中，再调用LLM得到最终输出。

结语

AI应用开发的实践正在如火如荼地展开。现阶段，可能是对已有的基建平台、开发编排工具、现成的横向基础产品进行整合使用，并结合使用场景进行链路设计。但随着时间推移，还是需要逐步深入细节，向更深的领域探索。

本文探讨的RAG只是AI架构中的一部分，其他相关技术，在对待方式上也大体相似。都需要经历快速上手、技术细节了解、产品实现掌握、应用中的设计迭代、面向效果的循环优化这一路径。快速上手确实有捷径，得益于现在越来越完善的基础设施，成本很低；但深入追求效果，切实提升效率或体验，就需要更深入的探索。希望这些内容能对大家有所帮助。