AIOS: Operativsystem til LLM-agenter

Over de sidste seks årtier er operativsystemer udviklet gradvist, fra simple systemer til komplekse og interaktive operativsystemer, der driver i dagens enheder. Oprindeligt fungerede operativsystemer som en bro mellem computerhardwares binære funktioner, såsom gate-manipulation, og bruger niveau-opgaver. Over årene er de dog udviklet fra simple batch-job-behandlings-systemer til mere avancerede processtyrings-teknikker, herunder multitasking og tidsdeling. Disse fremskridt har gjort det muligt for moderne operativsystemer at håndtere en bred vifte af komplekse opgaver. Introduktionen af grafiske brugergrænseflader (GUI’er) som Windows og MacOS har gjort moderne operativsystemer mere brugervenlige og interaktive, samtidig med at de har udvidet OS-økosystemet med runtime-biblioteker og et omfattende sæt af udvikler-værktøjer.

Seneste innovationer inkluderer integrationen og implementeringen af Large Language Models (LLM’er), der har revolutioneret forskellige industrier ved at låse op for nye muligheder. Mere nylig har LLM-baserede intelligente agenter vist bemærkelsesværdige evner, opnået menneske-lignende præstationer på et bredt spektrum af opgaver. Disse agenter er dog stadig i de tidlige udviklingsfaser, og nuværende teknikker står over for flere udfordringer, der påvirker deres effektivitet og efficiens. Almindelige problemer inkluderer underoptimal planlægning af agent-anmodninger over den store sprogmodel, kompleksiteter i integration af agenter med forskellige specialiseringer og vedligeholdelse af kontekst under interaktioner mellem LLM’en og agenten. Den hurtige udvikling og øgede kompleksitet af LLM-baserede agenter fører ofte til flaskehalse og underoptimal ressourceanvendelse.

For at løse disse udfordringer vil denne artikel diskutere AIOS, et LLM-agent-operativsystem designet til at integrere store sprogmodeller som “hjernen” i operativsystemet, effektivt givende det en “sjæl”. Specifikt sigter AIOS-rammen mod at facilitere kontekstskift mellem agenter, optimere ressourceallokering, tilbyde værktøjservice til agenter, vedligeholde adgangskontrol og muliggøre samtidig udførelse af agenter. Vi vil dykke dybt ind i AIOS-rammen, udforske dens mekanismer, metode og arkitektur, og sammenligne det med state-of-the-art-rammer. Lad os dykke ind.

Efter at have opnået bemærkelsesværdig succes med store sprogmodeller er næste fokus for AI- og ML-industrien at udvikle autonome AI-agenter, der kan operere uafhængigt, træffe beslutninger på egen hånd og udføre opgaver med minimal eller ingen menneskelige indgreb. Disse AI-baserede intelligente agenter er designet til at forstå menneskelige instruktioner, behandle information, træffe beslutninger og tage passende handlinger for at opnå en autonom tilstand, med udviklingen af store sprogmodeller åbner nye muligheder for udviklingen af disse autonome agenter. Nuværende LLM-rammer, herunder DALL-E, GPT og flere, har vist bemærkelsesværdige evner til at forstå menneskelige instruktioner, resonere og løse problemer, samt interagere med menneskelige brugere og eksterne miljøer. Bygget oven på disse kraftfulde og kapable store sprogmodeller har LLM-baserede agenter stærke opgave-udfyldelsesevner i diverse miljøer, fra virtuelle assistenter til mere komplekse og avancerede systemer, der involverer problemløsning, resonnering, planlægning og udførelse.

Figuren ovenfor giver et overbevisende eksempel på, hvordan en LLM-baseret autonom agent kan løse virkelige opgaver. Brugeren anmoder systemet om rejseinformation, hvorefter rejseagenten bryder opgaven ned i udførbare trin. Derefter udfører agenten trinnene sekventielt, booker fly, reserverer hoteller, behandler betalinger og mere. Under udførelsen af trinnene adskiller disse agenter sig fra traditionelle software-applikationer ved deres evne til at vise beslutningstagningsevner og inkorporere resonnering i udførelsen af trinnene. Sammen med en eksponentiel vækst i kvaliteten af disse autonome agenter har belastningen på funktionaliteten af store sprogmodeller og operativsystemer øget, og et eksempel herpå er, at prioritering og planlægning af agent-anmodninger i begrænsede store sprogmodeller udgør en betydelig udfordring. Derudover kan genereringsprocessen for store sprogmodeller blive en tidskrævende opgave, når man har at gøre med lange kontekster, og det er muligt for planlæggeren at suspendere den resulterende generering, hvilket rejser et problem om at udvikle en mekanisme til at snapshot den nuværende generationsresultat for sprogmodellen. Dette medfører, at pause/fortsæt-adfærd er aktiveret, når den store sprogmodel ikke har afsluttet respons-genereringen for den nuværende anmodning.

