Ragas, ARES y LangSmith: herramientas de evaluación

Cuarta entrega del bloque de evaluación. Las dos anteriores dejaron las métricas definidas; esta mira quién las implementa por ti. Tres herramientas que suelen citarse juntas y que en realidad resuelven problemas distintos, hasta el punto de que combinarlas es más común que elegir entre ellas.

Antes de elegir herramienta: qué parte del problema quieres resolver

Evaluar un RAG en serio son cuatro tareas separadas, y ninguna herramienta las cubre todas bien:

1. Calcular métricas sobre un conjunto de casos: fidelidad, relevancia, recall, precisión del contexto.
2. Registrar trazas de lo que pasó en cada consulta: qué se recuperó, con qué puntuación, qué prompt se construyó, qué respondió el modelo, cuánto tardó y cuánto costó.
3. Gestionar conjuntos de datos: mantener las preguntas de evaluación, sus anotaciones y sus versiones, y añadir casos nuevos cuando aparecen fallos en producción.
4. Decidir con confianza: saber si la diferencia entre dos versiones es real o es ruido, sin anotar mil ejemplos a mano.

Ragas ataca sobre todo la primera. LangSmith, la segunda y la tercera. ARES, la cuarta. Esa es, en una línea, toda la comparativa; el resto de la entrega la desarrolla.

Ragas: la biblioteca de métricas

Ragas es una biblioteca de Python que implementa el catálogo de métricas de la capa de generación y parte de la de recuperación. Le pasas, por cada caso, la pregunta, los fragmentos recuperados, la respuesta generada y —para algunas métricas— una respuesta de referencia, y te devuelve las puntuaciones.

Su rasgo distintivo es que buena parte de sus métricas son sin referencia: no necesitan que alguien haya escrito la respuesta correcta. La fidelidad se calcula descomponiendo la respuesta en afirmaciones y verificándolas contra el contexto recuperado, exactamente el procedimiento de la entrega anterior; la relevancia de la respuesta se calcula retro-generando preguntas. Ambas cosas se hacen con un modelo de lenguaje que tú configuras, junto con un modelo de embeddings para las comparaciones semánticas.

Eso es lo que explica su adopción: permite empezar a medir el mismo día, con un corpus sin anotar y sin haber montado un golden dataset. Es, sin ninguna duda, la vía más rápida para pasar de «creo que va bien» a un número.

Sus límites vienen del mismo sitio. Al no haber referencia, las métricas heredan íntegros los sesgos y la varianza del juez, y la propia herramienta no te dice si su juez está calibrado con tu criterio: eso lo tienes que comprobar tú. Las métricas que sí necesitan anotación —el recall del contexto, sobre todo— siguen exigiendo el trabajo humano que la herramienta parecía haberte ahorrado. Y las cifras que produce son comparables consigo mismas, no con las que publique otro proyecto.

Ragas incluye además generación sintética de conjuntos de prueba a partir de tus documentos. Es útil para arrancar y para cubrir volumen, con una advertencia que conviene tomarse en serio: las preguntas generadas a partir de un fragmento se responden recuperando ese fragmento, lo que sesga la evaluación hacia el optimismo y no se parece a cómo pregunta la gente. Sirve como suelo, no como sustituto de preguntas reales.

ARES: jueces entrenados y estimación estadística

ARES aborda un problema distinto: cómo obtener una estimación fiable del rendimiento sin anotar a mano cientos de ejemplos, y cómo saber cuánta confianza merece esa estimación.

Su planteamiento tiene tres piezas. Primero, genera datos sintéticos de entrenamiento a partir de tu propio corpus: pares de pregunta y pasaje, positivos y negativos. Segundo, con esos datos afina modelos ligeros que actúan de clasificadores para las dimensiones clásicas —relevancia del contexto, fidelidad de la respuesta, relevancia de la respuesta—. Un clasificador pequeño y especializado sale mucho más barato de ejecutar que un modelo grande haciendo de juez, y es determinista en la práctica.

Tercero, y es lo que lo diferencia de verdad: usa un conjunto reducido de ejemplos anotados por humanos para corregir el sesgo de sus propios jueces y producir intervalos de confianza sobre la puntuación estimada. La técnica que emplea para eso es la inferencia potenciada por predicciones (prediction-powered inference), que combina las predicciones abundantes del clasificador con las pocas etiquetas humanas para dar un estimador con garantías estadísticas.

La consecuencia práctica es la que importa: en lugar de «tu sistema tiene 0,81 de fidelidad», obtienes un rango, y con un rango puedes decidir si la diferencia entre dos configuraciones es real o no lo es. Es exactamente el problema que dejó abierto la entrega anterior al hablar de varianza.

El precio es la complejidad. Hay que generar datos, entrenar clasificadores, mantener un pequeño conjunto anotado y volver a hacerlo cuando el dominio cambia. Es una herramienta de proyecto con recorrido y con exigencias de rigor, no de prototipo de dos semanas. Nació además en el ámbito académico, con lo que eso implica en documentación y en soporte comparado con productos comerciales.

LangSmith: trazas, conjuntos de datos y evaluación continua

