收藏！RAG技术深度解析：从文档分块到重排序的全面优化指南

EnjoyEDU

568人浏览 · 2025-09-01 10:16:47

EnjoyEDU · 2025-09-01 10:16:47 发布

随着人工智能应用开发的浪潮席卷各行各业，RAG（检索增强生成）已从技术圈的专业术语，逐渐成为企业数字化转型中的 “高频热词”。无论是中小型科技公司的 AI 客服搭建，还是大型企业的知识库升级，RAG 都以其 “低成本补充模型知识” 的特性被广泛应用。但与此同时，关于 RAG 的负面反馈也层出不穷：“用 RAG 做的产品总是答非所问，是不是得先微调大模型？”“公司内部文档用 RAG 检索时，经常调出不相关的内容，精准度太差了”“现有的 RAG 工具根本满足不了复杂场景需求，优化效果微乎其微”……

必须承认，这些声音并非毫无依据，毕竟每个企业的实践场景和数据基础存在差异。但当我们深入与从业者沟通时，会发现一个共性问题：多数人难以清晰回答 “RAG 效果差” 的具体原因。比如 “你认为 RAG 不好用，是某类特定查询出现问题，还是所有场景都受影响？”“能否举例说明，某条用户查询召回了哪些不符合预期的知识内容？”“企业的文档是按部门分类存储，还是按业务流程梳理？在文档分块和结构化处理上做了哪些工作？” 这些关键问题的模糊，往往导致 RAG 优化陷入 “头痛医头” 的困境。

在日常实践中，很多团队习惯将 RAG 视为一个 “黑盒系统”—— 输入端投入企业沉淀的历史文档、产品手册等数据，输出端直接对接 AI 应用的最终回复（如图 1 所示）。这种 “粗放式” 应用模式，确实能让企业在短期内看到效果，比如客服响应速度提升、简单问题自动化解决等。但当业务场景拓展（如从产品咨询延伸到技术故障排查），或对回复准确率要求提高（如金融领域的合规问答）时，“黑盒思维” 的弊端便会凸显：既无法精准定位问题出在检索环节还是生成环节，也难以明确当前链路的核心优化诉求，最终导致后续的技术调整与业务目标严重脱节。

Fig1.RAG 链路图 - 粗粒度版，有缺失

为帮助更多从业者跳出 “黑盒困境”，本文将深入拆解 RAG 的技术链路与关键细节，梳理影响 RAG 效果的核心因素，为企业提供可落地的优化思路 —— 无论是诊断现有系统的问题，还是设计新的 RAG 迭代方案，都能找到明确的技术抓手。

1、重新认知 RAG：不止于 “检索 + 生成”

RAG 的核心价值，在于为大模型的回答提供 “实时、精准、专属” 的知识补充。当用户提出查询时，大模型自身的训练数据可能存在 “知识过时”（如未涵盖 2024 年后的行业政策）或 “领域空白”（如企业内部的专属业务流程）的问题，而 RAG 能通过检索外部知识库，将与查询相关的信息补充给模型，最终生成更贴合实际需求的回复。

要实现这一价值，RAG 需满足两个核心指标：

召回率：能从海量文档中 “全面捕捉” 与查询相关的关键信息，避免因遗漏重要内容导致回复片面；
精确率：在召回相关信息的同时，严格过滤无关内容，防止冗余信息干扰模型判断，导致回复偏离主题。

值得注意的是，召回率与精确率在实际应用中存在 “此消彼长” 的权衡关系。例如，为了不遗漏任何相关信息，扩大检索范围可能会导致精确率下降；而若严格限制检索条件提升精确率，又可能错过部分关键内容。因此，企业需根据业务场景确定 “最优平衡点”—— 比如医疗领域的问诊场景，需优先保证召回率以避免遗漏病情相关信息；而电商客服的订单查询场景，则需优先提升精确率，确保快速定位用户订单详情。

