Carichi di lavoro batch e asincroni

Guadagni:

• Determina per quali carichi di lavoro è adatta l'elaborazione batch
• Comprende il compromesso costo/latenza tra l'elaborazione sincrona, asincrona e batch
• Progetta un flusso di lavoro batch affidabile che abbina custom_id ai risultati

La maggior parte delle integrazioni LLM si concentra su scenari “live” in cui un utente attende una risposta davanti a uno schermo. Ma la maggior parte dei carichi di lavoro professionali non sono realmente attivi: etichettatura di migliaia di documenti durante la notte, riepilogo di un intero set di dati, classificazione di intere registrazioni di chiamate nell'archivio. In queste questioni nessuno si aspetta una risposta immediata; L’importante è finire il lavoro in modo economico e affidabile. Batch è esattamente per questi carichi di lavoro. In questa unità imparerai la differenza tra l'elaborazione sincrona, asincrona e batch, quando batch è la scelta giusta, e un flusso affidabile che corrisponde con sicurezza a custom_id e risultati.

Tre modalità di lavoro

modalità

Come funziona

ritardo

Costo tipico

lavoro adatto

sincrono

Fai una richiesta e attendi la risposta

secondi

Norma

Chat dal vivo, assistente istantaneo

asincrono

Metti in coda il lavoro e ricevi una notifica quando è finito.

Secondi-minuti

Norma

Attività in background, passaggi di automazione

Lotto

Invia migliaia di richieste in un unico pacchetto, quindi ottiene i risultati

Minuti-ore

Solitamente scontato

Lavori ad alto volume e tolleranti ai ritardi

L'elaborazione batch è questa: invii centinaia/migliaia di richieste come un unico "lavoro" al fornitore; Il fornitore li elabora secondo i propri ritmi e restituisce tutti i risultati in blocco una volta completati. In cambio ottieni due cose: (1) un costo unitario generalmente inferiore, (2) la capacità di spostare volumi elevati senza dover affrontare limiti di velocità. Il prezzo è che i risultati non arrivano subito, ma dopo qualche tempo.

Quando effettuare il batch, quando no?

La decisione si riduce a una domanda: l’utente sta aspettando il risultato adesso?

• No, posso trattenerlo → candidato batch. Etichettatura notturna, riepilogo batch, classificazione dell'archivio, arricchimento dei dati, esecuzione della valutazione (eval).
• Sì, in attesa sullo schermo → sincronizzazione. Chat dal vivo, consulenza immediata, aiuto nella compilazione dei moduli.

Suggerimento: due modalità possono coesistere nello stesso prodotto. L'utente lavora in modo sincrono nella chat dal vivo; Di notte, fornisci tutte le conversazioni di quel giorno al lotto per l'analisi della qualità. Separare il “bisogno abitativo” dal “bisogno collettivo” è la prima decisione dell'architettura.

Anatomia del flusso batch robusto

La regola tecnica più importante dell'elaborazione batch è la corrispondenza dei risultati.

1. Assegna a ciascuna richiesta un "custom_id" univoco. Questo è il tuo ID generato che identifica la richiesta (ad esempio fattura-2026-07-18-000431).
2. Invia il lavoro. Tutte le richieste vanno in un unico pacchetto; ciascuno con il proprio custom_id.
3. Fai un sondaggio sulla situazione. Chiedi lo stato a intervalli finché il lavoro non è "finito".
4. Abbina i risultati con "custom_id". I risultati possono essere restituiti in un ordine diverso rispetto all'ordine di invio; quindi non corrispondere mai in base alla posizione ma in base al custom_id trasportato da ciascun risultato.
5. Controlla il tipo di ciascun risultato. Una richiesta potrebbe avere successo, un'altra potrebbe fallire, un'altra potrebbe scadere. Processo basato sul successo/fallimento.

{ "requests": [ { "custom_id": "invoice-000431", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Classifica fattura. Restituisci solo JSON.", "messages": [{ "role": "user", "content": "{{invoice_text}}" }] } }, { "custom_id": "invoice-000432", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Classifica fattura. Restituisci solo JSON.", "messages": [{ "role": "user", "content": "{{invoice_text_2}}" }] } } ]}

Attenzione: la corrispondenza dei risultati in base all'ordine di invio è l'errore numero uno nell'invio in batch. La coda non viene conservata. Senza custom_id non puoi sapere con sicurezza quale risultato appartiene a quale documento: la corrispondenza errata porta silenziosamente a dati errati.

Modelli copiabili

# regola di generazione custom_id (univoca e tracciabile)Formato: <isture>-<data>-<sequenza>. Esempio: request-20260718-000431Regola: non ripetere mai nel lavoro; Incorpora l'ID del record di risorsa al suo interno.

# Scheda lavoro batch (modello di pianificazione)Nome lavoro: .............Numero di record: .............Modello: ............. (lavoro semplice → modello veloce)Max_token per richiesta: .............Tolleranza tempo di consegna previsto: ......... oreChiave di corrispondenza risultato: custom_idIn caso di errore: riprova / accoda / report

# Richiesta singola in batch (breve e schematica) Classificare questo documento. Restituisci semplicemente questo JSON, commentando:{"category":"...","urgency":"low|medium|high"}Documento: """{{document}}"""

# Pseudo-codice di elaborazione del risultato per ciascun risultato: if result.status == "success": record = find(custom_id) save(record, result.output) altrimenti: add_to_fail(custom_id, result.error) # quindi riprova

Prompt debole/Prompt forte (progettazione di lavori batch)

# DEBOLE (design fragile) Invia 10.000 documenti in ordine con il modello forte, salva i risultati restituiti nell'ordine in cui arrivano.