LangSmith no es principalmente una biblioteca de métricas: es una plataforma de observabilidad y experimentación para aplicaciones con modelos de lenguaje, desarrollada por el equipo de LangChain aunque utilizable sin él.

Lo que aporta y las otras dos no:

• Trazas completas de cada ejecución, con el árbol de llamadas: la consulta reescrita, los fragmentos recuperados con su puntuación, el prompt final literal, la respuesta, los tokens y la latencia de cada paso. Cuando una respuesta sale mal, esto es lo que permite saber en qué capa se rompió sin reproducir nada a mano.
• Conjuntos de datos versionados alojados en la plataforma, con la capacidad de convertir cualquier traza de producción en un caso de prueba con un clic. Es el mecanismo que hace que el golden dataset crezca solo a partir de los fallos reales.
• Colas de anotación para que personas revisen y etiqueten casos con una interfaz decente, en lugar de una hoja de cálculo compartida.
• Ejecución de experimentos: lanzar una versión del sistema contra un conjunto, guardar los resultados y compararlos con ejecuciones anteriores caso a caso, no sólo en el promedio.

Sus evaluadores admiten tanto funciones propias escritas en código como jueces basados en modelo, y nada impide usar Ragas como evaluador dentro de un experimento de LangSmith. Esa combinación —Ragas para las métricas, LangSmith para las trazas, los conjuntos y el historial— es probablemente el montaje más frecuente.

Las contrapartidas son las de cualquier plataforma: precios por volumen de trazas, privacidad (tus prompts, tus fragmentos y tus respuestas salen de tu infraestructura salvo que despliegues la opción autoalojada) y dependencia de proveedor.

Comparativa por uso

Integración en integración continua

El objetivo no es tener un panel bonito: es que un cambio que empeora la calidad no llegue a producción. Un montaje razonable, y viable en casi cualquier proyecto, se organiza en tres niveles por coste.

Nivel 1, en cada commit. Sólo métricas de recuperación sobre el golden dataset completo. No llaman al modelo generador, tardan segundos y son deterministas. Se fija un umbral por métrica —recall@10 no puede bajar del valor de la rama principal menos un margen— y la comprobación falla si se cruza. Aquí se cazan los estropicios más comunes: un cambio de troceado, un filtro de metadatos mal escrito, otro modelo de embeddings.

Nivel 2, en cada solicitud de cambio. Métricas de generación sobre un subconjunto de veinte a treinta preguntas, incluidos los casos difíciles y los casos sin respuesta. Cuesta dinero y minutos, así que va en la revisión. Lo relevante del informe no es la media, sino la lista de casos que cambiaron de veredicto respecto de la rama principal.

Nivel 3, programado. Conjunto completo, todas las métricas, una vez al día o antes de cada despliegue, con el resultado archivado para mirar la serie histórica. Es lo que detecta las degradaciones lentas: un corpus que crece y diluye el índice, un proveedor que actualiza su modelo sin avisar, una deriva en el tipo de preguntas que llegan.

Tres reglas que evitan la mayoría de los disgustos: fija la versión exacta del modelo juez y trátala como una dependencia más; guarda el prompt de evaluación en el repositorio y versiónalo con el código, porque cambiarlo invalida toda comparación anterior; y no pongas umbrales absolutos («fidelidad > 0,9») sino relativos a la rama principal, porque los absolutos o no fallan nunca o fallan siempre y en ambos casos acaban desactivados.

Qué queda inevitablemente en manos humanas

Ninguna de las tres herramientas hace estas cuatro cosas, y ninguna futura las hará:

• Decidir qué es una buena respuesta en tu dominio. Si un asistente jurídico debe citar el artículo o basta con parafrasearlo es una decisión de producto que se codifica en la rúbrica de evaluación. La herramienta aplica la rúbrica; no la escribe.
• Calibrar el juez. Comprobar que el modelo evaluador coincide con el criterio humano exige etiquetar a mano unas decenas de casos y medir el acuerdo. Es la única forma de saber si tus números significan algo.
• Construir el conjunto de preguntas real. Las preguntas sintéticas cubren volumen; las preguntas que la gente hace de verdad, con sus faltas de ortografía, sus siglas internas y sus supuestos implícitos, sólo salen de registros y de personas.
• Leer respuestas. Veinte casos revisados a mano cada semana descubren modos de fallo que ninguna métrica agregada muestra, porque los promedios existen precisamente para ocultar la cola.

Conviene decirlo sin rodeos: instalar Ragas es una tarde de trabajo y montar un panel de LangSmith es otra. El trabajo de verdad —el conjunto de preguntas anotado— no lo ahorra ninguna herramienta, y es justamente el que casi todos los proyectos se saltan.

Qué viene ahora

La siguiente entrega cierra el bloque con ese trabajo pendiente: cómo se construye un golden dataset de cincuenta a doscientas preguntas con respuesta verificada y fragmento de origen anotado. De dónde salen las preguntas, cómo se anotan, cómo se cubren los casos difíciles y los que no tienen respuesta, cómo se mantiene cuando el corpus cambia y cómo se convierte en la prueba de regresión que protege el proyecto entero.

Los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.