【干货】RAG系统构建指南：12个核心技术提升准确率至99%（含代码示例）

原创于 2025-10-21 14:13:13 发布 · 463 阅读

CC 4.0 BY-SA版权

文章标签：

本文分享了构建高精度RAG系统的12项核心技术，包括PageIndex、多向量检索、重排序等，帮助将系统准确率从基础的50%提升至99%。作者提供分阶段实施策略和正确评估指标，强调真正的魔法在于智能检索、排序和推理信息，而非模型本身。内容实用，含代码示例，适合程序员学习参考。

一、为什么基础RAG会失败？

“大多数RAG系统甚至在开始之前就坏了。”

当我第一次开始构建RAG应用程序时，我遵循了大家都在谈论的经典流程：分块文档→嵌入它们→存储在向量数据库中→检索前k个相似的块。理论上听起来很可靠——但在实际使用中，这种方法常常会失败。

基础RAG架构

这就是为什么：

需要多块推理的复杂查询：当答案需要组合来自多个块的信息时，简单的相似性搜索就难以应对了。
跨多个部分扩展的上下文：传统的块切分会破坏文档的自然流程，导致模型丢失重要上下文。
需要澄清的模糊问题：一个模糊或多部分的问题常常会检索到不相关的块，让LLM去猜测。
多源信息综合：当答案需要连接不同文档或来源的事实时，基础的向量搜索无法有效处理关系。

现实世界的例子：像DoorDash、LinkedIn和Amazon这样的公司已经意识到了这些局限性，并远远超越了简单的向量相似性。他们实施了先进的检索策略，以适应查询的复杂性、文档结构和多源推理，使其RAG系统能够在生产规模上运行。

这就是为什么理解超越基础检索的技术对于构建高准确率的RAG应用至关重要。

二、实现高性能RAG的12个核心技术

“模型不是魔法——这些技术才是。”

当我第一次构建RAG系统时，我以为一个更大的LLM能解决所有问题。我错了。真正的区别在于你如何检索、排序和结构化你的知识。

让我们深入探讨那些将我的RAG流程在 FinanceBench 上准确率提升至99%的技术。

高性能RAG

2.1 PageIndex：类人文档导航

PageIndex 不再将文档视为孤立的块，而是构建了文档的层次树——非常像人类略读报告的方式。

PageIndex，来源：https://github.com/VectifyAI/PageIndex

为什么它有效：

LLM可以在章节上进行推理，而不是扫描不相关的块。
没有人工分块→保留了自然结构。
透明：你可以追踪在推理过程中使用了哪些节点。

为什么使用它？

它解决了“分块”的根本问题。它不再检索零散的文本片段，而是允许LLM在整个文档及其结构上进行导航和推理，就像人类一样。这消除了幻觉，并在复杂数据集上将准确率提高了40%以上，因为模型拥有完整的上下文。

缺点：

高复杂性：构建和维护层次树是复杂且资源密集型的。
计算成本：在树上进行推理可能比简单的向量搜索要慢。

事实：在FinanceBench上，向量RAG的准确率约为50%，而PageIndex达到了98.7%。

from langchain.indexes import PageIndex
from langchain.llms import OpenAI

# 为财务报告构建树索引
document_tree = PageIndex.from_documents(documents)

# 查询树
llm = OpenAI(temperature=0)
query = "What was the company's net profit trend in Q2?"
response = document_tree.query(query, llm=llm)
print(response)

2.2 多向量检索

不再是每个块只生成一个嵌入，而是生成代表不同方面的多个嵌入：摘要、关键词、潜在问题和全文。

多向量检索，来源：https://blog.langchain.com/semi-structured-multi-modal-rag/

为什么它有效：

一个嵌入无法捕捉所有相关的角度。
多个嵌入允许以不同的方式将内容与查询匹配。

为什么使用它？

它克服了单一向量嵌入的“单一视角”限制。通过捕捉文档的多个方面（例如，摘要、关键词、问题），它极大地提高了成功和相关检索的机会，特别是对于复杂或多方面的查询。

缺点：

存储开销：为每个块存储多个嵌入会显著增加存储需求。
索引复杂性：索引过程更复杂且耗时。

from langchain.vectorstores import FAISS
from sentence_transformers import SentenceTransformer

model = SentenceTransformer("all-MiniLM-L6-v2")

