增量更新与失效治理是什么
文档会改、会删、会过期，知识库必须配套同步链路。增量更新用内容哈希与文档指纹判断变化：内容没变就不重新切分与向量化，省下大量嵌入成本；文档删除或改版时，先按文档标识删掉旧块再写入新块，避免新旧版本同时躺在索引里互相打架。元数据里写有效期，检索时过滤掉过期内容，再配一个定期巡检任务扫描失效链接与超期文档。只增不删是知识库最常见的腐化来源。
基本信息
| 增量判定 | 按文档内容哈希对比，仅对变化的文档重算 |
|---|---|
| 更新动作 | 按 doc_id 先删旧块再写新块 |
| 删除链路 | 文档下架时同步清除其全部块 |
| 过期治理 | 元数据写有效期，检索时过滤 |
| 巡检任务 | 定期扫描失效链接与超期文档 |
| 主要风险 | 只增不删导致旧制度与旧价格持续被召回 |
典型使用场景
- 制度与价格类文档：新版本发布后旧版本必须及时退出索引
- 文档下架：删除原文后同步清理向量与元数据
- 日常同步：每天扫描变更，只更新有改动的文档
- 链接巡检：发现失效来源并标记停用
- 大批量迁移：重切分时按批次替换，避免索引长时间半成品
按文档标识替换旧块
按文档标识替换旧块
// 1) 先按 doc_id 删除旧块，保证不出现新旧并存
POST /collections/kb/points/delete
{
"filter": {
"must": [
{ "key": "doc_id", "match": { "value": "handbook-v3" } }
]
}
}
// 2) 再写入新切分的块，同一 doc_id，版本号更新
// 3) 删写之间失败要留下任务记录，可重跑而不是靠人工比对变更类型与索引动作
| 变更类型 | 索引侧动作 | 不做的后果 |
|---|---|---|
| 内容修改 | 删除旧块后写入新块 | 新旧版本同时被召回，答案互相矛盾 |
| 文档删除 | 按 doc_id 清除全部块 | 已废止内容继续作为答案来源 |
| 文档过期 | 依赖有效期元数据过滤 | 过期价格与制度持续被引用 |
| 仅元数据变化 | 更新字段而不重算向量 | 按部门或版本过滤失效 |
| 大批量变更 | 按批次限速重建 | 索引短时不可用或触发限流 |
知识库腐化通常不是模型问题：旧版本内容留在索引里，检索会把它们和现行制度一起召回，答案看起来有依据却已经过期。
用内容哈希做增量能把嵌入成本压到只与改动量成正比；全量重算既贵又会让索引在重建期间处于不可用状态。