Evaluación de modelos de IA: cómo saber si responde bien

La evaluación de modelos de IA es la parte del proyecto que casi nadie presupuesta y la única que responde a la pregunta que importa: ¿esto funciona lo bastante bien para ponerlo delante de un cliente o de un compañero? La escena típica es siempre la misma. Alguien enseña una demo, el asistente contesta tres preguntas bien, la sala asiente y el proyecto avanza. Seis semanas después, en producción, resulta que falla en el 20 % de los casos reales y nadie sabe decir si antes fallaba más o menos, porque nunca se midió.

Probar un rato no es evaluar. Evaluar es tener un conjunto fijo de casos con la respuesta correcta acordada de antemano, pasarlo cada vez que cambia algo y comparar números con los de la semana pasada. Sin eso, cualquier decisión —cambiar de proveedor, tocar el prompt, subir de versión— se toma por sensación.

Esta guía explica cómo montar esa evaluación en una empresa normal, sin equipo de investigación: qué casos meter en el conjunto de pruebas, qué métricas tienen sentido según el tipo de tarea, cuánta revisión humana hace falta de verdad y qué exigir por contrato a quien te vende el modelo o el asistente.

¿Qué es la evaluación de modelos de IA y por qué no basta con probarlo un rato?

Evaluar un modelo es medir su comportamiento sobre un conjunto de casos representativos y estables en el tiempo. Tres palabras hacen el trabajo:

• Representativos. Los casos salen de tu operación real, no de ejemplos bonitos. Si el 30 % de los correos que entran en atención al cliente vienen mal escritos y con dos preguntas mezcladas, ese 30 % tiene que estar en el conjunto.
• Estables. El mismo conjunto, pasado antes y después del cambio. Si cada semana pruebas con preguntas distintas, no estás midiendo el modelo: estás midiendo tu memoria.
• Con respuesta acordada. Alguien del negocio ha decidido antes qué respuesta es correcta. No vale decidirlo mirando lo que contestó el modelo; eso se llama validar hacia atrás y siempre aprueba.

El error de fondo de la demo es que premia el caso fácil. Un asistente que responde bien a «¿cuál es el plazo de entrega estándar?» dice muy poco. Lo que decide si el proyecto vive o muere es qué hace con «el pedido 4471 llegó incompleto, ¿me lo reponéis antes del viernes o anulo?». Esa pregunta tiene contexto, tiene una consulta a un sistema y tiene una respuesta que puede costar dinero si se inventa.

Hay además una asimetría que conviene tener clara desde el principio: no todos los errores cuestan lo mismo. Que el asistente responda de forma algo torpe pero correcta es un problema menor. Que afirme con seguridad un plazo de entrega falso es un problema grave. Que filtre el dato de otro cliente es un incidente. La evaluación debe separar esos tres niveles en vez de dar un único porcentaje de acierto que los mezcla.

¿Cómo se construye un conjunto de pruebas propio?

El conjunto de pruebas (lo que en la jerga llaman golden set) es el activo más duradero de todo el proyecto. El modelo cambiará, el proveedor puede cambiar; el conjunto se queda y sirve para comparar.

Cómo se monta, en orden:

1. Saca 100-200 casos reales del histórico. Tickets, correos, consultas, documentos. No los escribas tú: cópialos tal cual llegaron, con faltas y ambigüedades incluidas. 2. Estratifica. Agrupa por tipo de consulta y respeta el peso real de cada grupo, más una cuota deliberada de casos difíciles: ambiguos, con dos intenciones, con datos que no existen, fuera de alcance. 3. Escribe la respuesta esperada. La escribe quien hoy hace ese trabajo, no el equipo técnico. Para tareas de clasificación basta la etiqueta; para tareas de redacción, basta con listar los puntos que la respuesta debe contener y los que no debe decir nunca. 4. Mete casos trampa. Preguntas cuya respuesta correcta es «no lo sé» o «esto lo ve una persona». Son los que detectan la invención, que es el fallo más caro. 5. Congélalo y versiónalo. Un archivo en el repositorio, con fecha. Si añades casos, se crea la versión 2 y se dice en el informe.

Con 150 casos bien elegidos se detectan la mayoría de los problemas. Con 2.000 mal elegidos, ninguno. Y reserva un puñado de casos que nadie usa para ajustar nada: son el control final, lo que impide que acabes optimizando el prompt contra el examen en vez de contra el trabajo.

