📚 喵喵的笔记库

07-LLM可观测性与生产运维

9分钟阅读

阶段四：LLM 可观测性与生产运维

第 8 周 | 核心目标：Humanizer 监控大盘上线，从"能跑"到"跑得稳、跑得省"

💡 前移理由：从阶段一就应该开始埋点（Langfuse trace 从第一行代码就接上）。到第 8 周时已有大量调用数据，可以做有意义的成本分析和质量回归检测。

Step 1：本阶段资料

| 资料类型 | 具体资料 | 用途 | |----------|---------|------| | 文档 | Langfuse 官方文档（开源） | LLM 可观测性平台，trace/span/metric | | 文档 | LangSmith 官方文档 | LangChain 生态的可观测性方案（付费） | | 工具 | OpenTelemetry + Grafana | 通用可观测性栈 | | 文章 | 《LLM Observability: What to Track and Why》| 生产环境监控方法论 | | 项目 | Humanizer 代码库 | 集成可观测性的目标项目 | | 项目 | OpenClaw 日志系统 | 已有的日志基础设施参考 |

Step 2：本阶段心智模型

心智模型 1：LLM 可观测性三支柱模型

  • 核心思想：LLM 应用的可观测性 = Traces（请求链路）+ Metrics（数值指标）+ Logs（事件日志），和传统可观测性一样，但关注点不同
  • 关键变量：
    • Traces：一次用户请求的完整链路（输入 → prompt 构建 → LLM 调用 → 后处理 → 输出），每一步的耗时和 token 消耗
    • Metrics：延迟分位（P50/P95/P99）、成功率、token/请求、成本/请求、质量评分
    • Logs：异常事件、降级事件、prompt 版本变更
  • 应用场景：Humanizer 每次改写请求的完整链路追踪、成本归因、质量回归检测
  • 局限性：LLM 输出的"质量"最难度量，Metrics 能追踪成本和延迟，但质量需要人工评估或 LLM-as-Judge
  • 相关资料：Langfuse 文档

心智模型 2：LLM 成本优化决策树

  • 核心思想：降成本不是盲目砍 API 调用，而是先看数据再决策——哪类请求最贵？哪类可以缓存？哪类可以降级到更便宜的模型？
  • 关键变量：请求类型分布、每类请求的平均 token 消耗、缓存命中率、模型成本梯度
  • 应用场景：Humanizer 的成本分析——哪些改写请求占了大头？能不能用缓存/降级/微调模型优化？
  • 局限性：需要足够的调用数据才能做分析；过早优化是万恶之源
  • 相关资料：Langfuse 成本分析面板

Step 3：本阶段分歧点

分歧 1：Langfuse（开源自部署）vs LangSmith（付费 SaaS）？

  • A 方（Langfuse 派）：开源免费，数据在自己手里，可以自部署到现有服务器
  • B 方（LangSmith 派）：LangChain 生态原生集成，开箱即用，但收费
  • 实践倾向：Langfuse。你已经习惯自部署（MemMachine、OpenClaw），数据隐私可控，长期成本低
  • 为什么重要：可观测性工具会存所有 prompt 和输出，数据在谁手里很重要

分歧 2：全量 trace 还是采样 trace？

  • A 方（全量派）：所有请求都 trace，数据完整，方便回溯问题
  • B 方（采样派）：高流量场景全量 trace 存储成本太高，采样 10% 够分析趋势
  • 实践倾向：Humanizer 当前流量不大，先全量 trace。日调用 > 10000 后考虑采样
  • 为什么重要：存储成本和排查效率的平衡

Step 4：实操项目（Humanizer 监控大盘）

项目目标：给 Humanizer 接入 Langfuse，搭建监控大盘，实时追踪每个 API 调用的延迟、成本、质量。

模块 1：Langfuse 部署与集成

  • [ ] 自部署 Langfuse（Docker，和 MemMachine 一起管理）
  • [ ] Humanizer API 接入 Langfuse SDK（每次 LLM 调用自动上报 trace）
  • [ ] 设计 trace 结构：generation（LLM 调用）+ span（prompt 构建、后处理）+ score（质量评分）
  • [ ] 配置 prompt 版本管理：每次 prompt 变更自动记录版本

