AI 代码助手的黄金指标：CPO和PCW

Codeium 引入了两个指标，即每个机会的字符数 (CPO) 和编写代码百分比 (PCW)。

Codeium 认为 CPO 应该是衡量不同 AI 代码助手自动完成功能和质量的权威指标。与接受率不同，该指标不易受到可玩弄的混杂因素的影响，并且与实际工具价值相关，因此更高的 CPO 确实意味着产品的实际价值更高。Codeium 认为 PCW 应该是评估代码助手为最终开发人员带来的价值的权威指标，因为它是使用代码助手的实际结果的衡量标准，并且是一个相对指标，它考虑到不同的开发人员一开始编写代码的时间不同。这些指标在概念上是相关的，但在实践中与数学无关，我们将对此进行讨论。Codeium 根据 CPO 为 Codeium 做出开发决策，Codeium 目前的 CPO 为 1.27，PCW 为 44.6%，这意味着使用 Codeium 的开发人员提交的新代码中有 44.6% 实际上来自 Codeium。

大多数代码助手都具有多种模式，那么为什么自动完成的指标特别重要？

自动完成是一种密集的被动人工智能，这意味着开发人员可以在每次击键时获得建议，而无需改变其行为来调用工具。这意味着即使只编码几个小时，开发人员每天也可以获得数千条建议。

因此，虽然聊天和其他功能无疑很有用，但自动完成所能带来的价值远远超过其他所有影响。

从 Codeium 的使用数据来看，开发人员每天会获得数百条自动完成建议，同时每天进行五到十次聊天。因此，即使有用的聊天比自动完成建议有用一个数量级，也知道真正的价值来自哪里。

现有的基准指标为何不可信？

实际上，有太多方法可以以牺牲价值为代价来操纵现有的基准指标，因此，如果针对此类指标进行优化，Codeium 就会激励错误的产品决策。如果Codeium 真的想根据真实价值将一种产品与另一种产品进行比较，就需要一个无法操纵的基准指标，其中指标的增加实际上对应于为开发人员带来的更多价值。这给Codeium 带来了解决方案……

CPO：每个机会的字符数

直接说吧，Codeium 是这样计算每个机会的字符数的：

Characters per Opportunity =
             Attempt rate *
    

Feedback rate *

         Acceptance rate *
         (Avg Num Tokens / Acceptance) *
            (Avg Num Characters / Token)

让我们逐一分析一下每个因素：

• Attempt Rate：每次用户在编辑器中执行操作（例如输入新字符或删除一些新无效的代码）时，AI 都会有机会尝试提出建议。尝试率可以反映 AI 尝试提出建议的机会比例。不尝试的原因可能包括延迟（防抖动）或 AI 必须确定是否尝试的上下文过滤器。

• Feedback Rate：从上下文检索到网络开销再到实际的模型推理，提出建议存在明显的延迟。如果延迟太高，开发人员将继续在编辑器中执行新操作，从而触发新的机会并使现有机会变得无用。此外，在建议完成后，该工具可能会出于各种原因（置信度不够高、触发抑制过滤器等）决定不向开发人员显示建议。反馈率捕获了有多少比例的建议甚至到达了开发人员那里，以便进行人工“反馈”（即接受或拒绝）。

• Acceptance Rate：即使建议被开发人员接受，在开发人员看来，它仍然可能不是好的。接受率反映了开发人员接受的建议的比例。这是经常被公开引用的指标。

• Avg Num Tokens / Acceptance：在其他条件相同的情况下，长建议和短片段的价值量是不同的。LLM 以“标记”为单位提取输入并创建输出，标记通常是一小段字符，因此每次接受的平均标记数反映了每次接受建议的价值量。

• Avg Num Characters / Token：最终，开发人员看到的是字符中的文本，而不是标记，并且不同的 LLM 可以具有不同的“标记器”（即字符序列集），因此，如果 LLM 每个标记产生更多的字符，则它实际上会编写更多的代码，并且每个标记的平均字符数恰好捕获了这一点。

综合起来，您就得到了每个机会的字符数 (CPO)。

