AI评估从任务指标到线上实验完整原理

AI 评估不是让人读几个答案后说“看起来不错”，也不是所有任务都算一个准确率。分类、抽取、检索、生成、Tool Calling 和 Agent 的正确单位、标准答案、错误代价与指标完全不同。

真正的评估要回答：系统要完成什么任务，什么证据算成功，错误有多严重，当前样本能否代表未来流量，改善来自哪一层，离线改善能否转化为真实业务收益，以及上线后怎样发现结论失效。

学习目标

学完后应能：

从业务结果反推任务、样本单位、标签和指标。
区分离线质量、系统性能、安全门禁和线上业务指标。
从混淆矩阵推导 Accuracy、Precision、Recall 和 F1。
根据误报、漏报成本选择分类阈值，而不是固定使用 0.5。
理解概率校准、Brier Score 和可靠性分桶。
为抽取、RAG、生成、Tool Calling 和 Agent 选择正确指标。
设计代表性、分层、时间切分且防泄漏的数据集。
建立标注指南、盲标、双标、仲裁和一致性度量。
拆分 RAG 的文档、检索、上下文、生成和引用问题。
区分确定性规则、LLM Judge 与人工评估的边界。
设计线上 A/B 的随机化单位、护栏、SRM 检查和停止条件。
根据逐层证据执行质量事故 Runbook。

一、先定义评估对象和单位

“评估 AI 助手”范围过大。必须先写清：

问题	示例
用户是谁	医院数据管理员、普通员工、内部运维
要完成什么任务	查资产、解释错误、抽取字段、创建工单
一条样本是什么	单轮问题、完整会话、文档、字段或Agent任务
权威真值来自哪里	业务数据库、版本化制度、专家标注、模拟Tool
什么算成功	找到正确资产且未越权，工单一次创建成功
错误代价是什么	漏掉风险、误拦正常用户、错误写入、延迟或成本

为什么样本单位很重要

对分类任务，一条样本通常是一个待分类对象。
对字段抽取，一条样本可能是一份文档，但评分单位可以是字段。
对 RAG，一条 Query 可能对应多个相关 Chunk。
对多轮助手，只评最后一句会漏掉历史污染和前后矛盾。
对 Agent，最终完成不等于过程安全，必须评整个轨迹。

如果同一会话的每一轮都当作独立样本计算，会把高度相关数据误当成大量独立证据。

二、从业务目标建立指标树

mermaid

flowchart TD
    A["业务目标：安全完成采集工单"] --> B["任务结果"]
    A --> C["AI质量"]
    A --> D["安全护栏"]
    A --> E["系统体验"]
    A --> F["成本"]
    B --> B1["工单有效率、一次成功率"]
    C --> C1["意图、字段、引用、Tool参数"]
    D --> D1["越权、秘密、未确认写入"]
    E --> E1["TTFT、P95、错误和可用性"]
    F --> F1["每个成功任务成本"]

2.1 四类指标不能混为一个分数

类别	回答的问题	例子
任务质量	AI结果本身是否正确	分类F1、字段准确、引用支持
安全护栏	是否出现不可接受事件	跨租户、秘密、未授权Tool
系统性能	用户是否能及时稳定获得结果	P95、超时、TTFT、TPOT
业务结果	是否真正创造价值	任务完成、人工转接、返工率

安全事件不能通过与普通质量加权求平均被抵消。系统质量很高但每个请求耗时 40 秒，也不等于产品可用。

2.2 领先指标和滞后指标

领先指标：JSON 成功、引用合法、检索 Recall、TTFT，能快速定位技术变化。
滞后指标：投诉、返工、任务完成、续费，最接近业务价值但反馈慢且受其他因素影响。

只优化代理指标会产生 Goodhart 问题：当“答案越长”被误当作完整性，模型会输出冗长内容；当“少拒答”被当作覆盖率，模型可能开始编造。每个代理指标都要与真实业务结果定期核对。

三、数据集怎样构建才有代表性

