RAG 高级用法

本文系统梳理了 RAG（检索增强生成）的全链路实践路线，从技术树概览到 RAFT 方法论，从高效召回策略到 Qwen-Agent 构建超长上下文处理能力，再到 Ragas 框架的质量评估与实操。最后，总结了商业落地实施 RAG 工程的核心步骤。

1. NativeRAG 实现步骤

索引（Indexing）
- 文档加载
  - 将企业内容部的私有化数据（语料：非结构化数据）进行清洗
  - 数据质量把控部门
  - 使用智能文档解析技术转为结构化数据
- 文档切片（Chunking 策略）
  - TextSplitter 切割
    - 设置 chunk_size
    - 设置 chunk_overlap
  - 策略：递归、富文本、基于语义的切片
- 文本向量化
  - 选择合适的向量模型（如 BGE 系列）
- 向量存储
  - Chroma（轻量化）
  - Milvus（适合企业高并发场景）
检索（Retrieval）
- 多路召回策略（混合检索）
  - 向量检索（语义相似度、向量距离度量）
  - 关键字检索（基于 BM25、倒排索引）
- 文档重排序
  - 对召回的文档按相关性进行重排序，提升精度
生成（Generation）
- 上下文利用率优化
  - LLM 如何精确提炼知识
  - 经验结论：3–6 个文档作为上下文最合适，过多会增加噪声

RAG 发展
- 技术树范围：RAG 的研究主要涉及 预训练（Pre-training）、微调（Fine-tuning） 和 推理（Inference） 三个阶段。
- 早期阶段：随着 LLM 的出现，RAG 研究最初重点利用 LLM 强大的上下文学习能力，主要集中在 推理阶段。
- 发展趋势：研究逐渐与 LLM 的 微调阶段深度融合，并探索在 预训练阶段引入检索增强技术，以进一步提升语言模型性能。

2. RAFT 方法

RAFT（Retrieval Augmented Fine Tuning）是一种将检索增强生成（RAG）与监督微调（SFT）结合的训练方式，用于提升 LLM 在特定领域问答任务中的表现。

论文：RAFT: Adapting Language Model to Domain Specific RAG (2024)
论文解读：RAFT（RAG + SFT）

背景类比：如何最好地准备考试？
- 基于微调的方法：通过“学习”直接记忆输入文档，或做练习题但不参考文档。
- 基于上下文检索的方法：没有利用固定领域可提前获得的文档，相当于“开卷考试但不复习”。
- RAFT 方法：结合微调与问答对，在模拟不完美检索环境中使用参考文档，有效为开卷考试场景做准备。
RAFT 训练 LLM：
- 从**一组正面文档（Golden Documents）与干扰文档（Distractors）**中读取解决方案。
- 与标准 RAG 不同，RAFT 在训练中显式引入干扰文档，迫使模型学会识别与忽略无关信息。
- 测试阶段依旧遵循标准 RAG 流程（提供 top-k 检索文档）。
训练数据准备
- 每条训练数据包含：
  - 问题（Q）
  - 黄金文档 $D^{*}$
  - 干扰文档 $D_{1}, D_{2}, \dots, D_{k}$
  - 答案（A*）：包含推理链（CoT）与引用原文内容
- 数据混合策略：
  - $P %$ 的样本： $Q + D^{*} + D_{1} + \dots + D_{k} \to A^{*}$
  - $(1 - P) %$ 的样本： $Q + D_{1} + \dots + D_{k} \to A^{*}$ （无黄金文档，强迫模型依靠记忆回答）
实验结果
- 在 PubMed、HotPotQA、HuggingFace、Torch Hub、TensorFlow Hub 等领域：
  - 领域特定微调（DSF）提升了基础模型性能
  - RAFT 在有/无 RAG 情况下均优于 DSF
- 结果表明：在上下文中训练模型是必要的

3. RAG高效召回方法

RAG 的高效召回就是在检索增强生成（Retrieval-Augmented Generation）里，把“从知识库里找资料”的这一步做得又准又快

思考：有哪些策略可以提升 RAG（检索增强生成）的召回质量？

3.1 合理设置 Top-K

核心权衡：
- K 太小 ➔ 漏召回 (错过相关结果)。
- K 太大 ➔ 引入噪声/冗余，增加重排序负担，可能降低精度。

实操建议：

