当前位置：首页 > news >正文

用基础模型构建应用（第四章）AI Engineering: Building Applications with Foundation Models学习笔记

news 2025/7/1 6:29:43

在 AI 技术落地过程中，不少团队会面临这样的困境：部署的模型表现时好时坏，却缺乏体系化的评估手段来定位问题；面对市场上繁多的基础模型，也难以判断哪款真正契合业务需求。本章（Evaluate AI Systems 评估 AI 系统）聚焦 “A model is only useful if it works for its intended purposes” 这一核心命题，揭示了一个关键认知：评估并非模型上线后的事后检验，而是贯穿开发全流程的工程化能力。

为确保模型满足预期目标，必须在具体应用场景中进行评估：第三章（Evaluation Methodology 评估方法论）侧重介绍不同的自动评估方法（如功能正确性、困惑度等），而本章则更关注 “如何将这些方法应用到实际业务场景中”—— 从评估标准的业务化定义，到公共基准的筛选策略，再到评估流程与业务指标的绑定，形成从方法论到落地实践的完整闭环。

本章系统拆解了 AI 应用评估的三大维度：如何定义领域特定能力、生成质量、指令遵循性等评估标准；如何在开源模型与 API 服务间做出决策；以及如何设计评估流程。通过建立科学的评估体系，实现模型能力与业务价值的精准对齐。

1 Evaluation Criteria（评估标准）

1.1 Domain-Specific Capability（领域特定能力）

1.2 Generation Capability（生成能力）

1.2.1 Factual Consistency（事实一致性）

1.2.2 Safety（安全性）

1.3 Instruction-Following Capability（指令遵循能力）

1.4 Cost and Latency（成本与延迟）

2 Model Selection（模型选择）

2.1 Model Selection Workflow（模型选择的工作流程）

2.2 Model Build Versus Buy（模型自建 vs 购买决策）

2.3 Navigate Public Benchmarks（公共基准导航）

3 Design Your Evaluation Pipeline（设计评估流程）

3.1 Evaluate All Components in a System（评估系统中所有组件）

3.2 Create an Evaluation Guideline（创建评估指南）

3.3 Define Evaluation Methods and Data（定义评估方法和数据）

1 Evaluation Criteria（评估标准）

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

1. 核心思想：强调在 AI 应用开发前定义评估标准的重要性，类比软件工程中的 “测试驱动开发”，即 “先定义评估指标，再构建模型”。

2. 企业AI应用的现实选择：

1）筛选标准：存在明确量化评估指标 → 确保ROI可验证
2）典型场景：

推荐系统：通过用户参与度/购买率评估
欺诈检测：通过 “防欺诈节省的资金” 衡量
代码生成：通过功能性测试验证正确性（天然可评估优势）
封闭任务：意图分类、情感分析等（评估难度＜开放式任务）

3. 评估标准分类：领域特定能力、生成能力、指令遵循能力、成本与延迟。

1.1 Domain-Specific Capability（领域特定能力）

1. 定义与约束

模型在特定领域（如编码、法律、数学）的专业能力，能力边界由模型架构、参数规模及训练数据决定。例如，未接触拉丁语训练数据的模型无法理解拉丁语；编码能力依赖模型是否接受过代码相关训练数据。

2. 评估方法与基准测试

1）基准测试

公共基准：覆盖代码生成、数学、科学、法律等领域，如代码生成与调试基准；小学算术基准；法律知识基准。
私有基准：企业根据自身业务定制的领域测试集（如汽车估值模型的专用评估数据）。

2）评估维度与技术

精确评估：
- 功能正确性：编码任务中通过测试用例验证代码是否运行正确；
- 效率指标：如 SQL 查询生成的执行时间、内存占用，如 BIRDSQL 基准同时衡量查询准确性与运行效率。
主观评估：
- 针对难以量化的指标（如代码可读性），依赖 AI 评委或人工判断。

3）封闭式任务（Close-Ended Tasks）的应用

多选题（MCQ）为主：
- 优势：易验证、可复现，如评估数学能力时给出选项让模型选择正确答案；
- 案例：MMLU 基准包含 57 个学科的多选题，如经济学问题 “政府监管垄断的原因”；
- 指标：常用准确率（正确题数占比）、加权评分（难题分值更高）。
分类任务：如情感分析（NEGATIVE/POSITIVE/NEUTRAL），使用 F1 分数、精确率、召回率评估。

