小爱同学与大模型的完美融合：开启智能交互新时代

前言

在当今科技飞速发展的时代，人工智能正逐渐融入我们生活的方方面面。小爱同学作为一款智能助手，凭借其强大的功能和便捷的使用体验，为用户提供了诸多便利。而大模型的出现，更是为小爱同学的发展带来了新的机遇与挑战。

随着大模型浪潮的兴起，各行各业都在积极探索其应用潜力。在小爱同学的产品中，大模型的应用实践尤为关键。它不仅能够提升小爱同学的智能水平，还能为用户带来更加精准、高效的服务。

通过对大模型在意图分发、意图理解和回复生成等方面的深入研究和实践，小爱同学得以更好地理解用户的需求，提供更加个性化的回答。这不仅有助于提高用户的满意度，还能增强用户与小爱同学之间的互动和信任。

在这个充满变革和创新的时代，大模型与小爱同学的结合将为智能助手领域带来新的突破。未来，小爱同学将能够更加智能地处理各种复杂的任务，为用户提供更加优质的服务。让我们一起期待大模型在小爱同学中的应用能够不断取得新的进展，为我们的生活带来更多的惊喜和便利。

小爱同学与大模型的完美融合

在当今科技飞速发展的时代，人工智能已经成为人们生活中不可或缺的一部分。小爱同学作为一款智能助手，凭借其强大的功能和便捷的使用体验，受到了广大用户的喜爱。而大模型的出现，更是为小爱同学的发展带来了新的机遇和挑战。本文将深入解读大模型在小爱同学中的应用实践，探讨其如何为用户带来更加智能、高效的服务。

小爱同学是一款无处不在的 AI 助手，其产品线丰富，包括小爱建议、小爱语音、小爱视觉、小爱翻译和小爱通话等，支持的设备涵盖手机、音箱、电视以及小米汽车等。自 ChatGPT 发布以来，大模型浪潮席卷全球，国内外公司纷纷发力开展大模型相关工作。小米公司也积极思考如何让小爱同学用上并用好大模型，通过多轮讨论，决定利用大模型重新构建小爱同学。这一举措使得产品体验和用户留存得到了大幅提升，活跃用户次日留存提升了 10%，中长尾 query 满足率提升了 8%。

小爱同学的整体架构采用分而治之的思想。当一个 query 到来时，首先会有一个意图分发的大模型对其进行意图分发，判断用户 query 的意图归属，然后将 query 路由到下游各个垂域的 agent 上进行深度理解。这样的架构使得每个垂域的 agent 只关注于自己垂直的意图理解，模型迭代的难度更小，迭代效率更高，能够更好地满足用户的需求。

在大模型意图分发方面，其目的是将用户的 query 准确地分发到相应的垂域 agent 上。然而，这一过程存在两个难点：一是模型需要知识才能正确理解意图，例如区分“打开设置”和“打开空调”的意图；二是耗时要求高，小爱场景意图分发需要控制在 200ms 以内。为了解决这些问题，团队首先尝试了 prompt engineering 的方法，即设定任务并请求大模型输出用户请求中蕴含的意图。但在实践中发现，大模型输出的意图与预定义的意图不一致，且只有百亿级或千亿级的模型才能有效遵循指令，较小的模型倾向于直接回答问题。为了缓解这些问题，团队采用了 few - shot 方法，在 prompt 中定义意图并给出示例 query，但这又带来了输入 token 过多的问题。因此，团队尝试了大模型的微调。

大模型微调分为两步：继续预训练和指令微调。在继续预训练中，利用小爱积累的对话数据和通用训练数据进行预训练，增强大模型对小爱领域知识的理解能力，并保证小爱的数据和通用数据的比例在 10 比 1 到 15 比 1 的范围内。在指令微调中，prompt 较为简单，且没有显示注入意图定义，团队认为模型在微调过程中有能力记住意图定义。通过这样的方式，整个输入的 token 数明显减少。此外，团队还对是否需要继续预训练和 few - shot 进行了尝试，发现继续预训练 + 指令微调可以使评测集准确率提升 2%，训练数据由百万级别降到了万级别，减少了 95%。

