为什么“大模型上线后的可观测性”决定能不能长期跑

在“Ai大模型训练教程：从入门到实战落地的系统课程”里，训练与评测只是起点。一旦模型上线，真实用户流量会把隐藏问题全部放大：

• 延迟（Latency）抖动导致转化下降、客服投诉；
• Token 成本不可控导致预算爆炸；
• RAG/缓存命中率低导致“答非所问”、重复计算；
• 缺少审计与安全链路导致提示注入、数据泄露、合规风险。

可观测性不是“装个监控面板”，而是一套从指标（Metrics）—日志（Logs）—追踪（Traces）—审计（Audit）贯通的运行体系。本篇聚焦上线后最关键的四类可观测目标：延迟、Token 成本、命中率与安全审计，给出可落地的指标定义、埋点方案、告警规则与优化路径。

可观测性建设总览：先把链路画清楚

在开始埋点前，先明确一次 LLM 请求链路通常包含哪些阶段（不同架构略有差异）：

1. 入口层：API Gateway / BFF（鉴权、限流、路由）
2. 编排层：Prompt 构造、工具选择、会话状态读取
3. 检索层（可选）：Embedding、向量检索、重排、文档裁剪
4. 推理层：模型服务（自建推理或外部 API）
5. 后处理：安全过滤、结构化解析、落库、缓存写入
6. 回传层：SSE/流式输出、前端渲染

可观测性核心原则：

• 每个阶段都要有：开始时间、结束时间、关键输入规模（token/文档数/候选数）、关键输出规模、错误码。
• 统一一个 trace_id 串起全链路。
• 统一一个 request_id 便于排查单次请求。

建议最小埋点字段（后文会逐项用到）：

• trace_id, request_id, user_id_hash, tenant_id, app_id
• model, model_version, provider（自建/某云API）
• prompt_tokens, completion_tokens, total_tokens
• cache_hit（true/false）, rag_hit（true/false）, rag_topk, rerank_used
• latency_ms_total, latency_ms_retrieval, latency_ms_infer, latency_ms_postprocess
• status（success/fail）, error_type, http_status
• policy_flags（安全策略命中项数组）

延迟可观测性：把“慢”拆成可行动的段

1) 延迟指标怎么定义才不误导

上线后常见误区是只看平均延迟。对 LLM 场景，应至少监控：

• TTFT（Time To First Token）：从请求到首个 token 输出时间（对流式体验最关键）
• TPOT（Time Per Output Token）：每个输出 token 的平均耗时（反映解码速度、并发压力）
• E2E Latency（端到端）：从请求进入到响应结束
• 分段延迟：retrieval / infer / postprocess / gateway 等

推荐监控分位数：p50 / p90 / p95 / p99，再加一个超时比例（例如 > 10s 的请求占比）。

示例：建议的延迟SLO（可按业务调整）

• 交互问答：TTFT p95 < 1.5s；E2E p95 < 6s
• 客服工单总结：E2E p95 < 15s（非强交互）

2) 如何埋点：流式输出要特别处理

如果使用 SSE/WS 流式输出，延迟要分两段：

• ttft_ms = first_token_ts - request_start_ts
• e2e_ms = response_end_ts - request_start_ts

同时记录输出 token 数，计算：

• tpot_ms = (response_end_ts - first_token_ts) / completion_tokens

实践建议：

• 在网关层记录 request_start_ts，在模型服务层记录 first_token_ts 与 response_end_ts。
• 如果调用外部 LLM API，优先采集其返回的 usage 字段和流式首包时间；无法直接获取首 token 时间时，可用“收到第一段流数据的时间”近似。

3) 告警怎么设才不“吵”

只看单点超时会导致告警风暴。更建议：

• 分位数告警：例如 TTFT p95 > 2s 持续 5分钟
• 错误率联动：p95上升 + 5xx上升 才升级告警等级

• 分层告警：

  • P1：全站不可用、错误率激增
  • P2：TTFT/TPOT 恶化但仍可用
  • P3：某特定模型/租户/地区异常

4) 延迟问题排查套路（按优先级）

1. 先定位慢在哪段：检索慢还是推理慢？网关慢还是后处理慢？

2. 推理慢常见原因：

   • 并发高导致排队（queue time）
   • 输出太长（completion_tokens 激增）
   • 模型切换到更大版本

3. 检索慢常见原因：

   • 向量库索引不佳、topK过大、重排耗时
   • 文档裁剪不足导致上下文太长（反过来拖慢推理）
4. 后处理慢：敏感词/安全模型串行调用、JSON 解析失败重试等

Token 成本可观测性：从“总费用”下钻到“谁在烧钱”

