Optimizare și exploatare
Optimizează o nevoie observată: timp, cost sau eșecuri.
Ce vei învăța
- Explici: erorile au nevoie de trasee explicite
- Aplici ideea într-un exemplu: Optimizare și exploatare
- Recunoști limitele și verifici rezultatul exercițiului
Optimizează o nevoie observată: timp, cost sau eșecuri. O configurație mai complicată nu este automat mai robustă.
Acesta este un laborator conceptual sau extern. Nu presupune că aplicația oferă toate controalele descrise.
Cum funcționează, pas cu pas
Erorile au nevoie de trasee explicite
Un timeout nu este același lucru cu o eroare de permisiune. Reîncearcă doar erorile tranzitorii, cu un număr limitat de încercări și pauze crescătoare. O operație cu efecte poate fi executată înainte ca răspunsul să se piardă; repetarea fără cheie de idempotency poate dubla efectul. Streaming arată progresul, dar nu garantează finalizarea. Checkpoint-urile pot permite reluarea etapelor eșuate, în limitele runtime-ului. Păstrează identificatorul rulării, etapa, durata și eroarea, eliminând secretele din logs. Măsoară și cel mai lent traseu, nu doar media.
Costul aparține întregului traseu
Numără apelurile de model, tokenii de intrare și ieșire, embeddings, reranking, vision și uneltele. Reasoning poate consuma tokeni facturați fără un răspuns vizibil la fel de lung. Costul indexării și costul conversației sunt diferite. Folosește tarifele curente, nu o cifră permanentă din curs. Estimarea simplă este tokeni/1.000.000 × tarif, plus operații suplimentare; creditele aplicației pot folosi propria conversie. Compară costul per sarcină reușită, nu doar per apel. Parallel poate reduce latența, dar crește consumul total. Bugetul trebuie să aibă o condiție de oprire verificată.
Definește succesul înainte de optimizare
Pregătește un set de cereri reprezentative și răspunsuri sau proprietăți așteptate. Include cazuri obișnuite, ambigue, fără date și cu erori de unelte. Pentru RAG măsoară separat găsirea dovezii și corectitudinea răspunsului. Recall@k urmărește proporția dovezilor relevante găsite în primele k rezultate; precision@k urmărește proporția rezultatelor relevante. Pentru agenți urmărește și acțiunile, accesul și oprirea. Un LLM-as-judge poate accelera evaluarea, dar se calibrează față de oameni. Nu modifica simultan promptul, modelul și indexul dacă vrei să înțelegi cauza îmbunătățirii.
Harta vizuală
Urmărește săgețile continue pentru fluxul principal. Săgețile albastre punctate furnizează date sau context; cele roz punctate arată feedback sau rezultate care revin. Culorile și formele disting modelele, stocările, deciziile și rezultatele. Pe ecrane mici, derulează orizontal pentru a urmări întreaga diagramă.
Un exemplu complet
Cache-ul unei politici poate reduce timp, dar stocul live trebuie să expire rapid. Retry ajută un timeout tranzitoriu, nu o cheie invalidă. Fallback trebuie să păstreze condițiile și accesul.
Încearcă tu
- Proiectează retry limitat, expirarea cache-ului și un fallback conceptual.
- Notează intrarea, sursa și rezultatul așteptat înainte să rulezi experimentul. Folosește doar datele fictive din exemplu.
- Urmărește etapele din diagramă. La fiecare pas scrie ce informație primește și ce produce; nu confunda rezultatul intermediar cu rezultatul final.
- Repetă cazul după eliminarea unei informații necesare sau după o intrare ambiguă. Verifică dacă sistemul cere clarificare, se oprește sau inventează.
- Compară cu soluția comentată. Păstrează configurația, data, rezultatul și o explicație pentru orice diferență. Schimbă un singur lucru și retestează.
Soluție comentată
Măsori înainte și după, incluzi cazuri de eșec și verifici lipsa regresiilor. Pentru a considera exercițiul reușit, poți arăta legătura dintre intrare, etapele parcurse și rezultat. Dacă lipsesc date, un răspuns prudent este mai util decât o completare inventată. Nu compara doar stilul: verifică și condițiile, sursele și operațiile efectuate.
Când merită și ce poate merge prost
Nu presupune că produsul expune toate aceste opțiuni în interfață. Alege această abordare când îmbunătățește o nevoie măsurată. Păstrează o variantă simplă ca referință și compară rezultatele pe aceleași intrări. Un singur exemplu reușit nu stabilește fiabilitatea în toate situațiile.
Verifică ce ai înțeles
Un timeout dovedește că operația nu s-a executat?
Nu. Verifică starea înainte de reluarea unei acțiuni cu efecte.
Mai multe apeluri simultane sunt automat mai ieftine?
Nu. Timpul și suma consumului sunt mărimi diferite.
Ce rezultat trebuie să obții în acest exercițiu?
Măsori înainte și după, incluzi cazuri de eșec și verifici lipsa regresiilor.
Cuvinte de ținut minte
- Idempotency: Repetarea controlată fără duplicarea efectului.
- Latență / Latency: Timpul până la rezultatul util.
- Regresie / Regression: O schimbare care strică un caz anterior corect.
Surse și următorul pas
Pentru pregătire: E05 — Tokeni, credite, bugete și cost total