需要按相关性而非按事件推送
别名: 相关性推送 · 智能通知 · notification relevance · precision recall
概念解释
基于相关性的通知（relevance-based notification）不是每发生一个事件就推送，而是先判断这次变化是否影响某个人的责任、订阅、依赖、当前任务或明确表达过的兴趣，再决定要不要打断、用什么强度打断、什么时候打断。事件发生是一个客观事实，"是否值得打断某个人"是另一项独立的判断，相关性系统要做的正是后者。
机制
事件流天然按生产者组织——谁改了什么、什么时候改的；但接收者关心的是自己下一步要做什么，这两种组织方式并不对齐，相关性过滤本质上是在两者之间架一座桥：把对象关系、角色、期限和用户历史偏好当作过滤条件，判断一条事件落在桥的哪一端。
第二层机制是这座桥必然要面对精确率与召回率的权衡（precision-recall tradeoff）：过滤越激进，被漏放的相关事件（假阴性）越多；过滤越保守，混进来的不相关事件（假阳性）越多，等于没有过滤。这个权衡不能靠调参数一次性解决，因为它对每个用户、每类事件的最优点都不一样——对高风险责任变更，宁可容忍更多假阳性也不能有假阴性；对一般性动态，反过来。更棘手的是漏放事件的不可见性：通知过多时用户至少知道自己被打扰了、可以主动去查；过滤过度导致的漏放却是安静的——用户根本不知道有一条本该看到的事件从未出现，直到后果暴露出来才追溯发现，这比噪声更难被察觉、也更难被纠正，是相关性系统最大的隐藏风险。
怎么研究
- 范式：在同一批真实事件流上并行跑"按事件全推""按订阅推""按角色/依赖相关性推"三套规则，对每条事件人工标注"这个人本该被通知吗"作为基准，计算三套规则各自的精确率、召回率与用户实际行动率。
- 变量：相关性特征集合、推送时机、精确率、召回率、行动率、静默率与"事后发现的漏放"数量。
- 方法论注意点：不能把用户点击当成相关性的代理指标——点击本身会放大既有的注意偏差（越显眼的越容易被点），真正的相关性标注需要结合接收者角色和该事件实际造成的任务后果，而不是互动数据本身。
边界
相关性模型依赖历史关系数据，新成员、罕见风险类型和跨团队边界信息往往缺少这类历史，模型倾向于把"没见过"判断为"不相关"，恰恰在这些场景里假阴性风险最高。过度个性化还有一个更根本的代价：用户会失去"发现"的机会——那些本来不在自己订阅范围内、但读到会有收获的信息永远不会出现在过滤后的视野里，这不是系统出错，而是相关性优化的必然副作用。因此，关键警报类别不能完全交给预测模型兜底，必须保留一条不经过相关性过滤、直接触达的安全通道。
怎么落地
- 让用户能看到"为什么收到这条"，并允许按对象、角色、时段和强度手动调整，把黑箱过滤变成可解释、可纠偏的过滤。
- 把高确定性的责任变更（分配给我的任务、我签字的审批）设为即时直达，一般性动态聚合成摘要，用确定性而不是猜测的相关性来分流。
- 保留一条可检索的完整活动流，作为过滤出错时的兜底；安全关键事件单独走不经过滤的独立提醒通道。
- 验证办法：定期抽样"被过滤掉的事件"人工复核，按角色统计漏放率，检查是否有某类角色（新成员、跨部门协作者）被系统性漏放；把这个漏放率和用户满意度一起作为迭代过滤规则的依据，而不只看用户是否抱怨通知多。