从技术构成来看，RAG 是 Retrieval（检索）、Augmentation（增强）、Generation（生成）三个核心环节的有机结合，同时还需依赖 Embedding（编码）技术实现 “文本向量化”，为高效检索奠定基础（如图 2 所示）。这四个环节环环相扣，任何一个环节的技术选择或参数设置，都会直接影响 RAG 的整体效果。

Fig2.RAG 链路图 - 细粒度版

接下来，本文将针对图 2 中标注的关键技术节点，结合实际案例拆解各环节对 RAG 效果的影响，为从业者提供可落地的技术优化方向。

1. 文档分块-Chunking

所谓兵马未动粮草先行，要有一个好的检索结果，首先要从我们的知识文档的优化开始，我们实践中比较重视知识文档的内容沉淀，但是在一些文档结构组织，段落划分，以及一些知识点的内聚性和正交性上会涉及少一点。我们来看下一份文档在语义chunking（基础的按照token、字符、语句、段落切分大部分情况下效果都比较局限）下是被如何处理的。


# 设置本地数据保存目录
local_data_dir = pathlib.Path("/Users/jiangdanyang/workspaces/python/MarioPython/src/RAG/dataset/ai-arxiv2")
# 加载数据集（如果本地存在则从本地加载，否则下载）
dataset = load_dataset("jamescalam/ai-arxiv2", split="train", cache_dir=str(local_data_dir))

# 初始化编码器
encoder = OpenAIEncoder(
   name="text-embedding-3-small",
   openai_api_key=os.getenv("AI_API_KEY"),
   openai_base_url=os.getenv("AI_API_BASE_URL")
)

chunker = StatisticalChunker(
    encoder=encoder,
    min_split_tokens=100,
    max_split_tokens=500,
    plot_chunks=True,
    enable_statistics=True,
)

chunks_0 = chunker(docs=[dataset["content"][0]], batch_size=500)

例子中是针对一篇论文做chunking，chunking会设置min_split_tokens（最小chunk的tokens数）和max_split_tokens（最大chunk的tokens数），chunking完之后的统计结果可见下面的图和表：

Chunking Statistics:
  - Total Documents: 474
  - Total Chunks: 46
  - Chunks by Threshold: 41
  - Chunks by Max Chunk Size: 4
  - Last Chunk: 1
  - Minimum Token Size of Chunk: 54
  - Maximum Token Size of Chunk: 495
  - Similarity Chunk Ratio: 0.89

可以先看下统计的结果文字描述，简单做下解释：

整体Documents（可以简单理解为句子数，本部分设计的document都是该含义）：474；
整体切分的文件块chunk：46个，其中41chunk的切分是基于相似度的阈值（可以理解为是按照语义正常划分出来的），有4个是因为达到了500tokens数量被切分的，还有最后1个chunk是到文章结尾了；
最大的chunk的token数495个，最小的chunk的token数54个，因为是lastchunk，所以会出现小于min_split_tokens的情况；
最后SimilarityChunkRatio是统计这次切分的chunk，89%的chunk是按照语义切分出来的（41/46）；

SimilarityChunkRatio可以比较好的说明当前外部文档的chunking的结果，因为试想都是被max_split_tokens卡主划分的chunk，后续在语义检索的时候，结果也不会太好。实践中需要针对你的文档情况，调整split的token大小，在chunk的数量和相关性比例上达到一个平衡；除了chunk的大小，还有两个值需要关注：

Threshold，就是所谓的相似度的下限，上面例子中threshold是0.31，该值越大，chunk内的相关性越好；
WindowSize，是被用于计算的document的数量大小，默认是5，即每次是选择连续的5个document计算相似度，windowsize设置越大，上下文切分的相关性越好，但是同时chunking过程的计算量和耗时也更高，chunk大小相对要大；

