Accueil › Glossaire › Question Answering

Question Answering (QA)

Le question answering (QA, ou réponse automatique aux questions) est une tâche de traitement automatique du langage naturel qui consiste à produire automatiquement une réponse précise à une question formulée en langage naturel, en exploitant un contexte textuel, une base de connaissances ou les connaissances internes d’un modèle.

Vous posez une question, le système vous renvoie la réponse. Pas une liste de liens (comme un moteur de recherche classique), mais la réponse directe. C’est ce que font déjà les chatbots IA, les assistants virtuels, les moteurs de recherche conversationnels comme Perplexity, et les systèmes internes d’entreprise qui permettent d’interroger la documentation en langage naturel.

Le QA a connu une transformation majeure ces dernières années. L’arrivée des Transformers (BERT en 2018), puis des LLM génératifs (GPT, Claude, Gemini), a fait passer le QA d’une tâche de recherche académique à un produit déployé massivement en production. Le paradigme RAG (Retrieval-Augmented Generation), qui combine recherche documentaire et génération de réponse, est devenu l’architecture standard pour les systèmes de QA en entreprise.

Types de question answering

Le QA n’est pas une tâche monolithique. Selon la source de la réponse et la méthode de production, on distingue plusieurs variantes.

QA extractif (Extractive QA)

Le modèle reçoit une question et un passage de texte (le contexte), et doit identifier le segment exact (le « span ») du texte qui répond à la question. La réponse est une sous-chaîne du contexte, copiée telle quelle.

Exemple : le contexte contient « Paris est la capitale de la France depuis le Xe siècle. » À la question « Quelle est la capitale de la France ? », le modèle extrait « Paris ».

C’est le format du benchmark SQuAD. Le modèle prédit deux positions : le début et la fin du span de réponse dans le texte. BERT fine-tuné sur SQuAD 1.1 atteint un F1-score de 93,2%, et les meilleurs modèles dépassent les performances humaines (F1 ~91,2% pour les annotateurs humains sur SQuAD 1.1).

L’avantage du QA extractif est la traçabilité : la réponse vient mot-pour-mot du document source, ce qui élimine le risque d’hallucination. L’inconvénient est qu’il ne peut pas reformuler, synthétiser ou combiner des informations de plusieurs passages.

QA abstractif / génératif (Generative QA)

Le modèle génère la réponse mot par mot plutôt que de l’extraire d’un texte source. Les LLM comme GPT, Claude et Gemini fonctionnent nativement en mode génératif. Ils peuvent reformuler, synthétiser des informations provenant de plusieurs sources, et produire des réponses fluides et complètes.

Le risque principal est l’hallucination : le modèle peut générer une réponse plausible mais fausse, surtout quand il n’a pas de source fiable à consulter. C’est pour ça que le paradigme RAG (voir ci-dessous) est devenu incontournable en production.

QA open-domain vs closed-domain

Closed-domain (domaine fermé) : le système répond à des questions dans un domaine spécifique, en s’appuyant sur un corpus défini. Exemples : FAQ d’un produit, documentation technique interne, base de connaissances médicale. Le contexte est connu et contrôlé.

Open-domain (domaine ouvert) : le système doit répondre à n’importe quelle question sur n’importe quel sujet. Il doit d’abord trouver les documents pertinents (étape de retrieval) puis extraire ou générer la réponse. C’est ce que font les moteurs de recherche conversationnels et les assistants IA généralistes. C’est nettement plus complexe car le corpus source est potentiellement illimité (tout le web, ou toute une base documentaire d’entreprise).

QA sur base de connaissances (KBQA)

Le Knowledge-Base Question Answering traduit la question en langage naturel en une requête structurée (SPARQL, SQL, ou autre) exécutée sur un graphe de connaissances (Wikidata, DBpedia, graphe propriétaire). Exemple : « Qui est le président de la France ? » devient une requête structurée qui retourne l’entité correspondante. Cette approche est précise mais limitée aux informations présentes dans la base de connaissances et nécessite un parsing sémantique complexe.

QA visuel (Visual QA)