为什么 CPO 衡量的是真实价值，并且不容操纵

那么为什么要采用 CPO？简单来说，它无法通过偷工减料而不是实际改进产品来大幅提高这一指标。

让我们看一些工具的例子，以及它们的决策如何以 CPO 为代价使接受率看起来非常好：

• GitHub Copilot：最受欢迎的 AI 助手的接受率高达 30%。太不可思议了！然而，没有提到的是，Copilot 的尝试率和反馈率较低。他们实际上一开始并没有显示那么多建议，这反过来提高了接受率，但实际上却减少了该工具带来的实际价值。

• SourceGraph Cody：Cody 是以牺牲反馈率为代价来提高接受率的一个很好的例子。Cody 在其 LLM 层中使用第三方 API，并花费大量时间进行上下文检索，导致自动完成建议的延迟非常高，通常超过一秒钟。因此，即使这些建议质量高、接受率高，开发人员几乎总是在建议显示之前就开始下一步操作。也许接受率还可以，但实际交付的价值却很低。

• TabNine：TabNine 是一个很好的例子，它通过每次接受的平均令牌数量较低来博取接受率。通过严重偏向单行或较短的建议（即建议在行末截断），TabNine 能够快速提供建议（良好的反馈率），但每个被接受的建议的价值远低于竞争对手，即使他们的接受率很高，他们也无法弥补实际交付的价值。

事实上，所有工具中游戏接受率的一个很好的例子就是缺乏内联填空建议。从遥测中，Codeium 知道大约 33% 的机会是内联 FIM 机会，人们在一行代码的中间编写代码，但除了 Codeium 之外没有其他工具为他们提供建议，即他们在 33% 的机会中的尝试率为 0%！为什么？因为内联 FIM 建议的接受率较低（特别是如果在模型训练时没有通过额外的目标函数正确完成），因此通过不提供这些建议，其他工具可以夸耀更高的接受率，但以牺牲交付给开发人员的实际价值为代价。接受率可以被操纵，但 CPO 不能。

Codeium 现在的 CPO

内联建议和行末建议的情况有很大不同，因此让我们分别分析 CPO。

Codeium 的行末建议的 CPO 为 1.78，而Codeium 的内联建议的 CPO 为 0.30。

这意味着，即使按内联机会百分比（约 33%）对它们进行加权，Codeium 的加权 CPO 也为 1.27。

Codeium 不知道其他工具的最终 CPO，但正如上一节所讨论的，我们知道所有其他工具的内联 CPO 为 0，并且我们坚信所有其他工具的最终 CPO 都低于 Codeium 的。

Codeium 如何应用 CPO

Codeium 内部使用 CPO 已有一段时间了。由于尝试率接近 100%（由于延迟，我们的反跳率确实低于 2%，但我们没有任何会人为降低尝试率的预生成过滤器），并且我们的标记器很少改变（每个标记的平均字符数是恒定的），因此我们通常关注三个中间项之间的权衡：反馈率、接受率和每次接受的平均标记数。现在，介绍一下最近做出的一项改变，其中 CPO 指导了我们的决策。

使用更大的自动完成模型

Codeium 最近训练了一个自动完成模型，它的权重比Codeium 之前的模型高出 60%，有了额外的容量，当我们对这两个模型进行 A/B 测试时，可以看到绝对接受率明显提高了几个百分点。

然而，当在相同的硬件上部署它而不改变我们的推理堆栈时，发现延迟的增加使反馈率下降了很多，以至于抵消了接受率增加对 CPO 的影响。

这种权衡就是为什么 Codeium 通常不理会客户对模型大小的疑问，因为即使大小与接受率相关，也不一定与实际价值相关。

无论如何，Codeium 意识到：必须做很多基础技巧（比如量化），才能在最大限度地减少对反馈率的影响的同时，仍然从接受率中获得好处。Codeium 做基础工作不是为了更聪明，而是因为我们需要这样做才能带来更多的实际价值。

实际价值与感知价值的差异

那么，如果 CPO 能够捕捉到真正的价值，为什么代码字符接受率会受到如此多的关注呢？

