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