Migliori Framework Open Source per la Valutazione LLM nel 2026 (Uno Non È Davvero Open Source)

Riga 1 del file LICENSE nel repo di Arize Phoenix recita "Elastic License 2.0 (ELv2)". Non Apache. Non MIT. Un framework open source per la valutazione LLM fortemente consigliato non è open source secondo la definizione dell'OSI, e quasi ogni pagina posizionata per questa query ripete comunque l'affermazione. Lo faceva anche una delle nostre, fino a oggi. Il 2026-08-04 abbiamo letto a mano il file di licenza e il log dei commit sul branch di default di otto framework, più altri tre ancora consigliati dalle pagine in prima posizione, poi ne abbiamo installati sei e fatto girare gli stessi 10 casi su ciascuno. Non vendiamo un framework di valutazione, quindi nessun verdetto qui sotto sta proteggendo un prodotto.

Punti Chiave

• Arize Phoenix è distribuito sotto Elastic License 2.0, che l'OSI non approva come open source.
• L'ultimo commit di UpTrain su main risale al 2024-07-29. Non partire con un nuovo progetto su questa base.
• pip install promptfoo installa un wrapper di terze parti. Il progetto vero è pubblicato su npm.
• Ragas non ha commit dal 2026-02-24 e ha cambiato organizzazione GitHub in vibrantlabsai.

Quale Framework Open Source per la Valutazione LLM Installare nel 2026?

Scegli in base al vincolo, non alla classifica. Per asserzioni in stile pytest dentro una suite di test esistente, installa DeepEval. Per una configurazione YAML e una CLI adatta a qualsiasi stack linguistico, installa promptfoo. Per la separazione più netta tra risposte buone e cattive che abbiamo misurato, installa Opik. Tutti e tre sono Apache-2.0 o MIT.

Ecco l'audit. Otto framework nel campione, più altri tre ancora consigliati dalle pagine in prima posizione per questa query.

Le date sono l'ultimo commit sul branch di default di ogni progetto al 2026-08-04. La pagina del repo su GitHub mostra invece l'ultimo push su qualsiasi branch, che è successivo per due progetti qui: UpTrain 2024-08-18 e Deepchecks 2025-12-28. Nessuno dei due repo è archiviato.

La colonna del costo di migrazione è quella che si tende a saltare, per poi pentirsene. I punteggi sono solo numeri, quindi passare tra DeepEval, Ragas, Opik e phoenix-evals significa perlopiù riscrivere un ciclo. Abbandonare promptfoo o Inspect AI significa riscrivere un formato di config o di task senza un equivalente altrove, e lasciare Evidently significa riverificare ogni soglia scritta, perché la sua scala va nella direzione opposta. Due dei framework ancora consigliati dalle pagine in prima posizione non pubblicano una release dal 2024.

Cerchi livelli, piattaforme in hosting e un ordinamento netto? È un altro lavoro, e lo abbiamo già fatto nel nostro confronto classificato degli strumenti di valutazione LLM, incluse le piattaforme a pagamento.

Gli Otto Framework di Valutazione LLM, Raggruppati per Modalità di Installazione

La forma dell'installazione è quello con cui devi convivere, quindi è il criterio di raggruppamento.

Librerie Python da importare nei test

DeepEval (pip install deepeval, Apache-2.0) incapsula le metriche LLM in asserzioni in stile pytest: costruisci un LLMTestCase, lo passi ad assert_test, e il test fallisce sotto la tua soglia. È al suo meglio quando serve mettere un gate di qualità accanto ai test unitari che un team già esegue. Sceglilo se i tuoi eval devono stare nello stesso job CI di tutto il resto.

Una precisazione, detta una volta sola: DeepEval è realizzato da Confident AI, partner a pagamento su altri due post di questo sito, incluso il confronto classificato a cui rimanda questa pagina. Non riceve trattamenti di favore qui, e ogni link a DeepEval in questa pagina rimanda al repo su GitHub.

Ragas (pip install ragas, Apache-2.0) è l'opzione specifica per RAG: evaluate() prende righe di domanda, contesto e risposta e restituisce punteggi per metrica in modo asincrono. È al suo meglio nella misurazione della qualità del retrieval dentro una pipeline Python. Il suo repo si è spostato da explodinggradients a vibrantlabsai, l'ultima release è stata v0.4.3 il 2026-01-13, e non ci sono commit dal 2026-02-24. Sceglilo se le metriche RAG sono l'intero lavoro e un repo silenzioso è accettabile, e vedi anche lo stack più ampio di strumenti RAG.

