Leestijd 5 min

Alexander Frimout

Bij ACA zijn de Ship-IT Days no-nonsense innovatiedagen.

Leestijd 5 min

Remco Goyvaerts

De wereld van chatbots en Large Language Models (LLM's) heeft onlangs een spectaculaire evolutie doorgemaakt. Met ChatGPT, ontwikkeld door OpenAI, als een van de meest opmerkelijke voorbeelden, is de technologie erin geslaagd om meer dan 1.000.000 gebruikers te bereiken in slechts vijf dagen. Deze stijging onderstreept de groeiende interesse in conversational AI en de ongekende mogelijkheden die LLM's bieden. LLM's en ChatGPT: Een korte introductie Grote taalmodellen (LLM's) en chatbots zijn concepten die tegenwoordig onmisbaar zijn geworden in de wereld van kunstmatige intelligentie. Ze vertegenwoordigen de toekomst van mens-computerinteractie, waarbij LLM's krachtige AI-modellen zijn die natuurlijke taal begrijpen en genereren, terwijl chatbots programma's zijn die menselijke gesprekken kunnen simuleren en taken kunnen uitvoeren op basis van tekstuele invoer. ChatGPT, een van de opmerkelijke chatbots, heeft in korte tijd enorm aan populariteit gewonnen. LangChain: de brug naar LLM-gebaseerde toepassingen LangChain is een van de frameworks waarmee de kracht van LLM's kan worden benut voor het ontwikkelen en ondersteunen van toepassingen. Deze open-source bibliotheek, geïnitieerd door Harrison Chase, biedt een generieke manier om verschillende LLM's aan te spreken en uit te breiden met nieuwe gegevens en functionaliteiten. LangChain is momenteel beschikbaar in Python en TypeScript/JavaScript en is ontworpen om eenvoudig verbindingen te maken tussen verschillende LLM's en gegevensomgevingen. LangChain Kernconcepten Om LangChain volledig te begrijpen, moeten we enkele kernconcepten verkennen: Ketens: LangChain is gebouwd op het concept van een keten. Een keten is eenvoudigweg een generieke opeenvolging van modulaire componenten. Deze ketens kunnen worden samengesteld voor specifieke use cases door de juiste componenten te selecteren. LLMChain: Het meest voorkomende type keten binnen LangChain is de LLMChain. Deze bestaat uit een PromptTemplate, een Model (dat een LLM of een chatmodel kan zijn) en een optionele OutputParser. Een PromptTemplate is een sjabloon dat wordt gebruikt om een prompt voor de LLM te genereren. Hier is een voorbeeld: Met deze template kan de gebruiker een onderwerp invullen, waarna de ingevulde prompt als input naar het model wordt gestuurd. LangChain biedt ook kant-en-klare PromptTemplates, zoals Zero Shot, One Shot en Few Shot prompts. Model en OutputParser: Een model is de implementatie van een LLM-model zelf. LangChain heeft verschillende implementaties voor LLM modellen, waaronder OpenAI, GPT4All en HuggingFace. Het is ook mogelijk om een OutputParser toe te voegen om de uitvoer van het LLM-model te verwerken. Er is bijvoorbeeld een ListOutputParser beschikbaar om de uitvoer van het LLM-model om te zetten in een lijst in de huidige programmeertaal. Gegevensconnectiviteit in LangChain Om de LLM Chain toegang te geven tot specifieke gegevens, zoals interne gegevens of klantinformatie, gebruikt LangChain verschillende concepten: Documentladers Met documentloaders kan LangChain gegevens ophalen uit verschillende bronnen, zoals CSV-bestanden en URL's. Tekst Splitter Deze tool splitst documenten op in kleinere stukken zodat ze makkelijker verwerkt kunnen worden door LLM modellen, rekening houdend met beperkingen zoals tokenlimieten. Inbeddingen LangChain biedt verschillende integraties om tekstuele gegevens om te zetten in numerieke gegevens, zodat ze gemakkelijker te vergelijken en te verwerken zijn. Het populaire OpenAI Embeddings is hier een voorbeeld van. VectorStores Hier worden de ingesloten tekstuele gegevens opgeslagen. Dit kunnen bijvoorbeeld gegevensvectoropslagplaatsen zijn, waarbij de vectoren de ingesloten tekstuele gegevens vertegenwoordigen. FAISS (van Meta) en ChromaDB zijn enkele populaire voorbeelden. Retrievers Retrievers maken de verbinding tussen het LLM-model en de gegevens in VectorStores. Ze halen relevante gegevens op en breiden de prompt uit met de benodigde context, waardoor contextbewuste vragen en opdrachten mogelijk worden. Een voorbeeld van zo'n contextbewuste prompt ziet er als volgt uit: Demo toepassing Om de kracht van LangChain te illustreren, kunnen we een demotoepassing maken die de volgende stappen volgt: Gegevens ophalen op basis van een URL. De gegevens opsplitsen in hanteerbare blokken. De gegevens opslaan in een vector database. Een LLM toegang verlenen tot de vector database. Een Streamlit-toepassing maken die gebruikers toegang geeft tot de LLM. Hieronder laten we zien hoe je deze stappen in code uitvoert: 1. Gegevens ophalen Gelukkig vereist het ophalen van gegevens van een website met LangChain geen handmatig werk. Hieronder lees je hoe we dat doen: 2. Gegevens splitsen Het dataveld hierboven bevat nu een verzameling pagina's van de website. Deze pagina's bevatten veel informatie, soms te veel voor de LLM om mee te werken, omdat veel LLM's met een beperkt aantal tokens werken. Daarom moeten we de documenten opsplitsen: 3. Gegevens opslaan Nu de gegevens zijn opgesplitst in kleinere contextuele fragmenten, slaan we ze op in een vectordatabase om de LLM efficiënt toegang te geven tot deze gegevens. In dit voorbeeld gebruiken we Chroma: 4. Toegang verlenen Nu de gegevens zijn opgeslagen, kunnen we een "Chain" bouwen in LangChain. Een keten is simpelweg een reeks LLM-uitvoeringen om het gewenste resultaat te bereiken. Voor dit voorbeeld gebruiken we de bestaande RetrievalQA-keten die LangChain biedt. Deze keten haalt relevante contextfragmenten op uit de nieuw gebouwde database, verwerkt deze samen met de vraag in een LLM en levert het gewenste antwoord: 5. Streamlit toepassing maken Nu we de LLM toegang hebben gegeven tot de gegevens, moeten we de gebruiker een manier bieden om de LLM te raadplegen. Om dit efficiënt te doen, gebruiken we Streamlit: Agenten en hulpmiddelen Naast de standaardketens biedt LangChain ook de mogelijkheid om Agents te maken voor geavanceerdere toepassingen. Agents hebben toegang tot verschillende tools die specifieke functionaliteiten uitvoeren. Deze tools kunnen variëren van een "Google Search" tool tot Wolfram Alpha, een tool voor het oplossen van complexe wiskundige problemen. Hierdoor kunnen Agents geavanceerdere redeneertoepassingen bieden, waarbij ze beslissen welk hulpmiddel ze moeten gebruiken om een vraag te beantwoorden. Alternatieven voor LangChain Hoewel LangChain een krachtig raamwerk is voor het bouwen van LLM-gestuurde toepassingen, zijn er andere alternatieven beschikbaar. Een populair hulpmiddel is bijvoorbeeld LlamaIndex (voorheen GPT Index), dat zich richt op het verbinden van LLM's met externe gegevens. LangChain daarentegen biedt een completer framework voor het bouwen van applicaties met LLM's, inclusief tools en plugins. Conclusie LangChain is een spannend raamwerk dat de deuren opent naar een nieuwe wereld van conversationele AI en applicatieontwikkeling met grote taalmodellen. Met de mogelijkheid om LLM's te koppelen aan verschillende gegevensbronnen en de flexibiliteit om complexe toepassingen te bouwen, belooft LangChain een essentieel hulpmiddel te worden voor ontwikkelaars en bedrijven die willen profiteren van de kracht van LLM's. De toekomst van conversational AI ziet er rooskleurig uit en LangChain speelt een cruciale rol in deze evolutie.

