模型微调怎么解决多轮对话容易受到上轮对话的影响问题

在先前的讨论中，我们主要关注的是单轮问答的情境。然而，在现实世界的对话中，我们往往需要处理连续的多轮对话。在自然的人类语言交流中，多轮对话常常伴随着指代问题的产生，例如使用代词“它”、“他们”、“我们”等。在这种情况下，如果仅仅依据用户的原始提问来检索相关知识片段，可能会导致检索结果的不精确或者无法检索到相关信息。此外，由于我们对模型的回复内容施加了限制，使得模型不再依赖其内部知识库来生成答案，有时这可能会导致多轮对话的流畅性受到影响，甚至出现对话中断的情况。因此，为了提升对话系统的性能和用户体验，我们需要开发提示词来解决多轮对话中的指代消解问题，并确保模型能够在连续的交流中提供准确、连贯的回答。不过，由于“指代消解”需要多轮对话来完成，单次交互是无法达成的（至少目前看来是这样），所以我们需要将测试形式进行转换。首先解决”指代消解“的问题，然后再进行下一轮答复。首先，我们准备指代消解所需的提示词：大家可以看到，这里使用的“指代消解”提示词是使用CoT写出的思维链，我们在这个思维链中列举了不同情况的推理情景，目的就是让模型能够适应并成功推理出需要消解的代词，然后根据消解代词的结果重新组织问题。接着我们开始尝试复现指代消解的步骤：步骤1：进行第一轮对话在第一轮对话中，我们提出问题”尼罗河是什么？“，接着，系统成功召回了关于“尼罗河“的知识片段，并做出了回复。步骤2：开始指代消解

在先前的讨论中，我们主要关注的是单轮问答的情境。然而，在现实世界的对话中，我们往往需要处理连续的多轮对话。在自然的人类语言交流中，多轮对话常常伴随着指代问题的产生，例如使用代词“它”、“他们”、“我们”等。在这种情况下，如果仅仅依据用户的原始提问来检索相关知识片段，可能会导致检索结果的不精确或者无法检索到相关信息。此外，由于我们对模型的回复内容施加了限制，使得模型不再依赖其内部知识库来生成答案，有时这可能会导致多轮对话的流畅性受到影响，甚至出现对话中断的情况。因此，为了提升对话系统的性能和用户体验，我们需要开发提示词来解决多轮对话中的指代消解问题，并确保模型能够在连续的交流中提供准确、连贯的回答。不过，由于“指代消解”需要多轮对话来完成，单次交互是无法达成的（至少目前看来是这样），所以我们需要将测试形式进行转换。首先解决”指代消解“的问题，然后再进行下一轮答复。首先，我们准备指代消解所需的提示词：大家可以看到，这里使用的“指代消解”提示词是使用CoT写出的思维链，我们在这个思维链中列举了不同情况的推理情景，目的就是让模型能够适应并成功推理出需要消解的代词，然后根据消解代词的结果重新组织问题。接着我们开始尝试复现指代消解的步骤：步骤1：进行第一轮对话在第一轮对话中，我们提出问题”尼罗河是什么？“，接着，系统成功召回了关于“尼罗河“的知识片段，并做出了回复。步骤2：开始指代消解

聊天模型通过一串聊天对话作为输入，并返回一个模型生成的消息作为输出。尽管聊天格式的设计是为了多轮对话更简单，但它对于没有任何对话的单轮任务同样有用(例如以前由text-davinci-003等指令遵循模型提供的任务)。下面是一个API调用的例子:messages参数是主要的输入。messages必须是一哥的消息对象(message object)数组，每个对象拥有一个role(“system”,“user”,或“assistant”)和content(消息的内容)。会话可以少至1条消息或者是有许多条。通常，会话首先使用系统消息(“system”)格式化，然后交替使用用户消息(“user”)和助手消息(“assistant”)。系统消息有助于设定助手的行为。在上面的例子中，助手被说明为“你是一个能干的助手”。用户消息帮助指示助手。它们可以由应用的用户生成，也可以由开发者设置为指令。助手消息用于存储之前的响应。它们也可以是由开发者编写用于获取期望响应的示例。当用户的指令是关于之前的消息时，包含聊天历史记录将有所帮助。在前面的例子中，用户最后的问题“在哪里举办的?”只有在前面关于世界职业棒球大赛的上下文中有意义。因为模型不能记住前面的请求，所以全部的相关信息必须在会话中提供。如果会话包含的token超出了模型的限制，则需要用一些方法去缩减会话。