同一条消息转发十次，不等于十个信号：跨群去重与事件聚类

一张截图在十个群里出现，不代表发生了十次事件；十个人用不同语言描述相似故障，也不能因为文本不同就被当成十件毫无关系的事。

跨群信号发现的核心难题之一，是把“消息数量”还原成“真实事件数量”。如果没有去重与聚类，趋势图会被转发放大，提醒会反复出现，用户很快产生告警疲劳。

三种不同的重复

完全重复

文本、链接或图片完全相同，通常来自直接复制或 Bot 转发。这类内容最容易通过哈希、链接规范化和媒体指纹识别。

近似重复

内容基本相同，但有人修改了标题、增加表情、翻译语言或截取部分段落。需要通过语义相似度和关键实体匹配识别。

同一事件的独立描述

多位用户从不同角度描述同一件事，例如某个平台出现故障。它们不是重复消息，而是能够相互印证的独立证据，应该被合并到同一个事件下，同时保留各自来源。

这三种情况的处理方式不同：完全重复应压缩，近似重复应合并，独立描述则应增加事件可信度。

第一步：规范化消息

比较消息之前，先移除不影响语义的差异：

多余空格、表情和标点；
跟踪参数不同但指向同一页面的链接；
群组自动添加的转发前缀；
引用格式和用户名标记；
大小写、全角半角和常见字符变体。

规范化不能删除时间、金额、地区和产品版本等关键细节，否则不同事件可能被错误合并。

第二步：提取事件特征

事件聚类不能只比较整段文本，还应提取：

涉及的品牌、产品或供应商；
事件类型，如涨价、故障、采购需求或政策变化；
地区、语言和时间；
金额、版本号与其他关键参数；
原始链接、图片或文件指纹；
发言者是在转述还是描述亲身经历。

只有核心实体和事件类型一致，消息才可能属于同一事件。

第三步：设置时间窗口

同一个品牌两个月前和今天发生的故障，不应被合并。

不同事件需要不同窗口：

实时服务故障：数小时；
价格调整：数天到数周；
政策变化：数周；
用户采购需求：通常只在需求有效期内；
长期市场话题：可以按周或月形成趋势主题。

时间窗口太短会拆散同一事件，太长则会把多次独立变化混成一件事。

第四步：建立事件主卡片

聚类后，系统应生成一张事件卡，而不是继续展示几十条相似消息。

事件卡可以包含：

一句话事件摘要；
首次发现和最近更新时间；
总消息数与独立信源数；
覆盖的群组、地区和语言；
代表性原文；
已确认事实与存在分歧的部分；
可信度和行动优先级；
事件状态：新增、发展中、已确认、已解决。

用户既能快速理解事件，也可以展开查看完整证据。

转发量和独立信源必须分开显示

假设一个事件有 60 条相关消息：

48 条来自同一篇文章的转发；
8 条是重复截图；
4 条来自不同用户的亲身反馈。

正确的表达应该是：

共捕获 60 条相关消息，其中 4 个独立信源提供了直接反馈。

而不是“60 个来源确认”。这一区别直接影响趋势判断和可信度评分。

如何判断两个消息属于同一事件

可以采用分层判断：

核心实体是否一致；
事件类型是否一致；
时间与地区是否兼容；
关键细节是否相互冲突；
文本或媒体是否高度相似；
是否指向相同的原始来源。

当系统不确定时，宁可标记“可能相关”，也不要强行合并。错误合并会隐藏重要差异，比多保留一张事件卡更危险。

去重之后才能计算趋势

市场趋势需要观察独立事件和独立参与者的变化，而不是原始消息总量。

例如：

10 个群转发同一条新闻：传播热度高，证据多样性低；
6 个群出现不同用户的实际反馈：传播量较小，信号质量更高；
同一问题连续三周出现新的独立事件：可能代表结构性趋势。

这也是市场趋势信号必须依赖事件聚类的原因。

给用户一个安静的通知体验

事件首次出现时发送提醒；后续只有在独立信源增加、影响范围扩大、状态改变或可信度明显提高时更新。

不要为每一次转发重新通知。用户真正需要知道的是“发生了什么变化”，而不是系统又收到了几条相似消息。

TOP Prospect 如果能够把数百条群聊压缩成少量可追溯事件，就不只是一个消息搜索工具，而会成为帮助团队理解市场变化的情报基础设施。