建议初始设置 K = 8~12
核心后处理： 必须结合 重排序（Re-ranking） + 去重合并（Dedup/Merge by source & overlap），以补齐上下文、提升完整性
动态调整 K (进阶)：
- 依据：第一阶段检索的最高置信度得分
- 策略：
  - 最高分 高 → 使用较小 K（如 5）
  - 最高分 低 → 使用较大 K（如 20）
- 实现：设定得分阈值，或用“温度式”平滑调整

降低冗余：MMR（Max Marginal Relevance）

作用：提升结果多样性，减少高度相似内容

示例（LangChain）：

# 基础相似度召回
docs_base = knowledgeBase.similarity_search(query, k=10)

# MMR 多样性召回
docs_mmr = knowledgeBase.max_marginal_relevance_search(
    query,
    k=10,          # 最终返回的多样结果数
    fetch_k=30,    # 候选池大小，必须 > k
    lambda_param=0.5  # 相关性 vs 多样性平衡因子
)

关键参数：
- fetch_k：候选池大小，应显著大于 k
- lambda_param：0=多样性优先，1=相关性优先，0.5 为常用平衡值

3.2. 改进索引算法（结构化语义）

目标： 超越纯词匹配/向量相似度，利用结构化语义信息提升检索效果（可解释性更强、支持多跳推理、降低文本块碎片化带来的信息缺失）。

知识图谱 (KG)索引：
- 构建方法：
  - 从文档中抽取实体与关系，形成实体-关系图
  - 将文本块锚定到对应的实体节点（可多标签锚定）
- 优势：
  - 可解释性：显式展示实体关系
  - 多跳检索：从查询定位实体 → 沿关系边遍历 → 聚合跨块/跨文档证据
  - 更易整合零散信息
层级（父子）索引
- 构建方法：
  - 基于文档结构（章-节-段）或主题聚类
  - 建立父子、上下级关系
- 优势：
  - 召回子块时自动补充父节点上下文
  - 降低碎片化，提升答案完整度
跨文档链接索引
- 构建方法：
  - 显式链接：引用、超链接
  - 隐式链接：实体共现、主题相似、事件关联等（可存储相关性分数）
- 优势：
  - 支持跨文档多跳检索
  - 快速整合不同来源的相关信息
适用场景
- 复杂/多跳问答：答案证据分散在多个段落或文档
- 高可解释性需求：需要展示推理路径
- 长文档/结构化文档：章节清晰、上下文关联强

3.3 引入重排序（Reranking）

Cross-encoder 重排序：对“query-document”对进行逐对打分，重排 Top-K。

常用：BGE-Rerank、Cohere Rerank 等。
作用：把“语义相近但不相关”的文档压后，把“能回答问题”的文档拉前。

场景示例

查询：“如何提高深度学习模型的训练效率？”
初召回：10 篇文章，主题覆盖“深度学习/训练/效率/基础理论……”。
重排后：像“优化深度学习训练的技巧”这类文档排前，“基础理论”类文档靠后。

混合检索 + 重排

先并行做向量检索与关键词/BM25 检索
合并去重 → 重排序统一归一化（可用 z-score 或 min-max）→ 产出最终 Top-K

# 伪代码示例
INPUT: query, corpus (list[Doc{id, text, meta}]), k_final=10

# 1) 预处理
tokens = tokenize_all(corpus)
embeddings = embed_all(corpus)              # 用向量模型离线生成

# 2) 混合初检（BM25 + 向量）
bm25_top = bm25_search(query, corpus, k=K1)  # 稀疏检索
vec_top  = vector_search(query, corpus, k=K2) # 稠密检索（余弦/内积）

# 3) 合并 + 去重
pool = merge(bm25_top, vec_top)
pool = deduplicate(pool, by_id=True, by_text_norm=True)

# 4) （可选）MMR 降冗余（在 Cross-Encoder 前做）
#     参数: fetch_k > k_mmr, lambda ∈ [0,1]
pool = mmr_select(query_embedding, pool_embeddings, k_mmr, fetch_k, lambda)

# 5) Cross-Encoder 批量重排（最终打分）
pairs = [(query, doc.text) for doc in pool]
scores = cross_encoder.batch_score(pairs)    # 一次性批量打分

# 6) （可选）与第一阶段得分融合
#     若需要融合 BM25/向量分数, 先做 z-score/min-max 归一化再加权
if fuse_first_stage:
    s_bm25 = normalize([doc.bm25 for doc in pool])
    s_vec  = normalize([doc.vec  for doc in pool])
    s_ce   = normalize(scores)
    scores = w1*s_ce + w2*s_vec + w3*s_bm25

