Najlepsze open source'owe frameworki do ewaluacji LLM w 2026 roku (jeden wcale nie jest open source)

Najlepsze open source'owe frameworki do ewaluacji LLM w 2026 roku (jeden wcale nie jest open source)

Linia 1 pliku LICENSE w repozytorium Arize Phoenix mówi „Elastic License 2.0 (ELv2)". Nie Apache. Nie MIT. Jeden z mocno rekomendowanych open source'owych frameworków do ewaluacji LLM nie jest open source według definicji OSI, a niemal każda strona zajmująca wysokie pozycje dla tego zapytania i tak powtarza to twierdzenie. Podobnie robiła jedna z naszych, aż do dziś. 2026-08-04 ręcznie przeanalizowaliśmy plik licencji i historię commitów na branchu głównym ośmiu frameworków, plus trzech kolejnych, które wciąż polecają strony na szczycie wyników, a potem zainstalowaliśmy sześć z nich i przepuściliśmy przez każdy te same 10 przypadków. Nie sprzedajemy frameworka do ewaluacji, więc żaden werdykt poniżej nie chroni żadnego produktu.

Kluczowe wnioski

• Arize Phoenix działa na licencji Elastic License 2.0, której OSI nie uznaje za open source.
• Ostatni commit UpTrain na main był 2024-07-29. Nie zaczynaj na nim nowego projektu.
• pip install promptfoo instaluje wrapper firmy trzeciej. Prawdziwy projekt jest wydawany na npm.
• Ragas nie miał commitów od 2026-02-24 i przeniósł się do organizacji GitHub vibrantlabsai.

Który open source'owy framework do ewaluacji LLM zainstalować w 2026 roku?

Wybieraj według ograniczeń, nie rankingu. Do asercji w stylu pytest wewnątrz istniejącego zestawu testów zainstaluj DeepEval. Do configu YAML i CLI pasującego do dowolnego stosu językowego zainstaluj promptfoo. Dla najczystszego rozdziału dobrych i złych odpowiedzi, jaki zmierzyliśmy, zainstaluj Opik. Wszystkie trzy są na licencji Apache-2.0 albo MIT.

Oto audyt. Osiem frameworków w zakresie, plus trzy kolejne, które wciąż polecają strony na szczycie wyników dla tego zapytania.

Daty to ostatni commit na branchu domyślnym każdego projektu, stan na 2026-08-04. Strona repozytorium GitHub pokazuje ostatni push do dowolnego brancha, co dla dwóch projektów tutaj jest późniejsze: UpTrain 2024-08-18 i Deepchecks 2025-12-28. Żadne z repozytoriów nie jest zarchiwizowane.

Kolumna kosztu zmiany to ta, którą ludzie pomijają, a potem żałują. Wyniki to po prostu liczby, więc przejście między DeepEval, Ragas, Opik i phoenix-evals sprowadza się głównie do przepisania pętli. Rezygnacja z promptfoo albo Inspect AI oznacza przepisanie formatu configu albo taska bez odpowiednika gdzie indziej, a rezygnacja z Evidently oznacza przegląd każdego napisanego progu, bo jego skala działa w drugą stronę. Dwa z frameworków wciąż polecanych przez strony na szczycie wyników nie miały wydania od 2024 roku.

Szukasz raczej tierów, hostowanych platform i prostego rankingu? To inne zadanie i już je wykonaliśmy w naszym rankingu narzędzi do ewaluacji LLM, w tym płatnych platform.

Osiem frameworków do ewaluacji LLM pogrupowanych według sposobu instalacji

Kształt instalacji to coś, z czym trzeba żyć na co dzień, więc to on jest kryterium podziału.

Biblioteki Pythona importowane do testów

DeepEval (pip install deepeval, Apache-2.0) opakowuje metryki LLM w asercje w stylu pytest: budujesz LLMTestCase, przekazujesz go do assert_test, a test kończy się niepowodzeniem poniżej ustawionego progu. Najlepszy do wstawienia bramki jakości obok testów jednostkowych, które zespół już uruchamia. Wybierz to, jeśli twoje evale mają siedzieć w tym samym zadaniu CI co reszta.

