Miro 如何利用 Amazon Bedrock 提高软件错误路由准确性并从天级缩短至小时级解决时间

标题：Miro 如何利用 Amazon Bedrock 提高软件错误路由的准确性并从数天缩短到数小时解决时间 | Amazon Web Services

URL 来源：https://aws.amazon.com/blogs/machine-learning/how-miro-uses-amazon-bedrock-to-boost-software-bug-routing-accuracy-and-improve-time-to-resolution-from-days-to-hours/

发布时间：2026-05-11T09:03:00-08:00

Markdown 内容： _本文由 Miro 的 Philipp Pavlov、Dmytro Romantsov、Evgeny Mironenko 和 Gowri Suryanarayana 共同撰写。_

Miro 是一个支持全球超过 9500 万用户的 AI 驱动创新工作空间，帮助团队将零散的想法转化为有条理的工作流程。为了支持这一规模并继续优化其系统，Miro 的开发人员体验团队决定为其自身创建一个创新工作空间，使用现代技术来提高开发人员的生产力。该团队面临的一个关键挑战是如何高效地将软件错误分配给负责的团队。快速且准确的错误路由可以减少不必要的上下文切换，降低开发人员的挫败感，缩短解决问题的时间，并最终带来更好的产品和更满意的客户。在 Miro，由于错误分配不当以及团队之间的重复重新分配，大量错误未能达到内部的解决服务水平协议（SLA）。这一问题每年导致约 42 年的累计生产力损失，主要来自延迟和冗余调查工作。为了解决这个问题，Miro 与 AWS 原型设计和云工程（PACE）团队合作开发了 BugManager，这是一个基于 AI 的自动化错误分类解决方案。

在这篇文章中，我们将深入探讨我们用于改进 Miro 错误路由的架构和技术，实现了六倍的团队重新分配减少和五倍的解决时间缩短，这一切都得益于 Amazon Bedrock。

挑战：准确地将错误报告路由到大约 100 个软件团队

在现代软件环境中实现错误分类自动化非常复杂。错误报告通常杂乱无章，缺乏上下文，并包含多种数据类型，包括文本、堆栈跟踪、截图甚至视频。在专注于软件的公司中，这种复杂性会随着团队数量的增加而加剧，形成一个多类分类问题，可能有众多标签。Miro 的工程组织由近 100 个团队组成，每个团队负责特定的产品方面。高精度的错误分类需要从各种来源（包括 GitHub 拉取请求、Confluence 文档、README 文件和之前解决的工单）中补充相关的产品信息。此外，组织结构是动态变化的——团队合并、新团队成立，产品不断发展，持续改变团队的责任。同样，软件功能的新增、更新或弃用也会影响这一点。传统的基于自然语言处理（NLP）的文本分类器，例如微调的 BERT 模型或微调的大语言模型（LLM）分类器，在这些动态环境中面临严重限制。当组织发生变化时，它们需要重新训练，并依赖于可能不存在于新结构中的标记数据。Miro 使用现有基于微调 GPT 模型的解决方案时，性能迅速下降。认识到这些挑战后，Miro 选择了基于 LLM 的方法，结合优化的团队分类提示和检索增强生成（RAG）上下文检索，创建了一个更具适应性、无需训练且更高精度的错误分类解决方案：BugManager。

BugManager：基于 Amazon Bedrock 的 RAG 驱动错误分类

BugManager 采用基于 LLM 的方法对错误进行分类。当收到新的错误报告时，BugManager 分类系统开始运作。BugManager 首先使用 Amazon Nova Pro 的 多模态图像和视频理解能力 解析非文本数据，如截图或屏幕录制。然后，系统使用 Amazon Bedrock Knowledge Bases 的 RAG 从多个知识库中丰富解析后的报告。这些知识库包含已解决的 Jira 问题、GitHub 拉取请求、Confluence 文档和 GitHub README 文件等内容。通过 Amazon Bedrock 上的 Anthropic’s Claude Sonnet 4，系统将丰富的错误描述与每个团队及其职责的详细文本信息结合起来，生成一个单一的优化分类提示，执行正确的团队路由。作为可选功能，系统还可以生成详细的根因分析，结合从整个 Miro 代码库中检索的信息，提供对该问题的更深入洞察，并提出如何解决问题的假设。

为了实现无缝采用和使用，BugManager 通过简单的 Slack 工作流向 Miro 工程社区开放。下图显示了用户与 BugManager 交互的一个示例。根据错误的初始描述，BugManager 提出多达五个合适的团队（按优先级排序），并附带理由。默认情况下，错误会被路由到最有可能的团队，但用户可以选择手动覆盖此选择。可选地，BugManager 还可以为工程师提供所报告错误的根因分析，基于从整个 Miro 代码库中检索的信息。