# 7) 排序并取最终 Top-K
ranked = sort_by_score(pool, scores, desc=True)
return ranked[:k_final]

3.4 优化查询扩展（Query Expansion）

相似语义改写：让大模型生成多版本查询，覆盖不同表述/同义词/细化点。
- LangChain 的 MultiQueryRetriever 可直接用。

1
2
3

from langchain.retrievers import MultiQueryRetriever
retriever = MultiQueryRetriever.from_llm(retriever=kb.as_retriever(), llm=llm)
docs = retriever.get_relevant_documents(query)

提示：控制改写条数（如 3–6），并对改写做去重/过滤（避免低质量扩写拖低精度）。

3.5 双向改写（Query2Doc / Doc2Query）

将查询改写成文档（Query2Doc）或为文档生成查询（Doc2Query），缓解短文本向量化效果差的问题。

Query2Doc：把短查询扩写成文档
- 原始查询：“如何提高深度学习模型的训练效率？”
- 扩写示例（节选）：
  - 采用更高效的优化器（AdamW/LAMB）
  - 混合精度（AMP）
  - 分布式训练（数据/模型并行）
  - 数据预处理与增强
  - 学习率调度（Cosine/One-Cycle）

价值：缓解短文本向量化信息不足，提升语义匹配的覆盖度与精准度。

Doc2Query：为文档生成可能查询
- 文档：介绍“AdamW、混合精度、分布式训练”的训练优化技巧
- 生成查询示例：
  1. 如何选择深度学习优化器？
  2. 混合精度训练有哪些优势？
  3. 分布式训练如何加速？
  4. 如何减少显存占用？
  5. 训练最佳实践有哪些？

价值：为倒排/关键词索引与recall-oriented 召回提供更多可命中的查询面。

3.6 索引扩展

离散索引扩展：使用关键词抽取、实体识别等技术生成离散索引，与向量检索互补，提升召回准确性。
连续索引扩展：结合多种向量模型（如 OpenAI 的 Ada、智源的 BGE）进行多路召回，取长补短。
混合索引召回：将 BM25 等离散索引与向量索引结合，通过 Ensemble Retriever 实现混合召回，提升多样性。

3.6.1 离散索引

使用关键词抽取、实体识别等技术生成离散索引，与向量检索互补，提升召回准确性。

关键词抽取
- 方法：从文档中提取重要关键词，作为离散索引的一部分，用于补充向量检索的不足。
- 文档内容：
  本文介绍了深度学习模型训练中的优化技巧，包括：
  1. 使用 AdamW 优化器替代传统的 SGD。
  2. 采用混合精度训练，减少显存占用。
  3. 使用分布式训练技术加速大规模模型的训练。
- 关键词抽取结果（如 TF-IDF、TextRank）：["深度学习", "模型训练", "优化技巧", "AdamW", "混合精度训练", "分布式训练"]
- 应用场景：当用户查询“如何优化深度学习模型训练？”时，离散索引中的关键词能够快速匹配到相关文档。
实体识别
- 方法：从文档中识别命名实体（如人名、地点、组织等），作为离散索引的一部分，增强检索的精确性。
- 文档内容：2023 年诺贝尔物理学奖授予了三位科学家，以表彰他们在量子纠缠领域的研究成果。
- 实体识别结果（如 SpaCy、BERT-based NER）：["2023年", "诺贝尔物理学奖", "量子纠缠"]
- 应用场景：当用户查询“2023 年诺贝尔物理学奖的获奖者是谁？”时，离散索引中的实体能够快速匹配到相关文档。

3.6.2 混合索引召回

将离散索引（如关键词、实体）与向量索引结合，通过混合召回策略提升检索效果。

文档内容：
本文介绍了人工智能在医疗领域的应用，包括：
1. 使用深度学习技术进行医学影像分析。
2. 利用自然语言处理技术提取电子病历中的关键信息。
3. 开发智能诊断系统辅助医生决策。
关键词抽取：["人工智能", "医疗领域", "深度学习", "医学影像分析", "自然语言处理", "电子病历", "智能诊断系统"]
实体识别：["人工智能", "医疗领域", "深度学习", "自然语言处理"]

应用场景：
当用户查询“人工智能在医疗领域的应用有哪些？”时：

