Parhaat avoimen lähdekoodin LLM-arviointikehykset vuonna 2026 (yksi ei olekaan avoin lähdekoodi)

Parhaat avoimen lähdekoodin LLM-arviointikehykset vuonna 2026 (yksi ei olekaan avoin lähdekoodi)

Arize Phoenixin repon LICENSE-tiedoston ensimmäinen rivi kertoo: "Elastic License 2.0 (ELv2)". Ei Apache. Ei MIT. Yksi laajalti suositelluista avoimen lähdekoodin LLM-arviointikehyksistä ei ole avointa lähdekoodia OSI:n määritelmän mukaan, ja lähes jokainen tälle haulle sijoittuva sivu toistaa väitteen silti. Niin teki myös meidän oma sivumme, tähän päivään asti. Luimme 2026-08-04 kahdeksan kehyksen lisenssitiedoston ja oletushaaran commit-lokin käsin, plus kolme muuta, joita kärkisivut yhä suosittelevat, ja asensimme sitten kuusi niistä ja ajoimme samat 10 testitapausta kunkin läpi. Emme myy arviointikehystä, joten yksikään alla oleva johtopäätös ei suojele tuotetta.

Keskeiset huomiot

• Arize Phoenix julkaistaan Elastic License 2.0 -lisenssillä, jota OSI ei hyväksy avoimeksi lähdekoodiksi.
• UpTrainin viimeisin commit main-haaraan oli 2024-07-29. Älä aloita sillä uutta projektia.
• pip install promptfoo asentaa kolmannen osapuolen wrapperin. Oikea projekti julkaistaan npm:ssä.
• Ragasilla ei ole ollut committeja 2026-02-24 jälkeen, ja se siirtyi GitHub-organisaatioon vibrantlabsai.

Minkä avoimen lähdekoodin LLM-arviointikehyksen kannattaa asentaa vuonna 2026?

Valitse rajoitteen, ei sijoituksen perusteella. Jos tarvitset pytest-muotoisia väitteitä olemassa olevaan testisarjaan, asenna DeepEval. Jos tarvitset YAML-konfiguraation ja CLI:n, joka sopii mihin tahansa kielipinoon, asenna promptfoo. Jos haluat puhtaimman hyvä-vastaan-huono-erottelun, jonka mittasimme, asenna Opik. Kaikki kolme ovat Apache-2.0- tai MIT-lisensoituja.

Tässä on auditointi. Mukana kahdeksan kehystä, plus kolme muuta, joita tämän haun kärkisivut yhä suosittelevat.

Päivämäärät ovat kunkin projektin oletushaaran viimeisin commit 2026-08-04 tilanteen mukaan. GitHubin repo-sivu näyttää viimeisimmän pushin mihin tahansa haaraan, mikä on myöhäisempi kahdella tässä mainitulla projektilla: UpTrain 2024-08-18 ja Deepchecks 2025-12-28. Kumpaakaan repoa ei ole arkistoitu.

Vaihtokustannus-sarake on se, jonka ihmiset ohittavat ja jota he sitten katuvat. Pisteet ovat vain lukuja, joten siirtyminen DeepEvalin, Ragasin, Opikin ja phoenix-evalsin välillä tarkoittaa lähinnä silmukan uudelleenkirjoittamista. Promptfoosta tai Inspect AI:sta pois siirtyminen tarkoittaa konfiguraatio- tai tehtäväformaatin uudelleenkirjoittamista, jolle ei ole vastinetta muualla, ja Evidentlystä pois siirtyminen tarkoittaa jokaisen kirjoittamasi kynnysarvon auditointia, koska sen asteikko toimii toisin päin. Kaksi kärkisivujen yhä suosittelemaa kehystä ei ole julkaissut versiota vuoden 2024 jälkeen.

Haluatko sen sijaan tasoja, hostattuja alustoja ja suoraviivaisen paremmuusjärjestyksen? Se on eri tehtävä, ja teimme sen jo LLM-arviointityökalujen paremmuusvertailussa, joka kattaa myös maksulliset alustat.

