OpenTelemetry：AI基础设施

梯形图转SCL | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

从某种意义上说，它确实是。

它的工作是回答这样的问题：

• 我的应用程序在做什么？
• 它在哪里失败了？
• 每个操作需要多长时间？
• 哪个服务调用了哪个？
• 错误出现之前发生了什么？

为此，OpenTelemetry提供了一个用于生成和传输跟踪、指标和日志的开放标准。

可以使用OpenTelemetry对应用程序进行检测，然后将该遥测发送到任何可观测性系统。

架构通常如下所示：

应用程序
↓
OpenTelemetry
↓
收集器
↓
可观测性后端

应用程序生成遥测数据。

收集器可以处理、过滤、转换或路由它。

最后，可观测性、存储或分析工具可以使用它。

这个想法看起来很简单，但它解决了一个重要问题：防止每个应用程序都必须实现不同的方式来描述内部正在发生的事情。

这个问题在AI系统中变得特别相关。

1、观测AI系统

传统应用程序可能生成如下跟踪：

HTTP请求
└── 数据库查询

基于AI的应用程序可能更像这样：

用户请求
└── 智能体
├── LLM调用
├── 检索
│ └── 向量数据库
├── 工具调用
│ └── CRM
├── LLM调用
└── 工具调用
└── 支付API

突然之间，我们不再只想知道请求花了多长时间。

我们还想要了解诸如：

• 使用了哪个模型，
• 消耗了多少令牌，
• 智能体调用了哪些工具，
• 检索了哪些文档，
• 哪个提供商运行了模型，
• 执行成本是多少，
• 生成为什么结束，
• 智能体遵循了哪些步骤，
• 响应收到了什么评估。

这就是一个看似小问题出现的地方。

没有技术原因阻止每个团队以任何他们想要的方式记录这些数据。

一个团队可能将模型存储为：

llm.model

另一个存储为：

model_name

另一个存储为：

provider_model

这三个字段本质上代表相同的东西。

当我们想要比较应用程序、切换可观测性提供商、在这些跟踪之上构建工具，或分析使用不同框架构建的系统时，问题就出现了。

在令牌、智能体、工具、检索、模型、评估和提供商之间乘以这种不一致。

看起来像是命名问题的东西最终变成了基础设施问题。

2、OpenTelemetry正在尝试为AI创建通用语言

这就是OpenTelemetry的GenAI语义约定的用武之地。

语义约定定义了在跟踪中表示某些操作的通用方式。

目标不是让每个SDK、框架或可观测性平台发明自己的模型调用表示，而是让整个生态系统共享相同的词汇。

例如，执行可以在概念上产生如下跟踪：

agent.run
├── gen_ai.chat
├── retrieval
├── execute_tool
└── gen_ai.chat

每个操作都可以携带关于模型、提供商、使用的令牌或执行的工具的结构化属性。

重要的不是每个属性今天的确切名称。

重要的是有一个通用契约。

如果不同的应用程序按照相同的模式生成遥测数据，不同的工具就可以理解它。

这使得开始分离两件历史上紧密耦合的事情成为可能：

检测 ≠ 可观测性后端

3、一次检测

没有通用标准，集成可观测性平台最终可能在应用程序中引入特定于供应商的代码。

例如：

vendor.start_llm_span(...)
vendor.log_tokens(...)
vendor.log_tool_call(...)
vendor.finish_span(...)

如果我们以后想要切换平台，部分检测也必须更改。

使用OpenTelemetry，模型可以不同：

with tracer.start_as_current_span("generate_response") as span:
    response = model.generate(prompt)
    span.set_attribute("gen_ai.request.model", model_name)

应用程序使用通用标准生成跟踪。

然后我们可以决定将其发送到哪里。

┌── 后端A
应用程序 → OTel → 收集器 ── 后端B
└── 数据仓库

我们甚至可以同时将其发送到多个系统。

这使得遥测成为独立于最终可视化它的工具的一层。

这在AI中尤其有趣，因为生态系统变化极快。

今天应用程序可能使用一个模型提供商；明天可能使用另一个。

今天它可能使用一个智能体框架，六个月后可能会替换它。

可观测性应该能够经受住这些变化。

4、示例：理解智能体在做什么

想象一个负责解决支持请求的智能体。

用户写道：

我想知道为什么我还没有收到
订单839281的退款。

智能体执行以下操作：

agent.run
│
├── llm
│
├── tool: get_order
│
├── tool: get_refund_status
│
└── llm

跟踪让我们可以重建完整的执行过程。

例如，我们可以发现第一个模型花了800毫秒，get_order调用花了120毫秒，get_refund_status失败了一次并不得不重试，最终生成消耗了1,200个令牌。

当AI系统失败时，只看外部请求的HTTP 500并不能告诉我们多少信息。

我们想要了解系统内部发生了什么。

这使得跟踪对智能体特别有价值。

5、另一个示例：发现成本问题

可观测性还可以回答不严格关于错误的问题。

假设智能体的新版本开始消耗两倍的令牌。

没有结构化的跟踪，我们可能只知道账单增加了。

有了它们，我们可以检测到：

版本41
平均输入令牌：2,140
平均输出令牌：430