结论：领域特定能力评估需结合专业基准与业务场景，通过精确指标（如功能正确性、效率）和主观判断（如可读性）综合衡量。封闭式任务（如多选题）适用于知识与推理评估，但无法覆盖生成类需求，需与其他评估方法互补。

1.2 Generation Capability（生成能力）

生成能力的评估指标演进

早期 NLG 模型因生成不自然，流畅性与连贯性是核心指标；现代大模型生成接近人类水平，事实一致性与安全性成为新焦点。

1. 传统 NLG 指标（自然语言生成）

流畅性Fluency（语法正确性与自然度）、连贯性Coherence（逻辑结构）；
忠实性Faithfulness（翻译与原文一致性）、相关性Relevance（摘要与原文重点匹配）。

2. 新兴生成模型指标

事实一致性（Factual Consistency）：检测输出是否与上下文或公开知识冲突（本地/全局）；
安全性（Safety）：识别毒性、偏见、仇恨言论等有害内容；

1.2.1 Factual Consistency（事实一致性）

1. 本地一致性（Local Consistency）：模型输出内容必须匹配给定上下文（如文档、政策、数据集）。

1）检测逻辑：输出与上下文矛盾 → 不一致；输出被上下文支持 → 一致

示例：输入上下文："天空是紫色的"
输出"天空是蓝色的" → 不一致；输出"天空是紫色的" → 一致

2）应用场景：

摘要任务：摘要需与原文事实一致；
客服聊天机器人：回复需符合企业政策。

3）评估方法：

AI 评委：如 GPT-3.5 通过提示 “摘要是否包含未被原文支持的事实” 进行判断；
文本蕴含（Textual Entailment）：判断输出与上下文的关系（蕴含、矛盾、中立）。

2. 全局一致性（Global Consistency）：模型输出内容需符合开放世界的普遍认知（常识、科学事实等）。

1）检测逻辑：输出与公认知识矛盾 → 错误；符合共识 → 正确

输出"天空是蓝色的"（符合常识） → 一致；输出"地球是平的"（违背科学） → 不一致

2）应用场景：通用聊天机器人、事实核查、市场研究；

3）评估挑战：

需先检索可靠知识源（如通过搜索引擎验证）；
易受 “证据缺失谬误” 影响（如误将 “无证据支持” 视为 “事实正确”）。

3. 事实一致性技术方案

1）AI 评委：如 GPT-3.5/4 可评估摘要与原文的事实一致性。

2）自我验证（Self-Verification）：

原理：生成 N 个响应，通过内部一致性判断是否存在幻觉（如 SelfCheckGPT）；若模型对同一问题生成多个相互矛盾的输出，则原始输出很可能存在幻觉。
工作流程：

局限：需多次调用模型，成本较高。

3）知识增强验证（Knowledge-Augmented Verification）：

原理：通过搜索引擎实时验证开放域事实。
案例：Google 的 SAFE 工具通过搜索引擎分解并验证输出事实，分四步验证
- 分解输出为独立陈述→修正表述→搜索验证→AI 判断一致性

4）文本蕴含（Textual Entailment）

原理：判断输出与上下文的 “蕴含、矛盾、中立” 关系。
三类关系定义与事实一致性映射

关系类型	定义	事实一致性判定	经典案例（前提："Mary喜欢所有水果"）
蕴含 (Entailment)	假设可从前提逻辑推导	✅ 一致	假设："Mary喜欢苹果" → 🟢 苹果属于水果
矛盾 (Contradiction)	假设与前提存在直接冲突	❌ 不一致	假设："Mary讨厌橙子" → 🔴 与"喜欢所有"矛盾
中性 (Neutral)	前提既不能支持也不能否定假设	⚠️ 无法判定	假设："Mary喜欢鸡" → 🟡 鸡不属于水果范畴

4. 基准测试：TruthfulQA 包含 817 个易引发错误回答的问题，评估模型抗幻觉能力。

1.2.2 Safety（安全性）

1. 有害内容：不当言语、有害指南（如 “抢劫步骤”）、仇恨言论、暴力威胁、刻板印象等。

