interface FewShotExample {
input: string;
output: string;
}
export function buildSystemPrompt(instruction: string, examples: FewShotExample[]): string {
const examplesBlock = examples
.map(ex => `Input: ${ex.input}\nOutput: ${ex.output}`)
.join("\n---\n");
return `${instruction}\n\nUrmează câteva exemple de comportament dorit:\n\n${examplesBlock}`;
}Am văzut prea des echipe de dev-i care sar direct la fine-tuning de cum dau de o problemă mai complexă cu LLM-urile. E o greșeală costisitoare pe care am făcut-o și eu acum doi ani la un startup de analiză financiară. Hai să îți spun cum am pierdut o lună de zile și vreo 4.000 de dolari pe fine-tuning ca să ne dăm seama că o structură mai bună de prompt rezolva totul în 10 minute.
Mitul "învățării" prin fine-tuning
Cea mai mare confuzie pe care o văd pe forumuri e legată de ce face de fapt fine-tuning-ul. Mulți cred că e modul prin care „înveți” modelul cunoștințe noi. Fals. Fine-tuning-ul este excelent pentru a învăța modelul cum să se comporte, ce stil să adopte și ce format să respecte, nu ce să știe.
La proiectul de care ziceam, aveam de extras entități din rapoarte financiare extrem de nișate. Am strâns un set de date de 5.000 de exemple manual etichetate și am antrenat un model GPT-3.5 Davinci. Rezultatul? Halucina la fel de mult pe cifre, dar măcar le formata frumos în JSON. Am rezolvat problema aducând datele relevante în context prin RAG (Retrieval-Augmented Generation) și scriind un prompt clar, cu exemple de tip "few-shot".
Când te oprești la Prompt Engineering
Pentru 90% din cazurile de utilizare, prompt engineering-ul combinat cu RAG e tot ce ai nevoie. Este ieftin, modificările se fac în secunde și poți folosi modele de ultimă generație (cum e GPT-4o sau Claude 3.5 Sonnet) direct prin API, fără să îți bătătorești capul cu hosting sau costuri de antrenare.
Merge brici pentru:
- Traduceri de ton sau stil pe volume rezonabile de text.
- Extragere de date unde contextul încape lejer în fereastra de tokeni.
- Prototipuri rapide unde vrei să validezi ideea în două zile, nu în două luni.
Trade-off-ul? Plătești mai mult pe context (input tokens) pentru că trebuie să trimiți instrucțiuni lungi și exemple de fiecare dată. Dacă ai 100 de cereri pe zi, e irelevant. Dacă ai 80k de useri activi zilnic, povestea se schimbă radical.
Când merită să spargi pușculița pentru Fine-tuning
Sunt doar câteva scenarii clare unde fine-tuning-ul își scoate banii în producție:
- Reducerea drastică a latenței și a costurilor la volum mare. Dacă ai un prompt de 3.000 de tokeni pe care îl trimiți de un milion de ori pe lună, costurile de API te omoară. Prin fine-tuning pe un model mai mic (cum e Llama-3-8B sau GPT-4o-mini), poți reduce promptul la 50 de tokeni. Modelul știe deja comportamentul din antrenare. Am economisit așa peste 35% din costurile lunare de rulare la un serviciu de clasificare de tichete.
- Sintaxă și formate ultra-stricte. Dacă ai nevoie ca modelul să scoată un limbaj de programare exotic sau un JSON super specific pe care prompturile normale îl mai "ratează" din când în când.
- Performanță pe un task extrem de specific unde modelele generale pur și simplu nu au destulă "atenție" chiar și cu few-shot learning.
Concluzia mea?
Pornește mereu de la prompt engineering și RAG. Stoarce tot ce poți din ele, optimizează instrucțiunile, folosește tehnici de chain-of-thought. Abia când te lovești de limita de tokeni, de costuri insuportabile de API sau de o latență prea mare pe un volum uriaș, abia atunci deschide tab-ul de fine-tuning.
Voi ce experiențe ați avut? A reușit cineva să obțină rezultate mai bune cu un model fine-tuned pe un task general decât cu un prompt bine scris pe GPT-4?