Accueil › Glossaire › Single-turn

Single-turn

Le single-turn (ou tour unique) désigne un mode d’interaction avec un LLM dans lequel l’échange se limite à un seul cycle : l’utilisateur envoie un prompt, le modèle génère une réponse, et l’interaction est terminée. Aucun suivi conversationnel n’est attendu ni nécessaire.

Qu’est-ce qu’une interaction single-turn

Dans une interaction single-turn, tout le contexte nécessaire est contenu dans une seule requête. Le user prompt fournit l’instruction, les données, les contraintes et le format attendu en un seul message. Le modèle produit une réponse, et c’est fini. Pas de question de suivi, pas de raffinement itératif, pas d’historique de conversation à gérer.

Exemple typique : vous envoyez un e-mail à classifier au LLM avec l’instruction « Classifie cet e-mail comme spam, promotionnel, ou important. Réponds en un seul mot. » Le modèle répond « important ». L’interaction est complète. Vous passez à l’e-mail suivant avec une nouvelle requête indépendante.

{
  "model": "claude-sonnet-4-6",
  "max_tokens": 10,
  "system": "Vous êtes un classificateur d'e-mails. Répondez uniquement par : spam, promotionnel, ou important.",
  "messages": [
    {
      "role": "user",
      "content": "Classifiez cet e-mail :nnObjet : Réunion Q2 demain à 14hnCorps : Bonjour, rappel pour notre réunion trimestrielle demain. Ordre du jour en PJ."
    }
  ]
}

Notez l’absence d’historique : un seul message user, pas de message assistant précédent. C’est la signature d’une interaction single-turn.

Single-turn vs multi-turn

Cas d’usage du single-turn

Classification et catégorisation

Le single-turn est le mode naturel pour la classification de texte : sentiment, catégorie, intention, priorité, langue. Chaque document est traité indépendamment, la réponse est un label ou un score, et il n’y a aucun bénéfice contextuel à tirer d’un échange précédent. Vous pouvez traiter des milliers de documents en parallèle, chacun dans sa propre requête single-turn.

Extraction d’information

Extraire des entités nommées (noms, dates, montants), des métadonnées structurées, ou des points clés d’un document se fait en single-turn. Le prompt fournit le document et les instructions d’extraction, le modèle retourne les données structurées (typiquement en JSON). Chaque document est un cas indépendant.

Traduction

La traduction de texte est l’un des usages single-turn les plus courants. Le prompt contient le texte source et la langue cible, la réponse est la traduction. Pas de contexte conversationnel nécessaire (sauf pour la traduction de dialogues où le contexte inter-répliques peut aider, mais c’est alors le document entier qui est fourni en une seule requête).

Résumé

Résumer un document, un article, une transcription de réunion est une tâche single-turn typique. Le document complet est fourni dans le user prompt avec les instructions de résumé (longueur, format, public cible). La réponse est le résumé. Si le document est trop long pour une seule requête, on peut le découper en segments traités séparément (map), puis résumer les résumés (reduce), mais chaque étape reste un appel single-turn.

Génération ponctuelle

Rédiger un e-mail, générer une description produit, écrire une requête SQL, formater un bloc de code : autant de tâches qui se prêtent au single-turn quand tous les paramètres sont connus d’avance. Le prompt décrit précisément ce qu’il faut produire, et le modèle s’exécute en un tour.

Pipelines batch et automatisés

Le single-turn est le mode d’interaction par défaut des pipelines automatisés. Les Batch API d’Anthropic et d’OpenAI sont conçues pour le single-turn : vous soumettez des milliers de requêtes indépendantes, et elles sont traitées en parallèle avec une remise (typiquement 50 % chez les deux providers). Le batch processing n’a de sens qu’en single-turn, car chaque requête doit être indépendante.

Implémentation technique

Conception du prompt single-turn

En single-turn, le prompt doit être autosuffisant. Il n’y a pas de tour précédent pour clarifier une ambiguïté. Tout ce dont le modèle a besoin doit être dans la requête : l’instruction précise, le contexte complet, le format de sortie attendu, et les contraintes. C’est paradoxalement plus exigeant que le multi-turn en termes de prompt engineering, car vous n’avez pas la possibilité de corriger ou de préciser au tour suivant.

