# 项目记录：给资讯流做一次去重，我把标题相似度阈值调到多少 ## 问题 每天从几个渠道收 AI 资讯，同一件事会被转载三四次，标题各改一点：有的加“刚刚”，有的换成疑问句，有的把公司名提前。结果一份清单里，真正的新事件只有一半，剩下都是同一条的变体。人工挑费时间，不挑又影响后面写简报。 于是做了一次很小的去重实验，目标不是“自动写稿”，只是**把同一事件的条目合并成一条**。 ## 设计 没用复杂模型，就三层： 1. **时间窗**：只比较 48 小时内到达的条目。超出窗口的一律不合并，避免把“发布”和“后续更新”误判成重复。 2. **标题相似度**：去掉停用词和常见修饰词（“刚刚”“重磅”“一文看懂”），再算相似度。 3. **来源字段**：合并时保留全部来源链接，不删除任何一条原始记录。 第 3 点是我最坚持的。去重的目的是让清单变短，不是让证据变少。合并后的一条里，来源链接列成一行，反而更方便复核。这套“先聚合、再标注来源”的思路，跟 [万象云档按主题聚合文档](https://www.wanxiangyundang.top/) 的做法其实是同一个道理。 ## 阈值怎么定 拿过去两周的 120 条真实条目做样本，人工标出哪些该合并，然后试了三个值： | 阈值 | 结果 | | --- | --- | | 0.80 | 合并太狠，把两款不同产品的更新并成一条 | | 0.92 | 太保守，同一事件换个标题就漏过去 | | 0.86 | 误合并 2 条、漏合并 5 条，可接受 | 最后停在 0.86，但加了一条补救规则：**标题相似度在 0.80–0.86 之间、且包含同一产品名或版本号的，标为“疑似重复”，交人工看一眼**。这一层把漏合并的 5 条捞回来 4 条。 ## 一个没预料到的收获 误合并的那 2 条，原因不是算法，是标题写得实在太像。顺着这个发现，我改了资讯卡的字段：强制加一个“事件类型”（发布 / 更新 / 合作 / 传闻）。有了类型，即便标题雷同也不会并错。这比继续调阈值有效得多。 用 WorkBuddy 跑这套比对和汇总很省事，[官方文档](https://www.workbuddy.cn/docs/workbuddy/Overview) 里关于任务编排的部分可以配合看，不过真正起作用的还是字段设计——工具只是把规则稳定地执行了一遍。 ## 复盘 阈值不是关键，**“合并后保留来源”和“补一个结构化字段”才是**。前者保证可追溯，后者从源头减少歧义。如果只盯着把数字调得更准，大概率会陷进无止境的调参里。这份去重规则现在跑了两周，每天省下大约二十分钟，且没有再出现把两条不同消息并成一条的事故。