引言
设想一下，当你学习新的课程或面对挑战性的概念时，身边始终有一位虚拟学习伙伴，随时为你答疑解惑、总结课程要点、或者进行知识点测验。这不再是遥远的未来设想，而是借助 Udemy AI助手 已经实现的现实。这款AI助手基于先进的人工智能技术，正积极地帮助全球各地的学习者，引导他们一步一个脚印地完成技能提升之旅，使学习过程更加流畅、快捷和个性化。而这一切智能、相关性强的辅助功能背后，都依赖于一个至关重要的能力：准确理解学习者的真实意图。无论是课程相关的疑问、讲座内容总结，还是其他问题，AI助手 必须能够精准地把握用户提问背后的意图，才能提供最完美的回答。本文将深入剖析 Udemy AI助手 意图理解系统的演进过程，揭示我们所面临的挑战、取得的突破，以及如何在响应质量、速度和成本之间实现平衡的关键经验。文章的核心关键词包括：Udemy AI助手、意图理解、Embedding、LLM（大型语言模型）、混合方案、响应质量、延迟、成本。
背景：LLM与意图理解的重要性
在使用 LLM 的过程中，设置相关的上下文至关重要，这能确保模型产生高质量、高相关性的对话回复。为此，我们让 AI助手 能够连接到各种数据源和服务，以便获取最相关的上下文信息。在后台，AI助手 会预测学习者的 意图，然后调用相应的动作链，从数据源和 API 中提取最有用的上下文。举例来说，如果学习者想要获得当前视频讲座的总结，那么动作链将包含调用 API 来获取预先生成的讲座总结，并将其发送给 LLM 进行最终回复生成。再比如，如果学习者想要搜索课程中的某个主题，那么函数调用会通过我们的内部搜索 API 执行搜索。在这种架构下，意图理解 系统扮演着至关重要的角色，它决定了后续的动作链。一个错误的 意图 分类往往会导致错误的回复，如下面的对话所示：
示例：
学习者：“请总结一下这节课的内容。”
错误的AI助手回复： 触发了讲座搜索动作，而非讲座总结。
最初的解决方案：基于相似度的Embedding方法
当学习者提交消息后，第一步是预测学习者的 意图。在 AI助手 的初始版本中，我们采用了一种基于相似度的基础方法来预测 意图。我们使用 Nvidia 开源的 NeMo Guardrails 包，预定义了一组“用户 意图”，每个 意图 都配有示例用户话语（例如，“你能总结一下这节课的主要内容吗？”可以是讲座总结 意图 的一个示例话语）。示例用户话语会被 Embedding 并保存到一个轻量级的向量数据库中。当学习者提交消息后，系统会根据余弦距离和近似最近邻检索最相似的 Embedding。系统仅根据数据库中最接近匹配的用户话语来预测用户 意图。
在最初的产品发布时，我们使用轻量级的句子 Embedding 模型 all-MiniLM-L6-v2 来 Embedding 学习者的消息。由于这个模型很小，Embedding 操作非常迅速，并且产生的推理成本可以忽略不计。
挑战：新功能扩展导致的响应质量下降
随着产品发布，新的 AI助手 功能陆续上线，这些功能需要理解更多的 意图。随着我们扩展到新的 意图，我们注意到 AI助手 的 响应质量 出现下降。通过分析从 AI助手 响应质量 反馈中收集的数据，我们发现了错误回复的模式，并将这些问题归因于不正确的 意图 分类。很明显，在添加更多 意图 后，分类混淆的情况增加了。添加更多的示例用户话语只能稍微缓解这个问题。例如，用户询问关于某个特定概念的问题时，系统可能误以为用户想搜索包含该概念的讲座，导致提供不相关的搜索结果。
应对响应质量下降：模型选择与微调的探索
在确定 意图 错误分类是 响应质量 低下的根本原因后，我们着手检查现有的方法，并研究提高其准确性的方法。在评估新方法时，我们的主要考虑因素是：
- 响应质量
- 推理成本
- 响应 延迟
更大的Embedding模型：性能与成本的权衡
我们决定对可用的开源 Embedding 模型进行评估。下图显示了在我们早期版本的测试集上的准确性比较：
数据示例：
| 模型 | 准确率 | 推理成本 |
| ————————- | —- | ——– |
| all-MiniLM-L6-v2 | 75% | 低 |
| multilingual-e5-base | 85% | 中 |
| 其他大型Embedding模型 | >85% | 高 |
很明显，multilingual-e5-base 在性能/成本比方面表现最佳。Multilingual-e5-base（278M 参数）需要的 FLOPs 大约是 all-MiniLM-L6-v2（23M 参数）的 10 倍。因此，我们决定将 Embedding 模型部署到一个独立的服务器。这个新模型还为我们带来了多语言支持的优势，因为我们正在扩展对更多语言的支持。
更大的 Embedding 模型立即提升了 响应质量。然而，随着我们添加一些新 意图 以支持新功能，这种提升随着时间的推移而消失了。特别是，我们注意到新的讲座搜索用户 意图 存在很高比例的假阳性分类（参见示例 1）。
为了更好地评估最新的 意图 分类性能，我们扩展了我们的测试集，以涵盖新旧用户 意图，然后重新运行了评估。结果证实了 意图 分类性能存在很大差距。
数据示例：
| 意图类别 | 准确率（原模型） | 准确率（新模型） |
|————|———-|———-|
| 讲座总结 | 90% | 85% |
| 课程提问 | 85% | 80% |
| 讲座搜索 | 70% | 50% |
这促使我们重新审视我们的方法。
实验：使用困难负样本微调Embedding模型
在这个实验中，假设是现成的 multilingual-e5-base 模型难以捕捉我们学习者消息的细微差别。现成的模型经过训练，在通用自然语言处理任务上表现良好。在一般意义上被认为是语义相似的两个句子可能不一定在我们以学习为中心的用例中具有相同的含义。通过使用足够多的实际错误分类消息微调模型（这个过程称为困难负样本挖掘），我们希望微调后的模型能够学习我们学习者消息中的细微差别。
不幸的是，经过多次使用不同 Embedding 模型和不同损失函数的实验试验后，指标没有显示出任何改善。我们决定尝试另一种方法。
纯LLM方案：上下文理解的提升与成本的挑战
Embedding 方法有两个主要限制。首先，我们观察到某些 意图 存在高度的混淆。例如，提到“讲座”的消息经常被错误分类为讲座搜索，而不是正确的 意图，例如讲座总结。我们假设句子 Embedding 过程充当了一种有损压缩的形式，有时会丢失关键的语义信息。第二个限制是，由于 Embedding 模型的小而固定的输入大小（multilingual-e5-base 为 768 个 token），我们的 Embedding 方法仅考虑了最近的学习者消息。它无法考虑整个对话的上下文。为了同时解决这两个限制，我们决定利用 LLM 将聊天历史作为输入来预测学习者的 意图。我们的假设是，即使是一个小型 LLM 也应该能够比我们最好的 Embedding 模型表现更好。
我们评估了这些 LLM 在成本、延迟 和分类性能方面的表现：
- gpt-4.1
- gpt-4.1-mini
- gpt-4.1-nano
数据示例：
| LLM模型 | 准确率 | 平均延迟 (秒) | 成本指数 |
|————|———-|—————–|———-|
| gpt-4.1 | 95% | 1.2 | 100 |
| gpt-4.1-mini | 92% | 0.8 | 25 |
| gpt-4.1-nano | 93% | 0.6 | 6.25 |
在我们的评估中，gpt-4.1-nano 的表现略好于 gpt-4.1-mini，但成本却比 gpt-4.1-mini 低约 75%。gpt-4.1-nano 在这三个模型中具有最低的 延迟。gpt-4.1-nano 是明显的赢家。
再次强调，引发良好的 LLM 回复的关键是提供良好的上下文。我们采用了一种 few-shot learning 方法，在我们的自定义用户 意图 分类提示中为每个用户 意图 提供几个示例。
示例提示：
你必须确定用户的意图。始终返回预定义的用户意图之一：
- 询问课程问题
- 询问课程概述问题
- 搜索讲座
- 询问讲座总结
...
永远不要提出新的意图。只使用英语。
机器人的用户意图响应是预定义用户意图的完整集合。
用户：什么是递归函数，应该在什么时候使用它？
机器人：用户意图：询问课程问题
用户：成功的业务运营战略的关键组成部分是什么？
机器人：用户意图：询问课程问题
用户：本课程涵盖哪些内容？
机器人：用户意图：询问课程概述问题
用户：哪个讲座讲到递归？
机器人：用户意图：搜索讲座
与仅使用 Embedding 的方法相比，我们观察到分类准确率提高了约 19 个百分点。
然而，这种方法有两个缺点。它为每个聊天回复增加了平均 0.6 秒的额外 延迟。额外的 gpt-4.1-nano 调用导致每次对话的总体 LLM 成本增加了 10%。
最终的混合方案：性能、延迟与成本的平衡
虽然仅使用 LLM 的方法在分类性能方面实现了飞跃，但我们不想忽视额外的 OpenAI 往返 延迟，这可能会损害用户体验。因此，我们决定尝试一种 混合方案。
对于每条学习者消息，我们从向量数据库中检索最相似的 Embedding。如果相似度得分超过预设的阈值，我们使用最相似的 Embedding 来预测学习者的 意图。否则，调用 LLM 进行预测。
我们通过在一系列阈值（以 0.5 为增量）上运行验证集指标来近似估计最佳阈值：
数据示例：
| 阈值 | 准确率 | LLM调用比例 | 平均延迟 (秒) |
|—–|———-|————–|—————–|
| 0.5 | 90% | 60% | 0.4 |
| 0.8 | 92% | 40% | 0.3 |
| 0.9 | 93% | 30% | 0.25 |
在 gpt-4.1-nano 的情况下，估计的最佳阈值为 0.85。然后，我们对 gpt-4.1-mini 和 gpt-4.1 模型进行了类似的阈值分析，并获得了这些结果以进行比较。
数据示例：混合Embedding + LLM 性能
| 模型 | 阈值 | 准确率 | LLM调用比例 | 平均延迟 (秒) |
|———-|—–|———-|————–|—————–|
| gpt-4.1-nano | 0.85 | 93% | 32.5% | 0.26 |
| gpt-4.1-mini | 0.8 | 92% | 40% | 0.3 |
| gpt-4.1 | 0.9 | 95% | 30% | 0.25 |
在执行分类任务时，LLM 响应非常短（<10 个输出 token），因此为了简单起见，我们只考虑输入 token 成本：
数据示例：gpt-4.1 变体之间的成本比较
| 模型 | 输入Token成本 |
|———-|———–|
| gpt-4.1 | 100 |
| gpt-4.1-mini | 25 |
| gpt-4.1-nano | 5 |
虽然 gpt-4.1 的性能比 gpt-4.1-nano 高出 3%，但成本却高出 20 倍。从性能与成本的角度来看，gpt-4.1-nano 是明显的赢家。
关于额外的响应生成 延迟，gpt-4.1-nano 调用平均需要约 0.6 秒的往返时间。这种额外的往返时间使端到端响应的平均 延迟 增加了约 10%，这仍然是可以接受的 延迟。此外，我们估计只有 32.5% 的学习者消息触发了 gpt-4.1-nano 回退。
最后，我们在之前失败的对话中测试了混合解决方案：
正确的AI助手回复： 能够正确识别 意图 并提供讲座总结。
结论
总而言之，通过这种 混合方案，我们实现了两全其美。AI助手 以高准确率运行，同时只增加了少量 延迟 和 成本。我们计划监控学习者的反馈，以验证对学习者满意度的影响。展望未来，我们计划继续向 AI助手 添加新的强大功能，使其对所有 Udemy 学习者更有帮助。这种持续的优化和创新，将进一步提升 Udemy AI助手 的 意图理解 能力，为学习者带来更优质的学习体验。未来的发展方向包括：进一步优化 LLM 的提示工程、探索更先进的 Embedding 模型、以及引入更复杂的对话管理机制，以实现更精准、更自然的交互。