Beste Open Source LLM-evalueringsrammeverk i 2026 (ett er faktisk ikke open source)

Beste Open Source LLM-evalueringsrammeverk i 2026 (ett er faktisk ikke open source)

Linje 1 i LICENSE-filen i Arize Phoenix-repoet lyder "Elastic License 2.0 (ELv2)". Ikke Apache. Ikke MIT. Ett av de mest anbefalte open source LLM-evalueringsrammeverkene er ikke open source etter OSIs definisjon, og nesten alle sider som rangerer for dette søket gjentar likevel påstanden. Det gjorde en av våre også, frem til i dag. Den 2026-08-04 leste vi lisensfilen og commit-loggen på hovedgrenen til åtte rammeverk for hånd, pluss tre til som de øverste sidene fortsatt anbefaler, og installerte deretter seks og kjørte de samme 10 testene gjennom hver. Vi selger ikke et eval-rammeverk, så ingen konklusjon nedenfor beskytter et produkt.

Hovedfunn

• Arize Phoenix leveres under Elastic License 2.0, som OSI ikke godkjenner som open source.
• UpTrains siste commit til main var 2024-07-29. Ikke start et nytt prosjekt på det.
• pip install promptfoo gir deg en tredjeparts wrapper. Det ekte prosjektet leveres på npm.
• Ragas har ingen commits siden 2026-02-24 og flyttet GitHub-organisasjon til vibrantlabsai.

Hvilket open source LLM-evalueringsrammeverk bør du installere i 2026?

Velg etter behov, ikke etter rangering. For pytest-formede assertions inne i en eksisterende testpakke, installer DeepEval. For en YAML-konfigurasjon og en CLI som passer enhver språkstack, installer promptfoo. For det klareste skillet mellom gode og dårlige svar vi målte, installer Opik. Alle tre er Apache-2.0 eller MIT.

Her er gjennomgangen. Åtte rammeverk i omfang, pluss tre til som de øverst rangerte sidene for dette søket fortsatt anbefaler.

Datoene er siste commit på hvert prosjekts hovedgren per 2026-08-04. GitHubs repo-side viser siste push til hvilken som helst gren, som er senere for to prosjekter her: UpTrain 2024-08-18 og Deepchecks 2025-12-28. Ingen av repoene er arkivert.

Byttekostnad-kolonnen er den folk hopper over og angrer på senere. Scores er bare tall, så å bytte mellom DeepEval, Ragas, Opik og phoenix-evals betyr stort sett bare å omskrive en løkke. Å bytte bort fra promptfoo eller Inspect AI betyr å omskrive et konfig- eller task-format uten ekvivalent noe annet sted, og å bytte bort fra Evidently betyr å revidere hver eneste terskel du har skrevet, fordi skalaen går motsatt vei. To av rammeverkene de øverst rangerte sidene fortsatt anbefaler, har ikke sluppet en release siden 2024.

Vil du ha nivåer, hostede plattformer og en ren rangering i stedet? Det er en annen jobb, og vi har allerede gjort den i vår rangerte sammenligning av LLM-evalueringsverktøy inkludert betalte plattformer.

De åtte LLM-evalueringsrammeverkene, gruppert etter hvordan du installerer dem

Installasjonsformen er det du må leve med, så det er slik vi grupperer dem.

Python-biblioteker du importerer inn i tester

DeepEval (pip install deepeval, Apache-2.0) pakker LLM-metrikker inn i pytest-formede assertions: bygg en LLMTestCase, gi den til assert_test, og testen feiler under terskelen din. Best på å plassere en kvalitetssluse rett ved siden av enhetstestene et team allerede kjører. Velg denne hvis evalueringene dine hører hjemme i samme CI-jobb som alt annet.

Én opplysning, sagt én gang: DeepEval er bygget av Confident AI, som er en betalt partner på to andre innlegg på dette nettstedet, inkludert den rangerte sammenligningen denne siden lenker til. Det får ingen særbehandling her, og hver DeepEval-lenke på denne siden peker til GitHub-repoet.

