Ottimizzazione e operazioni
Ottimizza un'esigenza osservata: latenza, costi o guasti.
Cosa imparerai
- Spiegare: gli errori necessitano di percorsi espliciti
- Applica l'idea in un esempio: Ottimizzazione e operazioni
- Riconoscere i limiti e verificare il risultato dell'esercizio
Ottimizza un'esigenza osservata: latenza, costi o guasti. Le configurazioni più complicate non sono automaticamente più robuste.
Questo è un laboratorio concettuale o esterno. Non presuppone che l'applicazione esponga tutti i controlli descritti.
Come funziona, passo dopo passo
Gli errori necessitano di percorsi espliciti
Un timeout è diverso da un errore di autorizzazione. Riprova solo errori temporanei, con tentativi limitati e ritardi crescenti. Un'operazione con effetti collaterali può essere eseguita prima che la sua risposta venga persa; riprovare senza una chiave di idempotenza può duplicare l'effetto. Lo streaming mostra l'avanzamento ma non garantisce il completamento. I checkpoint possono consentire la ripresa delle fasi non riuscite entro i limiti di runtime. Memorizza l'identificatore dell'esecuzione, la fase, la durata e l'errore rimuovendo i segreti dai log. Misura i percorsi lenti e le medie.
Il costo appartiene all'intero percorso
Conta le chiamate ai modelli, i token di input e output, gli incorporamenti, la riclassificazione, la visione e gli strumenti. Il ragionamento può consumare token fatturabili senza una risposta visibile altrettanto lunga. I costi di indicizzazione e i costi di conversazione differiscono. Utilizza i prezzi correnti anziché un numero permanente di un corso. Una stima semplice è token/1.000.000 × prezzo più operazioni aggiuntive; i crediti dell'applicazione possono avere la propria conversione. Confronta i costi per attività riuscita, non solo per chiamata. L'esecuzione parallela può ridurre la latenza aumentando al contempo il consumo totale. Un budget necessita di una condizione di arresto verificata.
Definire il successo prima di ottimizzare
Preparare richieste rappresentative e risposte o proprietà previste. Includere casi ordinari, ambiguità, dati mancanti ed errori dello strumento. Per RAG, misurare il recupero delle prove separatamente dalla correttezza della risposta. Recall@k misura la quota di prove rilevanti trovate nei primi k risultati; Precision@k misura la quota di risultati restituiti che sono rilevanti. Per gli agenti, monitora anche azioni, autorizzazioni e arresti. Un LLM come giudice può accelerare la valutazione ma necessita di una calibrazione rispetto agli esseri umani. Non modificare prompt, modello e indice contemporaneamente se vuoi capire quali risultati migliorati.
Lo schema esplicativo
Seguire le frecce continue per il flusso principale. Le frecce blu tratteggiate forniscono dati o contesto; le frecce rosa tratteggiate mostrano feedback o risultati restituiti. Colori e forme distinguono modelli, negozi, decisioni e risultati. Su schermi piccoli, scorri in orizzontale per seguire l’intero schema.
Un esempio completo
Una policy cache può ridurre la latenza, ma il patrimonio vivo necessita di una scadenza rapida. Il nuovo tentativo aiuta il timeout temporaneo, non una chiave non valida. Il fallback deve preservare le condizioni e l'accesso.
Provalo tu stesso
- Nuovo tentativo limitato dal progetto, scadenza della cache e fallback concettuale.
- Registrare l'input, la fonte e il risultato atteso prima di eseguire l'esperimento. Utilizzare solo i dati fittizi nell'esempio.
- Seguire le fasi del diagramma. Ad ogni passaggio registrare quali informazioni vengono ricevute e prodotte; non confondere il risultato intermedio con il risultato finale.
- Ripetere dopo aver rimosso le informazioni necessarie o reso ambiguo l'input. Controlla se il sistema chiarisce, ferma o inventa una risposta.
- Confrontare con la soluzione spiegata. Conserva la configurazione, la data, il risultato e una spiegazione delle differenze. Cambia una cosa e riprova.
Una soluzione spiegata
Misura prima e dopo, includi i fallimenti e controlla le regressioni. Un esercizio riuscito ti consente di mostrare la connessione tra input, fasi e risultato. Quando mancano le informazioni, una risposta cauta è più utile dei dettagli inventati. Confrontare non solo stile: verificare anche condizioni, fonti e operazioni.
Quando è utile e quali sono i suoi limiti
Non dare per scontato che il prodotto esponga tutte queste opzioni nella sua interfaccia. Scegli questo approccio quando migliora un bisogno misurato. Mantieni una linea di base semplice e confronta i risultati utilizzando input identici. Un esempio di successo non stabilisce l’affidabilità in ogni situazione.
Verifica ciò che hai imparato
Un timeout dimostra che l'operazione non è stata eseguita?
No. Controlla lo stato prima di ritentare un'azione con effetti collaterali.
Più chiamate simultanee sono automaticamente più economiche?
No. Il tempo trascorso e il consumo totale sono quantità diverse.
Quale risultato dovrebbe produrre questo esercizio?
Misura prima e dopo, includi i fallimenti e controlla le regressioni.
Termini da ricordare
- Idempotenza: Ripetizione controllata senza duplicare un effetto.
- Latență / Latenza: tempo necessario per ottenere un risultato utile.
- Regresia/Regressione: una modifica che interrompe un caso precedentemente corretto.
Fonti e il prossimo passo
Per preparare: E05 — Gettoni, crediti, budget e costo totale