怎么放心上线 — 评测 / 追踪 / 红队
这条分支在货架里的位置: 总纲把这 195 个库的共性讲成一句话——「把一个只会吐文本的 LLM,包成能在循环里感知-动作、能被放心运营的程序」。前面几条分支讲怎么造这个 agent(编码、框架、多智能体、记忆、检索、工具落地)。本章是**「怎么放心运营」的后半截「监工」:agent 造出来了、也能动作了,可它非确定性**、会幻觉、会被越狱/注入——你凭什么敢把它接上生产流量?这条分支就是回答这个问题的一整套工程:测它、盯它、攻它。
30 秒导读: 模型本身只保证「大概率说对」,而生产要的是「能被验收、能被追责」。这一档 17 个库把「监工」拆成三块——① 像 pytest 一样测 LLM 输出(评测:给不确定的输出定一个可打分、可回归的标准)、② 用 OTel 追踪长跑 agent 的每一步 + 盯成本(可观测:把黑盒变成可回放、可算钱的 span 树)、③ 主动越狱 / 注入去攻它(红队:在上线前替坏人把该干的坏事干一遍)。本章把这 17 个库横过来切,告诉你三块各有哪几种流派、代表库怎么做、以及怎么按需求选。
怎么读本章: 正文是给人读的白话综述,不出现路径行号。每个论断挂一个脚注
[^x],精确的仓库/路径:行+ 符号名都在脚注里;对比矩阵单开一列「代码锚点」放引用。人读正文,agent 读脚注 / 锚点列。
1. 这条分支要解决什么(第一性原理)
承上:整个货架的共性是「给只会说话的 LLM 装手脚,让它能对世 界采取动作,并被放心运营」。前面分支把「造 agent」讲透了;可造出来 ≠ 敢上线。本分支把「放心运营」里最硬的那一半单拎出来——监工。
为什么单靠模型不够?因为 LLM 有三条改不掉的毛病,恰好卡死了传统软件的验收范式:
| 模型的毛病 | 对传统「测试 / 运维 / 安全」意味着什么 |
|---|---|
| 非确定性 | 同样输入两次跑,输出可能不同——assert output == "预期" 直接失效 |
| 会幻觉 | 语法完全合法、事实凭空捏造——编译器 / linter 一个都拦不住 |
| 会被越狱 / 注入 | 攻击面是自然语言,而不是 SQL / XSS——WAF 与静态扫描无从下手 |
于是这条分支的第一性问题就是:当被监工的对象本身不可靠、不可复现、攻击面是语言时,「测试、运维、安全」这三件传统工程各要重造成什么样子? 三块答案正好对上三个子分支:
- 评测(测它): 输出没有唯一正确答案,就不能靠字符串相等断言。得改用「打分」——要么规则打分,要么请另一个 LLM 当裁判(LLM-as-judge),再把分数卡一个阈值当 pass/fail,像 pytest 一样跑、像 CI 一样挡回归。
- 可观测(盯它): 一次 agent 调用不是一个函数,而是一棵「LLM 调用 → 工具调用 → 子 agent」的树,还烧真金白银的 token。得把每一步记成 span、串成 trace,顺带把 token 成本、延迟一并算清——这几乎就是 OpenTelemetry 的问题,只不过语义换成了 LLM。
- 安全 / 红队(攻它): 坏人用的是自 然语言 payload。防御方只能先扮坏人:自动合成越狱 / 注入攻击去打自己的 agent,看它招不招;上线后再挂一层实时护栏(guardrail)在入口 / 出口拦截。
一句话直觉: 前面分支让 agent「能动」,本分支让 agent「可信」。评测给不确定的输出定一把可回归的尺;可观测把黑盒长跑变成可回放、可算钱的 span 树;红队在坏人之前先把坏事干一遍。三者共用一条底线——别赌模型不出错,要在出错时能测出来、看得见、拦得住。
形态上,这 17 个库落在三种角色里:库 / SDK(你 import 进代码里跑:deepeval、promptfoo、deepteam、llamafirewall、nemo-guardrails、agentops、logfire、openllmetry、openlit、opik、evidently、mlflow),自托管平台(带后端 + UI 的一整套:langwatch、laminar、helicone、cozeloop、ai-infra-guard),不少库两副面孔都有(opik / langwatch 既能当库又是平台)。
2. 流派一:像 pytest 一样测 LLM 输出(评测)
第一块是评测——把「这条输出到底好不好」变成一个能打分、能卡阈值、能进 CI 的断言。难点只有一个:输出没有唯一正确答案。于是「怎么打这个分」分化出几个流派,从最不依赖模型到最依赖模型排开。
怎么读这张图: 从左到右是「打分时对 LLM 的依赖递增」。最左边是纯规则 / 字符串断言,完全确定;越往右越靠「请一个 LLM 当裁判」,越灵活也越不稳。
确定、便宜、只能测浅层 ───────────────────► 灵活、能测语义、但裁判本身会飘
┌────────────┐ ┌──────────────┐ ┌──────────────┐ ┌────────────────┐
│ ① 规则断言 │──►│ ② LLM 裁判 │──►│ ③ 带步骤/权重 │──►│ ④ 决策树 / DAG │
│ contains / │ │ llm-rubric │ │ 的裁判 G-Eval │ │ 确定性拆解裁判 │
│ 正则 / JSON │ │ (打分+理由) │ │ CoT+logprob │ │ 逐节点判定 │
└────────────┘ └──────────────┘ └──────────────┘ └────────────────┘