Los Mejores Frameworks de Evaluación LLM de Código Abierto en 2026 (Uno No Es Realmente de Código Abierto)

Los Mejores Frameworks de Evaluación LLM de Código Abierto en 2026 (Uno No Es Realmente de Código Abierto)

La línea 1 del archivo LICENSE en el repo de Arize Phoenix dice "Elastic License 2.0 (ELv2)". Ni Apache. Ni MIT. Uno de los frameworks de evaluación LLM open source más recomendados no es open source según la definición de la OSI, y casi todas las páginas posicionadas para esta búsqueda repiten esa afirmación de todos modos. También lo hacía una de las nuestras, hasta hoy. El 2026-08-04 leímos a mano el archivo de licencia y el historial de commits de la rama principal de ocho frameworks, más otros tres que las páginas mejor posicionadas todavía recomiendan, y luego instalamos seis y ejecutamos los mismos 10 casos en cada uno. No vendemos un framework de evaluación, así que ningún veredicto de abajo protege un producto.

Puntos Clave

• Arize Phoenix se distribuye bajo la Elastic License 2.0, que la OSI no aprueba como código abierto.
• El último commit de UpTrain a main fue el 2024-07-29. No empieces un proyecto nuevo con esta herramienta.
• pip install promptfoo instala un wrapper de terceros. El proyecto real se distribuye en npm.
• Ragas no tiene commits desde el 2026-02-24 y cambió de organización en GitHub a vibrantlabsai.

¿Qué Framework de Evaluación LLM Open Source Deberías Instalar en 2026?

Elige según tu restricción, no según el ranking. Para aserciones con forma de pytest dentro de una suite de tests existente, instala DeepEval. Para una configuración YAML y una CLI que encaje con cualquier stack de lenguaje, instala promptfoo. Para la separación más limpia entre respuestas buenas y malas que medimos, instala Opik. Los tres son Apache-2.0 o MIT.

Aquí está la auditoría. Ocho frameworks en el alcance, más otros tres que las páginas mejor posicionadas para esta búsqueda todavía recomiendan.

Las fechas corresponden al último commit en la rama principal de cada proyecto a fecha de 2026-08-04. La página del repo en GitHub muestra el último push a cualquier rama, que es posterior en dos proyectos aquí: UpTrain 2024-08-18 y Deepchecks 2025-12-28. Ningún repo está archivado.

La columna de coste de cambio es la que la gente se salta y luego lamenta. Las puntuaciones son solo números, así que moverse entre DeepEval, Ragas, Opik y phoenix-evals significa sobre todo reescribir un loop. Dejar promptfoo o Inspect AI implica reescribir un formato de configuración o de tareas sin equivalente en ningún otro sitio, y dejar Evidently implica auditar cada umbral que escribiste, porque su escala funciona al revés. Dos de los frameworks que las páginas mejor posicionadas siguen recomendando no lanzan una versión desde 2024.

¿Prefieres niveles, plataformas alojadas y un orden directo? Eso es otro trabajo, y ya lo hicimos en nuestra comparativa clasificada de herramientas de evaluación LLM, incluidas las plataformas de pago.

Los Ocho Frameworks de Evaluación LLM, Agrupados por Cómo los Instalas

La forma de instalación es con lo que tienes que convivir, así que esa es la agrupación.

Bibliotecas de Python que importas en tus tests

DeepEval (pip install deepeval, Apache-2.0) envuelve las métricas de LLM en aserciones con forma de pytest: construyes un LLMTestCase, se lo pasas a assert_test, y el test falla por debajo de tu umbral. Es lo mejor para poner una puerta de calidad junto a los tests unitarios que un equipo ya ejecuta. Elígelo si tus evals deben vivir en el mismo job de CI que todo lo demás.

Una aclaración, dicha una sola vez: DeepEval está creado por Confident AI, que es un partner de pago en otros dos posts de este sitio, incluida la comparativa clasificada a la que enlaza esta página. Aquí no recibe trato especial, y cada enlace a DeepEval en esta página apunta al repo de GitHub.

