Produzione end-to-end: verifica, monitoraggio ed etica

Guadagni:

• Può progettare l'architettura end-to-end che porta una funzionalità LLM dall'idea alla produzione
• Stabilisce livelli di applicazione della verifica, approvazione umana e monitoraggio (registrazione/metriche)
• I confini traducono i principi di etica e privacy in decisioni di produzione

Nelle dieci unità precedenti, abbiamo imparato le parti una per una: struttura della richiesta, economia dei token, flusso, prompt del sistema, selezione del modello, cache, batch, gestione degli errori, chiave sicura e automazione. In quest'ultima unità, combiniamo le parti e stabiliamo l'architettura olistica che porta una caratteristica LLM dall'idea alla produzione. La produzione è diversa da una “demo funzionante”: la verifica è obbligatoria, i risultati devono essere monitorati, i confini e i principi etici devono essere incorporati nelle decisioni. Questa unità costituisce la colonna portante del modulo; Tutti i precedenti si riuniscono qui.

Livelli di architettura di produzione

Una solida qualifica LLM è composta da circa cinque livelli:

1. Livello di input: raccogli i dati, puliscili, maschera le aree sensibili, trasmetti solo ciò che è necessario.
2. Livello modello: seleziona il modello corretto (unità 5), imposta il prompt e i parametri del sistema (unità 4), memorizza la cache (unità 6).
3. Livello di convalida: verifica l'output rispetto a schema/regola, origine e approvazione umana, se necessario.
4. Livello azione: esegue un'azione con output convalidato; Cattura azioni ad alto impatto.
5. Livello di monitoraggio: registra e misura ogni chiamata, costo, errore e qualità.

Questi strati sono una pipeline; ognuno controlla l'output del precedente.

Perché è richiesta la verifica?

Gli LLM possono produrre risultati fluidi ma a volte imprecisi. Questa si chiama allucinazione: il modello può fabbricare informazioni che sembrano vere ma non lo sono. In un gioco in chat questo è tollerabile; non possono essere tollerate in un sistema produttivo (fatturazione, sanità, legale, finanza). Quindi si è rivelato ciecamente inaffidabile; è confermato.

