大模型测试综述

本文全面阐述了大模型应用的质量保障策略。首先介绍了大模型应用的核心组件，随后区分了模型评估和系统评估的不同侧重点，并详细探讨了系统测评指标，涵盖知识能力、安全性和应用性评估。在业务测试方面，强调了明确目标和设计相应指标的重要性，并以具体场景为例进行说明。此外，还分析了提示词攻击的风险及应对策略，并介绍了常见的性能测试指标。最后，总结出大模型质量保障的三个关键阶段：确保模型安全、开展工程测试和持续进行效果评测。本文为大模型应用的质量保障提供了系统性的指导。

被测对象概述

大模型应用通常由几个核心层次和组件构成，形成一个完整的系统架构：

1. 客户端层：作为用户与应用交互的前端接口，负责接收用户输入并展示输出结果。它是用户体验的直接载体，需要设计直观且响应迅速的界面。
2. API 网关层：处理所有进入系统的请求，负责请求的路由、负载均衡和初步处理。API 网关作为系统的统一入口，确保了接口的一致性和安全性。
3. 应用层：

• 业务逻辑服务：实现应用特定的业务规则，处理与模型无关的应用逻辑。它确保了系统行为符合特定领域的需求和规范。 任务管理服务：协调各个服务的核心，管理请求的整个生命周期。它负责任务的调度、监控和状态管理，确保系统运行的连贯性和效率。

4. 服务层：

• 模型服务：作为大模型应用的核心组件，负责管理和运行预训练的大语言模型。它包含模型加载、推理执行和结果生成等关键功能。模型服务首先将预训练模型加载到内存或 GPU 中。在接收到请求后，它将输入数据传递给模型，执行前向推理过程，生成输出。此外，模型服务还负责模型的版本控制、动态切换和性能优化，如模型量化、批处理等技术，以提高推理速度和资源利用率。
• 数据处理服务：处理输入数据的预处理和执行输出数据的后处理，确保数据格式满足模型和应用的需求。它在原始数据和模型输入输出之间起到桥梁作用，提高了系统的适应性和灵活性。

5. 数据层：

• 数据存储服务：管理用户数据、模型配置等，提供数据持久化和检索功能。它是整个系统的基础设施，确保数据的安全性、一致性和可用性。

在这个分层架构中，各组件之间通过明确的接口进行交互，既保证了系统的模块化和可扩展性，又提高了开发和维护的效率。值得注意的是，模型服务的性能和可靠性直接影响整个系统的响应速度和输出质量，因此在系统设计、测试和优化过程中需要特别关注。通过合理的架构设计和资源分配，可以充分发挥大模型的能力，同时确保系统的稳定性和可扩展性，为用户提供高质量的服务。

测试思路综述

一个典型的大模型系统的可变部分可以被粗略划分为提示词输入、Prompt 模板和输出内容：

• Prompt 模板由 AI 开发工程师或业务产品团队配置，是确保大模型输出质量的基础；
• 提示词输入是面向外部用户的接口，此处的提示词变化多端，甚至可能被别有用心的用户利用来对大模型系统发起攻击；
• 输出内容与提示词测试密切相关，需要作为一个整体进行评估。然而，我们可以通过控制变量法，保持输入一致，从而获取相对客观的模型输出。

模型评估与系统评估

模型评估 (Model Evaluation) 专注于比较不同 LLM 模型的性能，通过使用相同的 prompt 模板和输入数据来测试多个模型，如 Llama 和 Vicuna，目的是评估它们在相同条件下的表现差异。这种方法有助于我们直接比较不同模型的能力，为特定任务选择最合适的模型。

系统评估 (System Evaluation，也叫任务评估，Task Evaluation) 关注整个 AI 系统的性能，特别是 prompt 设计的影响。它使用同一个模型测试不同的 prompt 模板，评估不同 prompt 设计对模型输出的影响，目的是优化 prompt 工程，提升系统整体性能。

这两种评估方法都很重要，它们相辅相成，共同为 AI 系统的全面优化提供了基础。面对不同的任务需求，我们可能需要灵活调整模型选择和 prompt 设计的组合。全面掌握模型评估和系统评估这两种方法，让我们能够从容应对多变的场景，为每个任务量身定制最优解决方案。 此外，在当前 AI 技术快速迭代的大环境下，持续改进 AI 应用的能力至关重要。通过循环往复地执行模型评估和系统评估，我们可以与时俱进地优化 AI 系统，使其始终紧跟技术前沿，满足日益变化的业务需求。

