Genie - o copilot de plantão com IA generativa da Uber

• Em um ambiente tecnológico que muda rapidamente, manter uma operação de plantão robusta é crucial para garantir o funcionamento contínuo dos serviços
• As equipes de engenharia de plataforma enfrentam dificuldades para gerenciar com eficiência escalas de plantão, resposta a incidentes, comunicação em momentos críticos e um suporte forte ao cliente em canais do Slack®
• O texto descreve o Genie, um copilot de plantão que usa IA generativa para otimizar a comunicação com engenheiros de plantão e responder perguntas

Analisando mais de perto: o problema e a motivação

• Na Uber, várias equipes, como a equipe Michelangelo, têm canais de suporte no Slack onde usuários internos podem pedir ajuda
• Nesses canais, são feitas em média 45.000 perguntas por mês
• O grande volume de perguntas e o longo tempo de espera por respostas reduzem a produtividade dos usuários e dos engenheiros de plantão

Processo trabalhoso

• Em geral, quando um usuário faz uma pergunta em um canal do Slack, precisa esperar a resposta do engenheiro de plantão
• O engenheiro de plantão responde à pergunta inicial do usuário ou pede mais detalhes
• O usuário pode fazer perguntas de acompanhamento, pedir mais esclarecimentos ou fornecer informações adicionais
• Isso cria uma situação em que é preciso esperar novamente pela resposta do engenheiro de plantão
• Depois de várias idas e vindas na comunicação, a pergunta do usuário é resolvida

Dificuldade para encontrar informações

• Muitas perguntas podem ser respondidas consultando documentação existente, mas como as informações estão espalhadas pela wiki interna da Uber chamada Engwiki, pelo Stack Overflow interno e por outros lugares, é difícil encontrar uma resposta específica
• Como resultado, os usuários frequentemente repetem as mesmas perguntas, o que gera alta demanda por suporte de plantão em centenas de canais do Slack

Desafios de arquitetura

• Para construir o copilot de plantão, foi preciso escolher entre fazer fine-tuning do modelo LLM ou usar Retrieval-Augmented Generation (RAG)
• O fine-tuning exige dados curados com exemplos variados e de alta qualidade para que o LLM possa aprender
• Também exige recursos computacionais para manter o modelo atualizado com novos exemplos
• Já o RAG não exige uma grande variedade de exemplos desde o início
• Como isso reduziu o tempo de lançamento do copilot, essa foi a abordagem escolhida

Houve vários desafios para construir o copilot de plantão, incluindo resolver o problema de alucinações, proteger fontes de dados e melhorar a experiência do usuário. A seguir, uma visão geral de como cada desafio foi tratado.

Em relação às alucinações, o foco foi nos seguintes pontos:

• Precisão das respostas: recuperar conhecimento relevante para a pergunta para evitar que o mecanismo de LLM gere informações incorretas ou enganosas
• Mecanismos de validação: implementar formas de validar as respostas do copilot com base em fontes autorizadas para reduzir a possibilidade de alucinação
• Aprendizado contínuo: garantir que o copilot tenha acesso aos dados mais atuais para aumentar a precisão

Para segurança de dados, como havia muitas fontes que não podiam ser expostas em canais do Slack, as fontes coletadas foram escolhidas com cuidado

Para melhorar a experiência do usuário, o sistema foi projetado com:

• Interface intuitiva: uma interface fácil de usar para que os usuários possam interagir com o copilot de forma eficiente
• Loop de feedback: um sistema para que os usuários forneçam feedback sobre as respostas, permitindo melhorar continuamente o desempenho do copilot

Esses desafios foram enfrentados ao desenvolver um copilot de plantão confiável, amigável ao usuário e seguro

Análise aprofundada da estrutura

• Vamos examinar a arquitetura do copilot de plantão Genie
• Em resumo, fontes internas de dados, como a wiki interna da Uber, o Stack Overflow interno e documentos de requisitos de engenharia, são raspadas, e vetores são criados a partir dessas fontes usando o modelo de embeddings da OpenAI
• Esses embeddings são armazenados em um banco de dados vetorial
• Depois, quando um usuário publica uma pergunta em um canal do Slack, a pergunta é convertida em embedding
• O serviço busca no banco de dados vetorial os embeddings relevantes para a pergunta
• Os resultados indexados pelos embeddings são usados como prompt para o LLM gerar a resposta

A etapa de envio de artefatos para preparação de dados, embeddings e serving pode ser generalizada como uma aplicação RAG que usa Apache Spark™. Essas etapas comuns formam a base de aplicações RAG

ETL

Preparação de dados