2. 评估工具与方法

专用模型：如 Facebook 仇恨言论检测模型、Perspective API 毒性分类器；
基准测试：
- RealToxicityPrompts：10 万条易引发毒性输出的自然提示；
- BOLD：检测开放式生成中的偏见；
内容 moderation 工具：OpenAI 内容审核端点、Meta 的 Llama Guard。

1.3 Instruction-Following Capability（指令遵循能力）

1. 定义：模型按要求生成结构化输出（如 JSON 格式）或遵循风格约束（如 “使用四字符以内单词”）的能力。

业务影响：若模型无法遵循指令，即使具备领域能力也会导致应用失败。如情感分析任务中，要求模型检测推文中的情绪并输出 NEGATIVE、POSITIVE 或 NEUTRAL，模型输出 “HAPPY” 而非要求的 “POSITIVE”，会破坏下游流程。
易与 “领域特定能力” 混淆：例如模型无法生成越南 “六八诗”（lục bát），可能是因不了解诗歌形式（领域能力缺失），也可能是未理解指令要求（指令遵循问题）。

2. 评估基准与方法

1）IFEval：结构化指令评估

核心目标：关注格式验证（如关键词包含、段落数、JSON 格式）；
指令类型：关键词控制（包含 / 禁止特定词汇等）；格式约束（段落数、JSON 格式等）；语言要求（指定响应语言，如 “全文用西班牙语”）。
评估逻辑：通过程序检测输出是否符合预设规则，分数为正确指令占比。

2）INFOBench：复杂指令评估

扩展维度：评估内容约束（如 “仅讨论气候变化”）、语言风格（如 “维多利亚英语”）等更广泛指令，需人工或 AI 评委验证。
验证方式：
- 将指令拆解为若干是 / 否问题，由人工或 AI 评委判断。例如：评估 “为酒店客人生成评论问卷” 时，验证 “是否为问卷”“是否针对客人”“是否有帮助”；
- 分数为符合标准的问题占比，GPT-4 可作为性价比高的自动化评委。

3. 角色扮演（Roleplaying）评估

1）应用场景

娱乐场景：游戏 NPC、互动故事中的角色模拟；
提示工程：通过角色设定提升输出质量（如 “扮演资深工程师解答技术问题”）。

2）评估要点

风格一致性：输出需符合角色语言特点（如 Jackie Chan 的口语化表达）；
知识准确性：角色相关知识正确（如不虚构角色未知信息，避免剧透）。
评估方法：
- AI 评委：使用定制提示对比输出与角色描述的匹配度（如 RoleLLM 基准的评分流程）；
- 相似度指标：计算生成内容与预期角色输出的文本相似度。

1.4 Cost and Latency（成本与延迟）

1. 成本与延迟的评估维度与重要性

核心定位：模型性能的关键工程化指标，直接影响应用落地可行性。即便模型质量高，若延迟过长或成本过高，也无法投入生产。
业务决策影响：企业常因成本或延迟妥协模型质量，选择性价比更优的方案（如用中小模型替代大模型）。

2. 延迟（Latency）评估

1）关键指标

首 token 时间（Time to First Token）：模型开始生成首个 token 的耗时；
每 token 时间（Time per Token）：生成单个 token 的平均耗时；
总查询时间（Total Query Time）：从接收请求至返回完整响应的总耗时。

2）影响因素

模型架构：大模型（如 70B 参数）通常比小模型延迟更高；
提示与输出长度：token 数越多，总延迟越高；
采样参数：如温度（Temperature）越高，生成随机性强，可能增加耗时。

3）优化策略

提示工程：通过指令简化输出（如 “请简洁回答”）减少 token 生成量；
生成控制：设置停止条件（如最大 token 数）避免无意义延长；
工程优化：模型量化、部署优化（如 GPU 并行计算），详见第 9 章。

3. 成本（Cost）评估

1）成本构成

模型 API 费用：按输入 / 输出 token 数计费。
自建模型成本：
- 硬件成本：GPU 内存（如 48GB GPU 适配 65B 参数模型）、服务器集群；
- 运维成本：模型优化、推理服务维护。

2）规模效应与成本策略

