// Comparatie intre cele doua abordari
// 1. Prompt Engineering (Cost tokeni mare pe request)
const response = await openai.chat.completions.create({
model: "gpt-4",
messages: [
{ role: "system", content: "Esti un expert legal. Urmeaza aceste 15 reguli de stil... [instructiuni de 2000 tokeni]" },
{ role: "user", content: "Analizeaza contractul atasat." }
]
});
// 2. Fine-tuned Model (Prompt scurt, model specializat)
const responseFT = await openai.chat.completions.create({
model: "ft:gpt-3.5-turbo-0125:my-startup:legal-bot-v1",
messages: [
{ role: "user", content: "Analizeaza contractul atasat." }
// Stilul si regulile sunt deja 'hardcoded' in ponderile modelului
]
});M-am lovit de dilema asta anul trecut la un startup de legal-tech. Clienții voiau răspunsuri care să sune „ca un avocat”, nu ca un bot de suport generic. Prima reacție a echipei? „Hai să facem fine-tuning pe 500 de documente interne”. Spoiler: a fost un eșec costisitor și am pierdut vreo două săptămâni degeaba.
Înainte să sari cu cardul la OpenAI sau să închiriezi instanțe de A100 pe Lambda, trebuie să înțelegi unde se termină magia prompt-ului. Prompt engineering-ul nu e doar „scrie frumos”. E arhitectură pură. Dacă știi să folosești Few-Shot prompting (adică îi dai 3-5 exemple clare direct în context), rezolvi cam 80% din problemele de consistență. La proiectul ăla de legal, am trecut de la un fail total la un output chiar utilizabil doar schimbând System Prompt-ul și adăugând un format strict de JSON pentru output. Am economisit timp și nervi.
Fine-tuning-ul e pentru formă, nu pentru informație
Asta e cea mai mare greșeală pe care o văd în comunitate. Oamenii cred că dacă fac fine-tune pe baza lor de date de 10GB, modelul o să „știe” totul pe de rost. Nu funcționează așa. Modelul „uită” fapte sau halucinează cu o încredere incredibilă dacă încerci să-i injectezi cunoștințe noi doar prin fine-tuning.
Pentru informații proaspete, cifre exacte sau documentație internă, RAG (Retrieval-Augmented Generation) e regele. Am avut un caz unde am redus costurile cu 30% la build time și runtime trecând de la un model finetuned prost la un sistem cu vector database (folosisem Pinecone) și un prompt bine structurat. Fine-tuning-ul e ca și cum ai învăța un student să scrie în stilul lui Shakespeare, în timp ce RAG e ca și cum i-ai da studentului o bibliotecă întreagă și l-ai învăța cum să caute în ea.
Când merită să scoți banii din buzunar?
Există, totuși, situații unde prompt engineering-ul pur și simplu nu mai face față. Am investit în fine-tuning în trei scenarii clare:
- Stil și ton extrem de specifice: Când brandul are niște reguli de comunicare atât de complexe încât ai consuma 3000 de tokeni doar explicându-le la fiecare request.
- Latență și costuri la volum mare: Dacă ai 100k request-uri pe zi și prompt-ul tău are 2k tokeni de instrucțiuni, plătești o avere. Un model finetuned (chiar și un GPT-3.5 sau un Llama 3 de 8B) poate înțelege ce vrei de la el cu un prompt de doar 50 de tokeni.
- Sarcini de nișă: Am lucrat la un tool care genera cod într-un limbaj proprietar, un DSL intern. GPT-4 scotea prostii. După un fine-tune pe 1500 de exemple bune, modelul mic (Llama) a început să bată GPT-4 la acuratețe pe nișa aia.
Trade-off-ul sincer
Fine-tuning-ul e „garbage in, garbage out” pe steroizi. Dacă n-ai cel puțin 500-1000 de exemple curate, verificate de un om care știe meserie, mai bine stai potolit. E mult mai ieftin să optimizezi un prompt sau să îmbunătățești chunking-ul în RAG decât să re-antrenezi un model pentru că ai descoperit că datele tale de training erau pline de typo-uri.
În 9 din 10 cazuri, dacă modelul „nu te ascultă”, problema e la prompt, nu la model. Voi ce ați ales pentru ultimul proiect? V-a bătut fine-tuning-ul la buzunar sau ați rămas pe prompt-uri lungi și RAG?