Kahdeksan LLM-arviointikehystä ryhmiteltynä asennustavan mukaan

Asennustapa on se, jonka kanssa joudut elämään, joten se on ryhmittelyperuste.

Python-kirjastot, jotka tuot testeihin

DeepEval (pip install deepeval, Apache-2.0) paketoi LLM-mittarit pytest-muotoisiin väitteisiin: rakenna LLMTestCase, anna se assert_test-funktiolle, ja testi epäonnistuu, kun tulos alittaa kynnysarvon. Parhaimmillaan laatuportin asettamisessa samaan paikkaan, missä tiimi jo ajaa yksikkötestejä. Valitse tämä, jos arviointisi kuuluvat samaan CI-ajoon kaiken muun kanssa.

Yksi läpinäkyvyysmerkintä, kerran mainittuna: DeepEvalin on rakentanut Confident AI, joka on maksettu kumppani kahdessa muussa tämän sivuston artikkelissa, mukaan lukien paremmuusvertailussa, johon tämä sivu linkittää. Se ei saa täällä erikoiskohtelua, ja jokainen DeepEval-linkki tällä sivulla osoittaa GitHub-repoon.

Ragas (pip install ragas, Apache-2.0) on RAG-spesifinen vaihtoehto: evaluate() ottaa vastaan question-, context- ja answer-rivejä ja palauttaa mittarikohtaiset pisteet asynkronisesti. Parhaimmillaan hakulaadun mittaamisessa Python-putkessa. Sen repo siirtyi organisaatiosta explodinggradients organisaatioon vibrantlabsai, viimeisin julkaisu oli v0.4.3 2026-01-13, eikä committeja ole ollut 2026-02-24 jälkeen. Valitse tämä, jos RAG-mittarit ovat koko tehtävä ja hiljainen repo on hyväksyttävä, ja katso laajempi RAG-työkalupino.

Opik (pip install opik, Apache-2.0, Cometilta) julkaisee mittareita, joita voi kutsua itsenäisesti. Aseta OPIK_TRACK_DISABLE=true, niin AnswerRelevance().score() toimii ilman tiliä, ilman paikallista palvelinta ja ilman konfiguraatiotiedostoa – jotain, mitä tuotteen markkinointi ei mainosta. Parhaimmillaan todellisen pisteytyksen saamisessa vähimmällä koodilla. Valitse tämä, jos haluat mittarit nyt ja alustan ehkä myöhemmin.

Evidently (pip install evidently, Apache-2.0) käsittelee arvioinnit deskriptoreina datasetin päällä ja kirjoittaa HTML-raportin sivuvaikutuksena. Parhaimmillaan eräraportoinnissa useiden rivien yli, ei binäärisenä porttina. Sen LLM-pisteet ovat käänteisiä: 1.0 tarkoittaa epäuskollista vastausta. Valitse tämä, jos velkaa jollekulle on jaettava raportti, ei punainen build.

Giskard (pip install giskard, Apache-2.0) skannaa mallin haavoittuvuuksien varalta sen sijaan, että pisteyttäisi itse kirjoittamaasi datasettiä. PyPI-paketti asentaa v2-linjan, ja projektin oman READMEn mukaan v2 "ei ole enää aktiivisesti ylläpidetty". Parhaimmillaan automatisoiduissa red team -tyylisissä skannauksissa. Valitse tämä, jos haluat, että haavoittuvuudet löydetään puolestasi, sen sijaan että määrittelisit itse LLM-tuomari-mittarit.

CLI- ja konfiguraatiotyökalut, joita ajat YAML-tiedostoa vasten

promptfoo (npm install promptfoo, MIT) on CLI, joka lukee YAML-tiedoston: määrittele providerit, testitapaukset ja väitteet, aja npx promptfoo eval, ja saat läpi/ei läpi -tuloksen per tapaus sekä paikallisen tulos-UI:n. Parhaimmillaan prompttien arvioinnissa, kun sovellustasi ei ole kirjoitettu Pythonilla. Valitse tämä, jos laatuporttisi pitäisi olla konfiguraatiotiedosto, jota myös ei-Python-tiimiläinen voi muokata.

