FeelingsAnalysis - Classification de sentiments pour avis de restaurants
NLP, sentiment analysis, classification multi-aspects, camembert, fine-tuning, PyTorch Lightning, transformers, analyse de sentiments, avis restaurants
L’analyse de sentiments est devenue un enjeu majeur pour les entreprises cherchant à comprendre les opinions de leurs clients. Dans le secteur de la restauration, les avis en ligne constituent une source d’information précieuse mais complexe à traiter, car ils expriment souvent des opinions nuancées sur plusieurs aspects d’une même expérience (qualité des plats, service, ambiance, rapport qualité-prix).
1 Contexte et problématique
Ce projet s’inscrit dans le cadre d’un défi académique visant à développer un système de classification multi-aspects de sentiments pour des avis de restaurants en français. Contrairement à une classification de sentiment simple (positif/négatif), l’objectif est d’identifier précisément l’opinion exprimée sur quatre aspects distincts : le prix, la cuisine, le service et l’ambiance. Pour chaque aspect, le système doit déterminer si l’opinion est positive, négative, neutre ou non Exprimée (NE).
Cette tâche présente plusieurs défis : (i) la nature multi-sortie du problème (4 classifications indépendantes) ; (ii) la gestion des classes déséquilibrées ; (iii) l’optimisation des performances avec des ressources GPU limitées ; et (iv) la nécessité d’atteindre un score d’exactitude d’au moins 85% pour être compétitif. Pour relever ces défis, deux approches ont été explorées : l’utilisation de modèles de langage (LLM) en mode zero-shot via Ollama, et le fine-tuning de modèles pré-entraînés (PLMFT) avec CamemBERT-Large (1).
2 Données
Le jeu de données utilisé est composé de trois fichiers TSV (Tab-Separated Values) : ftdataset_train.tsv (entraînement), ftdataset_val.tsv (validation) et ftdataset_test.tsv (test). Chaque fichier contient des avis de restaurants en français avec les colonnes suivantes :
| Colonne | Description |
|---|---|
Avis |
Texte de l’avis client |
Prix |
Sentiment sur le prix (Positive/Négative/Neutre/NE) |
Cuisine |
Sentiment sur la qualité de la cuisine |
Service |
Sentiment sur le service |
Ambiance |
Sentiment sur l’ambiance |
Les données présentent les caractéristiques suivantes :
- Classification multi-sortie : 4 tâches de classification indépendantes par avis
- 4 classes par aspect : positive, négative, neutre, NE (non exprimé)
- Déséquilibre potentiel : La classe “NE” peut être sur-représentée pour certains aspects
- Langue : Français exclusivement, nécessitant l’utilisation de modèles adaptés CamemBERT (1)
3 Approche et méthodologie
3.1 Deux approches complémentaires
3.1.1 LLM Zero-Shot (Ollama)
La première approche exploite des modèles de langage de grande taille (LLM) en mode zero-shot, sans entraînement spécifique. Un prompt structuré en français est envoyé au modèle via Ollama, demandant de classifier l’avis selon les 4 aspects. Le modèle retourne une réponse au format JSON qui est ensuite parsée.
Avantages : Aucun entraînement nécessaire, facilité de mise en œuvre
Limites : Fragilité du parsing JSON, performances variables, lenteur du traitement
3.1.2 PLMFT (Pre-trained Language Model Fine-Tuning)
La seconde approche, qui s’est révélée la plus performante, consiste à fine-tuner le modèle CamemBERT-Large (110M paramètres, (1)) sur nos données spécifiques. L’architecture mise en place utilise :
- Backbone : CamemBERT-Large pré-entraîné sur du texte français
- 4 têtes de classification indépendantes : Une couche linéaire par aspect
- Pooling : Extraction du token [CLS] comme représentation de la phrase
- Loss : CrossEntropyLoss avec label smoothing (0.1) pour réduire l’overfitting
3.2 Optimisations implémentées
Pour maximiser les performances tout en respectant les contraintes GPU, plusieurs optimisations ont été déployées :
- Gradient Checkpointing : réduit l’utilisation mémoire GPU de ~40%
- Mixed Precision Training (FP16) : accélération ~2-3x de l’entraînement
- Discriminative Learning Rates : taux d’apprentissage différencié entre le backbone (\(1e-5\)) et les têtes de classification (\(2e-5\))
- Label Smoothing (0.1) : régularisation pour améliorer la généralisation
- Gradient Accumulation (×4) : simule des batchs plus larges (batch effectif = 128)
- Warmup + Linear Scheduler : stabilise l’entraînement avec 1000 steps de warmup
- Early Stopping (patience=3) : arrêt automatique si pas d’amélioration sur la validation
- DataLoader optimisé :
num_workers=8,pin_memory=True,persistent_workers=True
3.3 Pipeline d’entraînement
Le pipeline d’entraînement s’appuie sur PyTorch Lightning, garantissant reproductibilité et modularité :
- Préparation des données : chargement des fichiers TSV et création de
AspectDataset - Tokenization : utilisation du tokenizer CamemBERT avec
max_length=256 - Entraînement : fine-tuning avec validation croisée
- Évaluation : calcul de l’accuracy par aspect et macro-accuracy
- Logging : sauvegarde automatique des métriques dans
lightning_logs/
L’ensemble du processus est orchestré par runproject.py, qui permet de lancer facilement des expériences avec différents hyperparamètres via des arguments CLI (device, batch_size, learning_rate, etc.).
4 Résultats
Les expériences menées ont permis d’atteindre des performances solides, avec une macro-accuracy de 85.99% sur l’ensemble de validation.
4.1 Performances par aspect
| Aspect | Val Accuracy |
|---|---|
| Prix | 86.7% |
| Cuisine | 87.2% |
| Service | 87.8% |
| Ambiance | 82.3% |
| Moyenne | 85.99% |
Le service est l’aspect le mieux prédit (87.8%), suivi de la cuisine (87.2%) et du prix (86.7%). L’ambiance reste légèrement en retrait (82.3%), probablement en raison d’une plus grande variabilité dans les expressions utilisées pour décrire cet aspect.
4.2 Historique des expériences
Au total, 24+ versions d’expériences ont été menées avec différentes combinaisons d’hyperparamètres. Les logs détaillés sont disponibles dans src/lightning_logs/, permettant de comparer :
- Les courbes de loss (train/validation)
- Les métriques par aspect
- Les temps d’entraînement
- L’impact des différents hyperparamètres
L’analyse de ces expériences a permis d’identifier la configuration optimale retenue dans config.py.
5 Technologies utilisées
Le projet repose sur un écosystème Python moderne et éprouvé :
Deep Learning
- torch>=2.0.0 : Framework de deep learning - lightning>=2.0.0 : Entraînement structuré et reproductible - transformers>=4.30.0 : Accès aux modèles pré-entraînés (CamemBERT, (1))
Traitement de données
- pandas>=2.0.0 : Manipulation des fichiers TSV - numpy>=1.24.0 : Calculs numériques
Configuration et CLI
- pyrallis>=0.3.0 : Parsing élégant des arguments avec dataclasses - pyyaml>=6.0 : Configuration au format YAML
LLM (optionnel)
- ollama>=0.1.0 : Interface pour l’approche zero-shot - jinja2>=3.1.0 : Templates de prompts
Évaluation
- scikit-learn>=1.3.0 : Métriques d’évaluation - tqdm>=4.65.0 : Barres de progression
L’ensemble forme un stack cohérent, bien documenté et maintenu par la communauté scientifique et industrielle.
6 Difficultés et leçons apprises
6.1 Gestion de la mémoire GPU
Le fine-tuning de CamemBERT-Large (110M paramètres, (1)) sur GPU a nécessité une optimisation poussée de l’utilisation mémoire. Les erreurs CUDA Out Of Memory ont été fréquentes dans les premières expériences. L’activation du gradient checkpointing et l’utilisation de mixed precision training ont été déterminantes pour permettre l’entraînement avec des batch sizes raisonnables.
6.2 Équilibrage des hyperparamètres
Trouver le bon équilibre entre learning rate du backbone et des têtes de classification s’est révélé crucial. Un learning rate trop élevé sur le backbone entraînait un “catastrophic forgetting” (le modèle oubliait ses connaissances pré-entraînées), tandis qu’un learning rate trop faible ralentissait la convergence.
6.3 Gestion du déséquilibre des classes
La classe “NE” (Non Exprimé) étant potentiellement sur-représentée, l’utilisation de label smoothing a permis de réduire la sur-confiance du modèle sur cette classe majoritaire et d’améliorer la généralisation.
6.4 Pipeline reproductible
La mise en place d’un système de configuration centralisé (config.py) et l’utilisation de PyTorch Lightning (3) ont grandement facilité la reproductibilité des expériences. Chaque run est loggé automatiquement avec ses hyperparamètres, permettant de tracer précisément les améliorations entre versions.
7 Lien vers le projet
Le code source est accessible sur GitHub : https://github.com/NCSdecoopman/FeelingsAnalysis
8 Cas d’usage et perspectives
8.1 Applications pratiques
Ce système de classification multi-aspects trouve des applications directes dans :
- Analyse de réputation en ligne : les restaurateurs peuvent identifier précisément les points forts et faibles de leur établissement
- Recommandation personnalisée : suggérer des restaurants en fonction des préférences aspect par aspect
- Monitoring temps réel : détecter rapidement une dégradation sur un aspect spécifique (ex: service)
- Benchmarking concurrentiel : comparer les performances sur chaque dimension
8.2 Pistes d’amélioration
Plusieurs axes d’amélioration sont envisageables :
- Ensembling : combiner les prédictions de plusieurs modèles (XGBoost + LGBM sur features linguistiques + CamemBERT)
- Data augmentation : augmenter artificiellement les données d’entraînement (paraphrase, back-translation)
- Architecture avancée : tester des modèles plus récents (DeBERTa, mBART, RoBERTa-large français)
- Attention multi-aspects : intégrer un mécanisme d’attention croisée entre les 4 têtes pour capturer les interactions entre aspects
- Distillation : créer un modèle plus léger (CamemBERT-base) pour le déploiement en production
- Interface interactive : développer une API REST ou une interface web pour des tests en temps réel
8.3 Généralisation
L’approche développée est transposable à d’autres domaines nécessitant une analyse fine d’opinions :
- Avis produits e-commerce (qualité, prix, livraison, SAV)
- Enquêtes de satisfaction client (plusieurs dimensions)
- Analyse de feedback employés (environnement, management, rémunération)