简而言之，它是实际价值和感知价值之间的差异。虽然 CPO 确实捕捉到了自动完成所驱动的全部价值，但开发人员“感觉”的是接受率。

每次按下 Tab 键接受建议时，人们都会获得一点多巴胺的提升，他们越是觉得人工智能让他们有机会按下 Tab 键，他们就越高兴，他们认为这个工具就越有用。这不是对开发人员的打击，这只是人类的心理！

那么这对 CPO 意味着什么呢？即使 CPO 是黄金指标，接受率的二次优化也很重要。毕竟，CPO 因素的值有无数种组合，接受率也各不相同，这些组合将乘以相同的 CPO。以 CPO 为条件，应该始终优化选择具有最大接受率的组合，以优化感知价值。

事实上，如果 CPO 可以大幅提高接受率，那么 CPO 受到一点影响可能也无妨，因为感知价值很重要，但不能影响太大（大多数其他产品都这样做了）。可以用一些极端数字来图形化地展示这一点，方法是从 CPO 中提取接受率（y 轴），其余项合并在 x 轴上：

阴影区域捕捉了工具的示例性能空间，它通过调整各种常量而不做任何实际工作来内在地改进系统。点 A，即使它具有最高的 CPO，也具有极低的接受率，并且以达到点 B 的方式更改系统将使接受率绝对增加 25%，而 CPO 只会减少一个单位。但是，如果您考虑将系统更改为点 C，则可以看到采取此操作的边际价值会下降，因为对于相同单位的 CPO 减少，您只能获得 10% 的接受率绝对增加，因此如果您继续优化接受率，您很快就会发现有必要大幅降低 CPO 或实际值。如果您可以沿着等距线朝着更高的接受率移动，请务必这样做，但通常您不会通过简单的黑客攻击、偷工减料或不断调整获得这样的权衡。归根结底，要向上和向右移动，您必须增加 CPO。

好了，说了这么多关于 CPO 的话题，你您可能忘记了Codeium 还引入了第二个指标，即编写代码百分比 (PCW)。它的含义并不难描述 - 对于添加到代码库的任何新代码，您可以将每个字符归因于是否来自已接受的 AI 建议，并且此类“正匹配”的百分比将成为 PCW。

您可能想知道为什么不能只使用 CPO 来计算 PCW。毕竟，CPO 直观地捕获了 AI 为开发人员执行的每个操作编写了多少个字符。因此，如果 AI 的 CPO 为 1.5，这是否意味着对于开发人员编写的每个代码字符，AI 都在编写 1.5 个字符，这意味着 AI 正在编写提交到代码库的新代码的 60%（1.5/2.5）？

好吧，在一个人类所做的唯一编辑就是添加单个字符的世界里，是的，这是正确的。但实际上，人们会编辑和删除已接受完成的部分，还有其他方法可以获取非 AI 编写的代码块（例如 Intellisense）等等。

Codeium 希望此类操作能够影响捕捉 AI 驱动的最终价值的指标，这就是Codeium 通过精确的字符归因来衡量 PCW 的原因，但Codeium 也不希望此类操作影响用来对助手本身进行基准测试的指标。例如，如果有人接受了 Intellisense 建议，这不应被解释为对 AI 助手的负面信号 - 据Codeium 所知，如果有机会，AI 助手会完美地建议相同的代码块！这就是Codeium 将 CPO 和 PCW 分开的原因 - CPO 衡量工具在有机会时的表现如何，而 PCW 衡量开发人员通过将工具集成到他们的工作流程中所带来的价值。

在 Codeium，我们专注于创造真正更好、真正带来更多价值的产品。我们无意为了营销目的而优化我们的产品，也无意追逐分散我们注意力的指标和基准。我们认真对待我们的评估，并且可能比其他任何致力于解决这些问题的团队都更认真地考虑如何做到这一点，这就是为什么我们可以自信地说，普通 Codeium 用户有 44.6% 的新提交代码是由 Codeium 编写的。凭借我们的评估方法，我们相信，当我们向用户（尤其是付费企业客户）推出功能时，我们实际上正在带来更多实际价值。