Harness-luokka ja alustapaketoidut

Inspect AI (pip install inspect-ai, MIT) tulee UK AI Safety Institutelta ja arvioi malleja Pythonilla määriteltyjä tehtäviä vasten, aidoilla solver- ja scorer-abstraktioilla sekä ajonäkymällä. Parhaimmillaan mallitason benchmarkkauksessa toistettavilla tehtävämäärityksillä. Valitse tämä, jos testattava kohde on malli eikä oma sovelluksesi.

Arize Phoenix (pip install arize-phoenix-evals) tarjoaa valmiita arvioijia, kuten FaithfulnessEvaluator ja CorrectnessEvaluator, jotka palauttavat binäärisen merkinnän ja pisteen. Parhaimmillaan deterministisissä merkinnöissä, joiden varaan voi rakentaa portin ilman kynnysarvon valintaa. Sen lisenssi on syy, miksi tämän artikkelin otsikossa on sulkeissa oleva lisäys, ja se saa oman osionsa seuraavaksi.

Onko Arize Phoenix avointa lähdekoodia?

Ei, ei Open Source Initiativen ylläpitämän määritelmän mukaan. Arize Phoenix julkaistaan Elastic License 2.0 (ELv2) -lisenssillä. Repon LICENSE-tiedoston ensimmäinen rivi kertoo sen, ja PyPI ilmoittaa itsenäisesti license: Elastic-2.0 versiossa v19.15.0. Lähdekoodi on luettavissa, haarautettavissa ja itse hostattavissa. Yksi käyttötapa on rajoitettu.

Rajoitus, jolla on merkitystä: ELv2 kieltää ohjelmiston tarjoamisen kolmansille osapuolille hostattuna tai hallinnoituna palveluna. Lue tämä tarkkaan, koska se sitoo huomattavasti harvempia kuin miltä se kuulostaa. Jos asennat arize-phoenix-evals-paketin pisteyttääksesi omaa sovellustasi, ELv2 ei koske sinua lainkaan. Jos olet konsulttitoimisto tai alustatiimi, joka paketoi Phoenixin ulkoisille asiakkaille myytäväksi arviointipalveluksi, se koskee. Se on koko ero, ja Open Source Definition on se, jonka ELv2 ei täytä, erityisesti käyttötarkoitusta rajoittavien lausekkeiden osalta.

Jokainen tälle haulle nyt sijoittuva sivu luokittelee Phoenixin "avoimeksi lähdekoodiksi", niin teimme mekin. Oma LLM-arviointityökalujen paremmuusvertailumme kuvaa Phoenixin täysin avoimeksi lähdekoodiksi, mikä on väärin, ja se korjataan. Phoenix on lähdekoodiltaan saatavilla (source-available), ei avointa lähdekoodia, ja ero purree vain, jos aiot myydä sitä palveluna. Jos tarvitset oikeasti jäljitystä (tracing) etkä pisteytystä, se kuuluu tekoälyn observointialustoihin, ei tänne.

Mitkä näistä ovat yhä aktiivisesti ylläpidettyjä?

Suurin osa. Kuusi tarkistamastamme yhdestätoista revosta sai commitin main-haaraan 2026-08-03 tai 2026-08-04: DeepEval, promptfoo, Opik, Arize Phoenix, Inspect AI ja Giskard. Kaksi ei ole julkaissut versiota vuoden 2024 jälkeen. Yksi on hiljentynyt vuonna 2026 GitHub-organisaation vaihdon jälkeen.

Kehykset, joilla emme aloittaisi uutta projektia vuonna 2026