mermaid

flowchart TD
    A["真实日志、业务流程和风险清单"] --> B["授权抽样与脱敏"]
    B --> C["去重和问题簇分组"]
    C --> D["场景、难度、语言、风险分层"]
    D --> E["开发集"]
    D --> F["回归集"]
    D --> G["盲测或时间外集合"]
    G --> H["发布最终验收"]

3.1 数据来源

真实流量的合规抽样。
产品需求和标准业务流程。
历史故障、投诉和人工纠正。
专家设计的边界、无答案和冲突资料。
安全团队设计的注入、越权和敏感样本。
生成式扩展样本，但必须去重并人工抽验。

合成数据适合补稀有风险，不代表真实分布；真实日志更有代表性，却可能含敏感数据和历史产品偏差。应组合使用并保留 source 标签。

3.2 分层而不是只随机抽样

至少按以下维度看覆盖：场景、租户、角色、语言、输入长度、难度、风险、资料版本、多轮长度、工具类型。高风险事件在线上很少，按自然流量抽一万条也可能一条都没有，因此必须过采样并单独报告，不能再按总体比例稀释。

3.3 防止数据泄漏

同一文档相邻 Chunk、同一会话、同一模板改写应放在同一集合。时间敏感任务用过去开发、未来盲测；开发者不能看到 Holdout 标签。否则模型或 Prompt 只记住近重复题，离线分数会虚高。

评测集还要版本化：样本内容、标签、拆分、标注指南和 Hash 共同构成 Dataset Revision。

四、真值和标注怎样产生

4.1 真值不总是一段标准答案

任务	真值形式
分类	一个或多个允许标签
抽取	字段、类型、单位、证据位置
检索	相关文档集合及相关等级
生成	必须事实、禁用事实、证据和Rubric
Tool	是否调用、工具名、参数约束、权限结果
Agent	允许动作、禁止动作、最终状态和预算

订单状态、金额和权限应从权威系统快照产生；不要让标注者凭记忆猜。存在多个合理答案时，指南要说明允许范围，不能强迫唯一措辞。

4.2 标注流程

先定义标签和正反例，不急着大规模标注。
用小批量试标发现歧义。
标注者看不到候选版本，避免偏爱某模型。
关键样本至少双人独立标注。
计算一致性并分析具体分歧。
由有资格的仲裁者确认最终标签。
修改指南后对受影响样本重新标注。
保存标注者角色、指南版本、时间和仲裁原因。

4.3 为什么只看一致率不够

当 95% 样本都是“无需拒答”时，两人始终标“不拒答”就有 95% 一致率，即使他们不会识别真正风险。Cohen's Kappa 会扣除按边际分布随机一致的部分：

text

kappa = (observedAgreement - expectedAgreement)
        / (1 - expectedAgreement)

Kappa 不是标注质量的唯一真理：类别极不平衡时也会受影响。仍要看逐类混淆、分歧案例和高风险漏标。

五、分类指标从混淆矩阵推导

以“是否需要人工审核”为正类：

实际\预测	预测需要审核	预测不需审核
实际需要审核	TP	FN
实际不需审核	FP	TN

TP：风险样本正确送审。
FN：风险样本被放行，通常代价最高。
FP：正常样本被误拦，增加人工和用户成本。
TN：正常样本正确放行。

text

Accuracy  = (TP + TN) / 全部
Precision = TP / (TP + FP)
Recall    = TP / (TP + FN)
F1        = 2 * Precision * Recall / (Precision + Recall)

为什么Accuracy会骗人

若 10000 条请求只有 100 条风险，模型全部预测“正常”，Accuracy 仍有 99%，但 Recall 为 0，一个风险都没识别。安全筛查通常更关注 Recall；人工容量有限时又要关注 Precision。

Micro、Macro和Weighted F1

Micro：汇总所有类别 TP/FP/FN，容易被大类主导。
Macro：每类先算再平均，小类权重相同，适合看长尾。
Weighted：按各类样本数加权，介于两者之间。

