Nejlepší open source frameworky pro evaluaci LLM v roce 2026 (jeden ve skutečnosti není open source)

Nejlepší open source frameworky pro evaluaci LLM v roce 2026 (jeden ve skutečnosti není open source)

První řádek souboru LICENSE v repozitáři Arize Phoenix zní: „Elastic License 2.0 (ELv2)". Ne Apache. Ne MIT. Jeden hojně doporučovaný open source framework pro evaluaci LLM není open source podle definice OSI, a přesto to tvrdí skoro každá stránka, která se na tento dotaz umisťuje na předních místech. Do dneška to tvrdila i jedna z našich. K 2026-08-04 jsme ručně prošli soubor LICENSE a commit log výchozí větve u osmi frameworků, plus dalších tří, které stále doporučují nejlepší stránky, poté jsme šest z nich nainstalovali a spustili na nich stejných 10 případů. Neprodáváme evaluační framework, takže žádný verdikt níže nechrání žádný produkt.

Klíčové poznatky

• Arize Phoenix běží pod licencí Elastic License 2.0, kterou OSI neschvaluje jako open source.
• Poslední commit UpTrain do main byl 2024-07-29. Nezačínejte na něm nový projekt.
• pip install promptfoo vám dá wrapper od třetí strany. Skutečný projekt vychází na npm.
• Ragas nemá žádné commity od 2026-02-24 a přesunul se na GitHubu do organizace vibrantlabsai.

Který open source framework pro evaluaci LLM byste měli v roce 2026 nainstalovat?

Vybírejte podle omezení, ne podle žebříčku. Pro assertions ve stylu pytestu uvnitř existující testovací sady nainstalujte DeepEval. Pro YAML konfiguraci a CLI, které sedne k jakémukoli jazykovému stacku, nainstalujte promptfoo. Pro nejčistší oddělení dobrých a špatných odpovědí, jaké jsme naměřili, nainstalujte Opik. Všechny tři jsou pod licencí Apache-2.0 nebo MIT.

Zde je audit. Osm frameworků v rozsahu, plus další tři, které stále doporučují stránky s nejlepším umístěním pro tento dotaz.

Data jsou poslední commit ve výchozí větvi každého projektu k 2026-08-04. Stránka repozitáře na GitHubu zobrazuje poslední push do jakékoli větve, což je u dvou projektů zde pozdější datum: UpTrain 2024-08-18 a Deepchecks 2025-12-28. Žádný z repozitářů není archivovaný.

Sloupec s náklady na přechod je ten, který lidé přeskočí a pak toho litují. Skóre jsou jen čísla, takže přechod mezi DeepEval, Ragas, Opik a phoenix-evals většinou znamená přepsat smyčku. Přechod z promptfoo nebo Inspect AI znamená přepsat formát konfigurace nebo úlohy, ke kterému jinde neexistuje ekvivalent, a přechod z Evidently znamená projít každý práh, který jste napsali, protože jeho škála běží opačně. Dva z frameworků, které stále doporučují stránky s nejlepším umístěním, nevydaly release od roku 2024.

Chcete místo toho tiery, hostované platformy a přímé pořadí? To je jiná práce a už jsme ji udělali v našem žebříčku nástrojů pro evaluaci LLM včetně placených platforem.

Osm frameworků pro evaluaci LLM podle způsobu instalace

Podoba instalace je to, s čím musíte žít, takže podle toho je uděláno i členění.

Python knihovny, které importujete do testů

DeepEval (pip install deepeval, Apache-2.0) balí LLM metriky do assertions ve stylu pytestu: sestavíte LLMTestCase, předáte ho do assert_test a test selže pod vaším prahem. Nejlepší pro umístění kontroly kvality vedle unit testů, které tým už spouští. Vyberte si to, pokud vaše evaluace patří do stejné CI úlohy jako všechno ostatní.

Jedno zveřejnění, řečeno jednou: DeepEval staví Confident AI, což je placený partner u dvou dalších příspěvků na tomto webu, včetně žebříčku, na který tato stránka odkazuje. Nedostává tu žádné zvláštní zacházení a každý odkaz na DeepEval na této stránce míří na GitHub repozitář.

