RAG高级技术与调优RAG 调优的本质是：先把知识治理好，再让检索召回更全、排序更准、生成更受约束，最后通过评测和版本管

来源：用户上传 PDF《1-RAG高级技术与调优.pdf》 + 官方/公开资料联网补充
生成时间：2026-05-16
适用对象：RAG 应用开发、企业知识库问答、AI Agent/RAG 后端工程落地

1. 总体结论

这份课程的核心不是讲“RAG 是什么”，而是讲 RAG 如何从 Demo 走向可用、可评估、可持续优化的工程系统。

RAG 可以拆成三个主链路：

Indexing：知识如何更好地存起来
包括文档解析、切片、问题生成、对话沉淀、版本管理、健康度检查。
Retrieval：如何从海量知识中找到真正有用的部分
包括 MultiQuery、Query Rewrite、BM25、向量检索、混合检索、Rerank、Small-to-Big。
Generation：如何基于检索结果生成可靠答案
包括上下文拼接、引用来源、提示词约束、结果校验、Agent 多步检索与多跳推理。

一句话总结：

高质量 RAG = 高质量知识库 + 高召回检索 + 精排重排序 + 可评估闭环 + 可维护版本体系。

2. RAG调优总览图

flowchart LR
    A[用户问题] --> B[查询理解/改写]
    B --> B1[MultiQuery 多查询]
    B --> B2[Query2Doc 查询扩展]
    B --> B3[关键词/实体抽取]

    B1 --> C[多路召回]
    B2 --> C
    B3 --> C

    C --> C1[BM25 关键词检索]
    C --> C2[Vector 向量检索]
    C --> C3[Doc2Query 问题索引]
    C --> C4[GraphRAG 图谱检索]

    C1 --> D[融合排序]
    C2 --> D
    C3 --> D
    C4 --> D

    D --> E[Rerank 精排]
    E --> F[Top-K 上下文构建]
    F --> G[LLM生成答案]
    G --> H[引用/校验/反馈]
    H --> I[评估与知识库优化]
    I --> C

3. PDF课程核心内容梳理

3.1 坚实地基：知识库处理

课程把知识库处理拆成 4 个典型场景：

场景	目标	关键做法	适合解决的问题
知识库问题生成与检索优化	缓解用户问题与原文切片不匹配	为每个知识切片生成多个可能问题，并建立问题索引	用户问法口语化、原文表达偏书面化
对话知识沉淀	从线上问答中持续提炼知识	从对话中抽取事实、流程、注意事项，并合并去重	产品上线后不断补充知识库
知识库健康度检查	找出缺失、过期、冲突知识	完整性、时效性、一致性评分	避免知识库越用越乱
知识库版本管理与性能比较	支持上线前验收和回归测试	版本快照、MD5、差异比较、评测集回归	知识库升级可控、可回滚

3.1.1 知识库问题生成：Doc2Query 思路

课程中给出的核心思路是：

当用户问题和知识切片原文相似度不高时，可以用 AI 为每个知识切片生成“可能被用户问到的问题”，再让用户问题和生成问题匹配。

示例逻辑：

原始知识切片：
上海迪士尼乐园位于上海市浦东新区，是中国大陆首座迪士尼主题乐园……

生成问题：
1. 上海迪士尼乐园是什么时候开园的？
2. 中国大陆第一座迪士尼乐园在哪里？
3. 上海迪士尼乐园占地多少公顷？
4. 如果想游览所有主题园区，需要了解哪些区域？

课程示例中，BM25 原文检索准确率为 66.7%，基于生成问题的 BM25 检索准确率提升到 100%。这说明在某些语义不直接匹配的场景中，问题索引可以显著改善召回效果。

工程建议

在企业知识库中，可以设计两套索引：

document_index       原文切片索引
question_index       生成问题索引

每个问题索引需要反向关联原始 chunk：

{
  "question": "客户经理被投诉一次扣多少分？",
  "chunk_id": "chunk_001",
  "question_type": "直接问",
  "difficulty": "简单",
  "source": "llm_generated"
}