Jedno zastrzeżenie, wypowiedziane raz: DeepEval jest tworzony przez Confident AI, płatnego partnera na dwóch innych wpisach na tej stronie, w tym na rankingu, do którego linkuje ta strona. Nie otrzymuje tu żadnego specjalnego traktowania, a każdy link do DeepEval na tej stronie prowadzi do repozytorium na GitHubie.

Ragas (pip install ragas, Apache-2.0) to opcja specyficzna dla RAG: evaluate() przyjmuje wiersze z pytaniem, kontekstem i odpowiedzią i zwraca wyniki per metryka asynchronicznie. Najlepszy do mierzenia jakości retrievalu wewnątrz pipeline'u w Pythonie. Jego repozytorium przeniosło się z explodinggradients do vibrantlabsai, ostatnie wydanie to v0.4.3 z 2026-01-13, a commitów nie było od 2026-02-24. Wybierz to, jeśli metryki RAG to cała robota, a ciche repozytorium jest akceptowalne, i zobacz szerszy stos narzędzi RAG.

Opik (pip install opik, Apache-2.0, od Comet) dostarcza metryki, które można wywoływać samodzielnie. Ustaw OPIK_TRACK_DISABLE=true, a AnswerRelevance().score() zadziała bez konta, bez lokalnego serwera i bez pliku konfiguracyjnego, czego framing produktu nie reklamuje. Najlepszy do uzyskania prawdziwego wyniku w jak najmniejszej liczbie linii. Wybierz to, jeśli chcesz metryki już teraz, a platformę może później.

Evidently (pip install evidently, Apache-2.0) traktuje evale jako deskryptory nad datasetem i jako efekt uboczny zapisuje raport HTML. Najlepszy do raportowania wsadowego po wielu wierszach, a nie do binarnej bramki. Jego wyniki LLM są odwrócone: 1.0 oznacza brak wierności. Wybierz to, jeśli to, co komuś jesteś winien, to raport do udostępnienia, a nie czerwony build.

Giskard (pip install giskard, Apache-2.0) skanuje model pod kątem podatności zamiast oceniać napisany przez ciebie dataset. Pakiet PyPI rozwiązuje się do linii v2, a własny README projektu stwierdza, że v2 „nie jest już aktywnie utrzymywana". Najlepszy do automatycznych skanów w stylu red-team. Wybierz to, jeśli chcesz, żeby podatności zostały znalezione za ciebie, a nie metryki LLM-as-a-judge, które definiujesz sam.

Narzędzia CLI i config uruchamiane na pliku YAML

promptfoo (npm install promptfoo, MIT) to CLI, które czyta plik YAML: deklarujesz providerów, przypadki testowe i asercje, uruchamiasz npx promptfoo eval i dostajesz wynik pass/fail per przypadek plus lokalny interfejs wyników. Najlepszy do oceny promptów, gdy twoja aplikacja nie jest napisana w Pythonie. Wybierz to, jeśli bramka jakości ma być plikiem konfiguracyjnym, który edytuje kolega niepracujący w Pythonie.

Klasa harnessów i narzędzia dołączone do platform

Inspect AI (pip install inspect-ai, MIT) pochodzi z brytyjskiego UK AI Safety Institute i ocenia modele względem tasków definiowanych w Pythonie, z pełnoprawnymi abstrakcjami solvera i scorera oraz podglądem uruchomień. Najlepszy do benchmarkingu na poziomie modelu z odtwarzalnymi definicjami tasków. Wybierz to, jeśli tym, co testujesz, jest model, a nie twoja aplikacja.

Arize Phoenix (pip install arize-phoenix-evals) daje gotowe evaluatory, takie jak FaithfulnessEvaluator i CorrectnessEvaluator, które zwracają binarną etykietę plus wynik. Najlepszy do deterministycznych etykiet, na których można bramkować bez wybierania progu. Jego licencja jest powodem, dla którego ten artykuł ma dopisek w tytule, i to dostaje własną sekcję zaraz dalej.

Czy Arize Phoenix jest open source?

