2025，我们这样评测 AI

1 背景介绍

作为一位在测试开发领域深耕十余年的从业者，我的经历横跨互联网、智能汽车与 AI 服务等多个行业，在 ToC 产品、中台系统、智能客服、自动驾驶及大模型等业务的质量建设中积累了一定的实践。目前，我担任一家 AI ToB 创业公司的质量团队负责人，负责知识库、智能客服、智能问答等产品的整体质量体系建设。

在传统软件质量模型中，质量维度通常包括功能、性能、可用性、易用性、安全性、兼容性等。2025 年，团队除继续推行传统软件测试质量保障方案之外，我们通过建立 “AI 评测原则”（第 3 章节讲述），并以智能文档问答、智能问答、Agentic 智能体、语音类客服等业务场景为实践场地，逐步在项目中探索并完善各类 AI 效果的评测方法。本文也聚焦于易用性质量维度中的 AI 评测维度，其余维度暂不在本文中展开描述。

2 AI 评测痛点

在 AI 质量保障实践中，我们主要面临以下三方面痛点：

1. 评测数据的构建
   • 数据真实性： 如何构建能够真实反映业务场景的评测数据集？在构建过程中，应采取哪些方法确保数据分布、用户意图及使用场景与业务实际情况一致？
   • 标注权威性： 应由谁来负责标注 “标准答案”（Ground Truth），才能保证其准确性与业务权威性？是业务专家、终端用户，还是经过专门培训的标注团队？
2. 如何进行有效断言
   • 有标准答案的断言： 当存在明确 Ground Truth 时，如何制定评估规则，以判断模型输出在语义上是否与标准答案 “相近” 或 “等效”？
   • 无标准答案的断言： 对于开放型任务，往往不存在唯一的标准答案。此时应依据哪些维度、标准或方法，来评估输出结果的质量与符合度？
3. 如何控制评测数据规模
   • 如何科学设定评测数据的数量与范围？应依据哪些准则来确定既能保障统计信度、又能控制成本的数据规模？

3 AI 评测原则

3.1 评测数据构建原则

在 AI 质量保障过程中，评测数据的构建是确保模型效果符合业务需求的关键环节。目前，评测数据主要来源于以下四类：

• 客户线上数据回流： 直接来自实际生产环境，最能反映真实业务场景与用户行为分布。
• 客户团队手工标注： 由业务专家根据实际场景进行标注，贴近业务需求，但与完全真实的线上数据分布仍可能存在一定差距。
• 服务提供商通过工具/大模型泛化生成： 利用自动化方法或大模型批量生成数据，效率高、覆盖广，但可能存在噪声、过拟合或质量波动等问题。
• 服务提供商的标注团队手工标注： 由经过训练的标注人员完成，质量可控、结果稳定，在某些场景下优于纯自动生成方式，但效率较低，且依赖于标注团队当前的工作负荷及其对业务的理解程度。

在实际应用中，数据源的选取一般遵循以下优先级：
客户线上数据回流 > 客户团队手工标注 > 通过工具/大模型泛化生成 ≥ 标注团队手工标注

对于我们当前所处的业务来说，大多数是处于探索阶段的 AI ToB 项目，绝大部分项目缺乏充足的线上真实数据，且客户团队对标注工作的支持度和兴趣度往往有限。因此，实践中一般会首先尝试使用工具或大模型泛化生成评测数据。若生成的评测数据经标注团队抽样检验后符合要求，则优先采用该方式；若效果不理想，且优化成本高于手工构建，则转为由标注团队介入构造。另一种常见做法是采用混合构建策略，例如按照一定比例（如 7:3）将工具生成数据与手工标注数据相结合，以在保证效率的同时降低纯自动生成带来的质量风险。

3.2 评测指标选取原则

对于一个 AI 算法来说，评测指标的选取一般要经历三个层面：基础测量指标 → 离散函数层 → 直接业务指标。其中基础测量指标为底层指标（例如 Levenshtein 距离、字准率、句准率、BLEU、ROUGE、BERTScore），可以定量的展现评测结果，但不能展示确定性结果；直接业务指标为顶层指标，这是最贴近业务成果的综合性评价，直接回答了 “系统效果好不好”、“业务目标是否达成” 等核心问题；在基础测量指标和直接业务指标之间可能存在一个离散函数层，通过离散函数将基础测量指标的定量值转化为直接业务指标的定性值。

3.2.1 基础测量指标选取

基础测量指标类型一般有以下四种：

• 基于人工复核的指标： 虽为主观判断的金标准，能反映复杂语义和领域知识，但其成本高昂、效率低下且难以规模化。
• 基于传统规则/简单统计的指标： 具有规则明确、计算高效、结果完全可解释的优势。它们适用于对确定性要求高、注重表面形式一致性的场景，是快速验证和线上监控的可靠基础工具，但难以处理语义灵活性与复杂性。
• 基于特定模型的指标： 通过预训练模型捕捉深层语义相似度，在语义匹配等任务上提供了比传统方法更接近人类判断的自动化评估。其选取需考虑特定领域微调的成本，并理解其本质仍是另一个模型的输出。
• 基于 LLM-as-a-Judge 的指标： 利用大模型的通用知识与推理能力，能进行灵活、拟人化的综合评估，尤其擅长处理开放性和多维度判断任务。尽管强大且日益普及，但其评估结果本身具有一定黑盒性和波动性，且有一定的调用成本。

各分类的典型指标见下表所示：

