{
"messages": [
{ "role": "system", "content": "Ești un asistent care extrage clauze de reziliere din contracte în format JSON strict." },
{ "role": "user", "content": "Contractul se poate rezilia cu un preaviz de 30 de zile de către oricare parte." },
{ "role": "assistant", "content": "{\"clauza\": \"reziliere\", \"preaviz_zile\": 30}" }
]
}Am văzut prea des echipe de dev care sar direct la fine-tuning crezând că asta le va rezolva magic toate problemele de acuratețe. E o greșeală costisitoare și, de cele mai multe ori, un prompt engineering bine structurat rezolvă 90% din cazurile de utilizare. Hai să analizăm pe cifre și pe experiență reală unde tragem linia între ele și când merită cu adevărat să investești în antrenarea unui model.
Cazul meu real: 12.000 de documente pe lună
Anul trecut am lucrat la un proiect unde trebuia să extragem metadate din contracte juridice complexe. Prima reacție a echipei a fost: „Facem fine-tuning pe un Llama sau GPT-3.5, altfel n-avem șanse”.
Înainte să ne aruncăm la dataseturi și ore de GPU, am zis să facem un test. Am scris un system prompt extrem de riguros, am folosit tehnica Few-Shot (i-am dat modelului 3 exemple clare de „așa da” / „așa nu”) și am activat Structured Outputs (JSON Schema) pe GPT-4o.
Rezultatul? Am obținut o acuratețe de 94% din prima săptămână de teste. Costul de dezvoltare? Câteva ore de bibilit promptul și vreo 15 dolari consumați pe API. Dacă mergeam pe fine-tuning din prima, doar curățarea datelor ne lua două săptămâni.
Trade-off-ul sincer: Flexibilitate vs. Cost de rulare
Prompt engineering-ul are un avantaj uriaș: este instant. Ai modificat o linie în prompt, ai dat deploy și modelul se comportă diferit.
Dar vine cu un cost ascuns. Dacă pentru fiecare request trebuie să trimiți un context uriaș (instrucțiuni de 2000 de tokeni plus exemple), factura de API o să înceapă să doară la volum mare. În plus, latența crește direct proporțional cu numărul de tokeni din input.
Aici intervine utilitatea unui fine-tuning:
- Reducerea latenței: Nu mai trimiți contextul uriaș la fiecare request. Modelul deja „știe” formatul și stilul.
- Economie de tokeni: Poți scurta promptul de input cu 80%, ceea ce pe termen lung scade costurile de rulare masiv.
- Consistență extremă: Un model fine-tuned pe 500 de exemple perfecte va respecta formatul JSON mult mai bine decât un model generalist ghidat doar de prompt.
Când merită să faci pasul spre Fine-Tuning?
Nu folosi fine-tuning ca să-i oferi modelului cunoștințe noi. Dacă ai nevoie ca modelul să știe regulamentul intern al companiei tale sau prețurile din baza de date, folosești RAG (Retrieval-Augmented Generation). Fine-tuning-ul este pentru a învăța modelul cum să se comporte, nu ce să știe.
Investește în fine-tuning doar când ai deja un dataset curat (minimum 100-200 de exemple de calitate superioară), când ai validat logica aplicației prin prompt engineering și când costul tokenilor de input la volum mare depășește costul estimat pentru rularea unui model custom.
La un alt proiect, trecerea de la un prompt gigant pe GPT-4 la un GPT-3.5 fine-tuned ne-a redus costurile cu 65% și latența de la 3 secunde la sub o secundă, păstrând aceeași calitate a output-ului. Dar asta doar pentru că știam exact ce format vrem.
Concluzia mea e simplă: începe mereu cu prompt engineering. Când te lovești de limitări de buget sau de latență la volume mari, abia atunci deschide portofelul pentru fine-tuning.
Voi ați trecut prin procesul ăsta? Cât de repede ați abandonat prompt-urile simple în favoarea unui model antrenat?