Ragas (pip install ragas, Apache-2.0) je varianta specializovaná na RAG: evaluate() bere řádky s otázkou, kontextem a odpovědí a asynchronně vrací skóre pro jednotlivé metriky. Nejlepší pro měření kvality retrievalu uvnitř Python pipeline. Jeho repozitář se přesunul z explodinggradients do vibrantlabsai, poslední release byl v0.4.3 dne 2026-01-13 a od 2026-02-24 nejsou žádné commity. Vyberte si to, pokud jsou metriky pro RAG celá práce a tichý repozitář je přijatelný, a podívejte se na širší sadu nástrojů pro RAG.

Opik (pip install opik, Apache-2.0, od Comet) dodává metriky, které lze volat samostatně. Nastavte OPIK_TRACK_DISABLE=true a AnswerRelevance().score() poběží bez účtu, bez lokálního serveru a bez konfiguračního souboru, což se v marketingu produktu příliš nezmiňuje. Nejlepší pro získání reálného skóre v co nejméně řádcích. Vyberte si to, pokud chcete metriky hned a platformu možná později.

Evidently (pip install evidently, Apache-2.0) pojímá evaluace jako deskriptory nad datasetem a jako vedlejší efekt zapisuje HTML report. Nejlepší pro dávkové reportování přes mnoho řádků spíš než binární kontrolu. Jeho LLM skóre jsou obrácená: 1.0 znamená nevěrné (unfaithful). Vyberte si to, pokud to, co někomu dlužíte, je sdílitelný report, ne červený build.

Giskard (pip install giskard, Apache-2.0) skenuje model na zranitelnosti místo toho, aby skóroval dataset, který jste napsali. Balíček na PyPI se rozřeší na řadu v2 a samotné README projektu uvádí, že v2 „už není aktivně udržovaná". Nejlepší pro automatizované skeny ve stylu red-teamu. Vyberte si to, pokud chcete, aby za vás zranitelnosti našel někdo jiný, místo metrik LLM-as-a-judge, které si definujete sami.

Nástroje CLI a konfigurace, které spouštíte proti YAML souboru

promptfoo (npm install promptfoo, MIT) je CLI, které čte YAML soubor: deklarujete providery, testovací případy a assertions, spustíte npx promptfoo eval a dostanete pass/fail pro každý případ plus lokální UI s výsledky. Nejlepší pro evaluaci promptů, když vaše aplikace není napsaná v Pythonu. Vyberte si to, pokud má být vaše kontrola kvality konfigurační soubor, který dokáže upravit i kolega mimo Python.

Třída harness a balíčky svázané s platformou

Inspect AI (pip install inspect-ai, MIT) pochází z britského AI Safety Institute a evaluuje modely proti úlohám, které definujete v Pythonu, se skutečnými abstrakcemi pro solvery a scorery a prohlížečem běhů. Nejlepší pro benchmarking na úrovni modelu s reprodukovatelnými definicemi úloh. Vyberte si to, pokud je testovanou věcí model, ne vaše aplikace.

Arize Phoenix (pip install arize-phoenix-evals) dává k dispozici předpřipravené evaluátory jako FaithfulnessEvaluator a CorrectnessEvaluator, které vracejí binární štítek plus skóre. Nejlepší pro deterministické štítky, na které lze stavět kontrolu bez volby prahu. Jeho licence je důvod, proč má tento článek v titulku závorku, a to má vlastní sekci hned dál.

Je Arize Phoenix open source?

Ne, ne podle definice, kterou udržuje Open Source Initiative. Arize Phoenix běží pod Elastic License 2.0 (ELv2). Říká to první řádek repozitářového souboru LICENSE a nezávisle to deklaruje i PyPI, kde je u v19.15.0 uvedeno license: Elastic-2.0. Zdrojový kód lze číst, forkovat a self-hostovat. Omezené je jedno konkrétní použití.

Omezení, na kterém záleží: ELv2 zakazuje poskytovat software třetím stranám jako hostovanou nebo spravovanou službu. Čtěte to pozorně, protože se to týká mnohem méně lidí, než to zní. Pokud si nainstalujete arize-phoenix-evals, abyste skórovali vlastní aplikaci, ELv2 se vás vůbec netýká. Pokud jste konzultantská firma nebo tým platformy, který balí Phoenix do evaluační služby prodávané externím zákazníkům, týká se vás to. To je celý rozdíl, a přesně v tomto bodě ELv2 neprojde Open Source Definition, konkrétně ustanoveními o omezeních oblasti použití.

