Evaluar salida de IA: una respuesta no es evaluación

Una buena respuesta de IA muestra que el sistema puede hacer la tarea una vez. No muestra con qué frecuencia acierta, en qué entradas falla ni si vale la pena mantener la herramienta en ese trabajo. La evaluación de salida trata la generación como muestra: varias entradas representativas, repeticiones y un criterio de aceptación definido antes. La decisión de quedarse o salir es por tarea, no por demo.

Por qué una buena respuesta no prueba nada

Los sistemas de lenguaje no son deterministas. El mismo pedido puede dar respuestas de distinta calidad. El Nielsen Norman Group lo plantea así (en inglés): una salida aislada es un ejemplo, no una evaluación. Décadas de software clásico enseñaron al equipo a tratar “pasó una vez” como prueba. En IA, eso no se sostiene.

El artículo usa el ejemplo de atención al cliente. La misma pregunta sobre devoluciones puede salir correcta en una ronda, omitir una excepción en otra y prometer un reembolso indebido en la tercera. ¿Cuál representa al sistema? Las tres juntas, y ninguna sola.

Qué tiene que medir la evaluación

El mismo texto del NN/g (en inglés) compara la evaluación de IA con un estudio cuantitativo de usabilidad. En lugar de un participante y una tarea, observas a varias personas en tareas representativas y reportas un promedio con intervalo de confianza. En IA, el “participante” es una ejecución; la “tarea” es una entrada de prueba.

Dos preguntas necesitan respuesta:

Cómo se desempeña el sistema en el abanico de entradas que enviará la persona real.
Qué tan consistente es cuando la misma entrada vuelve.

La primera es variabilidad de entrada. La segunda es variabilidad entre ejecuciones. Más entradas no sustituyen más rondas, y lo contrario tampoco.

Cuántas entradas y cuántas rondas

El artículo ilustra con 10 preguntas representativas y 5 ejecuciones cada una, 50 salidas en total. Esos números no son una recomendación universal. Sirven para mostrar el diseño: varias entradas, repetición por entrada y un resumen de la distribución.

Antes de correr, define qué cuenta como aceptable. En el ejemplo de atención, el NN/g pide respuesta correcta, con condiciones y excepciones, alineada a la política y con el siguiente paso cuando corresponda. Fallar en cualquier ítem vuelve inaceptable la salida.

Como mínimo, reporta el porcentaje de salidas aceptables, un intervalo de confianza, la variación entre preguntas y la consistencia en la misma pregunta. Documenta modelo, versión, instrucciones, herramientas y fecha. Si cambia cualquier pieza, la evaluación es otra foto.

Qué esconde la nota final

Dos sistemas pueden acertar el 80% de las 50 ejecuciones y tener problemas muy distintos. El NN/g muestra el contraste (en inglés): uno acierta 8 de 10 preguntas en cada ronda y falla siempre en las otras 2; el otro acierta 4 de 5 en cada pregunta.

El primero es previsible: puedes mapear los temas que fallan y derivarlos a una persona. El segundo es imprevisible: cualquier pregunta puede salir mal, y el uso seguro suele exigir revisión humana antes del cliente. El promedio solo esconde esa diferencia.

Decidir por tarea: el marco PROVE

La presión por adoptar IA no es evidencia de que la herramienta ayuda. El marco PROVE del NN/g (en inglés) evalúa una herramienta contra una tarea y cierra con una decisión provisional que se puede defender. Las letras cubren alineación con el problema, riesgo, calidad de la salida, velocidad total y experiencia de uso.

Empieza por la tarea recurrente, no por la demo. Confirma que el dato que vas a cargar está permitido. Compara la salida con un trabajo tuyo real, no con un caso amable. Mide el tiempo entero: setup, prompt, revisión, corrección y formato. Separa el roce de una vez del roce que vuelve cada semana.

En la escala sugerida, 3 significa “parecido a lo que ya hago”. Una ronda en una sola entrada es un triaje, no un veredicto. PROVE no recomienda una herramienta para toda la organización; recomienda si la mantienes, la pruebas un plazo o la dejas de lado en esa tarea.

Quién verifica: alfabetización de salida

Usar IA con frecuencia no es lo mismo que usarla bien. El estudio del NN/g sobre alfabetización en IA (en inglés) separa dos capacidades: fluidez de prompt y alfabetización de salida. La primera comunica intención, límite y contexto. La segunda evalúa el resultado: laguna, alucinación, fuente y contraste cuando el riesgo sube.

Las dos no crecen juntas. Hay gente fluida en el prompt que acepta la respuesta al pie de la letra. Hay gente escéptica que casi no usa y, por eso, no entrena el prompt. Quien verifica de verdad cruza datos, pregunta de nuevo y cambia de herramienta según la tarea.

Eso importa en la evaluación. Sin alguien con alfabetización de salida, la ronda se vuelve aplauso a la respuesta más pulida. El análisis de adopción de chat de IA en UX (en inglés) muestra uso concentrado en escritura, diseño y código, y mucho menos en tareas con interacción humana o análisis complejo. Intentar la tarea con IA no prueba que la salida pasó.

Productividad medida, con matices

Jakob Nielsen resume tres estudios (en inglés) en los que la productividad media subió un 66% con IA generativa. Atención ganó un 13,8% más de consultas por hora. Profesionales de negocio escribieron un 59% más de documentos por hora. Programadores entregaron un 126% más de proyectos por semana.

El propio artículo lista matices. Los datos vinieron de versiones anteriores, en la línea de ChatGPT 3.5. Dos de los tres estudios midieron un solo uso, a menudo el primero. La ganancia vale en las tareas que la IA cubre; en el resto del día, el efecto se diluye. Cita el 66% con el enlace y con estos matices en el mismo párrafo. Alta productividad sin evaluación de salida aún puede esconder error silencioso.

Cómo queda en Vexor

En Vexor, mi producto de asistentes de IA en WhatsApp, la regla antes de instalar en el cliente es la misma. Una buena respuesta en la demo no es evaluación. El modelo se elige por tarea. Solo queda lo que aguanta preguntas reales repetidas, en el tipo de conversación que el negocio va a recibir.

El costo medido quedó en centavos por conversación, con tope mensual por cliente, y la cuenta está en el post sobre costo de IA por conversación. Ese número solo tiene sentido después de que la calidad de la salida pasa el criterio de la tarea. Un modelo barato que falla y uno caro que juzgaste por una demo brillante caen en el mismo error de método.

Dónde divergen las fuentes

Estadística frente a decisión. El artículo de evaluación trata muestreo, intervalo de confianza y distribución de fallos. PROVE trata si la herramienta vale en tu tarea, con escala y decisión provisional.
Quién verifica. La alfabetización de salida enfoca el comportamiento de chequeo diario. La evaluación formal enfoca el diseño experimental; se complementan, pero responden preguntas distintas.
Productividad frente a calidad. El texto del 66% mide throughput y, en parte, calidad del entregable. No sustituye el muestreo de salidas sobre la política o el flujo de tu producto.
Uso frente a éxito. El análisis de adopción cuenta conversaciones intentadas por ocupación. No reporta la tasa de acierto de esos intentos.

El error común

El error clásico es juzgar por la mejor respuesta que apareció en la prueba. La demo elige la entrada fácil, corre una vez y vende lo más llamativo. Una evaluación seria elige el abanico real, repite, mira dónde falla y solo entonces decide si la herramienta se queda en esa tarea. Si las rondas cuestan demasiado para repetir, la conclusión clara es que la evidencia aún no alcanza.