# FORTE (design durevole) Invia 10.000 documenti in un batch con un modello veloce. Assegna a ciascun documento un custom_id univoco contenente l'ID del record di origine. Abbina i risultati con custom_id; metti in coda quelli falliti e riprova. Corri nella finestra notturna; Tolleranza di consegna 6 ore.

Versione potente; Predefinisce la selezione del modello, la chiave di corrispondenza, la gestione degli errori e la tempistica. Questa è la differenza nell'elaborazione sicura di decine di migliaia di record.

Tre mini custodie

Caso 1 — Etichettatura notturna. Un team di e-commerce ordinerebbe 200.000 recensioni di prodotti in tag sentiment. Lo streaming live sincrono era soggetto a limiti di velocità ed era costoso. Hanno portato avanti il ​​lavoro nella notte in batch con un modello veloce; Il costo unitario è diminuito, l'intero set era pronto al mattino e non ci sono stati problemi di limiti di velocità.

Caso 2 — Confusione dell'ordinanza. Un gruppo di ricerca ha estratto 5.000 articoli, ma ha scritto i risultati in file nell'ordine in cui sono arrivati. Poiché i risultati sono stati restituiti in un ordine diverso, circa 900 dei 5.000 abstract erano collegati all'articolo sbagliato. L'hanno rimappato su custom_id; problema risolto e questa esperienza è diventata regola permanente: "Sempre custom_id in batch."

Caso 3 — Live standby nella modalità errata. Un team di supporto ha tentato di fornire in batch le risposte in tempo reale che l'utente si aspettava sullo schermo; Gli utenti hanno abbandonato perché i risultati sono arrivati ​​pochi minuti dopo. Hanno riportato il lavoro in tempo reale alla sincronizzazione, lasciando nel batch solo l'analisi della qualità notturna. Lezione: il batch non è per il live standby.

Errori comuni

• Risultati corrispondenti per posizione: L'ordine non viene mantenuto; Utilizza custom_id.
• Trasferimento del lavoro attivo in batch: l'utente non può attendere minuti; batch è per lavori con tolleranza al ritardo.
• Mancata gestione dei casi di errore: alcune richieste potrebbero restituire errori/scadute; Mettilo in una coda separata e riprova.
• Forte riflesso di utilizzo del modello in batch: modello veloce + batch è la combinazione più economica in lavori semplici.
• Non rendere tracciabile custom_id: se nessun record di origine è incorporato nell'ID, diventa difficile ricollegare il risultato.
• Dimenticare di esaminare la situazione: aspettarsi risultati prima che il lavoro sia finito; Controlla lo stato di completamento.

Approfondimento: monitoraggio del batch e gestione dei guasti parziali

L'aspetto più maturo dell'elaborazione batch è che richiede una mentalità diversa rispetto alle chiamate individuali: un lavoro batch è un "processo", non un "evento". Supporre che decine di migliaia di richieste abbiano tutte successo è fragile; La progettazione realistica accetta il fallimento parziale fin dall'inizio. Lo stato di ciascun risultato può essere diverso: riuscito, non riuscito (ad esempio input non valido), annullato o scaduto. Un flusso robusto elabora lo stato di ciascun risultato separatamente mentre lo attraversa, inserisce gli errori in una "coda di tentativi" separata ed esegue tale coda separatamente.

La seconda pratica è progettare per l'idempotenza (che eseguire due volte lo stesso lavoro non causa alcun danno). Se un batch viene interrotto e lo si riavvia, non è necessario rielaborare e scrivere due volte i record già elaborati. Anche in questo caso il collegamento del custom_id al record di origine funziona: "questo record è già stato elaborato?" prima di salvare il risultato. Il controllo impedisce la doppia digitazione.

Il terzo punto è scaglionare i live streaming in batch. Alcuni lavori hanno dimensioni sia live che batch: quando l'utente carica un documento, gli viene fornito un rapido riepilogo preliminare (sincrono) e si rielabora lo stesso documento per un'analisi più approfondita durante la notte (batch). Separare consapevolmente le due modalità ottimizza sia l'esperienza dell'utente che i costi.

Infine, il batching è anche un modo per gestire i limiti di velocità (unità 8). L'invio di un volume elevato in un flusso sincrono in tempo reale produce un 429 costante, mentre l'invio dello stesso volume ai trasferimenti batch limita la pressione sulla pianificazione del fornitore e rende il lavoro più prevedibile.

In sintesi

L'elaborazione batch è generalmente una modalità più economica e più robusta per carichi di lavoro con tolleranza alla latenza e volumi elevati. La sua decisione è stata "l'utente sta aspettando il risultato adesso?" determina la domanda. La regola tecnica più importante consiste nel fornire a ciascuna richiesta un custom_id univoco, abbinare i risultati in base all'ID anziché alla posizione e trattare separatamente il successo/fallimento di ciascun risultato.

Compito dell'applicazione

Scegli un lavoro ad alto volume (ad esempio classificazione dell'archivio). (1) Decidere se questo lavoro è dal vivo o collettivo e giustificarlo. (2) Progettare un formato custom_id (includere il record di risorse). (3) Compila la scheda lavoro batch (modello, max_tokens, tolleranza, politica di errore). (4) Scrivere lo pseudocodice di elaborazione dei risultati per includere le richieste non riuscite.

lista di controllo

• [ ] Posso distinguere la modalità sincrona, asincrona e batch sull'asse costo/ritardo.
• [ ] Posso decidere se un lavoro è adatto o meno per il batch ponendo la domanda giusta.
• [] Fornisco a ogni richiesta un custom_id univoco e abbino i risultati in base all'ID.
• [ ] Posso gestire separatamente i risultati non riusciti/scaduti.
• [ ] Conosco i vantaggi derivanti dalla scelta di un modello veloce in semplici lavori batch.