Streaming

Quand vous construisez des interfaces de chat, les utilisateurs s’attendent à voir les réponses apparaître immédiatement — pas à fixer un indicateur de chargement pendant 10 à 30 secondes en attendant la réponse complète. Cette attente est le temps réel de génération d’une longue réponse ; on ne peut pas la supprimer, mais on peut la rendre invisible. La fonction converse_stream résout le problème en envoyant le texte au fur et à mesure de sa génération.

Comment fonctionne le streaming

Au lieu d’attendre la génération complète de la réponse, le streaming renvoie des morceaux de texte dès qu’ils sont disponibles. Quand vous appelez converse_stream, vous recevez immédiatement un objet de flux (stream) qui produit des événements à mesure que le modèle génère du texte — la latence perçue tombe au temps du premier fragment, quelques centaines de millisecondes, quelle que soit la longueur totale de la réponse.

Implémentation de base

Le passage au streaming ne change presque rien à l’appel :

messages = []
add_user_message(messages, "Écrivez une phrase décrivant une base de données fictive")
response = client.converse_stream(messages=messages, modelId=model_id)

for event in response["stream"]:
    print(event)

Mêmes messages, même identifiant de modèle — seule la méthode change, et la nature du retour : response["stream"] est un itérateur d’événements. Ce code les affiche bruts ; exécutez-le une fois, c’est la meilleure façon de voir le protocole défiler en vrai avant de l’apprivoiser.

Types d’événements du flux

Le flux produit plusieurs types d’événements dans un ordre prévisible :

1. messageStart : début du message
2. Plusieurs contentBlockDelta : les morceaux de texte généré
3. contentBlockStop : fin du bloc de contenu
4. messageStop : fin du message
5. metadata : informations sur la génération

La structure raconte le message en train de naître : ouverture, fragments, clôtures, puis les métadonnées — dont le décompte de tokens, utile pour le suivi des coûts. Pour la génération de texte basique, seuls les événements contentBlockDelta vous intéressent : ce sont eux qui contiennent les morceaux de texte à afficher.

Extraire le texte

D’où le filtre classique, qui affiche en direct tout en accumulant le texte complet :

text = ""
for event in response["stream"]:
    if "contentBlockDelta" in event:
        chunk = event["contentBlockDelta"]["delta"]["text"]
        print(chunk, end="")
        text += chunk

print("\n\nMessage complet :\n" + text)

Deux gestes à noter. Le paramètre end="" supprime le saut de ligne automatique de print, ce qui fait apparaître le texte de façon fluide, mot après mot — l’effet machine à écrire des interfaces de chat. Et l’accumulation dans text n’est pas décorative : c’est ce message complet qu’il faudra ajouter à l’historique de conversation pour le tour suivant — streamer l’affichage ne dispense pas de conserver la réponse.

Applications pratiques

Dans une vraie application, le print cède la place à un relais : le streaming décrit ici relie votre serveur à Bedrock, et il reste à transporter les fragments jusqu’à l’utilisateur. Concrètement, vous envoyez chaque chunk au frontend via WebSockets ou Server-Sent Events, vous mettez à jour l’interface en temps réel, vous stockez le message complet une fois le streaming terminé, et vous gérez les erreurs potentielles en cours de flux — une connexion peut tomber au milieu d’une génération, et l’interface doit le dire proprement plutôt que de rester figée.

Le streaming transforme l’expérience utilisateur : au lieu de « soumettre et attendre », c’est « soumettre et voir la réponse apparaître progressivement » — la différence entre une application qui semble lente et une application qui semble vivante, pour le même temps de génération.

Points clés à retenir

• converse_stream = même appel que converse, mais retour en flux d’événements
• Ordre prévisible : messageStart → contentBlockDelta (×n) → contentBlockStop → messageStop → metadata
• Seuls les contentBlockDelta portent le texte ; metadata donne les tokens pour le suivi des coûts
• Accumulez le texte pendant l’affichage : l’historique de conversation a besoin du message complet
• En production : relayez les chunks via WebSockets/SSE et gérez les coupures en cours de flux