LLMOps： 生产环境下的大语言模型管理——大型语言模型（LLM）的评估

语言模型（LLM）变得越来越复杂，但准确评估其有效性仍然是一项重大挑战。

LLM评估的重要性不仅引起了学术界的关注，也得到了行业利益相关者的高度重视。这种研究与测试工作的汇聚，彰显了该问题的重要性和集体寻找有效解决方案的决心，同时也加快了创新步伐，帮助研究人员更好地理解和改进这些模型。

在学术界，研究人员不断探索新的方法论，开发创新的评价指标，并开展严格的实验，推动LLM评估的边界。尽管已有一些领先的评测指标，但尚无绝对的赢家，因为许多指标和排行榜往往只在短期或针对狭窄应用场景中有效。无论如何，业界对LLM性能的实际影响有着深刻认识。

评估的核心目的是衡量LLM完成其预期目标的能力，无论是生成连贯且语境相关的文本、理解用户输入，还是完成特定任务。本章将介绍一个系统的评估框架，针对不同应用挑战提供解决方案，并分享一些实践经验。

为什么评估LLM如此困难？

LLM评估是衡量其性能和能力的过程，结合多种方法以判断模型是否达到了预期目标并遵循伦理规范。

开发和部署机器学习（ML）解决方案时，测试和评估方法需要与传统软件开发不同。尤其是，机器学习模型训练时会使用随机数，评估时需在整体数据集和具体数据点上进行验证，以确认训练效果。但训练完成后，大多数ML模型推理是确定性的，即同样输入总会产生相同输出。

相比之下，LLM在训练和推理时都会使用随机数，因此即使模型未发生变化，同一输入也可能产生不同输出。许多传统假设不再成立，或者需要加以补充。本章将探讨数据集、指标和方法选择中的若干开放问题。

任何上线运行的ML系统都需预先设定预期性能标准，并提供有效的监控手段以发现并解决性能问题。模型评估的作用包括：

• 确保模型表现符合预期
• 发现可改进之处
• 保证模型的安全和负责任使用

评估LLM难点的具体原因：

1. 人类语言极其复杂且难以量化，导致准确的质量评价指标难以开发。

2. 语言模型训练于大规模文本数据，很难找到模型未见过且具代表性的测试文本。

3. 模型可能继承训练数据的偏见，生成可能违反社会、伦理或法律规范的内容。

4. 难以解释LLM为何生成特定输出，这给实验设计和结果复现带来挑战。

5. LLM输入空间几乎无限，不可能对所有场景进行穷尽测试，只能针对若干类别进行评估，如下：

   • 信息性与事实准确性

     • 输出是否事实正确？
     • 是否包含与输入相关的充分信息？
     • 生成文本是否完整回应了输入？

   • 流畅性与连贯性

     • 语法是否正确，易读性如何？
     • 逻辑是否通顺？
     • 语言水平是否合适？

   • 吸引力与风格

     • 输出是否有趣且引人入胜？
     • 文风是否合适？

   • 安全与偏见

     • 是否可能生成有害内容？
     • 输出是否可能危及他人安全？
     • 是否包含偏见语言或概念？

   • 基于事实的支撑

     • 回复是否有现实信息支撑？
     • 是否提供适当参考？
     • 是否避免了“幻觉”现象？

   • 效率

     • 生成输出所需计算资源多少？
     • 响应启动时间？
     • 生成完整回复所需时间？

评估中主观性与目标冲突：

某些任务有明确的成功标准（例如图像识别中的准确率：“这是一只鸟吗？”），但LLM的“好”回答常带主观性。输出是否提供相关信息？是否有创意？是否事实准确？这些目标可能相互冲突，导致难以设计涵盖所有方面的单一指标。“良好表现”可能包含多种含义。

解释性工具的局限：

传统ML模型在评估失败时，开发团队通常借助解释性工具分析模型决策机制，这些工具通过大量输入样本测试，判断输入变化如何影响输出。由于多数ML模型确定性强（相同输入总输出相同），此方法有效帮助理解模型内部机制。

然而，LLM因参数庞大且推理非确定性，缺乏可用的解释性工具。要理解其内部机制，需巨量样本和计算时间，至今仍是开放难题。

评估性能

在开发和部署过程中，有多种方式可以评估和监控基于LLM的解决方案的准确性。人工检查输出的准确性和正确性虽然有效，但耗时且依赖评估者的主观判断。自动化评估则利用工具来检测LLM输出的准确性，实质上是用LLM去评估另一个LLM。用户反馈同样有助于发现模型表现不佳、需要改进的领域。

最重要的是，评估LLM必须依托具体的应用场景。在许多LLM应用中，用户能够明确哪些实际性能指标是有用的。例如，假设贵公司使用LLM生成网页广告文案。人工撰写广告时，典型的评估方式是A/B测试——将不同版本广告随机展示给相似受众A和B，统计各自的点击率等成功指标。如果A版本的成功率显著优于B版本，公司则选用A版本。对LLM生成的文案，同样可以采用此方法。事实上，对于许多常见的机器学习任务，如文本分类、图像识别和物体计数，使用传统的预LLM方法和指标是合理且有效的。

不过，也存在一些特定于自然语言处理（NLP）且无需用户参与的指标，这些指标成本较低，适合作为LLM评估的选项。

由于LLM主要用于内容生成，通常使用一类称为生成式指标（generative metrics）来衡量生成内容的质量。最基础的生成式指标是基于n-gram的度量，它通过比较生成文本和参考答案之间连续n个词的重合情况来衡量相似度。使用此指标时，你需要知道“正确”答案，然后比较LLM生成的文本中有多少n-gram与正确答案重合。

