Найкращі фреймворки з відкритим кодом для оцінювання LLM у 2026 (один насправді не open source)

Рядок 1 файлу LICENSE у репозиторії Arize Phoenix свідчить: "Elastic License 2.0 (ELv2)". Не Apache. Не MIT. Один із найбільш рекомендованих open-source фреймворків оцінювання LLM не є open source за визначенням OSI, і майже кожна сторінка, що ранжується за цим запитом, все одно повторює це твердження. Так само робили і ми — до сьогодні. 4 серпня 2026 року ми вручну прочитали файл ліцензії та лог комітів у гілці за замовчуванням восьми фреймворків, плюс ще три, які досі рекомендують топові сторінки, а потім встановили шість і прогнали через кожен ті самі 10 кейсів. Ми не продаємо eval-фреймворк, тож жоден вердикт нижче не захищає якийсь продукт.

Головні висновки

• Arize Phoenix поширюється за ліцензією Elastic License 2.0, яку OSI не визнає open source.
• Останній коміт UpTrain у main датований 2024-07-29. Не варто починати новий проєкт на ньому.
• pip install promptfoo встановлює сторонню обгортку. Справжній проєкт публікується на npm.
• У Ragas немає комітів з 2026-02-24, і проєкт переїхав в іншу організацію на GitHub — vibrantlabsai.

Який open-source фреймворк оцінювання LLM встановити у 2026 році?

Обирайте за обмеженнями, а не за місцем у рейтингу. Для тверджень у стилі pytest всередині наявного тестового набору — ставте DeepEval. Для YAML-конфігу та CLI, що підходить під будь-який мовний стек, — ставте promptfoo. Для найчистішого розділення хороших і поганих відповідей, яке ми виміряли, — ставте Opik. Усі три поширюються за ліцензіями Apache-2.0 або MIT.

Ось сам аудит. Вісім фреймворків у фокусі, плюс ще три, які досі рекомендують топові сторінки за цим запитом.

Дати — це останній коміт у гілці за замовчуванням кожного проєкту станом на 2026-08-04. Сторінка репозиторію GitHub показує останній пуш у будь-яку гілку, який пізніший для двох проєктів тут: UpTrain 2024-08-18 і Deepchecks 2025-12-28. Жоден з репозиторіїв не заархівовано.

Стовпець вартості переходу — саме той, який усі пропускають, а потім шкодують. Скори — це просто числа, тож перехід між DeepEval, Ragas, Opik і phoenix-evals здебільшого зводиться до переписування циклу. Перехід з promptfoo або Inspect AI означає переписування конфігу чи формату завдань без прямого аналога деінде, а перехід з Evidently означає перегляд кожного порогу, який ви написали, бо шкала там йде в інший бік. Два з фреймворків, які досі рекомендують топові сторінки, не випускали релізів з 2024 року.

Хочете рівні, хостингові платформи та пряме ранжування замість цього? Це вже інше завдання, і ми його вже виконали в нашому ранжованому порівнянні інструментів оцінювання LLM, включно з платними платформами.

Вісім фреймворків оцінювання LLM, згруповані за способом встановлення

Форма встановлення — те, з чим доведеться жити, тож саме за цим і групуємо.

Python-бібліотеки, які імпортуються в тести

DeepEval (pip install deepeval, Apache-2.0) обгортає метрики LLM у твердження у стилі pytest: створюєте LLMTestCase, передаєте в assert_test, і тест провалюється, якщо результат нижчий за поріг. Найкраще підходить для того, щоб поставити ворота якості поруч з юніт-тестами, які команда вже запускає. Обирайте це, якщо ваші евали мають жити в тому самому CI-джобі, що й усе інше.

Одне розкриття, сказане один раз: DeepEval розробляє Confident AI, платний партнер двох інших постів на цьому сайті, включно з ранжованим порівнянням, на яке посилається ця сторінка. Особливого ставлення тут немає, і кожне посилання на DeepEval на цій сторінці веде на репозиторій GitHub.

