AI 演示成功后会出现什么问题

Source: Dev.to

几周前，我构建了一个小型 AI API。没有什么花哨的——只是一个简单的端点。

response = llm(prompt)

它能正常工作。请求陆续到来。模型给出了响应。一切看起来都很顺利——直到第二周。

第一个问题

一位团队成员问：

“哪个请求产生了此输出？”

我检查了日志，里面没有任何有用的信息。

• 没有请求 ID
• 没有追踪信息
• 没有提示与输出之间的关联

系统运行了——但无法追踪。

第二个问题

很快又出现了另一个问题。

“为什么我们的 AI 费用昨天会激增？”

我们通过 API 包装器调用模型，但没有记录：

• 令牌使用量
• 模型定价
• 请求级别成本

我们已经构建了一个在背后悄悄花钱的 AI 系统。

第三问题

然后发生了一件更微妙的事。用户报告说某个输出看起来不对。模型已经成功响应，但答案显然没有用。这引出了另一个问题：

“我们如何知道模型的响应是否可接受？”

我们并不知道。API 只能知道模型是否有响应，而无法判断结果是否有意义。

实现

模型本身不是问题，问题出在模型周围的系统。AI API 与传统 API 本质上不同。它们带来了三大运维挑战：

如果不解决这些问题，AI 系统很快就难以运维。因此我构建了一个小型参考项目来探索这个问题。我把它命名为 Maester。

最小可靠性架构

可靠的 AI API 请求应经过几个结构化步骤。

Client Request
      ↓
API Middleware (request_id + trace_id)
      ↓
Route Handler
      ↓
Model Gateway
      ↓
Cost Metering
      ↓
Evaluation
      ↓
Structured Logs
      ↓
Response

每一步都增加了运营清晰度。

1. 可观测性：使 AI 请求可追踪

第一个原语是 可观测性。每个请求都应该是可追踪的。

在 Maester 中，中间件会向请求上下文附加 request_id 和 trace_id：

request_id = new_id()
trace_id   = start_trace()

这些标识符会在整个请求生命周期中传播。操作会被包装在 span 中：

with span("model_generate", model=model_name) as sp:
    response = gateway.generate(prompt)

该 span 记录：

• 操作名称
• 持续时间
• 属性

示例日志输出：

{
  "event": "span_end",
  "span": "model_generate",
  "duration_ms": 412,
  "model": "gpt-4o-mini"
}

这可以立即洞悉时间花费的具体位置。

Source: …

2. 成本计量：AI 系统每个请求都要花钱

与传统 API 不同，AI 请求直接产生金钱成本。令牌使用量会转化为实际支出，因此每个请求都应生成一条成本记录。

示例：

cost_record = meter.record(
    model=model_name,
    input_tokens=usage.input_tokens,
    output_tokens=usage.output_tokens,
)

计量器使用定价目录：

MODEL_PRICING = {
    "gpt-4o-mini": {
        "input_per_1k": 0.00015,
        "output_per_1k": 0.00060,
    }
}

请求返回：

{
  "input_tokens": 1200,
  "output_tokens": 350,
  "total_cost_usd": 0.00042
}

现在 API 可以回答关键问题：“这次请求花费了多少？”

3. 评估：成功的调用并不总是正确的

即使模型成功响应，输出仍可能不可用。这时就需要评估。

在 Maester 中，响应会通过一个简单的评估器：

result = evaluator.evaluate(prompt, response)

当前检查包括：

• 非空响应
• 必需术语的存在
• 最大长度

示例评估结果：

{
  "passed": true,
  "checks": {
    "non_empty": true,
    "required_terms": true,
    "max_length": true
  }
}

随着系统规模的扩大，这种模式变得更加重要。评估可以发展为：

• 结构化输出验证
• 幻觉检测
• 策略执行
• 安全过滤器

为什么不直接使用 OpenTelemetry？

我在项目伊始就考虑过采用 OpenTelemetry，但最终决定自行实现一个自制的解决方案，因为 … （原文在此处截断）。

OpenTelemetry 与 Maester

OpenTelemetry 解决的是不同的问题。它提供：

• 分布式追踪
• 指标导出器
• 遥测管道

Maester (GitHub) 专注于 应用层可靠性原语。可以把它看作回答以下问题的层：

这些信号随后可以导出到完整的可观测性栈。

工作者路径

AI 系统很少仅在 HTTP 请求中运行。后台任务经常运行：

• 批量推理
• 评估流水线
• 数据增强任务

Maester 包含一个 worker 示例，演示相同的可靠性原语也适用于此。Worker 执行使用相同的工具：

• 追踪
• 成本计量
• 评估
• 结构化日志

可靠性不应依赖于入口点。

此架构的实现

只需少量模块，系统即可回答以下问题：

这些信号将黑盒 AI API 转变为可追踪的系统。

最终思考

大多数关于 AI 可靠性的讨论都聚焦于模型，但可靠性往往来自 系统设计，而不是模型质量。

一个记录以下内容的简单架构：

1. 发生了什么
2. 它的成本是多少
3. 结果是否可接受

可以显著提升 AI 系统的运营方式。

这些想法越早引入系统，系统就越容易维护。

注：本文最初发布在我的工程博客上，记录了 Maester（一个公开构建的 AI SaaS 基础设施系统）的设计。