Ce este Prompt Engineering în producție

Același prompt care merge impecabil în timpul unui demo poate începe să returneze JSON invalid a doua zi, în producție, fără ca nimeni să fi schimbat o linie de cod — iar echipa pierde ore întregi vânând un bug care nu există în cod, ci în felul în care a fost formulată instrucțiunea. Exact aici se vede diferența dintre cineva care „vorbește frumos" cu un LLM și inginerul care tratează prompt-ul ca pe un contract operațional reproductibil: cu intrări definite, ieșiri garantate și comportament testabil. În 2026, când GPT-5.6 Sol, Claude Opus 5 și Gemini 3.1 Pro alimentează milioane de fluxuri de producție, tocmai această diferență separă demo-ul impresionant de produsul stabil.

De ce prompt engineering este inginerie, nu artă

Termenul „prompt engineering" a evoluat radical față de 2023-2024. Atunci, un prompt bun însemna să formulezi o întrebare mai deștept decât media. Astăzi, în producție, un prompt este un contract formal între aplicația ta și modelul de limbaj. Acest contract specifică:

• Intrările acceptate — ce date primește modelul și în ce format
• Comportamentul așteptat — ce transformare trebuie aplicată
• Ieșirile garantate — structura exactă a răspunsului (JSON, Markdown, CSV etc.)
• Constrângerile de siguranță — ce NU trebuie să facă modelul sub nicio formă

Gândiți-vă la o funcție software clasică: are parametri de intrare, logică internă, tip de returnare și gestionare de erori. Un prompt de producție respectă exact aceeași paradigmă. Diferența este că „logica internă" este un model stochastic cu sute de miliarde de parametri — ceea ce face specificația contractului și mai critică.

Conversație vs. Producție — două lumi diferite

Când un dezvoltator testează Claude Opus 5 într-o conversație și obține un răspuns impresionant, aceasta nu demonstrează că promptul va funcționa în producție. Demo-ul beneficiază de context conversațional, de reformulare iterativă și de toleranță subiectivă. Producția nu are niciuna dintre aceste plase de siguranță.

De ce modelele impresionează în demo dar dezamăgesc fără prompt bun

Există un fenomen pe care îl numim „iluzia demo-ului". Un model precum GPT-5.6 Sol sau Claude Opus 5 poate genera răspunsuri remarcabile într-o sesiune interactivă, dar același model, fără un prompt riguros, produce inconsistențe sistematice la scară:

1. Lipsa ancorării formatului — Fără specificație explicită, modelul „decide" singur formatul răspunsului. La 10 apeluri, veți primi 10 formate diferite.

2. Deriva semantică — Pe parcursul a mii de apeluri, modelul interpretează instrucțiuni ambigue în moduri subtil diferite, generând o „derivă" greu de detectat.

3. Sensibilitate la ordine — Ordinea informațiilor din prompt influențează dramatic output-ul. Ce funcționează cu 3 exemple poate eșua cu 5.

4. Regresii la actualizări — Când providerul actualizează modelul (de exemplu, de la GPT-5.4 la GPT-5.5, sau de la Claude Opus 4.7 la 4.8 cu tokenizer nou care poate produce un număr diferit de tokeni pentru același text), prompturile nerobuste se pot „sparge" complet — atât semantic cât și ca buget.

# Exemplu: prompt fragil (NU faceți așa în producție)
Clasifică acest ticket de suport: "{ticket_text}"
Spune-mi categoria.

# Problemă: modelul poate răspunde:
# - "Categoria este: Facturare"
# - "Aceasta pare a fi o problemă de facturare."
# - "FACTURARE"
# - "Cred că ține de departamentul de facturare, dar ar putea fi și..."

Lifecycle-ul unui prompt de producție

Un prompt de producție trece prin șase faze clare, similare oricărui artefact software:

1. Design (Proiectare)

Definiți contractul: intrări, ieșiri, constrângeri, cazuri limită. Scrieți prima versiune a prompt-ului bazându-vă pe task analysis, nu pe intuiție.

2. Test (Testare)

Rulați prompt-ul pe un set de evaluare (eval set) — minimum 50-100 de exemple reale. Măsurați metrici cantitative, nu impresii subiective.

3. Version (Versionare)

Stocați prompt-ul în Git alături de cod. Fiecare modificare primește un commit cu mesaj explicit: „v2.3 — adăugat constrângere limită caractere pentru câmpul sumar".

4. Deploy (Lansare)

Lansați prompt-ul în producție cu canary deployment — 5% din trafic inițial, apoi ramp-up gradual.

5. Monitor (Monitorizare)

Urmăriți metrici în timp real: rata de succes, cost mediu per apel, latență, rate de eroare pe categorii.

6. Rollback (Revenire)

Dacă noua versiune degradează performanța, reveniți instant la versiunea anterioară — exact ca un rollback de cod.

prompt-registry/
├── classifiers/
│   ├── ticket-classifier-v3.2.yaml
│   ├── ticket-classifier-v3.1.yaml    # rollback target
│   └── eval-sets/
│       ├── ticket-eval-200.jsonl
│       └── ticket-eval-edge-cases.jsonl
├── extractors/
│   └── invoice-extractor-v1.4.yaml
└── generators/
    └── email-reply-v2.0.yaml

Metrici esențiale pentru prompt engineering

