Ragas: evaluar tu RAG local con chiffres

#¿Por qué «tiene buena pinta» no es suficiente?

Ragas es una biblioteca Python de código abierto, bajo licencia Apache 2.0, que asigna valores a la calidad de una cadena de búsqueda documental: la fidelidad de la respuesta con respecto a los pasajes proporcionados, su pertinencia respecto a la pregunta, la precisión y el recall del contexto recuperado. Así, separa el error de la búsqueda del error del modelo. Puede funcionar con un juez local, servido mediante Ollama, siempre que este modelo respete el formato de salida estructurado que le impone Ragas y que su contexto incluya toda la pregunta, los pasajes y la respuesta. Antes de adoptarla, recuerda tres puntos: sus puntuaciones sirven para comparar dos versiones del mismo sistema, no para evaluar una calidad absoluta; el conjunto de pruebas es más importante que la biblioteca; y los tutoriales en línea mezclan la antigua y la nueva API.

Cuando una respuesta es incorrecta, dos causas muy distintas se esconden detrás del mismo síntoma: o bien los pasajes recuperados no contenían la información, o bien la contenían y el modelo no respondió a lo que se le preguntaba. La corrección no es la misma: segmentación y embeddings en el primer caso, modelo y prompt en el segundo. Sin mediciones, se corrige al azar, y una mejora en tres preguntas empeora otras cinco sin que se note.

El otro escollo es la comparación. La pregunta «¿Es realmente mejor aquí el modelo de 27 mil millones de parámetros?» se resuelve volviendo a ejecutar el mismo conjunto de preguntas, no debatiendo. Eso es lo que permite una evaluación reproducible. Ragas supera las 15.000 estrellas en GitHub. La última versión publicada en PyPI es la 0.4.3, del 13 de enero de 2026, y el repositorio ha cambiado de organización en GitHub (vibrantlabsai). Fija la versión que utilizas.

#Las cuatro mediciones que cuentan

La documentación de Ragas especifica que la pertinencia de la respuesta no juzga la exactitud: mide solo la adecuación a la pregunta y penaliza las respuestas incompletas o llenas de detalles innecesarios. Por eso no reemplaza la fidelidad. Interpretar estas cifras conjuntamente es lo que las hace útiles. Un recall bajo con una fidelidad alta describe un sistema honesto pero mal alimentado: hay que trabajar la recuperación. Una fidelidad baja con un buen recall describe lo contrario: la información estaba disponible, el modelo añadió contenido inventado. Ambos problemas se corrigen en puntos opuestos de la cadena.

#Construir un conjunto de pruebas

Es la parte que requiere trabajo y no se puede automatizar sin consecuencias. Un conjunto útil contiene preguntas realmente planteadas por los usuarios, con sus formulaciones torpes, sus abreviaturas propias y sus errores tipográficos, no preguntas reformuladas de manera pulida por la persona que escribió la documentación.

1. 01
   Partir de preguntas reales

   Treinta a cincuenta preguntas basadas en el uso real valen más que doscientas preguntas inventadas. Incluye las que fallaron: son las más instructivas.
2. 02
   Escribir la respuesta de referencia

   Para cada pregunta, la respuesta correcta, redactada en una o dos frases. Ragas la utiliza para estimar la exhaustividad del contexto (recall): la versión basada en un LLM toma esta referencia como sustituto de los pasajes esperados, lo que evita anotar los pasajes uno a uno.
3. 03
   Mantener los casos sin respuesta

   Preguntas a las que el corpus no responde. Un buen sistema debe indicarlo; sin estos casos, nunca se mide esa cualidad.
4. 04
   Fijar el conjunto de datos

   No debe evolucionar al mismo tiempo que el sistema; de lo contrario, no será posible comparar los resultados a lo largo del tiempo.

