„Acționează ca un data analyst senior cu 15 ani de experiență."

Dacă ai deschis vreodată o listă de „prompt-uri pentru analiști" pe LinkedIn, ai văzut formula. E repetată în peste 80% din postările virale din ultimele 18 luni. E aproape inutilă. Modelele din 2026 — GPT-5, Claude 4.5, Gemini 2.5 — nu mai au nevoie să fie convinse de roluri pentru sarcini tehnice. Ce contează e altceva.

Prompt engineering data analyst a evoluat tăcut, dincolo de bula influencerilor. Ce funcționează acum în munca reală — extragere de insight-uri din tabele, scris de SQL complex, validare de date, comentariu de varianță — sunt câteva pattern-uri care merită învățate, plus un set de obișnuințe care apar din experiență. Restul e folclor.

prompt engineering: De ce „acționează ca un expert" nu mai contează

În 2022-2023, când GPT-3.5 era ce aveam, instrucțiunile de rol funcționau pentru că modelele aveau probleme reale de calibrare. Spunându-i „ești un statistician", reduceai șansa să primești o pseudo-explicație populară.

În 2026, modelele frontier au capacitatea tehnică încorporată. Le poți cere direct: „scrie o interogare SQL care calculează retenția pe cohorte". Ce contează acum e contextul concret: ce dialect SQL, ce schemă, ce definește o cohortă în business-ul tău, ce edge case-uri trebuie tratate.

Diferența între un prompt mediu și unul excelent în 2026 nu mai e în primul rând. E în restul.

Cele cinci pattern-uri care chiar funcționează

1. Few-shot pe tipul tău de output

Cel mai puternic instrument la dispoziția unui data analyst. În loc să descrii ce vrei, arată un exemplu de input și un exemplu de output. Modelele învață mult mai eficient prin exemplu decât prin instrucțiune.

Input: tabel cu vânzări pe zile, ultimele 30 de zile
Output dorit: comentariu de 3 paragrafe, ton sobru,
include procente față de săptămâna anterioară,
fără superlative, fără "incredibil"

Exemplu:
[paste un comentariu pe care l-ai scris tu la
raportul de luna trecută]

Acum scrie pentru datele de mai jos:
[datele noi]

Diferența între un prompt cu un exemplu și unul fără e brutală pe sarcini de scriere. Pentru SQL, două-trei exemple de query-uri din baza ta (cu rezultate) calibrează modelul pe dialectul și stilul tău mult mai bine decât „scrie SQL pentru PostgreSQL".

2. Separarea calculului de narativă

Modelele halucinează când cer să facă matematică. Soluția e să nu le ceri. Calculezi tu agregatele în SQL sau Python, le dai modelului doar numerele și-i ceri să le descrie.

Prompt prost: „Iată un tabel cu 200 de rânduri, scrie un comentariu cu evoluția lunară".

Prompt bun: „Vânzările au fost 1.2M în martie, 1.35M în aprilie, 1.18M în mai. Față de aceeași perioadă anul trecut: -3%, +5%, -8%. Scrie un comentariu de două paragrafe, nu calcula nimic nou."

Pare evident scris așa. Nu e, pentru că majoritatea analiștilor pun toate datele într-un context și se așteaptă ca modelul să facă agregările corect. Câteodată o face. Câteodată nu, și nu observi decât după ce e prea târziu.

3. Chain of thought controlat

Cere modelului să-și explice raționamentul înainte să dea răspunsul, dar într-un format pe care îl poți filtra. Util mai ales pentru SQL complex.

Pentru întrebarea de business următoare, scrie:
1. RAȚIONAMENT: care sunt pașii logici și ce tabele atingi
2. ASUMĂRI: ce presupui despre date care ar putea fi greșit
3. SQL: query-ul efectiv

Întrebare: care e churn rate-ul pe trimestrul curent
pentru segmentul SMB?

Schema:
[paste schema relevantă]

Cele trei secțiuni îți permit să verifici asumările înainte să rulezi query-ul. De multe ori, secțiunea „ASUMĂRI" îți arată că modelul a interpretat „churn" diferit de cum îl definește compania ta. Mai bine afli înainte.

4. Constrângeri negative explicite

Spune ce nu vrei. Modelele moderne au tendințe predictibile pe care merită să le tai din față.

• „Nu folosi cuvinte ca revoluționar, inovator, game-changer"
• „Nu adăuga concluzii care nu sunt direct deductibile din date"
• „Nu include disclaimere generice de tip aceste date pot varia"
• „Nu folosi subqueries când o JOIN cu CTE e mai lizibil"
• „Nu rotunji procente la cifre întregi"

O listă de cinci-șapte „nu" la finalul prompt-ului poate îmbunătăți output-ul mai mult decât o sută de cuvinte de descriere pozitivă.

5. Iterație pe diff, nu pe rescriere

Când rezultatul e aproape bun, nu cere o variantă nouă. Cere o modificare punctuală.

Prost: „Rescrie comentariul, e prea sec".

Bun: „Păstrează tot textul. Modifică doar al doilea paragraf — adaugă o frază care leagă scăderea din B2B de lansarea concurentului X din aprilie. Restul rămâne identic."

Modelele au tendința, când li se cere o rescriere, să schimbe ce funcționa bine doar pentru variație stilistică. Lucrul pe diff păstrează ce e bun.

Ce nu mai trebuie făcut

