项目记录：给资讯流做一次去重，我把标题相似度阈值调到多少

问题

每天从几个渠道收 AI 资讯，同一件事会被转载三四次，标题各改一点：有的加“刚刚”，有的换成疑问句，有的把公司名提前。结果一份清单里，真正的新事件只有一半，剩下都是同一条的变体。人工挑费时间，不挑又影响后面写简报。

于是做了一次很小的去重实验，目标不是“自动写稿”，只是把同一事件的条目合并成一条。

设计

没用复杂模型，就三层：

1. 时间窗：只比较 48 小时内到达的条目。超出窗口的一律不合并，避免把“发布”和“后续更新”误判成重复。
2. 标题相似度：去掉停用词和常见修饰词（“刚刚”“重磅”“一文看懂”），再算相似度。
3. 来源字段：合并时保留全部来源链接，不删除任何一条原始记录。

第 3 点是我最坚持的。去重的目的是让清单变短，不是让证据变少。合并后的一条里，来源链接列成一行，反而更方便复核。这套“先聚合、再标注来源”的思路，跟 万象云档按主题聚合文档 的做法其实是同一个道理。

阈值怎么定

拿过去两周的 120 条真实条目做样本，人工标出哪些该合并，然后试了三个值：

最后停在 0.86，但加了一条补救规则：标题相似度在 0.80–0.86 之间、且包含同一产品名或版本号的，标为“疑似重复”，交人工看一眼。这一层把漏合并的 5 条捞回来 4 条。

一个没预料到的收获

误合并的那 2 条，原因不是算法，是标题写得实在太像。顺着这个发现，我改了资讯卡的字段：强制加一个“事件类型”（发布 / 更新 / 合作 / 传闻）。有了类型，即便标题雷同也不会并错。这比继续调阈值有效得多。

用 WorkBuddy 跑这套比对和汇总很省事，官方文档 里关于任务编排的部分可以配合看，不过真正起作用的还是字段设计——工具只是把规则稳定地执行了一遍。

复盘

阈值不是关键，“合并后保留来源”和“补一个结构化字段”才是。前者保证可追溯，后者从源头减少歧义。如果只盯着把数字调得更准，大概率会陷进无止境的调参里。这份去重规则现在跑了两周，每天省下大约二十分钟，且没有再出现把两条不同消息并成一条的事故。