提升大模型系统体验的一些思路

在大模型为主题的这个技术版本，通过一些信息的输入或者是prompt的调整，让模型基本就可以朝着我们预期的结果方向输出了，然而凡事终有上限，大模型显然不能解决所有问题，因此现版本在了解大模型上限的情况下，一个以大模型为中心或者是结合了大模型的系统可能是一个更加合适的选择，我们可以以大模型为起点逐步拆解大模型功能或者是增加更多地辅助模块来配合大模型生成，也可以在原有系统中，加入大模型，使之能在系统中产生新的化学反应，或产生新的功能，或带来新的优化。

考虑到目前很多大模型项目其实都是围绕大模型逐步发展迭代而来，本期我给大家讲一些能让大模型系统效果和体验提升的一些思路方案。

场景划分

在大模型做得多了以后，或多或少都会面临以下几个问题：

• 有些问题不希望模型回复，或者希望模型用特定的方式回复。
• 不同的问题，希望模型使用不同的策略来回复。
• 某些问题，模型回复的不好，我手里有正确答案，希望他能用我这个内容来回复。
• 需要针对某一种领域进行专项的、有针对性的回复，但在此之前需要把这类型的问题先划分出来。

这里其实都会面临一个很重要的问题，那就是——边界。重述一下问题，在特定情况下，我们如果希望模型按照特定某种特殊的方案策略进行回复，此时我们需要一个模块（注意这里我用的是模块，稍后说），来鉴别在用户说什么内容的情况下触发这类回复策略。在上一个版本，即没有“大模型”有关技术的大环境下，通常是搜索或者是对话系统场景，我们会把这种划分的任务叫做意图识别，而抽象成NLP任务那就是文本分类。

此时，这里引出了第一个大模型系统中，可能需要的利用到的模块，即意图识别模块。

来举个例子。客服场景，用户有一类型高频问题就是售后维修的问题，因为客诉比较严重，所以需要针对这个领域的问题进行针对性的优化，甚至是一些定制型的优化，例如需要增加安抚话术等，因此我们需要增加一个意图识别模块，首先保证这类预期得到优化的query能被识别出来。

识别的方式其实挺多的，需要结合query的主要特点、训练数据、性能要求等原因来进行选择了，这也是为什么我这里严谨的说是模块，因为真不只是模型能够解决所有问题，常见的有这些：

• 基于规则、关键词、正则表达式的快速划分。
• fasttext、textcnn、bertforclassification等经典而又常用的分类方法。
• 基于检索的以搜代分方法（心法利器[26] | 以搜代分：文本多分类新思路）。
• 大模型通过prompt构造分类器。

拥有划分方法后，我们可以结合划分场景的特点，定制不同的回复策略。

回复策略的制定

对话系统，只要做的足够精细，针对不同场景，就会需要考虑不同的回复策略，这也是为什么上面要聊意图识别的理由，而在划分场景后，就可以开始定制每一种意图的回复策略。我来举一些列子给大家解释一下不同的回复策略，协助大家打开思路吧。

拒绝回复

拒绝回复其实很多场景会应用到，例如在面对用户提问的内容并不是目前我们预期支持的领域（客服场景问天气），或者用户所问出现观点类（如何看待俄乌问题）、黄反类问题（这个就不用我举例了吧）、大模型安全（query中带有诱导性错误）时，再就是知识库为空的情况，我们就需要进行拒绝，并给用户一些回复，让用户不至于那么不舒服。常见的策略一般有这些：

• 一句写死的回复：“哎呀，这方面的问题我还不太懂，需要学习下”。
• 用大模型生成，例如借助prompt引导生成一些安抚性的回复，“对不起，你问的[]问题，我好像还不太懂。你可以试试问问别的”。
• 使用推荐问或者追问的策略。（你是否在找以下几个问题XX；你描述的我好像不太懂，能再补充补充吗）

其实也可以看到，也不见得非得用大模型，有时候写死或者做一些推荐问疑似问（前沿重器[12] | 美团搜索引导技术启示），好像也可以。