在接下来的部分中，我们将深入探讨 BugManager 的架构。

架构深度解析

BugManager 主要使用 Amazon Bedrock，这是一项完全托管的服务，通过单一 API 提供来自领先 AI 公司的高性能基础模型 (FM) 的选择。借助 Amazon Bedrock Knowledge Bases、Anthropic 的 Claude Sonnet 4 和 Amazon Nova Pro on Amazon Bedrock，我们开发了一个端到端的工作流，将发布在 Slack 上的错误描述转换为在 Jira 中创建的问题，并分配给团队解决。

BugManager 在 Amazon Elastic Kubernetes Service (Amazon EKS) 集群中作为一个 Python 微服务运行。架构和应用流程如下图所示。

BugManager 工作流包括以下步骤：

1. 提交用户反馈报告。
2. 解析媒体附件。
3. 使用上下文丰富用户反馈。
4. 将用户反馈路由到正确的团队。
5. 生成根本原因分析。
6. 将结果返回给用户以供审查。

在接下来的部分中，我们将更详细地探讨这些步骤。

步骤 1：提交用户反馈报告

用户在专用的 Slack 频道中发布反馈报告（例如，一个错误）。报告可能包含文本和媒体附件。媒体附件可能包括一段视频（通常是屏幕录制），用于描述重现错误的过程，一张显示错误的截图，或者一张产品页面的截图以增强功能。错误报告以 JSON 对象的形式传递，其中包含内容（文本）以及附加到 Amazon Simple Storage Service (Amazon S3) 中的附件链接。

步骤 2：解析媒体附件

如果消息包含媒体附件，则必须将其解析为文本，以便在后续步骤中以单一模态（文本）进行错误分析和分类。我们使用 Amazon Nova Pro 的图像理解能力将媒体附件描述解析为文本。这种方法的一个挑战是，默认情况下 LLM 不具备上下文感知能力；它缺乏关于图像类型的必要信息（通常是一张 Miro 产品的截图），无法以特定且有用的方式解释它。因此，为了提供所需的上下文，我们首先基于错误文本运行 RAG，补充提示信息，以包含媒体资产中可能显示的具体功能的相关信息。我们的 RAG 方法使用 Amazon Bedrock Knowledge Bases 自动从 Miro 的内部产品文档中获取数据。这显著提高了从附件中提取信息的准确性。解析完成后，媒体附件的文本描述会被追加到原始错误文本中，并传递到应用程序工作流的下一步。

步骤 3：使用上下文丰富用户反馈

我们使用 Amazon Bedrock Knowledge Bases 从各种来源自动获取数据，并为 FMs 提供来自 Miro 内部和外部数据源的上下文信息。Amazon Bedrock Knowledge Bases 是一项完全托管的功能，具有内置的会话上下文管理和来源归属功能，帮助您实现整个 RAG 工作流——从数据摄取到检索和提示增强——而无需构建自定义的数据源集成或管理数据流。更具体地说，我们使用 Amazon S3 和 Confluence 连接器作为数据源。我们配置了 Amazon OpenSearch Serverless，即 Amazon OpenSearch Service 的按需无服务器选项，作为向量存储。我们在知识库中索引了以下数据源：Confluence 文档、Miro 帮助中心文章、已解决的 Jira 工单、GitHub README 文件以及 Backstage 文档（技术文档和软件目录）。Amazon Bedrock Knowledge Bases 支持增量重新同步，这使得以经济高效的方式保持知识库与文档更改同步变得简单（只有修改过的文档会被重新嵌入和重新索引）。

步骤 4：将用户反馈路由到正确的团队

借助 Amazon Bedrock 和 Anthropic 的 Claude Sonnet 4，我们将错误路由到负责的团队。LLM 用于正确分类的上下文包括丰富的错误描述、如果存在则附加的附件描述，以及在 Backstage 中集中策划和版本化的团队描述（由 GitHub 支持）。团队描述是动态文档，可以根据需要随时更新。Miro 的产品和工程组织是动态结构。产品功能可能会增加或废弃，团队职责也会发生变化。鉴于 BugManager 的基于提示的方法，只需更新相应的团队描述（一个用英语编写的 markdown 文件），即可轻松纳入这些更新。更改会立即传播。以下是我们在错误到团队分类中使用的简化版提示。请注意输出中 <xml> 标签的使用，这允许对输出进行稳健解析。