API 成本特性：单价随用量增长相对稳定，适合中小规模应用；
自建模型优势：大规模使用时（如日处理 10 亿 token），自建集群的单 token 成本可显著降低；
- 单Token成本 = (硬件折旧 + 能耗 + 运维) / 总处理Token量
- 当分母（Token量）指数级增长，分子（固定成本）不变 → 单Token成本非线性下降

决策案例：企业若预估 token 用量将持续增长，可能从 API 转向自建以控制长期成本。

3）成本优化实践

token 消耗控制：减少冗余输入（如压缩文档）、优化输出格式（如用 JSON 替代自然语言）；
模型选择：根据业务需求匹配模型规模（如非复杂任务用 7B 模型替代更大模型）。

4. 帕累托优化（Pareto Optimization）与权衡策略

多目标平衡框架：同时优化模型质量、延迟、成本，需明确 “不可妥协指标”。强调多目标权衡，而非单一指标最大化，避免因性能短板导致应用落地失败。例如：

实时客服场景：延迟为首要指标，优先筛选低延迟模型；
企业内部分析工具：可接受较高延迟，重点优化成本。

2 Model Selection（模型选择）

我们关心的并非是哪个模型性能最优，而是哪个模型最契合实际应用场景。明确应用需求的核心标准后，即可针对这些标准评估模型表现。模型选择应摒弃‘绝对最优’的幻想，转而评估场景契合度——实践中的最佳模型，永远是对当前需求最适配的解决方案。

工程决策流程
- 第一步：按延迟要求过滤不合格模型；
- 第二步：在剩余模型中选择成本与质量平衡最优的方案。

2.1 Model Selection Workflow（模型选择的工作流程）

四步筛选框架：模型选择并非单纯依赖性能指标，而是需结合业务场景与工程约束，通过系统化流程缩小候选范围。工作流程分为以下关键步骤：

第一步：过滤硬属性不匹配的模型

1）硬属性的定义与范围：指模型或部署方案中无法妥协的固有特性，由企业政策、技术约束或合规要求决定，包括许可证类型、数据隐私要求、模型规模与硬件适配、训练数据透明度等。

企业内部政策（如数据隐私、合规要求）
模型固有特性（许可证、训练数据、模型规模）

2）筛选案例

若企业要求数据不出域，则直接排除所有外部 API 模型，仅考虑自建开源模型；
若应用涉及实时交互，需过滤掉延迟无法满足要求的大模型。

第二步：借助公共基准与排行榜缩小范围

1）基准数据的应用策略

公共基准的价值：利用 MMLU（多学科知识测试）、HELM（综合评估）等基准快速定位模型能力短板，例如：
- 代码生成场景：参考 HumanEval 基准的 pass@1 指标；
- 事实一致性：用 TruthfulQA 评估模型抗幻觉能力。
排行榜的局限性
- 覆盖不全：如 Hugging Face 排行榜仅包含 6 个基准，无法覆盖所有业务场景；
- 数据污染：部分模型可能在基准训练数据中见过测试题，导致分数虚高。

2）多目标平衡思维：结合帕累托优化思想，在模型质量、成本、延迟间寻找平衡点。例如优先满足延迟要求，再从低延迟模型中选择成本最低的方案。

第三步：运行自定义评估流程

1）业务专属评估的必要性：公共基准无法完全模拟真实场景，需基于企业数据构建评估体系，使用业务专属数据与指标（如代码生成准确率、客服响应相关性）测试候选模型，确保与实际需求对齐。包括：

评估数据：使用真实用户查询、历史业务数据（如客服对话日志）；
指标定制：如电商推荐模型需评估 “点击率提升”，而非仅看准确率。

2）评估维度示例

功能正确性：金融模型的风险评估公式是否符合行业标准；
用户体验：客服机器人响应的自然度与解决率；
成本效率：生成相同质量输出的 token 消耗对比。

第四步：生产环境持续监控

1）监控的核心目标：跟踪模型性能衰减、用户反馈，动态调整模型选择策略，避免 “部署即失效”。例如：

用户投诉量突然增加，可能提示模型输出出现偏差。
模型在上线 3 个月后，因训练数据与实时数据分布差异，准确率下降 15%；

2）监控指标设计

