什么是 LLM 可观测性？
LLM 可观测性关注调用延迟、错误、Token 用量与输出评估。本文区分用量和费用，并说明 Prompt 采样、隐私与 APM 接入前提。
直接回答：LLM 可观测性是面向大模型应用的监控与分析实践，记录调用状态、Token 用量和延迟，并结合测试或反馈评估质量。Prompt 与响应内容按授权和最小化原则采样，不能默认全量保留或仅凭 Trace 判断答案正确。
为什么传统 APM 不够用
接入 LLM 后，应用出现了一组传统监控盲区：
- 输出质量无法靠状态码判断：接口返回 200，回答却可能是幻觉或跑题
- 成本是新维度：每次调用按 Token 计费，流量不变功能调整也可能让账单翻倍
- 非确定性：相同输入不同输出，传统"测试一次就放心"的模式失效
- Prompt 是生产变量：Prompt 调整等同代码发布，需要版本管理与效果对比
LLM 可观测性就是在经典三支柱之上，补上"质量"和"成本"这两根新支柱。
核心监控维度
| 维度 | 关键数据 | 典型告警 |
|---|---|---|
| 性能 | 首 Token 延迟（TTFT）、端到端耗时、吞吐 | 延迟 P99 超阈值 |
| 成本 | 输入/输出 Token 量、按功能与租户分摊的费用 | 日消耗环比突增 |
| 可用性 | API 错误率、限流（429）次数、超时率 | 错误率超 1% |
| 质量 | 输出相关性/准确性评估分、幻觉检出、用户负反馈率 | 评估分连续下滑 |
| 内容 | 经授权采样的内容或摘要 | 敏感信息泄露、越狱尝试 |
关键技术手段
1. 调用埋点：通过 SDK 包装、代理网关或 OpenTelemetry 语义约定（GenAI 语义规范）采集可用的调用元数据；GenAI 约定仍需按所用版本与字段稳定性核对。
2. 输出评估：
- 规则类：格式校验、关键词、长度
- 模型类：LLM-as-a-Judge 打分
- 业务类：任务完成率、人工抽检
3. 实验与回归：Prompt/模型变更先跑评测集回归，再灰度上线，上线后对比新旧版本的生产指标。
4. 反馈回路：用户点赞/点踩、工单关联，把真实反馈回流成评估数据。
落地建议（按优先级）
- 先记账：每次调用记录 Token 与耗时——这样可以识别消耗占比偏高的功能，不预设节省比例
- 再留痕：优先记录关联 ID 与摘要；确有需要时采样保存经授权且采集前脱敏的内容，辅助追溯
- 后评估：从最重要的 1-2 个场景开始建质量评估，不要试图一开始全覆盖
开始接入时，可选一条有明确预期结果的模型任务作为样本。按观测云 Agent 文档接入受支持的应用或框架后，核对调用耗时、模型字段与应用记录的用量，再检查工具调用是否串在正确层级；质量评分另由评估用例提供，敏感 Prompt 与响应按需脱敏留存。
常见问题（FAQ）
Q：LLM 可观测和普通 API 监控的本质差异是什么？
A：多了两件事：成本（Token 计量）与质量（输出好坏需要评估而非状态码）。其余部分——延迟、错误率、链路追踪——可以复用现有 APM 体系。
Q：自己包一层 SDK 记录调用数据就够了吗？
A：对单模型单场景够用，这正是推荐的第一步。当场景变多、需要跨团队分摊成本、做版本效果对比时，再引入统一平台或 OpenTelemetry 标准埋点，避免自建系统失控膨胀。
Q：评估输出质量一定要上 LLM-as-a-Judge 吗？
A：不一定。先用便宜的：格式/长度规则、业务转化率、用户反馈按钮。只有这些信号不足以回答"回答得好不好"时，再引入模型评分，并先用人工抽检校准它的可靠性。
参考资料
资料核对日期：2026 年 9 月 29 日。本文基于公开文档整理，代码片段和评估方案未作独立运行或性能验证；厂商测试结果已注明来源。
