De conversas no Slack a conhecimento estruturado: implementação de RAG na Snyk

A missão da Snyk é ajudar as organizações a desenvolver com agilidade e manter a segurança. Internamente, isso significa garantir que nossas equipes possam acessar rapidamente o rico conhecimento institucional gerado todos os dias. Uma das principais fontes? O Slack.

O Slack é nosso ponto central para atualizações, discussões técnicas e valiosas perguntas e respostas. No entanto, como sabem os usuários frequentes, a natureza conversacional da plataforma faz com que informações importantes sejam rapidamente soterradas por threads, canais e inúmeras mensagens.

É aí que entra a geração aumentada por recuperação (RAG). A RAG aprimora os grandes modelos de linguagem (LLMs) ao dar acesso a informações específicas e atuais que não faziam parte dos dados de treinamento originais. Nosso objetivo: aproveitar a riqueza de insights do Slack para criar uma ferramenta interna de perguntas e respostas mais inteligente.

Entendendo o desafio dos dados

A jornada começou não com algoritmos complexos, mas com uma análise aprofundada dos dados desorganizados do mundo real no Slack. As mensagens não são organizadas de forma clara: incluem conversas informais, emojis e identificadores enigmáticos, como <@U123ABC> para usuários e <#C456DEF> para canais. Ao longo de todo o processo, um princípio fundamental permaneceu claro: "Se você colocar lixo em um modelo, vai obter lixo como resultado." Antes de desenvolver nossa solução, identificamos vários desafios importantes:

• Encontrar informações valiosas: Identificar dados relevantes em meio ao ruído das conversas exigiu uma curadoria cuidadosa.

• Estratégia de divisão em blocos: Definir como segmentar os dados foi um desafio. As threads variavam bastante. Alguns canais tinham atividade intensa, enquanto outros eram esporádicos. Abordagens convencionais, como dividir por dia ou por janelas móveis, eram problemáticas por não oferecerem consistência nem foco.

• Decodificar IDs do Slack: Precisávamos converter os IDs de usuários e canais em nomes compreensíveis para garantir a legibilidade.

• Conversão para Markdown: A princípio, parecia simples converter as threads para Markdown. Porém, o Markdown bruto ficava cheio de emojis, reações e respostas aninhadas, o que poderia confundir o LLM.

O momento “Eureka!”: perguntas e respostas como estrutura central

A grande descoberta veio quando recuamos e voltamos a nos concentrar no motivo essencial da existência do sistema RAG: responder às perguntas dos funcionários. Em vez de forçar os dados a se encaixarem em blocos predefinidos, passamos a estruturar as informações em torno de interações claras de perguntas e respostas. Cada thread do Slack em que alguém fazia uma pergunta e recebia uma resposta se tornou um único bloco de documento estruturado.

Essa mudança intuitiva simplificou nosso processo:

• Identificação de perguntas: Priorizamos canais do Slack criados especificamente para perguntas, como #ask-product.

• LLM para sumarização: Usando a Gemini API do Google, processamos threads do Slack com instruções como: “Extraia uma pergunta clara e uma resposta completa”. Assim, geramos dados estruturados de alta qualidade, prontos para o sistema RAG.

• Estratégia de recuperação: Criamos embeddings apenas para as perguntas extraídas, permitindo uma recuperação eficiente por meio da comparação entre a consulta do usuário e a pergunta armazenada. É importante destacar que o LLM recebia a resposta (armazenada como metadado) da pergunta armazenada mais semelhante, e não a própria pergunta. Isso garantiu que o modelo recebesse o contexto mais relevante.

• Abordagem alternativa: Nem todas as threads valiosas eram simples perguntas e respostas. Nesses casos, formatamos as threads como resumos limpos em Markdown para preservar o contexto mais amplo.

• Atualizações contínuas: O sistema gera novos resumos automaticamente sempre que mensagens são adicionadas, mantendo nossa base de conhecimento atualizada.

Implementação da solução

Com um foco mais definido nas estruturas de perguntas e respostas, nosso fluxo de trabalho técnico ficou claro e eficiente:

• Slack SDK: busque mensagens diretamente no Slack.

• Gemini API: Transforma threads em perguntas e respostas estruturadas ou em resumos em Markdown.

• Snowflake Cortex Search Service: Armazena os resultados estruturados e cria embeddings a partir das perguntas.

• Aplicação RAG: Os funcionários enviam consultas, que são convertidas em embeddings e comparadas semanticamente às perguntas armazenadas. As respostas relevantes são recuperadas dos metadados para fornecer respostas precisas e contextualizadas.

Ver descrição da imagem

Além das APIs: aprendizados reais de engenharia

Nossa solução final não dependeu de algoritmos revolucionários, mas de uma compreensão profunda dos dados, da resolução criativa de problemas e do aprimoramento iterativo da nossa abordagem. A verdadeira conquista de engenharia não foi apenas integrar APIs ou implementar embeddings, mas estruturar os dados com precisão para resolver nosso desafio central.

Nossa estratégia centrada em perguntas e respostas se alinha de forma natural à mecânica da RAG, transformando o caos conversacional do Slack em conhecimento claro e acessível. Isso demonstra como soluções inovadoras de IA muitas vezes surgem de insights centrados nas pessoas, e não apenas de feitos tecnológicos complexos.