Qué da por sabido
esta serie
Esta serie lee el código fuente de siete herramientas de código abierto que usan un LLM para puntuar a otro. Da por hecho que has llevado software a producción y que has llamado a la API de un modelo, pero no que hoy hagas evaluaciones ni que hayas usado ninguna de estas herramientas.
Lo que
da por sabido
Ingeniería, sin estadística.
Si sabes leer Python y alguna vez has discutido qué significa un test inestable, tienes lo necesario.
- Saber leer Python. Basta con leer el código real que citan las partes, con fichero y línea.
- Haber llamado a la API de un modelo. Saber que entra un prompt y sale texto, y que el mismo prompt, lanzado dos veces, no devuelve el mismo texto.
- Para qué sirve una batería de tests. Por qué una puerta puede parar el pipeline y cuánto cuesta que se equivoque en un sentido o en el otro.
- Que la varianza es una propiedad del sistema. No se arregla abriendo un bug. La estadística formal no hace falta: si aparece un intervalo de confianza, se construye en la parte que lo necesita.
De esa última trata la serie entera. Todas estas herramientas pelean contra lo mismo (un juez cuya puntuación varía sin que haya cambiado nada más) y, curiosamente, cada una lo resuelve a su manera.
Lo que
no da por sabido
No es un tutorial de herramientas.
No hace falta haber usado Ragas, DeepEval, TruLens ni ARES, ni tener un pipeline de RAG en producción. Tampoco hacen falta nociones de concordancia entre evaluadores ni de Prediction-Powered Inference: la parte 4 construye lo que necesita.
La serie tampoco es una tabla comparativa que te diga qué herramienta adoptar. Lee el código para sacar a la luz la estrategia que implementa cada una, porque las estrategias sobreviven a las herramientas y las tablas caducan en un trimestre.
Como las versiones cambian, cada afirmación indica el fichero y la línea de donde sale, para que compruebes si sigue valiendo en la versión que usas.
Si te
falta algo
Las herramientas, antes que los posts sobre ellas.
Son los cuatro repositorios en los que más se detiene la serie, y el artículo con el que empezó la práctica. Ninguno es mío.
- Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena La referencia que popularizó la práctica y la primera que comparó un juez LLM con evaluadores humanos. Si solo lees una cosa de esta lista, que sea esta.
- Ragas Parte 2. La estrategia del veredicto binario, que descompone un juicio en preguntas atómicas de sí o no.
- DeepEval Partes 3 y 4. La evaluación como recorrido de un grafo y las puntuaciones ponderadas por las probabilidades de los tokens.
- TruLens Parte 5. La rúbrica negativa: decirle al juez, de forma explícita, qué queda fuera de su alcance.
- ARES Parte 4. Prediction-Powered Inference, para acompañar el veredicto de un juez con un intervalo de confianza.
Cómo
leerla
El argumento se va construyendo.
Primero la parte 1, luego en cualquier orden. La 1 fija los cuatro ejes de varianza a los que vuelve una y otra vez el resto de la serie. De la 2 a la 6, cada parte cuenta una estrategia y se sostiene sola.
Todo apunta a la parte 7. Las seis primeras muestran lo que hacen las herramientas y la última, lo que no hace ninguna. Si solo tienes tiempo para dos, lee la 1 y la 7.
Cada afirmación cita el código. Remite siempre al fichero y la línea, nunca a la documentación. Cuando una herramienta dice una cosa y hace otra, la serie lo señala y enseña la línea.