Ragas también ofrece generación asistida de conjuntos de pruebas sintéticos a partir del propio corpus: la documentación distingue entre preguntas de un salto (una sola fuente) y preguntas de varios saltos (varias fuentes que hay que relacionar), específicas o abstractas. Una guía oficial muestra cómo adaptarla a un corpus en un idioma distinto del inglés, utilizando el español como ejemplo, para iniciar una primera evaluación antes de que las preguntas reales de los usuarios hayan tenido tiempo de acumularse. Es un punto de partida práctico, nunca un sustituto: un conjunto completamente sintético no recoge las formulaciones torpes ni los errores tipográficos que, precisamente, revelan las debilidades reales de una búsqueda documental.

#Hacer todo funcionar localmente

Ragas se basa en dos modelos para evaluar: un modelo juez que lee la pregunta, los pasajes y la respuesta, y un modelo de embeddings para las medidas de similitud. La guía de inicio rápido de Ragas utiliza OpenAI por defecto, pero muestra la variante con Ollama: un cliente compatible con OpenAI dirigido a http://localhost:11434/v1 y pasado a la función llm_factory. Solo la relevancia de la respuesta requiere un modelo de embeddings: la fidelidad, la precisión del contexto y la exhaustividad del contexto solo utilizan el juez.

Dos condiciones para que el juez local sea creíble. La primera es la salida estructurada: las métricas actuales exigen al juez decisiones intermedias en un formato obligatorio (extracción de afirmaciones, veredictos). Un modelo local puede responder en prosa e incumplir este requisito, lo que genera errores de JSON o puntuaciones vacías (NaN); una guía de OneUptime recomienda probar al juez con una llamada mínima antes de cualquier campaña. Ninguna fuente oficial establece un tamaño mínimo de modelo: debes comprobarlo tú. La segunda es el contexto: Ollama aplica por defecto 4 000 tokens de contexto cuando hay menos de 24 GiB de VRAM, y la documentación recomienda aumentar el valor (variable OLLAMA_CONTEXT_LENGTH) para tareas exigentes. Un juez cuyo contexto se desborda evalúa en realidad un texto truncado.

• Construir la cadena RAG que evaluarás
• Elegir un modelo de embedding para el francés
• Añadir un reranker cuando la precisión del contexto es baja
• Langfuse: rastrear y almacenar las puntuaciones obtenidas

# pip install ragas openai
from openai import AsyncOpenAI
from ragas.llms import llm_factory
from ragas.metrics.collections import Faithfulness, ContextRecall

# Client compatible OpenAI pointé sur Ollama (la clé est un simple libellé)
client = AsyncOpenAI(api_key="ollama", base_url="http://localhost:11434/v1")
juge = llm_factory("mistral", provider="openai", client=client)  # nom du modèle tiré avec ollama pull

fidelite = Faithfulness(llm=juge)
resultat = fidelite.score(
    user_input="Où se trouve la tour Eiffel ?",
    response="La tour Eiffel se trouve à Paris.",
    retrieved_contexts=["La tour Eiffel est située à Paris, en France."],
)
print(resultat.value)  # entre 0 et 1

#Leer los resultados sin equivocarse

Son indicadores, no calificaciones

Una fidelidad de 0,82 no significa «82 % de respuestas correctas». Este número sirve para comparar dos versiones del mismo sistema, no para certificar una calidad absoluta.

El juez tiene sesgos

El artículo de referencia sobre los jueces LLM (arXiv 2306.05685) describe sesgos de posición, de verbosidad y de preferencia por sí mismos. Mantén el mismo juez de una campaña a otra; de lo contrario, las diferencias miden al juez y no al sistema.

Una sola campaña no demuestra nada

La generación es variable. En un conjunto de pruebas pequeño, una diferencia de unas pocas centésimas puede deberse al ruido.

Lee algunos casos de forma manual

Los números indican dónde mirar; no indican qué está mal. Los diez peores casos de una campaña enseñan más que el promedio general.

#Casos de uso concretos