基础测量指标分类	核心特点	语音识别类指标	语义匹配类指标	值比较类指标	代表指标
基于人工复核的指标	基于人类历史经验进行复核，与模型无关，受人类个人能力和对领域知识的理解力影响	人工语义匹配度	人工语义匹配度	-	-
基于传统规则/简单统计的指标	基于规则、词汇匹配、可解释性强、与模型无关	Levenshtein 距离、字准率、句准率	ROUGE、BLEU	字符串全等、字符串前缀匹配、字符串关键字匹配	-
基于特定模型的指标	使用在特定任务上微调的中小模型进行评价	-	BERTScore	-	-
基于 LLM-as-a-Judge 的指标	利用大模型的强大理解和生成能力，进行零样本/少样本的拟人化评估	大模型语义匹配度	大模型语义匹配度	-	-

在实践中，对基础测量指标的选取通常遵循一套决策逻辑，以确保评估效果与实施成本之间的平衡：

• 优先级一：遵循行业共识 若该领域已存在广泛认可的标准指标，则优先采纳。例如，在语音识别（ASR）评测中，Levenshtein 距离与字准率已成为事实上的行业标准，具备较强的可比性和公信力。
• 优先级二：根据任务复杂性自适应选择 若无公认指标，则需对评测任务本身的复杂性进行评估：
  • i) 规则可描述的中低复杂性任务： 若业务逻辑相对明确，可转化为清晰规则，则采用基于传统规则/简单统计的指标，如字符串匹配、关键词检出等，兼顾可解释性与执行效率。
  • ii) 实现复杂度与研发相当的复杂任务： 若业务高度复杂，且使用大模型进行自动评估的实现难度接近原系统研发（例如需额外构建一套与 ChatBI 等效的 SQL 生成系统），则评估的投入产出比偏低，此时宜采用基于人工复核的指标进行关键样本的深入校验。
  • iii) 适合大模型担任评估员的复杂任务： 若业务复杂但可通过提示工程较易调动大模型的评判能力，或评估依赖大量领域知识而测试团队不具备相应背景，则优先使用基于 LLM-as-a-Judge 的指标，以发挥其语义理解与灵活判断的优势。
  • iv) 受限于大模型使用条件的特殊情况： 如遇到客户侧禁用大模型、大模型调用成本高、大模型效率低下等约束，无法使用基于 LLM-as-a-Judge 的指标，可降级采用基于特定模型的指标。若该路径仍不可行，则进一步退回到传统规则类指标，在有限条件下实现基础自动化评测。

3.2.2 离散函数层的选取

在计算直接业务指标前，对于某些基础测量指标通常需要经过一个离散化过程，将一维连续指标的映射到特定的区间集合，再进行准确率、解决率等方面的计算。当然如果基础测量指标的结果本身就是离散的，则不需要进行此步骤的处理，可直接跳过。

以机器翻译评估为例，可通过 BLEU 算法计算两者相似度得分。然而 BLEU 本身是一个连续值，而最终我们需要的是一个 “正确” 或 “错误” 的二元判断。为此，我们可以引入一个单层离散函数，例如设定阈值 $X \geq 0.3$，当 BLEU 值大于等于 0.3 时即判定为正确。

为进一步支持不同阶段的评估需求，离散函数也可设计为多层，从而兼顾研发调试与产品验收的不同目标。例如，可设计第一级离散函数，将 BLEU 分值划分为四个质量等级：

• 较差 ($0 \leq X \leq 0.3$)
• 中 ($0.3 < X \leq 0.6$)
• 良 ($0.6 < X \leq 0.85$)
• 优 ($0.85 < X \leq 1$)

在此基础上，第二级离散函数可根据具体验收标准，将某些等级判定为 “通过”，其余为 “不通过”。例如可将 “中”“良”“优” 视为通过，“较差” 视为不通过。

多层分级设计有双重优势：一方面，细粒度的等级划分有助于研发团队定位问题、分析模型在不同质量区间间的表现；另一方面，客户对 “通过” 标准的定义可能随场景变化，通过灵活调整第二级离散函数的判定逻辑，即可快速适应不同的验收阈值，从而在统一评估体系下满足多样的业务需求。在我们内部实践中，如果多层分级设计不显著增加评测难度，那么采用该方式的实际效果会更好。

3.2.3 评测指标呈现原则

在指标呈现原则上，应根据受众背景与需求，分层提供不同深度的评测信息：

• 面向纯业务团队： 若客户侧缺乏技术背景或仅关注业务成效，建议只呈现直接业务指标。这类指标直观反映系统整体能力，便于业务理解与决策。
• 面向具备技术背景或感兴趣的业务团队： 可在此基础上，额外提供基础测量指标及离散函数层。这有助于客户技术团队理解评估细节，增强信任与协作透明度。
• 面向内部技术团队： 应完整呈现全部三层信息——基础测量指标、离散函数层与直接业务指标。这有助于研发进行问题定位、模型迭代和效果归因，支撑全链路优化。

3.3 评测量级确定原则

在第 3.1 节提到，部分项目的评测过程仍需依赖人工生成/标注/断言。若评测数据量过大，还是会面临人力问题；而数据量过少，则难以满足 “统计学意义”，导致结果受随机波动影响较大，可信度不足。那么，评测数据集的数量应保持在什么规模，才能在控制人力成本的同时，具备一定的统计可靠性呢？

