自动问题检测

使用 AI 驱动的追踪（trace）分析，直接在 MLflow UI 中自动识别 LLM 应用中的质量和运营问题。

为什么要进行自动问题检测？

随着 LLM 应用在生产环境中的扩展，维护智能体（agent）质量变得越来越困难：

• 逐个审查追踪极其繁琐：随着流量增长，手动检查单个追踪已无法满足扩展需求
• 不确定使用哪些质量指标：默认评分器可自动覆盖常见情况，因此无需预先定义指标即可开始使用
• 难以识别重复出现的模式：相关故障散落在各个追踪中，缺乏自动分组
• 缺乏结构化的问题跟踪：如果没有结构化的跟踪，已识别的问题容易丢失，导致回归问题未被察觉

工作原理

问题检测使用多阶段 AI 分析流水线：

识别追踪中的问题

根据所选类别和模型，从选定的追踪中自动识别问题

分析分类（triage）结果

结合分类依据、人工反馈和智能体执行逻辑，从分类结果构建会话级分析

聚类问题

通过基于 LLM 的标注和分组，将分析结果聚类为具体已识别的问题

注释问题

为带有相应问题的追踪添加注释，包括其分析依据

总结

生成已识别问题和根本原因的摘要

分析内容

系统会检查您的追踪数据以了解：

• 输入和输出：用户请求和智能体响应
• 工具调用和结果：函数调用、API 交互及其结果
• 执行流程：Span 序列、时序和控制流
• 错误和异常：故障、超时和错误消息
• 元数据：用户反馈、标签、会话上下文

基于此数据，AI 可识别六个质量维度的问题。

问题类别 (CLEARS)

MLflow 围绕六个质量维度组织问题检测，构成了 CLEARS 框架（Correctness 正确性、Latency 延迟、Execution 执行、Adherence 依从性、Relevance 相关性、Safety 安全性）。根据您的应用需求选择关注的类别：

正确性 (Correctness)

正确性：输出在事实层面是准确的，并基于所提供的数据。可检测幻觉、事实错误和无依据的响应。

延迟

智能体在可接受的时间范围内响应。可识别响应缓慢、超时和性能瓶颈。

执行

智能体成功完成操作（工具调用、API 步骤）。可发现工具调用失败、API 错误和执行问题。

依从性

响应遵循指令、约束、策略和格式。可捕捉不遵循指令和格式化问题。

相关性

输出是有用的，直接解决了用户的请求，并使用户对交互感到满意。

安全性 (Safety)

安全性：响应避免了有害、敏感或不当内容。可检测安全违规和策略破坏。

选择类别

不同的应用有不同的优先级：

• 客户支持机器人：侧重于相关性和依从性，以确保提供有帮助且合规的响应
• 数据检索系统：优先考虑正确性和执行，以捕捉幻觉和 API 故障
• 实时智能体：强调延迟和执行，以实现响应迅速、性能可靠
• 内容生成：考虑安全性、依从性和相关性，以确保输出内容适当且不偏题

您可以为每次分析选择任意类别组合。建议从所有类别开始以获得全面覆盖，随后随着您了解应用常见的故障模式，再缩小关注范围。

检测体验

入门

您可以在任何查看追踪的地方使用问题检测：概览仪表板、追踪列表或聊天会话。准备好分析一组追踪时，启动检测并配置两项内容：

1. 要查找哪些问题类别：选择与您用例最相关的 CLEARS 维度

2. 使用哪个 LLM 进行分析：选择现有的 MLflow AI Gateway 端点，或使用 API 密钥直接连接到供应商（OpenAI、Anthropic、Gemini 等）。所有选项均支持成本跟踪。

您可以分析实验中的所有追踪，或选择特定的子集。对于多轮对话，您可以按 会话 对追踪进行分组，以获得具备上下文感知能力的分析。

实时分析

配置完成后，分析会立即开始并异步运行。您可以实时查看进度或切换到其他页面——任务会在后台继续运行。分析期间，您将看到：

• 当前状态和进度
• 已扫描的追踪数量
• 迄今已检测到的问题（实时更新）

任务完成后，您还将看到分析的预计 LLM 成本。

理解结果

分析完成后，您将收到一份 AI 生成的摘要，突出显示关键发现、严重程度分布和建议的后续步骤。在深入研究具体问题之前，此摘要可为您提供即时的上下文信息。

处理已检测到的问题

问题概览

每个检测到的问题都代表在您的追踪中发现的一组相关问题。问题信息包括：

描述

问题是什么、为什么发生，以及它在您的应用中如何表现

严重程度评级

根据影响和频率划分的高、中或低优先级

受影响追踪数量

受影响的追踪数量，并提供指向每个受影响追踪的直接链接以便调查

类别标签

此问题所属的 CLEARS 维度（正确性、延迟、执行等）

问题与其检测来源的追踪之间保持完整的关联性，因此您可以随时从问题导航回发现该问题的特定追踪。

调查问题

