专题定位:2026 年 LLM 工程的最大共识是"评估前移"——不再等上线才知道效果,而是把评估嵌入开发全循环。本专题讲 FDE 如何搭一套能持续度量、驱动迭代的评估体系。

一、为什么"评估驱动"是 2026 的范式

传统软件有单元测试/集成测试,效果可自动验证。但 LLM 应用长期是"黑盒"——开发者改了 prompt 或换模型,只能靠"人工看看几个例子"判断好坏,既不可重复,也不可靠。

评估驱动开发(Eval-Driven Development) 把软件工程的"测试驱动"思想搬到 LLM:

• 先定义评估集和指标,再开发;
• 每次改动(prompt/模型/RAG)都跑评估,量化影响;
• 用数据决定"改了是变好还是变坏",而不是靠感觉。

为什么 2026 才普及:早期 LLM 应用简单(单轮问答),评估需求弱;2025—2026 Agent/RAG 复杂化,不评估就无法迭代,评估驱动成刚需。

二、评估的三层结构

第一层:组件评估(检索/生成各自)

• 检索:召回率、精确率、MRR;
• 生成:忠实度、相关性;
• 工具:调用准确率。

第二层:端到端评估(整个系统)

• 任务成功率;
• 答案质量(忠实/相关/完整);
• 用户满意度。

第三层:业务评估(对齐北极星)

• 良品率、准确率、成本、转化率;
• 直接对照项目北极星指标(见第 7 章结果定义卡)。

三、评估集构建

评估集是评估的命脉。 没有好评估集,评估就是空谈。

评估集来源

• 真实查询:从客户真实使用中采样;
• 边界用例:人工构造难例、对抗例;
• golden set:人工标注的标准问答对;
• bad case:历史出错的案例,纳入回归集。

评估集规模

• 起步:50—200 条覆盖核心场景;
• 成熟:500—2000 条,含各类边界;
• 持续扩充:bad case 不断回流。

评估集管理

• 版本化(每次评估用哪个集);
• 标注规范(怎么算"对");
• 防污染(评估集不能进训练)。

四、LLM-as-Judge:用强模型当评审

LLM-as-Judge 是 2026 评估的主流手段——用强模型(GPT-4 级)评判被评估系统的输出。

优点

• 可大规模(比人工快);
• 可多维度(忠实/相关/完整);
• 可解释(给出评判理由)。

陷阱

• 偏差:judge 偏好同源模型、偏好长答案、偏好自信表达;
• 成本:大规模调用贵;
• 自身不准:judge 也会错。

最佳实践

• judge 用比被评更强的模型;
• 用 rubric(评分细则)约束 judge;
• 人工抽验 judge 质量;
• 关键决策不唯 judge(加人工)。

五、评估指标体系(给 FDE 的清单)

检索质量

• Recall@k:相关文档在 top-k 的比例;
• Precision@k:top-k 里相关的比例;
• MRR:第一个相关文档的排名倒数;
• NDCG:考虑排序的质量。

生成质量

• Faithfulness(忠实度):答案是否可由检索内容支持(防幻觉);
• Answer Relevancy:答案是否切题;
• Context Precision/Recall:检索上下文质量。

Agent 质量

• Tool Call Accuracy:工具调用是否正确;
• Plan Quality:规划是否合理;
• Task Success Rate:任务是否完成;
• Step Efficiency:步数是否过多。

系统质量

• Latency:延迟;
• Cost:成本(token/调用);
• Error Rate:错误率。

业务质量

• 对照北极星(良品率、准确率、ROI)。

六、评估工具(2026)

RAGAS:RAG 专用评估(忠实度/相关性/上下文指标); TruLens:LLM 应用评估与追踪; LangSmith Eval:LangChain 生态评估; Phoenix(Arize):LLM 评估与可观测; DeepEval:开源 LLM 单元测试框架; Promptfoo:prompt/模型对比评估。

选型:RAG 用 RAGAS,通用用 TruLens/LangSmith,对比 prompt/模型用 Promptfoo。

七、评估驱动的开发循环

核心循环

1. 定义/更新评估集;
2. 跑评估,得到基线指标;
3. 改动(prompt/模型/RAG/Agent);
4. 再跑评估,对比基线;
5. 数据决定保留/回滚;
6. bad case 回流评估集。

这个循环的关键

• 自动化:每次改动自动跑评估(CI);
• 可对比:历史指标可追溯;
• 有门槛:定"达标线",不达标不发布;
• 快反馈:评估要快(不能一次跑几小时)。

八、持续评估:CI for LLM

把评估嵌入 CI/CD,是 2026 成熟团队的标志。

LLM CI 的实践

• prompt/模型变更触发评估;
• 评估不达标阻断发布;
• 回归集防止"修一个坏一个";
• 评估结果可视化看板。

挑战

• 评估有随机性(LLM 非确定),要多次平均;
• 评估本身要维护(评估集/指标更新);
• 成本(CI 跑评估要花钱)。

九、在线评估:AB 与反馈

离线评估之外,还要在线评估。

在线评估手段

• AB 测试:新旧版本分流,对比业务指标;
• 影子模式:新版本跑但不影响真实业务,对比;
• 用户反馈:点赞/点踩、评分、举报;
• bad case 监控:线上错误自动收集。

在线 vs 离线

• 离线:快、可控、但可能与真实有差;
• 在线:真实、但慢、有风险;
• 两者结合:离线筛,在线验。

十、评估的常见误区

误区一:只看整体指标 整体准确率 90% 可能掩盖"某类用例 0%"。要分场景看。

误区二:评估集污染 评估集混进训练/RAG,指标虚高。要隔离。

误区三:唯 LLM-as-Judge judge 会错,关键场景要人工。

误区四:评估不更新 业务变化,评估集/指标要跟着变。

误区五:评估与业务脱节 评估指标高但业务价值没提升——要始终对齐北极星。

本专题小结

• 评估驱动开发 = 测试驱动思想搬到 LLM,先评再开发,数据决定迭代;
• 评估三层:组件(检索/生成/工具)、端到端、业务;
• 评估集是命脉:真实+边界+golden+bad case,版本化、防污染;
• LLM-as-Judge 是主流,但有偏差,需 rubric+人工抽验;
• 指标体系:检索(Recall/Precision/MRR)、生成(Faithfulness/Relevancy)、Agent(Tool/Plan/Success)、系统(延迟/成本)、业务(北极星);
• 工具:RAGAS/TruLens/LangSmith/Phoenix/DeepEval/Promptfoo;
• 开发循环:定义集→基线→改动→再评→数据决策→bad case 回流;
• 持续评估:LLM CI,变更触发、不达标阻断;
• 在线评估:AB/影子/反馈/bad case 监控,与离线结合;
• 误区:只看整体/污染/唯judge/不更新/脱节业务。

本专题来源:RAGAS/TruLens/LangSmith/Promptfoo 文档、O'Reilly《AI Agents Stack 2026》、LangChain eval 指南、用户库《FDE工程化工具链》《fde-delivery 70-pitfalls-checklists》、本书第 7、9 章。