根据 Stripe 转化率选择模型：初创公司的实用评估

概述

最适合您的模型取决于您的业务目标。许多初创公司根据离线评估和公开基准来选择大型语言模型（LLM）。然而，在基准测试中得分高的模型不一定能促使用户付费、订阅或继续使用您的产品。在实际业务成果的衡量下，纸面上表现强劲的模型可能会表现不佳。

本指南介绍了一种基于初创公司最重要的业务成果之一的评估方法：用户是否愿意为您的产品付费。

我们将介绍 HyperWrite 的模型评估流程，重点关注实际支付转化率——特别是 Stripe 的一次性购买或每月经常性收入（MRR）订阅。如果您的目标是提高转化率，或在切换到更便宜的模型时维持转化率，此评估示例可能是一个有用的模式。

先决条件和范围

要将本指南应用于您的业务，您需要：

• 支付处理器。我们在示例中使用 Stripe，但您可以进行微调，并使用任何支付提供商采用相同的方法。
• 足够的用户以产生有意义的信号。每个测试变体至少需要一千名用户。为了获得更高的统计显著性，您需要更多的用户。
• 具有转化事件的 AI 驱动产品。我们使用 LLM 应用程序，转化事件是支付。相同的测试方法适用于围绕语音、视频和其他模式构建的应用程序。

基于实际目标选择模型

HyperWrite 构建了 AI 驱动的写作工具和研究助手。该公司的核心产品是具有高级研究功能的写作助手。

离线基准测试未能预测对 HyperWrite 最重要的因素——用户是否以一种促使他们订阅并继续使用产品的方式与写作助手互动。HyperWrite 团队将重点转移到关注的成果——转化率上，并开始根据实际 A/B 测试（比较 Stripe 转化率）来选择 AI 模型。

对初创公司有影响的是什么：转化率

在许多初创公司中，让用户注册并继续使用产品就是目标。使用经典的 A/B 测试，即使用科学家几十年来依赖的相同统计方法，您可以设计一个模型评估流程：

• 新用户被分组，每个组都使用不同的 AI 模型。
• 为了标准化用户遇到升级提示的时间，在用户向助手发送一定数量的消息后应用一致的速率限制——这足以创造一个有意义的升级时刻。
• 跟踪每个组向付费订阅（通过 Stripe）的转化情况。

用户被随机分配到模型，并且其他因素（入站流程、功能、提示等）得到控制，这使得可以将转化率的差异归因于正在测试的模型，而不是外部变化。统计数据提供了观察到的差异不太可能由机会引起的信心。

当发现真正的、非随机的改进时（例如，一个模型产生了更高的转化率），其影响是切实的：更高的 Stripe 转化率、更多的付费用户，以及通常更低的成本（如果模型更高效）。

如何进行 A/B 测试来选择模型

A/B 测试可以作为模型选择的实际评估工具。将用户随机分为几组，为每组提供不同的体验（在此是不同的 AI 模型），并观察哪一组在关键指标——在此是 Stripe 转化率——上表现更好。

基本原理：一个模型与另一个模型

标准的设置包括一个“对照组”（您当前的模型）和一个“变体”（一个挑战者）。用户被随机分配到其中一个组。为了确保测试隔离模型的影响，其他所有因素都保持不变：入站流程、功能、提示以及转化的机会。在预定的时间段或用户数量之后，比较转化率：使用模型 A 的人多还是使用模型 B 的人多？

实际示例：HyperWrite 的模型替换测试

HyperWrite 的目标是部署一个成本更低的 LLM，同时不实质性地降低获客能力。这是一个非劣效性场景：重点是确保新模型不比对照组差很多。考虑到成本节约，设计了一个单侧非劣效性测试。

• 测试重点： 节省成本而不损害 Stripe 转化率。
• 设计： 单侧双比例 Z 检验（专注于检测新模型是否更差）。
• Alpha（I 类错误率）： 0.15（即 85% 的置信度）。对于这个初创公司来说，迭代速度比非常严格的显著性阈值更重要。
• 功效： 0.60（足以捕捉有意义的下降，并与流量限制相平衡）。
• 最小可检测效应（MDE）： 转化率下降 30%——如果成本节约证明合理，任何低于此的下降都将被视为“足够接近”。
• 总体： 在定义的时间段内的新注册用户细分，在注册时按 user_id 随机分配。
• 触发器： 用户发送消息，达到升级付费墙，并可能通过 Stripe 结账进行转化。