这篇论文《Meta-Chunking: Learning Text Segmentation and Semantic Completion via Logical Perception》也给出了一个基于逻辑和语义的chunking的方法，有完整的效果评测，可参考；除了semantic Chunking之外，还有面向多模态数据文档类型的Modality-Specific Chunking（可以比较好的区分不同内容类型的文档块，并面向文本、表格、代码、图使用不同的chunking策略）和Agentic Chunking（让能力强的LLM阅读全文，判断给出切分策略），上述都是工具箱里面的工具，实践中需要结合自身的场景、知识现状、成本综合去权衡选择，并且面向效果进行调优或者切换更适合的方式。

2. 索引增强-Indexing

索引增强，这里介绍两种类型：1.语义增强；2.反向HyDE。

语义增强

语义增强就是将chunk和该chunk所在的文档内容（这里是整片论文）传给LLM，让LLM结合整个文档对这段chunk作个概述，然后把这个概述的信息append到chunk的内容中，从而增强在后续进行语义检索时的精确性。


DOCUMENT_CONTEXT_PROMPT = """
<document>
{doc_content}
</document>
"""

CHUNK_CONTEXT_PROMPT = """
Here is the chunk we want to situate within the whole document
<chunk>
{chunk_content}
</chunk>

Please give a short succinct context to situate this chunk within the overall document for the purposes of improving search retrieval of the chunk.
Answer only with the succinct context and nothing else.
"""

这里的LLM选择需要能力比较强的大模型，最好可以有promptcache功能，这样可以大大节省这一部的模型调用开销；同时也有一些做法是可以增加前后两个chunk的内容，对于整体文档比较长且前后文本关联度比较大的场景会有一些增强的效果。

反向HyDE

HyDE，Hypothetical Document Embeddings，是正向query检索增强的一种方式，即可以针对用户的query，生成一些假设的答案或者做query扩写，然后通过这些中间内容去做检索召回；反向HyDE的意思是针对chunk（可以视为answer），生成这块chunk可能的question，然后针对这些quetion进行索引构建，关联到具体的chunk内容；反向HyDE相比HyDE的优势是可以离线处理，不影响实时调用的rt。


Given the following text chunk, generate {n} different questions that this chunk would be a good answer to:

Chunk: {chunk}

Questions (enumarate the questions with 1.2., etc.):

该方法比较适合这类问答型的知识，比如一些答疑内容，有明确的A和Q的，或者可以作为后面hybridsearch中的关键词扩写，提升后续混合检索的效果。

3. 编码-Embedding

Embedding大家应该都很熟悉，就是将输入的文本（多模态内容）转换成向量，主要过程包含文字到token的切分，然后每个token在词汇表中有对应的id，每个tokenid都会对应同等维度（不同embedding模型维度不同）的向量，可以看个简单的例子。


first_sentence = "直播分享会AI Living第一场"
second_sentence = "直播鲁班小组分享第77期"

model = SentenceTransformer("/Users/jiangdanyang/workspaces/python/Model/all-MiniLM-L6-v2")
tokenized_first_sentence = model.tokenize([first_sentence])
tokenized_second_sentence = model.tokenize([second_sentence])

编码之后是当前文本对应的tokens的tokenid列表，这里影响编码的原因有这些：

1. 编码模型的语言问题，不同语言会有不同的分词和词汇表，比如例子中使用的这个编码模型all-MiniLM-L6-v2在处理中文的文本时候，就比较差，可以看到返回的id有好些100（不可识别的token），中文的处理可以找相应的中文embedding模型，但是不是所有语言都有对应的编码模型，因为语种太多，同时如果一些语种对应的数据语料太少，不足以训练这样的一个模型。

2. 编码模型的词汇表大小，例子中的all-MiniLM-L6-v2的词汇表大小是30522，有些主流模型的词汇表大小基本都在5w以上，有些10w以上，词汇表小会导致一些词无法表示，只能用一个兜底tokenid来代替，会影响后续处理的效果；词汇表大能精准标识文本的输入，但是间接也会增加文本编码完之后的token大小。

