# Exemplu de Few-Shot Prompting care adesea bate un model slab fine-tuned
system_prompt = """
Ești un asistent care extrage date financiare.
Urmează formatul exact din exemplele de mai jos:
Exemplu 1:
Input: 'Am plătit 50 RON pe cafea la Starbucks pe 12 mai.'
Output: {"suma": 50, "valuta": "RON", "vendor": "Starbucks", "data": "2024-05-12"}
Exemplu 2:
Input: 'Factura de curent de 320 lei de la Enel din iunie.'
Output: {"suma": 320, "valuta": "RON", "vendor": "Enel", "data": "2024-06-01"}
"""
# Dacă asta nu merge după 10-20 de exemple, abia atunci te gândești la fine-tuning.Am văzut mulți colegi care sar direct la fine-tuning de GPT-4 sau Llama 3 imediat ce promptul dă un rateu. E o greșeală costisitoare și, de cele mai multe ori, total inutilă. Dacă vrei să salvezi timp și vreo câteva mii de euro, merită să înțelegi unde se termină magia cuvintelor și unde începe antrenarea serioasă.
La un proiect de acum un an, trebuia să extragem date din niște contracte stufoase. Am început direct cu ideea de fine-tuning pentru că, deh, suna bine în raportul către client. După două săptămâni de curățat date și vreo 400 de dolari aruncați pe joburi de antrenare, am realizat că un prompt bine structurat cu Few-Shot prompting (adică 3-5 exemple clare în context) scotea rezultate identice. Ba chiar mai bune, că puteam schimba regulile în 5 secunde, nu trebuia să re-antrenez modelul.
Prompt engineering nu e doar „scrie frumos”
E vorba de context management. Dacă ai un model cu 128k context, poți să-i dai tone de informații. Problema e latența și prețul pe token. Dacă promptul tău are 10k tokens și îl rulezi de un milion de ori pe lună, factura de la OpenAI o să te facă să plângi. Aici intervine calculul matematic: costul de inferență pe un prompt lung vs. costul de inferență pe un model fine-tuned mai mic (de exemplu, un GPT-4o-mini sau un Llama-8B).
Prompt engineering-ul câștigă detașat când ai nevoie de flexibilitate. Vrei să schimbi tonul? Modifici o frază. Vrei să adaugi o regulă nouă de business? O pui în system prompt. La fine-tuning, orice modificare mică înseamnă un alt job de antrenare și alt dataset pregătit.
Când chiar ai nevoie de Fine-Tuning
Marea confuzie pe care o văd e că lumea crede că fine-tuning-ul e pentru a „învăța” modelul informații noi. Greșit. Dacă vrei ca AI-ul să știe despre ultimele tale update-uri de API, folosești RAG (Retrieval Augmented Generation). Fine-tuning-ul e pentru formă, nu pentru fond.
L-am folosit cu succes când am avut nevoie de un output JSON extrem de strict care pica la validare în 20% din cazuri cu prompt engineering, oricât de mult m-aș fi chinuit. După fine-tuning pe vreo 500 de exemple perfecte, rata de eșec a scăzut sub 1%. E util și dacă vrei un stil de scriere foarte specific care nu poate fi descris ușor în cuvinte, sau dacă vrei să micșorezi costurile folosind un model mic care să se comporte ca unul mare pe o sarcină foarte îngustă.
Trade-off-ul sincer între timp și bani
Un job de fine-tune pe modelele de top nu e ieftin. Plus că ai nevoie de un set de date de calitate. Dacă bagi gunoi, scoți gunoi. Am economisit cam 30% la build time și costuri operaționale pe un proiect de analiză de sentimente trecând de la un prompt complex pe GPT-4 la un fine-tune pe un model mai mic și mai rapid. Dar pregătirea dataset-ului a durat 3 zile de muncă manuală de verificare a etichetelor.
A meritat? Da, pentru că aveam volum mare, peste 50k de request-uri pe zi. Pentru un tool intern folosit de 10 oameni, e o nebunie curată să te apuci de fine-tuning. Rămâi la un prompt solid, eventual un RAG dacă ai documentație multă, și dormi liniștit noaptea.
Tu ai încercat să faci fine-tune pentru ceva ce s-ar fi rezolvat cu un prompt mai bun, sau ai găsit un use-case unde fine-tuning-ul a fost singura salvare?