执行追踪（Tracing）、日志、成本与延迟监控

学习目标

• 能设计一次人工智能请求的执行轨迹字段。
• 能监控质量、错误、成本和延迟。
• 能处理日志脱敏、权限和保留周期。

核心概念

人工智能应用上线后，问题不一定表现为服务报错。模型可能正常返回 200，但答案引用错了、拒答率突然升高、成本翻倍、延迟超出用户可接受范围，或者某个工具调用失败后被模型掩盖。

执行追踪（Tracing）的目标是把一次请求拆成可观察的事件：用户输入、检索结果、重排结果、提示词版本、模型调用、token 用量、工具调用、输出解析、最终响应和用户反馈。这样才能定位质量、成本和性能问题。

日志必须兼顾可排查和安全。不要无控制地保存原始敏感输入。常见做法是保存摘要、脱敏文本、哈希 ID、结构化指标和少量可授权查看的样本。

示例与拆解

一次请求执行轨迹可以记录为：

复制展开剩余 8 行
1{
2  "trace_id": "trace_20260502_001",
3  "feature": "course_qa",
4  "prompt_version": "course-qa-v4",
5  "model_id": "gpt-5.5",
6  "retrieval": {
7    "top_k": 5,
8    "hit_count": 4,
9    "index_version": "kb-index-2026-05-02"
10  },
11  "usage": {
12    "input_tokens": 3200,
13    "output_tokens": 480,
14    "cost_usd": 0.014,

这些字段能支持问题排查：成本升高时看 token，用时变长时看检索和模型阶段，引用错误时看检索命中和上下文组装。

常见误区

• 误区一：只监控接口报错率。人工智能质量退化经常不会触发 500。
• 误区二：只看总成本。没有按功能和模型拆分，就不知道该优化哪里。
• 误区三：保存所有原文。日志本身会变成隐私和合规风险。

小练习

为一个检索增强生成问答接口设计监控面板。至少包含请求量、成功率、格式有效率、拒答率、平均成本、P95 延迟、引用数量和用户负反馈率。

实操检查点

写出 8 个核心指标和报警阈值。

复制
1metric                         threshold
2format_invalid_rate            > 2% for 15m
3p95_latency_ms                 > 5000 for 10m
4avg_cost_usd_per_request        > 0.05 for 30m
5negative_feedback_rate          > 8% for 1h

检查标准：每个指标都能对应一个明确排查动作，而不是只展示好看的数字。

随堂测验

完成本章测验时，重点判断哪些信息必须进入执行轨迹，哪些信息需要脱敏或限制访问。

本章总结

大语言模型监控要同时覆盖技术稳定性、质量、成本和延迟。执行轨迹让一次人工智能请求可以被分层排查，日志治理让排查能力不变成新的风险。

下一步学习指引

下一章学习发布、实验、回滚和运行手册。监控能发现问题，发布流程要决定什么时候上线、什么时候停止、什么时候回滚。