Zo bouw je effectieve LLM-applicaties

In deze aflevering hoor je Willem Meints, Chief AI Architect bij InfoSupport, die de complexe wereld van LLM-applicaties met Semantic Kernel ontleed en praktische valkuilen blootlegt bij het bouwen van AI-gestuurde systemen. Met zijn uitgebreide ervaring en 10 MVP Awards laat Willem zien hoe je effectieve AI-toepassingen ontwikkelt die verder gaan dan de standaard chatbot functionaliteit. Veel plezier met deze aflevering! *** De laatste aflevering. En mij nog steeds niet kennen. Ik ben Willem Meints. Ik werk als chief AI architect voor Info Support. Samen met Joop bij Aigency. Heel druk met AI. Wat is nog meer interessant. Ik heb inmiddels tien MVP awards. In plaats van negen. Dus ik ben nog steeds heel erg druk in mijn vrije tijd. Dat is eigenlijk het idee. En voor de luisteraars. Wat houdt het eigenlijk in zo'n MVP award? We zeggen hier alsof het gewoon is. Maar dat is het natuurlijk niet. Wat houdt het precies in? De MVP award wordt door Microsoft uitgereikt. Het is de Microsoft Most Valuable Professional Award. Dat is de volledige naam. En je krijgt dat voor allerlei werk wat je doet in de community. Zo zeggen ze dat heel mooi. Dus als je veel spreekt op conferenties, boeken schrijft, voorbeeldcode maakt, op LinkedIn heel veel mensen helpt, dat soort dingen. Dus ik ben heel veel in de vrije tijd bezig en dat waarderen ze heel erg. Dus het is van Microsoft, maar nog steeds best wel onafhankelijk. Ik doe ook dingen die niet Microsoft gerelateerd zijn. Dus het is echt, mijn beeld van, corrigeer maar als ik het verkeerd zeg, is community appreciation, dus waardering vanuit de community, vanuit de omgeving, dat je je kennis deelt en daar tijd insteekt en dat mensen kennis laat opdoen van de technologie en de ontwikkelingen die daarbij zijn. Ja. Nou, je zegt al in je vrije tijd, een boek geschreven, een aantal maanden over gedaan. Wat is de titel van je boek? Building Effective LLM Applications met Semantic Kernel. Zo, helemaal vol. Moeten we even afbellen. Ja, daar zit heel veel in. Laten we eens beginnen met die LLM Applications. Wat is een LLM applicatie? Ja, ik denk dat de meeste mensen inmiddels wel bekend zijn met Cloud en met ChatGPT. En dat is eigenlijk, zo heb ik hem geïnterpreteerd, een LLM gebaseerde applicatie. Dus er zit een large language model in verpakt. In het geval van ChatGPT is dat een chatbot. maar je kan er veel meer mee bouwen dus mijn boek gaat eigenlijk over programma's bouwen waar een large language model een belangrijke rol in speelt en dat kan een chatbot zijn maar dat kan ook een workflow zijn een AIA gedreven workflow dat zou ook een agent kunnen zijn waar we ook al veel over in de podcast hebben gehoord ja, dit is vrij breed dus de LLM is een onderdeel van de applicatie waardoor je het een LLM applicatie noemt Ja. Effectief. Wanneer is iets effectiefs dan? Ja, nou, ik was eigenlijk met een boek begonnen zo van, er zijn heel veel voorbeelden op internet te vinden voor softwareontwikkelaars, hoe je nou met large language models applicaties kan bouwen. Alleen, dat is een soort van hallo wereld voorbeeld van, hé, het werkt en dan houdt het ook echt wel op. En ik heb de afgelopen jaren veel tijd geïnvesteerd in het leren werken met large language models. Ik heb er heel veel fouten mee gemaakt. Het is heel vaak kapot gegaan. En al die ervaringen heb ik eigenlijk in dat boek gestopt. Dus ik probeer mensen ook vooral te helpen met... Hoe bouw je nou een goed functionerende applicatie? Een goed functionerende chatbot bijvoorbeeld? Daar komt best wel heel veel bij kijken eigenlijk. Zou je daar een voorbeeld van kunnen noemen? Een van de dingen die in mijn boek best wel wordt beschreven... is het testen van dit soort applicaties. Dat gaat toch echt wel heel anders dan traditionele software testen. Bij traditionele software kun je een berekening testen door de inputs te geven en de verwachte output erbij. En dan kun je kijken of het programma dat ook goed doet, dat hij dezelfde output produceert. Bij een taalmodel is dat helemaal niet. De ene keer geeft hij op de ene manier antwoord en dan probeer je met dezelfde input nog een keer antwoord te krijgen. En dan zegt hij totaal wat anders. Die chatbot reageert elke keer anders op jouw vraag. En dat maakt dat ook wel weer ingewikkeld om dat te testen. Dus ik heb in mijn boek ook een strategie beschreven waarbij je eigenlijk zegt van ik ga niet letterlijk het antwoord nakijken of dat klopt met wat ik verwacht. Maar ik ga vragen stellen over het antwoord. Om dat wat concreet te maken. Je zou bijvoorbeeld een recept een chatbot kunnen maken met een large language model. En als je dan vraagt om een recept voor appeltaart, dan zou je toch wel verwachten dat er iets met appels wordt gedaan. En dat kun je vragen. Dan kun je dan een test schrijven die eigenlijk ook weer het large language model gebruikt. Hey, Large Language Model, hier was het antwoord op de vraag om een appeltaartrecept. Zitten daar ook toevallig appels in? En dan zal hij antwoorden met ja of nee. Dat gaat redelijk goed met een taalmodel. En dat beschrijf ik in mijn boeken ook van, hey, dat is heel erg belangrijk. Om te kunnen controleren dat hij ook de antwoorden geeft die in ieder geval qua betekenis hetzelfde zijn. Toch zullen heel veel mensen, zogal je het hebt over een taalmodel, denken aan een chatbot-achtige oplossing. Zou je voorbeelden kunnen noemen waarbij je een taalmodel gebruikt, maar dan in een andere type oplossing? Ja, dus waar ik zelf ervaring mee op heb gedaan de laatste jaren is bijvoorbeeld documentverwerking. Dat we van technische documentatie bij elkaar kunnen rapen met het taalmodel en dan één meer menselijke samenvatting daarvan kunnen maken. Dit ging om allerlei natuurbeschermingsinformatie en de impact van de bescherming op de verbetering van die natuur. Dat zijn allemaal hele technische documenten. Zoveel minder houtkap, zoveel minder CO2-uitstoot in dat gebied. Dat is allemaal best wel ingewikkeld. We hebben met het taalmodel een samenvatting gemaakt van de documenten en gezegd... map dat nou eens naar de impact voor een bepaalde aspect wat we belangrijk hebben gevonden. Dus we hebben doelen gesteld om de natuurbescherming te verbeteren. Kun je nou uitleggen wat de impact is geweest op dat doel aan de hand van die technische documentatie? En dat is een workflow, dat is niet zozeer een chatbot. Je kan er niet mee praten, want die documenten worden geüpload. Daar halen we uit een ander systeem de doelen op die daarbij horen bij dat project. En dan vervolgens gaan we automatisch op de achtergrond die samenvatting maken. En die sturen we via e-mail terug naar degene die dat moet beoordelen. En als je dan die stappen hebt, hoe bepaal je dan welke stap je wel of niet in RLM gebruikt? oh dat is een hele goeie daar heb ik heel erg over na zitten denken van zou je dit regelgebaseerd moeten doen sommige dingen wel moet je wel echt regelgebaseerd gaan doen sterker nog ik raad iedereen aan om het vooral op basis van regels te gaan doen en pas als je denkt van nou gaat het niet meer dan een taalmodel in te zetten in dit voorbeeld is eigenlijk dat samenvatten is wel echt een taalmodel iets dat is heel duidelijk in beeld dat kan ik alleen met een taalmodel doen maar wat ik wel heb gedaan is ik heb gezegd van ik ga dat opdelen in allemaal kleine stukjes dus ik ga niet het hele verhaal in één keer erin gooien maar ik ga één doel ga ik erin stoppen in het taalmodel met een set instructies en dan laat ik hem zelf de documentatie erbij zoeken die dan relevant is voor die vraag die dan gesteld wordt daarmee heb ik dus een soort van hybride gecreëerd aan de ene kant regels namelijk wat ga ik precies vragen en dat klein houden en het andere deel is dan toch wel het taalmodel Je geeft heel expliciet aan, zeker ook met name regelgebaseerd. Dat zeg je denk ik met een reden. Maar wat is die reden dan? Dat je toch echt wel die regelgebaseerde aanpak als eerst zou adviseren? Ja, wat ik zelf heel erg gemerkt heb over de afgelopen jaren. Is dat taalmodellen, ze worden steeds beter. Maar het is nog steeds best wel instabiel. Dat is ook met dat testen merk je dat al. Het is steeds anders. En daar zit toch wel een lastigheid in. En dat mensen op een of andere manier toch de verwachting hebben dat het steeds hetzelfde is. Omdat het toch een automatisch proces is waar ze het over hebben. Dus als je denkt van ik heb een hoge mate van zekerheid nodig. Dan werkt het nou eenmaal beter met regels. Ja oké, dus als je vastigheid wil hebben in je antwoord. Makkelijker te kunnen testen. De consistentie nodig hebt bij die stappen. Daarom advies om dan regelgebaseerd mee aan de slag te gaan. Dat je dat makkelijker kan testen en reproduceerbaar kan maken. Voor wanneer dat van belang is. Het verhoogt de kwaliteit toch wel, nog steeds. Het is building effective LLM applications with Semantic Kernel. Wat is Semantic Kernel? Ja, dat is wel een goeie. Ik denk niet dat er veel mensen van gehoord hebben, nog niet. Het is een raamwerk door Microsoft ontwikkeld in dit geval, dit soort programma's, zoals chatbots en de workflows waar we het net over hadden, dat je die zelf kan bouwen. Het idee van Microsoft is dat het een soort van kern van je programma gaat vormen, dat semantic kernel, wat semantiek begrijpt. Vandaar de naam semantic kernel ook. Dus wat zij zeggen is eigenlijk, je kan ChatGPT gewoon gebruiken, of Microsoft Copilot in het geval van Microsoft. Daarnaast heb je natuurlijk Copilot Studio van Microsoft. Daarmee kun je dan aangepaste chatbots bouwen. En vervolgens, als dat dan nog steeds niet voldoende voor je is, dan kom je in de hoek van de semantic kernel terecht. En daar wil ik wel iets zeggen over de complexiteit. Kijk, voor het gebruik van Microsoft Copilot hoef je alleen maar zelf te begrijpen hoe je de juiste prompt stelt. En heb je hulp van een systeembeheerder denk ik wel nodig om je bedrijfsgegevens daarin te laden. Bij Copilot Studio moet je al iets meer verstand hebben van hoe werkt eigenlijk een taalmodel. En hoe ga ik die chatbot de goede kant op sturen. Bij Semantic Kernel moet je er echt verstand van hebben. Hoe zit dat dan met tools? Je moet in C Sharp kunnen programmeren ook nog eens. En je moet ook wel echt verstand hebben van beveiliging en hoe je de dingen test. Daar komt wel wat voor terug. Je hebt maximale flexibiliteit. Je kunt het zo gek maken als je zelf wilt. Je kunt audio, afbeeldingen, tekst, alles door elkaar doen in principe. Dus het is best een mooi apparaat. Waar zit dan die overgang tussen Copilot Studio, waarbij je het makkelijker in elkaar klikt en sleept, naar dat je naar zoiets gaat als Semantic Kernel? Ik denk dat dat vooral zit in de workflowhoek. Copilot Studio is het agent-achtige ideeën. Ik heb één set aan instructies en daar val ik steeds op terug. En het taalmodel bepaalt eigenlijk ook wel de soort van workflow wat er achter elkaar gaat gebeuren. Of die in SharePoint gaat kijken, eerst in SharePoint gaat kijken en daarna een Word document gaat lezen. Of dat die eerst jouw input pakt en dan antwoord geeft en daarna pas in SharePoint gaat kijken. Bij Cement and Kernel heb je daar heel veel controle over. Kun je echt zeggen van oké, ik ga eerst in SharePoint kijken. Dan ga ik kijken in de zoekindex en dan ga ik op mijn eigen harde schijf kijken. Ik kan ook mijn lokale data van mijn eigen laptop combineren met SharePoint in één keer. Omdat ik, ja dat programmeer ik zelf. Dat kan bij Copilot Studio allemaal niet. Oh ja. En wat ook wel denk ik een belangrijk verschil is met producten als Microsoft Copilot en Copilot Studio. Is dat bij Semantic Kernel kan ik modellen van Amazon in één keer gebruiken. Of van Google. Of zelfs open source modellen. Dus we hebben eerder een podcast opgenomen over DeepSeq. Dat werkt met Semantic Kernel. En dat gaat eigenlijk best wel prima. Kun je volledig op je laptop draaien en dan heb je geen internetverbinding meer nodig. Dus dat is ook voor mensen die juist een extra laag beveiliging zouden willen, is Cemented Kernel wel een veel betere oplossing. Ja, dat klinkt bij mij even een beetje contra-intuitief. In de zin van, je hebt meer vrijheid, je kan het security opzetten, maar je moet ook zelf meer gaan regelen voor je security, heb ik dan het gevoel, toch? Ja, dat is wel echt een nadeel van deze vorm van bouwen. Dus als je even snel wilt, dat gaat niet. Nee, ik moet er wel bij vertellen. Tegenwoordig met oplossingen als GitHub Copilot. De bekende Vibecode tools bijvoorbeeld zoals Lovable. Ik denk dat je in een middagje wel heel ver kan komen. Dus ja, het is meer werk. Maar het wordt ook wel weer een beetje opgeheven met de moderne softwareontwikkeltools. Ja, maar je moet wel bewust zijn dat je bepaalde dingen zelf moet inregelen die niet in het platform zit. Wat je de vrijheid geeft, de flexibiliteit geeft. Maar daarbij komt ook een verantwoordelijkheid om daar wel bewust over na te denken. Om die kwaliteit die je nodig hebt voor je oplossing dus wel in acht te nemen. Ja, ik zou ook zeggen dit is niet iets wat voor de kleinere bedrijven in Nederland in te zetten is zomaar. Of je moet echt een heel specifiek geval hebben dat je zegt ja, ik wil deze workflow graag maken. En dat lukt me niet met een custom GPT ofzo. Dan is dat nog steeds voor kleine bedrijven ook te doen. Ik denk dat er hier veel meer te halen valt voor de grotere enterprises in Nederland. Die ook echt een ontwikkelteam hebben rondlopen die hiermee kan werken. Dat doe je ook niet in je eentje, zo'n oplossing bouwen. Waarom doe je dat niet in je eentje? Onder dat het misschien veel werk is? Ja, het is veel werk en de complexiteit ligt gewoon een stuk hoger. We zien het ook wel bij Info Support gebeuren, dat we dan vaak een combinatie hebben van een softwareontwikkelaar en een data scientist, die dat bijvoorbeeld al samen aan het doen zijn. En wat hier ook wel heel erg gebeurt, de Semantic Kernel is geënt op het maken van agents eigenlijk. Het ultieme doel van het raamwerk is, we willen een zelfstandige agent maken die complexe business taken kan automatiseren. En dan krijg je automatisch ook nog eens te maken met integratie met jouw bestaande IT-landschap. Want zo'n agent, hoe moet die voor jou een factuur gaan versturen? Zal die toch iets met de facturatie moeten gaan doen? Daarmee moet je integreren. En het kan met cementen kernel kan dat, omdat je zelf gereedschap kan bouwen voor die agent in een taal als C-Sharp. Dan hebben we vooral de bouwkant. Zijn er nog andere teamleden nodig om te komen tot een goed passende effectieve LLM applicatie? Ja, ik denk het wel. Waar ik zelf ook best wel wat tijd in heb gestoken om uit te zoeken van hoe ga je daar nou mee om. Het is mooi als je het kan bouwen. Maar dan ga je het daarna installeren in productie. En dan? Wat gebeurt er dan? Dan krijg je te maken met toch wel het feit, omdat een taalmodel instabiel is en steeds een ander antwoord geeft. Mensen gaan ook vragen stellen die jij niet verwacht had. En dan krijg je te maken met hoe ga ik dan achterhalen dat iemand een bijzondere vraag heeft gesteld. En dat die agent verkeerd gereageerd heeft. Daar komt een stuk monitoring en een stuk analyse bij kijken in productie om fouten op te sporen en fouten op te lossen. En dat is toch ook nog wel weer wat lastiger dan bij een normale software applicatie. Juist omdat steeds het antwoord zo anders is. En daar zie je denk ik ook wel de rol van een business analist weggelegd. Of in ieder geval iemand die meer verstand heeft van monitoring tools. Ja, monitoring, domeinkennis, echt een combinatie van factoren die dan van belang zijn. Ja, ja. Kijk, die agents zijn dan bezig. Wat is eigenlijk het belangrijkste om te regelen dat zo'n agent ook blijft werken? En daarmee bedoel ik eigenlijk, de tijd schuift op, je omgeving verandert, je data kan veranderen, je bedrijf kan veranderen. Hoe ga je daar dan eigenlijk mee om? Ja, nou, ik heb dat eigenlijk benaderd vanuit meer de agile gedachte. We zijn tegenwoordig gewend om kortcyclisch software te bouwen. Ik denk dat dat een hele sterke kant is van dit verhaal ook weer. Behoud het kortcyclisch en begin ook klein. Dus je begint met een kleine agent, met een paar stukken gereedschap en dan gaat dat steeds verder. Schuift dat eigenlijk door je organisatie in. En wat ik heb gemerkt dat heel erg goed werkt, is door dat kortcyclisch te houden en heel erg te investeren en automatisering daaromheen. Dus automatisch testen, automatisch uitrollen, monitoring. Zet gerust AI in voor de monitoring, want dat werkt dan weer wel heel erg goed. En daarmee, wat je eigenlijk doet, is een soort feedback loop creëren voor jezelf. Dus je rolt het uit, je verzamelt feedback uit die agent en dan zie je dat die wel of niet goed reageert. En dan vervolgens kun je als team daar weer op reageren en zeggen van oh, ik zie dat dat enig stuk gereedschap niet goed herkend wordt. Ik moet dat aanpassen. Ik pas daar de testen ook weer op aan. En dan rol ik hem weer uit en ga kijken of het beter gaat op productie. Dus je ziet dat daar de agile practices die we langzamerhand in de hele wereld geadopteerd hebben, hier in best wel een flinke hefboom creëren, waardoor je hier succesvol mee kan worden. Is een agent dan wel eigenlijk af? Of heb je eigenlijk altijd wel onderhoud eraan? Ik denk dat hij af is als hij in de prullenbak ligt. Oké. Dat is een mooie ja. Ben ik met je eens. En waarom? Kan je dat uitleggen? Nou, in mijn ervaring zijn de laatste maanden ook weer Cloud4 is uitgekomen. Voilà, mijn agent werkte totaal anders. Vervolgens deden ze nog eens even een update van een ander model. Was er weer een andere agent kapot bij Info Support. Die reageerde weer op een bijzondere manier. Iedere drie maanden zit ik achter mijn computer met mijn handen in de weinige haar wat ik nog heb. Van, oh oh, nou is er weer wat stuk. Dus het is alleen al om die reden nooit af. Maar ik zie ook nog iets heel moois gebeuren eigenlijk. Een paar jaar geleden dachten we, ah, chatgpt, ik ga er gewoon mee praten. En dat is het wel zo ongeveer. Als je nu kijkt naar wat mensen ermee doen. Iedereen is een heel stuk volwassener geworden in het gebruik van AI. Gaan dus veel meer verwachten en veel meer doen. De opdrachten worden steeds complexer. Sommige mensen die typen prompt in bij onze interne chatbot Ricardo van bijna drie A4'tjes. Dat had ik vorig jaar nog niet, dat probleem. Dus je ziet, we worden steeds beter in het gebruik van AI. En daarom moet je agent ook steeds blijven veranderen. Die moet meebewegen. Je zegt van, er kwam een nieuwe versie van Claude. Maar agent deed het niet meer. Waarom deed hij het niet meer? Hij herkende zijn tools niet meer. Hij was in een keer de weg kwijt. Hij kon in documentatie kijken. En op een gegeven moment zei hij, ik ga gewoon niet meer kijken in die documentatie. Ik ga zelf wel iets verzinnen. En dat zat hem erin. Als je zo'n agent hebt, dan kun je daar dus gereedschap tools, noemen we die in het Engels. En iedere tool heeft een beschrijving. Er staat eigenlijk bij van wanneer zou je deze tool moeten gebruiken en wat doet deze tool eigenlijk. En welke data je mag je meegeven of moet je meegeven. Ja, welke input verwacht hij, welke parameters krijg je en welke output zou hij terug kunnen geven potentieel. En wat er gebeurt, dat taalmodel gebruikt die beschrijving of metadata om te bepalen is deze tool op dit moment van toepassing. En als die omschrijving net een beetje vaag is of dat model is anders getraind, want dat is wat er bij mij gebeurde. Dan op een gegeven moment denkt hij, nou weet ik niet, dat is niet meer van toepassing voor mij. Ik ga gewoon lekker verder met waar ik mee bezig was. En dan krijg je dus gekke dingen. Want in mijn geval vind ik het belangrijk dat hij zelf kan kiezen of hij in de documentatie moet kijken of dat hij wat anders moet gaan doen. in een ander systeem gaan kijken. Ja, en dan is die beschrijving wel heel erg belangrijk. Hoe kwam je erachter? Monitoring. Dus in mijn geval kreeg ik een opmerking van iemand. Dat is ook een vorm van monitoring, zou ik zeggen. Die belde me op en die zei tegen mij... Ja, ik ben een beetje teleurgesteld. Oh ja, dat is wel heel droevig. Wat is er aan de hand dan? Ja, ik probeerde dit te doen. Vorige week werkte dit nog. En nu niet meer. Heb je iets veranderd? Ik zei, ja, dat klopt. Het taalmodel is veranderd. Je hebt iets geüpdatet. Oh, nou ja, ik ga wel even kijken voor je. Gelukkig is het vrij vlot op te lossen, maar dat is meestal wel de trigger. Want deze kun je dus ook niet vangen met monitoring, want die gebruiker deed wat anders ook nog. Dat was extra lastig. Je noemde net, ik weet niet of het goed geïnterpreteerde, maar een agent langzaam uitrollen en daarna in de organisatie breder in gaan zetten. Heb je het dan over één agent die van mijn gevoel dan groter wordt? Of heb je dan meerdere agents? Hoe kijk je daar tegenaan? Degene waar ik aan werk, die nu in productie draaien, dat zijn losse agents. Dus die praten ook niet met elkaar. Maar ik zou me kunnen voorstellen dat dat wel nog gaat gebeuren in de toekomst. In dit geval, de groei zit hem erin dat hij meer tools krijgt. Dus meer functies die hij kan aanroepen. Dus dat de agent wordt rijker in wat hij dan kan dan? Ja. En waar houdt het op? Net als bij software systemen heb je grenzen aan hoe je iets modulair opzet. Waar houdt de grens van een AI agent op? Ja, dat is wel een best wel vloeibaar begrip eigenlijk op dit moment. Omdat als je kijkt naar vier maanden geleden, had Microsoft in Semantic Kernel alleen de mogelijkheid om functions te koppelen aan een agent. Dat waren dan de tools. En dat moest binnen de grens van je applicatie blijven zitten. Dat kon niet in een andere applicatie zitten of zo. Je kon dan vanuit die tool wel weer integreren met je CRM of met je Office pakket of zo. Dat is prima. Maar de tools zaten bij de agent echt in hetzelfde blok. En wat je dus nu ziet. Antropic heeft die MCP protocol hebben ze bedacht. Een model context protocol. Waardoor we eigenlijk kunnen zeggen. Nou, dat gereedschap zit niet in de agent. Die staat ergens anders. Die staat gewoon los op jouw laptop. Of die staat ergens op een andere server. En wat je nu krijgt is dat... Eerst was het zo. Als je honderd tools in je C-Sharp programma stopte. Dan werd het wat minder onderhoudbaar. Daar krijg je wel een klein beetje hoofdpijn van. Dus dan is dat de grens eigenlijk. Maar nu door het MCP-protocol kan ik gewoon zeggen. Ja, ik heb hier een groep gereedschap. En die heb ik op die machine staan. Op die andere server. En die kan ik los onderhouden. Dus in één keer kan ik veel grotere agents bouwen. Maar wat wel zo is, hoewel dat dus nu kan met het MCP-protocol, is het nog steeds zo dat als je je agent 250 tools geeft bijvoorbeeld, dan komt hij er niet meer uit. Dan gaat hij willekeurige dingen lopen doen, omdat het verschil tussen het gereedschap heel klein wordt. Het is alsof je 200 bitjes hebt voor een schroevendraaier. Dan wordt het toch een beetje moeilijk. Dan ga je gewoon maar wat proberen. Nee, dan pak ik de hamer. Ja, dat doet ChatGPT ook wel eens. En Ricardo bij ons intern ook. En toch nog eventjes voor de luisteraars. MCP-protocol. Wat kan ik daarmee? Wat doet dat functioneel? Want het klinkt heel erg leuk. Ja, dat is wel een goede vraag. Het MCP-protocol is bedacht eigenlijk als een manier om agents modulair op te zetten. Dus wat het bijvoorbeeld beschrijft is van welke gereedschappen er beschikbaar zijn. Dus dan kun je, de agent kan er een verzoek naartoe sturen en dan kan hij vragen, doe mij alle gereedschappen even. En wat hij dan terugkrijgt is een lijst van, ik heb deze gereedschappen met de beschrijving erbij hoe hij dat moet gebruiken. En dat zit allemaal in dat protocol vervangen, hoe je dat precies moet instellen. MCP doet nog meer, je kan namelijk ook standaard prompt daarin zetten. Dus we hebben allemaal wel eens een keer een prompt waar we zeggen van, oh ja, dit gebruik ik altijd om een offerte te schrijven. Dat zou je in een MCP-server kunnen stoppen en heb je hem altijd beschikbaar. En het voordeel daarvan is dat je, als je dat centraal in je organisatie regelt, dat je die ene MCP-server met die prompt door meerdere medewerkers kan laten gebruiken. Dus voor standaardisatie, herbruik binnen de organisatie zou je het kunnen inzetten. En je kan dus één keer zo'n applicatie of functie of activiteit beschikbaar stellen. En heel veel keer herbruiken, zodat je ook dat stukje heel goed kan testen. Het wordt ook een beetje vergeleken als de USB-poort voor agents. Dat vind ik een hele mooie. En vanwaar dan die vergelijking naar de USB? Omdat je prikt hem eigenlijk ergens in. Dus de makkelijkste vergelijking is nu, je hebt bijvoorbeeld Cloud Desktop. En daar prik je dan die MCP server in. En in één keer heeft die toegang tot jouw agent en kan die daarmee praten. En zitten ze in dat protocol wat Willem net beschrijft. Wisselen ze dus data uit. Die zeggen van, oh ja, ik kan dit. Oh, maar dan kan ik als Cloud Desktop data naar jou sturen. En jij handelt altijd weer voor mij af. En dat komt ook weer via een standaard manier terug. En dat hoeft niet een cloud desktop te zijn. Dat kan ook je eigen applicatie zijn. Als je zelf een MCP host maakt. Dus je kan een beetje dingen in elkaar pluggen. Dus hij is universeel. Iedereen begrijpt dat je hem overal kan inpluggen. Is dat op dit moment ook zo? Dat je hem overal kan inpluggen? Ga je hem tegen alle modellen aanzetten? Nou, die MCP ondersteunen. Ja, daarom. Dus dat is ook eigenlijk een standaard in de markt. Ja, OpenAI heeft zich hier aan gecommitteerd. Google heeft zich hier aan gecommitteerd. Het grappige is, ze zijn bij Antropic begonnen als van... Zouden we zoiets misschien kunnen maken? En binnen no time is het eigenlijk een soort van de facto standaard geworden. Ja, de tools die ik nu voor Ricardo gebruik... die zouden bij GitHub Copilot er ook gewoon in kunnen. Of dat nuttig is binnen de context van die agent... Ja, dat weet ik niet. Maar het kan wel. En wat je ziet, is dat door dat MCP, dat je dus heel makkelijk agents kan koppelen aan zo'n host, is dat je zo'n host dus steeds meer mogelijkheden geeft in wat hij kan doen. Dus hij kan dus ook data van die verschillende agents met elkaar combineren. Maar zelfs ook dat hij bepaalt van, Oh ja, maar nou roep ik tool X aan van agent 1. Dan krijg ik data terug. Oh, maar dan kan misschien tool van agent 2. Die kan daar misschien weer mee verder. Want dan kom ik verder tot mijn doelantwoord. Dus het gaat helemaal door elkaar lopen. Dus hoe meer agents je via zo'n MCP aan elkaar knoopt. Hoe meer zo'n host kan. Maar ook hoe meer er mis kan gaan. Ja, dat vraag ik me dus altijd. Het biedt heel veel mogelijkheden. Maar kan je dan ook wel je security daarop inbouwen? Wat je daar wel of niet mee kan. Want dat is dan wel, als ik mijn toolbox ga weggeven. En ik heb alle gereedschappen erin. Ja, dat is zeker een heel belangrijk punt in dit verhaal. Oorspronkelijk had het MCP-protocol geen beveiliging in zich zitten. Ja, ik zie je gezicht vertrekken dat je denkt, oh oh, dit is niet goed. Dat klopt ook, het is ook niet goed. Maar inmiddels is dat heel erg veranderd. Dus nu heb je bijvoorbeeld de mogelijkheid dat je één keer inlogt met je gebruikersaccount van je bedrijf. En dat je dan bij de MCP-service van het bedrijf kan komen. Daar kan de agent namens jouw taken uitvoeren. Dus als jij dan toegang hebt tot bepaalde gegevens, dan zie je ook alleen maar die gegevens en niet de rest. Dat is inmiddels, als je het zelf bouwt, moet je het natuurlijk zelf regelen. In het geval van bijvoorbeeld de GitHub MCP, die door heel veel ontwikkelaars wordt gebruikt. Dan heb je echt alleen maar toegang tot je eigen GitHub spullen en niet die van de buren. Ja, misschien gaan we nu een beetje te ver. Maar Joop vul gerust aan, want we moeten even iets meer terug. Maar moet ik dan een agent gaan markeren wat voor rechten die je in mijn systemen moet krijgen? Moet ik dat dan zo zien? Want nu zeg je, ik ga onder een gebruiker, onder een persoon, ga ik naar een systeem. En ik mag bijvoorbeeld wel sales zien, maar mijn collega mag bijvoorbeeld de sales niet zien. Ja, nou dat is dus het bijzondere aan het werken met agents. Tot voor kort was een agent, had geen eigen user account of identiteit. Dat is eigenlijk heel raar, want we maakten de agents een soort van superman binnen onze organisatie. En zeiden, jij mag overal bij. En daarna gingen we tegen hem zeggen in de instructies, ja maar wacht even. als je antwoord gaat geven aan deze gebruiker mag je dit niet vertellen. Praat niet over de roze olifant. En dat is heel raar. Dat kan eigenlijk niet. Dat is heel gevaarlijk. Er is vaak mee ingebroken ook. In Londen zijn we op QCon geweest. Daar hebben we ons helemaal slap gelachen, want daar werd gewoon ingebroken op een Amazon omgeving met een gedicht. Dus dat was echt spectaculair om te zien. Dat gaat veel te ver voor deze podcast. Het is vrij spectaculair hoe je het kapot kan maken. Dus wat we tegenwoordig doen eigenlijk, is we zeggen dan de agent krijgt een eigen identiteit binnen het bedrijf. Je zou bijna zeggen het is een medewerker. Die krijgt zelf rechten op systemen binnen onze landschap. En wat we ook nog eens zeggen, die agent die werkt namens iemand anders. Dus we vragen eerst aan jou om in te loggen. En dan kunnen we met jouw login gegevens een stapje verder gaan en dan kunnen we dan de taken uitvoeren die we zouden willen doen. Dus dan kan de agent binnen de vrijheid die de agent heeft gekregen bepalen, moet ik mijn Niels zijn account gebruiken om iets te doen? Of kan ik mijn eigen mandaat gebruiken om mijn oplossing te gaan doen? Het is een soort gelaagde beveiliging die we dus nu aan het inbouwen zijn overal. En ik zeg, we zijn aan het inbouwen. Er zijn nog erg veel agents in de wereld die dit principe niet kennen. Want het bestaat nog maar net, deze mogelijkheden. En het risico daarvan is dus dat die agent te veel mag. Of dat je zo druk bezig bent om het weer in te kaderen binnen de context van de opdracht. Om geen rare activiteit te krijgen. En dan krijg je dus hele mooie verhalen. Dan kun je een haiku schrijven waarmee je gewoon wachtwoorden en broncode van systemen kan ophalen. Als je het link hebt. Ik hou hem aan. Anders plaatsen we hem ook in de show notes voor de luisteraar. Zeker. We hebben ook het kaartspel. Daar ben je bekend mee natuurlijk. Dit keer generatieve AI in de zorg. We hebben allemaal met de zorg te maken. Dus we zijn benieuwd naar jouw perspectief hierop. Blijft een lekker nummertje. Willem, ik ga je even vragen om een nummer tussen de 1 en de 40 te noemen. En dan pak ik de stelling erbij. Ah, niet eens 42. Nee, dan had je al het antwoord op alles. Dan maken we er 38 van wat 39 is al gekozen. Oh, dat is. Het categorie en thema is wetgeving en beleid. En de stelling luidt als volgt. De zorgverlener is altijd eindverantwoordelijk bij inzet van AI in het zorgproces. ik zou heel kort kunnen zeggen ja dat klopt maar dat is omdat ik door de ervaring met de AI en ook de wetgeving tegenwoordig we mogen binnen Europa al AI niet zelfstandig een besluit laten nemen dus automatisch betekent dat eigenlijk wel dat degene die het gebruikt de verantwoordelijkheid draagt voor wat daar gebeurt en ik mag hopen dat de AI dan zodanig is gebouwd dat er ook even gecheckt wordt dus in dit geval zou ik zeggen als mijn huisarts dat bijvoorbeeld zou gebruiken zou ik zeggen ja, je bent wel verantwoordelijk jij bent degene met verstand van zaken die AI, die doet maar wat eigenlijk helder verhaal zeker even terug naar de LLM applicaties als mensen nou zouden willen beginnen, ja dan beginnen ze met het kopen van je boek links staat in de show notes maar even Hoe begin je? Want de opstap naar de agents. Zeker als je het op deze manier maakt. Is best wel groot. Dat is zeker waar. Ik heb zelf ook in mijn boek gekozen. Voor de opbouw. Begin eerst eens met een enkele prompt. Dus bouwen. Dus als we het even houden. Ik wil zelf zo'n programma. Vanaf begin bouwen. Dan zou ik zeggen. Begin met een eenvoudige webapplicatie. Waarbij je één prompt. met behulp van een taalmodel verwerkt. Wat bijvoorbeeld heel interessant kan zijn, als jij een content website aan het bouwen bent met C-Sharp, zou je bijvoorbeeld kunnen zeggen, ik moet een samenvatting hebben voor mijn SEO in Google, die laat ik door AI genereren. Daar ga ik dan Cement in Kernel voor gebruiken. Dan kun je er rustig aan wennen aan hoe dat werkt. Dan heb je nog geen tools, je hebt nog geen nauwelijks monitoring nodig eigenlijk. Je hebt ook geen moeilijkheden met verschillende modellen, want eigenlijk ieder model is goed. daar kun je dan heel mooi mee beginnen en dan kun je hem langzaamaan uitbreiden door bijvoorbeeld te zeggen ja maar voor die content heb ik geen zin om de hele content op te schrijven ik ga puntsgewijs content opschrijven en dan wil ik dat de AI dat gaat uitbreiden dus dan kun je een tweede punt pakken en eventueel zeggen van ja ik ga daar dan gereedschap bij halen dus dat zit ook in mijn boek ook heel erg die opbouw omdat ik denk van anders wordt het wel het zijn heel veel bewegende delen eigenlijk dit onderwerp dus dit helpt daar wel bij Als je het een beetje gelaagd opbouwt, dan kom je er wel uit, denk ik. En je zegt, heb je je boek ook opgebouwd? Neem je in het boek ook de lezer mee in een voorbeeld situatie? Of geef je juist die opdracht mee van bedenk eentje die past bij de lezer van het boek? Dat is heel erg lastig. Toen ik begon aan het boek, had ik dat eerst wel in mijn hoofd zitten. Ik ga één voorbeeld applicatie laten zien hoe je dat doet. Alleen alle verschillende concepten bouwen wel op elkaar voort. Maar als jij als einddoel een agent in gedachten hebt. Dat had ik namelijk als scenario. Dan is het bij semantic kernel. Dan begin je met een agent. En dan kun je de rest overslaan. Dat is heel flauw. Hij gebruikt dat intern. Dus dat maakt het wel eenvoudig natuurlijk. Als je echt professioneel bezig wilt. Maar aan de andere kant, daar leer je niks van. Dus ik heb een aantal losse voorbeelden erin staan. Dus bij ieder hoofdstuk staat er wel een voorbeeld wat je kan uitproberen. En ik heb er ook heel bewust voor gekozen. Om de voorbeelden op GitHub gewoon als open source aan te bieden. Doe ermee wat je wilt. Dus daar zit ook een hele leuke voorbeeld. Er zit ook een chatbot bij die je in principe zou kunnen uitrollen. Maar hij is niet beveiligd. Dus dat is het enige puntje van aandacht. Wat ik dan de mensen nog even mee moet geven vanaf hier. Maar ik heb dus echt wel verschillende ideeën neergezet. En ik denk eigenlijk dat het ook wel beter uitpakt. Omdat je dan ook doorkrijgt wat eigenlijk de breedte is van het onderwerp waar we het over hebben. Het is echt wel met het doel om langzaam stapjes bij te leren, te groeien en dan eigenlijk te gaan ervaren wat voor uitdagingen er op je afkomen. En die dan met elkaar te tackelen. Wat is nou het verschil met de handleiding die Microsoft eigenlijk gewoon geeft bij dit framework? Ik wil Microsoft zeker niet tekort doen in dit verhaal. Maar in het begin was de handleiding heel moeilijk te volgen. Hij was heel zo van ga hier kijken, ga daar kijken, ga daar kijken, ga daar kijken. Dus je werd alle kanten opgestuurd. En het is heel erg beperkt. Dus semantic kernel gebruiken met de handleiding, dan weet je een soort van, oh ja, dit is waar de knoppen zitten op het dashboard. Maar dat maak je nog niet ervaren. Dus wat ik heb geprobeerd in mijn boek is ook om aan te geven van Microsoft biedt deze en deze optie aan. Om bijvoorbeeld een tool te bouwen hebben ze wel vijf verschillende mogelijkheden. Maar ik weet uit ervaring dat alleen deze twee goed zijn. Dus in mijn boek zul je ook niet alle opties uit de handleiding vinden. Ik heb er bewust van gekozen om die opties aan te bieden waarvan ik denk, die zijn nuttig en die zijn van toepassing voor mensen die een enterprise-achtige applicatie willen bouwen. Ik ben geen boekenschrijver en ik zit hier met twee boekenschrijvers. Dus misschien dat het een hele domme vraag is. Ik heb je wel eens gehoord van je vorige boek. Dat was best wel een bevalling. Dat was best wel wat werk en dat soort zaken. Maar wat heeft je dan toch doen starten met je volgende boek? Oh ja, ik heb daar geen goede verklaring voor. Het is emotioneels denk ik. Ja, dat is het denk ik wel. Het is ook het gevoel van... De aanleiding van dit boek was toch wel een hoop frustratie over dat... Ik word ongeveer twintig keer per dag gebeld door mensen. Ik weet niet of het helemaal twintig keer is. Maar ik word heel vaak gebeld. Willem, we hebben hier bij deze klant een heel leuk idee. We willen daar AI voor inzetten. Wil jij even langskomen om ons te helpen? Nou, ik vind het allemaal heel erg cool. Maar natuurkundig gaat dat niet meer op den duur. En ik merkte ook wel dat ik er ook wel een beetje op leeg aan het lopen was. Om elke keer mensen daar steeds maar te helpen met ieder stapje die ze aan het nemen waren. En toen dacht ik, ja maar wacht even. Als ik het nou opschrijf, dan kan ik tegen mensen zeggen van... Ik wil je best helpen. Maar misschien is het handiger om eerst even mijn boek te lezen. Dan heb je in ieder geval een soort. Dan heb je mijn verhaal op een rijtje. En dan kun je daarna de rest wel vragen. Ja, dus een papieren kloon. Op een gat van informatie. Slash ervaring. Die je hebt opgedaan. Die dus eigenlijk ontbrak. Die je zover je kan klonen op dit moment op papier. Dus mogelijk heeft gemaakt. Ja, want echt klonen dat ging niet. Dat heeft onze CTO wel geprobeerd. Die had nog gebeld met China. Beweert hij. Dat weet ik niet zeker of dat zo is. Maar dat gaat natuurlijk niet. Dus daar is het eigenlijk uit voortgekomen. Daarom dacht ik op een gegeven moment in januari... Ja, ik ga het ook gewoon weer doen. Ach ja. Maar ik heb wel dingen aangepast. Mijn eerste boek was samen met een uitgever. En dat moest best wel onder druk geproduceerd worden. Dat vond ik echt wel heel erg lastig. Dan merkte ik ook op mezelf dat ik daar behoorlijk weerstand tegen ervaarde. En ik heb dit keer gekozen voor een aanpak zonder uitgever. Ik weet echt nog niet hoe dat gaat uitpakken. Tot nog toe gaat eigenlijk de verkoop best wel goed. Dan ben ik heel tevreden. Maar ik merk ook dat een uitgever... die geeft je ook extra ondersteuning. En die mis ik nu allemaal. Maar gelukkig heb ik goede vrienden zoals Joop. En mijn familie die meelezen. En collega's die meelezen. En wat ik had gedaan. Wat denk ik ook wel een mooie tip is hier. Ik heb hoofdstuk 1 direct uitgebracht. Ik ben direct begonnen met publiceren. En dat is supereng. de eerste keer dacht ik, oh wat heb ik nou weer gedaan maar dat helpt want mensen gaan het hoofdstuk lezen en die komen dan bij je terug, ik snap het niet oh ja, oké, dan moet ik het toch nog even anders insteken en dat kan dan gewoon, je kan gewoon terug gaan zolang het nog digitaal is kun je terug en dan kun je het aanpassen dat is wel heel mooi aan deze vorm van schrijven vind ik inmiddels is hij ook op papier te krijgen, dus nou ben ik het bokje nou moet ik iets anders bedenken maar ik denk ook dat nu de tijd rijp is Dus dat de tempo waarmee ik dingen aanpas gaat wat naar beneden. Ik ben er ook wel een beetje klaar mee hoor. Het was ook dit keer weer een bevalling. Maar ik ben wel een stuk tevredener dan over het vorige boek. Nou en wat ik weet is dat, want Samantha Kunnel is in ontwikkeling. En ze komen iedere keer features bij. Dat Willem best heel vaak de voorbeelden heeft moeten aanpassen. Omdat iets weer niet werkte of dat iets uit preview kwam. En dat gaat ongetwijfeld nog een keer gebeuren. Ik geef dat ook aan in mijn boek. Sommige delen zijn echt heel erg instabiel. Dus daar kun je maar zo zijn dat volgende week even niet werkt. En de andere delen zijn wel heel stabiel. Dus het wisselt ook heel snel. Ik heb hoofdstuk 7, zo even, ja dat was hoofdstuk 7. Die heb ik drie keer opnieuw gemaakt. Gewoon hele grote stukken van het hoofdstuk weg moeten gooien. Omdat er echt helemaal niets meer van klopte. En als we dan even kijken, wat is je doelgroep waar je het voor geschreven hebt? Is dat voor de techneut? Ja, mensen zeggen wel eens van ja, als je bij Willem in de buurt komt, moet je toch wel echt heel technisch onderlegd zijn. Ja, dit is echt voor techneuten bedoeld, voor software engineers. Ik denk, als je echt durft, dan moet je vooral lezen als je helemaal niks met techniek hebt. Er zitten ook hele blokken tussen met uitleg over wat een LLM is en hoe de statistiek in elkaar zit. Dat is misschien ook wel leuk om te lezen. maar het is wel echt gericht op softwareontwikkelaars. Dus voor de luisteraars die zelf niet technisch onderlegd zijn, geef hem aan je team om inderdaad in te zetten. Want als het goed is is er wel duidelijk geworden waarvoor je het kan inzetten en zie je de waarde voor je organisatie. Begin zelf met lezen en geef hem daarna door aan je development team om daar mooie stappen uit te halen. En de link staat in de show notes voor het bestellen van het boek. Leuk. Dankjewel Willem. Graag gedaan. Leuk dat je weer luisterde naar deze aflevering. Tot de volgende keer.