设置参数：什么才算获胜？

并非所有观察到的差异都有意义——有些差异是偶然发生的。A/B 测试有助于区分真实效应和随机噪声。这里常用的统计工具是“双比例 Z 检验”，它检查两组之间的转化率差异是否足够大，可以被认为是统计上显著的。

此测试有几种变体：

• 单侧检验： 检查新模型是否优于（或根据设计，不差于）对照组
• 双侧检验： 检查任何差异，无论是向上还是向下
• 多变量测试（A/B/n）： 同时比较三个或更多模型

选择取决于您的目标。如果您需要明显的转化率提升，单侧检验可能就足够了。如果您愿意采用一个不差但更便宜的模型，您可以设计一个非劣效性（单侧）测试，以确保新模型没有显著变差。

关键术语

• I 类错误（假阳性）： 结论有效应，但实际上没有
• II 类错误（假阴性）： 未能检测到真实效应
• Alpha（α）： I 类错误的可接受风险（通常设置为 0.05，即 5%）
• 功效： 检测真实效应的概率（通常目标是 80%）

示例：运行真实的模型测试

考虑在您当前的型号（对照组）和新的变体（型号 X）之间进行选择。假设您运行一个单侧双比例 Z 检验，以查看型号 X 的转化率是否优于对照组。您将 α 设置为 0.05，并在使用基准转化率和所需的最小可检测效应进行功效计算后，确定每组大约 1,500 名用户将提供约 75% 的功效——这是一个折衷方案，可以更快地获得方向性见解。

在两组都达到所需样本量后，数据可能如下所示：

| 组 | 分配的用户数 | 转化次数 | 转化率 | p 值 | 统计上显著？ | 获胜者？ | I 类错误受控？ | II 类错误受控？ |

• 分配的用户数： 随机分配到每组的用户数。
• 转化次数： 每组通过 Stripe 付款的用户数。
• 转化率： 分配的用户数除以转化次数。
• p 值： 单侧双比例 Z 检验的结果，显示型号 X 的更高比率是否可能不是偶然的。
• 统计上显著？： p 值是否优于您的 alpha（此处为 0.05）？
• 获胜者？： 如果统计上显著，型号 X 是新的获胜者。
• I 类错误受控？： 我们是否将假阳性风险控制在 alpha 阈值内？
• II 类错误受控？： 我们的样本量是否足以检测到真实效应？

在此次运行中，型号 X 的转化率比对照组高 1 个百分点（2.0% 对比 1.0%）——相对增加了 100%。p 值为 0.012，远低于 0.05，因此我们将其标记为统计上显著：型号 X 是获胜者。由于我们计划的样本量具有 75% 的统计功效，因此我们也有信心我们没有错过真实的效应（II 类错误）。而且由于我们将 alpha 设置为 0.05，因此假阳性（I 类错误）的风险得到了控制。

实际示例：HyperWrite 的测试参数

HyperWrite 没有默认采用教科书式的 95% 置信度和 80% 功效。流量成本很高，最大化统计确定性会减慢学习速度并消耗资本。选择的 85% 置信度和 60% 功效允许检测任何实质性下降（约 30% 的下降），同时避免过度优化微小差异。

转化率通常会随着测试的进行而上升。在这些测试中，一旦达到所需的样本量（N），测试就会停止。只有一小部分传入流量被分配到每个测试臂，大部分流量仍然保留在经过验证的对照组体验中。

多重比较说明

使用了 A/B/n（“多对一”）设计：每个候选模型（GPT-4.1 和 GPT-4.1-mini）都与生产对照组（Claude 3.5 Sonnet）进行了评估，但没有直接相互评估。

由于发布决策是特定于变体的（“如果其单侧非劣效性测试在 α = 0.15 通过，则发布该变体；否则丢弃”），因此没有应用家族错误率校正。这对于小样本量、以对照为中心的测试是标准做法。假阳性风险仅适用于发布的单个变体，并且避免 Bonferroni 类型拆分可以保留功效。