Ragas (pip install ragas, Apache-2.0) es la opción específica para RAG: evaluate() toma filas de pregunta, contexto y respuesta, y devuelve puntuaciones por métrica de forma asíncrona. Es lo mejor para medir la calidad de recuperación dentro de un pipeline de Python. Su repo se mudó de explodinggradients a vibrantlabsai, su última versión fue v0.4.3 el 2026-01-13, y no hay commits desde el 2026-02-24. Elígelo si las métricas RAG son todo el trabajo y un repo tranquilo te resulta aceptable, y consulta el stack más amplio de herramientas RAG.

Opik (pip install opik, Apache-2.0, de Comet) trae métricas que puedes llamar por su cuenta. Con OPIK_TRACK_DISABLE=true configurado, AnswerRelevance().score() funciona sin cuenta, sin servidor local y sin archivo de configuración, algo que el producto no destaca en su marketing. Es lo mejor para obtener una puntuación real en el menor número de líneas. Elígelo si quieres métricas ahora y la plataforma quizás más adelante.

Evidently (pip install evidently, Apache-2.0) trata las evals como descriptores sobre un dataset y genera un informe HTML como efecto secundario. Es lo mejor para reportes en lote sobre muchas filas en lugar de una puerta binaria. Sus puntuaciones de LLM están invertidas: 1.0 significa no fiel al contexto. Elígelo si lo que le debes a alguien es un informe compartible, no un build en rojo.

Giskard (pip install giskard, Apache-2.0) escanea un modelo en busca de vulnerabilidades en lugar de puntuar un dataset que tú escribiste. El paquete de PyPI resuelve la línea v2, y el propio README del proyecto indica que la v2 "ya no recibe mantenimiento activo". Es lo mejor para escaneos automáticos estilo red-team. Elígelo si quieres que te encuentren las vulnerabilidades en lugar de definir tú mismo métricas LLM-as-a-judge.

Herramientas de CLI y configuración que ejecutas contra un archivo YAML

promptfoo (npm install promptfoo, MIT) es una CLI que lee un archivo YAML: declaras providers, casos de test y aserciones, ejecutas npx promptfoo eval, y obtienes apto/no apto por caso más una UI de resultados local. Es lo mejor para evaluar prompts cuando tu app no está escrita en Python. Elígelo si tu puerta de calidad debe ser un archivo de configuración que un compañero que no programa en Python pueda editar.

Tipo harness y paquetes de plataforma

Inspect AI (pip install inspect-ai, MIT) viene del UK AI Safety Institute y evalúa modelos frente a tareas que defines en Python, con abstracciones reales de solver y scorer y un visor de ejecuciones. Es lo mejor para benchmarking a nivel de modelo con definiciones de tareas reproducibles. Elígelo si lo que se está probando es un modelo y no tu aplicación.

Arize Phoenix (pip install arize-phoenix-evals) te da evaluadores predefinidos como FaithfulnessEvaluator y CorrectnessEvaluator que devuelven una etiqueta binaria más una puntuación. Es lo mejor para etiquetas deterministas sobre las que bloquear sin tener que elegir un umbral. Su licencia es la razón por la que este artículo tiene un paréntesis en el título, y eso tiene su propia sección a continuación.

¿Es Arize Phoenix de Código Abierto?

No, no según la definición que mantiene la Open Source Initiative. Arize Phoenix se distribuye bajo la Elastic License 2.0 (ELv2). La línea 1 del archivo LICENSE del repo lo dice, y PyPI declara de forma independiente license: Elastic-2.0 en la v19.15.0. El código fuente se puede leer, forkear y alojar tú mismo. Un uso concreto está restringido.

La restricción que importa: ELv2 prohíbe ofrecer el software a terceros como servicio alojado o gestionado. Léelo con atención, porque afecta a mucha menos gente de lo que parece. Si instalas arize-phoenix-evals para puntuar tu propia aplicación, ELv2 nunca te afecta. Si eres una consultora o un equipo de plataforma que empaqueta Phoenix en un servicio de evaluación que vendes a clientes externos, sí te afecta. Esa es toda la diferencia, y la Open Source Definition es lo que ELv2 incumple, en concreto las cláusulas sobre restricciones de campo de uso.

Todas las páginas que hoy están posicionadas para esta búsqueda catalogan a Phoenix como "open source", y nosotros también lo hicimos. Nuestra propia comparativa clasificada de herramientas de evaluación LLM describe a Phoenix como completamente open source, lo cual es incorrecto, y se está corrigiendo. Phoenix es source-available (código disponible), no open source, y la distinción solo importa si planeas venderla como servicio. Si lo que necesitas de verdad es tracing y no scoring, eso pertenece a las plataformas de observabilidad de IA, no aquí.

