生成型AI应用的质量为何常常不尽人意，以及如何改进
2025年，图片来源：elements.envato.com，Marcel Müller 编辑
过去两年，生成型AI的热潮席卷了商业世界。这项技术可以提高业务流程的执行效率，减少等待时间，降低过程缺陷。像ChatGPT这样的接口使得与大型语言模型（LLM）的互动变得简单而易于接触。任何有聊天应用使用经验的人都可以轻松输入查询，ChatGPT总能生成回答。然而，生成内容的质量和适用性可能会有所不同，特别是对于那些希望在其业务运营中使用生成型AI技术的企业而言。
我与无数管理者和企业家交谈过，他们因为无法将高质量的生成型AI应用投入生产，未能从一个非确定性模型中获得可重用的结果而失败。另一方面，我也开发了三十多种AI应用，意识到一个常见的误解：当人们思考生成型AI应用的质量时，他们认为这完全取决于底层模型的强大，但这只是全貌的30%。
然而，有许多技术、模式和架构可以帮助创建符合企业需求的高质量LLM应用。不同的基础模型、精调模型、带有检索增强生成（RAG）的架构以及先进的处理管道只是冰山一角。
本文将展示如何在具体的业务流程中，定性和定量地评估生成型AI应用。我们将不仅停留在通用基准上，还会介绍评估生成型AI应用的方法。在快速分析生成型AI应用及其业务流程之后，我们将探讨以下问题： • 在什么样的背景下，我们需要评估生成型AI应用，以评估它们在企业应用中的端到端质量和效用？ • 在生成型AI应用的开发生命周期中，我们何时使用不同的评估方法？它们的目标是什么？ • 我们如何在隔离和生产中使用不同的指标来选择、监控和改进生成型AI应用的质量？
这篇概述将为我们提供一个端到端的评估框架，适用于企业场景中的生成型AI应用，我称之为PEEL（企业LLM应用的性能评估）。基于本文创建的概念框架，我们还将介绍作为entAIngine平台模块的一部分的实施概念。
- 背景：业务流程与生成型AI
一个组织依赖于其业务流程。公司里的每一项工作都可以是业务流程，如客户支持、软件开发和运营流程。生成型AI可以通过加速和提高业务流程的效率，减少等待时间并提高流程结果的质量，来改善我们的业务流程。然而，我们还可以进一步将每个使用生成型AI的流程活动进行细分。
生成型AI应用的流程。© 2025，Marcel Müller
插图展示了一家电信公司客户支持代理必须经过的一个简单业务流程。每当有新的客户支持请求时，客户支持代理需要给它分配优先级。当他们的工作清单中的任务达到需要处理该请求的优先级时，客户支持代理必须找到正确的答案并撰写答复邮件。随后，他们需要将邮件发送给客户并等待回复，直到请求解决为止。
我们可以使用生成型AI工作流来提高“查找和写作答案”这一活动的效率。然而，这个活动通常不是单纯的调用ChatGPT或其他LLM，而是一系列不同的任务。在我们的例子中，电信公司使用了entAIngine流程平台构建了一个管道，其中包括以下步骤： • 提取问题并生成对向量数据库的查询。该公司有一个向量数据库作为检索增强生成（RAG）的知识库。我们需要从客户的请求邮件中提取问题的精髓，以生成最佳查询并找到语义上最接近该问题的知识库部分。 • 在知识库中查找上下文。语义搜索活动是我们流程中的下一步。检索排序结构常用于获取与查询相关的前k个上下文块，并使用LLM进行排序。此步骤的目的是检索正确的上下文信息，以生成最佳答案。 • 使用上下文生成答案。这一步通过提示和选择的上下文作为输入来协调大型语言模型。 • 撰写答复邮件。最后一步将预先编写的答案转化为正式的邮件，并以公司所需的语气和复杂性格式化邮件的开头和结尾。
像这样的流程执行称为高级LLM工作流的协调。在企业环境中，还有许多其他的协调架构。使用一个使用当前提示和聊天历史的聊天界面也是一种简单的协调方式。然而，对于需要使用敏感公司数据的可重现的企业工作流，单纯使用简单的聊天协调在许多情况下是远远不够的，因此需要像上述所展示的那样的高级工作流。
因此，当我们评估企业场景中的生成型AI协调过程时，仅仅看基础（或精调）模型的能力，在许多情况下只是开始。接下来的部分将深入探讨我们需要评估生成型AI应用的上下文和协调方式。
- 概念
以下部分介绍了我们方法的核心概念。
我的团队构建了entAIngine平台，这个平台在某种意义上是独特的，因为它允许低代码生成包含生成型AI任务的应用，这些任务不一定是聊天机器人应用。我们还在entAIngine上实施了以下方法。如果你想试试，给我发消息，或者，如果你想构建自己的测试床功能，可以从以下概念中获取灵感。
2.1 性能评估的上下文和协调
当评估生成型AI应用在其协调过程中的性能时，我们有以下选择：我们可以孤立评估基础模型、精调模型，或将其中任意一个作为更大协调的一部分进行评估，其中包括对不同模型和RAG的多次调用。这将产生以下影响。
生成型AI应用的上下文和协调。© Marcel Müller，2025
公开可用的生成型AI模型（如GPT-4、Llama 3.2等）是通过训练“互联网的公共智慧”而成的。它们的训练集包含了大量来自书籍、世界文学、维基百科文章以及其他互联网爬虫（如论坛和博客文章）的知识。因此，当我们评估基础模型的能力时，只能评估它们如何回答查询的总体能力。然而，无法评估公司特定的知识库，这些知识库展示了“模型了解多少”。只有在基础模型使用高级协调插入公司特定的上下文时，才能体现公司特定的知识。
例如，任何人都可以使用ChatGPT的免费账户询问“歌德是如何死的？”模型会给出答案，因为关于歌德生死的关键信息已经包含在模型的知识库中。然而，问题“我们公司去年在EMEA地区Q3的收入是多少？”很可能会导致一个高度虚构的答案，尽管对不经验丰富的用户而言看起来似乎有道理。然而，我们仍然可以评估答案的形式和表现，包括风格和语气，以及语言能力和推理与逻辑推导的能力。合成基准如ARC、HellaSwag和MMLU提供了这些维度的比较度量，我们将在后续部分深入探讨这些基准。
精调模型是建立在基础模型之上的。它们使用额外的数据集，通过进一步训练底层机器学习模型，向模型中添加基础知识。精调模型具有更多特定领域的知识。如果我们孤立地协调它们而不使用其他数据，便可以根据其在给定业务流程中对现实场景的适用性来评估它们的知识库。精调常用于向基础模型中添加特定领域的词汇和句子结构。
例如，如果我们在法律判决的语料库上训练一个模型，那么精调后的模型将开始使用法律领域中常见的词汇和句子结构，尽管该模型可能会结合一些旧案件的摘录，但却未能引用正确的来源。
通过检索增强生成（RAG）协调基础模型或精调模型，会产生高度依赖上下文的结果。然而，这也需要更复杂的协调管道。
例如，像我们上面提到的电信公司，可以使用语言模型为其客户支持知识库创建嵌入，并将其存储在向量存储中。现在，我们可以通过语义搜索高效地查询这个向量存储中的知识库。通过跟踪所检索的文本段落，我们可以非常精确地显示检索文本块的来源，并将其作为上下文传递给大型语言模型进行调用。这使我们能够端到端地回答问题。
我们可以通过不同的数据处理管道步骤来评估我们的应用是否在端到端上有效地服务于其预期目的。
2.2 生成型AI应用在开发生命周期中的评估
我们在不同阶段开发生成型AI应用：1）构建前，2）构建和测试过程中，3）生产中。使用敏捷方法，这些阶段并非线性执行，而是迭代进行。然而，尽管其顺序不同，不同阶段的评估目标和方法是相同的。
在构建前，我们需要评估选择哪个基础模型，或是否从头开始构建一个新的模型。因此，我们必须首先定义我们的期望和需求，尤其是关于执行时间、效率、价格和质量的需求。目前，由于成本和更新的努力，只有极少数公司决定从零开始构建自己的基础模型。精调和检索增强生成是构建高度个性化管道并实现可追溯内部知识、输出可重复的标准工具。在此阶段，合成基准是实现可比性的首选方法。例如，如果我们想构建一个帮助律师准备案件的应用，我们需要一个擅长逻辑论证和理解特定语言的模型。
在构建过程中，我们的评估需要聚焦于满足应用示例案例的质量和性能要求。对于构建律师应用的情况，我们需要选择有限的旧案例，这些案例是定义应用标准场景的基础，基于这些场景来实现应用。例如，如果律师专攻金融法和税收，我们将选择一些标准案例，让律师为其创建场景。在这个阶段的每一项构建和评估活动都有一个有限的代表性视角，并不涵盖所有实例。然而，我们需要在应用开发的持续步骤中评估这些场景。
在生产阶段，我们的评估方法专注于定量评估应用在真实用户期望下的实际使用情况。在生产环境中，我们会发现一些未涵盖的场景。这个阶段的评估目标是发现这些场景并收集实时用户的反馈，以进一步改进应用。
生产阶段应始终反馈到开发阶段，以便迭代改进应用。因此，这三个阶段并非线性顺序，而是交替进行。
2.3 基准指标评估
在明确了“做什么”和“何时做”之后，我们还需要问“怎么做”来评估我们的生成型AI应用。因此，我们有三种不同的方法：合成基准、有限场景和生产中的反馈循环评估。
对于合成基准，我们将查看最常用的方法并进行比较。
AI2推理挑战（ARC）通过一个包含7787个多项选择科学问题的数据集来测试LLM的知识和推理能力。这些问题的难度从3年级到9年级不等，分为容易和挑战两个级别。ARC对于评估多种类型的知识并推动模型整合来自多句话的信息非常有用。它的主要优势在于全面的推理评估，但局限于科学问题。
HellaSwag通过基于现实场景的句子完成练习来测试常识推理和自然语言推断。每个练习包括一个视频标题上下文和四个可能的结尾。这个基准测试了LLM对日常场景的理解。它的主要优点是通过对抗性过滤增加了复杂性，但它主要关注常识知识，限制了专门领域的测试。
MMLU（大规模多任务语言理解）基准测试了LLM在57项任务中的自然语言理解能力，涵盖从STEM到人文学科的各种主题。它包含了15,908个问题，涵盖从初级到高级的多个难度级别。MMLU非常适合全面的知识评估。它的广泛覆盖有助于识别缺陷，但有限的构建细节和错误可能影响其可靠性。
TruthfulQA评估LLM生成真实答案的能力，解决语言模型中的幻觉问题。它测量LLM的准确性，尤其是在训练数据不足或质量较低的情况下。这一基准对于评估准确性和真实性非常有用，尤其是在关注事实正确性时。然而，它的常识数据集可能无法反映专业领域中的真实性。
RAGAS框架设计用于评估检索增强生成（RAG）管道。它特别适用于利用外部数据来增强LLM上下文的LLM应用。该框架引入了忠诚度、答案相关性、上下文召回率、上下文精度、上下文相关性、上下文实体召回率和总结得分等度量指标，可以从多维度评估检索输出的质量。
WinoGrande通过基于Winograd Schema Challenge的代词解析问题测试LLM的常识推理能力。它通过触发词呈现几乎相同的句子，并给出不同的答案。该基准有助于解决代词引用中的歧义问题，数据集庞大且偏见较小，但注释中的伪造仍然是一个限制。
GSM8K基准通过大约8,500个小学生级别的数学问题来测试LLM的多步数学推理能力。每个问题需要多步运算，包括基本的算术运算。该基准突显了数学推理的弱点，涵盖了多种问题表述。然而，问题的简单性可能限制其长期相关性。
SuperGLUE通过测试LLM在8个子任务中的自然语言理解能力来增强GLUE基准，其中包括布尔问题和Winograd Schema Challenge。它提供了对语言学和常识知识的全面评估。SuperGLUE适合广泛的NLU评估，综合任务提供了详细的见解。然而，与类似MMLU的基准相比，测试的模型较少。
HumanEval通过编码挑战和单元测试来衡量LLM生成功能正确代码的能力。它包含了164个编码问题，每个问题有多个单元测试。该基准评估编码和问题解决能力，专注于与人工评估类似的功能正确性。然而，它只涵盖了一些实际编码任务，限制了其全面性。
MT-Bench通过模拟现实对话场景来评估LLM在多轮对话中的能力。它衡量了聊天机器人在对话中的互动效果，遵循自然的对话流程。MT-Bench的数据集经过精心策划，非常适合评估对话能力。然而，其数据集较小，模拟真实对话的挑战仍需要改进。
所有这些指标都是合成的，旨在提供不同LLM之间的相对比较。然而，它们在公司用例中的具体影响取决于挑战在场景中的分类与基准的匹配。例如，在需要大量数学计算的税务会计用例中，GSM8K将是一个很好的评估能力的选择。HumanEval是用于LLM在编码相关场景中的初始工具。
2.4 基于现实场景的评估
然而，这些基准的影响较为抽象，仅能指示它们在企业用例中的表现。因此，实际工作中需要使用现实场景。
现实场景包含以下成分： • 案例特定的上下文数据（输入）， • 与案例无关的上下文数据， • 完成的任务序列， • 预期输出。
通过现实测试场景，我们可以模拟不同的情况，如： • 多步聊天互动，包括多个问题和答案， • 复杂的自动化任务，涉及多次AI互动， • 涉及RAG的流程， • 多模态的过程互动。
换句话说，如果RAG管道因为分块策略不当始终返回平庸的结果，那么拥有世界上最强大的模型也没有用。同样，如果你没有正确的数据来回答查询，你总会得到一些虚假的答案，这些答案或许接近真相，也或许并非如此。
PEEL框架中引入的评估场景概念 © Marcel Müller
评估场景定义包括输入定义、协调定义和预期输出定义。
对于输入，我们区分了特定案例和独立于案例的上下文数据。特定案例的上下文数据在不同案例之间是不同的。例如，在客户支持的用例中，客户提出的问题会因客户不同而有所不同。在我们的示例评估执行中，我们展示了一个案例，其中电子邮件询问内容如下：
“亲爱的客户支持，
我的名字是[…]。我搬到不同的公寓时，如何重置我的路由器？
此致，[…]”
然而，答案所在的知识库（涉及大量文档）是与案例无关的。在我们的示例中，我们有一个知识库，其中存储了路由器AR83、AR93、AR94和BD77的PDF手册，并将其存储在向量存储中。
评估场景定义包括一个协调。协调由一系列n >= 1的步骤组成，这些步骤在评估场景执行中按顺序执行。每个步骤都有输入，输入来自前一个步骤或场景执行的输入。步骤可以是与LLM（或其他模型）的交互、上下文检索任务（例如，从向量数据库中检索）或对其他数据源的调用。对于每个步骤，我们区分提示/请求和执行参数。执行参数包括需要执行的模型或方法和超参数。提示/请求是多个静态或动态数据的集合，这些数据会被串联在一起（见插图）。
在我们的示例中，我们有一个三步的协调。在步骤1中，我们从特定案例的输入上下文（客户的电子邮件询问）中提取一个问题。我们在步骤2中使用这个问题，通过余弦相似度度量，在我们的向量数据库中创建一个语义搜索查询。最后一步将检索结果并使用LLM编写电子邮件。
在评估场景定义中，我们有预期输出和评估方法。在这里，我们为每个场景定义如何评估实际结果与预期结果的差异。我们有以下选项：
• 精确匹配/正则匹配：我们检查特定术语/概念的出现，并给出布尔值，0表示定义的术语没有出现在执行的输出中，1表示它们出现在了输出中。例如，安装路由器到新位置的核心概念是按住重置按钮3秒钟。如果答案中没有出现“重置按钮”和“3秒钟”这些术语，我们就会评估为失败。
• 语义匹配：我们检查文本是否与预期答案语义上接近。因此，我们使用LLM并让其以0到1之间的理性数值判断答案与预期答案的匹配程度。
• 人工匹配：人类在0到1的范围内评估输出。
评估场景应该执行多次，因为LLM是非确定性模型。我们希望执行合理次数的测试，以便我们能够聚合分数并得到具有统计意义的输出。
使用这些场景的好处是，我们可以在构建和调试协调过程时使用它们。当我们看到在100次相同提示的执行中有80次分数低于0.3时，我们可以使用这个输入来调整我们的提示或在协调之前添加其他数据来进行微调。
2.5 生产中的反馈收集与调整
在生产中收集反馈的原则与场景方法类似。我们将每个用户交互映射到一个场景。如果用户的交互自由度较大，我们可能需要创建一些在构建阶段未预料到的新场景。
用户可以通过滑块在0到1之间指示他们对结果输出的满意度。从用户体验的角度来看，这个数字也可以简化为不同的媒体，例如，笑脸、中性脸和难过的笑脸。这样，这个评估就是我们之前介绍的人工匹配方法。
在生产环境中，我们需要创建与之前相同的聚合和指标，只不过是使用真实用户和可能更多的数据。
- 作为entAIngine测试平台一部分的示例实现
与entAIngine团队一起，我们已经在平台上实现了这一功能。本节旨在展示如何实现这些功能，并为您提供灵感。或者，如果您想使用我们实现的内容，可以随时使用。
我们将评估场景和评估场景定义的概念映射到经典的软件测试概念中。创建新测试的起点是通过entAIngine应用程序仪表板。
entAIngine仪表板 © Marcel Müller
在entAIngine中，用户可以创建多种不同的应用程序。每个应用程序都是一组定义工作流的流程，这些流程使用无代码接口。流程由输入模板（变量）、RAG组件、LLM调用、TTS、图像和音频模块、文档集成和OCR组成。通过这些组件，我们构建可重复使用的流程，这些流程可以通过API集成、用作聊天流程、在文本编辑器中作为动态文本生成块使用，或在显示答案来源的知识管理搜索界面中使用。目前，这一功能已经在entAIngine平台上完全实现，并可以作为SaaS或100%部署在本地使用。它通过API与现有的网关、数据源和模型进行集成。我们将使用流程模板生成器来定义评估场景。
当用户想要创建一个新测试时，他们可以进入“测试平台”和“测试”界面。
在测试屏幕中，用户可以创建新的评估场景或编辑现有的评估场景。在创建新的评估场景时，必须定义协调（entAIngine流程模板）和一组度量标准。我们假设有一个客户支持场景，其中我们需要通过RAG来检索数据，以在第一步回答一个问题，然后在第二步编写答复邮件。接着，我们使用新模块来命名测试，定义/选择流程模板，并选择一个评估者来为每个单独的测试用例生成分数。
测试定义 © Marcel Müller，2025
测试用例（流程模板）定义 © Marcel Müller，2025
度量标准如上所述：正则匹配、语义匹配和人工匹配。流程定义的屏幕已经存在并且是功能齐全的，包括协调功能。下面显示的Bull中的测试定义功能是新的。
测试和测试用例 © Marcel Müller，2025
在测试编辑器中，我们处理一个评估场景定义（“评估我们客户支持的RAG回答有多好”），并在此场景中定义不同的测试用例。一个测试用例将数据值分配给测试中的变量。我们可以尝试50或100个不同的测试用例实例，进行评估并聚合它们。例如，如果我们评估客户支持的回答，我们可以定义100个不同的客户支持请求，定义我们预期的结果，然后执行它们并分析答案的质量。一旦我们设计好了一组测试用例，我们可以使用现有的协调引擎执行这些场景，并进行评估。
度量和评估 © Marcel Müller，2025
此测试发生在构建阶段。我们还有一个额外的屏幕，用于在生产阶段评估真实用户反馈。内容来自真实用户反馈（通过我们的引擎和API）。
实时反馈部分中可用的度量标准来自用户的星级评分。
结论：测试与质量
在本文中，我们探讨了生成型AI应用程序的高级测试和质量工程概念，尤其是那些比简单聊天机器人更复杂的应用程序。介绍的PEEL框架是一种基于场景的测试新方法，接近实现层面，比我们用来测试模型的通用基准更为精细。对于好的应用程序，重要的不仅是测试模型本身，而是要在协调中进行测试。
