Gains :
- Détermine à quelles charges de travail le traitement par lots est adapté
- Comprend le compromis coût/latence entre le traitement synchrone, asynchrone et par lots
- Conçoit un flux de travail par lots robuste qui fait correspondre custom_id aux résultats
La plupart des intégrations LLM se concentrent sur des scénarios « en direct » dans lesquels un utilisateur attend une réponse devant un écran. Mais la majorité des charges de travail professionnelles ne sont pas réellement réelles : marquer des milliers de documents du jour au lendemain, résumer un ensemble de données complet, classer des enregistrements d'appels entiers dans les archives. Dans ces domaines, personne n’attend une réponse instantanée ; L’important est de terminer le travail à moindre coût et de manière fiable. Batch est exactement destiné à ces charges de travail. Dans cette unité, vous découvrirez la différence entre le traitement synchrone, asynchrone et par lots, lorsque le traitement par lots est le bon choix, et un flux robuste qui correspond en toute confiance à custom_id et aux résultats.
Trois modes de fonctionnement
mode
Comment ça marche
retard
Coût typique
emploi convenable
synchrone
Vous faites une demande et attendez la réponse
secondes
Norme
Chat en direct, assistant instantané
asynchrone
Vous mettez le travail en file d'attente et êtes averti lorsqu'il est terminé.
Secondes-minutes
Norme
Tâches en arrière-plan, étapes d'automatisation
Lot
Envoie des milliers de requêtes dans un seul package, puis obtient les résultats
Minutes-heures
Généralement à prix réduit
Travaux à volume élevé et tolérants aux retards
Le traitement par lots est le suivant : vous envoyez des centaines/des milliers de requêtes en un seul « travail » au fournisseur ; Le fournisseur les traite à son rythme et renvoie tous les résultats en masse une fois terminés. En retour, vous obtenez deux choses : (1) un coût unitaire généralement inférieur, (2) la possibilité de déplacer un volume élevé sans avoir à gérer les limites de vitesse. Le prix est que les résultats ne viennent pas instantanément, mais après un certain temps.
Quand procéder par lots, quand pas ?
La décision se résume à une seule question : l’utilisateur attend-il le résultat maintenant ?
- Non, je peux le retenir → candidat par lots. Marquage de nuit, synthèse par lots, classification des archives, enrichissement des données, exécution d'évaluation (eval).
- Oui, en attente sur l'écran → synchronisation. Chat en direct, conseils instantanés, aide pour remplir les formulaires.
Astuce : Deux modes peuvent coexister dans un même produit. L'utilisateur travaille de manière synchrone dans le chat en direct ; La nuit, vous confiez toutes les conversations de la journée au lot pour analyse qualité. Séparer le « besoin vital » du « besoin collectif » est la première décision de l’architecture.
Anatomie d’un flux de lots robuste
La règle technique la plus importante du traitement par lots est la correspondance des résultats.
- Donnez à chaque requête un « custom_id » unique. Il s'agit de votre identifiant généré qui identifie la demande (par exemple, facture-2026-07-18-000431).
- Soumettez le travail. Toutes les demandes sont regroupées dans un seul paquet ; chacun avec son propre custom_id.
- Sondez la situation. Vous demandez le statut à intervalles réguliers jusqu'à ce que le travail soit « terminé ».
- Faites correspondre les résultats avec `custom_id`. Les résultats peuvent être renvoyés dans un ordre différent de celui de soumission ; donc ne faites jamais correspondre par position mais par le custom_id que porte chaque résultat.
- Vérifiez le type de chaque résultat. Une demande peut réussir, une autre peut échouer, une autre peut expirer. Processus basé sur le succès/l’échec.
{ "requests": [ { "custom_id": "invoice-000431", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Classer la facture. Renvoie JSON uniquement.", "messages": [{ "role": "user", "content": "{{invoice_text}}" }] } }, { "custom_id": "invoice-000432", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Classifier la facture. Renvoie JSON uniquement.", "messages": [{ "role": "user", "content": "{{invoice_text_2}}" }] } } ]}
Attention : La correspondance des résultats en fonction de l'ordre de soumission est l'erreur numéro un dans le traitement par lots. La file d'attente n'est pas conservée. Sans custom_id, vous ne pouvez pas savoir avec certitude quel résultat appartient à quel document : une mauvaise correspondance conduit silencieusement à des données erronées.
Modèles copiables
# règle de génération custom_id (unique et traçable)Format : <isture>-<date>-<sequence>. Exemple : request-20260718-000431Règle : ne jamais répéter au travail ; Intégrez-y l’ID de l’enregistrement de ressource.
# Fiche de travail par lots (modèle de planification)Nom du travail : ..............Nombre d'enregistrements : ..............Modèle : ............. (tâche simple → modèle rapide)Max_tokens par requête : ..............Tolérance du délai de livraison prévu : ......... heuresClé de correspondance des résultats : custom_idEn cas d'erreur : nouvelle tentative / file d'attente / rapport
# Invite de requête unique par lots (courte et schématique)Classez ce document. Renvoyez simplement ce JSON en commentant :{"category":"...","urgency":"low|medium|high"}Document : """{{document}}"""
# Pseudo-code de traitement des résultats pour chaque résultat : if result.status == "success": record = find(custom_id) save(record, result.output) sinon : add_to_fail(custom_id, result.error) # puis réessayez
Invite faible/Invite forte (conception de tâches par lots)
# FAIBLE (conception fragile)Envoyez 10 000 documents dans l'ordre avec le modèle fort, enregistrez les résultats renvoyés dans l'ordre d'arrivée.
# FORT (conception durable) Envoyez 10 000 documents en un seul lot avec un modèle rapide. Attribuez à chaque document un custom_id unique contenant l'ID de l'enregistrement source. Faites correspondre les résultats avec le custom_id ; mettez en file d'attente ceux qui ont échoué et réessayez. Exécutez dans la fenêtre de nuit ; Tolérance de livraison 6 heures.
Version puissante ; Il prédéfinit la sélection du modèle, la clé de correspondance, la gestion des erreurs et le timing. C’est la différence dans le traitement sécurisé de dizaines de milliers d’enregistrements.
Trois mini-étuis
Cas 1 — Marquage de nuit. Une équipe de commerce électronique trierait 200 000 avis sur des produits en étiquettes de sentiment. Le streaming synchrone en direct était soumis à des limites de vitesse et était coûteux. Ils ont réalisé le travail dans la nuit en lot avec un modèle rapide ; Le coût unitaire a baissé, l'ensemble était prêt le matin et il n'y a eu aucun problème de limitation de vitesse.
Cas 2 — Confusion des commandes. Une équipe de recherche a extrait 5 000 articles, mais a consigné les résultats dans des fichiers dans l’ordre de leur arrivée. Étant donné que les résultats ont été renvoyés dans un ordre différent, environ 900 des 5 000 résumés étaient liés au mauvais article. Ils l'ont remappé sur custom_id ; problème résolu et cette expérience est devenue une règle permanente : "Toujours custom_id par lots."
Cas 3 — Veille en direct dans un mauvais mode. Une équipe d'assistance a tenté de donner par lots les réponses en direct que l'utilisateur attendait à l'écran ; Les utilisateurs ont abandonné car les résultats sont arrivés quelques minutes plus tard. Ils ont replacé le travail en direct vers la synchronisation, ne laissant que l'analyse de qualité nocturne dans le lot. Leçon : le batch n'est pas destiné à la veille en direct.
Erreurs courantes
- Résultats de correspondance par position : l'ordre n'est pas conservé ; Utilisez custom_id.
- Transfert d'une tâche en direct vers un lot : l'utilisateur ne peut pas attendre plusieurs minutes ; le lot est destiné aux travaux tolérants aux délais.
- Ne pas gérer les cas d'erreur : certaines requêtes peuvent renvoyer un échec/expiré ; Mettez-le dans une file d'attente séparée et réessayez.
- Fort réflexe d'utilisation du modèle en batch : Modèle rapide + batch est la combinaison la moins chère dans les travaux simples.
- Ne pas rendre custom_id traçable : si aucun enregistrement source n'est intégré dans l'ID, il devient difficile de lier le résultat.
- Oublier d'examiner la situation : Attendre des résultats avant que le travail ne soit terminé ; Vérifiez l'état d'achèvement.
Plus profond : surveillance des lots et gestion des défaillances partielles
L'aspect le plus mature du traitement par lots est qu'il nécessite un état d'esprit différent de celui des appels individuels : un travail par lots est un « processus » et non un « événement ». Il est fragile de supposer que des dizaines de milliers de demandes aboutiront toutes ; Une conception réaliste accepte dès le départ un échec partiel. Le statut de chaque résultat peut être différent : réussi, échoué (par exemple, saisie invalide), annulé ou expiré. Un flux robuste traite l'état de chaque résultat séparément au fur et à mesure qu'il le parcourt, place les échecs dans une « file d'attente de nouvelles tentatives » distincte et exécute cette file d'attente séparément.
La deuxième pratique consiste à concevoir en fonction de l'idempotence (c'est-à-dire qu'exécuter deux fois le même travail ne cause aucun dommage). Si un lot est interrompu et que vous le redémarrez, vous ne devez pas retraiter et écrire deux fois les enregistrements déjà traités. La liaison du custom_id à votre enregistrement source fonctionne également ici : "cet enregistrement a-t-il déjà été traité ?" avant de sauvegarder le résultat. La vérification évite la double saisie.
Le troisième point est d’échelonner les diffusions en direct par lots. Certaines tâches ont à la fois des dimensions en direct et par lots : lorsque l'utilisateur charge un document, vous lui donnez un résumé préliminaire rapide (synchrone) et retraitez le même document pour une analyse plus approfondie la nuit (par lots). Séparer consciemment les deux modes optimise à la fois l’expérience utilisateur et les coûts.
Enfin, le batching est aussi un moyen de gérer les limitations de vitesse (unité 8). L'envoi d'un volume élevé dans un flux synchrone en direct produit un 429 constant, tandis que l'envoi du même volume vers des transferts par lots limite la pression sur la planification du fournisseur et rend le travail plus prévisible.
En résumé
Le traitement par lots est généralement un mode moins cher et plus robuste pour les charges de travail tolérantes à la latence et à volume élevé. Sa décision était « l'utilisateur attend-il le résultat maintenant ? » détermine la question. La règle technique la plus critique consiste à attribuer à chaque requête un custom_id unique, à faire correspondre les résultats par ID plutôt qu'à l'emplacement, et à traiter le succès/l'échec de chaque résultat séparément.
Tâche de candidature
Choisissez un travail à volume élevé (par exemple, classification d'archives). (1) Décider si cette œuvre est vivante ou collective et la justifier. (2) Concevez un format custom_id (incluez l'enregistrement de ressource). (3) Remplissez la fiche de travail par lots (modèle, max_tokens, tolérance, politique d'erreur). (4) Écrivez le pseudocode de traitement des résultats pour inclure les requêtes ayant échoué.
liste de contrôle
- [ ] Je distingue les modes synchrone, asynchrone et batch sur l'axe coût/délai.
- [ ] Je peux décider si un travail est adapté ou non au batch en posant la bonne question.
- [ ] Je donne à chaque demande un custom_id unique et je fais correspondre les résultats par ID.
- [ ] Je peux gérer séparément les résultats ayant échoué/expirés.
- [ ] Je connais les avantages de choisir un modèle rapide dans les tâches simples par lots.