Melhores Frameworks Open Source de Avaliação de LLM em 2026 (Um Não É Realmente Open Source)

Melhores Frameworks Open Source de Avaliação de LLM em 2026 (Um Não É Realmente Open Source)

A linha 1 do arquivo LICENSE no repositório do Arize Phoenix diz "Elastic License 2.0 (ELv2)". Não é Apache. Não é MIT. Um framework open source de avaliação de LLM fortemente recomendado não é open source pela definição da OSI, e quase toda página bem posicionada para essa busca repete a alegação mesmo assim. O mesmo valia para uma das nossas, até hoje. Em 2026-08-04 lemos manualmente o arquivo de licença e o histórico de commits da branch padrão de oito frameworks, mais três outros que as páginas do topo ainda recomendam, depois instalamos seis e rodamos os mesmos 10 casos em cada um. Não vendemos um framework de avaliação, então nenhum veredito abaixo está protegendo um produto.

Principais Conclusões

• O Arize Phoenix usa a Elastic License 2.0, que a OSI não aprova como open source.
• O último commit do UpTrain na main foi em 2024-07-29. Não comece um projeto novo com ele.
• pip install promptfoo instala um wrapper de terceiros. O projeto real fica no npm.
• O Ragas não tem commits desde 2026-02-24 e mudou de organização no GitHub para vibrantlabsai.

Qual Framework Open Source de Avaliação de LLM Você Deve Instalar em 2026?

Escolha pela restrição, não pelo ranking. Para asserções no formato pytest dentro de uma suíte de testes existente, instale o DeepEval. Para uma config YAML e uma CLI que se encaixa em qualquer stack de linguagem, instale o promptfoo. Para a separação mais limpa entre bom e ruim que medimos, instale o Opik. Os três são Apache-2.0 ou MIT.

Aqui está a auditoria. Oito frameworks no escopo, mais três outros que as páginas mais bem posicionadas para essa busca ainda recomendam.

As datas são o último commit na branch padrão de cada projeto, verificadas em 2026-08-04. A página do repositório no GitHub mostra o último push em qualquer branch, o que é mais recente para dois projetos aqui: UpTrain 2024-08-18 e Deepchecks 2025-12-28. Nenhum dos dois repositórios está arquivado.

A coluna de custo de troca é a que as pessoas pulam e depois se arrependem. Pontuações são só números, então migrar entre DeepEval, Ragas, Opik e phoenix-evals significa basicamente reescrever um loop. Sair do promptfoo ou do Inspect AI significa reescrever um formato de config ou task sem equivalente em outro lugar, e sair do Evidently significa auditar cada threshold que você escreveu, porque a escala dele funciona ao contrário. Dois dos frameworks que as páginas mais bem posicionadas ainda recomendam não lançam uma versão desde 2024.

Quer níveis, plataformas hospedadas e uma ordem direta em vez disso? Isso é um trabalho diferente, e já fizemos em nossa comparação classificada de ferramentas de avaliação de LLM, incluindo plataformas pagas.

Os Oito Frameworks de Avaliação de LLM, Agrupados pela Forma de Instalação

O formato de instalação é o que você tem que conviver, então é essa a base do agrupamento.

Bibliotecas Python que você importa nos testes

DeepEval (pip install deepeval, Apache-2.0) embrulha métricas de LLM em asserções no formato pytest: monte um LLMTestCase, passe para assert_test, e o teste falha abaixo do seu threshold. Melhor para colocar um gate de qualidade ao lado dos testes unitários que uma equipe já roda. Escolha isso se suas avaliações pertencem ao mesmo job de CI que tudo o mais.

Uma divulgação, dita uma vez: o DeepEval é feito pela Confident AI, que é parceira paga em outros dois posts deste site, incluindo a comparação classificada para a qual esta página aponta. Ele não recebe tratamento especial aqui, e todo link do DeepEval nesta página aponta para o repositório no GitHub.

