作者：来自 Elastic Brad Quarry
通过 LLM 可观测性证明 AI 价值需要什么
在六个月的时间里，Elastic IT 团队运行的内部 AI 应用为业务节省了价值 250 万美元的 运营 时间。¹ 一个对话式支持助手让我们从零数字化解决率 ------ 任何复杂问题都会变成一个工单 ------ 提升到 30% 的支持交互无需创建工单即可完成。
我们能够将这些数字呈现给财务团队，是因为从第一天开始，我们就在单次使用事件的层面进行衡量。对于每个使用场景，我们设定了一个保守的节省时间目标，并与实际执行这些工作的团队进行验证。例如，一份支持案例摘要大约可以节省 5 分钟。通过一个简单的公式（事件数 × 节省分钟数 × 标准人工成本），现在应用的投资回报率（ROI）已经成为一个实时 KPI，而不是仅仅因为应用使用了生成式 AI，就假设它可能具有价值。这些节省下来的时间重新回到了原本需要搜索答案的支持工程师手中，并被用于路线图上的工作。
大多数组织目前还没有达到这种程度。在我们针对 500 名 IT 决策者开展的《可观测性现状调查》中，85% 的受访者表示计划为其大 语言模型 （LLM）应用启用可观测性，但只有 8% 已经这样做了。团队看到了其中的价值，只是他们似乎还没有将其列为优先事项。
我想，你可以把这种推迟称为"度量债务"。每一个在没有埋点的情况下上线的 AI 能力，都在向未来借债，因为未来总会有人需要证明它值得上线。就像技术债务一样，它会悄悄累积，并最终随着领导层要求证明可观测性投入的合理性而带来越来越大的压力。
下面这些经验来自我们自己的实践，也包括我们从其他团队那里了解到的一些有用建议。
经验 1：MVP 应该包含 LLM 可观测性
面临展示 AI 进展压力的团队，不应该把遥测视为第二阶段才需要考虑的问题。等到领导层要求提供收益数据时，能够回答这个问题的使用历史必须已经被记录下来。如果没有记录，可能就无法重建这些数据。数据可能会过期。采样可能会丢弃那些从未被标记为重要的数据。
根据 Elastic《可观测性现状报告》，虽然 93% 的组织会以某种形式向领导层报告财务和业务影响，但只有 19% 会将其作为既定流程的一部分定期报告。³ 其余组织只是偶尔报告，或者只在被要求时才报告，这意味着相关数据通常会在截止日期的压力下，根据当时能够获得的信息临时整理出来。
试点项目会根据预期收益获得资金支持，并且需要在启动时定义成功标准，因此必须有一个可以进行衡量的基准。在第一位用户到来之前就确定成功是什么样的，并在同一个迭代周期中为其添加埋点。ROI 应该是一个查询结果，而不是一则轶事。
经验 2：不要使用确定性指标监控概率系统
当从 A 点到 B 点每次都产生相同结果时，可用性和延迟是足够的指标。然而，一个生成式应用可以完全可用、运行速度足够快，却完全错误。能够发现质量问题的团队会在传统指标之外跟踪第二组信号，例如 token 消耗量 ，因为它是成本计量器；检索质量 ，因为有依据的回答取决于检索到了什么；以及使用场景分类，因为了解人们实际提出的问题，是快速纠正方向的最快方式。
这些信号在上线之后最为重要。上线时的埋点可以告诉你应用运行得是否正常。但当真实用户与应用交互时，他们会提出一个不同但同样重要的问题：这个版本是否比上一个版本更好？ 任何上线时的埋点都无法回答这个问题。⁴ 更换模型、重写提示词或改变检索策略后，你需要一个系统来告诉你究竟是让事情变得更好，还是只是变得不同。这是一种比较，而比较需要记录之前发生过什么。而且，测试套件也只能回答其中一部分问题，也就是你事先想到并捕获的那些情况。用户实际提出的问题一直在不断变化，而测试用例集也需要根据实时遥测数据持续演进。基线必须在你意识到自己需要它之前就已经存在。
经验 3：坚持使用成熟的遥测术语
当团队手动创建 AI 应用时，必须有人为它产生的每个字段命名，例如 token 数量、模型、工具调用和检索步骤。之后的每一个仪表板、告警和成本报告都会依赖这些自定义名称，而当发生变化时，这笔债务就会到期。如果更换了 agent 框架，或者增加了第二个模型提供商，又或者公司进行了新的收购，那么报告层就必须重新构建。
OpenTelemetry 的生成式 AI 语义约定就是为了防止这种情况而存在的。它为重要的操作定义了标准名称，包括模型调用、agent 调用、工具执行和检索。采用趋势正在朝着一个方向发展：生产环境中的 OpenTelemetry 使用量同比增长近一倍，而根据《可观测性现状报告》，目前 60% 的组织使用厂商发行版，高于之前的 44%。
该规范中的生成式 AI span、指标或属性目前都还没有被标记为稳定，而且不同版本之间已经出现了属性重命名。⁵ 不过，使用一个不断演进的标准仍然胜过使用私有标准。重命名是一项迁移工作；私有术语体系则意味着整个系统需要重新构建。
经验 4：让埋点报告它已经知道的信息
总有一天，会有人把你的 AI 成本报告放在服务提供商的账单旁边，然后问为什么两者对不上。通常答案是，应用自己计算了一套数字，而没有记录服务提供商已经返回的数字。
常见的情况有三种：
-
当服务提供商的响应中已经包含它将实际计费的准确数字时，却使用 tokenizer 库估算 token 数量
-
在应用代码中硬编码价格来计算成本，而每次模型发布新版本后，这些价格都会过时
-
重复埋点，为同一次调用生成两条记录，从而悄悄将下游的所有计数翻倍
估算还会以仪表板无法展示的方式失败。不同服务提供商使用不同的 tokenizer ，因此同一个提示词针对不同模型会得到不同的 token 数量。推理模型会针对调用方永远无法收到的中间处理过程进行计费，因此从可见响应中获取的 token 数量会遗漏部分计费内容，而且对于成本最高的调用，遗漏的内容通常也最多。⁶
在今年我们现场团队构建的一个参考环境中进行审计时，我们发现并移除了上述三种情况，包括与服务提供商实际数据不一致的 token 估算，以及导致调用计数虚高的重复 span。修正方案并不是增加更多代码，而是减少代码。让埋点报告它已经知道的信息，然后在查询时根据价格表计算成本等派生值，这样价格变化就只需要更新数据，而不需要重新部署。
经验 5：不要让遥测账单成为下一个意外
可观测性支出是 2026 年领导层最关注的重点之一：97% 的组织已经遇到过意外成本或超额支出，其中 67% 表示这种情况经常发生。AI 工作负载会让情况变得更糟，因为一个过去只产生少量 span 的请求，现在可能产生几十个 span。
两个决策造成了大部分损失，而且这两个决策都是在无人审查的较低层级做出的。
-
使用会随着使用量增长的值来标记指标： 对话标识符就是典型案例。每一次新对话都会增加监控平台需要存储和索引的数据量，因此可观测性账单开始跟踪的是采用情况，而不是基础设施。应用取得了成功，而监控成本却越来越高。
-
账单出现后团队通常采取的补救措施： 对所有数据保留一个固定比例。统一采样会按照相同比例丢弃失败和成功的数据，而失败数据恰恰是遥测存在的全部原因。
这两个问题都不需要什么复杂的工具。模式和采样策略是需要附带预算考量的架构决策，而不是从配置文件中继承的默认设置。
经验 6：问题很可能出在数据，而不是模型
根据我们的经验，AI 应用中的大多数质量问题并不是模型问题，而是数据和检索问题，最终表现为模型问题。
基于你自己的内容进行知识库增强的应用，会从查询时检索到的文档中生成回答。当回答错误时，唯一可见的产物就是模型输出，因此这也就成了调查的对象。团队会重写提示词，然后升级到更大、更昂贵的模型，但回答只略有改善，或者完全没有改善，因为模型只能基于它获得的信息进行工作。我们在自己的测试中也看到了这一点。在同一个参考环境中，一次回答没有通过质量评审，因为用于支持该回答的检索文档只覆盖了问题所涉及的 6 个策略领域中的 3 个。无论更换什么模型，都无法找回一个从未被检索到的文档。
除非应用记录这些信息，否则这一切都是不可见的。检索到了什么、排名如何，以及这些内容实际支持了多少回答，这些都是请求本身的属性，而不是模型的属性，并且它们只存在于调用发生的那一刻。记录这些信息后，质量调试就会发生根本变化。你可以区分模型问题、排序问题和内容问题，而只有第一种问题可以通过更换模型来解决。
那条老规则依然成立 ------ 垃圾进，垃圾出 ------ 只不过现在它会以流畅而自信的幻觉形式呈现出来。我们花了一年时间构建以知识为中心的支持流程，让工程师在关闭案例时撰写知识文章。这一基础让 Support Assistant 真正发挥了价值。更好的数据提高了上限。而衡量检索效果，则让我们能够观察这个上限如何不断提高。
经验 7：了解成本可见性并不等于质量保证
完整的成本视图可以回答 AI 花费了多少钱，但无法说明 AI 是否正确。这是两个不同的领域，而第二个领域正是大多数组织无限期推迟的事情。 机器学习 工程师 Hamel Husain 为 AI 产品团队提供评估方面的咨询，他认为，不成功的 AI 产品几乎总是存在一个共同的根本原因："无法建立健壮的评估系统"。⁶ 对有依据性、忠实性和工具使用情况进行系统评估，并不是一个季度进行一次的工作。它应该接入承载性能和支出的同一份 trace 数据中，这样质量评分就能够追溯到产生该评分的运行记录。
仅仅关注成本可见性也可能产生误导，因为大多数仪表板展示的数字使用了错误的分母。每次调用的价格是一种单位成本，而业务真正购买的是一次已完成的请求。一个较弱的模型可能会降低前一个数字，却提高后一个数字，因为第一次尝试失败的工作会以重试、后续问题或更长的工具调用链形式再次出现，而这些操作中的每一个都会再次产生费用。节省的成本会立即出现在显眼的位置，而抵消这部分节省的支出则会在之后、不同的费用项目中，甚至经常出现在另一个团队的预算中。因此，两种节省看起来并没有关联。
解决方法是改变分母。报告每个已完成任务的成本 ------ 将总支出除以实际成功完成的任务数量 ------ 这样，一个需要尝试 3 次才能完成任务的低价模型就不会再显得便宜。将质量判定与成本记录在同一个 trace 中，这样财务评审和质量评审读取的是同一条记录。对于希望用一个数字表示这种关联的人，可以使用一个简化版本：任务成功率乘以准确率，再除以每个已完成任务的成本。对于 Support Assistant 而言，成功意味着回答了一个问题，而无需创建工单。
利益攸关的程度还在不断提高
一个回答糟糕的助手只会浪费片刻时间。一个推理糟糕的 agent 则会在多个步骤中基于错误结果采取行动，并通过工具调用产生费用，而成本是按照任务而不是问题逐步累积的。从未被记录的使用历史，会变成无法解释的行动历史。从未被记录的基线，会变成无法观察到的判断漂移。
运营层面的问题会从"模型说了什么"转变为"agent 做了什么，以及为什么这样做"。本文中的一切内容，都是为了提前准备好回答这个问题，而准备工作只需要在下一项 AI 计划上线之前做出一个决定：从第一个事件开始，就让它的价值可以被衡量。
一个无法衡量助手返回了什么的组织，就没有依据将采取行动的权限交给 agent。
深入了解领先组织如何应对 AI 模型生命周期管理中最紧迫的挑战，观看我们的点播网络研讨会：新的竞争优势：使用可观测性监控 AI 应用。
来源
1．Elastic 内部测量，持续 6 个月。方法：观察到的使用事件 × 经验证的节省时间 × 标准员工人工成本率。
2．Phillip Carter，《使用可观测性改进生产环境中的 LLM》，2023 年。
3．John Hodge，《OpenTelemetry GenAI 语义约定的现状》，2026 年。
4．Braintrust，《如何跟踪 LLM 成本》，2026 年。
5．OpenTelemetry，《生成式 AI 系统的 OpenTelemetry 语义约定》，2026 年。
6．Hamel Husain，《你的 AI 产品需要评估》，2024 年。
7．Mostafa Ibrahim，《什么是 Agent 可观测性？Trace、循环率、工具错误以及每个成功任务的成本》，2026 年。
本文中所描述的任何功能或特性的发布及其时间安排均由 Elastic 自行决定。目前尚未提供的任何功能或特性可能不会按时交付，也可能根本不会交付。
在本文中，我们可能使用或引用了由其各自所有者拥有和运营的第三方生成式 AI 工具。Elastic 无法控制这些第三方工具，对于其内容、运行或使用不承担任何责任，也不对因你使用此类工具而可能产生的任何损失或损害承担责任。在使用 AI 工具处理个人、敏感或机密信息时，请务必谨慎。你提交的任何数据都可能被用于 AI 训练或其他目的。无法保证你提供的信息会得到安全或保密的处理。在使用任何生成式 AI 工具之前，你应该了解其隐私实践和使用条款。
Elastic、Elasticsearch 及相关标识是 Elasticsearch B.V. 在美国及其他国家/地区的商标、徽标或注册商标。所有其他公司和产品名称均为其各自所有者的商标、徽标或注册商标。
原文：7 lessons for IT leaders on using observability to monitor AI applications | Elastic Blog