你的大型语言模型在排行榜上取得了非常高的分数，对吧？它是某些特定任务中的第一名。这很棒。但问题是，当你在AI应用或智能体中实际使用这个模型时，用户可能需要等待很长时间才能得到回复。而且结果可能正确，也可能有一半的答案是错误的。那么这里发生了什么？
这个排行榜只测试了一件事，而你的生产环境则涉及其他所有方面。基准分数与现实世界性能之间的差距正是我们今天视频要深入剖析的内容。无论你是构建回答客服请求的聊天机器人，还是通过提示词整合PDF和其他数据类型的RAG系统，亦或是帮助编写代码的代码助手或与服务交互的智能体。
无论你在构建什么，你总是在平衡三件事：准确性、性能和成本。我们可以将其可视化为一个三角形，顶部是模型的准确率；其次是性能，即用户等待回复的时间长短；最后是成本。通常你可以优化其中两项，但第三项往往会受到影响。
假设我们有一个巨大且准确的模型，并希望它以极高的性能运行以处理大量用户，这会带来高昂的成本。反之，一个便宜的模型可能速度很快，但准确性较低。基准测试和评估就是为了确定你的系统在这个三角形中的位置，并希望在用户发现问题之前你就搞清楚这一点。
主要有两种基准测试类型：模型评估和系统评估。模型评估关注模型的智能程度、推理能力以及是否准确，特别是针对特定领域的问题回答能力。系统评估则关注速度、扩展性以及每次请求的成本。我们需要同时理解这两者，首先从模型评估开始。
在最基本的层面上，模型评估是给模型一些问题并判断其回答是否正确。最著名的基准之一是MMLU（大规模多任务语言理解），或者是现在的MMMU（多模态）。这就像标准化考试，在不同领域如有机化学或世界历史中评估模型回答，并与已知正确答案进行比较。
对于编码等领域，我们可以使用基于领域的基准测试如SW-bench或Terminal Bench。这些基准让模型像软件工程师一样执行编码或使用终端任务。例如，分配一个来自Git仓库的错误工单给模型，让它探索代码库以找到修复文件并实施修改。
然后运行测试以查看该答案是否解决了最初出现的问题，这被称为基于执行的基准测试。然而，许多现实世界的使用场景没有唯一正确答案或可运行的SWE测试脚本。因为对于客服问题，可能有上百种正确的回应方式。
因此，你还需要无参考评估来判断语气是否恰当、是否有用以及模型是否对公司的产品或细节产生了幻觉。这时可以使用“LLM作为裁判”的方法，利用强大的模型来批评你正在测试系统的输出。我们将用户输入和模型响应结合起来发送给评估模型，它会根据训练过的标准验证答案是否幻觉或正确回答了问题。
但这里有一个陷阱：你不能盲目信任LLM在此时做出的判断。你需要人类在环中评估这些分数是否与领域专家的意见一致。因此，我们使用领域的专家来标记数据，然后LLM可以扩展这些好坏回答的模式，从而能够评估模型产生的数百或数千个不同输出。
这些都是目前领域内常见的几种评估示例，加上智能体评估或非英语的语言评估，常用于确定模型是否表现良好以及是否适合该领域。现在让我们谈谈另一半：系统评估，即理解AI应用或智能体的性能表现。
因为即使模型在所有准确率基准测试中都得满分，如果它无法处理真实流量，这一切都毫无意义。当我们对推理性能进行基准测试时——即向模型输入信息并生成输出的过程，例如“红帽是一家软件公司”等回答——有几个关键指标。首先是首字延迟（Time to First Token），即从输入到收到第一个回复需要多长时间，用户等待看到第一个字的时间。
此外还有我们想要查看的指标，如令牌间延迟（Inter-token Latency），即生成后续内容的速度有多快。
第一个令牌之后的其余令牌流是如何进入的？还有请求延迟，即获取响应总共需要多长时间，以及能够测量吞吐量。那么我们能同时处理多少个这样的请求呢？可能是五个吗？还是可能是一千个？这就是吞吐量的定义。那么，为什么这些指标很重要呢？为什么要单独测量它们呢？这是因为推理发生在两个截然不同的阶段。
第一个阶段称为预填充（pre-fill），模型一次性处理你的整个提示词，这是计算密集型的。然后是解码阶段（decode），模块逐个生成令牌，这是内存密集型的。之所以重要是因为这些阶段具有完全不同的瓶颈，这意味着你的工作负载形状会改变一切。
让我们思考一下典型的工作负载。我会给你举几个例子，关于你试图构建或今天正在使用的应用程序。例如聊天应用程序，比如客户服务、聊天机器人响应。你的输入可能是128个令牌，而输出可能是98到109个令牌。再比如检索增强生成（RAG）的例子，处理我们的数据时，我们会拉取巨大的文档块。在这种情况下，输入可能是4000个令牌，输出是512个令牌。
最后，我们许多人都在使用AI编码助手和智能体（agents）。智能体可能会调用工具，接收512个令牌，然后输出另外512个令牌。问题是，如果你使用错误的令牌分布进行基准测试，在AI应用程序的性能方面将会看到截然不同的结果。因此，建立服务级别目标（SLOs）非常重要。
这些目标允许你测量并定义指标。例如，对于聊天应用程序，我们希望99%的请求（即这里的第99百分位）在300毫秒以内。通过了解我将对我的AI应用程序发出的请求类型以及我收到的输出，我可以针对这些指标进行基准测试。
开源生态系统中的工具允许你模拟现实类型的流量模式。例如，假设我们有数千份文件需要总结。这非常可预测，这就是所谓的离线推理（offline inference）。但在代码辅助和智能体等情况下，我们采取不同的做法，即在线推理（online inference）。
请求可能是一个接一个地进入的，但在许多情况下，它们可能是并发的或以不同的间隔到达。了解你的应用程序中可能看到的流量模式类型以及不同类型的工作负载，使你能够针对这些不同的指标进行优化。
并为最终用户对此进行基准测试，这在扩展应用程序时非常重要。你要寻找的是拐点（inflection point）。让我用这样的图表为你可视化这一点，这里显示首令牌时间。请记住，随着这一指标上升，用户会感到有些不安，进入系统的请求也会受到影响。
在低流量下，延迟保持相对平稳，对吧？但随着你通过越来越多的请求，最终你会达到这个拐点，并且它会激增。而甜蜜点（sweet spot），即在保持我们的延迟目标的同时具有最大吞吐量的地方，大约就在这里。这将是我们用于容量规划的数字。
到目前为止我们讨论的一切都适用于执行单一任务的单个模型，但智能体略有不同，因为一个智能体不仅仅是一次模型调用，它是一系列决策链。从用户的输入或请求开始进入我们的智能体，然后转到某种类型的编排器（orchestrator），以便决定我们是否需要路由到工具调用。
或者可能路由以从数据库获取信息，或者执行某种类型的代码执行并收集这些输入，在此基础上进行推理，以做出安全且明智的决策。但问题是我们不能只评估最终输出，因为之前所有的步骤都需要检查。
例如，我们是否正确理解了用户的意图？或者当我们决定调用这个MCP服务器时，是否选择了正确的工具？或者通过向量数据库的检索实际上返回了生成此响应所需的正确相关上下文吗？智能体决策链中的每个环节都是一个潜在的故障点，因此每一个都需要自己的评估。
你可以将其想象为一个金字塔。在这个金字塔中，为了评估我们的智能体，我们有基础系统性能，也就是我们刚才讨论的内容。我们的系统足够快吗？它能扩展吗？我们能够处理多个用户吗？
接下来是格式化。我们是否按照应用程序和最终用户的期望正确格式化了响应？因为一个不能提供正确响应的系统毫无用处。然后是安全性和偏见，例如我们的最终输出是否包含任何私人用户信息？是否有我们可能会惹上麻烦的识别性信息。
使用安全护栏和防护栏来检查这一点非常重要，具体含义取决于你的特定用例。接下来是事实准确性，即通过例如使用工具调用、基于现实世界数据来减少幻觉。最后是这些特定领域的评估。
许多团队犯的一个错误实际上是直接从金字塔的顶部开始。但如果你的系统无法处理负载，如果你在整个智能体过程中没有这些评估，那么一切都会崩溃。因此总结起来，基准测试AI系统不仅仅是一件事，它是模型评估和系统评估的协同工作。
在模型方面，你有标准化的基准测试，可以告诉你不同领域的准确性，例如一般理解能力。或者如应用AI编码或智能体用途等场景。别忘了，我们还有“LLM作为裁判”，在人类评估者和标注员的帮助下，我们可以将响应和评估扩展到不同类型的开放式回答。
另一方面，在系统评估方面，我们关注诸如延迟等指标，即用户等待获取响应的时间。还有吞吐量，即我们可以同时服务多少用户？以及当我们以规模执行此操作时（无论是使用API还是其他方案），成本将会如何表现？
运行我们自己的模型。当我们谈论智能体（agents）时，我们会将所有这些要素整合进来，并将其层层融入智能体工作流的每一个步骤中。从用户的输入开始，到协调和调用工具，再到在给出最终响应之前执行安全检查——我们可以引入所有这些基础要素来评估流程的每一步，循环往复。
但这里的关键要点是：模型在特定领域的排行榜得分只是一个起点，而非终点。因为真正的基准测试发生在你使用自己的数据、真实的流量模式以及你自己定义的成功标准进行测试的时候。