Ragas (pip install ragas, Apache-2.0) er det RAG-spesifikke alternativet: evaluate() tar spørsmål, kontekst og svar-rader og returnerer per-metrikk-scorer asynkront. Best på hentekvalitetsmåling inne i en Python-pipeline. Repoet flyttet fra explodinggradients til vibrantlabsai, siste release var v0.4.3 den 2026-01-13, og det er ingen commits siden 2026-02-24. Velg denne hvis RAG-metrikker er hele jobben og et stille repo er akseptabelt, og se den bredere RAG-verktøystacken.

Opik (pip install opik, Apache-2.0, fra Comet) leverer metrikker du kan kalle på egen hånd. Sett OPIK_TRACK_DISABLE=true og AnswerRelevance().score() kjører uten konto, uten lokal server og uten konfigfil, noe produktbeskrivelsen ikke reklamerer med. Best på å få en ekte score på færrest linjer. Velg denne hvis du vil ha metrikker nå og plattformen kanskje senere.

Evidently (pip install evidently, Apache-2.0) behandler evalueringer som beskrivelser over et datasett og skriver en HTML-rapport som en bieffekt. Best på batch-rapportering over mange rader fremfor en binær sluse. LLM-scorene er omvendte: 1.0 betyr uten grunnlag i konteksten. Velg denne hvis det du skylder noen er en delbar rapport, ikke en rød build.

Giskard (pip install giskard, Apache-2.0) skanner en modell for sårbarheter i stedet for å score et datasett du selv skrev. PyPI-pakken løser opp til v2-linjen, og prosjektets egen README sier at v2 "ikke lenger vedlikeholdes aktivt". Best på automatiserte red-team-lignende skanninger. Velg denne hvis du vil ha sårbarheter funnet for deg fremfor LLM-as-a-judge-metrikker du definerer selv.

CLI- og konfig-verktøy du kjører mot en YAML-fil

promptfoo (npm install promptfoo, MIT) er en CLI som leser en YAML-fil: deklarer providere, testtilfeller og assertions, kjør npx promptfoo eval, og få bestått/ikke bestått per tilfelle pluss en lokal resultat-UI. Best på å evaluere prompter når appen din ikke er skrevet i Python. Velg denne hvis kvalitetsslusen din bør være en konfigfil et ikke-Python-teammedlem kan redigere.

Harness-klasse og plattformbundlet

Inspect AI (pip install inspect-ai, MIT) kommer fra UK AI Safety Institute og evaluerer modeller mot tasker du definerer i Python, med ekte solver- og scorer-abstraksjoner og en run-viewer. Best på modellnivå-benchmarking med reproduserbare task-definisjoner. Velg denne hvis det som testes er en modell fremfor applikasjonen din.

Arize Phoenix (pip install arize-phoenix-evals) gir deg ferdigbygde evaluatorer som FaithfulnessEvaluator og CorrectnessEvaluator som returnerer et binært merke pluss en score. Best på deterministiske merker du kan sluse på uten å velge en terskel. Lisensen er grunnen til at denne artikkelen har en parentes i tittelen, og det får sin egen seksjon nå.

Er Arize Phoenix open source?

Nei, ikke etter definisjonen Open Source Initiative opprettholder. Arize Phoenix leveres under Elastic License 2.0 (ELv2). Linje 1 i repoets LICENSE-fil sier det, og PyPI erklærer uavhengig license: Elastic-2.0 på v19.15.0. Kildekoden er lesbar, kan forkes og kan selv-hostes. Én bruk er begrenset.

Begrensningen som betyr noe: ELv2 forbyr å tilby programvaren til tredjeparter som en hostet eller administrert tjeneste. Les det nøye, for det binder langt færre enn det høres ut som. Hvis du installerer arize-phoenix-evals for å score din egen applikasjon, berører ELv2 deg aldri. Hvis du er et konsulentselskap eller et plattformteam som pakker Phoenix inn i en eval-tjeneste dere selger til eksterne kunder, gjør den det. Det er hele forskjellen, og Open Source Definition er det ELv2 ikke oppfyller, spesifikt klausulene om bruksområdebegrensninger.