Elegir un tamaño de fragmento

Volver a ejecutar el mismo conjunto de pruebas con fragmentos de 256, 512 y después 1024 tokens proporciona un valor de exhaustividad (recall) para cada configuración, en lugar de una preferencia no verificada.

Validar un cambio de modelo de embedding

Un nuevo modelo de embedding, incluso si se anuncia como mejor en un benchmark general, puede reducir la precisión del contexto en tu corpus específico; solo una serie de pruebas locales permite comprobarlo.

Justificar el añadido de un reranker

Comparar la precisión del contexto antes y después del reranking cuantifica una mejora que, de lo contrario, se queda en una impresión compartida en una reunión.

Hacer un seguimiento de una regresión tras actualizar el corpus

El añadido de nuevos documentos puede diluir la búsqueda; reproducir el juego de prueba fijo tras cada importación detecta la degradación antes de que un usuario la señale.

Elegir entre dos proveedores o arquitecturas

Ante dos propuestas competidoras para construir una misma cadena documental, una puntuación obtenida con el mismo conjunto de pruebas y el mismo corpus permite decidir más rápido que una demostración comercial.

#Organizar campañas

Frecuencia de las campañas

Después de cada cambio de segmentación, de modelo de embedding o de modelo de generación. No es necesaria una campaña diaria en un sistema estable.

Tamaño del corpus de prueba

El conjunto de preguntas sigue siendo pequeño; lo que debe ser una copia realista —o la totalidad— del corpus de producción es el corpus documental evaluado.

Costo real de una campaña

Cada métrica llama al juez varias veces (para la fidelidad: extracción de afirmaciones, luego verificación de cada una). El costo aumenta así con el número de preguntas multiplicado por el número de métricas: cronometra cinco preguntas antes de lanzar las cincuenta, luego planifica la campaña en consecuencia.

#Los límites del método

Evaluar con un modelo equivale a pedir a una inteligencia artificial que juzgue a otra inteligencia artificial: el método es útil, económico e imperfecto. Detecta regresiones y clasifica variantes; no sustituye la revisión humana en un ámbito donde hay mucho en juego y un error factual conlleva responsabilidad. Por último, cada campaña consume tiempo de cálculo: en una máquina que también atiende a los usuarios, se ejecuta cuando la carga es baja, de noche o un fin de semana, en lugar de en pleno horario de uso.

El sesgo de verbosidad merece un comentario adicional, porque es contraintuitivo. Un artículo de OneUptime explica que, en una respuesta larga, un juez tiene más oportunidades de citar las palabras clave de la rúbrica, parecer exhaustivo y ofrecer una justificación convincente. Un prompt que incita al modelo evaluado a extenderse más puede, por tanto, aumentar una puntuación sin mejorar la respuesta que recibe el usuario. En cuanto a la fidelidad, la documentación de Ragas menciona también una variante basada en HHEM-2.1-Open, un pequeño clasificador gratuito de Vectara para detectar alucinaciones: sustituye la etapa de verificación por un modelo especializado, que puedes probar si tu juez local es inestable.

La solución más sencilla es metodológica: nunca comparar una puntuación de fidelidad obtenida con un juez con una puntuación obtenida con otro juez, ni con una puntuación publicada por un tercero. La cifra solo tiene sentido dentro de una misma configuración de medición: mismo juez, mismo prompt de evaluación y misma versión de las métricas. Es una herramienta de comparación interna, no una clasificación universal.

• Fuente: repositorio oficial de Ragas en GitHub
• Fuente: sesgo de verbosidad de los jueces automáticos
• Fuente: documentación oficial de la métrica de fidelidad
• Fuente: guía de inicio rápido de Ragas, variante para Ollama
• Fuente: longitud de contexto predeterminada de Ollama
• Fuente: evaluar un RAG con un juez local que produce JSON inválido
• Fuente: artículo de referencia sobre los jueces LLM

#FAQ