1. 从降低审核成本,到明确什么可以交给 AI
业务人员提交素材时需要填写场景、功能等标签。素材数量多,审核又需要结合脚本理解语义,逐条检查耗时,也容易出现遗漏或理解不一致。
管理层提出降低审核成本的目标后,我进一步梳理原流程,识别重复检查、语义判断和争议处理三个环节,确定各自的处理方式。
| 任务 | 承担方式 | 判断依据 |
|---|---|---|
| 可以用明确条件检查的内容 | 程序与规则 | 结果确定,可重复执行与校验 |
| 脚本是否支持所填场景、功能标签 | LLM | 需要理解语义,难以穷举条件 |
| 脚本证据不足、标签存在争议 | 人工确认 | 输入信息不足时,模型无法补出事实 |
2. 审核流程:让业务先修改,管理员聚焦异常
素材脚本 + 已填标签 + 当前标签定义与规则
→ 确定性检查
→ 模型依据脚本独立推荐标签
→ 对照已填标签,识别疑似错标、漏标与待确认情况
→ 输出依据与修改建议
→ 业务人员修改,管理员处理异常与争议
在模型推荐环节,不提供原标签,让模型仅依据脚本从当前标签库中选择,再进行对照。模型的选择范围受到标签库约束;证据模糊时输出待人工确认。
3. 关键取舍:稳定主流程,配置高频变化
业务标签和特殊规则经常调整。如果每次修改都需要重构整条工作流,维护与回归成本会随业务变化增加。
我把相对稳定的审核主流程保留下来,将标签库、标签定义和特殊规则独立维护,由工作流读取当前配置。这样规则更新可以集中处理,也便于判断一次错误来自业务定义、输入还是模型。
任务路径明确,不需要模型自主规划下一步,因此采用固定 Workflow。对于证据不足的边界情况,先保留人工处理,再评估新增多模态输入的成本和实际收益。
4. 一个关键 Bad Case:先修标签定义
有一类素材,AI 在几个相近标签之间反复选错。继续核对后发现,人工也会对同一脚本给出不同标签。
我将问题追溯到标签初始定义:描述与适用边界存在重叠。随后重新明确标签的描述和边界,再用原来的 Case 回归验证。
这个过程影响了我后续的排错顺序:先看证据是否充分、规则是否清楚,再定位模型判断和输出问题。标签本身没有清晰边界时,提示词无法稳定解决业务分歧。
5. 运行与迭代结果
- 覆盖 30+ 人,连续运行约 2 个月。
- 完成 3–4 轮 Bad Case 复盘,推动 10+ 项修复上线。
- 参与审核人员每人每周的审核全流程耗时由 4–5 小时缩短至 1 小时以内,包含复核、纠错、审查等环节。