UpTrain on kuollut. Sen viimeisin commit main-haaraan tuli 2024-07-29, ja viimeisin julkaisu, v0.7.1, oli 2024-05-14 – kumpikin mittari asettaa sen kaksi vuotta kylmilleen. Repo on yhä olemassa ja yhä Apache-2.0-lisensoitu, joten mikään ei estä sinua, mutta uuden työn aloittaminen hylätyn arviointikirjaston varaan on päätös, jota joudut selittelemään myöhemmin.

Deepchecks ansaitsee tarkan version. Sillä ei ole ollut julkaisua sitten version 0.19.1, 2024-12-15, vaikka repo yhä vastaanottaa committeja, ja viimeisin niistä main-haaraan on päivätty 2025-11-24. Ihmiset työskentelevät sen parissa edelleen; kukaan vain ei ole leikannut versiota yli kahdeksaantoista kuukauteen. Kumpaakaan UpTrainia tai Deepchecksiä ei ole arkistoitu GitHubissa, eikä kumpikaan ole sulkeutunut kontribuutioilta.

Ragas saa vain päivämäärät, ei muuta. Viimeisin julkaisu v0.4.3 2026-01-13, ei committeja 2026-02-24 jälkeen, ja repo siirtyi organisaatiosta explodinggradients organisaatioon vibrantlabsai. Emme löytäneet vahvistettavaa selitystä organisaatiovaihdolle, joten emme keksi sellaista. Hiljainen repo ei ole rikkinäinen: Apache-2.0-koodi, joka laskee uskollisuuspisteen tänään, laskee sen ensi vuonnakin. Riski on korjaamattomat riippuvuudet, mikä puri meitä juuri alla olevassa testissä.

Muut tämän haun ensimmäisen sivun tulokset suosittelevat yhä sekä UpTrainia että Deepchecksiä ilman, että suositukseen on liitetty päivämäärää. Kehys, joka ei ole julkaissut versiota joulukuun 2024 jälkeen, on riippuvuuspäätös, ei ominaisuuspäätös.

Tarvitsetko arviointikehyksen vai arviointiharnessin?

Sovellusarviointikehys pisteyttää sovelluksesi omat tuotokset omaa dataasi vasten. DeepEval, Ragas, promptfoo, Opik, phoenix-evals ja Evidently tekevät kaikki näin. Mallin arviointiharness (engl. harness) sen sijaan benchmarkkaa mallin standardoituja julkisia tehtäviä vasten. lm-evaluation-harness ja Inspect AI tekevät näin. Väärän luokan valinta on tämän sivun kallein virhe.

Virhemuoto on konkreettinen. Joku kytkee lm-evaluation-harnessin testaamaan RAG-chatbottiaan, saa takaisin joukon MMLU-pisteitä eikä opi tarkalleen mitään siitä, palauttaako heidän hakijansa oikeat katkelmat. Pisteet ovat aitoja. Ne mittaavat pohjamallia, josta kukaan ei ollut huolissaan.

Inspect AI:n muoto seuraa sen alkuperästä: se rakennettiin UK AI Safety Institutessa MIT-lisenssillä frontier-mallien arviointiin, joten solverit, scorerit ja tehtävät ovat ensiluokkaisia kansalaisia, eikä sovelluksesi ole käsite, joka sillä on. Se on hyvä syy käyttää sitä siihen, mihin se on tarkoitettu. Jos ongelmasi ovat agentit yksittäisten vuorojen sijaan, agenttien arviointi tuotannossa on jälleen eri osa-alue, ja työkalukutsuja käyttävät palvelimet saavat oman käsittelynsä oppaassamme MCP-palvelinten ja -työkalujen arviointiin.

Mitä tapahtui, kun asensimme kuusi niistä ja ajoimme samat 10 testitapausta

