Cuando trabajé en la división IBM´s Watson, la primera prueba de mi equipo pronto se volvió un desastre, debido a problemas de ampliación. Creábamos una Interfaz de Programación de Aplicaciones-API por sus siglas en inglés- de reconocimiento visual. Nuestra primera «demo» era una simple web que permitía a usuarios «arrastrar y soltar imágenes», pulsar un botón, y recibir un listado de etiquetas que describen aquello que aparece en la imagen.
El propósito de la página era servir de herramienta de ventas a pequeña escala, para mostrar lo que la API era capaz de hacer. Lanzamos la prueba un miércoles y enviamos un link a algunos vendedores interesados. La mañana del sábado, mi teléfono se volvió loco. De alguna forma, nuestra pequeña «demo» logró situarse en la portada de Reddit. De repente nuestra web recibía miles de visitantes por minuto, en vez de los pocos que nos imaginábamos. No la habíamos configurado para crecer, y el sistema intentó ocuparse del tráfico extra -no lo hizo demasiado bien-. De alguna manera esto expuso algunos «bugs» subyacentes en la arquitectura del sistema de soporte de la página, en la que la prueba se sustentaba, lo que terminó por hacer caer al completo un centro de datos IBM -International Business Machine-, del sur de Estados Unidos.
Por suerte dicha corporación tiene numerosos procesos de refuerzo preparados, por lo que no terminamos haciendo daño real a nadie, pero igualmente la experiencia me enseño una valiosa lección: cuando construyas una IA, tienes que estar bien preparado para la ampliación. Afortunadamente, no deberás enfrentarte a un crecimiento inesperado como este, pero aun así, el propósito de toda IA va más allá de crear con éxito un piloto. La meta a largo plazo es implementar la solución IA a la producción, con lo que tu visión también debe seguir creciendo.
Planificar con éxito
Cuando creas tu piloto IA debes planificar constantemente. Cada decisión que hagas debe funcionar no sólo para el piloto, también para el futuro modelo que implementarás al ampliar la producción. Intenta aclararte en los que serán los «production pain points» -puntos de daño de producción-. Estos pueden afectar al marco de trabajo, a colecciones, o al idioma a utilizar en la producción; cómo y dónde implementarás tus modelos, y aquello que necesitarás para monitorearlo. Ponerse al tanto de estos puntos puede ayudar a evitar elecciones que vedarían la ampliación.
Una gran compañía de comercio electrónico se embarcó en un proyecto de Procesamiento de Lenguaje Natural -NLP en inglés-, para analizar sentimientos en su «chatbot» de registro. Buscaba un seguimiento personal con clientes que tuviesen una experiencia negativa. Para comenzar, crearon prototipos de todo lo necesario. Utilizaron para ello Python, lenguaje de programación usado por científicos para información. Este era un anfitrión disponible en colecciones de NLP.
Cuando llegó el momento de implementar el modelo a la producción, descubrieron que querían transferir todo a Scala, otro lenguaje de programación -usado por ingenieros de software, para crear software muy ampliable-. Así, podría funcionar en el ambiente Java del que disponían. Por tanto, para cada decisión que tomes en el piloto, pregunta: ¿podré hacer esto también al ampliar la producción? ¿podré integrar esto a un ambiente de producción, de la misma forma? Si tu prueba toma atajos al confiar en algunas características únicas de un ámbito menor -que podría ser prohibitivo al ampliarse-, o si necesita datos que no existen para el ámbito de producción completo, o si es técnicamente imposible, entonces tu proyecto fallará aunque tu piloto triunfe.
Considerar costes de ampliación
Con suerte, si has planificado bien, para ampliar sólo necesitarás gastar más en recursos. Sin embargo, el coste de ampliación puede ser más de lo que te esperes. La gente suele asumir que, una vez se crea el modelo, ampliará su producción con tan sólo aumentos marginales en costes. Esta gente suele terminar decepcionada.
Las soluciones IA no son como un negocio SaaS -Software como Servicio en inglés-, donde la consumición de recursos crece sólo marginalmente cuando se atraen nuevos clientes. Los modelos IA tienen que ser provistos constantemente de nueva información, para así funcionar y adaptarse a cambios inevitables en el mundo real. Según el problema que estés resolviendo, puedes necesitar recapacitar tu modelo con frecuencia, o este puede requerir nuevos datos para cada cliente que llega. Incluso es posible, aunque no usual, que tus costes de IA se amplíen linealmente con el uso.
Y si no sufres de altos costes por tu piloto, igualmente esto debería ayudarte a hacer el presupuesto de manera efectiva, incluso maximizar la eficiencia del gasto de tu plataforma en Google, AWS… Si adquieres GPUs o Unidades de Procesamiento Gráfico para el año entero, serán más baratos que distribuyéndolos por encargo. El proceso del piloto, si está bien estructurado, te ayudará a capitalizar esos ahorros.
Finalmente, si se hace bien, los costes deberían merecerlo. Piénsalo, sin el modelo IA, tendrías que ampliar todas tus operaciones de negocio manualmente para hacer lo mismo que con él automatizas. Así, incluso con la inversión extra, mientras mantengas los costes de ampliación en mente a la vez que construyes tu piloto, la solución por IA será más barata y te dará mejores resultados que las tareas manuales.
Tendrás que «pivotar»
Sin importar lo mucho que trates de mantener tu piloto consistente, con tus expectativas para el sistema de producción, este siempre será diferente. A veces puedes prever que será distinto, otras no. Como mínimo, la ampliación de producción será mayor, y la información distinta. Ambos cambiarán económicamente tus resultados y de manera imprevista. Debes planificar todo lo que puedas, evitando decisiones que vedarían la ampliación mientras consideras los costes de dicho proceso, pero también debes estar preparado para «pivotar» mientras haces todo esto.
*Artículo publicado originalmente en Appen.
