AI 的判断，哪些要交回给人：置信度、阈值与复核台账

AI 现在会告诉你它有多大把握。2026 年 11 月 11 日，Google 发布了一个只做判断的模型：它不写文章，只回答「是不是」「选哪个」「打几分」，并且给每个答案标一个 0 到 1 之间的置信度分数（置信度：模型自己估计这个答案有多大概率是对的）。同一周，美联航做了一个相反方向的决定：不管 AI 代理多有把握，都不准替乘客完成订票。这两件事中间，夹着一个大多数在用 AI 代理的团队还没白纸黑字回答过的问题：哪些事可以让软件自己定，哪些事必须回到人手里。

置信度阈值是指在模型 0 到 1 的置信度刻度上画的一条线：分数高于这条线，AI 系统按自己的答案行动；低于这条线，停下来，把这个决定转给人或者备用流程。它不是安全保证，也不衡量对错。它只是一条分流规则。分流规则好不好用，取决于背后的动作分级、复核流程和记录。

简短的答案是：错了也便宜的事，交给机器；拿不准的，排队；凡是等于签字的事，分数再高也留给人。做到这一步需要四个零件：动作分级、两种错误的价钱、一次影子运行的校准、一本复核台账。哪一样都不需要机器学习团队；最难的一件也不在技术上，难在要提前写下来——团队愿意以什么比率，容忍哪些错误。

置信度分数在度量什么

同一套大模型技术，用在两种差别很大的事情上。一种是生成：写一段开放的文字，答案空间是无限的，很难打分。另一种是判断：回答一个有边界的问题（是或否、几个选项里选哪个、按一个量表打几分），答案空间是封闭的，很容易打分。置信度能先在「判断」这边变成产品功能，就是因为判断可以被验证。

挂在这种答案上的置信度分数，是模型对「自己这个答案是对的」这件事的概率估计。要判断这个估计可不可信，要看校准（校准：在一大批判断上，模型报的分数和实际对错比例是否一致）。一个校准良好的模型，所有被它标 0.9 的答案里，大约 90% 事后被证明是对的。注意，校准是统计性质，它在一批答案上才成立，对单独某一个答案什么也保证不了。

这个区别撑起了整个话题。某一笔退款申请得了 0.92 的置信度，不代表这笔退款处理对了。它的意思是：如果模型在这类输入上的校准还成立，那么 100 笔类似的申请里，大约 92 笔会被处理对。剩下那 8 笔要花掉你多少钱，决定了 0.92 到底够不够。

分数还有一样东西不包含：责任。置信度是模型内部算出来的；行为的责任在模型外面，落在授权这套系统去做事的人身上。这正是主权 AI 分身六条标准里「动作在模型之外判断」那一条的含义：分身可以提议、也可以执行，但它被允许执行什么，由主人定的规则在模型之外把关。阈值就是这样一条规则。它是主人的规则，不是模型的规则。

好消息是，校准这件事不需要任何机器学习背景就能自己测。取最近 500 条你想自动化的那类决定（人已经处理过、对错已知的那种），让判断层全部打一遍分。按分数分桶：0.90 到 0.95 一桶，0.95 到 0.99 一桶，依此类推。再拿每桶对照已知的对错。如果 0.90 那桶大约对了九成，说明模型在你的业务上校准成立；如果 0.90 那桶只对了七成二，你就提前知道了这块表走得偏高，而不是等出了事故才知道（500 条是个可用的下限，样本再小，每桶的比例就太抖，没法拿来做决定）。

同样的练习每月在最近的流量上重做一遍，就是漂移检测。校准会因为很平常的原因失效：产品改版了、来了一批新客户、旺季改变了典型请求的样子、供应商悄悄更新了模型。这些变化都不会通知你。你唯一能收到的通知，是这个月每桶的正确率和上个月差了多少。所以这个测量必须排进日程，而不是想起来才做。上线时测一次校准是一张照片；阈值需要的是持续的脉搏。

关于分数从哪来，还有一个实际提醒。专门的判断模型，分数来自它在封闭答案集合上真实计算出的概率。拿一个通用聊天模型，在提示词里加一句「顺便输出你的置信度」，得到的是一个听起来合理的数字，背后没有这种计算支撑；公开的评测反复发现这类自报数字校准很差。选工具的时候这个差别很要紧：要拿来给真实动作分流的分数，应当来自为出分数而造的系统，否则就得先按「不可信」来验证它。

表走偏是什么样子：自报置信度 vs 实测正确率（示例场景）

Google 把「判断」拆出来单卖