一般来说，针对单条评测语料的判断结果通常为 “正确” 或 “错误”。在评测语料来源尽量随机的情况下，评测结果服从二项分布 $X \sim B(n, p)$，其中参数 $p$ 可视为模型的准确率。根据数理统计中的参数估计理论，当样本量 $n \to \infty$ 时，在 95% 置信水平下，参数 $p$ 的置信区间可用公式 $p \pm 1.96 \cdot \sqrt{\frac{p(1-p)}{n}}$ 表示。

假设在一般项目中，评测准确率的准出值设定为 $p=85\%$，则区间边界与 $p$ 的差值可由公式 $y = \frac{0.699}{\sqrt{x}}$ 计算得出，其中 $x$ 代表数据条数。数据量与误差之间的关系如下：

• $x=100$，误差 $y=6.9\%$
• $x=300$，误差 $y=4.0\%$
• $x=500$，误差 $y=3.1\%$
• $x=700$，误差 $y=2.6\%$

举例来说，如果在某次评测中使用 300 条数据，测得准确率为 85%，则其实际准确率下限约为 $85\% - 4\% = 81\%$，上限约为 $85\% + 4\% = 89\%$。在 AI 算法评测的实践中，我们通常选取 $n=200 \sim 300$ 条数据，从而将边际误差控制在 4%-5%。与此同时，在构建评测数据时，除关注数据总条数外，还需关注数据分布的合理性，确保各类数据样本均有足够的代表性。

---

4 AI 评测实践

4.1 智能问数 (ChatBI)

4.1.1 背景

智能问数 (ChatBI) 是一种基于自然语言对话的新型商业智能工具。它将传统 BI 复杂的数据查询、建模和可视化过程，简化为如同与人交谈一般的自然语言交互。用户无需掌握 SQL 或熟悉复杂的报表工具，只需用日常语言提问（如 “去年 XX 渠道销售额最高的产品是什么？”），ChatBI 系统便能理解其意图，自动生成并执行相应的数据查询，并以直观的表格、图表或文本摘要形式返回分析结果。其核心价值在于降低数据分析门槛、提升决策效率，并支持灵活、深度的数据探索。

4.1.2 评测语料生成

为确保全面、真实地评估 ChatBI 系统的产品价值，关键在于通过多样性的评测语料覆盖各类用户问法，并将其转化为正确的数据查询与分析结果。评测语料的设计基于用户自然语言查询的三大核心语义要素：原子指标（如销售额、库存量）、加工逻辑（如求和、同比、排名）以及分析维度（如时间、地区、产品）。这三者是构成任何数据查询意图的基础。

以此为基础，评测语料的生成需遵循一套多维度的系统化策略，以确保覆盖从基础功能到核心价值的全场景测试：

1. 指标体系覆盖：确保查询意图的完整表达 此维度的目标是模拟用户在询问业务指标时的各种可能方式。语料需全面覆盖客户业务中的所有原子指标、加工逻辑（包括基础统计、排序比较、时间序列分析、占比分析等）、分析维度。同时，还要覆盖维度的各种比较方式（如大于、介于、属于、为空）、布尔运算（且、或）以及不同数量的维度组合，以检验系统解析复杂业务问题的能力。
2. 用户问法覆盖：测试自然语言理解的鲁棒性 为体现 ChatBI 在模糊提问与多轮对话方面的价值，语料需从语言本身的变化角度进行设计。这包括：同一意图的多钟句式表达（疑问句、陈述句、短语）；分析维度的不同表述顺序；使用别称、缩写及大小写变体；模拟多向问题聚合查询；以及构建多轮对话场景，考察上下文继承与指代消解能力。
3. 分析复杂度覆盖：验证处理复杂逻辑的能力 此维度旨在挑战系统的深层分析潜力。语料需从技术实现角度出发，设计涵盖不同 SQL 复杂度的场景，例如涉及多表 JOIN、多个关联条件、以及集合操作（并集、交集等）的查询，以评估系统在应对复杂数据关系时的性能与准确性。
4. 多语言场景覆盖：评估国际化支持能力 根据交付要求，需将核心评测语料翻译为目标语言（如英文），以验证系统在不同语言环境下的意图理解和查询生成是否一致与准确。
5. 算法稳定性覆盖：保障系统的可靠性与健壮性 此维度关注系统的隐性要求。通过设计错误问法（如输入不存在的指标或维度值）来测试系统的容错与引导能力；通过幂等测试（重复请求同一问题）来检验结果的一致性与服务的稳定性。

4.1.3 评测指标计算

为判断结果是否符合要求，一种常见的做法是 SQL 复写法，即由测试人员将评测语料人工翻译为标准 SQL 语句，执行后得到预期结果，再与系统实际输出进行比对。然而，该方法要求测试人员为每条语料编写 SQL，人力成本高昂。

因此，在实践中往往转向一种更为轻量化的断言方案。鉴于 ChatBI 的技术路径（无论是 NL2DS2L2SQL 还是 NL2SQL）最终均会将自然语言转换为 SQL 执行，测试人员可在首次测试时，直接对系统生成的 SQL 进行人工评审 (Review)，并人工判断断言结果为正确 (True) 或错误 (False)。在后续的回归测试中，则以首次评审通过时所对应的执行结果作为基准真值 (Ground Truth)，进行自动化或半自动化的结果比对，从而在后续工作中相对高效地完成回归验证工作。

ChatBI 的评测通常采用端到端准确率作为核心指标，其定义为：
ChatBI 端到端准确率 = 结果完全符合预期的测试用例数 / 测试用例总数