• O app Spark busca conteúdo de cada fonte de dados usando a Engwiki da Uber ou a API do Uber Stack Overflow
• Nessa etapa de preparação dos dados, é gerado um dataframe do Spark
• O esquema tem, em uma coluna, o link da Engwiki e, em outra, o conteúdo da Engwiki, ambos em formato string

Geração de embeddings

• Depois que os dados são raspados, os embeddings são gerados com o modelo de embeddings da OpenAI e enviados para o Terrablob, o armazenamento de blobs da Uber
• Os embeddings gerados só podem ser acessados por canais específicos do Slack relacionados ao espaço da Engwiki
• O formato de saída é um dataframe com um esquema que mapeia o conteúdo de cada chunk ao vetor correspondente daquele chunk
• O conteúdo da wiki interna da Uber é dividido em chunks com langchain, e os embeddings são gerados pela OpenAI via UDF do PySpark

Pusher

• É mostrado como os vetores são enviados para o Terrablob
• Também é mostrado o modo como os vetores são enviados
• Um job de bootstrap é acionado para coletar dados da fonte para o Sia
• O Sia é a solução interna de banco de dados vetorial da Uber
• Em seguida, dois jobs Spark são acionados para construir e mesclar índices e coletar os dados para o Terrablob
• Todos os nós folha sincronizam e baixam o índice base e os snapshots armazenados no Terrablob
• Durante a busca, a consulta é enviada diretamente para cada nó folha

Knowledge Service

• O Genie tem um serviço de backend chamado Knowledge Service
• Ele primeiro converte consultas recebidas em embeddings e depois busca os chunks mais relevantes no banco de dados vetorial para responder às requisições de todas as consultas recebidas

Rastreamento de custos

• Para rastrear custos, quando o cliente do Slack ou outra plataforma chama o Knowledge Service, um UUID é repassado para o Knowledge Service
• Em seguida, o Knowledge Service passa esse UUID para o Michelangelo Gateway por meio de um cabeçalho de contexto
• Como o Michelangelo Gateway é um serviço pass-through para o LLM, ele pode adicionar esse UUID ao log de auditoria usado para rastrear custos

Avaliação de desempenho do Genie

Como medir

• Os usuários podem fornecer feedback imediato no Slack clicando nos botões apropriados na resposta do Genie

• São oferecidas as seguintes opções ao usuário:

  • Resolvido: a resposta resolveu completamente o problema
  • Ajudou: a resposta ajudou parcialmente, mas o usuário ainda precisa de mais ajuda
  • Não ajudou: a resposta estava errada ou não era relevante
  • Não relevante: o usuário precisa de suporte de plantão e o Genie não pode ajudar com isso, como em casos de code review

• Quando o usuário deixa feedback, o plugin do Slack o captura e faz streaming do feedback e dos metadados relacionados para uma tabela Hive usando um tópico específico do Kafka

• Mais tarde, essas métricas são visualizadas em um dashboard

Avaliação de desempenho

• Os usuários do Genie têm a opção de executar avaliações personalizadas
• Eles podem avaliar alucinações, relevância das respostas ou qualquer outra métrica que considerem importante para seu caso de uso
• Essa avaliação pode ser usada para ajustar melhor todos os componentes relevantes do RAG, como recuperação e geração

O processo de avaliação é um pipeline ETL separado que usa componentes já construídos do Michelangelo. O contexto e as respostas do Genie são recuperados do Hive e unidos a outros dados relevantes, como metadados do Slack e feedback dos usuários. Depois disso, tudo é processado e enviado ao Evaluator. O Evaluator recebe o prompt especificado e executa o LLM como Judge. As métricas definidas são extraídas e incluídas em um relatório de avaliação, que os usuários podem acessar pela UI

Avaliação de documentos

• A recuperação precisa de informações depende da clareza e da precisão dos documentos de origem
• Se a qualidade da documentação em si for baixa, não há como obter bom desempenho, por melhor que o LLM seja
• Por isso, a capacidade de avaliar documentos e fazer sugestões práticas para melhorar sua qualidade é essencial para um sistema RAG eficiente e eficaz

É mostrado o fluxo de trabalho do app de avaliação de documentos. Depois que os dados são raspados, os documentos da base de conhecimento são convertidos em um dataframe do Spark. Cada linha do dataframe representa um documento da base de conhecimento. Em seguida, o LLM é chamado como Judge para processar a avaliação. Aqui, um prompt de avaliação personalizado é usado para alimentar o LLM. O LLM retorna a pontuação da avaliação, uma explicação dessa pontuação e sugestões práticas para melhorar a qualidade de cada documento. Todas essas métricas são publicadas em um relatório de avaliação acessível aos usuários na UI do Michelangelo

