RAG知识库构建流程详解

这道题问的是[[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和延迟，通过才切换，不通过就回滚。

对了，还有一个容易被忽略的点：。比如一个文档既存摘要向量又存详细内容向量，检索时先粗筛再细筛，效果会好很多。这其实涉及到检索策略的层次设计，有兴趣我们可以深入聊。