用 Langfuse 打造终极 LLMOps 体系——LLM 监控原则

引言

监控 LLM 并不只是验证它们是否在运行；它还要确保它们持续交付符合准确性、效率和安全目标的结果。本章介绍 LLM 监控的基础原则，并说明这些实践与传统软件可观测性有何不同。它讨论了多个监控维度，例如性能、成本、安全性和伦理考量。本章还覆盖了如何制定监控策略，以支持持续改进，并在速度、准确性、用户体验和负责任的 AI 实施之间取得平衡。读完本章后，读者将掌握一组原则，用于建立能够随着应用一起扩展的 LLM 监控框架。

结构

本章将覆盖以下主题：

• LLM 中的监控与可观测性
• Trace 与 Span
• 面向 LLM 的站点可靠性工程
• SRE 如何应用于 LLM
• 服务等级指标（SLIs）与服务等级目标（SLOs）
• 错误预算
• 在监控中管理错误预算
• 有效 LLM 监控的原则
• 在语义层进行监控
• 用户反馈
• 平衡性能、成本与质量指标
• 监控漂移
• 监控安全与合规指标
• 监控的维度
• 功能性监控
• 非功能性监控
• 伦理监控
• 安全监控
• 典型 LLM 应用的监控维度
• 内容生成系统
• 检索增强生成（RAG）应用
• 聊天机器人
• AI Agent

LLM 中的监控与可观测性

让我们从理解监控与可观测性在概念上的区别开始本节内容。简短地说：监控告诉我们出了问题；可观测性告诉我们为什么出了问题。

监控与可观测性并不局限于 LLM，它们是系统工程中的通用概念。可观测性的概念甚至可以追溯到 20 世纪 60 年代，由匈牙利裔美国工程师 Rudolf E. Kálmán 提出。他将其定义为：根据系统外部输出推断系统内部状态的能力度量。 在软件工程类比中，这意味着通过查看日志、指标、事件或任何其他输出来判断我们的应用正在发生什么。一个很好的例子是错误发生时日志中出现的堆栈跟踪。它通过展示导致错误的一系列方法调用，暴露了应用的内部状态。对于基于 LLM 的应用，我们不仅需要日志或指标来实现可观测性，还需要用 LLM 特有的元素进行补充，例如 prompt、检索到的文档（对于 RAG 应用），或者在涉及推理模型时的推理步骤。

另一方面，监控更线性地适用于 LLM 应用和其他软件系统。它关注的是追踪表明系统行为方式的信号；差异只在于要追踪什么。我们在第 1 章《大语言模型与监控导论》中已经看到了一些对 LLM 有意义的信号，也就是指标：延迟、成本、Token 使用量、幻觉、完整性、相关性和正确性。

总结来说，监控与可观测性是互补的：监控通过追踪已定义的指标来识别问题何时发生；而可观测性则通过根因分析帮助我们理解问题为什么发生。两者结合起来，可以在 LLM 应用中同时支持问题检测和问题诊断。

Trace 与 Span

在可观测性中，trace 可以定义为一个请求在系统中流转时的完整执行路径。一个 trace 由多个 span 组成，每个 span 都是请求生命周期中一个独立的、有时间记录的操作。Span 甚至可以嵌套在其他 span 之中。我们可以在 Web 应用中看到一个基础示例：当你访问一个页面或提交一个表单时，就会启动一个新的 trace。这个 trace 可以包含许多 span，每个 span 代表一个步骤，例如认证用户、查询数据库、调用 API 等等。每个 span 都有开始时间和结束时间、状态信息，也可以有自定义属性。通过分析 span，可以发现延迟瓶颈、应用错误，或者监控系统中特定组件的健康状态。

图 2.1：Trace 与 Span

下面是一个基于 RAG 的聊天机器人中，当用户提出问题时，一个 trace 中的 span 可能呈现的样子：