系统测评测试指标

在评估大模型系统时，我们关注多种测评类型，每种类型都聚焦于模型能力的特定方面。这些测试类型可以从业务视角出发，衍生出一系列测评维度和具体指标。在实际应用中，通过对不同测评类型的深入分析，我们可以有选择地采用最相关的测评维度和指标，从而实现对业务的全面保障。

业务测试探索

测试场景分析

首先需要明确业务目标，然后基于这些目标设计相应的测试指标。这些指标应该符合业务流程场景、工程场景和安全场景，旨在全面评估模型在实际应用中的表现。下面以客服机器人、情感分析、机器翻译和内容生成为例简单介绍大模型应用常见的业务指标与注意事项。

在客户服务领域，大模型主要用于提供全天的自动化支持。关键测试指标包括问题解决率、响应时间和客户满意度。高效的客服机器人不仅能够迅速回应客户询问，还应具备准确理解和解决复杂问题的能力。因此，建议将多轮对话能力作为评估指标之一，以测试模型处理复杂情境的能力。

情感分析在舆情监控和客户反馈分析中发挥着重要作用。除了基本的准确率、精确率和召回率，还建议评估模型的细粒度分析能力和上下文理解能力。这有助于捕捉复杂的情感表达和隐含的情感倾向。

机器翻译的评估需要综合考虑翻译质量、语义保留度和流畅度。建议结合自动评估指标（如 BLEU）和人工评分，以全面评估翻译效果。此外，专业术语的翻译准确性也是一个值得关注的指标，尤其在特定领域的应用中。

内容生成是大模型的另一个重要应用领域。在这一场景中，内容质量和创意性是关键指标。推荐使用人工评分或基于预定义标准的自动评分系统来评估生成内容的质量。此外，如果生成内容会进被行进一步处理或者作为下游系统的输入，那么就需要考量业务系统对内容的统计学指标，例如平均生成字数、生成字数中位数等，确保生成内容可以满足下游服务的输入条件。

评估指标制定

在设计和实施这些业务指标时，Anthropic 提出了一个极具启发性的建议：设计与选择指标的核心是构建快速、可靠且扩展性强的评价体系。

具体来说，在设计评价体系时应该遵循任务明确、尽可能自动化和量大于质这三个原则。第三点可能与追求高质量评估的直觉相悖，但这背后的原因令人暖心。

• 首先，更大的样本量能提供更可靠的统计结果。即使每个单独的评估可能不如人工评分那么精确，但大量的评估可以抵消个别误差，提供更准确的整体性能评估。
• 其次，更多的问题能够覆盖更广泛的场景和边缘情况，这对于全面评估模型的性能至关重要。虽然自动化评分可能存在一些系统性偏差，但它可以消除人工评分中可能出现的主观偏见。
• 最后，自动化评分大大降低了评估的时间和资源成本，使得大规模评估成为可能，有助于快速迭代开发和持续改进。

Anthropic 在构建评分系统时提出了三种常见的评分方式：自程序动化打分、人工打分和大模型打分。我们将重点讨论使用大模型进行打分时的注意事项，特别是在评估其他大模型产出时 (例如使用类似 CriticGPT 的评估模型) 需要考虑的关键点。

• 首先，制定详细且清晰的评分提示词。比如 “答案应该始终在第一句话中提到’汉堡’。如果没有提到，答案自动评为’不正确’。”
• 其次，评估标准应该是可量化且客观的。具体实践中，可以要求大模型根据特定的条件仅输出 True 或者 False ，或者要求从 1 到 5 打分。这种评估标准即有利于大模型客观评分，又便于后续批量自动化时整理结果。
• 最后，鼓励思考但不输出推理过程。这适用于比较复杂的推理场景，例如，分析给定的用户使用协议文本，考虑其合法性、适用范围和潜在影响。然后，仅给出 1-5 的评分，其中 1 代表"完全不合法"，5 代表"完全合法且广泛适用"。模型会更可能考虑到问题的各个方面，但最终只保留结论。

需要注意的是，这里仅探讨了 Anthropic 的方法。读者可以进一步探索其他公司的实践案例，并结合自身需求进行灵活运用和创新，以不断丰富和完善大模型业务类评估的方法论。

测试探索实践

提示词攻击