举例来说，n=1时比较单个词，n=2时比较词对，依此类推。此类指标通过共享n-gram数量量化文本的相似度，从而反映生成文本与正确答案的连贯性和相关性。

例如，测试题“问：法国的首都是哪里？答：巴黎。”如果LLM回答“巴黎”，n-gram指标会显示100%匹配，表现良好；但如果回答“The capital of France is Paris.”，由于预期答案仅为“巴黎”，该回答只有16.6%的词汇匹配，导致指标得分偏低，可能误判LLM表现不佳。

其次，还有基于相似度的指标，旨在捕捉生成文本与参考文本在多个层面的相似性，包括：

• BERTScore
  衡量内容重合度及文本流畅性
• SemScore
  检查生成文本是否传达了与参考文本相同的意义和意图
• MoverScore
  计算将一个文本转换为另一个文本所需的最小“工作量”

这些指标通过计算文本的向量表示（embedding）并比较它们的相似度来评估句子整体的相似性。以之前的例子来说，LLM回答“It’s Paris”和“The capital of France is Paris”都会得到较高分数，因为两句意思接近。但“Teh KaPiTaLL of Franceland is PARIS”虽然拼写错误且包含虚构词“Franceland”，也可能因为语义相似而获得较高分数。

因此，我们转向基于LLM的评估指标，它们使用其他LLM对目标LLM的生成质量进行评估，并能检测潜在的“幻觉”问题。这类指标既能识别正确答案，也能评价文本的流畅性和语法正确性，但计算成本较高。以下是一些流行的基于LLM的评估指标及相关论文：

• G-Eval
  通过另一LLM判断生成文本的连贯性、流畅性和事实一致性得分。
• UniEval
  通过多个LLM评估者的集成，综合考虑流畅性、语法性和事实连贯性。
• GPTScore
  专为GPT类模型设计，评估连贯性、安全性和事实一致性等方面。
• TRUE
  利用其他LLM评估事实正确性和识别潜在事实幻觉。
• SelfCheckGPT
  针对GPT模型，重点检测逻辑不一致和事实错误。

这些指标可根据具体应用场景进行配置。尽管相关论文通常提供示例问答集，建议您根据实际需求构建适用的问答数据库。

此外，还有许多通用的LLM基准测试，旨在评估LLM作为通用问题解决者的表现，而非针对特定任务。这类基准更适合构建平台级LLM，如Google的Gemini或OpenAI的ChatGPT。虽然这些基准结果在某些方面有参考价值，且常见于市场宣传中，但存在重要局限：它们无法预测模型在特定任务上的表现。例如，模型A在通用任务和GLUE基准上表现优于模型B，但模型B可能在法律文档分析等特定任务上更胜一筹。因此，需理性看待这些基准，将其视作通用适用性的综合评分。

表7-1列出了部分主流通用基准，需注意该领域不断有新基准被提出。

基准名称	描述	关注点
General Language Understanding Evaluation (GLUE)	核心NLP能力评测套件	自然语言理解 (NLU)
SuperGLUE	GLUE的升级版，包含更具挑战性的任务	自然语言理解 (NLU)
HellaSwag	注重推理与常识理解	自然语言推断 (NLI)
TruthfulQA	评估事实正确性和避免事实幻觉	问答 (QA)
Massive Multitask Language Understanding (MMLU)	大规模多任务基准	多任务学习

这些基准公开其问答对，方便在统一标准下比较不同LLM。

然而，这也带来一个问题：LLM开发者可能针对基准进行“刷题式”训练，如同学生死记硬背考试答案。这在实际应用中非常普遍，导致某些LLM在基准表现优异，却在现实场景（例如描述场景）中表现甚至不如过时但稳定的GPT-3.5。遇到这种情况时，用户的实际体验应当是最终判定标准，而非基准分数。

另一个问题是，LLM对训练数据和评估提示（prompt）的匹配非常敏感。提示中看似细微的改动会导致截然不同的输出，给持续设计稳定且有效的提示带来困难。

例如，有研究表明，某些模型在被提示“逐步思考”（think step-by-step）时表现更佳，而另一些模型则对以“please”开头的礼貌提示反应更好。这种现象源于训练数据的偏向性：如果包含更多礼貌提示的训练数据部分对应更高正确率，简单在所有提示前加“please”就能提升基准得分。

LLM还常用一种学生考试中的“妙招”：在回答中重复或改写问题或提示的部分内容。这会给人一种模型理解或同意的假象，即使答案本身质量不高，回答仍与问题高度相关。

总结来说，基准测试是比较不同LLM表现的有用工具，但必须了解其局限性并谨慎使用。

某些LLM应用非常常见，如检索增强生成（RAG）和多智能体系统，虽然本文介绍的指标可用于评估它们，但这类应用有其专门的指标体系，后续章节将详细说明。

评估“崩溃前的征兆”

当大型语言模型（LLM）首次进入生产环境时，其早期故障表现得零星且难以预测。这些初期问题通常被归结为模型“表现怪异”，被视作一种随机的怪癖，而非系统性故障。然而，随着使用规模扩大和数据积累，更加清晰且稳定的故障模式开始显现。这些故障模式不同于传统的软件漏洞，如段错误或程序崩溃，而是我们所称的“失败模式”（见表7-2）。

表7-2 常见的LLM失败模式及其评估切入点