Trace: User Query "What is the best way to get started with Langfuse?”
|
+-- Span A: Retrieve Developer Documents from langfuse.com
|    |
|    +-- Span B: Re-rank Documents based on relevance
|          |
|          +-- Span C: Construct a Prompt for the LLM using the documents
|                |
|                +-- Span D: LLM Generates Answer
|                      |
|                      +-- Span E: Post-process the Output to the user’s needs

在 Langfuse 中，Trace 是可观测性的最基本单元。要使用 Langfuse 平台，我们首先需要做的，就是把应用的 trace 发送到 Langfuse。具体如何完成这件事，会在第 5 章和第 6 章中详细介绍。之后我们所做的所有监控，都将围绕这些 trace 展开。我们追踪的指标也会附着到 trace 之上。

Langfuse 对 span 使用了略有不同的术语。在 Langfuse 中，span 实际上被称为 observation。Langfuse 中的一个 trace 由多个 observation 组成，这些 observation 会提供 trace 中不同步骤的更多信息。Observation 也可以根据步骤的不同而有不同类型。在 Langfuse 中，还有许多面向 LLM 的特定 observation 类型，例如 generation、retriever、tool call 等等。我们会在第 5 章《Langfuse 中的可观测性》中更详细地介绍这些内容。

面向 LLM 的站点可靠性工程

站点可靠性工程，也就是 Site Reliability Engineering，简称 SRE，是一门起源于 Google 的学科。它在 2003 年被提出，作为监控和提升软件系统可用性的一种方式。此后，SRE 被行业广泛采用，用于平衡运维稳定性与开发速度。SRE 与监控之间有很深的关联，因为监控提供了 SRE 实践所依赖的信号。SRE 会把这些被监控的信号，也就是 SLI，形式化为目标，也就是 SLO，以及承诺，也就是 SLA，然后通过错误预算、告警和事故响应等机制来管理可靠性。当应用到基于 LLM 的应用时，SRE 的概念是相同的，但“可靠性”的定义会从基本的正常运行时间，扩展到包括语义正确性和行为正确性。

SRE 如何应用于 LLM

SRE 的设计初衷，是在不减缓创新的前提下保持大规模软件系统的可靠性。同样的理念也自然适用于基于 LLM 的应用。SRE 为 LLM 监控提供了一个结构化框架，它会将抽象问题，例如幻觉或不安全输出，重新表述为可度量的指标、目标和预算。这有助于团队在安全性、可靠性和快速创新需求之间取得平衡。

应用 SRE 原则可以确保可靠性并不只由基础设施健康状况来定义，还包括模型输出的质量和可信度。一个 LLM 系统可能是“在线”的，也能响应请求，但如果它在编造事实、泄露敏感信息，或者生成有偏见的输出，那么它从根本上说仍然是不可靠的。SRE 实践可以被调整用于定义和追踪可靠性指标，例如输出一致性、语义正确性和用户参与度，从而维持基于 LLM 的应用的可信度。

服务等级指标（SLIs）与服务等级目标（SLOs）

在 SRE 中，核心思想是可靠性必须以某种形式被量化。这是通过服务等级指标（Service Level Indicators，SLIs）和服务等级目标（Service Level Objectives，SLOs）来完成的。SLI 是一个具体的、可度量的指标，它从用户视角反映服务质量，例如请求延迟、错误率或系统可用性。SLO 则是为该 SLI 设定的目标或阈值，例如“99.9% 的请求应在 200 毫秒内完成”。SLI 和 SLO 合在一起，为工程团队和业务团队提供了一种共同理解：SLI 捕捉指标，SLO 定义预期，两者共同驱动运维决策。

正如我们在本节开头看到的，在 LLM 中，可靠性的概念会被拓宽。这意味着 LLM 的 SLI 必须捕捉诸如幻觉、RAG 中的 grounding 成功率，或者不含有毒或有害内容的安全响应比例等质量。相应地，SLO 会变成这样的表述：“95% 的回答必须引用检索到的来源”，或者“少于 1% 的输出应触发毒性过滤器”。类似地，对于面向客户的聊天机器人，一个 SLO 可以被定义为：“至少 90% 的会话应该在不需要人工客服介入的情况下解决客户问题。”