Ragas (pip install ragas, Apache-2.0) é a opção específica para RAG: evaluate() recebe linhas de pergunta, contexto e resposta e retorna pontuações por métrica de forma assíncrona. Melhor para medir a qualidade da recuperação dentro de um pipeline Python. Seu repositório mudou de explodinggradients para vibrantlabsai, sua última versão foi a v0.4.3 em 2026-01-13, e não há commits desde 2026-02-24. Escolha isso se métricas de RAG são todo o trabalho e um repositório quieto for aceitável, e veja a stack mais ampla de ferramentas de RAG.

Opik (pip install opik, Apache-2.0, da Comet) traz métricas que você pode chamar sozinhas. Defina OPIK_TRACK_DISABLE=true e AnswerRelevance().score() roda sem conta, sem servidor local e sem arquivo de config, o que o marketing do produto não anuncia. Melhor para obter uma pontuação real no menor número de linhas. Escolha isso se você quer métricas agora e a plataforma talvez depois.

Evidently (pip install evidently, Apache-2.0) trata avaliações como descritores sobre um dataset e escreve um relatório HTML como efeito colateral. Melhor para relatórios em lote em muitas linhas em vez de um gate binário. Suas pontuações de LLM são invertidas: 1.0 significa infiel ao contexto. Escolha isso se o que você deve a alguém é um relatório compartilhável, não um build vermelho.

Giskard (pip install giskard, Apache-2.0) varre um modelo em busca de vulnerabilidades em vez de pontuar um dataset que você escreveu. O pacote no PyPI resolve a linha v2, e o próprio README do projeto afirma que a v2 "não é mais mantida ativamente". Melhor para varreduras automatizadas estilo red-team. Escolha isso se você quer vulnerabilidades encontradas para você, em vez de métricas de LLM-as-a-judge que você mesmo define.

Ferramentas de CLI e config que rodam contra um arquivo YAML

promptfoo (npm install promptfoo, MIT) é uma CLI que lê um arquivo YAML: declare providers, casos de teste e asserções, rode npx promptfoo eval, e receba pass/fail por caso mais uma UI local de resultados. Melhor para avaliar prompts quando seu app não é escrito em Python. Escolha isso se seu gate de qualidade deve ser um arquivo de config que um colega de equipe que não usa Python consiga editar.

Classe harness e integrado em plataforma

Inspect AI (pip install inspect-ai, MIT) vem do UK AI Safety Institute e avalia modelos contra tasks que você define em Python, com abstrações reais de solver e scorer e um visualizador de execuções. Melhor para benchmark em nível de modelo com definições de task reproduzíveis. Escolha isso se o que está sendo testado é um modelo, e não sua aplicação.

Arize Phoenix (pip install arize-phoenix-evals) oferece avaliadores prontos como FaithfulnessEvaluator e CorrectnessEvaluator que retornam um rótulo binário mais uma pontuação. Melhor para rótulos determinísticos que você pode usar como gate sem precisar escolher um corte. Sua licença é o motivo deste artigo ter um parêntese no título, e isso ganha sua própria seção a seguir.

O Arize Phoenix É Open Source?

Não, não pela definição que a Open Source Initiative mantém. O Arize Phoenix usa a Elastic License 2.0 (ELv2). A linha 1 do arquivo LICENSE do repositório diz isso, e o PyPI declara independentemente license: Elastic-2.0 na v19.15.0. O código-fonte é legível, pode ser bifurcado (fork) e hospedado por conta própria. Um uso é restrito.

A restrição que importa: a ELv2 proíbe oferecer o software a terceiros como serviço hospedado ou gerenciado. Leia isso com atenção, porque afeta bem menos gente do que parece. Se você instala arize-phoenix-evals para pontuar sua própria aplicação, a ELv2 nunca chega até você. Se você é uma consultoria ou uma equipe de plataforma empacotando o Phoenix num serviço de avaliação que vende a clientes externos, aí sim chega. É essa a diferença inteira, e a Open Source Definition é o que a ELv2 não cumpre, especificamente as cláusulas sobre restrições de campo de uso.

