词雷达扫出来的结果噪声偏高 / 先从信源清单里删掉搬运号

词雷达结果噪声高，通常不是分词或词表的问题，而是信源结构的问题：词表决定“扫什么”，信源决定“谁来贡献命中”。当结果里大量词条其实来自转载、搬运、聚合账号时，先动词表只会把搬运号的高频词一起压掉，真正的新词反而被误伤。更稳妥的顺序是：按来源账号聚合结果 → 确认谁在搬运 → 从信源清单里移除搬运号、保留原始发布者 → 重跑对比 → 给新信源加观察期。下面每一步都落在配置、日志或页面操作上，可以自行复现。

适用场景：扫描结果里词条与人气集中在少数转载账号，人工筛选成本高。操作动作：先按 source_account 聚合并核对发布时间差，再把搬运号从信源清单禁用、保留原始发布者，重跑一次看条数与重复率。验证方式：修改前后同一批次的条数、重复率、Top 账号分布对照。风险边界：搬运号可能也首发部分内容，移除前需抽查；信源改动的效果与你的采集周期和去重规则有关，需结合环境确认。

在结果里按来源账号聚合，找出高频转载号

先不要看词表，把最近一个扫描批次的结果导出成表格，确认里面有来源账号字段（常见命名是 source_account / author / channel，按你实际的字段改）。然后做一次分组计数，看命中量是不是集中在少数几个账号上。

-- 结果表结构以实际为准，字段名按需替换
SELECT source_account,
       COUNT(*)                AS hit_rows,
       COUNT(DISTINCT keyword) AS keyword_cnt,
       MIN(published_at)       AS first_seen,
       MAX(published_at)       AS last_seen
FROM radar_result
WHERE scan_batch = :batch_id
GROUP BY source_account
ORDER BY hit_rows DESC
LIMIT 20;

没有数据库时，用导出的 CSV 加一条命令行也能看出分布，字段序号按你的导出列顺序调整：

tail -n +2 radar_result.csv \
  | awk -F',' '{print $4}' \
  | sort | uniq -c | sort -rn | head -20

把结果填进下面这张结构表。判断标准不是“某账号排第一”，而是看头部几个账号的命中行数是否与其余账号拉开明显差距——如果前几个账号就占了大部分行数，且这些账号的 keyword_cnt 很低（反复命中同一批词），基本可以判断噪声来自信源而不是词表。表中数值请用你自己的导出结果填写，这里只给结构。

排名	来源账号	命中行数	涉及词条数	词条/行数比值	初步判断
1	______	______	______	______	比值低，疑似转载
2	______	______	______	______	______
3	______	______	______	______	______
其余	（合计）	______	______	______	对照基准

核对转载内容和原始发布的时间差

“看起来像搬运”不能直接作为移除依据。更可靠的做法是给每条内容生成一个去重键（例如正文首段规范化后的哈希，或标题+正文前 N 字），再看同一去重键在不同账号下的最早发布时间，先后顺序就出来了。

SELECT content_hash,
       source_account,
       MIN(published_at) AS first_seen,
       COUNT(*)          AS rows_in_batch
FROM radar_result
WHERE scan_batch = :batch_id
GROUP BY content_hash, source_account
ORDER BY content_hash, first_seen;

挑几条命中量最高的内容，做成下面这种对照。时间早的一方通常是原始发布者，时间晚且正文高度重合的一方按搬运处理；如果两边时间几乎相同，先看正文是否有外链、署名、图片水印等可区分特征，判不出来的先放进观察名单，不要急着删。

去重键	账号 A 发布时间	账号 B 发布时间	先后顺序	处理
______	______	______	A 早于 B	B 判为转载
______	______	______	B 早于 A	A 判为转载
______	______	______	接近	进观察名单

在信源配置里移除这些账号，保留原始发布者

观察完就要落到配置上，否则下一轮扫描噪声照旧。多数词雷达类工具的信源清单是一个 YAML 或 JSON 文件，形如 sources 列表。建议不要直接删行——先置 enabled: false 并写明原因和对应的原始发布者，方便回滚和复查。以下只是通用骨架，字段名以项目实际配置为准。

sources:
  - id: acct_1042
    name: 原始发布者A
    enabled: true
    role: origin          # 保留，作为该内容的基准来源

  - id: acct_2210
    name: 转载号B
    enabled: false        # 先禁用，不物理删除
    role: repost
    duplicate_of: acct_1042
    disabled_reason: 同一内容发布时间晚于 acct_1042

  - id: acct_3305
    name: 聚合号C
    enabled: false
    role: aggregator
    disabled_reason: 命中集中在少数词，无原创首发记录

改完先做一次配置校验（多数工具带 `--dry-run` 或 validate 子命令），确认语法没坏、被禁用的账号已从生效列表里消失，再正式跑。若配置里有 role 这类字段而工具不识别，按实际 schema 精简，不要留无效键。

重跑一次，比较词条数量和重复率变化

用同一批次参数重跑，才能和修改前对比。命令行示例中的脚本名、参数名按你的项目替换：

# 1) 备份旧结果
cp result.csv result_before.csv

# 2) 用改后的信源配置重跑同一批次
python radar.py scan `--config` sources.yaml `--batch` compare_01 `--out` result.csv

# 3) 统计条数与重复率（重复率口径：重复去重键行数 / 总行数）
python radar.py stats `--input` result_before.csv
python radar.py stats `--input` result.csv

页面操作也可以在结果页切换批次，看“总条数 / 去重后条数”，部分工具会直接给出重复率；没有该指标的，用第 2 步里的去重键自己算。对照表里填实际数值，不要凭印象判断：

指标	修改前	修改后	取值方式
结果总条数	______	______	`stats` 输出或结果页计数
去重后条数	______	______	按 content_hash 去重
重复率	______	______	重复行数 / 总行数
Top1 账号命中占比	______	______	第 1 节的聚合查询

如果总条数下降、去重后条数基本持平，说明去掉的主要是重复贡献，是想要的结果；如果总条数下降、去重后条数也同步下降，要去查被移除账号里是否有独家首发内容，必要时按第 2 节回捞单条来源。

给新加的信源设置观察期

噪声压下去之后，真正的风险是下次又有人把搬运号加回来。建议新信源一律先进观察期：配置里标记为 role: pending，扫描结果单独打标签，不并入主词表统计，观察期内逐条人工判定，判定记录落在同一张表里。

- id: acct_5108
    name: 待观察账号D
    enabled: true
    role: pending
    observe_since: __观察起始批次__
    observe_batches: 3

观察账号	批次	产出条数	与已有来源重复条数	人工判定	结论
______	______	______	______	原创 / 转载 / 不确定	转正 / 移除 / 延长观察

判定“不确定”的比例偏高时，不要靠感觉放行，延长观察批次或继续用第 2 节的时间差核对；观察期结束后再改 role，并把判定理由写进配置注释，下一次排查时能直接看出这个信源为什么被留下。