离散索引通过关键词和实体匹配到相关文档。
向量索引通过语义相似度匹配到相关文档。
综合两种召回结果，提升检索的准确性和覆盖率。

3.6.3 Small-to-Big

Small-to-Big 索引策略：一种高效的检索方法，特别适用于长文档或多文档场景。
核心思想：先用小规模内容（摘要、关键句）建立索引，并链接到大规模内容主体中。
优势：快速定位相关内容，并在需要时获取完整上下文，提升检索效率和答案的逻辑连贯性。

小规模内容（索引部分）
- 摘要（从论文中提取）：
  - 摘要 1：本文介绍了 Transformer 模型在机器翻译任务中的应用，并提出了改进的注意力机制。
  - 摘要 2：本文探讨了 Transformer 模型在文本生成任务中的性能，并与 RNN 模型进行了对比。
- 关键句（与查询相关）：
  - 关键句 1：Transformer 模型通过自注意力机制实现了高效的并行计算。
  - 关键句 2：BERT 是基于 Transformer 的预训练模型，在多项 NLP 任务中取得了显著效果。
大规模内容（链接部分）
- 论文 1：链接到完整的 PDF 文档，包含详细的实验和结果。
- 论文 2：链接到完整的 PDF 文档，包含模型架构和性能分析。
Small-to-Big 机制流程
1. 小规模内容检索：用户查询后，先在小规模内容（摘要、关键句、段落）中检索匹配项。这些小规模内容是通过摘要生成、关键句提取等技术从大规模内容中提取的。
2. 链接到大规模内容：当找到匹配的小规模内容后，系统通过文档 ID、URL 等链接找到对应的大规模内容（全文），获取更详细的上下文。
3. 上下文补充：将大规模内容作为 RAG 系统的上下文输入，结合用户查询和小规模内容，生成更准确、连贯的答案。

4. Qwen-Agent 构建 RAG

4.1 基本介绍

Qwen-Agent 是一个基于通义千问（Qwen）模型的开发框架，充分利用其在指令遵循、工具调用、规划、记忆等方面的能力。

Qwen-Agent 支持的模型接入形式包括：

DashScope 服务：直接调用通义千问官方提供的模型服务。
OpenAI API 兼容模式：通过 OpenAI API 接口方式接入开源的 Qwen 模型。
GitHub 项目地址

4.2 扩展上下文记忆至百万量级（Qwen-Agent）

随着大型语言模型（LLMs）向支持百万字级上下文发展，一个上下文仅有 8K token 的模型，如何处理 1M token 的长上下文？

可参考以下方法进行数据与模型准备：

构建强力智能体：使用一个上下文长度为 8K 的聊天模型，构建一个能处理百万级上下文的智能体。
生成与筛选微调数据：利用该智能体合成微调数据，并进行自动化质量过滤，确保数据准确与有效。
微调预训练模型：使用筛选后的合成数据对预训练模型进行微调，最终获得一个能高效处理 1M 上下文的强大聊天模型。

4.3 构建智能体

Qwen-Agent 构建的智能体包含三个复杂度级别，每一层都建立在前一层的基础上。

4.3.1 Level-1：检索

处理 100 万字上下文的一种朴素方法是采用 RAG：先将上下文切分为不超过 512 字的块，然后只保留最相关的块装入 8K 字的上下文窗口。关键挑战是如何精准定位最相关的块。一种基于关键词的方案步骤如下：

分离“信息”与“指令”：指导聊天模型将用户查询中的指令信息与非指令信息分开。。
原查询：回答时请用 2000 字详尽阐述，我的问题是，自行车是什么时候发明的？请用英文回复。
拆分后：{"信息": ["自行车是什么时候发明的"], "指令": ["回答时用2000字", "尽量详尽", "用英文回复"]}
从“信息”中推导多语言关键词：要求聊天模型从查询的信息部分推导出多语言关键词。
- 例如，短语 "自行车是什么时候发明的" 会转换为 {"关键词_英文": ["bicycles", "invented", "when"], "关键词_中文": ["自行车", "发明", "时间"]}
BM25 关键词检索：使用 BM25 基于上述关键词检索最相关的文档块，入选到 8K 上下文中。

参考代码（RAG）：https://github.com/QwenLM/Qwen-Agent/blob/main/examples/assistant_rag.py

4.3.2 Level-2：分块检索