3. 编码模型的语义空间，不同的编码模型有自己的词汇表，以及自己对应的向量语义空间，向量语义空间的效果决定于该模型训练基于的数据集，目前用于文本编码的模型，基本都是现有世界知识的通用语义空间，偏日常、大众化的关联，如果我们需要在一个特定领域下，有一个特殊的语义空间，可能就需要找一个使用该领域下的数据训练的embedding模型，或者需要自己SFT一个，不然预期想要的效果和实际效果可能会有比较大的gap。（顺便说下图知识的问题，直接拿图片当知识，处理过程可能就是OCR的文本提取，或者是LLM对于图片的理解描述，但是这里的干扰会很大，比如中间过程的文本，是不是你期望的样子和描述的维度，这些都需要把握下，不然后续的检索召回肯定也是一团浆糊）

4. 检索-HybridSearch

HyBridSearch，混合搜索，本质上是结合了Term-based和Semantic-based两种模式的检索特性，通过融合两种形式的算法，来提升检索的准确性和相关性；HybridSearch结合了SparseVector（稀疏向量）相似度计算----关键词匹配和DenseVector稠密向量相似度计算----语义匹配，从而提升检索的效果，可见下图：

Sparse向量主要是通过BM25为代表的算法生成，BM25核心就是TF-IDF算法（词频-反向文档频率），返回是某个query相对每个文档编号的分数值（具体算法如下）。


# Load the chunks
corpus_json = json.load(open('/Users/jiangdanyang/workspaces/python/MarioPython/src/RAG/dataset/corpus.json'))
corpus_text = [doc["text"] for doc in corpus_json]

# optional: create a stemmer
english_stemmer = snowballstemmer.stemmer("english")

# Initialize the Tokenizer with the stemmer
sparse_tokenizer = Tokenizer(
    stemmer=english_stemmer,
    lower=True, # lowercase the tokens
    stopwords="english",# or pass a list of stopwords
    splitter=r"\w+",# by default r"(?u)\b\w\w+\b", can also be a function
)

# Tokenize the corpus
corpus_sparse_tokens = (
    sparse_tokenizer
    .tokenize(
        corpus_text, 
        update_vocab=True, # update the vocab as we tokenize
        return_as="ids"
    )
)

# Create the BM25 retriever and attach your corpus_json to it
sparse_index = bm25s.BM25(corpus=corpus_json)
# Now, index the corpus_tokens (the corpus_json is not used yet)
sparse_index.index(corpus_sparse_tokens)

# Return 10 the most relevant docs according to the query
sparse_results, sparse_scores = sparse_index.retrieve(query_tokens, k=10)

Dense向量主要是通过基于Transformer架构的embedding模型来进行编码生成，同时针对查询query，使用同样的embedding模型进行编码，然后再进行向量的相似度比对，找出最相似的n个结果。


#Dense Index
# create the vector database client
qdrant = 
QdrantClient(path="/Users/jiangdanyang/workspaces/python/MarioPython/src/RAG/dataset/qdrant_data")
# Create the embedding encoder
dense_encoder = SentenceTransformer('/Users/jiangdanyang/workspaces/python/Model/all-MiniLM-L6-v2')

collection_name = "hybrid_search"
qdrant.recreate_collection(
    collection_name=collection_name,
        vectors_config=models.VectorParams(
        size=dense_encoder.get_sentence_embedding_dimension(), 
        distance=models.Distance.COSINE
    )
)
# vectorize!
qdrant.upload_points(
    collection_name=collection_name,
    points=[
        models.PointStruct(
            id=idx,
            vector=dense_encoder.encode(doc["text"]).tolist(),
            payload=doc
        ) for idx, doc in enumerate(corpus_json) # data is the variable holding all the enriched texts
    ]
)

query_vector = dense_encoder.encode(query).tolist()
dense_results = qdrant.search(
    collection_name=collection_name,
    query_vector=query_vector,
    limit=10
)

最后针对上述两种方式找出的chunk做综合筛选，这里可以有多种方式，比如比较常用的就是先分别对Sparse向量和Dense向量计算出来的topn个结果的分值做归一化，然后针对统一个Chunk，按照一定的权重（比如Sparse向量计算结果权重0.2，Dense向量计算结果权重0.8）计算一个最终分值，最后返回topn个chunk列表给到下个节点：