# 为单个文档块创建多个嵌入
embeddings = [
    model.encode(chunk.text),      # 全文
    model.encode(chunk.summary),   # 摘要
    model.encode(chunk.keywords)   # 关键词
]

faiss_index = FAISS.from_embeddings(embeddings)

2.3 元数据增强

元数据为每个块增加了额外的上下文：来源、作者、创建日期、质量得分、相关实体。

好处：

提高检索精度。
帮助模型优先处理可信来源。

为什么使用它？

它增加了向量搜索本身所缺少的关键上下文。通过包含来源、日期和作者等信息，它帮助LLM做出更明智、更可信的决策，从而产生更高质量的答案和更好的引用召回率。

缺点：

手动工作：手动添加元数据可能非常耗时且容易出错。
质量依赖：检索的质量高度依赖于元数据的质量。

2.4 CAG（缓存增强生成）

CAG通过将频繁访问的静态数据预加载到模型的键值缓存中来减少延迟。

非常适合合规规则、产品手册或内部指南。
与RAG结合使用：RAG检索新信息，CAG记住静态信息。

为什么使用它？

它极大地减少了频繁被问到的问题或静态信息的延迟和计算成本。通过将数据预加载到缓存中，它绕过了整个RAG流程，为常见查询提供了即时、低成本的答案。

缺点：

可伸缩性限制：缓存仅对高频、静态数据有效；对动态或新信息无效。
内存使用：将数据预加载到KV缓存中会消耗大量内存。

# 将静态内容预加载到KV缓存中
kv_cache = CAGCache()
kv_cache.preload(static_documents)

# 在查询期间
response = llm.generate(query, context=kv_cache)

事实：使用CAG的公司报告称，高流量查询的响应时间加快了50-70%。

2.5 上下文检索

该技术确保每个块在嵌入前携带足够的上下文。受Anthropic研究的启发，它防止LLM误解孤立的块。

def contextualize(chunk):
    # 在嵌入前添加上下文
    return f"In the 2022 finance report, {chunk['text']}"

embeddings = model.encode([contextualize(c) for c in chunks])

单独使用，可将检索准确率提高约49%。
与重排序结合使用→改进高达67%。

为什么使用它？

它直接解决了由模糊或复杂查询引起的“检索失败”。通过添加简洁的、由模型生成的上下文，它引导搜索并确保在第一次尝试时就检索到最相关的信息，从而提高效率和准确性。

缺点：

增加延迟：在嵌入前添加上下文的过程会引入少量延迟。
提示工程依赖：有效性依赖于精心设计的提示来添加有用的上下文。

2.6 重排序

“第一次检索是不够的——你需要第二次意见。”

重排序增加了一个辅助模型来评估初步检索到的文档的相关性。这一步确保LLM只看到与上下文最相关的块，而不是盲目相信向量相似性。

为什么使用它？

它将检索结果的质量从“可能相关”提升到“高度相关”。简单的语义搜索通常会返回一个相关文档的列表，但重排序器会根据真实相关性对它们进行排序，确保LLM只在最好的证据上进行推理。

事实：重排序可以将准确率比简单的语义相似性提高多达60%。

from transformers import AutoModelForSequenceClassification, AutoTokenizer

# 加载重排序器模型
tokenizer = AutoTokenizer.from_pretrained("cross-encoder/ms-marco-MiniLM-L-6-v2")
model = AutoModelForSequenceClassification.from_pretrained("cross-encoder/ms-marco-MiniLM-L-6-v2")

