Genie - el copilot de guardia con IA generativa de Uber

• Mantener una operación de guardia sólida en un entorno tecnológico que cambia rápidamente es clave para garantizar el funcionamiento fluido de los servicios
• Los equipos de ingeniería de plataforma tienen dificultades para gestionar de forma eficiente los turnos de guardia, la respuesta a incidentes, la comunicación en momentos críticos y el sólido soporte al cliente en canales de Slack®
• Se describe Genie, un copilot de guardia que usa IA generativa para optimizar la comunicación con los ingenieros de guardia y responder preguntas

Una mirada más de cerca: el problema y la motivación

• En Uber, varios equipos como Michelangelo tienen canales de soporte en Slack donde los usuarios internos pueden pedir ayuda
• En estos canales se plantean en promedio 45,000 preguntas al mes
• El alto volumen de preguntas y los largos tiempos de espera para responder reducen la productividad de los usuarios y de los ingenieros de guardia

Un proceso engorroso

• Normalmente, cuando un usuario hace una pregunta en un canal de Slack, tiene que esperar la respuesta de un ingeniero de guardia
• El ingeniero de guardia responde la pregunta inicial del usuario o solicita más detalles
• El usuario puede hacer preguntas de seguimiento, pedir más claridad o aportar información adicional
• Entonces vuelve a producirse una situación en la que hay que esperar otra respuesta del ingeniero de guardia
• Después de varios intercambios de ida y vuelta, la pregunta del usuario se resuelve

Dificultad para encontrar información

• Muchas preguntas podrían responderse consultando documentación existente, pero la información está dispersa entre la wiki interna de Uber llamada Engwiki, el Stack Overflow interno y otros lugares, por lo que resulta difícil encontrar una respuesta específica
• Como resultado, los usuarios suelen repetir las mismas preguntas una y otra vez, lo que genera una alta demanda de soporte de guardia en cientos de canales de Slack

Retos de arquitectura

• Para construir el copilot de guardia, se eligió entre afinar un modelo LLM o aprovechar Retrieval-Augmented Generation (RAG)
• El fine-tuning requiere datos curados que incluyan ejemplos diversos y de alta calidad con los que el LLM pueda aprender
• También requiere recursos de cómputo para mantener el modelo actualizado con ejemplos nuevos
• En cambio, RAG no necesita una gran variedad de ejemplos desde el principio
• Como esto acortaba el tiempo de salida al mercado del copilot, se eligió este enfoque

Construir el copilot de guardia implicó varios retos, como resolver el problema de las alucinaciones, proteger las fuentes de datos y mejorar la experiencia de usuario. A continuación se resume cómo se abordó cada uno de ellos.

Para las alucinaciones, se puso el foco en lo siguiente:

• Exactitud de las respuestas: recuperar conocimiento relevante para las preguntas y evitar que el motor LLM genere información incorrecta o engañosa
• Mecanismos de verificación: implementar formas de validar las respuestas del copilot contra fuentes autorizadas para reducir la posibilidad de alucinaciones
• Aprendizaje continuo: asegurar que el copilot tenga acceso a los datos más recientes para mejorar la precisión

Para la seguridad de los datos, se seleccionaron cuidadosamente las fuentes a recopilar, ya que existen muchas fuentes de datos que no pueden exponerse en canales de Slack

Para mejorar la experiencia de usuario, se diseñó lo siguiente:

• Interfaz intuitiva: una interfaz fácil de usar para que los usuarios interactúen con el copilot de forma eficiente
• Bucle de retroalimentación: un sistema para que los usuarios den feedback sobre las respuestas y así mejorar continuamente el rendimiento del copilot

Estos retos se resolvieron al desarrollar un copilot de guardia confiable, fácil de usar y seguro

Análisis profundo de la estructura

• Veamos la arquitectura del copilot de guardia Genie
• En resumen, se hace scraping de fuentes de datos internas como la wiki interna de Uber, el Stack Overflow interno y documentos de requisitos de ingeniería, y se crean vectores a partir de esas fuentes con el modelo de embeddings de OpenAI
• Estos embeddings se almacenan en una base de datos vectorial
• Luego, cuando un usuario publica una pregunta en un canal de Slack, esa pregunta se convierte en embedding
• El servicio recupera de la base de datos vectorial los embeddings relevantes relacionados con la pregunta
• Los resultados indexados por embeddings se usan como prompt para el LLM con el fin de obtener una respuesta

La etapa de push de artefactos para preparación de datos, embeddings y serving puede generalizarse como una aplicación RAG que usa Apache Spark™. Estos pasos generales forman la base de las aplicaciones RAG

ETL

Preparación de datos