Každá stránka, která se aktuálně umisťuje pro tento dotaz, řadí Phoenix pod „open source", a stejně to měli i my. Náš vlastní žebříček nástrojů pro evaluaci LLM popisuje Phoenix jako plně open source, což je chyba, a právě se opravuje. Phoenix je source-available, ne open source, a ten rozdíl začne kousat jen tehdy, pokud ho plánujete prodávat jako službu. Pokud ve skutečnosti potřebujete spíš tracing než skórování, patří to do platforem pro AI observabilitu, ne sem.

Které z nich jsou stále aktivně udržované?

Většina z nich. U šesti z jedenácti repozitářů, které jsme zkontrolovali, přišel commit do main 2026-08-03 nebo 2026-08-04: DeepEval, promptfoo, Opik, Arize Phoenix, Inspect AI a Giskard. Dva nevydaly release od roku 2024. Jeden v roce 2026 utichl po změně GitHub organizace.

Frameworky, na kterých bychom v roce 2026 nezačínali nový projekt

UpTrain je mrtvý. Jeho poslední commit do main přistál 2024-07-29 a poslední release, v0.7.1, byl 2024-05-14, což ho na obou měřítkách dělá dva roky studeným. Repozitář tam pořád je a pořád je pod Apache-2.0, takže nic vám nebrání, ale začínat novou práci na opuštěné evaluační knihovně je rozhodnutí, které budete později muset vysvětlovat.

Deepchecks si zaslouží přesnou verzi. Nemá žádný release od 0.19.1 z 2024-12-15, i když repozitář stále dostává commity, přičemž poslední na main je datovaný 2025-11-24. Lidé na tom stále pracují; verzi ale nikdo nevydal už přes osmnáct měsíců. Ani UpTrain, ani Deepchecks nejsou na GitHubu archivované a ani jeden z nich nemá uzavřené přispívání.

Ragas dostává jen data a nic víc. Poslední release v0.4.3 z 2026-01-13, žádné commity od 2026-02-24 a repozitář se přesunul z explodinggradients do vibrantlabsai. Nenašli jsme ověřitelné vysvětlení, proč se organizace změnila, takže si žádné nevymyslíme. Tichý repozitář není rozbitý repozitář: kód pod Apache-2.0, který dnes spočítá skóre faithfulness, ho spočítá i příští rok. Rizikem jsou nezáplatované závislosti, což je přesně to, co nás bodlo při testování níže.

Jiné stránky na první straně výsledků pro tento dotaz stále doporučují UpTrain i Deepchecks, aniž by k doporučení uváděly nějaké datum. Framework bez release od prosince 2024 je rozhodnutí o závislosti, ne o funkcích.

Potřebujete evaluační framework, nebo evaluační harness?

Aplikační evaluační framework skóruje výstupy vaší vlastní aplikace proti vašim vlastním datům. Dělají to DeepEval, Ragas, promptfoo, Opik, phoenix-evals a Evidently. Evaluační harness modelu naopak benchmarkuje model proti standardizovaným veřejným úlohám. Dělají to lm-evaluation-harness a Inspect AI. Zvolit špatnou třídu je nejdražší chyba na této stránce.

Selhání je konkrétní. Někdo si zapojí lm-evaluation-harness, aby otestoval svého RAG chatbota, dostane sadu skóre MMLU zpátky a nedozví se z toho vůbec nic o tom, jestli jeho retriever vrací správné pasáže. Skóre jsou reálná. Měří základní model, o který se nikdo nebál.

Podoba Inspect AI vychází z jeho původu: vznikl v UK AI Safety Institute pod licencí MIT pro evaluaci frontier modelů, takže solvery, scorery a úlohy jsou prvotřídní součástí a vaše aplikace pro něj není koncept, který zná. To je dobrý důvod používat ho na to, k čemu je určený. Pokud je vaším problémem spíš agenti než jednotlivé tahy, evaluace agentů v produkci je zase jiná disciplína, a servery pro volání nástrojů mají vlastní zpracování v našem průvodci evaluací MCP serverů a nástrojů.

Co se stalo, když jsme šest z nich nainstalovali a spustili stejných 10 případů