Ragas (pip install ragas, Apache-2.0) — варіант, спеціалізований на RAG: evaluate() бере рядки з питанням, контекстом і відповіддю та повертає скори по метриках асинхронно. Найкраще підходить для вимірювання якості пошуку всередині Python-пайплайну. Його репозиторій переїхав з explodinggradients до vibrantlabsai, останній реліз — v0.4.3 від 2026-01-13, а комітів з 2026-02-24 немає. Обирайте це, якщо метрики RAG — вся робота, а тихий репозиторій прийнятний, і дивіться ширший стек інструментів RAG.

Opik (pip install opik, Apache-2.0, від Comet) постачає метрики, які можна викликати окремо. Встановіть OPIK_TRACK_DISABLE=true, і AnswerRelevance().score() спрацює без акаунта, локального сервера чи файлу конфігурації — про це маркетинг продукту не розповідає. Найкраще підходить для отримання реального скору мінімумом рядків. Обирайте це, якщо метрики потрібні зараз, а платформа, можливо, потім.

Evidently (pip install evidently, Apache-2.0) розглядає евали як дескриптори над датасетом і як побічний ефект пише HTML-звіт. Найкраще підходить для пакетної звітності по багатьох рядках, а не для бінарного гейта. Його скори LLM інвертовані: 1.0 означає неправдиву відповідь. Обирайте це, якщо потрібен звіт, яким можна поділитися, а не червона збірка.

Giskard (pip install giskard, Apache-2.0) сканує модель на вразливості замість оцінювання датасету, який ви написали. Пакет на PyPI резолвиться до лінійки v2, і власний README проєкту прямо стверджує, що v2 "більше не підтримується активно". Найкраще підходить для автоматизованих сканувань у стилі red-team. Обирайте це, якщо потрібно, щоб уразливості знайшли за вас, а не метрики LLM-як-судді, які визначаєте самі.

CLI-та-конфіг інструменти, що запускаються над YAML-файлом

promptfoo (npm install promptfoo, MIT) — це CLI, який читає YAML-файл: описуєте провайдерів, тест-кейси й твердження, запускаєте npx promptfoo eval і отримуєте pass/fail по кожному кейсу плюс локальний UI з результатами. Найкраще підходить для оцінювання промптів, коли ваш застосунок написаний не на Python. Обирайте це, якщо ворота якості мають бути конфіг-файлом, який може редагувати колега без Python.

Класу harness та вбудовані в платформу

Inspect AI (pip install inspect-ai, MIT) походить від UK AI Safety Institute й оцінює моделі проти завдань, які ви визначаєте в Python, із повноцінними абстракціями solver і scorer та переглядачем запусків. Найкраще підходить для бенчмаркінгу на рівні моделі з відтворюваними визначеннями завдань. Обирайте це, якщо об'єкт тестування — модель, а не ваш застосунок.

Arize Phoenix (pip install arize-phoenix-evals) дає готові оцінювачі на кшталт FaithfulnessEvaluator і CorrectnessEvaluator, які повертають бінарну мітку плюс скор. Найкраще підходить для детермінованих міток, за якими можна гейтити без вибору порогу. Саме через його ліцензію ця стаття має уточнення в дужках у заголовку, і наступний розділ присвячений саме цьому.

Чи є Arize Phoenix open source?

Ні, не за визначенням, яке підтримує Open Source Initiative. Arize Phoenix поширюється за ліцензією Elastic License 2.0 (ELv2). Рядок 1 файлу LICENSE репозиторію прямо про це каже, і PyPI незалежно декларує license: Elastic-2.0 на v19.15.0. Джерело доступне для читання, форкання й самостійного хостингу. Обмежене лише одне використання.

Обмеження, яке має значення: ELv2 забороняє надавати програмне забезпечення третім сторонам як хостинговий чи керований сервіс. Прочитайте це уважно, бо воно стосується набагато меншого кола людей, ніж здається на перший погляд. Якщо ви встановлюєте arize-phoenix-evals, щоб оцінювати власний застосунок, ELv2 вас узагалі не торкається. Якщо ви консалтингова компанія чи команда платформи, що пакує Phoenix у сервіс оцінювання й продає його зовнішнім клієнтам, торкається. Це вся різниця, і Open Source Definition — саме те, чому не відповідає ELv2, конкретно пунктам про обмеження за сферою використання.