¿Cuáles de Estos Todavía Reciben Mantenimiento Activo?

La mayoría. Seis de los once repos que revisamos recibieron un commit a main el 2026-08-03 o el 2026-08-04: DeepEval, promptfoo, Opik, Arize Phoenix, Inspect AI y Giskard. Dos no lanzan una versión desde 2024. Uno se ha quedado en silencio en 2026 tras un cambio de organización en GitHub.

Frameworks con los que no empezaríamos un proyecto nuevo en 2026

UpTrain está muerto. Su último commit a main llegó el 2024-07-29 y su última versión, v0.7.1, fue el 2024-05-14, lo que lo deja dos años frío en cualquiera de las dos medidas. El repo sigue ahí y sigue siendo Apache-2.0, así que nada te lo impide, pero empezar un trabajo nuevo sobre una biblioteca de evaluación abandonada es una decisión que tendrás que explicar más adelante.

Deepchecks merece la versión precisa. No ha tenido una versión desde la 0.19.1 el 2024-12-15, aunque el repo todavía recibe commits, con el último en main fechado el 2025-11-24. La gente sigue trabajando en él; nadie ha publicado una versión en más de dieciocho meses. Ni UpTrain ni Deepchecks están archivados en GitHub, y ninguno ha cerrado sus contribuciones.

Ragas recibe fechas y nada más. Última versión v0.4.3 el 2026-01-13, sin commits desde el 2026-02-24, y el repo se mudó de explodinggradients a vibrantlabsai. No encontramos ninguna explicación verificable de por qué cambió de organización, así que no vamos a inventar una. Un repo tranquilo no es uno roto: el código Apache-2.0 que hoy calcula una puntuación de fidelidad seguirá calculándola el año que viene. El riesgo son las dependencias sin parchear, que es exactamente lo que nos mordió en las pruebas de más abajo.

Otras páginas en la primera página de esta búsqueda todavía recomiendan tanto UpTrain como Deepchecks, sin ninguna fecha junto a la recomendación. Un framework sin versiones desde diciembre de 2024 es una decisión de dependencias, no una decisión de funcionalidades.

¿Necesitas un Framework de Evaluación o un Harness de Evaluación?

Un framework de evaluación de aplicaciones puntúa las salidas de tu propia app contra tus propios datos. DeepEval, Ragas, promptfoo, Opik, phoenix-evals y Evidently hacen eso. Un harness de evaluación de modelos, en cambio, hace benchmark de un modelo contra tareas públicas estandarizadas. lm-evaluation-harness e Inspect AI hacen eso. Elegir la clase equivocada es el error más caro de esta página.

El fallo típico es concreto. Alguien conecta lm-evaluation-harness para probar su chatbot RAG, recibe un conjunto de puntuaciones de MMLU, y no aprende absolutamente nada sobre si su retriever está devolviendo los pasajes correctos. Las puntuaciones son reales. Están midiendo el modelo base, que a nadie le preocupaba.

La forma de Inspect AI viene de su origen: se construyó en el UK AI Safety Institute bajo MIT para evaluar modelos de frontera, así que solvers, scorers y tareas son ciudadanos de primera clase y tu aplicación no es un concepto que maneje. Esa es una buena razón para usarlo para lo que sirve. Si tu problema son agentes en lugar de turnos únicos, evaluar agentes en producción es otra disciplina distinta, y los servidores de tool-calling tienen su propio tratamiento en nuestra guía sobre cómo evaluar servidores y herramientas MCP.

Qué Pasó Cuando Instalamos Seis de Ellos y Ejecutamos los Mismos 10 Casos

El 2026-08-04 instalamos seis de estos en venvs nuevos de Python 3.11.14 (más npm para promptfoo) y puntuamos un mismo set RAG de 10 elementos con un solo juez, openai/gpt-4o-mini a través de OpenRouter a temperatura 0. Siete elementos eran correctos. Tres estaban rotos de tres formas distintas: uno contradice su contexto, otro se inventa datos concretos, y otro es prosa fluida que nunca responde la pregunta. Cada framework se ejecutó dos veces, una tras otra.

