AI 测试的思维模式

哪些知识需要保留,哪些知识需要舍弃:将您的 Web 测试知识与 LLM 的新世界相关联。

示例应用

在整个系列中,ThemeBuilder 都是您的示例应用。 ThemeBuilder 会输出一个 JSON 对象,其中包含 LLM 生成的格言和调色板。

  • 口号和调色板必须与输入的品牌名称、说明、受众群体和语气相符。
  • 座右铭不得有害,且必须简短(不超过 6 个字)。
  • 调色板对比度必须符合 WCAG 最低指南规定的无障碍标准,即对比度为 4.5:1
ThemeBuilder 输入和输出。
在 ThemeBuilder 中,用户输入公司名称和说明、目标受众群体以及基调和氛围。前端会将此信息发送到您的服务器。您的服务器使用 LLM 生成与品牌相符的口号和调色板。

客观评估和主观评估

如何测试 ThemeBuilder 是否按预期运行?

基于规则的评估(有时称为精确评估)是一种客观测试,答案为正确或错误。这些问题最适合询问数据格式、对比度或其他具有明确答案的问题。您可以使用常规的程序化代码来实现这些测试。

有些检查是客观的,答案只有正确或不正确两种。这些问题最适合询问数据格式、对比度或其他具有明确答案的问题。您可以使用常规的程序化代码来实现这些测试。这些评估称为“基于规则的评估”或“精确评估”

例如:

// Example rule-based eval: data format
function evaluateFormat(appOutput) {
  // Check if JSON is valid, colors are hex, no empty strings, motto is 6 words or fewer
  // Use deterministic tools like zod for schema validation
  return "PASS"; // or "FAIL"
}

其他检查则具有主观性,例如口号和调色板的品牌和受众群体一致性。虽然恶意内容检测是一项分类任务,但它也具有主观性,因为涉及判断。

虽然主观测试也涉及分类,但正确和错误的范围可能会有很大差异。例如,评估口号和配色方案是否与品牌和受众群体相契合。恶意检测也是主观的。

虽然评估主观质量可能听起来像是只有人类专家才能做到的事情,但您可以借助 LLM-as-a-judge 技术大规模自动执行这些测试。

[LLM 评判模型] 速度快、易于使用且相对便宜 [...] 它已成为评估生产环境中的 AI 模型最常见的方法之一,甚至是最常见的方法。

—AI 工程,Chip Huyen

例如:

// Example LLM-as-a-judge eval for a subjective quality like brand fit
async function evalBrandFit(userInput, appOutput) {
  const brandPrompt = `You are an expert brand strategist. Evaluate the
  following generated motto for the company whose target audience is
  ${userInput.audience}, and who describes itself as
  ${userInput.companyDescription}: ${appOutput.motto}`
  // Call the LLM judge
  const evalResult = evalWithLLM(brandPrompt);
  // Return the consolidated results
  return {
    mottoBrandFit: evalResult,
  };
}

// Helper that communicates with the LLM API
async function evalWithLLM(prompt) {
  // ... Call LLM with the prompt ...
  // ... Parse the resulting judgement ("PASS" or "FAIL") + rationale
  return {
    status: "PASS",
    rationale: "This motto perfectly captures the brand and tone, because..."
  };
}

模型会模仿人类的判断,因此您需要一种方法来准确告知评判模型您要寻找的内容。为此,您可以向法官提供评分标准。

评分准则是一组结构化的标准或评分指南,供评委(人工或 AI)用来评估输出。它提供了一个一致的框架,可在每次评估中评估主观质量。

其他类型的评估

您可能需要使用基于参考的评估或成对评估。

基于参考

这些指标用于衡量与标准答案的相似度。这些数据可用于翻译或技术事实等存在已知良好回答的任务。

成对

即使一个版本比另一个版本好,法官也可能会给两个不同的版本打出相同的 PASS 分。成对评估通过以下方式解决了这个问题:为评审员提供同一输入的两个输出(A 和 B),并指示评审员选择胜出者。

例如,假设您正在评估一家温馨咖啡馆的口号:

Input: "Friendly cafe"

Pointwise evaluation:
Output A: "Come get coffee." // PASS
Output B: "Your morning smile in a cup." // PASS
2 PASS. Unconclusive!

Pairwise evaluation:
Output B wins. It captures the "friendly" tone more effectively than the generic Output A.

使用成对评估来选择要部署的模型版本,或比较两个不同的提示。

标准 Web 测试与 AI 评估

Web 测试包括回归测试。对于 AI,您需要添加优化和模型评估。

我们假设本课程的读者已经知道如何测试网站和 Web 应用。添加 AI 时,您需要改变现有的心理模型。使用 AI 评估可执行以下操作:

  • 执行回归测试:更改提示或模型后,应用是否出现故障?您是否遇到了损坏的调色板或有害的格言? 与中断是软件功能的 Web 应用不同,这里您要检查 LLM 输出是否优质且安全。这涉及主观性。
  • 优化应用:您的应用是否在不断改进?您是否在改进所需指标,例如,是否在不增加有害内容的情况下获得更多符合品牌调性的口号?
  • 选择合适的模型:是否有更适合您使用场景的模型?在 AI 出现之前,您只需选择一次 Web 堆栈。借助 AI,您应定期对模型进行基准比较,以发掘改用更好(可能更便宜)模型的机会。

分层测试

测试分为四个层级:单元测试、扩展单元测试、回归测试和集成测试,以及人工测试。

一个健康的代码库应包含多个层级的测试:单元测试、回归测试和集成测试,以及端到端测试。您的评估也应分层进行。

  • 将基于规则的评估与 LLM 作为裁判的评估相结合,以全面自动执行 AI 应用的测试。这样,您就可以在日常开发和 CI/CD 中发现问题,并测试候选版本是否符合质量标准。
  • 运行集成测试和回归测试,以大规模验证质量。
  • 运行人工手动评估作为验收测试。

除了在构建时运行这些评估之外,您还可以通过运行时评估来监控生产流量。这些数据有助于您发现实际输入中的质量或安全问题。

不断改进评估

Evals 应随应用一起增长。随着模型的智能化程度不断提高,请更新旧的评估。

定期向测试数据集添加棘手的示例,例如在生产环境中发现的新边缘情况或令人惊讶的用户输入。

您的评估衡量哪些方面?

在设计评估之前,您应了解如何评估输出。您需要了解以下几个术语。

条件是指需要测试的规则和维度。例如,品牌一致性、有害内容和无障碍功能。

每项评估标准都通过一个指标来衡量。指标是指根据标准衡量模型输出的单项具体得分。此得分可以是二元值,也可以是某个范围内的值,用于衡量输出结果与评估者的预期之间的差距。

可以使用不同类型的指标来衡量同一标准。例如,对于品牌一致性:

  • “这句口号是否符合品牌调性?”相应指标为 PASSFAIL
  • “在 1 到 5 的范围内,这句口号与品牌的契合度如何?”相应指标是介于 1 到 5 之间的整数。

评估器是用于对标准进行评分的代码或模型。评估人员确定指标。