Appearance
L02-14 增量更新:改一篇文档不用重灌全库
全局中心内容:增量更新的关键是 sourceId + 内容哈希——先判定要不要更新,再决定怎么更新。 全局讲解主线:全量重灌的代价 → 变更检测 → 删除与重灌的顺序 → 版本并存 → 编码 → 一致性校验。
P1 · 产出页
中心内容:一个按 sourceId 做增量同步的管道,未变更文档零开销。
- 讲解技巧
- 开场算账:10 万片段全量重灌 = 多少 Embedding 调用 + 多少钱 + 多久。把数字写在黑板上。
- 然后说:改一个错别字也要付这个钱吗?
- 时长:20s
P2 · 变更检测
中心内容:用内容哈希判断片段是否真的变了。
页面内容:sourceId + contentHash 的比对流程
讲解技巧
- 讲清为什么用哈希而不是 updatedAt:文件时间会被复制、同步、touch 操作改变,极不可靠。
- 讲清哈希粒度:按片段算哈希,不是按文件,这样只有真正变化的片段需要重新 Embedding。
时长:6min
P3 · 删除与重灌的顺序
中心内容:先插新的,再删旧的,中间不能出现空窗。
页面内容:错误顺序(先删后插)导致的检索空窗示意
讲解技巧
- 这是本节最容易出错的工程细节:先删后插,如果在中间查询,会一条都查不到,用户看到「无结果」。
- 正确做法:先写入新版本,再删除旧版本,或用状态字段标记后原子切换。
时长:5min
P4 · 版本并存策略
中心内容:是「替换」还是「共存」取决于业务要不要追溯历史。
- 讲解技巧
- 给判断标准:知识库问答用替换(用户只关心最新政策);合规审计场景用共存(要能回答「三个月前的说法」)。
- 共存时要按 version 或 effectiveDate 过滤,否则检索会同时命中新旧版。
- 时长:5min
P5 · 软删除与孤儿清理
中心内容:源文档删了,库里的片段要能被清理。
页面内容:删除标记 + 定时清理任务
讲解技巧
- 讲「孤儿片段」问题:源文件被移走或重命名,如果不做全量比对,旧片段会永久残留。
- 给出兜底方案:每日一次全量 sourceId 对账,只比对 ID 不重算向量,成本极低。
时长:5min
P6 · 编码:增量管道
中心内容:解析 → 切分 → 哈希比对 → 差异写入 → 记录同步日志。
页面内容:IncrementalIngestor;sync_log 表设计
讲解技巧
- 强调同步日志的价值:出问题时能回答「这篇文档什么时候同步的、写了多少片段、删了多少」。
- 提醒:同步过程要加分布式锁,避免两个任务同时写同一 sourceId。
时长:7min
P7 · 一致性校验
中心内容:同步后要校验「库里片段数 == 源文档切分出的片段数」。
- 讲解技巧
- 给一个简单的自检 SQL:按 sourceId 分组计数,与同步日志比对。
- 强调失败要有告警,静默失败的增量同步比全量重灌更危险。
- 时长:4min
P8 · 避坑与小结
中心内容:切分策略变了,哈希全变,等于触发一次全量更新。
- 讲解技巧
- 这个点经常被忽略:改切分参数会导致所有片段哈希变化,所以要在低峰期做并提前算好成本。
- 引出下一节:高频问题每次都走全流程太贵——02-15 缓存。
- 时长:2min
讲师备忘
| 项 | 内容 |
|---|---|
| 课前必做 | 准备全量重灌成本换算表;准备两份只差一个字的文件 |
| 最容易超时处 | P6 编码,sync_log 设计容易展开 |
| 学员最常问 | 「哈希用什么算法?」答:SHA-256 截断 32 位足够,碰撞概率可忽略 |
| 现场备用 | 无数据库 → 用文件模拟 sync_log 演示比对逻辑 |