模型只出"疑似"时：辅助筛查系统的判定权要写进哪里
一、“辅助”不是一个状态，是三档不同的权限
有一份技术示例值得从交付角度读一遍。它做的是五类对象的检测，网页界面提供四种输入：单张图片、批量压缩包、视频文件与摄像头实时流；输出是类别标识、类别名、保留四位小数的置信度和取整到一位小数的框坐标；配置与推理分离、权重单独存放，可以在局域网地址与端口上启动；文中写了一句“仅作辅助筛查，密度判定与处置决策交专业人员”。我们不谈这项检测本身的应用领域，只谈那句页脚的话：它在多数系统里是一句免责说明，而在工程上它应当是一组约束。要让它真的生效，得先承认“辅助”分三档——模型直接执行、模型给候选加人工确认、模型只做统计。三档下结论的人不同、责任归属不同、对字段与界面的要求也不同。
把三档混起来是这类系统最常见的结构性错误。示例里同时提供了单图与实时流两种入口，而这两种入口天然落在不同档上：批量图片通常进入人工复核队列，实时流却很容易被接成“检测到就动作”。接成哪一种，决定的不是模型能力，而是字段和留痕有没有跟上。
顺带说一句输出精度的问题：置信度保留四位小数，很容易被读成“精度到万分位”。界面呈现的位数会直接改变专业人员对可信度的直觉，所以字段要写明这个数字的含义是模型输出的分值，而不是错误概率的估计。
二、核心交付物：三档判定权与对应的字段、界面要求
| 档位 | 谁下结论 | 错误由谁承担 | 界面必须呈现 | 输出字段要求 |
|---|---|---|---|---|
| 模型直接执行 | 系统 | 系统责任方，即开发与运营方 | 动作已执行的记录、可撤销入口、失败时的显式提示 | 全字段留痕，含模型版本、参数、阈值来源与执行时间 |
| 模型给候选，人工确认 | 专业人员 | 确认动作由人做出，责任在确认环节；模型侧责任在字段是否完整 | 默认状态为待审、逐条确认、修改原因必填 | 每条带置信度、区域、版本与是否进入人工队列 |
| 模型只做统计 | 使用统计结果的管理者 | 统计口径的责任在定义者 | 样本量、时间窗、漏检与误检分开呈现 | 汇总字段，禁止把统计结果当成单条判定使用 |
这三档里最容易出问题的是第二档被做成第一档：界面把“通过”设成默认状态，确认按钮变成批量操作，人员实际上只是在给模型的结论盖章。责任边界就在这一刻悄悄转移了——页脚那句话还在，但它已经不再描述系统行为。
三、每条输出的最小字段集
字段的作用是事后能解释。我们要求每条输出至少带上：类别标识与类别名；置信度及其含义说明；区域坐标与来源媒介（图片、视频帧或实时流）；模型版本与数据版本，两者要能分别追溯；推理参数，包括阈值、缩放与输入尺寸；是否进入人工队列、进入哪一档队列；人工最终结论，以及当结论与模型输出不一致时的修改原因。
最后两项是这类系统的分水岭。没有它们，系统里留下的唯一记录就是模型的判断，事后既无法解释为什么漏，也无法把人工经验回流给模型；有了它们，“辅助”才有可核查的证据链。修改原因不要用下拉固定项了事，至少要允许一句自由文本，专业人员真正想说的内容常常不在预设项里。
实时流的输出还要多带一个字段：这条记录代表一个事件还是同一目标的连续多帧。不然统计时同一个目标会被数成很多次，密度与量的估计全错，而这恰好是专业人员最关心的那部分。
四、阈值必须按用途分档，共用一个一定两头不讨好
同一个分值在三类用途下对应完全不同的代价。筛查阶段宁可多报，漏掉的代价是问题进到下一环节，多报的代价是人工工作量；统计阶段必须控误报，因为汇总数字会被用来做资源安排，误报会让趋势失真；告警或者处置阶段要算成本，每一次触达都有人力与停工成本，阈值过高会耗尽响应能力。
三条用途共用一个阈值，结果必然是两头不讨好：筛查嫌漏、统计嫌多、处置嫌吵。做法是把阈值定义为“用途与对象”的二维配置，每档单独记录来源：这个数值来自哪一批标注数据、由谁确认、什么时候复核。阈值的修改要作为变更被记录，包括修改人和理由，否则后期无法解释“为什么这个类别一直没人报”。
类别之间也不该共用一套阈值。不同类别的样本量、外观相似度和错误代价都不同，出现一个类别表现正常、另一个类别全靠人工兜住的情况并不罕见。分档配置要能在界面上按类别查看，而不是藏在一个配置文件里。
五、界面要防止“默认接受”，演示服务不能当生产服务
避免默认接受靠四个具体设计：归档必须由逐条确认触发，未确认的条目不进统计；队列默认状态是待审而不是通过；人工改动的内容回写为训练侧的负样本，让改动有去处；批量操作要留痕，记录操作范围与执行人，且批量通过要单独权限。界面速度优化不该走在这些之前——一个让人顺手全选的快捷交互，等于把责任推给不了解规则的人。
演示服务被当成生产服务，是这一类示例被复制进企业环境后的固定路径，后果有三类。局域网地址与端口直接开放，没有鉴权与访问边界，任何能连到这台机器的人都能提交任务并读取结果，这在生产里是不可接受的暴露面。配置与权重分离存放带来版本错配：权重换了、配置里的类别表与阈值没换，或者反过来，输出的类别名和实际模型对不上却没有任何报错。把类别定义与阈值从权重里独立出来可以，但两侧都要带版本标识，启动时做一致性校验，不一致直接拒绝服务而不是照常出结果。第三类是示例默认值被沿用：默认的输入尺寸、默认阈值、默认的批处理并发数，这些为演示选的值在真实数据量与真实工况下会变成性能与准确率问题的源头。默认值要在部署清单里逐项确认并写明由谁核定。
六、验收口径、留痕复盘与交付文档里该写的三句话
验收不看总体分数。我们按三条口径来：与人工判定的一致率按类别拆开统计，混合口径会掩盖单个类别的糟糕表现；错误代价高的类别单独设指标，即使它在总量里占比很小；漏检与误检分开统计，两者的整改手段完全不同，合成一个指标就没法派活。指标还要绑定样本来源，说明这些一致率是在哪批数据上算出来的。
留痕与复盘要有固定节奏。每条确认记录要能回答“谁在什么时间确认了什么、改动原因是什么”；抽审比例按类别与操作员设定，专门抽查那些被快速通过的条目。抽审不是惩罚机制，它是唯一能发现“默认接受”已经发生的工具；错例回流要有固定路径，谁负责把复核发现的偏差转成阈值调整或者重新标注，要写在值班表上而不是靠自觉。
交付文档里必须写的三句话：模型输出不构成最终判定，任何进入业务动作的结论都需要确认记录；待审队列有处理时限，超时的条目按预设规则升级而不是无限堆积；人工改判率作为常态指标被监控，并设定目标区间——改判率过高说明模型或阈值有问题，改判率异常偏低说明复核在走过场。这两端的偏离都是告警条件。
洹拓科技在做这类辅助系统时，会把“判定权落在哪一档”作为方案评审的第一项，写在文档首页而不是免责声明里。因为只有先确定谁下结论，字段、界面和验收口径才有推导依据；顺序倒过来，页脚那句话就只是页脚那句话。