CVE LLM Pipeline : séparer les faits vérifiables du contenu généré

Le problème : jusqu’où faire confiance au LLM ?

J’ai construit ce projet personnel pour apprendre le fine-tuning LoRA, le RAG et l’expérimentation MLOps à partir de données réelles de vulnérabilités. Le pipeline collecte des CVE depuis la NVD, adapte Mistral 7B sur un GPU AMD avec ROCm, indexe les CVE dans ChromaDB et compare les réponses avec et sans contexte supplémentaire.

L’adaptateur LoRA de référence a été entraîné sur 3 000 exemples, avec un passage complet sur le jeu d’entraînement. Les 24 292 CVE affichées en tête de page correspondent aux CVE indexées dans ChromaDB, et non au nombre d’exemples utilisés pour l’entraînement.

Le principal enseignement n’a pas été un meilleur score du modèle. Les expériences ont surtout montré que de bons résultats apparents pouvaient cacher des erreurs d’évaluation, et que le RAG ou le fine-tuning ne suffisaient pas à rendre des informations factuelles fiables. Un LLM peut expliquer une vulnérabilité, mais peut-on lui faire confiance pour fournir lui-même des informations précises comme le score CVSS ou la CWE ?

La réponse apportée par le projet est de séparer les deux rôles : les faits vérifiables viennent des données de référence, tandis que le LLM est utilisé pour produire l’explication.

Ce que les expériences ont changé

Le jeu d’évaluation principal porte sur 50 CVE identifiées explicitement et présentes dans l’index. Dans la version actuelle, ces 50 CVE sont exclues des jeux d’entraînement et de validation. Cela ne permet toutefois pas de reconstituer avec certitude les données utilisées par certains anciens adaptateurs LoRA. Les résultats ci-dessous décrivent donc ce jeu de test précis et ne constituent pas une mesure générale des performances du modèle.

Les 50/50 d’Exp1 et les 44/50 utilisés comme contrôle dans Exp4 proviennent d’exécutions expérimentales différentes ; ils ne forment pas une comparaison directe avant/après.

L’architecture qui en découle

Les données NVD normalisées sont indexées dans ChromaDB, avec une CVE par document. L’API suit ensuite l’une des deux voies selon qu’un identifiant exact est trouvé ou non.

Les données de référence comprennent l’identifiant CVE, le CVSS officiel NVD lorsqu’il existe, la sévérité, les CWE, la date de publication et le vecteur d’attaque. facts contient ces informations vérifiables. answer contient l’explication générée par le LLM. Pour une valeur précise comme le CVSS ou la CWE, le client doit donc utiliser facts, et non essayer de retrouver cette information dans le texte généré.

Après Exp4, continuer à entraîner le modèle ne répondait plus au problème principal. Le véritable enjeu était de déterminer quelles informations ne devaient pas être générées par le LLM. J’ai donc arrêté les expériences GPU et séparé les données factuelles de l’explication générée. Cela ne signifie pas que le problème des hallucinations est résolu ; l’architecture évite simplement de confier au modèle les champs qui doivent rester vérifiables.

Traçabilité et méthode

La première préparation des données répartissait des exemples entre les ensembles plutôt que des CVE complètes. Une même CVE pouvait donc apparaître dans plusieurs ensembles, ce qui rendait les premières comparaisons peu fiables. Le pipeline actuel réserve d’abord les 50 CVE de test, puis sépare les CVE entre entraînement et validation avant de créer les différentes variantes d’instruction. Il vérifie ensuite qu’aucune CVE n’est partagée entre entraînement, validation et test.

DVC suit les données utilisées et MLflow enregistre les expériences. Les contextes et réponses sauvegardés permettent aussi de recalculer certaines évaluations sans relancer le modèle sur GPU. Une suite de 184 tests pytest vérifie notamment l’isolation des données, le comportement de l’index et la séparation entre facts et answer.

La traçabilité historique reste partielle : pour certains anciens artefacts, il n’est pas possible de reconstituer exactement le jeu de données d’entraînement utilisé.

Le développement a été largement assisté par des coding agents. J’ai défini leur périmètre et gardé la responsabilité de l’architecture, du protocole expérimental, des critères d’acceptation, des revues ciblées, des tests, du dépannage et des conclusions. Ce projet complète mon expérience SRE / Platform Engineering ; il ne prétend pas être une plateforme de sécurité en production ni un travail de recherche académique.

Ce que j’en retiens

• Une mauvaise évaluation peut donner l’impression qu’un modèle s’améliore alors que ce n’est pas le cas.
• Trouver la bonne CVE ne garantit pas que le LLM reproduira correctement ses valeurs.
• Le RAG et le fine-tuning peuvent changer le type d’erreurs, mais ils ne rendent pas automatiquement le texte généré fiable.
• Les faits vérifiables doivent venir de la source de référence ; le LLM est surtout utile pour les expliquer.
• Savoir arrêter l’entraînement et changer l’architecture fait aussi partie du travail d’ingénierie.