完整题目
请描述搭建RAG（Retrieval-Augmented Generation）系统中知识库的主要流程，包括文档预处理、分块、向量化存储及检索索引构建等关键步骤。
本文目录
1. 文档预处理
- 格式解析：用
PyPDF2、python-docx等提取文本，扫描件需OCR（PaddleOCR/EasyOCR） - 清洗去噪：去除页眉页脚、特殊符号、重复内容，保留表格/标题结构信息
- 元数据标注：记录文档来源、章节、时间戳，用于过滤和溯源
2. 文本分块（Chunking）
| 策略 | 特点 | 适用场景 |
|---|---|---|
| 固定长度 | 简单高效，可能切断语义 | 通用场景，追求速度 |
| 递归分块 | 按标点层级分割，保持句子完整 | 大多数文本 |
| 语义分块 | 用模型判断语义边界，块大小不均 | 对连贯性要求高的文档 |
关键权衡：块太小可能缺上下文，块太大可能引入噪声。应把多组 chunk size 与 overlap 组合放进同一评测集，比较召回、答案质量和成本。
3. 向量化与存储
- Embedding选型：中文用
BGE、M3E，多语言用E5、OpenAI text-embedding-3 - 向量数据库：Milvus（大规模）、Qdrant（易用）、Elasticsearch（混合检索方便）
- 索引构建：HNSW（图索引，召回率高）、IVF-PQ（内存友好），根据数据规模和延迟要求选择
4. 检索优化
- 混合检索：向量相似度 + 关键词匹配（BM25），用RRF融合排序
- 查询改写：扩展同义词、纠错，提升召回
- 重排序（Rerank）：用Cross-Encoder精排Top-K结果
学习建议
建议系统学习该知识点
换一种问法，检查是否真正理解
场景切入
假设咱们要给电商客服做个智能问答，需要把商品手册、售后政策这些文档都喂进去。你拿到一堆PDF和Word，第一步会怎么处理？从原始文档到能检索的知识库，关键步骤有哪些？
层层追问
RAG系统里知识库的构建流程你了解吗？……文档进来之后，你是怎么把长文本切成小段的？……切完怎么转成向量存起来？检索的时候怎么保证又快又准？
直球架构
直接说，搭建一个RAG知识库，从文档预处理、分块、向量化到索引构建，整个流程你怎么设计？每个步骤选什么工具或策略？为什么？
练习口述回答 · 约4分钟
- 定位：RAG知识库搭建本质是质量与延迟的平衡
- 预处理：格式解析与元数据，扫描件OCR的坑
- 分块：固定长度与语义切分的适用边界，重叠窗口
- 向量化与索引：Embedding选型、HNSW与IVF-PQ的取舍
- 检索优化：混合检索与重排序，落地风险
这道题我觉得本质上不是在问流程，而是在问你怎么在检索质量、存储成本和响应延迟之间做取舍。搭建[[RAG]]知识库，我一般会按预处理、[[分块]]、[[向量化]]、索引构建、检索优化这几个环节来走，但每个环节都有很多坑，我重点说几个。
先说文档预处理。这一步核心是格式解析和清洗。比如PDF，如果是文本型的，用PyPDF2或者python-docx直接提取就够；但如果是扫描件，那就必须走[[OCR]]，我会用PaddleOCR或者EasyOCR。这里有个坑，OCR识别率不是100%，尤其表格和数字，识别错了直接带偏后续检索。所以我会在清洗阶段保留结构信息，比如标题、表格的边框，同时标注元数据，比如文档来源、章节、时间戳，这样后面检索时可以按时间过滤，也能溯源。
预处理完就是分块，这是最影响检索质量的环节之一。很多人一上来就照搬一个固定长度分块，简单高效，但很容易切断一句话，导致语义不完整。真正落地时我会看场景：如果是客服退款政策这种结构清晰的文档，我倾向于用Chunk递归分块，按句号、换行层级切，尽量保持段落完整；如果是长篇小说或者对话记录，对连贯性要求高，那就得上语义分块，用模型判断语义边界。但语义分块也有代价，块大小不均匀，索引效率低。所以我的取舍是把递归分块、语义分块与多组 chunk size、overlap 组合都作为候选，用同一评测集比较边界召回、答案正确率、索引体积和延迟。参数过小可能缺上下文，过大可能引入噪声，不能脱离数据直接给默认值。
分完块就要向量化。中文Embedding我常用BGE或者M3E，多语言场景用E5。选型上我会优先看它在领域数据上的召回率，而不是盲目追新。存储方面，[[向量数据库]]我选过Milvus和Qdrant。Milvus适合大规模、高并发，但运维成本高；Qdrant上手快，小规模够用。索引构建是性能关键，[[HNSW]]召回率高，但内存消耗大；[[IVF-PQ]]内存友好，但召回率会降。我一般先评估数据量：百万级以内用HNSW，千万级以上用IVF-PQ做量化，再调nprobe参数平衡速度和精度。
最后是检索优化，这里有两个点。一是[[混合检索]]，把向量相似度和关键词匹配（比如[[BM25]]）结合起来，用RRF融合排序。为什么呢？因为向量擅长语义相似，但精确匹配不行，比如订单号、错误码，关键词搜更准。二是[[重排序]]，对Top-K结果用[[Cross-Encoder]]精排，提升最终质量。但重排序有延迟，所以我会控制K值，比如先召回20条，重排后取前5。
其实还有一个方向我没展开，就是知识库更新频繁时，怎么保证索引的实时性和一致性。比如新增文档，直接增量插入；但删除和修改，如果原地动图索引，召回率会崩，我会用软删除加异步重建。
所以整体上，我更倾向把知识库搭建看作一个持续调优的过程，而不是一次性工程。前提是数据质量要过关，如果源文档噪声太大，后面所有环节都会打折扣。常见失败场景就是预处理没做好，导致检索结果一堆垃圾，用户直接弃用。上线后我会特别关注Recall@K和延迟的监控，定期做bad case分析。