Am văzut prea des echipe care sar direct la fine-tuning doar pentru că sună mai „pro”. În 90% din cazuri, e o risipă masivă de timp și bani pe care o puteai evita cu un prompt bine structurat și un flux RAG curat. Hai să vorbim pe cifre și pe experiența mea de la un proiect recent, ca să nu repeți aceleași greșeli.
Mitul fine-tuning-ului ca soluție universală
Anul trecut am lucrat la o aplicație de suport tehnic pentru un client cu vreo 15k utilizatori activi lunar. Managementul a venit cu ideea fixă: „Facem fine-tuning pe GPT-4 ca să știe produsul nostru perfect”. Am stat trei săptămâni doar ca să curățăm datele. Am formatat mii de perechi de întrebări și răspunsuri în format JSONL, am dat discard la zgomot și am rulat primele joburi de antrenare.
Costul inițial? Câteva sute de dolari pe antrenare, dar adevăratul cost a fost timpul echipei (trei developeri blocați pe asta). Rezultatul? Modelul o lua pe arătură când apăreau update-uri noi de produs. Fine-tuning-ul nu e o bază de date dinamică. El schimbă comportamentul, tonul și formatul modelului, nu-l învață fapte noi în timp real.
Când e de ajuns un prompt bun (și un pic de RAG)
Dacă ai nevoie ca modelul să extragă informații din documente, să răspundă pe baza unui manual de utilizare sau să formateze date, un prompt System solid e arhisuficient.
Folosește tehnici de Few-Shot prompting. Îi dai modelului 3-5 exemple clare de „Așa DA” și „Așa NU” direct în context. Am rezolvat o problemă de clasificare de tichete cu un prompt de 1.5k tokeni care funcționează cu o acuratețe de 94%. Fără antrenare, fără bătăi de cap cu dataseturi.
Trade-off-ul aici e costul pe token și latența. Dacă trimiți la fiecare request un context uriaș de 8k tokeni, costurile de rulare cresc rapid și latența trece de 2-3 secunde. Pentru MVP-uri sau volume mici (sub 50k apeluri pe lună), asta e calea cea mai ieftină și rapidă.
Când merită să treci la Fine-Tuning
Treci la fine-tuning doar în trei scenarii clare, când matematica și performanța o cer:
- Reducerea latenței și a costurilor la scară: Când ai un volum uriaș de requesturi (sute de mii pe zi). Dacă poți elimina 1000 de tokeni de instrucțiuni din promptul System printr-un model finisat care „știe” deja formatul din fabrică, economisești mii de dolari lunar. La un proiect cu volum mare, am redus costurile cu 35% doar făcând fine-tuning pe un model mai mic (GPT-3.5-Turbo în loc de GPT-4) care rula instant.
- Stilizare extremă sau jargon de nișă: Când modelul trebuie să vorbească exact ca un copywriter specific, să folosească formule medicale ultra-complexe sau să scrie cod într-un mod proprietar pe care niciun prompt nu-l poate descrie în limitele ferestrei de context.
- Formatare rigidă de output: Când ai nevoie ca modelul să scoată un JSON extrem de complex și, în ciuda tuturor schemelor restrictive din prompt, modelele generale tot mai dau rateuri ocazionale.
Pe scurt: Prompt engineering-ul te învață ce să faci, fine-tuning-ul te învață cum să fii. Tu în ce tabără ești acum? Încerci să repari un prompt prost prin fine-tuning sau chiar ai volume care să justifice antrenarea unui model?