报告多分类模型时至少给混淆矩阵和每类 Precision/Recall，不要只给一个 F1。

六、阈值选择取决于错误代价

分类器常输出风险分数，不是天然标签。阈值降低通常提高 Recall、降低 Precision；阈值升高反之。

text

expectedCost(threshold)
  = FN(threshold) * costFN
  + FP(threshold) * costFP
  + reviewCount * reviewCost

安全泄露的 costFN 可能远大于多一次人工审核，阈值应偏向召回；营销推荐中误推和漏推代价可能接近。阈值必须按场景选择，并受每日人工容量、法规和硬门禁约束。

可运行Demo一：混淆矩阵和成本阈值

python

from dataclasses import dataclass


@dataclass(frozen=True)
class Sample:
    actual: int
    risk_score: float


samples = [
    Sample(1, 0.95), Sample(1, 0.82), Sample(1, 0.61),
    Sample(1, 0.38), Sample(0, 0.72), Sample(0, 0.49),
    Sample(0, 0.40), Sample(0, 0.31), Sample(0, 0.10),
]


def metrics(threshold: float) -> dict:
    tp = fp = tn = fn = 0
    for sample in samples:
        predicted = int(sample.risk_score >= threshold)
        if sample.actual == 1 and predicted == 1:
            tp += 1
        elif sample.actual == 0 and predicted == 1:
            fp += 1
        elif sample.actual == 0 and predicted == 0:
            tn += 1
        else:
            fn += 1
    precision = tp / (tp + fp) if tp + fp else 0.0
    recall = tp / (tp + fn) if tp + fn else 0.0
    f1 = 2 * precision * recall / (precision + recall) if precision + recall else 0.0
    # 漏掉风险代价50，误送人工代价3。
    cost = fn * 50 + fp * 3
    return {
        "threshold": threshold, "tp": tp, "fp": fp,
        "tn": tn, "fn": fn, "precision": round(precision, 3),
        "recall": round(recall, 3), "f1": round(f1, 3),
        "cost": cost,
    }


results = [metrics(t) for t in (0.3, 0.5, 0.7, 0.9)]
for result in results:
    print(result)
print("highest-F1 threshold:", max(results, key=lambda x: x["f1"])["threshold"])
print("lowest-cost threshold:", min(results, key=lambda x: x["cost"])["threshold"])

这个 Demo 中 F1 最高的阈值是 0.5，但由于漏掉一个风险的代价远高于多送几个正常样本去审核，最低业务成本阈值是 0.3。指标选择必须服务于真实风险，而不是为了报告好看。

七、概率校准为什么重要

区分排序能力和概率可信度：模型把风险样本排在前面，不代表 0.8 真意味着约 80% 会发生风险。概率用于人工容量、预算和自动化决策时必须校准。

Brier Score

二分类 Brier Score：

text

mean((predictedProbability - actualLabel)^2)

越低越好。它同时惩罚方向错误和过度自信。

可靠性分桶

把预测概率分成 0~0.1、0.1~0.2 等区间，比较每桶平均预测与真实发生率。若平均预测 0.8 的样本只有 40% 为正，模型严重过度自信。

校准方法可包括 Platt Scaling、Isotonic Regression 等，但必须在独立校准集上拟合，再在测试集验证。不能用测试集同时调阈值、做校准并报告最终成绩。

八、抽取任务怎样评估

只判断整份 JSON 完全一致会过严；只判断“能解析”又过松。应分层：

语法成功率：JSON 能否解析。
Schema 成功率：字段、类型、枚举是否正确。
字段级 Precision/Recall/F1：多值字段是否漏抽或多抽。
Exact Match：身份证号、错误码等必须精确。
规范化后匹配：日期、空格、大小写、单位换算。
数值误差：允许绝对/相对容差时明确公式。
证据定位：抽取值是否能指向原文页码和区域。
业务合法性：开始时间小于结束时间、金额非负、资源归属正确。

