它与“何时”维度特别相关，因为及时响应的能力对于执行许多时间敏感的任务至关重要。 由于对计算资源的需求增加，多用户对话中的响应能力比单用户情况下更具挑战性。 产品设计解决方案需要能够有效管理高消息流量、多个用户的复杂交互以及多线程讨论。
小组成员之间的参与平衡：
在群聊机器人设计中，还要考虑鼓励平衡的成员参与，这与所有 3W 维度相关。 产品设计解决方案需要识别不活跃的用户，确定适当的干预时机，并使用适当的、定制的和非攻击性的语言来鼓励参与。 这样可以解决群体活动的问题，又不会显得突兀和尴尬。
解决冲突：
这与所有 3W 尺寸相关。 产品设计提案应该能够提供建议和摘要，以帮助参与者在投票期间达成一致、解决争议或结束对特定问题的长时间讨论。
上述产品设计中的具体问题举例如下：
设计
面对上述挑战和具体问题，微软研究团队提出了MUCA（多用户聊天）的通用框架。 该框架主要由三部分组成，分别是：
1. 子主题生成器（Sub-）：用于在群聊环境中生成初始子主题
2. 对话分析器（ ）：用于从聊天记录中提取短期和长期特征
3. 对话策略决策者（ ）：用于决定生成响应的策略，包括何时、谁、什么。
下图是MUCA的设计框架
整个设计方案的伪代码如下。 它看起来仍然很抽象，对于大多数人来说一开始很难理解。 没关系。 后面看提示词的结构就明白了。
以上是框架的介绍，接下来介绍三个核心组件。
副主题生成器 (Sub-)
副主题生成器的主要功能是基于用户的输入，包括用户的角色。 对于原主题中的提示，需要深入讨论的部分给出子主题，然后谁更适合参与这个子主题，讨论，给出这样的结果。
为了促进子主题的生成，用户提供初始主题，并且可以选择包括议程（会议场景）、提示和与会者角色。 下图显示了生成器的数据流。 输入提示模板的完整提示，紫色文本表示为占位符，并替换为用户输入的主题、提示和参与者角色，生成 3 个子主题（议程是可选的，示例中未显示）。 副主题生成器在聊天开始前执行一次，并且副主题在整个聊天过程中保持不变。
从提示语中可以看出，这是基于计算机专业背景的学生的小组讨论。 最初讨论的话题是选择攻读博士学位还是硕士学位。 最后产生了三个子主题，分享了大家选择攻读博士或硕士学位的原因，然后讨论了每个选择的职业路径和机会，最后讨论了探索更多可能的选择。
对话分析器 ( )
对话分析器的主要任务是提取和更新有用的长期和短期信号，以帮助话语策略仲裁器模块确定响应的适当对话行为，它由四个模块组成。
1.子主题状态更新模块（Sub-topic）
2.对话特征提取模块（ ）
3.对话历史摘要更新模块（ ）
4. 群体成员特征提取模块（ ）
子主题状态更新模块（Sub-topic）
该模块用于高效更新各个子主题的状态，子主题根据讨论进度定义：未讨论、正在讨论、已充分讨论。 在前面的示例中，生成了三个子主题来选择是否攻读博士学位或硕士学位。 它们用于更新这三个子主题的状态。
详细定义了不同的状态（即未讨论、正在讨论和充分讨论），并且针对不同类型的主题使用不同的定义以避免歧义。 例如，对于目标导向的沟通任务（即决策、解决问题和公开讨论），充分讨论意味着大多数参与者达成共识，而其余参与者没有任何相互冲突的建议。 然而，在闲聊交流的背景下，充分讨论意味着参与者进行与当前子主题密切相关的对话。 尽管每个术语都有精确的定义，但区分正在讨论和充分讨论是很困难的。 为了提高状态更新的准确性，采用了思想链（COT）方法。
该方法首先返回子主题的ID，然后使用当前上下文窗口和之前的摘要来总结每个参与者对具有该ID的子主题的意见。 然后使用摘要来确定讨论是否符合充分讨论的定义。 最后，根据结果更新状态。
以上就是对话分析器完整的数据流的结构。 我用红框圈出了子主题状态更新模块。 可以在提示词结构下分别看到输入和输出：
输入：子主题列表、参与小组成员列表、上下文对话历史、上一个子主题状态、当前对话情况、主题状态定义
输出：
1.更新的子主题id
2. 对于本次主题，每位参与者的观点
3、更新这个id子主题的状态，并以一定的格式输出。
对话特征提取模块（ ）
该子模块提取短期上下文中所有讨论的子主题的特征，并给出接下来可以讨论的主题ID。 这使得整个架构能够跟踪当前的子主题，特别是对于上面提到的多线程。 讨论场景，然后传递给话语政策仲裁者以生成适当的结果。
对话历史摘要更新模块（ ）
该子模块根据长期上下文窗口更新每个子主题中每个参与者的对话历史记录的摘要。 输入考虑了子主题（正在讨论中）、先前的摘要和简短的上下文窗口。
简明摘要由每个子主题下的每个参与者更新和存储，其灵感来自于从存储的消息中提取实体并仅返回当前 run() 中引用的实体的信息。
下游模块不是检索相关消息以根据用户输入的查询生成响应，而是提供简洁的摘要，以节省查询理解和检索的计算成本。 输入输出组件可以从下图中的提示词看出。
群体成员特征提取模块（ ）
与之前基于LLM的子模块不同，该子模块从长期上下文窗口中提取统计特征，包括每个参与者的感叹词频率、总感叹词话语长度和短期上下文。 此外，所提出的参与者特征提取器测量每个参与者参与不同子主题的频率，有效记录他们对这些特定领域的兴趣程度。 这可以作为定制激励措施以提高群组中不活跃人员的参与度的参考。 这些统计数据用于下游子模块（参与鼓励）中，以识别在群体互动中扮演被动角色的参与者，然后为他们提供定制的激励措施以鼓励他们发言。 该子模块还记录从一开始就讨论该子主题的参与者数量以及在短上下文窗口内仍在讨论该子主题的参与者数量。 该数据将用于指示子主题切换。
对话政策决策者 ( )
七种对话行为在对话策略决策者中实现。 作为MUCA架构中与参与者进行通信的控制器，七种对话行为如下图所示。 可以看到这七个对话行为和前面提到的具体问题之间的关系。 关系。
七种对话行为
保留
内嵌式
副主题切换（Sub-topic）
鼓励参与（ ）
倡议概要（ ）
立即回复( )
对话冲突解决（ ）
对话行为的顺序采用启发式设计方法，由一系列触发条件动态确定。 这些触发条件包括主题的热身轮和冷却轮。 对话动作的默认顺序是：
1. 现在私聊 ( )
2. 倡议概要（ ）
3. 鼓励参与（ ）
4. 副主题切换（Sub-topic）
5. 对话冲突解决（ ）
6. 插播
7.保留
在所有符合触发条件的对话行为中选择排名最高的对话行为执行。
立即回复()
团队成员可以直接在 MUCA 架构内进行交互，并充当个人用户的支持助理，解决他们的特定请求并根据需要提供帮助。 该对话框行为始终具有最高优先级，一旦用户@就会立即响应，无论执行周期如何。 这和我之前介绍的逻辑是一样的，现在已经在开源项目中得到支持，并且会被引入到群组中。 因此，它没有预热和冷却循环，当最后一句匹配@（不区分大小写）关键字时，就满足其触发条件。 即使是立即回复，也需要考虑到当前的一系列上下文背景信息，并尽量优化提示词，避免产生幻觉。提示词设计如下图
倡议概要 ( )
这种会话行为使得跨参与者和子主题的碎片消息能够生成简洁的摘要，提供有洞察力的句子，以便更清晰地掌握讨论，触发条件是自上次触发以来已经有足够的消息 参与者主动参与的场景加入讨论是启发式设计的。
鼓励参与 ( )
这种对话行为旨在吸引声音较小的群体成员，并促进对话中的平衡贡献。 它利用来自组成员特征提取器的统计特征（例如，中断频率freq、话语总长度len）来识别在长期和短期上下文窗口中很少说话的参与者。 将参与者识别为潜伏者的过程是保守的。 仅当参与者的频率和长度显着低于长期上下文窗口中的平均值并且他们在短期上下文窗口中很少说话时，才被视为潜伏者。 这里的结果将通过两个公式计算。
我不会详细解释这个公式。 这里的一些参数是通过实验获得的，论文没有详细描述它们是如何获得的。 在实际的产品设计中，我觉得你可以自己调试这些参数，看看效果。
此外，它将热身轮次设置为 w = 3 * Np，每个参与者的冷却轮次随着每次触发而线性增加：c(x) j+1 = 2 + c(x) j。 这种方法可确保喜欢保持沉默的用户不会不断被提示参与聊天。 该产品架构旨在通过考虑从参与者特征中提取的潜在不活跃成员的聊天历史和感叹状态来生成个性化消息。
以下是详细的提示词结构，供参考。
副主题切换（Sub-topic）
当对话达到用户已充分讨论当前主题或大多数用户不再感兴趣时，这种对话行为使得能够在 MUCA 架构下引入新的且高度相关的主题。 触发话题切换的会话行为的条件有两类：
(1) 少于一半的参与者讨论了当前的子主题
（2）超过一半的参与者正在讨论当前的子主题，但只有少数人在短期、短期上下文窗口中讨论过：Ned >= Np/2 且 Ning < Ned/2。 其预热轮和冷却轮分别设置为w = 5 * Np和c = 7 * Np。 这些是特定的参数设置，可以针对不同的产品主题类型进行专门调整。
但引入新的子主题可能会扰乱对话的流程，并可能使讨论脱轨，因此请进行更多测试。
从下面的提示词结构可以看出，触发条件有两种
对话冲突解决 ( )
这种对话行为有助于参与者及时达成共识，从而提供高效的讨论过程。 不是在上一次对话中为每项任务设定时间限制，而是提出建议，帮助不同意见的各方达成共识，同时也提出下一步讨论的主题。 想要达到这样的效果肯定很难，所以笔者这里就不给出提示词的示例模板了。 想想现实生活中，你的同事很难说服两个观点不同的人达成共识。 虽然论文没有提供提示词设计，但确实提供了一些结果示例。
左边的人试图通过引导用户以他或她自己的意见来解决冲突，这是非常误导和偏见的，更糟糕的是在给出他或她自己的意见后转向另一个主题，这可能会惹恼用户，因为它破坏了用户的利益。对话流程。
右边总结了双方之间的冲突，并提出了一些具有挑战性的问题，供人们深入思考，并在可能的情况下解决冲突。
内嵌式
MUCA 架构的自动感叹对话功能通过提供见解、推进有问题的聊天场景以及解决参与者的担忧来增强对话深度。 这种中断的触发条件是中断概率（P-chime）参数>0.45阈值。影响中断概率的因素有两个
1、沉默因子概率（）：随着连续沉默回合数的增加而增加（见公式3）。 因此，当聊天机器人沉默多轮时，它插话的概率就更高。
2. 语义因素概率（）：它与由于重复的话语或聊天机器人必须解决的未解决的问题而导致对话陷入困境的情况相关。 群组成员之间交换的问题和疑虑不构成聊天机器人未解决的问题。 意味着谈话陷入僵局，意味着有问题没有解决。 值的范围是0-1。
最终的钟声概率（P-chime）根据以下公式计算，取两者的平均值
这应该是对话行为中最重要、最复杂的行为。 主要难点在于合适的触发时间，也就是前面的
提到了两个触发因素。
下面是提示词结构，主要解决触发后的who、what问题。
保持安静
这种对话行为可以避免过度响应，从而防止多用户设置中的刺激。 当不满足其他对话行为的触发条件时，“保持沉默”会自动激活，保持对话流畅，不会分散参与者的注意力。
总结：在对话政策决策者部分，会不会出现多种行为同时满足的情况？ 如果是的话，按照默认的优先级，至少应该有这样的策略。
案例评价
人工智能相关产品设计方案与传统互联网产品设计最大的区别在于，产品设计方案需要有评估方案，或者评估本身就是产品方案的组成部分。 就群聊助手而言，不可能不经过评价就直接交给用户。 如果让测试人员测试，只能测试很小的范围，很难给出有效的测试结果，并且在聊天机器人或机器学习代理与真实用户交互的对话系统设置中收集交互信息以进行进一步训练或者测试可能既昂贵又耗时。
多用户仿真系统（MUS）的设计
因此，AI测试解决方案往往需要设计一个模拟系统，或者使用LLM生成更大的测试集来测试AI用户。 该方案还设计了用户模拟系统来评估群聊助手。 下图是MUS（多用户）的架构图。
以下是模拟系统的伪代码：
这对大多数人来说可能显得太费劲，不过没关系，看了最后的提示词你就明白了。
从上图可以看出，仿真系统由两个模块组成：
1.用户行为模拟模块（User）
2.用户对话生成模块（User）
用户行为模拟模块（User）
从实际用户对话日志中选择三个聊天片段（C），每个包含10-30轮。 为了定义话语内容和方言，预先确定了 11 个说话角色（Sr）和 10 个话语特征（Ut）。 例如，作为说话角色的提问者是指根据给定上下文提出问题的人，而作为言语特征的简洁性是指使用尽可能少的单词来表达一个想法。 事实上，它本质上是基于LLM的几次射击生成。 以下是用户行为模拟模块的提示词结构。
除此之外，使用从150轮群聊得出的最小长度lmin、最大长度lmax和平均长度lavg来模拟每个虚拟参与者的话语长度（即字数）的对数正态分布。
为每个虚拟与会者定制用户行为模拟模块并离线初始化。 该模块以真实用户的历史数据为参考，控制话语的内容和习惯用语，以保持虚拟参与者之间行为的一致。 可以说是非IP角色扮演。 需要的是群聊中的角色和表达方式。 专业。
用户对话生成模块（User）
角色的角色和说话特征是在用户行为模拟模块中生成的。 在此基础上，该模块开始根据主题生成具体的对话内容。 以下为生成具体对话内容的提示词。
上图左侧提示词的目的是按照规则输出接下来应该发言的与会者姓名。
上图右侧根据规则生成下一轮的对话内容。
实验评价
案例研究和用户研究主要是为了检验 MUCA 架构的 在具有各种讨论主题和群组规模的群组对话中的性能。 基线比较对象是GPT4。 案例研究描述了解决方案设计的客观优势，而用户研究则展示了MUCA的主观优势，这些优势很容易被用户识别。
团体规模
建立用户模拟系统后，可以通过将其连接到先前设计的系统来对其进行评估。 论文中，作者构建了两种不同规模的群聊，一种是4人群聊，另一种是8人群聊。
小组话题
尽管所提出的 MUCA 被设计为通用框架，但该评估侧重于 4 个目标导向的沟通任务（即估计、决策、解决问题和公开讨论），而不是闲聊或开玩笑。 通过设计评估基准，可以在面向目标的通信任务中更好地体现多用户聊天机器人的重要性。
案例分析
主要研究对象是多用户聊天助手的对话行为，分别研究了7个案例的对话行为。
1. 现在私聊 ( )
2. 倡议概要（ ）
3. 鼓励参与（ ）
4. 副主题切换（Sub-topic）
5. 对话冲突解决（ ）
6. 插播
7.保留
不赘述，针对不同的用户群进行了测试，以证明其有效性。
用户研究
为了评估 MUCA 的有效性，对 3 组参与者进行了用户研究，即两组小型组（4 人）和一组中型组（8 人）。 （每组男女：1：1）。 选择了两个具有代表性的目标导向主题进行用户研究。
对于小规模小组实验，主要任务是将所提出的聊天机器人（-small）与基线聊天机器人（-GPT4）进行比较。
评估中主要从打断时间、打断内容、参与鼓励三个维度进行比较。 以下是基于人工评估结果的统计数据。
在中断时间方面，MUCA的时序比简单的GPT4要好。
感叹词内容也比较贴切
TopA 在鼓励参与方面表现较好，而 topB 表现较差。
评估人员还对这两个聊天机器人的效率、一致性和实用性进行了评分。
• 效率：聊天机器人响应及时；
• 简单性：聊天机器人对关键点进行响应，没有冗余；
• 实用性：聊天机器人的响应很有帮助或富有洞察力。
从上面的分数可以看出，MUCA 在大多数情况下取得了明显更高的分数。
思考
1、群聊AI助手的需求和场景是真实的，但其实现的前提是开发者能够获取完整的群聊记录内容。
2、群聊助手解决方案相对完整，但由于实际落地并嵌入到社交场景中，更大的问题是成本和隐私问题。 如果手机厂商内置了小型号，是否可以将其中一些集成到系统中？ 工作放到本地模型中，复杂的工作放到云端大模型中执行。 它被设计为混合架构，在成本、隐私和效果上实现了兼容。
3.用户模拟系统（MUS）的扩展。 在生成式人工智能应用的评估中，通过用户模拟系统进行评估是一种新的测试范式。 不可避免的，这就是与传统互联网功能应用最大的区别。 不同之处在于，此类用户模拟系统可以针对不同的场景而构建。
4、效果评估中，常采用领先模型进行基线比较。 这种比较在实际产品中的适用性值得怀疑。 如果基线指标与真实可用性相差甚远，即使比基线指标更好，对于实际产品来说也是不实用的。 对于产品来说，并没有多大意义，所以在实际的AI产品中，如何构建和确定针对真实场景的可用性指标是一个难题。 因此，通常的做法是首先使用大量的人工评估，确认人工评估的有效性，然后训练评估机器人来替代人工评估。 其实这就是open ai所做的比对工作，所以如果我们再拓展一点思路，特定场景下的AI应用在评估阶段就会有该场景的比对过程。