失败模式	评估环节	工具/信号
幻觉（Hallucinations）	检索、提示、推理	与来源的相似度、事实核查
提示退化（Prompt regressions）	编排	提示差异比较、质量下降日志
延迟突增（Latency spikes）	推理、检索	p95/p99延迟指标、追踪
数据漂移（Data drift）	输入、检索	嵌入变化、聚类分布
行为不一致（Inconsistent behavior）	推理	会话级追踪、重复查询
安全违规（Safety violations）	输出	有害内容过滤、个人身份信息（PII）检测

失败模式指的是由于模型内部假设与真实世界复杂数据和交互之间的根本不匹配而产生的可复现但可解释的故障。这些不同于传统软件错误不会触发异常或导致程序崩溃，而是“隐性失败”。系统表面上正常运行，输出看起来语法正确、风格连贯，但实际上可能存在事实错误、伦理问题或结构缺陷。这种隐蔽性使得失败模式特别狡猾，常规依赖崩溃或明显错误信号的调试手段难以发现。

因此，LLM的评估范式必须从被动的故障调试转向更主动的预防性检测（见图7-1）。目标不再是等到故障影响用户时再修复，而是提前预判并早期发现这些失败模式，防止错误信息或有害影响的扩散。这种主动检测需要复杂的监控框架，结合自动指标、人机协同验证以及领域专属检查，以识别模型假设失效或输出偏离预期的情况。通过将评估从事后修复转变为持续的、前瞻性的监督，我们能更好地保障LLM在大规模部署时的可靠性、安全性和伦理完整性。

让我们来理解现代LLM流水线中最常见的失败模式，并找出观测和评估工具能够及早拦截它们的环节。

幻觉（Hallucinations）

在各种LLM的失败模式中，幻觉尤为臭名昭著且难以控制。幻觉指的是LLM生成的回答在语言上流畅自信，但在事实层面却错误或完全捏造。这种现象源于LLM通过基于训练数据预测最可能的词序列来生成文本，而非查询可靠且实时更新的事实知识库。因此，幻觉是LLM固有的风险，尤其在医疗、金融、法律等高风险领域，错误或误导信息可能导致严重后果。

评估幻觉不仅仅是发现孤立的事实错误，而需要系统且长期的模式监控。通常做法是记录所有生成输出，并在可能的情况下与验证过的真实数据进行比对。当无法获得准确的真实数据时，可采用多次生成结果之间的一致性检查，发现矛盾或不稳定性。这些方法有助于识别单个幻觉及其发生频率较高的条件和情境。

在检索增强生成（RAG）系统中，幻觉常反映检索组件的问题。例如，当检索器返回无关、过时或质量低劣的文档时，LLM更容易生成错误或捏造内容。因此，保持对检索和推理层的全面观测尤为重要。通过监控检索文档的质量和相关性，结合模型输出分析，可以判断幻觉是由检索失败、生成错误还是两者共同引起。理解根因对设计针对性的缓解策略至关重要，比如提升检索准确性、引入更可靠的知识源，或在生成过程中加入验证机制。

提示退化（Prompt regressions）

提示退化是一种特别隐蔽却令人沮丧的失败模式。它不同于明显的输出错误，表现为对提示模板的微小调整（如变量重命名、空格增删、格式调整）意外导致模型输出质量下降。这种退化往往不易被及时察觉，实时检测和诊断较为困难。

复杂性还因LLM的非确定性而加剧：相同输入在不同运行中可能产生不同输出，源于采样方法和随机预测。这使得提示退化难以稳定复现，成为传统调试的重大障碍。

为应对这一挑战，稳健的评估系统必须整合细粒度的提示版本控制和日志记录功能。精确追踪每次修改，支持提示差异（diff）高亮，方便开发者识别具体更改内容。将这些提示变动与可量化指标（如回答的帮助度、事实准确性或结构连贯性下降）进行关联，团队能准确定位退化发生的时间和方式。

这种系统化关联促成有效的根因分析，帮助开发者快速识别有问题的提示版本。更重要的是，团队能在检测到退化时回滚至先前稳定版本，保障输出质量与用户信任。如此，提示退化监控成为主动评估策略的重要组成部分，防止微小提示调整无意中削弱模型性能或可靠性。

延迟突增（Latency spikes）

无论系统多么智能或复杂，用户都无法容忍缓慢且无响应的体验。延迟，尤其是分布尾部的峰值延迟（如95百分位p95或99百分位p99）对用户体验影响尤为严重。虽然发生频率低，但这类极端延迟常造成明显等待，有时还引发下游系统超时或故障。

有效评估延迟需要持续且细致的监控，不仅跟踪平均响应时间，还要观察令牌使用模式及相关系统指标。这种全面的可观测性有助于及早发现突发延迟，防止服务质量大范围恶化。

延迟突增发生时，详尽的追踪机制不可或缺，助力根因分析。工程师可拆解请求流程，定位瓶颈或故障点。可能原因包括：输入提示过长导致处理时间增长、负责检索的组件响应迟缓，或上游依赖（如向量数据库、外部API）阻塞。此外，模型版本或系统架构变更也可能引入意外的延迟回退。

缺乏此类观测，延迟突增难以被监控仪表盘或告警系统捕获，往往直到用户体验明显变差或发生故障才暴露。因此，将端到端追踪和实时延迟监控纳入评估流程，是确保系统稳定、响应一致的关键。

数据漂移（Data drift）

在实际生产环境中，用户行为和输入数据持续变化。此动态环境导致数据漂移，即系统内嵌的基本假设（如预期输入格式、用户意图分布、上下文嵌入特征）逐渐偏离实际流入数据。

数据漂移表现形式多样。输入漂移通常表现为敌意或异常查询增多，偏离训练时的设计预期，给系统鲁棒性带来压力，影响输出质量。检索器漂移指的是检索到文档相关性下降，即使检索算法及配置未变。嵌入漂移则是用于语义相似度比较的向量表示效果变差，导致检索失效。