其中，“结果完全符合预期” 是指 SQL Review 正确且系统返回的数据/表格/图表等均等一致。

4.1.4 评测工具建设

基于上述方案，我们利用大模型技术开发了一套评测语料生成工具，并已成功应用于多个 ChatBI 项目的交付测试中。该工具的核心实现思路如下：

• 第一步： 在生成框架中内置多种评测语料场景的 Prompt 模板，覆盖原子指标泛化、加工逻辑泛化、数值比较方式泛化、分析维度泛化、多轮对话泛化、时间维度泛化等典型场景。
• 第二步： 向大模型注入特定项目的领域知识，主要包括：用户典型问法示例、原子指标列表、加工逻辑列表、分析维度及枚举值列表、别称映射或别称规则、有效查询组合、国际化语言列表等。
• 第三步： 融合第一步的 Prompt 模板与第二步的领域知识，生成面向具体场景的、可执行的 prompt。
• 第四步： 通过 YAML 文件对所有 prompt 进行任务编排，构建完整的评测语料生成任务流程，并自动化执行。
• 第五步： 将生成的评测语料按照预设的语料类型进行分类存储，便于后续的测试与管理。

4.1.5 未来优化方向

在 ChatBI 评测的实践过程中，我们主要遇到以下两类问题，需要进行持续优化。

1. 用户问法多样性带来的适配挑战： 基于框架生成的评测问法需持续迭代，以覆盖在初始设计时未能预见的用户真实表达方式。例如，在查询某一原子指标在不同维度下的取值时，我们预设的多轮对话模式为：
   • 第一轮：“What's the value in dim1?”
   • 第二轮：“How about it in dim2?” 而实际场景中，用户可能将两轮询问合并，并直接要求对比不同维度下的数值，形成如下的复合问法：“How does the value compare across dim1 and dim2?”
2. 评测结果断言的效率与门槛问题： 尽管人工评审法在效率上优于 SQL 复写法，但仍存在两方面局限：一是对测试人员的 SQL 能力与业务理解要求较高，二是人工逐条审核 SQL 仍存在效率瓶颈。目前该方法是我们实践中的较优解，若有更高效的解决方案，也期待进一步探讨。

---

4.2 智能文档问答 (RAG)

4.2.1 背景

RAG 是一种将信息检索与大型语言模型相结合的框架。其核心流程是：当收到一个用户查询时，系统首先从一个外部知识库（如文档集合）中检索出相关的上下文片段，然后将这些片段与原始查询一起输入给 LLM，从而生成一个基于可靠来源、减少幻觉的答案。RAG 的关键优势在于能够利用最新的、特定领域的信息，同时保留 LLM 强大的理解和生成能力。

RAGAS 是评测 RAG 流水线而设计的流行开源框架。它的核心理念是通过分析 RAG 内部组件的输出来评估其质量。RAGAS 主要评估以下几个核心过程指标：

• 答案相关性： 衡量答案与问题的匹配度
• 答案忠实度： 衡量答案对检索上下文的依赖程度
• 上下文相关性： 衡量检索出的上下文与问题的相关度

我们在实践 RAG 评测时，主要面临以下两类关键问题：

1. RAGAS 评估指标与业务目标的错位。 RAGAS 核心输出是一系列过程指标。这些指标本质上是诊断性的，它们孤立地评测 Query、Answer、Context 三者中任意两者之间的关系，有助于定位 “检索过程” 或 “生成过程” 的短板。然而，客户往往关心的是一个简单、直接的端到端业务指标，即：“这个系统给出的答案最终准确率是多少？” 如何定义一个综合反映事实正确性、完整性且符合业务直觉的 “答案准确率”，是 RAGAS 这类工具未能解决的关键需求。
2. “真值不真” 与 “局部最优” 陷阱。 如果不采用 RAGAS 而采用端到端评测时，通常需要依赖人工标注真值。然而，这种方法极易使评测陷入一种 “局部最优” 的误区。所谓局部最优是指：为控制成本，真值通常基于一个有限的评测文档子集（例如部分文章段落）来反向生成问题并标注答案。但在实际生产环境中，RAG 系统面对的是全量文档。很可能出现这种情况：对于某个评测问题，全量文档中存在比评测子集更相关、信息更丰富的文档，能产生更优的答案。此时，基于局部子集标注的 “真值” 本身就并非全局最优，甚至可能是片面或次优的。用这个 “不真” 的真值作为标准去评判系统，会错误地引导系统流向这个局部最优对齐，而抑制了其从更全知识库中寻找最佳答案的能力。寻找 “全局最优” 真值的代价（标注全量文档所有可能的问题与答案）过高，导致这一根本矛盾在实践中难以解决。

为应对上述挑战，我们在评估实践中采用了一套融合有真值评估与无真值评估的综合断言方法，并辅以针对性的评测语料生成策略。这一组合方案在一定程度上缓解前述的两类问题。

4.2.2 评测语料生成

评测语料生成的核心目标是构建一个覆盖多种查询类型与难度层次的多样化测试用例集合，以全面评估 RAG 系统的各项能力。整体生成逻辑是基于实际客户文档，通过抽样选取文档内容并通过大模型反向生成对应问题。为充分保证问题的多样性，我们设计了多层次、多维度的生成方法，具体如下：

