LLMs for Qualitative Data Analysis Fail on Security-specificComments in Human Experiments

1. Problématique et Contexte

L'analyse thématique (Thematic Analysis - TA) est une méthode standard en ingénierie logicielle et en sécurité pour extraire des insights qualitatifs à partir de données textuelles libres (comme les justifications des participants dans des expériences). Ce processus est traditionnellement manuel, coûteux et chronophage, nécessitant plusieurs experts pour garantir la fiabilité (calcul du Kappa de Cohen).

Bien que les Grands Modèles de Langage (LLMs) aient montré des résultats prometteurs pour des tâches d'analyse de sentiment ou d'extraction d'opinions générales, leur capacité à remplacer les annotateurs humains sur des commentaires techniques spécifiques à la sécurité reste inexplorée.

Le problème central est de savoir si les LLMs peuvent automatiser l'annotation de codes thématiques complexes dans des commentaires humains analysant des vulnérabilités logicielles. Contrairement à la détection de sentiments (positif/négatif), ces tâches exigent une compréhension contextuelle profonde (ex: identifier si un identifiant de variable spécifique est mentionné, si une ligne de code est citée, ou si un mot-clé de sécurité est présent dans un contexte technique précis).

2. Méthodologie

Les auteurs ont conçu une étude expérimentale rigoureuse pour évaluer quatre LLMs d'état de l'art (GPT-5, Claude-4, DeepSeek-V3.2, Qwen3-Max) sur un jeu de données réel.

A. Données et Annotation

