Utviklingen av AI-systemer går fort. Mye av utviklingen tilskrives bedre språkmodeller, men det er primært andre faktorer som driver denne utviklingen. MCP er en slik faktor som har fått en del oppmerksomhet den siste tiden.
Selv om språkmodeller i seg selv kan brukes til å løse mange oppgaver, har de en del begrensninger:
- De er kun en representasjon av treningsdataen, ikke virkeligheten. Språkmodeller i seg selv har ikke tilgang til sanntidsdata, og eventuelle feil i datagrunnlaget gjenspeiles i modellen. Språkmodeller er ikke fakta-modeller.
- Språkmodeller er kun trent på offentlig tilgjengelig data. Språkmodeller har ikke kjenskap til, eller tilgang til din bedriftsdata.
- Språkmodeller kan ikke interagere med omverden.
Det er ikke sikkert at du kjenner deg igjen i disse begrensningene, fordi du har opplevd at feks ChatGPT kan søke på nett. ChatGPT er ikke en språkmodell, men en chatte-tjeneste. Det er ikke språkmodellen som søker på internett, det er chatte-applikasjonen. Flere andre tjenester har også kommet på markedet som gir inntrykk av at språkmodellene har fått helt nye og banebrytende evner. Fellesnevneren her er en helt ny protokoll som heter Model Context Protocol, MCP. For å forstå MCP bedre tar vi en titt på utviklingen i AI-verktøy fra November 2023, og frem til i dag.
Enkel interaksjon med språkmodell
Omtrent alle AI-chattetjenester fulgte denne relativt enkle arkitekturen i starten. En Chattetjeneste som feks Intility GPT, bestod av 2 hovedkomponenter:
- Chatte-klient: Holder styr på input fra brukeren, meldingshistorikk, etc.
- Stor språkmodell (LLM): Mottar input (prompt) og genererer en output (completion).
Slike tjenester fungerte utmerket til oppgaver som oversetting, oppsummering, analyse av store mengder tekst, feilsøking av kode, osv. Svært mange oppgaver i dag, og i fremtiden, vil løses med en slik tjeneste.
Det er dog en del oppgaver som en slik enkel tjeneste ikke kan løse. Spørsmål som krever tilgang til privat, proprietær informasjon, søk på internett etter sanntidsinformasjon, eller å utføre handlinger i et eksternt miljø var ikke mulig. Utvidelsen av arkitekturen med verktøy var løsningen på dette.
Språkmodell + verktøy
Introduksjonen av verktøy har i utgangspunktet ikke noe med språkmodellen å gjøre, det var en utvidelse av chatteklientene. I stedet for at det kun er kommunikasjon mellom chatte-klienten og språkmodellen, har vi denne flyten:
- Input fra bruker: Kan du hjelpe meg med XYZ?
- Språkmodellen svarer med enten:
- Dette kan jeg ikke svare på, men bruk verktøy XXX med input YYY og send resultatet tilbake til meg så kan jeg hjelpe deg
- Selvsagt kan jeg hjelpe deg med XYZ.
- Avhengig av hva som skjedde i forrige steg vil chatteklienten enten:
- Kalle på verktøy XXX med input YYY og sende resultatet tilbake til språkmodellen. Språkmodellen vil generere et svar som presenteres til brukeren.
- Presentere svaret til brukeren
Med denne utvidelsen får chattetjenesten flere bruksområder, og kan løse enda flere problemer. Eksempler på verktøy som er vanlig å bruker er
- Websøk
- Dokumentsøk- og prosessering
- Code Execution
- Bildegenerering
I teorien er det ingen begrensninger på hvilke verktøy man kan lage og tilgjengeliggjøre for en chatteklient. Man kan hekte på så mange dokumenter, fagapplikasjoner og private datakilder som man vil, så lenge en utvikler kan skrive kode for det.
Selv om dette høres veldig fint ut er det noen viktige begrensninger:
- Verktøyene man lager er tett knyttet til klienten. Det er ingen måte å dele disse verktøyene med andre klienter. Fører til duplisering av kode.
- Det er ingen enkel måte å håndtere tilganger og rettigheter på i stor skala. Ansvaret for implementasjon av tilgangsstyring overlates til utvikler av klienten. Dette utgjør en sikkerhetstrussel.
Disse begrensningene har ført til at man ikke uten videre kan integrere fagapplikasjoner i tjenester som Intility GPT. Her kommer MCP inn fra sidelinjen som håndterer disse utfordringene.
Språkmodell + MCP
Arkitekturen med MCP er nokså lik, men vi har en ny komponent i skissen vår: MCP Server. MCP Serveren fungerer som en standardisert bro mellom klienten og de eksterne systemene. Noen andre viktige endringen i skissen ovenfor:
- Chat Client til MCP Clients: Klienten må støtte protokollen, og alle klienter som gjør det kaller vi for MCP Clients. En MCP Client kan kommunisere med hvilken som helst MCP Server.
- User: Vi har tatt med bruker, og hvordan brukerens identitet tas i bruk mellom MCP Server og den eksterne tjenesten. Det er veldig viktig at MCP Serveren benytter seg av brukerkonteksten for å ivareta brukeren rettigheter.
Kraften i MCP ligger i at dersom man har en MCP Client, så kan man benytte seg av enhver MCP Server.
Hvem lager MCP Serveren?
I teorien kan hvem som helst lage en MCP Server. Det eneste som kreves er programatisk tilgang til det systemet eller datakilden du skal jobbe mot. Typisk ser man 3 varianter:
- Applikasjonsleverandør lager en MCP Server for sin applikasjon. Eksempler som finnes i dag er GitHub, PayPal og Stripe.
- Community/MCP as a Service: Det finnes et stort utvalg MCP Servere som er tilgjengelig som åpen kildekode som man kan kjøre på egen infrastruktur uten kostnad. Det finnes også leverandører av MCP Servere som tilbyr dette mot en kostnad.
- Lage selv. Så lenge systemet man skal gå mot har et API, kan man lage MCP Servere selv. Da har man muligheten til å skreddersy den til egne behov.
Bygg for fremtiden og unngå «Vendor lock in»
MCP er en åpen standard som skiller selve integrasjonen (MCP?serveren) fra både klienten og språkmodellen. Det betyr at koblingene til systemene dine ikke ligger innbakt i én bestemt chattetjeneste eller i et leverandørspesifikt API. Kort sagt bygger du en gang og gjenbruker på tvers av verktøy og miljøer.
En MCP-server kan benyttes fra ulike MCP-klienter og mot forskjellige modeller. MCP-serverne kan også kjøres der dataen bor (on-prem, sovereign, public cloud, edge) og eksponeres sikkert via protokollen.