有效评估漂移需严格统计监测输入特征分布随时间的变化。技术手段包括：对查询类型进行聚类分析，发现新兴用户意图或交互模式；统计输入长度直方图，跟踪输入详细程度变化；持续测量嵌入相似度，捕捉语义表示的细微漂移。这些量化的预警信号让团队预见系统假设失效的临界点。

通过主动检测漂移，团队能及时重训模型、更新检索索引、调整提示模板，避免用户感知的性能下降。这种前瞻式管理确保系统顺应数据环境演变，持续保持准确性和用户满意度。

行为不一致

LLM生成的固有随机性意味着同一个查询重复多次可能每次得到不同的回答，这种现象称为非确定性（nondeterminism）。这种变异性是基于概率的令牌采样策略的自然结果，它促进了生成文本的多样性和创造性。然而，这种随机性对审计性、合规性和可复现性至关重要的应用场景构成了根本挑战。在这些场景中，不一致的输出可能破坏信任、增加调试难度，甚至违反监管要求。

评估和管理行为不一致需要一个会话级别的追踪框架，不仅仅是简单地记录输入和输出。该框架必须捕捉丰富的上下文元数据，包括模型的超参数（如温度参数和top-k采样值）、具体模型版本，以及相关的历史对话或用户交互信息。通过这种全面的追踪，团队可以重构并分析产生特定输出的确切环境和条件。

借助详尽的会话级日志（见图7-2），可以识别变异模式，将输出不一致性与特定设置或上下文变化关联起来，并在必要时通过固定采样参数或重放交互序列来确保可复现性。这种细粒度的评估对于在需要可预测、可验证行为的敏感领域负责任地部署LLM至关重要。

一致性可以通过选择性地采用确定性解码策略来实现，比如贪心搜索（greedy search）或束搜索（beam search），不过这通常会牺牲输出的多样性。关键在于平衡在必要时保证一致性，同时构建监控系统，在关键时刻能够及时发现并提示不一致行为。

伦理与合规风险

LLM可能无意间生成有害内容或带有偏见的语言，泄露私人信息，或容易被绕过限制的“越狱”提示攻击。这些风险会带来严重的法律和声誉后果。为降低这些风险，评估工具必须集成自动化过滤器和分类器，能够实时标记问题输出，正如本章前面所述。应当收集安全评分、有害内容指数和偏见测量等指标，并结合模型元数据进行审计。

RAG应用的指标

RAG（检索增强生成）应用使用大型语言模型（LLM）生成文本，但通过从知识库中检索数据并将其附加到用户提示中，帮助LLM生成更精准的内容。RAG应用的流程如图7-3所示。

让我们详细看看每个步骤：

用户输入

用户向RAG应用提交一个问题或提示。

检索

应用使用检索系统在相关文档或文本数据库中搜索，例如文章、手册、代码片段，或与LLM领域相关的其他信息。检索系统基于用户查询，采用向量相似度搜索等技术，识别最相关的数据部分。

提示增强

应用将开发者设计的提示与上一步检索到的文本及原始用户输入拼接在一起。

LLM生成

增强后的提示被发送给LLM，模型利用附加的上下文信息生成回答并呈现给用户。

除了上一节提到的生成指标，RAG系统还需依赖检索指标来评估检索组件的有效性。以下是一些关键的检索指标：

召回率（Recall）

衡量系统收集关键材料的完整程度。计算时，首先需要有专家判断为相关的“真实”文档集合。检索结果与该权威集合的重合度越高，召回率越高；遗漏越多，召回率越低。结果通常以百分比表示。

平均倒数排名（MRR）

衡量用户多快能看到第一个真正有用的结果。对每个查询，从排名列表顶部开始扫描，记录第一个相关文档的位置。第1位理想，第5位效果较差。将这些位置转换为得分（如第一位得n分，第二位得n-1分，以此类推），对多个查询取平均。高MRR意味着用户通常能在结果顶部或附近看到相关内容。

平均精度均值（MAP）

评估相关文档在整个结果列表中的位置和分布一致性。遍历单个查询的结果，计算每遇到一个相关文档时，当前已浏览文档中相关文档的比例，最终对这些中间比例取平均值作为该查询的平均精度。多个查询的平均值即为MAP。高MAP表示相关文档频繁出现且分布集中在结果顶部，而非零散或集中在底部。

上下文准确率（Context precision）

衡量检索结果中有多少内容真正有助于语言模型任务。检查每段文本是否支持任务，还是纯粹噪声。当大部分检索结果与权威文档匹配时，上下文准确率高；若无关或误导内容占多数，得分降低。通常以百分比表示。

相关性（Relevance）

平衡精度和召回率的指标，既考虑检索集合覆盖事实的完整性，又考虑其无冗余的程度。高相关性意味着为模型提供的信息既几乎包含全部关键内容，又避免了杂乱无章的干扰，助力模型生成准确且聚焦的回答。通常通过精度和召回率的调和平均（F1分数）计算，避免单方面高分掩盖低分问题。

虽然你可以自行测量这些指标，实际中更常用评估工具。大多数工具能同时评测前述检索指标和上一节的生成指标。对于简单应用，可使用现成框架如Python开源项目Ragas，它集成了上述指标，能测量应用输出并汇总成单一分数，且文档清晰易用，适合无丰富编程经验的研究者和开发者。

对大多数生产应用，通常需要可定制评估器，支持自定义指标、数据集，并与CI/CD工具集成，实现新模型上线后自动测试。一个流行的开源工具是LangSmith，由LangChain团队开发。

