Fra ett system til mange

Tenk deg en stor bank eller et forsikringsselskap der kundeserviceavdelingen har bygget en KI-agent for å svare på henvendelser, mens IT-avdelingen har laget en helt annen agent for å automatisere interne prosesser – og en tredje avdeling tester enda et rammeverk for å analysere kontrakter. Hver avdeling har valgt sine egne verktøy, språkmodeller og leverandører, fordi det løste deres problem best der og da.

Dette er situasjonen AWS beskriver i sitt nyeste innlegg på selskapets blogg for maskinlæring. Ifølge AWS er dette ikke noe bedrifter bør forsøke å unngå, men en tilstand de må lære å håndtere. Selskapet kaller det et «multi-alt-miljø»: flere rammeverk, flere språkmodeller, flere leverandører og flere team som alle utvikler seg i sitt eget tempo, side om side i samme organisasjon.

Innlegget er del to i en serie fra AWS om multiagentsystemer – oppsett der flere KI-agenter samarbeider om å løse oppgaver. Del én handlet om hvordan man optimaliserer samspillet mellom agenter innenfor ett og samme bruksområde. Del to tar steget opp til hele virksomheten, der utfordringen ikke lenger er å koordinere noen få agenter, men å drifte mange forskjellige agentsystemer samtidig uten at det oppstår kaos.

Valgfrihet som noe man må styre

Det sentrale poenget i AWS' gjennomgang er at valgfrihet mellom leverandører og modeller ikke lenger bare er en fordel man utnytter i utviklingsfasen – det blir en begrensning som må forvaltes aktivt når systemene settes i produksjon. Ifølge AWS fører forsøk på å tvinge gjennom ett bestemt rammeverk eller én bestemt modell for hele organisasjonen ofte til friksjon: teamene finner omveier, innføringen går saktere, eller avdelingene bygger systemer utenfor de godkjente arkitekturene likevel.

Samtidig advarer AWS mot den motsatte fellen: å bygge applikasjoner så tett sammenvevd med én bestemt modell eller leverandør at det blir vanskelig å bytte når markedet endrer seg – det som gjerne kalles leverandørlåsing. Løsningen selskapet foreslår, er å standardisere ett nivå under selve applikasjonene. Det vil si at identitetsstyring, regelverksetterlevelse, overvåking og trafikkstyring («routing») samles i et felles kontrollag, mens teamene fortsatt står fritt til å velge hvilke rammeverk og modeller de bygger de faktiske agentene med.

Denne inndelingen – mellom et kontrollag og et utførelseslag – er selve bærebjelken i AWS' anbefaling. Kontrollaget fjerner ikke mangfoldet av teknologier i bedriften, men det begrenser skadeomfanget slik at systemene kan utvikle seg uavhengig av hverandre uten å velte hele arkitekturen.

Seks utfordringer som forsterker hverandre

AWS lister opp en rekke problemer som typisk dukker opp når KI-systemene blir mange og forskjellige. Regelverksetterlevelse blir vanskelig å håndheve likt når hvert rammeverk har sin egen måte å definere kontroll og tillatelser på. Integrasjon blir mer komplisert fordi agenter, verktøy og tjenester snakker ulike tekniske «språk» med hverandre. Kostnader og ytelse blir vanskeligere å optimalisere uten løpende justering, noe som ifølge AWS ofte fører til at ressurser brukes ineffektivt.

I tillegg utvides sikkerhetsflaten når agenter kobler seg dynamisk til data, verktøy og andre agenter – tilgangsmønstrene blir mindre forutsigbare. Vedvarende hukommelse i agentene skaper egne utfordringer knyttet til hvor lenge data skal lagres, hvordan de skal isoleres fra hverandre, og om informasjonen forblir konsistent over tid. Til sist påpeker AWS at mange bruksområder krever skreddersydd ytelse som generiske konfigurasjoner ikke kan levere. Selskapet understreker at disse utfordringene forsterker hverandre over tid, og at de derfor krever en løsning på systemnivå – ikke enkeltstående lapper på hvert enkelt problem.

Prinsippene bak en robust arkitektur