Cinco de seis métricas de grounding detectaron los tres defectos. Los tres hallazgos de abajo son la razón de ser de esta sección.

Las métricas de relevancia no son métricas de calidad, y dos de ellas puntuaron una mentira convincente por encima de una respuesta correcta. Ragas ResponseRelevancy puntuó el elemento que afirma que HTTP 404 es un error de servidor 5xx con 0.777, por encima de dos de las siete respuestas correctas, y el elemento con límites de tasa inventados con 0.813, por encima de cuatro. promptfoo answer-relevance hizo lo mismo: 0.800 para el elemento del 404, un aprobado limpio frente a un umbral de 0.7, mientras que falló la q01 correcta con 0.679. No es un bug. Una respuesta incorrecta pero convincente aborda la pregunta a la perfección. Pero si la relevancia es el número que ves en tu dashboard, una alucinación fluida parece tu mejor resultado.

Una puerta que solo mira fidelidad se pierde la respuesta irrelevante. DeepEval puntuó el elemento que nunca responde la pregunta con 1.000 de fidelidad, un aprobado limpio, lo cual es defendible: una respuesta que no afirma nada sobre el contexto no contradice nada en él. Solo la relevancia lo detectó, con 0.000. Ese es el único fallo de grounding en la tabla de arriba. Cada métrica por separado tiene un hueco; juntas cubren ambos.

Los evaluadores binarios fueron estables a temperatura 0. Los graduados no. Phoenix y DeepEval no movieron ninguno de los diez elementos entre dos ejecuciones idénticas. Opik movió cuatro, todos en AnswerRelevance, en una rejilla de 0.05; Evidently también movió cuatro. Aquí ninguna deriva cambió un veredicto, pero la q01 correcta de promptfoo aterrizó en 0.679 y luego en 0.642 frente a un umbral de 0.700, que es la forma de una puerta de CI inestable.

Dos notas menores: tres de seis (DeepEval, Opik, Phoenix) se instalaron y se ejecutaron limpios a la primera, mientras que Ragas no se importaba hasta que fijamos langchain-community<0.4. Solo promptfoo reportó el uso de tokens del juez, 16.011 tokens de aserción en la run 1 y 16.010 en la run 2.

Los límites de esto, dichos sin rodeos. n = 10 es una prueba de humo, no un benchmark: te dice cosas sobre ergonomía y puntos ciegos, no sobre la precisión de las métricas. Un solo modelo juez puntuó todo, y un juez más grande movería todos los números, probablemente incluidos los dos falsos positivos que DeepEval y Ragas produjeron sobre el mismo elemento correcto. Dos ejecuciones demuestran que la deriva existe, pero no permiten caracterizarla. Las respuestas estaban preescritas, así que nada de esto pone a prueba la generación, el tracing o la gestión de datasets, lo que hace que los 337.9 segundos de instalación de promptfoo parezcan peores de lo que en realidad son. "Mejor" siempre significa mejor para una restricción concreta: una puerta de CI, métricas RAG o una UI cambian cada uno la respuesta, igual que la división entre evaluación offline y online.

La Misma Comprobación, Escrita de Tres Formas

La forma más rápida de elegir un tipo de interfaz es leer la misma aserción tres veces. Aquí tienes una comprobación de grounding sobre un elemento en DeepEval, Ragas y promptfoo, recortada de los scripts que realmente ejecutamos. Los nombres de las métricas difieren; enlazamos a cómo funcionan realmente las métricas LLM-as-a-judge en lugar de redefinirlas aquí.

# DeepEval 4.1.5: con forma de pytest, falla el test por debajo del umbral
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: fíjate en la ruta de import. `from ragas.metrics import Faithfulness`
# lanza ImportError en esta versión; la métrica concreta se movió.
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, luego npx promptfoo eval
providers:
  - id: echo          # puntuamos respuestas preescritas en lugar de generarlas
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."

Las líneas de instalación esconden más trampas que el propio código, y cada comentario de abajo es algo que nos costó tiempo el 2026-08-04:

# El promptfoo real se distribuye en npm. El paquete de PyPI con el mismo
# nombre es un wrapper de terceros: https://pypi.org/project/promptfoo/ vs
# https://www.npmjs.com/package/promptfoo
npm install promptfoo