如何在 Python 中检查 A/B 测试的显著性

为了准确演示我们 A/B 测试背后的统计原理，这里有一个 10 行的 Python 代码片段，它使用单侧双比例 Z 检验（变体优于对照组）将原始转化计数转换为 p 值。将其粘贴到任何 Python REPL、Colab 或笔记本中，并在进行实际实验时替换您自己的数字。

# 单侧双比例 Z 检验
from statsmodels.stats.proportion import proportions_ztest

conversions   = [30, 15]     # [变体, 对照组]
sample_sizes  = [1500, 1500] # [变体, 对照组]

z_stat, p_val = proportions_ztest(
    conversions,
    sample_sizes,
    alternative="larger"      # "larger" → 变体 > 对照组
)

print(f"Z-statistic = {z_stat:.2f}")
print(f"p-value     = {p_val:.3f}")    # → 0.012 (α = 0.05)

如何解读结果：

• 如果 p 值 ≤ 0.05，则您的变体的转化率更高，具有统计显著性——继续发布它，或继续监控更多数据。
• 如果 > 0.05，则结果可能是随机噪声——收集更多数据，或坚持使用您的对照组。

注意事项

• 尾部选择 / p 值操纵： 在第一个用户流入之前决定单侧或双侧；稍后更改会增加您的 I 类错误（假阳性）。
• 低计数： 如果任何一组的转化次数少于约 10 次，请将 Z 检验替换为 Fisher 精确检验或 Wilson/Wald 置信区间。
• 早期查看： 未经 α 支出校正而反复查看数据会增加假阳性风险。使用固定样本或分组顺序设计。
• 用户重叠 / 污染： 确保同一用户 ID 不能进入两个组（例如，通过注销/登录）。
• 多个挑战者： 如果您计划选择多个变体中的“最佳”变体，请控制家族错误率（Bonferroni、Holm）或使用多臂老虎机。
• 缓存和提示漂移： 确认您的推理层不会将一个模型的响应泄露到另一个模型的缓存中；在各组之间保持相同的提示。

要了解有关这些陷阱及其避免方法的更多信息，请参阅 Evan Miller 的《如何不进行 A/B 测试》。

主要收获

A/B 测试不仅仅适用于登陆页面或按钮颜色——它是选择适合您产品的 LLM 的关键。将其作为工作流程的一部分，您将避免代价高昂的错误，并发现基于用户重视的内容的改进：一个值得付费的产品。

实际示例：HyperWrite 通过 GPT-4.1 实现成本节约

模型定价通常随着功能改进而增加。HyperWrite 花了几个月时间寻找一个能够匹配其现有模型（Anthropic 的 Claude 3.5 Sonnet）而又不损害转化率或用户体验的模型，最好是成本更低的。在几个模型表现不佳之后，OpenAI 的 GPT-4.1 取得了显著的成果：以更低的价格匹配了现有模型的 Stripe 转化率。

以下是各变体在 Stripe 转化率方面的表现：

| 变体 | 分配用户数 | 转化次数 | 比率 | 所需样本量 | 完成百分比 | 转化截止值（≤） | 更差？ |

• 变体： 模型名称（对照组或挑战者）。
• 分配用户数： 随机分配到该组的用户数。
• 转化次数： 该组中通过 Stripe 付款的用户数。
• 比率： 分配用户数除以转化次数。
• 所需样本量： 为非劣效性测试预先计算的样本量目标。
• 完成百分比： 分配用户数除以所需样本量（目标进度）。
• 转化截止值（≤）： 低于此值的最大转化次数将被标记为比对照组“显著更差”。
• 更差？： 如果该组低于其截止值（即统计上更差），则为“是”；否则为“否”。

结果

• GPT-4.1 变体均通过了其截止值——这意味着它们均未在统计上劣于对照组。
• GPT-4.1（完整版）在转化率方面与 Claude 3.5 Sonnet 持平，同时实现了可观的成本节约。

衡量转化需要一些创造力和数据

要执行此分析，您需要一个将用户行为与 Stripe 付款事件联系起来的系统。对此没有通用的模板，但 HyperWrite 使用的架构说明了一种实现方式。此工作流程可适用于任何用户与 AI 互动并通过 Stripe 升级的初创公司。

