La fiabilidad no se arregla cambiando de modelo
Tres semanas de investigación publicada en agosto apuntan al mismo sitio: lo que hace fiable un sistema de IA está fuera del modelo, y casi siempre es más barato de lo que parece.
Cuando algo falla en un proyecto de IA, la primera propuesta suele ser la misma: cambiar a un modelo mejor. Es la reacción natural, porque es la única palanca que se ve desde fuera y la única que se puede comprar el mismo día.
Llevo unas semanas leyendo los resúmenes de lo que se publica en arXiv sobre IA aplicada, y lo que más me ha llamado la atención de agosto es que los trabajos que salieron apuntan casi todos en dirección contraria. Casi ninguno habla del modelo. Hablan del montaje que lo rodea: qué información se le pasa, qué se guarda de lo que va haciendo y qué ocurre cuando una pieza del circuito falla.
Resumo tres cosas que me parecen útiles para una empresa que ya tiene algo en marcha o está a punto de tenerlo.
Que el sistema sepa decir «no lo sé» se construye, no se pide
Cuatro trabajos distintos de la última semana de agosto se ocupan de lo mismo: que el sistema reconozca cuándo no tiene información suficiente para contestar.
Y ninguno lo resuelve escribiendo «si no lo sabes, dilo» en las instrucciones. Lo tratan como una capacidad más del sistema, que se construye aparte y se comprueba aparte, igual que se comprueba que las respuestas sean correctas.
Uno de ellos, antes de responder, clasifica la documentación que ha encontrado en tres casos: suficiente, insuficiente o contradictoria entre sí. Poder decir «estos dos documentos no dicen lo mismo» en lugar de elegir uno en silencio es, en mi experiencia, la forma más habitual de perder la confianza en un asistente montado sobre documentación propia.
Y no es un problema menor: un estudio de agosto sobre ocho sistemas de consulta legal encuentra respuestas inventadas en menos del 10 % de los casos en el mejor sistema, y en cerca de la mitad en el peor. Sobre el mismo tipo de documentación.
Lo que hay que mirar es el rastro, no la respuesta
El hallazgo más incómodo del mes: un equipo estaba probando modelos para un servicio interno de extracción de datos y encontró uno que pasaba el control de calidad sin haber abierto nunca el documento. Una restricción de formato le había cortado el acceso al archivo sin avisar, y el modelo contestó igualmente, inventándose lo que supuestamente había leído.
Comparar la respuesta con la esperada no lo detectaba. Sólo se vio al revisar el registro de qué había hecho el sistema paso a paso.
Otro trabajo del mismo mes va en la misma línea, con los fallos que no dan la cara. Cuando el sistema le pide un dato a otro programa y ese programa devuelve un error, el error se ve y se gestiona. Pero si devuelve una página antigua guardada en memoria, o un precio en negativo, la respuesta llega con la forma correcta y se da por buena.
La conclusión práctica es barata de aplicar: guardar el registro de qué hizo el sistema en cada paso, no sólo qué acabó contestando. Es una línea en el pliego de un proyecto, y es lo que separa un fallo detectado de un fallo que lleva meses ocurriendo.
Con un presupuesto fijo, suele ganar el montaje
Un análisis controlado compara diecisiete formas de construir un mismo sistema —de esos que permiten preguntarle a la base de datos en lenguaje corriente— y mide, pieza por pieza, cuánto acierto aporta cada una y cuánto cuesta.
La conclusión responde a la pregunta que hace todo el mundo: con un presupuesto dado, suele rendir más construir un buen circuito alrededor de un modelo intermedio que poner el modelo más caro del mercado en un circuito pobre.
De todas las piezas que probaron, sólo una aporta siempre y sale barata: ejecutar la consulta de verdad, mirar lo que devuelve la base de datos y corregir con ese resultado delante.
Un apunte para quien ya tiene algo funcionando
Hay un cuarto resultado que conviene tener presente porque llega sin avisar: cuando un proveedor retira una versión y obliga a actualizar, la mejora media esconde casos concretos que empeoran.
En el estudio, actualizaciones que mejoraban 7,3 puntos de media contenían hasta un 8,3 % de casos que salían peor que antes. Y no era ruido: lo comprobaron repitiendo cada caso cincuenta veces.
Es decir, la versión nueva va mejor en conjunto y a la vez rompe cosas que antes funcionaban. Para darse cuenta hace falta tener guardados veinte o treinta casos reales de tu empresa, pasarlos por el sistema antes de actualizar y volver a pasarlos después, comparando. Si eso no se hace, el primero que nota el fallo es un cliente.
Nada de esto exige un presupuesto grande. Guardar el registro de lo que hace el sistema, tener veinte casos de prueba propios y dejar que conteste «esto no lo sé» son decisiones de diseño, no de compra.
Y son, según lo que se publicó en agosto, las que más determinan si lo que montaste sigue funcionando dentro de seis meses.