K 2026-08-04 jsme šest z nich nainstalovali do čerstvých venvů s Python 3.11.14 (plus npm pro promptfoo) a oskórovali jednu identickou 10položkovou RAG sadu s jedním soudcem, openai/gpt-4o-mini přes OpenRouter při teplotě 0. Sedm položek bylo správně. Tři byly rozbité třemi různými způsoby: jedna si odporuje se svým kontextem, jedna si vymýšlí detaily, jedna je plynulá próza, která nikdy neodpoví na otázku. Každý framework proběhl dvakrát, hned po sobě.

Pět ze šesti metrik groundingu zachytilo všechny tři defekty. Tři zjištění níže jsou důvodem, proč tato sekce existuje.

Metriky relevance nejsou metriky kvality a dvě z nich ohodnotily sebejistou lež výš než správnou odpověď. Ragas ResponseRelevancy oskóroval položku tvrdící, že HTTP 404 je chyba serveru 5xx, na 0.777, výš než dvě ze sedmi správných odpovědí, a položku s vymyšlenými rate limity na 0.813, výš než čtyři. promptfoo answer-relevance udělal totéž: 0.800 pro položku s 404, čisté projití proti prahu 0.7, zatímco správnou q01 nechal propadnout na 0.679. Není to bug. Sebejistá špatná odpověď dokonale odpovídá na otázku. Ale pokud je relevance číslo na vašem dashboardu, plynulá halucinace vypadá jako váš nejlepší výstup.

Kontrola založená jen na faithfulness přehlédne irelevantní odpověď. DeepEval oskóroval položku, která nikdy neodpoví na otázku, na 1.000 faithfulness, čisté projití, což je obhajitelné: odpověď, která o kontextu nic netvrdí, mu v ničem neodporuje. Zachytila to jen relevancy, na 0.000. To je ten jediný chybějící případ groundingu ve výše uvedené tabulce. Každá metrika sama má díru; dohromady pokryjí obě.

Binární evaluátory byly při teplotě 0 stabilní. Odstupňované ne. Phoenix a DeepEval nezměnily napříč dvěma identickými běhy ani jednu z deseti položek. Opik se posunul u čtyř, všechny na AnswerRelevance, na mřížce 0.05; Evidently se posunul také u čtyř. Žádný drift tady nepřeklopil verdikt, ale správná q01 u promptfoo přistála na 0.679 a pak na 0.642 proti prahu 0.700, což je přesně tvar nestabilní CI kontroly.

Dvě menší poznámky: tři ze šesti (DeepEval, Opik, Phoenix) se nainstalovaly a napoprvé čistě proběhly, zatímco Ragas se nedal importovat, dokud jsme nepinnuli langchain-community<0.4. Využití tokenů soudce hlásilo jen promptfoo, 16 011 tokenů assertion v běhu 1 a 16 010 v běhu 2.

Limity tohoto testu, řečeno na rovinu. n = 10 je smoke test, ne benchmark: řekne vám něco o ergonomii a slepých místech, ne o přesnosti metrik. Skóroval jeden soudcovský model, a větší soudce by pohnul s každým číslem, pravděpodobně včetně dvou falešně pozitivních výsledků, které DeepEval i Ragas produkovaly na stejné správné položce. Dva běhy dokazují, že drift existuje, ale neumí ho charakterizovat. Odpovědi byly předepsané předem, takže tady nic netestuje generování, tracing ani správu datasetu, což dělá instalaci promptfoo trvající 337.9 s horší, než si zaslouží. „Nejlepší" vždy znamená nejlepší vzhledem k omezení: CI kontrola, RAG metriky nebo UI každé mění odpověď, stejně jako rozdíl mezi offline a online evaluací.

Stejná kontrola zapsaná třemi způsoby

Nejrychlejší způsob, jak vybrat podobu rozhraní, je přečíst si stejnou assertion třikrát. Tady je kontrola groundingu jedné položky v DeepEval, Ragas a promptfoo, ořezaná ze skriptů, které jsme skutečně spustili. Názvy metrik se liší; místo abychom je tu znovu definovali, odkazujeme na to, jak metriky LLM-as-a-judge skutečně fungují.

# DeepEval 4.1.5: ve stylu pytestu, test selže pod prahem
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: všimněte si cesty importu. `from ragas.metrics import Faithfulness`
# v této verzi vyhodí ImportError; konkrétní metrika se přesunula.
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, poté 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."

Instalační řádky skrývají víc pastí než samotný kód, a každý komentář níže je něco, co nás 2026-08-04 stálo čas:

# Skutečný promptfoo vychází na npm. Balíček na PyPI se stejným jménem je
# wrapper od třetí strany: https://pypi.org/project/promptfoo/ vs
# https://www.npmjs.com/package/promptfoo
npm install promptfoo

# pip install giskard se rozřeší na řadu v2, kterou samotné README projektu
# označuje jako už neaktivně udržovanou.
pip install giskard

# lm-evaluation-harness se instaluje pod názvem balíčku lm-eval.
pip install lm-eval

# Evidently si nestahuje openai a soudce spadne až při volání, ne při
# importu, poté co už máte sestavený dataset.
pip install evidently openai

# Ragas 0.4.3 se neimportuje proti langchain-community 0.4.x.
pip install ragas "langchain-community<0.4"

Můžete kvůli evaluačnímu skóre shodit build?

Ano. Každý framework tady vrací číselné nebo binární skóre a každý skončí s nenulovým kódem, když selže prahová assertion, a to je vše, co GitHub Actions potřebuje, aby udělal build červený. Zapojení exit kódu je snadná část. Zvolit práh, který váš soudcovský model náhodou nepřekročí, je část, která zabere týden.

Toto je podoba workflow, kterou spouštíme, přišpendlená na verze z našeho testu z 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: Ohodnoť zlatou sadu
        env:
          # Přišpendlete soudce. Upgrade modelu uprostřed čtvrtletí pohne s každým skóre.
          JUDGE_MODEL: openai/gpt-4o-mini
          # Prahy žijí na jednom místě, čtou je konstruktory metrik.
          EVAL_THRESHOLD: "0.7"
          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
        run: deepeval test run tests/evals/

Než začne kousat práh, kousnou dřív dva háčky. Za prvé, volání soudce jsou síťová volání: náš běh DeepEval na 10 položkách trval 126.8 s, protože .measure() je sekvenční, a 200položková zlatá sada na této cestě kódu je kávová pauza u každého pull requestu. Každý další framework v testu ve výchozím nastavení paralelizuje, což je jednoznačně největší páka na dobu běhu CI.

Za druhé, nestabilita. Při teplotě 0 se u Opik i Evidently posunuly čtyři z deseti položek mezi běhy hned po sobě, a správná odpověď u promptfoo seděla na 0.679 a pak na 0.642 proti prahu 0.700. Zmírnění jsou nudná a fungují: spouštějte pevný zlatý dataset, který se mění jen podle pull requestu, přišpendlete soudcovský model, preferujte binární evaluátory tam, kde stačí štítek, a kontrolujte podle delty místo absolutního minima. To poslední má největší význam pro evaluaci vícekolových konverzací, kde jedna konverzace produkuje mnoho skóre, z nichž každé může kolísat.

Pro srovnání měřítka: průzkum State of Agent Engineering od LangChain (1 340 odpovědí, sběr od 18. listopadu do 2. prosince 2025, publikováno 12. června 2026) zjistil, že 89 % organizací zavedlo nějakou formu observability pro své agenty, zatímco offline evaluace na testovacích sadách spouští jen 52.4 %. Sledování je běžné. Kontrola (gating) není.

Co bychom nainstalovali tento týden

Čtyři věci k zapamatování. Arize Phoenix je source-available pod Elastic License 2.0 a není open source schválený OSI, což pro většinu čtenářů nic nemění, ale mění úplně vše, pokud evaluační nástroje prodáváte dál. UpTrain je mrtvý a stránky bez uvedeného data ho stále doporučují. Deepchecks také nevydal release od prosince 2024, i když jeho repozitář stále přijímá commity. Metrika groundingu a metrika relevance mají každá díru, kterou pokrývá ta druhá, takže kontrolujte podle obou. A odstupňovaná skóre při teplotě 0 driftují, takže si přišpendlete soudce a dejte prahům rezervu.

Kdybych tento týden začínal novou evaluační sadu, nainstaloval bych DeepEval pro CI kontrolu, protože assertions patří vedle testů (zveřejnění výše), a přidal bych samostatné metriky Opik pro nejčistší oddělení, jaké jsme naměřili. Kdyby náš stack nebyl v Pythonu, bez váhání bych sáhl po promptfoo. A pokud byste raději nechali zlatou sadu a workflow zapojit někoho jiného, rádi si o tom promluvíme.

Často kladené otázky

Jaký je nejlepší open source framework pro evaluaci LLM?