# pip install giskard resuelve la línea v2, que el propio README del
# proyecto marca como sin mantenimiento activo.
pip install giskard

# lm-evaluation-harness se instala bajo el nombre de paquete lm-eval.
pip install lm-eval

# Evidently no trae openai como dependencia, y el juez falla en el momento
# de la llamada y no en el import, después de que ya hayas construido el dataset.
pip install evidently openai

# Ragas 0.4.3 no se importa correctamente contra langchain-community 0.4.x.
pip install ragas "langchain-community<0.4"

¿Puedes Hacer que un Build Falle por una Puntuación de Eval?

Sí. Todos los frameworks de esta lista devuelven una puntuación numérica o binaria, y cada uno saldrá con un código distinto de cero cuando falle una aserción de umbral, que es todo lo que GitHub Actions necesita para poner un build en rojo. Conectar el código de salida es la parte fácil. Elegir un umbral que tu modelo juez no vaya a cruzar por accidente es la parte que se lleva una semana.

Esta es la forma del workflow que ejecutamos nosotros, fijado a las versiones de nuestra prueba del 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: Puntuar el golden set
        env:
          # Fija el juez. Una actualización del modelo a mitad de trimestre mueve todas las puntuaciones.
          JUDGE_MODEL: openai/gpt-4o-mini
          # Los umbrales viven en un solo sitio, leídos por los constructores de las métricas.
          EVAL_THRESHOLD: "0.7"
          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
        run: deepeval test run tests/evals/

Dos trampas muerden antes que el umbral. Primero, las llamadas al juez son llamadas de red: nuestra ejecución de DeepEval con 10 elementos tardó 126.8 segundos porque .measure() es secuencial, y un golden set de 200 elementos por ese mismo camino es un descanso para el café en cada pull request. Todos los demás frameworks de la prueba paralelizan por defecto, que es la palanca individual más grande sobre el tiempo real de la CI.

Segundo, la inestabilidad. A temperatura 0, Opik y Evidently movieron cada uno cuatro de diez elementos entre ejecuciones consecutivas, y la respuesta correcta de promptfoo se quedó en 0.679 y luego en 0.642 frente a una puerta de 0.700. Las mitigaciones son aburridas y funcionan: ejecuta un golden dataset fijo que solo cambie por pull request, fija el modelo juez, prefiere evaluadores binarios cuando una etiqueta sea suficiente, y bloquea sobre un delta en lugar de un suelo absoluto. Ese último punto importa más en la evaluación multiturno, donde una sola conversación produce muchas puntuaciones que pueden tambalearse cada una por separado.

Para poner esto en perspectiva: la encuesta State of Agent Engineering de LangChain (1.340 respuestas, recogidas del 18 de noviembre al 2 de diciembre de 2025, publicada el 12 de junio de 2026) encontró que el 89% de las organizaciones ha implementado alguna forma de observabilidad para sus agentes, mientras que solo el 52.4% ejecuta evaluaciones offline sobre conjuntos de test. Observar es común. Bloquear no lo es.

Qué Instalaríamos Esta Semana

Cuatro cosas para llevarte. Arize Phoenix es source-available bajo la Elastic License 2.0 y no es open source aprobado por la OSI, lo cual no cambia nada para la mayoría de los lectores y lo cambia todo si revendes herramientas de evaluación. UpTrain está muerto, y hay páginas sin fecha que todavía lo recomiendan. Deepchecks tampoco ha lanzado una versión desde diciembre de 2024, aunque su repo sigue recibiendo commits. Una métrica de grounding y una métrica de relevancia tienen cada una un hueco que la otra cubre, así que bloquea sobre ambas. Y las puntuaciones graduadas derivan a temperatura 0, así que fija tu juez y da margen a los umbrales.

Si yo estuviera empezando una suite de evaluación nueva esta semana, instalaría DeepEval para la puerta de CI porque las aserciones deben vivir junto a los tests (aclaración arriba), y añadiría las métricas independientes de Opik para la separación más limpia que medimos. Si nuestro stack no fuera Python, promptfoo en su lugar, sin dudarlo. Si prefieres que alguien más conecte el golden set y el workflow, esa es una conversación que nos encanta tener.

Preguntas Frecuentes

¿Cuál es el mejor framework de evaluación LLM open source?