Opik (pip install opik, Apache-2.0, di Comet) offre metriche richiamabili in autonomia. Imposta OPIK_TRACK_DISABLE=true e AnswerRelevance().score() gira senza account, senza server locale e senza file di config, cosa che il posizionamento del prodotto non pubblicizza. È al suo meglio nell'ottenere un punteggio reale con il minor numero di righe. Sceglilo se vuoi le metriche subito e la piattaforma magari in seguito.

Evidently (pip install evidently, Apache-2.0) tratta gli eval come descrittori su un dataset e scrive un report HTML come effetto collaterale. È al suo meglio nella reportistica batch su molte righe piuttosto che in un gate binario. I suoi punteggi LLM sono invertiti: 1.0 significa non fedele. Sceglilo se quello che devi consegnare è un report condivisibile, non una build rossa.

Giskard (pip install giskard, Apache-2.0) esegue una scansione del modello alla ricerca di vulnerabilità invece di dare un punteggio a un dataset scritto da te. Il pacchetto su PyPI risolve la linea v2, e il README del progetto stesso dichiara che v2 "non è più mantenuta attivamente". È al suo meglio nelle scansioni automatiche in stile red-team. Sceglilo se vuoi che le vulnerabilità vengano trovate per te, invece di definire tu stesso le metriche LLM-as-a-judge.

Strumenti CLI-e-config da eseguire su un file YAML

promptfoo (npm install promptfoo, MIT) è una CLI che legge un file YAML: dichiari provider, test case e asserzioni, esegui npx promptfoo eval, e ottieni un pass/fail per caso più un'interfaccia dei risultati in locale. È al suo meglio nella valutazione dei prompt quando la tua app non è scritta in Python. Sceglilo se il tuo gate di qualità deve essere un file di config che un collega non-Python può modificare.

Harness e piattaforme integrate

Inspect AI (pip install inspect-ai, MIT) arriva dallo UK AI Safety Institute e valuta i modelli contro task che definisci in Python, con vere astrazioni di solver e scorer e un visualizzatore delle run. È al suo meglio nel benchmark a livello di modello con definizioni di task riproducibili. Sceglilo se ciò che stai testando è un modello e non la tua applicazione.

Arize Phoenix (pip install arize-phoenix-evals) offre valutatori predefiniti come FaithfulnessEvaluator e CorrectnessEvaluator che restituiscono un'etichetta binaria più un punteggio. È al suo meglio nelle etichette deterministiche su cui fare gate senza scegliere una soglia. La sua licenza è il motivo per cui questo articolo ha una parentesi nel titolo, ed è l'argomento della prossima sezione.

Arize Phoenix È Open Source?

No, non secondo la definizione mantenuta dall'Open Source Initiative. Arize Phoenix è distribuito sotto Elastic License 2.0 (ELv2). La riga 1 del file LICENSE del repo lo dichiara, e PyPI dichiara indipendentemente license: Elastic-2.0 sulla v19.15.0. Il codice sorgente è leggibile, forkabile e ospitabile in autonomia. Un solo uso è limitato.

La restrizione che conta: ELv2 vieta di fornire il software a terze parti come servizio ospitato o gestito. Leggila con attenzione, perché vincola molte meno persone di quanto sembri. Se installi arize-phoenix-evals per valutare la tua stessa applicazione, ELv2 non ti riguarda mai. Se sei una consulenza o un team di piattaforma che impacchetta Phoenix in un servizio di eval venduto a clienti esterni, sì. È tutto lì il confine, e la Open Source Definition è ciò che ELv2 non rispetta, in particolare le clausole sulle restrizioni di ambito d'uso.

Ogni pagina attualmente posizionata per questa query classifica Phoenix come "open source", e lo facevamo anche noi. Il nostro stesso confronto classificato degli strumenti di valutazione LLM descrive Phoenix come pienamente open source, il che è sbagliato, ed è in fase di correzione. Phoenix è source-available, non open source, e la distinzione conta solo se pensi di venderlo come servizio. Se ti serve il tracing e non lo scoring, l'argomento appartiene alle piattaforme di osservabilità AI, non a questo articolo.