1. 基于单篇文章生成： 此模式以单篇文章的标题、摘要及全文内容为基础生成问题，旨在检验系统对单文档的理解与信息提取能力。生成过程系统覆盖以下维度：
   • 信息检索深度： 包括单表单段落（答案可直接从单个段落推导）与单表多段落（需跨段落整合信息）两种类型。
   • 答案内容类型： 按比例涵盖量化型（涉及具体数值、指标）、非量化型（涉及概念、过程）及混合型。
   • 查询精确度控制： 平衡低精确度（≤1 个限制条件）与高精确度（包含明确限制目标或≥2 个限制条件）问题的比例。
   • 表达多样性增强： 生成后的问题会经过同义替换、句式转换、常识扩展等自动化改写，以丰富语言表达并提升语料多样性。
2. 基于多篇文章生成： 此模式专注于测试系统的跨文档推理与信息综合能力。我们通过聚类算法筛选内容高度相关的文章对，并据此生成问题。问题明确设计为需跨文档解决的复杂类型，主要包括：
   • 多文多跳： 需进行跨文档的链式逻辑推理。
   • 多文聚合： 需从多篇文章中拼接、比对或整合信息。 同样，其答案内容会覆盖量化、非量化及混合类型，并包含不同精确度要求。
3. 基于标题聚类生成： 此模式模拟用户基于模糊记忆或主题经验发起的查询。首先对全部文档进行主题聚类，然后基于聚类结果生成问题，其答案通常为相关文章的标题或标题集合。该方法主要用于检验系统在文档元数据（标题）层面的检索与关联能力。

通过上述生成方式与问题属性的有机结合，我们所构建的测试语料库能够相对广泛地模拟 RAG 系统在实际应用中可能面对的各种查询场景。

4.2.3 评测指标计算

为应对 4.2.1 中提到的 RAGAS 评估指标与业务目标不匹配、真值本身存在局限性的问题，我们设计了一套融合有真值评估与无真值评估的综合断言方法。该方法具体方案如下：

1. 真实答案与上下文获取 将测试语料生成的预期答案输入至待测系统，获取系统实际生成的答案及其对应的检索上下文。
2. 初步评估（基于 LLM 的定性判断） 针对每个测试用例，使用大语言模型 (LLM) 对比预期答案与实际答案，执行初步质量评估。LLM 将依次进行以下分析： 1) 从预期答案和实际答案中提取关键信息点； 2) 对信息点进行归一化处理； 3) 分析信息点匹配情况，划分为共同信息点、仅存于预期答案中的信息点，以及仅存于实际答案中的信息点； 4) 对仅存于预期答案中的信息点标注重要性等级（高/中/低）； 5) 检测仅存于实际答案中的信息点是否存在矛盾或冲突。 6) 基于以上分析，按照预设规则将结果划分为 “优”、“良”、“中”、“差” 四个等级。等级判定不仅依据缺失信息点的数量，也综合考虑缺失信息点的重要性。
3. 二次评估（基于 RAGAS 的量化指标） 为避免因预期答案仅为局部最优、而系统实际答案可能优于预期所导致的误判，针对初步评估为 “中” 或 “差” 的测试用例，引入 RAGAS 指标进行二次量化评估。具体计算实际答案与预期答案之间的答案相关性 (Answer relevance) 得分，以及实际答案基于上下文的答案忠实度 (faithfulness) 得分。此步骤目的有二：1) 通过比较答案相关性得分，判断实际答案是否比预期答案更贴合问题；2) 通过答案忠实度得分，确保实际答案在优于预期的同时，未脱离原文依据，避免幻觉或编造造成的质量误判。若实际答案相关性未显著高于预期答案（差值 ≤ 0.01），则维持初步评估等级；否则，结合相关性得分与忠实度计算得到的幻觉概率进行等级重调：
   • 相关性 ≥ 0.8 且 幻觉概率 ≤ 1% → 调整为 “优”
   • 相关性 ≥ 0.7 且 幻觉概率 ≤ 1%，或相关性 ≥ 0.8 且 幻觉概率 ≤ 2%，或相关性 ≥ 0.9 且 幻觉概率 ≤ 3% → 调整为 “良”
   • 相关性 ≥ 0.6 且 幻觉概率 ≤ 5% → 调整为 “中”
   • 其余情况 → 调整为 “差” 其中，幻觉概率通过公式 (1 - faithfulness_score) × 模型基准幻觉率 计算。此调整机制确保了在认定实际答案更优时，同时满足高相关性与低幻觉率的要求。
4. 端到端结果汇总 若测试用例的答案等级被评定为 “优”、“良” 或 “中”，则最终结果为通过。 若评定为 “差”，则最终结果为不通过。 若测试用例在执行过程中出现异常，则不纳入最终统计范围。
5. 评价指标 最终，RAG 的评测通常可采用 RAG 端到端准确率作为核心指标，计算公式为： RAG 端到端准确率 = 结果通过的测试用例数 / 测试用例总数

4.2.4 评测工具建设

RAG Evaluator 是一个面向 RAG（检索增强生成）系统的内部自研自动化评估框架。该框架集成了 RAGAS 和大模型能力，提供从测试语料构建到系统质量评估的端到端解决方案，其标准工作流程为：
输入文章 → 问题生成 → 请求发送 → 质量评估 → 评估报告。

框架的核心由以下三个模块构成：