Asensimme 2026-08-04 kuusi näistä tuoreisiin Python 3.11.14 -venveihin (plus npm promptfoolle) ja pisteytimme yhden identtisen 10 kohdan RAG-setin yhdellä tuomarilla, openai/gpt-4o-mini, OpenRouterin kautta lämpötilassa 0. Seitsemän kohtaa oli oikein. Kolme oli rikki kolmella eri tavalla: yksi on ristiriidassa kontekstinsa kanssa, yksi keksii yksityiskohtia, yksi on sujuvaa proosaa, joka ei koskaan vastaa kysymykseen. Jokainen kehys ajettiin kahdesti peräkkäin.

Viisi kuudesta grounding-mittarista löysi kaikki kolme vikaa. Alla olevat kolme havaintoa ovat syy, miksi tämä osio on olemassa.

Relevanssimittarit eivät ole laatumittareita, ja kaksi niistä pisteytti itsevarman valheen korkeammalle kuin oikean vastauksen. Ragasin ResponseRelevancy pisteytti kohteen, jossa väitetään HTTP 404:n olevan 5xx-palvelinvirhe, arvoon 0.777 – korkeammalle kuin kaksi seitsemästä oikeasta vastauksesta – ja kohteen, jossa on keksittyjä rate limit -arvoja, arvoon 0.813, korkeammalle kuin neljä. promptfoon answer-relevance teki saman: 0.800 404-kohteelle, puhdas läpäisy 0.7-kynnysarvoa vasten, samalla kun se hylkäsi oikean q01:n arvolla 0.679. Ei bugi. Itsevarma väärä vastaus vastaa kysymykseen täydellisesti. Mutta jos relevanssi on kojelaudallasi näkyvä luku, sujuva hallusinaatio näyttää parhaalta tuotokseltasi.

Pelkkä uskollisuusportti ohittaa epäolennaisen vastauksen. DeepEval pisteytti kohteen, joka ei koskaan vastaa kysymykseen, arvoon 1.000 uskollisuus, puhtaan läpäisyn, mikä on puolusteltavissa: vastaus, joka ei väitä mitään kontekstista, ei ole ristiriidassa minkään kanssa siinä. Vain relevanssi havaitsi sen, arvolla 0.000. Se on ainoa grounding-mittarin ohitus yllä olevassa taulukossa. Kummallakin mittarilla yksinään on aukko; pari kattaa molemmat.

Binääriset arvioijat pysyivät vakaina lämpötilassa 0. Asteikolliset eivät pysyneet. Phoenix ja DeepEval eivät liikuttaneet yhtään kymmenestä kohteesta kahden identtisen ajon välillä. Opik liikutti neljää, kaikki AnswerRelevance-mittarilla, 0.05-välein; Evidently liikutti myös neljää. Mikään ajautuma ei kääntänyt tulosta tässä, mutta promptfoon oikea q01 päätyi arvoon 0.679 ja sitten 0.642 0.700-kynnysarvoa vasten, mikä on epävakaan CI-portin muoto.

Kaksi pienempää huomiota: kolme kuudesta (DeepEval, Opik, Phoenix) asentui ja ajoi puhtaasti ensimmäisellä kerralla, kun taas Ragas ei importoitunut ennen kuin lukitsimme langchain-community<0.4. Vain promptfoo raportoi tuomarin tokenkäytön: 16 011 väitetokenia ajossa 1 ja 16 010 ajossa 2.

Tämän rajoitteet, suoraan sanottuna. n = 10 on savutesti, ei benchmark: se kertoo ergonomiasta ja sokeista pisteistä, ei mittarin tarkkuudesta. Yksi tuomarimalli pisteytti kaiken, ja isompi tuomari siirtäisi jokaista lukua, todennäköisesti myös niitä kahta väärää positiivista, jotka sekä DeepEval että Ragas tuottivat samasta oikeasta kohteesta. Kaksi ajoa todistaa ajautuman olemassaolon muttei pysty kuvailemaan sitä. Vastaukset olivat valmiiksi kirjoitettuja, joten mikään tässä ei koettele generointia, jäljitystä tai datasetin hallintaa, mikä saa promptfoon 337.9 sekunnin asennuksen näyttämään huonommalta kuin se ansaitsee. "Paras" tarkoittaa aina parasta jonkin rajoitteen kannalta: CI-portti, RAG-mittarit tai UI muuttavat kukin vastausta, kuten myös offline- ja online-arvioinnin välinen jako.

