Văd des discuția asta pe forumuri și prin call-uri: „băieți, merită să facem fine-tuning sau ne chinuim cu un system prompt lung?”. Am trecut prin dilema asta anul trecut, la un proiect unde trebuia să procesăm mii de documente juridice zilnic, și am învățat pe banii noștri când merită să spargi bugetul pe antrenare și când e doar un moft. Spoiler: de cele mai multe ori, e doar un moft.
Când e suficient un prompt bun (și de ce să te oprești acolo)
Să fim sinceri. Prompt engineering-ul a devenit aproape o glumă printre devii „serioși”, dar adevărul e că modelele actuale (GPT-4o, Claude 3.5 Sonnet) sunt incredibil de capabile să înțeleagă instrucțiuni complexe din prima. Dacă ai nevoie de un ton specific, de o structură anume sau de niște reguli de business clare, un system prompt bine structurat, eventual cu tehnici de tip Few-Shot (adică îi dai 2-3 exemple de „așa da/așa nu” direct în prompt), rezolvă problema în 90% din cazuri.
Am avut un tool intern de suport tehnic pentru vreo 5.000 de utilizatori activi. Am început direct cu ideea de fine-tuning, că sună bine în CV. Ne-am blocat repede în colectarea datelor. Până la urmă, am rezolvat totul cu un system prompt XML-structured de vreo 800 de tokeni și RAG (Retrieval-Augmented Generation) pentru documentație. Timp de implementare? Trei zile. Costuri de development? Aproape zero.
Când devine fine-tuning-ul o necesitate reală
Trecerea la fine-tuning nu se face pentru că modelul „nu știe destule”, ci din două motive mari: costul tokenilor pe termen lung și latența.
Am avut un alt proiect, un parser de fișe medicale nestructurate care trebuia să scuipe un JSON extrem de strict pentru un sistem legacy. Ca să determinăm modelul (pe atunci GPT-4) să respecte structura fără să dea erori de parsare, aveam un system prompt mamut, plus vreo 5 exemple gigantice de input/output. Consumam cam 4.000 de tokeni doar pe instrucțiuni la fiecare request. La un volum de 20.000 de request-uri pe zi, factura OpenAI începea să arate ca o rată la bancă.
Aici a intrat în scenă fine-tuning-ul. Am strâns un set de date curat, cam 500 de exemple bune. Am făcut fine-tune pe un model mai mic și mai ieftin. Rezultatul?
- Am redus promptul de la 4.000 de tokeni la doar 150.
- Latența a scăzut de la 4 secunde la sub 1 secundă.
- Am economisit aproape 70% din costurile lunare de API, amortizând costul de antrenare în mai puțin de trei săptămâni.
Trade-off-ul sincer pe care nu-ți-l spune nimeni
Fine-tuning-ul vine cu o grămadă de dureri de cap ascunse. În primul rând, e un proces rigid. Dacă se schimbă cerințele de business săptămâna viitoare, la prompt engineering schimbi trei rânduri de text și ai terminat. La fine-tuning? Trebuie să refaci setul de date, să reantrenezi modelul și să-l redeploiezi.
În al doilea rând, fine-tuning-ul nu este o bază de cunoștințe. Dacă vrei ca modelul tău să știe prețurile produselor tale actualizate la zi, NU îi faci fine-tuning. Modelul va începe să halucineze fapte vechi din dataset-ul de antrenare. Pentru informații dinamice, RAG-ul (bază de date vectorială + prompt) bate fine-tuning-ul de la distanță.
Pe scurt, folosești prompt engineering când vrei flexibilitate, iterație rapidă și ai volum mic de request-uri. Treci la fine-tuning doar când vrei să înveți un model cum să se comporte (stil, format rigid, jargon specific) pe un model mai ieftin, reducând costurile de rulare la volume mari.
Voi ce experiențe aveți? Ați trecut prin procesul de fine-tuning doar ca să vă dați seama că un prompt bun făcea același lucru, sau chiar v-a salvat bugetul?