Кожна сторінка, що наразі ранжується за цим запитом, зараховує Phoenix до "open source", і ми теж це робили. Наше власне ранжоване порівняння інструментів оцінювання LLM описує Phoenix як повністю open-source, що неправильно, і ця помилка виправляється. Phoenix — source-available (доступний як вихідний код), а не open source, і ця різниця має значення лише якщо ви плануєте продавати його як сервіс. Якщо насправді потрібне трасування, а не скоринг, це справа платформ AI-спостережливості, а не цієї статті.

Які з них досі активно підтримуються?

Більшість. Шість з одинадцяти перевірених репозиторіїв отримали коміт у main 2026-08-03 чи 2026-08-04: DeepEval, promptfoo, Opik, Arize Phoenix, Inspect AI і Giskard. Два не випускали релізів з 2024 року. Один затих у 2026 після зміни організації на GitHub.

Фреймворки, на яких ми б не почали новий проєкт у 2026 році

UpTrain мертвий. Останній коміт у main датований 2024-07-29, а останній реліз, v0.7.1, вийшов 2024-05-14, тобто за обома показниками проєкту вже два холодних роки. Репозиторій досі існує й досі поширюється за Apache-2.0, тож ніщо технічно не заважає, але почати нову роботу на покинутій бібліотеці оцінювання — це рішення, яке потім доведеться пояснювати.

Deepchecks заслуговує на точну версію. Не було релізу після 0.19.1 від 2024-12-15, хоча репозиторій все ще отримує коміти, останній з яких у main — 2025-11-24. Люди досі над ним працюють; просто ніхто не різав версію понад вісімнадцять місяців. Ні UpTrain, ні Deepchecks не заархівовані на GitHub, і жоден з них не закритий для контриб'юцій.

Ragas отримує лише дати й нічого більше. Останній реліз v0.4.3 від 2026-01-13, комітів з 2026-02-24 немає, а репозиторій переїхав з explodinggradients до vibrantlabsai. Ми не знайшли перевірюваного пояснення, чому змінилася організація, тож не вигадуватимемо його. Тихий репозиторій — ще не зламаний: код на Apache-2.0, який рахує скор правдивості сьогодні, рахуватиме його так само й наступного року. Ризик — непатчені залежності, і саме це нас укусило під час тестування нижче.

Інші сторінки на першій сторінці видачі за цим запитом досі рекомендують і UpTrain, і Deepchecks, без будь-якої дати біля рекомендації. Фреймворк без релізу з грудня 2024 року — це рішення про залежність, а не про фічу.

Вам потрібен eval-фреймворк чи eval-harness?

Прикладний eval-фреймворк оцінює результати саме вашого застосунку на ваших власних даних. DeepEval, Ragas, promptfoo, Opik, phoenix-evals і Evidently роблять саме це. Harness для оцінювання моделі, натомість, бенчмаркить модель проти стандартизованих публічних завдань. lm-evaluation-harness і Inspect AI роблять саме це. Обрати не той клас — найдорожча помилка на цій сторінці.

Провальний сценарій цілком конкретний. Хтось підключає lm-evaluation-harness, щоб протестувати свого RAG-чатбота, отримує набір скорів MMLU і не дізнається практично нічого про те, чи повертає ретрівер потрібні уривки. Скори реальні. Вони вимірюють базову модель, за яку ніхто й не переймався.

Форма Inspect AI випливає з його походження: його створили в UK AI Safety Institute за ліцензією MIT для оцінювання фронтирних моделей, тож solver, scorer і завдання — повноцінні перші класи, а ваш застосунок для нього взагалі не концепція. Це вагома причина використовувати його саме за призначенням. Якщо ваша проблема — агенти, а не окремі репліки, оцінювання агентів у продакшені — це вже інша дисципліна, а серверам виклику інструментів присвячений окремий розбір у нашому гайді з оцінювання MCP-серверів та інструментів.

Що сталося, коли ми встановили шість із них і прогнали ті самі 10 кейсів

4 серпня 2026 року ми встановили шість із цих фреймворків у свіжих venv на Python 3.11.14 (плюс npm для promptfoo) і оцінили один і той самий набір з 10 RAG-пунктів одним суддею — openai/gpt-4o-mini через OpenRouter при температурі 0. Сім пунктів були правильними. Три були зламані трьома різними способами: один суперечить своєму контексту, один вигадує деталі, один — це плавна проза, яка так і не відповідає на питання. Кожен фреймворк запускали двічі підряд.

