很多团队第一次做 AI 应用测试时都会遇到一个很尴尬的问题传统系统测对错通常有明确答案。接口返回状态码是不是 200 金额计算是不是 99.99 权限校验是不是拦住了非法用户 数据库字段是不是落对了这些问题大多可以写成断言。但是到了 AI 系统里问题突然变复杂了。同一个问题模型可能给出不同表达 同一个任务不同上下文下答案可能都“看起来合理” 同一个输出业务觉得能用测试觉得不可控法务觉得有风险产品觉得体验还行。于是很多团队会卡在第一步AI 系统到底怎么算“正确”如果这个问题没有定义清楚后面的测试用例、评估指标、验收标准、质量门禁基本都会变成拍脑袋。阅读目录传统软件里的“正确性”为什么更容易定义AI 系统的正确性为什么变复杂了AI 系统正确性的核心定义不能只看答案要看任务、证据、约束和风险AI 系统正确性的 8 个评估维度RAG、Agent、多模态系统的正确性差异测试团队如何把“正确性”落到工程里一个可落地的 AI 正确性评估框架一、传统软件里的“正确性”本质上是“规格符合”在传统软件测试里我们判断一个系统是否正确核心依据通常是需求规格 输入条件 预期输出。比如一个优惠券系统输入 商品金额 200 优惠券规则 满100减20 预期输出 最终金额 180这个场景的正确性很清楚。只要输出不是 180那就是错误。传统软件的正确性大多建立在几个前提上维度传统软件特点输入相对结构化规则明确写在需求里输出可预测、可枚举判断方式可以断言失败原因大多可追踪到代码逻辑所以传统测试最常见的方法是assert actual_result expected_result这也是很多测试工程师熟悉的工作方式。但 AI 系统不是这样。二、AI 系统的正确性为什么不能只靠“标准答案”AI 系统最大的问题不是“它没有答案”而是它经常有多个看似合理的答案。比如用户问请帮我总结这份会议纪要里的核心风险。模型可能输出版本 A核心风险包括需求边界不清、交付时间紧、跨团队协作成本高。版本 B主要风险集中在排期压缩、责任人不明确以及验收标准缺失。这两个答案谁更正确如果会议纪要里确实都提到了这些内容那两个答案可能都不算错。但如果模型凭空补了一条“预算不足”而原文没有出现那就属于错误。所以 AI 系统的正确性不能简单定义成输出是否等于某个标准答案更准确地说AI 系统的正确性应该定义为“在给定任务目标、上下文、约束条件、证据来源和风险等级下AI 系统输出是否满足可验证目标并且没有突破业务、安全、事实和格式边界。这句话比较长但非常关键。AI 的正确性不是一个单点判断而是一组约束共同成立。三、AI 系统正确性的核心不是“像不像人话”很多团队做 AI 测试时容易把注意力放在这些表面问题上回答是不是流畅语气是不是自然内容是不是看起来合理有没有把话说完整这些当然重要但它们更多属于体验质量不等于正确性。一个回答可以非常流畅但事实完全错误。比如某个内部接口支持 /api/v3/user/export并且默认返回 CSV。这句话看起来很像真的。但如果系统里根本没有这个接口它就是错误。AI 系统最危险的地方就在这里它可以用非常确定的语气说出完全不存在的内容。所以 AI 系统的正确性一定要从“语言表达”往下拆真正的正确性不是“说得像不像”而是有没有把该做的事做对。四、AI 系统的正确性要先区分三类问题做 AI 测试时建议先把问题分成三类答案型任务生成型任务行动型任务这三类任务的正确性标准完全不同。1. 答案型任务重点看事实和证据典型场景智能客服问答企业知识库问答政策制度查询技术文档问答代码解释数据分析问答用户问公司的报销发票要求是什么这类任务的正确性重点不是文采而是答案是否来自知识库是否引用了正确文档是否遗漏关键限制是否编造不存在的规则是否把旧制度当成新制度是否能拒答知识库里没有的信息对于答案型 AI 系统正确性可以简单理解为回答内容 用户问题 检索证据 业务规则 的一致结果如果没有证据支撑就不能随便回答。2. 生成型任务重点看目标、约束和可用性典型场景写文章写邮件生成测试用例生成代码生成 SQL生成方案生成海报文案比如让 AI 生成测试用例根据登录需求生成边界值和异常场景测试用例。这类任务通常没有唯一标准答案。正确性不能只看“是不是和标准答案一模一样”而要看是否覆盖核心业务路径是否包含异常场景是否符合测试设计方法是否没有引入不存在的需求是否输出结构可直接使用是否符合团队模板规范生成型任务的正确性更像是满足任务目标 覆盖关键场景 遵守输出约束 具备实际可用性3. 行动型任务重点看执行链路是否安全可靠典型场景Agent 调用工具自动创建工单自动操作浏览器自动执行 SQL自动发邮件自动调用接口自动修改代码仓库比如用户说帮我查一下最近 7 天支付失败的订单并生成分析报告。一个 Agent 可能会执行这里的正确性不只是最后报告写得好不好还包括工具选得对不对查询条件对不对时间范围有没有错SQL 有没有越权是否访问了不该访问的数据是否正确处理空结果是否对异常做了降级是否保留执行日志行动型 AI 系统的正确性本质上是意图理解正确 工具选择正确 参数构造正确 执行结果正确 权限边界正确只看最终输出很容易漏掉中间链路的问题。五、AI系统正确性的 8 个核心维度如果要把 AI 正确性落到测试标准里不能只写一句“回答正确”。建议至少拆成 8 个维度。维度一任务理解是否正确AI 首先要理解用户到底想干什么。比如用户说帮我看一下这段代码有没有性能问题。它要识别出这是一个代码评审任务重点应该放在时间复杂度空间复杂度IO 调用数据库访问循环嵌套缓存使用并发风险如果模型跑去解释代码语法方向就偏了。测试关注点检查项示例是否识别用户意图用户要评审不是翻译是否识别任务类型问答、生成、分析、执行是否识别关键对象代码、接口、日志、文档是否识别隐含目标找风险、给建议、输出结论维度二事实是否正确这是 AI 系统最基础的正确性。比如技术概念有没有说错API 参数有没有编造法规政策有没有过期公司制度有没有引用错误数据统计有没有算错文档内容有没有歪曲AI 系统常见的事实错误包括1. 编造不存在的信息 2. 把旧信息当成新信息 3. 把相似概念混在一起 4. 用不确定内容给出确定结论 5. 对数字、时间、版本号产生错误尤其是企业知识库场景事实正确性非常重要。因为用户不是在跟 AI 聊天而是在把 AI 当成一个业务系统使用。维度三证据是否一致对于 RAG 系统来说正确性不能只看回答还要看回答和检索证据是否一致。一个回答如果看似正确但不是基于检索材料得出的也存在质量风险。典型错误包括错误类型说明无证据回答知识库没有内容模型自己补充证据错配检索到了 A 文档却回答 B 文档内容证据过期引用了旧制度、旧接口、旧版本证据断章取义只引用局部信息忽略限制条件证据冲突未处理多份文档说法不同模型直接选一个RAG 系统的正确性可以拆成两层如果检索错了生成再好也没用。 如果检索对了生成乱编也不行。维度四约束是否遵守AI 系统通常会有很多约束。比如只能基于知识库回答 不能输出敏感字段 必须使用 JSON 格式 不能给出医疗诊断 不能执行删除类操作 必须先确认再发邮件这些约束往往比答案本身更重要。比如让 AI 输出接口测试用例要求是{ case_name: , precondition: , steps: [], expected_result: }如果模型内容写得不错但格式不符合平台要求系统就无法解析。这类错误在 AI 工程里非常常见。所以格式正确性也是正确性的一部分。维度五推理过程是否可靠有些 AI 系统不是直接回答而是需要多步分析。比如根据这份日志判断支付失败的主要原因。正确的分析链路可能是先识别错误码 再聚合出现频次 再结合时间窗口 再判断是否集中在某个渠道 最后给出根因假设如果模型直接跳到结论应该是第三方支付通道异常。但没有任何依据这个结论就不可靠。AI 的推理正确性不是要求它展示复杂过程而是要求结论能被输入支撑中间判断没有明显跳步不把猜测包装成事实能区分确定结论和可能原因能在证据不足时降低置信度维度六工具调用是否正确Agent 系统尤其要关注工具调用。因为一旦 AI 能调用工具它就不只是“说错”还可能“做错”。比如用户想查询订单Agent 却调用了退款接口。这就不是普通回答错误而是执行风险。Agent 工具调用正确性至少包括维度检查点工具选择是否选择了正确工具参数构造参数是否完整、准确权限控制是否越权访问执行顺序多工具调用顺序是否合理异常处理工具失败后是否重试或降级高风险动作是否需要二次确认Agent 系统的正确性可以理解为不仅要答对还要做对不仅要做对还要在边界内做对。维度七稳定性和一致性是否可接受AI 输出存在随机性。同一个问题问三次模型可能给出三种表达。这不是天然错误但要看业务是否允许。比如写营销文案适度变化可以接受。 但查公司制度、生成 SQL、审批建议就不能随意变化。因此 AI 正确性里还要考虑一致性同一输入、多次执行核心结论是否稳定 相似输入、轻微改写输出是否保持一致 不同模型版本关键任务是否出现质量回退这就是 AI 系统里的回归测试问题。传统系统升级后我们跑自动化用例。 AI 系统升级模型、Prompt、知识库、检索策略后也必须跑评估集。维度八风险边界是否守住AI 系统不是所有错误都一样严重。比如把文章标题写得不够好和错误地生成了一条删除数据库数据的 SQL完全不是一个风险等级。所以 AI 正确性一定要引入风险分级。风险等级示例测试策略低风险文案表达不够自然人工抽检中风险测试用例遗漏场景评估集 人工复核高风险错误业务建议证据校验 专家审核极高风险自动执行付款、删除、审批强权限 二次确认 全链路审计AI 系统的正确性不是平均分越高越好。真正关键的是高风险场景不能错。六、不同 AI 系统正确性的定义不一样AI 系统不是一种系统而是一组系统形态。不同形态下正确性的重点完全不同。1. 大模型问答系统关注重点回答是否准确是否理解问题是否拒绝无法回答的问题是否避免编造是否遵守角色设定是否能给出清晰解释适合指标准确率、拒答正确率、幻觉率、相关性、完整性2. RAG 知识库系统关注重点是否检索到正确文档是否引用正确片段是否基于证据回答是否处理文档冲突是否避免知识库外编造适合指标检索召回率、Top-K 命中率、上下文相关性、答案忠实度、引用准确率3. AI Agent 系统关注重点是否正确拆解任务是否选择正确工具是否构造正确参数是否处理异常是否遵守权限和审批流程是否留下可审计记录适合指标任务成功率、工具调用准确率、参数正确率、执行失败率、人工接管率4. 代码生成系统关注重点代码是否能运行是否满足需求是否通过测试是否存在安全问题是否符合工程规范是否容易维护适合指标编译通过率、单测通过率、漏洞数量、代码规范评分、需求覆盖率5. 测试用例生成系统关注重点是否覆盖主流程是否覆盖异常流是否覆盖边界值是否贴合需求是否没有编造需求是否能直接进入测试管理平台适合指标需求覆盖率、场景完整度、无效用例率、可执行率、重复率七、AI 正确性不能只靠人工感觉要工程化评估很多团队上线 AI 功能时评估方式是找几个人试一下感觉还不错就上线。这种方式在 Demo 阶段可以在生产环境不够。AI 系统的正确性要工程化至少需要四类数据八、黄金测试集AI 测试的基本盘黄金测试集可以理解为 AI 系统的“核心回归用例”。它不是随便凑一批问题而是从业务高频场景、风险场景、历史问题中整理出来的标准评估集。一条黄金测试样本至少应该包含{ question: 员工报销发票抬头有什么要求, context: 报销制度文档片段, expected_points: [ 必须使用公司全称, 发票内容需与实际业务一致, 电子发票需上传原始文件 ], forbidden_points: [ 不能编造税号规则, 不能引用旧版制度 ], risk_level: medium }注意这里的 expected_points 不一定是完整标准答案而是关键判断点。因为 AI 输出可能有不同表达但关键事实不能错。九、AI 正确性评估建议用“打点式”而不是“全文匹配”传统断言喜欢这样写assert actual expected但 AI 输出不适合全文匹配。更适合使用“关键点检查”。比如def evaluate_answer(answer: str) - dict: checks { mentions_company_full_name: 公司全称in answer, mentions_invoice_consistency: 实际业务in answer or业务一致in answer, no_fake_tax_rule: 税号必须notin answer, no_old_policy: 旧版制度notin answer } passed all(checks.values()) return { passed: passed, checks: checks }这只是一个简化示例。真实工程里可以结合规则校验关键词校验结构化字段校验LLM-as-Judge人工抽检业务专家复核线上反馈闭环重点是不要只问“这段回答好不好”而要拆成可检查的判断点。十、LLM-as-Judge 可以用但不能迷信现在很多团队会用大模型来评估大模型。比如让评估模型判断回答是否忠实于参考文档 回答是否遗漏关键点 回答是否出现幻觉 回答是否满足格式要求这种方式很有价值尤其适合大规模评估。但它也有明显风险评估模型本身也可能误判评分标准不稳定Prompt 改动会影响评分对细粒度业务规则不一定敏感对高风险场景不能完全替代人工比较稳妥的做法是也就是说能用规则判断的不要全交给模型规则判断不了的再让模型辅助评估。十一、AI 系统正确性必须引入“可观测性”AI 系统出错时不能只看到最后一句回答。要能追踪它为什么这么回答。尤其是 RAG 和 Agent 系统至少要记录日志对象作用用户原始输入判断任务意图Prompt 版本定位提示词变更影响模型版本定位模型升级影响检索 Query判断检索是否跑偏召回文档判断证据是否正确Rerank 分数判断排序是否合理工具调用记录判断执行链路是否正确最终输出判断结果质量用户反馈形成优化闭环没有可观测性AI 测试会变成玄学。你只能看到“这次回答错了”却不知道是问题理解错了是知识库没召回是召回了但排序错了是 Prompt 没约束住是模型编造了是工具参数传错了是用户问题本身有歧义AI 系统正确性的评估必须和链路追踪绑定。十二、一个更实用的定义AI 正确性 契约正确性如果要用一句话来总结可以这样定义“AI 系统的正确性不是输出一个唯一标准答案而是在特定任务契约下满足事实、证据、约束、格式、行动和风险边界。这里的关键词是任务契约。每个 AI 能力上线前都应该定义清楚它的任务契约。比如一个“AI 生成测试用例”的能力任务契约可以写成输入 需求文档、接口文档、业务规则 输出 结构化测试用例列表 必须满足 1. 覆盖主流程、异常流、边界值 2. 不编造需求文档中不存在的功能 3. 输出字段符合测试管理平台格式 4. 高风险业务规则必须生成对应用例 5. 不输出无法执行的空泛描述 不可接受 1. 把技术方案当成需求 2. 生成重复用例 3. 遗漏权限、幂等、异常处理场景 4. 输出无法导入平台的格式一旦契约清楚测试就能落地。否则只能靠感觉判断。十三、测试团队可以怎么做如果你是测试团队要评估一个 AI 系统的正确性可以按这个流程走具体动作可以拆成 7 步第一步先定义 AI 能做什么、不能做什么不要一上来就测。先问清楚这个 AI 能力的边界是什么 哪些问题必须回答 哪些问题必须拒答 哪些动作可以自动执行 哪些动作必须人工确认边界不清正确性就无从谈起。第二步把任务类型拆清楚同一个 AI 系统里可能同时包含问答摘要生成推荐分类工具调用多轮对话不同任务要用不同标准。不要用一套指标评估所有能力。第三步定义每类任务的正确性指标比如 RAG 问答指标含义答案相关性是否回答了用户问题事实准确性内容是否正确证据忠实度是否基于召回文档引用准确率引用文档是否匹配拒答正确率无答案时是否拒答幻觉率是否编造不存在内容比如 Agent指标含义任务成功率是否完成用户目标工具选择准确率是否选对工具参数正确率是否传对参数越权调用率是否触碰权限边界异常恢复率工具失败后是否处理人工接管率需要人工介入的比例第四步建设黄金测试集测试集不要只放简单问题。要覆盖高频问题边界问题易混淆问题无答案问题冲突文档问题权限限制问题历史线上问题高风险业务问题AI 系统的很多问题不会出现在正常样本里而会出现在边界样本里。第五步评估不能只看平均分AI 系统很容易出现一种情况整体评分 90 分但关键问题错了。比如客服系统 100 个问题里答对 90 个但把退款规则答错了。这比普通闲聊错一句严重得多。所以评估时要看总体分分场景分高风险场景通过率幻觉率拒答能力线上负反馈样本高风险场景建议单独设置准入门槛。第六步把评估接入发布流程AI 系统每次变更都可能影响质量换模型改 Prompt改知识库改检索参数改切分策略改工具描述改权限策略所以 AI 系统也需要回归测试。发布前至少跑一轮核心评估集。第七步线上反馈要能回流到测试集AI 系统上线后用户反馈非常重要。但不能只停留在“用户点了踩”。要进一步分析用户为什么点踩 是答非所问 是事实错误 是缺少证据 是格式不对 是没有解决问题 是触发了风险边界然后把典型问题沉淀到测试集中。这样 AI 系统才会越测越稳而不是每次都从头排查。十四、AI系统正确性的最终判断标准AI 系统的正确性不应该再用一句“答案对不对”来概括。更合理的判断方式是1. 它是否理解了用户任务 2. 它是否基于正确证据 3. 它是否遵守系统约束 4. 它是否输出了可用结果 5. 它是否避免了编造和越界 6. 它是否在高风险场景下足够保守 7. 它的结果是否可以被追踪和复现 8. 它在版本迭代后是否保持稳定如果这几个问题答不清楚AI 系统的质量就很难被真正控制。AI 测试的难点不是没有标准而是标准要重新设计传统软件测试的核心是给定输入验证输出是否符合预期。AI 系统测试的核心变成了给定任务、上下文、证据和约束验证系统是否在边界内完成目标。这就是 AI 正确性和传统正确性的最大区别。AI 系统不是不能测也不是只能靠人工感觉测。它需要把“正确性”从一个模糊判断拆成一组可验证的工程契约任务契约 事实契约 证据契约 格式契约 工具契约 权限契约 风险契约 回归契约未来 AI 应用越深入业务测试团队越不能只盯着“模型回答得像不像”。真正要盯的是它有没有在正确的边界里完成正确的事情。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。