Aan de slag met AI-agenten (deel 2): ​​Autonomie, waarborgen en valkuilen

In onze eerste termijnhebben we belangrijke strategieën geschetst voor het inzetten van AI-agenten om de bedrijfsefficiëntie te verbeteren. Ik legde uit hoe agenten, in tegenstelling tot op zichzelf staande AI-modellen, taken iteratief verfijnen met behulp van context en tools om resultaten zoals het genereren van code te verbeteren. Ik besprak ook hoe multi-agentsystemen de communicatie tussen afdelingen bevorderen, een uniforme gebruikerservaring creëren en de productiviteit, veerkracht en snellere upgrades stimuleren.

Het succes bij het bouwen van deze systemen hangt af van het in kaart brengen van rollen en workflows, evenals van het instellen van veiligheidsmaatregelen zoals menselijk toezicht en foutcontroles om een ​​veilige werking te garanderen. Laten we eens dieper ingaan op deze cruciale elementen.

Waarborgen en autonomie

Agenten impliceren autonomie, dus er moeten verschillende waarborgen in een agent worden ingebouwd binnen een systeem met meerdere agenten om fouten, verspilling, juridische blootstelling of schade te verminderen wanneer agenten autonoom opereren. Het toepassen van al deze waarborgen op alle agenten kan overdreven zijn en een uitdaging vormen voor de middelen, maar ik raad ten zeerste aan om elke agent in het systeem in overweging te nemen en bewust te beslissen welke van deze waarborgen zij nodig hebben. Een agent mag niet autonoom opereren als aan een van deze voorwaarden is voldaan.

Expliciet gedefinieerde omstandigheden voor menselijk ingrijpen

Het activeren van een van een reeks vooraf gedefinieerde regels bepaalt de omstandigheden waaronder een mens het gedrag van een agent moet bevestigen. Deze regels moeten geval per geval worden gedefinieerd en kunnen worden gedeclareerd in de systeemprompt van de agent – ​​of, in meer kritische gebruikssituaties, worden afgedwongen met behulp van deterministische code buiten de agent. Een dergelijke regel, in het geval van een aankoopmakelaar, zou zijn: “Elke aankoop moet eerst worden geverifieerd en bevestigd door een mens. Roep uw ‘check_with_human’-functie aan en ga niet verder totdat deze een waarde retourneert.’

Bescherm agenten

Een beveiligingsagent kan worden gekoppeld aan een agent die de rol heeft om te controleren op risicovol, onethisch of niet-conform gedrag. De agent kan worden gedwongen om altijd alle of bepaalde elementen van zijn gedrag tegenover een vrijwaringsagent te controleren, en niet verder te gaan tenzij de vrijwaringsagent groen licht geeft.

Onzekerheid

Ons laboratorium heeft onlangs een papier over een techniek die een maatstaf kan zijn voor de onzekerheid over wat een groot taalmodel (LLM) genereert. Gezien de neiging van LLM’s om te confabuleren (algemeen bekend als hallucinaties), kan het geven van een voorkeur aan een bepaalde output een agent veel betrouwbaarder maken. Ook hier zijn kosten aan verbonden. Het beoordelen van de onzekerheid vereist dat we meerdere outputs genereren voor hetzelfde verzoek, zodat we deze kunnen rangschikken op basis van zekerheid en het gedrag kunnen kiezen dat de minste onzekerheid kent. Dat kan het systeem traag maken en de kosten verhogen. Daarom moet dit worden overwogen voor meer kritische agenten binnen het systeem.

Knop losmaken

Er kunnen momenten zijn waarop we alle autonome, op agenten gebaseerde processen moeten stopzetten. Dit kan zijn omdat we consistentie nodig hebben, of omdat we gedrag in het systeem hebben gedetecteerd dat moet stoppen terwijl we uitzoeken wat er mis is en hoe we het kunnen oplossen. Voor meer kritische workflows en processen is het belangrijk dat deze ontkoppeling er niet toe leidt dat alle processen stoppen of volledig handmatig worden. Daarom wordt aanbevolen dat er een deterministische fallback-modus wordt ingericht.

Door agenten gegenereerde werkorders

Niet alle agenten binnen een agentennetwerk hoeven volledig te worden geïntegreerd in apps en API’s. Dit kan een tijdje duren en er zijn een paar iteraties nodig om het goed te krijgen. Mijn aanbeveling is om een ​​generieke placeholder-tool toe te voegen aan agenten (meestal bladknooppunten in het netwerk) die eenvoudigweg een rapport of een werkorder zouden uitbrengen, met daarin voorgestelde acties die handmatig namens de agent moeten worden uitgevoerd. Dit is een geweldige manier om uw agentennetwerk op een flexibele manier op te starten en te operationeel te maken.

Testen

