// 1. Abordarea cu Prompt Engineering (Plătești instrucțiuni la fiecare request)
const promptEngPayload = {
model: "gpt-4o",
messages: [
{ role: "system", content: "Ești un expert financiar. Extrage datele în JSON. Respectă schema: {venit: number, profit: number}. NU returna markdown. Iată 3 exemple: ... (încă 1000 de cuvinte de context) ..." },
{ role: "user", content: "Raport pe Q3: venituri de 50k..." }
]
};
// 2. Abordarea cu Model Fine-Tuned (Prompt minim, modelul știe deja formatul și tonul)
const fineTunedPayload = {
model: "ft:gpt-3.5-turbo-custom-financial-extractor",
messages: [
{ role: "system", content: "Extract financial JSON." },
{ role: "user", content: "Raport pe Q3: venituri de 50k..." }
]
};Salutare tuturor. Văd tot mai des pe grupuri și prin call-uri de consultanță obsesia asta cu "trebuie să facem fine-tuning pe datele noastre". De cele mai multe ori, e o gaură neagră de timp și de resurse. Am avut acum câteva luni un caz la un client cu un SaaS de analiză financiară. Echipa voia neapărat fine-tuning pe un model open-source ca să extragă date din rapoarte PDF. Estimaseră vreo două săptămâni de muncă doar pentru curățarea și etichetarea setului de date.
I-am oprit și am făcut un test rapid. Am scris un prompt solid de sistem, cu vreo trei exemple clare (few-shot prompting) și l-am rulat pe GPT-4o. Rezultatul? Acuratețe de peste 95% din prima zi, cu un cost de implementare de exact două ore de muncă.
Hai să fim sinceri: fine-tuning-ul nu este conceput pentru a învăța modelul informații noi. Pentru asta folosești RAG (Retrieval-Augmented Generation). Fine-tuning-ul este despre stil, format, constrângeri stricte de output și, cel mai important, optimizare de costuri la volum mare.
Când e de ajuns un prompt bun (și ieftin)
Dacă ai sub 5.000 de cereri pe zi și modelul trebuie doar să clasifice text, să schimbe tonul unui email sau să extragă entități într-un format JSON standard, rămâi la prompt engineering. Cu tehnicile potrivite – delimitatori XML clari și 2-3 exemple concrete de "input -> output" introduse direct în prompt – rezolvi 90% din cazuri.
Trade-off-ul sincer? Plătești mai mult pe tokenii de input din cauza contextului lung și ai o latență ceva mai mare la fiecare request. Dar pentru validarea unui MVP, e sfânt. Nu te apuci să antrenezi un model când nici nu știi dacă ai product-market fit.
Când merită să treci la fine-tuning
Trecerea la fine-tuning devine rentabilă în două scenarii clare pe care le-am simțit pe pielea mea:
- Costurile cu tokenii de context te omoară la scară. La un proiect cu peste 8k utilizatori activi pe zi, trimiteam un prompt gigant de 4k tokeni la fiecare request doar ca să menținem tonul brandului și formatul JSON. Am făcut fine-tune pe un model mai mic. Am eliminat instrucțiunile lungi din prompt, scăzând dimensiunea contextului cu 70%. Am economisit aproape 30% din factura lunară la API, iar latența a scăzut la jumătate.
- Ai nevoie de o sintaxă extrem de specifică pe care promptul o uită. Dacă ai nevoie ca modelul să scoată un format de cod esoteric sau să respecte un protocol proprietar unde și o singură virgulă greșită strică parserul, prompt-ul clasic o să dea rateuri ocazional. Fine-tuning-ul îi "întărește" rețelei neuronale exact acele reguli de formatare.
Uite mai jos o comparație directă între cum arată payload-ul trimis către API în cele două cazuri. Diferența de dimensiune a promptului se traduce direct în bani economisiți la fiecare rulare.
Cum iei decizia?
Regula mea de aur e simplă: începe întotdeauna cu prompt engineering și eventual RAG. Dacă performanța e slabă, optimizează promptul. Dacă tot e slabă, adaugă mai multe exemple în context. Doar atunci când costul de rulare la volum mare depășește costul estimat de colectare a datelor și antrenare (care adesea înseamnă mii de dolari în timp de development și labeling manual), abia atunci deschizi tab-ul de fine-tuning.
Voi ce experiențe aveți? Ați încercat să faceți fine-tune și v-ați lovit de dataset-uri proaste, sau ați rezolvat totul direct din system prompt?