Hver eneste side som for øyeblikket rangerer for dette søket, plasserer Phoenix under "open source", og det gjorde vi også. Vår egen rangerte sammenligning av LLM-evalueringsverktøy beskriver Phoenix som fullstendig open source, noe som er feil, og det rettes nå opp. Phoenix er source-available, ikke open source, og skillet spiller bare en rolle hvis du planlegger å selge det som en tjeneste. Hvis det er sporing snarere enn scoring du faktisk trenger, hører det hjemme under AI-observabilitetsplattformer, ikke her.

Hvilke av disse vedlikeholdes fortsatt aktivt?

De fleste av dem. Seks av de elleve repoene vi sjekket, tok en commit til main den 2026-08-03 eller 2026-08-04: DeepEval, promptfoo, Opik, Arize Phoenix, Inspect AI og Giskard. To har ikke sluppet en release siden 2024. Ett har blitt stille i 2026 etter et skifte av GitHub-organisasjon.

Rammeverk vi ikke ville startet et nytt prosjekt på i 2026

UpTrain er dødt. Siste commit til main landet 2024-07-29, og siste release, v0.7.1, var 2024-05-14, som gjør det to år kaldt på begge mål. Repoet er fortsatt der og fortsatt Apache-2.0, så ingenting stopper deg, men å starte nytt arbeid på et forlatt evalueringsbibliotek er en beslutning du kommer til å forklare senere.

Deepchecks fortjener den presise versjonen. Det har ikke hatt en release siden 0.19.1 den 2024-12-15, selv om repoet fortsatt mottar commits, med den siste på main datert 2025-11-24. Folk jobber fortsatt med det; ingen har kuttet en versjon på over atten måneder. Verken UpTrain eller Deepchecks er arkivert på GitHub, og ingen av dem er stengt for bidrag.

Ragas får datoer og ikke noe annet. Siste release v0.4.3 den 2026-01-13, ingen commits siden 2026-02-24, og repoet flyttet fra explodinggradients til vibrantlabsai. Vi fant ingen verifiserbar forklaring på hvorfor organisasjonen endret seg, så vi finner ikke opp en. Et stille repo er ikke det samme som et ødelagt et: Apache-2.0-kode som beregner en faithfulness-score i dag, beregner den fortsatt neste år. Eksponeringen er upatchede avhengigheter, som er akkurat det som bet oss i testingen nedenfor.

Andre sider på side én av dette søket anbefaler fortsatt både UpTrain og Deepchecks, uten dato knyttet til anbefalingen. Et rammeverk uten release siden desember 2024 er en avhengighetsbeslutning, ikke en funksjonsbeslutning.

Trenger du et eval-rammeverk eller en eval-harness?

Et applikasjons-eval-rammeverk scorer appens egne output mot dine egne data. DeepEval, Ragas, promptfoo, Opik, phoenix-evals og Evidently gjør alle det. En modell-eval-harness benchmarker en modell mot standardiserte offentlige tasker i stedet. lm-evaluation-harness og Inspect AI gjør det. Å velge feil klasse er den dyreste feilen på denne siden.

Feilmodusen er konkret. Noen kobler lm-evaluation-harness til for å teste RAG-chatboten sin, får et sett med MMLU-scorer tilbake, og lærer nøyaktig ingenting om hvorvidt retrieveren returnerer de riktige passasjene. Scorene er ekte. De måler grunnmodellen, som ingen var bekymret for.

Inspect AIs form følger av opprinnelsen: det ble bygget ved UK AI Safety Institute under MIT for å evaluere frontier-modeller, så solvere, scorere og tasker er førsteklasses, og applikasjonen din er ikke et konsept det har. Det er en god grunn til å bruke det til det det er laget for. Hvis problemet ditt er agenter fremfor enkeltturer, er evaluering av agenter i produksjon en annen disiplin, og verktøykallende servere får sin egen behandling i vår guide til evaluering av MCP-servere og verktøy.

Hva skjedde da vi installerte seks av dem og kjørte de samme 10 testene

Den 2026-08-04 installerte vi seks av disse i ferske Python 3.11.14-venv-er (pluss npm for promptfoo) og scoret ett identisk 10-elements RAG-sett med én dommer, openai/gpt-4o-mini via OpenRouter ved temperatur 0. Syv elementer var korrekte. Tre var ødelagte på tre forskjellige måter: ett motsier konteksten sin, ett finner opp detaljer, ett er flytende prosa som aldri svarer på spørsmålet. Hvert rammeverk kjørte to ganger, rett etter hverandre.

