在AI重塑产品逻辑的时代，评测不再只是“验证功能”，而是“定义价值”。本篇作为系列首发，将从战略视角切入，解析为何评测必须前置于产品设计与运营之中，成为连接用户认知与产品能力的关键枢纽。

本文面向受众：

参与大模型应用设计和开发的所有人员，包括不限于（产品经理、开发、算法、测试人员、业务人员）

内容导读：

评测的战略必要性 （是什么、为什么）

不同岗位人员的分工（谁来评）

目标：

• 帮助产研团队和业务人员对大模型应用评测形成全面认知，知道自己在整个工作流中扮演着什么样的角色
• 搭建一套评测方法论，为内部提供一份可操作的指南，构建一套属于自己的、全面的应用评估设计框架
• 调研主流评测平台和评测框架，为技术栈和平台选型提供参考

评测的战略必要性

什么是大模型应用评测

大模型应用评测：评估的是大模型所赋能的产品或系统在特定任务上的表现。不仅包括模型部分需要评估，还包括其他部分：提示词、工作流逻辑、用于增强回答效果的知识库等等。

模型基准测试像学校考试，衡量的是通用技能；而产品和应用层面的评估更像是工作绩效考核，检验的是系统在它所“受雇”的特定岗位上是否表现出色。下表总结了大模型应用评测和传统软件测试、大模型基准测试有何区别：

为什么要进行大模型应用评测

无法评估，就无法管理。

大模型的特性带来新的挑战

大模型独特的性质导致传统的软件测试已经无法全面评估相关产品的质量或用来定位系统的问题了。为了应对以下大模型所带来的特殊问题，评测必须存在：

非确定性输出：传统软件的输入与输出是固定的，而 LLM 对同一输入可能产生多种有效输出。因此评测的目标不再是验证唯一的正确答案，而是确保所有潜在输出都落在可接受的范围内。

结果质量定义的主观性：传统软件测试由工程团队负责；而LLM的输出，还需业务人员等非技术方评估；对于创意、摘要等生成式任务，也不存在唯一的“标准答案”。

独特的失败模式：LLM 带来的风险并非传统“bug”，而是需专门评估的特殊属性

• 幻觉：生成看似合理但与事实不符的信息。
• 偏见：学习并放大训练数据中的社会偏见。
• 提示敏感性：输入内容的微小变化可能会导致输出结果的质量剧烈波动。
• 提示注入和越狱：恶意用户可能通过精心设计的提示词，绕过模型的安全护栏，诱使其生成有害或被禁止的内容，或者泄露其训练数据或上下文中包含的个人隐私或商业机密

衡量产品是否成功

当我们需要说服非技术背景的业务人员参与评测，或者说服领导层支持评测，最核心的问题是：我们为什么要投入资源进行评测？

一个健全的评测体系能够清晰地将抽象的指标与具体的业务成果联系起来。通过评测可以回答以下关键问题：

• 当前产品是否能满足我们定义给它的特定任务和需求，满足到什么程度？
• 用户使用情况是否符合预期？用户满意度如何？
• 产品或系统运行的怎么样？能够应对状况之外的场景或问题吗？能覆盖边缘和风险情况吗？

定位问题快速迭代

如果没有良好的评估体系，团队很容易陷入“原地打转”的困境，不断地进行修改，却无法确定这些修改是否真正提升了产品性能。

评估体系为每一次迭代提供了必要的“量化反馈”，验证了关于改进的假设是否成立，并确保了团队在正确的方向上前进，形成“构建-部署-评估-记录-迭代”组成的快速、可验证的循环。

不同岗位人员的分工

产品经理

产品经理是评测的发起者和需求的源头。

1）评测设计阶段：

• 定义业务目标与指标：明确本次评测要验证的假设是什么（如：AI客服能否将用户满意度从80%提升到90%？）。
• 定义用户场景：描述用户会在什么情境下使用这个功能，他们的核心诉求是什么。这是构建评测集的基础。
• 定义“可接受”的质量门槛：与团队一起决定，例如，“幻觉率低于5%”或“答案采纳率达到70%”才能上线。
• 定义主观指标：对于“风格”、“趣味性”等主观指标，给出明确的定义和判断标准。

2）结果分析与决策阶段：

• 解读业务价值：从用户和商业视角解读评测报告，判断当前版本是否达到上线标准。
• 做出决策：根据评测结果，决定下一步的行动：是上线发布、继续优化还是调整方向？
• 划分优先级：如果评测暴露出多个问题，由产品经理决定优先修复哪些问题（如：“事实错误”的优先级高于“语气生硬”）

业务/领域专家

业务专家是评测质量的基石，尤其在专业领域（如医疗、金融、法律）。

1）评测设计阶段：

• 提供高质量的评测数据：编写或审核评测用的问题和“标准答案”。
• 定义领域内的“红线”：指出哪些是绝对不能出错的专业常识或合规要求。例如，在医疗领域，绝对不能推荐错误的药品剂量。
• 识别“陷阱”问题：设计能够暴露模型深层次问题的边缘案例。

2）评测执行阶段：

• 进行人工评测：对模型生成的专业内容进行打分和标注，判断其准确性、专业性和可靠性。专家的标注是评测中最宝贵的“黄金数据”。
• 提供定性反馈：不仅给出“对/错”的结论，还要解释“为什么错”，为产品优化提供方向。

开发人员

开发人员是评测的技术支撑和执行主体。

1）评测设计与准备阶段：

• 构建评测工具与平台：开发自动化评测流水线、人工标注平台、结果可视化看板等。
• 提供技术指标建议：建议使用哪些技术指标（如精确率、召回率、BLEU、ROUGE）来衡量特定任务。
• 实现评测逻辑：将产品和业务定义的指标，通过代码实现为可执行的评测脚本。

2）评测执行与分析阶段：

• 执行自动化评测：运行评测脚本，获取模型在各项技术指标上的表现。
• 分析技术根因：深入分析badcase，从模型、算法、数据、提示词等技术层面定位问题根源。

3）迭代优化阶段：

• 修复问题：根据分析结果，进行优化操作。
• 模型选型：评测和比较不同基础模型或API，为技术选型提供数据支持。

测试人员

测试人员的角色从传统的功能测试，演变为AI质量保障的组织者和度量者。

1）评测设计阶段：

• 设计评测方案与流程：制定详细的评测计划，明确评测范围、方法、资源和时间表，确保评测过程的科学性和一致性。
• 管理评测数据集：负责评测集的创建、版本控制、维护和扩充，保证评测标准的一致性。
• 设计评测用例：专注于发现边界条件、鲁棒性问题和潜在的安全漏洞。

2）评测执行与管理阶段：

• 组织和协调评测活动：无论是自动化测试的执行，还是协调业务专家进行人工评测，都由测试人员来组织和推进。
• 聚合与呈现结果：收集所有自动化和人工评测的数据，进行汇总分析，并生成多维度的质量报告或看板。
• 执行回归测试：在开发人员修复问题后，进行回归评测，确保旧的问题已解决且未引入新问题。