Rob Zuber 称 LLM 测试工具已备齐九成

CircleCI CTO Rob Zuber 对 LLM 应用测试有一个大胆的判断：在他看来，所需的工具和方法我们已经有了 90%。他认为，CI/CD 天然适合测试由 LLM 驱动的应用。这是一门老手艺的演进，而不是一门新学科。

这也是 Automated Testing for LLMOps 的主张。这门短期课程由 Zuber 讲授，DeepLearning.AI 与 CircleCI 合作制作，2024 年 1 月发布。课程为入门级，时长约一小时，主要目标是帮你搭建一个评测 LLM 应用的 CI 工作流。

对前线部署工程师（FDE）来说，这一小时花得值。客户的智能体或检索增强生成（RAG）系统一旦上了生产环境，你最常听到的问题就是：“你怎么知道这次改 prompt 没把别的东西弄坏？”这门课让你能用一条流水线来回答，而不是靠一句保证。

一小时里讲了什么？

课程大纲很紧凑：简介、CI 概述、自动化评测概述、模型打分评测、完整测试框架、总结、测验，以及一节可选的 CircleCI 配置文件讲解。任何人都可以报名，但计分练习需要 PRO 账户。

课程面向具备 Python 基础、已经做过 LLM 应用的人。如果你从没调用过模型 API，先做个小应用再来：课程默认你手上已经有东西可测。

内容围绕常见的 LLM 故障展开：幻觉、数据漂移，以及有害或冒犯性输出。课程的出发点很简单：LLM 的行为比传统软件更难预测。

第一个思路：两类评测，两种节奏

最值得记住的，是课程把评测分成两类。基于规则的评测靠字符串或模式匹配，例如正则表达式，运行非常快。模型打分评测用于好答案或坏答案都有很多种合理形式的问题，课程用它来检测幻觉。

假设你在为一家零售商部署一个回答退款政策问题的机器人。基于规则的评测检查机器能量化的东西：输出是合法 JSON，订单号格式正确，内部邮箱地址从不外泄。

模型打分评测回答正则回答不了的问题：机器人有没有编造一条政策文档里根本没有的“60 天内可退款”条款？

由此可以得出一种实用安排：便宜、快速的那类在每次提交时运行；昂贵、缓慢的那类在更关键的节点运行，例如合并或发布之前。这是运维层面的建议，课程并未明确规定，但它直接源于课程所描述的两类评测的特点。

第二个思路：评测就是测试，应当放进 CI

第二个思路来自 Zuber 的定位。如果评测只是某个偶尔有人打开的 notebook，到客户现场第一周之后就会被遗忘。把评测放进 CI，回答质量就成了一道关卡，和单元测试一样：不通过，就不能合并。

客户的工程团队一听就懂这种说法。你不需要说服他们采用陌生的“LLMOps”流程，只需在他们已经在用的流水线里加几个 job。

第三个思路，以及该舍弃的部分

第三个思路课程只是点到为止，CircleCI 自身的生产经验讲得更清楚。据 CircleCI 的人介绍，非确定性是主要挑战，而且没有哪一种评测是完美的，必须组合多种评测。

他们还建议在应用中内置收集用户反馈的工具，再把这些反馈回流到评测集中。

一门只讲 CI 的课程教不了这个闭环，而这恰恰是 FDE 在现场必须做的事。机器人答错、真实用户点了 👎 的案例，应当成为下周评测集里的新测试用例。

该舍弃的是工具。课程中两类评测都在 CircleCI 上自动运行，而你的客户可能用的是别的工具。

所以，保留思路，自己重写配置。用 GitHub Actions 做一个具体练习：第一个 job 在每次 push 时运行基于规则的评测；第二个 job 只在向主分支发起 pull request 时运行，声明依赖第一个 job，并在一组固定问题上调用打分模型。

最后开启分支保护，两个 job 都通过后才能合并。

谁该学，按什么顺序学？

如果你是写过 CI 但从没评测过 LLM 的软件工程师，这门课正好是入门：先学它，再去找关于 LLM-as-judge 的深入资料。如果你已经是 FDE、一直在手动跑评测，可以跳过 CI 简介，直接看模型打分评测和完整测试框架。

简历上别写“完成 Automated Testing for LLMOps 课程”。写一句有结果的话，例如“为一个 RAG 应用搭建 CI 流水线，运行基于规则和模型打分的评测，幻觉率超过阈值时阻止合并”，并附上 repo 链接。

当 FDE 岗位描述在“CI/CD”旁边提到“evals”或“LLM testing”时，准备好这样一条流水线，被问到时能讲清细节。

关于那 90%，Zuber 也许说得对。但在客户那边，缺的那 10% 往往决定你能不能接到更多工作。