1) 成本指标体系：不仅是 total_tokens

对 Token 成本，建议至少分三个层级：

• 使用量层：prompt_tokens / completion_tokens / total_tokens
• 单价层：不同模型、不同供应商价格不同，需记录 unit_price_prompt 与 unit_price_completion
• 归因层：按 app_id / tenant_id / user_id_hash / endpoint / 场景 聚合

计算：

• cost = prompt_tokens * unit_price_prompt + completion_tokens * unit_price_completion

再加两个关键派生指标：

• Cost per Request（每请求成本）：用于发现“异常贵”的请求类型
• Cost per Successful Task（每成功任务成本）：把失败重试算进去更真实

2) 必做埋点：把“提示词与检索”变成成本的可解释来源

建议记录：

• prompt_template_id：哪个模板导致 prompt 变长
• context_tokens：RAG 拼进去的上下文 token（与系统prompt区分）
• tool_calls_count：工具调用次数（多轮调用会指数级增成本）
• retry_count：重试次数（尤其是超时重试）

如果你无法直接得到 “context_tokens”，也可以记录：

• rag_chars 或 rag_bytes 作为近似

3) 成本告警：用“预算 + 异常检测”组合

三种常用告警：

1. 预算消耗告警：日成本达到预算 70%/90% 提醒
2. 单请求异常告警：cost_per_request > 历史p99 且持续出现
3. 结构异常告警：例如 completion_tokens / prompt_tokens 比例突然升高（可能输出失控）

4) 成本优化的具体抓手（按投入产出排序）

• 限制最大输出：对不同 endpoint 设 max_tokens 上限；对摘要类输出改为“要点数 + 每点字数”硬约束。
• 减少无效上下文：RAG 文档先裁剪再拼接；优先拼“引用段落”而不是整篇。
• 缓存与复用：对高频问答做语义缓存（见命中率章节），对工具结果做结果缓存。
• 模型分层路由：简单问题用小模型，大问题再升级；需要记录 routing_reason 做可观测解释。
• 失败重试策略：将“超时重试”改为“快速失败 + 降级模型/降级回答”，避免同一请求烧两次钱。

命中率可观测性：缓存命中、RAG 命中、答案有效命中

“命中率”在大模型系统里至少有三层含义，建议分开统计，否则你会得到一个“看似很高但没意义”的数字。

1) 缓存命中率（Cache Hit Rate）

适用场景：高频重复问题、模板化输入（如运营文案生成）、固定工具调用结果。

埋点建议：

• cache_key_type：精确key / 语义key / 会话key
• cache_hit：true/false
• cache_ttl_sec：TTL
• cache_fallback_reason：未命中的原因（过期/未找到/相似度不足）

关键指标：

• cache_hit_rate = hit / (hit + miss)
• 命中带来的节省：tokens_saved、cost_saved、latency_saved_ms

2) RAG 命中率：检索是否“找到了该找的”

RAG 命中不是简单的“检索到了文档”。建议定义两个指标：

• Retrieval Hit：是否检索到候选（向量库返回非空）
• Grounding Hit：最终答案是否引用了检索内容（或依据检索内容生成）

可操作的埋点：

• rag_hit：是否检索返回有效候选（例如 topK>0 且相似度>阈值）
• rag_top1_score、rag_topk_scores（可选）
• used_citations：是否输出引用（true/false）
• citations_count：引用条数

如果业务允许，强烈建议在输出中引入结构：

• answer + citations（文档id+段落范围）

这样“grounding”可观测且可审计。

3) 答案有效命中率：用户是否认为“这次答对了”

仅靠检索/缓存命中仍不足以衡量质量。建议引入：

• thumb_up_rate / reask_rate（同一会话短时间重复提问比例）
• task_success（由业务侧判定，例如工单是否一次解决）
• fallback_rate（触发“我不确定/请联系人工”的比例）

将这些与 rag_hit、cache_hit 联合分析：

• cache_hit 高但 thumb_up 低：缓存内容可能陈旧或语义key误命中
• rag_hit 低且 reask_rate 高：检索召回失败，需要调 embedding、分段、topK、重排

4) 命中率优化步骤（给一套可执行流程）

1. 先做数据分桶：按场景（endpoint）统计 rag_hit、cache_hit、thumb_up_rate
2. 抽样人工复核：从 rag_hit=false 且 reask=true 的请求里抽样 100 条看问题类型

3. 针对性改造：

   • 召回不足：提高分段质量、加同义词扩展、调整 embedding 模型
   • 噪声太多：加重排（rerank）、降低 topK、加相似度阈值
   • 上下文太长：裁剪规则（按标题/段落/关键句）