Nu puteți îmbunătăți ceea ce nu măsurați. Iată cele patru categorii fundamentale de metrici:

Format Adherence (Aderență la format)

Procentul de răspunsuri care respectă exact structura cerută. Dacă cereți JSON cu 5 câmpuri specifice, măsurați câte răspunsuri din 1000 sunt JSON valid cu exact acele câmpuri.

Target producție: >99.5% pentru formate stricte (JSON, CSV), >97% pentru formate semi-structurate.

Task Success Rate (Rata de succes a task-ului)

Procentul de răspunsuri corecte semantic — nu doar formatate bine, ci și corecte. Un JSON perfect formatat care clasifică un ticket de „Facturare" ca „Suport tehnic" este un eșec.

Target producție: Depinde de domeniu. Clasificare simplă: >95%. Extracție date complexe: >90%. Generare text creativ: evaluare umană necesară.

Cost per Task (Cost per sarcină)

Costul total al unui apel: tokeni input × preț input + tokeni output × preț output. În 2026, prețurile variază dramatic:

Policy Violations (Încălcări de politică)

Procentul de răspunsuri care încalcă regulile stabilite: generează conținut interzis, divulgă informații din system prompt, depășesc limitele temei etc.

Target producție: 0% toleranță pentru încălcări critice. <0.1% pentru încălcări minore.

Exemplu complet: Clasificator de tickete cu JSON output

Să construim un prompt de producție real — un clasificator de tickete de suport care returnează JSON structurat.

# ticket-classifier-v3.2.yaml
model: gpt-5.6-sol
temperature: 0
max_tokens: 256

system_prompt: |
  Ești un clasificator automat de tickete de suport IT.

  TASK: Clasifică fiecare ticket în exact una dintre categoriile:
  HARDWARE, SOFTWARE, REȚEA, SECURITATE, CONT_UTILIZATOR, ALTELE.

  REGULI:
  1. Răspunde EXCLUSIV cu JSON valid.
  2. Nu adăuga explicații, comentarii sau text suplimentar.
  3. Câmpul "confidence" este un float între 0.0 și 1.0.
  4. Câmpul "subcategory" este opțional — include-l doar dacă poți fi specific.
  5. Dacă ticketul este ambiguu, alege categoria dominantă și setează confidence < 0.7.

  FORMAT OBLIGATORIU:
  {
    "category": "CATEGORIA",
    "subcategory": "subcategorie_opțională",
    "confidence": 0.95,
    "language": "ro|en|hu|de"
  }

user_prompt_template: |
  Clasifică următorul ticket:

  ---
  {ticket_text}
  ---

Rezultate pe eval set (200 tickete):

• Format adherence: 99.8% (1 singur răspuns cu virgulă lipsă — remediat cu retry)
• Task success: 94.5% (11 tickete clasificate greșit, 8 dintre ele cu confidence < 0.7 — corect semnalate ca ambigue)
• Cost mediu: $0.00195 per ticket (GPT-5.6 Sol, ~150 tokeni input, ~40 tokeni output)
• Policy violations: 0%

Calibrare cross-model: GPT-5.6 Sol vs Claude Opus 5 vs Gemini 3.1 Pro

Un prompt de producție robust trebuie testat pe multiple modele — fie pentru redundanță (failover), fie pentru optimizare de cost. Același prompt de clasificare, rulat pe trei modele:

Observații practice:

• Claude Opus 5 (top-ul familiei Opus, lansat 24 iulie 2026; cel mai capabil model Anthropic este Claude Fable 5) are cea mai bună acuratețe la cost similar cu GPT-5.6 Sol ($5/$25 input/output). Atenție la tokenizer-ul nou (introdus din 4.7): poate produce un număr diferit de tokeni pentru același text — recalibrați bugetele. Folosiți Opus 5 pentru cazurile escalate (confidence < 0.7).
• Gemini 3.1 Pro este cel mai ieftin și rapid, dar are format adherence ușor mai scăzut — necesită un layer de validare JSON mai robust.
• Strategia optimă: Gemini 3.1 Flash Lite pentru volumul mare (>90% din tickete), cu fallback la Claude Opus 5 pentru cazurile ambigue.

Instrumente moderne pentru prompt engineering în 2026

Ecosistemul de instrumente a maturat semnificativ:

• LangSmith — Platformă completă de observabilitate: traces, evaluări automate, comparații A/B între versiuni de prompturi
• Braintrust — Eval framework cu suport nativ pentru scoring funcțional și comparație cross-model
• Promptfoo — Open-source, CLI-first, ideal pentru integrare în CI/CD pipeline-uri
• Anthropic Console — Workbench cu generator și îmbunătățire automată de prompturi, plus evaluări integrate direct în platforma API

Ce urmează

Până acum ai văzut de ce un prompt de producție este un contract, nu o conversație — dar a numi cele patru clauze ale unui contract nu este totuna cu a le proiecta astfel încât să reziste la intrări reale. Cele 6 componente fundamentale care transformă o instrucțiune vagă într-un contract operațional robust sunt exact locul în care majoritatea prompturilor se rup în producție, fără să pară. În lecția următoare le disecăm pe rând și construim primul prompt cu adevărat modular, reutilizabil și testabil — iar de aici, fiecare lecție adaugă o piesă la sistemul de prompting pe care, la final, îl vei putea susține în fața oricărei echipe.