Nie, nie według definicji, którą utrzymuje Open Source Initiative. Arize Phoenix działa na licencji Elastic License 2.0 (ELv2). Mówi o tym linia 1 pliku LICENSE repozytorium, a PyPI niezależnie deklaruje license: Elastic-2.0 na v19.15.0. Kod źródłowy jest czytelny, można go forkować i samodzielnie hostować. Ograniczone jest jedno zastosowanie.

Ograniczenie, które ma znaczenie: ELv2 zabrania udostępniania oprogramowania stronom trzecim jako usługi hostowanej lub zarządzanej. Przeczytaj to uważnie, bo dotyczy znacznie mniej osób, niż mogłoby się wydawać. Jeśli instalujesz arize-phoenix-evals, żeby oceniać własną aplikację, ELv2 w ogóle cię nie dotyczy. Jeśli jesteś firmą konsultingową albo zespołem platformowym pakującym Phoenix w usługę ewaluacji sprzedawaną klientom zewnętrznym, dotyczy. To cała różnica, a Open Source Definition to właśnie to, czego ELv2 nie spełnia, konkretnie klauzul dotyczących ograniczeń pola zastosowania.

Każda strona obecnie zajmująca wysokie pozycje dla tego zapytania klasyfikuje Phoenix jako „open source", my też tak robiliśmy. Nasz własny ranking narzędzi do ewaluacji LLM opisuje Phoenix jako w pełni open source, co jest błędne, i jest właśnie poprawiane. Phoenix jest source-available, nie open source, a ta różnica ma znaczenie tylko wtedy, gdy planujesz sprzedawać go jako usługę. Jeśli tym, czego naprawdę potrzebujesz, jest tracing, a nie ocenianie, to temat dla platform obserwowalności AI, nie ten artykuł.

Które z nich są wciąż aktywnie utrzymywane?

Większość. Sześć z jedenastu sprawdzonych przez nas repozytoriów dostało commit na main 2026-08-03 albo 2026-08-04: DeepEval, promptfoo, Opik, Arize Phoenix, Inspect AI i Giskard. Dwa nie miały wydania od 2024 roku. Jedno ucichło w 2026 roku po zmianie organizacji na GitHubie.

Frameworki, na których nie zaczęlibyśmy nowego projektu w 2026 roku

UpTrain jest martwy. Jego ostatni commit na main wylądował 2024-07-29, a ostatnie wydanie, v0.7.1, miało miejsce 2024-05-14, co daje dwa lata zastoju według obu miar. Repozytorium wciąż tam jest i wciąż jest na Apache-2.0, więc nic ci nie przeszkodzi, ale zaczynanie nowej pracy na porzuconej bibliotece ewaluacyjnej to decyzja, którą będziesz musiał później tłumaczyć.

Deepchecks zasługuje na precyzyjną wersję. Nie miał wydania od 0.19.1 na 2024-12-15, choć repozytorium wciąż dostaje commity, a ostatni na main ma datę 2025-11-24. Ludzie wciąż nad nim pracują; nikt nie wypuścił wersji od ponad osiemnastu miesięcy. Ani UpTrain, ani Deepchecks nie są zarchiwizowane na GitHubie, i żadne z nich nie zamknęło się na kontrybucje.

Ragas dostaje daty i nic więcej. Ostatnie wydanie v0.4.3 z 2026-01-13, brak commitów od 2026-02-24, a repozytorium przeniosło się z explodinggradients do vibrantlabsai. Nie znaleźliśmy wiarygodnego wyjaśnienia zmiany organizacji, więc go nie wymyślimy. Ciche repozytorium to nie to samo co zepsute: kod na Apache-2.0, który dziś liczy wynik wierności, będzie go liczył tak samo za rok. Ekspozycją są niezałatane zależności, co dokładnie ugryzło nas podczas testów poniżej.

Inne strony na pierwszej stronie wyników dla tego zapytania wciąż polecają zarówno UpTrain, jak i Deepchecks, bez podanej daty przy rekomendacji. Framework bez wydania od grudnia 2024 to decyzja o zależności, nie o funkcjonalności.

Potrzebujesz frameworka do ewaluacji czy harnessa ewaluacyjnego (eval harness)?