Le Visual Question Answering combine vision par ordinateur et compréhension du langage : le modèle reçoit une image et une question et doit produire une réponse. Exemple : une photo d’une rue avec la question « Combien de voitures sont visibles ? » Les modèles multimodaux comme GPT-4o et Gemini excellent sur cette tâche.

Le paradigme RAG : l’architecture dominante

Le Retrieval-Augmented Generation (RAG) est devenu l’architecture standard pour le QA en production. Il résout le problème fondamental des LLM : leur connaissance est figée au moment de l’entraînement et ils peuvent halluciner.

Le pipeline RAG fonctionne en deux étapes :

1. Retrieval (recherche) : la question est convertie en embedding et comparée aux embeddings des documents dans une base vectorielle. Les passages les plus similaires sont récupérés.
2. Generation (génération) : les passages récupérés sont injectés dans le contexte du LLM avec la question. Le modèle génère une réponse basée sur ces documents sources.

Cette architecture combine le meilleur des deux mondes : la fraîcheur et la précision factuelle des documents sources, avec la fluidité et la capacité de synthèse des LLM.

Les frameworks dominants pour construire des pipelines RAG sont LangChain, LlamaIndex, et les SDKs natifs des fournisseurs de LLM (Anthropic, OpenAI). Pour le stockage vectoriel, les solutions les plus utilisées sont Pinecone, Weaviate, ChromaDB, Qdrant, et FAISS.

Évolution des méthodes de QA

Avant les Transformers

Les premiers systèmes de QA (années 2000-2015) utilisaient des pipelines complexes : analyse de la question (type de réponse attendu), retrieval de passages, extraction de candidats, et re-ranking. Les modèles incluaient des features linguistiques artisanales (type d’entité nommée attendu, patterns syntaxiques), combinées avec des SVM ou des réseaux de neurones simples.

Les architectures neuronales comme BiDAF (Bidirectional Attention Flow, 2016) et DrQA (Chen et al., 2017) ont marqué un tournant en introduisant des mécanismes d’attention pour aligner la question et le contexte. DrQA a aussi popularisé l’approche « retriever + reader » pour le QA open-domain.

L’ère BERT (2018-2020)

BERT a révolutionné le QA extractif. En encodant simultanément la question et le contexte dans un seul modèle Transformer bidirectionnel, BERT capture les interactions fines entre la question et le passage. Le fine-tuning de BERT sur SQuAD est devenu un exercice standard en NLP.

Sur SQuAD 1.1, BERT-large a atteint un F1-score de 93,2% dès sa publication, dépassant le score humain de 91,2%. Sur SQuAD 2.0 (qui inclut des questions sans réponse), BERT a atteint un F1 de 83,1%. Les variantes (RoBERTa, ALBERT, DeBERTa) ont poussé ces scores encore plus haut.

L’ère des LLM (2022-présent)

Les LLM génératifs ont fondamentalement changé l’approche du QA. Au lieu d’extraire un span d’un passage, ils génèrent directement la réponse. Combinés avec le RAG, ils produisent des réponses complètes, bien formulées, et sourcées.

L’avantage des LLM est leur capacité de raisonnement multi-étapes. Les questions complexes (« Quelle est la différence de PIB par habitant entre la France et l’Allemagne, et quel pays a la meilleure croissance sur 5 ans ? ») nécessitent de combiner plusieurs informations. Les systèmes extractifs classiques ne gèrent pas ce type de raisonnement.

Des architectures comme Doc-React (ACL 2025) poussent encore plus loin en utilisant un framework itératif : le LLM formule des sous-questions, récupère des informations, évalue leur pertinence, et raffine sa recherche avant de produire la réponse finale.

Benchmarks de référence

SQuAD reste le benchmark de référence académique, mais il est considéré comme « résolu » : les meilleurs modèles dépassent les performances humaines depuis 2019. Les benchmarks actuels se concentrent sur des tâches plus complexes : multi-hop reasoning (HotpotQA), intégration multimodale (HybridQA), et QA conversationnel (CoQA, QuAC).

Outils pour le question answering

Hugging Face Transformers

La pipeline question-answering de Hugging Face permet de déployer un QA extractif en quelques lignes. Des centaines de modèles pré-entraînés et fine-tunés sur SQuAD sont disponibles sur le Hub.

from transformers import pipeline

