Un agente de IA que responde bien en la demo y falla en producción es el escenario más repetido de 2024 y 2025 en proyectos de automatización con LLM. El motivo casi siempre es el mismo: nadie definió cómo medir si funciona, ni se instrumentó el sistema para ver qué hace cuando nadie mira. En JULDITEC lo vemos constantemente al integrar agentes en flujos de n8n o en procesos de negocio sobre Liferay: el prototipo convence, pero falta la capa de evals (evaluaciones sistemáticas) y observabilidad que permita confiar en el sistema a medio plazo.
Por qué "funciona bien" no es una métrica
Con software tradicional, un test unitario tiene un resultado binario: pasa o falla. Con un LLM, la misma entrada puede producir salidas distintas, y "correcto" depende del contexto, del tono, de si cumple una política de negocio o de si cita fuentes reales. Esto obliga a cambiar el chip: en lugar de un único test, se necesita un conjunto de evals que evalúen dimensiones distintas (precisión factual, formato, seguridad, coste, latencia) y que se ejecuten de forma continua, no solo antes del despliegue.
La pregunta que debe responder un sistema de evals no es "¿ha salido bien?", sino "¿sigue saliendo bien después de cambiar el prompt, el modelo o la base de conocimiento?". Esa es la diferencia entre probar un agente una vez y mantenerlo en producción con garantías.
Tipos de evals que de verdad aportan señal
Evals unitarios (golden datasets)
Se construye un conjunto de casos representativos (entre 30 y 200 suele bastar para empezar) con la entrada esperada y el criterio de éxito. Por ejemplo, para un agente de soporte que consulta pedidos:
{
"input": "¿Cuál es el estado del pedido 10234?",
"expected_tool_call": "get_order_status",
"expected_contains": ["10234", "estado"],
"must_not_contain": ["no tengo acceso"]
}
Cada caso se ejecuta contra el agente real y se compara la salida con las reglas definidas. Esto detecta regresiones cuando se cambia el prompt del sistema o se actualiza el modelo base.
LLM-as-judge: un modelo evaluando a otro
Para criterios subjetivos (tono, claridad, cumplimiento de política de marca) se usa un segundo LLM como juez, con una rúbrica explícita. No es perfecto, pero escala mucho mejor que la revisión manual:
from openai import OpenAI
client = OpenAI()
def eval_response(question, answer, rubric):
prompt = f"""Evalúa la siguiente respuesta según esta rúbrica: {rubric}
Pregunta: {question}
Respuesta: {answer}
Devuelve un JSON con: score (0-10), razon (texto breve)."""
result = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": prompt}],
response_format={"type": "json_object"}
)
return result.choices[0].message.content
Conviene calibrar el juez: ejecutarlo contra respuestas ya puntuadas por humanos y comprobar que coincide razonablemente antes de confiar en él a gran escala.
Human-in-the-loop y muestreo en producción
Los evals automáticos no sustituyen la revisión humana, la complementan. Lo habitual es muestrear un porcentaje de las conversaciones reales (entre el 2% y el 10%, según volumen) y que un humano las puntúe con la misma rúbrica. Esto sirve también para detectar casos nuevos que hay que añadir al golden dataset.
Un eval que no se actualiza con los casos reales de producción deja de medir lo que de verdad importa.
Observabilidad: ver qué hace el agente paso a paso
Los evals responden a "¿funciona bien?" en momentos concretos. La observabilidad responde a "¿qué está pasando ahora mismo?". Para un agente con herramientas, llamadas a APIs y pasos de razonamiento, necesitas trazas detalladas: qué prompt se envió, qué modelo respondió, qué herramienta se invocó, cuánto tardó y cuánto costó cada paso.
Herramientas de trazabilidad: Langfuse y similares
Plataformas como Langfuse o LangSmith permiten instrumentar cada llamada del agente como un span dentro de una traza. Integrarlo en un agente propio es directo:
from langfuse.decorators import observe
from langfuse.openai import openai
@observe()
def consultar_pedido(order_id):
response = openai.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": f"Consulta el pedido {order_id}"}]
)
return response.choices[0].message.content
Cada ejecución queda registrada con latencia, tokens consumidos, coste estimado y el árbol completo de llamadas, lo que facilita diagnosticar por qué una respuesta tardó ocho segundos o por qué un agente llamó dos veces a la misma herramienta.
Observabilidad en flujos de n8n
Cuando el agente vive dentro de un workflow de n8n, la observabilidad no termina en el LLM: hay que vigilar también los nodos previos y posteriores (consultas a bases de datos, webhooks, transformaciones). En estos casos combinamos el Execution Log nativo de n8n con el envío de eventos a Langfuse mediante un nodo HTTP Request, de forma que cada ejecución del workflow queda enlazada con la traza del modelo:
// Nodo Function en n8n: envía metadata de la ejecución a Langfuse
const payload = {
name: "n8n_workflow_execution",
input: $json.input,
metadata: {
workflow_id: $workflow.id,
execution_id: $execution.id
}
};
return [{ json: payload }];
Esto es especialmente útil en agentes que orquestan varios subprocesos: sin esta correlación, un fallo intermitente puede tardar días en localizarse.
Métricas que de verdad hay que vigilar
- •Tasa de éxito por tarea: porcentaje de ejecuciones que cumplen el criterio de éxito definido en el golden dataset, no una media global difusa.
- •Alucinaciones detectadas: respuestas que afirman datos no presentes en las fuentes consultadas; se detectan comparando la respuesta contra el contexto recuperado (especialmente crítico en sistemas RAG).
- •Latencia por paso: además del total, cuánto tarda cada llamada a herramienta o modelo, para identificar cuellos de botella.
- •Coste por conversación: tokens de entrada y salida multiplicados por el precio del modelo, agregado por tipo de tarea.
- •Tasa de escalado a humano: cuántas conversaciones terminan derivadas a soporte, indicador indirecto de calidad percibida.
Estas métricas deben verse en un dashboard accesible para el equipo de producto, no solo en logs técnicos. Langfuse y LangSmith ofrecen vistas agregadas; si el stack es más artesanal, exportar a Grafana sobre una base de datos de eventos funciona igual de bien.
Cómo montar un pipeline de evaluación continua
El patrón que recomendamos en proyectos de JULDITEC combina tres capas que se ejecutan en momentos distintos:
- •Pre-despliegue: el golden dataset corre en CI/CD cada vez que cambia un prompt o se actualiza el modelo, bloqueando el merge si la tasa de éxito baja de un umbral.
- •Producción continua: cada interacción real se traza; un job periódico ejecuta LLM-as-judge sobre una muestra y alimenta el dashboard de métricas.
- •Revisión humana semanal: el equipo revisa casos marcados con baja puntuación o alta latencia, y los casos nuevos relevantes se incorporan al golden dataset.
Este ciclo convierte los evals en algo vivo, no en una checklist que se ejecuta una vez antes de lanzar. Un agente de IA en producción cambia de comportamiento con cada actualización de modelo del proveedor, con cada nuevo documento en la base de conocimiento, con cada prompt retocado; sin este pipeline, esos cambios se descubren por quejas de usuarios, no por métricas.
Si vas a desplegar un agente ahora mismo, empieza por lo mínimo viable: 20 casos de prueba reales, una traza básica con Langfuse y una revisión manual semanal de diez conversaciones. Es más valor que cualquier dashboard sofisticado sin datos reales detrás.