在LangSmith中，先定义测试用例数据集和一个或多个评估器。每个评估器可定义指标（如本章介绍）或英文评分标准。使用LangSmith编程接口，将LLM输出连接到评估器，自动计算得分。

LangSmith提供SDK，可在开发中运行测试，也可在新模型上线时自动运行测试。你只需写脚本，将提示发送至新模型，CI/CD工具部署后立即用LangSmith评估回答。

你还可以用SDK创建脚本，定期用固定数据集在生产环境运行测试，检测模型漂移——即模型性能随时间变化。一般而言，针对同一数据集反复测试应得相同分数，但若用OpenAI GPT API或Google Gemini API等服务，底层模型可能在你无法控制的情况下发生变更，即所谓模型漂移（将在本章末详细介绍）。无论如何，定期测试有助于及时发现模型漂移。

智能体系统的评估指标

到2024年底，“智能体系统”（agentic system）这一术语开始变得流行。在LLM的语境下，智能体系统指的是包含多个内部模块和多步骤流程的AI系统，它能够在仅有战略性人类监督的情况下，自主规划、决策并执行以实现高层目标。在智能体系统中，用户向协调型LLM发送请求，该协调LLM将请求拆分为多个任务，再将任务分别发送给自己、其他LLM或专用程序，汇总它们的响应后反馈给用户。这种多步骤流程带来了众多评估挑战。

本章前面定义的所有指标依然适用；例如智能体系统的某个组件是RAG系统，则可以使用RAG指标；若涉及内容生成的LLM，则可使用本章前段定义的生成指标。但除此之外，还存在额外复杂性：

• 动态行为
  智能体基于交互可能展现出涌现行为，难以预测结果或行为何时出现。
• 上下文敏感性
  智能体表现因上下文而异，需广泛测试不同场景。
• 持续学习
  许多LLM和智能体随交互动态适应，静态评估效果有限。
• 反馈循环
  智能体间存在反馈环路，可能产生难以复现的非线性效应。
• 与现有系统集成
  在真实环境部署时，可能暴露模拟环境中未见的未知问题。
• 环境多变性
  运营环境变化可能导致意外行为，增加评估难度。
• 多目标冲突
  智能体可能目标冲突或协作，需平衡多个指标。有时两个单独表现差的智能体合作，产出优于两位单独表现更好的智能体协作。

实际上，更易于评估智能体协作的最终产出。因此，智能体系统的两大评估方式是人类评估和LLM评估。尽管人类评估被视为金标准，但成本高且耗时。LLM评估在成本、质量和效果之间常取得良好平衡，但可能存在偏见。另两个问题是LLM的黑箱性和资源消耗大。使用LLM评估时，不宜完全放手，建议保留一定程度的人类复核。且目前尚无统一公认的智能体系统评估指标，导致评估结果不一致。

此外，计算资源和内存限制也限制评估规模。不同配置资源消耗差异大，影响可扩展性评估。

针对任何基于LLM的智能体系统，有四个关键评估目标：

1. 检视系统内部属性
   关注核心语言能力、上下文理解、学习与知识迁移能力及涌现行为出现的速度；评估适应新环境/任务的速度及多智能体协作效率。证据来源包括回答的连贯性与相关性、实时交互理解力、受控场景下的决策能力和情境变化时的响应性。日志和仿真揭示集体现象，长期测试展示性能趋势（提升、稳定或退化）。可用前述指标测量。
2. 工程层面审计性能
   关注效率、可扩展性和故障恢复能力。测量完成任务所用计算资源，压力测试评估智能体数量或工作负载增加时表现，故障注入测试探查恶劣条件下的弹性和恢复策略。
3. 聚焦交互质量
   评估对人类用户来说对话的吸引力、清晰度和可信度。指标包括会话长度、对话轮次频率和响应延迟量化参与度，调查问卷评估感知可靠性、对话连贯性和亲和度。现实使用的观察研究补充真实用户行为数据。
4. 衡量用户满意度
   用户最终应感到系统助其达成目标，并留下积极情感印象。可通过任务成功的显性反馈（如每次回答后的点赞/踩）、用户评论的情感分析及情绪与总体满意度调查来捕捉。

一种典型成功衡量方法是计算净推荐值（NPS），即询问用户“您有多大可能将本系统推荐给他人完成任务？”，评分0至10。9-10分用户为支持者，0-6分用户为反对者。NPS = 支持者百分比 – 反对者百分比，范围为+100（所有支持者）至-100（所有反对者），高于+30代表表现良好。

这四个视角——系统属性、技术性能、交互质量和用户满意度——共同提供了对智能体LLM系统实际表现的全方位、互补的认知。

鉴于智能体系统评估的复杂性，实践中通常在系统开发的不同阶段采用不同评估策略。若将智能体系统开发拆分为模型开发与训练、部署和生产监控三步，则在每个阶段侧重点各异的指标最为重要。

阶段1：模型开发、训练及集成到智能体系统中

当模型仍处于实验室阶段时，重点关注内在能力：

• 语言能力
  跟踪回答的连贯性和最终用户的理解情况。可以使用本章介绍的生成指标及相关工具进行评估。
• 集成情况
  测量智能体系统各组件在用户请求到来时的使用情况。测试是否恰当地调用了相关智能体。例如，若有一个执行数学计算的程序（计算器智能体），当用户输入数学问题时，应由协调型LLM调用此程序，确保实际运行与预期一致。若不符，可能需要调整协调型提示（prompt）。

阶段2：智能体系统部署

