你的AI系统上线前，真的测对了吗？

大多数人以为AI测试就是跑几个用例看结果对不对——但一个客服机器人第二周就开始"编造"退款政策，这种损失怎么防？

巴西开发者Lucas Pereira在2025年4月19日的技术梳理中，把AI评估（evals）拆解成可操作的工程实践。核心发现：评估不是终点，而是持续决策的数据基础。

为什么评估比想象中更关键

Lucas提到一个真实场景：客服机器人第一周表现完美，第二周却在退款期限问题上"幻觉"出错误答案。没有评估层，这类风险只能靠用户投诉发现。

他把评估的价值压到三个支点：

• 部署前质量控制——像传统软件的单测/集成测试一样，设定指标门槛才能上线

• 回归检测——换模型版本、改提示词、调检索器，怎么知道是进步还是退步？

• 数据驱动的持续改进——从MLFlow学到的核心经验：架构决策不能靠直觉，要靠实验和证据选 winner

「你不应该在黑暗中做架构决策。」这是Lucas从机器学习生命周期管理框架MLFlow中提炼的原则。

四类基础评估对象

原文将AI系统拆成四个必测模块，每个都有对应的指标和工具：

1. 智能体（Agent）——多步骤任务执行，测工具调用准确率、任务完成率

2. RAG系统——检索增强生成，测上下文相关性、答案忠实度、检索准确率

3. 大语言模型（LLM）本身——测幻觉率、指令遵循度、输出一致性

4. 端到端流程——用户真实交互路径的完整验证

关键洞察：不同层级的问题需要不同的评估粒度。RAG的检索失败和LLM的生成幻觉，不能混为一谈。

从理论到落地的工具链

Lucas的实践全部基于OpenRouter的免费LLM接口完成，降低了实验成本。他在文末附上了个人学习仓库，持续跟踪新方法和框架。

这套方法论的隐性门槛在于：指标设计本身就是产品决策。选什么指标、设什么阈值，等于在定义"什么算好"的质量标准。

对于25-40岁的技术从业者，这意味着evals不是QA团队的后期工序，而是产品经理和工程师的前置共识工具。上线前的指标会议，可能比上线后的A/B测试更能规避系统性风险。

冷知识：Lucas写这篇文章的当天，还在同步跟踪Harness协议和LLM新版本——评估方法论的迭代速度，正在追赶模型本身的更新节奏。