Accueil › Glossaire › Slot Filling

Slot Filling

Le slot filling (remplissage de slots) est une tâche d’étiquetage de séquences en compréhension du langage naturel (NLU) qui consiste à identifier et extraire les paramètres pertinents (slots) dans un message utilisateur, en associant chaque mot ou groupe de mots à un type sémantique prédéfini comme une date, un lieu, un nom de produit ou un montant.

Slot filling en contexte

Quand un utilisateur dit « Réserve-moi un vol Paris-Tokyo le 15 avril pour 2 personnes », l’intent classification identifie l’intention (book_flight). Le slot filling, lui, extrait les paramètres nécessaires pour exécuter cette action :

Sans slot filling, le chatbot sait que l’utilisateur veut réserver un vol, mais pas les détails. C’est comme si un agent de voyage entendait « je veux réserver » sans savoir où, quand, ni pour combien de personnes. Le slot filling comble ce manque en structurant l’information extraite du langage naturel.

Le schéma BIO et ses variantes

Le slot filling est formalisé comme un problème d’étiquetage de séquences (sequence labeling). Chaque token du message reçoit une étiquette selon le schéma BIO :

B-slot (Begin) : premier token d’une entité. « B-departure_city » marque le début d’une ville de départ.

I-slot (Inside) : tokens suivants de la même entité. « I-departure_date » pour le « avril » dans « 15 avril ».

O (Outside) : tokens qui ne font partie d’aucun slot.

Des variantes existent : BIO2 (identique à BIO mais avec des conventions plus strictes), BIOES (ajoute S pour single-token entities et E pour le dernier token), et BILOU (Begin, Inside, Last, Outside, Unit). En pratique, BIO est le plus utilisé car il offre le meilleur compromis simplicité/performance.

Slot filling vs. NER : quelle différence ?

Le slot filling est très proche de la reconnaissance d’entités nommées (NER), mais avec des différences importantes :

En pratique, un NER générique peut servir de base pour le slot filling si les types d’entités correspondent. Mais les slots spécifiques à un domaine (type de cuisine, catégorie de produit, niveau de priorité) nécessitent un modèle entraîné sur des données spécifiques.

L’approche joint : intent + slots ensemble

La recherche montre clairement que traiter l’intent classification et le slot filling conjointement (joint model) produit de meilleurs résultats que de les traiter séparément. L’intuition est simple : savoir que l’intent est book_flight aide à identifier les slots (departure_city, arrival_city, date), et réciproquement, identifier les slots aide à confirmer l’intent.

Les architectures joint modernes partagent un encodeur commun (typiquement BERT) et utilisent deux têtes de sortie : une tête de classification pour l’intent (softmax sur le token [CLS]) et une tête d’étiquetage de séquences pour les slots (softmax par token). La loss est une combinaison pondérée des deux tâches.

Architectures joint de référence

JointBERT : l’approche fondatrice. BERT encodeur partagé + tête intent + tête slot. Simple, efficace, et le baseline que tout le monde compare. Atteint environ 97.5% d’accuracy d’intent et 96.1% de F1 de slots sur ATIS.

DIET (Dual Intent and Entity Transformer) : le modèle phare de Rasa. DIET est une architecture Transformer allégée conçue pour le NLU conversationnel, qui traite conjointement intent et slots avec des performances proches de BERT mais une inférence plus rapide. Son avantage : il peut combiner des embeddings pré-entraînés (BERT, GloVe) avec des features sparse (n-grammes) dans une architecture unifiée.

ESIE-BERT : publié dans ScienceDirect (2024), ce modèle résout un problème spécifique de BERT pour le slot filling. Le tokenizer WordPiece de BERT découpe les mots complexes en sous-tokens, créant un désalignement entre tokens et labels. ESIE-BERT utilise un Sub-word Attention Adapter pour exploiter explicitement l’information des sous-tokens, avec des gains mesurables sur ATIS et SNIPS.

Multichannel CNN-BiLSTM : un modèle publié en 2024 (PMC) qui combine des embeddings multiples (Word2Vec, fastText, BERT) via un CNN multi-canaux avec un BiLSTM pour capturer les features syntaxiques et sémantiques. Les résultats montrent des gains de 2 à 3 points de F1 en slot filling par rapport aux modèles BiLSTM-BERT classiques.

