AI应用上线后最怕什么？不是模型不准，是出了问题你不知道。传统应用监控看延迟、看错误率、看CPU，LLM应用还要看prompt质量、看token消耗、看幻觉率、看用户满意度。这篇文章聊聊怎么搭建一套LLM应用的监控体系。
LLM监控和传统监控的区别
传统应用的行为是确定的：输入X一定输出Y，执行时间可预测，错误类型明确。LLM应用完全不同：同一个输入可能输出不同的结果，执行时间波动大，错误不是异常而是质量问题；
这意味着LLM监控需要关注的维度完全不同：
- 输入维度：prompt长度分布、用户意图分布、语言分布、多轮对话轮数；
- 输出维度：响应长度、延迟（首token延迟和总延迟）、token消耗、格式合规率；
- 质量维度：幻觉率、相关性评分、用户满意度（点赞/点踩）、人工审核通过率；
- 成本维度：每个请求的token成本、模型调用费用趋势、缓存命中率；
Trace记录：调试的核武器
LLM监控最有价值的数据不是聚合指标，而是Trace——每次调用的完整链路记录。Trace记录了从用户输入到最终输出的每一步：传入的prompt是什么、检索了哪些文档、调用了什么工具、工具返回了什么、最终模型是怎么生成回答的；
LangSmith
LangChain团队出品的LLM专用监控平台。接入方式非常简单：
import os
os.environ["LANGCHAIN_TRACING_V2"] = "true"
os.environ["LANGCHAIN_API_KEY"] = "your-key"
os.environ["LANGCHAIN_PROJECT"] = "my-project"
# 之后的所有LangChain调用自动记录
LangSmith的价值在于调试：用户说"回答不对"，你可以直接在LangSmith里找到那条请求，看到完整的调用链，定位是prompt问题、检索问题还是模型问题。
Langfuse
开源替代品，功能和LangSmith类似但数据完全自主：
from langfuse import Langfuse
langfuse = Langfuse()
with langfuse.start_as_current_generation(name="qa") as generation:
generation.update(input=question)
result = llm.invoke(question)
generation.update(output=result)
Prometheus + Grafana方案
适合已经有Prometheus基础设施的团队。自定义指标用Prometheus记录，Grafana做可视化：
from prometheus_client import Counter, Histogram
token_counter = Counter('llm_tokens_total', 'Total tokens', ['model', 'direction'])
latency_histogram = Histogram('llm_latency_seconds', 'Latency', ['model'])
# 在LLM调用处记录
token_counter.labels(model='gpt-4o', direction='input').inc(input_tokens)
latency_histogram.labels(model='gpt-4o').observe(latency)
关键告警规则
延迟突增：P95延迟超过阈值（比如5秒），可能是模型提供商的服务问题或prompt过长。设置渐进式告警——P95>3s是Warning，>10s是Critical；
幻觉率上升：如果有人工反馈机制（点赞/点踩），负反馈比例超过阈值时告警。比如24小时内点踩率从5%升到15%，说明模型或prompt出了问题；
Token消耗异常：突然的token消耗暴增可能是prompt注入攻击，也可能是代码bug导致prompt膨胀；
错误率飙升：HTTP 5xx错误率超过1%就该告警。LLM服务的错误通常来自超时、OOM或上游模型API故障；
实践建议
采样记录，不要记录所有请求。高流量场景下记录所有请求的成本太高，采样率1-10%足够发现问题趋势，同时保留完整的错误日志；
关联用户反馈。把用户的点赞/点踩和对应的Trace关联起来，这样可以分析"用户不满意时模型的输出有什么特征"；
定期审查prompt。不是监控系统的活，但比监控更重要。每周review一次高频prompt的输出质量，主动发现问题比被动接收告警有效；
写在最后
LLM监控的核心挑战是"质量不可量化"。延迟、错误率这些硬指标好监控，但"回答好不好"这个软指标很难自动化判断。结合自动监控和人工审查，是目前最务实的方案。