模型训练完成后，需要回答“用户是否信任并觉得该系统有用？”这一问题。

• 信任与可靠性
  使用基于调查的内部用户信任评分。前述的净推荐值（NPS）是衡量用户喜欢系统并认可其实用性的良好指标。
• 用户与智能体关系
  通过深入用户访谈和简短的用户满意度调查了解测试用户对系统的感受。
• 整体满意度与感知效果
  通过A/B测试、成功率统计和开放式文本反馈的情感分析，获得真实反馈。

内置调查组件便于在受控沙箱环境中收集这些数据，待确认后再向真实客户开放系统。

阶段3：生产环境

在大规模运行时，关注更高阶现象和运营健康状况：

• 智能体组件使用率
  检查各组件智能体的使用情况。你可能预先创建了多个专用智能体以应对用户负载，但若某些智能体未被使用，考虑关闭它们，将功能迁移至协调型LLM，以加快响应速度。
• 用户参与度
  以平均会话时长和单用户交互频率作为流失率的领先指标。用户是否完成任务？是否日复一日回归完成更多任务？
• 计算效率
  和任何计算系统一样，监控计算资源。记录平均任务完成时间和资源利用率（CPU/GPU），及时发现瓶颈，避免云服务费用激增。

通用评估注意事项

最终，你的系统能否成功取决于用户体验。自动化指标的主要目标是及时发现错误，改进系统，从而提升用户体验并避免用户挫败感。然而，只要条件允许，应开展长期的用户研究，追踪用户在使用产品过程中的信任度和满意度变化。

净推荐值（NPS）是一项简单且有效的一问式成功指标，因此被广泛应用于众多行业。

满意度小工具也非常实用，例如在每次回复后添加“点赞”和“点踩”按钮，收集用户对真实交互的反馈。

你还可以使用商业监控平台，如Weights & Biases，或使用本章前述的LangSmith工具自定义指标，监控生产环境中的系统表现。LangSmith能够自动评估智能体系统的输出，Weights & Biases则可收集指标、展示仪表盘，并在指标低于你设定的阈值时发出警报。

通过整合即时用户反馈渠道，你可以从用户交互中学习，持续改进应用。这个反馈收集与应用更新的迭代过程确保系统不断适应用户偏好，最终提升信任与满意度。

自动化指标的价值

如第6章所示，自动化指标极大简化了判断改动是否提升应用效果的过程。举例来说，假设你有一款基于文本描述图像的应用，现有提示的NPS为90%，但一篇新论文提出另一种提示技巧（例如使用项目符号）。如果指标自动化，你可以轻松进行A/B测试，将现有提示的输出给A组，将新提示的输出给B组。你预计A组NPS接近90%，若B组NPS更高，就可以决定全面采用新提示。

A/B测试另一应用是提升计算效率。LLMOps从业者常尝试在保证性能的同时缩减提示长度。因大多数LLM按提示长度计价或计资源消耗，使用最短满足质量要求的提示尤为重要。你甚至无需自己编写缩减提示，可让LLM在保持原意和意图的基础上总结或压缩提示。借助自动化指标，你能测试多条提示，选择最短且满足性能的版本，节省大量成本和资源。当然不使用自动指标也能完成，但耗时更长。

模型漂移

LLM持续开发更新，新的模型和版本层出不穷。应用性能可能因模型变化发生漂移，有时提升，有时下降。如果不测量，你无从知晓。

举例来说，热门的GPT-3.5 Turbo有四个版本，其中前两个版本于2025年2月13日停止服务。设置了“自动更新”的用户调用过时版本时，会自动切换至最新版；未设置自动更新的用户则收到错误。

在这两种情况下，LLMOps均能发挥作用。后者更明显，因为即使是最基本的监控系统（如大量不满用户的投诉邮件）也能捕捉异常。

而前者，即模型自动切换版本，可能带来意想不到的问题。比如，你之前为防止旧版本错误设计的防护措施，在新版本可能不再必要。常见例子是大量提示内容用于防止偏见和攻击。新版模型通常内置多种防护，继续在提示中包含这些措施可能浪费资源。

更棘手的是性能意外下降的情况。某些对旧版本有效的提示，出于未知原因可能对新版本失效。

理想情况下，你应提前获知版本变更，以便在两个版本并存期间进行测试和调整。但并非所有最初AI热潮期开发的应用都具备完善的指标和监控，许多开发者在云端模型提供商后端变更后，遭遇应用突然失效或结果改变而措手不及。

传统指标远远不够

如我们之前在RAG和智能体评估章节中讨论的那样，准确率（accuracy）和损失（loss）等标准指标长期以来一直是模型训练和验证阶段性能的基础衡量手段。这些指标有效量化了模型对训练数据的拟合程度以及对验证集的泛化能力。然而，当模型部署到复杂的现实生产环境后，它们无法捕捉到那些细微且多面的失败模式。

在生产环境中，模型输出可能语法流畅、风格优雅，但却潜藏幻觉、潜在偏见或结构不一致等问题，而传统的准确率或损失等指标根本无法发现这些问题。这些细微缺陷往往会带来严重的下游影响，比如传播错误信息、引发伦理违规或导致用户不满。

因此，生产级别的评估需要专门设计的工具集和框架，支持对模型行为的持续实时监控。这些系统聚焦于异常检测、数据和概念漂移跟踪、用户影响评估以及新兴伦理风险识别。有效评估不仅仅是识别失败模式，更要求构建全面的可观测性流水线，能够早期且高精度地捕获这些失败。