Framework do ewaluacji aplikacji ocenia wyniki twojej własnej aplikacji na twoich własnych danych. Robią to DeepEval, Ragas, promptfoo, Opik, phoenix-evals i Evidently. Harness ewaluacyjny modelu benchmarkuje model względem standardowych, publicznych tasków. Robią to lm-evaluation-harness i Inspect AI. Wybranie złej klasy to najkosztowniejszy błąd na tej stronie.

Tryb awarii jest konkretny. Ktoś podłącza lm-evaluation-harness do testowania swojego chatbota RAG, dostaje zestaw wyników MMLU i nie dowiaduje się dokładnie niczego o tym, czy jego retriever zwraca właściwe fragmenty. Wyniki są prawdziwe. Mierzą model bazowy, o który nikt się nie martwił.

Kształt Inspect AI wynika z jego pochodzenia: powstał w UK AI Safety Institute na licencji MIT do ewaluacji modeli frontier, więc solvery, scorery i taski są pierwszoklasowymi obywatelami, a twoja aplikacja to pojęcie, którego on nie ma. To dobry powód, żeby używać go do tego, do czego jest. Jeśli twoim problemem są agenci, a nie pojedyncze tury, ewaluacja agentów w produkcji to zupełnie inna dyscyplina, a serwery narzędziowe dostają własne omówienie w naszym przewodniku po ewaluacji serwerów i narzędzi MCP.

Co się stało, gdy zainstalowaliśmy sześć z nich i przepuściliśmy przez nie te same 10 przypadków

2026-08-04 zainstalowaliśmy sześć z nich w świeżych środowiskach venv na Python 3.11.14 (plus npm dla promptfoo) i oceniliśmy jeden identyczny zestaw 10 przypadków RAG jednym sędzią, openai/gpt-4o-mini przez OpenRouter przy temperature 0. Siedem pozycji było poprawnych. Trzy były zepsute na trzy różne sposoby: jedna zaprzecza własnemu kontekstowi, jedna wymyśla szczegóły, jedna to płynna proza, która nigdy nie odpowiada na pytanie. Każdy framework uruchomiliśmy dwukrotnie, jeden przebieg za drugim.

Pięć z sześciu metryk ugruntowania wykryło wszystkie trzy defekty. Trzy poniższe ustalenia to powód istnienia tej sekcji.

Metryki trafności to nie metryki jakości, a dwie z nich oceniły pewną siebie nieprawdę wyżej niż poprawną odpowiedź. Ragas ResponseRelevancy ocenił pozycję twierdzącą, że HTTP 404 to błąd serwera 5xx, na 0.777, wyżej niż dwie z siedmiu poprawnych odpowiedzi, a pozycję z wymyślonymi limitami zapytań na 0.813, wyżej niż cztery. promptfoo answer-relevance zrobił to samo: 0.800 dla pozycji z 404, czysty przechodzący wynik przy progu 0.7, podczas gdy poprawne q01 oblało z wynikiem 0.679. To nie błąd. Pewna siebie zła odpowiedź doskonale adresuje pytanie. Ale jeśli trafność to liczba na twoim dashboardzie, płynna halucynacja wygląda jak twój najlepszy wynik.

Bramka oparta wyłącznie na wierności przeocza nietrafną odpowiedź. DeepEval ocenił pozycję, która nigdy nie odpowiada na pytanie, na 1.000 wierności, czysty przechodzący wynik, co jest obronne: odpowiedź, która niczego nie twierdzi o kontekście, niczemu w nim nie zaprzecza. Wykryła to tylko trafność, na poziomie 0.000. To jedyne przeoczenie ugruntowania w powyższej tabeli. Każda metryka z osobna ma lukę; para pokrywa obie.

Evaluatory binarne były stabilne przy temperature 0. Te z gradacją, nie. Phoenix i DeepEval nie przesunęły ani jednej z dziesięciu pozycji między dwoma identycznymi przebiegami. Opik przesunął cztery, wszystkie na AnswerRelevance, na siatce 0.05; Evidently też przesunął cztery. Żaden dryf nie odwrócił tu werdyktu, ale poprawne q01 w promptfoo wylądowało na 0.679, a potem 0.642, przy progu 0.700, co jest kształtem niestabilnej bramki CI.