ROUTING_PROMPT = """
您是 Miro 的错误报告路由助手，Miro 是一家提供协作和画布软件的公司。您的职责是分析传入的错误报告，并确定哪个软件团队应该处理它们。您的目标是根据各个团队的责任范围，准确地将每个错误报告路由到最合适的 Miro 软件团队。
在分析错误报告时，请按照以下步骤操作：
1. 仔细阅读提供的团队描述，了解每个团队的专业领域和责任范围。
2. 分析错误报告中的以下内容：
   - 受影响的系统或组件
   - 技术关键词和技术术语
   - 错误消息或堆栈跟踪
   - 用户影响和行为
   - 相关的功能、特性和功能
3. 将错误详情与每个团队的责任进行比较。
4. 根据以下方面选择最合适的 Miro 软件团队：
   - 对受影响组件的直接所有权
   - 所需的技术专长
   - 历史处理类似问题的能力
   - 跨领域的关注点和依赖关系
返回五个最合适的软件团队，并分别为每个选择提供高、中、低的信心级别以及相应的理由。将答案分别用 `<team>`、`<confidence>` 和 `<rationale>` XML 标签括起来。
以下是错误报告的详细信息和每个 Miro 软件团队的责任描述：
错误详情和上下文：
<bug_report>
{bug_report}
</bug_report>
<parsed_bug_attachments>
{parsed_attachments}
</parsed_bug_attachments>
<context>
{parsed_attachments}
</context>
Miro 软件团队描述：
<teams_info>
{teams_info}
</teams_info>
Miro 团队描述
一步一步思考！
""".strip()

SQL

BugManager 在错误到团队路由的准确性上达到了超过 75% 的前 1 名准确率（比基于微调 NLP 模型的现有内部解决方案提高了 70%）。平均分类延迟为 53 秒，在生产环境中部署时证明是实用的。BugManager 返回多达五个可能的团队选项（按置信度排名，具体数量可配置）。前 3 名准确率为 95%，当结合人工参与的方法时，已被证明进一步提升了分类准确性。这些结果得益于 Anthropic 的 Claude 的扩展思维，这带来了额外的 7-9% 的准确性提升。

对于每个分类，该解决方案还提供了详细的理由，解释为什么做出了特定的路由决策。这显著提高了用户对系统的接受度和信任度，而相比之下，微调的 NLP 解决方案仅返回一个团队且没有进一步解释。

第 5 步：生成根本原因分析

BugManager 可选生成错误的根本原因分析。同样，我们利用 Amazon Bedrock 知识库提供必要的上下文来运行此类分析，这次参考了整个 Miro GitHub 代码库。在根本原因分析过程中，我们将 LLM（Anthropic 的 Claude Sonnet 4，启用扩展思维）提供错误描述、之前检索到的上下文以及选定的修复错误的软件团队。然后，LLM 使用 Amazon Bedrock 知识库检索相关的代码部分，并生成一组关于观察到的错误的根本原因假设。通过这样做，它减轻了软件工程师识别行动方向所需的调研工作。

第 6 步：将结果返回给用户以供审查

分类的结果和根本原因分析（可选）作为对初始消息的响应发送到 Slack。用户可以查看路由结果并根据需要修改默认选择。之后，创建一个包含原始错误描述和支持文档（从知识库中检索）以及根本原因分析结果的 Jira 工单，并将其分配给选定的团队。

结论

BugManager 具备多个关键特性，使其成为由 Amazon Bedrock 提供支持的强大错误分类解决方案，已在 Miro 的工程组织中取得了显著成功。这些关键特性包括：

• 高准确率的一次性错误到团队路由
• 多类别预测带来的性能提升，实现人工参与的决策过程
• 透明的路由决策，提高用户接受度
• 错误根本原因分析加速解决
• 持续更新的组织知识增强
• 对团队职责变化的稳健性和灵活性

BugManager 在生产环境中成功路由了成千上万的错误和支持请求，为 Miro 的开发流程带来了卓越成果。该系统使客户支持请求的团队重新分配减少了六倍，中位解决时间提高了五倍，将原本需要几天的工作缩短为几个小时。预计 BugManager 每年将节省数年的累积等待和调查时间，最终带来显著改进的 Miro 产品体验。

要开始构建自己的反馈路由系统，请探索 AWS 生成式 AI 资源和示例架构 AWS 上的生成式 AI，其中您可以找到逐步指南、参考实现和最佳实践，以加速您迈向 AI 驱动运营效率的旅程。

• * *

关于作者