Esta publicación es coautora de Philipp Pavlov, Dmytro Romantsov, Evgeny Mironenko y Gowri Suryanarayana de Miro.
Miro es un espacio de trabajo de innovación impulsado por IA que atiende a más de 95 millones de usuarios en todo el mundo y ayuda a los equipos a transformar ideas no estructuradas en flujos de trabajo organizados. Para respaldar esta escala y continuar mejorando su sistema, el equipo de experiencia de desarrolladores de Miro decidió crear un espacio de trabajo de innovación para Miro, utilizando tecnologías modernas para impulsar la productividad de los desarrolladores. Uno de los desafíos clave que enfrenta el equipo es enviar de manera eficiente los errores de software a los equipos responsables. El enrutamiento de errores rápido y preciso elimina cambios de contexto innecesarios, reduce la frustración de los desarrolladores, mejora el tiempo de resolución y, en última instancia, genera un mejor producto y clientes más satisfechos. En Miro, un porcentaje significativo de errores no cumplen con los SLA de resolución interna, principalmente debido a enrutamientos incorrectos y reasignaciones repetidas entre equipos. Este problema resulta en aproximadamente 42 años de pérdida acumulada de productividad anualmente debido a retrasos y esfuerzos de investigación redundantes. Para abordar este problema, Miro se asoció con el equipo de AWS Prototyping and Cloud Engineering (PACE) para desarrollar BugManager, una solución impulsada por IA para la clasificación automatizada de errores.
En esta publicación, profundizamos en la arquitectura y las técnicas que utilizamos para mejorar el enrutamiento de errores de Miro, logrando seis veces menos reasignaciones de equipo y cinco veces menos tiempo de resolución con la tecnología de Amazon Bedrock.
Desafío: enviar con precisión informes de errores a aproximadamente 100 equipos de software
Automatizar la clasificación de errores en entornos de software modernos es complejo. Los informes de errores suelen ser confusos, carecen de contexto y contienen datos diversos, incluidos texto, seguimientos de pila, capturas de pantalla e incluso vídeos. La complejidad se multiplica en empresas centradas en software con muchos equipos, creando un problema de clasificación multiclase con numerosas etiquetas posibles. La organización de ingeniería de Miro consta de casi 100 equipos, cada uno responsable de aspectos específicos del producto. La clasificación de errores de alta precisión requiere aumentar los informes con información relevante del producto de varias fuentes, incluidas las solicitudes de extracción de GitHub, la documentación de Confluence, los archivos README y los tickets resueltos previamente. Además, las estructuras organizativas son dinámicas: los equipos se fusionan, se forman nuevos equipos y los productos evolucionan, cambiando continuamente las responsabilidades del equipo. Lo mismo se aplica a las funciones de software que se agregan, actualizan o desaprueban. Los clasificadores de texto tradicionales basados en el procesamiento del lenguaje natural (NLP), como los modelos BERT ajustados o los clasificadores de modelos de lenguaje grande (LLM) ajustados, enfrentan graves limitaciones en estos entornos dinámicos. Requieren reentrenamiento cuando ocurren cambios organizacionales y dependen de datos etiquetados que podrían no existir para nuevas estructuras. Miro experimentó una rápida degradación del rendimiento con una solución existente basada en un modelo GPT ajustado. Al reconocer estos desafíos, Miro optó por un enfoque impulsado por LLM que combina indicaciones optimizadas para la clasificación de equipos con recuperación de generación aumentada (RAG) para la recuperación de contexto, creando una solución de clasificación de errores más adaptable, sin entrenamiento y de mayor precisión: BugManager.
BugManager: clasificación de errores basada en RAG con tecnología de Amazon Bedrock
BugManager adopta un enfoque basado en LLM para la clasificación de errores. Cuando se recibe un nuevo informe de error, el sistema de clasificación BugManager toma medidas. BugManager primero analiza datos que no son texto, como capturas de pantalla o grabaciones de pantalla, utilizando las capacidades multimodales de comprensión de imágenes y videos de Amazon Nova Pro. Luego, el sistema enriquece el informe analizado con contexto importante de varias bases de conocimiento (utilizando las bases de conocimiento de Amazon Bedrock) con RAG. Estas bases de conocimiento contienen, por ejemplo, problemas de Jira resueltos previamente, solicitudes de extracción de GitHub, documentación de Confluence y archivos README de GitHub. Utilizando Claude Sonnet 4 de Anthropic en Amazon Bedrock, el sistema combina las descripciones de errores enriquecidas junto con información textual detallada sobre cada equipo y sus responsabilidades en un mensaje de clasificación único y optimizado que realiza la ruta al equipo correcto. Como característica opcional, el sistema también puede generar un análisis detallado de la causa raíz, utilizando la información recopilada en combinación con la recuperación de repositorios de código fuente relevantes para proporcionar información más profunda sobre el problema y ofrecer hipótesis sobre cómo resolverlo.
Para permitir una adopción y un uso sin fricciones, BugManager está expuesto a la comunidad de Miro Engineering a través de un flujo de trabajo simple basado en Slack. La siguiente captura de pantalla muestra un ejemplo de la interacción de un usuario con BugManager. Según la descripción inicial del error, BugManager propone hasta cinco equipos adecuados (en orden de prioridad) junto con una justificación. De forma predeterminada, el error se dirige al equipo más probable, pero los usuarios pueden sobrescribir manualmente esta selección. Opcionalmente, BugManager también proporciona a los ingenieros un análisis de la causa raíz del error informado, basándose en la información recuperada de la base de código completa de Miro.
En las siguientes secciones, nos sumergimos en la arquitectura de BugManager.
Análisis profundo de la arquitectura
BugManager utiliza principalmente Amazon Bedrock, un servicio totalmente administrado que ofrece una selección de modelos básicos (FM) de alto rendimiento de empresas líderes en inteligencia artificial a través de una única API. Con Amazon Bedrock Knowledge Bases, Claude Sonnet 4 de Anthropic y Amazon Nova Pro en Amazon Bedrock, desarrollamos un flujo de trabajo de un extremo a otro que convierte una descripción de error publicada en Slack en un problema creado en Jira y asignado a un equipo para su resolución.
BugManager se ejecuta como un microservicio de Python en un clúster de Amazon Elastic Kubernetes Service (Amazon EKS). La arquitectura y el flujo de la aplicación se muestran en el siguiente diagrama.
El flujo de trabajo de BugManager consta de los siguientes pasos:
Enviar informe de comentarios de los usuarios. Analizar archivos adjuntos multimedia. Enriquezca los comentarios de los usuarios con contexto. Dirija los comentarios de los usuarios al equipo correcto. Generar análisis de causa raíz. Devolver los resultados al usuario para su revisión.
En las siguientes secciones, exploramos estos pasos con más detalle.
Paso 1: enviar el informe de comentarios de los usuarios
Un usuario publica un informe de comentarios (por ejemplo, de un error) en un canal dedicado de Slack. El informe puede contener texto y archivos adjuntos multimedia. Los archivos adjuntos multimedia pueden incluir un vídeo (normalmente una grabación de pantalla) que describe el proceso para reproducir el error, una captura de pantalla que muestra el error o una captura de pantalla de la página de un producto para mejorar las funciones. El informe de error se entrega como un objeto JSON, que incluye el contenido (texto) y el enlace a los archivos adjuntos depositados en Amazon Simple Storage Service (Amazon S3).
Paso 2: analizar los archivos adjuntos multimedia
Si el mensaje contiene archivos adjuntos multimedia, estos deben analizarse en texto para permitir el análisis y la clasificación de errores en una única modalidad (texto) en pasos posteriores. Utilizamos las capacidades de comprensión de imágenes de Amazon Nova Pro para analizar la descripción del archivo adjunto multimedia como texto. Un desafío con este enfoque es que el LLM no tiene en cuenta el contexto de forma predeterminada; carece de información sobre el tipo de imagen (normalmente una captura de pantalla del producto Miro) para interpretarla de forma específica y útil. Por lo tanto, para proporcionar el contexto requerido, primero ejecutamos RAG en función del texto del error para complementar nuestro mensaje con información sobre la característica específica que probablemente se muestra en el recurso multimedia. Nuestro enfoque RAG utiliza las bases de conocimiento de Amazon Bedrock para recuperar automáticamente datos de la documentación interna del producto de Miro. Esto mejora significativamente la especificidad de la información extraída del archivo adjunto. Una vez analizado, la descripción de texto del archivo adjunto multimedia se agrega al texto del error original y se pasa al siguiente paso en el flujo de trabajo de la aplicación.
Paso 3: enriquecer los comentarios de los usuarios con contexto
Utilizamos las bases de conocimientos de Amazon Bedrock para obtener automáticamente datos de varias fuentes y proporcionar a los FM información contextual de una amplia gama de fuentes de datos internas y externas de Miro. Amazon Bedrock Knowledge Bases es una capacidad totalmente administrada con administración de contexto de sesión integrada y atribución de fuente que le ayuda a implementar todo el flujo de trabajo de RAG, desde la ingesta hasta la recuperación y el aumento rápido, sin tener que crear integraciones personalizadas con fuentes de datos ni administrar flujos de datos. Más específicamente, utilizamos Amazon S3 y el conector Confluence como fuentes de datos. Configuramos Amazon OpenSearch Serverless, la opción sin servidor bajo demanda de Amazon OpenSearch Service, como un almacén de vectores. Indexamos las siguientes fuentes de datos en la base de conocimientos: documentación de Confluence, artículos del centro de ayuda de Miro, tickets de Jira resueltos, archivos README de GitHub y documentos Backstage (documentación técnica y catálogo de software). Amazon Bedrock Knowledge Bases admite resincronizaciones incrementales, lo que hace que sea sencillo mantener la base de conocimientos actualizada con los cambios de documentación de una manera rentable (solo se reincrustan e indexan los documentos modificados).
Paso 4: Dirija los comentarios de los usuarios al equipo correcto
Con la ayuda de Amazon Bedrock y Claude Sonnet 4 de Anthropic, enviamos el error al equipo responsable. El contexto proporcionado al LLM para realizar la clasificación correcta consiste en la descripción del error enriquecida, la descripción del archivo adjunto enriquecida, si el archivo adjunto está disponible, y las descripciones del equipo que están seleccionadas y versionadas centralmente en Backstage (respaldadas por GitHub). Las descripciones de los equipos son documentos vivos que se pueden actualizar cuando sea necesario. La organización de productos e ingeniería de Miro son construcciones dinámicas. Las características del producto se agregan o dejan de estar disponibles y las responsabilidades del equipo cambian. Dado el enfoque basado en indicaciones de BugManager, dichas actualizaciones se pueden incorporar con relativa facilidad simplemente actualizando las descripciones de los equipos respectivos (un archivo de rebajas escrito en inglés). Los cambios se propagan inmediatamente. La siguiente es una versión simplificada del mensaje que utilizamos para la clasificación de error a equipo. Tenga en cuenta el uso de etiquetas en la salida, lo que permite un análisis sólido de las salidas.
BugManager logra una precisión máxima para el enrutamiento de errores a equipos de más del 75 % (un aumento del 70 % en comparación con una solución interna existente basada en un modelo de PNL ajustado). La latencia de clasificación promedio es de 53 segundos, lo que resultó práctico cuando se implementó en producción. BugManager devuelve hasta cinco opciones probables de equipo (clasificadas por confianza, el número exacto es configurable). La precisión de los 3 primeros es del 95%, lo que, cuando se combina con un enfoque humano involucrado, se ha demostrado que aumenta aún más la precisión de la clasificación. Estos resultados fueron posibles gracias al pensamiento ampliado de Claude de Anthropic, que resultó en ganancias de precisión adicionales del 7% al 9%.
Para cada clasificación, la solución también proporciona una justificación integral de por qué se tomó una determinada decisión de ruta. Esto mejoró significativamente la aceptación y la confianza del usuario en comparación con la solución de PNL optimizada que solo devolvió un equipo sin más explicaciones.
Paso 5: Generar análisis de causa raíz
BugManager puede opcionalmente generar un análisis de la causa raíz del error. Nuevamente, proporcionamos el contexto necesario para ejecutar dicho análisis utilizando las bases de conocimiento de Amazon Bedrock, esta vez basándose en todo el código base de Miro GitHub como referencia. Durante el análisis de la causa raíz, proporcionamos al LLM (Claude Sonnet 4 de Anthropic con pensamiento extendido habilitado) la descripción del error, el contexto recuperado previamente y el equipo de software seleccionado para resolver el error. Luego, el LLM recupera las secciones de código respectivas utilizando las bases de conocimiento de Amazon Bedrock y genera un conjunto de hipótesis para la causa raíz del error observado. Al hacerlo, libera a los ingenieros de software del trabajo de investigación necesario para identificar un curso de acción.
Paso 6: devolver los resultados al usuario para su revisión
El resultado de la clasificación y el análisis de causa raíz (opcional) se envía a Slack como respuesta al mensaje inicial publicado. Los usuarios pueden revisar los resultados de enrutamiento y realizar cambios en la opción predeterminada si es necesario. Después de eso, se corta y se asigna al equipo seleccionado un ticket de Jira con la descripción del error original y la documentación de respaldo recuperada de las bases de conocimiento, así como los resultados del análisis de la causa raíz.
Conclusión
BugManager cuenta con varias características clave que lo convierten en una solución de clasificación de errores altamente capaz impulsada por Amazon Bedrock que se ha adoptado con gran éxito en toda la organización de ingeniería de Miro. Estas características clave incluyen:
Enrutamiento de alta precisión desde el primer intento del error al equipo Mayores aumentos del rendimiento a través de la predicción multiclase que permite la toma de decisiones humanas en el circuito Decisiones de enrutamiento transparentes que impulsan la aceptación del usuario Análisis de la causa raíz del error para acelerar la resolución Aumento con conocimiento organizacional continuamente actualizado Robustez y flexibilidad ante los cambios en las responsabilidades del equipo
BugManager ha solucionado con éxito miles de errores y solicitudes de soporte en producción, brindando resultados excepcionales para el flujo de trabajo de desarrollo de Miro. El sistema ha logrado una reducción de seis veces en las reasignaciones de equipos para solicitudes de atención al cliente y una mejora de cinco veces en el tiempo medio de resolución, transformando lo que antes tomaba días en procesos que duraban horas. Se prevé que BugManager ahorre años de espera acumulada y tiempo de investigación anualmente y, en última instancia, brindará una experiencia de producto Miro significativamente mejor.
Para comenzar a crear su propio sistema de enrutamiento de comentarios hoy, explore los recursos de IA generativa de AWS y las arquitecturas de muestra en Generative AI en AWS, donde puede encontrar guías paso a paso, implementaciones de referencia y mejores prácticas para acelerar su viaje hacia la eficiencia operativa impulsada por la IA.
Sobre los autores
Philipp Pavlov
Philipp es líder técnico y de productos en Miro, y dirige la habilitación de desarrolladores que priorizan la IA y las iniciativas de eficacia operativa a gran escala. Dirige el trabajo en Miro Digital Twin, una capa de conocimiento semántico conectada que reúne el contexto en todos los sistemas de la empresa, lo que permite flujos de trabajo de IA conscientes del contexto y la toma de decisiones basada en el contexto.
Dmytro Romantsov
Dmytro es un ingeniero senior de SRE y experiencia de desarrollador con más de 12 años de experiencia en infraestructura de nube, ecosistema JVM e IA aplicada. Construye plataformas internas y automatización que ayudan a los equipos de ingeniería a moverse más rápido y operar de manera más confiable. Sus áreas de enfoque incluyen herramientas para desarrolladores, habilitación de IA, propiedad y gobernanza de software, eficiencia operativa y de costos, y excelencia en producción, convirtiendo sistemas fragmentados en bases escalables que mejoran la velocidad, la confiabilidad y los resultados comerciales.
Evgeny Mironenko
Evgeny es un ingeniero de software que trabaja en tecnologías frontend, backend y de inteligencia artificial y se especializa en la creación de plataformas internas escalables. Su enfoque está en unificar sistemas, mejorar la experiencia de los desarrolladores y permitir que los equipos avancen más rápido a través de la automatización y sólidas bases de ingeniería.
Gowri Suryanarayana
Gowri es analista y desarrollador de datos en Miro, con experiencia en ciencia de datos e inteligencia artificial. Se especializa en la construcción de infraestructura de análisis de datos y gráficos de conocimiento interno, enfocándose en conectar sistemas de ingeniería y vincular código, documentación, equipos, personas y seguimiento del trabajo para brindar información sobre la productividad de los desarrolladores y el conocimiento organizacional.
Dr. Karsten Schröer
Karsten es arquitecto senior de prototipos de aprendizaje automático (ML) en AWS y se especializa en IA generativa, modelos básicos y técnicas avanzadas de ML. Con una profunda experiencia en los dominios de IA/ML, colabora con los clientes a través del desarrollo conjunto para abordar problemas complejos y desafiantes y acelerar su viaje desde el concepto hasta la producción. La fortaleza de Karsten radica en traducir los avances teóricos de vanguardia en soluciones prácticas y listas para producción que brindan un impacto comercial mensurable. Karsten tiene un doctorado en aprendizaje automático aplicado.
Eleni Dimitropoulou
Eleni es arquitecta sénior de creación de prototipos en AWS. Trabaja con clientes, creando prototipos de soluciones, mientras los ayuda a diseñar y crear aplicaciones seguras y escalables en la nube.
Iaroslav Ustinov
Iaroslav es arquitecto de soluciones senior en AWS centrado en la región de Europa central y oriental. Su pasión son las tecnologías sin servidor y le gusta compartirlas con empresas de diferentes tamaños para ayudarlas a acelerar su transformación digital y su ritmo de innovación.