Dwie mniejsze uwagi: trzy z sześciu (DeepEval, Opik, Phoenix) zainstalowały się i zadziałały czysto za pierwszym razem, podczas gdy Ragas nie chciał się zaimportować, dopóki nie przypięliśmy langchain-community<0.4. Tylko promptfoo raportował zużycie tokenów sędziego: 16 011 tokenów asercji w run 1 i 16 010 w run 2.

Ograniczenia tego testu, powiedziane wprost. n = 10 to test dymny, nie benchmark: mówi o ergonomii i martwych punktach, nie o dokładności metryk. Jeden model sędziowski ocenił wszystko, a większy sędzia przesunąłby każdą liczbę, prawdopodobnie łącznie z dwoma fałszywymi pozytywami, które DeepEval i Ragas dały na tej samej poprawnej pozycji. Dwa przebiegi dowodzą, że dryf istnieje, ale nie potrafią go scharakteryzować. Odpowiedzi były napisane wcześniej, więc nic tutaj nie testuje generowania, tracingu ani zarządzania datasetem, co sprawia, że instalacja promptfoo trwająca 337.9 s wygląda gorzej, niż na to zasługuje. „Najlepszy" zawsze znaczy najlepszy dla danego ograniczenia: bramka CI, metryki RAG albo interfejs UI, każde zmienia odpowiedź, podobnie jak podział na ewaluację offline i online.

To samo sprawdzenie, zapisane na trzy sposoby

Najszybszym sposobem wyboru kształtu interfejsu jest przeczytanie tej samej asercji trzy razy. Oto sprawdzenie ugruntowania na jednej pozycji w DeepEval, Ragas i promptfoo, przycięte ze skryptów, które faktycznie uruchomiliśmy. Nazwy metryk się różnią; linkujemy do tego, jak faktycznie działają metryki LLM-as-a-judge, zamiast definiować je ponownie tutaj.

# DeepEval 4.1.5: w stylu pytest, test kończy się niepowodzeniem poniżej progu
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: zwróć uwagę na ścieżkę importu. `from ragas.metrics import Faithfulness`
# rzuca ImportError w tej wersji; konkretna metryka się przeniosła.
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, potem npx promptfoo eval
providers:
  - id: echo          # oceniliśmy wcześniej napisane odpowiedzi zamiast je generować
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."

Linie instalacji kryją więcej pułapek niż sam kod, a każdy komentarz poniżej to coś, co kosztowało nas czas 2026-08-04:

# Prawdziwy promptfoo jest wydawany na npm. Pakiet PyPI o tej samej nazwie to
# wrapper firmy trzeciej: https://pypi.org/project/promptfoo/ vs
# https://www.npmjs.com/package/promptfoo
npm install promptfoo

# pip install giskard rozwiązuje się do linii v2, którą własny README projektu
# oznacza jako już nieaktywnie utrzymywaną.
pip install giskard

# lm-evaluation-harness instaluje się pod nazwą pakietu lm-eval.
pip install lm-eval

# Evidently nie ściąga openai, a sędzia crashuje w momencie wywołania, nie
# importu, już po zbudowaniu datasetu.
pip install evidently openai

# Ragas 0.4.3 nie zaimportuje się przy langchain-community w wersji 0.4.x.
pip install ragas "langchain-community<0.4"

Czy można wysypać build na podstawie wyniku ewaluacji?

Tak. Każdy framework tutaj zwraca wynik liczbowy albo binarny i każdy zakończy się kodem różnym od zera, gdy asercja progu zawiedzie, a to wszystko, czego GitHub Actions potrzebuje, żeby zaczerwienić build. Podłączenie kodu wyjścia to łatwa część. Wybranie progu, którego twój model sędziowski nie przekroczy przypadkiem, to część zajmująca tydzień.