Quali di Questi Framework Sono Ancora Attivamente Mantenuti?

La maggior parte. Sei degli undici repo verificati hanno ricevuto un commit su main il 2026-08-03 o il 2026-08-04: DeepEval, promptfoo, Opik, Arize Phoenix, Inspect AI e Giskard. Due non pubblicano una release dal 2024. Uno è diventato silenzioso nel 2026 dopo un cambio di organizzazione GitHub.

Framework su cui non avvieremmo un nuovo progetto nel 2026

UpTrain è morto. Il suo ultimo commit su main è arrivato il 2024-07-29 e la sua ultima release, v0.7.1, risale al 2024-05-14, il che lo colloca a due anni di distanza su entrambe le misure. Il repo esiste ancora ed è ancora Apache-2.0, quindi nulla te lo impedisce, ma avviare un nuovo lavoro su una libreria di valutazione abbandonata è una decisione che dovrai spiegare più avanti.

Deepchecks merita la versione precisa. Non ha una release dalla 0.19.1 del 2024-12-15, anche se il repo continua a ricevere commit, con l'ultimo su main datato 2025-11-24. People are still working on it: non è che nessuno ci lavori più, semplicemente nessuno taglia una versione da oltre diciotto mesi. Né UpTrain né Deepchecks sono archiviati su GitHub, e nessuno dei due ha chiuso i contributi.

Ragas riceve date e nient'altro. Ultima release v0.4.3 il 2026-01-13, nessun commit dal 2026-02-24, e il repo si è spostato da explodinggradients a vibrantlabsai. Non abbiamo trovato un resoconto verificabile del motivo del cambio di organizzazione, quindi non ne inventiamo uno. Un repo silenzioso non è un repo rotto: il codice Apache-2.0 che oggi calcola un punteggio di fedeltà lo calcolerà anche l'anno prossimo. L'esposizione riguarda le dipendenze non aggiornate, che è esattamente ciò che ci ha morso nei test più sotto.

Altre pagine in prima pagina per questa query continuano a consigliare sia UpTrain sia Deepchecks, senza alcuna data accanto al consiglio. Un framework senza una release da dicembre 2024 è una decisione sulle dipendenze, non una decisione sulle funzionalità.

Ti Serve un Framework di Valutazione o un Harness di Valutazione?

Un framework di valutazione applicativo dà un punteggio agli output della tua app rispetto ai tuoi dati. DeepEval, Ragas, promptfoo, Opik, phoenix-evals ed Evidently fanno questo. Un harness di valutazione modello confronta invece un modello con task pubblici standardizzati. lm-evaluation-harness e Inspect AI fanno questo. Scegliere la categoria sbagliata è l'errore più costoso di questa pagina.

Il modo in cui si sbaglia è concreto. Qualcuno collega lm-evaluation-harness per testare il proprio chatbot RAG, ottiene un set di punteggi MMLU, e non impara nulla su se il proprio retriever restituisca i passaggi giusti. I punteggi sono reali. Stanno misurando il modello di base, di cui nessuno era preoccupato.

La forma di Inspect AI deriva dalla sua provenienza: è stato costruito allo UK AI Safety Institute sotto licenza MIT per valutare modelli frontier, quindi solver, scorer e task sono cittadini di prima classe e la tua applicazione non è un concetto che possiede. È un buon motivo per usarlo per ciò per cui è pensato. Se il tuo problema riguarda gli agenti e non i singoli turni, valutare gli agenti in produzione è una disciplina diversa, e i server tool-calling hanno una trattazione a parte nella nostra guida alla valutazione dei server e degli strumenti MCP.

Cosa È Successo Quando Ne Abbiamo Installati Sei ed Eseguito gli Stessi 10 Casi

Il 2026-08-04 abbiamo installato sei di questi in venv Python 3.11.14 appena creati (più npm per promptfoo) e valutato lo stesso set RAG identico di 10 elementi con un solo giudice, openai/gpt-4o-mini tramite OpenRouter a temperatura 0. Sette elementi erano corretti. Tre erano difettosi in tre modi diversi: uno contraddice il proprio contesto, uno inventa dei dettagli, uno è prosa fluente che non risponde mai alla domanda. Ogni framework è stato eseguito due volte, di fila.

