自动评分适合做初筛,不适合替你做最终裁决。防止人工判断被替代的关键,是把评分降级为线索,把可解释的证据链和人工结论留成独立记录;当旧内容、旧系统或旧合作关系需要退出时,先区分“整体废弃”与“保留仍有价值的部分”,再决定评分参与到什么程度。
退出场景里最容易犯的错,是把“该不该退”和“退到什么程度”混成一个分数。两种条件成立时,做法应当不同。
第一种条件:退出对象整体失效,保留部分没有独立价值。例如一个旧系统只服务一条已停用的业务线,旧合作关系的产出无法迁移到任何现有渠道。此时自动评分可以承担主要筛选工作,你要做的是抽检评分依据是否覆盖了退出决策真正关心的维度,比如数据可迁移性、合同约束、下游依赖。抽检通过后,人工只需确认边界,不必逐项重判。
第二种条件:退出对象整体失效,但局部仍有价值。例如旧内容里有一部分仍能承接真实需求,旧系统里有一组数据仍被其他流程引用,旧合作关系里有一类资源仍可复用。此时自动评分几乎必然误伤,因为评分模型通常按整体表现给分,不会识别“局部保留”这种非标准答案。你要做的是先人工圈出保留范围,再让评分只在保留范围之外起作用。
判断属于哪一种,可以问一个具体问题:如果把这个对象拆开,拆出来的部分有没有明确的接收方?有接收方,走第二种;没有,走第一种。这个判断本身不能交给评分,因为评分看不到接收方是否存在。
自动评分被滥用的根源,是让它回答“该不该保留”这类需要权衡的问题。更稳妥的做法是限定它的回答范围。
把评分限定在可量化、可复核的维度上,例如:该对象最近是否还有真实访问或调用、是否有下游流程仍在引用、维护成本是否随时间上升。这些维度评分可以给出方向性提示。而“保留哪一部分”“保留多久”“由谁接手”属于决策问题,必须由人给出结论并写明理由。
实施动作可以这样落地:先列出退出决策真正需要的判断项,逐项标注“可由评分提示”或“必须人工定论”。对后者,要求写下结论和一条可验证的依据,例如“保留该模块,因为下游流程A仍调用它”,而不是“评分较高所以保留”。这个动作的结果会直接影响下一步:如果人工定论项超过你能投入的复核量,说明退出范围划得太大,应先缩小到一批对象再处理,而不是放宽人工判断。
假设某站点要清理一批旧内容,自动评分按整体流量和更新时间排序,把一篇长期低流量、多年未更新的页面排在退出队列前列。但该页面包含一段仍被其他页面引用的说明,删除后会造成引用断裂。
评分没有错,它只是没被要求看引用关系。要防止这种误伤,动作是在评分之外单独跑一次依赖检查:列出每个待退出对象被哪些其他对象引用。检查结果会改变处理顺序——有引用的先处理引用,再决定退出;没有引用的才进入评分主导的批量退出。这个例子的数字和场景均为假设,用于说明比较方法,不代表任何真实项目结果。
例外情况也要写清楚:如果引用本身也已失效,或者引用方同样在退出范围内,那么依赖检查不应成为保留理由。判断引用是否有效,同样需要人工确认,不能只看“存在引用”这个信号。
第二种条件下,最容易出现的问题是保留范围无限扩大,最后等于没退出。防止办法是给保留部分单独设标准。
这些条件的作用是让“保留”成为一个有终点的状态,而不是评分的豁免区。评分在这里仍可使用,但只用于提示保留部分是否出现新的风险信号,例如维护成本继续上升或调用量持续下降;出现信号时触发人工复查,而不是自动触发删除。
如果人工结论只存在于讨论里,下一次复核时它很容易被新一轮评分覆盖。要让判断留下来,记录需要包含三样东西:结论、依据、复查条件。
结论写“退出”“保留”或“部分保留”;依据写可验证的事实,例如依赖关系、合同条款、接收方确认;复查条件写触发重新评估的信号。评分结果可以作为附件保留,但不能替代这三项。这样做的实际效果是:当评分与人工结论冲突时,你能看出冲突来自哪里——是依据变了,还是评分维度本就不覆盖这个判断。前者需要重新决策,后者说明评分不该用在这里。
至于具体工具是否提供上述记录字段、导出方式或权限控制,不同产品差异较大,需要以你实际使用的版本核对,不能默认某类工具一定具备。
回到最初的问题:防止人工判断被自动评分替代,不是拒绝评分,而是明确评分只做线索、人工结论必须带依据和复查条件。当退出对象整体失效且无接收方时,评分可以主导;当局部仍有价值时,先人工划定保留范围,再让评分处理范围之外的部分。这个区分做对了,退出才不会变成一次性的批量删除,也不会变成永远退不干净的拖延。