心法利器[131] | 盘点踩过大模型多轮对话的坑 - 文章 - 开发者社区

心法利器

本栏目主要和大家一起讨论近期自己学习的心得和体会。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。

2023年新的文章合集已经发布，获取方式看这里：又添十万字-CS的陋室2023年文章合集来袭，更有历史文章合集，欢迎下载。

往期回顾

众所周知，大模型是具备多轮回复能力的，因此应该很多人会对他有很高的期待，也开始进行尝试，然而随着逐渐做的深入，会发现很多问题，下面我盘点一下大模型做多轮对话过程可能会遇到的问题以及可能的解决方案。

问题会比较零散，我直接以章节分点进行逐个讲解。

前置信息的预设
长多轮的遗忘问题
强流程要求下的对话管理
过分信任大模型
可迭代和可维护性
小结

这里做个先修的补充，对于对话系统，尤其是多轮对话系统并不了解的同学，可以参考我的这个系列文章：前沿重器[21-25] | 合集：两万字聊对话系统，尤其是这篇：前沿重器[25] | 聊聊对话系统：多轮对话。虽说文章有些老，但现在回头看很多思想仍然非常有必要树立起来。

前置信息的预设

大量对话都需要有前置的信息，例如对话所处的背景场景、对话人的人设、目标等，很多时候生成的对话内容，不符合我们的预期，更多是因为我们没有为大模型提供让其满足我们要求的信息和描述，当且仅当模型拥有足够完善的信息，模型才能完美按照我们的要求进行对话。

举个例子，涉及知识问答的对话，包括追问，对于大模型不知道的知识，通过RAG往往能比较容易获得，此时嵌入RAG能帮助大模型更好地应对各种问题。

再补充一个例子，对于有明显人设的对话，我们需要再prompt里增加对人设的定义，例如“6岁的小男孩”、“专业的手机客服”、“友好的志愿者”等，亦或者提供一些对方的信息，例如“面对的是一名年老，对业务并不了解的客人”、“一位资深的老油条”，在比较强的大模型下，能更加从容地应对各种问题。

再再说一个例子，帮助大家更好地理解，有某些带有特定目的的主动沟通，例如推销等，如果有预先了解的用户画像、推销策略，在放入后的效果会非常明显。

长多轮的遗忘问题

首先要有一个正确的理解，大模型能吃下很长的长度，不代表长度长了效果还能稳定保持，长度长了以后的效果衰减是非常明显的，尤其是在对前面信息的记忆部分，类似人设、前置信息等，很容易忘记，用比较直白的话说就是容易“原形毕露”，回到大模型比较原始的人设上，同时容易忘记一些前面谈到的内容，针对这种问题，要考虑做这几件事。

首先，不要任由对话无休止进行，全都扔进大模型，扔进大模型的轮数要有截断，做好移动窗口。
第二，每隔N段，都要复述原有的前置信息，避免遗忘，一般短期几轮内，大模型确实不容易遗忘，并不需要担心。
第三，前面的对话内容，会因为移动窗口而被屏蔽，大模型不可见，因此对前面的对话内容，要做必要的摘要，放到前置模块信息里，甚至要对重要的信息结构化。

强业务需求下的对话管理

前文有提到（前沿重器[25] | 聊聊对话系统：多轮对话），对话管理这个事在多轮对话里非常重要，而在大模型的场景下，经过实验同样发现，对话管理依旧很重要，尤其是业务场景对流程推进的规范性比较高，或者是本身对话主动性要求比较足的场景，我说这么几个我感受到的原因：

大模型对流程的理解并不敏感，无论是直接通过prompt，还是进行过SFT的训练，简单的对话数据无法让模型学到流程。
大模型并不能直观感受目前对话处于什么阶段，尤其是做过移动窗口切分后的对话。
大模型无法主动推进对话的进度，例如用户回复“嗯嗯”、“好的”之类的话术时，大模型往往会手足无措。

因此，借助可靠完善的对话管理模块，是非常有必要的，对话管理的详细内容，大家可以先参考这篇：前沿重器[25] | 聊聊对话系统：多轮对话，在此基础上，我继续聊，在大模型场景下可以做的更多的事：

现在说法应该叫做路由，他可以比一般的意图识别的外延要更多（按需吧），借助路由的方式是可以引导大模型给出特定的回复的，这个路由的依据可以是目前客户的意图（Intent）、对话目前所在阶段（Dialogue State）、下一步的对话策略（Dialogue Policy）。
大胆拆解大模型的功能。在之前的一篇文章里（前沿重器[37] | 大模型对任务型对话的作用研究），有提及某些功能是可以拆解的，例如query理解、阶段识别、槽位抽取、对话策略、话术生产等，不要让大模型一次性完成所有的功能，分步逐步完成。
更进一步，别拘泥于大模型本身，要完成拆解后的多个任务，并非都需要大模型，各个任务可以配合自己的需求来做，例如槽位抽取，用大模型做baseline可以，但是训练一个小模型并非不能做，甚至有很多优势。

对话管理模块相当于把整个流程的把控都从原有的端到端大模型中拆解出来，除了有利于整体流程的把控，还对后续会提到的可迭代和可维护性有很大帮助。

在过分信任大模型

在做agent的时候，很容易陷入一个误区，过分相信大模型，即使是拆解，也让大模型把所有任务都完成，这其实会有很多风险，请大家都要留意。

评测误区。切忌测几个简单或者复杂的case就认为没问题，直接上线，至少准备100个样本，样本尽量覆盖各种情况。
过程监控。如果中间使用大模型的次数比较多，注意多个任务都需要进行评测，尽量不偷懒，对整个过程和流程都有把控。
性能监控。耗时、并发，都需要有严格的把控和评估，整个流程搞定要等个几分钟，体验肯定很差。
大模型生成内容安全。注意对大模型内容的质检，无论是用户的输入还是大模型的输出，都需要关注，监控好用户诱导大模型生成问题内容的行为，以及大模型生成内容的质量，确保大模型生成内容的安全性。

可迭代和可维护性

多轮对话系统的建设，往往不是一蹴而就的，中间会有大量横向拓展和纵向深度优化的需求，如果整个多轮对话系统内的元素过于单一，则整个系统的迭代灵活性会大打折扣。举一个例子，多轮对话往往需要应对很多不同的问题，每个迭代周期增加几个，从无到有逐步完善，如果整个系统内只有一个大模型，随着功能变多，要不就是prompt越来越长，要不就是不断微调，无论是前者还是后者，都会对原有功能造成影响，甚至很难维持多个功能的正常运行，因此，在设计过程，需要提前考虑这些问题，确保系统安稳迭代，避免形成算法特有的技术债。

最常见的方式就是进行模块的拆分和适配，考虑在上游进行拆解，拆解后通过意图识别的方式来进行分流，这个模式其实就和agent一样，把多个事拆解成多个agent分别解决，通过路由来进行分流和调度。此时，每当增加新功能，只需要挂载新的路由，借助新的agent专项解决特定问题，多个agent质检形成互不影响的关系，从而能减轻每次拓展所带来的对其他功能的影响。

多轮，随着轮数变长和业务场景变复杂，需要维护的流程和agent会变多，可以再行考虑把更新频次不高的部分逐步合并，或者是通过更灵活的方式梳理好。

小结

本文主要是总结一些在用大模型进行多轮对话时遇到的坑，无一例外都在指向一个点，至少现在的大模型技术下，无法很轻易地通过一个通用的大模型，端到端地贯穿整个系统，

picture.image