RAG知识库构建流程详解
文档预处理、分块、Embedding 选型到 Milvus 索引构建
原题：请描述构建RAG系统中知识库的完整流程，包括文档预处理、文本分块、向量嵌入模型选择、向量数据库选型与索引构建等关键步骤。
文档处理 · 美团真题
回答与解析
1. 文档预处理
- 格式解析：PDF用PyMuPDF/MinerU，Word用python-docx，HTML用BeautifulSoup
- 内容清洗：去除页眉页脚、页码、特殊符号；统一编码；处理OCR错误
- 结构保留：提取标题层级、表格结构、段落关系，用于后续语义分块
2. 文本分块策略
| 策略 | 适用场景 | 注意点 |
|---|---|---|
| 固定长度 | 实现简单，参数需评测 | 比较多组 chunk size 与 overlap 候选，验证边界召回和冗余成本 |
| 递归字符 | 按标点/换行逐级切分 | 优先保证句子完整性 |
| 语义分块 | 对连贯性要求高的文档 | 用Embedding相似度判断断点，计算成本较高 |
| 结构感知 | 论文、合同等结构化文档 | 按章节、条款边界切分，保留元数据 |
关键权衡：块太小→语义不完整；块太大→检索噪声高、Embedding稀释
3. Embedding模型选择
- 通用场景：BGE-M3（支持多语言、长文本）、GTE-large
- 英文专用：OpenAI text-embedding-3-large、E5系列
- 领域适配：金融/法律等垂直场景需微调（用领域数据对比学习）
- 长文本：优先选支持8K+上下文的模型，或采用滑动窗口平均
4. 向量数据库选型
| 数据库 | 特点 | 适用 |
|---|---|---|
| Milvus/Zilliz | 功能全、分布式、云原生 | 大规模生产环境 |
| Pinecone | 托管服务、免运维 | 快速上线、中小规模 |
| Weaviate | 混合搜索、GraphQL | 需要关键词+向量混合检索 |
| pgvector | PostgreSQL扩展 | 已有PG基础设施，数据量<100M |
| Faiss | 纯索引库、轻量 | 实验环境、嵌入式部署 |
5. 索引构建与优化
- 索引算法：HNSW（高召回、快查询，内存占用大）vs IVF（省内存、适合十亿级）
- 参数调优：HNSW的
M（连接数，通常16-64）、efConstruction（构建精度） - 增强策略：
- 多向量表示：一个文档存摘要向量+详细内容向量
- 元数据过滤：先按时间/类别过滤再向量检索
- 增量更新：处理新增文档的索引合并策略
学习建议
建议系统学习该知识点
口语版讲法(约4分钟)
- 定位RAG本质：检索增强不是万能药，重点在知识库质量和检索精度
- 文档预处理：格式解析和清洗的坑，尤其OCR和表格
- 分块策略：固定长度加重叠窗口是基础，语义分块成本高但必要
- Embedding与向量数据库选型：通用和垂直场景的取舍，HNSW和IVF的权衡
- 落地风险：元数据过滤和增量更新的常见失败场景
这道题问的是RAG知识库构建，但我觉得面试官真正想听的是：你怎么在检索质量和工程成本之间做取舍。RAG本质上是个检索增强系统，知识库的质量直接决定了最终回答的上限，所以我会把整个流程拆成几个核心环节来讲，重点说每个环节的权衡和落地坑。
先说文档预处理。这一步最容易被低估，但实际踩坑最多。比如PDF解析，用PyMuPDF或者MinerU能搞定大部分，但遇到扫描件就得走OCR，而OCR的错误率直接影响后面检索的准确性。我一般会保留文档的标题层级和表格结构，因为这对后续语义分块特别重要。清洗的时候要小心，页眉页脚、页码这些噪声必须去掉，但别把关键信息也误删了。说白了，预处理的目标是让后续分块和向量化拿到干净的输入。
接下来是文本分块，这是RAG里最关键的工程决策之一。固定长度切分与重叠窗口可以作为候选，但不能直接当成默认答案。我会比较多组 chunk size，以及无重叠、短重叠和较长重叠，在同一评测集验证边界召回、答案质量、索引体积和延迟。但固定长度对结构化文档比如合同或者论文就不够用了，这时候得用结构感知分块，按章节、条款边界来切，同时保留元数据，比如标题、段落号，这样检索时能带上上下文。语义分块听起来更智能，用Embedding相似度找断点，但计算成本高，而且对短文本效果不稳定。我的经验是：通用文本和垂直文档都先看结构与查询类型，再用同一评测集比较固定长度、递归切分和结构感知方案；不能仅凭文档类别断言某一种方案一定更好。这里有个前提：块太小语义不完整，块太大检索噪声高，Embedding会被稀释，所以上线前我会用一批典型query跑一遍，调块大小直到Recall@K稳定。
再聊Embedding模型和向量数据库的选择。通用场景BGE-M3或者GTE-large够用，但如果是英文为主，OpenAI的text-embedding-3-large效果更好。垂直领域比如金融合同或者医疗文档，最好用领域数据微调一下，否则领域术语的语义抓不准。向量数据库这块，HNSW索引是首选，召回高查询快，但内存占用大；如果数据量上亿，我会考虑IVF或者IVF-PQ来省内存。选型上，中小规模用Pinecone快速上线，大规模生产环境上Milvus。但不管选哪个，元数据过滤必须做，比如按时间或类别先过滤再向量检索，能大幅提升精度。
落地时有个常见失败场景：知识库频繁更新，但增量索引没处理好。比如删除操作，如果直接动图索引，召回质量会崩。我的做法是维护一个删除标记，后台异步重建，查询时用双索引合并再按版本过滤。上线前我会用一批固定query做回放，对比Recall@K和延迟，通过才切换，不通过就回滚。
对了，还有一个容易被忽略的点：多向量表示。比如一个文档既存摘要向量又存详细内容向量，检索时先粗筛再细筛，效果会好很多。这其实涉及到检索策略的层次设计，有兴趣我们可以深入聊。
所以整体上，我更倾向把RAG知识库构建看成一套系统工程，每个环节都有明确的边界和取舍。预处理决定下限，分块和Embedding决定上限，向量数据库和索引决定性能。没有银弹，只有针对场景做对权衡。
关键一句:多向量表示：文档存摘要向量和内容向量，先粗筛再细筛，提升检索效率
面试官还可能这样问
- 问法 1 · 场景切入
假设你做一个智能客服，需要从各种手册、PDF里找答案。现在给你一堆杂乱文档，你会怎么处理成知识库？从原始文件到能检索的向量，每个步骤具体做什么？
- 问法 2 · 层层追问
RAG系统的效果很大程度依赖知识库的质量吧？……那你觉得构建知识库的第一步是什么？……清洗完文档后，文本怎么切分更好？……固定大小和按语义切分各有什么优缺点？……选Embedding模型和向量数据库时又得考虑哪些因素？
- 问法 3 · 直球架构
请你完整描述构建RAG知识库的流程，包括文档预处理、文本分块策略、Embedding模型选择、向量数据库选型以及索引构建的关键步骤，每个环节的核心权衡是什么？