S-a umplut LinkedIn-ul de experți în prompt engineering care promit marea cu sarea, în timp ce alții sar direct la fine-tuning de parcă au bugetul infinit al celor de la Microsoft. Am trecut prin ambele tabere anul trecut la un proiect cu vreo 12.000 de utilizatori activi și am învățat pe pielea mea unde se duc banii degeaba. Spoiler alert: de cele mai multe ori, o să vrei să eviți fine-tuning-ul cât de mult poți.
Când e de ajuns un prompt bun (și mult mai ieftin)
Am început proiectul cu ideea preconcepută că avem nevoie de un model customizat pentru suport tehnic pe nișa noastră de nișă (imprimante industriale 3D). Ne gândeam direct la un fine-tune pe GPT-3.5 sau vreun Llama-2 de 13B găzduit pe AWS. Din fericire, am zis să testăm mai întâi cu un system prompt bine structurat, un pic de RAG (Retrieval-Augmented Generation) și câteva exemple concrete în context (few-shot prompting).
A mers surprinzător de bine. Am realizat rapid că 90% din probleme se rezolvă dacă îi dai modelului contextul potrivit în momentul apelului. Prompt-ul nostru avea vreo 2.000 de tokeni cu tot cu documentația extrasă în timp real din baza de date vectorizată. Costul era minuscul, undeva la 0.02 dolari per apel la vremea respectivă. Dacă utilizatorul întreba ceva, baza de date vectorizată returna paragraful relevant, îl puneam în prompt, iar LLM-ul doar formata răspunsul frumos. N-am avut nevoie de niciun antrenament suplimentar pentru a obține acuratețe de peste 95%.
Când devine prompt-ul o problemă și trecem la fine-tuning
Trade-off-ul la prompt engineering e însă destul de dureros: plătești la fiecare request pentru acei tokeni de context. Când ai 50 de pagini de manual pe care modelul trebuie să le știe pe de rost la fiecare întrebare, prompt-ul devine uriaș. Pe lângă latența care crește groaznic (stai și câte 6-7 secunde după un răspuns), factura de la OpenAI sau Anthropic începe să arate ca o rată la bancă.
Aici intervine fine-tuning-ul. Noi am recurs la el când a trebuit să învățăm un model să genereze cod într-un limbaj proprietar de scripting pe care nu-l găseai pe internet. Am strâns un set de date de vreo 1.200 de exemple de tipul "input - cod corect".
Fine-tuning-ul nu e bun pentru a-i da modelului informații noi (pentru asta RAG-ul rămâne sfânt), ci pentru a-l învăța un stil specific, un format fix sau o sintaxă pe care altfel o greșește constant. După fine-tuning, am obținut un model care scria codul corect din prima, fără să-i mai dăm exemple în prompt la fiecare rulare. Am redus dimensiunea prompt-ului cu 70% și latența a scăzut sub o secundă.
Costurile ascunse pe care nu ți le spune nimeni
Dar atenție mare la calculul financiar. Pregătirea setului de date pentru fine-tune ne-a luat trei săptămâni de muncă manuală. Am stat să curățăm JSON-uri și să validăm răspunsuri greșite. Timpul unui dev senior costă mult mai mult decât diferența de preț pe tokeni pentru câteva luni de producție.
În plus, dacă furnizorul de cloud scoate o versiune nouă de model, munca ta de fine-tuning s-ar putea să devină inutilă. Adesea, trebuie să o iei de la capăt pe noul model de bază.
Ca regulă generală după care mă ghidez acum: începe mereu cu few-shot prompting combinat cu RAG. Dacă performanța e slabă din cauza formatului sau dacă costul tokenilor de input depășește 400-500 de dolari pe lună la volumul tău de trafic, abia atunci merită să deschizi editorul și să pregătești setul de date pentru fine-tuning.
Voi ce experiențe ați avut cu costurile astea în producție? A reușit cineva să scoată profit bunicel dintr-un model fine-tuned la volume mici?