知识库做到一定规模后全量重建会变成一件负担。每次同步都重新解析所有文档耗时、耗算力还会覆盖人工修订过的条目。更麻烦的是去重同一份内容在网盘、邮件附件、共享盘里各存一份文件名不同、修改时间不同靠路径判断根本认不出来。这篇文章给一个可落地的增量方案抽取正文、归一化、算内容哈希、按哈希比对只处理真正变了的内容。一、先定义「内容变没变」不能拿文件修改时间当判据。复制、下载、解压都会刷新时间戳但内容没变。也不能只比文件大小改一个字大小可能不变。可靠的做法是对正文做归一化后求哈希。归一化包含四步统一换行、压缩连续空白、统一全角半角、去掉页眉页脚这类版式噪声。归一化之后同一份内容无论从哪种格式导出哈希都应当一致。下面是一段 Node 实现依赖内置模块不需要额外安装const crypto require(crypto); function normalize(text) { return text .replace(/\r\n?/g, \n) .replace(/[\u3000\s]/g, ) .replace(/[\uFF01-\uFF5E]/g, ch String.fromCharCode(ch.charCodeAt(0) - 0xFEE0)) .trim(); } function contentHash(text) { return crypto.createHash(sha256) .update(normalize(text), utf8) .digest(hex); }归一化之后再做全文哈希可以从根上识别「换个文件名但内容相同」的副本。二、再区分「改了一点」与「换了内容」全文哈希能判断相等却判断不了相似。一份文档只改了一个段落全文哈希全变按「变了就重建」处理等于每次都重建。这里要再加一层段落级指纹。把正文按空行切成块对每块求哈希用集合比较。function blockFingerprints(text) { return new Set( normalize(text) .split(/\n{2,}/) .map(b b.trim()) .filter(b b.length 20) .map(b contentHash(b)) ); } function diffRatio(oldText, newText) { const a blockFingerprints(oldText); const b blockFingerprints(newText); let same 0; for (const h of b) if (a.has(h)) same; return 1 - same / Math.max(b.size, 1); }diffRatio小于 0.2 视为局部修订只更新变动的段落大于 0.6 视为新文档整篇重建。中间区间进入人工复核队列避免误判。三、同步流程的五个状态增量同步的关键不是算法而是状态管理。每条内容在库里应当有明确状态流程才能断点续跑。| 状态 | 含义 | 进入条件 | 后续动作 ||---|---|---|---|| new | 新发现 | 哈希不在索引 | 解析并入库 || changed | 内容变更 | 哈希存在但全文不同 | 按差异比例分流 || same | 未变化 | 全文哈希一致 | 跳过 || missing | 来源消失 | 扫描不到源文件 | 标记待确认不直接删 || conflict | 多源冲突 | 同标题不同哈希 | 人工复核 |missing不要直接删。源文件消失可能是网盘同步延迟也可能是权限变更导致的读不到。直接删会造成知识库缺口而且很难恢复。四、索引表怎么设计索引表至少要存五列内容哈希、来源路径、最近扫描时间、状态、版本号。哈希作为主键一个哈希对应多条来源路径这样天然支持多源去重。版本号用来支持回滚。每次内容变更生成一个新版本旧版本保留但标记失效。回填到问答系统时只取有效版本历史版本仍可追溯。CREATE TABLE kb_index ( hash TEXT PRIMARY KEY, paths TEXT NOT NULL, status TEXT NOT NULL, version INTEGER NOT NULL DEFAULT 1, scanned_at TEXT NOT NULL );索引与正文分表存储。正文放在对象存储或文件系统索引只存元数据扫描与比对都走索引速度会快很多。五、两个容易忽略的边界一是编码。老文档常见 GBK 与 UTF-8 混用读进来先探测编码再解码否则同一份内容会算出两个哈希。Node 侧可以用iconv-litePython 侧用chardet加codecs。二是表格与图片。表格里的信息很多但归一化时容易被压成一行导致不同表格算出相同哈希。建议表格单独抽取为结构化文本再参与哈希图片则只记录引用不参与内容比对。做到这一步增量同步的准确率基本可控。剩下的工作是定期跑一次全量校验确认索引与正文一致。增量解决效率全量解决正确性两者不能互相替代。本文由一支长期做企业内容系统的技术团队整理欢迎同行交流指正。
