{
"messages": [
{ "role": "system", "content": "Ești un parser de contracte ultra-specializat." },
{ "role": "user", "content": "Contract nr 124 din 12.02.2024, valoare 15000 EUR..." },
{ "role": "assistant", "content": "{\"id\":124,\"data\":\"2024-02-12\",\"valoare\":15000,\"moneda\":\"EUR\"}" }
]
}La un proiect recent unde trebuia să procesăm în jur de 12.000 de documente pe lună, am stat două săptămâni în cumpănă: scriem un mega-prompt de trei pagini sau facem fine-tuning pe un model mai mic? Mulți sar direct la fine-tuning fiindcă sună mai profi și mai „enterprise”, dar de cele mai multe ori e o risipă enormă de timp și resurse.
Hai să îți arăt cum am calculat noi rentabilitatea și unde am dat cu capul de pragul de sus.
Iluzia că un prompt lung rezolvă orice
Prompt-ul e excelent pentru prototipare rapidă. În faza de început, bagi câteva exemple (few-shot prompting), îi explici contextul în detaliu și ai gata un MVP în două ore. Am reușit să aducem acuratețea extracției de date la 85% doar bătându-ne capul cu structura promptului și adăugând reguli clare de excludere.
Dar am dat rapid de o problemă de cost și latență. Când ai un system prompt de 2.000 de tokeni, plin de reguli de business și exemple de „așa da/așa nu”, plătești acei tokeni la fiecare request. La volumul nostru, factura de API începuse să crească alarmant, iar timpul de răspuns trecea frecvent de 4-5 secunde pentru că modelul trebuia să proceseze tot contextul de fiecare dată.
Regula de aur: „Cum să spună” vs „Ce să știe”
Din experiența mea de până acum, am trasat o linie destul de clară între cele două abordări:
- Fine-tuning-ul este genial pentru a învăța modelul cum să se comporte, ce ton să folosească și ce format strict de output să respecte (de exemplu, un JSON valid care să nu crape la parsare).
- Prompt engineering + RAG (Retrieval-Augmented Generation) este singura soluție viabilă dacă vrei ca modelul să aibă acces la informații externe sau date care se schimbă des.
Nu folosi fine-tuning ca să-ți înveți modelul baza de date de produse. O să dea halucinații imediat ce se schimbă stocul sau prețurile.
Cazul real în care fine-tuning-ul ne-a salvat bugetul
Când am realizat că 80% din costul fiecărui API call era generat de contextul gigantic pe care îl trimiteam (instrucțiunile de formatare), am decis să facem fine-tune pe un model mai mic și mai ieftin (GPT-3.5 Turbo la acea vreme, înlocuit acum cu succes de GPT-4o-mini).
Am strâns un set de 500 de exemple curate de tipul input -> output JSON perfect.
Rezultatele au fost clare:
- Reducerea costurilor: Am eliminat 1.500 de tokeni de instrucțiuni din fiecare request. Costul per rulare a scăzut cu aproape 40%.
- Latență redusă: Timpul de răspuns a scăzut de la 4.5 secunde la sub 1.5 secunde.
- Consistență: Formatul JSON nu a mai crăpat deloc. Modelul învățase structura direct în rețeaua neuronală, nu mai avea nevoie de „rugăminți” în prompt.
Trade-off-ul ascuns: Blocarea în versiune (Version Lock)
Sună perfect, dar există o capcană uriașă de care nimeni nu vorbește la conferințe: mentenanța.
Când faci fine-tune, te blochezi pe o anumită versiune de model de la un anumit provider. Dacă OpenAI sau Anthropic lansează un model nou, de trei ori mai ieftin și mai deștept peste noapte, tu nu poți doar să schimbi un string în fișierul .env. Trebuie să o iei de la capăt: să cureți datele, să re-antrenezi noul model, să-i testezi comportamentul și să plătești din nou procesul de training.
În plus, pregătirea unui dataset de calitate e o muncă extrem de plictisitoare. Dacă strecori greșeli în datele de antrenament, modelul custom le va replica cu o precizie matematică și o încăpățânare greu de corectat.
Pe scurt: începe mereu cu prompt engineering până când costul tokenilor de context sau latența devin blocante. Abia atunci merită să deschizi portofelul pentru fine-tuning.
Voi cum ați rezolvat problemele de consistență a formatului? Ați mers pe mega-prompturi sau ați trecut direct la modele custom antrenate local?