Oto kształt workflow, który uruchamiamy, przypięty do wersji z naszego 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: Score the golden set
        env:
          # Przypnij sędziego. Zmiana modelu w środku kwartału przesuwa każdy wynik.
          JUDGE_MODEL: openai/gpt-4o-mini
          # Progi żyją w jednym miejscu, czytane przez konstruktory metryk.
          EVAL_THRESHOLD: "0.7"
          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
        run: deepeval test run tests/evals/

Dwa haczyki gryzą, zanim zrobi to próg. Po pierwsze, wywołania sędziego to wywołania sieciowe: nasz 10-pozycyjny przebieg DeepEval zajął 126.8 s, bo .measure() działa sekwencyjnie, a złoty zestaw na 200 pozycji na tej samej ścieżce kodu to przerwa na kawę przy każdym pull requeście. Każdy inny framework w teście domyślnie zrównolegla, co jest największą pojedynczą dźwignią czasu ściany zegarowej w CI.

Po drugie, niestabilność. Przy temperature 0 Opik i Evidently przesunęły po cztery z dziesięciu pozycji między kolejnymi przebiegami, a poprawna odpowiedź w promptfoo wylądowała na 0.679, a potem 0.642, przy bramce 0.700. Środki zaradcze są nudne i działają: uruchamiaj stały złoty zestaw danych, który zmienia się tylko wraz z pull requestem, przypnij model sędziowski, preferuj evaluatory binarne tam, gdzie wystarczy etykieta, i bramkuj na delcie, a nie na progu bezwzględnym. Ten ostatni punkt ma największe znaczenie dla ewaluacji wieloturowej, gdzie jedna rozmowa produkuje wiele wyników, z których każdy może się wahać.

Dla skali: ankieta State of Agent Engineering firmy LangChain (1 340 odpowiedzi, zebranych między 18 listopada a 2 grudnia 2025, opublikowana 12 czerwca 2026) wykazała, że 89% organizacji wdrożyło jakąś formę obserwowalności dla swoich agentów, podczas gdy tylko 52.4% uruchamia ewaluacje offline na zestawach testowych. Obserwowanie jest powszechne. Bramkowanie nie.

Co zainstalowalibyśmy w tym tygodniu

Cztery rzeczy do zapamiętania. Arize Phoenix jest source-available na licencji Elastic License 2.0 i nie jest zatwierdzonym przez OSI open source, co dla większości czytelników nie zmienia niczego, a dla tych odsprzedających narzędzia ewaluacyjne zmienia wszystko. UpTrain jest martwy, a strony bez podanej daty wciąż go polecają. Deepchecks też nie wydał niczego od grudnia 2024 roku, choć jego repozytorium wciąż przyjmuje commity. Metryka ugruntowania i metryka trafności mają każda lukę, którą pokrywa ta druga, więc bramkuj na obu. A wyniki z gradacją dryfują przy temperature 0, więc przypnij swojego sędziego i daj progom trochę luzu.

Gdybym zaczynał w tym tygodniu nowy zestaw ewaluacyjny, zainstalowałbym DeepEval do bramki CI, bo asercje należą obok testów (zastrzeżenie powyżej), i dodałbym samodzielne metryki Opik dla najczystszego rozdziału, jaki zmierzyliśmy. Gdyby nasz stos nie był Pythonowy, promptfoo bez wahania. Jeśli wolisz, żeby ktoś inny okablował złoty zestaw i workflow, chętnie o tym porozmawiamy.

Najczęściej zadawane pytania

Jaki jest najlepszy open source'owy framework do ewaluacji LLM?

Nie ma jednego zwycięzcy, tylko najlepsze dopasowanie do ograniczenia. Do bramki pass/fail wewnątrz zestawu testów Python: DeepEval. Do niezależnego od języka configu YAML i CLI: promptfoo. Do metryk retrievalu RAG: Ragas, jeśli akceptujesz repozytorium bez commitów od 2026-02-24. Dla najczystszego rozdziału dobrych i złych odpowiedzi w naszym teście z 2026-08-04: Opik.

Czy Arize Phoenix jest open source?

