大模型的风口已至，但评估却始终是一道“看不清又绕不过”的门槛。本篇文章将从基础概念出发，手把手引导初学者理解大模型评估的核心逻辑与方法体系，厘清技术指标背后的实际含义，为后续深入探索打下坚实的认知地基。
OpenAI的首席产品官（CPO）Kevin Weil在一次播客访谈中提到：“编写评估将成为AI产品经理的一项核心技能。这是用AI打造优秀产品的关键一环”
Anthropic的CPO Mike Krieger在与Weil的对谈中同样强调，产品领导者必须开发出色的评估指标，以准确衡量AI模型的能力和产品的成功 。
这些观点将“大模型评估”的地位从一个单纯的测试环节，提升到了与产品管理、用户体验设计同等重要的战略高度。
基于这样的背景，本文专为所有从事大语言模型（LLM）相关产品工作的从业人员（从产品经理到开发和测试人员）而写，旨在提供一份清晰易懂的“LLM评估入门指南”。
这篇文章将用通俗易懂的方式，讲解评估LLM应用的基础知识。只要你对如何在产品中应用LLM有基本了解，就能轻松上手。
本文涵盖以下内容：
我们将聚焦于评估的核心原则与工作流程。所谓LLM评估（evals），就是评价模型的性能，确保其输出结果准确、安全，并能满足用户需求。
在具体方法上，评估可以由领域专家或审核员人工进行，也可以自动化进行。
自动化评估又分为两类：
一类是有参考评估，在实验或测试中，将模型输出与标准答案进行比对；
另一类是无参考评估，直接评价输出内容的质量，常用于生产环境的监控和安全防护。在众多方法中，“LLM作评判”（LLM-as-a-judge）是目前非常流行的一种。
在深入探讨评估之前，先明确一下评估的对象。
LLM产品，或称LLM应用，是指将大语言模型（LLM）作为其核心功能一部分的产品。
这些产品形态各异，既可以是面向用户的客服聊天机器人，也可以是公司内部使用的营销文案生成器。 可以将LLM功能嵌入现有软件，比如让用户通过自然语言查询数据；也可以完全围绕LLM打造一个全新的应用，比如对话式AI助手。
以下是一些实际案例：
这些应用都依赖于LLM，LLM本身是基于海量数据训练出的模型，能通过指令提示（Prompt）处理各种任务，如内容创作、信息提取、代码生成、翻译或进行完整对话。
有些任务，比如生成一句产品描述，可能一个提示就足够了。但大多数LLM应用会更复杂。可能会将多个提示串联起来，形成一个“提示链（prompt chain）”，例如在一个写作助手中，先生成文案，再调整风格。
检索增强生成（RAG） 是一种非常流行的LLM应用类型。这个名字听起来复杂，但概念很简单：将LLM与搜索技术相结合。当用户提问时，系统首先检索相关资料，然后将问题和这些资料一并交给LLM，从而生成更精准的答案。例如，一个基于RAG的客服机器人可以从帮助中心数据库里查找信息，并在回复中附上相关文章的链接。
此外，还可以创建LLM驱动的智能代理（Agent），让它自动化处理需要按步骤推理的复杂工作流，比如修改代码、规划并预订一次旅行。智能代理不仅能生成文本，还能使用提供的工具，例如查询数据库或发送会议邀请。一个复杂的代理系统可能涉及多步规划、数十个提示以及用于追踪进度的“记忆”功能。
在开发这些LLM应用的过程中， 我们总会问自己：
要回答这些问题，就需要进行LLM评估。
LLM评估（简称“evals”）旨在评价大语言模型的性能，确保其输出结果准确、安全，并符合用户需求。
这个术语通常用于两种不同的情境：
尽管两种评估在方法上有所重叠，但它们的本质截然不同。
直接评估大模型时，我们关注的是它的“原始”能力，比如编码、翻译或解数学题。研究人员通常使用标准化的基准测试（Benchmark） 来完成这项工作。例如，他们可能会评估：
目前已有数百个LLM基准，每个都有自己独特的测试集。大多数基准包含有标准答案的问题，评估过程就是看模型的回答与标准答案的匹配度。有些基准则采用更复杂的方法，比如通过众包对模型的回答进行排序。
LLM基准可以直观地比较不同模型。许多公开的排行榜会展示各个LLM在基准上的表现，帮助回答“哪个开源LLM更擅长编码？”这类问题。
尽管LLM基准在选型和追踪行业进展时很有用，但它们并不太适合用来评估一个具体的应用。
因为基准测试的是通用能力，而不是应用需要处理的特定场景。同时，它们只关注LLM本身，而一个完整的产品还包含其他部分。
LLM产品评估，评估的是整个系统在其特定任务上的表现。
这不仅包括LLM，还包括所有其他部分：提示、将它们连接起来的逻辑、用于增强回答效果的知识库等等。 还可以在更贴近真实场景的数据上进行测试，比如使用真实的客户支持问题。
这类应用层面的评估通常关注两大方面：
具体的评估标准因应用场景而异。“好”与“坏”的定义取决于具体用途。比如要开发一个问答系统， 可能需要评估：
在安全方面， 可能需要测试问答系统是否会产生有偏见或有害的输出，以及在受到诱导时是否会泄露敏感数据。
在设计评估方案时， 需要根据应用的目标、风险和已发现的错误类型来确定评估标准。 这些评估应该能真正帮助我们做决策，比如：新的提示效果更好吗？应用可以上线了吗？
以“流畅性”或“连贯性”这类标准为例，大多数现代LLM在生成通顺自然的文本方面已经做得很好。一个完美的流畅性得分在报告上可能很好看，但并不能提供太多有效信息。
不过如果使用的是一个能力较弱的小型本地模型，那么测试流畅性可能就很有必要。
即使是评估标准也并非放之四海而皆准。在多数情况下，事实准确性至关重要。但如果开发的是一个用于头脑风暴、构思营销创意的工具，那么“天马行空”或许正是用户想要的。在这种情况下， 我们更关心的可能是输出的多样性和创造力，而不是事实准确性。
这就是LLM产品评估与基准测试的核心区别。基准测试像学校考试，衡量的是通用技能；而LLM产品评估更像是工作绩效考核，检验的是系统在它所“受雇”的特定岗位上是否表现出色。
核心要点：每个LLM应用都需要一套量身定制的评估框架。
评估标准既要有用（关注真正重要的问题），又要有区分度（能有效反映不同版本间的性能差异）。
LLM评估之所以复杂，不仅因为质量标准是定制的，还因为其评估方法本身就不同于传统的软件测试和机器学习。
1）输出的非确定性：LLM的输出是概率性的，这意味着对于同一个输入，它每次可能给出不同的回答。这虽然带来了创造性和多样性，但也让测试变得复杂：必须检查一系列可能的输出是否都符合预期。
2）没有唯一的标准答案：传统的机器学习系统（如分类器、推荐系统）处理的是预定义好的输出。例如，一封邮件要么是垃圾邮件，要么不是。但LLM通常处理的是开放式任务，比如写邮件或进行对话，这些任务存在多个合理的答案。例如，写一封好邮件的方式有无数种。这意味着不能简单地将模型输出与某个参考答案进行精确匹配，而是需要评估模糊的相似性或主观质量，如风格、语气和安全性。
3）输入范围极其广泛：LLM产品通常要应对各种各样的用户输入。例如，一个客服机器人可能要回答关于产品、退货的咨询，或帮助解决账户问题。需要基于不同场景进行测试，才能覆盖所有预期的输入。如何创建一个高质量的评估数据集本身就是一个不小的挑战。
4）线上线下表现不一：更重要的是，在测试中表现良好的系统，在实际应用中不一定同样出色。真实用户可能会向系统抛出各种意想不到的输入，完全超出计划。为了应对这种情况，需要有办法在生产环境中观察和评估线上质量。
5）独特的风险：使用这种基于自然语言指令的概率性系统，会带来一些新型的风险，包括：
需要一个完善的评估流程来应对所有这些挑战：对系统进行压力测试，发现其弱点，并监控其实际表现。
LLM评估通常发生在两个关键阶段：部署前和发布后。
在开发阶段， 需要检验应用在迭代过程中是否足够好。一旦上线， 就需要监控它的实际运行情况。无论哪个阶段，评估都始于数据。
无论是在测试还是生产环境， 都可以选择人工评估和自动评估。
最开始， 我们可以做一些简单的“直觉检查”，问自己：“这些回答看起来对吗？”
在创建第一个版本的提示或RAG系统后， 可以输入几个样本问题，然后肉眼检查回答。如果结果偏差太大，就调整提示或修改方法。即使在这个非正式的阶段， 也需要准备一些测试用例。例如，为客服机器人准备几个有标准答案的示例问题。每次做出修改后，都重新评估系统处理这些问题的效果。
虽然这种方法能帮我们快速发现问题并激发新的想法，但它并不可靠，也无法重复。随着开发的深入， 需要更有条理的方法——包括一致的评分标准和详细的结果记录。
一种更严谨地利用人类专业知识的方法是标注（Annotation）：建立一个正式的工作流程，让测试人员根据预设的指南来评估回答。
他们可以给出“通过/失败”这样的二元标签，也可以评估特定维度，比如检索到的上下文是否“相关”，或回答是否“安全”。 还可以要求审核员简要说明他们的判断依据。
为了让标注过程高效且一致， 必须提供清晰的指南，例如要求测试人员专门寻找某些类型的错误。 也可以让多个人评估同一个样本，以发现和解决意见分歧。
人工评估是判断LLM应用是否正常工作的最可靠的方法。作为产品构建者， 最清楚在应用场景中，“成功”意味着什么。在医疗等高度专业化的领域， 可能还需要引入领域专家来辅助判断。
尽管人工评估价值巨大，但成本高。 不可能每次修改提示都去人工审查成千上万个输出。要实现规模化就需要自动化。
自动化评估主要分为两种类型：
有标准答案的评估
这类评估依赖于预先定义好的正确答案——通常被称为“参考答案”、“基准答案（ground truth）”或“黄金答案（golden）”。
例如，在一个客服系统中，对于问题“ 们的退货政策是什么？”，参考答案可能是“您可以在30天内退货。” 可以将聊天机器人的实际输出与这个已知答案进行比较，以评估其正确性。
这类评估本质上是离线的。 通常在迭代应用或将新版本部署到生产环境之前运行这些测试。
要使用此方法， 首先需要一个评估数据集：一个包含样本输入及其对应标准答案的集合。 可以自己生成这样的数据集，也可以从历史日志中整理，比如使用人工客服过去的回答。这些用例越能反映真实世界， 的评估就越可靠。
数据集准备好后，自动化评估的流程如下：
这里的难点在于第三步：如何比较回答与参考答案？
精确匹配：看新回答是否与参考答案一字不差。但通常过于严格，在开放式场景中，不同的措辞可以表达相同的意思。
为了解决这个问题， 可以使用其他方法，比如量化两个回答之间的词语重叠度，使用嵌入（embedding）来比较语义，甚至可以请求另一个LLM来判断它们是否匹配。
以下是一些常见的匹配方法：
在判断单个回答的正确性后， 就可以分析系统在整个测试集上的整体表现了。
如果 LLM被用于预测任务，则可以使用经典的机器学习质量指标。
然而，并非所有场景都有标准答案。对于复杂、开放式的任务或多轮对话，很难定义一个唯一的“正确”回答。在生产环境中，更没有完美的参考答案： 评估的是实时传入的未知输出。
此时， 可以进行无参考的LLM评估。它们不将输出与固定答案比较，而是直接评估输出的特定质量，如结构、语气或含义。
一种方法是使用LLM作为评判者（LLM-as-a-Judge），即利用另一个语言模型，根据一套规则来为输出打分。例如，LLM评判者可以评估聊天机器人的回答是否完整，或者输出的语气是否一致。
但这也不是唯一的选择，以下是一些常见方法：
这些无参考的评估方法既可以在迭代开发期间使用（例如，优化输出的语气或格式时），也可以用于监控生产环境的性能。
虽然在这种情况下无需标注标准答案，但仍需做一些前期工作，重点在于：
总而言之，所有LLM评估都遵循相似的结构：
1.明确构建的目标或任务。
2.根据特定标准/指标评估输出。
3.收集和创建评估数据集（测试或生产数据）。
4.决定评估方法（人工、自动或混合）。
以下是LLM产品生命周期中的一些常见评估场景：
（为AI产品选择最佳的模型、提示或配置。）
项目刚开始时，第一步通常是进行模型对比。 可以查看排行榜，挑选几个候选LLM，并用真实数据测试它们。另一个常见的比较任务是找到最佳提示（Prompt Engineering）。
“用简单的话解释”和“写一个总结摘要”，哪个效果更好？
如果把任务分解成多个步骤，效果会怎样？
如果在提示里加入一些期望风格的例子呢？
微小的调整往往会带来巨大的差异，因此在数据集上系统地测试每个版本至关重要。
每次更改都是一个新的实验， 需要LLM评估来比较它们的结果。这意味着我们需要一个精心策划的测试数据集和自动化的性能衡量方法。
可以同时使用有参考的评估方法（如与理想摘要比较）和无参考的评估方法（如检查所有输出是否遵循设定格式）。
在尝试复杂方案之前，先试试简单的方法，这为评估提供了一个明确的衡量进展的起点。
（通过评估产品在各种场景下的表现，检查它是否为实际使用做好了准备。）
当模型和提示策略基本确定后，就该进行更彻底的测试了。 我们构建的系统可能在十几个测试用例上运行良好，但几百个、几千个呢？
这意味着要添加更多的测试用例，既要覆盖常见的场景，也要考察系统如何处理更棘手的边缘情况（Edge Cases）。
如果输入只有一个词怎么办？如果太长了呢？
如果是另一种语言或错别字呢？
系统如何处理它不应涉及的敏感话题？
设计这些测试需要深入了解用户如何与产品互动。最终， 为每个主题或场景都建立一套评估方案。
从技术上讲，压力测试与对比实验没有太大区别。
区别在于重点： 不是在探索哪个选项更好，而是在检查当前版本的产品是否足够健壮，能否应对用户可能抛出的各种问题。
（测试系统如何响应对抗性行为或恶意使用。）
红队测试是一种模拟攻击的测试技术，例如通过提示注入（Prompt Injection）等方式，发现系统中的漏洞。这是评估高风险应用安全性的关键步骤。
压力测试关注的是有挑战性但合理的场景，而红队测试则专门针对滥用。它寻找的是恶意行为者可能利用系统、将其推向不安全或意外行为（如提供有害建议）的方法。
例如，对于一个医疗聊天机器人，测试它如何安全地处理医疗问题属于其核心功能范围。但对于一个通用的问答机器人，医疗、金融或法律问题就超出了其预期用途，可被视为对抗性输入。
红队测试可以手动进行，也可以通过合成数据和有针对性的提示来自动化地模拟各种风险。
（了解系统的实时性能，以便检测和解决问题。）
离线评估终究有限，当产品面向真实用户后， 需要了解它在实际使用中的表现。这就引出了生产环境可观察性（Observability）。
一旦产品上线， 就需要追踪其性能。
用户体验好吗？回答是否准确、安全？
可以从追踪用户行为开始，比如收集点击率或点赞/点踩等反馈。
但要获得更深入的洞察， 需要追踪用户提出的问题以及系统如何响应。这就需要收集跟踪记录所有交互的详细日志。
有了这些日志， 就可以通过在线评估来评价生产环境中的质量。 可以使用无参考的评估方法（如LLM作评判、专用模型或正则表达式）自动处理每个新输出，看它们在特定标准下得分如何。
还可以通过A/B测试来检验改动效果。例如，将新提示部署给10%的用户，并比较性能指标，看它是否提升了质量。
（测试新的改动是否在改进系统的同时，没有破坏以前正常工作的功能。）
即使产品已经上线， 仍然需要离线评估来运行回归测试。它能验证所做的更改没有引入新的（或旧的）问题。
修复一个问题后，会不会影响其他功能？
微调一个提示后，有多少以前的输出会改变？这些改变是好是坏？
系统化的回归测试可以让我们更安全地在现有系统之上进行迭代，确保在做出改进的同时，没有引入新的问题。
（在运行时检查，检测LLM输入或输出中的质量问题。）
大模型驱动的产品，在输入和输出的过程中，有时需要立即发现危险的信息并过滤或阻拦。这些实时的验证被称为安全护栏（Guardrails），充当系统响应和用户之间的安全网。
从内部看，这些检查与无参考评估相同，但它们被直接内置到应用中并实时运行。例如， 可以检查：
当检测到问题时，系统可以阻止响应并显示一条回退消息（如“抱歉，我无法提供帮助”），或者采取补救措施，比如删除敏感数据。
由于额外的处理会引入延迟，安全护栏通常只用于最关键的风险，如阻止有害内容或识别敏感信息。
好消息是：AI还没有完全接管一切。即使是基于LLM的产品， 仍然需要人类来管理质量，需要人类设计和维护一个自动化的评估系统。
坏消息是：LLM评估并不简单。每个应用都需要根据其具体用途、针对性的风险和潜在的失败模式，来定制一套评估方法。
从最初的产品构思到生产环境的维护， 在每个阶段都需要评估。
这些工作流程环环相扣：
自动化评估和人工评估相辅相成。虽然人工标注能提供最明确的信号，但自动化评估有助于规模化地复制和应用这些洞察。
所有这些评估工作不仅仅是为了计算指标，更是为了：
一个可靠的LLM评估流程还有一个额外的好处：它会自然而然地促使我们收集高质量的标注数据。未来可以用这些数据来进一步优化系统，比如用更小的模型替代大模型，优化生产提示，甚至微调核心模型。
本文由 @Mrs.Data 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Pexels，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。