AI 应用的可观测性体系从黑盒调用到全链路追踪的监控架构一、AI 服务看起来正常的监控假象一个 AI 客服系统的健康检查显示所有服务绿灯API 响应时间 P99 在 3 秒内。但用户体验团队反馈上周三开始下午 2-4 点的回答质量明显下降。排查后发现知识库索引服务在那个时段有偶发性延迟导致检索结果返回不完整大模型因此基于不完整信息生成回答。整个过程中没有一个监控告警被触发——因为 API 没有报错响应时间也在阈值内只是回答质量变差了。传统微服务监控关注的是可用性——服务是否存活、响应是否超时。AI 应用需要额外关注生成质量——回答是否准确、是否有幻觉、Token 消耗是否异常。这要求可观测性体系覆盖从输入到输出的完整链路。二、三柱一面的 AI 可观测性模型借用 OpenTelemetry 的三柱Traces、Metrics、Logs并扩展 AI 特有的质量面graph TB subgraph 传统三柱 T[Tracesbr/全链路追踪] M[Metricsbr/聚合指标] L[Logsbr/离散事件日志] end subgraph AI 扩展面 Q[Qualitybr/生成质量评估] Q1[输出格式正确率] Q2[幻觉检测] Q3[用户反馈闭环] end T -- DASH[统一可观测看板] M -- DASH L -- DASH Q -- DASH subgraph AI 调用链路 REQ[用户请求] -- INTENT[意图识别] INTENT -- RETRIEVE[知识检索] RETRIEVE -- GENERATE[大模型生成] GENERATE -- POST[后处理] POST -- RESP[响应用户] end REQ -.- T RETRIEVE -.- M GENERATE -.- Q RESP -.- LTraces 追踪单次 AI 调用的完整路径意图识别→检索→生成→后处理在分布式系统中关联上游请求。Metrics 聚合 Token 用量、API 延迟、错误率等统计指标。Logs 记录 Prompt 和 Response 的原始内容用于问题排查。Quality 是 AI 特有层评估生成内容的质量并通过用户反馈形成闭环。三、OpenTelemetry 接入 AI 调用链// AI 调用链的 OpenTelemetry 埋点 // 设计意图将 AI 调用视为分布式追踪的一个 Span // 在 Span 属性中记录 Prompt、Response、Token 用量 import { trace, Span, SpanStatusCode } from opentelemetry/api; import { SemanticAttributes } from opentelemetry/semantic-conventions; const tracer trace.getTracer(ai-service); interface AICallParams { model: string; messages: Array{ role: string; content: string }; temperature?: number; maxTokens?: number; } interface AICallResult { content: string; model: string; usage: { promptTokens: number; completionTokens: number; totalTokens: number; }; finishReason: string; } async function tracedAICall( params: AICallParams, ): PromiseAICallResult { // 创建 AI 调用的 Span——关联到当前活跃的 Trace return tracer.startActiveSpan(ai.chat.completion, async (span) { const startTime Date.now(); // 设置 Span 属性——这些属性在 Tracing UI 中可搜索和聚合 span.setAttributes({ ai.model: params.model, ai.temperature: params.temperature ?? 0.7, ai.max_tokens: params.maxTokens ?? 4096, // 记录消息轮数——用于分析多轮对话的 Token 膨胀 ai.messages_count: params.messages.length, // 估算输入 Token 数——精确值在响应返回后更新 ai.input_tokens_estimate: JSON.stringify(params.messages).length * 0.5, }); try { const result await callOpenAI(params); // 记录响应指标 span.setAttributes({ ai.output_tokens: result.usage.completionTokens, ai.total_tokens: result.usage.totalTokens, ai.finish_reason: result.finishReason, ai.response_length: result.content.length, // 延迟——从请求发起到首 Token 返回的时间 ai.time_to_first_token_ms: Date.now() - startTime, }); // 质量标记——后续可由质量评估系统更新 span.setAttribute(ai.quality_flag, pending_review); // 记录请求和响应的摘要脱敏后的前 200 字符 // 设计意图全量 Prompt 可能包含敏感信息只记录摘要 span.addEvent(ai.prompt_summary, { content: params.messages[params.messages.length - 1]?.content.slice(0, 200), }); span.setStatus({ code: SpanStatusCode.OK }); return result; } catch (error) { // 记录错误详情 span.setStatus({ code: SpanStatusCode.ERROR, message: (error as Error).message, }); span.setAttributes({ ai.error_type: (error as Error).name, ai.retry_count: 0, // 如果有重试逻辑 }); throw error; } finally { span.end(); } }); } // Token 用量聚合——Prometheus Counter 模式 import { MeterProvider } from opentelemetry/sdk-metrics; const meter new MeterProvider().getMeter(ai-metrics); const tokenCounter meter.createCounter(ai.tokens.total, { description: AI 调用总 Token 消耗, unit: tokens, }); const requestCounter meter.createCounter(ai.requests.total, { description: AI 请求总数, }); const requestDuration meter.createHistogram(ai.request.duration, { description: AI 请求延迟分布, unit: ms, }); // 在 AI 调用完成后记录指标 function recordAIMetrics(result: AICallResult, durationMs: number): void { tokenCounter.add(result.usage.totalTokens, { model: result.model, environment: process.env.NODE_ENV || production, }); requestCounter.add(1, { model: result.model, finish_reason: result.finishReason, }); requestDuration.record(durationMs, { model: result.model, }); }三个可观测性设计要点Span 属性以ai.前缀命名——在 Tracing UI 中可统一筛选和聚合Prompt 只记录摘要而非全量——生产环境的 Prompt 可能包含用户 PII 数据Metrics 按model和finish_reason分组——可以按模型分析 Token 消耗趋势。四、质量监控的自动化与局限自动化质量检测。可以通过规则引擎对 AI 回复做自动化检查回复是否包含拒绝回答的模板话术作为 AI 我无法……是否超过或低于预期长度是否包含不应出现的关键词。这些规则只能检测明显的质量问题无法评估回复的准确性和有用性。用户反馈闭环。点赞/踩是最直接的质量信号。但存在偏置不满意的用户更倾向于点踩满意的用户经常忘记点赞。需要在 UI 中降低反馈成本——在回复末尾直接显示快捷反馈按钮而非隐藏在菜单中。质量监控的延迟性。用户反馈需要数小时甚至数天才能积累足够的样本量。当日质量问题需要当日发现时应结合自动化检测和实时 MetricsToken 用量突变、回复长度异常做早期预警。五、总结AI 应用可观测性体系的四个维度Traces——追踪单次 AI 调用的完整路径关联上下游服务Metrics——按模型和场景聚合 Token 用量、延迟、错误率Logs——记录 Prompt/Response 摘要用于问题排查脱敏处理Quality——通过自动检测和用户反馈闭环评估生成质量。落地步骤接入 OpenTelemetry SDK为 AI 调用创建独立 Span建立 Token 用量、延迟 P50/P99、错误率的 Dashboard在 UI 中加入无摩擦的用户反馈按钮配置 Token 用量突变告警——30 分钟内用量超过基线 2 倍时触发。
AI 应用的可观测性体系：从黑盒调用到全链路追踪的监控架构
发布时间：2026/7/14 14:10:57
AI 应用的可观测性体系从黑盒调用到全链路追踪的监控架构一、AI 服务看起来正常的监控假象一个 AI 客服系统的健康检查显示所有服务绿灯API 响应时间 P99 在 3 秒内。但用户体验团队反馈上周三开始下午 2-4 点的回答质量明显下降。排查后发现知识库索引服务在那个时段有偶发性延迟导致检索结果返回不完整大模型因此基于不完整信息生成回答。整个过程中没有一个监控告警被触发——因为 API 没有报错响应时间也在阈值内只是回答质量变差了。传统微服务监控关注的是可用性——服务是否存活、响应是否超时。AI 应用需要额外关注生成质量——回答是否准确、是否有幻觉、Token 消耗是否异常。这要求可观测性体系覆盖从输入到输出的完整链路。二、三柱一面的 AI 可观测性模型借用 OpenTelemetry 的三柱Traces、Metrics、Logs并扩展 AI 特有的质量面graph TB subgraph 传统三柱 T[Tracesbr/全链路追踪] M[Metricsbr/聚合指标] L[Logsbr/离散事件日志] end subgraph AI 扩展面 Q[Qualitybr/生成质量评估] Q1[输出格式正确率] Q2[幻觉检测] Q3[用户反馈闭环] end T -- DASH[统一可观测看板] M -- DASH L -- DASH Q -- DASH subgraph AI 调用链路 REQ[用户请求] -- INTENT[意图识别] INTENT -- RETRIEVE[知识检索] RETRIEVE -- GENERATE[大模型生成] GENERATE -- POST[后处理] POST -- RESP[响应用户] end REQ -.- T RETRIEVE -.- M GENERATE -.- Q RESP -.- LTraces 追踪单次 AI 调用的完整路径意图识别→检索→生成→后处理在分布式系统中关联上游请求。Metrics 聚合 Token 用量、API 延迟、错误率等统计指标。Logs 记录 Prompt 和 Response 的原始内容用于问题排查。Quality 是 AI 特有层评估生成内容的质量并通过用户反馈形成闭环。三、OpenTelemetry 接入 AI 调用链// AI 调用链的 OpenTelemetry 埋点 // 设计意图将 AI 调用视为分布式追踪的一个 Span // 在 Span 属性中记录 Prompt、Response、Token 用量 import { trace, Span, SpanStatusCode } from opentelemetry/api; import { SemanticAttributes } from opentelemetry/semantic-conventions; const tracer trace.getTracer(ai-service); interface AICallParams { model: string; messages: Array{ role: string; content: string }; temperature?: number; maxTokens?: number; } interface AICallResult { content: string; model: string; usage: { promptTokens: number; completionTokens: number; totalTokens: number; }; finishReason: string; } async function tracedAICall( params: AICallParams, ): PromiseAICallResult { // 创建 AI 调用的 Span——关联到当前活跃的 Trace return tracer.startActiveSpan(ai.chat.completion, async (span) { const startTime Date.now(); // 设置 Span 属性——这些属性在 Tracing UI 中可搜索和聚合 span.setAttributes({ ai.model: params.model, ai.temperature: params.temperature ?? 0.7, ai.max_tokens: params.maxTokens ?? 4096, // 记录消息轮数——用于分析多轮对话的 Token 膨胀 ai.messages_count: params.messages.length, // 估算输入 Token 数——精确值在响应返回后更新 ai.input_tokens_estimate: JSON.stringify(params.messages).length * 0.5, }); try { const result await callOpenAI(params); // 记录响应指标 span.setAttributes({ ai.output_tokens: result.usage.completionTokens, ai.total_tokens: result.usage.totalTokens, ai.finish_reason: result.finishReason, ai.response_length: result.content.length, // 延迟——从请求发起到首 Token 返回的时间 ai.time_to_first_token_ms: Date.now() - startTime, }); // 质量标记——后续可由质量评估系统更新 span.setAttribute(ai.quality_flag, pending_review); // 记录请求和响应的摘要脱敏后的前 200 字符 // 设计意图全量 Prompt 可能包含敏感信息只记录摘要 span.addEvent(ai.prompt_summary, { content: params.messages[params.messages.length - 1]?.content.slice(0, 200), }); span.setStatus({ code: SpanStatusCode.OK }); return result; } catch (error) { // 记录错误详情 span.setStatus({ code: SpanStatusCode.ERROR, message: (error as Error).message, }); span.setAttributes({ ai.error_type: (error as Error).name, ai.retry_count: 0, // 如果有重试逻辑 }); throw error; } finally { span.end(); } }); } // Token 用量聚合——Prometheus Counter 模式 import { MeterProvider } from opentelemetry/sdk-metrics; const meter new MeterProvider().getMeter(ai-metrics); const tokenCounter meter.createCounter(ai.tokens.total, { description: AI 调用总 Token 消耗, unit: tokens, }); const requestCounter meter.createCounter(ai.requests.total, { description: AI 请求总数, }); const requestDuration meter.createHistogram(ai.request.duration, { description: AI 请求延迟分布, unit: ms, }); // 在 AI 调用完成后记录指标 function recordAIMetrics(result: AICallResult, durationMs: number): void { tokenCounter.add(result.usage.totalTokens, { model: result.model, environment: process.env.NODE_ENV || production, }); requestCounter.add(1, { model: result.model, finish_reason: result.finishReason, }); requestDuration.record(durationMs, { model: result.model, }); }三个可观测性设计要点Span 属性以ai.前缀命名——在 Tracing UI 中可统一筛选和聚合Prompt 只记录摘要而非全量——生产环境的 Prompt 可能包含用户 PII 数据Metrics 按model和finish_reason分组——可以按模型分析 Token 消耗趋势。四、质量监控的自动化与局限自动化质量检测。可以通过规则引擎对 AI 回复做自动化检查回复是否包含拒绝回答的模板话术作为 AI 我无法……是否超过或低于预期长度是否包含不应出现的关键词。这些规则只能检测明显的质量问题无法评估回复的准确性和有用性。用户反馈闭环。点赞/踩是最直接的质量信号。但存在偏置不满意的用户更倾向于点踩满意的用户经常忘记点赞。需要在 UI 中降低反馈成本——在回复末尾直接显示快捷反馈按钮而非隐藏在菜单中。质量监控的延迟性。用户反馈需要数小时甚至数天才能积累足够的样本量。当日质量问题需要当日发现时应结合自动化检测和实时 MetricsToken 用量突变、回复长度异常做早期预警。五、总结AI 应用可观测性体系的四个维度Traces——追踪单次 AI 调用的完整路径关联上下游服务Metrics——按模型和场景聚合 Token 用量、延迟、错误率Logs——记录 Prompt/Response 摘要用于问题排查脱敏处理Quality——通过自动检测和用户反馈闭环评估生成质量。落地步骤接入 OpenTelemetry SDK为 AI 调用创建独立 Span建立 Token 用量、延迟 P50/P99、错误率的 Dashboard在 UI 中加入无摩擦的用户反馈按钮配置 Token 用量突变告警——30 分钟内用量超过基线 2 倍时触发。
)