Cinque metriche di grounding su sei hanno rilevato tutti e tre i difetti. I tre risultati qui sotto sono il motivo per cui esiste questa sezione.

Le metriche di rilevanza non sono metriche di qualità, e due di esse hanno valutato una bugia sicura di sé al di sopra di una risposta corretta. Ragas ResponseRelevancy ha assegnato all'elemento che afferma che HTTP 404 è un errore server 5xx un punteggio di 0.777, superiore a due delle sette risposte corrette, e all'elemento con limiti di frequenza inventati un punteggio di 0.813, superiore a quattro. promptfoo answer-relevance ha fatto lo stesso: 0.800 per l'elemento sul 404, un pass netto contro una soglia di 0.7, mentre falliva la corretta q01 a 0.679. Non è un bug. Una risposta sbagliata ma sicura di sé affronta la domanda perfettamente. Ma se la rilevanza è il numero sul tuo dashboard, un'allucinazione fluente sembra il tuo output migliore.

Un gate basato sulla sola fedeltà si perde la risposta irrilevante. DeepEval ha assegnato all'elemento che non risponde mai alla domanda un punteggio di 1.000 di faithfulness, un pass netto, il che è difendibile: una risposta che non afferma nulla sul contesto non contraddice nulla al suo interno. Solo la rilevanza lo ha rilevato, a 0.000. Questo è l'unico difetto di grounding mancato nella tabella qui sopra. Ciascuna metrica presa da sola ha un buco; la coppia copre entrambi.

I valutatori binari sono rimasti stabili a temperatura 0. Quelli graduati no. Phoenix e DeepEval hanno spostato zero elementi su dieci tra due run identiche. Opik ne ha spostati quattro, tutti su AnswerRelevance, su una griglia di 0.05; anche Evidently ne ha spostati quattro. Nessuna deriva ha ribaltato un verdetto qui, ma la corretta q01 di promptfoo si è posizionata a 0.679 e poi a 0.642 contro una soglia di 0.700, che è la forma tipica di un gate CI instabile.

Due note minori: tre framework su sei (DeepEval, Opik, Phoenix) si sono installati ed eseguiti senza intoppi al primo tentativo, mentre Ragas non si importava finché non abbiamo vincolato langchain-community<0.4. Solo promptfoo ha riportato l'uso di token del giudice, 16.011 token di asserzione nella run 1 e 16.010 nella run 2.

I limiti di questo test, detti chiaramente. n = 10 è uno smoke test, non un benchmark: dice qualcosa sull'ergonomia e sui punti ciechi, non sull'accuratezza delle metriche. Un solo modello giudice ha valutato tutto, e un giudice più grande sposterebbe ogni numero, probabilmente inclusi i due falsi positivi che DeepEval e Ragas hanno entrambi prodotto sullo stesso elemento corretto. Due run dimostrano che la deriva esiste ma non possono caratterizzarla. Le risposte erano pre-scritte, quindi nulla qui esercita la generazione, il tracing o la gestione dei dataset, il che fa sembrare l'installazione di promptfoo da 337.9 secondi peggiore di quanto meriti. "Migliore" significa sempre migliore rispetto a un vincolo: un gate CI, metriche RAG o un'interfaccia utente cambiano ciascuno la risposta, così come la distinzione tra valutazione offline e online.

Lo Stesso Controllo, Scritto in Tre Modi

Il modo più veloce per scegliere una forma di interfaccia è leggere la stessa asserzione tre volte. Ecco un controllo di grounding su un elemento in DeepEval, Ragas e promptfoo, ridotto dagli script che abbiamo effettivamente eseguito. I nomi delle metriche differiscono; rimandiamo a come funzionano davvero le metriche LLM-as-a-judge invece di ridefinirle qui.

# DeepEval 4.1.5: in stile pytest, fa fallire il test sotto la soglia
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: nota il percorso di import. `from ragas.metrics import Faithfulness`
# solleva ImportError in questa versione; la metrica concreta si è spostata.
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, poi npx promptfoo eval
providers:
  - id: echo          # we scored pre-written answers instead of generating them
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."

Le righe di installazione nascondono più insidie del codice stesso, e ogni commento qui sotto è qualcosa che ci ha fatto perdere tempo il 2026-08-04:

# The real promptfoo ships on npm. The PyPI package of the same name is a
# third-party wrapper: https://pypi.org/project/promptfoo/ vs
# https://www.npmjs.com/package/promptfoo
npm install promptfoo

# pip install giskard resolves the v2 line, which the project's own README
# marks as no longer actively maintained.
pip install giskard

# lm-evaluation-harness installs under the package name lm-eval.
pip install lm-eval

# Evidently does not pull openai, and the judge crashes at call time rather
# than import time, after you've already built the dataset.
pip install evidently openai

# Ragas 0.4.3 will not import against langchain-community 0.4.x.
pip install ragas "langchain-community<0.4"

Puoi Far Fallire una Build su un Punteggio di Eval?

Sì. Ogni framework qui restituisce un punteggio numerico o binario, e ciascuno esce con codice diverso da zero quando un'asserzione di soglia fallisce, che è tutto ciò di cui GitHub Actions ha bisogno per rendere rossa una build. Collegare il codice di uscita è la parte facile. Scegliere una soglia che il tuo modello giudice non superi per caso è la parte che richiede una settimana.

Ecco la forma del workflow che eseguiamo, ancorata alle versioni del nostro test del 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:
          # Pin the judge. A model upgrade mid-quarter moves every score.
          JUDGE_MODEL: openai/gpt-4o-mini
          # Thresholds live in one place, read by the metric constructors.
          EVAL_THRESHOLD: "0.7"
          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
        run: deepeval test run tests/evals/

Due insidie mordono prima della soglia. Primo, le chiamate al giudice sono chiamate di rete: la nostra run DeepEval a 10 elementi ha impiegato 126.8 secondi perché .measure() è sequenziale, e un golden set da 200 elementi su quel percorso di codice è una pausa caffè ad ogni pull request. Ogni altro framework nel test parallelizza per impostazione predefinita, il che è la leva singola più grande sul tempo reale della CI.

Secondo, la flakiness. A temperatura 0, Opik ed Evidently hanno spostato ciascuno quattro elementi su dieci tra run consecutive, e la risposta corretta di promptfoo si è posizionata a 0.679 e poi a 0.642 contro un gate di 0.700. Le mitigazioni sono noiose e funzionano: esegui un golden dataset fisso che cambia solo per pull request, ancora il modello giudice, preferisci valutatori binari dove un'etichetta basta, e fai gate su un delta invece che su un pavimento assoluto. Quest'ultimo punto conta di più per la valutazione multi-turn, dove una singola conversazione produce molti punteggi che possono oscillare ciascuno per conto proprio.

Per un ordine di grandezza: il sondaggio State of Agent Engineering di LangChain (1.340 risposte, raccolte dal 18 novembre al 2 dicembre 2025, pubblicato il 12 giugno 2026) ha rilevato che l'89% delle organizzazioni ha implementato una qualche forma di osservabilità per i propri agenti, mentre solo il 52.4% esegue valutazioni offline su set di test. Osservare è comune. Fare gate no.

Cosa Installeremmo Questa Settimana

Quattro cose da portare a casa. Arize Phoenix è source-available sotto Elastic License 2.0 e non è open source approvato dall'OSI, il che non cambia nulla per la maggior parte dei lettori e cambia tutto se rivendi strumenti di valutazione. UpTrain è morto, e pagine senza data continuano a consigliarlo. Anche Deepchecks non taglia una release da dicembre 2024, sebbene il suo repo riceva ancora commit. Una metrica di grounding e una di rilevanza hanno ciascuna un buco che l'altra copre, quindi fai gate su entrambe. E i punteggi graduati derivano a temperatura 0, quindi ancora il tuo giudice e lascia margine alle soglie.

Se dovessi avviare una nuova suite di eval questa settimana, installerei DeepEval per il gate CI perché le asserzioni appartengono accanto ai test (precisazione sopra), e aggiungerei le metriche autonome di Opik per la separazione più netta che abbiamo misurato. Se il nostro stack non fosse Python, promptfoo senza esitazione. Se preferisci che qualcun altro colleghi il golden set e il workflow, è una conversazione che siamo felici di fare.

Domande Frequenti

Qual è il miglior framework open source per la valutazione LLM?

