大模型驱动的产品评测方案(三): 数据准备和评测环节

构建一个大模型应用都有哪些环节需要进行评测，需要进行什么样的测试活动？

一、数据集准备

选择能够验证指标、说明问题的数据，关注以下三个方面：

覆盖度:是否覆盖了产品的主要功能和话题？

多样性:输入方式、难度、意图是否足够丰富？

代表性:数据分布是否能反映真实的用户使用情况？

在整个评测体系中，数据集的质量直接决定了评测结果的可信度和有效性。一个有缺陷的、或是不具代表性的数据集，会产生误导性的指标结果，让团队对产品能力产生错误判断，最终可能导致产品在真实世界中的失败。

因此，制定并执行一个严谨的数据集策略，是评测工作成功的重要条件。构建一个高质量的“黄金”数据集可以遵循以下步骤：

从业务目标出发

数据集的构建必须由业务需求驱动，首先要问：我们想测试什么？哪些场景的成功或失败对业务影响最大？例如，一个电商客服机器人，其问题数据集必须包含关于订单状态、退货政策、产品推荐等核心业务流程的问题。

从多个渠道收集数据来源

为了确保数据集的丰富性和真实性，应从多个渠道收集数据样本。

生产数据：对于一个客服机器人，可以收集生产环境中真实用户询问过的历史问题，这是获取绝大多常规数测试数据和意想不到的边缘案例的最佳来源。（注意：当使用生产数据时，必须高度重视数据隐私。所有个人可识别信息都应在处理前进行脱敏或匿名化处理）

灰度测试：邀请内部员工或一小部分种子用户对产品进行测试，可以系统性地收集反馈和有价值的测试用例。

人工编写/标注：对于一些专业性强的场景，或者为了系统性地测试某一类问题，可以由领域专家人工编写测试用例。例如一个和病人沟通的病情诊断机器人，可以由资深医生编写测试数据（包括问题和正确的回答）。

LLM合成：也可以利用大模型来生成大规模的测试数据，但是需要注意检查模型生成数据的质量。如果生成的问题没有代表性或者隐含着基本的事实错误，会对测试结果造成很大的影响。

人工标注：定义“黄金标准”：这是构建数据集过程中最耗费人力但也是价值最高的环节。由专家对收集到的数据进行标注，即为每个输入提供一个理想的“标准答案”或质量评分。

-明确标准：标注过程本身就是一个强迫团队清晰、明确地定义评测标准的过程。例如，什么是“完整”的回答？什么程度的语气才算“有同理心”？

-多重标注与一致性检验：为了保证标注质量，最佳实践是让多名标注员独立对同一份数据进行标注。只有当大多数标注员（如三人中的两人）达成共识时，这个标签才被采纳为最终的“标准答案”。这有助于消除个人主观偏见，确保数据集的可靠性。

数据集构成确保多样性与平衡性

数据集必须在多个维度上具有多样性，以模拟真实世界的复杂性，例如覆盖不同的用户画像、主题、提问风格和语言复杂度。

同时要避免数据不平衡，即某个类别的问题被过度代表，这可能导致评测结果产生偏差。

常见的数据集构成

常规：业务场景中最常见的数据类型

边缘：业务场景中不常见，但是有可能出现的数据类型

对抗：影响系统和应用正常运行的有害数据输入

快速启动，迭代扩展

不需要在一开始就构建一个包含数千个样本的庞大数据集。一个由20-50个高质量、多样性的样本组成的初始数据集，就足以启动评测流程。

关键在于建立一个持续的流程，随着对应用失败模式的理解加深，不断地将新的、有挑战性的案例补充到数据集中。

一个“黄金”数据集不是一成不变的静态文件。它是一个动态的、与产品共同成长的“活”的资产。

当在生产环境发现了新的用户行为模式，或当红队测试发现了新的系统漏洞时，这些新的数据都必须被吸收、标注，并整合回“黄金”数据集。这个反馈闭环将生产环境的洞察力源源不断地注入到评测流程中，使得评测体系随着时间的推移变得越来越强大和全面。

二、评测环节和测试活动

从最初的产品构思到生产环境的维护，在每个阶段都需要评估，这些工作流程环环相扣：

从方案选型开始，找到最佳方案。

在发布前进行压力测试和红队测试，为各种情况做准备。

应用上线后，安全护栏可以帮助预防重大问题。

产品投放市场后，通过生产可观察性持续监控实时数据。

如果出现问题，修复后运行回归测试，然后推出更新。

评测环节

测试活动

1）选型测试：为AI产品选择最佳的模型、提示词或其他配置

项目刚开始时，第一步通常是进行技术方案选型，首先要为任务选择一个模型，可以查看模型排行榜挑选几个候选LLM，并在具体任务上进行测试。另一个常见的选型任务是找到最佳提示词，对比不同提示词下的输出小效果。

2）压力测试：通过评估产品在各种场景下的表现，检查它是否为实际上线使用做好了准备。

压力测试旨在检查当前版本的产品是否足够健壮，能否应对用户可能抛出的各种问题。系统可能在十几个测试用例数据上运行良好，但几百、几千个呢？压力测试需要更多的测试数据，既要覆盖常见的场景，也要考察系统如何处理更棘手的边缘情况。

如果用户的输入只有一个词怎么办？如果太长了呢？

如果输入用的是另一种语言或包含错别字呢？

系统如何处理它不应涉及的敏感话题？

设计这些测试需要深入了解用户如何与产品互动，尽可能对每个主题或场景都进行测试。

3）红队测试：测试我们的系统如何响应对抗性行为或恶意输入

红队测试是一种模拟攻击的测试技术，例如通过提示注入等方式，发现系统中的漏洞。这是评估高风险应用安全性的关键步骤，专门针对滥用或者故意的有害行为。它寻找的是恶意用户如何利用系统缺陷，将行为推向不安全或意外（如提供有害建议）的方法。

例如，对于一个医疗聊天机器人，测试它如何安全地处理医疗问题属于核心功能范围。但对于一个产品客服机器人，医疗、金融或法律问题就超出了预期用途，可被视为对抗性输入。

红队测试可以手动进行，也可以通过合成数据和有针对性的提示来自动化地模拟各种风险。

4）生产环境监控：了解系统在生产环境中的实时性能，以便检测和解决问题。

在测试环境中评估终究有限。当产品面向真实用户后，需要了解它在实际使用中的表现。这就引出了生产环境可观察性。一旦产品上线，就需要追踪性能。

可以从追踪用户行为开始，比如收集点击率或点赞/点踩等反馈。但要获得更深入的洞察，就需要追踪用户提出的问题以及系统如何响应。收集跟踪记录所有交互的详细日志。

用户体验好吗？回答是否准确、安全？

有了这些日志数据，就可以通过运行在线评估来评价生产环境中的质量。

5）回归测试：测试新的改动是否在改进系统的同时，没有破坏以前正常工作的功能。

回归测试能验证所做的更改或优化没有引入新的（或旧的）问题。

修复一个问题后，会不会影响其他功能？

微调一个提示后，有多少以前的输出会改变？这些改变是好是坏？

系统化的回归测试可以安全地在现有系统之上进行迭代，确保在做出改进的同时，没有引入新的问题。