一、项目背景

我们有几个关键业务场景，比如合同关键条款抽取、风控结论生成，原来只接单一模型。问题是模型偶尔会抽风答错，业务方不信任，又不敢全切到备用模型，怕另一个也错。纠结来纠结去还是人工兜底，效率上不去，模型的价值也没发挥出来。我们复盘过一个季度，关键场景人工兜底占了近三成请求，审核同学天天盯着屏幕比对自己累，模型省下的时间又被人审吃回去了。更尴尬的是，人工兜底本身也会出错，人盯久了走神，反而出现模型对、人改错的case，信任关系一度很拧巴。

我们当时想，关键结果不该押宝在一个模型身上，多跑几个比对一下，总比人盯屏幕强，而且多数时候几个模型会给出一致答案，只有少数分歧才需要人。

二、落地场景

方案分五块。一是多模型并行调用：网关收到关键请求，同时发给两个或三个模型。二是结果一致性校验：对多份结果做语义相似度比对，判断是不是一回事。三是对分歧投票：多数一致才采用，不一致转人工。四是低置信转人工：任一份置信度过低，直接交人审。五是调用轨迹留痕：谁答的、相似度多少、为何采用，全记录，方便复盘和扯皮时有据可依。

三、关键技术挑战与解决思路

最磨人的是一致性校验怎么做。结构化输出好比对，自由文本难。我们对关键字段做抽取后比对，非结构部分用嵌入向量算余弦相似度，设阈值判一致，而不是逐字匹配，这样同义不同表述也能认出来是一回事，误判少很多。

另一个坎是投票的边界。两个模型一致、第三个分歧，多数对，但第三份可能是对的。我们加了一个规则：当相似度都低于阈值，说明三份都不靠谱，直接转人工，不硬投，宁可多一次人审也别放错结论出去，尤其合同金额这种不能错。

还有调用成本。并行调用贵一倍，不能所有请求都投票。我们按业务关键等级分流，只有高敏场景走多模型，普通问答还是单模型，成本可控，钱花在刀刃上，业务方也不会为账单跳脚。

还有一处实操经验，是低置信转人工的阈值怎么定。定太低，几乎全都转人工，模型白跑；定太高，错的结论漏出去。我们按业务后果倒推，合同金额、风控等级这种错了代价大的，阈值定严，普通摘要类的放宽。这个分级让人工兜底真正落在刀刃上，审核同学的工作量也合理。我们也保留了完整的调用轨迹，哪份结论被采用、相似度多少、为什么转人工，全都留痕，万一出问题能立刻回溯，这点对合规和扯皮都重要，业务方也放心把关键场景接进来。灰度时我们刻意留了一批单模型请求做对照，对比投票前后的错误率，数据摆出来业务方才真正信这套方案，不然他们总觉得多跑模型是浪费钱。现在高敏场景已经默认走投票，新上的关键业务直接接这个通道。说实话，调阈值的那两周我们和审核组长吵了不少次，但他给的真实误判案例帮我们把阈值定得更准。

案例片段（已脱敏）： 多模型投票与一致性校验（配置节选）：vote:  models: [primary, fallback_a, fallback_b]  consensus:    field_match: 0.95    embed_cosine: 0.82  on_low_confidence: route_to_human  trace: enabled route_by_sensitivity:    high: vote    normal: single某次合同金额抽取，primary 与 fallback_a 一致、fallback_b 偏差，系统按多数采用并标记分歧，人工复核确认正确；而此前单模型版本曾把数字单位看错，漏过一次，那次是靠客户发现才兜住的。

案例片段（已脱敏）： 某风控场景三模型给出三个不同风险等级，相似度均低于阈值，系统没有硬投，直接转人工。审核同学打开轨迹面板，看到三份结论和各自置信度，结合客户资料三分钟定了级。事后复盘，那笔恰好是模型都没见过的新型欺诈手法，硬投任何一个都会放错，投票在这里真正起到了兜底作用，而不是走形式。

四、效果数据

关键场景结果一致率从单模型约 91% 提升到投票后约 98%，错误拦截率提升明显。人工兜底率从全员兜底降到约 6%，只在真正分歧时出现，审核同学的负担实打实降下来了。高敏场景调用成本约为单模型的 2.1 倍，但覆盖了不到 8% 的请求，整体可控。文中数据为项目复盘口径，已做脱敏。

五、可复用经验总结

关键结果别押宝一个模型，多跑两个比对，分歧大就转人工，比人盯屏幕稳。一致性校验对结构化字段比对、对自由文本用向量相似度，比逐字匹配靠谱。投票要设低置信全转人工的兜底，不能硬投。我们灰度时只做了双模型，遇到三模型分歧的边界 case 还是漏，后来加投票阈值才稳，这一步值得花时间调，别急着全量上线，先在低风险场景验证了再放大。关键场景的准确率，靠的不是单个模型多强，而是让多个模型互相校验，这条路我们还会往自动校准的方向继续走。