For at løse de nævnte udfordringer tilbyder AIOS, et stort sprogmodel-operativsystem, aggregater og modul-isolation af LLM- og OS-funktioner. AIOS-rammen foreslår en LLM-specifik kernel-design i et forsøg på at undgå potentielle konflikter mellem opgaver, der er tilknyttet den store sprogmodel, og dem, der ikke er det. Den foreslåede kernel adskiller operativsystem-lignende pligter, især de, der overvåger LLM-agenter, udviklingsværktøjer og deres respektive ressourcer. Som følge heraf forsøger LLM-kernen at forbedre koordinationen og styringen af aktiviteter relateret til LLM’er.

AIOS: Metodik og Arkitektur

Som du kan se, er der seks store mekanismer involveret i AIOS-rammens funktionsmåde.

• Agent-planlægger: Agent-planlæggerens opgave er at planlægge og prioritere agent-anmodninger for at optimere udnyttelsen af den store sprogmodel.

• Kontekst-manager: Kontekst-managernes opgave er at understøtte snapshots samt genskabe den midlertidige generationsstatus i den store sprogmodel, samt kontekst-vindue-styring af den store sprogmodel.

• Hukommelses-manager: Hukommelses-managernes primære ansvar er at tilbyde midlertidig hukommelse til interaktions-loggen for hver agent.

• Lagring-manager: Lagrings-managernes ansvar er at.persistere interaktions-loggene for agenter til langsigtede lagringsmedier til fremtidig hentning.

• Værktøjs-manager: Værktøjs-managernes mekanisme styrer opkald til eksterne API-værktøjer.

• Adgangs-manager: Adgangs-managernes ansvar er at gennemtvinge privatlivs- og adgangskontrol-politikker mellem agenter.

Ud over de ovennævnte mekanismer har AIOS-rammen en lagdelt arkitektur, der er inddelt i tre distinkte lag: applikationslaget, kernel-laget og hardware-laget. Den lagdelte arkitektur, der er implementeret af AIOS-rammen, sikrer, at ansvarerne er fordelt jævnt over systemet, og at de øvre lag abstraherer kompleksiteterne i lagene under dem, hvilket muliggør interaktioner ved hjælp af bestemte moduler eller grænseflader, hvilket forbedrer modulariteten og forenkler system-interaktioner mellem lagene.

Startende med applikationslaget bruges dette lag til at udvikle og implementere applikations-agenter, såsom matematik- eller rejse-agenter. I applikationslaget tilbyder AIOS-rammen AIOS-software-udviklingskit (AIOS SDK) med en højere abstraktion af system-kald, der forenkler udviklingsprocessen for agent-udviklere. Software-udviklingskitet, der tilbydes af AIOS, tilbyder et rigt værktøjsæt til at faciliterer udviklingen af agent-applikationer ved at abstrahere kompleksiteterne af de lavere niveau-systemfunktioner, hvilket tillader udviklere at fokusere på funktionaliteten og den væsentlige logik af deres agenter, hvilket resulterer i en mere effektiv udviklingsproces.

Herefter er kernel-laget yderligere inddelt i to komponenter: LLM-kernen og OS-kernen. Begge OS-kernen og LLM-kernen tjener de unikke krav til LLM-specifikke og ikke-LLM-operationer, med den forskel, der tillader LLM-kernen at fokusere på store sprogmodel-specifikke opgaver, herunder agent-planlægning og kontekst-styring, aktiviteter, der er essentielle for håndtering af aktiviteter relateret til store sprogmodeller. AIOS-rammen koncentrerer sig primært om at forbedre den store sprogmodel-kernel uden at ændre strukturen af den eksisterende OS-kernel væsentligt. LLM-kernen er udstyret med flere nøgle-moduler, herunder agent-planlægger, hukommelses-manager, kontekst-manager, lagrings-manager, adgangs-manager, værktøjs-manager og LLM-system-kald-grænsefladen. Komponenterne i kernel-laget er designet til at løse de forskellige udførelses-krav for agent-applikationer, hvilket sikrer effektiv udførelse og styring inden for AIOS-rammen.

Til sidst har vi hardware-laget, der består af de fysiske komponenter i systemet, herunder GPU, CPU, periferienheder, disk og hukommelse. Det er vigtigt at forstå, at systemet af LLM-kerner ikke kan interagere direkte med hardwaren, og disse kald grænseflade med system-kaldene af operativsystemet, der i sin tur styrer hardware-ressourcerne. Denne indirekte interaktion mellem LLM-kernens system og hardware-ressourcerne skaber et lag af sikkerhed og abstraktion, der tillader LLM-kernen at udnytte hardware-ressourcerne uden at kræve direkte styring af hardwaren, hvilket faciliterer vedligeholdelsen af integriteten og efficiensen af systemet.

Implementering