Graph-based models : des architectures utilisant des réseaux d’attention sur graphes (GAT) pour modéliser les interactions entre intents multiples et slots, particulièrement efficaces en multi-intent où un seul message contient plusieurs intentions avec des slots entrelacés.

LLMs pour le slot filling

Les grands modèles de langage transforment le slot filling en supprimant le besoin d’annotation BIO :

Extraction structurée par prompt : au lieu d’un modèle d’étiquetage de séquences, on demande au LLM d’extraire les slots en JSON. Cette approche est naturelle pour les LLMs qui excellent en sortie structurée.

Prompt :
"Extrayez les informations suivantes du message utilisateur :
- departure_city (ville de départ)
- arrival_city (ville d'arrivée)
- departure_date (date de départ, format YYYY-MM-DD)
- num_passengers (nombre de passagers)

Message : 'Je voudrais réserver un vol de Lyon à Berlin
le 22 mai pour 3 passagers'

Répondez uniquement en JSON."

Réponse LLM :
{
  "departure_city": "Lyon",
  "arrival_city": "Berlin",
  "departure_date": "2026-05-22",
  "num_passengers": 3
}

Function calling / Tool use : les LLMs modernes (GPT-5.4, Claude Opus 4.6) supportent nativement le function calling, qui est essentiellement du slot filling intégré au modèle. Vous définissez un schéma de fonction avec ses paramètres, et le LLM extrait automatiquement les valeurs à partir du message utilisateur. C’est la forme la plus moderne et la plus élégante de slot filling.

LLMs fine-tunés pour le NLU joint : des travaux récents (ACM Computing Surveys, 2025) montrent que les LLMs fine-tunés sur des datasets NLU surpassent les modules séparés et les LLMs non fine-tunés pour le joint intent + slot filling. L’approche CoF-CoT (Chain of Filling with Chain of Thought) décompose le NLU en étapes de raisonnement multiples, permettant au LLM de raisonner sur les slots à différentes granularités.

Datasets de référence

ATIS (Air Travel Information System) est le dataset historique, utilisé depuis les années 1990. Il ne contient que des requêtes de réservation aérienne, ce qui le rend facile mais peu représentatif des cas réels. SNIPS est plus réaliste avec 7 domaines (musique, météo, restaurants, etc.) et une plus grande variété de formulations. MultiWOZ est le plus complet car il contient des dialogues multi-tours avec un suivi d’état (dialogue state tracking), pas seulement des requêtes isolées.

Évolution des méthodes

Ère CRF et HMM (2005-2015)

Les premiers systèmes de slot filling utilisaient des modèles séquentiels classiques : Hidden Markov Models (HMM) pour modéliser la séquence de slots, puis Conditional Random Fields (CRF) qui capturent les dépendances entre labels adjacents. Les CRF restent un composant utile comme couche de sortie dans les architectures modernes (JointBERT + CRF).

Ère RNN/BiLSTM (2015-2019)

Les réseaux récurrents bidirectionnels (BiLSTM) ont marqué un progrès majeur en capturant le contexte dans les deux sens. L’architecture BiLSTM-CRF (BiLSTM pour l’encodage + CRF pour le décodage) est devenue le standard, offrant le meilleur des deux mondes : représentations contextuelles apprises et contraintes structurelles sur les séquences de labels.

Ère Transformers (2019-aujourd’hui)

BERT et ses variantes ont remplacé le BiLSTM comme encodeur, apportant des représentations contextuelles pré-entraînées nettement supérieures. JointBERT (2019) a posé les bases. Les travaux ultérieurs (ESIE-BERT, SlotRefine, GL-GIN) ont raffiné l’architecture pour gérer les problèmes de sous-tokenisation, les interactions multi-intent/slot, et le transfer cross-lingue. Les modèles joints BERT atteignent 96-97% de F1 sur les slots ATIS et 95-96% sur SNIPS.

Ère LLMs (2023-aujourd’hui)

Les LLMs reformulent le slot filling comme une tâche de génération de texte structuré plutôt qu’un étiquetage de séquences. Le function calling et le JSON mode sont les mécanismes pratiques. Les LLMs fine-tunés pour le NLU joint montrent des gains par rapport aux modules séparés, surtout en scénario multi-domaine et multilingue. La tendance est aux systèmes hybrides où un DSL (Domain-Specific Language) sert d’interface entre le LLM et la logique métier.

Applications concrètes

Chatbots de service client : extraire automatiquement le numéro de commande, le nom du produit, la date d’achat et le type de problème à partir du message client. Chaque slot remplit un champ dans le CRM ou déclenche une requête API spécifique.

Assistants vocaux : « Mets de la musique jazz dans le salon » → slots : {genre: jazz, room: salon, action: play}. La vitesse d’extraction est critique (l’utilisateur attend une réponse immédiate).

Systèmes de réservation : hôtels, restaurants, transport. Les slots couvrent les dates, le nombre de personnes, les préférences (fenêtre/couloir, végétarien/non), le budget.

Formulaires conversationnels : au lieu de remplir un formulaire classique, l’utilisateur décrit sa demande en langage naturel et le système extrait les champs. C’est l’application qui se développe le plus avec les LLMs, car le function calling rend ce pattern trivial à implémenter.

Agents IA : les agents autonomes utilisent le slot filling (via function calling) pour extraire les paramètres nécessaires avant d’invoquer un outil ou une API. « Envoie un email à Marie avec le résumé du rapport Q3 » → slots : {recipient: Marie, content: résumé Q3, action: send_email}.

Implémentation pratique

# Option 1 : Hugging Face Token Classification
from transformers import pipeline

slot_filler = pipeline(
    "token-classification",
    model="dslim/bert-base-NER",  # NER générique comme base
    aggregation_strategy="simple"
)

result = slot_filler("Book a flight from Paris to Tokyo on April 15")
# → [{'entity_group': 'LOC', 'word': 'Paris', ...},
#    {'entity_group': 'LOC', 'word': 'Tokyo', ...}]

# Option 2 : LLM avec function calling (Claude/GPT)
# Définir les paramètres de la fonction
tools = [{
    "name": "book_flight",
    "description": "Réserve un vol",
    "input_schema": {
        "type": "object",
        "properties": {
            "departure_city": {"type": "string"},
            "arrival_city": {"type": "string"},
            "date": {"type": "string", "format": "date"},
            "passengers": {"type": "integer"}
        },
        "required": ["departure_city", "arrival_city", "date"]
    }
}]
# Le LLM extrait automatiquement les slots

Défis ouverts

Slots implicites : « Réserve pour demain » implique que la date est le lendemain de la date actuelle. Le système doit inférer et normaliser cette information. Les LLMs gèrent mieux les slots implicites que les modèles BIO classiques.

Multi-domaine et transfert : un modèle entraîné sur les réservations aériennes ne reconnaît pas les slots de réservation de restaurant. Le transfer learning cross-domaine et les modèles multilingues (xSID) adressent cette limitation.

Slots dans les dialogues multi-tours : « Je veux un vol pour Tokyo. Ah non, finalement Berlin. » Le système doit mettre à jour les slots au fil de la conversation, pas seulement les extraire d’un seul message. C’est le domaine du dialogue state tracking.

Sous-tokenisation : le tokenizer WordPiece de BERT découpe les mots rares en sous-tokens, créant un désalignement avec les labels BIO. Les solutions incluent ESIE-BERT (exploitation des sous-tokens) et l’alignement de labels post-tokenisation.

Verdict

Le slot filling est une tâche NLU mature avec des performances élevées sur les benchmarks (>96% F1 sur ATIS/SNIPS). L’approche joint (intent + slots dans un même modèle) est le standard, avec JointBERT et DIET (Rasa) comme solutions de référence. Les LLMs changent la donne non pas en améliorant les performances brutes, mais en simplifiant radicalement l’implémentation via le function calling, qui transforme le slot filling en un problème d’extraction structurée naturellement géré par le modèle.

Pour un projet concret : si vous construisez un chatbot dédié avec des données d’entraînement, Rasa avec DIET est le choix le plus robuste. Si vous construisez un agent IA polyvalent ou un prototype, le function calling de Claude ou GPT-5.4 est la voie la plus rapide et la plus flexible. Pour le français, les modèles multilingues (mBERT, XLM-RoBERTa) ou les LLMs multilingues fonctionnent bien sans données françaises spécifiques.