查询时可以：

先查问题索引；
再查原文索引；
合并去重；
进入 Rerank。

3.2 对话知识沉淀

课程提出：产品上线后，每天会产生大量用户对话，可以从这些对话中提取长期有效的知识，持续丰富知识库。

核心流程：

flowchart LR
    A[线上对话日志] --> B[LLM结构化抽取]
    B --> C[知识分类]
    C --> D[过滤临时信息]
    D --> E[相似知识合并]
    E --> F[人工审核]
    F --> G[写入知识库]

可沉淀的知识类型

类型	示例	是否建议入库
事实	门票价格、规则、开放时间	可以，但要标注有效期
流程	如何申请、如何操作、如何办理	强烈建议
注意事项	禁止事项、风险提示	强烈建议
用户需求	“用户想了解门票”	一般不入知识库
用户问题	“停车费多少？”	可以作为 FAQ 候选，不直接作为事实知识

课程中特别强调：需求和问题往往是临时的、个性化的，不应直接作为知识沉淀。更合理的做法是把它们作为 FAQ 候选，再由审核流程决定是否入库。

企业落地建议

推荐建立 knowledge_candidate 表，用于存放待审核知识：

字段	说明
id	候选知识ID
content	抽取后的知识内容
knowledge_type	事实 / 流程 / 注意 / FAQ
confidence	LLM置信度
source_conversation_id	来源对话ID
status	pending / approved / rejected
reviewer	审核人
effective_time	生效时间
expire_time	过期时间

3.3 知识库健康度检查

知识库长期运行后，最大问题不是“没有知识”，而是：

有些知识缺失；
有些知识过期；
有些知识彼此冲突；
有些知识无人维护；
有些知识无法覆盖高频问题。

课程提出三类检查：

检查项	目标	示例
完整性检查	是否覆盖用户主要问题	用户问“有什么特别活动”，知识库没有活动信息
时效性检查	是否过期	价格、版本、政策、活动时间过期
一致性检查	是否冲突	两个切片给出不同价格或不同营业时间

推荐指标：

知识库健康度 = 完整性得分 × 0.4 + 时效性得分 × 0.3 + 一致性得分 × 0.3

建议的巡检任务

巡检任务	频率	说明
高频问题覆盖率检查	每日	根据用户真实问题统计未命中问题
过期知识检查	每周	检查价格、政策、活动、版本信息
冲突知识检查	每周	同主题、同实体、同规则聚合比对
回归测试集执行	每次上线前	防止知识库升级导致旧问题失效

3.4 知识库版本管理与性能比较

课程中强调：知识库也应该像代码一样有版本管理。

推荐版本元数据：

{
  "version": "kb-v2026.05.16",
  "description": "新增支付退款相关FAQ，修复订单状态机说明",
  "chunk_count": 1250,
  "avg_chunk_length": 480,
  "content_hash": "md5...",
  "created_by": "admin",
  "created_at": "2026-05-16 10:00:00"
}

版本比较重点：

比较项	说明
新增切片	新增了哪些知识
删除切片	删除了哪些知识
修改切片	内容是否变更
分类分布	是否某类知识异常增多或减少
检索准确率	同一测试集下命中率是否提升
平均响应时间	性能是否下降
回归通过率	历史问题是否仍能答对

课程示例中，增强版知识库相比基础版准确率从 60% 提升到 100%，但平均响应时间略有增加。这个例子说明：

知识库优化不能只看准确率，也要看响应时间、成本、稳定性和回归通过率。

4. 精准雷达：高效召回

4.1 增大 Top-K 只是最粗糙的方法

最简单的提升召回方式是：

docs = knowledgeBase.similarity_search(query, k=10)

但 Top-K 变大有明显副作用：

噪声增加；
上下文更长；
LLM 成本更高；
答案更容易被无关内容干扰。

所以生产系统一般采用：