Google 这次的发布值得细读，因为它把一个架构观点变成了标好价的商品。Gemini Decisions API 于 2026 年 11 月 11 日发布，背后是一个叫 Gemini Decision 1 的专用模型。它完全不生成文字，只在一次前向计算里，对同一份输入回答最多 1,000 个有边界的问题，并返回概率。

产品的实际形态如下（出自 Google 2026 年 11 月 11 日的发布文章；Google 是厂商，性能数字是厂商自报）：

表里有两行比其余的更要紧。先看价格：按每 100 万输入 token 收 $0.10 算，对一封 2,000 token 的邮件做一次政策检查，花 $0.0002（假设每次检查 2,000 个输入 token、不重试）。一美元能买五千次这样的检查。「判断」作为商品，现在比 AI 技术栈里几乎所有东西都便宜，包括它所监督的那个「生成」。

另一行藏着设计者自己的假设。Google 的文档原文说，置信度分数的存在是「为了让你的代码把拿不准的情况转给备用流程或人工复核员」。卖判断的厂商，在产品手册里告诉你：有些判断不应该被自动接受。Google 还披露了自家的内部用法：用同一个 API 给日常请求做意图分类、路由到更轻的模型，这类请求的延迟最多降低 40%；也用它驱动 Stitch 画布工具里的快速设计迭代（两个例子和数字都来自 Google 2026 年 11 月 11 日的发布文章，属厂商自报）。路由这一层具体怎么运作、为什么判断模型天然适合干这个，多模型路由有完整的解释。

「输出不收费」这个定价还有一层商业含义。答案本身不要钱，说明 Google 指望靠调用量挣钱：判断被定位成管道，像数据库索引一样被一个工作流调上几千次，而不是像一份报告那样被郑重其事地买一次。对买家来说，这件事两面都要看。判断便宜，意味着这套分流做法在任何规模下都花得起，这是好的一面。判断便宜，也意味着过去让团队「接一层模型判断之前先想一想」的成本摩擦没有了。当每次检查只要万分之二美元的时候，人会忍不住让「检查」处处取代「检查的人」。哪些层级仍然需要一个人，这个纪律今后只能来自政策，不会再来自账单。

有一点要说清楚：以上不是为某一家厂商的分数背书。任何判断层，买的也好、自建的也好，给你的都是同样三样东西：一个有边界的问题、一个答案、一个描述回答者自信程度的数字。分级、定价、台账，要的也只是这三样。

自建还是采购，其实是一道普通的工程权衡题。买专用判断 API，换来现成的校准和毫秒级延迟，代价是在技术栈最敏感的位置（决定你的代理可以做什么的那个部件）多了一个外部依赖。自建意味着在自己掌控的硬件上跑一个开放权重模型加受限输出头，或者一个小的微调分类器：分数质量起点更低，维护是自己的事，换来的是这一层判断不会被别人的路线图涨价、下架或悄悄改版。成本很少是决定因素：即便一个团队每天跑一万次政策检查、每次 2,000 token，按 Google 的价格一年也只花大约 730 美元（10,000 次 × 2,000 token × $0.10/100 万 × 365 天，忽略重试），自建的电费都不止这个数。真正决定选择的是决定本身的敏感程度：路由公开内容标签的团队，放心买就是；路由付款审批的团队，很可能会得出结论：做判断的部件，应该握在为付款负责的那一方手里。很多团队最后走中间路线：低风险层级买判断，高风险层级保持人工复核加一份自己掌控的检查单，让任何外部 API 都不插在「昂贵动作」和「为它负责的人」之间。下文的分级结构正好让这种拆法顺理成章。

检查比被检查的任务便宜（对数刻度）

哪些决定不能交给任何置信度：美联航的三条理由

就在 Google 给判断标价 $0.10 的同一天，美联航画了一条任何置信度分数都跨不过去的线。《华尔街日报》报道、The Verge 于 2026 年 11 月 11 日向美联航确认：这家航空公司不允许第三方 AI 代理替乘客完成购票。代理仍然可以搜索和展示航班，但不能完成交易。

美联航给出的理由比禁令本身更有启发。一条是隐私。一条是误购：代理可能买下主人并不想买的票。第三条最锋利：美国联邦规则要求某些申报必须由乘客本人确认，比如申报「托运行李内没有爆炸物」。代理不能替你做这个申报，因为申报这个动作的全部意义，就在于一个具体的人为后果签了字。CEO Scott Kirby 还补了一个商业动机，他的原话是「说实在的，我不想再造出一个中间商」。美联航同时表示，等旅客保护机制成熟后可能重新考虑；The Verge 的报道还提到，eBay 已经对 AI 代理关了门，几家大银行也对代理加了限制。