Som nævnt ovenfor er der seks store mekanismer involveret i AIOS-rammens funktionsmåde. Agent-planlæggeren er designet til at kunne håndtere agent-anmodninger på en effektiv måde og har flere udførelses-trin i modsætning til en traditionel sekventiel udførelses-paradigme, hvor agenten behandler opgaverne i en lineær måde med trin fra samme agent, der behandles først, før man går videre til næste agent, hvilket resulterer i øgede ventetider for opgaver, der opstår senere i udførelses-sekvensen. Agent-planlæggeren anvender strategier som Round Robin, First In First Out og andre planlægnings-algoritmer til at optimere processen.

Kontekst-managernes er designet til at kunne håndtere konteksten, der gives til den store sprogmodel, og genereringsprocessen, givet den bestemte kontekst. Kontekst-managernes involverer to afgørende komponenter: kontekst-snapshot og genskabelse, samt kontekst-vindue-styring. Kontekst-snapshot- og genskabelse-mekanismen, der tilbydes af AIOS-rammen, hjælper med at mildne situationer, hvor planlæggeren suspenderer agent-anmodningerne, som vist i følgende figur.

Som vist i følgende figur er det hukommelses-managernes ansvar at håndtere midlertidig hukommelse inden for en agents livscyklus og sikre, at data er gemt og tilgængelig kun, når agenten er aktiv, enten under kørsel eller når agenten venter på udførelse.

På den anden side er lagrings-managernes ansvar at bevare data på lang sigt og at overvåge lagringen af information, der skal gemmes for en ubestemt periode, ud over en enkelt agents aktivitetstid. AIOS-rammen opnår permanent lagring ved hjælp af en række varige medier, herunder cloud-baserede løsninger, databaser og lokale filer, hvilket sikrer data-tilgængelighed og integritet. Derudover er det værktøjs-managernes ansvar i AIOS-rammen at styre en varieret række af API-værktøjer, der forbedrer funktionaliteten af de store sprogmodeller, og følgende tabel summerer, hvordan værktøjs-managernes integrerer almindelige værktøjer fra forskellige ressourcer og klassificerer dem i forskellige kategorier.

Adgangs-managernes organiserer adgangskontrol-operationer inden for distinkte agenter ved at administrere en dedikeret privilegie-gruppe for hver agent og nægter en agent adgang til dens ressourcer, hvis de er ekskluderet fra agentens privilegie-gruppe. Derudover er adgangs-managernes også ansvarlig for at samle og vedligeholde overvågnings-logfiler, der forbedrer systemets gennemsigtighed yderligere.

AIOS: Eksperimenter og Resultater

Evalueringen af AIOS-rammen er guidet af to forsknings-spørgsmål: først, hvordan er AIOS-planlægnings-præstationen i forbedring af balance og ventetid, og anden, om svaret fra LLM’en til agent-anmodninger er konsistent efter agent-suspension?

For at besvare konsistens-spørgsmålet kører udviklerne hver af de tre agenter individuelt og herefter udfører disse agenter i parallel, og forsøger at fange deres output under hver fase. Som vist i følgende tabel opnår BERT- og BLEU-scores værdien 1,0, hvilket indikerer en perfekt alignment mellem output, der er genereret i enkelt-agent- og multi-agent-konfigurationer.

For at besvare efficiens-spørgsmålet gennemfører udviklerne en sammenlignende analyse mellem AIOS-rammen, der anvender FIFO eller First In First Out-planlægning, og en ikke-planlagt tilgang, hvor agenterne kører samtidigt. I den ikke-planlagte indstilling udføres agenterne i en foruddefineret sekventiel rækkefølge: Matematik-agent, Fortælling-agent og Rec-agent. For at vurdere den tidsmæssige efficiens anvender AIOS-rammen to metrikker: ventetid og udførelsestid, og da agenterne sender multiple anmodninger til den store sprogmodel, beregnes ventetiden og udførelsestiden for enkelt-agenter som gennemsnittet af ventetiden og udførelsestiden for alle anmodninger. Som vist i følgende tabel viser den ikke-planlagte tilgang tilfredsstillende præstation for agenter tidligt i sekvensen, men lider under forlængede ventetider og udførelsestider for agenter senere i sekvensen. På den anden side regulerer planlægnings-tilgangen, der er implementeret af AIOS-rammen, både ventetid og udførelsestid effektivt.

Endelige Tanker

I denne artikel har vi talt om AIOS, et LLM-agent-operativsystem, der er designet til at indlejre store sprogmodeller i operativsystemet som “hjernen” i operativsystemet, hvilket giver operativsystemet en “sjæl”. For at være mere specifik er AIOS-rammen designet med det formål at facilitere kontekst-skift mellem agenter, optimere ressource-allokering, tilbyde værktøjs-service til agenter, vedligeholde adgangskontrol for agenter og muliggøre samtidig udførelse af agenter. AIOS-arkitekturen demonstrerer potentialet for at facilitere udviklingen og implementeringen af store sprogmodel-baserede autonome agenter, hvilket resulterer i et mere effektivt, samlet og effektivt AIOS-Agent-økosystem.