完整题目
请详细描述搭建专业领域知识RAG系统的完整流程，包括数据准备、向量化处理、检索策略、模型集成和效果评估等关键环节。
本文目录
答案要点
- 数据清洗与分块策略设计
- Embedding模型选型与微调考量
- 多路召回与重排序的检索架构
- 大模型Prompt工程与上下文压缩
- 端到端评估指标与迭代优化闭环
一、数据准备：质量决定天花板
数据清洗
- 去重、去噪、格式标准化（PDF/Word/网页解析）
- 领域术语词典构建，确保专业概念不被错误分词
分块策略（关键！）
- 按语义切分优于固定长度：用BERT-based句子嵌入判断边界
- 领域特性：医学/法律需保留完整条款上下文，代码按函数/类切分
- 块大小与重叠窗口都作为候选变量，用同一评测集比较证据完整率、召回与成本
二、向量化：选型与微调
Embedding模型选择
| 场景 | 推荐方案 |
|---|---|
| 通用领域 | BGE-M3、E5系列 |
| 垂直领域 | 领域语料微调M3-E或自研 |
| 多语言 | 多语言专用模型 |
微调要点：用领域内的(query, doc)正例对+In-batch负采样，提升领域语义对齐
三、检索策略：多路召回+精排
用户Query → 改写/扩展 → 并行召回
├── 向量检索（语义相似）
├── 关键词检索（BM25，兜底专有名词）
└── 图谱检索（如有构建实体关系）
↓
重排序模型（Cross-Encoder/LLM-based）
↓
Top-K 送入生成模型关键优化：Query改写（HyDE、伪文档生成）、多向量表示（ColBERT）
四、模型集成与生成
- 上下文压缩：检索结果去冗余，用LLM摘要或选择性上下文
- Prompt设计：明确引用格式要求，强制"不知道就拒绝"
- Citation生成：要求模型标注信息来源，提升可信度
五、效果评估：闭环迭代
| 层级 | 指标 | 方法 |
|---|---|---|
| 检索 | Recall@K、MRR | 人工标注或合成评测集 |
| 生成 | 忠实度、答案相关性 | LLM-as-Judge（GPT-4/Claude） |
| 端到端 | 用户满意度、任务完成率 | A/B测试、人工评估 |
持续优化：Bad case分析驱动，定期更新知识库，监控数据漂移
换一种问法，检查是否真正理解
场景切入
假设我们做一个企业内部知识库的问答系统，比如客服部门想查产品文档。用户问“退款流程”，你希望返回准确的段落。能聊聊从原始文档到最后给出答案，你一般会怎么搭建这个流程？
层层追问
构建一个专业领域的RAG系统，你会从哪些环节入手？……数据准备阶段，清洗和分块怎么设计？……向量检索和关键词检索怎么配合？最后生成时怎么保证答案准确？
直球架构
请描述搭建专业领域RAG系统的完整流程，包括数据准备、向量化、检索策略、模型集成和效果评估。重点说说分块策略、多路召回和评估指标。
练习口述回答 · 约4分钟
- 一句话定位：RAG本质是查文档+读文档的工程化
- 数据准备：分块是核心难点，语义切分比固定长度好
- 检索策略：混合检索兜底，重排提升精度
- 生成集成：上下文压缩和Prompt防幻觉
- 评估闭环：Bad case驱动迭代
这道题问的是搭建领域[[RAG]]的完整流程，其实本质就是一件事：把外挂知识库里的信息准确找出来，再让大模型读明白、说人话。它不是微调模型学知识，而是查文档加读文档的工程化。
先说数据准备。很多人一上来就[[向量化]]，其实质量天花板在数据清洗和[[分块]]。清洗不难，去重去噪、统一格式就行，但领域数据有个坑：专业术语容易被通用[[分词器]]切碎。比如医学里的“非小细胞肺癌”，拆成“非”“小细胞”“肺癌”就丢语义了。所以前提是建一个领域词典，把这类复合词保留。
分块才是真正的难点。固定长度切分最简单，但容易把一个完整条款砍成两半，比如法律合同里“甲方有权……但乙方除外”，断开后模型就断章取义。我更倾向按语义切分，用BERT-based句子嵌入判断边界，把语义完整的段落保持在一起。块大小与重叠窗口我都会准备多组候选，用同一评测集比较证据完整率、召回、索引体积和去重成本后再定。说白了，分块策略要根据文档类型调，代码按函数切，合同按条款切，没有万能方案。
然后是向量化。Embedding模型选型上，通用场景用BGE-M3或E5就够了，但垂直领域我建议微调。微调不复杂，用领域内的query和doc正例对，加上in-batch负采样，让模型更懂你的语义。不过这里有个风险：如果领域数据量不够，微调反而会过拟合，召回变差。所以我会先拿小样本试一下，不显著提升就不微调，直接用通用模型。
检索策略我走的是多路召回加精排。具体来说，一条路是向量检索，找语义相似的；另一条是关键词检索，用[[BM25]]兜底专有名词，比如订单号或错误码，向量搜不到但关键词一找一个准。两条路的结果合并后，再用一个[[Cross-Encoder]][[重排]]模型精排，把相关性低的过滤掉。这样既保证召回率，又提升精度。你可以这么理解：向量检索像模糊匹配，BM25像精确匹配，两者互补。真正上线时，我会特别关注Query改写，比如用户说“退款没到”，我会用HyDE技术先生成一个伪文档，再拿去检索，效果提升很明显。
生成阶段，核心是上下文压缩和Prompt设计。检索回来的Top-K文档可能有很多冗余，直接全塞进Prompt会稀释关键信息，还浪费token。我会先用LLM做一次摘要，或者只保留和query最相关的片段。Prompt里要明确要求模型引用来源，比如“根据文档第三段……”，并且强制模型说“不知道就拒绝”，不能瞎编。这里有个常见失败场景：模型看到多个相似文档，会把不同条款混在一起，产生[[Hallucination]]。我的对策是让模型先判断文档一致性，不一致就输出“文档冲突，请人工核实”。
最后是效果评估和迭代。我不会只盯着一个指标，而是分三层：检索层看Recall@K和MRR，生成层看[[忠实度]]，端到端看用户满意度。忠实度可以用[[RAGAS]]框架里的Faithfulness指标自动评估，但人工抽检还是少不了。上线后我会建一个Bad case库，每周分析一次，看是检索漏了还是模型读错了，再针对性优化。比如发现很多case是分块不合理导致的，就回头调分块策略。