4. 上线 A/B：命中率指标必须与“成本/延迟”联动看，避免为了命中率堆上下文导致成本暴涨

安全审计可观测性：可追溯、可阻断、可复盘

上线后最常见的安全问题不是“模型被黑客攻破”，而是：

• 提示注入导致泄露系统提示词或越权调用工具
• 输出包含隐私数据（PII）或敏感内容
• RAG 引入含版权/涉密文档被外发
• 工具调用（发邮件/查库/下单）缺少审计链

安全审计要做到两件事：实时阻断 + 事后可追溯。

1) 审计日志要记录什么（最小合规集）

建议将审计日志与业务日志分开存储（权限隔离、不可篡改策略）。最小字段：

• 标识：trace_id, request_id, tenant_id, user_id_hash, ip_region
• 模型与版本：model, model_version, provider

• 输入输出摘要：

  • input_hash（原文可脱敏/加密存储）
  • output_hash
  • prompt_template_id
• 安全策略命中：policy_flags（如 PII_DETECTED、PROMPT_INJECTION、TOOL_ABUSE）
• 工具审计：tool_name, tool_args_hash, tool_result_hash, tool_auth_scope
• 处置结果：action（allow/block/redact/require_human）
• 证据：matched_rules（规则ID）、detector_version

重要建议：

• 对原始内容存储采用“分级策略”：默认只存 hash/摘要；仅在命中高风险策略或用户授权情况下存明文，并设置严格保留期。

2) 提示注入与越权调用的可观测检测

可落地的检测点：

• 输入侧检测：识别“忽略之前指令/泄露系统prompt/输出密钥”等模式
• 工具调用侧检测：模型请求调用工具时，校验其 tool_auth_scope 是否与用户权限匹配
• 输出侧检测：PII、涉政涉暴、内部信息、密钥模式（AK/SK）等

对应指标：

• injection_detect_rate：注入检测命中率
• tool_denied_rate：工具调用被拒比例（过高说明提示词或路由有问题）
• redaction_rate：脱敏比例
• high_risk_block_rate：高风险阻断比例

3) 安全告警：把“风险等级”设计清楚

建议分级：

• High：疑似密钥/身份证/银行卡外泄；越权调用支付/发信等工具；涉密文档引用外发
• Medium：提示注入尝试、引导输出系统提示词、黄赌毒等内容
• Low：一般违规词、边界擦线

告警策略：

• High：实时告警 + 自动阻断 + 工单
• Medium：聚合告警（如 10分钟内 > N 次）+ 观察
• Low：仅统计，用于策略调优

4) 审计复盘：一次事故要能回答四个问题

1. 谁发起的？（tenant/user/来源）
2. 走了哪条链路？（trace）
3. 为什么没拦住/为什么拦住了？（policy_flags + matched_rules + detector_version）
4. 造成了什么影响？（是否外发、是否落库、是否被下游系统使用）

如果你的审计数据能完整回答上述问题，才算具备“可运营的安全能力”。

落地建议：一套可直接照做的实施清单

H3 第 1 周：先把指标与埋点跑起来

• 统一 trace_id/request_id 贯穿网关、编排、检索、推理、后处理
• 上线基础指标：TTFT、E2E、prompt/completion tokens、cost、cache_hit、rag_hit、错误率
• 建立 3 张核心看板：
  1) 体验看板（TTFT/E2E 分位数 + 错误率）
  2) 成本看板（总成本、每请求成本、按租户/场景归因）
  3) RAG/缓存看板（命中率 + 节省成本 + 与点赞/复问的关联）

H3 第 2~3 周：加上分段追踪与“慢/贵”的根因字段

• 增加 retrieval/infer/postprocess 分段耗时
• 增加 prompt_template_id、retry_count、tool_calls_count、context_tokens
• 开始做“Top N 慢请求/贵请求”榜单（按 endpoint/租户聚合）

H3 第 4 周：补齐安全审计闭环

• 审计日志独立存储、权限隔离、保留期策略
• 输入/输出/工具调用三段安全检测与 action 记录
• 高风险自动阻断 + 复盘流程（工单字段固定化）

结语：可观测性是上线后的“第二训练”

在 Ai 大模型应用里，上线后的真实数据会持续改变你对“性能、成本、质量与安全”的理解。延迟、Token 成本、命中率、安全审计这四类可观测能力，决定了你能否把模型从“能用”运营到“稳定可控、可扩展、可合规”。

如果你正在按“Ai大模型训练教程”做实战落地，建议把本篇的指标字段与实施清单作为上线验收标准：没有这些，你很难在真实流量下快速定位问题、控制预算并满足合规要求。