Slik velger du riktig rammeverk for KI-agenter til automatisering i bedriften

Hva er rammeverk for KI-agenter, og hvorfor er de viktige?

Rammeverk for KI-agenter er programvaren du bygger autonome agenter på. Se for deg et understell og en motor som du kan koble de verktøyene og instruksjonene agenten trenger til. Da kan den utføre komplekse oppgaver uten at et menneske må gripe inn hele tiden.

Rammeverkene er den eneste meningsfulle broen mellom en ren stor språkmodell (LLM) og en fungerende bedriftsapplikasjon som faktisk gjør nytte for seg. I bunn og grunn gir et rammeverk KI evnen til å planlegge handlinger, bruke verktøy som API-er og databaser, huske tidligere samhandling og tilpasse strategien for å nå et mål.

Uten denne strukturen må teamet bygge all den komplekse styringslogikken fra bunnen av, en garantert sløsing med tid og ressurser i hvert eneste prosjekt. Og betydningen deres øker raskt. Med utprøvde, ferdige komponenter som kutter utviklingstid og kostnader, gjør disse rammeverkene generativ KI til mer enn en smart innholdsprodusent: De lar den bidra aktivt og skape verdi i virksomhetens drift.

Et kritisk blikk: Hvorfor skaper de fleste KI-agentprosjekter ikke verdi?

Hypen rundt KI-agenter er øredøvende. Men i praksis møter mange prosjekter nederlag og skuffelse. Avstanden mellom en imponerende demo og en automatisert prosess som tåler produksjonsbruk, sluker både budsjetter og utviklernes entusiasme. Vi ser det stadig vekk.

Hvorfor mislykkes så mange? Fordi utfordringene endrer seg i det øyeblikket en agent forlater tryggheten i en Jupyter-notatbok. Driftsavdelingene vi snakker med, trekker stadig frem hvor skjøre disse systemene er.

Synet deres endrer seg når vi viser en tydelig vei til produksjon gjennom grundig evaluering av verktøy og god feilhåndtering.

De fleste feil kan spores til fire forutsigbare problemer som det går an å løse. Først kommer kaos i orkestreringen: Logikk og feilhåndtering på tvers av trinn, verktøy og agenter blir et mareritt å vedlikeholde. En analyse på Medium fant faktisk at orkestreringsproblemer utgjorde 12.54% av utviklernes problemer.

Det andre er svært lav pålitelighet. Når hvert trinn i en prosess kan feile, kan sannsynligheten for feil hope seg opp slik at andelen vellykkede gjennomføringer faller helt ned til 35.8% uten omfattende finjustering.

Deretter kommer manglende innsikt i systemets oppførsel. Hvis du ikke kan se hvorfor en agent feilet, kan du heller ikke rette feilen, og de fleste rammeverk mangler nødvendige verktøy for sporing og feilsøking. Til slutt begrenses agentene av hull i minne og kontekst.

Da gjentar de feil og ber om den samme informasjonen på nytt, noe som ødelegger nytteverdien.

Hvis du ikke utformer arkitekturen for å løse disse produksjonsproblemene fra første dag, ender agentprosjektet ditt som enda et dyrt eksperiment.

Trinn 1: Sammenlign de ledende rammeverkene: LangGraph vs. AutoGen vs. CrewAI

Valget av rammeverk legger grunnlaget for hele agentsystemet. Det bestemmer arkitekturen, mulighetene og hvor langt systemet til slutt kan skaleres. Det finnes dusinvis av alternativer, men tre har etablert seg som de dominerende valgene for seriøs utvikling med produksjon som mål: LangGraph, AutoGen og CrewAI.

De bygger på grunnleggende ulike tilnærminger til agenter og passer derfor til helt forskjellige typer problemer.

LangGraph: Tilstandsmaskinen for komplekse arbeidsflyter

LangGraph bygger på det populære biblioteket LangChain og krever at du modellerer agentens utførelse som en graf. Hver node er en funksjon eller et verktøy. Kantene er overgangene mellom dem.

Denne strukturen er i bunn og grunn en tilstandsmaskin. Derfor er den spesielt godt egnet til oppgaver som krever gjentakelser, kompleks forgreningslogikk og eksplisitt tilstandshåndtering over tid. Hvis prosessen din ikke følger en enkel, rett linje, men krever at agenten går tilbake, revurderer valgene sine eller venter på ekstern godkjenning før den fortsetter, er LangGraph det riktige arkitekturvalget.

• Best egnet til: Å bygge avanserte agenter som arbeider i sykluser eller over lang tid, der kontroll og tilstand er avgjørende. Eksempler er kundestøtteboter som må overlate en sak til et menneske og ta den opp igjen senere, eller komplekse datapipelines med valideringsrunder.