粗召回 Top 20~50 -> Rerank 精排 -> 最终 Top 3~5

4.2 MultiQuery：多查询扩展

MultiQuery 的核心是让 LLM 从不同角度改写用户问题。

例如：

原始问题：客户经理被投诉了，投诉一次扣多少分？

改写问题：
1. 客户经理投诉扣分标准是什么？
2. 银行客户经理被投诉一次会扣多少绩效分？
3. 金融机构客户经理投诉处罚机制是什么？

这样可以缓解用户问题和文档表达之间的“词汇鸿沟”。

适用场景

场景	是否适合 MultiQuery
用户问题口语化	适合
文档表达正式、法规化	适合
复杂问题包含多个子意图	适合
精确数字查询	谨慎使用，可能引入噪声

联网资料补充：LangChain 的 MultiQueryRetriever 就是通过 LLM 生成多个等价查询，并对每个查询分别检索后合并结果，用来缓解单一向量距离检索的局限。

4.3 Hybrid Search：BM25 + Vector

课程重点讲了混合检索：

BM25：适合关键词、专有名词、数字、法规条款等精确匹配；
Vector：适合同义词、语义相近、口语化表达；
Hybrid Search：把两者结果融合，兼顾精确匹配和语义理解。

推荐流程：

flowchart LR
    A[用户查询] --> B1[BM25检索]
    A --> B2[向量检索]
    B1 --> C[分数归一化]
    B2 --> C
    C --> D[加权融合]
    D --> E[候选Top-K]
    E --> F[Rerank精排]

课程中给出的融合公式：

Score_hybrid = α × Score_vector + (1 - α) × Score_BM25

参数建议：

alpha	检索倾向	适用场景
0.0	纯 BM25	专业术语、精确条款、数字查询
0.3	偏关键词	法规、制度、技术文档
0.5	平衡	通用默认值
0.7	偏语义	口语化问题、模糊查询
1.0	纯向量	表达多样、同义词丰富场景

联网资料补充：Qdrant 官方文档也强调，混合检索常用于融合 dense vectors 和 sparse vectors，以同时获得语义理解和精确词匹配能力；它支持 RRF、DBSF 等融合方式，还支持先粗召回再重评分的多阶段查询。

4.4 Rerank：为什么有 Embedding 还要重排序

Embedding 检索通常是 Bi-Encoder 思路：

Query -> 向量
Document -> 向量
相似度计算 -> Top-K

它速度快，但 Query 和 Document 的深度交互不足。

Rerank 通常是 Cross-Encoder 思路：

(Query, Document) -> 模型一起编码 -> 相关性分数

它速度慢，但相关性判断更精细。

因此典型结构是：

Embedding/BM25 粗召回 20~50 条
        ↓
Rerank 精排
        ↓
最终取 3~5 条给 LLM

BGE-Rerank 与 Cohere Rerank 对比

维度	BGE-Rerank	Cohere Rerank
类型	开源模型	商业 API
部署	可本地部署	云端调用
数据隐私	更适合私有化	需要传输到外部 API
中文支持	中文/英文表现较好	多语言支持较好
成本	机器资源成本	API 调用成本
推荐场景	企业私有知识库、内网部署	快速集成、多语言场景

联网资料补充：BGE 官方文档说明，Reranker 与 Embedding 模型不同，它直接以问题和文档作为输入输出相似度，常见用法是先用 embedding 召回 top 100，再用 reranker 重排得到最终 top 3。

4.5 Query2Doc 与 Doc2Query

课程提到“双向改写”：

方法	说明	解决问题
Query2Doc	把短查询扩展成一段更完整的“假设答案/文档”	用户问题太短，向量信息不足
Doc2Query	为文档生成可能问题	文档表达和用户问法不一致

示例

用户查询：如何提高深度学习模型的训练效率？

Query2Doc 扩展：
提高训练效率可以从优化器、混合精度、分布式训练、数据预处理、学习率调度等方面入手……

这类方法适合技术文档、政策制度、问法多样的 FAQ 场景。

