Răspuns scurt: Definiți ce înseamnă „bun” pentru cazul dvs. de utilizare, apoi testați cu prompturi reprezentative, versionate și cazuri limită. Asociați metricile automate cu scorarea rubrica umană, alături de verificări ale siguranței adverse și ale injectării prompturilor. Dacă constrângerile de cost sau latență devin obligatorii, comparați modelele în funcție de succesul sarcinii per kilogram cheltuit și timpii de răspuns p95/p99.
Concluzii cheie:
Responsabilitate : Desemnați proprietari clari, păstrați jurnale de versiune și rulați din nou evaluările după orice solicitare sau modificare a modelului.
Transparență : Notați criteriile de succes, constrângerile și costurile eșecului înainte de a începe colectarea scorurilor.
Auditabilitate : Mențineți suite de teste repetabile, seturi de date etichetate și metrici de latență p95/p99 urmărite.
Contestabilitate : Folosiți rubrici de evaluare umane și o cale de contestare definită pentru rezultatele contestate.
Rezistență la utilizare abuzivă : Injectarea promptă de către echipa roșie, subiecte sensibile și refuz excesiv de a proteja utilizatorii.
Dacă alegi un model pentru un produs, un proiect de cercetare sau chiar un instrument intern, nu poți pur și simplu să te gândești la „pare inteligent” și să îl livrezi (consultă ghidul de evaluare OpenAI și NIST AI RMF 1.0 ). Așa obții un chatbot care explică cu încredere cum să încălzești o furculiță la microunde. 😬
Articole pe care ți-ar putea plăcea să le citești după acesta:
🔗 Viitorul inteligenței artificiale: tendințe care vor modela următorul deceniu.
Inovații cheie, impactul asupra locurilor de muncă și etica de urmărit.
🔗 Modele fundamentale în IA generativă explicate pentru începători.
Aflați ce sunt, cât de antrenate sunt și de ce contează.
🔗 Cum afectează inteligența artificială mediul și consumul de energie
Explorează emisiile, cererea de energie electrică și modalitățile de a reduce amprenta ecologică.
🔗 Cum funcționează upscaling-ul AI pentru imagini mai clare astăzi
Vedeți cum modelele adaugă detalii, elimină zgomotul și măresc imaginea în mod curat.
1) Definirea termenului „bun” (depinde, și e în regulă) 🎯
Înainte de a face orice evaluare, decide cum arată succesul. Altfel, vei măsura totul și nu vei învăța nimic. E ca și cum ai aduce o ruletă pentru a juriza un concurs de prăjituri. Sigur, vei obține cifre, dar nu îți vor spune prea multe 😅
Clarifica:
-
Scopul utilizatorului : rezumat, căutare, scriere, raționament, extragerea faptelor
-
Costul eșecului : o recomandare greșită de film este amuzantă; o instrucțiune medicală greșită este... deloc amuzantă (încadrarea riscului: NIST AI RMF 1.0 ).
-
Mediu de execuție : pe dispozitiv, în cloud, în spatele unui firewall, într-un mediu reglementat
-
Constrângeri principale : latență, cost per solicitare, confidențialitate, explicabilitate, suport multilingv, controlul tonului
Un model care este „cel mai bun” la un loc de muncă poate fi un dezastru la altul. Nu este o contradicție, este realitatea. 🙂
2) Cum arată un cadru robust de evaluare a modelelor de inteligență artificială 🧰
Da, asta e partea pe care oamenii o sar peste. Iau un test de evaluare, îl rulează o dată și termină cu el. Un cadru de evaluare robust are câteva trăsături consistente (exemple practice de instrumente: OpenAI Evals / Ghidul OpenAI evals ):
-
Repetabil - îl puteți rula din nou săptămâna viitoare și puteți avea încredere în comparații
-
Reprezentativ - reflectă utilizatorii și sarcinile reale (nu doar detalii banale)
-
Multi-stratificat - combină metrici automatizate + evaluare umană + teste contradictorii
-
Acționabil - rezultatele îți spun ce trebuie să repari, nu doar „scorul a scăzut”
-
Rezistent la manipulare - evită „învățarea pentru test” sau scurgerile accidentale
-
Conștient de costuri - evaluarea în sine nu ar trebui să te falimenteze (cu excepția cazului în care îți place durerea)
Dacă evaluarea ta nu poate supraviețui unui coechipier sceptic care spune „Bine, dar corelează asta cu producția”, atunci nu este încă finalizată. Aceasta este verificarea vibrațiilor.
3) Cum să evaluezi modelele de inteligență artificială începând cu segmente de cazuri de utilizare 🍰
Iată un truc care economisește o grămadă de timp: împarte cazul de utilizare în felii .
În loc să „evaluați modelul”, faceți:
-
Înțelegerea intenției (se obține ceea ce își dorește utilizatorul)
-
Recuperare sau utilizare a contextului (folosește corect informațiile furnizate)
-
Raționament / sarcini cu mai mulți pași (rămâne coerent de-a lungul pașilor)
-
Formatare și structură (respectă instrucțiunile)
-
Siguranță și aliniere la politici (evită conținutul nesigur; vezi NIST AI RMF 1.0 )
-
Tonul și vocea mărcii (sună așa cum vrei să sune)
Asta face ca „Cum să evaluezi modelele de inteligență artificială” să pară mai puțin un examen imens și mai mult un set de teste specifice. Testele sunt enervante, dar ușor de gestionat. 😄
4) Noțiuni de bază despre evaluarea offline - seturi de teste, etichete și detaliile banale care contează 📦
Evaluarea offline este locul în care efectuați teste controlate înainte ca utilizatorii să atingă ceva (modele de flux de lucru: OpenAI Evals ).
Construiește sau colecționează un set de teste care este cu adevărat al tău
Un set de teste bun include de obicei:
-
Exemple de aur : rezultate ideale pe care le-ați livra cu mândrie
-
Cazuri limită : solicitări ambigue, intrări neordonate, formatare neașteptată
-
Sonde de mod de defecțiune : solicitări care provoacă halucinații sau răspunsuri nesigure (încadrarea testării riscului: NIST AI RMF 1.0 )
-
Acoperire diversă : diferite niveluri de competență ale utilizatorilor, dialecte, limbi, domenii
Dacă testezi doar pe prompturi „curate”, modelul va arăta uimitor. Atunci utilizatorii tăi vor apărea cu greșeli de scriere, jumătate de propoziție și energie de clicuri furioase. Bine ai venit în realitate.
Opțiuni de etichetare (cunoscute și sub numele de: niveluri de strictețe)
Puteți eticheta ieșirile astfel:
-
Binar : admis/reușit (rapid, sever)
-
Ordinal : scor de calitate de la 1 la 5 (nuanțat, subiectiv)
-
Atribute multiple : acuratețe, completitudine, ton, utilizarea citărilor etc. (cel mai bun, mai lent)
Multi-atributele sunt punctul ideal pentru multe echipe. E ca și cum ai gusta mâncarea și ai judeca săratul separat de textură. Altfel, pur și simplu spui „bun” și ridici din umeri.
5) Indicatori care nu mint - și indicatori care într-un fel mint 📊😅
Indicatorii sunt valoroși... dar pot fi și o bombă cu sclipici. Strălucesc peste tot și sunt greu de curățat.
Familii metrice comune
-
Precizie / potrivire exactă : excelent pentru extragere, clasificare, sarcini structurate
-
F1 / precizie / rechemare : util atunci când omiterea unui lucru este mai rea decât zgomotul suplimentar (definiții: scikit-learn precizie/rechemare/scor F )
-
Suprapunere stil BLEU / ROUGE : acceptabilă pentru sarcini de sumarizare, adesea înșelătoare (metrici originale: BLEU și ROUGE )
-
Încorporarea similarității : utilă pentru potrivirea semantică, poate recompensa răspunsurile greșite, dar similare
-
Rata de succes a sarcinii : „a primit utilizatorul ceea ce avea nevoie?”, standardul de aur atunci când este bine definit.
-
Conformitate cu constrângerile : respectă formatul, lungimea, validitatea JSON, aderența la schemă
Punctul cheie
Dacă sarcina ta este deschisă (scriere, raționament, chat de asistență), valorile numerice unice pot fi... instabile. Nu inutile, doar instabile. Măsurarea creativității cu o riglă este posibilă, dar te vei simți prost făcând asta. (În plus, probabil îți vei scoate ochiul.)
Așadar: folosiți indicatori, dar ancorați-i la evaluarea umană și la rezultatele reale ale sarcinilor (un exemplu de discuție privind evaluarea bazată pe LLM + avertismente: G-Eval ).
6) Tabelul comparativ - cele mai bune opțiuni de evaluare (cu ciudățenii, pentru că viața are ciudățenii) 🧾✨
Iată un meniu practic de abordări de evaluare. Combinați și potriviți. Majoritatea echipelor fac asta.
| Instrument / Metodă | Public | Preţ | De ce funcționează |
|---|---|---|---|
| Suită de teste prompte construită manual | Produs + inginerie | $ | Foarte precis, detectează rapid regresiile - dar trebuie să îl menții la zi 🙃 (instrumente pentru începători: OpenAI Evals ) |
| Panel de evaluare a rubricii umane | Echipe care pot economisi recenzori | $$ | Cel mai bun pentru ton, nuanță, „ar accepta un om asta”, un ușor haos, în funcție de recenzori |
| LLM-ca-judecător (cu rubrici) | Bucle de iterație rapidă | $-$$ | Rapid și scalabil, dar poate moșteni prejudecăți și uneori notează vibrațiile, nu faptele (cercetare + probleme cunoscute de prejudecăți: G-Eval ) |
| Sprint adversari în echipă roșie | Siguranță + conformitate | $$ | Descoperă moduri de eșec picante, în special injecția promptă - se simte ca un test de stres la sală (prezentare generală a amenințărilor: OWASP LLM01 Injecție promptă / OWASP Top 10 pentru aplicații LLM ) |
| Generarea de teste sintetice | Echipe cu date reduse | $ | Acoperire excelentă, dar solicitările sintetice pot fi prea elegante, prea politicoase... utilizatorii nu sunt politicoși |
| Testarea A/B cu utilizatori reali | Produse mature | $$$ | Cel mai clar semnal - și cel mai stresant din punct de vedere emoțional atunci când valorile metrice se schimbă (ghid practic clasic: Kohavi și colab., „Experimente controlate pe web” ) |
| Evaluare bazată pe recuperare (verificări RAG) | Aplicații de căutare + control al calității | $$ | Măsoară „folosește corect contextul”, reduce inflația scorului de halucinații (prezentare generală a evaluării RAG: Evaluarea RAG: Un sondaj ) |
| Monitorizare + detectare a derivei | Sisteme de producție | $$-$$$ | Surprinde degradarea în timp - este simplu până în ziua în care te salvează 😬 (prezentare generală a derivei: Studiu privind derivele conceptuale (PMC) ) |
Observați că prețurile sunt intenționat mici. Acestea depind de scară, instrumente și de numărul de întâlniri pe care le generați accidental.
7) Evaluarea umană - arma secretă pentru care oamenii nu primesc suficiente fonduri 👀🧑⚖️
Dacă faci doar evaluare automată, vei rata:
-
Nepotrivire de ton („de ce este atât de sarcastic”)
-
Erori factuale subtile care par fluente
-
Implicații dăunătoare, stereotipuri sau formulări incomode (încadrarea riscului + prejudecăților: NIST AI RMF 1.0 )
-
Eșecuri de urmărire a instrucțiunilor care încă sună „inteligente”
Faceți rubricile concrete (sau evaluatorii le vor folosi în stil liber)
Rubrică nepotrivită: „Care este de ajutor”
Rubrică mai bună:
-
Corectitudine : exactitate factuală, având în vedere solicitarea + contextul
-
Completitudine : acoperă punctele necesare fără divagații
-
Claritate : lizibil, structurat, confuzie minimă
-
Politică / siguranță : evită conținutul restricționat, gestionează bine refuzul (încadrare în siguranță: NIST AI RMF 1.0 )
-
Stil : se potrivește cu vocea, tonul, nivelul de citire
-
Fidelitate : nu inventează surse sau afirmații nejustificate
De asemenea, faceți uneori verificări între evaluatori. Dacă doi evaluatori nu sunt de acord în mod constant, nu este o „problemă de oameni”, ci o problemă de rubrică. De obicei (noțiuni de bază despre fiabilitatea între evaluatori: McHugh despre kappa lui Cohen ).
8) Cum să evaluezi modelele de inteligență artificială pentru siguranță, robustețe și „uf, utilizatori” 🧯🧪
Aceasta este partea pe care o faci înainte de lansare - și apoi continui să o faci, pentru că internetul nu doarme niciodată.
Teste de robustețe care să includă
-
Greșeli de scriere, argou, gramatică defectuoasă
-
Subiecte foarte lungi și subiecte foarte scurte
-
Instrucțiuni contradictorii („fii scurt, dar include fiecare detaliu”)
-
Conversații cu mai multe rânduri în care utilizatorii își schimbă obiectivele
-
Încercări de injectare promptă („ignorați regulile anterioare…”) (detalii amenințare: OWASP LLM01 Injectare promptă )
-
Subiecte sensibile care necesită un refuz prudent (încadrarea riscului/siguranței: NIST AI RMF 1.0 )
Evaluarea siguranței nu înseamnă doar „dacă refuză”?
Un model bun ar trebui:
-
Refuzați solicitările nesigure în mod clar și calm (structură de îndrumare: NIST AI RMF 1.0 )
-
Oferiți alternative mai sigure atunci când este cazul
-
Evitați refuzul excesiv al interogărilor inofensive (rezultate fals pozitive)
-
Gestionați solicitările ambigue cu întrebări clarificatoare (atunci când este permis)
Refuzul excesiv este o problemă reală a produsului. Utilizatorilor nu le place să fie tratați ca niște goblini suspecti. 🧌 (Chiar dacă sunt goblini suspecti.)
9) Cost, latență și realitatea operațională - evaluarea pe care toată lumea o uită 💸⏱️
Un model poate fi „uimitor” și totuși greșit pentru tine dacă este lent, scump sau fragil din punct de vedere operațional.
Evalua:
-
Distribuția latenței (nu doar media - p95 și p99 contează) (de ce contează percentilele: Google SRE Workbook despre monitorizare )
-
Cost per sarcină reușită (nu costul per token izolat)
-
Stabilitate sub sarcină (timeout-uri, limite de rată, vârfuri anormale)
-
Fiabilitatea apelării instrumentului (dacă folosește funcții, se comportă)
-
Tendințe ale lungimii de ieșire (unele modele sunt divagante, iar divagarea costă bani)
Un model puțin mai slab, dar de două ori mai rapid, poate câștiga în practică. Pare evident, dar oamenii ignoră. Ca și cum ai cumpăra o mașină sport pentru a merge la supermarket, apoi te-ai plânge de spațiul din portbagaj.
10) Un flux de lucru simplu, complet, pe care îl poți copia (și modifica) 🔁✅
Iată un flux practic despre cum să evaluezi modelele de inteligență artificială fără a te prinde în experimente nesfârșite:
-
Definirea succesului : sarcină, constrângeri, costuri de eșec
-
Creați un set de teste „de bază” mic : 50-200 de exemple care reflectă utilizarea reală
-
Adăugați seturi de muchii și adversari : încercări de injectare, prompturi ambigue, sonde de siguranță (clasa de injectare prompt: OWASP LLM01 )
-
Execută verificări automate : formatare, validitate JSON, corectitudine de bază acolo unde este posibil
-
Executarea unei verificări umane : eșantionarea rezultatelor în diferite categorii, evaluarea cu ajutorul unei rubrici
-
Comparați compromisurile : calitate vs. cost vs. latență vs. siguranță
-
Pilot în lansare limitată : teste A/B sau lansare etapizată (ghid de testare A/B: Kohavi și colab. )
-
Monitorizare în producție : derivă, regresii, bucle de feedback utilizatori (prezentare generală a derivei: Sondaj privind derivele conceptuale (PMC) )
-
Iterație : actualizarea prompturilor, recuperarea, reglarea fină, barierele de siguranță, apoi rularea din nou a eval (modele de iterație a eval: ghidul OpenAI evals )
Păstrează jurnale versionate. Nu pentru că e distractiv, ci pentru că în viitor - îți vei mulțumi în timp ce ții o cafea în mână și mormăi „ce s-a schimbat…” ☕🙂
11) Capcane comune (adică: modalități prin care oamenii se păcălesc singuri din greșeală) 🪤
-
Antrenament pentru test : optimizezi solicitările până când benchmark-ul arată excelent, dar utilizatorii au de suferit
-
Date de evaluare scurgeri : solicitările de testare apar în datele de antrenament sau de reglare fină (oops)
-
Cultul unei singure metrici : urmărirea unui scor care nu reflectă valoarea pentru utilizator
-
Ignorarea schimbării distribuției : comportamentul utilizatorului se schimbă, iar modelul se degradează în liniște (încadrarea riscului de producție: Sondaj privind deviația conceptelor (PMC) )
-
Supraindexare pe „inteligență” : raționamentul inteligent nu contează dacă încalcă formatarea sau inventează fapte
-
Nu se testează calitatea refuzului : „Nu” poate fi corect, dar totuși experiența utilizatorului este groaznică.
De asemenea, atenție la demonstrații. Demonstrațiile sunt ca trailere de filme. Arată momentele importante, ascund părțile lente și, ocazional, mint cu muzică dramatică. 🎬
12) Rezumat final despre cum se evaluează modelele de inteligență artificială 🧠✨
Evaluarea modelelor de inteligență artificială nu se rezumă la un singur scor, ci la o masă echilibrată. Ai nevoie de proteine (corectitudine), legume (siguranță), carbohidrați (viteză și cost) și, da, uneori și desert (ton și încântare) 🍲🍰 (încadrarea riscului: NIST AI RMF 1.0 )
Dacă nu vă mai amintiți nimic altceva:
-
Definește ce înseamnă „bun” pentru cazul tău de utilizare
-
Folosește seturi de teste reprezentative, nu doar repere celebre
-
Combină indicatorii automati cu revizuirea rubricilor realizată de oameni
-
Testează robustețea și siguranța la fel cum utilizatorii sunt adversari (pentru că uneori... sunt) (clasa de injecție promptă: OWASP LLM01 )
-
Includeți costul și latența în evaluare, nu ca o idee ulterioară (de ce contează percentilele: Google SRE Workbook )
-
Monitorizare după lansare - modelele evoluează, aplicațiile evoluează, oamenii devin creativi (prezentare generală a derivei: Sondaj privind derivele conceptuale (PMC) )
Așa evaluezi modelele de inteligență artificială într-un mod care să reziste atunci când produsul tău este live și oamenii încep să facă lucruri imprevizibile. Ceea ce se întâmplă întotdeauna. 🙂
FAQ
Care este primul pas în evaluarea modelelor de inteligență artificială pentru un produs real?
Începeți prin a defini ce înseamnă „bun” pentru cazul dvs. de utilizare specific. Definiți obiectivul utilizatorului, ce costuri vă pot aduce eșecurile (mică mică vs. mică mare) și unde va rula modelul (cloud, pe dispozitiv, mediu reglementat). Apoi, enumerați constrângeri stricte, cum ar fi latența, costul, confidențialitatea și controlul tonului. Fără această bază, veți măsura multe și tot veți lua o decizie proastă.
Cum pot construi un set de teste care să reflecte cu adevărat utilizatorii mei?
Construiește un set de teste care este cu adevărat al tău, nu doar un benchmark public. Include exemple de referință de care ai fi mândru să te ofere, plus solicitări zgomotoase, neobișnuite, cu greșeli de scriere, semi-propoziții și solicitări ambigue. Adaugă cazuri limită și sonde de mod de eșec care provoacă halucinații sau răspunsuri nesigure. Acoperă diversitatea în ceea ce privește nivelul de calificare, dialecte, limbi și domenii, astfel încât rezultatele să nu se prăbușească în producție.
Ce indicatori ar trebui să utilizez și care pot fi înșelători?
Potriviți indicatorii cu tipul de sarcină. Potrivirea exactă și acuratețea funcționează bine pentru extragere și rezultate structurate, în timp ce precizia/reamintirea și F1 ajută atunci când omiterea unui lucru este mai rea decât zgomotul suplimentar. Indicatorii suprapuși, cum ar fi BLEU/ROUGE, pot induce în eroare în cazul sarcinilor deschise, iar încorporarea similarității poate recompensa răspunsurile „greșite, dar similare”. Pentru scriere, suport sau raționament, combinați indicatorii cu revizuirea umană și ratele de succes ale sarcinilor.
Cum ar trebui să structurez evaluările astfel încât să fie repetabile și de calitate pentru producție?
Un cadru de evaluare robust este repetabil, reprezentativ, cu mai multe niveluri și acționabil. Combinați verificările automate (format, validitate JSON, corectitudine de bază) cu evaluarea prin rubrici umane și teste contradictorii. Asigurați-vă că este rezistent la manipulare evitând scurgerile de informații și „predând pentru test”. Mențineți evaluarea conștientă de costuri, astfel încât să o puteți rula din nou frecvent, nu doar o dată înainte de lansare.
Care este cea mai bună metodă de a face evaluarea umană fără ca aceasta să se transforme în haos?
Folosește o rubrică concretă, astfel încât evaluatorii să nu se implice în stil liber. Evaluează atribute precum corectitudinea, caracterul complet, claritatea, siguranța/gestionarea politicilor, potrivirea stilului/vocei și fidelitatea (nu inventează afirmații sau surse). Verifică periodic acordul între evaluatori; dacă evaluatorii sunt în mod constant în dezacord, este probabil ca rubrica să necesite rafinări. Evaluarea umană este deosebit de valoroasă pentru nepotrivirea tonului, erorile factuale subtile și eșecurile în respectarea instrucțiunilor.
Cum evaluez siguranța, robustețea și riscurile injectării prompte?
Testați cu intrări de genul „ugh, utilizatori”: greșeli de scriere, argou, instrucțiuni contradictorii, solicitări foarte lungi sau foarte scurte și modificări multiple ale obiectivelor. Includeți încercări de injectare a prompturilor, cum ar fi „ignorați regulile anterioare” și subiecte sensibile care necesită refuzuri atente. O performanță bună în materie de siguranță nu înseamnă doar refuz - este refuzul clar, oferirea de alternative mai sigure atunci când este cazul și evitarea refuzului excesiv al interogărilor inofensive care dăunează experienței utilizatorului.
Cum pot evalua costul și latența într-un mod care să corespundă realității?
Nu măsurați doar mediile - urmăriți distribuția latenței, în special p95 și p99. Evaluați costul per sarcină reușită, nu costul per token în mod izolat, deoarece reîncercările și ieșirile divagante pot elimina economiile. Testați stabilitatea sub sarcină (timeout-uri, limite de rată, vârfuri de timp) și fiabilitatea apelării instrumentelor/funcțiilor. Un model puțin mai slab, care este de două ori mai rapid sau mai stabil, poate fi o alegere mai bună.
Care este un flux de lucru simplu, complet, pentru evaluarea modelelor de inteligență artificială?
Definiți criteriile și constrângerile de succes, apoi creați un set mic de teste de bază (aproximativ 50-200 de exemple) care să reflecte utilizarea reală. Adăugați seturi de teste de tip „edge” și „adversarial” pentru siguranță și încercări de injectare. Rulați verificări automate, apoi eșantionați rezultatele pentru evaluarea prin rubrică umană. Comparați calitatea versus cost versus latență versus siguranță, testați cu o implementare limitată sau un test A/B și monitorizați în producție abaterile și regresiile.
Care sunt cele mai frecvente moduri în care echipele se păcălesc accidental în evaluarea modelului?
Printre capcanele comune se numără optimizarea solicitărilor pentru a atinge un standard în timp ce utilizatorii au de suferit, scurgerea solicitărilor de evaluare în datele de antrenament sau de ajustare fină și venerarea unei singure metrici care nu reflectă valoarea pentru utilizator. Echipele ignoră, de asemenea, schimbarea distribuției, supraindexează „inteligența” în loc de conformitatea formatului și fidelitate și omit testele de calitate a refuzurilor. Demonstrațiile pot ascunde aceste probleme, așa că bazați-vă pe evaluări structurate, nu pe evidențierea fragmentelor de date.
Referințe
-
OpenAI - Ghid de evaluare OpenAI - platform.openai.com
-
Institutul Național de Standarde și Tehnologie (NIST) - Cadrul de gestionare a riscurilor în domeniul inteligenței artificiale (AI RMF 1.0) - nist.gov
-
OpenAI - openai/evals (repozit GitHub) - github.com
-
scikit-learn - suport_precision_recall_fscore - scikit-learn.org
-
Asociația pentru Lingvistică Computațională (Antologia ACL) - BLEU - aclanthology.org
-
Asociația pentru Lingvistică Computațională (Antologia ACL) - ROUGE - aclanthology.org
-
arXiv - G-Eval - arxiv.org
-
OWASP - LLM01: Injecție promptă - owasp.org
-
OWASP - Top 10 OWASP pentru aplicații cu modele de limbaj extinse - owasp.org
-
Universitatea Stanford - Kohavi și colab., „Experimente controlate pe web” - stanford.edu
-
arXiv - Evaluarea RAG: Un sondaj - arxiv.org
-
PubMed Central (PMC) - Studiu privind deviația conceptelor (PMC) - nih.gov
-
PubMed Central (PMC) - McHugh despre kappa lui Cohen - nih.gov
-
Google - Caiet de lucru SRE despre monitorizare - google.workbook