Există o listă întreagă de practici recomandate prin 2023-2024 care în 2026 sunt fie inutile, fie contraproductive.

„Respiră adânc înainte să răspunzi" și alte instrucțiuni de tip „gândește cu atenție". Existau studii care arătau efecte pe modelele vechi. Pe modelele actuale, e zgomot. Mai rău, consumă tokens.

Rolurile elaborate: „Ești un data scientist cu PhD de la MIT, specializat în machine learning, cu 20 de ani de experiență la Google". Adaugă entropie fără să schimbe output-ul. Spune simplu ce vrei.

Tipping: „Îți dau 100$ dacă răspunzi bine". Era un truc real în 2023. Acum modelele sunt instruction-tuned suficient să-l ignore.

Promisiuni de pedeapsă: „Vei fi penalizat dacă răspunzi greșit". La fel, ineficient și prost privit la audit intern dacă cineva citește log-urile prompt-urilor.

Prompturi infinite cu 15 secțiuni și 200 de reguli. La un anumit punct, claritatea scade exponențial cu lungimea. Promptul ideal pentru o sarcină tipică e undeva între 150 și 400 cuvinte, plus exemplele.

Diferențele între modele în practica analistului

În 2026, alegerea modelului contează aproape la fel de mult ca prompt-ul. Câteva observații care vin din muncă reală, nu din benchmark-uri:

GPT-5 (OpenAI) rămâne cel mai puternic pe SQL complex, în special pe dialecte mai puțin obișnuite (Oracle, T-SQL avansat). Generează cod care funcționează din prima într-un procent ridicat.

Claude 4.5 (Anthropic) e remarcabil pe sarcini de scriere — comentarii, narativă pe agregate, rezumate executive. Are voce mai naturală și păstrează mai bine constrângerile stilistice.

Gemini 2.5 (Google) e prima opțiune când lucrezi nativ în BigQuery sau în ecosistemul Google. Integrarea cu sheet-urile lor și cu Looker e net superioară.

Copilot (Microsoft Fabric / Power BI) e cel mai relevant când compania ta deja a investit în Microsoft 365. Calitatea pură a output-ului e sub frontier models, dar integrarea cu datele reale (fără să le exporți altundeva) compensează în multe cazuri.

O echipă matură folosește două-trei. Nu există „cel mai bun".

Un scenariu care arată diferența

O analistă de la o companie de e-commerce din regiune trebuie să producă raportul săptămânal de retenție pe cohorte. Înainte, scria SQL-ul manual, exporta în Excel, făcea graficul, scria comentariul. 90 de minute.

Iterația ei de prompt — pe care a calibrat-o în trei săptămâni — arată cam așa:

• Un fișier de context cu schema bazei (paste o dată în custom GPT/Claude Project).
• Trei exemple de query-uri pe cohorte pe care le-a scris ea, cu comentarii inline.
• Un set de definiții: „cohortă activă = utilizator cu cel puțin o tranzacție în ultimele 30 de zile".
• Constrângeri negative: „nu folosi window functions când GROUP BY e suficient", „nu include comentariu interpretativ în query, doar comentarii tehnice".

Acum scrie: „raport săptămâna 32, accent pe cohorta din iunie". Modelul produce SQL-ul, ea îl rulează, copiază output-ul, cere comentariu pe baza lui. 25 de minute total. Diferența nu vine din magie, ci din infrastructura de context pe care a construit-o.

Două capcane fine

Prima: over-prompting. Există tentația de a continua să adaugi reguli după fiecare iterație imperfectă. La un moment dat, prompt-ul devine atât de specific încât nu mai generalizează. Devine fragil, se sparge la primul edge case nou. Periodic, simplifică.

A doua: încrederea în continuitate. Conversațiile lungi cu un model par să-l facă „să te înțeleagă". În realitate, după 30-40 de schimburi, contextul devine zgomotos. Câteodată un prompt nou, curat, dă rezultate mai bune decât a 25-a iterație în aceeași conversație.

Tema se leagă natural de discuția despre Data Analyst, unde am intrat în detaliu pe pattern-urile pe care le observăm în piață. În fond, prompt engineering nu e doar un concept tehnic — este o decizie de business cu impact direct pe productivitatea echipei.

Outlook

Direcția pentru următoarele 12 luni e clar către integrare nativă în tool-urile de date. DataGrip cu AI Assistant, dbt cu LLM-uri în transformations, Hex și Mode cu funcționalități native — toate reduc nevoia de prompt engineering manual.

Dar pentru analistul individual, capacitatea de a formula bine un prompt rămâne o diferențiere care contează. Pentru cine vrea să meargă mai adânc, documentația Anthropic pe prompt engineering e încă cea mai onestă și practică, fără cuvinte goale.

Cele mai bune prompt-uri pe care le-am văzut în 2026 nu sunt cele mai lungi. Sunt cele care arată exact ce vrei printr-un exemplu, taie din față ce nu vrei printr-o listă de constrângeri și lasă modelul să fie ce e — un instrument care răspunde foarte bine la cine știe să întrebe clar.

În practică, prompt engineering a trecut de la subiect de roadmap la prioritate operațională pentru echipele care livrează rezultate de business — exact tipul de tracțiune pe care o vedem reflectată în deciziile reale de buget. Pentru cititorii care lucrează zilnic cu prompt engineering, articolul rămâne deschis pentru update-uri pe măsură ce piața evoluează.