Fem av seks grunnlagsmetrikker fanget alle tre feilene. De tre funnene nedenfor er grunnen til at denne seksjonen eksisterer.

Relevans-metrikker er ikke kvalitetsmetrikker, og to av dem ga en selvsikker løgn høyere score enn et korrekt svar. Ragas ResponseRelevancy scoret elementet som hevder at HTTP 404 er en 5xx-serverfeil til 0.777, over to av de syv korrekte svarene, og elementet med oppdiktede rate limits til 0.813, over fire. promptfoo answer-relevance gjorde det samme: 0.800 for 404-elementet, en ren bestått mot en 0.7-terskel, mens det korrekte q01 falt gjennom med 0.679. Ikke en bug. Et selvsikkert feil svar adresserer spørsmålet perfekt. Men hvis relevans er tallet på dashbordet ditt, ser en flytende hallusinasjon ut som din beste output.

En sluse som kun bruker faithfulness går glipp av det irrelevante svaret. DeepEval scoret elementet som aldri svarer på spørsmålet, til 1.000 faithfulness, en ren bestått, som er forsvarlig: et svar som ikke hevder noe om konteksten motsier heller ingenting i den. Bare relevancy fanget det, med 0.000. Det er det eneste grunnlagsmissen i tabellen over. Én av metrikkene alene har et hull; sammen dekker de begge.

Binære evaluatorer var stabile ved temperatur 0. Graderte var det ikke. Phoenix og DeepEval flyttet null av ti elementer over to identiske kjøringer. Opik flyttet fire, alle på AnswerRelevance, på et 0.05-rutenett; Evidently flyttet også fire. Ingen drift snudde en konklusjon her, men promptfoos korrekte q01 landet på 0.679 og deretter 0.642 mot en 0.700-terskel, som er formen på en flaksete CI-sluse.

To mindre notater: tre av seks (DeepEval, Opik, Phoenix) installerte og kjørte rent første gang, mens Ragas ikke ville importeres før vi låste langchain-community<0.4. Bare promptfoo rapporterte dommer-tokenbruk, 16 011 assertion-tokens i kjøring 1 og 16 010 i kjøring 2.

Begrensningene her, sagt rett ut. n = 10 er en røyktest, ikke en benchmark: den forteller deg om ergonomi og blindsoner, ikke metrikk-nøyaktighet. Én dommermodell scoret alt, og en større dommer ville flytte hvert eneste tall, sannsynligvis inkludert de to falske positivene DeepEval og Ragas begge produserte på samme korrekte element. To kjøringer beviser at drift finnes, men kan ikke karakterisere den. Svarene var forhåndsskrevet, så ingenting her tester generering, sporing eller datasetthåndtering, noe som gjør promptfoos 337.9-sekunders installasjon til å se verre ut enn den fortjener. "Best" betyr alltid best for en gitt begrensning: en CI-sluse, RAG-metrikker eller et UI endrer alle svaret, det samme gjør skillet mellom offline og online evaluering.

Den samme sjekken, skrevet på tre måter

Den raskeste måten å velge grensesnittform på er å lese den samme assertion tre ganger. Her er en grunnlagssjekk på ett element i DeepEval, Ragas og promptfoo, trimmet fra skriptene vi faktisk kjørte. Metrikknavnene er forskjellige; vi lenker til hvordan LLM-as-a-judge-metrikker faktisk fungerer fremfor å definere dem på nytt her.

# DeepEval 4.1.5: pytest-formet, feiler testen under terskelen
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: legg merke til importstien. `from ragas.metrics import Faithfulness`
# gir ImportError i denne versjonen; den konkrete metrikken flyttet.
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, deretter npx promptfoo eval
providers:
  - id: echo          # vi scoret ferdigskrevne svar i stedet for å generere dem
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."

Installasjonslinjene inneholder flere feller enn koden gjør, og hver kommentar nedenfor er noe som kostet oss tid den 2026-08-04:

# Det ekte promptfoo leveres på npm. PyPI-pakken med samme navn er en
# tredjeparts wrapper: https://pypi.org/project/promptfoo/ vs
# https://www.npmjs.com/package/promptfoo
npm install promptfoo

