🧪 为什么你的 AI 应用上线后没人知道有没有效果？从“可评估性”说起

在技术大会上，我经常问一个问题：

哪个更糟糕？从未上线的应用，还是上线了但没人知道它是否正常工作？

大部分工程师都会选第二个：上线了但无法评估。
因为这种应用不仅占资源，要想下线还可能带来更大的代价。

事实上，大量 AI 应用的 ROI（投入产出）都是模糊甚至无法判断的。
原因并不只是“难评估”，更常见的是：开发者根本不知道用户是怎么用的——甚至有没有用。

比如：

• 某二手车公司做了“估值模型”，上线一年后用户都挺喜欢，但工程师完全不知道它准不准。

• ChatGPT 火起来后，各公司都在冲 chatbot，但很多至今不清楚它们到底是提升客服体验，还是让用户更烦躁。

这些问题背后其实只说明了一件事：

🚦 在做 AI 应用前，没有定义“怎么判断成功”

这就是我提的一个核心概念：

⭐ Evaluation-Driven Development（评估驱动开发）

灵感来自 TDD（测试驱动开发）：写代码前先写测试。

在 AI 工程里，理念类似：

做应用之前，先写好评估标准。

为什么这样做？

因为真正能落地的企业级 AI 应用，往往都有一个共同特点：
成功可以量化。

例如：

• 推荐系统 → 看点击率、停留时长、购买率

• 风控系统 → 看节省了多少钱

• 代码生成 → 能不能正确运行

• 分类类任务 → 情感分析、意图识别、下一步动作预测等，都有明确指标

这些都因为“能评估”，所以“能落地”。

但只做能量化的应用，就像“只在灯下找钥匙”——方便，却限制了创新方向。

我认为：

真正限制 AI 落地的最大瓶颈，就是评估体系。

只要能搭建稳定的评估流水线，很多新场景都会被解锁。

---

📌 一个 AI 应用的评估体系，一般要覆盖四类能力

做任何应用之前，都应该先定义好你的模型必须达到哪些指标。一般可分为 4 大类：

1. 领域能力（Domain-Specific Capability）

2. 生成能力（Generation Capability）

3. 指令遵循能力（Instruction Following）

4. 成本与延迟（Cost & Latency）

举个例子：让 AI 总结法律合同。

• 领域能力：模型是否能理解法律条款？

• 生成能力：总结内容是否连贯、准确？

• 指令遵循：是否按你要求的字数、格式输出？

• 成本与延迟：每次总结花多少钱、耗时多久？

下面我们逐项拆开来看。

---

🧩 1. 领域能力：模型要“懂这个领域”才能做事

如果你要：

• 写代码 → 模型必须有代码能力

• 翻译拉丁文 → 模型必须看过大量拉丁文

• 做法律摘要 → 模型必须具备法律文本理解能力

领域能力的来源主要是：

• 模型结构与大小

• 训练数据覆盖范围

没有训练过拉丁文的模型，理论上根本无法理解拉丁文。

所以第一件事是确定模型“是不是天生就能胜任这个任务”。

如何评估？

最常见方法就是利用 领域基准（benchmarks）。
现在已经有成千上万的 benchmark，用于测试模型是否具备：

• 代码生成

• 调试能力

• 数学能力

• 理科知识

• 常识推理

• 法律知识

• 工具调用

• 游戏策略
  …几乎你能想到的领域都有。

一些评估细节差异

例如：

✓ 代码类任务 → 功能正确性（Functional Correctness）

但如果只是“能跑”，其实还不够：

• 性能重要吗？

• 资源占用是否合理？

• 可读性是否足够高？

比如 text-to-SQL 任务：
即使查询正确，但运行时间是 ground truth 的 10 倍，你的系统能接受吗？

BIRD-SQL 就把运行效率也纳入评估。

✓ 非代码任务 → 多选题、分类最常见

因为验证容易、稳定。

例如 MMLU、AGIEval、ARC 等热门 benchmark —— 都是大量 MCQ。

分类指标例如：

• Accuracy

• Precision

• Recall

• F1

但它们有一个问题：评价“知道”比评价“能生成”要容易得多。

MCQ 测的是“识别正确答案”，不是“生成内容的能力”。

---

🧩 2. 生成能力：模型是真的“写得好”，还是只是“答对选择题”？

MCQ 无法评估：

• 总结是否流畅

• 翻译是否自然

• 文章是否结构清晰

• 生成内容是否忠实原文

这些需要 生成类指标，并且常常要用到：

• AI judge

• 人工评审

• LLM-based 评估 pipeline

这部分在此文不展开（对应书的下一节）。

---

🧩 3. 指令遵循：模型要严格按你说的来

例如：

• 字数限制

• 输出格式

• JSON schema

• 步骤顺序

• 不能出现某些敏感词

这类指标通常是自动可检测的，也是企业应用中非常重要的一环。

---

🧩 4. 成本与延迟：企业最现实的问题

即便模型再强，一次请求要花 2 美元、等 15 秒——应用基本宣告失败。

因此评估也必须包括：

• 推理成本

• 响应延迟

• 吞吐量

尤其是当应用面向真实用户时。

---

🔚 总结：AI 应用必须“先会评估，再谈落地”

一个成功的 AI 应用，通常不是从建模开始，而是从一个清晰的问题开始：

你怎么知道这个应用“成功”？

企业真正需要的不是一个“看上去很酷的模型”，
而是一个 结果可度量、可复现、可优化的业务组件。

如果我们能：

• 在应用开发前定义好完整评估体系

• 构建可靠的评估流水线

• 持续监控模型在真实世界的表现

那么 AI 的落地速度将大幅提升。

Evaluation-Driven Development，不是技术，是方法论。
也是未来 AI 工程最重要的基石之一。