Cele Mai Bune Framework-uri Open-Source pentru Evaluarea LLM în 2026 (Unul Nu E Chiar Open Source)

Cele Mai Bune Framework-uri Open-Source pentru Evaluarea LLM în 2026 (Unul Nu E Chiar Open Source)

Prima linie din fișierul LICENSE al repo-ului Arize Phoenix spune "Elastic License 2.0 (ELv2)". Nu Apache. Nu MIT. Un framework open source de evaluare LLM extrem de recomandat nu e open source conform definiției OSI, iar aproape fiecare pagină aflată pe primele locuri pentru această interogare repetă totuși afirmația. La fel și una dintre paginile noastre, până azi. Pe 2026-08-04 am citit manual fișierul de licență și istoricul de commit-uri de pe ramura principală a opt framework-uri, plus alte trei încă recomandate de paginile de top, apoi am instalat șase și am rulat aceleași 10 cazuri prin fiecare. Nu vindem un framework de evaluare, așa că niciun verdict de mai jos nu protejează un produs.

Concluziile Cheie

• Arize Phoenix rulează sub Elastic License 2.0, pe care OSI nu o aprobă drept open source.
• Ultimul commit al UpTrain pe main a fost pe 2024-07-29. Nu porniți un proiect nou pe el.
• pip install promptfoo instalează un wrapper terț. Proiectul real e publicat pe npm.
• Ragas nu are commit-uri din 2026-02-24 și s-a mutat pe organizația GitHub vibrantlabsai.

Ce Framework Open-Source de Evaluare LLM Ar Trebui Să Instalezi în 2026?

Alege în funcție de constrângere, nu de clasament. Pentru assertion-uri în stil pytest într-un suite de teste existent, instalează DeepEval. Pentru un fișier de config YAML și un CLI care se potrivește oricărui stack de limbaj, instalează promptfoo. Pentru cea mai clară separare între răspunsuri bune și rele pe care am măsurat-o, instalează Opik. Toate trei sunt Apache-2.0 sau MIT.

Iată auditul. Opt framework-uri incluse, plus alte trei încă recomandate de paginile aflate pe primele locuri pentru această interogare.

Datele reprezintă ultimul commit de pe ramura principală a fiecărui proiect, la 2026-08-04. Pagina de repo de pe GitHub arată ultimul push pe orice ramură, dată care e mai recentă pentru două proiecte de aici: UpTrain 2024-08-18 și Deepchecks 2025-12-28. Niciun repo nu e arhivat.

Coloana cu costul de migrare e cea pe care oamenii o sar și apoi o regretă. Scorurile sunt doar numere, deci trecerea între DeepEval, Ragas, Opik și phoenix-evals înseamnă în mare parte rescrierea unui loop. Migrarea de pe promptfoo sau Inspect AI înseamnă rescrierea unui format de config sau de task fără echivalent în altă parte, iar migrarea de pe Evidently înseamnă auditarea fiecărui prag pe care l-ai scris, pentru că scala lui merge invers. Două dintre framework-urile încă recomandate de paginile de top nu au mai avut un release din 2024.

Vrei niveluri, platforme hostate și o clasificare directă în loc de asta? E o muncă diferită, și am făcut-o deja în comparația noastră clasificată a instrumentelor de evaluare LLM, inclusiv platforme plătite.

Cele Opt Framework-uri de Evaluare LLM, Grupate După Modul de Instalare

Forma de instalare e ce trebuie să trăiești cu ea, deci asta e gruparea.

Biblioteci Python pe care le imporți în teste

DeepEval (pip install deepeval, Apache-2.0) încapsulează metricile LLM în assertion-uri în stil pytest: construiești un LLMTestCase, îl dai lui assert_test, iar testul eșuează sub pragul tău. Cel mai bun pentru a plasa o poartă de calitate lângă testele unitare pe care o echipă le rulează deja. Alege-l dacă evaluările tale trebuie să fie în același job de CI cu tot restul.

