Evaluación automática vs LLM as a Judge

Resumen

Evaluar un agente de IA es la única forma de saber si realmente cumple con los objetivos de tu producto. Aquí verás cómo medir su desempeño con datos cualitativos y cuantitativos usando dos enfoques: evaluación automática y LLM as a Judge, dos técnicas clave para alinear tus respuestas con lo que esperas del agente.

¿Por qué es difícil evaluar la respuesta de un agente de IA?

Los agentes son sistemas estocásticos: la salida no es predecible. Una vez te dirá "Claro, el precio del producto es 100 dólares" y otra vez "Seguro, el precio del producto es 100 dólares". Cambia una palabra y tu evaluación basada en strings se rompe.

Imagina que quieres que tu agente sea más amigable, que use emojis y que recomiende alternativas cuando un producto no existe. No basta con que entregue datos correctos: necesitas que se comporte de cierta forma. Y ahí es donde la evaluación tradicional falla.

¿Qué es un sistema estocástico en agentes de IA? Es un sistema cuya salida varía aunque la entrada sea la misma. Por eso no puedes evaluar un agente comparando texto exacto, necesitas métricas más flexibles.

¿Cómo funciona la evaluación automática de un agente?

La evaluación automática usa un algoritmo determinista: mismo input, mismo output. Si quieres validar que la respuesta contenga un emoji, escribes una función simple en Python que recorre el string y devuelve true o false.

Este tipo de evaluación funciona muy bien cuando:

  • Buscas elementos concretos como emojis, palabras clave o formato.
  • El criterio se puede expresar como una regla lógica.
  • Necesitas resultados consistentes y rápidos de calcular.

En el caso del agente que estamos construyendo, esta función se llamará contains_emoji y verificará que la respuesta tenga cierta cantidad de emojis [02:50]. Es directa, barata y confiable para criterios objetivos.

¿Qué es LLM as a Judge y cuándo usarlo?

Cuando quieres evaluar cosas que no se pueden codificar como reglas, como la amabilidad, la efusividad o la voluntad del agente de recomendar alternativas, necesitas otro enfoque. Codificar comportamiento estocástico en un sistema determinista sería muy complicado.

Ahí entra LLM as a Judge: usas un modelo externo, más simple, dedicado únicamente a evaluar qué tan bien cumplió el agente principal con su objetivo. Le preguntas al modelo juez si la respuesta fue amable, si sugirió alternativas, si tuvo el tono correcto.

¿Qué es LLM as a Judge? Es una técnica donde un modelo de lenguaje evalúa las respuestas de otro modelo basándose en criterios cualitativos como tono, claridad o utilidad. Sirve para medir lo que un algoritmo determinista no puede.

La evaluación que mide esto se llamará kindness y se enfoca en la efusividad, amabilidad y disposición de sugerir otros productos cuando no existe el solicitado [03:30].

¿Cómo se implementa la evaluación en la práctica?

El flujo parte del agente ya construido, con sus archivos main.py, pipeline.py y store agents. A partir de ahí, creas un clon del agente que llamarás target.

El target emula el comportamiento del agente original con funciones limitadas, porque probablemente no necesites usarlas todas para evaluarlo. Lo importante es que lo someterás al dataset completo de preguntas que ya construiste.

Los pasos clave son:

  1. Tomar el agente principal y crear el clon target.
  2. Someter al target al dataset de preguntas previamente armado.
  3. Recolectar las respuestas que entrega el target.
  4. Aplicar las dos evaluaciones: contains_emoji (automática) y kindness (LLM as a Judge).
  5. Ejecutar todo con client.evaluate de LangSmith [04:15].

Después de la primera corrida es normal que los resultados sean bajos en ambas métricas. La idea es ir afinando el system prompt iterativamente. A veces los resultados subirán y otras veces bajarán, porque el system prompt también es un sistema complejo donde un cambio puede mejorar una métrica y empeorar otra.

¿Por qué medir es la única forma de mejorar un agente?

Lo que no se mide no se puede mejorar. Sin estas evaluaciones, estarías ajustando el system prompt a ciegas, esperando que las respuestas "se sientan" mejor sin tener evidencia real.

Con contains_emoji cubres lo objetivo y verificable. Con kindness cubres lo subjetivo y conversacional. Juntas te dan una foto completa del desempeño del agente frente al dataset, y te permiten iterar con datos en la mano en lugar de intuiciones.

¿Ya pensaste qué métricas cualitativas y cuantitativas necesitarías para tu propio agente? Cuéntame en los comentarios qué comportamientos te gustaría evaluar.