AI监控折腾手记

这些是最基础的，没有它们就没法理解系统行为：

• 请求量：多少用户在用，高峰期在什么时候
• 延迟：用户等待多久才能拿到结果
• 成功率：有多少请求成功了，有多少失败了

这些指标和传统 Web 服务一样，没什么特别。

为什么需要 AI 监控

最开始我们其实没有监控这个概念。那时候的 AI 应用比较简单，就一个 GPT 调用，请求进去，响应出来，看得见也摸得着。

后来业务变复杂了：多个模型串行调用、RAG 管道、工具调用、多轮对话。一旦出问题，日志里只有一长串 JSON，根本看不出来哪一步出了问题。

真实场景是这样的：

1. 用户反馈"昨天还能用的功能今天突然不行了"
2. 工程师去翻日志，发现输出确实不对
3. 但是问题出在哪里？是模型版本变了？是 prompt 漂移？还是向量检索召回了错误文档？
4. 没有监控，只能瞎猜

这就是我们决定上 AI 监控的触发点。

我们要监控什么

在动手之前，我们先把要监控的东西列清楚。不是所有东西都值得监控，重点是能快速定位问题的指标。

基础指标

这些是最基础的，没有它们就没法理解系统行为：

• 请求量：多少用户在用，高峰期在什么时候
• 延迟：用户等待多久才能拿到结果
• 成功率：有多少请求成功了，有多少失败了

这些指标和传统 Web 服务一样，没什么特别。但 AI 系统有几个特有的指标：

• Token 使用量：输入多少 token，输出多少 token
• 成本：每次请求花了多少钱
• Token 节流情况：有没有遇到速率限制

质量指标

这些是 AI 特有的，用来衡量输出质量：

• 响应相关性：输出是不是真的回答了问题
• 事实准确性：输出内容是不是符合事实
• 格式正确性：是不是按照要求的格式输出了（比如 JSON）

这些指标很难自动评估，通常需要人工标注或者用另一个模型来评估。

业务指标

从业务角度看的问题：

• 用户满意度：用户反馈的好评率
• 任务完成率：用户拿到结果后是否完成了任务
• 重复请求率：用户是不是因为不满意而重复提问

实现方案选择

在选方案的时候，我们看了几个方向：

自建监控

一开始想自己写一个监控系统。优点是灵活性高，想怎么改就怎么改。缺点也很明显：

• 要处理数据采集、存储、可视化
• 要自己实现指标计算
• 维护成本高

我们试着搞了一个最基础的版本，用 PostgreSQL 存日志，用 Grafana 做可视化。搞了两周后发现只是勉强能用，高级功能（比如自动标注、异常检测）完全没精力做。

开源工具

看了几个开源方案：

• LangSmith：功能强大，但是要自己部署，配置比较复杂
• Weights & Biases：主要面向训练阶段，推理阶段监控功能有限
• MLflow：偏向模型生命周期管理，监控功能比较基础

这些工具要么太重，要么功能不满足我们的需求。

商业方案

最后还是选了商业方案，主要是因为：

• 快速上线，不需要自己搭建基础设施
• 功能比较全面，从日志采集到异常检测都有
• 不需要投入额外的维护精力

我们用的是 Arize，体验下来还不错。市面上类似的还有 Helicone、LangSmith Cloud 等，功能大同小异。

实施步骤

集成 SDK

第一步是集成监控 SDK。以 Arize 为例，在代码里加几行就能把请求信息发过去：

from arize import Arize

client = Arize(
    api_key="YOUR_API_KEY",
    space_key="YOUR_SPACE_KEY"
)

# 在推理时记录
response = client.log(
    model_id="my-ai-model",
    prediction_id="unique-request-id",
    prediction_label="输出结果",
    actual_label="真实标签",  # 如果有的话
    features={
        "prompt": user_prompt,
        "context": retrieved_docs
    },
    environment="production"
)

这里有个坑：prediction_id 必须唯一。我们一开始用时间戳当 ID，结果并发请求时撞车了，数据都乱掉了。后来改成 UUID 就没问题了。

配置数据采集

SDK 集成后，要配置采集哪些数据：

• 输入输出文本
• 请求时间戳
• 延迟信息
• Token 使用量
• 模型版本
• 用户 ID（如果有的话）

有个注意点：不要采集敏感信息。我们一开始把用户输入原样记录，后来发现有个人信息泄露风险，改成了只记录脱敏后的内容。

