当知识库从几十篇文档扩展到数万、数十万篇时，RAG 系统会面临全新的挑战：检索变慢、召回质量下降、存储成本攀升。曾经在原型阶段表现良好的方案，可能在生产环境中因数据量激增而出现“找不到、找得慢、找不准”的问题。大规模场景下的优化，不再是“把文档灌进去就行”，而是需要在索引构建、检索策略和系统架构上做出有针对性的设计。
16.4.1 分块策略的重新审视
小规模知识库时，固定长度的分块（如 512 个 token）往往就够用。但文档数量庞大后，不合理的分块会成倍放大噪声。
- 语义完整性优先：尽量让每个 chunk 承载一个完整的最小知识单元（如一个条款、一个操作步骤），避免将一个知识点硬切成两半。可以使用段落边界、标题作为自然切分点，必要时引入简单的 NLP 模型进行语义切分。
- 动态调整块大小：根据文档类型差异化设置。例如 FAQ 类文档 chunk 可以较短（单问答对），而技术白皮书可能需要更长的上下文才能理解；可以针对不同来源维护多套切片配置。
- 元数据保留：确保每个 chunk 携带所属文档标题、章节、版本、生效日期等元数据，这不仅为了溯源，更为了后续的过滤和优先级调整。
16.4.2 向量索引的选型与调优
向量数据库是检索的心脏，在大数据量下，索引类型和参数直接影响性能。
- 选择近似近邻（ANN）索引：如 HNSW、IVF 等，在百万到亿级向量规模下，精确搜索已经不可行，必须用 ANN。根据召回率和延迟要求选择算法，HNSW 通常提供较高召回和合理内存占用。
- 索引构建参数：合理设置 HNSW 的
M（每个节点的连接数）和ef_construction，构建时适当增大参数可提升搜索质量，但会增加内存和构建时间；搜索时可通过ef_search动态平衡召回和速度。 - 多索引与分区：当向量数量极大（如超过几百万）时，可以考虑按时间段、文档来源或主题进行分区，查询时根据问题类型路由到特定分区，减少单次扫描范围。
16.4.3 检索流水线的精细化
单一轮次的向量检索在大规模数据下容易遗漏内容，或者被大量相似文档冲淡关键信息。
- 多阶段检索（混合检索）：第一级用轻量方法快速筛选（如基于关键字的 BM25 检索），第二级对候选集再做精确的向量匹配。混合检索能更好地处理专有名词和长尾查询。
- 重排序（Re-ranking）：召回 top-K 后，使用计算量稍大但更准确的模型（如 cross-encoder）对结果重新打分排序，只保留前几篇送入 LLM。这可以在不显著增加整体延迟的情况下，大幅提升最终答案的精确性。
- 查询重写与扩展：对于用户输入的短问题，先在后台做一次“假设性文档生成”或基于 LLM 的查询扩展，补全上下文后再检索，缓解因查询信息不足导致的召回失败。
16.4.4 成本与延迟的控制
大规模知识库意味着每次检索需要扫描更多向量，生成阶段也可能需要塞入更多片段。这两者都会推高 API 调用成本和响应时间。
- 智能裁剪上下文：不要盲目增加
top_k。可以动态根据检索结果的相关性分数设定阈值，仅保留分数高于某值的片段，或者限制总 token 数不超过模型窗口的一定比例。 - 缓存常见问题：对高频查询，可缓存问题-答案对或检索结果，避免重复计算。生产环境中往往有 20% 的问题覆盖 80% 的流量，缓存能显著降低整体成本。
- 分级模型使用：对简单查询可以调用轻量模型生成答案，仅对复杂推理请求使用强模型。在检索阶段也可以先用小嵌入模型快速粗筛，再用大嵌入模型精排。
16.4.5 知识库质量的持续治理
规模一大，知识库很容易成为“信息坟场”：过时文档、重复内容、甚至相互矛盾的规定并存，直接污染回答质量。
- 去重与冲突检测：定期运行文档级别的相似度检查，识别并标记高度重复或矛盾的 chunk，提示运维人员合并或下线旧版本。
- 自动过期与下线：利用元数据中的生效日期或版本号，自动将已失效的文档从活跃索引中剥离（而不是物理删除），回答中避免引用过期信息。
- 反馈闭环：收集用户对回答的反馈（踩赞、纠错），统计高频低分答案所引用的知识片段，反推知识库中需要修订的部分，形成“回答差→溯源文档→修复文档→回答改善”的正向循环。
16.4.6 监控与可观测性
在大规模部署中，不能等到用户投诉才发现检索出了问题。需要建立关键指标监控：
- 检索相关度监控：定期抽样查询，人工评估或使用评估模型判断检索结果是否切题。
- 延迟与吞吐量：监控 P95、P99 检索延迟和 API 调用频率，设阈值告警。
- 知识库新鲜度：统计最近更新时间，当指定目录超过一定天数无更新时自动通知，防止知识老化。
综合运用以上手段，可以将一个面向“万份文档”设计的 RAG 系统平滑扩展至“百万份文档”规模，在保证回答质量的同时，维持可接受的响应速度和运维成本。大规模知识库不是简单的数量堆砌，而是需要从数据组织、检索架构到运维策略的系统性优化。