Toda página atualmente bem posicionada para essa busca classifica o Phoenix como "open source", e nós também classificávamos assim. Nossa própria comparação classificada de ferramentas de avaliação de LLM descreve o Phoenix como totalmente open source, o que está errado, e está sendo corrigido. O Phoenix é source-available (código disponível), não open source, e essa distinção só importa se você planeja vendê-lo como serviço. Se o que você realmente precisa é rastreamento (tracing) e não pontuação, isso pertence às plataformas de observabilidade de IA, não aqui.

Quais Deles Ainda São Mantidos Ativamente?

A maioria. Seis dos onze repositórios que verificamos receberam um commit na main em 2026-08-03 ou 2026-08-04: DeepEval, promptfoo, Opik, Arize Phoenix, Inspect AI e Giskard. Dois não lançam uma versão desde 2024. Um ficou quieto em 2026 depois de uma mudança de organização no GitHub.

Frameworks com os quais não começaríamos um projeto novo em 2026

O UpTrain está morto. Seu último commit na main foi em 2024-07-29 e sua última versão, v0.7.1, foi em 2024-05-14, o que o deixa dois anos parado por qualquer uma das duas medidas. O repositório ainda existe e ainda é Apache-2.0, então nada te impede, mas começar um trabalho novo numa biblioteca de avaliação abandonada é uma decisão que você vai ter que explicar depois.

O Deepchecks merece a versão precisa. Não tem uma versão lançada desde a 0.19.1 em 2024-12-15, embora o repositório ainda receba commits, com o último na main datado de 2025-11-24. As pessoas ainda estão trabalhando nele; ninguém lançou uma versão em mais de dezoito meses. Nem o UpTrain nem o Deepchecks estão arquivados no GitHub, e nenhum dos dois fechou as portas para contribuições.

O Ragas só recebe datas e nada mais. Última versão v0.4.3 em 2026-01-13, sem commits desde 2026-02-24, e o repositório mudou de explodinggradients para vibrantlabsai. Não encontramos nenhuma explicação verificável para a mudança de organização, então não vamos inventar uma. Um repositório quieto não é um repositório quebrado: código Apache-2.0 que calcula uma pontuação de faithfulness hoje ainda vai calcular no ano que vem. O risco são dependências sem patch, que foi exatamente o que nos pegou nos testes abaixo.

Outras páginas na primeira posição desta busca ainda recomendam tanto o UpTrain quanto o Deepchecks, sem nenhuma data associada à recomendação. Um framework sem versão desde dezembro de 2024 é uma decisão de dependência, não uma decisão de feature.

Você Precisa de um Framework de Avaliação ou de um Harness de Avaliação?

Um framework de avaliação de aplicação pontua as saídas da sua própria aplicação contra seus próprios dados. DeepEval, Ragas, promptfoo, Opik, phoenix-evals e Evidently fazem isso. Um harness de avaliação de modelo, em vez disso, faz benchmark de um modelo contra tasks públicas padronizadas. lm-evaluation-harness e Inspect AI fazem isso. Escolher a classe errada é o erro mais caro desta página.

O modo de falha é concreto. Alguém conecta o lm-evaluation-harness para testar seu chatbot de RAG, recebe de volta um conjunto de pontuações MMLU, e não aprende absolutamente nada sobre se o retriever está retornando as passagens certas. As pontuações são reais. Elas medem o modelo base, com o qual ninguém estava preocupado.

O formato do Inspect AI vem da sua origem: foi construído no UK AI Safety Institute sob MIT para avaliar modelos de fronteira, então solvers, scorers e tasks são cidadãos de primeira classe, e sua aplicação não é um conceito que ele tem. É um bom motivo para usá-lo para o que ele serve. Se seu problema são agentes em vez de turnos únicos, avaliar agentes em produção é uma disciplina diferente de novo, e servidores de tool-calling ganham seu próprio tratamento no nosso guia de avaliação de servidores e ferramentas MCP.

O Que Aconteceu Quando Instalamos Seis Deles e Rodamos os Mesmos 10 Casos

Em 2026-08-04 instalamos seis dessas ferramentas em venvs limpos de Python 3.11.14 (mais npm para o promptfoo) e pontuamos um mesmo conjunto de 10 itens de RAG com um único juiz, openai/gpt-4o-mini via OpenRouter, em temperatura 0. Sete itens estavam corretos. Três estavam quebrados de três formas diferentes: um contradiz seu contexto, um inventa detalhes específicos, um é uma prosa fluente que nunca responde à pergunta. Cada framework rodou duas vezes, seguidas.

