{
"messages": [
{"role": "system", "content": "You are a financial parser. Output strict JSON."},
{"role": "user", "content": "Company X made 10M in Q2."},
{"role": "assistant", "content": "{\"company\": \"Company X\", \"revenue\": 10000000, \"quarter\": \"Q2\"}"}
]
}Văd tot mai des startup-uri și developeri care sar direct la fine-tuning de cum dă modelul de la OpenAI sau Anthropic primele rateuri. Am pățit și eu asta anul trecut, la un proiect cu vreo 8.000 de utilizatori activi pe zi, unde generam rapoarte financiare nișate. Ne-am fript destul de tare până să înțelegem unde e granița reală între un prompt bun și un model antrenat dedicat.
Hai să demitizăm puțin lucrurile astea, din tranșee, nu din pliante de marketing.
Mitul „învățării” și de unde pornește greșeala
Cea mai mare confuzie pe care o văd e legată de scop. Mulți cred că fine-tuning-ul e metoda prin care înveți modelul informații noi despre business-ul tău. Total greșit. Dacă vrei ca LLM-ul să știe regulamentul tău intern sau prețurile actualizate la produse, fine-tuning-ul e cel mai prost mod de a face asta. Modelul va hallucina vesel pe datele tale vechi de trei luni.
Pentru cunoștințe noi, RAG (Retrieval-Augmented Generation) e sfânt. Rămâi la un prompt bun în care injectezi contextul din baza de date vectorizată.
Când prompt-ul devine prea gras și te costă o avere
Noi am început clasic: prompt engineering grosier. Am băgat în system prompt reguli de formatare, exemple de "așa da/așa nu" (few-shot prompting), tonul brandului și structura de JSON pe care o doream la ieșire.
Rezultatul? Promptul nostru de sistem ajunsese pe la 4.000 de tokeni. La fiecare request trimis de user, noi plăteam acei 4.000 de tokeni de intrare doar ca să obținem un răspuns de 200 de tokeni. La volumul nostru, factura de API a început să arate ca o rată la bancă pentru un apartament în Cluj.
Trade-off-ul e simplu aici:
- Prompt engineering: E ieftin de dezvoltat (scrii text, dai save, testezi), dar devine extrem de scump la rulare dacă ai volum mare de request-uri și context lung.
- Fine-tuning: E scump de pregătit (timp de dev, curățat date, cost de antrenare), dar scapi de 80% din tokenii de sistem. Modelul știe deja formatul și tonul din oficiu.
Când am trecut noi la fine-tuning și ce am obținut
Am decis să facem pasul când am realizat că modelul de bază nu reușea să respecte un format JSON strict în 5% din cazuri, indiferent cât de mult îl amenințam în prompt.
Am strâns un dataset curat de vreo 1.500 de conversații perfecte (input-uri de la useri și output-urile ideale generate manual sau corectate de noi). După fine-tuning, am scos toate exemplele din system prompt. Promptul a scăzut de la 4k tokeni la doar 150 de tokeni.
Am obținut două chestii mari:
- Am redus costurile per API call cu aproape 60% (plăteam mult mai puțin pe tokenii de input).
- Latența a scăzut la jumătate. Modelul nu mai trebuia să "citească" o pagină de instrucțiuni la fiecare rulare.
Dezavantajele de care nu-ți zice nimeni
Nu e totul roz. Dacă schimbi o regulă de business mâine, la prompt engineering modifici o linie de text în 10 secunde. La fine-tuning? Trebuie să refaci dataset-ul, să reantrenezi modelul și să-l redeploiezi. E rigid și doare.
În plus, dacă folosești modele proprietare, costul per token pentru un model fine-tuned e adesea dublu față de cel de bază. Trebuie să faci bine matematica înainte: compensează reducerea de tokeni de input tariful mai mare per token?
Voi cum ați rezolvat dilema asta? Ați rămas pe prompt-uri lungi sau ați trecut pe modele custom?