Leestijd 9 min

Davy Steegen

In deze blogpost wil ik je een overzicht geven van de OAuth 2 specificatie. Toen ik me hierin begon te verdiepen, verdwaalde ik al snel in alle verschillende aspecten. Om ervoor te zorgen dat jij niet hetzelfde hoeft te doen, zal ik OAuth 2 uitleggen alsof je niet eens een technische achtergrond hebt. Omdat er veel te behandelen valt, laten we er meteen in springen! De kernconcepten van beveiliging Als het gaat om het beveiligen van een applicatie, zijn er 2 kernconcepten die je in gedachten moet houden: authenticatie en autorisatie . Authenticatie Met authenticatie probeer je de vraag "Wie is iemand?" of "Wie is deze gebruiker?" te beantwoorden. Je moet het bekijken vanuit het perspectief van je applicatie of je server. Ze hebben in principe vreemdelingengevaar. Ze weten niet wie je bent en er is geen manier voor hen om dat te weten tenzij je je identiteit aan hen bewijst. Authenticatie is dus het proces om aan de applicatie te bewijzen dat je bent wie je beweert te zijn . In een voorbeeld uit de echte wereld is dit het verstrekken van je ID of paspoort aan de politie wanneer ze je aan de kant zetten om jezelf te identificeren. Authenticatie is geen onderdeel van de standaard OAuth 2 specificatie. Er is echter een uitbreiding op de specificatie genaamd Open ID Connect die dit onderwerp behandelt. Autorisatie Autorisatie is de keerzijde van authenticatie. Zodra een gebruiker heeft bewezen wie hij is, moet de applicatie uitzoeken wat een gebruiker mag doen . Dat is in wezen wat het autorisatieproces doet. Een eenvoudige manier om hierover na te denken is het volgende voorbeeld. Als je een leraar bent op een school, heb je toegang tot informatie over de leerlingen in je klas. Als je echter de directeur van de school bent, heb je waarschijnlijk toegang tot de gegevens van alle leerlingen van de school. Je hebt een grotere toegang vanwege je functie. OAuth 2 Rollen Om OAuth 2 volledig te begrijpen, moet je je bewust zijn van de volgende 4 actoren die de specificatie vormen: Eigenaar van de bron Bronnen server Machtigingsserver Client / Toepassing Zoals eerder leggen we het uit met een heel eenvoudig voorbeeld om te zien hoe het echt werkt. Laten we zeggen dat je een jas hebt. Omdat je de eigenaar bent van die jas, ben je de eigenaar van de bron en de jas is de bron die je wilt beschermen. Je wilt het jasje opbergen in een kluisje om het veilig te bewaren. Het kastje zal fungeren als de Resource Server . Je bent geen eigenaar van de Resource Server, maar hij bewaart je spullen voor je. Omdat je wilt voorkomen dat het jasje door iemand anders wordt gestolen, moet je een slot op het kastje zetten. Dat slot is de autorisatieserver . Deze regelt de beveiligingsaspecten en zorgt ervoor dat alleen jij toegang hebt tot de jas of mogelijk iemand anders die jij toestemming geeft. Als je wilt dat je vriend je jasje uit het kastje haalt, dan kan die vriend gezien worden als de Client of Applicatie actor in de OAuth flow. De Client handelt altijd namens de gebruiker. Tokens Het volgende concept waar je veel over zult horen is tokens. Er zijn verschillende soorten tokens, maar ze zijn allemaal heel eenvoudig te begrijpen. De 2 soorten tokens die je het meest tegenkomt zijn access tokens en refresh tokens . Als het gaat om toegangsmunten, heb je misschien wel eens gehoord van JWT-tokens, tokens aan toonder of opake tokens. Dat zijn eigenlijk alleen maar implementatiedetails die ik in dit artikel niet ga behandelen. In essentie is een toegangstoken iets dat je aan de resource server geeft om toegang te krijgen tot de items die hij voor je bewaart. Je kunt toegangsmunten bijvoorbeeld zien als papieren kaartjes die je op de kermis koopt. Als je in een attractie wilt stappen, laat je je ticket zien aan de persoon in het hokje en die laat je instappen. Je maakt een ritje en na afloop verloopt je ticket. Belangrijk om te weten is dat wie het token heeft, eigenaar is van het token . Wees er dus heel voorzichtig mee. Als iemand anders je token in handen krijgt, kan hij of zij namens jou toegang krijgen tot je items! Refresh tokens lijken erg op access tokens. In wezen gebruik je ze om meer toegangsmunten te krijgen. Toegangsmunten hebben meestal een korte levensduur, maar verversingsmunten hebben vaak een langere vervaldatum. Om terug te komen op ons kermisvoorbeeld, een verversingstoken zou de creditcard van je ouders kunnen zijn die kan worden gebruikt om meer kermiskaartjes te kopen die je kunt uitgeven aan attracties. Scopes Het volgende concept dat we behandelen zijn scopes. Een scope is in feite een beschrijving van dingen die een persoon kan doen in een applicatie. Je kunt het zien als een functie in het echte leven (bijvoorbeeld een directeur of leraar op een middelbare school). Bepaalde scopes geven je meer rechten dan andere. Ik weet dat ik zei dat ik niet in technische details zou treden, maar als je bekend bent met Spring Security, dan kun je scopes vergelijken met wat Spring Security rollen noemt. Een scope komt één op één overeen met het concept van een rol. De OAuth specificatie specificeert niet hoe een scope eruit moet zien, maar vaak zijn het punt-gescheiden Strings zoals blog.write . Google daarentegen gebruikt URL's als scope. Als voorbeeld: om alleen-lezen toegang tot iemands agenda toe te staan, geven ze de scope https://www.googleapis.com/auth/calendar.readonly. Toelage types Types van toekenningen zijn typisch waar dingen verwarrend beginnen te worden voor mensen. Laten we beginnen met het tonen van de meest gebruikte grant types: Clientgegevens Machtigingscode Apparaatcode Vernieuwen Wachtwoord impliciet Client Credentials is een type toekenning dat vaak wordt gebruikt als 2 back-end diensten op een veilige manier met elkaar moeten communiceren. De volgende is het grant type Authorization Code , wat waarschijnlijk het moeilijkste grant type is om volledig te begrijpen. Je gebruikt dit type grant wanneer je gebruikers wilt laten inloggen via een browsergebaseerd aanmeldformulier. Als je ooit de knop 'Log in met Facebook ' of 'Log in met Google' op een website hebt gebruikt, dan heb je zonder het te weten al een autorisatiecodestroom ervaren! De volgende is het toestemmingscodetype , dat vrij nieuw is in de OAuth 2-scene. Het wordt meestal gebruikt op apparaten met beperkte invoermogelijkheden, zoals een TV. Als je bijvoorbeeld wilt inloggen op Netflix, in plaats van je gebruikersnaam en wachtwoord op te geven, verschijnt er een link met een code die je moet invullen met de mobiele app. Het Refresh grant type gaat meestal hand in hand met de Authorization Code flow. Omdat toegangstokens een korte levensduur hebben, wil je niet dat je gebruikers telkens moeten inloggen als het toegangstoken verloopt. Dus is er deze refresh flow die refresh tokens gebruikt om nieuwe access tokens te verkrijgen wanneer ze bijna verlopen zijn. De laatste 2 toekenningsvormen zijn Wachtwoord en Impliciet . Deze toekenningsvormen zijn minder veilige opties die niet worden aanbevolen bij het bouwen van nieuwe applicaties. We zullen ze kort behandelen in de volgende sectie, waarin de bovenstaande toekenningsvormen in meer detail worden uitgelegd. Autorisatie stromen Een autorisatiestroom bevat een of meer stappen die moeten worden uitgevoerd om een gebruiker te autoriseren door het systeem. Er zijn 4 autorisatiestromen die we zullen bespreken: Client Credentials stroom Wachtwoord stroom Autorisatie Code stroom Impliciete stroom Client Credentials stroom De Client Credentials stroom is de eenvoudigste stroom om te implementeren. Het werkt ongeveer hetzelfde als hoe een traditionele gebruikersnaam/wachtwoord login werkt. Gebruik deze flow alleen als je de client/applicatie kunt vertrouwen, omdat de client credentials worden opgeslagen binnen de applicatie. Gebruik dit niet voor single page apps (SPA's) of mobiele apps, omdat kwaadwillende gebruikers de app kunnen deconstrueren om de credentials te bemachtigen en deze te gebruiken om toegang te krijgen tot beveiligde bronnen. In de meeste use cases wordt deze flow gebruikt om veilig te communiceren tussen 2 back-end systemen. Hoe werkt de Client Credentials stroom? Elke applicatie heeft een client ID en secret die geregistreerd zijn op de autorisatieserver. De applicatie presenteert deze aan de autorisatieserver om een toegangstoken te krijgen en gebruikt het om de beveiligde bron van de resource server te krijgen. Als op een bepaald moment het toegangstoken verloopt, herhaalt hetzelfde proces zich om een nieuw token te krijgen. Wachtwoord stroom De Password flow lijkt erg op de Client Credentials flow, maar is erg onveilig omdat er een 3e actor bij betrokken is, namelijk een daadwerkelijke eindgebruiker. In plaats van een veilige client die we vertrouwen die een ID en geheim aan de autorisatie provider presenteert, hebben we nu een gebruiker die met een client 'praat'. In een Password flow geeft de gebruiker zijn persoonlijke gegevens aan de client. De client gebruikt deze gegevens om toegangstokens te krijgen van de autorisatieserver. Dit is de reden waarom een Password flow niet veilig is, omdat we er absoluut zeker van moeten zijn dat we kunnen vertrouwen dat de client de credentials niet misbruikt voor kwaadaardige redenen. Uitzonderingen waarbij deze flow nog steeds gebruikt zou kunnen worden zijn commandoregelapplicaties of bedrijfswebsites waarbij de eindgebruiker de client-apps moet vertrouwen die hij dagelijks gebruikt. Maar afgezien hiervan wordt het niet aanbevolen om deze flow te implementeren. Autorisatie Code Stroom Dit is de stroom die je zeker wilt begrijpen, omdat het de stroom is die het meest wordt gebruikt bij het beveiligen van applicaties met OAuth 2. Deze stroom is iets gecompliceerder dan de eerder besproken stromen. Het is belangrijk om te begrijpen dat deze flow vertrouwelijk, veilig en browsergebaseerd is . De flow werkt door veel HTTP redirects te maken, daarom is een browser een belangrijke speler in deze flow. Er is ook een back-channel verzoek (zo genoemd omdat de gebruiker niet betrokken is bij dit deel van de stroom) waarbij de client of applicatie rechtstreeks met de autorisatieserver praat. In deze flow moet de gebruiker meestal de scopes of rechten goedkeuren die aan de applicatie worden toegekend. Een voorbeeld hiervan is een applicatie van derden die vraagt of je toegang mag krijgen tot je Facebook-profielfoto nadat je bent ingelogd met de knop 'Aanmelden met Facebook'. Laten we de Autorisatiecode-flow toepassen op ons voorbeeld 'jas in de kast' om een beter begrip te krijgen. Onze jas ligt in de kast en we willen hem uitlenen aan een vriend. Onze vriend gaat naar het (hightech) kluisje. Het kastje belt ons, want wij zijn de Resource Owner. Deze oproep is een van die redirects waar we het eerder over hadden. Op dit punt maken we een beveiligde verbinding met het kastje, dat fungeert als een autorisatieserver. We kunnen nu veilig onze referenties geven om toestemming te geven om het slot te ontgrendelen. De autorisatieserver verstrekt vervolgens een tijdelijke code, de OAuth-code, aan onze vriend. De vriend gebruikt vervolgens die OAuth-code om een toegangscode te verkrijgen om het kastje te openen en mijn jas te pakken. Impliciete stroom De impliciete flow is in principe hetzelfde als de autorisatiecode flow, maar dan zonder de tijdelijke OAuth code. Dus na het inloggen stuurt de autorisatieserver direct een toegangstoken terug zonder dat er een back-channelverzoek nodig is. Dit is minder veilig, omdat het token onderschept kan worden via een man-in-the-middle aanval. Conclusie OAuth 2 kan er in eerste instantie ontmoedigend uitzien vanwege alle verschillende actoren die erbij betrokken zijn. Hopelijk begrijp je nu beter hoe ze met elkaar samenwerken. Met deze kennis in je achterhoofd is het veel gemakkelijker om de technische details te begrijpen als je je er eenmaal in begint te verdiepen.