一、项目背景

我们把大模型接进客服和写作两个场景，一开始图省事，模型吐什么前端就用什么，觉得大模型够聪明不会出错。没几天就出问题：有的回答跑题，有的整段乱码，还有明显的事实错，比如把流程步骤写反。人工抽检根本覆盖不到全量，差结果流到用户面前才被发现，回滚都来不及，因为已经展示出去了。运营找来说投诉涨了，我们才意识到模型输出不能直接裸用，得在出口加一道闸，而不是等出了事再救，那时候影响已经造成，品牌口碑也搭进去了。我们拉了两周的客诉，至少有一成是模型抽风导致的，这种事故不是概率问题，是必然会发生，只是早晚，这让我们下定决心做质量门。

二、落地场景

我们在推理出口加了一层结果质量门。模型输出先过一个轻量打分模型，给流畅度、相关度、事实一致性打几分，打分和主模型输出同步走不额外等。分数低于阈值的判为低质，自动拦截并触发重试或用兜底话术，用户看到的是正常回复而不是乱码。质量数据进看板，按场景和模型维度统计低质率，哪个场景差答案多一眼能看见。badcase 回流到评测集，用来迭代打分模型本身，门也会越用越准。整套门对调用方透明，正常结果不受影响，只有低质的才被拦，用户侧几乎无感，体验反而更稳，投诉也少了，运营终于敢把模型 answer 直接挂到首页，不再先过人工。写作场景里我们给质量门接了场景化阈值，营销稿和客服问答用不同的拦截线，营销稿容错低卡得紧，闲聊类放得宽，一套门多套尺度。badcase 回流不是全量，我们只挑被拦截里人工判为误杀的样本进评测集，打分模型迭代不被噪声带偏。运营后来把质量门的拦截明细开放给内容团队，哪类选题容易出低质答案一目了然，写 prompt 的时候就有意识避开，源头质量也跟着上来了。

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

实时打分开销是第一道关。打分模型不能比主模型还慢，我们用了小模型加规则混合，主模型边出边打分，基本不增加端到端延迟，用户感知不到这道门的存在。误杀和漏杀是核心矛盾：阈值紧了正常回答被拦，松了差答案漏过去，两头都不好。我们的做法是分层打分，跑题和乱码这类明显错的硬拦，事实类存疑的降级提醒而不是一棍子打死，给用户一个兜底答案总比没有强。低质重试要限次，避免重试也失败还拉长延迟，我们设了最多一次重试。质量可观测靠把每一次拦截记进看板，哪类低质多一眼能看见，方便回头调阈值。这里踩过坑，第一版阈值设得太紧，把一些口语化但正确的回答也拦了，客服以为系统坏了，后来放宽常见误报才正常，阈值要贴着真实分布走，不能拿训练集的指标直接套线上。

案例片段（已脱敏）： 输出质量打分与拦截配置（示意）： score.model: small_classifier score.streaming: true block.threshold: 0.35 retry.max: 1 fallback.on_low: true 某客服线低质拦截率约 4.2%，其中误杀率控制在 0.6% 以内，前端投诉下降约三成，重试救回率约八成。

四、效果数据

我们主要看低质拦截率、误杀率、重试成功率和前端投诉率。低质拦截率稳定在百分之四左右，说明大部分差答案被拦在出口，没流到用户那；误杀率压到千分之六以内，没有误伤正常回答，客服也不再报"系统坏了"；重试成功率约八成，拦下后能救回大部分，不用走兜底；前端投诉率下降约三成，运营终于敢把模型 answer 直接挂到首页了。我们把拦截出来的 badcase 按场景做了归因看板，内容团队每周看一眼就知道哪类 prompt 容易翻车，写稿时主动规避，源头低质率又降了一截，质量门的压力也小了。这套拦截、归因、改稿的小闭环跑顺之后，我们基本不再靠人工抽检，运营也敢把模型输出直接对外，信任是一步步攒出来的。

文中数据为项目复盘口径，实际值会随模型版本波动，每次换模型我们都重测一遍阈值。运营那边最大的感受是"终于不用提心吊胆看模型抽风了"，半夜也不再被叫起来处理投诉，团队松了口气，连带着对模型本身的信任也回来了。

五、可复用经验总结

模型输出接生产环境，出口加一道质量门几乎是必要的，别信它每次都对，再强的模型也有抽风的时候，线上不怕一万就怕万一。打分用小模型加规则混合，别让质量门自己变成瓶颈，门比主模型慢就本末倒置了，用户体验反而更差。阈值是最难调的，紧了误杀松了漏杀，我们的经验是先宽后紧，靠 badcase 慢慢收，别一上来就从严把正常回答误伤了。我倾向于把事实类存疑的降级而不是硬拦，因为硬拦容易误伤，降级至少给个答案。做生成类应用的，把拦截数据和投诉对起来看，比单纯看模型 benchmark 实在，线上表现才是真指标，benchmark 再好上线翻车也没用。