Este es un patrón que observamos constantemente. Un equipo crea un flujo de IA —redacción de contenido, clasificación de solicitudes de soporte, generación de correos de ventas o cualquier otra tarea—. Durante la semana 1 funciona bien. El equipo está encantado y lo implanta.
Tres meses después, algo parece ir mal. La calidad de las respuestas ha empeorado. Los clientes se quejan. Los representantes dejan de utilizarlo. Nadie sabe cuándo cambió ni por qué.
La causa casi siempre es la misma: nadie medía la calidad. El flujo que funcionaba durante la semana 1 podría haberse degradado gradualmente; quizá cambió el modelo subyacente, los prompts se desviaron o se modificó la distribución de las entradas. Sin medición, no lo detectas hasta que se quejan los usuarios y, para entonces, ya has perdido su confianza.
La solución son las evaluaciones, es decir, la medición sistemática de la calidad de las respuestas de la IA. Suelen considerarse una tarea de ingeniería, pero todos los equipos que ejecutan flujos de IA las necesitan. Además, los conceptos básicos se pueden aplicar sin programar.
Este artículo explica qué son las evaluaciones, por qué importan y cómo configurarlas para cualquier flujo de IA sin ser ingeniero.
Las evaluaciones no son un ejercicio para aparentar control. Una evaluación útil conduce a una decisión: publicar, mantener, revertir o investigar. Si una puntuación no puede cambiar lo que hace el equipo, simplifica la evaluación hasta que pueda hacerlo.
Qué son las evaluaciones y qué no son
Una evaluación permite medir de forma sistemática la calidad de las respuestas de tu IA mediante ejemplos que controlas.
Los componentes:
- Un conjunto de datos. Un conjunto de entradas (las cosas que procesa tu IA).
- Comportamiento esperado. Lo que quieres que haga la IA con esas entradas.
- Un método de puntuación. Cómo se determina si la IA ha respondido correctamente.
- Una ejecución y un informe. Se procesa el conjunto de datos, se puntúa cada respuesta y se resume el resultado.
El objetivo es poder preguntar de forma repetible «¿hace la IA lo que necesito, con la calidad esperada?» y detectar cuándo cambia la respuesta.
Las evaluaciones no son:
- Pruebas puntuales durante la construcción inicial.
- Revisión aleatoria cuando algo parece mal.
- Comentarios de usuarios, que son útiles, pero reactivos, lentos y sesgados.
- Impresiones subjetivas como «la respuesta parece correcta».
Una evaluación real se ejecuta periódicamente sobre un conjunto definido de entradas y utiliza criterios de puntuación coherentes. Proporciona una señal incluso cuando nadie se queja.
Por qué las herramientas para ingenieros no sirven a la mayoría de los equipos
Si buscas «evaluaciones de LLM» en Google, encontrarás artículos sobre herramientas como Promptfoo, LangSmith, Braintrust y Helicone. Son excelentes, pero están diseñadas para ingenieros que publican productos basados en LLM a gran escala.
Para la mayoría de los equipos que ejecutan flujos de IA —marketing, ventas, operaciones o soporte—, estas herramientas resultan excesivas. Necesitas algo más sencillo: una forma de medir tu flujo concreto sin aprender todo un stack de herramientas.
La buena noticia es que puedes hacerlo con una hoja de cálculo y un LLM. No tendrá la sofisticación de LangSmith, pero bastará para detectar la mayoría de los problemas de calidad.
Los cuatro patrones de evaluación
Existen cuatro patrones de evaluación habituales. Cada uno se adapta a un tipo distinto de flujo de trabajo.
Patrón 1: Coincidencia exacta
Utilízalo cuando solo exista una respuesta correcta.
Ejemplo de flujo de trabajo: clasificar solicitudes de soporte al cliente en 8 categorías.
Conjunto de datos: 50 solicitudes con su categoría correcta. Puntuación: la respuesta de la IA coincide con la categoría correcta (1 punto) o no (0 puntos). Resultado: porcentaje de aciertos.
Funciona bien para clasificación, extracción y respuestas estructuradas sencillas.
Patrón 2: Comparación con referencia
Utilízalo cuando exista una respuesta de calidad conocida con la que comparar.
Ejemplo de flujo de trabajo: redactar descripciones de productos.
Conjunto de datos: 30 productos con “descripciones de referencia” que escribiste. Puntuación: grado de similitud entre la descripción de la IA y la referencia en dimensiones como exactitud, tono e integridad.
Puedes puntuar manualmente —una persona lee ambas versiones y asigna una nota de 1-5— o utilizar un LLM como juez, como se explica en el patrón siguiente. La comparación con una referencia es el estándar de máxima calidad para los flujos de contenido.
Patrón 3: LLM como juez
Utilízalo cuando haya muchas respuestas válidas, pero sea posible evaluar su calidad.
Ejemplo de flujo de trabajo: generar correos de ventas personalizados.
Conjunto de datos: 30 perfiles de posibles clientes. Puntuación: un LLM actúa como juez y, a partir de la entrada y la respuesta, puntúa dimensiones como especificidad, profesionalidad, longitud y adecuación a la voz.
El LLM como juez es poderoso pero requiere un diseño cuidadoso de prompts. Un patrón común:
You are evaluating a sales email for quality. Score it on these dimensions:
1. Specificity (1-5): Does it reference specific facts about the prospect, not generic flattery?
2. Professionalism (1-5): Does it sound like a peer rather than spam?
3. Length appropriateness (1-5): Is it concise (40-80 words)?
4. Voice match (1-5): Does it match our voice (direct, no buzzwords)?
For each dimension, give the score and a one-sentence reason.
Output JSON: {"specificity": {"score": N, "reason": "..."}, ...}
Prospect profile: [input]
Email to evaluate: [output]
Un LLM como juez aporta una coherencia difícil de mantener entre revisores humanos: se aplica el mismo modelo y el mismo prompt de forma uniforme. Sin embargo, un juez que nunca has verificado no es más que una segunda opinión de calidad desconocida. Por eso debes calibrarlo correctamente:
- Toma 50 ejemplos que tu equipo ya haya etiquetado —como aprobados o rechazados, o mediante tu escala de puntuación—. Reutiliza casos reales de la cola de revisión; no inventes casos sintéticos.
- Ejecuta el juez sobre esos mismos 50 ejemplos y calcula la concordancia. Por encima de aproximadamente el 85%, puedes confiarle las revisiones rutinarias y mantener una muestra bajo revisión humana. Entre ~70% y 85%, analiza cada discrepancia: casi siempre se debe a una rúbrica imprecisa, no a que el juez sea incapaz. Ajusta la redacción de la rúbrica y vuelve a ejecutar la prueba. Por debajo de ~70%, el juez está midiendo algo distinto; no automatices con él.
- Observa la dirección de los errores, no solo la tasa. Un juez que aprueba respuestas deficientes es peligroso; uno que rechaza respuestas buenas resulta molesto, pero menos arriesgado. Define el umbral en consecuencia.
- Recalibra con 20-30 ejemplos nuevos cada vez que cambies el modelo del juez, su prompt o la rúbrica, porque cualquiera de estos elementos puede alterar silenciosamente la tasa de concordancia.
Estos intervalos forman parte de nuestro protocolo inicial recomendado, no son una ley universal. Lo innegociable es calibrar antes de permitir que las puntuaciones del juez activen una acción.
Patrón 4: Comprobación de propiedades
Utilízalo cuando puedas expresar qué significa «bueno» mediante propiedades concretas y verificables.
Ejemplo de flujo de trabajo: generar títulos de productos para una tienda de comercio electrónico.
Conjunto de datos: 50 productos. Propiedades que se deben comprobar en cada respuesta:
- Longitud entre 30-70 caracteres.
- Incluye el nombre de la marca.
- Incluye al menos uno de los atributos clave del producto.
- No usa palabras de marketing prohibidas (“increíble”, “mejor”, “revolucionario”).
Cada propiedad es una prueba de sí o no. La puntuación es el porcentaje de propiedades superadas en todas las respuestas.
Las comprobaciones de propiedades son excelentes para restricciones estructuradas que siempre deben cumplirse. Se ejecutan con rapidez y detectan desviaciones concretas.
Cómo configurar tu primera evaluación
Una configuración práctica y accesible para no ingenieros:
Paso 1: Elige el flujo de trabajo
Elige un flujo de trabajo. No intentes evaluarlo todo a la vez. Empieza por el que más te preocupe por su calidad o por el que tenga mayores consecuencias.
Ejemplo: «la IA que clasifica por tema las solicitudes entrantes de soporte al cliente».
Paso 2: Construye el conjunto de datos
Crea una lista de 20-50 ejemplos representativos que incluya:
- Casos fáciles (claramente categoría A).
- Casos difíciles (podrían ser A o B).
- Casos límite (no encajan claramente en ninguna categoría).
- Variaciones comunes (diferentes formulaciones del mismo propósito).
Regístralos en una hoja de cálculo:
| ID | Entrada | Salida esperada |
|---|---|---|
| 1 | ”Mi contraseña no funciona" | "account-access” |
| 2 | ”Quiero cancelar mi suscripción" | "billing” |
| 3 | ”Tu última actualización rompió mi flujo de trabajo" | "bug” |
| … | … | … |
Este conjunto de datos será la base de la evaluación. No debe cambiar con frecuencia, pues su función es servir como referencia estable.
Paso 3: Define la puntuación
Define con precisión qué se considera una respuesta correcta para cada ejemplo.
Para clasificación: coincidencia exacta en la categoría. Para contenido: una puntuación de 1-5 en cada una de las 2-4 dimensiones definidas. Para extracción: cada campo correcto/incorrecto.
Escribe la rúbrica de puntuación y aplícala de forma coherente.
Paso 4: Ejecuta el flujo de trabajo en el conjunto de datos
Ejecuta el flujo de IA con cada ejemplo del conjunto de datos y registra la respuesta en una columna nueva.
En una clasificación, puedes hacerlo en una hoja de cálculo mediante una integración de GPT con Google Sheets o copiando y pegando manualmente.
Para flujos más complejos, exporta las entradas a una herramienta como Promptfoo o ejecuta un proceso por lotes una vez por semana.
| ID | Entrada | Esperado | Real |
|---|---|---|---|
| 1 | … | “account-access" | "account-access” |
| 2 | … | “billing" | "billing” |
| 3 | … | “bug" | "feature-request” |
| … | … | … | … |
Paso 5: Asigna las puntuaciones
Para una coincidencia exacta, añade una columna «coincidencia» con 1 si Esperado = Real y 0 en caso contrario. La suma determina la exactitud.
Para un LLM como juez, ejecuta el prompt del juez sobre cada respuesta y registra las puntuaciones.
Para una comprobación de propiedades, ejecuta cada propiedad como una prueba independiente y agrega los resultados.
Cuadro de evaluación mínimo viable
En la primera evaluación, mide pocas dimensiones, pero procura que todas permitan actuar.
| Dimensión | Pregunta | Umbral de aprobación | Acción si está por debajo del umbral |
|---|---|---|---|
| Exactitud | ¿El flujo de trabajo produjo la respuesta o clasificación correcta? | 90% | Revisar los fallos antes del lanzamiento |
| Seguridad | ¿Evitó contenido prohibido, afirmaciones no respaldadas o acciones riesgosas? | 100% | Bloquear lanzamiento |
| Formato | ¿Devuelve la estructura esperada? | 95% | Corregir prompt/esquema antes del lanzamiento |
| Utilidad | ¿Un usuario aceptaría razonablemente esta respuesta? | 4/5 promedio | Revisar ejemplos o instrucciones |
| Regresión | ¿Los fallos conocidos permanecieron corregidos? | 100% | Bloquear lanzamiento |
El cuadro debe indicar una persona responsable y una regla de lanzamiento. «Por debajo del 90% de exactitud, debe revisar el responsable del producto» es más útil que «medir la exactitud».
Paso 6: Resume los resultados
Una tabla de resumen como:
| Fecha de evaluación | Puntuación | Notas |
|---|---|---|
| 2026-05-01 | 47/50 (94%) | Referencia. 3 errores: solicitudes 8, 23, 41. |
| 2026-05-08 | 46/50 (92%) | Estable. 4 errores. |
| 2026-05-15 | 44/50 (88%) | Caída. Nuevos errores en las solicitudes 12, 35. |
Con el tiempo, esta tabla muestra la evolución de la calidad. Una caída activa una investigación.
Paso 7: Programar
Ejecuta la evaluación con una periodicidad fija. Una vez por semana basta para la mayoría de los flujos. Después de cambiar un prompt o un modelo, ejecútala antes de implantar el cambio.
Un hábito semanal de 30 minutos. Establece un bloque recurrente en el calendario. No lo omitas.
El cuadro enlazado desde este artículo está diseñado para esta primera evaluación semanal.
Añade una puerta de lanzamiento
Las evaluaciones resultan más valiosas cuando controlan los cambios. En cualquier flujo de IA que afecte a clientes, registros operativos o decisiones del equipo, utiliza una puerta de lanzamiento sencilla:
- Referencia. Registra la puntuación del flujo que está actualmente en producción.
- Candidato. Ejecuta el nuevo prompt, modelo, herramienta o paso del flujo sobre el mismo conjunto de evaluación.
- Comparación. El candidato debe mantener las puntuaciones de seguridad y regresión, y no reducir la puntuación principal de calidad más allá del umbral acordado.
- Decisión. Publicar, mantener, revisar o revertir. Registra el motivo.
- Verificación posterior al lanzamiento. Después de publicar, vuelve a ejecutar la evaluación sobre una pequeña muestra de casos reales.
No es necesario automatizarlo desde el primer día. Basta una hoja de cálculo y una persona responsable de aprobar, siempre que el proceso impida sistemáticamente que lleguen a producción cambios sin medir.
¿Qué hacer cuando las puntuaciones caen
El objetivo de las evaluaciones es detectar la degradación de la calidad. Cuando ocurra, investiga.
Una investigación simple:
Paso 1: Identifica los casos fallidos. ¿Qué ha salido mal exactamente?
Paso 2: Busca patrones. ¿Se agrupan los fallos en entradas similares o están dispersos entre tipos distintos?
Paso 3: Diagnostica.
- Patrón → probablemente una debilidad específica (problema de prompt, conocimiento faltante).
- Disperso → probablemente una caída general de calidad (cambio de modelo, desviación).
Paso 4: Formula una hipótesis sobre la causa.
- ¿El modelo subyacente cambió recientemente? Revisa el registro de cambios del proveedor.
- ¿El prompt cambió recientemente? Revierte y prueba.
- ¿La distribución de entradas cambió? Mira datos recientes reales.
- ¿El conjunto de datos se volvió obsoleto? Refresca ejemplos.
Paso 5: Prueba la solución. Realiza un cambio y vuelve a ejecutar la evaluación. ¿Se ha recuperado la puntuación?
Este enfoque sistemático es más eficaz que actuar con pánico o especular.
Mejora el conjunto de datos con el tiempo
El conjunto de datos inicial es solo un punto de partida. Mejóralo con estas prácticas:
Añade casos de fallo reales. Cuando un caso de un cliente o usuario produzca una respuesta deficiente, incorpóralo al conjunto de evaluación. Se convertirá en una prueba de regresión que detectará ese fallo si vuelve a ocurrir.
Elimina los casos obsoletos. A medida que evoluciona el flujo, algunos casos de prueba dejan de ser pertinentes. Elimínalos.
Amplía la cobertura. Si el conjunto de evaluación contiene 20 casos de «account-access» y solo 1 de «billing», está sesgado. Reequilíbralo.
Añade casos límite cuando los encuentres. Incorpora nuevos patrones de quejas, nuevas funciones del producto y nuevas categorías.
Un buen conjunto de evaluación está vivo: refleja la realidad actual, no solo la histórica.
Errores comunes
Estos son algunos patrones que hacen fracasar los programas de evaluación:
Error 1: Intentar crear una evaluación perfecta antes de empezar. Preparar 50 ejemplos con una puntuación elaborada puede resultar abrumador. Hoy mismo puedes crear 10 ejemplos con una puntuación sencilla. Empieza con poco e itera.
Error 2: Evaluar solo el recorrido ideal. Un conjunto compuesto únicamente por ejemplos fáciles no detecta fallos reales. Incluye casos difíciles, casos límite y fallos conocidos.
Error 3: Deriva del conjunto de evaluación. Si actualizas el conjunto cada vez que cambia el flujo, la puntuación deja de ser útil. El flujo puede cambiar con frecuencia, pero el conjunto de evaluación solo debe hacerlo ocasionalmente. El objetivo es medir el flujo, no adaptar la evaluación.
Error 4: Confiar ciegamente en el LLM juez. Los LLM utilizados como jueces tienen sesgos y pueden conceder demasiado peso a características superficiales como la longitud o el formato. Calíbralos periódicamente frente al criterio humano. Si discrepas de forma sistemática, debes mejorar el prompt del juez.
Error 5: Puntuar sin actuar. Ejecutar evaluaciones cada semana sin actuar sobre los datos es puro teatro. El objetivo es detectar y corregir problemas. Si una caída no activa una investigación, estás perdiendo el tiempo.
Error 6: Evaluar una sola dimensión. «¡Mi evaluación muestra un 95% de exactitud!», pero quizá haya empeorado la calidad, aumentado la latencia o crecido la tasa de alucinaciones. Mide varias dimensiones cuando sean relevantes.
Herramientas que ayudan (pero no son obligatorias)
Si quieres dar el salto desde las hojas de cálculo, estas son algunas opciones accesibles:
Promptfoo. Es de código abierto, se configura mediante YAML y se ejecuta en tu portátil o en CI. Es excelente para probar y comparar prompts.
Braintrust. Plataforma alojada para evaluaciones con una interfaz fácil de usar. Es más cara, pero potente.
LangSmith. Está estrechamente vinculada a los flujos de LangChain y es una buena opción si utilizas ese ecosistema.
Helicone. Ofrece registros y análisis de llamadas a LLM, además de funciones de evaluación.
OpenAI Evals. Framework de código abierto orientado principalmente a desarrolladores.
Para la mayoría de los equipos no técnicos, basta con una hoja de cálculo y ChatGPT o Claude. Promptfoo es la opción más sencilla cuando quieras avanzar.
Un programa de evaluación de 4 semanas
Para un equipo que comienza desde cero, un plan realista:
Semana 1: Elegir y definir.
- Elige un flujo de trabajo.
- Construye un conjunto de datos de 20 ejemplos.
- Define la puntuación (coincidencia exacta, juez LLM o propiedades).
Semana 2: Primera referencia.
- Ejecuta la evaluación. Registra la puntuación de referencia.
- Identifica cualquier fallo obvio.
- No cambies nada aún — solo observa.
Semana 3: Itera.
- Haz un cambio que crees que mejorará la calidad.
- Vuelve a ejecutar la evaluación.
- ¿La puntuación subió, bajó o se mantuvo? Investiga por qué.
Semana 4: Programar.
- Programa ejecuciones semanales.
- Documenta el proceso de evaluación.
- Informa al equipo sobre lo que significan las puntuaciones y qué activa una acción.
Después de 4 semanas tendrás una evaluación funcional. A partir de ahí, amplía el programa a más flujos, mejora el conjunto de datos y perfecciona la puntuación.
El cambio cultural
Las evaluaciones exigen un cambio más cultural que técnico. Los equipos acostumbrados a publicar flujos de IA «porque parecen funcionar» deben adoptar una cultura de medición.
El cambio implica:
Aceptar que las cifras pueden bajar. A veces, un cambio que te entusiasmaba perjudica la calidad. Las evaluaciones lo mostrarán y debes estar dispuesto a revertirlo.
Invertir en calibración. Durante el primer mes de una evaluación nueva tendrás que perfeccionar el conjunto de datos, la puntuación y los prompts. Es una inversión.
Crear un hábito de «antes y después». Cualquier cambio relevante en un flujo de IA debe pasar por la evaluación antes de llegar a producción. Con el tiempo, será algo natural.
No rebajar el nivel de calidad. Cuando caen las puntuaciones, corrige el problema o revierte el cambio. No publiques con una calidad degradada solo porque exista un plazo.
Este cambio cultural es la parte más difícil. Una vez establecido, las herramientas son la parte sencilla.
Un flujo de trabajo, veinte ejemplos, media hora a la semana
Las evaluaciones marcan la diferencia entre flujos de IA en los que puedes confiar a lo largo del tiempo y otros que derivan gradualmente hacia la mediocridad sin que nadie lo advierta.
Para empezar no necesitas ingenieros, conocimientos de ML ni herramientas sofisticadas. Necesitas un flujo que merezca la pena medir, un conjunto de datos pequeño, un método de puntuación y media hora a la semana.
Elige un flujo esta semana. Crea una evaluación con 20 ejemplos. Ejecútala y observa el resultado. Repítela la semana siguiente y comprueba cómo se consolida el hábito.
Dentro de 6 meses, los equipos que evalúan tendrán flujos de IA que realmente han mejorado. Los que no lo hacen tendrán flujos parecidos a los de hace 6 meses, pero peores.