SLI 与 SLO 的组合，为我们提供了一种具体方式来衡量可靠性，并打开了在实验创新和维护系统稳定性之间进行优先级排序的路径。当 SLO 得到满足时，团队可以安全地实验新的 prompt 或模型版本；当 SLO 未被满足时，稳定性应优先。

错误预算

错误预算听起来可能会和成本令人困惑地相似，但在 SRE 中，它被定义为允许失败的边际。当我们说“99% 的模型回答不会是有毒的”时，实际上也意味着有 1% 的时间可能不是这样。因此，这里的 1% 就成为该 SLI 的错误预算。之所以将其视为“预算”，是因为它限制了我们在不破坏已经承诺的稳定性基础上，能够在新功能上进行多少实验。

在基于 LLM 的应用中，一个“错误”可能是一次幻觉、一次不安全回答、一次未能基于检索内容进行 grounding 的失败，甚至是成本超支。

错误预算会随着用例不同而变化。对于创意领域中的内容生成，这个数字甚至可以超过 5%，尽管并不是每个 SLI 都可以如此。而对于关键的面向客户聊天机器人，这个数字可能要低得多。错误预算总是绑定到一个时间窗口上，例如每周、每月。这确保它们会随着时间被摊平，而不是让实验长期停摆。

在监控中管理错误预算

在衡量或追踪错误预算之前，我们应该先清晰定义它们，以便理解。这意味着要提前知道系统的 SLI 和 SLO。对于一个 LLM 应用来说，这转化为要在语义层面确定什么构成失败，除了停机、延迟等等之外。幻觉是不是你的应用最大的风险？或者，从知识库中检索出错误文档才是最大风险？所有这些失败都应该被量化，这样后续才能被测量和追踪。

设想我们运行一个由 LLM 驱动的摘要 API，企业客户用它把报告、审计材料、研究论文等长篇内部文档转换为简明摘要。我们定义一个 SLO：“96% 的摘要必须准确、忠实于源文档，并在 4 秒内生成。”

为了支持这个 SLO，我们追踪三个 SLI：

忠实度分数：
每个摘要与源文档匹配得有多接近，可以通过语义相似度或基于 LLM 的评分来衡量。

覆盖度分数：
摘要是否包含用户期望的所有关键点。

延迟：
摘要接口需要多长时间响应。

如果到月底时，该服务只有 92% 的时间满足 SLO，那么它已经消耗了相当大一部分错误预算。也许是一次 prompt 变更让摘要更有创造性，但降低了忠实度；或者最近一次模型升级让加载时间增加了一秒。无论哪种情况，系统现在都需要先做稳定性工作，例如调优 prompt 模板、使用缓存、采用更小的模型变体，然后再发布新功能。

我们会在后续章节中看到，Langfuse 如何将监控与仪表盘创建结合起来，使团队能够持续追踪错误预算已经被消耗了多少。如果我们看到预算已被消耗，就可以冻结新功能发布，并优先稳定 SLI。

有效 LLM 监控的原则

现在我们来看一些可以应用于 LLM 监控的指导原则。到目前为止已经很清楚，LLM 是复杂的。监控 LLM 应用要求我们超越传统软件系统的操作手册。延迟、正常运行时间和错误码仍然重要，但它们只讲述了一部分故事。在基于 LLM 的系统中，真正重要的是模型是否生成准确、安全、成本有效，并且符合用户意图的输出。为了实现这一点，监控必须由一组原则来指导，这些原则会把可观测性扩展到 AI 所特有的语义层和行为层。下面这些原则勾勒了如何设计监控系统，使其不仅能检测失败，还能解释失败为什么发生，以及它们如何影响用户和业务。