Sama tarkistus kirjoitettuna kolmella tavalla

Nopein tapa valita rajapinnan muoto on lukea sama väite kolmesti. Tässä on grounding-tarkistus yhdelle kohteelle DeepEvalissa, Ragasissa ja promptfoossa, tiivistettynä skripteistä, joita todella ajoimme. Mittarien nimet eroavat; linkitämme oppaaseen miten LLM-tuomari-mittarit oikeasti toimivat sen sijaan, että määrittelisimme ne uudelleen tässä.

# DeepEval 4.1.5: pytest-muotoinen, testi epäonnistuu kynnysarvon alittuessa
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: huomaa import-polku. `from ragas.metrics import Faithfulness`
# nostaa ImportError-virheen tässä versiossa; konkreettinen mittari siirtyi.
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, sitten npx promptfoo eval
providers:
  - id: echo          # pisteytimme valmiiksi kirjoitettuja vastauksia niiden generoinnin sijaan
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."

Asennusrivit sisältävät enemmän ansoja kuin itse koodi, ja jokainen alla oleva kommentti on jotain, mikä vei meiltä aikaa 2026-08-04:

# Oikea promptfoo julkaistaan npm:ssä. Saman niminen PyPI-paketti on
# kolmannen osapuolen wrapperi: https://pypi.org/project/promptfoo/ vs
# https://www.npmjs.com/package/promptfoo
npm install promptfoo

# pip install giskard asentaa v2-linjan, jonka projektin oma README
# merkitsee ei enää aktiivisesti ylläpidetyksi.
pip install giskard

# lm-evaluation-harness asentuu pakettinimellä lm-eval.
pip install lm-eval

# Evidently ei tuo openai-pakettia mukanaan, ja tuomari kaatuu vasta
# kutsuhetkellä, ei import-hetkellä, kun dataset on jo rakennettu.
pip install evidently openai

# Ragas 0.4.3 ei importoidu langchain-community 0.4.x -version kanssa.
pip install ragas "langchain-community<0.4"

Voiko buildin kaataa arviointipisteen perusteella?

Kyllä. Jokainen tässä mainittu kehys palauttaa numeerisen tai binäärisen pisteen, ja kukin poistuu nollasta poikkeavalla koodilla, kun kynnysarvoväite epäonnistuu, ja se on kaikki, mitä GitHub Actions tarvitsee muuttaakseen buildin punaiseksi. Exit-koodin kytkeminen on helppo osuus. Kynnysarvon valitseminen niin, ettei tuomarimalli ylitä sitä vahingossa, on osuus, joka vie viikon.

Tämä on workflow-muoto, jota ajamme, lukittuna 2026-08-04-testimme versioihin:

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:
          # Lukitse tuomari. Malliversion päivitys kesken kvartaalin siirtää jokaista pistettä.
          JUDGE_MODEL: openai/gpt-4o-mini
          # Kynnysarvot elävät yhdessä paikassa, joita mittarikonstruktorit lukevat.
          EVAL_THRESHOLD: "0.7"
          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
        run: deepeval test run tests/evals/

Kaksi sudenkuoppaa puree ennen kynnysarvoa. Ensinnäkin tuomarikutsut ovat verkkokutsuja: 10 kohteen DeepEval-ajomme kesti 126.8 sekuntia, koska .measure() on sekventiaalinen, ja 200 kohteen golden-setti samalla koodipolulla on kahvitauko jokaisella pull requestilla. Jokainen muu testin kehys rinnakkaistaa oletuksena, mikä on suurin yksittäinen vipu CI:n seinäkelloaikaan.

