Por que a arquitectura de IA é diferente das aplicacións clásicas
Os sistemas de IA teñen requisitos específicos que os distinguen das aplicacións web típicas. Os modelos de linguaxe requiren recursos computacionais significativos, pero non sempre nin en todas partes. Diferentes compoñentes do sistema teñen perfis de carga diametralmente opostos: o módulo de inferencia GPU é o pescozo de botella de recursos, a capa de API debe xestionar miles de peticións paralelas, e os procesos de adestramento funcionan por lotes e poden durar horas. A arquitectura debe telo en conta.
Argumentos a prol do monolito ao inicio
A maioría de proxectos de IA deberían comezar como monolito. As razóns son prosaicas: a arquitectura monolítica é máis sinxela de depurar, máis fácil de entender para un novo equipo e máis rápida para iterar. Cando o sistema está en fase experimental e os límites entre compoñentes aínda se están definindo, a división prematura en microservizos causa máis prexuízos que beneficios.
Un erro clásico é deseñar decenas de microservizos antes de que o sistema atenda o primeiro usuario real. Os patróns de uso descoñecidos tradúcense en límites incorrectos dos servizos, que despois xeran enormes custos de refactorización.
Cando os microservizos son a elección correcta
A migración a microservizos ten sentido cando aparecen problemas concretos e medibles co monolito:
- Requisitos de escalado diferentes — o módulo OCR require 10x máis recursos durante as campañas, o resto do sistema permanece estable.
- Ciclos de despregamento independentes — o equipo de modelos ML desprega novas versións varias veces ao día, e os cambios no módulo de informes unha vez ao mes.
- Illamento de fallos — un erro nun compoñente non debería interromper o traballo dos outros.
- Pilas tecnolóxicas diferentes — o módulo de procesamento de imaxes require bibliotecas Python non dispoñibles na pila principal.
Estratexias de migración desde o monolito
A migración segura basease no patrón Strangler Fig: retirar gradualmente funcionalidades do monolito e substituirlas por servizos independentes, mantendo o sistema en funcionamento durante todo o proceso. A clave é identificar os límites de dominio naturais — non cortar artificialmente por liñas técnicas, senón dividir segundo a lóxica de negocio.
O primeiro candidato a ser extraído debería ser o compoñente que: está ben definido funcionalmente, ten unha API clara e estable, e xera máis problemas polas diferenzas nos requisitos de escalado. Normalmente, este é precisamente o módulo de inferencia de modelos de IA.
Orquestración multiaxente e arquitectura de servizos
Os sistemas multiaxente de ESKOM.AI operan por riba da capa de microservizos tradicionais — os axentes de IA individuais poden utilizar tanto unha aplicación de negocio monolítica como un ecosistema de microservizos. O fundamental é deseñar as interfaces de maneira que a arquitectura interna do sistema obxectivo non limite as posibilidades de integración coa lóxica dos axentes.