def rerank(query, candidates):
    inputs = tokenizer([query]*len(candidates), candidates, return_tensors=\'pt\', padding=True)
    scores = model(**inputs).logits.squeeze().detach().numpy()
    ranked = [c for _, c in sorted(zip(scores, candidates), reverse=True)]
    return ranked

top_candidates = rerank("Net profit trend Q2 2025", retrieved_docs)

缺点：

增加延迟：运行第二个模型进行重排序会增加检索过程的计算时间和延迟。
成本：使用更复杂的模型进行重排序会增加成本。

2.7 混合RAG

“一种方法是不够的——结合优势。”

混合RAG结合了基于向量的语义搜索和图遍历来处理：

语义相似性（向量搜索）。
实体关系和依赖（图）。

为什么它很重要：非常适合需要跨文档连接事实的多跳推理。

为什么使用它？

它结合了两种不同检索方法的优势。向量搜索擅长寻找语义上相似的信息，而图遍历非常适合多跳推理和连接实体。这使得系统能够有效地处理简单和复杂的、相互关联的数据查询。

# 向量检索
vector_candidates = vectorstore.similarity_search(query)

# 图检索
graph_candidates = knowledge_graph.query_related_entities(query)

# 合并和重排序
hybrid_candidates = rerank(query, vector_candidates + graph_candidates)

缺点：

集成复杂性：将向量搜索与图遍历系统相结合在技术上具有挑战性，需要构建和维护。
高开销：需要管理两种不同的搜索方法，增加了基础设施和维护成本。

2.8 自我推理

“让你的LLM成为一个主动的质量检查员。”

LLM不再盲目相信检索到的块，而是在多个阶段评估自己的输入：

RAP (Relevance-Aware Process)：评估检索质量。
EAP (Evidence-Aware Process)：选择带有理由的关键句子。
TAP (Trajectory Analysis Process)：将推理路径综合成最终答案。

为什么使用它？

它将RAG系统从一个被动的检索器转变为一个主动的、智能的代理。通过让LLM自己评估检索到的块，它可以纠正自己的错误，优化其搜索，并显著减少幻觉和提高引用准确性。

事实：自推理的准确率达到83.9%，而标准RAG为72.1%，并提高了引用召回率。

缺点：

执行缓慢：多阶段推理过程计算量大且缓慢。
LLM可靠性：性能高度依赖于LLM的推理能力，而这并非总是可靠的。

for chunk in retrieved_chunks:
    relevance_score = llm.evaluate_relevance(chunk, query)
    if relevance_score > 0.7:
        evidence_chunks.append(chunk)

answer = llm.synthesize_answer(evidence_chunks)

2.9 迭代/自适应RAG

“并非所有查询都是平等的——区别对待它们。”

自适应RAG根据复杂性路由查询：

简单的事实性查询→单步检索。
复杂的分析性查询→多步迭代检索。

为什么使用它？

它创建了一个更高效、响应更快的系统。它不再采用一刀切的方法，而是根据查询的复杂性匹配检索策略，为简单问题节省时间和资源，同时确保复杂问题的彻底性。

缺点：

路由复杂性：根据复杂性路由查询的逻辑难以实现和微调。
开发时间增加：构建具有不同检索路径的系统会增加大量的开发和测试工作。

好处：优化准确性和成本，将计算集中在需要的地方。

complexity = query_classifier.predict(query)

if complexity == "simple":
    answer = simple_retrieve(query)
else:
    answer = iterative_retrieve(query)

2.10 Graph RAG

“将文档转化为知识网络。”

Graph RAG从文档中构建知识图谱，连接实体、概念和事实：

支持多跳推理。
减少幻觉。
示例集成：MongoDB + LangChain

为什么使用它？

它为多跳推理和知识密集型任务提供了强大的解决方案。通过创建一个结构化的知识图谱，它允许LLM跟踪实体之间的关系，从而为复杂的、相互关联的查询提供高度准确和无幻觉的答案。

缺点：

图构建开销：从非结构化文本创建和维护知识图谱是一项复杂且耗时的任务。
可伸缩性问题：将图和图遍历扩展到大量文档可能具有挑战性。

2.11 查询重写

“别让你的系统猜——先澄清意图。”

将模糊或结构不良的查询转换为可检索的格式。
将复杂问题分解为子查询。
为精确性添加领域特定上下文。

为什么使用它？

它通过使系统对模糊或格式不佳的问题更具鲁棒性，直接改善了用户体验。通过自动澄清或分解查询，即使用户的初始提示不完美，它也能确保搜索成功。

缺点：

潜在错误：LLM的重写过程可能会误解用户的意图，导致不正确的结果。
增加延迟：在搜索前重写查询会增加一个额外的步骤和延迟。

def rewrite_query(raw_query):
    # 示例：解决模糊性并添加上下文
    return f"In the 2025 finance report, {raw_query}"

clean_query = rewrite_query("Net profit Q2")

2.12 BM25集成

“将语义智能与精确匹配相结合。”

BM25集成将语义向量搜索与基于关键字的排名相融合：

并行运行两种搜索。
使用加权评分合并结果。
应用重排序来挑选最相关的候选者。

为什么使用它？

它为语义搜索增加了一个关键的词法精度层。通过包含关键字匹配，它确保系统可以找到纯语义搜索可能会漏掉的精确术语、名称或代码，从而创建一个更全面、更准确的结果。

缺点：

参数调整：在向量搜索和关键字搜索之间加权结果需要仔细和复杂的调整。
有限的语义理解：BM25本身缺乏语义理解，如果平衡不当，可能会影响整体结果的质量。

from rank_bm25 import BM25Okapi

bm25 = BM25Okapi([doc.split() for doc in docs])
bm25_scores = bm25.get_scores(query.split())

# 结合BM25和语义向量分数
final_scores = 0.6 * vector_scores + 0.4 * bm25_scores
ranked_docs = [doc for _, doc in sorted(zip(final_scores, docs), reverse=True)]

这些先进技术是高精度、生产就绪的RAG的支柱。

三、实施策略：分阶段方法

“技术如果没有系统的计划就是无用的。”

我们讨论的所有RAG技术都很强大——但没有一个结构化的实施策略，即使是最好的方法也无法持续交付成果。这是一个对我有用的分阶段方法，可以应用于大多数RAG系统。

3.1 阶段1：基础

目标：为您的检索系统构建坚实的基础。

文档预处理：清理、规范化和结构化您的文档（如果需要，删除噪音、处理HTML）。
上下文分块：避免任意分割；保留语义边界，以便每个块都保留有意义的上下文。

构建良好的知识库 [VectorDB]

def preprocess_document(doc):
    # 删除页眉、页脚和特殊字符
    clean_text = clean_html(doc)
    return split_into_semantic_chunks(clean_text)

chunks = [preprocess_document(d) for d in documents]

影响：适当的基础通常会在RAG准确性方面带来最大的初始收益。

3.2 阶段2：检索增强

目标：提高模型所见文档的相关性。

重排序：添加一个辅助模型来优先处理与上下文最相关的块。
BM25集成：将语义向量搜索与精确的关键字匹配相结合，以捕获精确的术语。

检索增强示例:


# 结合BM25和向量分数
final_scores = 0.6 * vector_scores + 0.4 * bm25_scores
ranked_docs = [doc for _, doc in sorted(zip(final_scores, docs), reverse=True)]

影响：提高检索精度和将相关信息反馈给LLM。

3.3 阶段3：智能层

目标：使您的系统更具查询感知和自适应性。

查询重写：在检索前澄清用户意图以减少歧义。
自适应路由/迭代RAG：根据复杂性路由查询；简单查询获得快速的单步答案，复杂查询获得多步推理。

RAG和基于LLM的架构中的智能层

if query_classifier.predict(query) == "complex":
    answer = iterative_retrieve(query)
else:
    answer = simple_retrieve(query)

影响：优化准确性和延迟，将资源集中在最需要的地方。

3.4 阶段4：高级技术

目标：有效处理复杂、多跳或连接的数据。

Graph RAG：捕获实体和概念之间的关系。
自推理：让LLM评估块相关性并综合推理路径。
多向量检索：为每个块使用多个嵌入以用于不同方面（摘要、关键字、问题）。

多跳和处理复杂查询

# 基于图的多跳推理
related_entities = knowledge_graph.query_entities("Company A", depth=2)

# LLM自我评估
evidence_chunks = [c for c in retrieved_chunks if llm.evaluate_relevance(c, query) > 0.7]
answer = llm.synthesize_answer(evidence_chunks)

影响：最大限度地提高生产级RAG系统的准确性、上下文感知和可靠性。

实施RAG不仅仅是挑选技术——而是战略性地对它们进行分层。通过遵循这个分阶段的计划，您可以确保每个技术都建立在前一个技术的基础上，从而实现高精度、可扩展的RAG流程。

四、衡量成功：正确的指标

“如果你无法衡量它，你就无法改进它。”

实施高性能RAG系统只是成功的一半。另一半是衡量它的实际效果。没有正确的指标，你就不知道哪些技术是有效的，哪些是无效的。

以下是评估RAG系统的关键指标：

4.1 忠实度

定义：衡量模型的响应与检索到的上下文的一致性。确保答案不是幻觉。

示例概念：

faithfulness_score = llm_judge.evaluate_faithfulness(response, retrieved_chunks)

4.2 答案相关性

定义：响应是否实际回答了用户的问题？高检索准确性并不能保证LLM产生相关的答案。

由自动化法官和人类评审员共同评估。

relevance_score = llm_judge.evaluate_relevance(response, query)

4.3 上下文精确度和召回率

上下文精确度：最重要的相关文档是否排在最前面？

上下文召回率：是否检索到了所有相关的文档？

精确度可确保LLM首先看到高质量的上下文。
召回率可确保不会遗漏任何重要信息，特别是对于多跳或连接的查询。

示例概念：

precision = compute_precision(retrieved_docs, ground_truth_docs)recall = compute_recall(retrieved_docs, ground_truth_docs)

4.4 持续评估：LLM即法官+人工验证

现代生产RAG系统通常使用LLM即法官框架来自动评估指标。

LLM即法官：在忠实度、相关性和格式合规性方面对输出进行评分。
人工评审员：验证样本以确保与专家判断的一致性。

事实：LLM法官与人类评审员的一致性可以达到85%的时间，通常超过人类评估者之间的一致率（81%）。

通过系统地使用这些指标，您可以确保您的RAG系统不仅仅是“工作”——它是准确、可靠和持续改进的。

五、其他高级技术

“一旦你掌握了基础知识，这些先进技术将把你的RAG系统提升到一个新的水平。”

拥有强大的基础和分阶段的实施，高性能RAG系统将受益于专门的优化和先进方法。以下是我帮助我将生产就绪系统的准确性和可扩展性推向极限的一些技术。

5.1 嵌入模型优化

定义：使用特定领域的嵌入而不是通用嵌入来更好地捕捉数据中的细微差别。

通用嵌入通常会漏掉领域行话、缩写或结构化内容。
切换到在金融、医疗或法律数据上训练的嵌入可以显著提高检索准确性。

示例：

from sentence_transformers import SentenceTransformer# 针对金融领域优化的特定领域嵌入模型model = SentenceTransformer("tge-base-en-v1.5") # 针对金融领域进行了优化embeddings = model.encode(documents)

5.2 延迟分块

定义：首先为整个文档生成嵌入，然后将其拆分为块。保留每个块内的完整上下文，特别适用于传统分块会破坏上下文的冗长文档。

示例概念：

full_embeddings = model.encode(full_document)chunks_embeddings = split_embedding_into_chunks(full_embedding, chunk_size=512)

5.3 高级文档预处理

定义：处理超越纯文本的复杂文档结构。

HTML感知解析：保留标题、表格和层次结构。
表格感知处理：准确提取结构化数据。
多模态内容：处理带有嵌入式文本的图像、图表或PDF。

示例概念：

from bs4 import BeautifulSoupsoup = BeautifulSoup(html_content, "html.parser")text_chunks = [section.get_text() for section in soup.find_all("p")]

5.4 Fusion-in-Decoder (FiD)

定义：在生成之前并行处理问题-文档对，允许模型同时考虑多个来源。改进了复杂查询的多源推理，优于顺序标记生成。

示例概念：

# FiD 流程responses = fid_model.generate(query, context_documents)final_answer = combine_responses(responses)

5.5 RAG-Token vs RAG-Sequence

定义：在生成过程中集成检索文档的两种策略。

RAG-Token：为每个生成的标记选择不同的文档→细粒度集成。
RAG-Sequence：为整个答案选择最佳的整体文档→更简单、更稳定的输出。

用例：

RAG-Token → 非常适合具有高细节的多源合成。
RAG-Sequence → 更适合简洁的单源答案。

示例概念：

# RAG-Sequenceanswer = rag_sequence_model.generate(query, retrieved_documents)# RAG-Tokenanswer = rag_token_model.generate(query, retrieved_documents)

这些先进技术是可选的，但对于生产级的RAG应用程序，尤其是在处理长文档、复杂查询或特定领域数据集时，具有很高的影响力。

五、结论/行动号召

“RAG在不断发展——你的系统也必须如此。”

大多数工程师开始时都认为LLM是魔法。但正如我们所见，真正的性能来自于你围绕它构建的检索和推理策略。准确性、可扩展性和可靠性并非来自更大的模型——它们来自更智能的系统。

如果你正在为生产构建RAG，请记住：

准确性不是运气→而是关于PageIndex、重排序、元数据和自适应流程。
速度不仅仅是硬件→而是关于CAG、上下文检索和缓存正确的数据。
可靠性不是试错→而是关于衡量正确的指标并系统地应用先进技术。

不要依赖一次性的技巧。采用系统的、分阶段的改进策略，将您的RAG应用程序从原型带到生产就绪。

如何学习大模型 AI ？

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

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

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

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

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

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

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