Met op LLM gebaseerde agenten winnen we aan robuustheid ten koste van consistentie. Gezien de ondoorzichtige aard van LLM’s hebben we bovendien te maken met black-box-knooppunten in een workflow. Dit betekent dat we voor agent-gebaseerde systemen een ander testregime nodig hebben dan voor traditionele software. Het goede nieuws is echter dat we gewend zijn dergelijke systemen te testen, aangezien we al sinds het begin van de industrialisatie mensgestuurde organisaties en workflows runnen.

Hoewel de voorbeelden die ik hierboven liet zien een enkel toegangspunt hebben, hebben alle agenten in een systeem met meerdere agenten een LLM als hun brein, en kunnen zij dus als toegangspunt voor het systeem fungeren. We moeten gebruik maken van verdeel en heers, en eerst subsets van het systeem testen door te beginnen bij verschillende knooppunten binnen de hiërarchie.

We kunnen ook generatieve AI gebruiken om testcases te bedenken die we tegen het netwerk kunnen uitvoeren om het gedrag ervan te analyseren en het netwerk ertoe aan te zetten zijn zwakke punten bloot te leggen.

Ten slotte ben ik een groot voorstander van sandboxing. Dergelijke systemen moeten eerst op kleinere schaal worden gelanceerd binnen een gecontroleerde en veilige omgeving, voordat ze geleidelijk worden uitgerold om bestaande workflows te vervangen.

Fijnafstemming

Een veel voorkomende misvatting over gen-AI is dat het beter wordt naarmate je het vaker gebruikt. Dit is duidelijk verkeerd. LLM’s zijn vooraf opgeleid. Dit gezegd hebbende, kunnen ze worden verfijnd om hun gedrag op verschillende manieren te beïnvloeden. Als er eenmaal een systeem met meerdere agenten is ontworpen, kunnen we ervoor kiezen om het gedrag ervan te verbeteren door de logboeken van elke agent te nemen en onze voorkeuren te labelen om een ​​verfijnd corpus op te bouwen.

Valkuilen

Multi-agentsystemen kunnen in een neerwaartse spiraal terechtkomen, wat betekent dat een zoekopdracht soms nooit wordt beëindigd, waarbij agenten voortdurend met elkaar praten. Dit vereist een vorm van time-outmechanisme. We kunnen bijvoorbeeld de geschiedenis van de communicatie voor dezelfde zoekopdracht controleren, en als deze te groot wordt of als we repetitief gedrag detecteren, kunnen we de stroom beëindigen en opnieuw beginnen.

Een ander probleem dat zich kan voordoen is een fenomeen dat ik overbelasting zal noemen: te veel verwachten van één enkele agent. De huidige stand van zaken op het gebied van LLM’s staat ons niet toe agenten lange en gedetailleerde instructies te geven en van hen te verwachten dat ze deze altijd en altijd opvolgen. Had ik al gezegd dat deze systemen inconsistent kunnen zijn?

Een oplossing voor deze situaties is wat ik granularisatie noem: agenten opsplitsen in meerdere verbonden agenten. Dit vermindert de belasting voor elke agent en zorgt ervoor dat de agenten consistenter zijn in hun gedrag en minder snel in een neerwaartse spiraal terechtkomen. (Een interessant onderzoeksgebied dat ons laboratorium uitvoert, is het automatiseren van het granularisatieproces.)

Een ander veelvoorkomend probleem bij het ontwerpen van systemen met meerdere agenten is de neiging om een ​​coördinerende agent te definiëren die verschillende agenten oproept om een ​​taak te voltooien. Dit introduceert een single point of faillment dat kan resulteren in een nogal complexe reeks rollen en verantwoordelijkheden. Mijn suggestie in deze gevallen is om de workflow als een pijplijn te beschouwen, waarbij de ene agent een deel van het werk voltooit en dit vervolgens aan de volgende overdraagt.

Multi-agentsystemen hebben ook de neiging om de context verderop in de keten door te geven aan andere agenten. Dit kan die andere agenten overbelasten, in verwarring brengen en is vaak onnodig. Ik stel voor dat agenten hun eigen context behouden en de context opnieuw instellen als we weten dat we te maken hebben met een nieuw verzoek (een beetje zoals hoe sessies werken voor websites).

Ten slotte is het belangrijk op te merken dat de lat relatief hoog ligt voor de capaciteiten van de LLM die als brein van agenten wordt gebruikt. Kleinere LLM’s hebben mogelijk veel snelle engineering of verfijning nodig om aan verzoeken te voldoen. Het goede nieuws is dat er al verschillende commerciële en open-sourceagenten zijn, zij het relatief grote, die de lat passeren.

Dit betekent dat kosten en snelheid een belangrijke overweging moeten zijn bij het bouwen van een multi-agentsysteem op schaal. Ook moeten de verwachtingen worden gewekt dat deze systemen, ook al zijn ze sneller dan mensen, niet zo snel zullen zijn als de softwaresystemen die we gewend zijn.

Babak Hodjat is CTO voor AI bij Op de hoogte.