01

60 秒回答模板

RAG 知识库维护不是简单定期重建向量库，而是一套知识生命周期流程：先接入权威数据源，做去重、清洗、权限和版本管理；再按文档结构切分，保留标题、章节、时间、来源、权限等元数据；更新时支持增量索引、过期清理、冲突检测和回滚；上线后用检索召回率、命中片段质量、答案引用正确率、用户 badcase 来评估。RAG 和 SFT 的选择上，我会按知识变化频率和目标能力区分：如果问题依赖外部知识、更新频繁、需要引用和可追溯，优先 RAG；如果要改变模型稳定行为、风格、格式遵循或领域推理模式，才考虑 SFT。实际工程里常见组合是 RAG 负责知识注入，SFT 或提示词负责回答格式和工具使用习惯。

考点 知识生命周期
难度 真实面经题
回答目标 讲清知识维护和方案取舍
02

深入解析

01

知识库维护的对象不是只有向量

RAG 知识库包括原始文档、清洗后的文本块、元数据、embedding、索引、权限和评测集。维护时不能只看向量库有没有更新，还要保证知识来源可信、文本版本清楚、过期内容能下线、不同用户只检索到自己有权限的内容。

02

定期维护要覆盖增量、过期和冲突

一个合理流程是定期扫描数据源，识别新增、修改、删除和过期文档。新增文档进入清洗和切分；修改文档要重新生成相关 chunk 和 embedding；删除或过期文档要从索引中移除或打不可见标记；同一知识多版本冲突时，要按发布时间、权威来源或业务优先级决定召回策略。

03

切分和元数据决定后续可维护性

切分不能只按固定 token 长度切开。应该尽量保留标题、章节、表格说明、FAQ 问答对、发布时间、文档来源和权限范围。这样后续检索可以做过滤、排序、引用展示和问题追踪。没有元数据的向量库很难解释为什么答错，也很难做局部修复。

04

维护效果要用检索和答案双层指标看

底层看检索质量，比如 top-k 是否召回正确 chunk、相似度分布是否异常、重复 chunk 是否过多。上层看答案质量，比如回答是否基于引用、是否答非所问、是否使用过期知识、用户是否继续追问或点踩。只看 embedding 构建成功或接口可用，不能证明 RAG 维护有效。

05

RAG 适合动态知识，SFT 适合稳定能力

当问题依赖公司制度、产品文档、价格、接口说明、知识库 FAQ 等经常变化的信息，RAG 更合适，因为它可更新、可引用、可回滚。SFT 更适合让模型学会稳定输出格式、领域表达习惯、工具调用范式或特定任务策略，但不适合频繁灌入事实知识，否则更新成本高且难追溯。

06

真实系统常用 RAG 与 SFT 组合

不是所有场景都二选一。可以用 RAG 提供最新事实，用 prompt 或 SFT 约束回答结构和拒答边界，再用评测集持续比较命中率、事实正确率和用户满意度。面试中好的回答是先说明选择原则，再说明维护流程和评估闭环。

03

易错点

  • 把定期维护说成“重新跑 embedding”，漏掉数据源、元数据、权限和过期治理。
  • 只比较 RAG 和 SFT 的概念定义，没有给出选择标准。
  • 认为 SFT 可以解决所有知识更新问题，忽略模型参数中的事实难以删除和追踪。
  • 只看检索相似度，不看最终答案是否引用正确证据。
  • 没有考虑知识冲突、多版本和权限隔离，工程可落地性不足。
  • 把 RAG 回答错误全部归因于模型，忽略切分、召回、重排和上下文拼接问题。
04

面试官追问

知识库更新后如何避免旧答案继续出现？

要删除或失效旧 chunk，刷新相关 embedding 和索引，并在召回阶段用版本、时间和可见状态过滤。还要用回归用例验证旧知识不再被引用。

什么时候 RAG 不适合？

如果任务主要是固定格式生成、分类、风格迁移或稳定决策策略，而不是查外部知识，RAG 的检索链路会增加延迟和不确定性，此时更适合 prompt、SFT 或规则。

如何发现知识库切分有问题？

看 badcase 中是否经常召回半截段落、缺上下文、表格语义丢失、多个 chunk 才能回答却只召回一个。也可以用标注问题检查 top-k 召回是否命中完整证据。

RAG 的评测集怎么构造？

从真实用户问题、业务高频 FAQ、历史 badcase 和关键文档变更点抽样，标注标准答案和证据片段，同时覆盖找得到、找不到、过期知识和权限受限问题。

SFT 能不能替代知识库？

一般不建议把频繁变化的事实知识固化到 SFT 里。SFT 更新慢、难追溯、难删除；知识需要可审计和可更新时，RAG 更稳。