Livelli di verifica (in aumento in base all'impatto):

• Convalida formato/schema: l'output è conforme allo schema JSON previsto? (L’output strutturato lo garantisce in gran parte.)
• Verifica delle regole/logica: i valori sono ragionevoli? (L'importo è negativo, la data è futura, la categoria è valida?)
• Verifica della fonte: la richiesta si basa sulla documentazione fornita? Il modello dice qualcosa che non è nel documento?
• Approvazione umana: un esperto esamina decisioni di grande impatto o ambigue.

Attenzione: "Il modello è così buono che non sono necessarie ulteriori verifiche" è l'errore di produzione più pericoloso. Non importa quanto sia valido il modello, il livello di verifica è una rete di sicurezza nelle decisioni ad alto impatto. Anche una decisione automatica sbagliata può togliervi tutto il tempo risparmiato.

Human-in-the-Loop

Non tutte le decisioni devono essere completamente automatiche. Nell’approccio human-in-the-loop, il modello accelera il lavoro e l’umano lo approva. Il giusto equilibrio dipende dall’impatto della decisione e dall’affidabilità del modello su tale compito.

Impatto della decisione

Avvicinamento

Basso (suggerimento etichetta, bozza)

Automazione completa; l’errore è economico e reversibile

Medio (routing, priorità)

Automazione + controllo del campionamento

Alto (denaro, contratto, salute, cancellazione)

Il consenso umano è obbligatorio; il modello suggerisce solo

Monitoraggio: non puoi gestire ciò che non vedi

In produzione è necessario monitorare ogni chiamata. Senza monitoraggio, non è possibile migliorare i costi, la qualità o individuare tempestivamente un problema. Metriche chiave da registrare:

• Utilizzo/costo: per richiesta e token totali, distribuzione del modello, spesa giornaliera.
• Latenza: tempo di risposta medio e nel caso peggiore.
• Tasso di errore: 429/500 tassi, tentativi, abbandoni.
• Qualità: tasso di output rifiutato al livello di verifica, tasso di correzione all'approvazione umana, feedback degli utenti.

Suggerimento: non scrivere dati sensibili (informazioni personali, chiavi) nei registri di monitoraggio. Considerare i registri nell'ambito della riservatezza; registrare mascherando se necessario (unità 9).

Etica e confini

La responsabilità etica è parte della decisione di produzione tanto quanto l’accuratezza tecnica:

• Trasparenza: l'utente deve sapere se sta parlando con un'intelligenza artificiale o con un essere umano.
• Equità e distorsione: il modello può contenere distorsioni derivanti dai dati su cui è addestrato; Monitorare le conseguenze discriminatorie nelle decisioni ad alto impatto (assunzioni, credito).
• Responsabilità: se una decisione automatizzata causa un danno, sei responsabile; “Lo ha detto il modello” non è una difesa.
• Accettazione dei limiti: il modello non può eseguire alcuni compiti in modo affidabile; anche non automatizzarli è una decisione di progettazione.

Modelli copiabili

# Elenco di controllo di convalida (dopo la generazione dell'output)1) Lo schema è valido? (convalida dell'output strutturato)2) I valori hanno senso? (controllo delle regole: intervallo, data, enum)3) L'affermazione è basata sulla fonte? (rifiutare se non presente nel documento)4) L'impatto è elevato? → invia per l'approvazione umana5) Se tutti hanno superato → consenti l'azione, salva

# Richiesta di sistema che forza l'affidamento alla fonte. Affidarsi solo alle informazioni nel documento fornito. Non aggiungere nulla che non sia presente nel documento. Se un'informazione non è presente nel documento, scrivi "Non trovata nel documento". Non indovinare o inventare mai cose.

# Soglia di approvazione umana (regola decisionale)SE tipo_decisione in [denaro, contratto, eliminazione, salute] → approvazione umana obbligatoriaSE fiducia_modello < soglia O convalida "incerto" → sottoporre all'approvazione umanaALTRO → applicazione automatica + controllo campionamento

# Modello di log di traccia (scrittura di dati sensibili){ "time":"...", "model":"...", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":"...", "authentication":"passed|rejected|human", "cost_usd":... } // i dati personali e la chiave non vengono MAI scritti

Prompt debole / Prompt forte (affidabilità della produzione)

# DEBOLE (nessuna verifica, nessuna fonte, si applica automaticamente) Valuta questa richiesta, prendi una decisione sul rimborso e fai domanda.

# FORTE (basato sulla fonte, genera raccomandazioni, lascia all'approvazione umana) Valuta questa richiesta di reso solo in base al documento sulla politica di restituzione. Raccomandare la decisione con giustificazione ma non implementarla: {"recommendation":"approve|reject","reason":"...","policy_clause":"..."}. Se non vi è una base chiara nel documento politico, indicare "non chiaro". Un rappresentante approverà la decisione finale.

Versione potente; Attribuisce la decisione alla fonte, posiziona il modello come un “suggeritore” piuttosto che come un “agente” e pone il passo ad alto impatto dietro l’approvazione umana. Questa è l'essenza dell'affidabilità della produzione.

Tre mini custodie

Caso 1: il giorno in cui è stato salvato il livello di verifica. Una fintech stava facendo in modo che il modello classificasse le descrizioni delle transazioni e creasse registrazioni contabili automatiche. Hanno aggiunto la convalida delle regole: una volta che il modello ha generato l'importo in modo errato (12.500 invece di 1.250 nel documento), la regola "l'importo non corrisponde al documento" ha rifiutato l'output e il record è caduto nelle mani dell'essere umano. Se non ci fosse stata alcuna verifica, il record errato sarebbe entrato silenziosamente nel sistema.

Caso 2 – Fuggitivo catturato dalla sorveglianza. Un team SaaS aveva istituito un pannello di monitoraggio; Una mattina il costo giornaliero è triplicato. Dai log si è visto che un client è entrato in un loop e ha inviato la stessa richiesta migliaia di volte. Hanno aggiunto quota e deduplicazione; Il problema è stato risolto in poche ore. Senza tracciabilità, la fattura sarebbe una sorpresa a fine mese.

Caso 3 – Accettazione del limite. Una startup del settore sanitario voleva formulare una raccomandazione diagnostica in modo completamente automatico e mostrarla al paziente. In una revisione di etica e responsabilità hanno deciso che ciò era vietato: il modello fornisce solo un riassunto e possibili punti al medico, il medico fa la diagnosi. Anche non automatizzare un lavoro è una decisione progettuale matura.

Errori comuni

• Saltare la convalida: applicare ciecamente l'output, dicendo "il modello è buono".
• Automatizzare le decisioni ad alto impatto: l’approvazione umana è essenziale in materia di denaro/salute/legge.
• Mancato monitoraggio: i problemi relativi ai costi e alla qualità vengono scoperti tardi.
• Scrittura di dati sensibili nei log: violazione della privacy; Salvalo mascherandolo.
• Non cercare di fare affidamento sulla fonte: il modello potrebbe inventare ciò che non è presente nel documento.
• Ignorare i limiti: non automatizzare alcune attività è la decisione giusta; La trasparenza e la responsabilità sono vostre.

Approfondimento: gestione del rilascio, rollback e distribuzione incrementale

Portare in produzione una funzionalità LLM non significa configurarla e dimenticarsene; è modificare in modo sicuro un sistema live nel tempo. Ha tre pilastri.

Controllo delle versioni. La richiesta di sistema, la selezione del modello e le regole di verifica cambiano nel tempo. Versione ogni modifica significativa e registra quale versione è attiva. Se un giorno la qualità cala, "cosa abbiamo cambiato?" Dovresti essere in grado di rispondere alla domanda in pochi minuti. In un sistema senza versione, trovare la causa principale di una regressione richiede giorni.

Rollback. Se un nuovo prompt o modello si comporta peggio del previsto in modalità live, dovresti essere in grado di ripristinare rapidamente la versione precedente e ben nota. Un cambiamento senza un piano di rollback equivale ad accettare ciecamente un rischio vivo. "Ho cambiato qualcosa, è andata male, non posso tornare indietro" è lo scenario di produzione più costoso.

Lancio graduale. Invece di applicare una modifica a tutto il traffico in una volta, la distribuisci prima a una piccola percentuale (ad esempio il 5%) e monitora le metriche (qualità, costi, errori). Se va bene aumenti la percentuale; Se è brutto, lo riavrai indietro con solo una piccola sezione interessata. Ciò limita notevolmente il rischio.

Queste tre pratiche combinano le tecniche di tutte le unità precedenti: eval (unità 5) misura il cambiamento in anticipo, monitoraggio (questa unità) fornisce un allarme tempestivo durante la propagazione, il livello di verifica rileva output errati prima che diventino utilizzabili. La produzione non è un'unica impostazione corretta; È una disciplina continua che misura, monitora e può cambiare con fiducia. L'intero modulo serve per stabilire questa disciplina.

In sintesi

La produzione è più di una demo funzionante: è una pipeline di livelli di input, modello, verifica, azione e monitoraggio. L'output non è affidabile senza verifica; le decisioni ad alto impatto sono legate all’approvazione umana; Ogni chiamata viene monitorata per costi, errori e qualità. Etica, trasparenza, controllo dei pregiudizi, responsabilità e accettazione dei limiti sono parte integrante delle decisioni tecniche. Ogni parte appresa in questo modulo si fonde in questo design olistico.

Compito dell'applicazione

Progetta una funzionalità LLM end-to-end. (1) Compila i cinque livelli (input, modello, verifica, azione, monitoraggio) per il tuo compito specifico. (2) Indicare in base all'impatto quali decisioni richiederanno l'approvazione umana. (3) Scrivere almeno tre controlli di validazione (schema, regola, sorgente). (4) Determina le metriche chiave che monitorerai e cosa non registrerai. (5) Scrivi un limite e un principio etico che accetti in questa rubrica.

lista di controllo

• [] Posso progettare cinque livelli della pipeline di produzione.
• [] Posso convalidare l'output rispetto a schema, regola e origine.
• [ ] Posso impostare una soglia di approvazione umana in base all'impatto della decisione.
• [ ] Controllo i costi, gli errori e la qualità e mi esercito a non scrivere dati sensibili nei log.
• [ ] Posso trasformare l'etica, la responsabilità e i confini in decisioni di produzione.

Esame del modulo

1. Cosa fa il ruolo "sistema" in un'API di chat LLM?

• A) Fornisce al modello istruzioni permanenti e regole di comportamento che si applicano durante l'intera conversazione ✔
• B) Mantiene l'ultima domanda scritta dall'utente
• C) Memorizza la risposta prodotta dal modello
• D) Crittografa la chiave API

Descrizione: il ruolo di sistema fornisce al modello istruzioni, personalità e regole persistenti che si applicano durante l'intera conversazione; È un reindirizzamento di alto livello, separato dai messaggi dell'utente.

2. Perché la cronologia delle conversazioni (messaggi precedenti) viene inviata nuovamente ogni volta in una richiesta API?

• R) È necessario eseguire il backup poiché il server elimina la cronologia
• B) Le chiamate API sono stateless; ✔ Il contesto viene rinviato ad ogni richiesta perché il modello non ricorda la cronologia
• C) Necessario solo per la fatturazione, non ha effetti sul modello
• D) L'invio dello storico è obbligatorio per evitare rallentamenti nella risposta

Spiegazione: le chiamate API LLM sono stateless; Il modello non ricorda i round precedenti, quindi tutta la cronologia rilevante viene reinviata a ogni richiesta per preservare il contesto.

3. Cos'è un "token" nei prezzi LLM?

• A) Password monouso utilizzata per accedere all'API
• B) Una quota fissa pagata su ogni richiesta
• C) L'unità più piccola in cui il modello elabora il testo; di solito corrisponde alla parte della parola ✔
• D) Un'unità che misura solo la lunghezza dell'output

Descrizione: il token è l'unità più piccola in cui il modello elabora il testo; Di solito corrisponde a un frammento di parola e sia l'input che l'output vengono addebitati in base al numero di token.