# QA extractif avec un BERT fine-tuné sur SQuAD
qa = pipeline("question-answering",
              model="deepset/roberta-base-squad2")

contexte = """
L'intelligence artificielle générative utilise des modèles de deep learning
pour créer du contenu original : texte, images, musique, code.
Les LLM comme GPT et Claude sont des exemples d'IA générative.
Le marché de l'IA générative est estimé à plus de 60 milliards de dollars.
"""

question = "Quels sont des exemples d'IA générative ?"
result = qa(question=question, context=contexte)
print(f"Réponse : {result['answer']}")
print(f"Score : {result['score']:.3f}")
print(f"Position : [{result['start']}:{result['end']}]")
# Réponse : GPT et Claude
# Score : 0.847

LangChain / LlamaIndex (RAG)

Pour le QA en production sur une base documentaire, LangChain et LlamaIndex fournissent des abstractions pour construire des pipelines RAG complètes : chargement de documents, chunking, embeddings, stockage vectoriel, retrieval, et génération.

from langchain.document_loaders import DirectoryLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import HuggingFaceEmbeddings
from langchain.vectorstores import FAISS
from langchain.chains import RetrievalQA
from langchain.llms import Anthropic

# 1. Charger les documents
loader = DirectoryLoader("./docs", glob="**/*.md")
documents = loader.load()

# 2. Découper en chunks
splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000, chunk_overlap=200)
chunks = splitter.split_documents(documents)

# 3. Créer les embeddings et la base vectorielle
embeddings = HuggingFaceEmbeddings(
    model_name="sentence-transformers/all-MiniLM-L6-v2")
vectorstore = FAISS.from_documents(chunks, embeddings)

# 4. Pipeline RAG avec un LLM
qa_chain = RetrievalQA.from_chain_type(
    llm=Anthropic(model="claude-sonnet-4-20250514"),
    chain_type="stuff",
    retriever=vectorstore.as_retriever(search_kwargs={"k": 5}),
    return_source_documents=True
)

result = qa_chain({"query": "Comment fonctionne le RAG ?"})
print(result["result"])

API et services managés

Applications concrètes

Support client et FAQ automatisée

Le cas d’usage le plus déployé. Le système indexe la documentation produit, les FAQ, les guides utilisateur, et répond automatiquement aux questions des clients. Réduit le volume de tickets de 30 à 60% selon les implémentations. Les meilleurs systèmes détectent quand ils ne savent pas répondre et escaladent vers un humain.

Recherche documentaire interne

Les employés interrogent en langage naturel la base de connaissances de l’entreprise : politiques RH, procédures, documentation technique, contrats, comptes-rendus. Remplace les requêtes par mots-clés par des questions naturelles (« Quelle est la politique de congés pour les parents d’enfants de moins de 3 ans ? »).

QA juridique

Interroger des corpus juridiques (lois, jurisprudence, contrats) en langage naturel. Des modèles spécialisés comme LegalBERT sont fine-tunés sur du texte juridique. Le RAG est particulièrement critique ici car les réponses doivent être traçables (citer le texte de loi ou l’article exact).

QA médical

Systèmes de QA sur la littérature biomédicale (PubMed), les guides cliniques, ou les dossiers patients. BioBERT, ClinicalBERT et les modèles Stanza biomédicaux sont optimisés pour ce domaine. La fiabilité et la traçabilité des réponses sont critiques.

Éducation et tutorat

Les systèmes de QA permettent aux étudiants d’interroger des manuels, des cours, et des ressources pédagogiques en langage naturel. Le fine-tuning de BERT sur des datasets universitaires (comme démontré dans des travaux récents) améliore significativement la pertinence des réponses par rapport à un modèle généraliste.

Moteurs de recherche conversationnels

Perplexity, Google Search (avec AI Overviews), et Bing (avec Copilot) utilisent tous des architectures RAG pour transformer la recherche web en conversation. L’utilisateur pose une question, le système recherche sur le web, et génère une réponse synthétique avec des sources.

Métriques d’évaluation