在语义层进行监控

在处理 NLP 时，语义，也就是文本的含义，是最重要的事情。在 LLM 系统中，即便服务本身是“健康”的，模型也可能生成语义上不正确的输出，也就是幻觉。这意味着，如果我们的监控方案只是测量 CPU / 内存使用率、延迟和正常运行时间这样的指标，那它只完成了一半。有效的监控必须延伸到语义层，并直接关注内容质量。语义监控应该包括：

事实准确性：
通过与可靠数据源或人工审查交叉验证，检查回答是否基于现实。

相关性：
如果一个回答没有直接回答用户的问题，或者添加了无关细节，即使它看起来不错，也可能被认为是坏回答。

一致性：
经常会发生这样的情况：模型在长对话中，或者在反复询问同一个问题时，给出相互矛盾或不稳定的回答。缺乏一致性可能削弱客户信任，并降低系统可靠性。

用户反馈

LLM 运行在一些正确性往往具有主观性或依赖上下文的领域。针对语义含义的自动化指标是存在的，但它们并不总是能反映真实世界中的有用性。用户交互是模型质量最强的真实世界信号。因此，一个核心原则应该是系统性地捕获显式信号，例如点赞 / 点踩、评分等等，以及隐式信号，例如用户重新提问、升级给人工客服等等，并将这些信号反馈到我们的监控系统中。

收集用户反馈没有唯一方式，这实际上取决于应用目标，以及我们想如何捕获用户反馈。工具选择甚至也会受到用户是谁、我们打算以什么形式收集反馈的影响。本质上，一个好的用户反馈机制应该包括：

结果质量：
用户是否真的喜欢这个回答？这可以是简单的点赞 / 点踩，也可以是数字评分系统，例如 1–5 分、1–10 分等等。

响应速度：
大多数用户都很在意时间。他们会期望响应快速返回，较慢的响应可能导致用户不满。

开放式回答：
为回答提供自由文本或评论区，可以让用户指出问题，甚至提出改进响应质量的建议。

监控漂移

不同于其他软件系统，LLM 应用会暴露在不断变化的数据中，例如检索文档、演进中的业务规则，以及变化的用户行为。因此，监控必须包括漂移检测：

数据漂移：
检索结果是否正在拉取相关性更低或已经过时的文档？

行为漂移：
模型是否开始给出比以前更长、更模糊的回答？

我们会在下一章更详细地介绍漂移。但现在只需要理解：漂移检测确保系统随时间保持可靠，因为即便 LLM 本身稳定或没有变化，在运行时喂给 LLM 的外部数据源也可能随着时间变化或退化。

平衡性能、成本与质量指标

监控 LLM 并不只是关于准确性；成本和性能同样关键。高质量回答如果需要很久才返回，或者消耗过多 token，在生产环境中可能无法接受。这里的一个原则是同时追踪延迟、吞吐量、token 使用量和准确性，因为优化其中一个指标，常常会损害另一个指标。每个系统都有它需要遵守的业务约束，因此在决定优化哪些指标时，需要取得平衡。

监控安全与合规指标

LLM 可能生成不安全、有偏见或不合规的输出。监控必须显式追踪并标记安全维度，例如毒性、个人身份信息（Personally Identifiable Information，PII）泄露，以及不同人口群体之间的偏见。这些指标应该像延迟或成本指标一样处于核心位置。在今天的世界里，安全不应该是事后考虑的问题；它必须与技术 KPI 一起被实时监控。

下表展示了每项原则可以追踪的一些指标示例。这并不是一个穷尽列表，只是为了在设计适合系统需求的监控策略时提供一些方向感。

原则	需要监控的指标
语义层	幻觉、相关性、对来源的忠实度
用户反馈	点赞 / 点踩、重复提问、升级到人工的比例、用户满意度
漂移检测	文档新鲜度，也就是检索文档的年龄；回答长度趋势；查询主题分布
性能与成本平衡	延迟、Token 使用量、成本
安全与合规	毒性、偏见、PII 暴露、越狱尝试、Prompt 注入尝试