# Normalize the two types of scores
dense_scores = np.array([doc.get("dense_score", 0) for doc in documents_with_scores])
sparse_scores = np.array([doc.get("sparse_score", 0) for doc in documents_with_scores])

dense_scores_normalized = (dense_scores - np.min(dense_scores)) / (np.max(dense_scores) - np.min(dense_scores))
sparse_scores_normalized = (sparse_scores - np.min(sparse_scores)) / (np.max(sparse_scores) - np.min(sparse_scores))

alpha = 0.2
weighted_scores = (1 - alpha) * dense_scores_normalized + alpha * sparse_scores_normalized

如果当前场景的检索需要兼顾关键词和语义的时候，可以考虑混合搜索（需要结合文档内容、chunking和关键字词构建等环节）；相对于关键字词匹配检索，混合搜索可以降低查询编写的规范性（不一定要有特定的关键词出现）以及提升查询的容错性（可能会有拼写错误或者不恰当的描述）；相对于语义相似检索，混合搜索可以增加一些领域专有信息的更精准匹配，提升检索结果的准确性。

5. 重排-ReRanking

检索的优点是可以在海量的知识里面快速找到和用户query相关的内容块docs，但是检索所返回出来的docs，实际上可能部分和用户query关联度并不大，这个时候就需要通过re-rank这一步，对于检索返回出来的docs做关联度排序，最终选取最相关的topk个doc，做后续的上下文补充。

在RAG链路中，ReRanking的常用技术是Cross-Encoder（交叉编码器），本质一个Bert模型（Encode-only的transformer架构），计算query和每一个doc相关性，返回0~1之间的结果（1代表最相关），示意图和代码示例如下：


from sentence_transformers import CrossEncoder 


cross_encoder = CrossEncoder("/Users/jiangdanyang/workspaces/python/Model/jina-reranker-v1-tiny-en")
hybrid_search_results = {}
with open('/Users/jiangdanyang/workspaces/python/MarioPython/src/RAG/dataset/dense_results.json') as f:
 dense_results = json.load(f)
    for doc in dense_results:
        hybrid_search_results[doc['id']] = doc

with open('/Users/jiangdanyang/workspaces/python/MarioPython/src/RAG/dataset/sparse_results.json') as f:
    sparse_results = json.load(f)
    for doc in sparse_results:
        hybrid_search_results[doc['id']] = doc

console.print(hybrid_search_results)

# This is the query that we used for the retrieval of the above documents
query = "What is context size of Mixtral?"
pairs = [[query, doc['text']] for doc in hybrid_search_results.values()] 
scores = cross_encoder.predict(pairs)

最后进行排序，选择topk个结果补充到context中，然后调用模型拿最后的结果：


client = OpenAI(
   api_key=os.getenv("AI_API_KEY"),
   base_url=os.getenv("AI_API_BASE_URL")
)
completion = client.chat.completions.create(
    model="qwen_max",
    messages=[
        {"role": "system", "content": "You are chatbot, an research expert. Your top priority is to help guide users to understand reserach papers."},
        {"role": "user", "content": query},
        {"role": "assistant", "content": str(search_results)}
    ]
)

2、结语

AI应用的开发实践进行得非常火热，现阶段可能更多的是对已有的一些基建平台、开发编排工具、现成的横向基础产品做整合使用，结合使用场景做链路设计。但是随着时间推移，还是需要慢慢深入到部分细节，往深水区慢慢前行，本文讲述的RAG只是AI架构中的一块，其他相关的技术，在对待方式上也雷同，都需要经历快速使用、技术细节了解、使用产品实现了解、应用中的设计实现迭代、面向效果的循环优化，快速上手有捷径，得益于比较好的基础设施建设，成本比较低，但是深入追寻效果，切实提升效率或幸福感，需要更深入的探寻，希望对读到这里的小伙伴有帮助。

3、如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】