夜雨聆风核心观点：模块测试定位问题，端到端测试判断整体是否可用。AI 应用评测不能只做端到端测试，也不能只测单模块。模块测试回答"哪里错了"，端到端测试回答"整体有没有用"。一个完整的评测体系需要两者配合，并覆盖高频、高风险、边界、多用户类型、多输入形式和多业务路径六类关键场景。
评测集不仅要区分来源，还要区分测试范围。
从大的角度看，AI 应用评测可以分为两类：模块测试和端到端应用测试。两者的目标不同。模块测试关注的是某一个能力节点是否稳定，端到端测试关注的是整个应用是否完成了业务任务。
如果只有端到端测试，团队可能知道结果错了，但不知道错在哪里。如果只有模块测试，团队可能知道每个节点看起来都不错，但无法判断整体用户体验和业务结果是否成立。
因此，一个完整的 AI 应用评测体系，应该同时包含模块测试和端到端测试。
一、模块测试：定位单点能力问题
模块测试的目标，是评估 AI 应用中某个独立能力是否稳定。它更适合用于问题定位、能力优化和局部回归。常见模块包括意图识别、信息抽取、规则判断、工具调用、上下文组装和输出生成。
1. 意图识别
意图识别测试用于判断 AI 是否能正确理解用户想要完成的任务。在保险业务场景中，用户输入可能对应核保咨询、产品推荐、理赔咨询、保单查询、客服问题，或是超出能力范围的问题。
意图识别错误会导致后续流程全部偏离。因此，这一模块的评测重点包括：是否识别正确意图，是否能识别多意图，是否能识别模糊意图，是否能识别不应处理的请求，是否能在不确定时进入澄清或兜底流程。
2. 信息抽取
信息抽取测试用于判断 AI 是否能从用户输入中提取关键字段，例如疾病名称、检查结果、治疗情况、年龄、性别、职业名称、产品意向等。
对于很多 AI 应用来说，后续判断高度依赖前置信息抽取。如果抽取错误，即使后续规则和模型能力再强，也可能得到错误结果。因此，信息抽取评测不只要看字段是否提取出来，还要看字段是否完整、准确、结构化，并能否识别缺失信息。
3. 规则判断
规则判断测试用于评估 AI 是否能根据业务规则做出正确判断，例如是否命中某条业务规则，是否需要追问，是否需要转人工，是否符合推荐条件，是否存在高风险因素。
这一模块的重点，是判断 AI 是否遵守业务规则，而不是只看回答是否流畅。对于金融、保险、医疗、法务等高风险场景，规则判断错误往往比表达不佳更严重。
4. 工具调用
很多 AI 应用不是单纯问答，而是需要调用知识库、产品库、规则库、用户系统、订单系统、CRM 或其他业务工具。工具调用测试需要评估：是否在正确时机调用工具，是否选择了正确工具，是否传入了正确参数，是否正确理解工具返回结果，工具失败时是否有合理兜底，是否避免不必要的工具调用。
工具调用能力决定了 AI 应用能否从"回答问题"走向"完成任务"。如果工具调用不稳定，AI 应用很难真正进入业务流程。
5. 输出生成
AI 的最终输出不仅要正确，还要可读、可用、可执行。常见评测点包括：结论是否清晰，依据是否充分，信息是否完整，风险提示是否到位，是否给出下一步动作，是否符合业务话术，是否避免过度承诺，格式是否符合系统或人工复核要求。
在业务应用中，一个回答即使结论正确，如果缺少依据、缺少下一步建议，或者表达不符合业务规范，也可能无法被采纳。
二、端到端测试：判断整体任务是否完成
端到端测试关注的是从用户输入到最终输出的完整链路。它不只看某个模块是否正确，而是评估整个 AI 应用是否完成了业务任务。
例如，一个核保产品推荐应用，端到端测试需要评估：用户输入是否被正确理解，健康信息是否被正确抽取，是否正确判断核保风险，是否正确识别缺失信息，是否调用正确产品或规则工具，是否生成合理推荐结果，是否说明推荐理由，是否提示最终以核保结论为准，是否在信息不足时追问，是否在无法判断时转人工或兜底。
端到端测试的价值，是直接反映用户和业务最终感受到的应用质量。
但端到端测试也有局限。如果最终结果错误，它不一定能直接告诉团队问题出在哪里。错误可能来自意图识别、信息抽取、规则判断、工具调用、上下文缺失，也可能来自最终输出。
因此，端到端测试和模块测试需要配合使用。可以这样理解：模块测试回答"哪里错了"，端到端测试回答"整体有没有用"。 成熟的 AI 应用评测，不能只做其中一种。
三、评测集需要覆盖的六类关键场景
无论是 0-1 阶段的 Mock Case，还是线上运营阶段的真实 Case，评测集都不能只覆盖标准问题。一个真正有用的评测集，需要从多个维度设计，以尽可能接近真实业务复杂性。
1. 高频场景
高频场景决定用户对 AI 应用的基本体验。如果一个应用在高频场景中经常出错，用户会很快认为它不可靠。评测集必须覆盖业务中最常见的问题、最常见的用户表达、最常见的任务路径。高频 Case 不一定最复杂，但必须稳定通过。
2. 高风险场景
高风险场景决定业务底线。有些场景虽然出现频率不高，但一旦出错，影响很大——例如保险核保结论、理赔判断、金融建议、医疗建议、合规表述。这类场景不能只看"回答是否像样"，更要看是否谨慎、是否遵守边界、是否避免过度承诺、是否在不确定时进入追问或人工处理。高风险 Case 是评测集中的底线样本。
3. 边界场景
边界场景用于测试 AI 应用的鲁棒性。常见边界场景包括：信息不完整，用户表达模糊，多意图混合，前后文冲突，图片与文字信息不一致，输入中包含错别字或噪音，用户提出超出能力范围的问题。边界 Case 的重点，是测试 AI 是否知道什么时候应该追问、拒答、兜底或转人工。
4. 不同用户类型
同一个 AI 应用，面对不同用户时，表达方式和任务目标可能完全不同。同样是保险咨询：普通客户可能会问"我这个情况还能买保险吗"，顾问可能会问"客户甲状腺结节 3 类，近一年复查无变化，有哪些重疾产品可以尝试"，核保老师可能关注"缺少哪些核保要素"。同一个场景，不同用户的语言、专业程度、信息完整度和期望输出都不同。评测集需要覆盖不同用户类型，而不是只面向一个"平均用户"。
5. 不同输入形式
真实 AI 应用中的输入形式可能不止文本。用户可能输入一句话、多轮对话、长文本、截图、影像件、表格、语音转文字、文本加图片、历史上下文加当前问题。如果应用实际需要处理多模态或多轮输入，评测集也应该覆盖这些输入形式。否则，评测结果只能说明应用在单一输入形式下表现良好，不能代表真实使用效果。
6. 不同业务路径
AI 应用通常存在多个业务分支：可以直接回答，需要补充信息，需要调用工具，需要转人工，需要进入推荐流程，需要进入审核流程，需要拒答或兜底。评测集要覆盖这些不同路径，否则只能验证主路径能力，无法验证完整业务流程。
四、评测case不是越多越好，而是越有代表性越好
建设评测集时，一个常见误区是把重点放在“数量”上，认为 Case 越多评测越可靠。但实际情况恰恰相反：评测集的价值不由规模决定，而由代表性决定。
100 条覆盖核心场景、高风险场景和历史 Bad Case 的高质量 Case，往往比 1000 条重复、同质、缺少标准答案的 Case 更有价值。如果评测集里堆了大量相似问法、简单问题或缺乏业务差异的样本，跑出来的通过率再高，也说明不了真实质量。
更成熟的做法是把评测集分层，让不同层级的 Case 承担不同角色：
核心回归集：数量少但覆盖全面，包含黄金 Case、高频 Case、高风险 Case 和历史 Bad Case。每次版本更新必须全部通过，用于防止核心能力退化。
专项评测集：围绕某类具体优化问题临时或阶段性使用。例如优化甲状腺结节核保判断时，构造一组覆盖不同分级、不同信息完整度的专项 Case，验证优化是否真正生效。专项评测集用完可以归档，高质量的可以并入核心回归集。
线上抽样集：持续从真实用户数据中补充新样本，用于发现设计阶段未覆盖的问题和新的 Bad Case。这层不需要立即打分，重点是保持评测集对真实业务环境的感知。
Bad Case 集：凡是线上出现过的错误、误判、用户不满意、业务人员不采纳的样本，持续沉淀进入 Bad Case 集，用于防止同类问题回归。
评测集的分层管理，本质上是在回答一个问题：团队有限的评测资源，应该优先投在哪里？核心回归集保障底线，专项评测集解决具体问题，线上抽样集保持感知，Bad Case 集防止反复——四层分工清晰，评测才能真正融入迭代节奏。
结语
评测集的测试范围，最终应该形成一个矩阵：横轴是模块和能力维度，纵轴是关键场景类型。模块测试帮助定位具体问题，端到端测试帮助判断整体效果，六类场景覆盖确保评测集不脱离真实业务复杂度。
只有三者结合，评测集才能真正回答两个核心问题：哪里出了问题，以及整体执行效果是否达到业务可用标准。