П'ять з шести метрик обґрунтованості впіймали всі три дефекти. Три знахідки нижче — причина, чому цей розділ узагалі існує.

Метрики релевантності — не метрики якості, і дві з них оцінили впевнену брехню вище за правильну відповідь. Ragas ResponseRelevancy оцінив пункт, що стверджує, ніби HTTP 404 — це помилка сервера класу 5xx, у 0.777, вище за дві із семи правильних відповідей, а пункт із вигаданими лімітами запитів — у 0.813, вище за чотири. promptfoo answer-relevance зробив те саме: 0.800 для пункту з 404, чистий прохід проти порогу 0.7, тоді як правильна відповідь q01 провалилася з 0.679. Це не баг. Впевнена неправильна відповідь ідеально адресує поставлене питання. Але якщо релевантність — те число, що на вашому дашборді, плавна галюцинація виглядатиме як ваш найкращий результат.

Гейт лише за правдивістю пропускає нерелевантну відповідь. DeepEval оцінив пункт, що взагалі не відповідає на питання, у 1.000 за правдивістю — чистий прохід, що по-своєму логічно: відповідь, яка нічого не стверджує про контекст, нічому в ньому й не суперечить. Лише релевантність впіймала це, з оцінкою 0.000. Це той самий один промах обґрунтованості з таблиці вище. У кожної метрики окремо є діра; разом вони закривають обидві.

Бінарні оцінювачі були стабільні при температурі 0. Градовані — ні. Phoenix і DeepEval не зрушили жодного з десяти пунктів за два ідентичні запуски. Opik зрушив чотири, усі на AnswerRelevance, на сітці 0.05; Evidently теж зрушив чотири. Жоден дрейф тут не перевернув вердикт, але правильна q01 у promptfoo впала з 0.679 до 0.642 проти порогу 0.700 — це форма нестабільного CI-гейта.

Дві менші примітки: три з шести (DeepEval, Opik, Phoenix) встановилися й запустилися чисто з першого разу, тоді як Ragas не хотів імпортуватися, поки ми не зафіксували langchain-community<0.4. Тільки promptfoo звітував використання токенів суддею: 16 011 токенів на твердження в запуску 1 і 16 010 у запуску 2.

Обмеження цього тесту, сказані прямо. n = 10 — це дим-тест, не бенчмарк: він розповідає про ергономіку й сліпі зони, а не про точність метрик. Скорив усе один суддя-модель, і більша модель зрушила б кожне число, ймовірно, включно з двома хибнопозитивними результатами, які і DeepEval, і Ragas видали на тому самому правильному пункті. Два запуски доводять, що дрейф існує, але не дозволяють його охарактеризувати. Відповіді були заготовлені заздалегідь, тож нічого тут не задіює генерацію, трасування чи керування датасетами, через що 337.9-секундне встановлення promptfoo виглядає гірше, ніж заслуговує. "Найкращий" завжди означає найкращий для якогось обмеження: CI-гейт, метрики RAG чи UI — кожне з них дає іншу відповідь, так само як і поділ на офлайн- та онлайн-оцінювання.

Одна й та сама перевірка, написана трьома способами

Найшвидший спосіб обрати форму інтерфейсу — прочитати одне й те саме твердження тричі. Ось перевірка обґрунтованості на одному пункті в DeepEval, Ragas і promptfoo, скорочена зі скриптів, які ми справді запускали. Назви метрик відрізняються; ми посилаємось на як насправді працюють метрики LLM-як-судді, замість того щоб перевизначати їх тут.

# DeepEval 4.1.5: у стилі pytest, провалює тест нижче порогу
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: зверніть увагу на шлях імпорту. `from ragas.metrics import Faithfulness`
# викидає ImportError у цій версії; конкретна метрика переїхала.
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, потім npx promptfoo eval
providers:
  - id: echo          # ми оцінювали заготовлені відповіді замість генерації
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."

У рядках встановлення пасток більше, ніж у самому коді, і кожен коментар нижче — те, на чому ми втратили час 4 серпня 2026 року:

# Справжній promptfoo публікується на npm. Пакет з тією самою назвою на PyPI —
# стороння обгортка: https://pypi.org/project/promptfoo/ проти
# https://www.npmjs.com/package/promptfoo
npm install promptfoo

# pip install giskard резолвиться до лінійки v2, яку власний README проєкту
# позначає як таку, що більше не підтримується активно.
pip install giskard

# lm-evaluation-harness встановлюється під назвою пакета lm-eval.
pip install lm-eval

# Evidently не підтягує openai, і суддя падає під час виклику, а не під час
# імпорту — вже після того, як ви побудували датасет.
pip install evidently openai

# Ragas 0.4.3 не імпортується проти langchain-community 0.4.x.
pip install ragas "langchain-community<0.4"

Чи можна провалити збірку через eval-скор?

Так. Кожен фреймворк тут повертає числовий або бінарний скор, і кожен вийде з ненульовим кодом, коли твердження про поріг провалиться, — а це все, що потрібно GitHub Actions, щоб зробити збірку червоною. Прокинути код виходу — легка частина. Обрати поріг, який суддя-модель не перетне випадково, — та частина, що займає тиждень.

Ось форма воркфлоу, яку ми запускаємо, зафіксована на версіях з нашого тесту від 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:
          # Зафіксуйте суддю. Оновлення моделі посеред кварталу зрушить кожен скор.
          JUDGE_MODEL: openai/gpt-4o-mini
          # Пороги живуть в одному місці, зчитуються конструкторами метрик.
          EVAL_THRESHOLD: "0.7"
          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
        run: deepeval test run tests/evals/

Дві пастки кусають раніше за поріг. По-перше, виклики судді — це мережеві виклики: наш запуск DeepEval на 10 пунктів зайняв 126.8 секунди, бо .measure() виконується послідовно, а золотий набір з 200 пунктів на цьому ж коді — це перерва на каву на кожен pull request. Кожен інший фреймворк у тесті паралелізує виконання за замовчуванням, і це найважливіший важіль часу очікування CI.

По-друге, нестабільність. При температурі 0 Opik і Evidently зрушили по чотири з десяти пунктів між парою запусків підряд, а правильна відповідь promptfoo впала з 0.679 до 0.642 проти гейта 0.700. Заходи пом'якшення нудні й прості: запускайте фіксований золотий датасет, який змінюється лише разом з pull request, зафіксуйте модель-суддю, надавайте перевагу бінарним оцінювачам там, де досить мітки, і гейтіть за дельтою, а не за абсолютним порогом. Останнє має найбільше значення для багатотурнового оцінювання, де одна розмова дає багато скорів, і кожен з них може хитнутись.

Для масштабу: опитування LangChain State of Agent Engineering survey (1 340 відповідей, зібраних з 18 листопада по 2 грудня 2025 року, опубліковано 12 червня 2026 року) показало, що 89% організацій впровадили якусь форму спостережності для своїх агентів, тоді як лише 52.4% запускають офлайн-оцінювання на тестових наборах. Спостерігати — звична річ. Гейтити — ні.

Що б ми встановили цього тижня

Чотири речі на винос. Arize Phoenix — source-available за ліцензією Elastic License 2.0 і не схвалений OSI як open source, що для більшості читачів не змінює нічого, а для тих, хто перепродає eval-інструменти, змінює все. UpTrain мертвий, і сторінки без дати досі його рекомендують. Deepchecks теж не різав реліз з грудня 2024 року, хоча його репозиторій все ще приймає коміти. У метрики обґрунтованості й метрики релевантності — по одній дірі, яку закриває інша, тож гейтіть за обома. І градовані скори дрейфують при температурі 0, тож зафіксуйте суддю й залиште запас для порогів.

Якби ми починали новий набір евалів цього тижня, ми б поставили DeepEval для CI-гейта, бо твердженням місце поруч з тестами (розкриття вище), і додали б окремі метрики Opik для найчистішого розділення, яке ми виміряли. Якби наш стек не був на Python — без вагань promptfoo. Якщо ви хочете, щоб хтось інший налаштував золотий набір і воркфлоу, ми з радістю про це поговоримо.

Часті запитання

Який найкращий open-source фреймворк оцінювання LLM?