把航空业的细节剥掉，一个通用类别就露出来了：属于「签字担责」性质的决定。签合同。在罚则之下申报信息属实。承担法律责任。这些不是「模型再强一点就能答对」的难题，而是意义就在于「某个特定的人做了它」的行为。置信度分数对它们毫无意义，就像一个仿得再像的签名，仍然是伪造。

所以在做任何阈值运算之前，团队需要先列一张短名单：哪些决定干脆不上自动化的桌面。大多数团队会发现这张名单比担心的要短，剩下的地盘反而可以放开手脚、问心无愧地自动化。

还有一个角度值得花一分钟：美联航禁的是别人家的代理，不是自家的软件。如果你的团队的分身要订差旅、挂商品、在第三方平台上交易，那么你的阈值政策有一部分现在是由对手方替你定的：eBay 挡了代理浏览，几家大银行限制了代理访问账户，更多行业正在公开地做决定（The Verge，2026 年 11 月 11 日）。今天跑得好好的自动化流程，明天可能撞上对手方的墙；而美联航那句「随着第三方 AI 代理的发展」可能重新考虑，也说明墙是会挪的。落到计划上：把「对手方拒绝代理」单独当成一个层级来对待，给它配一条测试过的、而不是纸面上的人工兜底路径，这样一家航空公司或一家银行改政策时，你的流程是降级运行，不是当场停摆。

阈值能带来什么

替阈值说句实话：它真正的价值在于处理数量。一个团队让分身去跑企业自动化工作流，比如监测、工单分流、合同初审，每天就要面对几百个小决定。人把每一条都看一遍，到周四就看不动了；人一条都不看，出了错要靠客户来告诉你。阈值这件工具，把「折中」从一句空话变成了可执行的机制：机器处理它被证明擅长的那部分，拿不准的进入一个按人的真实注意力配大小的队列。

它还把一种说不清的焦虑换算成了一个有人认领的数字。「我们放心让分身批退款吗？」这个问题在会议室里是吵不出结果的。「低于 0.90 进小丹的队列，这是上个月 0.90 以上那部分的实测错误率」，这个说法可以拍板、可以审计、可以调整。阈值从此是一个政策对象：可以复查、可以记版本、出了事可以收紧，跟防火墙规则一个待遇。

还有一个安静一点的好处。被分流的决定会留痕。人批复分身拿不准的那一单时，记录里有模型当时的估计、人最后的决定、以及时间。几个月攒下来，这串记录是团队的教材，是审计的证据，也是续约时唯一要紧的那个问题的原始数据：自动化的实际正确率，到底配不配得上它报的分数。

说到底，阈值是给你自己的乐观上的一份便宜保险。团队总是高估线上环境和试点环境的相似程度。阈值不能防止这个错误，但它能给「发现这个错误」的代价封顶。

想象一个普通的周二，差别会更具体。没有阈值政策的时候，客服主管要么把分身起草的每一笔退款都过目一遍，那分身省下的只是她打字的时间，没省下她判断的时间；要么想起来才抽查，那分身最差的几单，恰好在她最忙、顾不上抽查的日子发出去。有了政策，她早上的队列里是模型打了低分的十一单，每单顶上带着分数和原因。她就着咖啡清完，驳回两单，这两单进了当月的校准数据。另外一百四十单分身自己处理了。没有人检查那一百四十单——而「不检查」是某个人白纸黑字、带着数字、慎重做出的决定，不是一个没人注意到的窟窿。

阈值给不了什么

失效模式值得一个个起名字。起了名字的风险会被管理，没名字的风险只会在事故复盘里被发现。

第一个叫校准漂移：分数和现实之间的缝。在上个季度的工单上校准好的模型，碰上产品改版、客群变化、输入语言变化，就会走偏。漂移之后的 0.95，可能只值从前的 0.80。表盘上的指针动了，底下的机芯没跟上。所以校准必须定期在你自己最近的流量上重测，不能从厂商的基准测试里「推定」。Google 给 Decision 1 报的校准成绩，和所有厂商一样，是在 Google 自己的基准上测的（厂商数字，2026 年 11 月 11 日），不是在你的退款队列上测的。

第二个更难缠，叫担责缺口。把决定转给人，只是让一个人出现在了环节里；这个人是否负责、是否知情、是否清醒，转交本身一样也保证不了。如果复核队列每小时往一个还有本职工作的人桌上倒四十单，几周之内复核就退化成了盖章，组织花了「真监督」的价钱，买到的是「看起来有监督」。解法不花哨：限制队列流量；盯住不同意率（一个从来不跟模型唱反调的复核员，等于没在复核）；让批准成为一个要签名字的动作。

