分支⑥ 知道它行不行
这条分支补主干的哪块缺口: 模型「不保证对,你也看不见它在干嘛」。前五条让 agent 能跑;这条让你度量它准不准、看见它每一步、甚至反过来训练它——把 agent 从「能跑」推到「可信、可改进」。没有这条,前面所有努力都没法验证、没法迭代。
1. 这条分支是什么(第一性原理)
LLM 会一本正经地编,agent 还会在多步里把小错滚成大错。你需要在三个时点回答「它行不行」:
上线前 线上 回头改进
(offline eval) (observability) (training)
拿基准/测试集打分 给真实流量记 trace、看每一步 用结果反过来训模型
│ │ │
swe-bench langfuse ragen (RL)
openai-evals phoenix swe-smith (造数据)
ragas (RAG专项) deepcode/deeptutor
simple-evals (自带评测脚手架)
分支里的库,差别在在哪个时点看、看什么对象(通用模型 / RAG / 编码 agent / 生产 trace)、看完拿来干嘛(判优劣 / 排错 / 训练)。
2. 分支内有哪几种做法(流派)
- 基准与数据工厂:固定任务集打分,或批量造任务。
- RAG 专项评测:针对「检索+生成」的特有指标(忠实度、相关性)。
- 生产可观测:给线上真实流量记 trace、加分数、做实验。
- 用 RL 训练 agent:把交互结果当奖励信号,反过来训模型。
3. 对比矩阵(子库区别,逐格接地)
3.1 基准与数据工厂(上线前 / 造数据)
| 库 | 评什么 | 机制 | 一句话差异 | 代码锚点 |
|---|---|---|---|---|
| swe-bench | 编码 agent 解真实 GitHub issue | 把 issue+repo 快照变成可评实例,Docker 评测 patch | 编码 agent 的事实标准基准;引用必须点明 split(Verified≠full≠Lite) | (TODO: 待 swe-bench 子库 doc;swebench/collect/、harness/) |
| swe-smith | 不评、造 SWE-bench 式任务 | 程序/LM/PR 镜像三种注入 bug + 验证 | 无限合成任务工厂,喂 agent 微调(SWE-agent-LM 血统) | (TODO: 待 swe-smith 子库 doc;swesmith/bug_gen/、harness/) |
| openai-evals | 通用 LLM 基准 | YAML 注册表 + eval 类 + JSONL 样本;model-graded | 大型 eval 实现语料库;维护模式,取其模式而非当依赖 | (TODO: 待 openai-evals 子库 doc;evals/registry/) |
| openai-simple-evals | 头部基准(MMLU/GPQA…)的最简实现 | 一文件一基准,零样本 + CoT | 「官方报数用的最诚实最简实现」,抄形状别抄仓库 | (TODO: 待 openai-simple-evals 子库 doc;*_eval.py) |
| google-adk-python | agent 轨迹评测(eval set、trajectory scoring) | 框架内置评测harness | 把评测做进 agent 框架本体;绑 Google 栈 | (TODO: 待 google-adk-python 子库 doc;src/google/adk/evaluation/) |
3.2 RAG 专项 / 生产可观测 / 训练
| 库 | 时点 | 看什么 | 一句话差异 | 代码锚点 |
|---|---|---|---|---|
| ragas | 上线前(RAG) | faithfulness / context precision-recall / answer relevancy + 合成测试集 | RAG 专项指标库;LLM-as-judge 会带 judge 偏见,比较时要 pin judge 模型 | (TODO: 待 ragas 子库 doc;metrics/) |
| langfuse | 线上 | trace / observation / score 数据模型 + prompt 管理 + dataset 实验 | 生产级 LLM 工程平台;自托管需 ClickHouse+PG+Redis(v3) | (TODO: 待 langfuse 子库 doc;web/、worker/) |
| phoenix | 线上 | 基于 OTel/OpenInference 的 trace + 在 span 上跑 LLM-as-judge | 自托管可观测;走 OpenInference 约定,与 OTel GenAI semconv 要刻意映射 | (TODO: 待 phoenix 子库 doc;src/phoenix/) |
| ragen | 训练 | 把多轮交互当 RL 轨迹(StarPO)优化 | agent 自我改进的训练侧参考栈(建在 veRL 上);纯推理工作用不上 | (TODO: 待 ragen 子库 doc;ragen/ trainers/rollouts) |
| hkuds-deepcode | 训练/评测脚手架 | 论文→代码,自带 PaperBench 式可复现评测 | 研究 agent 把「评测脚手架」和 agent 一起交付;可复用的是角色分解 | (TODO: 待 hkuds-deepcode 子库 doc) |
| hkuds-deeptutor | 评测/会话 | 长程教学循环(assess→explain→quiz→adapt)+ 会话态 | 长程 agent 的「评测=教学效果」,会话态设计是亮点 | (TODO: 待 hkuds-deeptutor 子库 doc) |
4. 模式与权衡
- 永远点明 split / judge / 版本。 swe-bench 卡片要求报分必带 split;ragas/phoenix 的 LLM-as-judge 继承 judge 偏见,比较不同 run 必须 pin judge 模型;simple-evals 强调 prompting 姿态不同就不可比。「凭印象比分数」是这条分支最大的坑。
- 框架 vs 模式。 openai-evals 在维护模式——取其模式语料,别当活依赖;simple-evals 干脆「抄形状别抄仓库」。它们的价值是「eval 长什么样」的范本。
- 可观测的 telemetry 标准要统一。 langfuse 原生 SDK 语义比 OTel 富,phoenix 走 OpenInference——卡片都提醒:每个服务选一条 ingestion 路径并保持一致,别混。
- 评测、可观测、训练正在闭环。 trace(langfuse/phoenix)→ 变成 dataset → 跑 eval(ragas/openai-evals)→ 喂训练(ragen/swe-smith)。这条闭环是 agent 从「能跑」到「持续变好」的引擎。
5. 趋势
- 从「跑基 准」到「闭环」:trace → dataset → eval → 训练的回路在成形,langfuse/phoenix 的 dataset+experiment 功能就是为接上 eval 而生。
- 合成数据规模化:swe-smith 把训练任务从「人工标注」变成「无限合成」,但卡片提醒合成分布≠真实分布,别跨集比分。
- RL 训多轮 agent 升温:ragen 的 StarPO 把「多轮交互」当轨迹优化,与分支⑤的 dspy 提示优化在「自动改进」上汇流。
6. 代表作 + 深入
- 评编码 agent → swe-bench(记得点 split);造训练任务 → swe-smith。
- 评 RAG → ragas。
- 给生产 agent 加 trace → langfuse(平台全)或 phoenix(OTel 原生、自托管)。
- 写通用基准 → 抄 openai-simple-evals 的形状。
- 用 RL 训多轮 agent → ragen。