No hay un único ganador, solo el mejor encaje según tu restricción. Para una puerta apto/no apto dentro de una suite de tests en Python, DeepEval. Para una configuración YAML y CLI agnóstica al lenguaje, promptfoo. Para métricas de recuperación RAG, Ragas, si puedes aceptar un repo sin commits desde el 2026-02-24. Para la separación más limpia entre respuestas buenas y malas en nuestra prueba del 2026-08-04, Opik.

¿Es Arize Phoenix open source?

No según la definición de la Open Source Initiative. Arize Phoenix se distribuye bajo la Elastic License 2.0, que PyPI declara como license: Elastic-2.0 en la v19.15.0 y que la línea 1 del archivo LICENSE del repo indica directamente. Es source-available: puedes leerlo, forkearlo, modificarlo y alojarlo tú mismo. La única restricción es ofrecer el software a terceros como servicio alojado o gestionado.

¿Sigue teniendo mantenimiento Ragas?

Los hechos verificables, a fecha de 2026-08-04: la última versión fue v0.4.3 el 2026-01-13, no ha habido commits desde el 2026-02-24, y el repositorio se mudó de la organización explodinggradients a vibrantlabsai. El repo no está archivado. No encontramos una explicación pública fiable del cambio de organización y no vamos a especular con una. El código Apache-2.0 sigue funcionando; el riesgo son las dependencias sin parchear.

¿Necesito un framework de evaluación o una plataforma de observabilidad?

Los dos, con el tiempo, pero responden preguntas distintas. Un framework de evaluación te dice si un cambio mejoró o empeoró tus salidas antes de que lo publiques, sobre un dataset que tú controlas. Una plataforma de observabilidad te dice qué pasó de verdad en producción después de publicar. Empieza por el framework de evaluación si tienes un pipeline de CI; consulta plataformas de observabilidad de IA para el lado de producción.

¿Puedo ejecutar evals de LLM en CI/CD?

Sí. Todos los frameworks de este artículo salen con código distinto de cero cuando falla una aserción de umbral, que es todo lo que necesita un job de GitHub Actions. Las restricciones prácticas son el tiempo real (las llamadas al juez son llamadas de red, y nuestra ejecución secuencial de DeepEval tardó 126.8 segundos para 10 elementos) y el no determinismo del juez. La forma del workflow y las mitigaciones están en la sección de CI de arriba.

¿Cuál es la diferencia entre DeepEval y Ragas?

Forma de interfaz y alcance, no calidad. DeepEval tiene forma de pytest y es de propósito general: escribes casos de test y afirmas sobre umbrales de métricas, y cubre salidas de aplicación de muchos tipos. Ragas es una biblioteca específica para RAG cuyo evaluate() se ejecuta de forma asíncrona sobre un dataset de filas de pregunta, contexto y respuesta. DeepEval encaja de forma más natural en una puerta de CI; Ragas profundiza más en la recuperación.

¿Por qué pip install promptfoo me instala el paquete equivocado?

Porque promptfoo es un proyecto de Node. El proyecto real se publica en npm bajo MIT y se instala con npm install promptfoo. El paquete de PyPI con el mismo nombre es un wrapper de terceros, no el proyecto original, e instalarlo es una forma habitual de acabar depurando una CLI que no es la que describe la documentación.

¿Es lm-evaluation-harness un framework de evaluación LLM?

Es un harness de evaluación de modelos, un trabajo relacionado pero distinto. lm-evaluation-harness (instalado como pip install lm-eval) hace benchmark de un modelo contra tareas públicas estandarizadas como MMLU. No te va a decir si tu pipeline de recuperación devolvió el pasaje correcto, porque tu aplicación no es un concepto que maneje. Consulta la sección de framework frente a harness de arriba para ver la diferencia.

¿Son gratuitos estos frameworks?

En cuanto a la licencia, sí. DeepEval, Ragas, Opik, Evidently y Giskard son Apache-2.0; promptfoo, Inspect AI y lm-evaluation-harness son MIT. Ambas licencias permiten el uso comercial, la modificación y la redistribución. Arize Phoenix es la excepción: la Elastic License 2.0 permite alojarlo tú mismo pero no ofrecer el software a terceros como servicio gestionado. El uso de la API del modelo juez se factura aparte, por tu proveedor.