Pour les systèmes RAG, les frameworks d’évaluation comme RAGAS (Retrieval Augmented Generation Assessment), TruLens et Langfuse permettent de mesurer séparément la qualité du retrieval et la qualité de la génération. C’est essentiel car une mauvaise réponse peut venir d’un mauvais retrieval (les bons documents n’ont pas été trouvés) ou d’une mauvaise génération (le LLM a mal interprété les documents).

Défis du question answering

Hallucination

Le défi majeur du QA génératif. Le modèle produit une réponse plausible mais fausse. Le RAG atténue ce problème en fournissant des sources, mais ne l’élimine pas : le modèle peut mal interpréter les documents, combiner des informations de manière erronée, ou ignorer les passages pertinents.

Raisonnement multi-hop

Les questions nécessitant de combiner des informations provenant de plusieurs passages restent difficiles. « Quel est le fondateur de l’entreprise qui a développé le modèle GPT ? » nécessite de savoir que GPT a été développé par OpenAI, puis de trouver le fondateur d’OpenAI. Les architectures RAG standard récupèrent des passages indépendamment, sans ce chaînage logique.

Savoir dire « je ne sais pas »

SQuAD 2.0 a introduit cette dimension : le système doit reconnaître quand la question n’a pas de réponse dans le contexte et s’abstenir plutôt que de générer une réponse incorrecte. En production, cette capacité est cruciale. Un système qui répond toujours, même quand il ne devrait pas, perd rapidement la confiance des utilisateurs.

Fraîcheur des connaissances

Les LLM ont une date de coupure de connaissances. Le RAG résout partiellement ce problème en injectant des documents récents, mais nécessite un pipeline d’indexation maintenu en continu pour que la base documentaire reste à jour.

QA multilingue

Les performances des systèmes de QA varient considérablement selon la langue. L’anglais est sur-représenté dans les données d’entraînement et les benchmarks. Pour le français, les modèles multilingues (XLM-RoBERTa, mBERT) ou les modèles natifs (CamemBERT) fine-tunés sur des datasets de QA français (FQuAD, PIAf) offrent les meilleures performances.

QA pour le français

FQuAD (French Question Answering Dataset) : l’équivalent français de SQuAD, avec environ 25 000 paires question-réponse sur des articles Wikipedia en français. C’est le benchmark de référence pour le QA extractif en français.

PIAf (Pour une IA Francophone) : un dataset de QA en français créé par le programme national IA francophone, avec des questions annotées par des locuteurs natifs.

CamemBERT fine-tuné sur FQuAD : le modèle recommandé pour le QA extractif en français. Plusieurs versions fine-tunées sont disponibles sur Hugging Face (ex : etalab-ia/camembert-base-squadFR-fquad-piaf).

Approche RAG en français : utilisez un modèle d’embedding multilingue (ex : sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2) pour le retrieval et un LLM supportant le français (Claude, GPT, Mistral) pour la génération.

Bonnes pratiques

Commencez par définir le scope. Votre système doit-il répondre à toutes les questions ou seulement aux questions couvertes par votre documentation ? Un scope clair évite les hallucinations et les réponses hors sujet.

Mesurez le retrieval séparément de la génération. Si votre système RAG donne de mauvaises réponses, le problème vient-il des documents récupérés (mauvais retrieval) ou de la génération du LLM ? Mesurez le context recall et la faithfulness séparément.

Implémentez une stratégie d’abstention. Le système doit pouvoir répondre « je n’ai pas trouvé cette information dans la documentation » plutôt que de halluciner. Utilisez un seuil de confiance sur le retrieval (si aucun passage ne dépasse un score de similarité minimum, ne répondez pas).

Soignez le chunking. Le découpage des documents en chunks est critique pour la qualité du retrieval. Des chunks trop petits perdent le contexte, des chunks trop gros noient l’information pertinente. Expérimentez avec des tailles de 500 à 1500 caractères et un overlap de 10 à 20%.

Citez vos sources. En production, chaque réponse doit être accompagnée des passages sources utilisés pour la générer. Cela permet à l’utilisateur de vérifier et augmente la confiance dans le système.

Évaluez sur des questions réelles. Constituez un jeu de test de 200 à 500 questions posées par de vrais utilisateurs de votre système (pas des questions inventées par les développeurs). Les questions réelles sont plus ambiguës, plus variées et plus difficiles que les questions de test synthétiques.