表 2.1：每项监控原则需要监控的指标

监控的维度

在设计 LLM 监控策略时，将指标按照其适用的不同影响领域进行划分会很有帮助。在真实应用中，我们想要监控的指标列表可能非常庞大。对它们进行分组，会让它们更容易管理；当需要可视化呈现时，也能按类别看到系统在每个维度上的表现。这四个维度合在一起，旨在提供一个全面的监控框架。

功能性监控

这是监控的基础入门：它确保系统针对相应输入交付正确输出。换句话说，系统是否在做它应该做的事？这一维度关注的是相对于当前任务，对输出质量、准确性和相关性的监控。

从系统构思的那一刻起，我们就需要监控功能性指标。大多数正确功能性的指标，从第一个输出开始就已经可见。即使是在设计最小可行产品（Minimum Viable Product，MVP）时，这类监控也是必不可少的。功能性监控的典型例子包括：

• 监控代码生成 LLM 是否生成语法正确、能够无错误运行的代码。
• 在电子商务应用中，搜索助手是否帮助找到符合用户意图的产品。
• 在研究某个主题时，LLM 是否检索到该主题下最相关的内容。
• 如果一段文本需要翻译成一种或多种语言，LLM 是否生成了对目标语言来说准确的翻译。

非功能性监控

非功能性监控关注的是系统质量，而不是输出正确性。这些质量包括性能，例如速度或资源使用，可扩展性，以及成本效率。虽然非功能性指标看起来可能像是在后台运行，但它们已经不再是一组可以忽略到应用后续迭代才处理的可选指标。

正确性很重要，但在实践中，很多 LLM 应用都会产生同样正确的答案。将优秀系统与普通系统区分开的，往往是非功能性特征：速度、效率、成本和可扩展性。例如，一个 2 秒内响应的聊天机器人，会比一个需要 10 秒响应的聊天机器人创造好得多的用户体验，即使二者给出的答案同样优秀。同样，两个 RAG 系统可能生成同样好的摘要，但如果其中一个少消耗 50% 的 token，它对企业采用来说就会更有吸引力。这些指标之所以重要，是因为它们直接影响可用性、客户满意度和长期可持续性。

如果长期忽视非功能性监控，应用质量可能会在无声中退化；在负载增加时，我们的应用甚至可能变得不可用。成本超支甚至可能拖垮项目，使其在财务上不可持续。

伦理监控

列表中的下一个维度是 LLM 的标志性特征。LLM 需要伦理监控，是因为这些模型在大量由人类创建的文本上训练。这些文本的规模有时甚至连模型创造者自己都无法完全理解。训练数据包括来自互联网、书籍，甚至社交媒体的内容，它并不总是安全的，并且天然包含有偏见或不真实的信息。在应用中使用 LLM 时，确保系统行为符合人类价值观，是这些应用开发者的责任。

这一维度中的指标更难自动化，但可以包括偏见分数、公平性，以及收集用户对于感知伦理性的反馈。伦理监控对于建立用户信任，并遵守组织或监管标准至关重要。

这种类型的监控未必适用于每一个 LLM 系统，但在决定不采用它们之前，应该进行彻底审查。如果我们正在设计一个处理或筛选真实人物信息的系统，或者系统运行在教育、医疗、法律等关键领域，那么就应该使用伦理监控，以确保系统不会歪曲事实，或者生成针对任何人的有偏见内容。

安全监控

虽然安全与伦理紧密相关，但安全更关注直接风险，例如有害内容、安全漏洞和滥用。它的指导问题是：“在真实世界条件下，这个系统使用起来安全吗？”