定量指标：实时准确率、延迟 P90、成本消耗趋势；
定性指标：用户满意度调查、人工抽检的输出质量评分。

硬属性与软属性的区分原则

硬属性：不可改变的特性（如模型许可证类型、训练数据来源）；
软属性：可优化的指标（如准确率、毒性率），需通过提示工程或微调改善。

2.2 Model Build Versus Buy（模型自建 vs 购买决策）

1. 开源模型与模型API的定义与现状

1）开源模型（Open Source Models）：指权重公开可下载的模型，如Llama 2、Mistral-7B，但多数仅开放权重（Open Weight），训练数据未公开。

为了表明数据是否也是开放的，“open weight开放权重”用于不附带开放数据的模型，而“open model开放模型”用于带有开放数据的模型。
许可证复杂：不同模型有专属许可（如Meta的Llama 3 Community License），需关注商业使用限制、数据衍生权等。

2）模型API（Model APIs）：由模型提供商（如OpenAI）或第三方（如Azure）提供的推理服务接口，按token收费，无需自行部署。

优势：集成便捷，支持功能调用、安全护栏等现成能力；劣势：数据隐私风险较高。

2. 决策影响因素

维度

自建开源模型

使用模型API

数据隐私

数据完全本地处理，无需外传，适合医疗、金融等敏感领域；

避免第三方服务商利用数据训练模型，消除隐私泄露风险。

数据需上传至第三方服务器，存在机密泄露风险；

服务商可能更新条款允许使用用户数据训练模型（如Zoom修改服务条款引发争议）。

数据谱系

需自行确认训练数据来源，若使用未公开数据的开源模型，可能面临版权风险；

优势：若训练数据公开，可审计数据合法性。

训练数据透明度低（如GPT-4未披露详细训练数据），使用其API生成内容可能因数据谱系不明面临IP纠纷；

商业模型若训练数据含版权内容，用户可能间接侵权。

性能

顶尖开源模型（如Llama 3、Mistral）性能接近商业模型，但仍有差距（如MMLU基准上闭源模型领先）；

需自行优化推理效率（如量化、部署），延迟控制依赖工程能力。

可直接使用最新商业模型（如GPT-4、Claude），性能持续由服务商优化，适合低延迟需求场景（如实时客服）；

劣势：模型更新可能导致不可预测的性能波动（如OpenAI模型悄无声息更新）。

功能

可自定义模型架构、添加专属功能（如游戏NPC角色逻辑、工具调用适配、深度集成工具（如RAG））；

可访问logprobs、中间输出等底层信息，适合研究与深度定制。

功能受限于API接口（如多数API不暴露logprobs，禁止模型蒸馏）；

服务商预设安全护栏（如禁止生成真实人脸），可能限制特定场景需求（如创意内容生成）。

成本

初期投入高：需采购GPU集群、维护推理服务；

规模效应显著：大规模使用时（如日处理10亿token），单token成本可低于API 10倍以上。

按用量付费：中小规模成本可控（如日处理100万token），但大规模使用费用可能激增；

无前期硬件投入，适合预算有限或短期项目。

控制

完全自主控制模型版本、更新节奏，可冻结模型避免意外变化（如应对严格监管场景）；

可自定义安全策略（如放宽内容限制，适配业务需求）。

依赖服务商控制模型更新，版本变化不透明（如GPT-4更新未提前通知，可能导致提示失效）；

受限于服务商的安全策略（如过度审查影响内容生成自由度）。

设备部署

可部署在本地设备或私有网络，支持离线运行（如无网络环境、边缘计算场景）；

适合对网络依赖低、隐私要求高的终端设备（如医疗检测仪、工业机器人）。

必须联网调用API，无法离线使用，不适合网络不稳定或无网络场景；

依赖服务商服务器可用性，存在服务中断风险。

技术门槛

需解决模型量化、集群部署等问题，适合有算法工程团队的企业。

零运维，适合技术资源有限的团队。

开源模型：优势在控制、定制化和大规模成本，劣势在性能可能滞后，需处理许可证和数据溯源。
模型 API：优势在易用性、功能完善，劣势在数据隐私风险、成本随用量增长。
决策因素：数据隐私、性能、功能需求、成本、控制需求、边缘部署等。
不存在绝对最优解，需结合业务规模（如初创公司优先 API，大型企业考虑自建）、场景特性（如实时交互选 API，定制化需求选自建）动态权衡。