# pip install giskard løser opp til v2-linjen, som prosjektets egen README
# markerer som ikke lenger aktivt vedlikeholdt.
pip install giskard

# lm-evaluation-harness installeres under pakkenavnet lm-eval.
pip install lm-eval

# Evidently henter ikke openai, og dommeren krasjer ved kalletidspunkt heller
# enn ved importtidspunkt, etter at du allerede har bygget datasettet.
pip install evidently openai

# Ragas 0.4.3 vil ikke importeres mot langchain-community 0.4.x.
pip install ragas "langchain-community<0.4"

Kan du felle en build på en eval-score?

Ja. Hvert rammeverk her returnerer en numerisk eller binær score, og hver vil avslutte med kode ulik null når en terskel-assertion feiler, som er alt GitHub Actions trenger for å gjøre en build rød. Å koble opp exit-koden er den enkle delen. Å velge en terskel dommermodellen din ikke krysser ved en tilfeldighet, er delen som tar en uke.

Dette er arbeidsflytformen vi kjører, låst til versjonene fra vår 2026-08-04-test:

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:
          # Lås dommeren. En modelloppgradering midt i kvartalet flytter hver score.
          JUDGE_MODEL: openai/gpt-4o-mini
          # Terskler holdes ett sted, lest av metrikk-konstruktørene.
          EVAL_THRESHOLD: "0.7"
          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
        run: deepeval test run tests/evals/

To feller biter før terskelen gjør det. For det første, dommerkall er nettverkskall: vår 10-elements DeepEval-kjøring tok 126.8 sekunder fordi .measure() er sekvensiell, og et 200-elements gullsett på den kodestien er en kaffepause på hver eneste pull request. Hvert annet rammeverk i testen parallelliserer som standard, som er den enkelthendelsen som påvirker CI-kjøretid mest.

For det andre, ustabilitet. Ved temperatur 0 flyttet Opik og Evidently hver fire av ti elementer mellom kjøringer rett etter hverandre, og promptfoos korrekte svar lå på 0.679 og deretter 0.642 mot en 0.700-sluse. Botemidlene er kjedelige og de fungerer: kjør et fast gullsett datasett som bare endres per pull request, lås dommermodellen, foretrekk binære evaluatorer der et merke holder, og sluse på en delta fremfor et absolutt gulv. Det siste betyr mest for flerturns-evaluering, der én samtale produserer mange scorer som hver kan vakle.

Til skala: LangChains State of Agent Engineering-undersøkelse (1 340 svar, samlet inn 18. november til 2. desember 2025, publisert 12. juni 2026) fant at 89% av organisasjonene har innført en eller annen form for observabilitet for sine agenter, mens bare 52.4% kjører offline-evalueringer på testsett. Å observere er vanlig. Å sluse er det ikke.

Hva vi ville installert denne uken

Fire ting å ta med seg. Arize Phoenix er source-available under Elastic License 2.0 og er ikke OSI-godkjent open source, noe som endrer ingenting for de fleste lesere og alt hvis du videreselger eval-verktøy. UpTrain er dødt, og sider uten dato anbefaler det fortsatt. Deepchecks har heller ikke kuttet en release siden desember 2024, selv om repoet fortsatt tar imot commits. En grunnlagsmetrikk og en relevansmetrikk har hver sitt hull som den andre dekker, så sluse på begge. Og graderte scorer driver ved temperatur 0, så lås dommeren din og gi tersklene litt rom.

Hvis jeg skulle starte en ny eval-pakke denne uken, ville jeg installert DeepEval for CI-slusen fordi assertions hører hjemme rett ved siden av testene (opplysning over), og lagt til Opiks frittstående metrikker for det klareste skillet vi målte. Hvis stacken vår ikke var Python, promptfoo i stedet, uten å nøle. Hvis du heller vil at noen andre skal koble opp gullsettet og arbeidsflyten, er det en samtale vi gjerne tar.

Ofte stilte spørsmål

Hva er det beste open source LLM-evalueringsrammeverket?