Non c'è un vincitore unico, solo la scelta migliore per ogni vincolo. Per un gate pass/fail dentro una suite di test Python, DeepEval. Per una configurazione YAML e CLI indipendente dal linguaggio, promptfoo. Per le metriche di retrieval RAG, Ragas, se accetti un repo senza commit dal 2026-02-24. Per la separazione più netta tra risposte buone e cattive nel nostro test del 2026-08-04, Opik.

Arize Phoenix è open source?

No, non secondo la definizione dell'Open Source Initiative. Arize Phoenix è distribuito sotto Elastic License 2.0, che PyPI dichiara come license: Elastic-2.0 sulla v19.15.0 e che la riga 1 del file LICENSE del repo dichiara direttamente. È source-available: puoi leggerlo, forkarlo, modificarlo e ospitarlo tu stesso. L'unica restrizione è offrire il software a terze parti come servizio ospitato o gestito.

Ragas è ancora mantenuto?

I fatti verificabili, al 2026-08-04: l'ultima release è stata v0.4.3 il 2026-01-13, non ci sono commit dal 2026-02-24, e il repository si è spostato dall'organizzazione explodinggradients a vibrantlabsai. Il repo non è archiviato. Non abbiamo trovato una spiegazione pubblica affidabile del cambio di organizzazione e non ne inventiamo una. Il codice Apache-2.0 gira ancora; l'esposizione riguarda le dipendenze non aggiornate.

Mi serve un framework di valutazione o una piattaforma di osservabilità?

Entrambi, alla fine, ma rispondono a domande diverse. Un framework di valutazione ti dice se una modifica ha reso i tuoi output migliori o peggiori prima di rilasciarla, su un dataset che controlli. Una piattaforma di osservabilità ti dice cosa è realmente accaduto in produzione dopo il rilascio. Parti dal framework di valutazione se hai una pipeline CI; vedi le piattaforme di osservabilità AI per il lato produzione.

Posso eseguire eval LLM in CI/CD?

Sì. Ogni framework trattato qui esce con codice diverso da zero su un'asserzione di soglia fallita, che è tutto ciò di cui ha bisogno un job GitHub Actions. I vincoli pratici sono il tempo reale (le chiamate al giudice sono chiamate di rete, e la nostra run DeepEval sequenziale ha impiegato 126.8 secondi per 10 elementi) e la non-determinatezza del giudice. La forma del workflow e le mitigazioni sono nella sezione CI sopra.

Qual è la differenza tra DeepEval e Ragas?

Forma dell'interfaccia e ambito, non qualità. DeepEval è in stile pytest e generico: scrivi test case e fai asserzioni su soglie di metrica, e copre output applicativi di molti tipi. Ragas è una libreria specifica per RAG la cui evaluate() gira in modo asincrono su un dataset di righe domanda, contesto e risposta. DeepEval si adatta più naturalmente a un gate CI; Ragas va più a fondo sul retrieval.

Perché pip install promptfoo mi dà il pacchetto sbagliato?

Perché promptfoo è un progetto Node. Quello vero è pubblicato su npm sotto MIT e si installa con npm install promptfoo. Il pacchetto PyPI con lo stesso nome è un wrapper di terze parti, non il progetto originale, e installarlo è un modo comune per finire a debuggare una CLI diversa da quella descritta nella documentazione.

lm-evaluation-harness è un framework di valutazione LLM?

È un harness di valutazione modello, un lavoro affine ma diverso. lm-evaluation-harness (installato come pip install lm-eval) confronta un modello con task pubblici standardizzati come MMLU. Non ti dirà se la tua pipeline di retrieval ha restituito il passaggio giusto, perché la tua applicazione non è un concetto che possiede. Vedi la sezione framework contro harness sopra per la distinzione.

Questi framework sono gratuiti da usare?

Dal punto di vista della licenza, sì. DeepEval, Ragas, Opik, Evidently e Giskard sono Apache-2.0; promptfoo, Inspect AI e lm-evaluation-harness sono MIT. Entrambe le licenze permettono uso commerciale, modifica e redistribuzione. Arize Phoenix è l'eccezione: Elastic License 2.0 permette l'auto-hosting ma non offrire il software a terze parti come servizio gestito. L'uso dell'API del modello giudice è fatturato separatamente dal tuo fornitore.