可观测性（Observability）是指通过连接系统留下的记录，解释“内部发生了什么”的能力。对于使用LLM（Large Language Model，大型语言模型）的服务，应该能够追踪一个答案参考了哪些文档，经过了哪些模型和工具生成。
LLM服务即使服务器正常也可能失败。响应代码可能是200，延迟时间也很短，但却可能向用户提供了过时的规定。反之，答案可能是正确的，但内部可能经过多次重试，花费了比预期更多的时间和成本。
因此，LLM可观测性的目标是将执行过程、答案质量、耗时和成本与同一请求的上下文关联起来。本文将首先探讨哪些是不可见的，然后说明如何追踪单个请求，并按顺序连接评估和运营体系。以下时间、成本、故障案例均为理解目的的虚拟示例。
这是一张AI生成的图片，描绘了将LLM应用程序的多个处理阶段作为一个单一流程进行观察的场景。
1. 响应代码200不代表业务成功的理由
设想一个提供公司政策指导的聊天机器人。当用户询问差旅费报销标准时，系统会查找相关文档，将其传递给模型，然后显示答案。由于API服务器、搜索服务器和模型API都正常响应，运营仪表板显示为绿色。
但是，如果检索到的文档是去年的规定呢？模型忠实地总结了提供的文档，但错误的信息却传达给了用户。在这种情况下，既没有网络错误，也没有JSON解析错误。成功传递的响应与解决用户问题的响应不同。
这种差异也存在于现有服务中。谷歌的SRE文档也解释了除了明确的HTTP错误之外，返回错误内容的隐式失败。在LLM系统中，由于需要针对生成的语句判断成功，这个问题更频繁地成为运营的焦点。Google SRE: 监控分布式系统
如果将成功至少分为三个阶段，就能看到缺少了什么。
| — | — | — |
| 验证阶段 | 成功示例 | 仍存在的问题 |
| 传输与执行 | 接收请求并完整返回响应 | 内容是否正确？ |
| 结果质量 | 生成与问题相关且有依据的答案 | 实际业务是否完成？ |
| 业务结果 | 提供所需信息或完成授权操作 | 时间和成本是否可持续？ |
例如，如果代理回复“已收到”，但实际业务系统中没有提交记录，则不应算作业务成功。反之，如果对未经授权的请求进行了适当拒绝，则可能是符合政策的正常结果。将所有拒绝归类为错误，将所有语句生成归类为成功，将导致指标偏离方向。
这是LLM可观测性所需的第一个原因。需要分别确认服务是否存活以及服务是否履行其职责。
2. 答案在模型调用之外决定
实际的LLM应用程序并非仅限于一个模型。如果使用RAG（Retrieval-Augmented Generation，检索增强生成），系统会查找与问题相关的外部文档并将其作为模型输入。如果代理使用工具，则会根据模型的输出进行搜索或业务API调用。
追踪公司政策聊天机器人的一个请求，大致会经历以下过程：
- 验证用户并确定可查阅的文档范围。
- 将问题转换为适合搜索的形式并查找相关文档。
- 重新排序搜索结果，并选择符合长度限制的文档片段。
- 结合系统指令、对话历史和文档来调用模型。
- 如有必要，执行工具或切换到其他模型。
- 检查结果格式和政策，然后向用户响应。
即使是相同的问题，历史记录的长度、搜索索引、访问权限和选择的文档也可能不同。如果传递给模型的输入发生变化，答案也可能随之改变。因此，仅仅因为质量下降就立即更换模型的做法，可能会同时错过原因和成本。
如果只保存模型API的请求和响应，则很难知道搜索前应用的权限过滤器或排除文档的原因。仅查看网关日志可能无法得知对话导致了多少次模型调用。需要在了解应用程序含义的位置记录搜索、文档选择、模型调用、工具执行等工作单元。
此时，不应夸大观测范围。我们追踪的是应用程序中观察到的输入条件、调用顺序、结果和状态。一般的API度量无法恢复模型内部的非公开推理过程或权重级别的判断原因。
3. 将指标、日志、追踪与同一问题关联
可观测性数据通常用指标、日志和追踪来描述。重要的是，不是分别收集大量这三类数据，而是在调查一个问题时它们是否相互关联。
指标（Metric）是随时间聚合的数字。它们告诉我们“发生频率如何，规模多大”，例如请求数、错误率、延迟时间分布。日志（Log）是单个事件的记录。当发生异常或搜索结果为空时，可以记录具体状态。
追踪（Trace）是请求经过多个操作的路径。其中的跨度（Span）表示一个有开始和结束的操作。在同一个追踪中，查看搜索跨度、模型调用跨度、工具执行跨度之间的关系，可以缩小哪个阶段延迟或失败的范围。OpenTelemetry: 追踪和跨度
例如，在指标中发现“新部署后响应延迟增加”，然后打开该区间的追踪，发现模型调用的重试，再通过关联的日志确认限制错误的类型。与仅通过时间对比模型调用记录和日志相比，通过相同的trace_id进行关联可以更清晰地界定调查范围。
质量评估是与此执行记录关联的另一种分析结果。即使将评估分数存储在单独的表中，也必须能够识别评估了哪些请求和响应。如果分数很低但找不到相应答案的搜索结果或提示版本，则难以确定改进的位置。
当请求通过多个服务和异步操作时，需要传递追踪上下文。OpenTelemetry的上下文传播处理这种关联。如果一个对话中有多个请求，最好通过对话ID将请求捆绑起来，但要与将一个请求追踪保持开放数天的设计区分开来。OpenTelemetry: 上下文传播
4. 修复慢响应需要分段查看时间
用户感知的响应时间为6.4秒这一事实本身并不能确定改进方向。可能需要加快搜索速度，也可能需要更改模型的重试策略。以下是首次模型调用超时后重试的虚拟请求。
根据官方文档重新构建的虚拟执行时间线。在模型的逻辑调用下，区分了实际尝试和重试等待。依据：OpenTelemetry Traces, GenAI Span Conventions。时间为示例而非测量结果。
在此请求中，搜索和结果重新排序合计0.5秒，模型调用和重试等待合计5.5秒。即使将搜索时间减半，节省的时间也只有0.25秒。时间线相当于告诉我们应该从哪个改进开始。
如果SDK内部进行重试，有时可能只显示最终成功，因此需要区分逻辑模型调用的总时间和实际尝试次数。当前的OpenTelemetry GenAI Span规范也说明了要处理包含自动重试的逻辑操作的持续时间。是否提供单独尝试的子跨度或事件，需要检查度量实现。
首次响应和整体完成是不同的体验
在流式响应中，我们会区分首次内容显示前的等待时间和整个答案完成前的等待时间。TTFT（Time To First Token）指的是第一个token出现的时间，但需要确认起点和终点是什么才能进行比较。
模型服务器内部测量的第一个token时间、API客户端收到的第一个流式片段的时间、用户屏幕上显示第一个内容的时间是不同的。通过网络传输的一个片段可能包含多个token，也可能先收到不包含内容的初始片段。当前的GenAI规范也区分了客户端的第一个片段延迟和服务器的第一个token延迟。OpenTelemetry GenAI Metric Conventions
在前面的例子中，假设第二次模型调用开始后0.4秒就收到了第一个片段。在模型客户端看来速度很快，但从请求开始算起已经过去了4.0秒。浏览器显示可能还需要额外时间。这就是为什么用户感知指标和模型调用指标需要放在一起的原因。
仅凭平均延迟是不够的。如果p95是8秒，意味着该聚合对象中约95%在8秒内处理完成。将短问题和长文档摘要、流式和非流式请求混在一起，解释会变得困难，因此需要按业务类型和模型等有意义的范围进行划分。如果存在并行调用，则所有子跨度时间之和也不等于总响应时间。
5. 计算Token的原因应超越账单说明
Token是模型处理输入和输出时使用的单位。它不总是与一个汉字或一个单词完全一致。要理解LLM API的成本，需要将使用的模型、输入/输出使用量、缓存应用情况和实际计费规则关联起来。
但是，运营者想知道的问题不仅仅是“今天使用了多少个Token”。如果请求数量相同但成本增加了，就需要区分是长文档被更多地纳入，还是对话历史累积，还是切换到了更昂贵的模型，抑或是工具调用后再次调用了模型。
按请求估算成本的基本方法是将计费使用量划分为不重叠的项目进行计算：
请求的估算成本
= 所有模型调用的按计费项目使用量 × 相应单价的总和
+ 搜索、工具等额外使用成本
在某些提供商中，如果缓存Token包含在总输入Token中，直接相加会导致重复计算。还需要确认推理Token是否包含在提供商的输出使用量中。应记录单价的适用日期和模型标识符，并与实际账单明细核对估算金额。如果在重试过程中连接中断而未能获取使用量，将其处理为0元不如将其区分为使用量未确认更为准确。
廉价的请求不一定带来廉价的业务
假设我们以相同的1000个问题和相同的成功标准评估了两种配置。以下成本并非特定模型的实际费用，而是计算示例。
| — | — | — | — |
| 配置 | 处理1000次请求的成本 | 符合成功标准的请求数 | 每次成功请求的成本 |
| 配置A | 100,000韩元 | 800次 | 125韩元 |
| 配置B | 70,000韩元 | 400次 | 175韩元 |
配置B的总支出低30%，但获得一个成功结果的成本更高。该指标的分子是包括失败请求在内的总成本，分母是同一对象中成功的请求数。如果业务需要多个对话回合，则应以一个业务而非一个问题为基准进行捆绑。
因此，降低成本的变更应与质量一起评估。如果通过减少搜索文档来节省Token，但错过了必要的例外条款，则难以仅凭节省的金额来判断部署。也不应在比较用户类型或问题难度不同的流量时，就断定模型变更的效果。
6. 答案质量也应分阶段测量失败点
仅凭“答案质量分数0.7”这个数字，很难确定修复位置。需要知道是与什么进行比较后得出的分数。在RAG中，至少可以区分搜索结果、答案依据和最终正确性。
WRIMO-MD-TABLE-2]这种区分也可以在LangSmith的官方RAG评估文档中找到。即使工具不同，确定比较对象的原则也是一样的。[LangSmith: RAG应用程序评估
回想第一个案例中过时的差旅费文档。如果答案忠实于该文档，则依据忠实性评估可能很高。但是，与现行规定相比的正确性评估应该较低。有依据的事实并不能保证该依据的时效性或准确性。
即使搜索结果很好，在最终提示中插入文档的过程中也可能被截断。因此，区分搜索到的文档和实际传递给模型的文档片段，可以区分搜索器问题和输入组装问题。这也是记录文档ID以及修订号或索引版本的原因。
自动评估也需要验证
对于输出模式、必填字段、工具参数格式等规则明确的部分，可以通过代码进行检查。对于内容合理性等难以通过简单规则判断的部分，人工审查或使用LLM作为评估者会有所帮助。
然而，LLM评估者的分数也是测量工具的输出。研究表明，答案顺序或长度会产生偏差，评估提示和模型的变化也会导致分数标准的改变。需要确认与人工审查案例的一致性，并同时管理评估模型、标准和版本。MT-Bench的LLM评估者研究, 如何使评估者与人工反馈保持一致
在运营中，评估了全部流量还是仅评估了样本也很重要。不应将仅针对难题进行检查的分数作为整个服务的正确率。需要同时显示评估对象数量、选择方式、评估失败和未评估的请求数量，才能保持数字的意义。
用户的“不喜欢”或转接客服也是有用的信号，但与正确率不完全相同。有些人即使收到错误答案也不会提供反馈，而准确的答案也可能因不符合预期而引起不满。交叉检查多个信号以找到调查对象会更好。
7. 保留版本以缩小变更原因
在LLM系统中，部署的不仅仅是应用程序代码。提示词、模型选择规则、搜索索引、文档分块方式、工具的输入模式、策略和评估标准都会改变结果。
例如，假设从周五开始，某个特定问题的失败率增加了。如果在同一时间同时更改了模型和提示词，并更新了搜索索引，那么仅凭按日期平均值很难区分原因。如果为每个请求保留当时应用的版本，就可以看到失败集中在哪些组合上。
以下是为解释要存储的上下文而提供的概念性JSON示例。它不是OTLP传输格式或直接执行的SDK代码。app.*是本文中定义的应用程序属性，模型、版本、ID值均为虚拟。
{
"trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
"service.name": "policy-assistant",
"service.version": "2026.09.15-2",
"gen_ai.operation.name": "chat",
"gen_ai.request.model": "policy-model-alias",
"gen_ai.response.model": "policy-model-2026-09",
"gen_ai.prompt.name": "policy-answer",
"gen_ai.prompt.version": "v18",
"app.retrieval.index_version": "index-42",
"app.retrieval.selected_refs": ["policy-17@rev-8"],
"app.policy.version": "policy-rules-6",
"app.model.attempt_count": 2,
"app.outcome": "answered",
"app.content_capture": false
}OpenTelemetry的GenAI规范定义了请求模型和响应模型、提示名称和版本等多个上下文。但是，截至2026年9月15日确认，相关跨度（span）和指标（metric）文档处于开发状态。实际引入时，需要固定度量库和规范版本，并确认SDK提供哪些字段。如果提供商未告知模型的实际版本，也不应随意估算填充。OpenTelemetry GenAI Span规范
仅凭观察到的关联性并不能确定因果关系。即使新版本中失败较多，也可能是因为该版本分配了更多困难的请求。需要通过同一评估集的前后比较或控制条件下的实验来验证。如果当时文档和工具响应未保存，则在重现相同情况方面存在局限性，这一点也应记录。
8. 将运营中发现的失败转化为下一次部署的测试用例
仅凭运营数据进行修改，或仅凭固定评估集进行部署，都会有各自的遗漏。运营流量中会出现开发时未预料到的问题，而评估集则可以在相同条件下比较变更前后的情况。
离线评估是使用准备好的案例验证变更的过程。在线评估是分析运营中实际请求和结果的过程。在线评估不一定需要阻断用户响应路径并立即执行。可以异步评估并将结果与原始请求关联起来。LangSmith: 评估流程
根据官方文档重新构建的观测与评估连接结构。依据：LangSmith 评估流程, 评估概念。运营案例的重用需要数据最小化和单独审查。
以差旅费案例为例，从与失败答案关联的追踪中确认文档修订信息。人工审查现行规定和预期答案，删除敏感信息并添加到回归评估集中。修改文档选择逻辑后，不仅要检查这个问题，还要重新检查现有的正常案例。
这是因为仅仅修复一个特定的失败可能会降低其他问题的质量。评估集最好包含常见问题、例外条件多的问题以及因依据不足而需要保留答案的问题。如果正确答案或政策发生变化，评估集也应升级版本。
在此过程中，可观测性将故障调查资料转化为下一次质量改进的输入。如果运营追踪和评估案例之间存在关联，也可以解释“这个测试用例是由于哪个实际失败而添加的”。
9. 收集可观测数据时会产生新的数据边界
LLM的提示和响应可能包含问题、内部文档、合同内容、代码和个人信息。如果将所有这些都发送到日志平台，就会在与原始应用程序具有不同权限体系的存储中生成敏感数据副本。
因此，可观测性需要同时设计收集范围和访问控制。基本原则是收集延迟、状态、使用量、版本和允许的标识符，并为需要原始数据的调查设置单独的受限路径，这更切合实际。OpenTelemetry的GenAI规范也将输入/输出内容的收集作为明确的选项来处理。
根据官方文档重新构建的示例设计。原始数据默认不通过应用程序收集，仅在需要时应用单独的策略。依据：敏感数据处理, Collector架构。
如果需要收集内容，首先要确定目的、项目、保留期限和访问权限。认证头和密钥应排除在收集对象之外，对原始数据进行掩码处理应尽可能在数据离开进程之前应用。即使在Collector中进行额外过滤，SDK缓冲区或调试日志中残留原始数据的问题也不会自动消除。OpenTelemetry: 敏感数据处理
将用户ID转换为哈希值并不意味着所有数据都已匿名化。如果可以持续关联同一人的记录，或与其他属性结合进行识别，则仍需要访问和保留策略。在记录原始数据存储的引用ID时，也要避免在日志中同时记录访问令牌或签名下载URL。
安全观测与权限检查职责不同
如果系统支持工具调用，则可以观测到调用的工具、允许/拒绝结果、应用的策略版本、重试和批准结果。这些记录有助于调查异常行为和改进策略。
然而，记录调用并不能预防未经授权的操作。访问控制应由执行工具的服务器进行检查，而可观测数据应解释其判断和执行结果。拦截次数增加并不意味着攻击增加，这可能为时过早。政策变更也可能导致更多正常请求被拦截。
10. 收集的数据越多，并不意味着看得越清楚
存储和搜索可观测数据也需要成本。输入和输出较长的LLM服务如果无限记录正文或为每个Token记录事件，收集量可能会大幅增加。最终，如何稳定地保留所需证据是设计的核心。
首先是指标的基数（Cardinality），即区分值组合的数量。将用户ID、请求ID、问题原文放入指标标签，可能会为每个请求创建新的时间序列。应使用服务、工作类型、受限模型分类等范围受控的标签，而单个请求标识符则应在追踪或受控访问的记录中查找。Prometheus: 指标和标签命名
其次是采样（Sampling），即选择部分请求进行保留的策略。在请求开始时决定采样可以提前降低成本，但无法预知该请求后续是否会失败。根据请求结果选择采样更容易保留慢请求或错误，但这需要资源和时间来在选择前收集数据。OpenTelemetry: 采样
这里有一个经常被忽视的条件。前端已经丢弃的追踪，后端收集器无法恢复。即使几分钟后异步质量评估判定为失败，如果追踪已被删除，也无法查看相关的执行记录。需要同时设计评估延迟和保留期限，或在适当的时间内保持最少的元数据。
从故意保留大量错误请求的样本中计算出的错误率，也并非整个服务的错误率。应明确运营指标的计算路径和总体，并区分诊断用追踪样本和整体请求聚合。
第三是收集器自身的状态。如果不监控Exporter传输失败、队列增长、收集拒绝或丢弃，就很难知道“是没有问题所以没有数据，还是可观测系统故障所以没有数据”。Collector的内部遥测用于检查这些状态。OpenTelemetry Collector 内部遥测
11. 仪表板应能指导负责人的下一步行动
将CPU和内存、模型延迟和质量分数集中在一个屏幕上，并不意味着运营体系就已完善。当指标恶化时，需要明确谁来检查什么以及采取什么措施。
谷歌SRE的延迟、流量、错误和饱和度仍然是很好的起点。在使用外部模型API的情况下，应用程序队列、并发请求、提供商的限制响应等是理解资源不足的线索。如果运营自己的模型，推理服务器的队列和GPU内存等也应纳入观测范围。
在此基础上，增加LLM业务的成功标准和成本。以下是引入时可以提出的运营问题示例：
| — | — | — |
| 运营问题 | 共同查看的信号 | 下一步调查 |
| 用户等待时间是否过长？ | 首次内容显示时间、总延迟、取消率 | 检查慢请求的搜索、模型、工具阶段 |
| 正常响应的质量是否下降？ | 正确性样本评估、文档时效性、用户反馈 | 检查按提示词、索引版本划分的失败分布 |
| 每次请求的成本是否增加？ | 输入长度、重试、模型切换、使用量缺失率 | 检查高成本请求的执行路径 |
| 工具是否完成了业务？ | 执行结果、业务状态、是否重复执行 | 检查工具响应与最终指导的一致性 |
| 当前指标是否可信？ | 收集失败、丢弃、评估完成率 | 检查度量、传输、评估管道 |
服务水平目标SLO（Service Level Objective）也应在此基础上确定。对于对话式指导，首次内容显示时间和正常完成率可能很重要；对于异步报告生成，在规定时间内生成符合标准结果的比例可能更合适。
质量目标必须伴随评估对象和方法。如果写着“总请求正确率95%”，但实际每天只检查20个方便的样本，那么目标与测量就会脱节。需要区分是基于样本的估计，还是所有请求中可确认的业务结果，并同时查看样本数量和不确定性。
从警报到原因验证的一次性连接
假设收到政策指导评估分数下降的信号。负责人首先确认评估对象数量和评估者版本是否发生变化。然后，将失败请求按提示词、模型、索引版本进行划分，并从问题集中的请求追踪中确认实际选择文档的修订信息。
如果新搜索索引中包含旧版本文档是潜在原因，则进行验证。修改文档选择条件后，同时运行现有评估集和新的失败案例，并在受限部署中确认质量、延迟和成本是否得到改善。只有记录相互关联，这项调查才能摆脱反复猜测。
12. 现实的起点是完整地查看一个重要请求
如果一开始就尝试度量所有模型和所有工具，数据量和运营规则的制定工作就会变得庞大。最好先选择一个常用且失败时影响较大的业务，然后确认它是否能实际回答以下问题。
第一，定义成功的含义。就哪些响应算作成功、哪些拒绝算作正常、哪些需要人工审查达成一致。如果没有这个定义，就无法解释质量分数和警报。
第二，连接执行路径。将请求入口、搜索、模型调用和主要工具执行捆绑在一个上下文中，并记录延迟、状态、使用量和版本。确认框架自动记录的范围和需要手动度量的业务阶段。
第三，附加质量评估。使用人工审查的正常/失败案例创建评估标准，并使运营中发现的问题可以在同一请求的追踪中进行调查。不仅要记录评估分数，还要记录评估失败和缺失。
第四，测试记录是否实际连接。在测试环境中分别检查模型超时、搜索结果为空、工具失败、用户取消、流式中断。验证重试是否没有隐藏在一次成功之后，以及中断请求的延迟和状态是否被保留。
第五，确认收集和查询的边界。检查准备好的秘密值和个人信息虚拟标记是否未通过遥测传输出去，以及未经授权的运营者是否无法查询原始数据。还要确认正常样本和失败样本是否按预期策略保留。
OpenTelemetry是连接这些度量和传输的通用基础。收集到的信号的存储和探索后端，以及LLM评估和提示分析工具，可以根据运营条件进行组合。比选择的工具名称更重要的是，当选择一个质量不佳的响应时，是否能够追踪到该请求的执行、版本和成本。
总结：要持续提供优质答案，就必须能够解释其过程
LLM可观测性之所以必要，是因为失败的形式多种多样。服务可能响应了，但信息是错误的；答案可能是正确的，但由于不必要的重试而变得缓慢且昂贵。即使是相同的代码，文档、提示词、工具和模型配置不同，结果也可能改变。
连接执行记录可以缩小问题范围。连接质量评估可以确认响应成功和业务成功之间的差异。同时查看成本和版本可以验证变更是否确实是改进。并且，只有设计好收集数据的访问和保留策略，才能信任该可观测体系。
第一步是选择一个重要的用户请求，使其能够解释在什么条件下、经过什么过程、花费多少时间和成本、产生了什么结果。一旦建立起这种关联，运营中发现的失败就能成为提高下一次部署质量的依据。
发表回复