与：

版本42
平均输入令牌：5,870
平均输出令牌：460

也许系统向模型发送了太多上下文，检索了太多文档，或者工具返回了巨大的响应。

遥测将成本增加转化为我们可以调查的东西。

6、但观测AI引入了一个新问题

在传统应用程序中，跟踪通常包含有关软件的信息：执行时间、错误、端点或数据库查询。

在AI应用程序中，它可能包含完全不同的内容：用户正在处理的数据。

提示可能包含姓名、电子邮件地址、医疗信息或财务数据。工具调用可能包含客户的完整记录。RAG系统可能检索内部文档的部分内容。

智能体可以在单次执行期间导致该数据通过许多系统：

用户
↓
应用程序
├── 模型
├── 向量数据库
├── CRM
├── 外部API
└── 可观测性系统

问题不仅仅是敏感数据存在。

而是该数据的副本开始存在于许多不同的地方。

每个副本可能有自己的权限、保留策略、备份、存储区域和外部提供商。

为调试智能体而创建的跟踪可能意外地成为另一个包含个人信息的数据库。

7、存储前最小化

第一个解决方案相当简单：不存储我们不需要的东西。

为了理解智能体的行为，我们可能想要保留：

model = ...
input_tokens = 1842
output_tokens = 312
tool = get_customer
latency = 842ms
status = success

而不一定保留：

我的名字是María García，
我的电话号码是+34 612 345 678，还有...

但在AI中这并不总是足够的。

有时我们需要部分内容来理解智能体为什么做出某个决策，评估响应，或重现故障。

这就是第二个策略的用武之地：在存储或发送到外部系统之前转换数据。

例如：

María García请求订单839281的退款。

可以是：

<PERSON_71C2>请求订单<ORDER_89AD>的退款。

跟踪仍然有用。

我们甚至可以在多个跨度之间保持相同的假名标识符，以重建智能体所做的工作，而不会直接暴露个人身份。

这里有一个重要的区别。

如果我们破坏了以后识别María的任何合理可能性，我们谈论的是匿名化。

如果有一个私有映射可以恢复她的身份，我们谈论的是假名化。

对于可观测性，后者特别有趣，因为它允许在不将原始标识符分发到所有系统的情况下保持关联。

8、数据离开前的隐私层

一个可能的架构是引入一个专用层，在导出数据之前检查和转换数据：

AI应用程序
↓
检测
↓
隐私层
│
├── 检测PII
├── 移除机密
├── 应用策略
├── 假名化标识符
└── 编辑内容
↓
遥测管道
↓
可观测性后端

重要的问题是在哪里进行这种转换。

如果后端首先接收：

María García

然后将其转换为：

<PERSON>

后端已经接收了原始数据。

这与在我们自己的基础设施内执行转换并仅导出：

<PERSON_71C2>

是不同的安全属性。

相同的逻辑不仅适用于提示，还适用于：

• 模型响应，
• 工具参数，
• 工具结果，
• 通过RAG检索的文档，
• 元数据，
• 异常，
• 日志。

在智能体中，工具调用和检索的文档可能正是出现一些最敏感数据的地方。

9、如何构建此层

没有必要完全用另一个LLM来解决问题。

合理的实现可以结合多种技术。

首先，用于容易识别的信息的确定性检测器：

电子邮件
电话号码
IP地址
信用卡
API密钥
内部标识符

然后，用于较少结构化信息的实体识别模型：

人员
组织
地址
位置
医疗信息

最后，特定于应用程序的规则。

患者标识符或内部合同号可能无法通过通用库发现。组织本身知道格式并可以定义如何处理。

然后可以对这些检测应用策略：

EMAIL → 移除
PHONE_NUMBER → 移除
PERSON → 假名化
CUSTOMER_ID → 稳定的HMAC/哈希
API_KEY → 完全阻止
ORDER_ID → 保留

这比简单地对所有内容应用[REDACTED]更有用。

目标不应该是删除尽可能多的信息。

而应该是保留使跟踪保持有用的最少信息。

已经有用于执行此操作的开源组件；更成熟的包括Presidio、LLM Guard和Guardrails AI。我个人已经为此解决方案开发了两个开源项目（pii-firewall和gateforge）。

10、AI可观测性正在成为基础设施

AI系统正在超越对模型的单次调用。

它们越来越像由模型、智能体、工具、数据库、检索和外部API组成的分布式系统。

我们需要了解当它们失败、开始花费太多或智能体做出意外决策时，内部发生了什么。

为此，我们需要可观测性。

但我们也需要避免这种可见性意味着将提示、内部文档和个人数据复制到跟踪接触的每个系统。

这就是为什么我认为这两个部分最终将一起发展：

标准可观测性
+
隐私设计

OpenTelemetry可以为观测这些系统提供通用语言和基础设施。

下一步是决定允许哪些信息跨越该边界。

因为在AI系统中，良好的可观测性基础设施不仅应该解释发生了什么。

它还应该允许我们在不收集我们从未需要存储的数据的情况下这样做。

原文链接：Why OpenTelemetry Is Becoming Critical Infrastructure for AI

汇智网翻译整理，转载请标明出处