这类可观测系统必须能追踪错误产生的精确环节——无论是输入预处理、检索组件、生成模型本身，还是后处理层。这种细粒度的映射使工程团队能够快速开展根因分析、确定修复优先级，并有信心推行缓解措施。这样，主动的端到端监控基础设施将评估从事后补救转变为战略性、不可或缺的一部分，以确保大规模LLM系统的可靠性、安全性和伦理完整性。

可观测性流水线

评估不能再是生成回答后的事后补充，而必须贯穿LLM流水线的全过程，从初始输入到最终用户反馈（见图7-4）。

预处理与提示构建

LLM部署失败往往不是模型本身的问题，而是源于其接收到的提示。在生产环境中，提示很少是固定的、手工编写的片段。相反，提示通常是动态生成的，基于模板组装，并根据上游数据源或用户状态变化进行参数化。这种动态特性带来了复杂性和多样性，若管理不当，会悄然削弱系统性能。

提示阶段的评估聚焦几个关键维度。首先，提示必须语法有效，格式正确，无误导解析或分词的错误。其次，提示需语义连贯，提供清晰、无歧义的指令，与模型预期的输入格式保持一致。第三，提示模板及其变体需严格进行版本控制。通过记录每个提示版本和结构变动，团队能实现追踪，将下游推理错误直接关联到具体提示修改。

为防止推理阶段出现连锁失败，需及早检测格式错误的输入，如缺失上下文变量或参数注入错误。监控提示令牌长度分布是重要运维实践。过长提示可能被截断，导致关键信息缺失，影响输出质量；过短提示则可能上下文不足，无法为模型提供生成准确相关回复所需信息。持续跟踪这些分布，团队能主动发现退化并在影响用户体验前干预。

随着提示工程逐步规范化，该阶段评估也从被动调试转向基础流水线治理模式。此转变强调系统化监督、可复现性与受控迭代，确保提示生成成为整体LLM推理流水线稳定可靠的基石。

RAG流水线中的检索

在RAG系统中，失败往往源于检索环节而非LLM本身，因此评估检索性能至关重要。评估涵盖多个维度：检索文档的上下文相关性、信息的新鲜度，以及是否及时满足查询意图和领域需求。

有效的RAG可观测框架应记录每次用户查询检索到的确切文档集合，以便事后分析和结果复现。量化指标如检索文档与权威真实来源间的相似度分数，为检索准确性提供客观衡量。检索延迟监控同样重要，因为文档获取延时直接影响系统响应速度和用户体验。

嵌入相似度漂移检测是该场景中极具威力的评估技术。通过持续追踪查询和文档的向量分布统计，团队可发现微妙漂移，预警检索质量下降。这类漂移常是幻觉或模糊无关回答等明显故障的先兆，源自无关或过时文档。检测到漂移后，可及时采取措施，如重新训练检索器、更新索引和重构检索流程。

缺乏细粒度观测，难以区分失败是检索问题还是生成阶段的问题。因此，覆盖检索与生成组件的评估流水线对保障RAG驱动的企业级LLM系统的可靠性、准确性和用户信任至关重要。

LLM推理阶段

推理阶段的关键指标涵盖多个维度。事实准确率评估生成文本是否与可验证事实一致，幻觉率衡量幻觉出现频率。流畅度评价输出的可读性与连贯性。延迟监控响应时间，直接影响用户体验和系统吞吐。

为支持深入诊断，观测系统必须为每次推理调用记录详细元数据：

• 输入输出令牌数揭示使用模式及可能截断情况。
• 温度及其他采样参数说明生成的概率性质。
• 模型版本信息有助于追踪性能变化对应的代码或模型更新。
• 生成长度骤变可能暗示截断错误或潜在故障，虽不易从表面响应观察到，但该指标尤为重要。

除了表面指标，内部评估技术提供额外质量保障层。自一致性检查通过比较同一提示的多次生成，发现表面流畅却前后矛盾的回答。辅助评估器或专业分类器给出的置信度分数，有助标记偏离预期事实或伦理标准的输出。

推理通常非独立过程，而是嵌入包含多次调用、检索和后处理的复杂链路或流水线中。这时结构化日志和追踪可视化工具显得尤为重要。它们支持实时监控、根因分析，帮助团队精准定位复杂工作流中的失败或效率瓶颈。综合这些观测实践，推理评估从被动测量转变为主动治理机制，是确保部署LLM系统可靠性、准确性和可信度的核心环节。

后处理与输出校验

在生成阶段结束后，输出通常会经过后处理阶段，包括格式化、清理和结构调整，以准备将数据交付给最终用户或下游系统。尽管这一步看似简单，任何微小的结构性错误都可能在整个应用栈中引发级联故障。

后处理阶段的评估侧重于结构校验，验证生成输出是否符合预期格式。例如，确保JSON响应语法有效，严格遵循预定义模式，并包含所有必填字段。因为即便输出语法正确，若关键数据缺失或格式错误，功能上仍可能无法使用。

自动化工具在此环节至关重要。模式校验器系统性检查结构完整性，其他自动化检测可发现空白结果或可能干扰后续处理的异常。在高风险领域和合规性关键应用中，后处理阶段未被发现的错误可能引发隐性故障甚至法规违规，后果严重。

将后处理提升为系统流水线中正式、可评估的阶段，团队能主动发现并修复结构性问题，防止其扩散。此举将后处理由被动格式化步骤转变为确保生产环境输出可靠性、正确性和合规性的关键关卡。

捕获反馈

反馈数据包含用户评分、点赞/点踩、直接文本反馈及隐含行为指标，如参与时长、查询放弃率和升级至人工客服的频率。