O singură dezvăluire, spusă o dată: DeepEval e construit de Confident AI, care e partener plătit pe alte două articole de pe acest site, inclusiv comparația clasificată către care trimite această pagină. Nu primește niciun tratament special aici, iar fiecare link către DeepEval de pe această pagină duce către repo-ul de pe GitHub.

Ragas (pip install ragas, Apache-2.0) e opțiunea specifică RAG: evaluate() primește rânduri cu întrebare, context și răspuns și returnează scoruri per metrică, asincron. Cel mai bun pentru măsurarea calității retrieval-ului într-un pipeline Python. Repo-ul s-a mutat de la explodinggradients la vibrantlabsai, ultimul lui release a fost v0.4.3 pe 2026-01-13, iar de atunci nu mai există commit-uri din 2026-02-24. Alege-l dacă metricile RAG sunt tot ce ai de făcut și un repo tăcut e acceptabil, și vezi și stack-ul mai larg de instrumente RAG.

Opik (pip install opik, Apache-2.0, de la Comet) livrează metrici pe care le poți apela de sine stătător. Setează OPIK_TRACK_DISABLE=true, iar AnswerRelevance().score() rulează fără cont, fără server local și fără fișier de config, ceea ce framing-ul de produs nu subliniază. Cel mai bun pentru obținerea unui scor real în cele mai puține linii. Alege-l dacă vrei metrici acum și platforma poate mai târziu.

Evidently (pip install evidently, Apache-2.0) tratează evaluările ca descriptori peste un dataset și scrie un raport HTML ca efect secundar. Cel mai bun pentru raportare pe loturi, pe multe rânduri, mai degrabă decât o poartă binară. Scorurile lui LLM sunt inversate: 1.0 înseamnă neconform. Alege-l dacă ce datorezi cuiva e un raport partajabil, nu un build roșu.

Giskard (pip install giskard, Apache-2.0) scanează un model după vulnerabilități în loc să scoreze un dataset pe care l-ai scris tu. Pachetul PyPI rezolvă linia v2, iar README-ul propriu al proiectului afirmă că v2 "nu mai este întreținut activ". Cel mai bun pentru scanări automate în stil red-team. Alege-l dacă vrei ca vulnerabilitățile să fie găsite pentru tine, nu metrici LLM-as-a-judge pe care le definești tu.

Unelte CLI-plus-config pe care le rulezi pe un fișier YAML

promptfoo (npm install promptfoo, MIT) e un CLI care citește un fișier YAML: declari furnizori, cazuri de test și assertion-uri, rulezi npx promptfoo eval, și primești pass/fail per caz plus o interfață locală de rezultate. Cel mai bun pentru evaluarea prompt-urilor când aplicația ta nu e scrisă în Python. Alege-l dacă poarta ta de calitate trebuie să fie un fișier de config pe care un coleg non-Python îl poate edita.

Clasa harness și cele integrate cu o platformă

Inspect AI (pip install inspect-ai, MIT) vine de la UK AI Safety Institute și evaluează modele față de task-uri pe care le definești în Python, cu abstracții reale de solver și scorer și un vizualizator de rulări. Cel mai bun pentru benchmarking la nivel de model cu definiții de task reproductibile. Alege-l dacă ce se testează e un model, nu aplicația ta.

Arize Phoenix (pip install arize-phoenix-evals) oferă evaluatori predefiniți precum FaithfulnessEvaluator și CorrectnessEvaluator, care returnează o etichetă binară plus un scor. Cel mai bun pentru etichete deterministe pe care le poți folosi ca poartă fără să alegi un prag. Licența lui e motivul pentru care acest articol are o paranteză în titlu, și asta primește propria secțiune imediat.

Arize Phoenix E Open Source?

Nu, nu conform definiției menținute de Open Source Initiative. Arize Phoenix rulează sub Elastic License 2.0 (ELv2). Prima linie din fișierul LICENSE al repo-ului spune asta, iar PyPI declară independent license: Elastic-2.0 pe v19.15.0. Sursa e lizibilă, forkabilă și autohostabilă. O singură utilizare e restricționată.

