Capítulo 5 — Evaluar aplicaciones LLM

Quinta entrega del recorrido capítulo por capítulo de LLM Primer V: Building Real-World LLM Applications. El capítulo que asume que assertEqual está muerto para las salidas de un LLM y reconstruye la disciplina de testing alrededor de jueces anclados, el RAG Triad y los tests de trayectoria.

Por qué existe este capítulo

El testing clásico de software se apoya en el supuesto de que una salida correcta es una salida específica — la función devuelve 42, la cadena es igual a "Hello, world", el JSON coincide con el fixture. Los sistemas LLM producen paráfrasis equivalentes en significado y distintas carácter a carácter, y la aserción de coincidencia exacta que ha anclado el testing de software durante cincuenta años colapsa en la primera regeneración. Entonces los equipos recurren a BLEU, ROUGE o similitud coseno de embeddings y descubren que esas métricas correlacionan mal con el juicio humano sobre lo que importa — si la respuesta es correcta, si está fundamentada, si aborda la pregunta. El Capítulo 5 reconstruye la disciplina de testing alrededor de lo que sí funciona: rúbricas ancladas de LLM-as-a-judge, el RAG Triad, tests de trayectoria de agente y un bucle continuo donde las trazas de producción alimentan el conjunto de evaluación que da paso a la siguiente release.

5.1 La brecha de evaluación y LLM-as-a-judge

La brecha de evaluación es la distancia entre lo que un test clásico puede medir y lo que la salida de un LLM realmente necesita que se mida. Las métricas de coincidencia exacta y de cadena de referencia no capturan ninguno de los fallos interesantes en tareas con mucha paráfrasis. LLM-as-a-judge es el caballo de tiro que cierra la brecha, con dos disciplinas que lo separan de un truco de fiesta. Primera, la rúbrica del juez está anclada: cada valor de puntuación tiene una definición escrita, idealmente con un ejemplo, para que el juez no vaya asociando un número por libre. Segunda, el juez produce su razonamiento antes de la puntuación, porque un juez que tiene que escribir su razonamiento es un juez que puntúa de forma más consistente. Las comprobaciones programáticas complementan al juez en lo que es deterministamente verificable — el JSON parsea, los campos requeridos están, no hay cadenas prohibidas, la longitud de la respuesta cae dentro del rango. El juez no es universal; es lo que cubre el terreno que las comprobaciones deterministas no alcanzan.

5.2 El RAG Triad — contexto, fundamentación, relevancia de respuesta

Para sistemas de recuperación, el patrón que ha cristalizado es puntuar tres vértices de forma independiente. La relevancia de contexto pregunta si los chunks recuperados son realmente relevantes para la consulta, y aísla los fallos de recuperación de los fallos de generación. La fundamentación pregunta si la respuesta generada se sigue del contexto recuperado, y atrapa alucinaciones que pasan la validación de forma. La relevancia de respuesta pregunta si la respuesta aborda la pregunta que el usuario realmente hizo. Puntuados de forma independiente, los tres vértices localizan los fallos: una puntuación baja de relevancia de contexto apunta a recuperación, una puntuación baja de fundamentación apunta al generador, una puntuación baja de relevancia de respuesta apunta al router o a un sistema que responde a una pregunta adyacente. RAGAS operacionaliza el triad como un pipeline por lotes; la calidad del modelo juez domina la calidad de las puntuaciones, así que el propio juez es un componente que el equipo evalúa.

5.3 Nichos de frameworks y regresión de agentes

Tres frameworks ocupan nichos distintos. RAGAS ejecuta el RAG Triad por lotes contra un dataset de pares pregunta-respuesta y es la herramienta correcta para la evaluación periódica de dataset. TruLens conecta funciones de feedback al tráfico de producción en vivo y computa el triad sobre las propias trazas, cerrando el bucle entre producción y evaluación. DeepEval ejecuta tests LLM como gates de CI del mismo modo que pytest ejecuta tests unitarios, con umbrales por métrica. Los agentes extienden todo esto en tres direcciones: los tests de snapshot de trayectoria aseveran la forma de la secuencia de llamadas a herramientas para una entrada fija, atrapando la deriva estructural; las aserciones de invariante verifican que el agente no llamó a una herramienta prohibida ni saltó una aprobación requerida; los tests de rúbrica puntúan la propia trayectoria por si el camino fue razonable. Un agente que da la respuesta correcta por el camino equivocado está a un cambio de prompt de dar la respuesta equivocada por el mismo camino, y el test de trayectoria es la disciplina que lo atrapa.

Lo que prepara el Capítulo 5

Las evaluaciones necesitan trazas de producción de las que muestrear. Los gates de CI necesitan regresiones reales contra las que resguardar. El bucle de mejora continua solo funciona si hay una capa de observabilidad capturando cada paso de cada invocación — las llamadas al modelo, las llamadas a herramientas, los resultados de recuperación, los saltos entre sub-agentes, el coste, la latencia, el feedback del usuario. El Capítulo 6 es esa capa. Recorre OpenTelemetry con las convenciones semánticas GenAI, las métricas que realmente importan para sistemas LLM, las elecciones de plataforma y — lo más importante — el pipeline de exportación que enruta las trazas de baja puntuación de vuelta al conjunto de evaluación que da paso a la siguiente release.

Próximamente — Capítulo 6: Observabilidad y trazado en IA. El sustrato que hace posibles la evaluación y la depuración — una traza anidada por invocación, con coste y calidad como atributos de primera clase.