持续捕获并整合这些反馈，能将评估扎根于真实用户体验，揭示静态内部基准和离线测试可能忽略的细微缺陷与失败模式。本阶段指标是重要的可用性信号，直接指导系统优化优先级，包括停留时间（用户与生成内容互动时长）、放弃率（表明用户挫败或不满）、重试频率（反映回答不明确或无效）。

评估平台如LangSmith支持基于评分标准的输出打分，维度涵盖事实性、相关性和结构正确性。评分附带元数据（模型版本、提示变体、上下文信息），实现细粒度追踪和纵向性能分析。

随着人机协同微调和奖励建模等方法成熟，反馈从被动测量工具转变为持续改进的主动驱动力。用户信号成为训练数据，动态引导模型更新和流水线调整，闭环连接部署与迭代。

流水线的每个阶段都提供系统健康的独特且互补的洞察。其真正价值在于将这些观察整合入端到端可观测框架。这种互联可视性对在动态生产环境中维持强健、可靠且以用户为中心的LLM应用至关重要。

本质上，可观测性是异常检测问题。你需要在系统的指标、日志、追踪和输出中发现偏离预期行为的模式。类似烟雾探测器，目标不是捕捉每一个微小问题，而是及时发现那些关键且可能演变为严重故障的问题。你可能已在训练中建立了LLM的评估指标，而这些可观测指标则覆盖流水线剩余部分。你可以通过以下四个阶段来实现，每个阶段各有优势：

阶段1：基于阈值的告警
最简单形式。为关键指标设置明确限制，如API响应时间超过2秒或令牌数超过1024。超过阈值时，Prometheus收集数据，Grafana触发告警，通过Slack或问题追踪系统通知团队。实现快捷直接，但阈值静态，可能漏检复杂或变化中的问题。

阶段2：统计异常检测
超越固定阈值，利用滚动统计（移动平均、z分数）分析指标行为。例如，延迟突然飙升且z分数高，提示异常。Grafana仪表盘配合AlertManager标记偏离，结合LangSmith等追踪工具定位触发告警的请求或输出。此法适应正常波动，降低误报。

阶段3：漂移检测
监控输入数据或检索质量变化，防止AI性能随时间下滑。如用户查询变化或检索嵌入相似度降低，提示数据或检索可能陈旧。借助FAISS等库分析嵌入，使用LangChain等框架监控流水线，及早发现漂移。自动化工作流则刷新检索器或重训模型，保持系统准确和相关。

阶段4：反馈信号监控
用户反馈和回退行为直观反映系统健康。正面评分下降或回退（默认）响应增加，意味着用户体验问题或模型退化。LangSmith和MLflow等工具将反馈关联至具体模型版本和部署，帮助团队诊断根因，决定是否回滚或重训。

一个健壮的可观测系统融合上述四层。以下工具为一般建议，你也可继续使用现有技术栈：

• Prometheus：采集运行时指标（CPU、内存、延迟、令牌使用量）。
• Grafana：提供实时仪表盘及基于阈值和统计异常的告警。
• MLflow/ZenML：追踪模型版本和实验元数据。
• LangSmith：提供追踪级洞察，连接反馈信号与模型表现。

我在此不特指推荐具体工具，而是提供参考。无论选择何种工具，或完全手工实现，最重要的是实施技术。通过叠加简单阈值告警、自适应统计方法、漂移检测与用户反馈监控，你能构建覆盖明显违规到细微性能退化的全方位评估流水线。

结论

本章介绍了通用的LLM评估指标，并针对两个具体场景——RAG系统和多智能体系统，提出了额外的评估考虑。自动化指标采集的重要性不可低估，它往往决定了你的应用是成功且受信赖，还是面临大量用户投诉的局面。

本章侧重于适用于各种具体指标的一般原则，同时也介绍了撰写时最新的指标和评估框架。请记住，这是一个非常活跃的研究领域。虽然新指标可能随时出现，但其核心原则将保持不变。

参考文献

• CoreWeave. 未注明日期。《Weights & Biases》，访问时间：2025年5月21日。
• Es, Shahul 等人。《Ragas：检索增强生成的自动化评估》，arXiv，2025年4月。
• Fu, Jinlan 等人。《GPTScore：按需评估》，arXiv，2023年2月。
• Hendrycks, Dan 等人。《大规模多任务语言理解测评（MMLU）》，arXiv，2021年1月。
• Honovich, Or 等人。《TRUE：重新评估事实一致性评价》，arXiv，2022年5月。
• LangSmith. 未注明日期。《LangSmith入门》，访问时间：2025年5月21日。
• Lin, Stephanie 等人。《TruthfulQA：衡量模型模仿人类谬误的能力》，arXiv，2022年5月。
• Liu, Yang 等人。《G-Eval：使用GPT-4进行更好人类对齐的自然语言生成评估》，arXiv，2023年5月。
• Machan, J. J. 未注明日期。《Ragas》，访问时间：2025年5月21日。
• Manakul, Potsawee 等人。《SelfCheckGPT：针对生成型大型语言模型的零资源黑盒幻觉检测》，arXiv，2023年10月。
• Wang, Alex 等人。《GLUE：自然语言理解的多任务基准及分析平台》，arXiv，2019年2月。
• Wang, Alex 等人。《SuperGLUE：通用语言理解系统的更具挑战性基准》，arXiv，2020年2月。
• Wei, Jason 等人。《链式思维提示激发大型语言模型推理能力》，arXiv，2023年1月。
• Zellers, Rowan 等人。《HellaSwag：机器能否真正完成你的句子？》，arXiv，2019年5月。
• Zhong, Ming 等人。《面向文本生成的统一多维评估器》，arXiv，2022年10月。