Toiseksi, epävakaus. Lämpötilassa 0 Opik ja Evidently liikuttivat kumpikin neljää kymmenestä kohteesta peräkkäisten ajojen välillä, ja promptfoon oikea vastaus oli 0.679 ja sitten 0.642 0.700-porttia vasten. Lievennykset ovat tylsiä ja ne toimivat: aja kiinteä golden-datasetti, joka muuttuu vain pull requestin mukana, lukitse tuomarimalli, suosi binäärisiä arvioijia silloin, kun merkintä riittää, ja aseta portti deltalle absoluuttisen rajan sijaan. Viimeinen näistä merkitsee eniten monivuoroisessa arvioinnissa, jossa yksi keskustelu tuottaa monta pistettä, joista jokainen voi horjua.

Mittakaavaksi: LangChainin State of Agent Engineering -kyselyssä (1 340 vastausta, kerätty 18. marraskuuta – 2. joulukuuta 2025, julkaistu 12. kesäkuuta 2026) havaittiin, että 89 % organisaatioista on ottanut käyttöön jonkinlaisen observointiratkaisun agenteilleen, kun taas vain 52.4 % ajaa offline-arviointeja testisetteillä. Tarkkailu on yleistä. Portitus ei ole.

Minkä asentaisimme tällä viikolla

Neljä asiaa muistettavaksi. Arize Phoenix on lähdekoodiltaan saatavilla Elastic License 2.0 -lisenssillä eikä ole OSI-hyväksyttyä avointa lähdekoodia, mikä ei muuta mitään useimmille lukijoille ja muuttaa kaiken, jos myyt arviointityökaluja eteenpäin. UpTrain on kuollut, ja päiväämättömät sivut yhä suosittelevat sitä. Myöskään Deepchecks ei ole leikannut julkaisua joulukuun 2024 jälkeen, vaikka sen repo yhä ottaa vastaan committeja. Grounding-mittarilla ja relevanssimittarilla on kummallakin aukko, jonka toinen kattaa, joten porttaa molempien varaan. Ja asteikolliset pisteet ajautuvat lämpötilassa 0, joten lukitse tuomarisi ja anna kynnysarvoille liikkumavaraa.

Jos aloittaisin uuden arviointisarjan tällä viikolla, asentaisin DeepEvalin CI-porttia varten, koska väitteet kuuluvat testien viereen (läpinäkyvyysmerkintä yllä), ja lisäisin Opikin itsenäiset mittarit puhtaimman erottelun vuoksi, jonka mittasimme. Jos pinomme ei olisi Python, promptfoo ilman epäröintiä. Jos haluat mieluummin, että joku muu rakentaa golden-setin ja workflow'n puolestasi, siitä keskustelemme mielellämme.

Usein kysytyt kysymykset

Mikä on paras avoimen lähdekoodin LLM-arviointikehys?

Ei ole yhtä voittajaa, vain paras sopivuus kutakin rajoitetta varten. Läpi/ei läpi -porttiin Python-testisarjan sisällä: DeepEval. Kieliriippumattomaan YAML- ja CLI-asennukseen: promptfoo. RAG-hakumittareihin: Ragas, jos voit hyväksyä revon, jossa ei ole ollut committeja 2026-02-24 jälkeen. Puhtaimpaan hyvien ja huonojen vastausten erotteluun 2026-08-04-testissämme: Opik.

Onko Arize Phoenix avointa lähdekoodia?

Ei Open Source Initiativen määritelmän mukaan. Arize Phoenix julkaistaan Elastic License 2.0 -lisenssillä, jonka PyPI ilmoittaa muodossa license: Elastic-2.0 versiossa v19.15.0 ja jonka repon LICENSE-tiedoston ensimmäinen rivi toteaa suoraan. Se on lähdekoodiltaan saatavilla: voit lukea, haarauttaa, muokata ja itse hostata sitä. Ainoa rajoitus on ohjelmiston tarjoaminen kolmansille osapuolille hostattuna tai hallinnoituna palveluna.

Ylläpidetäänkö Ragasia yhä?