选择一个问题时，您可以浏览所有受影响的追踪。每个追踪都会显示其被标记的原因，并附有针对该特定示例解释问题的详细依据。这有助于您：

• 验证问题是否属实：检查被标记的追踪是否真实表现出该问题
• 理解模式：查看问题如何在不同上下文中表现
• 识别根本原因：查找受影响追踪中的共同因素
• 收集示例：收集具有代表性的案例用于调试或评估数据集，并用它们验证更改后问题是否已修复

管理和分类问题

问题状态

问题分为三种状态：

• 待处理 (Pending)：新发现的问题，等待审查
• 已解决 (Resolved)：您已修复并验证的问题
• 已拒绝 (Rejected)：误报或非问题

您可以按状态进行过滤，以专注于需要注意的问题。发现任务识别出的问题最初会被标记为“待处理”，随着调查的深入，可以将其分类为“已解决”或“已拒绝”。

细化问题

在审查问题时，您可以对其进行细化，以更好地反映您的领域知识和术语：

• 编辑描述：使用领域特定细节阐明或扩展问题描述
• 调整严重程度：根据业务影响更改优先级

这些细化有助于使发现的问题与团队的理解和优先级保持一致。

跟踪进度

在完成以下步骤后，将问题标记为“已解决”：

1. 识别并修复了根本原因
2. 将修复程序部署到您的应用
3. 验证在新追踪中该问题不再出现

在以下情况将问题标记为“已拒绝”：

• 这是误报：被标记的追踪实际上并未表现出所描述的问题
• 这是设计使然：该行为是有意的，例如刻意简短的响应或领域特定语言
• 这超出了范围：问题是真实的，但不是您的团队计划解决的问题（例如对用户影响可忽略不计的极端情况）

拒绝误报可以使您的问题列表保持重点，并防止干扰信息随时间积累。

最佳实践

有效分析

• 分析代表性数据：包含来自不同用户群体、时间段和用例的追踪
• 从全面开始：最初使用所有类别来发现应用的故障模式
• 迭代聚焦：随着了解常见问题，缩小到特定类别
• 验证结果：始终检查受影响的追踪以确认问题属实
• 定期运行：定期运行检测，以便在应用演进时捕捉新问题

成本与性能权衡

问题检测需要 LLM 调用来分析每个追踪。成本随以下因素扩展：

• 分析的追踪数量
• 追踪的复杂性和长度
• 模型大小和定价
• 选择的类别数量

成本基准

2026 年 4 月 16 日，我们对几种聊天模型的问题检测进行了内部基准测试。以下数字仅供参考——您的令牌数和美元成本会随追踪长度、类别选择、供应商定价和产品更改而有所不同。

设置：评估池中有 402 个经过验证的追踪；每次运行分析了 50、100 或 250 个追踪的确定性子集（种子值 42）

按追踪数量汇总的所有模型情况

跟踪	典型成本	已发现问题
50	$0.08–$0.42	5–9
100	$0.11–$0.53	8–13
250	$0.16–$0.93	10–22

完整模型明细

模型	跟踪	输入令牌	输出令牌	成本 (USD)	已发现问题
gpt-5.4	50	38,004	6,549	0.19	9
o3	50	25,253	10,866	0.14	6
claude-opus-4-6	50	44,219	7,935	0.42	6
claude-sonnet-4-6	50	45,139	7,837	0.25	8
gemini-3.1-pro	50	22,537	2,732	0.08	5
gpt-5.4	100	59,085	9,976	0.30	13
o3	100	51,508	25,789	0.31	8
claude-opus-4-6	100	56,128	9,985	0.53	9
claude-sonnet-4-6	100	80,965	15,062	0.47	11
gemini-3.1-pro	100	32,128	3,949	0.11	8
gpt-5.4	250	114,285	20,578	0.59	22
o3	250	61,733	30,173	0.36	12
claude-opus-4-6	250	94,152	18,174	0.93	10
claude-sonnet-4-6	250	97,299	18,062	0.56	14
gemini-3.1-pro	250	43,080	6,155	0.16	12

在我们的测试中，性能更强的模型（例如 gpt-5.4）通常能提高问题检测的质量；我们仍然建议从一个强大的默认模型开始，然后根据需要使用 Gateway 预算和更小的追踪集针对成本或延迟进行微调。

若要在大规模应用中控制成本，请通过 MLflow AI Gateway 端点进行连接，并使用其内置的预算控制功能来限制检测运行的支出。

何时使用问题检测

问题检测是对其他 MLflow 评估和监控功能的补充：

在以下情况使用问题检测：	在以下情况使用其他工具：
您想要检测未知问题	当您了解要测试的特定质量维度或假设时：使用 MLflow 评估判断器 (Evaluation Judges)
您需要一次性分析许多追踪	当您在调试单个追踪时：使用 MLflow 追踪 UI
您想要随时间跟踪、分类和解决已识别的问题	当您需要持续的生产监控时：使用 自动评估 (Automatic Evaluations) 对每个到达的追踪进行评分