模块 2：监控大盘搭建

  • [ ] 搭建实时 Dashboard：
    • 请求量趋势（按小时/天）
    • 延迟分位（P50/P95/P99）
    • Token 消耗和成本（按请求类型分组）
    • 错误率和错误类型分布
    • 用户满意度分布（👍👎 反馈）
  • [ ] 配置告警规则：
    • P95 延迟 > 10s → 告警
    • 错误率 > 5% → 告警
    • 日成本 > 预算阈值 → 告警
    • 满意度连续下降 → 告警
  • [ ] 告警通道：PushPlus 推送微信（复用已有通道）

模块 3：成本分析 & 优化

  • [ ] 分析 Humanizer 的请求类型分布和成本构成
  • [ ] 识别高成本请求：哪些类型占了大头？
  • [ ] 设计缓存策略：相似输入复用输出（语义缓存 vs 精确缓存）
  • [ ] 设计模型降级策略：简单改写用便宜模型，复杂改写用贵模型
  • [ ] 对比优化前后的成本数据，量化节省

模块 4：质量回归检测

  • [ ] 设计 LLM-as-Judge 评分 prompt（自动评估改写质量）
  • [ ] 每次 prompt 变更后自动跑质量评估（golden dataset 复用阶段二的成果）
  • [ ] 质量下降超过阈值 → 自动告警 + 回滚建议

Step 4.5：💬 AI 教练对话（做任务时用）

Prompt 1：可观测性设计

我要给 Humanizer 接入 LLM 可观测性系统。
请帮我分析：
1. trace 里应该包含哪些字段？哪些是必须的，哪些是 nice-to-have？
2. prompt 版本管理怎么做？每次改动怎么自动关联到 trace？
3. 质量评分（LLM-as-Judge）应该放在 pipeline 的哪个环节？实时算还是异步算？

Prompt 2：成本分析

Humanizer 的 API 成本比预期高 30%。
请帮我设计排查步骤：
1. 怎么按请求类型拆解成本？
2. 哪些成本是可以优化的？哪些是必要的？
3. 语义缓存和精确缓存各适合什么场景？

Step 5：关 AI 自测

关闭所有资料和 AI，纯靠记忆回答。

  1. LLM 可观测性的 Traces、Metrics、Logs 三支柱，各自关注什么？和传统 Web 应用的三支柱有什么区别？
  2. Langfuse 的 trace 里，generation 和 span 有什么区别？什么场景用哪个？
  3. 如果 Humanizer 的 P95 延迟从 3s 涨到 8s，你会怎么排查？
  4. LLM-as-Judge 做质量回归检测有什么局限性？怎么缓解？

评分：每题 25 分，≥80 分通过。

Step 6：费曼输出 + 信心校准

一句话版本：用 1 句话说清楚"LLM 可观测性为什么是生产环境必需品"。 三分钟版本：给同事解释 Humanizer 的监控大盘帮你发现了什么问题、省了多少钱。

信心自评：___/10 分 我最可能在什么地方翻车？

工程化要求

  • [ ] Langfuse 自部署运行稳定（Docker，和 MemMachine 同管理）
  • [ ] 全量 trace 覆盖（每次 LLM 调用都有 trace）
  • [ ] 监控大盘实时可用（延迟 < 1s 加载）
  • [ ] 告警规则生效（触发后 PushPlus 推送）
  • [ ] 成本分析报告可导出（按天/周/月）
  • [ ] Prompt 版本管理生效（每次变更可追溯）

验证指标

| 指标 | 目标值 | 测量方式 | |------|--------|----------| | Langfuse 部署 | ✅ 运行稳定 | 手动验证 | | Trace 覆盖率 | 100% LLM 调用 | 日志验证 | | 监控大盘 | 实时可看 | 手动验证 | | 告警响应 | < 1 分钟推送 | 模拟告警测试 | | 成本优化 | 量化节省百分比 | 优化前后对比 | | 质量回归检测 | prompt 变更后自动跑 | CI/CD 集成 |

关系图谱