Cinco das seis métricas de grounding capturaram os três defeitos. Os três achados abaixo são o motivo desta seção existir.

Métricas de relevância não são métricas de qualidade, e duas delas pontuaram uma mentira confiante acima de uma resposta correta. O ResponseRelevancy do Ragas pontuou o item que afirma que HTTP 404 é um erro de servidor 5xx em 0.777, acima de duas das sete respostas corretas, e o item com limites de taxa inventados em 0.813, acima de quatro. O answer-relevance do promptfoo fez o mesmo: 0.800 para o item do 404, um pass limpo contra um threshold de 0.7, enquanto reprovava o q01 correto em 0.679. Não é um bug. Uma resposta errada dita com confiança atende à pergunta perfeitamente. Mas se relevância é o número no seu dashboard, uma alucinação fluente parece sua melhor saída.

Um gate baseado só em faithfulness perde a resposta irrelevante. O DeepEval pontuou o item que nunca responde à pergunta com 1.000 de faithfulness, um pass limpo, o que é defensável: uma resposta que não afirma nada sobre o contexto não contradiz nada nele. Só a relevância capturou isso, em 0.000. Esse é o único erro de grounding na tabela acima. Qualquer uma das métricas isoladamente tem uma brecha; a dupla cobre as duas.

Avaliadores binários se mantiveram estáveis em temperatura 0. Os graduados, não. Phoenix e DeepEval não moveram nenhum dos dez itens entre duas execuções idênticas. O Opik moveu quatro, todos no AnswerRelevance, numa grade de 0.05; o Evidently também moveu quatro. Nenhuma oscilação virou um veredito aqui, mas o q01 correto do promptfoo caiu para 0.679 e depois 0.642 contra um threshold de 0.700, o que é a cara de um gate de CI instável.

Duas notas menores: três dos seis (DeepEval, Opik, Phoenix) instalaram e rodaram limpos de primeira, enquanto o Ragas só importou depois que fixamos langchain-community<0.4. Só o promptfoo reportou o uso de tokens do juiz: 16.011 tokens de asserção na execução 1 e 16.010 na execução 2.

Os limites disso, ditos com clareza. n = 10 é um smoke test, não um benchmark: mostra ergonomia e pontos cegos, não precisão de métrica. Um único modelo juiz pontuou tudo, e um juiz maior mudaria todos os números, provavelmente incluindo os dois falsos positivos que DeepEval e Ragas produziram no mesmo item correto. Duas execuções provam que a oscilação existe e não conseguem caracterizá-la. As respostas foram pré-escritas, então nada aqui exercita geração, rastreamento ou gestão de dataset, o que faz os 337.9 segundos de instalação do promptfoo parecerem piores do que merecem. "Melhor" sempre significa melhor para uma restrição: um gate de CI, métricas de RAG ou uma UI mudam a resposta, assim como a divisão entre avaliação offline e online.

A Mesma Verificação, Escrita de Três Formas

A forma mais rápida de escolher um formato de interface é ler a mesma asserção três vezes. Aqui está uma verificação de grounding num item no DeepEval, no Ragas e no promptfoo, resumida dos scripts que realmente rodamos. Os nomes das métricas diferem; linkamos para como as métricas de LLM-as-a-judge realmente funcionam em vez de redefini-las aqui.

# DeepEval 4.1.5: no formato pytest, falha o teste abaixo do threshold
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: repare no caminho de import. `from ragas.metrics import Faithfulness`
# lança ImportError nesta versão; a métrica concreta mudou de lugar.
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, depois npx promptfoo eval
providers:
  - id: echo          # pontuamos respostas pré-escritas em vez de gerá-las
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."

As linhas de instalação escondem mais armadilhas do que o código, e cada comentário abaixo é algo que nos custou tempo em 2026-08-04:

# O promptfoo real fica no npm. O pacote no PyPI com o mesmo nome é um
# wrapper de terceiros: https://pypi.org/project/promptfoo/ vs
# https://www.npmjs.com/package/promptfoo
npm install promptfoo