AutoGen: Rammeverket for samarbeid mellom flere agenter

AutoGen kommer fra Microsoft Research og er utviklet spesielt for systemer der flere ulike agenter samarbeider om å løse ett problem. Den viktigste styrken er å simulere komplekse samtaler mellom spesialiserte agenter. Vi definerer for eksempel ofte en «skribent», en «kritiker» og en «planlegger» som diskuterer, vurderer hverandres arbeid og forbedrer løsningen til hovedoppgaven er løst.

Sammenlignet med én agent som skal gjøre alt, gir slikt samarbeid mellom flere agenter gjennomgående bedre resultater for kompleks research, dyptgående analyse og kreativ sammenstilling.

• Best egnet til: Oppgaver som krever ulike perspektiver og felles problemløsning. Passer godt til omfattende rapporter, utforsking av komplekse forskningsspørsmål og automatiserte team for programvareutvikling.

CrewAI: Et hierarkisk team av spesialister

CrewAI har en tydelig, rollebasert tilnærming til å bygge systemer med flere agenter. Du definerer agenter med bestemte oppgaver («markedsanalytiker», «reklametekstforfatter») og setter dem sammen til et team som følger en forhåndsdefinert, hierarkisk prosess. Hovedformålet med rammeverket er å koordinere disse rollebaserte agentene slik at de løser oppgaver på en strukturert måte, styrt ovenfra.

Den målrettede enkelheten gjør det svært raskt å lage prototyper og ta i bruk team for prosessbasert arbeid.

Nedenfor ser du en enkel agentdefinisjon i CrewAI som viser hvordan rammeverket vektlegger roller og mål.

from crewai import Agent, Task, Crew


# Define the Researcher Agent
researcher = Agent(
 role='Senior Market Analyst',
 goal='Uncover a compelling new angle for our next marketing campaign for Product X',
 backstory='You are a world-class market analyst known for finding non-obvious insights.',
 verbose=True,
 allow_delegation=False
)


#. Define other agents and tasks.

• Best egnet til: Å automatisere klart definerte forretningsprosesser som kan deles inn i en rekke spesialiserte roller. Passer godt til produksjon av markedsføringsinnhold, personlig tilpasset salgsoppfølging og utarbeidelse av bedriftsrapporter.

Sammenligning av egenskaper

Trinn 2: Vurder rammeverkene etter kriterier for produksjonsbruk

Et rammeverk som fungerer utmerket på en hackathon i helgen, er nesten alltid et dårlig valg for en virksomhetskritisk prosess. Ikke la deg lure. Hvor raskt du kan lage en prototype, er fristende å se på, men sier svært lite om hvorvidt løsningen fungerer i produksjon.

For å velge riktig må du vurdere rammeverkene etter det som faktisk betyr noe når systemet er i drift og må håndtere reelle volumer og uforutsigbare feil. Vi insisterer på å bruke vurderingskriterier som måler hvor godt rammeverkene egner seg til drift, ikke bare hvilke funksjoner de har. Det tvinger frem den nødvendige, men krevende samtalen om totale eierkostnader fremfor bare innsatsen i den første utviklingsfasen.

Bruk kriteriene nedenfor på prosjektet ditt. Gi hvert rammeverk en poengsum fra 1 (dårlig) til 5 (utmerket) på disse områdene som er avgjørende i produksjon.

Denne gjennomgangen gjør én ting klart: Hvilke rammeverk for KI-agenter som er «best», avhenger helt av situasjonen. Med CrewAI lager du raskest en prototype. AutoGen er kraftig for kompleks research som krever samarbeid.

Men LangGraph gir den grundige kontrollen og innsikten i systemets oppførsel som virksomhetskritisk automatisering trenger for å tåle belastning.

Trinn 3: Bygg for virkeligheten: Håndter kostnader, sikkerhet og utfordringene etter utrulling

Det virkelige arbeidet begynner etter at agenten er «ferdig». Vi kaller det «dag 2-problemer». Det er slike problemer som velter KI-agentprosjekter i praksis: LLM-kostnader som løper løpsk, alvorlige sikkerhetshull og driftsfeil som er nesten umulige å feilsøke.

Derfor må du ta høyde for disse realitetene helt fra starten.

De høye kostnadene ved autonome agenter

En tenkt arbeidsmengde i kundeservice kan illustrere modellkostnadene. Anslå antall henvendelser, tokens, modellpriser, nye forsøk, verktøykall og treff i hurtigbufferen før lansering. Erstatt deretter anslagene med faktiske brukstall.