4.6 Small-to-Big：小索引，大上下文

Small-to-Big 的核心思想：

用小粒度内容建索引，用大粒度内容做上下文。

例如：

小粒度索引：标题、摘要、关键句、段落
大粒度上下文：完整章节、完整文档、父级 chunk

流程：

flowchart LR
    A[用户问题] --> B[检索小粒度索引]
    B --> C[命中摘要/关键句]
    C --> D[定位父文档/父chunk]
    D --> E[读取更完整上下文]
    E --> F[LLM生成答案]

适合场景：

长 PDF；
多文档问答；
合同/制度/规范文档；
需要上下文连续性的问答。

5. GraphRAG：全局视野下的结构化RAG

5.1 GraphRAG解决什么问题

传统 RAG 主要依赖向量相似度，适合回答“局部事实问题”。但当问题需要跨文档综合、实体关系推理、全局主题总结时，普通向量检索容易失败。

GraphRAG 的核心是：

先用 LLM 从原始文本中抽取实体、关系、主张，构建知识图谱；再对图谱进行社区聚类和社区摘要；查询时根据问题选择全局搜索或局部搜索。

适合问题：

问题类型	普通 RAG	GraphRAG
某条规则是什么	可以	可以
某个人/实体和哪些对象有关	一般	更适合
多篇文档的主题是什么	较弱	更适合
需要跨片段串联关系	较弱	更适合
需要宏观总结	较弱	更适合

5.2 GraphRAG索引流程

课程中总结的 GraphRAG 索引流程如下：

flowchart TD
    A[原始文档] --> B[切分 TextUnits]
    B --> C[LLM抽取实体/关系/主张]
    C --> D[实体合并与关系合并]
    D --> E[社区发现 Leiden]
    E --> F[社区摘要 Community Reports]
    F --> G[图谱增强 Node2Vec/UMAP]
    G --> H[GraphRAG索引完成]

关键对象：

对象	说明
Document	原始文档
TextUnit	文档切片
Entity	实体，如人、地点、组织、概念
Relationship	实体之间的关系
Claim / Covariate	主张或附加事实
Community Report	社区摘要
Node	图谱节点

5.3 GraphRAG查询模式

GraphRAG 常见两种查询方式：

模式	适用问题	数据来源	成本
Global Search	全局性、总结性、主题性问题	社区报告	高
Local Search	特定实体、局部关系、事实型问题	实体、关系、TextUnit、社区报告	中高

Global Search

用于回答宏观问题，例如：

《三国演义》的主要主题是什么？
整个知识库中关于风险控制的核心观点有哪些？

它通常基于社区报告，采用类似 Map-Reduce 的方式：

Map：对多个社区报告生成中间响应；
Rank：给中间观点打分；
Reduce：聚合高价值观点；
Generate：生成最终答案。

Local Search

用于回答具体实体问题，例如：

关羽战胜过哪些武将？
某个客户经理考核指标和哪些扣分项有关？

它会先识别相关实体，再扩展实体邻居、关系、TextUnit 和社区报告。

联网资料补充：微软 GraphRAG 官方文档也把 Query Engine 分为 Local Search、Global Search、DRIFT Search、Basic Search 和 Question Generation。其中 Local Search 会把知识图谱中的结构化数据与原文文本块结合进上下文；Global Search 则会基于 AI 生成的社区报告，以 Map-Reduce 方式生成答案。

6. Qwen Agent中的RAG

课程最后提到智能决策：Qwen Agent 中的 RAG。联网资料显示，Qwen-Agent 已提供内置 RAG 能力：

支持 PDF、Word、PPT、TXT、CSV、Excel、HTML 等多种格式；
默认使用 BM25 进行关键词检索；
支持文档切块；
支持基于 LLM 的关键词生成；
可以在 Assistant Agent 中自动启用 RAG；
可通过 pip install "qwen-agent[rag]" 安装 RAG 依赖。