• Source : Un ensemble de données inédit provenant d'une expérience précédente où des étudiants en informatique devaient identifier des vulnérabilités dans des extraits de code.
• Jeu de données : 263 commentaires textuels libres générés par des humains.
• Codes cibles : 9 codes thématiques spécifiques à la sécurité (ex: Var pour les identifiants de variables/méthodes, Lin pour les numéros de ligne, Key pour les mots-clés de sécurité, Vul pour la mention d'une vulnérabilité spécifique, Exp pour les exploits potentiels, etc.).
• Référence (Ground Truth) : Les commentaires ont été annotés par quatre annotateurs humains indépendants, suivis d'une phase de révision et de résolution de conflits.

B. Protocole Expérimental

L'objectif était de remplacer un annotateur humain par un LLM. Le protocole a suivi l'évolution de l'annotation humaine :

1. P1 (Prompt de base) : Description de la tâche et noms des codes uniquement.
2. P2 (Codebook) : Ajout de définitions formelles et d'exemples pour chaque code.
3. P3 (Exemples d'autres annotateurs) : Ajout des annotations d'autres humains pour fournir un contexte (few-shot learning).
4. P3+ (Exemples conflictuels et clarifications) : Le prompt inclut des exemples où les annotateurs humains étaient en désaccord, accompagnés des clarifications des chercheurs pour résoudre ces ambiguïtés.

C. Métriques d'Évaluation

Pour éviter de pénaliser les modèles sur des jeux de données déséquilibrés (où la plupart des commentaires ne contiennent pas un code spécifique), les auteurs n'ont pas utilisé uniquement la précision (Accuracy).

• Kappa de Cohen ($\kappa$) : Mesure l'accord entre le LLM et l'annotateur humain, corrigé par le hasard.
• Précision, Rappel et F1-score.
• Seuils de remplaçabilité : Les auteurs définissent des seuils (de "Hallucination" à "Presque Parfait") basés sur les guidelines standards du Kappa pour déterminer si un LLM est viable pour remplacer un humain.

3. Résultats Clés

Les résultats sont globalement négatifs concernant le remplacement complet des annotateurs humains.

A. Performance Globale (RQ1)

• Échec du remplacement : Aucun des quatre LLMs testés n'a atteint un niveau de performance suffisant pour remplacer de manière fiable un annotateur humain sur l'ensemble des codes.
• Kappa de Cohen : Les scores moyens de Kappa se situent majoritairement dans la fourchette "Limité" (0.2 - 0.4) ou "Modéré" (0.4 - 0.6), loin du seuil "Substantiel" (0.6+) nécessaire pour une automatisation fiable.
• Surprise : Les modèles open-source (DeepSeek-V3.2 et Qwen3-Max) ont souvent performé mieux que les modèles propriétaires (GPT-5, Claude-4) sur ce jeu de données spécifique.
• Spécificité des codes : Les modèles réussissent mieux sur des tâches factuelles simples (ex: détecter la mention d'un identifiant de variable Var ou d'un numéro de ligne Lin), mais échouent lamentablement sur des tâches interprétatives complexes (ex: détecter une réponse "floue" Unclr ou une incertitude Unsr).

B. Impact du Prompting (RQ2)

• Rendements décroissants : L'enrichissement progressif des prompts (de P1 à P3+) n'a pas entraîné d'amélioration statistiquement significative globale.
• Gain initial mineur : Une légère amélioration a été observée entre P1 (seulement la tâche) et P2 (ajout des définitions), mais les étapes suivantes (ajout d'exemples conflictuels) n'ont pas apporté de gains durables.
• Confusion par les données : Dans certains cas, l'ajout de détails et d'exemples a même confus les modèles, réduisant leur performance sur des codes spécifiques.

C. Analyse Qualitative des Erreurs

• Confusion sémantique : Les LLMs peinent à distinguer les termes techniques génériques des identifiants de code réels (ex: confondre le mot "debug" dans une phrase naturelle avec un identifiant de variable).
• Manque de contexte de sécurité : Les modèles interprètent souvent les mots-clés de sécurité de manière littérale sans comprendre l'intention de vulnérabilité sous-jacente.
• Gestion de l'incertitude : Les modèles ont tendance à sur-interpréter les expressions de doute humaines (ex: "je pense que...") comme des indicateurs d'incertitude, là où les annotateurs humains ne les considéraient pas comme tels.

4. Contributions Principales

1. Évaluation empirique rigoureuse : Première étude à tester systématiquement l'automatisation de l'analyse thématique dans le domaine de la sécurité logicielle, en utilisant un jeu de données annoté par des humains avec un protocole de validation strict.
2. Métrique adaptée : Utilisation du Kappa de Cohen (précision corrigée du hasard) comme métrique principale, démontrant que la simple précision (Accuracy) est trompeuse pour les tâches d'annotation de codes rares.
3. Analyse des prompts : Démonstration que l'ingénierie de prompt (même avec des techniques avancées comme l'ajout d'exemples conflictuels) ne suffit pas à combler le fossé sémantique entre la compréhension de surface des LLMs et le raisonnement expert en sécurité.
4. Comparaison Open vs Propriétaire : Mise en évidence que les modèles open-source peuvent surpasser les modèles propriétaires sur des tâches de niche spécifiques à la sécurité.

5. Signification et Conclusion

Conclusion : Les LLMs ne sont pas encore prêts à remplacer les annotateurs humains pour l'analyse qualitative de commentaires techniques en sécurité. Leur performance est trop incohérente, en particulier pour les codes nécessitant un raisonnement nuancé ou contextuel.

Implications :

• Rôle assistif : Les LLMs devraient être utilisés comme outils d'assistance (pour générer des ébauches, pré-filtrer des données ou suggérer des codes potentiels) plutôt que comme des annotateurs autonomes.
• Nécessité de validation humaine : La validation humaine reste indispensable pour garantir la fiabilité des données qualitatives dans les recherches en sécurité.
• Futur travail : Les auteurs suggèrent de se concentrer sur des interfaces de prompting structurées, le calibrage des modèles et la conception de pipelines hybrides où l'intelligence humaine complète l'analyse des LLMs.

En résumé, bien que les LLMs soient puissants pour le traitement du langage naturel général, leur application à l'analyse thématique fine et spécifique à la sécurité dans les expériences humaines rencontre encore des limites fondamentales de compréhension contextuelle et de fiabilité.