RAG 知识库变更感知：人工重建、定时比对与 Webhook 增量（MewHelp 实战·口播版）
面试高频问题：知识库里的文档规则变了，你怎么感知？什么时候更新向量库？ 一句话答案：分三级做法 —— ①人工全量重建（改完跑
make kb-build && make kb-vectorize，知识量小就是几分钟的事）；②定时任务比对文件修改时间或 hash，变了触发重建；③企业文档系统 Webhook 事件驱动增量更新。mewhelp 选第一种，够用；文档多了再考虑目录化组织与自动化。 项目背景：mewhelp 电商智能客服（Milvus + 混合检索，知识库来自data/kb/*.md） 适用面次：二面深度（RAG 工程化 / 运维闭环） 本版定位：口语应答脚本 —— 先给「开口就能说」的话术，再给速记要点。
【30 秒极简版】（面试官随口一问时用）
知识库更新我按三级答：最简单是人工全量重建 —— 文档改完跑一次
make kb-build && make kb-vectorize，知识量不大时几分钟搞定；再自动化一点，文档放固定目录或 CMS，定时任务比对修改时间或 hash，变了就触发重建；再进一步，企业文档系统（比如飞书文档）有 Webhook，文档一改就推事件过来，收事件做增量更新。 mewhelp 选的是第一种，因为这个知识量全量重建够快、也最不容易出错；文档多起来才需要往目录化和自动化演进。
【2 分钟完整口播】（正式被问到时的主干回答）
这题本质是「RAG 知识库怎么保鲜」—— 文档是活的，向量库是快照，中间的差怎么补。
第一，最简单也最可靠的是人工全量重建。 知识库文档改完，跑一次
make kb-build（切块、写入库）加make kb-vectorize（向量化），推倒重建。知识量不大的话，这就是几分钟的事，而且没有一致性问题 —— 全量重建之后，库里就是文档的完整现状。代价是每次都要人工触发，且随文档量增长耗时会线性上升。第二，自动化一级是定时比对。 文档放在固定目录或者 CMS 里，写个定时任务，比对文件的修改时间或 hash：变了就触发重建，没变就跳过。这里有个取舍 ——
mtime便宜，扫元数据就行，但可能误报（touch一下、拷贝一次时间就变）；hash 准确，但要真读文件内容，成本高一些。知识量中等、变更不频繁的场景，定时 + hash 是很稳的组合。第三，自动化二级是事件驱动增量。 企业内文档系统一般有 Webhook（飞书文档就是典型）：文档一改就推事件过来，收到事件后只更新受影响的那部分，不全量重建。这是生产上最省资源、延迟也最低的做法，但要求文档源本身支持事件、团队也有维护事件管道的能力。
第四，选型原则是按规模和变更频率走，不要为了自动化而自动化。 mewhelp 选第一种，是因为知识量小、变更不频繁，全量重建几分钟就完事，引入定时任务和 Webhook 反而是额外的运维负担。但项目里也做了块级修补：
kb-repatch可以按块 id 就地改指定内容，再跑kb-vectorize只重嵌这几块 —— 改两条规则就不用全量重跑；真需要推倒重来还有kb-reset。所以准确说法是：结构变了走全量重建，局部改动用块级修补，这套在知识库录入页上也有按钮，不依赖命令行。第五，文档一多，先解决组织问题再解决自动化问题。 文档多了以后，检索质量和维护效率首先取决于目录/分类怎么组织（按业务域、按文档类型），否则就算更新做得再及时，检索也分不清该召回哪一类。这是我在项目里踩过之后的判断顺序：先组织、再自动化。
一、速记要点
1. 三级做法对照
| 级别 | 做法 | 触发方式 | 成本 | 适用 |
|---|---|---|---|---|
| ① 人工全量重建 | make kb-build && make kb-vectorize | 人手动触发 | 低（量小几分钟） | 知识量小、变更不频繁 |
| ② 定时比对 | 固定目录 / CMS + 定时任务比对 mtime 或 hash | 时间驱动 | 中 | 中等知识量、可接受延迟 |
| ③ Webhook 增量 | 企业文档系统事件（飞书文档等）→ 只更新受影响部分 | 事件驱动 | 高（要维护事件管道） | 大规模、要求时效 |
2. mtime vs hash
| 判据 | 优点 | 缺点 |
|---|---|---|
| mtime | 便宜，只扫元数据 | 易误报（触碰、拷贝、同步都会改时间） |
| hash | 准确，内容变了才触发 | 要读文件内容，成本更高 |
面试里能说出这个取舍，比只说「定时任务监控文件变化」更像做过工程。
3. MewHelp 的实际做法
| 手段 | 用途 |
|---|---|
make kb-build | 切块 + 写库（建库材料清单与页面预览共用同一份切块实现，预览什么样入库就什么样） |
make kb-vectorize | 向量化；幂等 —— 已嵌过的块会跳过 |
make kb-repatch | 块级就地修补，按块 id 改指定内容（例：同时改价保与无理由退货两块，去掉规则混淆） |
make kb-reset | 推倒重建（结构性变更时用） |
| 页面按钮 | 上述动作在知识库录入页上都有按钮，不依赖命令行 |
一句话概括：结构性变更 → 全量重建；局部规则变更 → 块级修补 + 只重嵌这几块。
4. 追问预案
Q：增量更新会不会和旧数据不一致？
会，所以要保证「先改文档、再重建」的顺序，并且重嵌入按块幂等：同一块重复处理只是覆盖，不会产生重复数据；结构变更（切块规则变了）则必须全量重建，不能只修补。
Q：为什么不一开始就上 Webhook？
因为成本和收益不匹配：知识量小的时候，全量重建几分钟，Webhook 要额外维护事件通道、权限和失败重试，收益不明显。架构跟着规模演进，这也是我在多 Agent 那题里的同一套判断逻辑。
Q：知识库错了会怎样？
RAG 的错误会被模型「自信地放大」—— 检索到旧规则，回答就会按旧规则走。所以知识库更新不是运维小事，是效果底线。
二、露馅点 vs 加分点
- ❌ 只说「定期更新知识库」→ ✅ 给出三级做法 + 触发机制 + 成本取舍
- ❌ 说「改了文档向量库会自动同步」→ ✅ 说清默认是快照，要显式重建/修补
- ❌ 一上来就讲 Webhook 高级方案 → ✅ 先讲按规模选型，小知识量人工全量重建更稳
- ❌ 讲不清增量和全量的边界 → ✅ 说清「结构变 → 全量；内容局部变 → 块级修补 + 重嵌」
- ❌ 回避「课程项目没做自动化」→ ✅ 诚实说「当前选第一种」，再给生产演进路径
三、一句话收尾
知识库更新不是「有没有定时任务」的问题，是按知识量和变更频率选触发方式：小就用人工全量重建，中就用定时比对，大就用 Webhook 增量 —— 顺序是先组织文档，再谈自动化。
关联笔记：12PDF文档RAG工程化-四环节流水线（切块与入库流水线）、13GraphRAG跨文档多跳推理-三层架构与生产防御（增量更新与一致性校验）、18数据飞轮-智能体越用越聪明的底层逻辑（检索 badcase 回流）、09多Agent架构取舍-客服场景为什么不用多Agent（同一套「按规模演进」的判断逻辑）