关键词词库 - 用词库为内容审核提供可追溯依据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4da2dd505231.html
📄
关键词词库 - 用词库为内容审核提供可追溯依据
关键词词库要为内容审核提供依据，核心做法是：把每个词从“是否允许出现”变成一条可核对的记录，记录它的归类、判定理由、适用场景和更新时间。审核人员看到一篇文章时，不是凭感觉判断，而是拿词库逐项比对，得出“命中哪条规则、为什么命中、该怎么处理”的结论。词库的价值不在词多，而在每条词都有明确的处置口径。
先明确词库要回答哪些审核问题
在整理词之前，先确定审核需要词库回答什么。常见的有四类：能不能用（禁用、限用、可用）、什么场景能用（标题、正文、评论、广告语）、命中后怎么处理（删除、替换、加提示、转人工）、谁负责确认。这四类问题决定了词库的字段结构，也决定了审核时能拿到什么证据。
如果词库只列一个词表，没有归类和处理口径，审核就只能靠个人经验，遇到争议无法复盘。字段可以先从最小集合开始：词条、类别、处置动作、适用场景、判定说明、更新日期。字段够用即可，不必一次设计得很复杂。
准备阶段：把词条拆成可判定的记录
准备阶段的关键是让每条记录都能被独立判断。可以按下面的顺序操作：
- 收集来源：从历史审核记录、用户举报、业务反馈中汇总需要纳入的词，而不是凭空罗列。
- 逐条归类：给每个词标注类别，例如敏感、竞品、夸大宣传、行业限制等，类别名称要贴合自己的审核口径。
- 写判定说明：用一句话说明“为什么这个词要这样处理”，这句话就是审核时最直接的依据。
- 标注场景：同一个词在标题和评论区可能处置不同，场景字段不能省。
- 指定责任人：每条记录写明由谁维护，避免无人认领。
举例来说，假设某词被列为“限用”，判定说明写“仅可用于客观描述，不得用于效果承诺”，那么审核时看到它出现在承诺性语句里就命中限用规则，出现在客观描述里则放行。这个例子是假设，用于说明字段如何支撑判断。
实施阶段：用词库逐项比对并留下记录
实施时，审核动作应当是可重复的。对一篇待审内容，按以下检查项逐条过：
- 内容中出现的词，是否能在词库中找到对应记录；找不到的先标记为待补充，而不是直接放行或直接删除。
- 命中的词，其适用场景是否与当前内容位置一致。
- 命中的词，当前语境是否触发判定说明里的限制条件。
- 处置动作是否与词库记录一致，若不一致，记录实际动作和原因。
最关键的一步是把每次判定结果写回记录。审核结论、命中词条、处理动作、处理人、时间，这几项要能对应起来。这样当同一类内容再次出现，或有人对处理结果提出异议时，可以直接调出当时的依据，而不是重新争论一遍。
验证阶段：用已知样本检验词库是否可用
词库建好后，不能只看它列了多少词，而要用样本验证。准备一批已经人工判定过的内容，包含应当通过、应当拦截、边界模糊三类，让不同审核人员仅凭词库判断，再对比结果。
判断标准可以这样定：
- 应当通过的样本，若被误拦，说明词条过宽或场景字段缺失。
- 应当拦截的样本，若被放过，说明词条缺失或判定说明不够明确。
- 边界样本出现分歧，说明该词条需要补充更细的条件，或升级为人工复核项。
验证结果直接指向要修改的记录，而不是笼统地说“词库不准”。哪条词导致误判，就改哪条，并记录修改原因。
维护阶段：让依据保持可追溯
词库会随业务口径变化而调整，维护的重点是保留变更痕迹。每次增删改，至少记录改了什么、为什么改、从何时生效。旧内容按旧口径审核的结论不应被新口径直接推翻，除非业务明确要求追溯。
定期复查时，优先看两类记录：长期未被命中的词，判断是否还有保留必要；频繁触发人工复核的词，判断判定说明是否写得太模糊。维护不是把词库越堆越大，而是让每条记录继续能支撑判断。
下一步可以从现有审核记录中挑出十条争议内容，逐条对照词库，看哪一条缺少可核对的判定说明，先补齐这一条。