Restricția care contează: ELv2 interzice oferirea software-ului către terți ca serviciu hostat sau gestionat. Citește cu atenție, pentru că afectează mult mai puțini oameni decât pare. Dacă instalezi arize-phoenix-evals ca să-ți scorezi propria aplicație, ELv2 nu te atinge niciodată. Dacă ești o firmă de consultanță sau o echipă de platformă care ambalează Phoenix într-un serviciu de evaluare pe care îl vinzi unor clienți externi, te atinge. Asta e toată diferența, iar Open Source Definition e ceea ce ELv2 nu îndeplinește, în mod specific clauzele privind restricțiile de domeniu de utilizare.

Fiecare pagină aflată acum pe primele locuri pentru această interogare încadrează Phoenix la "open source", și la fel am făcut și noi. Propria noastră comparație clasificată a instrumentelor de evaluare LLM descrie Phoenix ca fiind complet open-source, ceea ce e greșit, și e în curs de corectare. Phoenix este source-available, nu open source, iar distincția contează doar dacă plănuiești să-l vinzi ca serviciu. Dacă ai nevoie de tracing, nu de scoring, asta ține de platformele de observabilitate AI, nu de aici.

Care Dintre Acestea Sunt Încă Întreținute Activ?

Majoritatea. Șase din cele unsprezece repo-uri pe care le-am verificat au primit un commit pe main pe 2026-08-03 sau 2026-08-04: DeepEval, promptfoo, Opik, Arize Phoenix, Inspect AI și Giskard. Două nu au mai avut un release din 2024. Unul a devenit tăcut în 2026, după o schimbare de organizație pe GitHub.

Framework-uri pe care nu le-am porni pentru un proiect nou în 2026

UpTrain e mort. Ultimul lui commit pe main a apărut pe 2024-07-29, iar ultimul release, v0.7.1, a fost pe 2024-05-14, ceea ce îl plasează la doi ani de inactivitate pe oricare dintre cele două măsurători. Repo-ul încă există și e încă Apache-2.0, deci nimic nu te oprește, dar a porni o lucrare nouă pe o bibliotecă de evaluare abandonată e o decizie pe care va trebui să o explici mai târziu.

Deepchecks merită versiunea exactă. Nu a avut niciun release din 0.19.1 pe 2024-12-15, deși repo-ul încă primește commit-uri, cu ultimul pe main datat 2025-11-24. Oamenii încă lucrează la el; nimeni nu a tăiat o versiune de peste optsprezece luni. Nici UpTrain, nici Deepchecks nu e arhivat pe GitHub, și niciunul nu s-a închis contribuțiilor.

Ragas primește date și nimic altceva. Ultimul release v0.4.3 pe 2026-01-13, fără commit-uri din 2026-02-24, iar repo-ul s-a mutat de la explodinggradients la vibrantlabsai. Nu am găsit o explicație verificabilă pentru schimbarea organizației, așa că nu vom inventa una. Un repo tăcut nu e unul stricat: codul Apache-2.0 care calculează un scor de fidelitate azi îl va calcula la fel și anul viitor. Expunerea e reprezentată de dependențele neactualizate, exact ceea ce ne-a afectat în testarea de mai jos.

Alte pagini de pe prima pagină pentru această interogare încă recomandă și UpTrain, și Deepchecks, fără nicio dată atașată recomandării. Un framework fără release din decembrie 2024 e o decizie despre dependențe, nu o decizie despre funcționalitate.

Ai Nevoie de un Framework de Evaluare sau de un Harness de Evaluare?

Un framework de evaluare pentru aplicații scorează output-urile propriei tale aplicații față de propriile tale date. DeepEval, Ragas, promptfoo, Opik, phoenix-evals și Evidently fac toate asta. Un harness de evaluare pentru modele face benchmark unui model față de task-uri publice standardizate. lm-evaluation-harness și Inspect AI fac asta. Alegerea clasei greșite e cea mai costisitoare greșeală de pe această pagină.

