Utvecklingen av AI-system går snabbt. Mycket av utvecklingen tillskrivs bättre språkmodeller, men det är främst andra faktorer som driver denna utveckling. MCP är en sådan faktor som har fått en del uppmärksamhet på sistone.
Även om språkmodeller i sig själva kan användas för att lösa många uppgifter, har de vissa begränsningar:
- De är endast en representation av träningsdata, inte verkligheten. Språkmodeller i sig har inte tillgång till realtidsdata, och eventuella fel i datagrunden återspeglas i modellen. Språkmodeller är inte faktamodeller.
- Språkmodeller är endast tränade på offentligt tillgänglig data. Språkmodeller har ingen kunskap om eller tillgång till ditt företagsdata.
- Språkmodeller kan inte interagera med omvärlden.
Det är inte säkert att du känner igen dig i dessa begränsningar, eftersom du har upplevt att till exempel ChatGPT kan söka på nätet. ChatGPT är inte en språkmodell, utan en chattjänst. Det är inte språkmodellen som söker på internet, det är chattapplikationen. Flera andra tjänster har också kommit på marknaden som ger intryck av att språkmodellerna har fått helt nya och banbrytande förmågor. Den gemensamma nämnaren här är en helt ny protokoll som heter Model Context Protocol, MCP. För att förstå MCP bättre tittar vi på utvecklingen i AI-verktyg från november 2023, och fram till idag.
Enkel interaktion med språkmodell
Ungefär alla AI-chattjänster följde denna relativt enkla arkitektur i början. En chattjänst som till exempel Intility GPT, bestod av 2 huvudkomponenter:
- Chattklient: Håller koll på användarens input, meddelandehistorik, etc.
- Stor språkmodell (LLM): Tar emot input (prompt) och genererar en output (completion).
Sådana tjänster fungerade utmärkt för uppgifter som översättning, sammanfattning, analys av stora mängder text, felsökning av kod, osv. Väldigt många uppgifter idag, och i framtiden, kommer att lösas med en sådan tjänst.
Det finns dock en del uppgifter som en sådan enkel tjänst inte kan lösa. Frågor som kräver tillgång till privat, proprietär information, sökningar på internet efter realtidsinformation, eller att utföra handlingar i en extern miljö var inte möjliga. Utvidgningen av arkitekturen med verktyg var lösningen på detta.
Språkmodell + verktyg
Introduktionen av verktyg har i princip inget med språkmodellen att göra, det var en utvidgning av chattklienterna. Istället för att det endast är kommunikation mellan chattklienten och språkmodellen, har vi denna flöde:
- Input från användaren: Kan du hjälpa mig med XYZ?
- Språkmodellen svarar med antingen:
- Detta kan jag inte svara på, men använd verktyg XXX med input YYY och skicka resultatet tillbaka till mig så kan jag hjälpa dig
- Självklart kan jag hjälpa dig med XYZ.
- Beroende på vad som hände i föregående steg kommer chattklienten antingen:
- Anropa verktyg XXX med input YYY och skicka resultatet tillbaka till språkmodellen. Språkmodellen kommer att generera ett svar som presenteras för användaren.
- Presentera svaret för användaren
Med denna utvidgning får chattjänsten fler användningsområden, och kan lösa ännu fler problem. Exempel på verktyg som är vanliga att använda är
- Webbsök
- Dokumentsök och -bearbetning
- Code Execution
- Bildgenerering
I teorin finns det inga begränsningar på vilka verktyg man kan skapa och tillgängliggöra för en chattklient. Man kan koppla så många dokument, fackapplikationer och privata datakällor som man vill, så länge en utvecklare kan skriva kod för det.
Även om detta låter väldigt bra finns det några viktiga begränsningar:
- De verktyg man skapar är tätt knutna till klienten. Det finns inget sätt att dela dessa verktyg med andra klienter. Leder till duplicering av kod.
- Det finns ingen enkel metod för att hantera tillgångar och rättigheter i stor skala. Ansvaret för implementeringen av åtkomstkontroll överlåts till klientutvecklaren. Detta utgör en säkerhetsrisk.
Dessa begränsningar har lett till att man inte utan vidare kan integrera fackapplikationer i tjänster som Intility GPT. Här kommer MCP in från sidan och hanterar dessa utmaningar.
Språkmodell + MCP
Arkitekturen med MCP är ganska lik, men vi har en ny komponent i vår skiss: MCP Server. MCP Servern fungerar som en standardiserad bro mellan klienten och de externa systemen. Några andra viktiga förändringar i skissen ovan:
- Chat Client till MCP Clients: Klienten måste stödja protokollen, och alla klienter som gör det kallar vi för MCP Clients. En MCP Client kan kommunicera med vilken som helst MCP Server.
- User: Vi har inkluderat användaren och hur användarens identitet används mellan MCP Server och den externa tjänsten. Det är mycket viktigt att MCP Servern använder sig av användarkontexten för att skydda användarens rättigheter.
Kraften i MCP ligger i att om man har en MCP Client, så kan man använda sig av vilken MCP Server som helst.
Vem skapar MCP Servern?
I teorin kan vem som helst skapa en MCP Server. Det enda som krävs är programmatisk åtkomst till det system eller datakälla du ska arbeta mot. Typiskt ser man 3 varianter:
- Applikationsleverantör skapar en MCP Server för sin applikation. Exempel som finns idag är GitHub, PayPal och Stripe.
- Community/MCP as a Service: Det finns ett stort urval av MCP Serverar som är tillgängliga som öppen källkod som man kan köra på egen infrastruktur utan kostnad. Det finns också leverantörer av MCP Serverar som erbjuder detta mot en kostnad.
- Skapa själv. Så länge systemet man ska gå mot har ett API, kan man skapa MCP Serverar själv. Då har man möjlighet att skräddarsy den efter egna behov.
Bygg för framtiden och undvik “Vendor lock in”
MCP är en öppen standard som skiljer själva integrationen (MCP-servern) från både klienten och språkmodellen. Det innebär att kopplingarna till dina system inte är inbakade i en specifik chattjänst eller ett leverantörsspecifikt API. Kort sagt bygger du en gång och återanvänder över verktyg och miljöer.
En MCP-server kan användas från olika MCP-klienter och mot olika modeller. MCP-servrarna kan också köras där datan finns (on-prem, sovereign, public cloud, edge) och exponeras säkert via protokollen.