例如金额字符串 1,000.00 与 1000 可在货币和精度规则允许时规范化相等，但身份证号绝不能做模糊相似匹配。

九、RAG评估必须逐层拆开

mermaid

flowchart TD
    A["问题和身份"] --> B["文档是否存在且当前有效"]
    B --> C["ACL过滤后的候选召回"]
    C --> D["Rerank和去重"]
    D --> E["Prompt中的最终上下文"]
    E --> F["答案事实与引用"]
    F --> G["用户任务结果"]

9.1 检索指标

Recall@K：相关文档是否至少进入前 K。
Precision@K：前 K 中有多少相关，反映噪声。
MRR：第一个相关结果的倒数排名。
nDCG@K：多个相关等级下的排序质量。
ACL Precision：返回候选是否全部有权访问，通常是硬门禁。

一个 Query 可能有多个相关 Chunk，必须保存相关集合和等级；只标一个 Doc ID 会把其他正确证据误判为错。

9.2 上下文指标

正确 Chunk 召回后还可能被去重、Token 裁剪或冲突处理丢掉。要记录它是否真正进入最终 Prompt，以及上下文是否包含重复、旧版本、互相冲突和越权内容。

9.3 生成指标

Correctness：答案是否符合权威事实。
Faithfulness：每个事实是否被给定上下文支持。
Completeness：必要事实是否覆盖。
Citation validity：引用 ID 是否真实存在于本次候选。
Citation entailment：引用内容是否真的支持对应结论。
Correct refusal：无证据或无权限时是否正确拒答。

“带了引用”不等于引用正确；模型可能引用真实文档 ID，却让该文档为另一个结论背书。

9.4 失败归因顺序

text

权威资料是否存在
→ 当前版本是否有效
→ ACL后是否可见
→ 是否进入TopK
→ 是否通过Rerank
→ 是否进入最终Prompt
→ 模型是否基于证据回答
→ 引用解析和响应转换是否正确

每一步证据都要保存，否则只能把所有错误模糊归为“RAG不好”。

十、开放式生成怎样评估

开放答案通常组合：

确定性规则：格式、字段、引用、禁用内容。
参考事实：必须点、允许表达、证据。
人工 Rubric：正确、完整、清晰和业务适用性。
LLM-as-Judge：大规模语义初筛。

不要把 BLEU/ROUGE 等文字重叠指标直接当事实正确率。它们可用于某些固定参考的翻译、摘要比较，但同义正确答案可能重叠低，文字重叠高也可能事实错误。

Judge 有位置、冗长、风格、自偏好和版本漂移，必须校准、随机交换 Pairwise 顺序并对高风险分歧人工仲裁。完整方法见 Prompt评测。

十一、Tool Calling和Agent评估

11.1 Tool Calling

层级	检查
路由	应不应该调用工具
工具	工具名是否正确
参数	Schema、枚举、资源ID、单位
权限	身份是否来自后端，资源是否有权
风险	写操作是否确认、幂等和审计
执行	下游是否成功，超时是否UNKNOWN
总结	是否准确表达真实业务结果

权限拒绝阻止了事故，但模型反复产生越权意图仍应记为模型路由失败，而不是因为最终 HTTP 403 就算端到端成功。

11.2 Agent轨迹

Agent 评估不能只看最终答案。它可能“完成任务但走了危险路径”。至少评估：

最终状态是否正确。
每一步 Action 是否允许。
工具顺序和依赖是否正确。
是否重复调用或形成循环。
Observation 是否被正确使用。
步数、Token、工具费和总 Deadline。
Checkpoint 恢复后是否重复副作用。
无法安全完成时是否澄清、拒绝或转人工。

对于开放路径，不要求与参考轨迹逐步完全一致；应定义允许动作集合、状态不变量和禁止动作。

十二、自动规则、Judge和人工怎样组合

mermaid