Modul de eșec e concret. Cineva conectează lm-evaluation-harness ca să-și testeze chatbot-ul RAG, primește un set de scoruri MMLU și nu învață practic nimic despre dacă retriever-ul lui returnează pasajele corecte. Scorurile sunt reale. Măsoară modelul de bază, de care nimeni nu era îngrijorat.

Forma lui Inspect AI decurge din proveniența sa: a fost construit la UK AI Safety Institute sub MIT, pentru evaluarea modelelor de frontieră, deci solvers, scorers și task-uri sunt concepte de prim rang, iar aplicația ta nu e un concept pe care îl are. E un motiv bun să-l folosești pentru ce a fost făcut. Dacă problema ta sunt agenții, nu turele individuale, evaluarea agenților în producție e o disciplină diferită din nou, iar serverele de tool-calling primesc propriul tratament în ghidul nostru despre evaluarea serverelor și instrumentelor MCP.

Ce S-a Întâmplat Când Am Instalat Șase Dintre Ele și Am Rulat Aceleași 10 Cazuri

Pe 2026-08-04 am instalat șase dintre acestea în venv-uri Python 3.11.14 proaspete (plus npm pentru promptfoo) și am scorat un set RAG identic de 10 elemente cu un singur judecător, openai/gpt-4o-mini prin OpenRouter la temperatura 0. Șapte elemente au fost corecte. Trei au fost stricate în trei moduri diferite: unul contrazice contextul, unul inventează detalii, unul e proză fluentă care nu răspunde niciodată la întrebare. Fiecare framework a rulat de două ori, unul după altul.

Cinci din șase metrici de fundamentare au prins toate cele trei defecte. Cele trei constatări de mai jos sunt motivul pentru care există această secțiune.

Metricile de relevanță nu sunt metrici de calitate, iar două dintre ele au acordat unei minciuni sigure de sine un scor mai mare decât unui răspuns corect. Ragas ResponseRelevancy a scorat elementul care afirmă că HTTP 404 e o eroare de server 5xx cu 0.777, peste două dintre cele șapte răspunsuri corecte, iar elementul cu limite de rată inventate cu 0.813, peste patru. promptfoo answer-relevance a făcut la fel: 0.800 pentru elementul cu 404, un pass clar față de un prag de 0.7, în timp ce a picat răspunsul corect q01 la 0.679. Nu e un bug. Un răspuns greșit dar sigur de sine adresează întrebarea perfect. Dar dacă relevanța e numărul de pe dashboard-ul tău, o halucinație fluentă arată ca cel mai bun output al tău.

O poartă bazată doar pe fidelitate ratează răspunsul irelevant. DeepEval a scorat elementul care nu răspunde niciodată la întrebare cu 1.000 fidelitate, un pass clar, ceea ce e defensibil: un răspuns care nu afirmă nimic despre context nu contrazice nimic din el. Doar relevanța l-a prins, la 0.000. Acesta e singurul ratat de fundamentare din tabelul de mai sus. Fiecare metrică luată singură are o gaură; perechea acoperă amândouă.

Evaluatorii binari au fost stabili la temperatura 0. Cei gradați nu au fost. Phoenix și DeepEval nu au mișcat niciun element din zece în două rulări identice. Opik a mișcat patru, toate pe AnswerRelevance, pe o grilă de 0.05; Evidently a mișcat și el patru. Nicio variație nu a schimbat un verdict aici, dar q01-ul corect al promptfoo a ajuns la 0.679, apoi la 0.642, față de un prag de 0.700, ceea ce e forma unei porți de CI instabile.

Două note mai mici: trei din șase (DeepEval, Opik, Phoenix) s-au instalat și au rulat curat din prima, în timp ce Ragas nu s-a importat până n-am fixat langchain-community<0.4. Doar promptfoo a raportat consumul de token-uri al judecătorului, 16.011 token-uri de assertion în rularea 1 și 16.010 în rularea 2.