Structure recommandée pour un prompt single-turn :

[System prompt]
Rôle + contraintes + format de sortie

[User prompt]
1. Instruction claire (quoi faire)
2. Contexte / données à traiter
3. Format attendu + contraintes spécifiques
4. Exemple de sortie (optionnel, few-shot)

Sortie structurée

Le single-turn se combine particulièrement bien avec les structured outputs et le JSON mode. Quand vous traitez des centaines ou des milliers de requêtes en batch, vous avez besoin de sorties parsables automatiquement. Le prefilling de l’assistant message (commencer la réponse par {) ou le JSON mode natif garantissent un format exploitable par votre pipeline.

Parallélisation

L’avantage majeur du single-turn en production est la parallélisation. Chaque requête étant indépendante, vous pouvez les envoyer simultanément, limitées uniquement par les rate limits de l’API. Un pipeline qui traite 10 000 documents en single-turn peut les envoyer en parallèle (ou via Batch API) et obtenir tous les résultats en quelques minutes, là où un traitement séquentiel prendrait des heures.

import asyncio
import anthropic

client = anthropic.AsyncAnthropic()

async def classify_email(email_text):
    response = await client.messages.create(
        model="claude-haiku-4-5",  # Modèle rapide et économique
        max_tokens=20,
        system="Classifiez l'e-mail comme : spam, promo, ou important. Un seul mot.",
        messages=[{"role": "user", "content": email_text}]
    )
    return response.content[0].text.strip()

async def process_batch(emails):
    tasks = [classify_email(email) for email in emails]
    return await asyncio.gather(*tasks)

# Traiter 1000 e-mails en parallèle
results = asyncio.run(process_batch(email_list))

Choix du modèle pour le single-turn

En single-turn, le choix du modèle est guidé par le rapport coût/performance sur la tâche spécifique. Pour la classification et l’extraction simples, un modèle compact comme Claude Haiku 4.5 (~$1/$5 par M tokens input/output) ou Gemini 3.1 Flash-Lite (~$0,25/$1,50) offre un excellent rapport qualité-prix. Réservez les modèles frontier (Claude Opus 4.6, GPT-5.4) aux tâches complexes (raisonnement, rédaction sophistiquée, analyse multi-étapes) où leur supériorité justifie le surcoût.

Prompt caching en single-turn

Le prompt caching est souvent associé au multi-turn, mais il est aussi pertinent en single-turn. Si vous envoyez des centaines de requêtes avec le même system prompt (par exemple, un classificateur qui traite un flux d’e-mails avec les mêmes instructions), le system prompt peut être caché. Chez Anthropic, le cache persiste pendant 5 minutes (ou 1 heure avec le cache étendu). Si vos requêtes arrivent dans cet intervalle, le system prompt n’est traité qu’une fois et les requêtes suivantes bénéficient du cache read (environ 10 % du coût standard).

Pour maximiser le caching en single-turn batch, regroupez vos requêtes par type (même system prompt) et envoyez-les en rafale plutôt qu’espacées dans le temps. Un system prompt de 2 000 tokens caché sur 10 000 requêtes économise environ $0,09 sur Claude Opus 4.6 (par rapport au re-traitement complet). C’est modeste sur le system prompt seul, mais si vous incluez du contexte de référence (catalogue produit, instructions détaillées), les économies deviennent significatives.

Évaluation et itération

L’avantage du single-turn pour l’évaluation est sa reproductibilité. Chaque requête est indépendante, ce qui rend les tests A/B directs : soumettez le même jeu de données à deux prompts différents (ou deux modèles) et comparez les résultats. Pas de variable confondante liée à l’historique de conversation.

Les métriques d’évaluation single-turn sont bien établies. Pour la classification : précision, rappel, F1-score. Pour l’extraction : exact match, partial match, F1 sur les entités. Pour la génération de texte : évaluations humaines, LLM-as-judge, scores ROUGE/BERTScore. Pour les sorties structurées : taux de parsing réussi (le JSON est-il valide ?), conformité au schéma attendu.

L’itération sur un prompt single-turn suit un cycle classique : définir un jeu de test (50-200 exemples avec des réponses attendues), mesurer la performance du prompt actuel, modifier le prompt, re-mesurer, et comparer. Ce cycle est beaucoup plus rapide qu’en multi-turn, où l’évaluation doit couvrir des scénarios conversationnels entiers.

Single-turn et RAG

Les pipelines RAG sont souvent implémentés en single-turn. L’utilisateur pose une question, le retriever récupère les documents pertinents, et une seule requête est envoyée au LLM avec la question + les documents comme contexte. La réponse est générée en un tour. Si l’utilisateur pose une question de suivi, c’est un nouveau cycle RAG complet (nouvelle recherche, nouvelle requête) plutôt qu’une continuation de l’historique.

Cette approche « RAG stateless » a l’avantage de la simplicité et de la cohérence : chaque réponse est basée sur les documents les plus pertinents pour la question spécifique, pas sur un historique qui pourrait contenir des documents obsolètes. L’inconvénient est la perte de contexte conversationnel : si l’utilisateur dit « Et les tarifs ? » après avoir demandé les fonctionnalités d’un produit, le système RAG doit ré-inférer que la question porte sur le même produit.

Les systèmes RAG avancés combinent les deux approches : single-turn pour chaque cycle de retrieval+génération, mais avec un mécanisme léger de mémoire conversationnelle (reformulation de la requête en intégrant le contexte de la question précédente) pour maintenir la cohérence.

Single-turn en pratique : exemples concrets

Pour illustrer la diversité des applications single-turn, voici des exemples d’utilisation en production :

Dans chacun de ces cas, les requêtes sont indépendantes les unes des autres. Un commentaire n’a aucun rapport avec le suivant. Un produit n’a aucun lien contextuel avec le précédent. C’est cette indépendance qui rend le single-turn idéal : chaque requête est auto-contenue, parallélisable, et son coût est fixe et prévisible.

Le choix du modèle a un impact direct sur le budget. Pour la modération de contenu à 100K requêtes/jour avec un prompt moyen de 500 tokens input et 50 tokens output, le coût quotidien varie de $2,75 sur Claude Haiku 4.5 à $15 sur Claude Opus 4.6. Multiplié par 30 jours, l’écart est considérable. Testez toujours sur un échantillon pour vérifier si le modèle compact atteint la qualité requise avant de choisir un modèle plus cher.

Limites du single-turn

Le single-turn ne convient pas à toutes les situations. Les tâches itératives (rédaction avec allers-retours, débogage de code, exploration d’idées) nécessitent du multi-turn. Les interactions ambiguës où l’utilisateur a besoin de clarifier sa demande sont mal servies par le single-turn. Et les tâches complexes qui bénéficient d’une décomposition en étapes interactives (analyse juridique, diagnostic médical, résolution de problèmes ouverts) perdent en qualité quand elles sont compressées en un seul tour.

Le single-turn exige aussi un prompt engineering plus rigoureux. En multi-turn, vous pouvez corriger une réponse insatisfaisante au tour suivant. En single-turn, si le prompt est ambigu, la réponse sera de mauvaise qualité et il faut relancer une nouvelle requête entière. Le coût d’un mauvais prompt est plus immédiat.

Verdict

Le single-turn est le mode d’interaction le plus sous-estimé dans l’écosystème LLM. Tandis que l’attention se porte sur les chatbots et les agents multi-turn, la majorité des applications LLM en production (classification, extraction, traduction, génération batch) fonctionnent en single-turn. C’est le mode qui offre le coût le plus prévisible, la parallélisation la plus facile, et l’implémentation la plus simple. Si votre tâche peut être résolue en un seul tour, ne la compliquez pas avec du multi-turn. Investissez plutôt dans la qualité de votre prompt unique et dans le choix du modèle optimal pour votre cas d’usage.