La IA acelera el desarrollo y normaliza los fallos que nadie investiga
Un ensayo sobre Jev, el modelo de TypeSafe AI que devuelve valores tipados con una probabilidad asociada, sostiene que usarlo sin evaluaciones convierte el 'a veces falla' en respuesta aceptable.
TypeSafe AI vende Jev como un modelo rápido y barato que devuelve valores tipados con una probabilidad asociada. La promesa es que se puede montar en producción en poco tiempo. El problema, según este análisis, no es el modelo: es lo que la gente hace con él.
Nadie que lo compra está corriendo evaluaciones. Se lanzan preguntas opacas a Jev y vuelven respuestas opacas con un número al lado. Así se tacha la casilla de "con IA" y se publica antes del viernes; cuando la lógica de aguas abajo se rompe, queda el encogimiento de hombros: la IA se equivoca. Presupuestos de error, modos de fallo, conjuntos de prueba: todo eso se ve luego. La tasa de fallo ya la descubrirá el usuario.
Las puntuaciones de confianza no vienen calibradas
El argumento que suele salir aquí es que Jev entrega puntuaciones de confianza. Para hacer algo sensato con ellas hacen falta dos cosas: saber cómo están calibradas y tener un modelo del coste de la incertidumbre. De lo primero, la publicidad del producto habla de resultados en benchmarks, no de calibración. Hay un cookbook sobre usar las puntuaciones para recorrer un árbol de clasificación, pero eso no dice nada sobre su calidad. En el mejor de los casos la gente las usa por costumbre; en el peor, son la excusa de por qué falló la llamada a la API.
Quién responde cuando algo se rompe
Cuando un botón de una web no funciona, hay un modelo mental de lo que debía pasar: el DNS está mal, alguien desplegó algo con un error de sintaxis en JavaScript por un camino concreto, un handler lanzó una excepción que no esperaba. Aunque solo tengas un 500, das por hecho que hay una persona cuyo trabajo es entender por qué ese endpoint devuelve 500. La propiedad del fallo está definida, aunque sea opaca.
Con un modelo opaco esa cadena se corta. El usuario no puede seguir el fallo hasta una causa concreta, y el resultado es la normalización de lo inexplicable. El autor no teme que haya más fallos según se acelere el desarrollo con LLM: ya los hay, y es parte del precio de construir de una forma nueva. Teme que "a veces falla" se convierta en el punto final aceptado de la investigación. Como recordatorio de cuánta accountability se tolera, ahí está el caso de Bill Gates y Movie Maker: todo el mundo asumió que era problema de alguien, no necesariamente suyo.
La ironía es que buena parte del QA automatizado que falta se debe a falta de tiempo de ingeniería, y la evaluación que justificaría o descartaría Jev está a unos pocos prompts de distancia. Se están construyendo sistemas donde ni quien los usa ni quien los hace parece tener interés en comprobar si hay un cuerpo detrás de la puerta.