Neexistuje jeden vítěz, jen nejlepší varianta pro dané omezení. Pro pass/fail kontrolu uvnitř Python testovací sady DeepEval. Pro jazykově nezávislé nastavení s YAML a CLI promptfoo. Pro metriky retrievalu u RAG Ragas, pokud dokážete přijmout repozitář bez commitů od 2026-02-24. Pro nejčistší oddělení dobrých a špatných odpovědí v našem testu z 2026-08-04 Opik.

Je Arize Phoenix open source?

Ne podle definice Open Source Initiative. Arize Phoenix běží pod licencí Elastic License 2.0, kterou PyPI deklaruje jako license: Elastic-2.0 u v19.15.0 a kterou přímo uvádí i první řádek repozitářového souboru LICENSE. Je to source-available: můžete ho číst, forkovat, upravovat a self-hostovat. Jediné omezení je nabízet software třetím stranám jako hostovanou nebo spravovanou službu.

Je Ragas stále udržovaný?

Ověřitelná fakta k 2026-08-04: poslední release byl v0.4.3 dne 2026-01-13, od 2026-02-24 nejsou žádné commity a repozitář se přesunul z organizace explodinggradients do vibrantlabsai. Repozitář není archivovaný. Nenašli jsme žádné spolehlivé veřejné vysvětlení změny organizace a nebudeme si žádné vymýšlet. Kód pod Apache-2.0 stále funguje; rizikem jsou nezáplatované závislosti.

Potřebuji evaluační framework, nebo observabilní platformu?

Nakonec obojí, ale odpovídají na jiné otázky. Evaluační framework vám před nasazením řekne, jestli změna udělala vaše výstupy lepšími nebo horšími, na datasetu, který máte pod kontrolou. Observabilní platforma vám řekne, co se v produkci skutečně stalo po nasazení. Pokud máte CI pipeline, začněte evaluačním frameworkem; pro produkční stránku věci se podívejte na platformy pro AI observabilitu.

Můžu spouštět evaluace LLM v CI/CD?

Ano. Každý zde popsaný framework skončí s nenulovým kódem při selhání prahové assertion, a to je vše, co úloha GitHub Actions potřebuje. Praktická omezení jsou reálný čas běhu (volání soudce jsou síťová volání a náš sekvenční běh DeepEval trval 126.8 s pro 10 položek) a nedeterminismus soudce. Podoba workflow a zmírnění jsou v CI sekci výše.

Jaký je rozdíl mezi DeepEval a Ragas?

Podoba rozhraní a rozsah, ne kvalita. DeepEval má podobu pytestu a je univerzální: píšete testovací případy a testujete prahy metrik, a pokrývá výstupy aplikací mnoha druhů. Ragas je knihovna specializovaná na RAG, jejíž evaluate() běží asynchronně nad datasetem řádků s otázkou, kontextem a odpovědí. DeepEval přirozeněji sedí do CI kontroly; Ragas jde hlouběji do retrievalu.

Proč mi pip install promptfoo dá špatný balíček?

Protože promptfoo je Node projekt. Ten skutečný je publikovaný na npm pod licencí MIT a instaluje se pomocí npm install promptfoo. Balíček na PyPI se stejným jménem je wrapper od třetí strany, ne upstream projekt, a jeho instalace je běžný způsob, jak skončit u debugování CLI, které není to, jaké popisuje dokumentace.

Je lm-evaluation-harness framework pro evaluaci LLM?

Je to harness pro evaluaci modelů, což je příbuzná, ale jiná práce. lm-evaluation-harness (instaluje se jako pip install lm-eval) benchmarkuje model proti standardizovaným veřejným úlohám, jako je MMLU. Neřekne vám, jestli vaše retrieval pipeline vrátila správnou pasáž, protože vaše aplikace pro něj není koncept, který zná. Rozdíl mezi frameworkem a harness najdete v sekci výše.

Jsou tyto frameworky zdarma k použití?

Licenčně ano. DeepEval, Ragas, Opik, Evidently a Giskard jsou pod Apache-2.0; promptfoo, Inspect AI a lm-evaluation-harness jsou pod MIT. Obě licence dovolují komerční použití, úpravy i redistribuci. Arize Phoenix je výjimka: Elastic License 2.0 dovoluje self-hosting, ale ne nabízení softwaru třetím stranám jako spravovanou službu. Využití API soudcovského modelu si účtuje samostatně váš poskytovatel.