第三个叫分布外风险：恰恰在最反常的案例上，置信度分数最不可靠，因为反常输入正是模型在训练里见得最少的输入。最该叫人来看的案例，偏偏是分数这个「叫人机制」最失灵的地方。低分转人工能接住其中一部分；硬性天花板（某些类别无论分数多高一律转人工）能接住更多。

第四个叫累积风险，最容易漏，因为单看每一笔都没毛病。一千笔自动批准的 30 美元退款，错误率 1%，就是十笔错单、约 300 美元，多半可以接受。同样的机器以 1% 的错误率给一千条客户记录自动打标签，可能悄悄污染一份整季度报表都建立在其上的数据，而这一批里没有任何一笔大到会被转给任何人。阈值是按「单笔」工作的；有些伤害只存在于「总和」里。防它的办法，是定期对自动批准的那一段流量抽样审计，恰恰是被阈值免检的那一段，因为量都在那里，漂移也在那里无声地累积。

范围也要说清楚。阈值管的是常规的、有边界的决定上的出错风险。它管不了签字担责类的决定，美联航的案例说明那类决定必须留在个人手里；它管不了供应商风险，判断层自己也是一个 API，一样会被下架和改价；它也不是急停开关。叫停一个正在动作中途的代理，是另一种控制，有它自己的要求，离真正的 AI 关停开关更近，离分流规则很远。

如何设定一个能用的阈值

这套方法不预设任何供应商。它需要三样东西：一个会出分数的判断层，一个接收转交决定的去处，一个愿意为这些数字负责的人。打算采购而不是自建的团队，可以把这些问题并进签约前的采购标准里一起问。

先说这活归谁干。大公司里，它落在平台组或风控组；十个人的公司里，它就是运营负责人的一个下午，而且这个下午值得花。分级名单是一场谈话，错误定价是白板上的四则运算，影子运行是表格里多出来的一列，全程不需要机器学习岗。真正需要的只有一样：愿意在第一次事故之前就写下来，团队决定以什么比率容忍哪些错误。这样等事故真来了，它是一条政策内的数据点，而不是一场「自动化还要不要搞」的全民公投。

按后果给动作分级，不按频率

把分身实际能做的事列出来：发送、发布、购买、删除、回复、归档。对每个动作问一句：最坏的一次错误执行，在钱上、在信任上、在法律上值多少。三档通常就够。可逆而且便宜的（内部草稿、打个标签）：分身直接做，不看分数。可逆但对外可见、或者花真金白银的（回复客户、小额退款）：分数过线分身做，不过线进队列。不可逆、昂贵、或者属于签字担责的（超限付款、合同签署、没有备份的删除）：永远人来做，分身的角色到「把决定准备好」为止。最后这一档，就是把美联航的教训用在办公桌的尺度上。

每周 600 单落在什么分数段（示例场景）

先算两种错的价钱，再挑数字

每条阈值都在两种成本之间做交换。定得高，人工复核的大多是本来就对的判断：你在用工资买安心。定得低，错误会出门：你在用返工、道歉和善后时间付账。把两个价钱都写下来，粗一点没关系（一笔批错的 40 美元退款，成本是那 40 美元加上大约 20 分钟的善后；一次多余的复核，成本是复核员大约 90 秒的注意力）。让这两个数字打平的那条阈值，是一个业务主管能认领、能辩护的预算决定；政策要想在第一次事故复盘里活下来，靠的就是这个。

阈值是一条成本曲线的最低点（示例场景）

先影子运行，从保守起步，自动化权限只向下授予

头两到四周跑影子模式：判断层给所有决定打分，人照旧做所有决定，谁的工作都不变。影子流量会给你之后所有争论的地基：分数分布曲线，和按分数段统计的人机不同意率。然后只对最高那一段打开自动化（0.95 以上是常见的起手式，但该由你自己的不同意率曲线来挑这个数，不是由惯例来挑），之后每放宽一段，都要用实测错误率来挣。自动化权限从谨慎这头向下授予，绝不在事故之后向上补丁。

上线六周，抓住一次漂移（示例场景）

每条转人工的决定，都当作将来有人要查那样记

每条进队列的决定应当记录：输入（或一个不会失效的指针）、问的问题、模型的答案和分数、当时生效的阈值版本、谁复核的、复核结论、时间。记录一薄，之后所有问题都答不上来：「漂移开始了吗」答不上，「这一单谁批的」也答不上。台账比阈值更要紧，因为阈值一定会变，而台账是你知道「它该变了」的唯一来源。台账放在哪、换供应商时它还在不在，是分身记忆归属的问题；锁在厂商控制台里的复核记录，是一份某天可能跟你告别的记录。