Level-1 常在相关块与用户查询关键词重叠程度不足时失效，导致这些相关的块未被检索到、没有提供给模型。尽管理论上向量检索可以缓解这一问题，但实际上效果有限。为了解决这个局限，我们采用了一种暴力策略来减少错过相关上下文的几率：

块级相关性判定（并行）：对每个 512 字块，请模型判断其与用户查询是否相关
- 不相关输出 "无"
- 相关则输出相关句子（而非整段）这些块会被并行处理以避免长时间等待。
用相关句子二次检索（BM25）：将所有非“无”的相关句子作为查询词，用 BM25 检索出最相关的块（总上下文长度控制在 8K 内）。
生成答案：基于检索到的上下文执行常规 RAG 生成流程。

参考代码（并行分块 QA）

4.3.3 Level-3：逐步推理

文档问答常见难点是多跳推理。

例如回答：“与《第五交响曲》创作于同一世纪的交通工具是什么？”
需要先回答子问题：“《第五交响曲》创作于哪个世纪？”→ 19 世纪，
再联想到：“自行车于 19 世纪发明”，最终合题作答。
思路：使用具有问题分解与逐步推理能力的工具调用（函数调用）智能体 / ReAct 智能体。将 Level-2 智能体封装为一个“工具”，由 Level-3 智能体按需调用，进行多跳检索与归纳。

流程伪代码

向 Lv3-智能体 提出一个问题
while Lv3-智能体 仅凭当前记忆仍无法作答:
    1) Lv3-智能体 拆出一个新的子问题
    2) Lv3-智能体 调用 Lv2-智能体 工具，向其提问该子问题
    3) 将 Lv2-智能体 的回答写入 Lv3-智能体 的记忆
Lv3-智能体 输出原问题的最终答案

例如: 
1. Lv3-智能体 最初向 Lv2-智能体 提出子问题：“贝多芬的第五交响曲是在哪个世纪创作的？  
2. 收到“19世纪”的回复后，Lv3-智能体 提出新的子问题：“19世纪期间发明了什么交通工具？”  
3. 通过整合 Lv2-智能体 的所有反馈，Lv3-智能体 便能够回答原始问题：“与第五交响曲创作于同一世纪的交通工具是什么？”

4.4 RAG 评测结果

在两个针对 256k 上下文 设计的基准测试中，我们对不同方案进行了对比实验：

测试基准
1. NeedleBench
  - 测试模型在大量无关句子中找到最相关句子的能力（“大海捞针”场景）。
  - 有时需要同时找到多根“针”并进行多跳推理。
2. LV-Eval
  - 要求模型同时理解多个证据片段。
  - 原版评估指标过于严苛，容易产生假阴性，因此我们进行了指标调整。
对比方法
- 32k-模型
  - 7B 对话模型，主要在 8k 上下文样本上微调，并辅助使用少量 32k 样本。
  - 通过 RoPE 外推 扩展到 256k，无需额外训练。
- 4k-RAG
  - 与 32k-模型相同的底层模型，采用 Lv1 智能体的 RAG 策略。
  - 只检索并处理最相关的 4k 上下文。
- 4k-智能体
  - 同样基于 32k-模型，但使用更复杂的智能体策略（前述 Lv2/Lv3 机制）。
  - 可并行处理多个片段，但单次调用模型时上下文不超过 4k。
实验结论
1. 短上下文场景：
  - 4k-RAG 可能不如 32k-模型表现好，原因可能在于 RAG 检索未覆盖关键信息或难以整合多个片段。
2. 长上下文场景
  - 随着文档长度增加，4k-RAG 表现逐渐超过 32k-模型。
  - 表明 32k-模型在长上下文训练上并未达到最佳。
3. 4k-智能体的优势
  - 始终优于 32k-模型和 4k-RAG。
  - 分块阅读与多轮检索策略帮助其克服长上下文训练不足的限制。
4. 理论 vs 实际
  - 理论上经过充分训练的 32k-模型应优于其他方案。
  - 实际上，由于训练不足，其表现不及 4k-智能体。
额外压力测试
- 在 100 万字词的超长文本中（极端“大海捞针”场景），4k-智能体依然可以正常运行并找到目标信息。

5. RAG 质量评估

在完成一个 RAG 系统的开发后，需要对其性能进行系统评估。 RAG 的产出可以分为三类信息：

question：用户提出的问题（Query）
context：检索器返回的相关文档
answer：生成器（LLM）基于 context 输出的答案

