Cuando especificas una funcion con un componente de IA, el criterio de aceptacion deja de ser «dado X el sistema devuelve Y». El criterio de aceptacion pasa a ser una eval: un conjunto de datos etiquetado, una funcion de puntuacion y una puntuacion objetivo que el sistema debe superar antes del lanzamiento y volver a superar despues de cada cambio de modelo o de prompt. La regla es simple: si no puedes escribir la eval, la funcion todavia no esta especificada. Este articulo desglosa los cuatro componentes de un criterio de aceptacion probabilistico y como escribirlos en la practica.
Que se rompe exactamente en una especificacion tradicional
Una especificacion clasica se apoya en un supuesto: la misma entrada produce siempre la misma salida. Toda la estructura de pruebas, definiciones y condiciones de salida se deriva de el. En el momento en que un componente del sistema es un modelo de lenguaje, ese supuesto se derrumba, y con el todas las herramientas construidas encima.
La expresion mas tangible de esto es la prueba de aceptacion. «El usuario pulsa enviar y recibe un resumen del ticket» no es un requisito comprobable, porque no existe una unica respuesta correcta. Dos resumenes distintos pueden ser ambos excelentes, y un tercero que parece similar puede estar completamente equivocado. Lo que hace falta es definir un rango de comportamiento aceptable en lugar de un resultado unico.
La prueba que ahorra meses de desarrollo: antes de escribir una linea de codigo, intenta escribir la eval. Si no puedes definir que cuenta como buena respuesta y como se mide, el requisito sigue siendo vago. Las funciones que se atascan en piloto casi siempre fallan en esta fase, no en la implementacion.
Los cuatro componentes de un criterio de aceptacion de IA
| Componente | Que define | Ejemplo |
|---|---|---|
| Descripcion del comportamiento | Que debe hacer el sistema, formulado para admitir variabilidad | Un resumen de ticket que contenga el problema, la accion tomada y el estado |
| Umbral de evaluacion | Una puntuacion minima sobre un conjunto de prueba reservado que nunca se uso en desarrollo | El 90% de los resumenes incluye los tres elementos |
| Restriccion de seguridad | Que cuenta como salida inaceptable, con independencia de la puntuacion | Ningun resumen contiene nunca el telefono de un cliente |
| Punto de revision humana | Que ocurre en los casos que el modelo no puede resolver | Una puntuacion de confianza baja envia el ticket a una cola humana |
La diferencia entre el segundo y el tercer componente es fundamental. El umbral es estadistico y tolera fallos aislados. La restriccion es binaria y no tolera ninguno. Sin esa separacion acabas con una funcion que aprueba con un 92% de exito mientras una fuga de datos se esconde dentro del 8% restante.
Como construir una eval sin un equipo de investigacion
Una eval no es un proyecto. En el caso tipico son tres activos pequenos mantenidos en el tiempo:
Un conjunto de datos. De 50 a 150 casos reales del sistema existente, incluidos los molestos. Importa que salgan del campo y no que se inventen, porque los casos inventados siempre son demasiado comodos. Adjunta a cada caso la respuesta que daria un experto en la materia.
Una funcion de puntuacion. No tiene por que ser sofisticada. En muchos casos basta con comprobar la presencia de elementos obligatorios, la conformidad con una estructura definida o la coincidencia de palabras clave. Donde haga falta juicio, puedes usar un modelo como juez, siempre que muestrees manualmente parte de las puntuaciones para confirmar que el propio juez no esta derivando.
Un umbral y una linea base. Mide una vez antes de cambiar nada. Sin linea base no puedes saber si un cambio de prompt mejoro o rompio algo, y la mayoria de los equipos lo descubre demasiado tarde.
Cuando ejecutarla: una eval no es una comprobacion puntual antes de publicar. Se vuelve a ejecutar en cada cambio de modelo, cada edicion de prompt y cada cambio en una fuente de datos que alimente el sistema. Eso es precisamente lo que separa una eval de un caso de prueba, y por eso conviene conectarla al proceso de build desde el primer dia.
Seis secciones que anadir al documento de especificacion
| Seccion | Que va dentro |
|---|---|
| Especificacion del comportamiento del modelo | Que debe hacer el modelo, en que tono y que queda fuera de alcance |
| Umbrales de aceptacion | Las metricas y las puntuaciones minimas, incluido sobre que datos se miden |
| Catalogo de modos de fallo | La lista de formas en que la funcion puede fallar y que ocurre en cada una |
| Restricciones de comportamiento | Lineas rojas binarias: que no debe aparecer nunca en la salida |
| Plan de evaluacion | El conjunto de datos, el metodo de puntuacion y la frecuencia de ejecucion |
| Datos y privacidad | Que datos entran en el prompt y con que nivel de clasificacion |
La ultima seccion conecta directamente con tu politica de clasificacion de datos. Si todavia no has definido una, el modelo de cuatro niveles es el punto de partida, porque sin el la especificacion definira una capacidad que no tienes permiso para ejecutar.
El catalogo de modos de fallo: la seccion que mas compensa escribir
En un sistema determinista un modo de fallo es un error. En un sistema con componente de IA un modo de fallo suele ser una respuesta que parece perfectamente correcta y no lo es. Por eso el catalogo tiene que enumerar los fallos por lo que experimenta el usuario, no por lo que reporta el sistema.
Cuatro son especialmente habituales: una respuesta incorrecta dada con seguridad, que exige citar fuentes para poder verificarla; una negativa a responder una pregunta legitima, que exige una ruta alternativa; una respuesta parcial que omite una condicion material; y la deriva con el tiempo, cuando la fuente de datos cambia y la salida se degrada sin que nadie toque una linea de codigo. Este ultimo es el motivo principal por el que una eval debe ejecutarse de forma periodica y no solo antes de publicar.
Que implica esto para el calendario y el presupuesto
El impacto practico es que el esfuerzo se desplaza. En una especificacion clasica la mayor parte del tiempo va a definir pantallas y flujos. En una funcion de IA una parte significativa se mueve a recopilar y etiquetar casos de prueba, y eso es trabajo de experto en la materia, no de desarrollador. Presupuestalo de forma explicita, porque de lo contrario se recorta y llegas a publicar sin manera de saber si el sistema funciona.
Un segundo desplazamiento: la funcion nunca termina. Arrastra un coste de mantenimiento continuo de ejecutar la eval y mantener el conjunto de prueba. Cuando calcules la viabilidad, ese coste pertenece a la economia unitaria desde el principio y no debe aflorar en el segundo trimestre.
Preguntas frecuentes
Que es una eval y en que se diferencia de una prueba de aceptacion normal?
Una eval es un conjunto de datos etiquetado junto con una funcion de puntuacion y un umbral minimo. Una prueba de aceptacion normal comprueba una unica salida y devuelve aprobado o fallo, mientras que una eval mide una distribucion de calidad sobre decenas de casos y se vuelve a ejecutar en cada cambio de modelo, prompt o fuente de datos.
Cuantos casos de prueba hacen falta para empezar?
Entre 50 y 150 casos reales del sistema existente basta para la mayoria de las funciones. Lo importante es que se recojan del campo y no se inventen, y que incluyan los casos dificiles y no solo los comodos.
Como se escriben criterios de aceptacion para una salida sin una unica respuesta correcta?
Define cuatro componentes: una descripcion del comportamiento que admita variabilidad, un umbral de evaluacion sobre un conjunto de prueba reservado, una restriccion de seguridad binaria que no tolere ninguna excepcion y una ruta de derivacion a una persona para los casos que el modelo no pueda resolver.
Por que separar el umbral de evaluacion de la restriccion de seguridad?
Porque el umbral es estadistico y tolera un porcentaje de fallos, mientras que la restriccion es binaria. Sin esa separacion una funcion puede aprobar con una puntuacion alta mientras una brecha grave, como exponer datos personales, se esconde dentro del porcentaje de fallo.
Se puede usar un modelo como juez para puntuar la salida?
Si, y es un metodo habitual donde hace falta juicio. La condicion es muestrear manualmente parte de las puntuaciones y compararlas con el juicio humano, para confirmar que el propio juez no deriva con el tiempo.
Esta guia forma parte de una serie sobre negocio digital: