Budget, rate limit, fallback

Un’integrazione LLM è una dipendenza remota: costa, può rallentare, può fallire, può essere limitata, può restituire output non valido. Se la tratti come una chiamata locale, prima o poi romperà l’esperienza utente o il budget.

Prompt engineering per sviluppatori significa anche progettare il comportamento quando il modello non risponde, risponde tardi, costa troppo o supera i limiti di provider.

Perché questa lezione conta

Molti prototipi LLM funzionano in demo perché hanno poco traffico, input piccoli e nessun vincolo economico. Il problema appare quando il flusso entra in uso reale: utenti simultanei, file grandi, retry, output lunghi, automazioni schedulate, code di job.

Senza budget e fallback, un prompt “migliore” può diventare un rischio operativo: produce risposte più ricche ma aumenta costo e latenza, oppure manda in errore l’app quando il provider limita le richieste.

Obiettivo operativo

Alla fine della lezione devi saper progettare una chiamata LLM con limiti di costo, strategia di retry, degradazione controllata e monitoraggio minimo.

Budget per richiesta

Ogni task dovrebbe avere un budget indicativo:

task: review automatica PR piccola
input massimo: 20.000 token
output massimo: 1.500 token
modello default: classe media
costo massimo per run: 0,20 EUR
latenza target: < 15 s
fallback: summary + richiesta review manuale

Il budget non serve a essere perfetto al centesimo. Serve a impedire sorprese. Se un input supera il limite, il sistema deve comprimere, dividere o rifiutare con messaggio chiaro.

Rate limit e retry

I rate limit sono normali. Il problema è come reagisci.

Retry immediati e paralleli possono peggiorare la situazione. Una strategia più sana:

1. riconoscere errori temporanei;
2. applicare backoff progressivo;
3. aggiungere jitter;
4. rendere la richiesta idempotente;
5. interrompere dopo un numero massimo di tentativi;
6. restituire una modalità degradata o una coda asincrona.

L’idempotenza è essenziale quando la chiamata può attivare tool o modificare stato. Se ripeti una richiesta, non devi inviare due email, creare due ticket o applicare due patch.

Fallback

Un fallback non è solo “prova un altro modello”. Può essere:

Fallback di modello. Passare a un modello più piccolo o più disponibile, accettando minore qualità.

Fallback di contesto. Ridurre documenti, usare riassunto, lavorare su chunk, chiedere all’utente di selezionare file.

Fallback di output. Produrre una risposta parziale: elenco dei rischi principali invece di review completa.

Fallback di esperienza. Mettere il job in coda, inviare notifica, proporre intervento umano.

Fallback deterministico. Usare regole tradizionali quando il task è semplice: regex, parser, validatori, template.

Il fallback va progettato prima. Se lo inventi nel blocco catch, sarà generico e poco utile.

Cache e deduplicazione

Molti costi inutili derivano da richieste ripetute. Se input, prompt, modello e parametri sono uguali, puoi riusare il risultato o almeno evitare doppie esecuzioni simultanee.

Attenzione però: cache e privacy si toccano. Non mettere in cache output con dati sensibili senza policy. Non riusare risposte tra tenant diversi. Non nascondere all’utente che sta vedendo un risultato non appena generato se questo conta per il workflow.

Limiti nel prompt

Anche il prompt può aiutare il budget:

Rispondi con massimo 8 finding.
Non ripetere il codice.
Se il contesto è insufficiente, chiedi il file mancante invece di ipotizzare.
Usa JSON compatto senza spiegazioni fuori schema.

Questi vincoli riducono output inutile. Ma il limite vero va imposto nell’API o nel runtime: il modello può non rispettare perfettamente un’indicazione testuale.

Monitoraggio minimo

Registra almeno:

1. modello usato;
2. token input/output;
3. costo stimato;
4. latenza;
5. esito: ok, errore, fallback, timeout;
6. dimensione dell’input;
7. versione del prompt.

Senza questi dati non puoi capire se il problema è il prompt, il provider, il modello, il traffico o un input fuori scala.

Laboratorio guidato

Prendi uno script o un flusso LLM semplice e aggiungi una scheda operativa:

1. limiti di input e output;
2. soglia costo per richiesta;
3. strategia di retry;
4. fallback;
5. log minimo;
6. messaggio utente in caso di degradazione.

Poi simula tre casi: rate limit, input troppo grande, output non valido. Il risultato atteso non è “non fallisce mai”, ma “fallisce in modo controllato”.

Output atteso

Devi produrre una mini specifica operativa per chiamate LLM:

1. budget per task;
2. limiti hard e soft;
3. retry policy;
4. fallback disponibili;
5. eventi da loggare;
6. criteri per escalare a intervento umano.

Se lavori in codice, aggiungi una piccola utility condivisa invece di duplicare retry e logging in ogni feature.

Errori comuni

Retry senza limite. Trasforma un errore temporaneo in un picco di costo e traffico.

Fallback che cambia semantica. Un modello più economico non deve prendere decisioni che il flusso riservava a un modello più accurato.

Non misurare output token. Molti costi esplodono perché l’output è verboso, non perché l’input è grande.

Gestire tutto sincrono. Alcuni task devono diventare job asincroni, non richieste bloccanti da UI.

Checklist di verifica

• ogni flusso LLM ha un budget indicativo;
• esistono limiti su input e output;
• i retry hanno backoff e massimo tentativi;
• il fallback è progettato, non improvvisato;
• loggo costo, latenza, modello e versione prompt.

Collegamenti

• Modulo: Affidabilità: valutazione, sicurezza, costi — questa lezione è la numero 30 del corso.
• Prepara il passaggio al modulo 7, dove il rischio aumenta perché il modello inizia a usare tool.