• La app de Spark obtiene contenido de cada fuente de datos usando Engwiki de Uber o la API de Uber Stack Overflow
• En esta etapa de preparación de datos se genera un dataframe de Spark
• El esquema tiene en una columna el enlace de Engwiki y en otra el contenido de Engwiki, ambos en formato string

Generación de embeddings

• Una vez hecho el scraping de los datos, se generan embeddings usando el modelo de embeddings de OpenAI y se envían a Terrablob, el almacenamiento de blobs de Uber
• Solo se puede acceder a los embeddings generados a través del canal de Slack específico asociado con el espacio de Engwiki
• El formato de salida es un dataframe con un esquema que mapea el contenido de cada chunk a su vector correspondiente
• El contenido de la wiki interna de Uber se divide en chunks con langchain y los embeddings se generan en OpenAI mediante un UDF de PySpark

Pusher

• Se muestra cómo enviar vectores a Terrablob
• Se muestra la forma en que se envían los vectores
• Se activa un trabajo de bootstrap para recopilar datos de las fuentes hacia Sia
• Sia es la solución interna de base de datos vectorial de Uber
• Luego se activan dos trabajos de Spark para construir y fusionar índices, y recopilar datos en Terrablob
• Todas las hojas sincronizan y descargan el índice base y los snapshots almacenados en Terrablob
• Durante la búsqueda, la consulta se envía directamente a cada hoja

Servicio de conocimiento

• Genie tiene un servicio backend llamado Knowledge Service
• Convierte primero las consultas entrantes en embeddings y luego recupera los chunks más relevantes desde la base de datos vectorial para responder las solicitudes de todas las consultas entrantes

Seguimiento de costos

• Para el seguimiento de costos, cuando el cliente de Slack u otra plataforma llama a Knowledge Service, se le pasa un UUID a Knowledge Service
• Luego, Knowledge Service pasa ese UUID a Michelangelo Gateway mediante un context header
• Como Michelangelo Gateway es un servicio passthrough hacia el LLM, puede agregar ese UUID al audit log que se usa para rastrear costos

Evaluación del rendimiento de Genie

Cómo se mide

• Los usuarios pueden dar feedback inmediato en Slack haciendo clic en los botones correspondientes en las respuestas de Genie

• Se ofrece a los usuarios la opción de elegir entre lo siguiente:

  • Resuelto: la respuesta resolvió completamente el problema
  • Útil: la respuesta fue parcialmente útil, pero el usuario necesita más ayuda
  • No útil: la respuesta fue incorrecta o no relevante
  • No relevante: el usuario necesita soporte de guardia y Genie no puede ayudar (por ejemplo, en casos como code review)

• Cuando un usuario deja feedback, un plugin de Slack lo recoge y transmite el feedback y los metadatos relacionados a una tabla de Hive usando un topic específico de Kafka

• Después, estas métricas se visualizan en un dashboard

Evaluación del rendimiento

• Se ofrece a los usuarios de Genie la opción de ejecutar evaluaciones personalizadas
• Los usuarios pueden evaluar alucinaciones, relevancia de las respuestas u otras métricas que consideren importantes para su caso de uso
• Esta evaluación puede usarse para ajustar mejor todos los componentes relevantes de RAG, como recuperación y generación

El proceso de evaluación es un pipeline ETL independiente que usa componentes de Michelangelo ya construidos. El contexto y las respuestas de Genie se recuperan desde Hive y se unen con otros datos relacionados, como metadatos de Slack y feedback de usuarios. Luego se procesan y se envían a Evaluator. Evaluator toma un prompt especificado y ejecuta el LLM como Judge. Las métricas especificadas se extraen y se incluyen en el reporte de evaluación, al cual los usuarios pueden acceder desde la UI

Evaluación de documentos

• La recuperación precisa de información depende de la claridad y exactitud de los documentos fuente
• Si la calidad de la documentación en sí es baja, no hay forma de lograr un buen rendimiento sin importar qué tan bien funcione el LLM
• Por lo tanto, la capacidad de evaluar documentos y hacer sugerencias accionables para mejorar su calidad es esencial para un sistema RAG eficiente y efectivo

Se muestra el flujo de trabajo de la app de evaluación de documentos. Después del scraping, los documentos de la base de conocimiento se convierten en un dataframe de Spark. Cada fila del dataframe representa un documento de la base de conocimiento. Luego se llama al LLM como Judge para procesar la evaluación. Aquí se alimenta al LLM con prompts de evaluación personalizados. El LLM devuelve una puntuación de evaluación junto con una explicación de la puntuación y sugerencias accionables para mejorar la calidad de cada documento. Todas estas métricas se publican en un reporte de evaluación al que los usuarios pueden acceder desde la UI de Michelangelo

