Gains :
- Peut expliquer ce qu'est le streaming, les types d'événements et pourquoi il est nécessaire.
- max_tokens saisit le délai d'attente et la relation de sortie longue de 128 000
- Peut faire le bon choix entre les demandes de streaming et de non-streaming en fonction de la charge de travail
Vous avez peut-être remarqué que dans une interface de chat, la réponse est « tapée » mot à mot. Il ne s’agit pas d’un épanouissement visuel ; C'est le résultat d'une technique appelée streaming et est souvent obligatoire pour une intégration LLM de qualité production. Dans cette unité, vous apprendrez ce qu'est le flux, de quels événements il se compose, sa relation avec les sorties longues et les délais d'attente, et quand utiliser le flux et quand ne pas le faire. Nous aborderons le sujet à travers les tâches réelles d'un professionnel : assistant en direct, génération de rapports longs, traitement par lots.
Qu’est-ce que le flux ?
Avec une requête sans streaming (synchrone), vous attendez que le modèle produise la réponse complète ; Lorsque la réponse est prête, elle arrive en un seul morceau. Dans une requête de streaming, le serveur envoie la réponse pièce par pièce au fur et à mesure que le modèle est généré. Techniquement, cela se fait avec des événements envoyés par le serveur (SSE — Server-Sent Events, une méthode dans laquelle le serveur envoie successivement de petits événements via une connexion ouverte).
La différence devient apparente dans l'expérience utilisateur : sur une réponse qui prend 8 secondes, l'utilisateur non-stream regarde un écran vide pendant 8 secondes ; L'utilisateur du streaming voit les premiers mots en environ 0,5 seconde et le texte commence à couler. La latence perçue (l'attente ressentie par l'utilisateur) est considérablement réduite, tandis que la durée totale reste inchangée.
Types de flux d'événements
Le flux est une séquence d'événements. Conceptuellement, un flux typique ressemble à ceci :
incident
Signification
message_start
La réponse commença ; Les informations d'en-tête telles que le modèle et l'ID sont arrivées.
content_block_start
Un bloc de contenu (par exemple du texte) a démarré
content_block_delta
Un petit morceau de texte (delta) est arrivé ; tu les collectionnes
content_block_stop
bloc terminé
message_delta
Informations de fin mises à jour telles que stop_reason et utilisation
message_stop
Répondre
Votre code combine séquentiellement des morceaux de texte dans les événements content_block_delta ; vous vous retrouvez avec exactement le même texte que la réponse non diffusée. l'utilisation (numéros de jetons) est généralement claire à la fin du flux — vous suivez les coûts une fois le flux terminé.
Astuce : La plupart des SDK officiels (Software Development Kit — bibliothèque prête à l'emploi du fournisseur) fournissent un assistant qui collecte le flux pour vous (par exemple stream.get_final_message()). Vous n'êtes pas obligé de gérer toutes les pistes manuellement ; Utilisez cette assistante si vous souhaitez obtenir le texte intégral, traiter des événements individuels mais pour une impression en direct.
Réponses longues, max_tokens et Timeout
La deuxième cause, plus technique, du streaming est le délai d'attente. Si une requête HTTP n'est pas terminée dans un certain délai, le client abandonne la connexion. Lorsque vous demandez une sortie importante au modèle (par exemple, un rapport de 40 000 jetons), l'appel sans flux peut dépasser cette limite et expirer — la demande échouera et vous devrez payer pour les jetons générés.
Les modèles modernes peuvent générer jusqu'à 128 000 jetons en une seule requête. Mais la règle générale est claire : utilisez les flux si la valeur « max_tokens » est élevée (environ au-dessus de 16 000). Le streaming maintient la connexion active et évite les délais d'attente ; Vous verrez également les progrès instantanément.
- `max_tokens` : nombre maximal de jetons de sortie que le modèle peut produire ; un plafond dur. Si une interruption se produit, stop_reason max_tokens est renvoyé.
- Fenêtre contextuelle : La fenêtre dans laquelle la somme des entrées + sorties doit tenir. max_tokens est le plafond de la sortie ; Ne mélangez pas les deux.
Attention : Lancer des requêtes sans flux avec de grands max_tokens est une erreur classique en production. Sans réponse, la connexion est interrompue, l'utilisateur voit une erreur et le coût du jeton est gaspillé. Sortie longue = flux.
Quand couler et quand pas ?
Statut
préférence
Pourquoi
Chat en direct / assistant
flux
La latence perçue diminue, l'utilisateur voit les progrès
Production de rapports/documents longs
flux
Empêche les délais d'attente, transporte des sorties importantes en toute sécurité
Classification courte (par exemple, balise d'un seul mot)
pas de flux
Le rendement est déjà faible ; complexité supplémentaire inutile
Traitement par lots
sans flux/par lots
Les résultats ne sont pas affichés instantanément ; Voir unité 7
Étape d'automatisation (en arrière-plan)
Généralement pas de flux
Vous passez le résultat à l'étape suivante, pas d'affichage en direct
Invites/modèles copiables
Le flux lui-même n'est pas une invite, mais les invites sont essentielles à la gestion de la sortie produite par le flux. Dans les productions longues et fluides, imposer la structure de face augmente à la fois la qualité et la traçabilité.
# Divisez le long rapport en sections (afin que les progrès soient visibles dans le flux) Rédigez le rapport avec les titres suivants, dans cet ordre exact. Commencez chaque titre par '## ' :## Résumé## Résultats## Recommandations## Étapes suivantes
# Donnez la longueur cible pour éviter la troncature dans les productions longues. Le texte total comptera environ 800 mots. Gardez les portions équilibrées ; Ne laissez pas une demi-phrase à la fin.
# Donnez immédiatement la première phrase à l'assistant de streaming. Donnez d’abord une réponse directe en une phrase, puis entrez dans les détails. Ainsi, l'utilisateur voit un résultat immédiat en attendant.
# Gardez la longue sortie structurée (afin qu'elle puisse être analysée plus tard) Sortez la sortie dans ces sections et marquez chaque section avec un en-tête '###' séparé afin que je puisse l'analyser par programme : ### INTRODUCTION ### CORPS ### SOURCES
Invite faible/invite forte (production longue)
# FAIBLERédigez un rapport long et détaillé sur ce sujet.
# FORTRédigez un rapport d'environ 900 mots sur ce sujet. Rubriques : ## Résumé, ## Analyse, ## Risques, ## Recommandations. Chaque titre doit comporter au maximum 3 paragraphes. Ne laissez pas une demi-phrase à la fin.
Version puissante ; Il détermine à l’avance la longueur, la structure et la qualité de finition. Au fur et à mesure que les sections arrivent dans le flux, l'utilisateur voit clairement la progression et gère lui-même la longueur contre le risque d'interruption du modèle.
Trois mini-étuis
Cas 1 — Plainte d’écran vide. L'assistant client d'une équipe de consultants répondait sans flux ; la réponse moyenne prend 7 secondes, les utilisateurs demandent « est-ce que ça gèle ? il s'est plaint. Une fois que je suis entré dans le flux, le premier mot est arrivé en environ 0,6 seconde ; La durée totale est restée la même, mais les plaintes « lentes » ont presque disparu.
Cas 2 — Rapport obsolète. Une équipe financière faisait produire un rapport trimestriel de 30 pages ; Avec max_tokens : 30 000, la demande d'absence de flux resterait bloquée dans un délai d'attente client de 60 secondes, la demande échouerait et les jetons générés seraient écrits sur la facture. Ils ont suivi le courant ; la connexion est restée active, le rapport a été livré dans son intégralité et les coûts inutiles ont été éliminés.
Cas 3 — Flux inutile. Une équipe opérationnelle qualifiait les e-mails entrants de « urgents/réguliers » ; Le résultat était un mot, mais ils utilisaient habituellement le flux. Le flux n'apportait aucun avantage dans la réponse en un seul mot, rendant le code inutilement complexe. Lorsque je suis passé au flowless, le code s'est simplifié et le comportement est resté le même. Leçon : le streaming est précieux dans la production longue/live, pas partout.
Erreurs courantes
- Ne pas utiliser de flux dans les sorties longues : délai d'attente et coût du jeton gaspillé.
- Utiliser le streaming pour produire des résultats courts : complexité inutile, aucun avantage.
- Ne pas vérifier `stop_reason` à la fin du flux : la réponse tronquée avec max_tokens est considérée comme complète.
- Fusion incorrecte des deltas : la sommation manuelle avec l'assistant du SDK produit une erreur de séquence/pièces manquantes.
- Essayer de lire « utilisation » à mi-parcours : les numéros de jetons deviennent généralement clairs à la fin ; Gardez une trace des coûts à la fin.
- Confondre streaming et réduction des coûts : le streaming améliore l'expérience et l'endurance ; Cela ne change pas le prix du jeton.
Plus profond : ruptures de flux et résilience
Le streaming est une connexion en direct ; C'est à la fois sa force et sa vulnérabilité. Si la connexion s'interrompt au milieu (fluctuation du réseau, délai d'attente du client), vous conserverez le texte que vous avez accumulé jusqu'à présent, mais la réponse sera incomplète. Un client de streaming de qualité production doit s'y préparer : il ne doit pas traiter le texte partiel comme une "réponse terminée", ni considérer la réponse comme terminée jusqu'à ce qu'il voie l'événement message_stop.
La deuxième subtilité est que le flux ne change pas le coût. Que vous receviez une réponse avec ou sans streaming n'affecte pas le prix du jeton ; le flux ne fait qu’améliorer l’expérience et l’endurance. Alors « si nous passons au streaming, seront-ils moins chers ? » La réponse à la question est non : pour le coût, regardez la 5ème et la 6ème unité (sélection du modèle, cache).
Le troisième point est de trouver un équilibre pratique : avec les assistants en direct, l'arrivée rapide du premier mot (délai perçu) est très appréciée ; Par conséquent, demander au modèle de saisir directement la réponse et de donner d'abord un résultat court (via l'invite système dans la 4ème unité) multiplie les avantages du flux. Si l’utilisateur voit quelque chose de significatif dans la première seconde, il attend patiemment le détail qui suit. En revanche, le flux n'a aucune contribution aux tâches qui s'exécutent en arrière-plan, dont la sortie passe à l'étape d'automatisation suivante ; Le seul critère est que le travail soit effectué correctement et complètement.
En résumé
Le streaming récupère la réponse pièce par pièce, réduisant ainsi la latence perçue et évitant les délais d'attente sur les débits importants. Presque obligatoire pour l'assistant en direct et la production de documents longs ; Ce n'est pas nécessaire pour un travail court/en arrière-plan. Dans les productions longues, imposer la structure et la longueur de face avec une invite augmente à la fois la qualité et la traçabilité ; Lorsque le flux est terminé, stop_reason et usage sont définitivement vérifiés.
Tâche de candidature
Choisissez deux scénarios : un en direct/long (par exemple, rapport au client), un court/en arrière-plan (par exemple, marquage). (1) Décidez et justifiez si vous utiliserez le flux pour chacun. (2) Écrivez une invite qui impose la structure du script long (titres + longueur cible). (3) Déterminez les valeurs max_tokens. (4) Répertoriez les vérifications que vous effectuerez avec stop_reason et l'utilisation à la fin du flux.
liste de contrôle
- [ ] Je peux expliquer ce qu'est le streaming et comment il réduit la latence perçue.
- [ ] J'ai compris les types d'événements de base du flux et de la jonction delta.
- [ ] Je connais la nécessité de diffuser avec de grands max_tokens et la relation de délai d'attente.
- [ ] Je peux décider dans quelle charge de travail j'utiliserai le streaming et dans laquelle je ne l'utiliserai pas.
- [ ] Je peux vérifier stop_reason et l'utilisation à la fin du flux.