LLMOps 可观测性应该记录哪些指标、日志和 Trace？
简化版
LLMOps 可观测性要覆盖技术稳定性、成本、质量和安全四类信号。常见记录包括请求链路 trace、模型名和版本、prompt 版本、token 数、延迟、错误、检索命中文档、工具调用、输出校验结果、用户反馈和安全拦截。
详细版
- 指标看趋势，例如 QPS、错误率、首 token 延迟、总延迟、token 成本。
- 日志看样本细节，例如 prompt 版本、检索结果、工具参数和模型输出。
- Trace 串起入口、RAG、工具、模型、后处理，便于定位慢在哪里。
- 质量信号包括格式合规率、引用命中率、人工反馈和离线评测结果。
- 日志要脱敏和分级保存，不能把敏感 prompt 随便落盘。
完整版教学
易错点：传统 APM 只能告诉你慢不慢，LLMOps 还要告诉你答得对不对、为什么这么答、花了多少钱。
一、这题真正考什么
易错点：传统 APM 只能告诉你慢不慢，LLMOps 还要告诉你答得对不对、为什么这么答、花了多少钱。
一次 LLM 请求要能还原“输入如何组装、检索拿到什么、调用了哪些工具、模型消耗多少、输出为何失败”。因此 Trace 的 span 边界应对应真实责任边界，而不是只记录一次 HTTP 调用。
二、核心原理和工程边界
LLM 应用的失败不只有 500 错误，还包括幻觉、漏检索、格式不合规、工具误调用和安全绕过。可观测性必须把模型相关上下文纳入 trace，但又不能泄露隐私。生产系统通常为每次请求生成 request_id，把 RAG、工具、模型和后处理的关键事件串起来。
三、带数字的工程算例
一次请求总耗时 8 秒，其中检索 300ms、重排 700ms、模型首 token 1.5 秒、decode 5 秒、后处理 500ms。没有 trace 只能感觉“慢”，有 trace 才知道主要瓶颈是输出太长还是模型首 token 慢。
总延迟 = 检索延迟 + 工具延迟 + 首 token 延迟 + decode 延迟 + 后处理延迟
单请求成本 = input_tokens_cost + output_tokens_cost + 工具成本
质量看板 = 任务成功率 + 格式合规率 + 幻觉率 + 人工反馈四、典型链路怎么跑
可以把这类问题拆成下面的链路来理解：
request_id
|
入口日志
|
RAG span：query、topK、文档版本
|
Tool span：工具名、参数摘要、状态
|
Model span：模型、token、延迟
|
Postprocess span：校验、安全、反馈五、方案对比和选择标准
| 对象 | 记录内容 | 用途 |
|---|---|---|
| Metric | 聚合数值 | 告警和趋势 |
| Log | 请求细节 | 错误分析和审计 |
| Trace | 跨组件链路 | 定位瓶颈和故障 |
| Eval | 质量样本 | 判断模型是否变差 |
六、上线后最容易出问题的地方
-
原始 prompt 和工具结果可能包含隐私，要做脱敏、采样和权限控制。
-
只监控错误码会漏掉“成功返回但答案错误”的核心问题。
-
日志默认保存哈希、长度、模板版本和脱敏摘要；只有受控采样才访问原文，并记录查看审计。
七、常见误区与追问
- 误区：LLM 应用只接入普通接口监控就够了。 HTTP 成功无法解释幻觉、引用错误、工具失败和 token 成本，需要模型与链路语义字段。
- 误区：把完整 prompt 全量落日志最方便。 其中可能含隐私、秘密和检索文档，应最小化采集、脱敏、加密并限制保留期。
- 误区：用户点赞率可以替代质量评测。 点赞受界面和选择偏差影响，且反馈稀疏；应与任务成功、人工金标和失败分类结合。
- 追问：如何设计一次 LLM 请求的 trace schema？ 记录 trace/span、租户、Prompt/模型/索引版本、token、检索 ID、工具参数摘要、阶段延迟和错误类型。
- 追问：怎样监控 hallucination？ 对可核验任务计算引用支持率和事实一致性，对开放任务抽样人工审查，并监控无证据断言。
- 追问：日志脱敏会不会影响排障？ 会损失细节，因此保留结构化特征与哈希，并为少量授权样本提供受审计的安全原文访问。
八、加强记忆
按“四张表”记：稳定性表、成本表、质量表、安全表。LLMOps 可观测的价值，是把模型黑箱外的每一步都变成可追踪证据。