- Benchling gère son infrastructure cloud sur plusieurs régions et dans plusieurs environnements.
- Elle gère plus de 160 000 ressources avec Terraform Cloud, et environ 50 ingénieurs publient des changements d'infrastructure par mois.
- Une documentation FAQ volumineuse (20 pages) et des historiques de threads Slack existent, mais le problème identifié était une « inefficacité de la recherche ».
- Pour le résoudre, ils ont mis en place un Slackbot basé sur un LLM en RAG.
Objectifs de mise en place
- Développer un Slackbot interne pour résoudre en temps réel les questions liées à Terraform Cloud.
- Combiner des sources de données internes et externes pour fournir des réponses via une interface Slack familière.
- Cas d’usage possibles:
- Réponse aux questions RH
- Recherche de cas de résolution de problèmes clients
- Explication de codes d’erreur logiciels
Fonctionnement
- Analyse de la requête utilisateur : rechercher des informations pertinentes dans une base de données.
- Constitution du prompt LLM : générer la réponse en incluant les résultats de recherche et les consignes.
Stack technique
- Modèle RAG : Amazon Bedrock.
- Mise en place d’une base de connaissances basée sur une base de données OpenSearch Serverless.
- Génération des réponses avec le modèle Claude 3.5 Sonnet v2.
Sources de données
- Confluence : FAQ Terraform Cloud (sauvegardée au format PDF puis téléchargée vers S3).
- Web : documentation Terraform Cloud et documentation de langage de HashiCorp.
- Slack : threads de Slack contenant des incidents Terraform Cloud résolus (collectés manuellement pour le POC).
- Les données sont stockées dans une base vectorielle pour être consultables lors des requêtes.
Architecture de mise en œuvre
- Composants :
- Slack App
- AWS API Gateway
- AWS Lambda (avec Python)
- AWS Bedrock
- OpenSearch Serverless (base de données vectorielle)
- Modèles utilisés :
- Amazon Titan Text Embeddings v2 (génération d’embeddings)
- Claude 3.5 Sonnet v2 (génération de réponses)
Contraintes et améliorations futures
Limitations
- Absence de traitement d’image : pas de prise en charge des diagrammes d’architecture ou captures d’écran fondés sur des images.
- Prise en charge Terraform insuffisante : le provider AWS de Terraform ne prend actuellement pas en charge les ressources Bedrock.
Améliorations futures
- Ajout de liens sources : inclure la source des documents dans les réponses Slack.
- Sauvegarde automatique des threads Slack : mise à jour de la base de données avec la commande
@help-terraform-cloud souviens-toi.
- Automatisation de la synchronisation des données : synchronisation hebdomadaire via CloudWatch Events.
- Utilisation de l’API Confluence : passage d’un upload PDF manuel à une intégration via API.
- Prise en charge de conversations multi-tours : conserver le contexte conversationnel entre un utilisateur et l’outil.
Leçons tirées de la mise en place
- Stratégie de découpage des données :
- On a commencé avec des chunks de 300 tokens (environ 1 paragraphe), puis les a ajustés à 1 500 tokens (environ 5 paragraphes) pour éviter de couper les réponses longues.
- Efficacité du parsing PDF :
- Sauf les images, les données textuelles sont extraites de manière fiable.
- Facilité de configuration de la base de connaissances :
- Il est possible de la mettre en place en quelques minutes avec Amazon Bedrock.
Cas d’utilisation
- Consultation de la FAQ et des codes d’erreur.
- Réponse automatique aux questions répétitives.
- Exploitation de jeux de données personnalisés par équipe :
- historiques de conversations, documents partagés, etc.
Considérations de sécurité
- Évaluation de la sensibilité des données et du risque de résultats inexacts.
- Vérification du modèle approuvé par l’organisation.
Conclusion
- Un Slackbot basé sur un LLM démontre qu’un prototype rapide est possible.
- Les expérimentations de nouvelles technologies peuvent améliorer l’efficacité et la productivité.
- Sur cette base, construisez également vos propres outils basés sur un LLM !
Aucun commentaire pour le moment.