Limitele acestui test, spuse direct. n = 10 e un smoke test, nu un benchmark: îți spune despre ergonomie și puncte oarbe, nu despre acuratețea metricilor. Un singur model judecător a scorat totul, iar un judecător mai mare ar muta fiecare număr, probabil inclusiv cele două fals-pozitive pe care DeepEval și Ragas le-au produs amândouă pe același element corect. Două rulări dovedesc că variația există, dar nu o pot caracteriza. Răspunsurile au fost pre-scrise, deci nimic de aici nu testează generarea, tracing-ul sau gestiunea datasetului, ceea ce face ca cele 337.9 secunde de instalare ale promptfoo să pară mai rele decât merită. "Cel mai bun" înseamnă întotdeauna cel mai bun pentru o constrângere: o poartă de CI, metrici RAG sau o interfață schimbă fiecare răspunsul, la fel ca și separarea între evaluarea offline și online.

Aceeași Verificare, Scrisă în Trei Moduri

Cel mai rapid mod de a alege o formă de interfață e să citești aceeași assertion de trei ori. Iată o verificare de fundamentare pe un element în DeepEval, Ragas și promptfoo, trunchiată din scripturile pe care le-am rulat efectiv. Numele metricilor diferă; trimitem către cum funcționează de fapt metricile LLM-as-a-judge în loc să le redefinim aici.

# DeepEval 4.1.5: în stil pytest, pică testul sub prag
from deepeval import assert_test
from deepeval.models import GPTModel
from deepeval.metrics import FaithfulnessMetric
from deepeval.test_case import LLMTestCase

judge = GPTModel(
    model="openai/gpt-4o-mini",
    base_url="https://openrouter.ai/api/v1",
    api_key=OPENROUTER_KEY,
)

def test_faithfulness():
    case = LLMTestCase(
        input=question,
        actual_output=answer,
        retrieval_context=[context],
    )
    assert_test(case, [FaithfulnessMetric(threshold=0.7, model=judge)])

# Ragas 0.4.3: notă calea de import. `from ragas.metrics import Faithfulness`
# ridică ImportError în această versiune; metrica concretă s-a mutat.
from ragas import evaluate, EvaluationDataset
from ragas.metrics._faithfulness import Faithfulness
from ragas.llms import LangchainLLMWrapper
from langchain_openai import ChatOpenAI

judge = LangchainLLMWrapper(
    ChatOpenAI(model="openai/gpt-4o-mini",
               base_url="https://openrouter.ai/api/v1")
)

result = evaluate(
    dataset=EvaluationDataset.from_list(rows),
    metrics=[Faithfulness(llm=judge)],
)

# promptfoo 0.121.20: npm install promptfoo, apoi npx promptfoo eval
providers:
  - id: echo          # am scorat răspunsuri pre-scrise în loc să le generăm
defaultTest:
  assert:
    - type: context-faithfulness
      threshold: 0.7
tests:
  - vars:
      query: "Is HTTP 404 a client error or a server error?"
      context: "HTTP 404 Not Found is in the 4xx class, which denotes client errors."
      output: "HTTP 404 is a server error in the 5xx class."

Liniile de instalare ascund mai multe capcane decât codul, iar fiecare comentariu de mai jos e ceva care ne-a costat timp pe 2026-08-04:

# Adevăratul promptfoo e publicat pe npm. Pachetul PyPI cu același nume e
# un wrapper terț: https://pypi.org/project/promptfoo/ vs
# https://www.npmjs.com/package/promptfoo
npm install promptfoo

# pip install giskard rezolvă linia v2, pe care README-ul propriu al
# proiectului o marchează ca nemaifiind întreținută activ.
pip install giskard

# lm-evaluation-harness se instalează sub numele de pachet lm-eval.
pip install lm-eval

# Evidently nu instalează openai, iar judecătorul pică la momentul apelării,
# nu la import, după ce ai construit deja datasetul.
pip install evidently openai

# Ragas 0.4.3 nu se importă cu langchain-community 0.4.x.
pip install ragas "langchain-community<0.4"

Poți Pica un Build Pe Baza Unui Scor de Evaluare?

Da. Fiecare framework de aici returnează un scor numeric sau binar, iar fiecare va ieși cu cod diferit de zero când o assertion de prag eșuează, ceea ce e tot ce are nevoie GitHub Actions ca să facă un build roșu. Conectarea codului de ieșire e partea ușoară. Alegerea unui prag pe care modelul tău judecător nu-l va depăși din greșeală e partea care durează o săptămână.