1. 用户跟踪： 为每个新注册用户分配一个唯一的标识符，该标识符在其整个生命周期中保持不变。
2. 模型分配： 在注册时，将每个用户随机分配到一个测试组（模型变体），并将此分配存储在您的数据库中。
3. 互动日志记录： 记录关键事件（例如，首次使用、达到速率限制），以及用户 ID 和模型分配。
4. 转化事件捕获： 设置一个 Stripe 网页钩子来监听来自 Stripe 网页钩子的 checkout.session.completed 事件，该事件在付款成功时触发。收到后，将 Stripe 客户与您的内部用户 ID 匹配，并更新您的数据库以反映付款/转化。
5. 数据聚合： 定期将测试组分配和转化数据提取到单个表或仪表板中进行分析。
6. 统计测试： 使用基本的 Z 检验（有许多库/Excel 模板可用）来分析转化率差异是否具有统计意义。

以下序列图概述了该过程：

用户工作流程

以下是 HyperWrite 的用户旅程：

1. 用户注册： 当用户创建帐户时，其信息将存储在数据库中，并分配一个唯一的 user_id。
2. 发送第一条消息： 新用户首次与写作助手互动。
3. 触发速率限制： 在发送一定数量的消息后，达到速率限制。这提供了一个一致的点，可以在此显示升级提示。
4. 转化机会： 一些用户此时选择订阅——他们将被引导至 Stripe 结账。

Stripe 工作流程

我们关心两个关键的 Stripe 操作：

1. Stripe 事件监听： 系统监听来自 Stripe 网页钩子的 checkout.session.completed 事件，该事件在付款成功时触发。
2. 数据库更新： 收到网页钩子后，数据库中相应的 user_id 将被标记为已转化。

运行测试

定期检查测试是否完成：

1. 查询测试组： 检索分配到每个模型变体的所有用户。
2. 合并 Stripe 数据： 将您的用户数据与 Stripe 订阅事件合并，以便您确切知道每个组中有哪些用户已转化。
3. 运行统计数据： 使用单侧双比例 Z 检验（参见上一节）来检查转化率差异是否具有统计意义。

结论和后续步骤

这种方法的一个主要教训是，与业务指标（如 Stripe 转化率）挂钩的实际测试可以揭示哪些模型选择能够真正为您的产品带来成果。虽然离线基准测试和实验室测试有其用武之地，但将评估与用户决定付款的时刻联系起来，通常会做出有利于客户和企业的决策。

这对初创公司意味着什么

不一定非要击败您现有的模型；在关键指标上表现“相同”但成本更低的模型可能很有价值。在这种情况下，OpenAI 的 GPT-4.1 在降低成本的同时，在 Stripe 转化率方面与现有模型相匹配。

这凸显了将模型评估与由 Stripe 驱动的 A/B 测试联系起来的价值——您可以获得清晰的、与收入相关的答案，而不是仅仅依赖基准测试或主观印象。

初创公司可以在几个方向上扩展此测试：

• 按用户画像或用例细分： 划分您的受众（例如，重度用户与新用户，不同行业），并查看哪些模型或提示对每个组表现最佳。
• 寻找收入-成本最佳点： 不仅要考虑收入，还要考虑服务每个模型的成本。最佳选择可能是平衡利润，而不是仅仅最大化销售额。
• 监控长期影响： 超越即时转化。跟踪用户生命周期价值、客户流失或留存率等指标，以优化可持续增长。

在衡量什么以及如何进行实验方面，有很多发挥创意的空间，这样您就可以调整产品以满足您团队最看重的东西。

如果您对这类测试有疑问、对您的方法有反馈或需要有关设置您自己测试的建议，请随时联系：josh@othersideai.com。

祝您在构建、实验中，让您的用户——以及您的 Stripe 仪表板——来指引方向。

贡献者

本手册由 HyperWrite 的首席工程师 Josh Bickett 贡献，HyperWrite 是一家构建 AI 驱动的写作工具和研究助手的公司。这些方法和案例研究反映了 HyperWrite 的经验，但旨在作为初创公司使用支付转化指标评估 LLM 的通用指南。