给阈值记版本，指定唯一负责人

没人认领的阈值，会在匆忙中被改掉，又被所有人忘掉。拿对待防火墙规则的态度对待它：有当前值，有带理由的修改历史，有一个有权动它的、具名的负责人。平时的修改走负责人，日志里留一行理由（「自动段检出漂移，0.95 → 0.97，已排期重校准」）。事故期间的修改只许朝一个方向：更多人工复核；放松要等复盘之后。另外两个习惯也值回票价：按日历、至少每季度对照最新的校准结果复查一次阈值，让这个数字反映当前的流量，而不是上线那一周的乐观；负责人换岗时，连台账一起把阈值显式交接，像交接值班寻呼机那样。没人继承的阈值，就是组织最后说不清「到底是谁决定机器可以花钱」的原因。

示例：一家 40 人电商的退款阈值

设想一家 40 人的网店，客服分身负责处理退款申请（每周 600 单，平均每单 38 美元）。团队在十月给「批准退款」这个动作分了级：金额 50 美元以下且分数高于 0.95，自动批准；分数在 0.70 到 0.95 之间，或金额在 50 到 200 美元之间，进客服主管的队列；金额超过 200 美元，或订单带欺诈标记，无论分数多高，一律人工。

这几条线背后的错误定价，是一场二十分钟的练习。一笔批错的退款，成本是退款额本身，加上客户或财务发现后大约二十分钟的善后，团队把典型案例记成约 55 美元；一次多余的排队复核，花主管约九十秒。按这两个价钱，把一笔拿不准的 35 美元申请转给人，只要每四十次这样的复核里有一次拦下真错误就回本；影子数据说，远不止一次。影子运行还给了一个预算外的发现：模型对礼品卡退款打分很自信，错误率却是整体的四倍，于是礼品卡按类别整个挪进了「永远人工」档。这个修补，任何阈值数字都给不了。

四周影子运行、六周上线之后，团队真正用来治理的是这些数字：

一月份产品线调整，自动段的错误率悄悄爬到 3%。因为台账把分数和结果记在一起，漂移出现在了周报里，阈值一天之内挪到 0.97，重校准排进了日程。要是没有台账，漂移的第一个信号会是一场退款纠纷。团队把分级名单和当前阈值放进运营手册，紧挨着值班表，让下一个新人第一天就知道线在哪。

这家店的一周发生了什么变化（示例场景）

开启自动化之前的自查表

这些问题可以压缩成一张表，一次会议走完。任何一行答得迟疑，这个动作就还没准备好交给自动化。

KarmaBox 如何落地置信度阈值与人工复核

我们自己的产品 KarmaBox，是一个运营你自己的 AI 分身的平台和网络；动作分级、审批、台账这几样，在它身上都有现成的对应。

动作分级这一步是产品原生的：每个 AI 分身按动作类别带着主人设定的策略，发送、发布、花钱、删除各有各的规则，而不是一个全局总开关。「永远人工」档对应的是审批卡：越过主人红线的动作不会静默执行，而是变成一张卡片送到主人面前，点一下批准或驳回——签字担责类的决定因此留在为后果负责的那个人手里。判断层的位置也是一个配置选择，和 Google 自述的路由用法同一个思路：分身可以在行动前先过决策检查，而这层判断和活本身跑在哪，由团队来定：敏感的复核流程放在自己部署的机器上，对外的公开任务交给云端分身。台账这一步是设计使然：分身做了什么、谁批准的、什么时候批的，留在主人自己的记录里，不在厂商的控制台里；策略和审批的具体配置步骤，产品文档里有完整说明。要在多个部门铺开的团队，通常从企业部署路径起步，分团队的动作策略在那里用得最多。

KarmaBox 不能替团队做的，是这套方法自己的功课：分级名单、错误定价、校准测量，这些判断只有拥有这摊业务的团队自己能做。平台负责把线执行到位；线在哪里，还得团队自己画。

常见问题

关于作者

Karma Box 团队。我们发布关于 AI 主权、工作台控制与供应商评估的实用指南。本文把报道事实（出处和日期标在事实出现的那一句里）与我们的判断分开；在对我们不利处照引厂商原话；KarmaBox 相关内容单独成节。本文不认证任何厂商的校准数字，也不构成法律或合规建议。新闻事实核查于 2026 年 11 月 12 日。