3. license 与数据 lineage 风险

1）开源模型 license 陷阱

部分模型禁止商业使用（如早期 Llama 1），或限制输出用于训练新模型（如 Mistral 原许可证）。
案例：企业若用某开源模型生成内容训练新模型，可能违反其许可条款。

2）数据 lineage 合规

商业模型（如 GPT-4）的训练数据透明度低，可能包含受版权保护内容，使用其 API 生成的内容可能面临 IP 风险。
开源模型若训练数据未公开，企业使用时可能因数据来源不明面临审计问题。

2.3 Navigate Public Benchmarks（公共基准导航）

公共基准是模型筛选的有效起点，但需警惕三大陷阱：覆盖不全、数据污染、基准偏差。企业应构建 “公共基准 + 自定义评估” 的复合体系：先用公共基准快速过滤明显不适用的模型，再用业务专属数据与指标进行深度验证。动态监控基准时效性（如定期更新基准以应对模型能力迭代），避免因基准滞后导致评估失效。

1. 公共基准的现状与挑战

1）基准数量与覆盖范围

现有基准超数千个，覆盖代码生成、数学推理、法律知识等领域（如 Google 的 BIG-bench 含 214 个基准）。
评估工具（如 EleutherAI 的 lm-evaluation-harness）支持超 400 个基准，但仍无法覆盖所有业务场景（如企业专属的工业质检任务）。

2）公共排行榜的局限性

覆盖不全：Hugging Face Open LLM Leaderboard 仅用 6 个基准（如 MMLU、TruthfulQA），Stanford HELM 用 10 个基准，均未包含代码生成、工具使用等场景。
基准相关性：部分基准存在强相关性（如 MMLU 与 ARC-C 的推理能力测试），导致评估结果偏差（如模型在相关基准上得分虚高）。
不同基准间存在强相关性（如 MMLU 与 ARC-C 的推理能力测试），导致评估偏差。
- 相当于用两套相似题库测试学生：题库A（MMLU）与题库B（ARC-C）均侧重数学逻辑题。
- 学生反复练习同类题后，两套题得分均提高。但该生语言能力实际未提升 → 分数虚高掩盖真实短板

2. 基准选择与聚合的核心问题

1）如何选择基准？

业务匹配度优先：
- 代码生成场景：选 HumanEval、MBPP 等编程基准；
- 医疗领域：选 MedQA 等专业基准。
避免 “唯排行榜论”：榜单排名仅反映泛化能力，而业务落地依赖场景适配度。
- 如某模型在 MMLU 排名靠前，但在企业专属的客服对话基准中表现不佳。MMLU的85% ≠ 客服场景的85%。
- 企业需通过领域基准建设 → 定向微调 → 动态监控闭环，实现模型价值的真实释放。

2）如何聚合基准结果？

常见方法：
- 简单平均：Hugging Face 将模型在 6 个基准的得分取平均。
- mean win rate：HELM 计算模型在各基准中优于其他模型的概率。
局限性：平均法忽视基准重要性差异（如对电商推荐系统，毒性基准权重应低于推荐准确率）。

3. 数据污染（Data Contamination）的风险与应对

1）污染的成因

有意 / 无意训练数据重叠：模型训练数据包含基准测试题，导致分数虚高（如 GPT-3 在 13 个基准中因训练数据重叠，准确率提升 20%）。
间接污染：训练数据与基准数据来源相同（如数学教材同时用于训练和基准构建）。

2）检测与处理技术

n-gram 重叠检测：对比评估样本与训练数据的 token 序列，若 13 个连续 token 重复，则判定为污染（如 OpenAI 检测 GPT-3 在 Quac 基准的污染率）。n-gram 重叠检测更准确，但受限于数据可访问性和计算成本。
困惑度（Perplexity）分析：模型对评估数据的预测困惑度异常低，可能已见过该数据（如模型在污染样本上的困惑度比干净样本低 40%）。是更灵活的替代方案，适合资源受限或闭源模型场景。
去污染实践：
- 私有测试集：部分基准保留未公开数据供模型开发者自测；
- 动态生成基准：如设计 “永无止境” 基准，随模型能力提升自动生成更难问题。

