RAG 知识库有十几万文档时，如何设计切片、索引、召回和增量更新，避免检索质量与性能下降？｜美团后端开发面经解析

60 秒回答模板

十几万文档的 RAG 我会先把文档处理成可检索的知识单元，再设计混合召回和增量索引。文档侧要解析标题、层级、段落、表格、时间、权限和来源，切片时根据语义边界、标题路径和 overlap 控制粒度，给每个 chunk 加元数据。索引侧通常同时建向量索引和关键词/稀疏索引，召回后做去重、权限过滤、重排和上下文压缩。增量更新要有文档版本、chunk hash、删除 tombstone、异步重建和回滚。质量上用标注 query 集评估 recall@k、MRR、答案命中率和无证据拒答率；性能上关注索引分片、ANN 参数、缓存、批量 embedding 和重排成本。

考点 先保证知识单元质量

难度 真实面经题

回答目标 展示你能把 RAG 从 demo 扩展到大规模知识库，并能同时控制检索质量、更新一致性和系统性能。

深入解析

文档解析

先把 PDF、网页、Markdown、表格和内部文档解析成结构化文本，保留标题层级、章节路径、来源 URL、更新时间、作者、权限和文档类型。RAG 的很多失败来自解析阶段丢表格、丢标题或把导航噪声混进正文。

切片策略

切片要按语义边界和业务查询习惯决定，不是固定每 500 字切一刀。太大导致召回不准、上下文浪费；太小导致信息不完整。常见做法是按章节、段落和标题路径切片，并加适度 overlap 与父文档摘要。

索引设计

大规模知识库通常用混合检索：向量索引负责语义相似，BM25 或稀疏检索负责关键词、专有名词和编号。元数据索引用于权限、时间、业务域和文档类型过滤。向量库要考虑 HNSW/IVF 等 ANN 参数、分片、副本和冷热数据。

召回重排

召回阶段先多路召回足够候选，再做去重、权限过滤和 rerank。重排模型或 cross-encoder 能提升精度，但成本和延迟更高，所以要控制候选数量、缓存热门 query、对简单 query 走轻量路径。

增量更新

文档更新要用版本号和 chunk hash 判断哪些 chunk 需要新增、更新或删除。删除要处理 tombstone，避免旧 chunk 继续被召回。索引构建最好异步化，有状态记录、失败重试和灰度切换，防止半更新状态污染线上检索。

评估优化

质量评估要有真实 query、标准证据和答案验收，指标包括 recall@k、precision@k、MRR、nDCG、答案引用命中率、无证据拒答率。性能优化看 p95 延迟、embedding 吞吐、索引构建耗时、重排耗时和存储成本。

易错点

只说用向量数据库，没有讲解析、切片、元数据和混合检索。
忽略增量更新和删除，导致旧知识继续被召回。
只看答案是否像样，不用 recall@k、证据命中率等指标定位问题。
没有考虑权限过滤、重排成本和 p95 延迟。

面试官追问

chunk 多了以后召回变慢怎么办？

可以用 ANN 索引、分片、副本、元数据预过滤、缓存热门 query、控制 topK 和分层检索。还可以先按业务域或文档类型缩小范围，再做向量召回和重排。

如何避免切片太碎导致答案缺上下文？

保留标题路径、父子 chunk 关系和相邻段落引用。召回到子 chunk 后，可以补充父章节摘要或邻近 chunk，再做上下文压缩，避免只给模型孤立片段。

权限过滤放在向量检索前还是后？

能前置就前置，尤其是租户、部门、文档类型等结构化权限。无法完全前置时，召回后必须二次过滤，并补足候选数量，避免过滤后上下文为空或泄漏无权限内容。

怎么判断 RAG 质量下降是召回问题还是生成问题？

先看检索结果是否包含标准证据。如果 topK 没证据，是解析、切片、索引或召回问题；如果证据存在但答案错，是 prompt、上下文压缩、生成边界或模型能力问题。