设置告警

监控配置好后，要设置告警规则。我们常用的几个：

• 延迟告警：P95 延迟超过阈值时告警
• 错误率告警：失败率超过 5% 时告警
• 成本告警：单日成本超过预算时告警
• 质量异常告警：用户满意度突然下降时告警

告警渠道用企业微信和邮件。这里有个经验：不要设置太多告警，否则会被淹没在告警海洋里。我们一开始设置了十几个告警规则，最后发现真正有用的就三四个。

建立基准线

监控系统运行一段时间后，要建立基准线。这些基准线用来判断当前系统是否正常：

• 正常情况下的 P95 延迟是多少
• 正常情况下的错误率是多少
• 正常情况下的用户满意度是多少

基准线不是固定的，会随业务变化。我们的做法是每周更新一次，用最近 7 天的数据算。

踩坑记录

坑一：采样率设置不当

一开始我们把采样率设为 100%，记录所有请求。结果数据量太大，存储成本飙升，查询也变慢了。

后来改成了智能采样：正常请求采样 10%，异常请求全采样。这样既能保证问题样本不丢，又能控制成本。

坑二：评估指标不统一

我们有两个工程师在做质量评估，一个比较严格，一个比较宽松。结果就是同一批数据，两个人的评估结果差异很大。

后来制定了明确的评估标准，每条数据都按照统一的标准打分。但还是很难完全消除主观性，现在在尝试用 GPT-4 做自动化评估。

坑三：过度依赖监控

监控系统上线后，我们有点"监控依赖症"，遇到问题先看监控，有时候反而误导了方向。

有一次，监控系统显示某类问题的错误率突然上升。我们花了一整天排查，最后发现其实是某个大客户集中使用这类问题，单个请求的成功率没变，但总量大了就显得错误率上升。

监控系统是辅助工具，不是万能的。还是要结合业务背景来看。

坑四：监控成为瓶颈

有一次我们的监控系统挂了，结果整个 AI 服务都跟着挂了。原来我们当时的设计是：每次请求都要等监控系统返回才能继续。

这个问题很简单：监控系统应该是异步的，不能阻塞主流程。改成异步后就正常了。

效果评估

上监控系统半年后，我们评估了一下效果：

问题定位时间

以前定位一个问题可能要半天，现在 10 分钟就能找到方向。

有一次用户反馈某个功能突然变慢了，我们直接看监控系统，发现是某个模型的延迟突然增加。进一步排查后发现是模型提供商的节点出了问题，很快就联系到对方处理了。

成本优化

通过监控系统的成本分析，我们发现有几个模型的调用量很大但用户反馈一般。后来优化了这些模型的调用策略，成本降低了 30%。

产品改进

监控系统的用户满意度数据帮助我们识别了哪些功能好用，哪些功能不好用。产品经理用这些数据做产品决策，比以前靠拍脑袋准确多了。

架构演进

我们的监控系统也在不断演进：

最初只是简单记录日志，后来加了可视化和告警，现在在做异常检测，希望能在问题发生前就预测到。

未来方向

还有一些想做但还没做的事：

自动化根因分析

现在发现异常后，还是要靠人工分析原因。如果能自动分析出可能的原因，效率会更高。

A/B 测试框架

监控数据可以用来做 A/B 测试，比较不同模型或不同 prompt 的效果。

联邦学习

多个公司的数据联合起来训练评估模型，这样能获得更准确的质量评估。

结语

把黑盒变成透明不是一蹴而就的事，我们折腾了半年才算是基本稳定下来。

监控系统不是银弹，它解决不了所有问题。但它确实让我们对自己的系统有了更深的理解，遇到问题时不再两眼一抹黑。

如果你也在做 AI 应用，我建议早一点考虑监控这件事。等到系统变复杂了再想补，成本会高很多。

最后说一句：监控的目标不是为了看数字，而是为了发现问题、优化系统、提升用户体验。数字只是手段，不是目的。

文章写完后，我做了一次插图审阅。考虑到文章内容主要是实践经验和步骤说明，文字描述已经足够清晰，没有明显需要用图片来补充的理解缺口。因此这篇文章没有配图，保持简洁。

版权声明: 本文首发于 指尖魔法屋-AI监控折腾手记（https://blog.thinkmoon.cn/post/296-ai-monitoring-blackbox-transparent-guide/） 转载或引用必须申明原指尖魔法屋来源及源地址！