Alguien cambió la instrucción sin registrar el efecto
Las respuestas cambiaron de tono o de longitud y no hay forma de saber si mejoró o empeoró.
IA aplicada · Evaluación
Una función de IA sin medición no está probada: solo está estrenada
Una función de IA puede variar entre ejecuciones y versiones, según el sistema, su configuración y el proveedor. Por eso complemento las pruebas habituales de software con un conjunto de preguntas con respuesta conocida, otro de preguntas que el sistema no debería poder responder, y medidas antes y después de cada cambio. Para cada configuración, el protocolo fija cuántas veces se ejecuta cada caso y cómo se agregan los resultados. El informe conserva la tasa de acierto, la tasa de abstención y su variabilidad; una sola ejecución no basta para aprobar un comportamiento no determinista. Sin ese conjunto, una muestra elegida sobre la marcha no representa los casos difíciles: alguien retoca una frase, las respuestas mejoran en los tres ejemplos que mira y pueden empeorar en los que no revisa.
- Hacen falta dos conjuntos: preguntas que el sistema puede responder y preguntas que debe dejar sin respuesta.
- Mido el comportamiento de la función antes y después de cada cambio, aunque solo se modifique una palabra de la instrucción.
- La atribución se comprueba aparte: una respuesta correcta con una cita inventada sigue siendo un fallo.
- Los accesos indebidos entre ámbitos de permisos se prueban desde cuentas reales con alcances distintos y se revisan también los puntos de autorización del código; ninguna de las dos comprobaciones basta por sí sola.
Experiencia en evaluación de funciones de inteligencia artificial
Defino tareas, corpus, métricas y criterios de aceptación antes de comparar una función de IA. Registro el modelo, la configuración y el coste de cada ejecución, reviso los errores relevantes con especialistas y vuelvo a evaluar cuando cambia alguna pieza del sistema.
Mi trayectoriaCuándo hace falta
Antes de que la función salga de las manos de quien la construyó.
Llega una queja concreta
Y la única respuesta posible es «vamos a mirarlo», porque no hay ni registro ni medida.
Hay que decidir entre dos proveedores
Y la comparación acaba en una muestra improvisada que no permite estimar la calidad, la variabilidad ni el coste.
El comité pregunta qué garantías existen
Y «el modelo es muy bueno» no puede ser la respuesta.
Cómo lo monto
Seis pasos, y el primero es el que más se salta.
- 01
Recoger casos reales con autorización
Reutilizo preguntas de correos, incidencias o foros solo cuando la finalidad lo permite. Antes de incorporarlas al conjunto, elimino los datos que no son necesarios o sustituyo los identificativos por códigos, documento la finalidad y limito el acceso y la conservación.
- 02
Fijar la respuesta esperada
Para cada pregunta, qué debería contestar y de qué documento debería salir. La respuesta esperada la valida la persona responsable del contenido, no quien desarrolla la función.
- 03
Construir el conjunto imposible
Preguntas cuya respuesta no está en el material, incluidas algunas muy plausibles. Es donde se ve si el sistema sabe callarse.
- 04
Probar los permisos
Las mismas preguntas desde cuentas con distinto acceso, comprobando que no se recupera lo que no corresponde.
- 05
Medir y registrar
Guardo aciertos, abstenciones correctas, citas válidas, latencia, coste y las versiones de instrucción y contenido. Conservo solo las medidas y el contenido imprescindibles para reproducir el resultado, con acceso y plazo definidos.
- 06
Repetir según lo que cambie
Cambiar el modelo, el troceado o la instrucción —aunque sea una palabra— dispara la regresión completa. Un cambio acotado del contenido activa las pruebas afectadas y la política de riesgo determina si también se repite todo el conjunto.
Qué determina el nivel de exigencia de la evaluación
Seis preguntas para no medir de menos ni de más.
- 01
¿Qué pasa si se equivoca?
Si un error puede alterar una calificación o una matrícula, o exponer, modificar o utilizar datos personales fuera de su finalidad y permisos, aplico la exigencia máxima de esta página: conjunto versionado, pruebas de aislamiento, revisión humana continuada y criterio de parada.
- 02
¿Quién recibe la respuesta?
El personal interno con criterio y contexto no afronta el mismo riesgo que un alumno que puede interpretar la respuesta como autorizada y carecer de elementos para comprobarla.
- 03
¿Se puede comprobar la respuesta?
Si la respuesta cita su fuente, el lector puede verificarla. Si no, el sistema debe ser mucho más conservador.
- 04
¿Con qué frecuencia cambia el material?
Cada cambio queda versionado y activa las pruebas afectadas. Los cambios de modelo, troceado o instrucción ejecutan además la regresión completa; para cambios acotados del contenido, la política de riesgo decide cuándo corresponde repetir todo el conjunto.
- 05
¿Hay datos personales de por medio?
Cambia dónde se pueden guardar las trazas, cuánto tiempo y quién puede verlas.
- 06
¿Quién firma que puede salir?
Una persona identificada. Si nadie asume expresamente la aprobación, la función no está lista.
Antes de firmar que puede salir
Ocho comprobaciones.
- El conjunto combina preguntas reales autorizadas y casos adversariales diseñados de forma independiente para cubrir ausencias, permisos y situaciones límite.
- Cada respuesta esperada la ha validado la persona responsable del contenido.
- Existe un conjunto de preguntas sin respuesta posible, con casos plausibles incluidos.
- En el conjunto sin respuesta posible, una abstención correcta cuenta como acierto; en el conjunto de preguntas con respuesta, cuenta como omisión.
- En la primera ejecución se verifican todas las citas una a una. Después de cada cambio se vuelve a comprobar la atribución; si el volumen impide una revisión manual completa, se automatizan las comprobaciones posibles y se revisa una muestra definida según el riesgo.
- Lo pruebo desde cuentas con permisos distintos.
- Cada ejecución guarda versión de modelo, de instrucción y de contenido.
- Hay una persona identificada que aprueba la salida a producción.
Lo que he visto salir mal
Cinco fallos de la propia evaluación.
Conjunto elegido solo por quien construyó
El equipo que construye la función no selecciona por sí solo los ejemplos con los que se aprueba. El conjunto combina preguntas reales obtenidas con autorización y casos adversariales diseñados de forma independiente.
Sin preguntas imposibles
Se mide el acierto y se omite la prudencia. Así he visto aprobar con nota sistemas que luego inventan en producción.
Cita no comprobada
Se da por buena una respuesta correcta cuya cita apunta a un documento que no dice eso.
Evaluación que no se reejecuta
Se hizo una vez, antes del despliegue. Seis cambios después ya no describe el sistema que está funcionando.
Trazas guardadas sin criterio
Conversaciones con datos personales conservadas indefinidamente porque nadie decidió el plazo.
Lo que se hace en su lugar
Tres sustitutos que no aguantan la primera incidencia.
Probar unas cuantas preguntas a mano
Se prueban las que a uno se le ocurren, que son justo las que el sistema responde bien. Los casos incómodos no se le ocurren a quien lo construyó.
Fiarse de las medidas del proveedor
Muchas medidas publicadas se obtienen sobre corpus y tareas distintos de los de la organización. Sirven como referencia, pero no sustituyen una evaluación local que reproduzca el uso, los datos y las condiciones reales.
Dejar la evaluación para después del piloto
Cuando el piloto ha ido bien, medir pierde prioridad; y cuando ha ido mal, no hay con qué comparar.
Qué cambia con el uso
La evaluación también crece.
- Piloto cerrado
Un conjunto pequeño y bien seleccionado puede aportar más que otro grande y mal cubierto; su tamaño y su composición deben justificarse según los casos, el riesgo y la variabilidad esperada.
- Un curso completo
Aparecen preguntas que nadie previó. La muestra de uso real empieza a alimentar el conjunto.
- Toda la institución
Segmento por titulación: lo que funciona en una puede fallar en otra con vocabulario distinto.
- Uso continuado
La deriva pasa a ser el problema principal: pueden cambiar tanto el modelo como el material, y la degradación no se detecta si no se repite la evaluación.
Qué exigir a un proveedor
Cuatro requisitos verificables.
| Requisito | Evidencia exigible | Criterio de aceptación |
|---|---|---|
| Conjunto de evaluación propio | Preguntas, respuestas esperadas y fuentes, entregados y versionados | Construido con preguntas reales de la organización, no genéricas |
| Prueba de abstención | Resultados sobre el conjunto de preguntas sin respuesta posible | El sistema se abstiene en cada una de las preguntas del conjunto |
| Prueba de aislamiento | Ejecución desde cuentas con distintos permisos | Ninguna recuperación fuera del alcance de cada cuenta |
| Repetición y variabilidad por cambio | Registro de varias ejecuciones por caso y configuración, con versiones y regla de agregación | El número de repeticiones, la agregación y la dispersión cumplen el protocolo; una ejecución aislada no aprueba un comportamiento variable |
Referencias
En qué me apoyo
- Marco reguladorReglamento europeo de inteligencia artificial
Establece obligaciones de gestión de riesgo, documentación y supervisión humana según la clasificación del sistema. El calendario de aplicación debe comprobarse siempre en la fuente oficial.
Describo el método que aplico. No incluyo resultados numéricos: dependen tanto del corpus y del caso que publicarlos fuera de contexto sería engañoso.
Blog
Casos, pruebas y fuentes.
En el blog publico casos de evaluación con preguntas, corpus, métricas y resultados que permiten ver por qué se acepta o se rechaza una función.
Ir a blog.albertolarah.comContacto
¿Tenéis una función de IA sin una medición propia?
El primer conjunto exige trabajo inicial, pero deja una base común para comparar cambios y decidir junto con la persona responsable de aprobar la función.
hola@albertolarah.comLinkedIn ↗