这个大模型Badcase修复方案，我服！

工作以后，对于做业务的同学，一个避免不了的话题就是“badcase”，在大模型时代，当然也是避免不了的问题。

对于很多没接触过实际业务的同学可能认为大模型足够强，强到可以很好的 fit 用户的所有需求，就算 fit 不了，也可以微调模型来解决。

但实际情况是怎样呢？其实不管是大模型，还是专有领域小模型，一定存会各式各样模型解决不了的 badcase。

具体原因很多，以智能客服系统为例，用户的咨询分布也符合二八原则，即用户 80% 的咨询问题主要是集中在 20% 的知识点中；

针对用户 20% 长尾知识咨询，一般采用 AI 模型手段解决，这个部分是比较好处理的。那剩下的 20% 的问题覆盖了 80% 的知识点，就属于长尾问题了。

这部分出现频率低，数据量不足，模型也不易学习到。长尾不代表不重要，但是却很难优化，线上出的 badcase 也经常属于这部分。

那线上大模型服务报了 badcase，如何解决呢？

我结合自己的经验，总结主要有以下 4 个思路：

• 加前置模块
• 加后处理
• 调 prompt
• 模型微调优化

最直接方式就是加前处理。具体来说就是在进入大模型前，做一级或者多级前置模块。

实际业务系统中，会呈现一个漏斗形，最前面是高频话术缓存，用户的问题会被逐级过滤和筛选。高频简单的问题会被优先处理掉，直接返回。

这部分的模块具有几个很明显的特点：

• 精度高
• 速度快
• 模型/规则简单

所以针对某些 badcase，可以直接在这一层做掉，如果命中，直接加 trigger 返回。

我给大家举几个例子：

（1）比如用户的 query 可能会出现一些敏感话题或词语，这种情况是不能进大模型。

如果敏感词检测模型也没有拦住，往往会在前面加一个拒识模块，问题可以及时 hotfix。

（2）有时候会出现地域性方言或者当地口语的话术，query 改写没兜住，意图识别没兜住，大模型也没兜住，怎么办？

第一类加前置处理。结合一些泛化手段，这个在平时工作中会总结出一套完整流程，从种子语料，query 泛化，到线上自动配置化，基本能做到只需要少量人工参与的快速 fix。

第二类方法是后处理。为了方便理解，我也给大家举个例子。

比如大模型被人熟知的输出会有“幻觉”，甚至出现一些不可控的话题。这种比较好的方案就是在后面加一个处理模块来二次过滤。

根据不可控的内容来构建检索规则，直接对这种话术过滤删掉，快速修复，保证产品的安全性。

第三类方法是调 prompt。这种方案一般是在 bug 不太紧急的情况下使用，不要求立即 fix。

例如有些场景对输出话术有要求，比如必须要回答上关键要点，比如机器人的人设不能偏离，保证一致性等。

在线下多次测试已经 OK 了，但推到线上发现了漏网之鱼，这种就可以通过调 prompt 来解决，这个过程比较长，也需要经验，所以一般不会很高效。

最后一类方案才是微调模型。是不是跟大家想象得不太一样？

把这个方案放到最后，原因有两点：

• 重新训练模型，时间比较长，可能需要多次调优。
• 对原有结果有影响，线上系统一般比较复杂，比如修复了 A，影响了 B，出现跷跷板的情况

所以，一般是有大版本升级的情况，才会更新模型。工作中，1，2，3 类的 badcase 会累积整理，累计到一个周期以后，再微调优化模型，然后经过严格的冒烟测试，回归测试和灰度测试以后，才发布到线上。

最后做一个总结吧，线上问题多种多样，科技含量最高的方案不一定是最好的，实际处理时要考虑几个方面，问题的紧急性，是否对现有模块有影响，修复所费的成本，对系统的负担等。

“奥卡姆剃刀”是合适的指导准则，复杂不一定是最好的，即思维经济性原则，如无必要，勿增实体。

本文转载自 ​​丁师兄大模型​​，作者： 丁师兄