拆解用户提问后的回复

用户的提问往往蕴含众多信息，我们可以仔细解析用户提问的内容，然后配以适当的策略，来生成合适的回复，举几个例子：

• 客服场景，可能有用户的投诉抱怨，我们可以先识别出用户的情绪（情绪识别），然后借助角色假设、语气等指令，给出一个带有安抚性质的回复。
• 某些特定问题，可能有十分重要的关键词，我们必须重复强调，因此我们可以提前提取关键词，然后告诉大模型，必须提及这些词汇。
• 为应对不同端的用户需求，可能需要对详细程度进行约束，例如手机端就尽量简单，电脑端可以更丰富。
• 手机端场景，一个类似“播放音乐”的指令，此时除了要给出生成的文字回复（甚至也可以写死），更重要的是生成一个json的接口以便调起手机端软件并播放对应的音乐。

这里可以看到，一方面，我们需要识别出用户提问中带有的各种信息，另一方面我们可以通过prompt等方式，来控制大模型的生成回复，从而形成了很强的多样性。

多轮

多轮应该是很多对话场景面临的关键难题了，而多轮的根本难题在于，如何把关键信息保留并在合适的时间取出并使用。目前的大家可能用的比较多的是直接拼接历史对话，这点并非不好，凭借大模型的能力确实能做到很高程度的多轮对话，但实际上，我们还是可以用很多思路：

• 简单的，可能并不需要考虑模型回复的内容，只需要拼接用户query。
• 单独构造DM模块，结合NER做槽位继承。
• 参考科研界的一些做法，做更加抽象的矩阵DM，然后配合大模型计算。

可见，从大模型中把DM释放出来，可以定制出适合这个场景的对话管理来，可控性可定制性也会更强。有关多轮，我之前也有文章聊过，虽然感觉深度还不太够，不过参考下应该还是有用的：前沿重器[25] | 聊聊对话系统：多轮对话。

知识依赖

要让大模型解决特定领域的问题，总有一个非常重要的痛点，那就是知识的问题，尽管大模型在通用知识里面已经表现出惊人的能力，但在特定领域上，或者对新的知识，非常容易出问题，目前而言常见的解决方案是两种：

• 微调，通过领域知识点或者领域文档数据，对大模型进行微调。
• 外挂知识库，通过检索，获取topN知识点，加入到prompt中，协助模型进行回复生成。

对后者，其实我们已经在无疑是地在对模型的功能进行拆解了，原本预期是大模型是有知识的维护和处理能力的，但实际上我们把知识的维护和处理已经拆解出来了。

进一步，既然拆了出来，那其实就有广阔的调整空间了。因为拆出来的任务，就是一个知识库查询，而有关知识库查询的这块的技术，一方面是对话系统的检索式对话，另一方面是经典的搜索，其实都已经在这块积累了大量的经验，内部可以有提槽、意图、多路召回、精排之类的复杂策略，很早的时候有一篇文章对这块内容做了概述，大家可以参考（R&S[21] | 搜索中涉及的算法问题），目前视角看这个总结的依旧是比较全的。

小结

这篇文章可以说是（心法利器[98] | 除了训练，大模型还有很多重要工作）的后续，再告诉大家可以做很多事之后，告诉了大家怎么做，有哪些可以尝试优化的方法，从而把比较统一的大模型升级为功能更完善也更健壮可控的大模型系统。

另外大家应该也可以看到，整个过程其实都在试图压缩大模型的空间，从大模型中拆出来让其他模块专门做各自最擅长的事，我个人的理解这是一个做应用的重要方向，与其对着大模型经常做训练来应对不同的复杂场景，不如逐步把大模型沉淀成统一、稳定的能力，让他在更多地方用起来。正好也预告下一篇，我会给大家介绍一下我理解的大模型在整个成熟系统中的位置和整体架构情况。

我是朋克又极客的AI算法小姐姐rumor北航本硕，NLP算法工程师，谷歌开发者专家欢迎关注我，带你学习带你肝一起在人工智能时代旋转跳跃眨巴眼