RAG 系统上线时，向量数据库应选择实时增量更新还是离线批量刷新？本地部署架构如何搭建，并如何评估检索与生成效果？｜中科闻歌算法面经解析

60 秒回答模板

向量数据库更新方式要看知识变化频率和一致性要求。实时增量适合文档频繁变化、用户希望马上可搜的场景，优点是新鲜，缺点是分片写入、索引碎片、去重、删除、权限同步和质量校验更复杂。离线批量刷新适合知识相对稳定、质量要求高的场景，优点是可离线清洗、重切片、重算 embedding、统一评测和原子切换，缺点是有刷新延迟。生产上常用混合策略：增量先进入小索引或 delta collection，定期离线合并成主索引，并通过版本号支持回滚。本地部署架构可以包括文档接入、解析、切片、embedding 服务、向量库、元数据/权限库、检索服务、reranker、LLM 推理服务、答案生成、引用校验、日志评测和管理后台。要考虑 GPU/CPU 资源、模型量化、缓存、并发、鉴权、租户隔离和数据脱敏。评估分两段：检索看 Recall@K、MRR、nDCG、命中证据、权限过滤正确率和延迟；生成看答案正确性、引用覆盖、忠实度、拒答率、幻觉率、人工满意度和端到端成本。上线前需要黄金问答集、难例集、灰度、回滚和持续反馈闭环。

考点 实时增量新鲜但复杂，离线批刷稳定但有延迟

难度 真实面经题

回答目标 让候选人能设计一个可上线的 RAG 系统，兼顾向量库更新策略、本地部署架构和检索生成效果评估。

深入解析

更新策略

实时增量追求新鲜度，离线批刷追求质量和一致性。选择取决于知识变化频率、用户时效要求、索引构建成本和错误回滚成本。

混合索引

常见方案是主索引批量构建，增量索引承接新文档，查询时合并结果。定期 compact 或 merge，并用索引版本实现原子切换和回滚。

本地架构

组件包括文档解析、chunking、embedding、向量库、元数据权限、检索、rerank、LLM、引用生成、日志和评测。每个组件都要能独立观测和降级。

权限与删除

RAG 常见风险是用户搜到无权文档或已删除文档。权限过滤要和 metadata 强绑定，删除要处理向量、原文、缓存和增量索引的一致性。

检索评估

检索看 Recall@K、MRR、nDCG、证据命中、重复 chunk、权限过滤、查询改写收益和检索延迟。只看向量相似度不足以说明可用。

生成评估

生成看答案正确性、引用忠实度、幻觉率、拒答率、格式遵循、人工采纳和端到端成本。检索和生成要联合分析，定位是没搜到还是搜到了没用好。

易错点

只说实时更新更好，不考虑索引碎片、质量校验和回滚。
只讲向量库，不讲文档解析、权限、rerank 和生成。
删除文档只删元数据，向量和缓存仍可能被检索到。
评估只看人工感觉，不建黄金问答和难例集。
没有区分检索失败和生成失败。
本地部署不考虑资源、并发、鉴权和数据脱敏。

面试官追问

文档更新后旧向量怎么处理？

要用文档版本和 chunk id 标识，删除或标记旧 chunk，同时清理缓存和增量索引。批量重建时通过新索引版本原子切换，避免新旧混杂。

本地部署为什么还要 reranker？

向量召回可能拿到语义相近但不精确的 chunk。reranker 在小候选上做细粒度相关性排序，能提高引用证据质量，但会增加延迟，需要按预算控制候选数。

如何判断 RAG 失败原因？

先看正确证据是否在 TopK；如果没有，是解析、切片、embedding 或查询改写问题；如果有但答案错，是 rerank、上下文拼接或生成忠实度问题。

离线批刷期间如何保证服务可用？

新索引在旁路构建和评测，通过版本号灰度切换；旧索引继续服务。切换失败可回滚到旧版本，避免构建过程影响线上查询。