这说明 Qwen Agent 的默认 RAG 更偏轻量级、关键词检索优先，适合快速构建文档问答；如果要做企业级高质量 RAG，建议补充向量索引、混合检索、Rerank、评测闭环和知识库版本管理。

7. 企业级RAG落地架构建议

7.1 推荐整体架构

flowchart TD
    A[文件/网页/数据库/对话日志] --> B[文档解析层]
    B --> C[切片与元数据处理]
    C --> D[知识增强]
    D --> D1[Doc2Query]
    D --> D2[摘要生成]
    D --> D3[实体/关键词抽取]

    D1 --> E[索引层]
    D2 --> E
    D3 --> E
    C --> E

    E --> E1[BM25/ES/OpenSearch]
    E --> E2[向量库 FAISS/Milvus/Qdrant/pgvector]
    E --> E3[图数据库 Neo4j/GraphRAG]

    F[用户问题] --> G[查询理解]
    G --> H[多路召回]
    H --> E1
    H --> E2
    H --> E3

    E1 --> I[候选合并去重]
    E2 --> I
    E3 --> I
    I --> J[Rerank精排]
    J --> K[上下文构建]
    K --> L[LLM生成]
    L --> M[引用与答案校验]
    M --> N[日志/反馈/评估]
    N --> O[知识库持续优化]

7.2 Java后端工程分层建议

rag-service
├── api                         # Controller / OpenAPI
├── application                 # 应用服务：入库、检索、问答、评估
├── domain                      # 知识库、切片、版本、评测集领域模型
├── infrastructure
│   ├── parser                  # PDF/Word/HTML解析
│   ├── embedding               # 向量模型调用
│   ├── vectorstore             # Milvus/Qdrant/pgvector/FAISS适配
│   ├── keyword                 # BM25/ES/OpenSearch
│   ├── rerank                  # BGE-Rerank/Cohere适配
│   ├── llm                     # Qwen/OpenAI/DeepSeek模型适配
│   └── graph                   # GraphRAG/Neo4j适配
├── job                         # 定时健康检查、版本回归测试
└── common                      # 异常、日志、幂等、限流

8. 推荐数据库表设计

8.1 知识文档表 `rag_document`

字段	类型	说明
id	bigint	主键
doc_name	varchar	文档名称
doc_type	varchar	PDF/Word/HTML等
source_type	varchar	upload/url/db/conversation
source_uri	varchar	来源地址
version_id	bigint	所属知识库版本
status	varchar	parsing/indexed/failed
created_at	datetime	创建时间

8.2 知识切片表 `rag_chunk`

字段	类型	说明
id	bigint	主键
doc_id	bigint	文档ID
chunk_no	int	切片序号
content	text	切片内容
summary	text	切片摘要
metadata	json	页码、标题、章节等
content_hash	varchar	内容哈希
created_at	datetime	创建时间

8.3 生成问题表 `rag_chunk_question`

字段	类型	说明
id	bigint	主键
chunk_id	bigint	关联切片
question	varchar	生成问题
question_type	varchar	直接问/间接问/推理问等
difficulty	varchar	简单/中等/困难
source	varchar	llm/manual

8.4 知识库版本表 `rag_kb_version`

字段	类型	说明
id	bigint	主键
version_code	varchar	版本号
description	varchar	版本说明
chunk_count	int	切片数量
content_hash	varchar	版本哈希
status	varchar	draft/testing/online/rollback
created_at	datetime	创建时间

8.5 检索评测表 `rag_eval_case`

字段	类型	说明
id	bigint	主键
question	varchar	测试问题
expected_answer	text	期望答案
expected_chunk_ids	json	期望命中切片
category	varchar	分类
enabled	boolean	是否启用

9. RAG调优参数速查表

