eduardweb.
AI & LLMsIntermediar#ai#openai#prompt-engineering#fine-tuning#llm

Prompt engineering vs fine-tuning: Când arunci cu bani în modele și când ajunge un prompt bun

De Corina Dobre, 3 aug. 2026 · 10 vizualizări · 2 like-uri

Postat 3 aug. 2026
typescript
import OpenAI from 'openai';

const openai = new OpenAI();

// Varianta 1: Prompt Engineering (plătești tokeni de sistem la fiecare call)
export async function classifyWithPrompt(userText: string) {
  return await openai.chat.completions.create({
    model: 'gpt-4o-mini',
    messages: [
      {
        role: 'system',
        content: 'Ești un classifier pentru tichete IT. Reguli: ... [peste 1500 tokeni de context și prim-exemple]'
      },
      { role: 'user', content: userText }
    ],
    temperature: 0.1
  });
}

// Varianta 2: Fine-Tuned Model (prompt minim, regulile sunt deja în weights)
export async function classifyWithFineTune(userText: string) {
  return await openai.chat.completions.create({
    model: 'ft:gpt-4o-mini-2024-07-18:org-id:ticket-classifier:v1',
    messages: [
      { role: 'user', content: userText }
    ],
    temperature: 0.1
  });
}

Aproape săptămânal văd pe forum sau prin comunități colegi care vor să sară direct la fine-tuning imediat ce GPT-4o sau Claude nu le dă exact formatul dorit. Am fost și eu fix în papucii ăștia anul trecut, la un proiect unde procesam vreo 40.000 de tichete de suport pe lună și ne rodea costul tokenilor de sistem.

Regula mea de aur după 3 ani de joacă cu LLM-uri în producție e simplă: începi mereu cu prompt-ul și treci la fine-tuning doar când te strânge pantoful la bani sau la latență.

Când e suficient un prompt bun (plus Few-Shot)

Să fim sinceri: 90% din cazurile din producție se rezolvă cu un System Prompt structurat impecabil, 2-3 exemple concrete (Few-Shot) și eventual un RAG ieftin.

Dacă aplicația ta nu are nevoie de un stil de scriere ultra-specific sau de un vocabular tehnic obscur pe care modelul de bază nu îl cunoaște, nu ai niciun motiv să te complici. Am văzut echipe pierzând săptămâni întregi construind dataset-uri de fine-tuning doar pentru că nu știau să folosească JSON Mode sau librării ca Zod / Instructor ca să forțeze schema de output.

Câștigul la prompt engineering e viteza de iterare. Schimbi două rânduri în text, dai deploy în mediu de staging și în 10 secunde vezi rezultatul. Dacă ai un volum mic spre mediu (sub 10.000 de request-uri pe zi), costul de API e insignifiant pe lângă salariul tău de dev.

Când merită să faci fine-tuning pe bune

Există însă un prag unde prompt engineering-ul devine o cârpă scumpă și lentă. Am pățit-o când prompt-ul nostru de sistem ajunsese la 2.500 de tokeni doar ca să acopere toate cazurile particulare, excepțiile din business și formatările speciale. Plăteam contextul ăla uriaș la fiecare request.

Fine-tuning-ul devine obligatoriu sau rentabil în câteva scenarii clare:

  1. Latență critică: Trebuia să coborâm timpul de răspuns sub 400ms. GPT-4o ne dădea 1.2-2 secunde. Am luat un model de 8B (Llama 3 sau Mistral), i-am făcut fine-tune cu LoRA pe 2.000 de exemple perfect curate și l-am ridicat pe vLLM. Latența a scăzut la 280ms.
  2. Reducerea masivă a costurilor: Când trimiți 2.000 de tokeni de instrucțiuni la fiecare call, la 100.000 de call-uri pe lună te usucă. După fine-tune, instrucțiunile sunt băgate direct în ponderile modelului (weights). Prompt-ul tău devine doar intrările brute de date. Am economisit aproape 65% din bill-ul de cloud.
  3. Respectarea strictă a stilului sau domeniului: Dacă vrei ca modelul să vorbească exact în jargonul medical românesc sau să genereze cod într-un DSL intern fără să-i reamintești la fiecare pas regulile.

Trade-off-ul de care nu-ți spune nimeni

Toată lumea vorbește despre cât de ieftin e rulajul după ce ai modelul tău customizat, dar puțini menționează mentenanța. Un prompt îl schimbi în Git în două secunde. Un model fine-tuned e o ancoră:

  • Ai nevoie de o infrastructură de evaluare (Evals). Fără un set automatizat de teste, nu știi dacă noul fine-tune nu a suferit de catastrophic forgetting pe alte cazuri.
  • Dataset-ul e greu de menținut. Dacă se schimbă o regulă de business, trebuie să re-etichetezi datele și să re-antrenezi.
  • Base models se schimbă rapid. Un fine-tune făcut pe GPT-3.5 acum un an e azi mai slab și mai scump decât GPT-4o-mini direct din cutie.

Dacă nu ai cel puțin 1.000-2.000 de exemple validate manual și un volum serios în producție, rămâi pe prompt engineering.

Voi la ce volum sau latență ați simțit că prompt-ul nu mai e de ajuns și ați trecut la fine-tuning?

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

Doar membrii comunității pot lăsa comentarii.