Det finnes ikke én vinner, bare en beste passform per behov. For en bestått/ikke bestått-sluse inne i en Python-testpakke, DeepEval. For et språkuavhengig YAML- og CLI-oppsett, promptfoo. For RAG-hentemetrikker, Ragas, hvis du kan akseptere et repo uten commits siden 2026-02-24. For det klareste skillet mellom gode og dårlige svar i vår 2026-08-04-test, Opik.

Er Arize Phoenix open source?

Ikke etter Open Source Initiatives definisjon. Arize Phoenix leveres under Elastic License 2.0, som PyPI erklærer som license: Elastic-2.0 på v19.15.0, og som linje 1 i repoets LICENSE-fil sier direkte. Det er source-available: du kan lese, forke, endre og selv-hoste det. Den ene begrensningen er å tilby programvaren til tredjeparter som en hostet eller administrert tjeneste.

Vedlikeholdes Ragas fortsatt?

De verifiserbare faktaene, per 2026-08-04: siste release var v0.4.3 den 2026-01-13, det har ikke vært commits siden 2026-02-24, og repoet flyttet fra organisasjonen explodinggradients til vibrantlabsai. Repoet er ikke arkivert. Vi fant ingen pålitelig offentlig forklaring på organisasjonsendringen og spekulerer ikke om en. Apache-2.0-koden fungerer fortsatt; eksponeringen er upatchede avhengigheter.

Trenger jeg et eval-rammeverk eller en observabilitetsplattform?

Begge deler, etter hvert, men de svarer på ulike spørsmål. Et eval-rammeverk forteller deg om en endring gjorde outputene dine bedre eller dårligere før du sender den, på et datasett du kontrollerer. En observabilitetsplattform forteller deg hva som faktisk skjedde i produksjon etter at du sendte det. Start med eval-rammeverket hvis du har en CI-pipeline; se AI-observabilitetsplattformer for produksjonssiden.

Kan jeg kjøre LLM-evalueringer i CI/CD?

Ja. Hvert rammeverk dekket her avslutter med kode ulik null ved en feilet terskel-assertion, som er alt en GitHub Actions-jobb trenger. De praktiske begrensningene er klokketid (dommerkall er nettverkskall, og vår sekvensielle DeepEval-kjøring tok 126.8 sekunder for 10 elementer) og dommer-ikke-determinisme. Arbeidsflytformen og botemidlene finner du i CI-seksjonen over.

Hva er forskjellen mellom DeepEval og Ragas?

Grensesnittform og omfang, ikke kvalitet. DeepEval er pytest-formet og til generell bruk: du skriver testtilfeller og assertes på metrikkterskler, og det dekker applikasjonsoutput av mange slag. Ragas er et RAG-spesifikt bibliotek der evaluate() kjører asynkront over et datasett av spørsmål-, kontekst- og svarrader. DeepEval passer mer naturlig til en CI-sluse; Ragas går dypere på henting.

Hvorfor gir pip install promptfoo meg feil pakke?

Fordi promptfoo er et Node-prosjekt. Det ekte er publisert på npm under MIT og installeres med npm install promptfoo. PyPI-pakken med samme navn er en tredjeparts wrapper, ikke det opprinnelige prosjektet, og å installere den er en vanlig måte å ende opp med å feilsøke en CLI som ikke er den dokumentasjonen beskriver.

Er lm-evaluation-harness et LLM-evalueringsrammeverk?

Det er en modell-evalueringsharness, som er en beslektet men annen jobb. lm-evaluation-harness (installert som pip install lm-eval) benchmarker en modell mot standardiserte offentlige tasker som MMLU. Det forteller deg ikke om hentepipelinen din returnerte riktig passasje, fordi applikasjonen din ikke er et konsept det har. Se seksjonen om rammeverk versus harness over for skillet.

Er disse rammeverkene gratis å bruke?

Lisensmessig, ja. DeepEval, Ragas, Opik, Evidently og Giskard er Apache-2.0; promptfoo, Inspect AI og lm-evaluation-harness er MIT. Begge lisenser tillater kommersiell bruk, endring og videredistribusjon. Arize Phoenix er unntaket: Elastic License 2.0 tillater selv-hosting, men ikke å tilby programvaren til tredjeparter som en administrert tjeneste. Bruk av dommermodell-API faktureres separat av leverandøren din.