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%采样策略清楚链路追踪才能在成本和排障价值之间取得平衡。