flowchart TD
    A["模型输出和全链证据"] --> B["确定性规则"]
    B --> C{"硬错误"}
    C -- "有" --> D["失败并保存证据"]
    C -- "无" --> E["Judge语义初筛"]
    E --> F{"高风险、低置信或分歧"}
    F -- "是" --> G["双人或专家复核"]
    F -- "否" --> H["进入聚合报告"]
    G --> H

能精确计算的内容不要交给模型判断；Judge 的输入和输出也可能包含敏感数据，需要 Provider 审批和最小化。人工不是天然正确，仍需指南、一致性、仲裁和抽检。

十三、可运行Demo二：标注一致性Kappa

python

from collections import Counter


annotator_a = ["allow", "deny", "allow", "review", "deny", "allow", "review", "deny"]
annotator_b = ["allow", "deny", "review", "review", "allow", "allow", "review", "deny"]


def cohen_kappa(a: list[str], b: list[str]) -> dict:
    if len(a) != len(b) or not a:
        raise ValueError("两组标签必须等长且非空")
    n = len(a)
    labels = set(a) | set(b)
    observed = sum(x == y for x, y in zip(a, b)) / n
    count_a = Counter(a)
    count_b = Counter(b)
    expected = sum((count_a[label] / n) * (count_b[label] / n) for label in labels)
    kappa = (observed - expected) / (1 - expected) if expected < 1 else 1.0
    disagreements = [
        {"index": i, "a": x, "b": y}
        for i, (x, y) in enumerate(zip(a, b)) if x != y
    ]
    return {
        "observed_agreement": round(observed, 3),
        "expected_agreement": round(expected, 3),
        "kappa": round(kappa, 3),
        "disagreements": disagreements,
    }


print(cohen_kappa(annotator_a, annotator_b))

Kappa 低时不能只要求标注者“认真一点”。应查看分歧集中在哪些标签，补充边界和反例，必要时重新定义任务。

十四、离线对比和发布门禁

基线与候选必须在相同 Case、身份、Fixture、模型调用条件下配对运行，并保存不可变 Run Manifest。至少报告：

分场景、难度、风险、语言的样本数和结果。
候选减基线的逐 Case 差值。
随机输出的重复运行和最坏情况。
Bootstrap 等不确定性区间。
安全、权限、格式等独立硬门禁。
P95/P99、Token和每个成功任务成本。

平均分提升不能抵消一次跨租户泄露。详细的配对比较、Judge、Bootstrap 和门禁算法见 Prompt评测、门禁与灰度发布。

十五、线上A/B实验怎样设计

离线评测无法完整模拟真实输入、用户适应、Provider 抖动和产品反馈，因此候选通过后还要 Shadow/Canary/A/B。

15.1 随机化单位

单轮无状态推荐可按用户随机。
多轮对话应按会话或用户稳定分组。
团队协作会互相影响时可能按租户随机。

每次请求随机会导致同一用户来回切版本并产生污染。实验分组要在请求进入 AI 链路前确定并记录。

15.2 主指标和护栏

主指标可以是任务完成率或有效工单率；护栏包括跨租户零事件、错误率、P95、成本、人工转接和投诉。发布前确定分析窗口和停止条件，不能看到哪项显著就临时宣布成功。

15.3 Sample Ratio Mismatch

若计划 A/B 各 50%，实际却是 60/40，称为 SRM。可能来自路由错误、过滤条件、埋点丢失、缓存或版本崩溃。在解释效果前必须先排查分流是否可信；分组基础坏了，指标差异不能直接归因于候选。

15.4 常见实验陷阱

反复每天偷看显著性并在最好时停止，增加假阳性。
同一用户跨组，产生学习和会话污染。
新奇效应：用户短期因界面或回答风格变化而活跃。
网络效应：一个用户的AI结果影响另一用户。
只看点击，不看任务是否真正完成。
候选延迟更高导致部分请求丢失，幸存样本看起来质量更好。

高风险 AI 发布通常先从允许名单和低风险场景开始，不应为了实验统计随机放开退款、医疗处置或权限变更。

