{
"prompt_engineering_few_shot": {
"system": "Ești un asistent util. Clasifică feedback-ul în: POZITIV, NEGATIV, NEUTRU.",
"examples": [
{"user": "Aplicația se mișcă super bine!", "assistant": "POZITIV"},
{"user": "Nu pot să mă loghez deloc.", "assistant": "NEGATIV"}
],
"input": "Butonul de checkout dă eroare 500."
},
"fine_tuning_dataset_line": {
"messages": [
{"role": "system", "content": "Clasificator tichete v1."},
{"role": "user", "content": "Butonul de checkout dă eroare 500."},
{"role": "assistant", "content": "NEGATIV"}
]
}
}Să fim sinceri: în ultima vreme, „fine-tuning” a devenit un fel de buzzword pe care toți clienții non-tehnici îl aruncă în discuții când vor un chatbot. Am avut anul trecut un proiect unde clientul voia neapărat fine-tuning pe GPT-3.5 pentru un clasificator de tichete, deși un prompt bine structurat cu 3 exemple (few-shot) rezolva problema cu o acuratețe de 94%. Am economisit atunci vreo două săptămâni de muncă și câteva sute de dolari doar explicându-i diferența reală dintre cele două abordări.
Cât de departe poți merge cu un prompt bun?
Răspunsul scurt: incredibil de departe. Cu ferestrele de context actuale (de la 128k la 1M de tokeni), poți îndesa o tonă de informație într-un prompt de sistem. Poți să-i dai reguli stricte de formatare, tone-of-voice, ba chiar și un mini-ghid de proceduri interne.
Dacă ai nevoie ca modelul să respecte un anumit stil sau să clasifice date după reguli clare, adaugă 3-5 exemple concrete în prompt (tehnica numită few-shot prompting). Pentru 90% din aplicațiile web obișnuite, asta e tot ce ai nevoie ca să livrezi valoare rapid.
Trade-off-ul? Latența și costul per token. Dacă trimiți la fiecare request un prompt de sistem de 4000 de tokeni ca să obții un răspuns de 50 de tokeni, factura la OpenAI sau Anthropic o să doară la final de lună. Plus că timpul de răspuns (Time to First Token) crește direct proporțional cu dimensiunea promptului de intrare.
Când merită să deschizi portofelul pentru fine-tuning?
Fine-tuning-ul nu înseamnă că înveți modelul cunoștințe noi. Pentru cunoștințe folosești RAG (Retrieval-Augmented Generation). Fine-tuning-ul înseamnă că antrenezi modelul să se comporte într-un anumit fel, să adopte un stil extrem de specific sau să reducă costurile de rulare.
Am avut un caz la un proiect cu 15k request-uri pe zi. Trimiteam un prompt masiv de system pe GPT-4 ca să formatăm output-ul într-un JSON foarte ciudat, cerut de un API legacy. Am trecut la un fine-tune pe Llama 3 8B (pe care îl rulăm pe instanța noastră). Am redus costurile cu API-ul la zero (plătim doar VPS-ul, în jur de 80$ pe lună) și latența a scăzut de la 2.1 secunde la sub 600ms.
Investești în fine-tuning când:
- Vrei să elimini promptul de sistem uriaș ca să reduci latența și costurile de tokeni.
- Modelul de bază ratează constant formatul de output (de exemplu, dă JSON invalid o dată la 100 de rulări).
- Ai nevoie de un ton extrem de specific pe care nu-l poți descrie ușor în cuvinte (ex: stilul de scriere al unui autor anume, bazat pe mii de articole anterioare).
Costul ascuns de care nu-ți spune nimeni
Să faci fine-tuning ca la carte e greu. Ai nevoie de un set de date curat. Nu vorbesc de 10 rânduri într-un Excel, ci de cel puțin 500 - 1000 de perechi de prompt-răspuns corectate manual. Dacă bagi în antrenament date proaste sau inconsistente, modelul o să devină mai prost decât era în starea inițială.
În plus, ești blocat pe acel model. Dacă OpenAI scoate o versiune nouă de GPT, trebuie să o iei de la capăt cu antrenamentul pe noul model de bază.
Voi ce folosiți mai des în producție? V-ați lovit de limitările prompt-urilor sau ați fost nevoiți să treceți direct la fine-tune?