安全监控尤其在对话式应用中非常关键，因为用户会直接与系统交互，在输入侧或输出侧产生不安全内容的可能性都会上升。安全监控可能会追踪生成有毒或辱骂性语言的比例、获取敏感数据的尝试，或者成功的 prompt 注入攻击。在许多情况下，它还包括监控个人身份信息（PII）泄露等风险。对于当前 LLM 的高级使用方式来说，安全监控是不可协商的，它也是保护组织免受声誉或法律损害的关键。

我们会在第 9 章《管理、LLM 安全与护栏》中讨论 LLM 安全时，简要介绍 Guardrails。Guardrails 就像围绕模型的安全网，确保即使底层 LLM 试图生成有风险的内容，系统也会在响应到达用户之前拦截、过滤或重定向它。

下面是我们已经看到的四个维度的快速总结：

维度	目标	关键指标	不监控的风险
功能性	确保输出正确、相关且有用	准确性、相关性、幻觉	用户收到误导性或无用的回答
非功能性	确保性能、可扩展性和成本效率	延迟、Token 使用量、成本	即使输出正确，系统也会显得缓慢、昂贵或不可用
伦理	确保公平性、包容性，以及与价值观一致	偏见、公平性	模型放大偏见或排除某些群体，导致声誉或法律风险
安全	防止伤害、滥用或合规违规	毒性、PII 泄露、越狱 / Prompt 注入尝试	用户暴露于有害内容、敏感数据泄露、安全漏洞

表 2.2：监控维度总结

典型 LLM 应用的监控维度

现在我们已经理解了 LLM 监控的维度，让我们看看如何把它们应用到可能构建的不同类型 LLM 应用中。这里不会覆盖每一种类型，但至少会提到最典型的几类。

内容生成系统

让我们从一个简单的 LLM 应用开始。生产文本或生成内容，是所有 LLM 使用的基础。这类系统的概念很简单：我们拿一个 LLM，并给它一条指令，也就是 prompt，让它生成任意类型的内容。这可以包括创建产品描述、为假期建议行程，甚至生成我们正在开发的项目代码。在所有这些场景中，输出都是开放式且带有主观性的。因此，监控会涉及功能性与非功能性两个方面的混合。

功能性监控

准确性与流畅性：
追踪生成文本在相应语言中是否语法正确、逻辑结构清晰且可读。

任务遵循度：
监控输出是否符合用户指令。

原创性：
确保内容不过度重复，也没有抄袭。

非功能性监控

延迟：
衡量输出生成速度。

Token 使用量：
监控每个输出的平均 token 数量与预期长度之间的关系。

吞吐量：
尤其在处理批量内容请求时，追踪性能。

单项成本：
确保内容创建成本低于人工替代方案。

伦理监控

偏见：
监控输出中是否存在刻板印象、排他性语言或不平衡表达。

包容性：
追踪生成内容是否在文化上合适，并避免冒犯性措辞。

透明性：
在需要时，确保生成文本被标注为 AI 生成。

安全监控

毒性过滤器：
监控输出中是否存在脏话、仇恨言论或有害内容。

知识产权与抄袭风险：
追踪生成内容是否与受版权保护的材料过于相似。

护栏：
防止生成推动有害活动或讨论敏感话题的内容。

检索增强生成（RAG）应用

RAG 是最早被开发出来用于补充 LLM 的技术之一。它只有一个目标：帮助检索并增强模型现有知识之外的新信息，而模型的现有知识来自预训练或微调阶段。直到今天，RAG 仍然被广泛用于构建个性化的 LLM 驱动应用，这些应用可以回答关于特定主题或专有主题的问题。这类信息在模型开发的早期阶段通常不可能真正可用，要么因为这些信息是私有持有的，要么因为这些信息是在很近期才出现的。下图以最简单的形式展示了 RAG 组件：

图 2.2：检索增强生成

正如我们在这里看到的，RAG 有很多步骤，并且每一步对获得最终答案都至关重要。此外，RAG 本身也可能是整体应用中的一个组件。从监控视角看，这里有很多环节需要覆盖。这里需要两层监控：