# pip install giskard resolve a linha v2, que o próprio README do projeto
# marca como não mais mantida ativamente.
pip install giskard

# lm-evaluation-harness instala sob o nome de pacote lm-eval.
pip install lm-eval

# O Evidently não puxa o openai, e o juiz quebra na hora da chamada, não
# na hora do import, depois que você já construiu o dataset.
pip install evidently openai

# Ragas 0.4.3 não importa contra langchain-community 0.4.x.
pip install ragas "langchain-community<0.4"

Você Pode Reprovar um Build Com Base numa Pontuação de Avaliação?

Sim. Todo framework aqui retorna uma pontuação numérica ou binária, e cada um sai com código diferente de zero quando uma asserção de threshold falha, o que é tudo que o GitHub Actions precisa para deixar um build vermelho. Conectar o código de saída é a parte fácil. Escolher um threshold que seu modelo juiz não vai cruzar por acidente é a parte que leva uma semana.

Esse é o formato de workflow que rodamos, fixado nas versões do nosso teste de 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: Pontuar o golden set
        env:
          # Fixe o juiz. Um upgrade de modelo no meio do trimestre move todas as pontuações.
          JUDGE_MODEL: openai/gpt-4o-mini
          # Os thresholds ficam num só lugar, lidos pelos construtores de métrica.
          EVAL_THRESHOLD: "0.7"
          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
        run: deepeval test run tests/evals/

Duas pegadinhas mordem antes do threshold. Primeiro, chamadas ao juiz são chamadas de rede: nossa execução de 10 itens no DeepEval levou 126.8 segundos porque .measure() é sequencial, e um golden set de 200 itens nesse caminho de código vira uma pausa para café em cada pull request. Todo outro framework no teste paraleliza por padrão, o que é a maior alavanca isolada no tempo de relógio do CI.

Segundo, instabilidade. Em temperatura 0, Opik e Evidently moveram quatro de dez itens cada entre execuções consecutivas, e a resposta correta do promptfoo ficou em 0.679 e depois 0.642 contra um gate de 0.700. As mitigações são chatas e funcionam: rode um golden dataset fixo que só muda por pull request, fixe o modelo juiz, prefira avaliadores binários onde um rótulo resolve, e faça o gate por um delta em vez de um piso absoluto. Esse último ponto importa mais na avaliação multi-turn, onde uma conversa produz muitas pontuações que podem oscilar cada uma.

Para dar uma escala: a pesquisa State of Agent Engineering da LangChain (1.340 respostas, coletadas entre 18 de novembro e 2 de dezembro de 2025, publicada em 12 de junho de 2026) descobriu que 89% das organizações implementaram alguma forma de observabilidade para seus agentes, enquanto apenas 52.4% rodam avaliações offline em conjuntos de teste. Observar é comum. Fazer gate não é.

O Que Instalaríamos Esta Semana

Quatro pontos para levar. O Arize Phoenix é source-available sob a Elastic License 2.0 e não é open source aprovado pela OSI, o que não muda nada para a maioria dos leitores e muda tudo se você revende ferramentas de avaliação. O UpTrain está morto, e páginas sem data ainda o recomendam. O Deepchecks também não lança uma versão desde dezembro de 2024, embora seu repositório ainda receba commits. Uma métrica de grounding e uma métrica de relevância têm, cada uma, uma brecha que a outra cobre, então faça gate nas duas. E pontuações graduadas oscilam em temperatura 0, então fixe seu juiz e dê folga aos thresholds.

Se eu estivesse começando uma suíte de avaliação nova esta semana, instalaria o DeepEval para o gate de CI porque asserções pertencem ao lado dos testes (divulgação acima), e adicionaria as métricas standalone do Opik pela separação mais limpa que medimos. Se nossa stack não fosse Python, promptfoo sem hesitar. Se você preferir que outra pessoa monte o golden set e o workflow, essa é uma conversa que temos prazer em ter.

Perguntas Frequentes

Qual é o melhor framework open source de avaliação de LLM?