Nie według definicji Open Source Initiative. Arize Phoenix działa na licencji Elastic License 2.0, którą PyPI deklaruje jako license: Elastic-2.0 na v19.15.0 i którą wprost stwierdza linia 1 pliku LICENSE repozytorium. Jest source-available: możesz go czytać, forkować, modyfikować i samodzielnie hostować. Jedynym ograniczeniem jest oferowanie oprogramowania stronom trzecim jako usługi hostowanej lub zarządzanej.

Czy Ragas jest wciąż utrzymywany?

Zweryfikowane fakty, stan na 2026-08-04: ostatnie wydanie to v0.4.3 z 2026-01-13, nie było commitów od 2026-02-24, a repozytorium przeniosło się z organizacji explodinggradients do vibrantlabsai. Repozytorium nie jest zarchiwizowane. Nie znaleźliśmy wiarygodnego publicznego wyjaśnienia zmiany organizacji i nie będziemy spekulować. Kod na Apache-2.0 wciąż działa; ekspozycją są niezałatane zależności.

Potrzebuję frameworka do ewaluacji czy platformy obserwowalności?

Obu, w końcu, ale odpowiadają na różne pytania. Framework do ewaluacji mówi, czy zmiana poprawiła czy pogorszyła twoje wyniki, zanim je wypuścisz, na kontrolowanym przez ciebie zestawie danych. Platforma obserwowalności mówi, co faktycznie wydarzyło się w produkcji po wypuszczeniu. Zacznij od frameworka do ewaluacji, jeśli masz pipeline CI; zobacz platformy obserwowalności AI dla strony produkcyjnej.

Czy mogę uruchamiać ewaluacje LLM w CI/CD?

Tak. Każdy omówiony tu framework kończy się kodem różnym od zera przy nieudanej asercji progu, a to wszystko, czego potrzebuje zadanie GitHub Actions. Praktyczne ograniczenia to czas ściany zegarowej (wywołania sędziego to wywołania sieciowe, a nasz sekwencyjny przebieg DeepEval zajął 126.8 s dla 10 pozycji) i niedeterminizm sędziego. Kształt workflow i środki zaradcze są w sekcji CI powyżej.

Jaka jest różnica między DeepEval a Ragas?

Kształt interfejsu i zakres, nie jakość. DeepEval jest w stylu pytest i ma ogólne zastosowanie: piszesz przypadki testowe i asercje na progach metryk, a obejmuje wyniki aplikacji wielu rodzajów. Ragas to biblioteka specyficzna dla RAG, której evaluate() działa asynchronicznie nad datasetem wierszy pytanie-kontekst-odpowiedź. DeepEval lepiej pasuje do bramki CI; Ragas idzie głębiej w retrieval.

Dlaczego pip install promptfoo instaluje zły pakiet?

Bo promptfoo to projekt Node. Prawdziwy jest publikowany na npm na licencji MIT i instaluje się przez npm install promptfoo. Pakiet PyPI o tej samej nazwie to wrapper firmy trzeciej, nie projekt macierzysty, a jego instalacja to częsty sposób na debugowanie CLI, które nie jest tym opisanym w dokumentacji.

Czy lm-evaluation-harness to framework do ewaluacji LLM?

To harness ewaluacyjny modelu, czyli powiązane, ale inne zadanie. lm-evaluation-harness (instalowany jako pip install lm-eval) benchmarkuje model względem standardowych, publicznych tasków, takich jak MMLU. Nie powie ci, czy twój pipeline retrievalu zwrócił właściwy fragment, bo twoja aplikacja to pojęcie, którego on nie ma. Zobacz sekcję framework kontra harness powyżej.

Czy te frameworki są darmowe w użyciu?

Pod względem licencji tak. DeepEval, Ragas, Opik, Evidently i Giskard są na Apache-2.0; promptfoo, Inspect AI i lm-evaluation-harness są na MIT. Obie licencje pozwalają na użycie komercyjne, modyfikację i redystrybucję. Arize Phoenix jest wyjątkiem: Elastic License 2.0 pozwala na samodzielny hosting, ale nie na oferowanie oprogramowania stronom trzecim jako usługi zarządzanej. Zużycie API modelu sędziowskiego jest rozliczane osobno przez twojego dostawcę.