十六、线上监控和反馈回流

每条请求至少记录实际 Bundle、场景、身份范围Hash、检索和引用ID、模型Revision、Tool结果、Token、TTFT、总延迟、评分代理和用户反馈。正文按数据安全策略脱敏、抽样和短期保存。

反馈回流流程：

mermaid

flowchart TD
    A["点踩、转人工、返工和事故"] --> B["授权取证与脱敏"]
    B --> C["按原因分类"]
    C --> D["专家标注和仲裁"]
    D --> E["加入Regression候选"]
    E --> F["去重、防泄漏和版本发布"]
    F --> G["后续变更持续回归"]

用户反馈不是天然标签。没有点踩可能是用户离开；点踩也可能因为语气而非事实。要结合任务完成、人工修正和抽样复核。

十七、商业场景：医疗数据资产助手

场景	评估单位	核心指标	硬门禁
字段解释	问题/答案/引用	事实完整、引用支持	不泄露真实患者
资产检索	Query/相关资产集	Recall@K、nDCG	ACL Precision=100%
敏感分类	字段/标签	每类Recall、混淆矩阵	高敏漏判为0
工单草案	JSON字段	字段F1、Schema、业务规则	未确认不写入
故障Agent	完整轨迹	成功率、步数、成本	禁止跨租户Tool

发布报告不能只说“总体准确率93%”。必须说明每个风险层样本数、高敏漏判、跨租户事件、正确拒答、P95和每个成功任务成本。

十八、生产Runbook

18.1 总分不变但用户投诉增加

检查线上场景分布是否变化，按租户、语言、输入长度和风险重算；确认评测集是否过度包含简单题。比较任务完成、转人工和返工，不把离线代理指标当最终价值。

18.2 RAG答案下降

按“资料存在 → 版本 → ACL → Recall → Rerank → 最终Prompt → Faithfulness → 引用解析”逐层比较基线和候选，保存每层ID和分数。不要一上来只改Prompt。

18.3 分类Accuracy很高但事故增加

查看类别比例和混淆矩阵，重点检查高风险类 FN、Recall 和阈值。确认线上分布漂移、标签规则及校准；必要时降低阈值并增加人工容量。

18.4 人工标注分歧突然上升

按标签和标注者查看分歧，确认指南、业务口径或资料版本是否变化；对争议样本仲裁，更新指南后重标受影响数据。不能把多数投票自动视为事实。

18.5 离线改善但A/B没有收益

先检查 SRM、埋点和稳定分组，再判断离线样本代表性、代理指标与业务指标关系、用户学习效应和实验时长。不要因线上无收益就反向修改历史评测结果。

18.6 Judge分数突然整体上涨

固定生成输出，用旧/新 Judge 分别重评，隔离评分器变化；检查模型Revision、Rubric和位置顺序，并在人类校准集上验证。未校准前不能沿用旧阈值。

18.7 成本下降但质量事故增加

检查小模型路由、上下文裁剪、TopK、缓存和最大输出Token变更；按场景比较，不允许高风险请求自动降级到未验证模型。先切回已验证Bundle，再重新做质量成本联合评测。

十九、常见误区

误区	后果	正确做法
所有任务只看准确率	稀有风险全部漏掉仍高分	混淆矩阵和逐类Recall
默认阈值0.5	不符合错误代价和人工容量	成本曲线与约束选阈值
只评最终答案	无法定位RAG或Tool哪层失败	保存全链中间证据
全文Exact Match	同义正确答案被判错	任务化真值和Rubric
Judge代替所有人工	偏差和漂移无人发现	校准、分歧复核和高风险人工
随机按行拆数据	近重复泄漏到测试集	按文档、会话、时间分组
离线通过直接全量	长尾、性能和行为反馈未验证	Shadow、Canary、A/B
只看点赞率	选择偏差严重	任务结果、返工和抽样复核

二十、面试标准回答

AI评估完整流程是什么