提示词攻击是针对大语言模型的一种新兴安全威胁。在这种攻击中，恶意行为者通过精心设计的输入提示词来操纵模型的输出，其手段包括但不限于注入恶意代码、诱导产生偏见性内容，以及利用对抗性样本进行干扰。这些攻击可能导致敏感信息泄露、决策严重失误，甚至系统整体崩溃。对于大模型系统而言，提示词攻击不仅威胁其技术可靠性，更严重损害用户对系统的信任。这一挑战在允许用户直接输入提示词的应用场景中尤为突出，凸显了加强大模型系统安全防护的紧迫性。

常见性能指标

针对大模型的性能指标设计需要从多个维度进行全面考量，以确保系统的高效运行和优质用户体验。这些指标不仅反映了系统的技术性能，还体现了业务需求的满足程度。我们可以从以下几个关键角度来设计和评估大模型的性能指标：业务响应能力、模型推理效率、资源利用率、系统可靠性和可扩展性指标。

让我们深入探讨为什么首令牌时间 (TTFT) 与平均输入令牌数量呈二次幂正相关关系。这主要源于 Transformer 模型中的自注意力机制。在该机制下，每个输入令牌都需要与所有其他输入令牌进行交互计算。这种全局交互导致计算复杂度与输入令牌数量成平方关系增长。具体而言，如果输入序列包含 $N$ 个令牌，那么每个令牌都需要与其他 $N-1$ 个令牌进行注意力计算，因此总的计算复杂度为 $O(N^2)$ 。

除了输入长度，TTFT 和每个输出令牌的生成时间 (TPOT) 还受到其他因素的影响,例如单设备推理并发数、模型并行数等。这意味着它们会随着系统负载的变化而动态调整。此外，设备算力、模型结构、参数规模、输出长度以及推理优化方法等因素也会影响 TTFT 和 TPOT 的基准值。

在满负载且输入输出长度固定的条件下，我们可以通过压力测试得出 TTFT、每秒处理令牌数 (TPS)、每秒查询数 (QPS) 和平均响应时间 (RT) 等关键性能指标。并发用户数 (VU) 可以通过 $QPS \times RT$ 计算得出。不过在实际聊天应用场景中，由于用户在收到模型响应后还需要一定的输入时间，因此 VU 的计算公式应为 $VU = QPS \times (RT + WT)$，其中 $WT$ 表示平均等待时间。根据经验，可以使用 $QPS$ 乘以 10 来粗略估计 $VU$。

这些指标提供了一个全面的框架来评估大模型应用的性能。在实际应用中，可以根据具体的业务需求和技术架构选择最相关的指标进行重点监控和优化。通过持续跟踪这些关键性能指标，可以及时发现系统瓶颈，指导优化方向，最终实现大模型应用的高效运行和卓越用户体验。

值得注意的是，这些指标并非孤立存在，而是相互关联、相互影响的。例如，提高 $QPS$ 可能会导致 $RT$ 增加，优化 $TTFT$ 可能会影响模型的整体准确率。因此，在性能优化过程中，需要权衡各项指标，找到最佳的平衡点，以满足特定应用场景的需求。

结论

在大模型业务质量保障的落地过程中，我们需要遵循一个层次分明的策略，以确保全面而有效的质量管理。

首要关注点是模型安全，这是整个质量保障体系的基石。它包括防范恶意攻击和滥用，以及严格的模型输出合规检测。只有在确保模型的安全性后，其他质量保障措施才能有效实施。此阶段的重点在于建立并执行严格的数据管理策略和精细的模型访问控制机制，为后续工作奠定坚实的安全基础。

其次，我们需要深入开展模型工程测试。这一阶段聚焦于识别和解决模型在实际运行中可能出现的偏差和错误。通过全面的工程测试，我们力求提升模型的健壮性，确保其在多样化的环境和高压力条件下仍能保持稳定性能，从而保障模型的持续可靠运行能力。

最后，贯穿整个模型生命周期的是持续的模型效果测评。这一过程旨在确保模型始终达到预定的性能标准和业务目标。我们需要建立定期的模型效果评估和验证机制，持续监控并提升模型输出的准确性和可靠性。此阶段的重点包括制定全面的测试套件和评估标准，快速构建自动化评估体系，以及不断优化模型性能。

通过这三个阶段的系统性质量保障措施，我们可以全面提升大模型的安全性、可靠性和性能，为其在复杂业务环境中的应用奠定坚实基础。