参数	建议值	调优方向
chunk_size	300~800 tokens	事实型问答偏小，章节总结偏大
chunk_overlap	50~150 tokens	解决上下文断裂，过大会增加重复
rough_top_k	20~50	粗召回候选数，越大越慢
final_top_k	3~5	给 LLM 的最终上下文数
hybrid_alpha	0.3~0.7	专业文档偏 BM25，口语问答偏向量
rerank_max_length	512/1024	长文档需分段，避免截断关键信息
min_score_threshold	按评测集确定	防止低相关内容进入上下文
eval_frequency	每次发版前	必须回归测试

10. 生产级RAG评估指标

指标	说明	关注点
Recall@K	期望答案是否出现在前K个召回结果中	召回能力
MRR	正确答案排得是否靠前	排序质量
Hit Rate	是否命中任一相关文档	初步可用性
Faithfulness	答案是否忠于上下文	防幻觉
Answer Relevance	答案是否回答用户问题	生成质量
Latency	平均响应时间 / P95 / P99	性能
Cost	每次问答 token/API/GPU 成本	成本控制
Regression Pass Rate	历史测试集通过率	发版稳定性

11. 推荐落地路线

阶段1：基础RAG可用

文档上传；
文档解析；
切片；
Embedding；
向量检索；
LLM 基于上下文回答；
返回引用来源。

阶段2：召回增强

MultiQuery；
BM25 + Vector 混合检索；
Doc2Query 问题索引；
Rerank 精排；
Top-K 参数调优。

阶段3：知识库治理

对话知识沉淀；
健康度检查；
过期知识提醒；
冲突知识检测；
知识库版本管理；
回归测试集。

阶段4：高级RAG

Small-to-Big；
Parent-Child Chunking；
GraphRAG；
Agentic RAG；
多跳推理；
多源知识融合。

12. 常见问题与调优判断

Q1：有了 Embedding，为什么还要 BM25？

因为 Embedding 擅长语义相似，但对精确词、数字、编号、专有名词、制度条款不一定稳定。BM25 对这些精确匹配更强。

Q2：有了 Embedding，为什么还要 Rerank？

Embedding 是快速粗召回，Rerank 是慢速精排。Embedding 只比较向量距离，Rerank 会让 Query 和 Document 深度交互，因此相关性判断更准。

Q3：什么时候上 GraphRAG？

当你的问题经常涉及：

多文档综合；
实体关系；
全局主题；
跨片段推理；
“A 和 B 有什么关系”；
“整个知识库反映了什么趋势”。

这时 GraphRAG 比普通向量 RAG 更合适。

Q4：为什么检索到了文档，答案还是错？

可能原因：

Top-K 中相关文档排名太靠后；
上下文太长，LLM 忽略关键片段；
切片把关键上下文切断了；
Rerank 缺失；
Prompt 没约束“只基于资料回答”；
知识库自身过期或冲突。

13. 最佳实践清单

14. 联网资料补充来源

以下资料用于补充 PDF 课程内容，主要参考官方或公开文档：

LangChain MultiQueryRetriever Reference
说明 MultiQueryRetriever 支持基于用户输入生成多个查询，并对每个查询执行检索。
Microsoft GraphRAG - Query Engine Overview
说明 GraphRAG Query Engine 包含 Local Search、Global Search、DRIFT Search、Basic Search 和 Question Generation。
Microsoft GraphRAG - Local Search
说明 Local Search 会结合知识图谱结构化数据与原始文档文本块来构建回答上下文。
Qdrant Hybrid and Multi-Stage Queries
说明 dense/sparse 向量融合、RRF、DBSF 以及多阶段检索/重评分策略。
BGE-Reranker Documentation
说明 BGE-Reranker 使用 Query + Document 作为输入输出相关性分数，常用于对初步召回结果进行重排序。
Qwen-Agent RAG Documentation
说明 Qwen-Agent 内置 RAG 能力，支持多种文档格式，默认使用 BM25 做关键词检索，并支持关键词生成。

15. 一句话复盘

RAG 调优的本质是：先把知识治理好，再让检索召回更全、排序更准、生成更受约束，最后通过评测和版本管理形成持续迭代闭环。

RAG高级技术与调优