先从业务任务定义样本单位、权威真值、错误代价和指标树，再按真实流量与稀有风险构建分层、去重、防泄漏的数据集，通过盲标、双标和仲裁保证标签。按任务选择分类、抽取、检索、生成、Tool或Agent指标，保存全链证据做失败归因。候选与基线同Case配对评估，安全权限设硬门禁；离线通过后再用Shadow、Canary或A/B验证真实任务、性能和成本，线上失败回流Regression。

Precision和Recall怎样选择

Precision回答“被判正的有多少真的正”，Recall回答“实际正类找回多少”。风险漏判代价高时优先Recall，人工审核容量有限时也要控制Precision。阈值应结合FN、FP和审核成本以及硬约束选择，不能因为0.5是默认值就固定使用。

RAG答错怎样定位

依次检查权威资料是否存在且版本有效、ACL后是否可见、是否进入TopK、Rerank后位置、是否进入最终Prompt、模型事实是否被上下文支持、引用ID和蕴含关系是否正确。每一层失败对应不同修复，不能都归为Prompt问题。

自动评估和人工评估怎样结合

JSON、Schema、引用集合、权限和Tool参数用确定性规则；开放语义可由校准过的Judge初筛；高风险、低置信和人机分歧进入双人或专家复核。人工也要有指南、一致性和仲裁，Judge版本变化后重新校准。

为什么离线分数提高线上不一定有收益

评测集可能不代表真实流量，代理指标可能不等于任务完成，线上还有延迟、Provider抖动、用户学习和交互效应。应先验证A/B分流和SRM，再同时看业务主指标与安全、性能、成本护栏。

二十一、关联知识点

知识点	作用
Prompt评测	Run Manifest、Judge、Bootstrap与发布门禁
LLMOps	资产Bundle、灰度、回滚和观测
RAG完整链路	检索、上下文、引用和索引发布
Embedding评估	Recall、MRR、nDCG和困难负样本
Tool Calling	权限、幂等、确认和UNKNOWN
AI数据安全	日志、数据集、标注和Judge副本治理
AI面试题	标准回答与原理跳转

二十二、学习验收清单

[ ] 能从业务目标写出评估单位、真值和错误代价。
[ ] 能手算混淆矩阵、Precision、Recall和F1。
[ ] 能解释类别不平衡时Accuracy为什么失真。
[ ] 能根据FN/FP成本和容量选择阈值。
[ ] 能解释概率校准和Brier Score。
[ ] 能为抽取、RAG、生成、Tool和Agent分别选指标。
[ ] 能设计分层、分组、时间外且防泄漏的数据集。
[ ] 能组织双人盲标、仲裁并解释Kappa限制。
[ ] 能逐层定位RAG失败。
[ ] 能设计离线门禁和线上A/B护栏。
[ ] 能识别SRM、代理指标和反馈选择偏差。
[ ] 能执行质量、标注、Judge和成本事故Runbook。

本章小结

AI评估的核心不是找到一个万能分数，而是让每个业务目标对应正确的样本、真值、错误代价和证据。分类看混淆与阈值，抽取看字段和业务规则，RAG拆检索、上下文、生成与引用，Agent还要检查轨迹。可靠标签来自可审计标注，可靠发布来自配对门禁，真实价值最终要由可信的线上实验和业务结果验证。

AI评估从任务指标到线上实验完整原理 ​

学习目标 ​

一、先定义评估对象和单位 ​

为什么样本单位很重要 ​

二、从业务目标建立指标树 ​

2.1 四类指标不能混为一个分数 ​

2.2 领先指标和滞后指标 ​

三、数据集怎样构建才有代表性 ​

3.1 数据来源 ​

3.2 分层而不是只随机抽样 ​

3.3 防止数据泄漏 ​

四、真值和标注怎样产生 ​

4.1 真值不总是一段标准答案 ​

4.2 标注流程 ​

4.3 为什么只看一致率不够 ​

