Ghidul Anthropic pornește de la trei lucruri pe care ar trebui să le ai înainte de prompt engineering: criterii de succes clare, o metodă empirică de a le testa și o primă versiune a promptului. Ghidul OpenAI recomandă, la fel, teste și suite de evaluare care măsoară comportamentul promptului pe măsură ce îl modifici sau schimbi versiunea modelului, plus fixarea aplicațiilor din producție pe un snapshot de model.
Fără evaluare, o schimbare care repară un caz poate strica altele, iar o actualizare de model poate schimba răspunsurile fără să observi. Un set de evaluare transformă impresia („pare mai bun”) într-un scor pe care îl poți compara între versiuni.
Anthropic notează că nu orice criteriu se rezolvă prin prompt: latența și costul, de exemplu, se îmbunătățesc uneori mai ușor alegând alt model.
Concepte cheie și caracteristici
| Concept / Parametru | Descriere practică |
|---|---|
Criterii specifice |
„Clasificare corectă a sentimentului”, nu „performanță bună”. Anthropic cere criterii specifice, măsurabile, realizabile și relevante pentru aplicație. |
Criterii măsurabile |
Metrici (acuratețe, F1, timp de răspuns) sau scale clare (de exemplu Likert 1–5, cu descrierea fiecărui nivel). Exemplul Anthropic: un scor F1 de cel puțin 0,85 pe un set de test separat de 10.000 de postări. |
Mai multe dimensiuni |
Majoritatea aplicațiilor au nevoie de mai multe criterii simultan: corectitudine, consistență, relevanță, ton, protecția datelor personale, folosirea contextului, latență, cost. |
Cazuri de test |
Să semene cu cererile reale și să includă cazuri-limită: date lipsă sau irelevante, intrări foarte lungi, cereri ambigue sau dăunătoare. Anthropic preferă multe cazuri notate automat în locul câtorva notate manual. |
Notare prin cod |
Potrivire exactă (output == golden_answer) sau căutarea unui șir în răspuns. Cea mai rapidă și mai fiabilă metodă, dar fără nuanțe. |
Notare cu LLM |
Rapidă și flexibilă pentru judecăți complexe. Are nevoie de o rubrică detaliată, de un verdict simplu (corect / greșit sau o scală 1–5) și de verificarea fiabilității înainte de a o folosi la scară. Anthropic recomandă un evaluator cu thinking activ. |
Notare umană |
Cea mai flexibilă, dar lentă și scumpă. Anthropic recomandă să o eviți când se poate. |
Exemple practice și scenarii reale
Exemplul 1: Evaluare prin cod pentru un prompt de clasificare
apel_model este funcția ta care trimite promptul la API și întoarce textul. Un set real are zeci sau sute de cazuri, inclusiv cazuri-limită.
cazuri = [
{"text": "Livrarea a întârziat o săptămână.", "asteptat": "Negativ"},
{"text": "Produsul e exact ca în descriere.", "asteptat": "Pozitiv"},
{"text": "Am primit coletul.", "asteptat": "Neutru"},
]
def evalueaza(prompt, apel_model):
corecte = 0
for caz in cazuri:
raspuns = apel_model(prompt.format(text=caz["text"])).strip()
corecte += raspuns == caz["asteptat"]
return corecte / len(cazuri)
# Rulezi aceeași funcție pentru fiecare versiune a promptului și compari scorurile.Exemplul 2: Rubrică pentru un evaluator LLM
După modelul de rubrică din ghidul Anthropic: criteriu scris explicit și verdict de un singur cuvânt.
Evaluează răspunsul de mai jos după rubrică.
<rubrica>
Răspunsul trebuie să numească firma Acme SRL în prima propoziție.
Dacă nu o face, verdictul este automat „greșit”.
</rubrica>
<raspuns>{RASPUNS}</raspuns>
Răspunde doar cu „corect” sau „greșit”.Greșeli frecvente și capcane
- Ajustezi promptul după câteva încercări în chat. Fără un set fix de cazuri nu știi dacă schimbarea a ajutat sau doar a mutat erorile în altă parte.
- Testezi doar cazurile ușoare. Anthropic cere și cazuri-limită: date lipsă, intrări foarte lungi, cereri ambigue sau dăunătoare.
- Folosești un evaluator LLM fără rubrică. Fără criterii scrise și un verdict simplu, notele sunt greu de comparat; verifică întâi pe câteva cazuri că evaluatorul dă aceleași note ca un om.
- Schimbi modelul în producție fără să rulezi din nou evaluarea. OpenAI recomandă fixarea pe un snapshot și testarea înainte de orice upgrade.