Soluções para os desafios

• Para reduzir alucinações, foi alterada a forma como os prompts obtidos do banco de dados vetorial são enviados ao LLM
  • Para todos os resultados obtidos no banco de dados vetorial, a URL da fonte correspondente foi adicionada explicitamente junto com um contexto parcial
  • Foi solicitado ao LLM que respondesse apenas com base nos vários subcontextos fornecidos e retornasse as URLs das fontes citadas na resposta
  • Buscou-se fornecer URLs de origem para todas as respostas
• Para evitar vazar para o Slack fontes de dados a pessoas que não podem acessar fontes sensíveis ou gerar embeddings com a OpenAI, foram previamente curadas fontes de dados amplamente acessíveis à maioria dos engenheiros da Uber, permitindo usar apenas essas fontes para gerar embeddings
• Para maximizar o potencial do Genie de responder perguntas, foi desenvolvido um novo modo de interação
  • Nesse modo, os usuários podem fazer perguntas de acompanhamento com mais conveniência e são incentivados a ler a resposta do Genie com mais atenção
  • Se o Genie não conseguir responder à pergunta, o usuário pode escalar facilmente o problema para o suporte de plantão

Nesse novo modo de interação, quando o usuário faz uma pergunta, o Genie responde junto com botões de próximas ações. Com esses botões, o usuário pode fazer perguntas de acompanhamento facilmente, marcar a questão como resolvida ou pedir ajuda humana

Resultados

• Desde seu lançamento, em setembro de 2023, o Genie expandiu sua presença para 154 canais do Slack e respondeu a mais de 70 mil perguntas
• O Genie apresenta uma taxa de utilidade de 48,9%, mostrando que sua eficácia está aumentando
• Estima-se que, desde o lançamento até agora, ele tenha economizado 13.000 horas de trabalho de engenharia

Futuro

• O Genie é um bot de Slack de ponta projetado para simplificar o gerenciamento de plantão, otimizar a resposta a incidentes e melhorar a colaboração entre equipes
• Desenvolvido com foco em simplicidade e eficácia, o Genie atua como um assistente abrangente, ajudando equipes de engenharia a lidar com responsabilidades de plantão sem atritos
• Esse copilot assistente de plantão pode transformar toda a experiência de como usuários e engenheiros de plantão interagem e se envolvem nos canais do Slack de cada plataforma
• Ele também pode transformar a experiência dentro de cada produto, como Michelangelo ou IDEs, para que usuários encontrem ajuda específica do produto dentro do canal do Slack correspondente ou dentro do próprio produto, sem precisar esperar pelo suporte de plantão

Conclusão

• O copilot assistente de plantão Genie revoluciona a forma como equipes de engenharia gerenciam o trabalho de plantão
• Ao promover resolução automatizada e fornecer análises valiosas, o Genie ajuda as equipes a lidar com responsabilidades de plantão de forma eficiente e eficaz

Opinião do GN⁺

• O Genie é um copilot de plantão inovador que responde às perguntas dos usuários em inúmeros canais do Slack da Uber, economizando tempo dos engenheiros e melhorando a experiência do usuário
• O sucesso do Genie mostra a poderosa combinação entre tecnologia de machine learning e conhecimento humano. Ele usa grandes volumes de dados e LLMs para fornecer respostas precisas e úteis às perguntas
• No entanto, o Genie ainda tem limitações e espaço para melhorias. Ele não resolveu completamente o problema das alucinações e, às vezes, pode fornecer informações imprecisas ou enganosas. O sistema precisa ser aprimorado com monitoramento contínuo e feedback dos usuários
• Outro ponto a considerar é a segurança dos dados e a privacidade. Os dados processados pelo Genie podem ser sensíveis e confidenciais, por isso o tratamento seguro e o controle de acesso são essenciais
• No futuro, o Genie pode evoluir para melhorar a qualidade das respostas, integrar mais fontes de dados e reforçar a segurança. Também é possível expandir copilots semelhantes ao Genie para outras áreas de negócio
• De suporte automatizado ao cliente a apoio em vendas e até assistência de programação, assistentes baseados em IA podem ser aplicados a diversas tarefas. Essas ferramentas podem aumentar a produtividade dos funcionários e melhorar a experiência do usuário
• No geral, o Genie é um caso interessante de como IA e conhecimento humano podem levar a formas melhores de trabalhar e de atender clientes. Essas tecnologias continuarão evoluindo e devem ter um impacto significativo em como trabalhamos e interagimos