评估时应将 question、context、answer 结合起来进行分析，才能全面反映系统的质量。

5.1 RAG 三元组

RAG 的标准流程：

用户提出 Query
RAG 检索器召回 Context
LLM 基于 Context 生成 Response

由此形成三元组：Query – Context – Response 它们之间两两相互牵制，任何一环质量不佳都会影响最终结果。
关键评估指标
- Context Relevance（上下文相关性）：衡量召回的 Context 对 Query 的支持程度。
  - 分数低 → 检索器召回了大量无关内容，可能误导 LLM 生成答案。
- Groundedness（答案依赖度）：衡量 LLM 的 Response 与 Context 的一致程度。
  - 分数低 → LLM 的回答未依赖召回知识，增加幻觉（Hallucination）风险。
- Answer Relevance（答案相关性）：衡量 Response 对 Query 的直接相关程度。
  - 分数低 → 答案可能偏题或不完整。

5.2 Ragas 评估

5.2.1 什么是 Ragas 评估

Ragas（Retrieval-Augmented Generation Assessment）是一个用于快速评估 RAG 系统性能的框架。Ragas 官方网站
评估所需信息包括：

question：用户输入的问题
answer：RAG 系统生成的答案（由 LLM 给出）
contexts：根据问题检索到的相关文档
ground_truths：人类提供的真实正确答案（唯一需要人工提供的部分）

5.2.2 评估指标

Ragas 提供五种评估指标：

忠实度（Faithfulness）：衡量生成的答案与给定上下文事实的一致性（取值范围 0~1，越高越好）。
- 步骤：
  - 从答案中提取事实性声明（claims）
  - 检查每个 claim 是否能从上下文推断
- 示例：
  - 问题（question）：爱因斯坦出生于何时何地？
  - 上下文（context）：阿尔伯特·爱因斯坦（Albert Einstein，1879 年 3 月 14 日出生）是一位出生于德国的理论物理学家，被广泛认为是有史以来最伟大和最有影响力的科学家之一。
  - 高忠实度答案：爱因斯坦 1879 年 3 月 14 日出生于德国。
  - 低忠实度答案：爱因斯坦于 1879 年 3 月 20 日出生于德国。
- 公式：

忠 实 度 得 分 = \frac{上 下 文 推 导 出 的 陈 述 数 量}{生 成 答 案 中 的 总 陈 述 数 量}

答案相关性（Answer Relevancy）：衡量答案与问题的相关程度（取值范围 0~1，越高越好）。
- 惩罚不完整或冗余答案
- 计算方法：
  - 用 LLM 从答案生成多个可能问题
  - 计算这些问题与原问题的平均余弦相似度
- 示例：
  - 问题（question）：法国在哪里，首都是哪里？
  - 低相关性答案：法国位于西欧。
  - 高相关性答案：法国位于西欧，巴黎是其首都。
上下文精度（Context Precision）：衡量检索到的上下文中，相关内容在排序中靠前的比例（取值范围 0~1）。
- 理想状态：所有相关文档块都出现在前列
- 示例：

\begin{aligned} 上 下 文 精 度 @ k & = \frac{\sum 精 度 @ k}{前 K 个 结 果 中 相 关 项 的 总 数} \\ 精 度 @ k & = \frac{前 k 个 结 果 中 的 真 阳 性}{前 k 个 结 果 中 的 真 阳 性 + 前 k 个 结 果 中 的 假 阳 性} \end{aligned}

其中，k 是 contexts 中返回的 chunks 数量。

上下文召回率（Context Recall）：衡量检索到的上下文与真实答案的一致程度（取值范围 0~1）。
- 方法：判断真实答案的每个句子是否可归因于检索到的上下文
- 示例：
  - 问题（question）：法国在哪里，首都是哪里？
  - 基本事实（Ground truth）：法国位于西欧，其首都是巴黎。
  - 高上下文召回率（High context recall）：法国位于西欧，拥有中世纪城市、高山村庄和地中海海滩。其首都巴黎以其时装屋、卢浮宫等古典艺术博物馆和埃菲尔铁塔等古迹而闻名。
  - 低上下文召回率（Low context recall）：法国位于西欧，拥有中世纪城市、高山村庄和地中海海滩。该国还以其葡萄酒和精致的美食闻名。拉斯科的古代洞穴壁画、里昂的罗马剧院和宏伟的凡尔赛宫都证明了其丰富的历史。
- 公式：

