Des fils Slack aux connaissances structurées : déployer le RAG chez Snyk

Chez Snyk, notre mission est d’aider les organisations à développer rapidement et en toute sécurité. En interne, cela signifie veiller à ce que nos équipes puissent accéder rapidement à la richesse des connaissances collectives générées chaque jour. Une source essentielle ? Slack.

Slack est notre plateforme centrale pour les actualités, les discussions techniques et les précieuses questions-réponses. Mais, comme le savent les utilisateurs réguliers, sa nature conversationnelle fait que les informations essentielles se retrouvent vite enfouies sous les fils de discussion, les canaux et les innombrables messages.

C’est là qu’intervient la génération augmentée par récupération (RAG). Le RAG améliore les grands modèles de langage (LLM) en leur donnant accès à des informations spécifiques et à jour qui ne figuraient pas dans leurs données d’entraînement initiales. Notre objectif : exploiter la richesse des informations partagées sur Slack pour créer un outil interne de questions-réponses plus intelligent.

Comprendre les défis liés aux données

Notre démarche a commencé non pas par des algorithmes complexes, mais par une plongée dans les données brutes et désordonnées de Slack, telles qu’elles existent dans la réalité. Les messages Slack ne sont pas organisés de manière structurée : on y trouve des conversations informelles, des émojis et des identifiants cryptiques comme <@U123ABC> pour les utilisateurs et <#C456DEF> pour les canaux. Tout au long de ce processus, un principe fondamental est resté évident : « Si vous donnez des données de mauvaise qualité à un modèle, vous obtiendrez des résultats de mauvaise qualité. » Avant de créer notre solution, plusieurs défis majeurs se sont présentés :

• Repérer les informations utiles : Identifier les données pertinentes au milieu du bruit des conversations nécessitait un travail de sélection minutieux.

• Stratégie de segmentation : Déterminer comment segmenter les données s’est avéré délicat. Les fils de discussion variaient considérablement. Certains canaux connaissaient une activité intense et rapide, tandis que d’autres étaient sporadiques. Les approches classiques, comme la segmentation par jour ou par fenêtres glissantes, posaient problème : elles manquaient de cohérence et de pertinence.

• Décoder les identifiants Slack : Nous devions convertir les identifiants des utilisateurs et des canaux en noms compréhensibles pour garantir la lisibilité.

• Conversion en Markdown : Au départ, convertir les fils de discussion en Markdown semblait simple. Pourtant, le Markdown brut s’est révélé encombré d’émojis, de réactions et de réponses imbriquées, susceptibles de perturber le LLM.

Le déclic : les questions-réponses comme structure centrale

La percée est venue lorsque nous avons pris du recul et recentré notre réflexion sur l’objectif essentiel du système RAG : répondre aux questions des employés. Au lieu de forcer les données à entrer dans des segments prédéfinis, nous avons choisi de structurer les informations autour d’échanges clairs de questions-réponses. Chaque fil Slack dans lequel une question recevait une réponse devenait un segment documentaire structuré unique.

Ce changement intuitif a simplifié notre processus :

• Repérage des questions : Nous nous sommes concentrés sur les canaux Slack explicitement dédiés aux questions, comme #ask-product.

• LLM pour la synthèse : Avec l’API Gemini de Google, nous avons soumis les fils Slack à des consignes telles que « Formulez une question claire et une réponse complète ». Nous avons ainsi obtenu des données structurées de haute qualité, prêtes à être utilisées par notre système RAG.

• Stratégie de récupération : Nous avons vectorisé uniquement les questions extraites afin de retrouver efficacement les informations en comparant la requête de l’utilisateur aux questions enregistrées. Point essentiel : le LLM recevait la réponse (stockée sous forme de métadonnées) associée à la question enregistrée la plus similaire, et non la question elle-même. Cela garantissait que le contexte transmis au modèle était le plus pertinent possible.

• Solution de repli : Tous les fils utiles ne prenaient pas la forme de questions-réponses simples. Dans ces cas, nous les avons convertis en résumés Markdown clairs afin de préserver le contexte général.

• Mises à jour continues : Le système régénère automatiquement les résumés à l’ajout de nouveaux messages, pour que notre base de connaissances reste à jour.

Mettre en œuvre la solution

En privilégiant les structures de questions-réponses, nous avons défini un flux de travail technique clair et efficace :

• SDK Slack : Récupérer directement les messages depuis Slack.

• API Gemini : Transformer les fils de discussion en questions-réponses structurées ou en résumés Markdown.

• Snowflake Cortex Search Service : Stocker les résultats structurés et créer des représentations vectorielles des questions.

• Application RAG : Les employés posent des questions, qui sont vectorisées puis comparées sémantiquement aux questions enregistrées. Les réponses pertinentes sont récupérées depuis les métadonnées afin de fournir des réponses précises et adaptées au contexte.

Voir la description de l’image

Au-delà des API : des enseignements concrets pour l’ingénierie

Notre solution finale ne reposait pas sur des algorithmes révolutionnaires, mais sur une compréhension approfondie de nos données, une résolution créative des problèmes et une amélioration progressive de notre approche. La véritable prouesse d’ingénierie ne consistait pas simplement à intégrer des API ou à créer des représentations vectorielles, mais à structurer méticuleusement les données pour répondre à notre défi fondamental.

Notre stratégie axée sur les questions-réponses s’accorde naturellement avec le fonctionnement du RAG et transforme le chaos conversationnel de Slack en connaissances claires et accessibles. Elle montre que les solutions d’IA innovantes naissent souvent d’une compréhension des besoins humains, plutôt que de prouesses technologiques complexes à elles seules.