1. Generator (生成器模块) 功能：负责从输入的文章中自动生成多样、高质量的测试问题。 工作内容：支持多种生成策略，包括：
   • 单篇文章问题生成：基于单篇文章的完整内容生成具体问题。
   • 多篇文章问题生成：基于多篇相关文章生成需要跨文档综合推理的问题。
   • 基于标题的问题生成：从文章标题直接导出相关问题。
   • 基于摘要的问题生成：利用文章摘要信息生成问题。 输出：生成标准化的测试用例文件（如 query.csv），其中包含问题、标准答案、问题分类等完整数据。
2. Requester (请求器模块) 功能：自动化地向目标 RAG 系统发送测试请求，并收集响应结果。 工作内容：支持对请求端点进行灵活配置，实现批量测试用例的自动发送与结果回收。
3. Tester (测试器模块) 功能：对 RAG 系统的响应进行多维度质量评估。 工作内容：采用 4.2.3 节所述的综合断言策略，从答案相关性、忠实度等角度输出进行自动化评判，并生成结构化评估结果。

4.2.5 未来优化方向

在 RAG 系统评测的实践过程中，我们主要遇到以下两类问题，需通过持续优化加以解决：

1. 评测结果与研发调优之间存在断层 当前评测结果中标记为 “不通过” 的用例，往往难以直观、高效地辅助研发人员定位根因，影响了问题排查与模型迭代的效率。
2. 评测语料生成与断言策略仍需完善 现有的语料生成策略和断言机制，仍需通过更多实际项目交付进行验证与优化，以进一步提升其有效性和对业务场景的覆盖度。例如如何对于同一篇文档的不同版本，如果出现知识冲突，如何进行测试，并融合进评测框架中。

---

4.3 Agentic 智能体

4.3.1 背景

Agentic 智能体（或称 “智能代理”）是指具备自主性、目标导向、能感知环境、进行决策并执行动作的人工智能系统。其基本架构如图所示（包含 Context, Knowledge, Tools, Strategy, LLM）。

与传统基于固定工作流的智能体不同，Agentic 智能体具有更强的主动性与上下文连贯性。这为测试工作带来了以下几项显著挑战：

1. 测试无法依赖预置脚本或静态语料。 由于 Agentic 智能体会根据实时上下文与环境动态生成回应，测试方无法再通过预先编排的固定流程来验证其行为。举例而言，传统智能体是 “剧本式” 的，只要掌握剧本即可按部就班执行；而 Agentic 智能体则基于其掌握的领域知识和环境信息进行实时判断与决策，因此传统的预先编制语料的方法难以直接适用。
2. 测试过程的高度动态性对测试动作与断言提出新要求。 具体表现为：
   • 对话推进的判断： 在与 Agentic 智能体交互时，测试程序如何自动决定是否应继续追问？
   • 对智能体提问的响应： 当智能体主动提出问题时，测试应当如何回应——是查询真实数据生成答复，还是结合测试场景架构构造合理回复？
   • 结果正确性断言的困难： 在动态交互过程中，可能存在 “过程错误但结果正确” 的情况。如何建立有效的断言机制，以准确评估其行为与输出的正确性？

这些挑战共同指向一个核心问题：如何对具有高度自主性与动态响应能力的智能系统进行可靠、自动化且可重复的测试。以笔记本键盘故障场景为例，若采用人工方式测试智能体 (Agentic)，可能呈现如下对话：

场景一：

• 测试员： 我的笔记本键盘坏了。
• 智能体： 请问你的笔记本键盘撒上水了吗？
• 测试员： 没有。
• 智能体： 请问你的笔记本键盘的键帽掉了吗？
• 测试员： 是。
• 智能体： 如果键盘键帽掉了，我们需要为您派发新键盘。

由于智能体具有动态响应特性，其提问顺序并不固定，因此对于同样的场景也可能出现如下对话：

场景二：

• 测试员： 我的笔记本键盘坏了。
• 智能体： 请问你的笔记本键盘的键帽掉了吗？
• 测试员： 是。
• 智能体： 如果键盘键帽掉了，我们需要为您派发新键盘。

可见在以上两种对话中，尽管智能体的提问不同（第二段对话中用户少回答了一个问题），但两段对话对现实世界产生的结果是一致的。这进一步凸显了对这类系统进行有效测试的复杂性与特殊性。

4.3.2 评测工具建设

为了解决上述问题，我们自主研发了 Agentic Tester，采用 “以智能体测试智能体” 的思路，将语料生成、请求发送和结果断言整合为统一流程，并根据 Agent 的响应进行动态实时测试，从而系统地应对前述挑战。该框架的整体结构包含 Agentic Tester 与 Agentic AI Agent 之间的交互逻辑。

框架的核心设计如下：