五、分类指标从混淆矩阵推导 ​

为什么Accuracy会骗人 ​

Micro、Macro和Weighted F1 ​

六、阈值选择取决于错误代价 ​

可运行Demo一：混淆矩阵和成本阈值 ​

七、概率校准为什么重要 ​

Brier Score ​

可靠性分桶 ​

八、抽取任务怎样评估 ​

九、RAG评估必须逐层拆开 ​

9.1 检索指标 ​

9.2 上下文指标 ​

9.3 生成指标 ​

9.4 失败归因顺序 ​

十、开放式生成怎样评估 ​

十一、Tool Calling和Agent评估 ​

11.1 Tool Calling ​

11.2 Agent轨迹 ​

十二、自动规则、Judge和人工怎样组合 ​

十三、可运行Demo二：标注一致性Kappa ​

十四、离线对比和发布门禁 ​

十五、线上A/B实验怎样设计 ​

15.1 随机化单位 ​

15.2 主指标和护栏 ​

15.3 Sample Ratio Mismatch ​

15.4 常见实验陷阱 ​

十六、线上监控和反馈回流 ​

十七、商业场景：医疗数据资产助手 ​

十八、生产Runbook ​

18.1 总分不变但用户投诉增加 ​

18.2 RAG答案下降 ​

18.3 分类Accuracy很高但事故增加 ​

18.4 人工标注分歧突然上升 ​

18.5 离线改善但A/B没有收益 ​

18.6 Judge分数突然整体上涨 ​

18.7 成本下降但质量事故增加 ​

十九、常见误区 ​

二十、面试标准回答 ​

AI评估完整流程是什么 ​

Precision和Recall怎样选择 ​

RAG答错怎样定位 ​

自动评估和人工评估怎样结合 ​

为什么离线分数提高线上不一定有收益 ​

二十一、关联知识点 ​

二十二、学习验收清单 ​

本章小结 ​

AI评估从任务指标到线上实验完整原理

学习目标

一、先定义评估对象和单位

为什么样本单位很重要

二、从业务目标建立指标树

2.1 四类指标不能混为一个分数

2.2 领先指标和滞后指标

三、数据集怎样构建才有代表性

3.1 数据来源

3.2 分层而不是只随机抽样

3.3 防止数据泄漏

四、真值和标注怎样产生

4.1 真值不总是一段标准答案

4.2 标注流程

4.3 为什么只看一致率不够

五、分类指标从混淆矩阵推导

为什么Accuracy会骗人

Micro、Macro和Weighted F1

六、阈值选择取决于错误代价

可运行Demo一：混淆矩阵和成本阈值

七、概率校准为什么重要

Brier Score

可靠性分桶

八、抽取任务怎样评估

九、RAG评估必须逐层拆开

9.1 检索指标

9.2 上下文指标

9.3 生成指标

9.4 失败归因顺序

十、开放式生成怎样评估

十一、Tool Calling和Agent评估

11.1 Tool Calling

11.2 Agent轨迹

十二、自动规则、Judge和人工怎样组合

十三、可运行Demo二：标注一致性Kappa

十四、离线对比和发布门禁

十五、线上A/B实验怎样设计

15.1 随机化单位

15.2 主指标和护栏

15.3 Sample Ratio Mismatch

15.4 常见实验陷阱

十六、线上监控和反馈回流

十七、商业场景：医疗数据资产助手

十八、生产Runbook

18.1 总分不变但用户投诉增加

18.2 RAG答案下降

18.3 分类Accuracy很高但事故增加

18.4 人工标注分歧突然上升

18.5 离线改善但A/B没有收益

18.6 Judge分数突然整体上涨

18.7 成本下降但质量事故增加

十九、常见误区

二十、面试标准回答

AI评估完整流程是什么

Precision和Recall怎样选择

RAG答错怎样定位

自动评估和人工评估怎样结合

为什么离线分数提高线上不一定有收益

二十一、关联知识点

二十二、学习验收清单

本章小结