Soluciones a los retos

• Para reducir las alucinaciones, se cambió la forma en que se envían al LLM los prompts obtenidos desde la base de datos vectorial
  • Para todos los resultados obtenidos desde la base de datos vectorial, se agregó explícitamente la URL de la fuente junto con un contexto parcial
  • Se pidió al LLM que respondiera solo con base en los distintos subcontextos proporcionados y que devolviera las URL fuente para citar la respuesta
  • Se intentó proporcionar URL fuente para todas las respuestas
• Para evitar filtrar a Slack fuentes de datos al generar embeddings con OpenAI o al permitir que personas sin acceso a fuentes críticas las vieran, se curaron previamente fuentes de datos disponibles de manera amplia para la mayoría de los ingenieros de Uber y solo se permitió usar esas fuentes para generar embeddings
• Para maximizar el potencial de Genie al responder preguntas, se desarrolló un nuevo modo de interacción
  • En este modo, los usuarios pueden hacer preguntas de seguimiento con mayor comodidad y se les incentiva a leer con más atención las respuestas de Genie
  • Si Genie no puede responder la pregunta, el usuario puede escalar fácilmente el problema al soporte de guardia

En el nuevo modo de interacción, cuando un usuario hace una pregunta, Genie responde junto con botones de acción para los siguientes pasos. Con estos botones, los usuarios pueden hacer fácilmente preguntas de seguimiento, marcar la pregunta como resuelta o contactar soporte humano

Resultados

• Desde su lanzamiento en septiembre de 2023, Genie ha ampliado su presencia a 154 canales de Slack y ha respondido más de 70 mil preguntas
• Genie presume una tasa de utilidad de 48.9%, lo que muestra que su efectividad está aumentando
• Se estima que ha ahorrado 13,000 horas de ingeniería desde su lanzamiento hasta la fecha

Futuro

• Genie es un bot de Slack de última generación diseñado para simplificar la gestión de guardias, optimizar la respuesta a incidentes y mejorar la colaboración entre equipos
• Desarrollado con foco en la simplicidad y la efectividad, Genie funciona como un asistente integral y ayuda a los equipos de ingeniería a manejar sin fricción sus responsabilidades de guardia
• Este copilot asistente de guardia puede transformar por completo la experiencia de cómo los usuarios y los ingenieros de guardia interactúan y participan dentro de los canales de Slack de cada plataforma
• Además, puede transformar la experiencia dentro de cada producto, como Michelangelo o el IDE, permitiendo que los usuarios encuentren ayuda específica del producto en su canal de Slack o dentro del propio producto sin esperar al soporte de guardia

Conclusión

• Genie, el copilot asistente de guardia, transforma la manera en que los equipos de ingeniería gestionan el trabajo de guardia
• Al promover la resolución automática y ofrecer análisis valiosos, Genie ayuda a los equipos a manejar sus responsabilidades de guardia de forma eficiente y efectiva

Opinión de GN⁺

• Genie es un innovador copilot de guardia que responde preguntas de usuarios en los numerosos canales de Slack de Uber, ahorrando tiempo a los ingenieros y mejorando la experiencia de usuario
• El éxito de Genie muestra una poderosa combinación entre tecnología de aprendizaje automático y experiencia humana. Aprovecha grandes volúmenes de datos y LLM para ofrecer respuestas precisas y útiles a las preguntas
• Sin embargo, Genie todavía tiene limitaciones y margen de mejora. No ha resuelto por completo el problema de las alucinaciones y a veces puede ofrecer información inexacta o engañosa. El sistema debe mejorarse mediante monitoreo continuo y feedback de los usuarios
• Otro punto a considerar es la seguridad de los datos y la privacidad. Los datos que procesa Genie pueden ser sensibles y confidenciales, por lo que el manejo seguro y el control de acceso son esenciales
• En el futuro, Genie puede evolucionar para mejorar la calidad de sus respuestas, integrar más fuentes de datos y reforzar la seguridad. También sería posible extender copilots similares a otras áreas del negocio
• Desde soporte automatizado al cliente y apoyo de ventas hasta incluso asistencia para programar, los asistentes impulsados por IA pueden aplicarse a diversas tareas. Estas herramientas pueden aumentar la productividad de los empleados y mejorar la experiencia de usuario
• En general, Genie es un caso interesante de cómo la IA y la experiencia humana pueden llevar a mejores formas de trabajo y mejor servicio al cliente. Se espera que estas tecnologías sigan evolucionando y tengan un impacto importante en cómo trabajamos e interactuamos