Єдиного переможця немає, є лише найкращий вибір під конкретне обмеження. Для гейта pass/fail усередині Python-тестів — DeepEval. Для мовно-незалежного налаштування YAML і CLI — promptfoo. Для метрик пошуку RAG — Ragas, якщо прийнятний репозиторій без комітів з 2026-02-24. Для найчистішого розділення хороших і поганих відповідей у нашому тесті від 2026-08-04 — Opik.

Чи є Arize Phoenix open source?

Не за визначенням Open Source Initiative. Arize Phoenix поширюється за ліцензією Elastic License 2.0, яку PyPI декларує як license: Elastic-2.0 на v19.15.0 і яку прямо вказує рядок 1 файлу LICENSE репозиторію. Це source-available: ви можете читати, форкати, модифікувати й самостійно хостити. Єдине обмеження — надання програмного забезпечення третім сторонам як хостингового чи керованого сервісу.

Чи Ragas досі підтримується?

Перевірювані факти станом на 2026-08-04: останній реліз — v0.4.3 від 2026-01-13, комітів з 2026-02-24 немає, а репозиторій переїхав з організації explodinggradients до vibrantlabsai. Репозиторій не заархівовано. Ми не знайшли надійного публічного пояснення зміни організації й не будемо його вигадувати. Код на Apache-2.0 і досі працює; ризик — непатчені залежності.

Чи потрібен мені eval-фреймворк чи платформа спостережності?

Зрештою — і те, і те, але вони відповідають на різні питання. Eval-фреймворк каже, чи зробила зміна ваші результати кращими чи гіршими, ще до того, як ви їх випустили, на датасеті, який ви контролюєте. Платформа спостережності каже, що насправді сталося в продакшені після випуску. Починайте з eval-фреймворка, якщо у вас є CI-пайплайн; дивіться платформи AI-спостережливості для продакшн-сторони.

Чи можна запускати LLM-евали в CI/CD?

Так. Кожен фреймворк, розглянутий тут, виходить з ненульовим кодом при провалі порогового твердження, а це все, що потрібно джобі GitHub Actions. Практичні обмеження — час очікування (виклики судді — це мережеві виклики, і наш послідовний запуск DeepEval зайняв 126.8 секунди на 10 пунктів) та недетермінованість судді. Форма воркфлоу й заходи пом'якшення — в розділі про CI вище.

У чому різниця між DeepEval і Ragas?

Форма інтерфейсу й сфера застосування, не якість. DeepEval у стилі pytest і загального призначення: ви пишете тест-кейси й тверджуєте пороги метрик, і він охоплює результати застосунку багатьох видів. Ragas — RAG-специфічна бібліотека, чий evaluate() виконується асинхронно над датасетом з рядків питання, контексту й відповіді. DeepEval природніше вписується в CI-гейт; Ragas глибше йде в пошук.

Чому pip install promptfoo встановлює не той пакет?

Бо promptfoo — це Node-проєкт. Справжній публікується на npm за ліцензією MIT і встановлюється через npm install promptfoo. Пакет на PyPI з тією самою назвою — стороння обгортка, а не оригінальний проєкт, і встановлення його — поширений спосіб опинитися за налагодженням CLI, який зовсім не той, що описаний у документації.

Чи є lm-evaluation-harness фреймворком оцінювання LLM?

Це harness для оцінювання моделі — суміжна, але інша робота. lm-evaluation-harness (встановлюється як pip install lm-eval) бенчмаркить модель проти стандартизованих публічних завдань на кшталт MMLU. Він не скаже, чи повернув ваш пошуковий пайплайн правильний уривок, бо ваш застосунок для нього взагалі не концепція. Розділ про фреймворк проти harness вище описує цей поділ.

Чи безкоштовні ці фреймворки у використанні?

За ліцензією — так. DeepEval, Ragas, Opik, Evidently і Giskard поширюються за Apache-2.0; promptfoo, Inspect AI і lm-evaluation-harness — за MIT. Обидві ліцензії дозволяють комерційне використання, модифікацію й поширення. Arize Phoenix — виняток: Elastic License 2.0 дозволяє самостійний хостинг, але не надання програмного забезпечення третім сторонам як керованого сервісу. Використання API моделі-судді оплачується окремо у вашого провайдера.