La diferencia entre ingenieria de IA y ingenieria de software que nadie te cuenta

TL;DR

Los bottleneck han cambiado

En la ingenieria de software tradicional, en los sistemas desplegados dentro de nuestra empresa, generalmente la latencia era uno de las principales preocupaciones, uno de los elementos a equilibrar frente a otro tipo de ganancias. Un limitador en cuanto a la segregación, en cuanto a tener en cuenta el nu mero de comunicaciones entre piezas, de lecturas I/O este tipo de operaciones que siempre hemos considerado “lentas” la atención del usuario es lo principal y superar las décimas de sgeundo de respuesta podía hacer que el usuario dejase de consumir nuestro servicio/aplicación/web.

Llegamos a la era de la IA y ahora estamos acostumbrando al usuario a trabajar en otro ttipo de tiempos, en los mejores escenarios una respuesta de IA completa puede tomar varios segundos, incluso en otro tipo de generaciones o de procesos mas costosos que una simple pregunta al modelo estamos acostumbrando a los usuarios a que tiempos de espera de minutos sean razonables.

Es por ello que este es un nuevo factor a tener en cuenta a la hora de diseñar arquitecturas de soluciones que envuelvan a la IA generativa, como la agéntica, wrappers o sistemas de otro tipo.

bajo el nuevo paradigma, no hay problema en que nos simplifiquemos la vida en el mantenimiento, una segregación mayor en microservicios más pequeños, que antes podía verse como un problema por incrementar latencia, ahora es más que aceptable, esas decimas de segundo adicionales (en muchos casos estamos hablando de milisegundos y optimizaciones que nunca han sido).

Esto no quiere decir que la atención del usuario sea infinita, tan solo se han creado nuevas herramientas para mantener al usuario atento, pero menos exhaustivos que antes, mientras que originalmente se priorizaba dar una respuesta completa y correcta desde un primer principio (no estamos manteniendo la atencion del usuario, solo estamos dandole su resultado). Ahora hay que ser ingeniosos manteniendo la atención, el streaming de texto, incluso ilusiones de procesamiento que pueden estar inclluso moclkeadas (mostrar hints del hilo de pensamiento del modelo, mocks de los pasos que estan ocurriendo por detras en nuestro sistema). Y te diré un secreto de desarrollador, estos pasos ni siquiera hace falta que sean veridicos. Recuerdo un sistema agéntico que desarrollé para dar soporte a unos agentes de ventas, en el origen, el frontal no mostraba nignun tipo de output cuando el usuario enviaba un mensaje, el feedback fue evidente, que era muy lento, que no sabian si funcionaba. La solución? Mismos tiempos de respuesta, le di un nombre al asistente virtual y mientras el sistema agéntico procesaba una respuesta, se muestra un mensaje simple y dinámico y un spinner. “Recibiendo respuesta, buscando en la base de datos, elaborando respuesta. No volvió a habver una queja relativa a la latencia.

Últimamente he estado comiendome la cabeza para como orquestar la exposicion de diferentes frameworks de sistemas de agentes de forma unificada, pero de forma que el desarrollo sea sencillo para mi equipo, el boilerplate de codigo que hay que incorporar para cumplir un estándar, por ejemplo cumplir con la API de openai desarrollando un agente en ADK, n8n o LangChain, es muy grande, y cada agenbte debería estar desplegado en su propio microservicio, ya que sus dependencias pueden ser muy diferetes. Esta pensamiento me ha hecho darme cuenta de la solcuion correcta, no hace falta que sea parte del mismo microservicio, es mucho más comodo exponwr cada framework con su API caracteristica, y posteriormente añadir un gateway de adaptación de esa API al estándar que queremos. ¿Incorpora latencia? Sí. ¿Y qué? NO es el bottleneck, NO es la limitacion de nuestro sistema, nuestra limitacion está en la llamada al proveedor de LLMs y esa latencia no se está reduciendo en los últimos años para que tengamos que empezar a preocuparnos de añadir algunas fracciones de segundo adicionales al sistema.