检索：
确保获取到的是正确文档。检索本身可能是一个多步骤过程，包括获取文档、重新排序文档，并在发送给 LLM 之前对上下文进行后处理压缩。

生成：
检查 LLM 是否使用获取到的文档生成了正确回答。

现在让我们看看，四个监控维度如何应用到这里：

功能性监控

Grounding / 忠实度检查：
生成回答应基于获取到的文档，同时在事实层面保持正确。

检索相关性：
追踪检索到的文档是否真正有助于回答问题。

上下文精确度：
监控检索到的文档是否覆盖了用户查询的广度。

答案质量：
使用自动化评估指标或人在回路评估来评估准确性和完整性。

非功能性监控

延迟：
分别衡量检索和生成的延迟，以识别整体流水线中的瓶颈。

Token 使用量：
过量检索可能导致 token 使用量激增。我们需要监控使用量，以评估添加额外上下文是否真的帮助 LLM 得到更好答案。

负载下的可扩展性：
追踪检索吞吐量，以确保向量数据库在负载下能够扩展。

成本监控：
基于 RAG 的应用除了使用 LLM 本身的常规成本外，还会因为索引文档产生额外成本。

伦理监控

来源偏见：
监控检索是否过度偏向某些观点，从而导致输出倾斜。偏见可能来自检索部分，也可能来自生成部分，或者两者兼有。

可解释性：
追踪系统是否能够生成引用或文档来源，以实现问责。

不同查询类型之间的公平性：
检查系统是否能在不同人口群体或地区相关查询上同样良好地回答。

安全监控

Prompt 注入防御：
监控查询中是否存在试图覆盖检索或绕过安全措施的行为，例如“忽略文档并执行 X”类型的查询。

PII 泄露监控：
确保知识库中的敏感信息不会被检索或暴露。

毒性过滤器：
监控检索文档和生成答案中是否存在有毒或有害语言。

合规风险：
追踪受限制或机密内容是否被暴露到预期范围之外。

聊天机器人

聊天机器人是部署最广泛的 LLM 应用之一。到现在为止，你很可能已经使用过或参与开发过某种基于 LLM 作为引擎的聊天应用。最近的 AI 聊天机器人与几年前的聊天机器人非常不同。过去的聊天机器人只能基于某些预定义路径回答问题；在其他情况下，它们要么失败，要么升级给人工。现在，聊天机器人能够进行几乎像人类一样的对话，甚至在被指示时表达同理心和兴奋等情绪。因此，聊天机器人的成功取决于它处理多轮交互、保持上下文，以及提供流畅对话体验的能力。

在大多数情况下，聊天机器人是面向客户的，并且必须超越正确性本身；用户会根据语气、速度、同理心和解决问题的能力来评价它们。这使得跨所有维度进行监控都同样关键。一个事实正确但缓慢、有偏见或有毒的聊天机器人，可能弊大于利。

功能性监控

意图识别准确性：
追踪聊天机器人正确理解用户意图的频率。

上下文保持：
监控聊天机器人是否能够在多轮对话中保持会话历史，而不出现矛盾。

解决率：
衡量聊天机器人在不升级给人工客服的情况下解决问题的频率。

答案准确性与有用性：
使用自动评分或人工反馈。

非功能性监控

每轮延迟：
监控响应时间，尤其是在多轮会话中。

成本：
追踪完整对话的 token 使用量，而不仅仅是每条消息，因为长会话中的成本可能迅速膨胀。

可扩展性：
监控聊天机器人并发会话的吞吐能力。

正常运行时间：
确保聊天机器人在服务时间内持续可用。

伦理监控

语气与包容性：
监控聊天机器人是否使用尊重、包容且文化上合适的语言。

偏见检测：
追踪回答是否因人口统计特征或用户群体不同而不公平地变化。