上 下 文 召 回 率 = \frac{可归因于上下文的基本事实句子数}{基本事实中的句子总数}

上下文相关性（Context Relevancy）：衡量检索到的上下文与问题的相关性（取值范围 0~1）。
- 方法：
  - 统计上下文中与解答问题相关的句子数 |S|
  - 计算相关句子在整体上下文中的占比
- 示例：
  - 问题（question）：法国的首都是哪里？
  - 高上下文相关性（High context relevancy）：法国位于西欧，拥有中世纪城市、高山村庄和地中海海滩。其首都巴黎以其时装屋、卢浮宫等古典艺术博物馆和埃菲尔铁塔等古迹而闻名。
  - 低上下文相关性（Low context relevancy）：西欧的法国包括中世纪城市、高山村庄和地中海海滩。其首都巴黎以其时装屋、卢浮宫等古典艺术博物馆和埃菲尔铁塔等古迹而闻名。该国还以其葡萄酒和精致的美食闻名。拉斯科的古代洞穴壁画、里昂的罗马剧院和宏伟的凡尔赛宫都证明了其丰富的历史。
- 公式：

上 下 文 相 关 性 = \frac{相 关 句 子 数 量}{检 索 到 的 上 下 文 总 句 子 数}

5.3. Ragas 评估实操

5.3.1. 父文档检索器（Parent Document Retriever）

在传统文档检索中，常用 CharacterTextSplitter 或 RecursiveCharacterTextSplitter 将文档按指定 chunk_size 均匀切割成文档块（chunks），对每个文档块进行向量化（Embedding），存储到向量数据库。检索时，将用户问题转为向量，与数据库中的文档块向量计算相似度，取前 K 个最相似的文档块，与用户问题一起送入 LLM 生成答案。

1. 传统方法的局限性：

文档块过大：向量可能无法准确反映文档块的全部内容 → 匹配度降低
文档块过小：向量匹配度更高，但包含的信息不足 → 答案可能不全面

2. 父文档检索器的优势：

在满足小块 Embedding 精准匹配与大块上下文保留信息的双重需求间找到平衡
LangChain的父子文档检索器提供两种策略：
1. 检索完整文档
2. 检索较大的文档块

5.3.2. 检索完整文档

流程：
1. 将原始文档均匀切割成较小文档块
2. 将小块与用户问题进行匹配
3. 找到匹配的小块后，取其所在原始文档的全部内容
4. 将原始文档和用户问题送入 LLM，由 LLM 生成最终答案
优点：
- 保证检索匹配的精度
- 同时利用完整文档的信息，答案更全面

5.3.3. 检索较大的文档块

适用于原始文档非常大的情况，采用两级切割：
1. 将原始文档先切割成 主文档块（Parent Chunk）
2. 再将每个主文档块切割成 子文档块（Child Chunk）
3. 用户问题与所有子文档块进行匹配
4. 匹配到某个子文档块后，将其所属的主文档块全部内容与用户问题一并送入 LLM
5. LLM 根据主文档块生成最终答案
优点：
- 保留更大范围的上下文
- 避免因单个小块信息不足导致答案不完整

6. 商业落地实施 RAG 工程的核心步骤

数据集准备（语料）
- 文档结构化处理：采用现代智能文档技术进行格式化与解析
- 目标：保证数据可被高效检索与处理
测试集准备（QA 对）
- 使用主流 LLM 模型，根据文档自动生成 问答对（QA Pairs）
- 测试集用于验证 RAG 系统在实际问答场景下的表现
技术选型（常见的 RAG 实现路径）
1. Native RAG：传统检索增强生成模式
2. Graph RAG：结合知识图谱的结构化检索
3. Agentic RAG：引入智能 Agent 进行多轮推理与工具调用
构建知识库
- 将结构化语料进行向量化处理并存入向量数据库
- 建立高效的检索与索引机制
测试与优化（针对不同阶段进行迭代优化）
- 数据预处理与结构化处理
- 切片（Chunking）策略调整
- 检索（召回）策略优化
- 重排序（Reranking）策略优化
- 引入 RAFT 等高级优化技术
最终效果评估
- 使用 Ragas 框架评估 RAG 性能
- 核心指标：忠实度、答案相关性、上下文精度、上下文召回率、上下文相关性
生产环境部署
- 部署方案可选择 本地模型推理（如 vLLM）
- 确保低延迟、高吞吐量，并支持扩展