4. 自定义基准构建策略

1）为何需要自定义基准？

公共基准无法模拟真实业务场景（如外卖平台的配送时间预测模型，需专属路况数据基准）。
避免数据污染：自建基准可确保训练数据与测试数据无重叠。

2）构建步骤

数据切片：按用户群体（付费 / 免费）、输入长度（短文本 / 长文档）等维度拆分业务数据。
指标定制：结合业务目标定义评估标准（如客服机器人的 “问题解决率” 而非仅准确率）。
样本量估算：根据 OpenAI 建议，若需检测 1% 的性能差异，需约 10,000 个评估样本。

3 Design Your Evaluation Pipeline（设计评估流程）

AI应用的成功高度依赖结果优劣的精准区分，这要求构建可信赖的评估流程。面对爆炸式增长的评估方法和技术，如何选择适配的评估组合成为关键挑战。开放式任务评估是当前难点，封闭式任务评估则相对简单，其流程可据此推导建立。

3.1 Evaluate All Components in a System（评估系统中所有组件）

组件级评估是构建可靠 AI 系统的基础，通过分解复杂流程为可独立验证的单元，实现故障的精准定位。对AI应用需建立 “端到端 + 组件级” 的复合评估体系，尤其在多步骤任务（如文档处理、多轮对话）中，可避免因局部缺陷导致整体失效。

1. 组件级评估的必要性

1）复杂系统的分解逻辑
真实 AI 应用常由多个串联组件构成，端到端评估（End-to-End Evaluation）无法定位具体故障环节。例如，从简历 PDF 中提取当前雇主的系统包含两个组件：

组件 1：PDF 文本提取；
组件 2：从文本中提取雇主信息。
若最终输出错误，需通过组件级评估确定是文本提取失败还是信息提取有误。

2）评估维度的分层价值

独立评估组件：每个组件可使用专属指标验证，如文本提取组件用 “与原文的相似度” 评估，信息提取组件用 “准确率” 评估。
避免误差累积掩盖问题：若仅评估端到端结果，可能因多个组件的误差叠加，无法定位根源（如 PDF 提取遗漏关键段落，导致后续信息提取错误）。

2. 组件评估的具体方法

1）按组件功能定制指标

示例 1：多步骤 NLP 系统
- 组件 1：文档分段 → 评估指标：分段准确性（与人工标注的段落边界匹配度）；
- 组件 2：实体识别 → 评估指标：F1 分数（实体识别准确率）。
示例 2：代码生成工具
- 组件 1：问题解析 → 评估指标：解析结果与需求的语义相似度；
- 组件 2：代码生成 → 评估指标：代码运行通过率（如 HumanEval 的 pass@1）。

2）中间输出验证机制

可视化中间结果：如 OCR 组件的文本提取结果，可通过人工比对或 OCR 准确率指标（如字符错误率 CER）验证。
模拟输入测试：针对某一组件，输入模拟数据以隔离其性能（如给信息提取组件直接输入正确文本，排除前序 PDF 提取的影响）。

3. 端到端评估与组件评估的结合

1）双层评估体系

端到端评估：验证整个系统是否达成最终目标（如简历处理系统是否正确输出雇主信息）；
组件评估：定位具体环节问题（如文本提取不完整或信息提取算法错误）。

2）多轮对话的分层评估

按回合（Turn-based）评估：每轮输出的质量（如客服机器人单轮响应的相关性）；
按任务（Task-based）评估：整个任务的完成度（如用户问题是否在 3 轮内解决）。
组件级是优化基础，任务级是最终目标。用户真正关心的是任务完成度（非过程细节）。
- 案例：调试 Python 代码的对话系统，需评估每轮提问的有效性（turn-based）和最终是否解决 bug（task-based）。

3.2 Create an Evaluation Guideline（创建评估指南）

评估指南是连接技术指标与业务目标的桥梁，其设计需遵循 “明确 - 可测 - 可验证” 原则。指南需随业务需求迭代，但应保持核心评估逻辑的稳定性，以支持长期效果追踪。

1. 评估指南的核心作用与设计原则

1）避免评估模糊性：指南需明确 “好的响应” 的定义，如客服聊天机器人需规定 “不回答与产品无关的问题” 的处理逻辑。