Si no puedes escribir la respuesta correcta a un caso, el modelo tampoco va a poder. Ese caso no es un problema de IA: es un problema de proceso sin resolver.

¿Qué métricas usar según el tipo de tarea?

No hay una métrica universal. Depende de qué le pides al sistema. Esta tabla cubre lo que se ve en una empresa mediana:

| Tipo de tarea | Ejemplo | Qué medir | Umbral razonable para empezar | |---|---|---|---| | Clasificación | Enrutar un correo al departamento | Acierto por clase, y sobre todo la matriz de confusión | 85-95 % según coste del error | | Extracción de datos | Sacar importe y NIF de una factura | Acierto campo a campo, no documento a documento | 95 %+ en campos críticos | | Respuesta sobre documentos | Buscador interno, asistente de soporte | Respuesta correcta, respuesta fundamentada en la fuente citada, tasa de invención | Invención por debajo del 2 % | | Redacción | Borrador de correo o de propuesta | % de borradores usados sin edición pesada | Se mide contra el tiempo que ahorra | | Resumen | Resumen de llamada o de acta | Cobertura de los puntos clave y ausencia de datos falsos | Revisión humana por muestreo |

Tres aclaraciones que evitan disgustos:

• El acierto global engaña cuando las clases están desequilibradas. Si el 95 % de las facturas son correctas, un modelo que diga siempre «correcta» acierta el 95 % y no sirve para nada. Mira el comportamiento sobre la clase minoritaria, que es justo la que te interesa.
• Falsos positivos y falsos negativos no se compensan. En detección de fraude o en criba de candidaturas, decidir dónde pones el umbral es una decisión de negocio, no técnica. Que la tome quien asume la consecuencia.
• La latencia y el coste son métricas de calidad. Un modelo que acierta tres puntos más pero tarda ocho segundos por respuesta puede ser peor producto que uno más simple. Mídelos en la misma tabla.

Para tareas de respuesta libre existe la opción de usar otro modelo como juez: se le da la pregunta, la respuesta esperada y la respuesta del sistema, y puntúa. Funciona razonablemente para filtrar y abarata mucho la evaluación continua, pero hay que calibrarlo: toma 50 casos, puntúalos a mano, compara con el juez automático y mira si coinciden. Si el juez aprueba lo que tus personas suspenden, el juez está roto y lo que mide no vale.

¿Cuánta revisión humana hace falta y quién la hace?

Toda. Pero no siempre y no sobre todo.

El esquema que funciona tiene tres capas:

• Evaluación de referencia, sobre el conjunto de pruebas, con personas. Se hace una vez bien hecha y se repite cada vez que hay un cambio relevante. Dos revisores sobre los casos dudosos; si discrepan, decide el responsable del proceso y esa decisión se escribe en el criterio.
• Evaluación automática continua, con el mismo conjunto, cada vez que se toca el prompt, se cambia de versión del modelo o se actualiza el repositorio documental. Debe tardar minutos y lanzarse sola.
• Muestreo en producción, que es el único que mide la realidad. Entre el 1 % y el 5 % de las interacciones reales revisadas por una persona cada semana, con un formulario de tres campos: ¿correcta?, ¿fundamentada?, ¿qué habría hecho tú?

Quién lo hace importa más que el método. La revisión la hace quien domina la tarea: la persona de atención al cliente, la del departamento fiscal, la del almacén. El equipo técnico monta el tinglado y lee los números; no decide qué respuesta es buena. Y hay que presupuestar ese tiempo: entre 8 y 16 horas de una persona del negocio para la evaluación inicial, y una o dos horas semanales de muestreo después. Si nadie tiene esas horas, el proyecto no está listo para producción, y conviene saberlo antes que después.

Esto conecta con algo que ya vimos en por qué se abandonan las herramientas de IA: el equipo que participa en definir qué es una buena respuesta es el que luego defiende el sistema cuando falla. El que solo lo recibe hecho, lo abandona a la tercera respuesta rara.

¿Qué exigir al proveedor antes de pagar?

Aquí es donde la evaluación deja de ser un ejercicio técnico y se convierte en una cláusula. Lo que se puede pedir sin ser abusivo:

• Prueba sobre tus datos, no sobre su demo. Que pasen tu conjunto de pruebas y entreguen resultados por tipo de caso. Si se niegan a tocar casos reales anonimizados, mala señal.
• Resultados desglosados, no un titular. «95 % de acierto» no significa nada sin saber sobre qué casos y con qué reparto. Pide la tabla por categoría.
• Tasa de invención medida. Para cualquier sistema que responda sobre documentos propios —ver RAG para empresas—, que digan qué porcentaje de respuestas no se sostiene en la fuente citada y cómo lo han medido.
• Qué pasa cuando cambien de versión de modelo. Esto es lo que más se olvida. Un cambio de versión al que no has asistido puede mover los resultados en ambas direcciones. Exige aviso previo y una pasada del conjunto de pruebas antes de aplicarlo.
• Trazabilidad. Registro de qué se preguntó, qué fuentes se usaron y qué se respondió, con retención acordada. Sin eso no hay forma de investigar un incidente ni de cumplir con una reclamación.
• Propiedad del conjunto de pruebas y de los resultados. Tuyos. Es lo que te permite comparar al siguiente proveedor con el mismo rasero.

Un detalle de negociación: pide que el pago de la fase de implantación se ligue a superar unos umbrales acordados sobre tu conjunto de pruebas, no a entregar una demo. Cambia por completo la conversación, y los proveedores serios lo aceptan sin pestañear. Si quieres el marco completo de esa conversación, está en cómo elegir consultora de IA.

¿Cómo se mantiene la evaluación viva cuando el sistema ya está en producción?

Un modelo no se degrada solo, pero el mundo alrededor sí cambia: entran productos nuevos, cambia la normativa, se actualiza el repositorio de documentos, el proveedor publica una versión nueva. Lo que antes funcionaba empieza a fallar en los casos nuevos, y nadie se entera hasta que llega la queja.

El mantenimiento mínimo que aguanta el día a día:

• Un cuadro con cuatro números revisado mensualmente: acierto sobre el conjunto de pruebas, tasa de invención, porcentaje de escalados a persona y coste por interacción. Nada más. Si la lista crece a quince métricas, no la mira nadie —el mismo error que describimos en cuadro de mando.
• Alimentar el conjunto con los fallos reales. Cada queja de producción se convierte en un caso de prueba nuevo. Es la forma más barata de que el conjunto siga siendo representativo.
• Un umbral que dispara una revisión. Por ejemplo: si el acierto baja más de tres puntos respecto a la referencia, se para el cambio y se investiga. Escrito y con un responsable.
• Registro de cambios. Cada modificación de prompt, de versión o de fuentes documentada con fecha y su resultado de evaluación al lado. Esto es parte del trabajo de MLOps y es lo que permite volver atrás cuando algo empeora.

Preguntas frecuentes

¿Cuántos casos necesita un conjunto de pruebas?

Entre 100 y 200 casos reales bien estratificados cubren la mayoría de proyectos en una empresa mediana. Importa mucho más la variedad y que incluyan casos difíciles que el volumen total. Un conjunto de 2.000 ejemplos fáciles mide peor que uno de 150 bien elegidos.

¿Puedo evaluar un modelo sin perfil técnico en el equipo?

Para la parte que decide —qué respuesta es correcta, qué error es inaceptable, dónde está el umbral— no hace falta perfil técnico, y de hecho es mejor que la haga el negocio. Para automatizar la pasada del conjunto y medir latencia y coste sí hace falta alguien técnico, interno o del proveedor.

¿Qué tasa de error es aceptable?

Depende del coste del error y de con qué lo comparas. La referencia correcta no es la perfección, sino lo que ocurre hoy sin IA: una persona cansada a última hora también se equivoca. Para tareas con revisión humana posterior se puede convivir con un 5-10 % de error; para procesos que escriben directamente en un sistema sin que nadie mire, hay que exigir 98 % o más y añadir controles.

¿Sirven los rankings públicos de modelos para elegir?

Sirven para descartar y para hacerte una idea general del nivel, pero no para decidir. Miden tareas genéricas que no se parecen a tu operación, y un modelo que va mejor en el ranking puede ir peor con tus documentos y tu vocabulario. La única prueba que decide es la tuya.

---

Si tienes un asistente o un modelo funcionando y no sabes decir con un número si responde bien, empieza por el conjunto de pruebas: es un par de días de trabajo y cambia todas las conversaciones posteriores, incluidas las de precio. Si prefieres que lo miremos juntos sobre tu caso concreto, pide la auditoría o escríbenos y hablemos: en una conversación se ve bastante rápido si lo que tienes montado se puede medir o hay que ordenarlo antes.