Aceasta e forma de workflow pe care o rulăm, fixată pe versiunile din testul nostru din 2026-08-04:

name: evals
on: [pull_request]

jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11.14"
      - run: pip install deepeval==4.1.5

      - name: Score the golden set
        env:
          # Fixează judecătorul. Un upgrade de model la mijlocul trimestrului mută fiecare scor.
          JUDGE_MODEL: openai/gpt-4o-mini
          # Pragurile stau într-un singur loc, citite de constructorii metricii.
          EVAL_THRESHOLD: "0.7"
          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
        run: deepeval test run tests/evals/

Două capcane mușcă înainte de prag. Prima, apelurile către judecător sunt apeluri de rețea: rularea noastră DeepEval de 10 elemente a durat 126.8 secunde pentru că .measure() e secvențial, iar un set de referință de 200 de elemente pe acest cod e o pauză de cafea la fiecare pull request. Fiecare alt framework din test paralelizează implicit, ceea ce e cea mai mare pârghie unică asupra timpului real de CI.

A doua, instabilitatea. La temperatura 0, Opik și Evidently au mișcat fiecare patru din zece elemente între rulări consecutive, iar răspunsul corect al promptfoo a stat la 0.679, apoi la 0.642, față de un prag de 0.700. Măsurile de atenuare sunt banale și funcționează: rulează un dataset de referință fix care se schimbă doar per pull request, fixează modelul judecător, preferă evaluatori binari acolo unde o etichetă e suficientă, și pune poarta pe o diferență, nu pe un prag absolut. Ultimul punct contează cel mai mult pentru evaluarea multi-turn, unde o singură conversație produce mai multe scoruri care pot oscila fiecare.

Pentru scară: sondajul State of Agent Engineering al LangChain (1.340 de răspunsuri, colectate între 18 noiembrie și 2 decembrie 2025, publicat pe 12 iunie 2026) a constatat că 89% dintre organizații au implementat o formă de observabilitate pentru agenții lor, în timp ce doar 52.4% rulează evaluări offline pe seturi de test. Urmărirea e comună. Blocarea nu e.

Ce Am Instala Săptămâna Aceasta

Patru lucruri de reținut. Arize Phoenix e source-available sub Elastic License 2.0 și nu e open source aprobat de OSI, ceea ce nu schimbă nimic pentru majoritatea cititorilor și schimbă totul dacă revinzi instrumente de evaluare. UpTrain e mort, iar paginile fără dată pe ele încă îl recomandă. Deepchecks nu a tăiat un release din decembrie 2024, deși repo-ul lui încă primește commit-uri. O metrică de fundamentare și una de relevanță au fiecare câte o gaură pe care cealaltă o acoperă, așa că pune poarta pe amândouă. Iar scorurile gradate variază la temperatura 0, deci fixează-ți judecătorul și lasă loc pragurilor.

Dacă aș porni un nou suite de evaluare săptămâna aceasta, aș instala DeepEval pentru poarta de CI, pentru că assertion-urile aparțin lângă teste (dezvăluirea de mai sus), și aș adăuga metricile de sine stătătoare ale Opik pentru cea mai clară separare pe care am măsurat-o. Dacă stack-ul nostru nu ar fi Python, promptfoo, fără ezitare. Dacă ai prefera ca altcineva să conecteze setul de referință și workflow-ul, asta e o conversație pe care suntem bucuroși să o purtăm.

Întrebări Frecvente

Care e cel mai bun framework open-source de evaluare LLM?

Nu există un singur câștigător, doar cea mai bună potrivire pentru fiecare constrângere. Pentru o poartă pass/fail într-un suite de teste Python, DeepEval. Pentru un setup YAML și CLI independent de limbaj, promptfoo. Pentru metrici de retrieval RAG, Ragas, dacă poți accepta un repo fără commit-uri din 2026-02-24. Pentru cea mai clară separare între răspunsuri bune și rele în testul nostru din 2026-08-04, Opik.