透明性：
在用户期望清楚知道时，确保聊天机器人披露自己是 AI，而不是人类。

安全监控

毒性：
监控不当、冒犯或有害回答。

Prompt 注入 / 越狱尝试：
追踪用户试图诱导聊天机器人泄露敏感信息的情况。

敏感数据保护：
监控用户是否输入 PII，并确保聊天机器人不会不当存储或使用这些信息。

有时，聊天机器人也可能基于 RAG 构建。在这种情况下，使用前面示例中的指导原则单独监控 RAG 部分，是有意义的。

AI Agent

AI Agent 本质上是独立 LLM 的升级版本。通过给 LLM 一组强大的工具，使其能够即时访问信息、编写代码或打开浏览器，我们就创建了一个更强大的实体，称为 AI Agent。这些 Agent 现在能够像人类一样计划、思考和推理，甚至能够通过多轮方式自主做决策来完成任务。但是，能力越大，责任越大；这里的责任就是监控 Agent 在与环境交互时采取的行动。所有这些工具调用和决策行为，都会让它们的行为更难预测。监控 AI Agent 包括持续追踪它们采取的行动、这些行动的副作用，以及它们产生的结果。

功能性监控

任务完成成功率：
衡量 Agent 成功完成指定目标的频率。

推理轨迹正确性：
追踪推理链和中间步骤。

工具调用准确性：
监控 Agent 是否使用正确参数调用了正确工具。

多步骤一致性：
检查 Agent 在多个步骤中的行动是否朝着预期结果保持一致。

非功能性监控

跨步骤延迟：
不仅监控总响应时间，也监控每一步的延迟。

资源使用：
追踪 token 消耗，因为 agentic 工作流可能很快变得昂贵。

可扩展性：
监控单 Agent 与多 Agent 工作流的性能。

效率权衡：
比较成功率与成本，例如 Agent 是否持续消耗过多 token，却只带来边际改进。

伦理监控

偏见：
追踪 Agent 行动是否受到任何形式偏见的影响。

推理透明性：
确保 Agent 暴露其推理轨迹，以便审计决策。

公平性：
监控 Agent 是否系统性地偏好某种结果，从而以不平等方式影响用户。

安全监控

工具误用检测：
确保 Agent 不会误用或错误使用它有权限访问的工具。

外部动作护栏：
监控 Agent 是否尝试使用未被授权使用的工具。

数据安全：
确保敏感信息不会被传递给不受信任的工具或外部服务。

不安全工具使用：
检测用户是否试图操纵 Agent 执行不安全的工具调用。

结论

本章介绍了监控基于 LLM 的应用的基础原则，强调了监控与可观测性之间的区别：监控用于发现问题，可观测性用于理解根因。本章概述了追踪技术指标与语义指标的重要性，包括准确性、延迟、成本、幻觉、安全性和用户反馈。它解释了如何将站点可靠性工程（SRE）中的 SLI、SLO 和错误预算等概念调整后应用到 LLM 中，以平衡可靠性和创新。

本章提出了四个关键监控维度：功能性，即输出的正确性和有用性；非功能性，即性能、成本和可扩展性；伦理，即偏见、公平性和包容性；安全，即毒性、PII 泄露和合规。本章还描述了典型 LLM 应用的实践监控方法，包括内容生成、RAG 系统、聊天机器人和 AI Agent，并强调需要跨所有维度进行监控，以确保 LLM 部署可信、高效且安全。在下一章中，我们将更深入地探讨如何检测 LLM 中的漂移和偏见，这也将结束理论概念部分，并为学习 Langfuse 打开道路。

参考资料

R.E. Kalman, On the general theory of control systems, IFAC Proceedings Volumes, Volume 1, Issue 1:
www.sciencedirect.com/science/art…

What is Retrieval Augmented Generation?:
research.ibm.com/blog/retrie…

What is Site Reliability Engineering (SRE)?:
aws.amazon.com/what-is/sre…