在大模型垂域意图理解方面，传统的意图理解方式通常采用 Intent + Slot 的架构，即先进行意图识别，然后进行槽位识别，最后根据识别结果执行回复。而小爱同学大模型采用的是 function calling 的方式。首先，对所有 API 抽象出 function 的定义，包括 API 的功能以及所需参数的描述。当一个 query 到来时，将 query 和 function 的定义一起构造一个 prompt，给到大模型。大模型会判断是否使用预定义的 Function，并在选择某个 function 时给出所需的参数。例如，对于“今天到上海的火车票”这个 query，大模型识别的 function 是 Search_train，并给出参数是 time 和 arrival。然后，会检查槽位是否满足 API 执行的条件，如果满足，则请求 API 得到结果，再给到大模型进行回复；如果不满足，则由大模型直接回复并引导用户补充或澄清。

Function calling 存在一些难点，如如何保证 100%的指令遵循、处理 Function calling 的依赖关系以及解决推理耗时过高的问题。为了保证 100%的指令遵循，团队对大模型进行了微调，方法与意图分发的继续训练模型类似，但不同垂域可以提供不同的继续预训练数据。在处理 Function calling 的依赖关系方面，团队采用了类似 LLMCompiler 的方式，通过 LLM Planner 规划分解子任务，Task Fetching Unit 执行任务获取，Executor 执行任务，以实现多 Function 的并行执行。在解决推理耗时过高的问题上，团队进行了输入优化和推理优化。输入优化包括让大模型记住 function 的定义和参数，以及让每个垂域虚拟一些 function，以提高大模型处理垂域 function 的能力，但这可能导致大模型需要频繁更新且通用性较差。推理优化则包括减少生成的 tokens 数和推理次数，具体方法包括选择高压缩率的底座模型、扩充词表并进行继续训练、进行 token 的替换以及采用投机采样等。通过应用大模型进行意图理解，中长尾 query 满足率提升了 4%，多轮 query 满足率提升了 3%，训练数据减少了 90%。

在大模型回复生成方面，通用大模型回复存在时效性、长上下文理解和指令遵循等问题。为了解决这些问题，团队采用了 RAG 技术，外挂知识库，让大模型基于检索到的知识进行回答。同时，大模型需要具备知识总结、信息抽取、复杂推理、多轮对话和兜底回复等能力。为了保证大模型具备这些能力，团队进行了微调，具体步骤包括优化单能力训练数据、按比例混合训练数据进行指令微调以及构建偏好数据进行对齐训练 DPO。在优化单能力训练数据时，采用更好的大模型进行自动评价，前期评测中大模型评价与人工评价的一致性大概为 80%。在按比例混合训练数据时，找到不同能力的满足率大幅提升到平稳的临界点，以此作为调整的基础，并控制每个能力的数据上限。通过指令微调 + DPO 训练，回复满足率相比单纯的指令微调提升了 2%，相比 prompt engineering 提升了 10%。

未来，小爱同学的发展方向包括探索用一个大模型端到端地满足用户需求，甚至实现由一个多模态大模型进行端到端的理解，无需 ASR 和 TTS，采用一个多模态的 Anything to Anything 的架构，类似 GPT4o 和谷歌 Gemini。此外，团队还在进行端侧大模型的研发，以更好地解决用户隐私问题。

大模型在小爱同学中的应用实践为智能交互带来了新的突破和发展。通过意图分发、意图理解和回复生成等方面的优化，小爱同学能够更好地理解用户的需求，提供更加准确、智能的回答。未来，随着技术的不断进步，小爱同学将继续不断创新和完善，为用户带来更加优质的服务和体验。相信在不久的将来，小爱同学将成为人们生活中更加不可或缺的智能助手，引领智能交互新时代的到来。

参考
https://mp.weixin.qq.com/s/M-agcbwjFC7_ZFglKm8jDg