如果你只是偶尔开车，可能不会对汽车有太高的要求。但如果你是一名职业司机，每天都在路上奔波，那么你一定会对汽车的性能、舒适性和可靠性有着极高的要求。同样，汽车制造商面对挑剔的职业司机用户，必须不遗余力地将汽车打磨到极致，因为任何细微的缺陷都可能导致客户流失。
大语言模型具备强大的推理能力和举一反三的本领，彻底改变了我们处理信息和解决问题的方式。但是通用大模型已经被巨头所垄断，对LLM系统开发者而言，真正的价值在于更出色、更高效地解决垂直领域的具体任务。
然而，这并非易事。大模型的能力与其不可预测性如同一辆性能强劲但难以掌控的汽车。开发者需要通过持续迭代和评估，在发挥模型智能性的同时，确保输出的稳定性和可预测性，将变数控制在可接受范围内。这就像打造一辆既性能卓越又易于操控的完美汽车。只有这样，才能在激烈的市场竞争中脱颖而出，成为用户的首选。
深入理解LLM系统评估
提到评估，很多人首先想到的是大语言模型的评估。然而，LLM的评估和基于LLM构建的系统或应用（以下简称LLM系统）的评估是完全不同的概念。LLM的评估主要关注模型本身的性能和能力，就像是测量一个人的智商水平；而对LLM系统的评估，更注重在垂直应用场景中解决实际问题的具体表现，以及使用者的主观体验，更像是评估一个专业人士在特定领域内的工作表现。
对于LLM系统或应用开发者来说，通常不需要在模型通用能力评估上投入太多精力，完全可以先从能力最强的模型开始，把更多精力投入到如何利用大模型的能力建立解决垂直领域任务的工作流。
LLM系统并不仅仅是简单的问答系统，而是由多个决策和执行步骤相互交织而成。以前，决策环节通常需要借助监督学习方式训练的分类模型，现在，也可以由大模型通过工具调用机制来实现；而执行环节，既可以通过大模型，也可以通过LLM结合外部知识，通过RAG（Retrieval-Augmented Generation）来实现，或者交由外部的RPA工作流完成，再由大模型进行汇总和二次生成。
这个过程中不断对提示语、模型和交互过程进行优化，对于复杂的系统，还可能会在不同任务环节中使用不同的模型，并且涉及到多个模型之间的分工与协同。更大的挑战在于如何利用模型构建出兼具智能性与可靠性的系统。
这个过程并非像拼插玩具那样简单，而是一个具有挑战性的复杂系统工程。通常来说，构建出一个表现出色的LLM系统要经过四个阶段：
- 原型搭建阶段 (Prototype Foundation)：提出设想，快速搭建原型并进行初步验证。
- 原型评估阶段 (End-to-End Evaluation)：设定目标、确定评估标准、准备评估样本、运行端到端评估并分析结果。
- 组件评估和优化阶段 (Component-wise Evaluation and Optimization)：对LLM系统的步骤/组件进行评估，根据评估结果定位问题，并对系统进行迭代优化。
- 线上验证阶段 (Real-world Validation)：当系统的生成质量和性能达到预期标准时，部署到线上。这并不是优化工作的结束，而是新的起点。系统上线后需要持续监控，收集数据并评估，进行反复优化。
接下来，将针对这四个阶段验证和评估的思路和方法进行分别阐述。
第一步：快速搭建原型，迭代验证
当你有了任何创意和想法时，快速搭建原型是让想法走向落地的重要一步。
前面已经提到，LLM系统由一系列决策与执行的步骤交叠而成，而每个用到LLM的步骤中，都会涉及到选择合适的基础模型，要用到定制化的提示语，还可能会用到知识检索或者工具调用，挑战是如何通过工作流将这些步骤串联起来，围绕目标任务实现自动化地执行。
有很多开发工具可以帮助我们快速搭建原型，比如像langchain这样的开发框架，或者选择OpenAI的
Asssitants API，还有Coze，Dify，FastGPT这样可视化的工作流编排平台。可以让我们忽略一些底层的技术细节，将更多精力放到业务流程中。
在搭建系统原型的过程中，我们已经需要对系统进行初步的验证，目标是确保工作流能够正常走通，并且对意外情况具有一定的容错性，达到基线标准的生成稳定性。
在传统的机器学习训练中，为了得到一个可用的系统，我们需要做大量的数据准备。这包括数据收集、清洗、标注等步骤。而大语言模型（LLM）由于已经在海量的多样化数据上进行了预训练，具有强大的基础智能和优秀的泛化能力，这让我们通过快速迭代的方式搭建原型成为了可能。
当初始系统的输出效果不够理想时，我们可以通过分析问题出现的原因，总结共性规律，并通过提示语工程的一些技巧（如反思技术、链式思维、少样本提示等）对提示语进行优化，并将新的输出结果与原来进行比较，而不需要像传统的机器学习那样每次都重新训练。
在这个阶段对样本量的要求不高，我们可以采用人造数据，使用大模型厂商和编排工具提供的Playground，或者ConsoleX.ai的一站式工作台进行测试，并且利用人类专家的经验进行评估。
但Playground中的评估只能覆盖特定的使用案例，并不能给我们足够的信心让系统生成稳定的回复。这时，我们就应该进入到下一个阶段，基于更大规模的数据进行更加系统的评估。
很不幸，很多开发者都把时间和精力放在了系统搭建之上，并未经过充分的评估就将产品投入市场，就好像驾驶着一辆未经过安全检验的原型车上路，其结果可能是严重甚至灾难性的。例如，[加拿大航空公司就被迫因为其客服聊天机器人给出的不符合事实的优惠政策而输掉了官司]((https://www.forbes.com/sites/marisagarcia/2024/02/19/what-air-canada-lost-in-remarkable-lying-ai-chatbot-case/)，并向客户进行退款和赔偿。在医疗、法律、心理咨询这样的专业领域中，使用LLM系统提供服务显然需要更加谨慎，任何失误都可能让公司付出沉重的代价。
第二步：进行端到端的评估
那么，该如何更加系统地通过评估优化LLM系统呢？
首先，你应该有思想准备，在进入这个全新的阶段之后你需要采纳一些新的方法，使用专业的评估工具和框架，并需要投入一定的时间和精力去做准备工作，而且这个过程不会是一蹴而就的，在各项指标都达到基准目标(benchmark)之前可能需要进行反复的迭代。
不过，要想让你的LLM system从激烈的竞争中脱颖而出，或者能够真正胜任垂直领域的工作任务，而不是忙于处理各种意外，这样的投入是必要也是值得的。
具体来说，在进入端到端评估阶段之前，你需要做以下三类的准备：
- 建立评估指标和衡量基准 根据业务目标和前一阶段的经验，确定考核的维度，并将在每个维度上要达到的目标进行量化。
- 确定评估方式，建立评估器 可以选择人工评估或自动评估，如果是自动评估，还需要围绕评估指标和量化标准建立评估器，让评估流程自动化。
- 准备运行评估需要使用的数据集 花时间去准备领域相关的评估数据集
确定评估指标和衡量基准
首先，我们要做的是确定评估的指标 (Metrics)，以及最终要达到的衡量基准 (Benchmark)。
在传统的NLP任务中，常用的评估指标包括准确率（accuracy）、精确率（precision）、召回率（recall）和F1分数（F1 score）等，而对于基于生成式AI的任务，评估指标和基准目标的确定通常更加复杂和多样化。
评估指标的设定还与你的实际应用场景相关，比如对于医疗应用程序，强大的引用准确性可能是关键，但对于休闲聊天机器人来说，上下文的连贯性更加重要。
在实际应用场景中，大多数LLM系统都需要在多个指标维度上进行评估，而不仅单一的指标。比如客服聊天机器人需要在在回答准确度、连贯性、知识引用正确性、响应时间、用户满意度等指标维度上进行评估。
在确定了需要评估的指标后，我们需要设定相应的衡量基准（benchmark），基准的设定有助于明确优化方向，为系统改进提供参考。
好的衡量基准应该兼备可衡量性和可实现性：
- 可衡量性：使用定量指标或明确的定性尺度，而不是模糊的表述。
- 可实现性：可以基于行业基准、先验实验、人工智能研究或专家知识来设定目标，避免基准目标脱离现实。
人工评估 vs 自动评估
接下来需要做的，是确定基于衡量指标进行评估的方式，我们可以选择人工评估或者自动评估。
人工评估虽然能够提供细致的反馈和对复杂问题的理解，但它耗时且容易受到主观偏见的影响。相反，自动评估则能够快速、一致地处理大量数据，提供客观的结果，但需要投入更多时间、精力进行准备。
特别是考虑到评估需要基于大规模的数据，而且伴随着大语言模型能力的不断进化，同样的评估可能还要重复进行，那么将评估过程尽量自动化就显得非常重要了。
如果选择自动评估，接下来的工作是围绕指标、评估方式和衡量基准建立评估器。评估器是用来根据一个或多个指标执行评估过程，并判断评估结果是否达到衡量基准的自动化程序。
根据评估器完成任务的手段，可以分为基于算法规则、基于专用模型和基于大语言模型的评估器。对于有明确评价规则的场景，我们可以采用基于算法规则的评估器，例如判断文本之间的匹配度、基于特定算法的相似性、JSON内容或规则的一致性等；对于分类任务，可以采用传统机器学习算法训练的专用模型进行评估，例如我们可以使用预训练的情感分析模型来评估用户反馈的情感极性（正面、负面、中性）。而基于大语言模型的评估器，可以在更加复杂和多样化的生成场景中进行有效的评估，确保LLM系统的质量表现和用户体验超过预期标准。
围绕同一个评估指标，可以采用多种不同类型的评估器进行评估，例如文本相似性，既可以采用嵌入向量距离的算法，也可以使用大语言模型的提示语来评估。
大语言模型充当评估员
为什么大模型能够胜任评估员的角色呢？
首先，用于生成的模型与用于评估的模型在智能水平上可能存在差异。出于成本、隐私、设备限制或生成速度等现实因素的考虑，我们并不需要在所有场景下都采用能力最强的模型。但是为了追求评估结果的准确性，我们通常要把能力最强的模型应用于评估中。
再者，生成与评估过程的关注点不同。比如在内容创作的场景下，生成模型需要具备高度的创造力和灵活性，能够生成多样化且有创意的内容，就像作家在创作时需要考虑各种可能性。而评估是一项收敛性任务，要求模型能够在特定标准下对文本进行严格的审查和打分，就像编辑需要根据既定的标准来评估稿件的质量。生成模型关注的是多样性和创造性，而评估模型关注的是准确性和一致性。
根据是否提供理想答案，又可以将评估器分为有参照和无参照两类。有参照的评估器在评估开始前需要准备参考答案，可以是一个或多个固定的选项，也可以是一个完美的回答或者解题过程的思路。如果不设置参考答案，那么就需要通过提示语让大模型利用自己的理解进行判断。
如前所述，大模型作为裁判员进行评估，本质上是依赖于评估提示语模版的生成任务，因此，尽可能采用高水平的AI模型，并采用经过验证的高质量提示语，对于评估结果的准确性至关重要。对于更加个性化的垂直应用场景，通用的评估提示语可能并不能完全适用，这时就需要定制符合特定需求的个性化评估器。EvalsOne提供了通过YAML配置文件，创建自定义评估器的方法。
最后，我们也需要对大模型评估的局限有所了解。将大模型作为裁判员，本质上是基于大模型和评估提示语，同样受限于提示语的质量，以及所使用大模型的基础能力。而且，大模型作为评估员仍然有一定的出错概率，用于评估的提示语依然需要经过评估验证。
但这并不意味着我们应该因噎废食，由此否定自动评估的效果和意义，相反，从整体的代价和收益角度来看，自动评估在许多方面具有显著的优势。随着技术的不断进步和完善，这些问题可以逐步得到改善。通过结合人工和自动评估的优势，我们可以建立更加高效、准确和全面的评估体系。
准备评估数据集
接着，我们就需要准备更大量的评估数据集，也叫Test Cases。与其一次准备海量的评估数据集，我们可以考虑采用渐进(progressive) 的方式，首先将样本集规模扩展到更大的量级，运行评估，如果结果达标则再扩展到更大的样本集，并增加数据的多元化程度，并引入具有挑战性的边缘情况问题。如果在扩展的样本集上评估不能达标，那么就需要定位问题并优化系统了。
长期以来，准备评估样本集都是以人工方式为主，这是一件既耗时又繁琐的工作。随着大语言模型能力的不断演进，采用LLM扩展评估数据集成为了可能，越来越多的研究和解决方案也在这一领域涌现，例如Claude的Workbench中就集成了智能生成变量的功能，就可以自动生成多样化的测试用例。
然而，利用大模型扩展评估样本集也面临一些挑战。一个主要问题是容易出现数据同质化，导致测试用例缺乏多样性。此外，大语言模型有时会产生幻觉，生成错误的结果。因此，在当前阶段，人工审核AI生成的样本数据仍然是不可或缺的一环。人工审核不仅可以确保数据的准确性和多样性，还可以帮助识别和纠正模型生成过程中出现的错误。
通过结合人工和AI的力量，我们可以更高效地生成多样化的测试用例，确保系统在各种情况下都能表现出色。
第三步：针对系统组件的评估和优化
当目标、指标维度都确定好，并建立了自动化的评估器之后，就可以开始运行端到端的评估，判断目前系统的整体质量和性能。
接着，收集结果数据，判断评估结果与期望目标之间的差距。如果能够达到期望目标，就可以扩大数据集，增加数据的挑战性。但如果没有达到期望目标，这时就需要去从过程中分析原因并优化系统。
这又是一个困难的过程，往往会给人无从下手的感觉。到底是模型本身的问题，还是提示语的问题，又或是RAG数据检索的过程，或者Agent工作流的设计问题？
这时我们要把大的系统分解成具体的细分步骤，并将每个步骤放到显微镜下进行评估。这需要我们需要对大模型系统的工作机制有更进一步的了解。
比如，对于一个RAG的生成通道来说，可以具体划分为检索过程和生成过程。其中，切片方式，嵌入算法，检索方式，以及大模型生成式是否合理利用了检索背景信息，都会影响最终的生成结果。这时我们就需要对过程进行解构，去追踪（tracing）每一步背后到底发生了什么，这有点像软件开发里面的debug。有一些第三方工具提供了这样的追踪功能，如LangChain, Langfuse等，使我们可以对过程细节有更好的把握并对系统参数进行调整和优化。
不过Tracing是基于单个或少量样本的，对于批量的数据，还需要用到比如EvalsOne这样更专业的评估工具，并使用系统的评估方法。在针对具体过程的评估中，所需用到的评估要件、评估指标和目标基准都与端到端评估是不同的。仍然以RAG系统的评估为例，RAG步骤中的每个环节都可能影响到最终生成的结果质量。Ragas 针对RAG的评估提出了回答相关性、背景信息准确性、背景信息唤回以及回答忠诚度四个评估指标维度，为我们通过评估提升RAG过程的整体效果提供了一个实用的思路。
评估对于AI Agent来说也极其重要。一个复杂的AI Agent，需要用到提示语链，需要具备决策和利用外部工具的能力，需要结合垂直领域的工作流RPA，还需要将工作流的结果用于二次生成。像AutoGPT这样的项目让我们看到了Agent的潜力，但是也同样暴露了Agent的局限。Agent执行过程中的每一步决策都可能导致离偏离目标，这时就需要Agent具备自我反思、纠错的能力，还需要对每一步的执行效果进行评估。
对于Agent的评估，是一个具有挑战性和探索性的领域。有人针对Agent的评估提出了Guardrail的概念，通过实时评估中间步骤的效果来及时纠正（比如再次生成）。但是，轨道评估的方式只能尽量让Agent的执行不至于偏离轨道，并不能保证Agent能够很好的完成既定目标，而且反复的纠错可能会带来很高的额外延迟和成本。
当基于过程的分析和评估帮助我们找到原因并进行了针对性的优化之后，还需要重新运行端到端的评估，确保LLM系统的运行效果确实得到了提升。我们可能要多次重复这种从整体到局部再回到整体的过程，直至最终达到期望的衡量基准。
有时候，我们会发现系统的优化可能会受限于所使用的原型搭建工具。比如像Coze、Dify、Fastgpt这样的可视化编排工具，虽然降低了Agent开发的门槛，但它们提供的调优空间和开放能力也有限。在实践中，我们可以先借助一些可视化编排工具快速搭建原型，对效果进行评估，并尝试调优。但如果受限于框架始终无法达到期望的benchmark时，就要考虑使用更加底层的方式去重构系统，这样我们可以对LLM系统的中间过程和参数具有更好的可控性。
第四步：从开发环境到生产环境
"用 LLM 做一些很酷的东西很容易，但真正投入生产环境却很难。"
——Chip Huyen
前面的评估做的越充分，对于LLM系统在真实世界中的表现，我们的信心就会越强。不过，由于生产环境的特点，我们对于错误应该保持更强的警觉，因此生产环境中的评估和监控往往是密不可分的。
LLM系统在生产环境中提供服务时，我们不可能对每一次输出都进行充分评估后再展现给终端用户，这会增加系统的延迟，并影响用户的使用体验。不过，我们依然可以通过API收集真实世界的数据进行事后的评估，并加强预警机制，对于异常情况作出敏捷的反应和必要的处理。
同时，还需要定期对输出质量进行阶段性回顾和检查，真实世界的情况总能给我们一些改进系统的启发。从开发到测试，再到生产环境，是将样本数据不断泛化，通过持续改进和集成（CICD），让系统变得更加健壮，不断追求卓越表现的过程。
但这并不意味着我们的目标是让系统达到 99.999% 的准确率。生成式AI的智能性和泛化能力必然伴随着不可预测性，从商业层面，我们要做的是将系统出错的概率降低到容忍限度以下，与此同时实现成本的降低和效率的提升，从而达到商业利益的最大化。
开源工具 vs SaaS平台
最后，让我们聊一聊LLM系统评估所需要用到的工具。如果你是一个技术高手，有很多开源的评估框架可供选择，比如OpenAI的Evals，promptfoo, ragas, deepEval等，LangChain和LlamaIndex也包含了评估组件。它们的优点是开源、透明而且免费，同时也不必过分担心数据隐私问题。
不过，开源评估工具提供的往往是更加技术层的解决方案，对于使用者有一定的开发背景要求，而对于团队开发以外的角色则上手难度较大，而且，它们提供的是单纯的评估工具，而不是完整的解决方案，如果要实现评估过程的自动化，包括从数据收集、准备，到迭代评估的过程管理，以及生产环境中的监控，则需要进行二次开发。
很多大模型厂商和托管平台也提供了评估的功能，但是往往仅支持自家提供的模型，且功能也比较有限。相对而言，像EvalsOne这样的SaaS平台的优势是有着更加友好的界面和使用流程，更广泛的模型支持，可以降低在团队中引入评估流程的门槛，并且能够提供一整套从开发环境到生产环境的评估解决方案，让开发人员将更多精力投入到系统优化之上，而不是在评估系统上重新造轮子，或者不得不整天和样本数据打交道。
当然，怎样才是明智的决策取决于每个团队和应用场景的具体情况，比如在数据隐私极其重要的场合，采用开源方案可能仍然是首选。而对于业务优先的场景下，SaaS系统的可视化界面和全面的解决方案可以各种角色的团队成员都能够平滑参与到LLM系统的改进过程中。
总结
最后，让我们总结一下本文的要点：
- LLM系统评估与LLM评估不同，更注重系统在垂直应用场景中解决实际问题的具体表现，对于构建可靠、高性能的AI应用至关重要。
- 通过评估构建出色的LLM系统通常要经过四个阶段：原型搭建阶段、端到端评估阶段、系统组件评估和优化阶段、线上验证阶段。测试和评估应贯穿整个过程。
- 从原型搭建到端到端评估，首先需要做好三方面的准备：建立评估指标和量化标准、确定评估方式和创建评估器，以及准备评估数据集。
- 利用LLM作为评估员是一个有效的方法，引入自动化评估相比人工评估可以提高效率和效果，但也需要接受由此带来的不确定性。
- 通过评估迭代优化LLM系统是一个从整体到局部再到整体的循环过程，需要反复进行直至达到目标。要深入分析和优化每个环节，如RAG系统中的检索和生成过程。
- 生产环境中的评估与监控密不可分，需要建立预警机制并以结果为导向进行持续改进。
- 选择评估工具时需权衡开源方案与SaaS平台的优劣，根据团队情况和应用场景做出决策。
将前面的步骤串联起来，我们可以得到一个通过迭代评估打造优秀LLM系统的整体路线图：
尽管针对LLM系统的评估发展至今已经有很多受欢迎的工具和解决方案，但由于生成式AI的快速发展，以及评估过程本身的复杂性，真正将评估平滑纳入工作流程的团队仍然只占少数比例。我们开发EvalsOne的目标，是让评估流程变得更加简单、直观，容易上手，同时又功能全面，且成本可控。
后面，我们会分别针对准备数据集、建立评估指标、各种LLM系统的评估和优化方法撰写专门的文章，使开发团队能够充分掌握评估的方法和技巧，打造出更多质量和性能出色的LLM系统。
