领域 RAG 知识库构建

30 秒回答

1. 数据清洗与分块策略设计
2. Embedding模型选型与微调考量
3. 多路召回与重排序的检索架构
4. 大模型Prompt工程与上下文压缩

回答与解析

答案要点

• 数据清洗与分块策略设计
• Embedding模型选型与微调考量
• 多路召回与重排序的检索架构
• 大模型Prompt工程与上下文压缩
• 端到端评估指标与迭代优化闭环

一、数据准备：质量决定天花板

数据清洗

• 去重、去噪、格式标准化（PDF/Word/网页解析）
• 领域术语词典构建，确保专业概念不被错误分词

分块策略（关键！）

• 按语义切分优于固定长度：用BERT-based句子嵌入判断边界
• 领域特性：医学/法律需保留完整条款上下文，代码按函数/类切分
• 块大小与重叠窗口都作为候选变量，用同一评测集比较证据完整率、召回与成本

二、向量化：选型与微调

Embedding模型选择

微调要点：用领域内的(query, doc)正例对+In-batch负采样，提升领域语义对齐

三、检索策略：多路召回+精排

用户Query → 改写/扩展 → 并行召回
            ├── 向量检索（语义相似）
            ├── 关键词检索（BM25，兜底专有名词）
            └── 图谱检索（如有构建实体关系）
                    ↓
            重排序模型（Cross-Encoder/LLM-based）
                    ↓
            Top-K 送入生成模型

关键优化：Query改写（HyDE、伪文档生成）、多向量表示（ColBERT）

四、模型集成与生成

• 上下文压缩：检索结果去冗余，用LLM摘要或选择性上下文
• Prompt设计：明确引用格式要求，强制"不知道就拒绝"
• Citation生成：要求模型标注信息来源，提升可信度

五、效果评估：闭环迭代

持续优化：Bad case分析驱动，定期更新知识库，监控数据漂移

口语版讲法(约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是分块不合理导致的，就回头调分块策略。

另外，当知识库频繁更新时，比如电商每天上架新商品，传统RAG的索引重建成本很高。我倾向用增量更新加双缓冲索引，但一致性校验是个坑，比如旧索引里删了某条数据，新索引还没建好，查询时就会返回过时结果。这块我还在探索更稳定的方案。

所以整体上，我更倾向把RAG看成一套持续迭代的系统，而不是一次搭完就完事。数据质量、检索策略、模型调优，每个环节都要根据业务反馈不断调整。

关键一句:知识库频繁更新时，增量索引的一致性校验是个坑，旧索引可能返回过时结果。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设我们做一个企业内部知识库的问答系统，比如客服部门想查产品文档。用户问“退款流程”，你希望返回准确的段落。能聊聊从原始文档到最后给出答案，你一般会怎么搭建这个流程？

2. 问法 2 · 层层追问

   构建一个专业领域的RAG系统，你会从哪些环节入手？……数据准备阶段，清洗和分块怎么设计？……向量检索和关键词检索怎么配合？最后生成时怎么保证答案准确？

3. 问法 3 · 直球架构

   请描述搭建专业领域RAG系统的完整流程，包括数据准备、向量化、检索策略、模型集成和效果评估。重点说说分块策略、多路召回和评估指标。