什么是大模型的badcase？如何修复大模型的badcase呢？

badcase 定义

首先我们定义什么是大模型的badcase，大模型badcase是指在应用场景中，出现不符合预期的答复。但实际上不符合预期的答复可能多种多样，原因也各不相同，有没有什么统一的思路能处理这些badcase呢？

badcase修复思路

首先在处理badcase流程上有个基本的套路，就是发现问题，总结规律，评估影响，设法修复。这个套路如果泛化一点的话，大概就是解决问题的基本思路。

发现的问题对应着大模型的评估，测试等。基本的发现问题手段有自动化和非自动化的方式，主要体现在样本的构造过程中。非自动化对应着手工测试，标注录入，收集用户反馈等；自动化的方式对应着用户模拟器，固定测试集推断等。有了样本之后，我们进入了第二步，总结规律。

解决badcase问题的关键在于通过归类的方式总结模式和规律，然后在badcase分布下解决关键的几种特定问题，比如典型的幻觉，复读机等。在自己具体的应用场景下，往往有不一样的特殊的要求，比如场景是RAG的应用，会存在检索知识不符合预期等问题。总结规律的方式上可以靠专家经验，对预期之外的结果进行归类，并形成明确的可执行标准，将标准传达给标注团队，进行一定规模的标注分析。

评估影响对应着两方面，一个是问题发生的概率，对应的是步骤二中总结问题的分布。另一方面是badcase对应的严重性，badcase概率乘上badcase严重性就是处理问题的优先级排序。确定好优先级之后，我们就可以按部就班进入第四步，尝试解决。

修复大模型的badcase，从解决问题的方式分类有两种，一种是彻底解决，从大模型生成的机理上削减此类问题发生的概率。另一种是掩盖问题，不在模型的生成的过程中根本解决，通过手段规避发生，事后修复等方法掩盖问题。

重点是第四步，解决对应问题的badcase，我们对这部分进行展开讲解。

实践解法

首先是机理上解决方法，机理上解决对应着大模型训练的四个阶段，预训练，sft，对齐，推断。

属于预训练阶段的问题大概率是难啃的骨头，也对应着大模型能力的上限，解决这些问题并让他生成非兜底的预期答复，基本等同于基座能力的提升，类似gpt3.5提升到gpt4，这也是一种非常通用但是成本非常高，难度非常大的方式。

这类问题典型的比如复读机，在gpt3.5我们还是比较容易触发大模型的复读机行为，但是在4.0几乎就看不到了。

除了此类问题，我们如果针对某些问题有些特定的badcase并不需要提升基座的基础能力，如安全方面用户引诱回答政治敏感类问题。那么我们期望的答复可以简化为兜底的拒绝回答，在sft和对齐阶段都有对应的方案。

sft和对齐阶段对应方案最简单直观的方法就是强化训练数据，让大模型“记住“更多的这种类型的模式，比如构造正确的数据进行强化训练。对应在对齐中，就是使用正例构造reward model的正样本，badcase构造负样本，使用ppo或者dpo等方法强化大模型的认知，这种打补丁的方式对一些模式明显的问题又一定帮助，但复杂的问题还是无能为力。

在推断阶段可以解决的问题，可以分成两类，第一类是生成参数调整上，第二类是通过prompt层面调整解决。

生成参数调整能一定程度上解决一类特定问题，典型的是复读机问题等。复读机问题可以通过生成函数的多样性参数增加多样性，重复惩罚参数等后置概率调整手段一定程度上减轻。当然，复读机问题的本质还是模型训练的“不够好”，最好能在数据，训练，对齐全流程上进行优化，从根本上解决。

prompt调整层面对应的典型方案是使用RAG方案对抗幻觉，RAG方案就是承认基座能力的局限性，也不期望短期通过提升基座能力，从根本上解决大模型幻觉问题，而是给模型更多的“参考信息”，让模型有一定的外部知识储备。除此之外，RAG还有动态更新，外部知识增强的能力，在实际应用上有很多价值。

通过cot，tool use等构建的agent能力也是承认大模型的局限性，一定程度在prompt上给更多的过程提示，工具调用参考等，期望大模型通过任务规划，调用外部工具一定程度上弥补模型能力的不足。

此类方案在大家的探索中都已经演进成为成熟的落地解决方案。

除了通过各种手段解决badcase，模型直接输出正确的内容之外，还有一种线上更实用的前后置处理方案，这类方案在模型的风控和安全上有典型的应用。

比如，模型上线的前后置风控处理上。前置风控主要面向的内容是用户输入prompt的检查上，进行相关的风险评级，可以设定为通过，拒绝回答，通过且增加限制的system prompt等几种典型策略，确保用户输入到大模型的内容不会触发大模型产生不合规，不安全的答复。

后置处理主要面向的内容是大模型的输出，确保大模型输出内容送达用户端的时候保证合规性。最简单的方式为检测大模型输出内容不合规的时候，对输出内容进行整体替换。通常为了保证大模型的交互体验，会流式送达用户端，因此针对大模型输出内容的质检有一定的滞后性，这也是我们在一些产品体验中流式生成一顿后，会整体覆盖替换为另一段固定话术的原因。

整体来看，天下没有免费的午餐，打补丁的方式可以快速解决某类特定的问题，但是想从根本上提高模型能力，应对各种case，又是一个难度和成本都非常高的路径。

审核编辑：刘清