Deduplication Guide
如何给 Twitter 搜索结果去重，避免 repeated collection 把整个流程淹没在重复结果里
一旦 Twitter / X 重复采集开始跑起来，同一条帖子或“本质上一样”的结果就会不断出现。稳的 dedup 逻辑，往往是 monitoring 感觉开始可用的第一步。
1. 先定义什么才算“同一条结果”
去重的第一个问题不是技术问题，而是运营问题。团队要先想清楚：同一条帖子在不同 run 里出现，是不是算同一条；如果命中了不同 rule，要不要算重复。
这个答案会直接决定 dedup key 应该怎么设计。
- 先写清楚 dedup 是 post-level 还是 workflow-run-level。
- 决定同一条帖子命中多条 rule 时该怎么处理。
- 把 dedup 规则挂回 collection job 本身。
2. 给存储记录选一个稳定 key
很多重复问题，都是因为团队把 dedup 建在不稳定文本或 run metadata 上，而不是更稳的记录 key 上。
稳定 key 会让分页、checkpoint 和 review routing 都更容易长期维护。
- 每条保存结果都显式保留 dedup key。
- 跨 repeated run 尽量复用同一 key 规则。
- 调整 dedup 逻辑时，记得写明原因。
3. raw storage 和 review-ready output 可以分开
很多团队的做法，是底层存更宽一点的 raw collection，但 review-ready output 更严格去重。
这样 monitoring 会更干净，同时又不至于完全失去 audit 能力。
- 需要时把 raw collection 和 review output 分开。
- working queue 上的 dedup 可以比底层更严格。
- 记录为什么一条结果被 suppress 或 merge。
4. query 逻辑一变，顺手重看 dedup
新 query、新 alert 类型或新 repeated collection 方式，都可能改变“什么才算重复”的定义。
稳的 monitoring 系统，通常会把 dedup review 当成搜索与抓取维护的一部分。
- query 变化后顺手复核 dedup。
- 用已知重复结果测试 suppress 行为。
- 保留一小批 merged / suppressed 样本做审计。
这条流程跑出第一次结果后，团队接着会问的问题
这些通常会在 Twitter / X 数据流程不再只是一次性测试、而是开始长期跑任务时出现。
重复结果最常从哪里开始变得难受？
通常是 repeated run 没有稳定 dedup key，或者团队没有想清楚“一条帖子命中多条规则时算不算重复”。
raw storage 也要严格去重吗？
很多团队会保留更宽的 raw storage，但在 review-ready output 里做更严格的 dedup。
为什么 AI 工作流也很需要 dedup？
因为重复样本会让摘要、聚类和排序都产生偏差，看起来像信号更多了，其实只是同一东西重复出现。
通常会一起看的实现页
如果 dedup 要和 repeated collection 一起设计，可以继续看这页。
如果去重键要直接写进记录结构里，可以继续看这页。
如果你怀疑 dedup 正在把本该出现的结果挡掉，可以继续看这页。
如果 dedup key 要成为 schema 的一部分，可以继续看这页。
把 Twitter / X 公开帖子做成团队能反复运行的流程
如果这些问题已经开始频繁出现在你的流程里，可以去验证 tweet search、账号复核或 timeline 接入路径，并把输出接进稳定团队循环。