Resumo Técnico: RAG4Tickets – Resolução de Tickets Impulsionada por IA via Geração Aumentada por Recuperação

1. Declaração do Problema

As equipes modernas de desenvolvimento de software enfrentam atrasos significativos na resolução de problemas recorrentes devido ao conhecimento fragmentado espalhado por tickets do JIRA, discussões de desenvolvedores e pull requests (PRs) do GitHub. À medida que os projetos escalam, o crescimento exponencial de tickets e mudanças de código leva à sobrecarga de informações. Os desenvolvedores frequentemente lutam para localizar resoluções passadas para problemas semanticamente semelhantes, mas linguisticamente distintos (ex: correspondendo "UI crash" com "application freeze"). Abordagens tradicionais de aprendizado de máquina supervisionado para classificação de bugs costem falhar em capturar a variabilidade semântica inerente aos relatórios de bugs do mundo real, levando a ineficiências no triagem e resolução.

2. Metodologia

O artigo propõe o RAG4Tickets, um framework de Geração Aumentada por Recuperação (RAG) projetado para unificar artefatos de software heterogêneos em um pipeline de resolução consciente do contexto. O sistema opera através de quatro camadas principais:

• Ingestão de Dados e Pré-processamento: O sistema ingere dados estruturados do JIRA (títulos, descrições, status, comentários) e do GitHub (PRs, mensagens de commit, diffs, comentários de revisão). O pré-processamento envolve a normalização de texto, remoção de boilerplate e o uso de parsers de Árvore de Sintaxe Abstrata (AST) para resumir diffs de código ao nível de função para reduzir o ruído.
• Camada de Embedding: Artefatos heterogêneos são convertidos em representações vetoriais densas. O framework utiliza Sentence-Transformers (especificamente all-MiniLM-L6-v2 e multi-qa-MPNet-base-dot-v1) para dados textuais (tickets, comentários). Para dados específicos de código (diffs de PR), ele emprega uma estratégia híbrida incorporando CodeBERT e GraphCodeBERT para capturar dependências estruturais e semântica de programação. Os embeddings são particionados por tipo de artefato para permitir buscas direcionadas.
• Camada de Recuperação: Todos os embeddings são indexados usando FAISS (Facebook AI Similarity Search) para realizar busca de Vizinho Mais Próximo Aproximado (ANN). O sistema avalia diferentes estruturas de índice (Flat, IVF, HNSW) e seleciona o HNSW por seu equilíbrio ideal entre velocidade e recall em conjuntos de dados de escala empresarial (milhões de vetores). Ao receber um novo ticket, o sistema o codifica e recupera os top-$k$ tickets, comentários e PRs historicamente similares.
• Camada de Geração: A evidência recuperada é sintetizada em um prompt estruturado para um Modelo de Linguagem de Grande Escala (LLM). O LLM gera sugestões de resolução fundamentadas, incluindo planos passo a passo, hiperlinks para PRs/commits relevantes e pontuações de confiança. Esta camada é projetada para minimizar alucinações, sendo estritamente baseada nas evidências recuperadas.

Integração de Implantação: O framework é modular, permitindo a integração via plugins do JIRA (para comentários de triagem automatizados), GitHub Actions (para exibição de problemas vinculados a PRs) e pipelines de CI/CD (para triagem automática de falhas de teste recorrentes).

3. Principais Contribuições

O artigo descreve cinco contribuições primárias:

1. Arquitetura Unificada: Um pipeline que ingere e vincula dados do JIRA e do GitHub, estabelecendo conexões explícitas entre tickets e mudanças de código.
2. Estratégia de Embedding Especializada: Uma abordagem adaptada para artefatos heterogêneos, combinando embeddings semânticos de texto com embeddings conscientes de código (CodeBERT) para capturar tanto a linguagem natural quanto as similaridades estruturais de código.
3. Pipeline de Decisão Guiado por Evidências: Um fluxo de trabalho RAG onde a evidência histórica recuperada guia diretamente as sugestões de resolução geradas pelo LLM, garantindo a rastreabilidade.
4. Avaliação Abrangente: Uma avaliação utilizando tanto métricas de Recuperação de Informação (IR) (Recall@k, Mean Reciprocal Rank) quanto medidas de produtividade do desenvolvedor (tempo para resolução, taxas de aceitação).
5. Estudo de Caso Prático: Um cenário de implantação real envolvendo uma migração de microserviço para React 19, demonstrando a capacidade do sistema de lidar com problemas recorrentes relacionados a métodos de ciclo de vida depreciados e gerenciamento de estado.

4. Resultados Experimentais

O sistema foi avaliado em um conjunto de dados compreendendo aproximadamente 15.000 tickets do JIRA e 6.500 PRs do GitHub de um projeto de migração de larga escala para React 19.

• Desempenho de Recuperação: Usando o índice HNSW, o sistema alcançou um Recall@5 de 82% e um Recall@10 de 91%, com um Mean Reciprocal Rank (MRR) de 0.78. Isso indica que resoluções históricas relevantes são tipicamente encontradas dentro dos cinco primeiros resultados.
• Qualidade de Geração: Em um conjunto de teste de 500 problemas não vistos, as soluções geradas alcançaram um score BLEU de 0.47 e ROUGE-L de 0.62. Crucialmente, o score de consistência factual foi de 84%, demonstrando que o LLM aderiu amplamente à evidência recuperada, minimizando assim as alucinações.
• Impacto no Negócio: Em uma implantação em três equipes ágeis, o sistema gerou as seguintes melhorias:
  • Tempo de Resolução: Reduzido de uma média de 18,5 horas para 10,2 horas (uma melhoria de 45%).
  • Taxa de Aceitação: Desenvolvedores adotaram ou editaram levemente as resoluções sugeridas pela IA 68% das vezes.
  • Produtividade: Desenvolvedores relataram um aumento de produtividade autoatribuído de 32%, atribuído à redução do tempo gasto em triagens repetitivas e buscas manuais.

5. Significância e Limitações

O artigo postula que o RAG4Tickets demonstra como fluxos de trabalho de DevOps aumentados por IA podem mitigar a sobrecarga cognitiva e melhorar a reutilização do conhecimento organizacional. Ao preencher a lacuna entre dados históricos não estruturados e a resolução automatizada, o framework oferece um caminho escalável para ambientes de engenharia conscientes do contexto.

No entanto, os autores mantêm uma postura modesta em relação às limitações atuais:

• Risco de Alucinação: Embora a fundamentação factual seja alta (84%), ocorrem alucinações ocasionais quando o LLM extrapola além da evidência recuperada.
• Viés de Dados e Drift: O sistema corre o risco de propagar padrões subótimos de dados legados e pode sofrer de drift semântico conforme os frameworks evoluem (ex: React 18 para 19).
• Custos Operacionais: A indexação de grandes repositórios e a inferência frequente de LLM introduzem overhead de computação e latência.

O artigo conclui que, embora o sistema mostre forte potencial para automatizar a manutenção de software, o sucesso a longo prazo depende da mitigação dos riscos de alucinação através da verificação de recuperação, garantia de adaptabilidade do modelo a tecnologias em evolução e manutenção da transparência para construir a confiança dos desenvolvedores. O trabalho futuro proposto inclui camadas de verificação de recuperação, aprendizado por reforço com feedback humano (RLHF) e arquiteturas de recuperação híbridas combinando busca densa e esparsa.