背景 看到本系列前三篇文章获得的惊人反响,我不得不推出第四部分。 在前 3 篇文章中,我们讨论了对话 AI 代理的性能指标定义、仪表和可扩展性。如果您还没有看过之前的文章,以下是链接: 第 1 部分 - 指标:吞下红色药丸 第 2 部分 - 指标重载:Oracle 第三部分 - 指标革命:扩展 在本文中,我们将讨论如何使 (使用最新的 LLM 进展),以便持续提高绩效。我们的目标是让讨论变得简单,并让所有从事该领域工作的人都能理解。 这些指标更具可操作性 问题 是我们讨论过的两类高级指标。传统上,前者被认为是系统级指标 - 这些指标直接从日志中测量。因此, 本质上是可操作的,因此是可操作的。 用户感知指标 和 用户报告指标 用户感知指标 定期从生产日志中跟踪运营指标,并可用于团队范围的 OKR 目标设定。 然而,尽管 很容易操作,但应该注意的是,这些是“感知”而不是“实际”用户指标。因此,对这些指标进行爬山法测试可能不会显著改善用户对对话式 AI 代理的感知。如果这些项目跨越多个季度,这可能会导致资源管理效率低下。 用户感知指标 需要有一种方法来衡量所有性能改进对 这应该被视为 用户报告指标的预期影响。 “北极星”影响。那么,问题是什么? 直接的用户反馈预计是非结构化的,不可操作且难以操作。 详细的用户报告反馈本质上应该是非结构化的。如果用户报告的反馈是结构化的,那么它最终可能会集中在内部团队已经知道的领域。除此之外, 还受到季节性和公司看法等因素的影响。 用户报告指标 对 的影响可以更准确地估计,但 有很多不可控的因素。 用户感知指标 用户报告指标 解决方案 非结构化的 应转换为可付诸行动的结构化格式。可以训练特定的 ML 模型,以便将非结构化反馈转换为现有的系统级指标。 用户反馈 需要注意的是,将 主要目标用于 可能更为实际,以防止这些指标中固有的偏差。对于更 ,应使用这些指标以及系统级指标来衡量对用户感知的影响。 用户报告指标的 “近期”用户指标回归 横向的长期项目 法学硕士是游戏规则的改变者 现在的问题是,针对我们正在寻找的特定指标,训练 ML 模型需要付出哪些努力?随着 LLM 的普及和可用性的提高,可能可以使用开箱即用的 API 将非结构化反馈转换为可以跟踪和测量的东西,类似于系统级指标。 值得注意的是,随着 LLM 可以处理的 token 数量的增加,许多特定于产品的信息可以作为“提示”本身的一部分提供。因此,现成的 LLM API 以及一些 提示工程可以提供可操作的 用户报告指标。 这提供了一种非常快速的方法来评估系统级指标改进项目对用户感知的影响,这对于确定性能改进项目的优先级很有用。 即使采用这种结构化的 仍有可能出现意外变化。但是,我们可以有信心地假设,如果某个特定项目(旨在改善系统级指标)最终 那么该项目很可能确实改善了用户感知。 用户报告指标方法, 对报告指标产生了积极影响, 然而,并不能保证所有真正“好的”改变都能有效改善 用户报告指标。 因此,重要的是结合两者来确定性能改进项目的优先顺序和评估方法。