1. 基于场景模拟的动态响应 在 Agentic Tester 中，我们不再直接生成静态的评测语料，而是将需要模拟的现实场景作为上下文输入。例如在 “键盘故障” 场景中，Agentic Tester 接收到的一条测试用例描述如下： a. 笔记本键盘无法使用 b. 现象为键帽脱落 c. 未出现其他异常现象 d. 期望给出的最终结果为派发新键盘 Agentic Tester 将基于这些已知设定，根据被测智能体的实时提问，动态决定如何回答。关于现实场景的覆盖率问题，我们并未追求对所有可能的现实情况进行模拟，原因有二：其一，我们并非业务专家，难以覆盖所有真实情况；其二，业务方通常只关注其服务范围内的可解决问题，模拟域外场景价值有限。因此，我们一般依据客户提供的可解问题范围，通过遍历方式进行测试。若数据结构为列表则枚举；若为树或图结构，则采用深度优先或广度优先遍历策略。
2. 对话终止条件的智能判断 智能体对话往往具有开放性，因此 Agentic Tester 需具备判断何时结束对话的能力。终止条件可通过多种方式设定，例如最大对话轮次、关键词匹配或关键意图识别等。
3. 支持外部数据查询的 MCP 机制 当智能体询问需要真实数据的问题时（如笔记本 ID），若返回虚假信息可能导致校验失败，进而影响评测有效性。为此，Agentic Tester 可根据问询意图，调用相应的 MCP 工具查询数据库，确保返回真实、有效的数据。
4. 过程与结果的双重断言 为避免 “过程错误但结果正确” 的情况，Agentic Tester 在断言阶段不仅检查智能体最终输出的解决方案是否正确，还会核对其所有交互应答是否符合最初设定的待模拟的现实场景条件，确保对话过程与最终结果均符合预期。
5. 评价指标 基于上述机制，Agentic 系统的评测通常采用端到端解决率作为核心指标，计算公式为： 端到端解决率 = 问题解决的对话数 / 对话总数

4.3.3 未来优化方向

在 Agentic 智能体评测的实际应用过程中，我们发现约 90% 的情况下 Agentic Tester 能够做出准确判断，但仍存在约 10% 的误判情况。误判的主要原因仍集中在对对话终止条件的动态判定、以及过程与结果的双重断言等环节，这些部分仍需通过持续优化 Prompt 来进一步提升准确性。尽管这需要测试人员投入一定时间进行调试与迭代，但相较于传统手工测试方式，所需的时间和精力仍然处于可控范围内，效率优势依然显著。

---

4.4 语音智能客服

4.4.1 背景

语音智能客服是一种结合语音识别、自然语言处理、等多种人工智能技术的客户服务系统。它不仅能处理文字交互，还能通过语音渠道与用户进行自然、高效的沟通。目前语音智能客服广泛应用于金融、售后、公共服务等领域。其关键技术组件包括：

• 语音识别 (ASR)： 将用户语音实时转换为文本。
• 自然语言处理 (NLP)： 理解用户意图，进行情感分析、实体提取，并生成上下文连贯的回复。
• 语音合成 (TTS)： 将文本回复转化为自然流畅的语音。
• 知识图谱与推荐系统： 基于结构化知识库快速检索答案，并主动推荐解决方案。

4.4.2 评测语料生成

评测语料类型涵盖以下多种语音与语义场景，以全面评估系统性能。

• 语音特性类： 音量稳定的长句、音量稳定的短句、音量强弱波动语料
• 语义结构类： 标准问语料、相似问语料、泛化语料、闲聊语料
• 语音复杂度类： 专业术语语料、含有助词/停顿词的语料

评测语料来源主要来自以下三种途径，确保语料覆盖全面且贴近实际场景。

• 线上回流数据切分： 通过人工听取线上真实录音，标注起止时间与转写真值，并借助 ffmpeg 切割为独立评测语音文件。
• 人工录制构造： 针对难以通过现有数据构造的场景（如音量强弱波动语料），采用人工录制方式生成对应语音文件。
• TTS 生成构造： 对大多数场景，可先通过人工或大模型生成泛化文本，再经 TTS 转换为语音文件，高效构建大规模评测集。

4.4.3 评测指标计算

评测方式： 评测采用人工抽检与自动化检测相结合的方式。考虑到语音测试通常涉及多轮对话、系统承压能力有限，且端到端响应时间较长，为平衡测试效率与覆盖度，自动化检测也需合理控制评测语料条数，避免全量测试带来的过高时间成本。

评测指标： 从 VAD、ASR、NLU、TTS、端到端等几个视角，判断最终效果。

VAD (语音活动检测)

• 漏切率 = 漏切的 case 数 / 总抽检 case 数 (采用人工抽检)
• 多切率 = 存在多切情况的 case 数 / 总抽检 case 数 (采用人工抽检)

ASR (语音识别)

• 字错率 (CER，采用自动化测试)。 为减少标点、助词、同义词等对识别结果的影响，在计算 CER 前会对标注文本与 ASR 输出文本进行统一过滤：
  • 使用正则表达式去除所有中英标点符号；
  • 分词后过滤常见助词与停用词，如 “的”“了”“呢”“吗”“啊”“呀”“吧” 等；
  • 分词后进行同义替换统一表达，如数字 “5” 替换为 “五”、“缴费” 替换为 “交费”、“您” 替换为 “你” 等。

NLU (自然语言理解)

• 意图识别精度 (采用自动化测试)

TTS (语音合成)

• TTS 准确率 = 准确的条数 / 总条数 (采用自动化测试 + 人工辅助检查)
  • 自动化判断：将 TTS 语音通过 ASR 转译为文本，与预期文本比较，CER ≤ 5% 即视为准确；
  • 人工辅助检查：对自动化判断准确率较低的案例进行复核，确保结果可靠。

端到端

• 端到端准确率 = NLU 和 TTS 阶段准确的测试语料数 / 测试语料总数

4.4.4 评测工具建设

下图（未在 MD 中展示图片）展示了我们内部开发的语音智能客服系统端到端自动化评测工具的架构图。主要流程描述如下：

1. 测试准备阶段
   • 使用本地语音文件（包含待测试的语音文件及其对应的转写真值、意图码）作为输入。
   • 通过测试语料服务管理测试用例，支持 HTTP 接口调用。
   • 语料库中每条测试语料包含：ID、项目详情、版本、文件路径、转写真值、级别、意图码、场景标签等信息。
