{
"messages": [
{
"role": "system",
"content": "Ești un parser de erori. Returnează strict codul intern și severitatea."
},
{
"role": "user",
"content": "Timeout connecting to DB replica 10.0.4.12 after 5000ms"
},
{
"role": "assistant",
"content": "{\"err_code\": \"ERR_DB_TIMEOUT\", \"severity\": \"HIGH\"}"
}
]
}Am văzut prea multe echipe care sar direct la fine-tuning doar pentru că sună mai „enterprise”, deși problema lor se rezolva lejer cu trei exemple bine alese într-un system prompt. Fine-tuning-ul nu e o baghetă magică prin care modelul învață cunoștințe noi, ci o metodă prin care îi schimbi forma răspunsului și stilul. Dacă ai nevoie de logică sau date actualizate, începi din direcția greșită.
Când prompt engineering-ul e mai mult decât suficient
Pentru 90% din cazurile de utilizare comune (extragere de date, clasificare, sumarizare sau generare de copy), prompt engineering combinat cu RAG (Retrieval-Augmented Generation) bate orice fine-tune la raportul efort/rezultat. Ieși mult mai ieftin și iterezi în câteva minute, nu în câteva zile.
La o aplicație cu vreo 35.000 de cereri pe lună unde trebuia să extragem date structurate din facturi scanate, prima idee din echipă a fost: „hai să facem fine-tune pe Llama”. Am zis pas. Am scris un prompt de 400 de tokeni, am definit un JSON schema strict via Structured Outputs pe GPT-4o-mini și am obținut o acuratețe de 98.5%. Cost total: sub 15 dolari pe lună. Dacă făceam fine-tuning, pierdeam două săptămâni curățând date, plus costul de hosting pentru modelul dedicat.
Trade-off-ul e evident: plătești la fiecare request tokenii din prompt. Dacă instrucțiunile tale au 3.000 de tokeni și le trimiți de un milion de ori pe zi, factura de API o să te usture rapid.
Când devine obligatoriu să faci fine-tune
Fine-tuning-ul începe să aibă sens când te lovești de două bariere majore: latența și volumul de date.
Am avut un caz la un sistem de procesare a log-urilor în timp real. Aveam nevoie de clasificare strictă pe 40 de categorii interne, iar un prompt few-shot funcționa, dar adăuga 1.200 de tokeni la fiecare apel. La 400.000 de cereri pe zi, latența era de 900ms pe request, iar costurile săriseră de 2.000 de dolari pe săptămână.
Am adunat 2.000 de exemple curate, am rulat un fine-tuning pe un model mic (Mistral 7B) și am redus promptul la doar 30 de tokeni. Modelul știa deja categoriile pe de rost, stilul de răspuns și cazurile limită.
Rezultatele după migrare:
- Latența a scăzut de la 900ms la sub 140ms.
- Costul de inference a scăzut cu aproximativ 70%.
- Acuratețea a rămas identică cu cea a modelului mare.
Partea proastă? Curățarea dataset-ului a fost un coșmar manual. Dacă bagi 100 de exemple proaste sau contradictorii într-un set de 2.000, modelul va învăța prostiile alea cu o precizie înfiorătoare.
Regula practică după care mă ghidez
Traseul sănătos este întotdeauna incremental:
- Faci zero-shot prompt. Vezi unde crapă.
- Adaugi 3-5 exemple concrete (few-shot) și folosești structured outputs. În 8 din 10 cazuri te oprești aici.
- Dacă modelul halucinează pe date factuale din companie, pui RAG, nu fine-tuning.
- Faci fine-tuning doar dacă modelul știe ce are de făcut, dar promptul e prea lung, latența te omoară sau vrei să cobori de la un model gigantic la unul mic pe care îl găzduiești tu.
Voi ați prins proiecte unde fine-tuning-ul a meritat cu adevărat investiția, sau s-a dovedit mai mult un exercițiu de palmares tehnic?