Não existe um único vencedor, só o melhor encaixe por restrição. Para um gate de pass/fail dentro de uma suíte de testes Python, DeepEval. Para uma configuração YAML e CLI independente de linguagem, promptfoo. Para métricas de recuperação em RAG, Ragas, se você aceitar um repositório sem commits desde 2026-02-24. Para a separação mais limpa entre respostas boas e ruins no nosso teste de 2026-08-04, Opik.

O Arize Phoenix é open source?

Não pela definição da Open Source Initiative. O Arize Phoenix usa a Elastic License 2.0, que o PyPI declara como license: Elastic-2.0 na v19.15.0 e que a linha 1 do arquivo LICENSE do repositório declara diretamente. É source-available: você pode ler, fazer fork, modificar e hospedar por conta própria. A única restrição é oferecer o software a terceiros como serviço hospedado ou gerenciado.

O Ragas ainda é mantido?

Os fatos verificáveis, em 2026-08-04: a última versão foi a v0.4.3 em 2026-01-13, não há commits desde 2026-02-24, e o repositório mudou da organização explodinggradients para vibrantlabsai. O repositório não está arquivado. Não encontramos nenhuma explicação pública confiável para a mudança de organização e não vamos especular sobre uma. O código Apache-2.0 ainda roda; o risco são dependências sem patch.

Eu preciso de um framework de avaliação ou de uma plataforma de observabilidade?

Os dois, eventualmente, mas eles respondem perguntas diferentes. Um framework de avaliação diz se uma mudança deixou suas saídas melhores ou piores antes de você lançar, num dataset que você controla. Uma plataforma de observabilidade diz o que realmente aconteceu em produção depois que você lançou. Comece pelo framework de avaliação se você tem um pipeline de CI; veja plataformas de observabilidade de IA para o lado de produção.

Posso rodar avaliações de LLM em CI/CD?

Sim. Todo framework coberto aqui sai com código diferente de zero quando uma asserção de threshold falha, o que é tudo que um job do GitHub Actions precisa. As restrições práticas são tempo de relógio (chamadas ao juiz são chamadas de rede, e nossa execução sequencial do DeepEval levou 126.8 segundos para 10 itens) e a não-determinismo do juiz. O formato do workflow e as mitigações estão na seção de CI acima.

Qual é a diferença entre DeepEval e Ragas?

Formato de interface e escopo, não qualidade. O DeepEval é no formato pytest e de propósito geral: você escreve casos de teste e faz assert em thresholds de métrica, e ele cobre saídas de aplicação de muitos tipos. O Ragas é uma biblioteca específica para RAG cujo evaluate() roda de forma assíncrona sobre um dataset de linhas de pergunta, contexto e resposta. O DeepEval se encaixa mais naturalmente num gate de CI; o Ragas vai mais fundo em recuperação.

Por que pip install promptfoo me dá o pacote errado?

Porque o promptfoo é um projeto Node. O real é publicado no npm sob MIT e instala com npm install promptfoo. O pacote no PyPI com o mesmo nome é um wrapper de terceiros, não o projeto original, e instalá-lo é uma forma comum de acabar debugando uma CLI que não é a que a documentação descreve.

O lm-evaluation-harness é um framework de avaliação de LLM?

É um harness de avaliação de modelo, um trabalho relacionado mas diferente. O lm-evaluation-harness (instalado como pip install lm-eval) faz benchmark de um modelo contra tasks públicas padronizadas como MMLU. Ele não vai dizer se seu pipeline de recuperação retornou a passagem certa, porque sua aplicação não é um conceito que ele tem. Veja a seção de framework versus harness acima para a diferença.

Esses frameworks são gratuitos?

Em termos de licença, sim. DeepEval, Ragas, Opik, Evidently e Giskard são Apache-2.0; promptfoo, Inspect AI e lm-evaluation-harness são MIT. Ambas as licenças permitem uso comercial, modificação e redistribuição. O Arize Phoenix é a exceção: a Elastic License 2.0 permite hospedagem própria, mas não oferecer o software a terceiros como serviço gerenciado. O uso da API do modelo juiz é cobrado separadamente pelo seu provedor.