Arize Phoenix e open source?

Nu conform definiției Open Source Initiative. Arize Phoenix rulează sub Elastic License 2.0, pe care PyPI o declară drept license: Elastic-2.0 pe v19.15.0 și pe care prima linie a fișierului LICENSE al repo-ului o afirmă direct. E source-available: poți citi, forka, modifica și autohosta. Singura restricție e oferirea software-ului către terți ca serviciu hostat sau gestionat.

Ragas mai e întreținut?

Faptele verificabile, la 2026-08-04: ultimul release a fost v0.4.3 pe 2026-01-13, nu au mai existat commit-uri din 2026-02-24, iar repo-ul s-a mutat de la organizația explodinggradients la vibrantlabsai. Repo-ul nu e arhivat. Nu am găsit o explicație publică fiabilă pentru schimbarea organizației și nu vom specula una. Codul Apache-2.0 încă rulează; expunerea e reprezentată de dependențele neactualizate.

Am nevoie de un framework de evaluare sau de o platformă de observabilitate?

Ambele, în cele din urmă, dar răspund la întrebări diferite. Un framework de evaluare îți spune dacă o schimbare a făcut output-urile tale mai bune sau mai rele înainte să lansezi, pe un dataset pe care îl controlezi. O platformă de observabilitate îți spune ce s-a întâmplat efectiv în producție după ce ai lansat. Începe cu framework-ul de evaluare dacă ai un pipeline de CI; vezi platformele de observabilitate AI pentru partea de producție.

Pot rula evaluări LLM în CI/CD?

Da. Fiecare framework tratat aici iese cu cod diferit de zero la o assertion de prag eșuată, ceea ce e tot ce are nevoie un job GitHub Actions. Constrângerile practice sunt timpul real de execuție (apelurile către judecător sunt apeluri de rețea, iar rularea noastră secvențială DeepEval a durat 126.8 secunde pentru 10 elemente) și non-determinismul judecătorului. Forma workflow-ului și măsurile de atenuare sunt în secțiunea de CI de mai sus.

Care e diferența dintre DeepEval și Ragas?

Forma interfeței și domeniul de aplicare, nu calitatea. DeepEval e în stil pytest și generalist: scrii cazuri de test și pui assertion pe pragurile metricilor, iar el acoperă output-uri de aplicații de multe feluri. Ragas e o bibliotecă specifică RAG al cărei evaluate() rulează asincron peste un dataset de rânduri cu întrebare, context și răspuns. DeepEval se potrivește mai natural într-o poartă de CI; Ragas merge mai adânc pe retrieval.

De ce pip install promptfoo îmi dă pachetul greșit?

Pentru că promptfoo e un proiect Node. Cel real e publicat pe npm sub MIT și se instalează cu npm install promptfoo. Pachetul PyPI cu același nume e un wrapper terț, nu proiectul original, iar instalarea lui e un mod comun de a ajunge să depanezi un CLI care nu e cel descris de documentație.

lm-evaluation-harness e un framework de evaluare LLM?

E un harness de evaluare pentru modele, ceea ce e o muncă înrudită, dar diferită. lm-evaluation-harness (instalat ca pip install lm-eval) face benchmark unui model față de task-uri publice standardizate precum MMLU. Nu-ți va spune dacă pipeline-ul tău de retrieval a returnat pasajul corect, pentru că aplicația ta nu e un concept pe care îl are. Vezi secțiunea framework-versus-harness de mai sus pentru diferență.

Aceste framework-uri sunt gratuite?

Din punct de vedere al licenței, da. DeepEval, Ragas, Opik, Evidently și Giskard sunt Apache-2.0; promptfoo, Inspect AI și lm-evaluation-harness sunt MIT. Ambele licențe permit uz comercial, modificare și redistribuire. Arize Phoenix e excepția: Elastic License 2.0 permite autohostarea, dar nu oferirea software-ului către terți ca serviciu gestionat. Consumul de API al modelului judecător e facturat separat de furnizorul tău.