Da får du et spenn å planlegge etter, uten å fremstille et tenkt oppsett som et målt resultat.

La oss regne på en agent som behandler 5,000 supportsaker i måneden.

Denne beregningen dekker bare de rene API-kostnadene. Du må også ta med hosting, overvåkingsprogramvare og tiden utviklere bruker på løpende vedlikehold. En tilsynelatende lav kostnad per sak kan raskt bli en betydelig driftsutgift som setter hele prosjektet i fare.

Agentarkitektur med sikkerhet først

En KI-agent med tilgang til interne verktøy og bedriftsdata innebærer en betydelig sikkerhetsrisiko. Den skaper en ny, dynamisk angrepsflate for promptinjeksjon, datalekkasje og uautoriserte handlinger med potensielt alvorlige følger. Følg prinsippet om minste privilegium: Gi agenten kun den tilgangen den trenger for å utføre oppgaven, og ikke mer.

Vi krever en agentarkitektur med sikkerhet først, der agenten er adskilt fra verktøyene den bruker.

Denne arkitekturen håndhever viktige sikkerhetsgrenser:

1. Rensing av inndata: Fjerner skadelige instruksjoner fra brukerens spørsmål for å hindre promptinjeksjon.
2. Agentkjerne: Resonneringssløyfen som drives av en språkmodell. Den har ingen direkte tilgang til verktøy.
3. Kontroll av verktøytilgang: En regelmotor uten KI som kontrollerer hvert verktøykall fra agenten og avgjør om det forespurte verktøyet kan brukes med de angitte parameterne.
4. Isolert utførelsesmiljø: Utfører godkjente verktøykall i et isolert miljø (for eksempel en Docker-container) med egne, begrensede tillatelser. Dermed kan ikke et kompromittert verktøy påvirke resten av systemet.

Dette skillet er avgjørende. Agenten kan *be om* at noe blir gjort, men kontrollen og utførelsesmiljøet *godkjenner og utfører* handlingen etter strenge, forhåndsdefinerte regler.

Hvordan bygger du et tilpasset evalueringsopplegg for agenten din?

Hvordan vet du egentlig om agenten fungerer? Og hvordan kan du bevise at en endring du nettopp har rullet ut, gjorde den bedre og ikke mye dårligere? Stikkprøver og magefølelse er ikke nok.

Du trenger et systematisk evalueringsopplegg som kan gjentas, og som måler resultatene mot konkrete forretningsmål. Generelle mål for nøyaktighet sier lite her. Det finnes klare paralleller til psykometri: Vi tester ikke bare om svaret er riktig eller galt, men hele rekken av beslutninger agenten tar, hvor kostnadseffektiv den er, og om den klarer å hente seg inn etter feil.

Et tilpasset evalueringsopplegg skiller et erfarent KI-utviklingsteam fra et uerfarent.

Slik går du frem, trinn for trinn:

1. Definer et fasitsett: Sett sammen et representativt utvalg på 50-100 testtilfeller fra virkeligheten som dere kan måle mot. Hvert tilfelle må inneholde inndataene (for eksempel en e-post fra en kunde) og ønsket sluttresultat (for eksempel et JSON-objekt som angir sakskategori og sentiment).
2. Fastsett kriterier for suksess: Gå lenger enn enkel bestått/ikke bestått. Lag et detaljert vurderingsskjema for hver testkjøring.
3. Automatiser testkjøringen: Skriv et skript som går gjennom hele fasitsettet, kjører hvert tilfelle gjennom agenten og lagrer en fullstendig sporingslogg over resonnement, verktøykall og endelig svar til analyse.
4. Bygg automatiske evaluatorer: Lag en evaluatorfunksjon for hvert kriterium i vurderingsskjemaet. Noen er enkle kodekontroller (for eksempel `is_json_valid(output)`). For mer nyanserte vurderinger kan du bruke en kraftig språkmodell (som GPT-4 eller Claude 3 Opus) som upartisk dommer.
5. Analyser og forbedre: Kjør hele evalueringsopplegget etter hver vesentlige endring i kode eller prompter. Analyser de samlede resultatene. Let etter tilbakegang. Et godt evalueringspanel viser ikke bare hvor stor andel som består, men også nøyaktig hvilke tilfeller som feiler, og gir deg dataene du trenger for å forstå hvorfor.

Slik går du fra skjøre og upålitelige agenter til systemer som er klare for produksjon.

Tyngdepunktet har flyttet seg fra modellen til systemet rundt den. Teamene som lykkes, bygger bedre løsninger for evaluering, overvåking og kontinuerlig forbedring. Det er viktigere enn å ha den beste modellen isolert sett.