LangWatch 数据可视化实战：给 AI 应用监控搭自定义仪表盘的完整指南

LangWatch 数据可视化实战：给 AI 应用监控搭自定义仪表盘的完整指南

【免费下载链接】langwatchOpen-Source Agent Observability & Evals for AI Platform teams. Trace, test, route and govern every agent & coding assistant in the company.项目地址: https://gitcode.com/GitHub_Trending/la/langwatch

有人问你：模型响应最近三天快了多少？每天烧多少 token？如果第一反应是"等我查下日志"，那你需要把 LangWatch 的 AI 应用监控数据可视化用起来——自定义仪表盘点几下配置，trace 数据、token 用量、评估通过率就能摆成一张张能看的图，这几个问题的答案直接摆在眼前。

这个能力能帮你做什么

LangWatch 的数据可视化不需要你写 SQL 或另配一套指标系统。图表构建器把 trace 数据变成一份可选的字段清单，你挑指标、挑聚合、挑样式，图就画出来了。仪表盘就是若干张这样的图拼在一起，配好后能存成自定义报表，整个团队打开看到的是同一份视图。

• 用几分钟回答"涨了多少、烧了多少"，不再翻日志
• 同一个指标既能画趋势线，也能画对比柱状图或 KPI 卡片，随场景切换
• 报表存下来就能共享，权限分查看、编辑、管理三档，团队各看各该看的

三步搭出 LangWatch 自定义仪表盘：像做 Excel 透视表

搭仪表盘和做一张 Excel 透视表很像：选字段、定聚合、挑样式，三步走完。

第一步，选字段。图表构建器支持的指标涵盖 trace 数、独立用户数、token 用量、成本、评估分数等，完整清单在 analytics 模块的图表词汇表里。我平时最关心四个：完成时间performance.completion_time，反映平均响应延迟，配avg；首 token 时间performance.first_token，决定流式回答的体感速度，看p95更真实；prompt token 用量performance.prompt_tokens，sum一下就是总开销；评估通过率evaluations.evaluation_pass_rate，avg出来是质量水位线。

第二步，定聚合。同一个字段，聚合方式不同，答案完全不同：sum是加总，avg是均值，cardinality是去重计数，"多少独立用户"只能用cardinality数。响应时间配avg常常偏乐观，p95/p99才能看到最慢那批用户真实的体感。

第三步，挑样式和分组。常用样式如下，选完再按模型、用户、主题分一分组：

一张图的全部配置就是一份结构化 JSON，等价于数据库里的一行记录，所以既能改、也能通过 graphs 接口用 API 建图挂到仪表盘上，最简形态长这样：

{ graphType: "line", timeScale: 3600000, groupBy: "metadata.model", series: [ { metric: "performance.completion_time", aggregation: "avg" }, { metric: "performance.prompt_tokens", aggregation: "sum" }, ], }

两个 LangWatch 自定义报表的真实场景

如何盯住 AI 客服的响应时长与满意度 📞

要盯什么：总对话量、响应延迟、正反馈比例。对话量是流量底盘，延迟是体感指标，正反馈比例直接对应服务质量。

怎么配：metadata.trace_id配cardinality得到对话数；performance.completion_time配p95；sentiment.thumbs_up_down配terms按正负向分组；再按topics.topics分一组，就能看到哪个话题槽在贡献投诉。时间粒度选一天一个点，勾上includePrevious会自动叠出上一周期的虚线做对比。

看到什么算达标：p95 低于 3 秒且近两周没有台阶式抬升；正反馈比例稳定在 80% 以上。如果连续两天跌破 70%，先按主题分组看分布，通常能定位到具体是哪类问题在拖后腿。

如何做多模型性能与成本对比 ⚖️

要盯什么：哪个模型又快又便宜，还不掉通过率。

怎么配：groupBy设成metadata.model，series 里放两条：performance.completion_time配avg、performance.total_cost配sum；想横向比质量，再加一条evaluations.evaluation_pass_rate配avg。时间范围取最近 30 天，图型用柱状图，模型多到柱状图挤不下时换horizontal_bar。

看到什么算达标：通过率相近的前提下，单次请求成本（总成本除以请求数）更低的那个模型更值得放量。如果某个模型的成本占比超过一半，要么换更便宜的模型顶上，要么看看缓存命中能不能再拉高一点。

进阶用法：阈值监控图与报表共享

把图型换成monitor_graph，图表会按数值自动变色：通过率高位是绿色，中间段黄色，跌破线红色，还可以标记为防护栏检查项，一眼扫过就知道哪块出了问题：

{ graphType: "monitor_graph", series: [{ metric: "evaluations.evaluation_pass_rate", aggregation: "avg" }], monitorGraph: { isGuardrail: true, disabled: false }, }

配好的图存成报表即可在团队仪表盘共享，权限分查看者（只读）、编辑者（可改配置）、管理员（完全控制）三档。更多结构细节见 dashboard 模块。

配置 AI 监控指标时容易踩的坑

1. 时间粒度选太细，折线变心电图。30 天数据按 10 分钟一个点画，稀疏时段全是零值和孤立尖峰，趋势完全被噪声盖住。日常报表用 1 小时一个点，看长周期直接用自动粒度。
2. 同一指标换聚合方式，数字对不上。trace 数用sum是总请求量，换成cardinality是去重数。开会引用数字时把聚合方式一起说出来，否则口径永远对不齐。
3. 分组维度贪多，图表变毛线团。同时按模型和主题分组，十几个类别叠在一起，谁也读不出信息。一张图只留一个分组维度，需要交叉对比时改用筛选条件收窄范围。

仪表盘不是目的，把"感觉哪里不对"变成"周二那天 p95 涨了 300 毫秒"才是。今晚就打开仪表盘构建器，先把最近 7 天的一张"响应时间 + 成本"折线图建出来，明天开会你手里就有数据了。

【免费下载链接】langwatchOpen-Source Agent Observability & Evals for AI Platform teams. Trace, test, route and govern every agent & coding assistant in the company.项目地址: https://gitcode.com/GitHub_Trending/la/langwatch