4. Perché i token di output sono più costosi dei token di input nella maggior parte dei fornitori LLM?

• A) I token di output sono sempre più lunghi di quelli di input
• B) I gettoni di input sono gratuiti
• C) I token di output vengono inviati due volte su Internet
• D) Il costo unitario è più alto perché la generazione dell'output richiede calcoli aggiuntivi per ciascun token ✔

Descrizione: ciascuno dei token di output richiede che il modello esegua la generazione (calcolo) passo dopo passo; Questo costo di produzione è più elevato rispetto all'elaborazione dell'input tutto in una volta, quindi il prezzo unitario dell'output è generalmente più elevato.

5. In quale situazione l'utilizzo dello streaming è più vantaggioso?

• A) Nelle risposte lunghe; Riduce il ritardo percepito e previene il timeout ✔
• B) Solo in risposte molto brevi, di una sola parola
• C) Ridurre i costi a zero
• D) Per nascondere la chiave API

Descrizione: nelle risposte lunghe, lo streaming riduce la latenza percepita facendo apparire immediatamente le prime parole e previene i timeout HTTP con valori max_tokens elevati.

6. Su cosa influisce generalmente l'aumento del parametro "sforzo" nei modelli moderni?

• A) Accorcia sempre la risposta
• B) Ruota automaticamente la chiave API
• C) Riduce solo il prezzo del token di input
• D) Aumenta la profondità di pensiero e la spesa simbolica; Può migliorare la qualità, ma aumenta anche la latenza e i costi ✔

Descrizione: il parametro impegno regola la profondità con cui il modello penserà a un'attività e quanti token spenderà; L'aggiornamento può migliorare la qualità, ma aumenta anche la latenza e i costi. Per compiti semplici è sufficiente uno sforzo minimo.

7. Qual è in genere l'approccio più conveniente per un'attività di classificazione semplice e di volume elevato?

• R) Utilizzare sempre il modello più costoso e più potente
• B) Chiamare tutte le modelle contemporaneamente per ogni richiesta
• C) Selezionare il modello più leggero/economico che assolve al compito verificandolo con una piccola valutazione ✔
• D) mantenere il valore max_tokens inutilmente troppo alto

Spiegazione: Se l'attività non è complessa, scegliere un modello più veloce ed economico che svolga facilmente l'attività (ad esempio la lezione Haiku) invece di utilizzare il modello più costoso e potente ridurrà significativamente il costo.

8. In quale scenario la memorizzazione nella cache dei prompt riduce maggiormente i costi?

• A) Quando un contesto ampio e fisso viene utilizzato ripetutamente per molte richieste ✔
• B) Quando con ogni richiesta viene inviato un testo completamente diverso
• C) Quando viene effettuata una sola richiesta
• D) Ridurre i gettoni in uscita

Descrizione: la memorizzazione nella cache è una corrispondenza del prefisso; Nei casi in cui un contesto ampio e immutabile (prompt di sistema, documenti) viene riutilizzato in molte richieste, la lettura dalla cache rappresenta una piccola frazione (~0,1x) del prezzo intero.

9. Come dovrei modificare il prompt in modo che la cache dei prompt venga attivata?

• A) Mettere il contenuto variabile all'inizio e il contenuto fisso alla fine
• B) Incorporare la data e l'ora correnti nel prompt del sistema per ciascuna richiesta
• C) Mettere il contenuto fisso (prompt di sistema, documenti) all'inizio e il contenuto variabile alla fine ✔
• D) Modifica dell'ordine della lista utensili ad ogni richiesta

Spiegazione: poiché la cache corrisponde a un prefisso, viene inizializzato il contenuto fisso/immutabile (prompt di sistema, documenti); il contenuto variabile (data, domanda dell'utente, ID richiesta) viene inserito alla fine. Anche un singolo byte modificato all'inizio invaliderà la cache.

10. Per quale tipo di carico di lavoro è più adatta l'elaborazione batch?

• A) Chat dal vivo in cui l'utente si aspetta una risposta immediata sullo schermo
• B) Solo una breve domanda
• C) Generazione della chiave API
• D) Lavori tolleranti ai ritardi, con grandi volumi e che non richiedono risultati immediati ✔

Descrizione: l'elaborazione batch è adatta per grandi volumi di lavori che non richiedono una risposta immediata e tollerano i ritardi; i risultati vengono forniti dopo un certo tempo, ma il costo unitario è generalmente inferiore.

11. Cosa viene utilizzato per abbinare con sicurezza la richiesta a cui appartengono i risultati in un batch?

• A) Invio ordine (posizione) delle richieste
• B) Lunghezza delle risposte
• C) Ultime 4 cifre della chiave API
• D) Un custom_id univoco assegnato a ciascuna richiesta ✔

Nota: i risultati in blocco possono essere restituiti in un ordine diverso rispetto all'ordine di invio; quindi è necessario abbinare i risultati per ID, non per posizione, con un custom_id univoco fornito a ciascuna richiesta.

12. Qual è il comportamento consigliato quando ricevi un errore 429 (limite di velocità) dall'API?

• A) Forzare inviando molte più richieste contemporaneamente
• B) Riprovare con backoff esponenziale, seguendo il titolo Riprova dopo ✔
• C) Annulla completamente la richiesta e mostra l'errore come un arresto anomalo all'utente
• D) Modifica della chiave API

Spiegazione: 429 è un errore reversibile; L'approccio corretto è riprovare con backoff esponenziale, rispettando l'intestazione retry-after. La maggior parte degli SDK ufficiali lo fanno automaticamente.

13. Quali dei seguenti codici di errore HTTP sono generalmente considerati ripetibili?

• A) 400 (richiesta non valida)
• B) 401 (errore di autenticazione)
• C) 529 (server sovraccarico) ✔
• D) 404 (non trovato)

Spiegazione: 429 (limite di velocità), 500 (errore del server) e 529 (sovraccarico) sono errori temporanei e possono essere riprovati tornando indietro. Errori come 400 e 401 sono problemi di richiesta/identità; Riprovare non risolverà il problema.

14. Quale dei seguenti è il modo sicuro per gestire le chiavi API?

• A) Memorizzare nella variabile d'ambiente/gestore nascosto, senza incorporarlo nel codice e ruotarlo regolarmente ✔
• B) Scrivi la chiave direttamente nel codice sorgente e inviala al repository
• C) Inserimento della chiave nel JavaScript lato client (browser).
• D) Condivisione di un'unica chiave con tutto il team via email

Descrizione: le chiavi non vengono mai scritte nel codice sorgente o nel repository; Viene archiviato in una variabile di ambiente o in uno strumento di gestione nascosto, concesso con privilegi minimi e ruotato regolarmente.

15. Qual è l'approccio migliore all'integrazione LLM con uno strumento di automazione (n8n, Zapier, Make) in termini di privacy?

• A) Invio di tutti i dati grezzi al modello, anche se non è necessario
• B) Scrivere la chiave API in testo semplice all'interno della fase del flusso
• C) Minimizzare e mascherare i dati sensibili e archiviare la chiave come credenziali segrete ✔
• D) Conservazione permanente dei dati personali nello storico del flusso

Descrizione: poiché i dati che entrano nell'automazione passano attraverso sistemi e modelli di terze parti, i dati sensibili/personali devono essere ridotti al minimo, mascherati e inviati solo i campi obbligatori; La chiave API viene inoltre archiviata come credenziali segrete all'interno dello strumento.

16. Perché la convalida dell'output è obbligatoria in una funzionalità di produzione basata su LLM?

• R) È necessaria solo la formattazione perché il modello non commette mai errori
• B) Perché il modello può produrre in modo fluido ma a volte in modo errato; Lo schema/la regola devono essere verificati con l'approvazione delle risorse e del personale ✔
• C) La validazione dovrebbe essere evitata perché aumenta solo i costi
• D) La verifica serve solo a ridurre il numero di token

Descrizione: gli LLM possono produrre output fluenti ma a volte imprecisi (allucinatori); quindi è emerso con decisioni ad alto impatto; Dovrebbe essere verificato mediante controllo di schemi/regole, convalida della fonte e approvazione umana quando necessario.