Vahvistettavat faktat, 2026-08-04 tilanteen mukaan: viimeisin julkaisu oli v0.4.3 2026-01-13, committeja ei ole ollut 2026-02-24 jälkeen, ja repo siirtyi organisaatiosta explodinggradients organisaatioon vibrantlabsai. Repoa ei ole arkistoitu. Emme löytäneet luotettavaa julkista selitystä organisaatiovaihdolle emmekä spekuloi sellaisella. Apache-2.0-koodi toimii yhä; riski on korjaamattomat riippuvuudet.

Tarvitsenko arviointikehyksen vai observointialustan?

Molemmat, lopulta, mutta ne vastaavat eri kysymyksiin. Arviointikehys kertoo, teikö muutos tuotoksistasi parempia vai huonompia ennen julkaisua, hallitsemallasi datasetillä. Observointialusta kertoo, mitä tuotannossa oikeasti tapahtui julkaisun jälkeen. Aloita arviointikehyksestä, jos sinulla on CI-putki; katso tekoälyn observointialustat tuotantopuolta varten.

Voinko ajaa LLM-arviointeja CI/CD:ssä?

Kyllä. Jokainen tässä käsitelty kehys poistuu nollasta poikkeavalla koodilla epäonnistuneen kynnysarvoväitteen kohdalla, ja se on kaikki, mitä GitHub Actions -ajo tarvitsee. Käytännön rajoitteet ovat seinäkelloaika (tuomarikutsut ovat verkkokutsuja, ja sekventiaalinen DeepEval-ajomme kesti 126.8 sekuntia 10 kohteelle) ja tuomarin epädeterminismi. Workflow-muoto ja lievennykset löytyvät yllä olevasta CI-osiosta.

Mitä eroa on DeepEvalilla ja Ragasilla?

Rajapinnan muoto ja laajuus, ei laatu. DeepEval on pytest-muotoinen ja yleiskäyttöinen: kirjoitat testitapauksia ja teet väitteitä mittarikynnyksistä, ja se kattaa monenlaisia sovellustuotoksia. Ragas on RAG-spesifinen kirjasto, jonka evaluate() ajaa asynkronisesti question-, context- ja answer-rivien datasetin läpi. DeepEval sopii luonnollisemmin CI-porttiin; Ragas menee syvemmälle hakuun.

Miksi pip install promptfoo antaa väärän paketin?

Koska promptfoo on Node-projekti. Oikea versio julkaistaan npm:ssä MIT-lisenssillä ja asentuu komennolla npm install promptfoo. Saman niminen PyPI-paketti on kolmannen osapuolen wrapperi, ei alkuperäinen projekti, ja sen asentaminen on yleinen tapa päätyä debuggaamaan CLI:tä, joka ei ole se, jota dokumentaatio kuvaa.

Onko lm-evaluation-harness LLM-arviointikehys?

Se on mallin arviointiharness, joka on lähisukuinen mutta eri tehtävä. lm-evaluation-harness (asennetaan pakettina pip install lm-eval) benchmarkkaa mallia standardoituja julkisia tehtäviä, kuten MMLU:ta, vasten. Se ei kerro, palauttiko hakuputkesi oikean katkelman, koska sovelluksesi ei ole käsite, joka sillä on. Katso yllä oleva kehys-versus-harness-osio jaosta.

Ovatko nämä kehykset ilmaisia käyttää?

Lisenssin puolesta kyllä. DeepEval, Ragas, Opik, Evidently ja Giskard ovat Apache-2.0-lisensoituja; promptfoo, Inspect AI ja lm-evaluation-harness ovat MIT-lisensoituja. Molemmat lisenssit sallivat kaupallisen käytön, muokkaamisen ja uudelleenjakelun. Arize Phoenix on poikkeus: Elastic License 2.0 sallii itse hostaamisen, mutta ei ohjelmiston tarjoamista kolmansille osapuolille hallinnoituna palveluna. Tuomarimallin API-käytön laskuttaa erikseen palveluntarjoajasi.