2. 测试执行阶段
   • 通过 SIPp 触发管理脚本 (Shell) 控制 SIPp（一个 SIP 协议测试工具）模拟呼叫并发送语音文件。
   • 待测语料进入语音系统后，系统处理后会返回 ASR 转写结果、NLU 识别出的意图码，以及 TTS 生成的语音回复。
3. 评测与分析阶段
   • 通过 端到端评测脚本 (Python) 对 ASR 转写结果与真值进行对比，计算识别准确率，同时可对 NLU 的意图识别结果进行验证以及 TTS 的合成结果进行验证。

4.4.5 未来优化方向

未来，我们将持续从各行业交付实践中系统化积累评测语料，逐步构建覆盖多领域的标准语料库。同时，积极探索基于多模态大模型的语料自动化生成方法，以提升语料构建效率，显著降低对人工制作的依赖与成本。

---

5 尾声

以上内容来自我团队在 2025 年 AI 质量保障一线实践中的经验与思考，其中既有局部创新与尝试，也包含不少仍在探索中的不足之处。如果大家对该文章中的评测方法有任何意见或建议，欢迎评论或微信交流。

testerhome.com

“并集” 报告可能存在的缺陷

1. 报告与源代码版本不匹配，导致数据失真
   这是最核心的问题。代码覆盖率报告的每一行都必须能对应到一个具体的源代码文件。在作者的案例中，最终的 HTML 报告是基于 temp-branch (修改后) 的源代码生成的，但覆盖率数据却包含了来自 master (修改前) 分支的执行信息。

   • 场景一：覆盖了已删除的代码：方法 mA 和 mC 在 master 分支被执行并记录了覆盖率，但在 temp-branch 中它们已经被删除。最终报告在展示 temp-branch 的代码时，就无法显示 mA 和 mC 的覆盖情况，这份来自旧版本的数据就成了 “幽灵数据”，只会影响总体的覆盖率百分比，但开发者找不到对应的代码。
   • 场景二：行号错乱：一个在两个版本中都存在的文件，如果在 temp-branch 中间被插入了几行代码，那么 master 分支记录的覆盖率行号就可能与 temp-branch 的实际行号对不上，导致报告将覆盖标记显示在错误的代码行上。

2. 产生误导性的、虚高的覆盖率指标
   覆盖率的核心目标是评估当前版本代码的测试完善程度。将旧版本的测试结果合并进来，会人为地 “膨胀” 覆盖率数字。

   • 例如，一个模块在旧版本中有 100% 的覆盖率。在新版本中，开发者对其进行了重构，但忘了更新测试，导致实际覆盖率下降到 50%。如果使用 “并集” 报告，旧的 100% 数据可能会掩盖新版本测试不足的事实，让团队产生 “这个模块测试很充分” 的错觉，从而忽略了潜在的质量风险。

3. 违背了代码覆盖率的 “快照” 哲学
   一次覆盖率报告应该是某个时间点上 “代码状态” 与 “测试状态” 的一个精确快照。它回答的问题是：“对于这份代码，我们的这套测试跑了多少？”
   而 “并集” 报告混合了两个不同时间点的快照，回答的是一个模糊的问题：“对于现在的代码，我们曾经跑过的、来自不同版本的测试加起来能覆盖多少？” 这个指标的指导意义就变得不那么明确了。

为什么 JaCoCo 原来不这么做？（其设计考量）

1. 保持确定性和单一事实来源
   JaCoCo 的设计遵循业界标准：一份报告严格对应一个代码版本和一次（或多次）针对该版本的测试执行。这样可以确保报告的结果是确定性的、可追溯的。开发者看到报告中的任何数据，都能准确地在对应的 Git Commit 中找到源代码和测试用例。

2. 聚焦于 “增量覆盖率” 和变更影响
   在现代 CI/CD 流程中，团队更关心的是“本次变更所引入的代码是否得到了充分测试”，即 “增量覆盖率”。JaCoCo 的标准用法能够很好地支持这一点。开发者在一个 Pull Request 中修改了代码，CI 会针对这个分支跑一次测试并产生报告，团队可以清晰地看到新代码的覆盖情况。如果合并历史数据，就无法有效评估当前变更的质量。

3. 避免工具的复杂性
   如果官方支持这种 “并集” 功能，就需要处理大量复杂的边界情况，例如如何对齐不同版本的行号、如何处理被重命名的类和方法、如何向用户清晰地展示数据来源等。这会让工具本身变得非常复杂，且容易产生让用户困惑的结果。保持简单、专注于核心场景是优秀开源工具的普遍设计原则。

这种角色有点像产品运营了

行情这么差啊，上海这边社工考试都很紧俏了，热门岗位 100：1 了

Offer 保底： 在目前的环境下，有一个 offer 在手总比没有强，能缓解焦虑。
涨薪 20%： 相对目前的薪资有提升，短期内能改善经济状况。
避免单休： 如果单休是您非常不能接受的点，那么去欢聚可以立即摆脱这个困境。

连续三年 A+ 说明您的工作能力和态度是得到认可的。续签大概率没问题

还有就是 了解试用期的考核标准和转正难度。

大龄就别去了

学历一般的话，35+ 是更难

希望 2025 春节以后就业环境好一点，论坛的兄弟们找工作都顺利

公司年底逼退大龄员工的常规操作吧，能把年终奖发完的都还算好了

仅楼主可见