2）双向定义原则：不仅定义 “应做什么”，更需明确 “不应做什么”。例如：

应做：简历评估模型需准确提取工作经验；
不应做：禁止生成带有偏见的候选人评价（如性别歧视表述）。

2. 定义评估标准的三大步骤

1）明确 “好响应” 的业务特征：通过真实用户的使用情况迭代标准。

例如 LinkedIn 的 AI 求职评估工具发现：正确但伤人的响应（如 “你完全不适合此岗位”）并非优质输出；优质响应需包含 “差距分析” 与 “改进建议”。

2）量化评估维度

常见多维度组合（以客服系统为例）：相关性（响应与用户问题的语义匹配）、事实一致性（回答与企业知识库的一致性）、安全性（无毒性或偏见表述）。

3）验证标准的可操作性：用人工标注或 AI 生成多版本响应，测试标准的区分能力。

例如：给定用户查询 “如何重置密码”，评估不同响应的 “步骤完整性” 与 “表述清晰度”。

3. 制定评分规则与示例

1）评分体系设计

二进制评分：如事实一致性（0 = 矛盾，1 = 一致）；
多级评分：1-5 分制（如响应友好度：1 分 “生硬”，5 分 “自然亲切”）；
加权评分：根据业务优先级分配权重（如电商推荐中 “点击率影响” 权重高于 “文本流畅性”）。

2）带示例的 rubric（评分规则）

示例：评估代码生成质量
- 5 分：代码功能正确、注释清晰、符合算法效率要求；
- 3 分：代码运行正确但结构混乱；
- 1 分：代码无法编译或逻辑错误。

3）人类验证环节

邀请团队成员或用户按规则评分，若出现分歧则修订指南。例如：若多人对同一响应的评分差异超过 1 分，需细化规则描述。

4. 绑定评估指标与业务成果

1）建立指标映射关系：将技术指标转化为商业价值。

事实一致性 80% → 客服自动化处理 30% 的咨询。
事实一致性 90% → 自动化比例提升至 50%。

2）定义 “有用性阈值”：设定最低可接受标准。

医疗 AI 的诊断准确率必须≥95% 方可部署。
低于阈值时，即使其他指标优秀也需重新优化。

3）平衡商业与伦理指标：避免过度追求黏性指标（如用户停留时间）而引入成瘾性设计，需同时考量社会责任感指标（如内容多样性、无极端观点引导）。

3.3 Define Evaluation Methods and Data（定义评估方法和数据）

评估方法与数据遵循 “业务对齐、成本可控、结果可靠” 原则，确保评估既反映模型真实能力，又贴近业务场景。评估流程通过信号正确性、可靠性验证及指标相关性分析，避免陷入 “指标优化但业务无收益” 的陷阱。

1. 评估方法的多元化选择

1）自动指标与人工评估的结合

自动指标：利用模型输出的 logprobs、困惑度等底层数据评估，如通过计算生成文本的困惑度衡量流畅性。
- 案例：代码生成任务中用 “单元测试通过率” 自动验证功能正确性。
人工评估：邀请领域专家或用户对输出质量打分，如客服响应的 “问题解决率” 需人工判断；
- 注意事项：人工评估需控制标注者偏差（如通过 Kappa 系数验证标注一致性）。

2）AI 评委的应用与局限

优势：
- 成本低于人工评估，如用 GPT-4 评估摘要的事实一致性，成本仅为人工的 1/10。
- 一致性高，避免人工标注的主观波动。
局限：
- 可能复制大模型的偏见（如 GPT-4 对某些领域术语的理解偏差）。
- 需定制提示以确保评估准确性（如明确 “评估摘要时优先检查时间线一致性”）。

2. 评估数据的标注与验证

1）数据采样策略

基于生产数据切片：按用户群体（新老用户）、输入长度（短文本 / 长文档）等维度拆分真实业务数据。
- 案例：电商推荐系统需包含 “高消费用户” 与 “低频用户” 的查询样本。
样本量估算：若需检测 1% 的性能差异，根据 OpenAI 建议需约 10,000 个评估样本。
- 小规模场景可采用 Bootstrap 重采样法减少样本量需求。

2）标注质量控制