AI 调用链路追踪：一次回答背后可能有十几个后端节点

AI 调用链路追踪：一次回答背后可能有十几个后端节点

用户看到一次 AI 回答，后端可能经历鉴权、限流、Prompt 构造、向量检索、重排、模型调用、内容安全、结果缓存、审计落库。任何一个环节慢了，用户只会觉得“AI 很慢”。没有链路追踪，排障只能靠猜。

大模型应用后端要把一次回答当成完整链路，而不是一次单纯 HTTP 调用。

一、先定义 Trace 边界

flowchart TD
  A[API Gateway] --> B[Auth]
  B --> C[Prompt Builder]
  C --> D[Retriever]
  D --> E[Reranker]
  E --> F[Model Gateway]
  F --> G[Safety Filter]
  G --> H[Response]

每个节点都应该有 span，记录耗时、输入规模和关键决策。比如检索 top_k、模型名、token 数量、是否命中缓存。

二、Trace ID 要贯穿日志

MDC.put("traceId", traceId);
log.info("retrieval finished, topK={}, costMs={}", topK, costMs);

日志、指标和 trace 要能对上。否则 trace 看到模型慢，日志却找不到对应请求。

三、关键标签要统一

trace_tags:
  tenant_id: required
  model_name: required
  prompt_tokens: required
  completion_tokens: required
  cache_hit: required
  retriever_top_k: optional

标签不是越多越好，但关键维度必须统一。否则后面做聚合分析会很难。

四、慢请求要能回放证据

对 p99 请求，要能看到是哪一段慢：检索慢、模型慢、过滤慢，还是队列等待。

latency_breakdown:
  auth: 5ms
  retrieval: 120ms
  model: 4200ms
  safety: 30ms
  total: 4380ms

拆开后，优化方向才明确。否则所有问题都会被笼统地叫做“模型慢”。

还要记录输入规模。检索 top_k、上下文 token、文档数量、图片数量都会影响耗时。同一个接口，输入规模不同，性能表现完全不同。

span_payload:
  prompt_tokens
  retrieved_chunks
  rerank_candidates
  output_tokens

这些信息不一定都进日志正文，但要进 trace 标签或事件里，方便按维度聚合。

五、总结

AI 调用链路追踪要覆盖鉴权、Prompt、检索、重排、模型、安全、缓存和审计等节点。Trace ID、日志和关键标签必须统一。

一次回答背后可能有十几个后端节点。链路可见，性能优化和故障排查才有抓手。

没有链路追踪时，架构图只是静态愿望；有了真实 trace，团队才能看到请求在系统里实际怎么走。

Trace 采样也要设计。全量采集成本高，但 p99 慢请求、错误请求和高成本请求应该强制保留。否则最需要分析的请求，可能刚好被采样丢掉。

trace_sampling:
  normal: 5%
  error: 100%
  slow_request: 100%
  high_token_cost: 100%

采样策略清楚，链路追踪才能在成本和排障价值之间取得平衡。