Basert på dette skisserer AWS et sett med arkitekturprinsipper som selskapet mener går igjen hos virksomheter som lykkes med denne typen skalering. Det første er skillet mellom kontroll og utførelse: identitet, regelhåndheving, overvåking og kostnadsfordeling sentraliseres, mens selve byggingen og driften av agentene forblir desentralisert ute i teamene.

Overvåking løftes fram som en forutsetning, ikke en tilleggsfunksjon – et felles lag for telemetri (systematisk innsamling av måledata om hvordan systemene oppfører seg) gjør det mulig å følge agenter på tvers av rammeverk og miljøer, spore feil og forbedre systemene uten å være avhengig av verktøy bundet til ett bestemt rammeverk. Regelverksstyring bør etter AWS' vurdering bygges inn som en egenskap ved hele plattformen, ikke kodes inn i hver enkelt agent for seg.

Videre trekker AWS fram dynamisk trafikkstyring: i stedet for å låse en oppgave til en fast modell eller infrastruktur på forhånd, bør systemet fortløpende matche oppgaver mot ressurser basert på kostnad, responstid og nøyaktighet. Produksjonssystemer bør også ha klare garantier for responstid og tilgjengelighet, med reserveløsninger som kretsbrytere og fallback-mekanismer når noe går galt. Mange organisasjoner starter med sentralisert styring av agentsamspillet og beveger seg gradvis mot mer distribuerte, hendelsesdrevne arkitekturer etter hvert som systemene vokser. Kostnads- og ytelsesoptimalisering, som dynamisk modellvalg og mellomlagring av svar («caching»), bør ifølge AWS bygges inn fra starten – ikke legges til etterpå.

AWS-tjenestene som skal bære arkitekturen

I den konkrete delen av innlegget beskriver AWS hvordan selskapets egne tjenester kan fylle rollene i denne arkitekturen. Amazon SageMaker framheves som kjernen for modelltrening, finjustering og driftssetting i stor skala, mens Amazon Bedrock beskrives som et forenklet grensesnitt for rask tilgang til ulike språkmodeller uten at bedriften selv må drifte underliggende infrastruktur. Ifølge AWS lar denne kombinasjonen bedrifter skille selve modelltilgangen fra modelldriften, slik at det blir enklere å bytte modell uten å bygge om hele systemet.

Til styring og trafikkflyt viser AWS til tjenester som AWS Lambda, AWS Step Functions og Amazon API Gateway, samt en nyere funksjon kalt Agent Orchestration on AWS. Identitet og regelverksstyring holdes samlet gjennom AWS Identity and Access Management (IAM) og AWS Organizations, mens overvåking standardiseres med Amazon CloudWatch og AWS X-Ray. Det er verdt å understreke at dette er AWS' egen beskrivelse av sine tjenester, og at selskapet naturlig nok framstiller sin egen portefølje som løsningen på problemet det selv definerer.

Tre mønstre bedrifter kombinerer

AWS beskriver tre typiske mønstre som virksomheter ender opp med, og påpeker at de sjelden står alene. Det første er en intern agentplattform for å automatisere forretningsprosesser, der en felles plattform håndterer modelltilgang, regelverk og kostnader, mens hver avdeling selv bestemmer hvordan de bygger og drifter sine agenter. Det andre er kundevendte agentplattformer, typisk hos programvareleverandører, der isolasjon mellom kunder («tenancy») og driftssikkerhet blir avgjørende – hver forespørsel må bære med seg informasjon om hvilken kunde den tilhører, slik at agenten aldri får tilgang til data den ikke skal ha.

Det tredje mønsteret handler om responstid i sanntidsapplikasjoner, som samtaleassistenter, der trafikkstyring, parallell kjøring av oppgaver og mellomlagring av svar blir avgjørende for brukeropplevelsen. AWS' hovedpoeng er at de fleste store virksomheter kjører alle tre mønstrene samtidig, bygget av forskjellige team med forskjellige verktøy – og at det er den samlede plattformen under disse mønstrene, ikke valget av ett enkelt mønster, som avgjør om systemene kan skaleres sammen uten at styringen smuldrer opp.