Zergatik da AA arkitektura aplikazio klasikoetatik ezberdina
AA sistemek eskakizun espezifikoak dituzte web aplikazio tipikoetatik bereizten dituztenak. Hizkuntza-modeloek konputazio-baliabide esanguratsuak behar dituzte, baina ez beti eta ez nonahi. Sistemaren osagai ezberdinek karga-profil diametralki ezberdinak dituzte: GPU inferentzia-modulua baliabideen botila-lepoa da, API geruzak milaka eskaera paralelo kudeatu behar ditu, eta entrenamendu-prozesuak loteka funtzionatzen dute eta orduak iraun ditzakete. Arkitekturak hori kontuan hartu behar du.
Hasieran monolitoaren aldeko argudioak
AA proiektu gehienek monolito gisa hasi beharko lukete. Arrazoiak prosaikoak dira: arkitektura monolitikoa arazteko sinpleagoa da, talde berri batek ulertzeko errazagoa eta iteratzeko azkarragoa. Sistema fase esperimentalean dagoenean eta osagaien arteko mugak oraindik finkatzen ari direnean, mikrozerbitzuetan goiztiarra den banaketak kalte gehiago ekartzen du onura baino.
Errore klasikoa da hamarkadetako mikrozerbitzuak diseinatzea sistemak lehen erabiltzaile erreala zerbitzatu aurretik. Erabilera-eredu ezezagunek zerbitzu-mugak oker definitzea dakar, eta horrek geroago birfaktorizazio-kostu handiak sortzen ditu.
Noiz dira mikrozerbitzuak aukera egokia
Mikrozerbitzuetara migrazioak zentzua du monolitoarekin arazo zehatz eta neurgarriak agertzen direnean:
- Eskalatzeko eskakizun desberdinak — OCR moduluak 10 aldiz baliabide gehiago behar ditu kanpainetan, gainerako sistema egonkor mantentzen da.
- Inplementazio-ziklo independenteak — ML modelen taldeak egunean hainbat aldiz inplementatzen ditu bertsio berriak, eta txosten-moduluko aldaketak hilean behin.
- Hutsegitoen isolamendua — osagai bateko errore batek ez luke gainontzekoen lana eten behar.
- Pila teknologiko desberdinak — irudi-prozesatze moduluak pila nagusian ez dauden Python liburutegiak behar ditu.
Monolitotik migrazio-estrategiak
Migrazio segurua Strangler Fig ereduan oinarritzen da: pixkanaka funtzionalitateak monolitotik kentzea eta zerbitzu independenteekin ordezkatzea, sistema prozesu osoan zehar martxan mantendu bitartean. Gakoa domeinu-muga naturalak identifikatzea da — ez lerro teknikoetatik artifizialki moztea, negozio-logikaren arabera banatzea baizik.
Ateratzeko lehen hautagaiak honako hau izan behar du: funtzionalki ondo definituta dagoena, API argi eta egonkorra duena, eta eskalatze-eskakizunen desberdintasunengatik arazo gehien sortzen dituena. Normalean, hau hain zuzen ere AA modelen inferentzia-modulua da.
Orkestrazio multiagentea eta zerbitzu-arkitektura
ESKOM.AI-ren sistema multiagenteek ohiko mikrozerbitzuen gaineko geruzan funtzionatzen dute — AA agente indibidualek enpresa-aplikazio monolitiko bat edo mikrozerbitzu-ekosistema bat erabil dezakete. Funtsezkoa da interfazeak diseinatzea helburu-sistemaren barneko arkitekturak agente-logikarekin integratzeko aukerak mugatu ez ditzan.