Comment rendre votre application d’IA plus rapide et plus interactive avec le streaming de réponses

Dans mes derniers articles, j’ai beaucoup parlé de la mise en cache rapide ainsi que de la mise en cache en général, et de la façon dont elle peut améliorer votre application d’IA en termes de coût et de latence. Cependant, même pour une application d’IA entièrement optimisée, la génération des réponses prend parfois un certain temps et nous ne pouvons tout simplement rien y faire. Lorsque nous demandons des résultats importants au modèle ou que nous avons besoin d’un raisonnement ou d’une réflexion approfondie, le modèle mettra naturellement plus de temps à répondre. Aussi raisonnable que cela puisse paraître, attendre plus longtemps pour recevoir une réponse peut être frustrant pour l’utilisateur et réduire son expérience utilisateur globale en utilisant une application d’IA. Heureusement, un moyen simple et direct d’améliorer ce problème consiste à diffusion en continu des réponses.

Le streaming signifie obtenir la réponse du modèle progressivement, petit à petit, telle qu’elle est générée, plutôt que d’attendre que la réponse entière soit générée puis de l’afficher à l’utilisateur. Normalement (sans streaming), on envoie une requête à l’API du modèle, on attend que le modèle génère la réponse, et une fois la réponse terminée, on la récupère depuis l’API en une seule étape. Cependant, avec le streaming, l’API renvoie des sorties partielles pendant que la réponse est générée. Il s’agit d’un concept plutôt familier car la plupart des applications d’IA destinées aux utilisateurs comme ChatGPT, dès leur première apparition, ont utilisé le streaming pour montrer leurs réponses à leurs utilisateurs. Mais au-delà de ChatGPT et des LLM, le streaming est essentiellement utilisé partout sur le web et dans les applications modernes, comme par exemple dans les notifications en direct, les jeux multijoueurs ou les flux d’actualités en direct. Dans cet article, nous allons explorer plus en détail comment intégrer le streaming dans nos propres requêtes pour modéliser les API et obtenir un effet similaire sur les applications d’IA personnalisées.

Il existe plusieurs mécanismes différents pour implémenter le concept de streaming dans une application. Néanmoins, pour les applications d’IA, il existe deux types de streaming largement utilisés. Plus précisément, il s’agit de :

• Streaming HTTP sur les événements envoyés par le serveur (SSE) : Il s’agit d’un type de streaming unidirectionnel relativement simple, permettant uniquement une communication en direct du serveur au client.
• Streaming avec WebSockets : Il s’agit d’un type de streaming plus avancé et plus complexe, permettant une communication bidirectionnelle en direct entre le serveur et le client.

Dans le contexte des applications d’IA, le streaming HTTP sur SSE peut prendre en charge des applications d’IA simples dans lesquelles il suffit de diffuser la réponse du modèle pour des raisons de latence et d’UX. Néanmoins, à mesure que nous allons au-delà des simples modèles de requête-réponse vers des configurations plus avancées, les WebSockets deviennent particulièrement utiles car ils permettent une communication bidirectionnelle en direct entre notre application et l’API du modèle. Par exemple, dans les assistants de code, les systèmes multi-agents ou les workflows d’appel d’outils, le client peut avoir besoin d’envoyer des mises à jour intermédiaires, des interactions utilisateur ou des commentaires au serveur pendant que le modèle génère encore une réponse. Cependant, pour la plupart des applications d’IA simples où nous avons juste besoin du modèle pour fournir une réponse, les WebSockets sont généralement excessifs et SSE est suffisant.

Dans le reste de cet article, nous examinerons de plus près le streaming pour des applications d’IA simples utilisant le streaming HTTP sur SSE.

. . .

Qu’en est-il du streaming HTTP sur SSE ?

Diffusion HTTP via Événements envoyés par le serveur (SSE) est basé sur Diffusion HTTP.

. . .

Le streaming HTTP signifie que le serveur peut envoyer tout ce qu’il doit envoyer en partie, plutôt qu’en une seule fois. Ceci est obtenu grâce au serveur qui ne met pas fin à la connexion au client après l’envoi d’une réponse, mais la laisse plutôt ouverte et envoie immédiatement au client tout événement supplémentaire qui se produit.

Par exemple, au lieu d’obtenir la réponse en un seul morceau :

Hello world!

nous pourrions l’obtenir en plusieurs parties en utilisant le streaming HTTP brut :

Hello

World

!

Si nous devions implémenter le streaming HTTP à partir de zéro, nous devrions tout gérer nous-mêmes, y compris l’analyse du texte diffusé, la gestion des erreurs éventuelles et les reconnexions au serveur. Dans notre exemple, en utilisant le streaming HTTP brut, nous devrons expliquer au client que « Bonjour tout le monde ! » est un événement conceptuellement, et tout ce qui suit serait un événement distinct. Heureusement, il existe plusieurs frameworks et wrappers qui simplifient le streaming HTTP, dont l’un est Streaming HTTP sur les événements envoyés par le serveur (SSE).

. . .

Donc, Événements envoyés par le serveur (SSE) fournir un moyen standardisé d’implémenter le streaming HTTP en structurant les sorties du serveur en événements clairement définis. Cette structure facilite grandement l’analyse et le traitement des réponses diffusées côté client.

Chaque événement comprend généralement :

• un id
• un event taper
• un data charge utile

ou plus exactement..

id: <unique-event-id>
event: <event-type>
data: <payload>

Notre exemple utilisant SSE pourrait ressembler à ceci :

id: 1
event: message
data: Hello world!

Mais qu’est-ce qu’un événement ? Tout peut être considéré comme un événement : un seul mot, une phrase ou des milliers de mots. Ce qui est réellement considéré comme un événement dans notre implémentation particulière est défini par la configuration de l’API ou du serveur auquel nous sommes connectés.

En plus de cela, SSE offre diverses autres commodités, comme la reconnexion automatique au serveur si la connexion est interrompue. Une autre chose est que les messages de flux entrants sont clairement étiquetés comme text/event-streampermettant au client de les gérer de manière appropriée et d’éviter les erreurs.

. . .

Retroussez vos manches

API Frontier LLM comme OpenAI L’API ou l’API Claude prennent en charge nativement le streaming HTTP sur SSE. De cette manière, intégrer le streaming dans vos requêtes devient relativement simple, car cela peut être réalisé en modifiant un paramètre dans la requête (par exemple, activer un stream=true paramètre).

Une fois le streaming activé, l’API n’attend plus la réponse complète avant de répondre. Au lieu de cela, il renvoie de petites parties de la sortie du modèle au fur et à mesure de leur génération. Côté client, nous pouvons parcourir ces morceaux et les afficher progressivement à l’utilisateur, créant ainsi l’effet de frappe ChatGPT familier.

Mais faisons un exemple minimal de cela en utilisant, comme d’habitude, l’API d’OpenAI :

import time
from openai import OpenAI

client = OpenAI(api_key="your_api_key")

stream = client.responses.create(
    model="gpt-4.1-mini",
    input="Explain response streaming in 3 short paragraphs.",
    stream=True,
)

full_text = ""

for event in stream:
    # only print text delta as text parts arrive
    if event.type == "response.output_text.delta":
        print(event.delta, end="", flush=True)
        full_text += event.delta

print("\n\nFinal collected response:")
print(full_text)

Dans cet exemple, au lieu de recevoir une seule réponse complète, nous parcourons un flux d’événements et imprimons chaque fragment de texte au fur et à mesure qu’il arrive. En même temps, nous stockons également les morceaux dans une réponse complète. full_text à utiliser plus tard si nous le souhaitons.

. . .

Alors, devrais-je simplement appliquer streaming = True à chaque requête ?

La réponse courte est non. Aussi utile soit-il, avec un grand potentiel d’amélioration significative de l’expérience utilisateur, le streaming n’est pas une solution universelle pour les applications d’IA, et nous devons user de notre discrétion pour évaluer où il doit être mis en œuvre et où non.

Plus précisément, l’ajout de streaming dans une application d’IA est très efficace dans les configurations où l’on attend des réponses longues, et nous valorisons avant tout l’expérience utilisateur et la réactivité de l’application. Un tel cas serait celui des chatbots destinés aux consommateurs.

D’un autre côté, pour les applications simples pour lesquelles nous nous attendons à ce que les réponses fournies soient courtes, l’ajout du streaming n’est pas susceptible d’apporter des gains significatifs à l’expérience utilisateur et n’a pas beaucoup de sens. De plus, le streaming n’a de sens que dans les cas où la sortie du modèle est en texte libre et non structurée (par exemple, des fichiers JSON).

Plus important encore, l’inconvénient majeur du streaming est que nous ne sommes pas en mesure d’examiner la réponse complète avant de l’afficher à l’utilisateur. N’oubliez pas que les LLM génèrent les jetons un par un et que la signification de la réponse se forme au fur et à mesure que la réponse est générée, pas à l’avance. Si nous faisons 100 requêtes à un LLM avec exactement la même entrée, nous obtiendrons 100 réponses différentes. Autrement dit, personne ne sait avant que les réponses ne soient terminées ce qu’il va dire. En conséquence, lorsque le streaming est activé, il est beaucoup plus difficile d’examiner la sortie du modèle avant de l’afficher à l’utilisateur et d’appliquer des garanties sur le contenu produit. Nous pouvons toujours essayer d’évaluer les achèvements partiels, mais encore une fois, les achèvements partiels sont plus difficiles à évaluer, car nous devons deviner où va le modèle. Le fait d’ajouter que cette évaluation doit être effectuée en temps réel et non pas une seule fois, mais de manière récursive sur différentes réponses partielles du modèle, rend ce processus encore plus difficile. En pratique, dans de tels cas, la validation est exécutée sur l’intégralité de la sortie une fois la réponse terminée. Néanmoins, le problème est qu’à ce stade, il est peut-être déjà trop tard, car nous avons peut-être déjà montré à l’utilisateur un contenu inapproprié qui ne passe pas nos validations.

. . .

Dans mon esprit

Le streaming est une fonctionnalité qui n’a pas d’impact réel sur les capacités de l’application IA, ni sur le coût et la latence associés. Néanmoins, cela peut avoir un impact important sur la façon dont l’utilisateur perçoit et expérimente une application d’IA. Le streaming rend les systèmes d’IA plus rapides, plus réactifs et plus interactifs, même lorsque le temps nécessaire pour générer la réponse complète reste exactement le même. Cela dit, le streaming n’est pas une solution miracle. Différentes applications et contextes peuvent bénéficier plus ou moins de l’introduction du streaming. Comme de nombreuses décisions en matière d’ingénierie de l’IA, il s’agit moins de ce qui est possible que de ce qui a du sens pour votre cas d’utilisation spécifique.

. . .

Si tu es arrivé jusqu’ici, les pialgorithmes pourraient vous être utiles — une plateforme que nous avons créée qui aide les équipes à gérer en toute sécurité les connaissances organisationnelles en un seul endroit.

. . .

Vous avez adoré cet article ? Rejoignez-moi sur 💌Sous-pile et 💼LinkedIn

. . .

Toutes les images sont de l’auteur, sauf mention contraire.