这道题我觉得本质上不是在问流程,而是在问你怎么在检索质量、存储成本和响应延迟之间做取舍。搭建[[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分析。