LLMOps Essentials: een praktische gids voor het operationaliseren van Large Language Models
Ontdek de essentials van LLMOps met onze gids over het operationaliseren van Large Language Models voor efficiëntie en betrouwbaarheid in AI-toepassingen.
Wanneer wij als gebruikers met ChatGPT interacteren, typen we simpelweg een prompt in de webinterface en drukken we op enter. Meestal ontvangen we binnen enkele seconden een reactie. Onder deze naadloze interactie schuilt echter een complexe en ordelijke reeks stappen die het mogelijk maken dat ChatGPT zo’n ervaring levert.
De automatische uitvoering van deze reeks stappen, bekend als Large Language Model Operations (LLMOps), garandeert dat de prompt niet alleen het model bereikt, maar ook efficiënt, nauwkeurig en betrouwbaar wordt verwerkt. Dit zorgt voor de levering van een goed geformuleerd antwoord binnen een redelijke tijd.
In dit artikel duiken we in het LLMOps-paradigma door de reis van een prompt door een Large Language Model (LLM)-dienst, zoals ChatGPT, te volgen. We bekijken de cruciale fasen, waaronder promptvoorbewerking, modelselectie, generatie van antwoorden, en de vaak over het hoofd geziene maar vitale aspecten zoals load balancing, monitoring en Continuous Integration.
Wat is LLMOps?
LLMOps is inderdaad een evolutie van de bekende Machine Learning Operations (MLOps), toegesneden op de concrete uitdagingen die LLM’s met zich meebrengen. Terwijl MLOps draait om levenscyclusbeheer van algemene Machine Learning-modellen, omvat LLMOps aspecten die uniek zijn voor dit type modellen.
Het is cruciaal te begrijpen dat LLMOps voor ons transparant zijn wanneer we met een model van OpenAI of Google interacteren, of dat nu via een webinterface is of via API-calls vanuit onze code. In dit scenario zeggen we dat deze modellen as-a-service worden aangeboden.
Als ons doel daarentegen is om ons eigen model voor een specifieke usecase aan te bieden zonder afhankelijk te zijn van externe providers, bijvoorbeeld een assistent voor medewerkers van een bedrijf, dan ligt de verantwoordelijkheid voor LLMOps bij ons.
Ongeacht de mogelijkheden van ons nieuwe model, zal het succes als dienst in hoge mate afhangen van de aanwezigheid van een robuuste en betrouwbare LLMOps-infrastructuur. Als je meer wilt weten over MLOps, is de tutorial MLOps Fundamentals iets voor jou!
Oorsprong van LLMOps
Vroege LLM’s zoals GPT-2 werden in 2018 geïntroduceerd. Ze zijn echter pas recent populair geworden, voornamelijk door de aanzienlijke vooruitgang in de capaciteiten van de nieuwere versies van die modellen, vanaf GPT-3 en verder.
Er zijn meerdere toepassingen ontstaan die LLM’s benutten dankzij hun indrukwekkende modelcapaciteiten. Voorbeelden zijn klantenservice-chatbots, vertaaldiensten en schrijf- en codeerassistenten, onder andere.
Het ontwikkelen van productieklare toepassingen die worden aangedreven door LLM’s brengt een unieke set uitdagingen met zich mee, anders dan bij traditionele ML-modellen. Om deze uitdagingen aan te pakken, zijn nieuwe tools en best practices ontwikkeld voor het beheren van de levenscyclus van LLM-toepassingen, wat heeft geleid tot het concept “LLMOps”.
Waarom LLMOps?
LLMOps is essentieel om deze complexe modellen efficiënt te beheren wanneer ze as-a-service worden ingezet, om meerdere redenen:
1. LLM’s zijn niet alleen groot qua hoeveelheid data die ze verwerken, maar ook qua aantal parameters. LLMOps zorgt ervoor dat de infrastructuur deze modellen kan ondersteunen op het gebied van opslag en bandbreedte.
2. Voor gebruikers is het cruciaal om in zo min mogelijk tijd een nauwkeurig antwoord te krijgen. LLMOps zorgt ervoor dat reacties binnen een redelijke tijd worden geleverd, zodat de vloeiendheid van mensachtige interacties behouden blijft.
3. Continu monitoren onder LLMOps draait niet alleen om het volgen van operationele aspecten of storingen in de infrastructuur. Het omvat ook zorgvuldig het gedrag van het model volgen om de besluitvormingsprocessen te begrijpen en het model in toekomstige iteraties verder te verbeteren.
4. Het draaien van LLM’s kan duur zijn vanwege de benodigde resources. LLMOps introduceert kosteneffectieve strategieën om te zorgen dat resources optimaal worden gebruikt zonder in te leveren op prestaties.
Achter de schermen van een LLM-service
Om LLMOps te begrijpen, is het belangrijk bekend te zijn met wat er “achter de schermen” gebeurt wanneer LLM’s as-a-service worden aangeboden. Dat is het pad dat een prompt volgt vanaf het moment dat deze aan het model wordt verstrekt tot het antwoord is gegenereerd. Het volgende schema toont deze workflow:
LLMOps-workflow: de stappen achter de schermen van een generieke LLM as-a-service. Gebruikersinvoer (in groen) doorloopt enkele stappen voordat deze naar het model gaat. Op vergelijkbare wijze ondergaat de modeluitvoer (in rood) meerdere transformaties voordat die aan de gebruiker wordt getoond.
Zoals we in het bovenstaande schema kunnen zien, doorloopt de prompt meerdere stappen voordat die het model bereikt. Hoewel het aantal stappen kan variëren, zijn er basiselementen om er bijvoorbeeld voor te zorgen dat de invoer duidelijk wordt begrepen en dat het antwoord van het model contextueel relevant is. Laten we deze stappen uitsplitsen:
1. Preprocessing
Deze stap bereidt de prompt van de gebruiker voor zodat het model deze kan begrijpen en verwerken. Dit omvat tokenization, waarbij de prompt wordt opgedeeld in kleinere eenheden, zogenaamde tokens. Deze stap omvat ook datanormalisatie, waaronder het verwijderen of transformeren van ruis in de data, zoals speciale tekens, het corrigeren van typefouten en het standaardiseren van de tekst.
Tot slot worden tijdens het encoderen tokens omgezet in een numerieke vorm die het model kan begrijpen. Dit gebeurt met behulp van embeddings, die elk token als een vector in een hoog-dimensionale ruimte representeren.
2. Grounding
Dit omvat het contextualiseren van de prompt op basis van eerdere gespreksbeurten of externe kennisbronnen om te zorgen dat het antwoord van het model coherent en contextueel passend is. Daarnaast helpen entiteitsherkenning en linking het systeem om entiteiten (zoals namen, plaatsen en datums) in de prompt te identificeren en te koppelen aan de relevante context.
3. Verantwoorde AI
Om te borgen dat het gebruik van LLM’s goede doeleinden dient, implementeren sommige diensten sanity-checks op de prompts van gebruikers. Meestal wordt de prompt beoordeeld aan de hand van veiligheids- en compliance-richtlijnen, met name in scenario’s met gevoelige informatie, ongepaste inhoud, bias of mogelijke desinformatie.
Pas na deze stappen wordt de prompt uiteindelijk doorgestuurd naar het model voor verwerking. Nadat het model het antwoord heeft gegenereerd, en voordat dit aan de gebruiker wordt getoond, kan het antwoord opnieuw de stappen voor Grounding en Verantwoorde AI doorlopen, plus een extra nabewerkingsstap:
4. Post-processing
Het antwoord dat door het model wordt gegenereerd is numeriek van aard vanwege de eerder genoemde vectorembeddings. Daarom is een decodering essentieel om deze numerieke data terug te zetten naar voor mensen leesbare tekst. Na het decoderen is een verfijnings-stap nodig om het antwoord te polijsten qua grammatica, stijl of leesbaarheid.
Tot slot wordt het antwoord aan de gebruiker getoond. De LLMOps-infrastructuur is verantwoordelijk voor het uitvoeren van deze stappen, onzichtbaar voor de gebruiker.
Latentie
Tot nu toe hebben we heel wat stappen gezien die de LLMOps-infrastructuur moet uitvoeren vanaf het moment dat een gebruiker een prompt verzendt totdat deze het antwoord terugkrijgt. Op dit punt is een redelijke vraag: Hoeveel tijd kosten deze stappen?
Bij het gebruik van ChatGPT is de reactietijd normaal gesproken vrijwel direct. Deze reactietijd staat bekend als latentie. Latentie is een kritieke prestatie-indicator, vooral in applicaties die direct contact met de gebruiker hebben, waar de responstijd de gebruikerservaring sterk beïnvloedt. De juiste latentie kiezen is cruciaal en hangt af van onze usecase.
Om de latentie van de respons te verlagen, past LLMOps verschillende strategieën en best practices toe om het volledige proces van inputontvangst tot responslevering te stroomlijnen. LLMOps draagt bij aan het verlagen van de modellatentie door alle vereiste stappen automatisch uit te voeren en de benodigde resources efficiënt te beheren, zodat geen berekening hoeft te wachten op beschikbare resources. Andere best practices kunnen de latentie eveneens verlagen:
Caching: Het opslaan van veelgebruikte of computationeel intensieve delen van de modeluitvoer, zodat ze niet bij elk verzoek opnieuw hoeven te worden berekend.
Gelijktijdige verwerking: Meerdere verzoeken parallel verwerken, bijvoorbeeld wanneer meerdere gebruikers tegelijkertijd verzoeken sturen, om beschikbare rekenresources beter te benutten en wachttijd te verminderen.
Monitoring: Het profileren van verschillende componenten van het model en de infrastructuur om knelpunten te identificeren en ze zo snel mogelijk te optimaliseren.
Het verminderen van latentie verbetert niet alleen de gebruikerservaring, maar draagt ook bij aan kostenefficiëntie door het resourcegebruik te optimaliseren.
Belangrijke componenten van LLMOps
Het juiste foundation model kiezen
Tot nu toe hebben we nog niet besproken welk model in onze LLMOps-setup zou moeten zitten. Er zijn verschillende soorten modellen beschikbaar, elk geoptimaliseerd voor specifieke usecases, met verschillende groottes, enzovoort. Het selecteren van het juiste model is cruciaal en hangt in grote mate af van onze applicatie en beschikbare resources.
Bovendien lijkt het aantal LLM’s en providers dagelijks toe te nemen. Daarom is een breed begrip van de verschillende soorten LLM’s en hun providers nuttig, vooral wanneer je probeert te bepalen welke het beste bij je usecase past.
LLM-providers
LLM-modellen en -providers kunnen in de volgende typen worden ingedeeld:
Proprietary-modellen: Deze categorie omvat bedrijven zoals OpenAI (GPT-modellen), Google (PaLM-modellen) en Anthropic (Claude-model), die eigen LLM’s trainen en deze as-a-service aanbieden via webinterfaces of API-endpoints.
Open-sourcemodellen: Deze categorie omvat gratis modellen die zijn ontwikkeld door de community, de academische wereld of organisaties zoals Eleuther AI en BigScience. Deze organisaties vertrouwen doorgaans op donaties voor de rekeninfrastructuur. Idealiter zouden we een open-sourcemodel kunnen nemen en de dienst zelf kunnen bouwen, inclusief de LLMOps-infrastructuur.
Bedrijven die infrastructuur leveren: Dit zijn bedrijven die de LLMOps-infrastructuur voor open-source LLM’s leveren. Ze verdienen dus aan het aanbieden van deploymentdiensten, zoals bij bedrijven als Together AI. Hierbij biedt het bedrijf de mogelijkheid om je LLMOps-infrastructuur eenvoudig aan te passen.
Proprietary-modellen vs open-source
De belangrijkste voordelen van open-sourcemodellen liggen in de transparantie en de mogelijkheid om ze aan te passen. Open-sourcemodellen bieden doorgaans volledige controle over alle componenten, waardoor eenvoudig debuggen en uitgebreide aanpassing via training of fine-tuning mogelijk is. Deze mate van flexibiliteit zorgt ervoor dat het LLM beter kan aansluiten op jouw specifieke behoeften, in plaats van te moeten voldoen aan de vooraf gedefinieerde opties van de LLM-provider.
Het zelfstandig beheren van open-source LLM’s kan echter leiden tot aanzienlijke engineeringuitdagingen en kosten op het gebied van computing en opslag. Zelfs als er een minimale infrastructuur door open-sourcemodellen wordt geboden, is het vaak lastig om te concurreren met proprietary-modellen qua latentie, doorvoer en inferencekosten.
Criteria voor modelselectie
Er zijn veel modellen om uit te kiezen. Maar hoe zorgen we dat we het juiste LLM kiezen?
Er zijn inderdaad enkele criteria om te overwegen, afhankelijk van onze usecase en mogelijkheden:
Kosten: We moeten niet alleen rekening houden met de inferencekosten van het model, maar ook met de engineeringkosten voor onderhoud, monitoring en optimalisatie van het model.
Type taken: De aard van de taken waarvoor het LLM wordt ingezet, zoals samenvatten, vraagbeantwoording, enzovoort, moet aansluiten bij de capaciteiten van het model. Modellen die al zijn gefinetuned voor onze doeltaak besparen ons tijd en geld bij het uitvoeren van eigen fine-tuning.
Prestatie-indicatoren: Veel providers maken de prestaties van hun modellen openbaar, zoals de snelheid van tekstgeneratie (Time Per Output Token) en de tijd tot de eerste token (Time To First Token). We moeten zeker weten dat het model presteert zoals verwacht voor onze usecase.
Licenties: Het is cruciaal om modellen te selecteren die ons beoogde gebruik toestaan. Zelfs modellen die expliciet commercieel gebruik toestaan, kunnen beperkingen hebben op specifieke soorten usecases. Zo legt de BigScience Open RAIL-M-licentie beperkingen op aan het gebruik van het LLM in domeinen die verband houden met wetshandhaving, immigratie en asielprocessen, onder andere.
Fine-tuningstrategieën
Of het nu proprietary of open-source is, LLM’s hebben vaak fine-tuning nodig om echt geschikt te zijn voor specifieke toepassingen.
Er zijn vooraf gefinetunede LLM’s beschikbaar voor bepaalde gebruikerstaken, vaak inclusief chatmodellen en modellen die gespecialiseerd zijn in samenvatten of sentimentanalyse. Een andere variant om te overwegen zijn long-context-modellen. Moderne LLM’s verwerken doorgaans contextlengtes van 2.000 tot 8.000 tokens, wat betekent dat input en output buiten dit bereik niet direct verwerkt kunnen worden. Sommige modellen bieden echter long-context-varianten. Zo heeft GPT-3.5 een grotere 16k-contextvariant.
Als de bestaande opties desondanks niet aan specifieke eisen voldoen, is er altijd de mogelijkheid om een model te fine-tunen of zelfs helemaal zelf te trainen. In dat geval is het kiezen van een geschikte dataset cruciaal, omdat dit het model helpt de aard van de doeltaak te begrijpen.
Als je geïnteresseerd bent in het vanaf nul trainen van een LLM-model, raad ik je echt de DataCamp-tutorial How to train an LLM with PyTorch aan.
Modelaanpassing
Als onze toepassing fine-tuning van een bestaand model vereist, moeten de bijbehorende stappen ook deel uitmaken van onze LLMOps-setup. Laten we deze aanpassingsstap aan ons oorspronkelijke diagram toevoegen:
LLMOps-workflow: inclusief de Model Customizatin-stappen (in oranje) in onze generieke workflow.
Een consistente fine-tuningpipeline kan je helpen de kennis van je model in de loop van de tijd uit te breiden naarmate er meer data beschikbaar komt, waardoor je moeiteloos je LLM-versie kunt upgraden of andere wijzigingen kunt doorvoeren.
Wanneer we afhankelijk zijn van modellen van derden, is het belangrijk te beseffen dat deze modellen kunnen veranderen in beschikbaarheid en kosten. Dit kan ons mogelijk dwingen om over te stappen op een ander basismodel. Een robuuste LLMOps-setup stelt ons in staat om deze kritieke situatie soepel af te handelen door simpelweg het vak “Model” te vervangen door een ander LLM.
Trainingsdata
Je zou kunnen denken dat het fine-tunen van je LLM of het vanaf nul trainen ervan een eerste stap buiten de LLMOps-infrastructuur is, aangezien het LLM pas gaat draaien zodra het in productie staat. Toch is dat niet zo, zeker om de eerder genoemde reden: een succesvolle dienst zal modelverbeteringen nodig hebben en veerkrachtig moeten zijn bij eventuele wisselingen van providers.
Voor effectieve training, fine-tuning of modelverfijning in een generieke LLMOps-infrastructuur is het belangrijk om de data-indeling consistent te houden tussen trainingsdata en latere inferentiedata. Hiervoor formatteren we de trainingsdata doorgaans in het JSON Lines-formaat (.jsonl). Dit formaat is zeer geschikt voor fine-tuning van LLM’s vanwege de structuur, die efficiënte verwerking van grote datasets mogelijk maakt. Een typisch .jsonl-bestand voor fine-tuning kan er zo uitzien:
{"prompt":"Question: What is the capital of France?","completion":"The capital of France is Paris."}{"prompt":"Question: Who wrote Macbeth?","completion":"Macbeth was written by William Shakespeare."}Mogelijk gemaakt door
Elke regel in een .jsonl-bestand is een afzonderlijk JSON-object dat een enkel trainingsexample vertegenwoordigt, met prompt- en completion-sleutels die respectievelijk de invoertekst en de verwachte modelrespons aangeven, zoals we tijdens inferentie zouden verwachten. Daarnaast vergemakkelijkt dit formaat het incrementeel toevoegen van nieuwe data aan de kennisbasis van het model.
Trainings- en inferentieparameters
Modelparameters zijn ook belangrijk bij het inrichten van onze LLMOps-infrastructuur, omdat ze impact hebben op kenmerken zoals modelgrootte en resourceverbruik.
Wat betreft trainingsparameters is het belangrijk om deze te optimaliseren om de complexiteit van het model in balans te brengen met deploybeperkingen zoals geheugengebruik. Deze optimalisatie is cruciaal om modellen in uiteenlopende omgevingen met verschillende resourcecapaciteiten te kunnen uitrollen, zodat modellen niet alleen geavanceerd zijn, maar ook praktisch voor real-world toepassingen.
Wat betreft inferentieparameters stelt het aanpassen van parameters zoals temperature en max tokens je in staat de lengte en willekeurigheid van de antwoorden te sturen. Deze instellingen worden beheerd als onderdeel van het LLMOps-proces om de modeluitvoer in lijn te brengen met de specifieke toepassingsvereisten en de intentie van de gebruiker.
Prompt engineering en -beheer
Prompt-engineeringtechnieken blijken de standaardcapaciteiten van LLM’s te verbeteren. Een reden hiervoor is dat ze helpen het model te contextualiseren. Bijvoorbeeld door het model te instrueren zich als expert in een specifiek domein te gedragen of het model richting een gewenst outputformaat te sturen. Prompt Engineering en Management zijn cruciale componenten die in onze LLMOps-setup moeten worden opgenomen.
Tot de meest effectieve prompt-engineeringpraktijken behoren few-shot prompting en chain-of-thought reasoning. Laten we deze technieken kort bespreken en aangeven hoe we ze in onze LLMOps-setup kunnen integreren:
Few-shot prompting houdt in dat je het LLM in de prompt zelf een klein aantal voorbeelden (shots) van de taak geeft. Dit helpt het model de specifieke taak beter te begrijpen en uit te voeren.
Chain-of-thought-reasoning houdt in dat je prompts zo structureert dat het model door een stapsgewijs redeneerproces wordt geleid. Deze techniek is vooral nuttig voor complexe taken die logische redenering of koppeling met externe bronnen vereisen.
Het implementeren van technieken zoals few-shot prompting en chain-of-thought-reasoning binnen onze LLMOps-setup kan effectief worden gerealiseerd met behulp van prompttemplates.
Prompttemplates
Prompttemplates zijn vooraf gedefinieerde structuren om het redeneren van LLM’s te sturen. Ze bieden een consistente structuur, zorgen ervoor dat vergelijkbare verzoeken uniform worden gedaan of helpen om prompt-engineeringtechnieken onzichtbaar voor de gebruiker op te nemen.
Het ontwikkelen en beheren van een repository met goed ontworpen prompttemplates voor verschillende usecases is cruciaal in een LLMOps-setup. De selectie van de juiste prompttemplate voor een specifieke usecase is meestal een voorbereidende stap die tijdens de preprocessingfase wordt uitgevoerd voordat de query naar het model wordt gestuurd.
Voor few-shot prompting moeten de templates worden ontworpen om meerdere voorbeelden op te nemen die de taak of de verwachte responsstijl van het model demonstreren. Evenzo moeten, om chain-of-thought-reasoning te integreren, de prompttemplates zorgvuldig worden ontworpen om een stapsgewijze gedachtegang te bevatten. In essentie moeten ze het model begeleiden in hoe elke gegeven probleemstelling methodisch kan worden benaderd en opgesplitst in eenvoudigere, beter beheersbare stappen.
Het opnemen van kennis uit externe bronnen kan een stap zijn in chain-of-thought-reasoning, vooral nuttig in frameworks zoals LangChain, waar het model de instructie krijgt om informatie van internet op te halen als de bestaande kennisbasis ontoereikend is.
Zowel bij few-shot prompting als bij chain-of-thought-reasoning is het gebruik van A/B-testen van prompts zeer waardevol. Dit houdt in dat je gecontroleerde experimenten uitvoert door verschillende subsets van gebruikers aan verschillende promptversies bloot te stellen, hun prestaties objectief te meten en op basis van de resultaten de meest effectieve te selecteren. Bovendien is het in beide gevallen belangrijk om te vertrouwen op prestatiegegevens om onze prompttemplates iteratief te verbeteren.
Deployment en monitoring
Als het basismodel is getraind of gefinetuned en we tevreden zijn met het resultaat, is het tijd om het model te deployen. Deployment van een model in de context van LLMOps verwijst naar het proces waarbij een taalmodel beschikbaar wordt gemaakt voor gebruik in een productieomgeving. Dit omvat het weghalen van het model uit de trainingsomgeving en het integreren in de productie-infrastructuur. Deze stap is in oranje aangegeven in ons gebruikelijke diagram:
LLMOps-workflow: de deploystap (in oranje) uitgelicht in onze generieke workflow. Deze stap houdt in dat het model wordt “verplaatst” van de ontwikkelomgeving naar productie.
De deployment omvat ook het opzetten van de interface die we zullen gebruiken om met het model te communiceren zodra het in productie staat. Over het algemeen is de interface afhankelijk van onze verwerkingsmodus:
Realtime verwerking: Voor applicaties die realtime interacties vereisen, zoals chatapplicaties, is het essentieel om het model zo te deployen dat data direct verwerkt wordt en output direct wordt gegenereerd. Dit wordt doorgaans bereikt door een Application Programming Interface (API) te creëren die met het model interfacet. Tegenwoordig zijn er bibliotheken zoals Flask waarmee we in een paar eenvoudige stappen API-interfaces kunnen maken.
De API’s kunnen worden uitgerold op webservers of cloudplatformen, zodat ze toegankelijk zijn voor gebruikers of systemen die met het model moeten interacteren. Onze LLMOps-setup moet ervoor zorgen dat de API de verwachte load aankan, met aandacht voor opschalen, load balancing en failovermechanismen.
Batchpredicatie: In veel usecases zijn realtime voorspellingen niet nodig. Als we bijvoorbeeld een batch klantbeoordelingen hebben die we eens per week moeten classificeren, kunnen we ons getrainde model gebruiken om deze beoordelingen in batches te verwerken. Deze aanpak is efficiënt en zuinig met resources voor taken die niet tijdkritisch zijn.
Voor batchusecases kun je batchjobs inplannen met tools als cron (in Unix-achtige systemen) of cloudgebaseerde jobplanners. Deze jobs draaien het model op de nieuwe data op de opgegeven intervallen, verwerken de data en slaan de resultaten op.
Tot slot omvat het deployen van het model naar de productie-setup normaal gesproken modelpackaging en -versiebeheer:
Packaging houdt in dat je je model en de afhankelijkheden verpakt in een formaat dat eenvoudig gedeployed en gebruikt kan worden in de productieomgeving. Dit kan containertechnologieën zoals Docker omvatten, die het model en zijn omgeving inkapselen om consistentie over verschillende platforms te waarborgen.
Modelversiebeheer: Het bijhouden van verschillende versies van je model is cruciaal, vooral wanneer je je model bijwerkt of opnieuw traint. Versiebeheer helpt bij het onderhouden van een duidelijk overzicht van modeliteraties, trainingsdata en prompttemplates.
CI/CD-pipelines
Continuous Integration (CI) en Continuous Delivery (CD)-pipelines automatiseren de stappen die nodig zijn om een model van de ontwikkelomgeving naar productie te brengen, zodat het model betrouwbaar, up-to-date en efficiënt gedeployed is.
In LLMOps zorgt CI ervoor dat, wanneer nieuwe code of wijzigingen aan het model worden geïntroduceerd (zoals hyperparametertuning, aanpassingen aan de modelarchitectuur of nieuwe trainingsdata), deze wijzigingen automatisch worden getest. Dit omvat het draaien van unittests, integratietests en andere checks om te valideren dat de wijzigingen het model niet breken of de prestaties niet verslechteren. In die zin is CI een manier om ons model continu te monitoren.
Zodra de wijzigingen alle tests in de CI-fase doorstaan, automatiseert CD de deployment van het model naar de productieomgeving. Zo draait in de LLMOps-productive setup altijd de meest stabiele, geteste versie van het model. CD faciliteert ook een snelle rollback naar eerdere versies als er een probleem wordt gedetecteerd in de productieomgeving, waardoor downtime tot een minimum wordt beperkt en de betrouwbaarheid van de dienst gewaarborgd blijft.
Orchestratie
Tot slot is er nog één aspect dat we nog niet hebben besproken: hoe ordenen we onze LLMOps-componenten zodat we een logische keten van stappen vormen?
Orchestratie omvat het definiëren en beheren van de volgorde van operaties in de LLMOps-setup, waarmee de zogeheten workflow wordt gevormd. Bijvoorbeeld het bepalen van de volgorde van pre- en postprocessingstappen of van de verschillende tests die een nieuw model moet doorlopen totdat het klaar is om te worden gedeployed.
In de LLM-context omvat orchestratie normaal gesproken het doorgeven van data tussen verschillende componenten van de workflow. Dit wordt vaak beheerd door datapaden of werkruimtes te specificeren waar de output van de ene stap wordt opgeslagen en vervolgens wordt opgepikt door de volgende stap.
Orchestratie wordt vaak beheerd via configuratiebestanden, doorgaans geschreven in YAML (Yet Another Markup Language). Deze bestanden definiëren de componenten, hun volgorde en de parameters voor elke stap in de workflow. Domain Specific Languages (DSL’s) worden in deze configuratiebestanden vaak gebruikt om een intuïtievere en gespecialiseerde syntaxis te bieden voor het definiëren van workflows.
Tot slot zijn workflows normaal gesproken geautomatiseerd. Dat zorgt ervoor dat zodra de workflow wordt gestart, alle bijbehorende stappen soepel zonder handmatige interventie verlopen, van de ene stap naar de volgende, waardoor de noodzaak voor handmatige uitvoering van taken wordt verminderd om problemen te voorkomen.
Geavanceerde technieken in LLMOps
In dit artikel hebben we de kerncomponenten van een LLMOps-infrastructuur en hun bestaansreden besproken. Er zijn echter andere geavanceerde technieken die de prestaties van je LLMOps-infrastructuur kunnen verbeteren:
High-performance resources: Het gebruik van high-performance computingresources zoals GPU’s of TPU’s kan leiden tot snellere inferentie, wat de latentie aanzienlijk vermindert ten opzichte van CPU’s. Bij het opzetten van een LLMOps-infrastructuur moet de hardware verstandig worden gekozen.
Load balancing: Als we van plan zijn een veelgebruikte dienst aan te bieden in verschillende landen, vergelijkbaar met ChatGPT, is het raadzaam meerdere instanties van hetzelfde model uit te rollen. Zo kun je inkomende verzoeken verdelen over verschillende modellen. Onze LLMOps-setup moet op elk moment op de hoogte zijn van het aantal beschikbare modellen en hun rekenmogelijkheden.
Geografische distributie: Als meerdere modellen in verschillende landen beschikbaar zijn, is een eenvoudige techniek om de modellen — en de benodigde delen van de LLMOps-infrastructuur — dichter bij de eindgebruikers te hosten. Deze strategie omvat het optimaliseren van dataserialisatie en overdrachtsprotocollen om snelle en efficiënte dataoverdracht tussen de gebruiker, de infrastructuur en het model te waarborgen.
Omgaan met beveiligingskwesties
Het waarborgen van dataprivacy en gebruikersbescherming in onze LLMOps-infrastructuur is essentieel voor het bouwen van een betrouwbare dienst.
Het implementeren van robuuste data-anonimisatietechnieken is bijvoorbeeld cruciaal. Technieken zoals differential privacy, k-anonimiteit of datamasking kunnen worden gebruikt om ervoor te zorgen dat de trainingsdata geen gevoelige persoonlijke informatie onthullen die tijdens het samenstellen van de trainingsdatasets is verzameld. Bovendien, als we van plan zijn om real-world data te gebruiken om onze modellen iteratief te verbeteren, moet de gebruiker daarvan op de hoogte zijn en moeten hun gegevens worden geanonimiseerd voordat ze in de fine-tuningloop worden opgenomen.
Een ander aspect met betrekking tot beveiliging is wanneer we van plan zijn om privégebruikersinformatie in ons systeem op te slaan, zoals de gespreksgeschiedenis in ChatGPT. In dat geval moeten we ervoor zorgen dat alle data veilig wordt verwerkt en in overeenstemming is met gegevensbeschermingsregels zoals de AVG (GDPR). Dit omvat het waarborgen van veilige dataopslag en versleutelde datatransmissie in onze infrastructuur.
Ten slotte moeten we zorgen voor robuuste toegangscontroles in de LLMOps-infrastructuur, zodat alleen geautoriseerde personen toegang hebben tot het model, de data en de trainingsomgeving, en zodat er geen lekken ontstaan die persoonlijke informatie van gebruikers blootstellen.
Conclusie
LLM-aangedreven toepassingen zijn sinds vorig jaar in opmars, gedreven door de verbeterde capaciteiten van recente LLM-iteraties. Deze toepassingen leveren LLM’s as-a-service, wat een robuust raamwerk voor hun beheer en optimalisatie vereist, bekend als de LLMOps-infrastructuur.
In dit artikel hebben we de cruciale rol van LLMOps verkend als de ruggengraat van een succesvolle, efficiënte en klantgerichte LLM-dienst. Eerst hebben we de reis van een prompt bekeken vanaf het moment dat een gebruiker deze naar het model stuurt tot het antwoord wordt ontvangen. LLMOps zorgt ervoor dat al deze stappen “achter de schermen” gestroomlijnd en efficiënt verlopen.
Vervolgens hebben we onderzocht hoe LLMOps modeltraining, deployment, monitoring en onderhoud omvat. LLMOps omvat ook het opschalen van resources om variabele loads efficiënt aan te kunnen, waarmee de schaalbaarheid en betrouwbaarheid van onze op LLM’s gebaseerde toepassingen wordt gegarandeerd. Daarnaast hebben we geavanceerde best practices besproken om onze LLMOps-infrastructuur te verfijnen.
Tot slot hebben we onderkend hoe LLMOps ook betrokken is bij het waarborgen van de integriteit en veiligheid van LLM’s as-a-service. Aangezien deze modellen vaak gevoelige data verwerken, zijn robuuste LLMOps-praktijken essentieel om strenge beveiligingsmaatregelen af te dwingen, zodat dataprivacy en naleving van regelgeving worden gewaarborgd.
Kortom, na het lezen van dit artikel hoop ik je van één belangrijk aspect te hebben overtuigd: LLMOps is niet alleen een operationele noodzaak, maar een strategisch kapitaal dat de waarde, betrouwbaarheid en duurzaamheid van LLM’s as-a-service vergroot.
Klaar om theorie in de praktijk te brengen? Duik dieper in de wereld van Large Language Models met onze hands-on tutorial: "How to Build LLM Applications with LangChain". Begin vandaag nog met het omzetten van je kennis in toepasbare vaardigheden!
Andrea Valenzuela werkt momenteel aan het CMS-experiment bij de deeltjesversneller (CERN) in Genève, Zwitserland. Met zes jaar ervaring in data-engineering en -analyse omvatten haar taken data-analyse en softwareontwikkeling. Ze zet zich nu in voor het democratiseren van het leren van datagerelateerde technologieën via de Medium-publicatie ForCode'Sake.
Ze behaalde een bachelor in Engineering Physics aan de Polytechnische Universiteit van Catalonië en een master in Intelligent Interactive Systems aan de Pompeu Fabra Universiteit. Haar onderzoekservaring omvat professioneel werk met eerdere OpenAI-algoritmes voor beeldgeneratie, zoals Normalizing Flows.
Begin je reis met het ontwikkelen van AI-gestuurde applicaties met de OpenAI API. Leer over de functionaliteit achter populaire AI-toepassingen zoals ChatGPT.
Wanneer wij als gebruikers met ChatGPT interacteren, typen we simpelweg een prompt in de webinterface en drukken we op enter. Meestal ontvangen we binnen enkele seconden een reactie. Onder deze naadloze interactie schuilt echter een complexe en ordelijke reeks stappen die het mogelijk maken dat ChatGPT zo’n ervaring levert.
De automatische uitvoering van deze reeks stappen, bekend als Large Language Model Operations (LLMOps), garandeert dat de prompt niet alleen het model bereikt, maar ook efficiënt, nauwkeurig en betrouwbaar wordt verwerkt. Dit zorgt voor de levering van een goed geformuleerd antwoord binnen een redelijke tijd.
In dit artikel duiken we in het LLMOps-paradigma door de reis van een prompt door een Large Language Model (LLM)-dienst, zoals ChatGPT, te volgen. We bekijken de cruciale fasen, waaronder promptvoorbewerking, modelselectie, generatie van antwoorden, en de vaak over het hoofd geziene maar vitale aspecten zoals load balancing, monitoring en Continuous Integration.
Wat is LLMOps?
LLMOps is inderdaad een evolutie van de bekende Machine Learning Operations (MLOps), toegesneden op de concrete uitdagingen die LLM’s met zich meebrengen. Terwijl MLOps draait om levenscyclusbeheer van algemene Machine Learning-modellen, omvat LLMOps aspecten die uniek zijn voor dit type modellen.
Het is cruciaal te begrijpen dat LLMOps voor ons transparant zijn wanneer we met een model van OpenAI of Google interacteren, of dat nu via een webinterface is of via API-calls vanuit onze code. In dit scenario zeggen we dat deze modellen as-a-service worden aangeboden.
Als ons doel daarentegen is om ons eigen model voor een specifieke usecase aan te bieden zonder afhankelijk te zijn van externe providers, bijvoorbeeld een assistent voor medewerkers van een bedrijf, dan ligt de verantwoordelijkheid voor LLMOps bij ons.
Ongeacht de mogelijkheden van ons nieuwe model, zal het succes als dienst in hoge mate afhangen van de aanwezigheid van een robuuste en betrouwbare LLMOps-infrastructuur. Als je meer wilt weten over MLOps, is de tutorial MLOps Fundamentals iets voor jou!
Oorsprong van LLMOps
Vroege LLM’s zoals GPT-2 werden in 2018 geïntroduceerd. Ze zijn echter pas recent populair geworden, voornamelijk door de aanzienlijke vooruitgang in de capaciteiten van de nieuwere versies van die modellen, vanaf GPT-3 en verder.
Er zijn meerdere toepassingen ontstaan die LLM’s benutten dankzij hun indrukwekkende modelcapaciteiten. Voorbeelden zijn klantenservice-chatbots, vertaaldiensten en schrijf- en codeerassistenten, onder andere.
Het ontwikkelen van productieklare toepassingen die worden aangedreven door LLM’s brengt een unieke set uitdagingen met zich mee, anders dan bij traditionele ML-modellen. Om deze uitdagingen aan te pakken, zijn nieuwe tools en best practices ontwikkeld voor het beheren van de levenscyclus van LLM-toepassingen, wat heeft geleid tot het concept “LLMOps”.
Waarom LLMOps?
LLMOps is essentieel om deze complexe modellen efficiënt te beheren wanneer ze as-a-service worden ingezet, om meerdere redenen:
1. LLM’s zijn niet alleen groot qua hoeveelheid data die ze verwerken, maar ook qua aantal parameters. LLMOps zorgt ervoor dat de infrastructuur deze modellen kan ondersteunen op het gebied van opslag en bandbreedte.
2. Voor gebruikers is het cruciaal om in zo min mogelijk tijd een nauwkeurig antwoord te krijgen. LLMOps zorgt ervoor dat reacties binnen een redelijke tijd worden geleverd, zodat de vloeiendheid van mensachtige interacties behouden blijft.
3. Continu monitoren onder LLMOps draait niet alleen om het volgen van operationele aspecten of storingen in de infrastructuur. Het omvat ook zorgvuldig het gedrag van het model volgen om de besluitvormingsprocessen te begrijpen en het model in toekomstige iteraties verder te verbeteren.
4. Het draaien van LLM’s kan duur zijn vanwege de benodigde resources. LLMOps introduceert kosteneffectieve strategieën om te zorgen dat resources optimaal worden gebruikt zonder in te leveren op prestaties.
Achter de schermen van een LLM-service
Om LLMOps te begrijpen, is het belangrijk bekend te zijn met wat er “achter de schermen” gebeurt wanneer LLM’s as-a-service worden aangeboden. Dat is het pad dat een prompt volgt vanaf het moment dat deze aan het model wordt verstrekt tot het antwoord is gegenereerd. Het volgende schema toont deze workflow:
LLMOps-workflow: de stappen achter de schermen van een generieke LLM as-a-service. Gebruikersinvoer (in groen) doorloopt enkele stappen voordat deze naar het model gaat. Op vergelijkbare wijze ondergaat de modeluitvoer (in rood) meerdere transformaties voordat die aan de gebruiker wordt getoond.
Zoals we in het bovenstaande schema kunnen zien, doorloopt de prompt meerdere stappen voordat die het model bereikt. Hoewel het aantal stappen kan variëren, zijn er basiselementen om er bijvoorbeeld voor te zorgen dat de invoer duidelijk wordt begrepen en dat het antwoord van het model contextueel relevant is. Laten we deze stappen uitsplitsen:
1. Preprocessing
Deze stap bereidt de prompt van de gebruiker voor zodat het model deze kan begrijpen en verwerken. Dit omvat tokenization, waarbij de prompt wordt opgedeeld in kleinere eenheden, zogenaamde tokens. Deze stap omvat ook datanormalisatie, waaronder het verwijderen of transformeren van ruis in de data, zoals speciale tekens, het corrigeren van typefouten en het standaardiseren van de tekst.
Tot slot worden tijdens het encoderen tokens omgezet in een numerieke vorm die het model kan begrijpen. Dit gebeurt met behulp van embeddings, die elk token als een vector in een hoog-dimensionale ruimte representeren.
2. Grounding
Dit omvat het contextualiseren van de prompt op basis van eerdere gespreksbeurten of externe kennisbronnen om te zorgen dat het antwoord van het model coherent en contextueel passend is. Daarnaast helpen entiteitsherkenning en linking het systeem om entiteiten (zoals namen, plaatsen en datums) in de prompt te identificeren en te koppelen aan de relevante context.
3. Verantwoorde AI
Om te borgen dat het gebruik van LLM’s goede doeleinden dient, implementeren sommige diensten sanity-checks op de prompts van gebruikers. Meestal wordt de prompt beoordeeld aan de hand van veiligheids- en compliance-richtlijnen, met name in scenario’s met gevoelige informatie, ongepaste inhoud, bias of mogelijke desinformatie.
Pas na deze stappen wordt de prompt uiteindelijk doorgestuurd naar het model voor verwerking. Nadat het model het antwoord heeft gegenereerd, en voordat dit aan de gebruiker wordt getoond, kan het antwoord opnieuw de stappen voor Grounding en Verantwoorde AI doorlopen, plus een extra nabewerkingsstap:
4. Post-processing
Het antwoord dat door het model wordt gegenereerd is numeriek van aard vanwege de eerder genoemde vectorembeddings. Daarom is een decodering essentieel om deze numerieke data terug te zetten naar voor mensen leesbare tekst. Na het decoderen is een verfijnings-stap nodig om het antwoord te polijsten qua grammatica, stijl of leesbaarheid.
Tot slot wordt het antwoord aan de gebruiker getoond. De LLMOps-infrastructuur is verantwoordelijk voor het uitvoeren van deze stappen, onzichtbaar voor de gebruiker.
Latentie
Tot nu toe hebben we heel wat stappen gezien die de LLMOps-infrastructuur moet uitvoeren vanaf het moment dat een gebruiker een prompt verzendt totdat deze het antwoord terugkrijgt. Op dit punt is een redelijke vraag: Hoeveel tijd kosten deze stappen?
Bij het gebruik van ChatGPT is de reactietijd normaal gesproken vrijwel direct. Deze reactietijd staat bekend als latentie. Latentie is een kritieke prestatie-indicator, vooral in applicaties die direct contact met de gebruiker hebben, waar de responstijd de gebruikerservaring sterk beïnvloedt. De juiste latentie kiezen is cruciaal en hangt af van onze usecase.
Om de latentie van de respons te verlagen, past LLMOps verschillende strategieën en best practices toe om het volledige proces van inputontvangst tot responslevering te stroomlijnen. LLMOps draagt bij aan het verlagen van de modellatentie door alle vereiste stappen automatisch uit te voeren en de benodigde resources efficiënt te beheren, zodat geen berekening hoeft te wachten op beschikbare resources. Andere best practices kunnen de latentie eveneens verlagen:
Het verminderen van latentie verbetert niet alleen de gebruikerservaring, maar draagt ook bij aan kostenefficiëntie door het resourcegebruik te optimaliseren.
Belangrijke componenten van LLMOps
Het juiste foundation model kiezen
Tot nu toe hebben we nog niet besproken welk model in onze LLMOps-setup zou moeten zitten. Er zijn verschillende soorten modellen beschikbaar, elk geoptimaliseerd voor specifieke usecases, met verschillende groottes, enzovoort. Het selecteren van het juiste model is cruciaal en hangt in grote mate af van onze applicatie en beschikbare resources.
Bovendien lijkt het aantal LLM’s en providers dagelijks toe te nemen. Daarom is een breed begrip van de verschillende soorten LLM’s en hun providers nuttig, vooral wanneer je probeert te bepalen welke het beste bij je usecase past.
LLM-providers
LLM-modellen en -providers kunnen in de volgende typen worden ingedeeld:
Proprietary-modellen vs open-source
De belangrijkste voordelen van open-sourcemodellen liggen in de transparantie en de mogelijkheid om ze aan te passen. Open-sourcemodellen bieden doorgaans volledige controle over alle componenten, waardoor eenvoudig debuggen en uitgebreide aanpassing via training of fine-tuning mogelijk is. Deze mate van flexibiliteit zorgt ervoor dat het LLM beter kan aansluiten op jouw specifieke behoeften, in plaats van te moeten voldoen aan de vooraf gedefinieerde opties van de LLM-provider.
Het zelfstandig beheren van open-source LLM’s kan echter leiden tot aanzienlijke engineeringuitdagingen en kosten op het gebied van computing en opslag. Zelfs als er een minimale infrastructuur door open-sourcemodellen wordt geboden, is het vaak lastig om te concurreren met proprietary-modellen qua latentie, doorvoer en inferencekosten.
Criteria voor modelselectie
Er zijn veel modellen om uit te kiezen. Maar hoe zorgen we dat we het juiste LLM kiezen?
Er zijn inderdaad enkele criteria om te overwegen, afhankelijk van onze usecase en mogelijkheden:
Fine-tuningstrategieën
Of het nu proprietary of open-source is, LLM’s hebben vaak fine-tuning nodig om echt geschikt te zijn voor specifieke toepassingen.
Er zijn vooraf gefinetunede LLM’s beschikbaar voor bepaalde gebruikerstaken, vaak inclusief chatmodellen en modellen die gespecialiseerd zijn in samenvatten of sentimentanalyse. Een andere variant om te overwegen zijn long-context-modellen. Moderne LLM’s verwerken doorgaans contextlengtes van 2.000 tot 8.000 tokens, wat betekent dat input en output buiten dit bereik niet direct verwerkt kunnen worden. Sommige modellen bieden echter long-context-varianten. Zo heeft GPT-3.5 een grotere 16k-contextvariant.
Als de bestaande opties desondanks niet aan specifieke eisen voldoen, is er altijd de mogelijkheid om een model te fine-tunen of zelfs helemaal zelf te trainen. In dat geval is het kiezen van een geschikte dataset cruciaal, omdat dit het model helpt de aard van de doeltaak te begrijpen.
Als je geïnteresseerd bent in het vanaf nul trainen van een LLM-model, raad ik je echt de DataCamp-tutorial How to train an LLM with PyTorch aan.
Modelaanpassing
Als onze toepassing fine-tuning van een bestaand model vereist, moeten de bijbehorende stappen ook deel uitmaken van onze LLMOps-setup. Laten we deze aanpassingsstap aan ons oorspronkelijke diagram toevoegen:
LLMOps-workflow: inclusief de Model Customizatin-stappen (in oranje) in onze generieke workflow.
Een consistente fine-tuningpipeline kan je helpen de kennis van je model in de loop van de tijd uit te breiden naarmate er meer data beschikbaar komt, waardoor je moeiteloos je LLM-versie kunt upgraden of andere wijzigingen kunt doorvoeren.
Wanneer we afhankelijk zijn van modellen van derden, is het belangrijk te beseffen dat deze modellen kunnen veranderen in beschikbaarheid en kosten. Dit kan ons mogelijk dwingen om over te stappen op een ander basismodel. Een robuuste LLMOps-setup stelt ons in staat om deze kritieke situatie soepel af te handelen door simpelweg het vak “Model” te vervangen door een ander LLM.
Trainingsdata
Je zou kunnen denken dat het fine-tunen van je LLM of het vanaf nul trainen ervan een eerste stap buiten de LLMOps-infrastructuur is, aangezien het LLM pas gaat draaien zodra het in productie staat. Toch is dat niet zo, zeker om de eerder genoemde reden: een succesvolle dienst zal modelverbeteringen nodig hebben en veerkrachtig moeten zijn bij eventuele wisselingen van providers.
Voor effectieve training, fine-tuning of modelverfijning in een generieke LLMOps-infrastructuur is het belangrijk om de data-indeling consistent te houden tussen trainingsdata en latere inferentiedata. Hiervoor formatteren we de trainingsdata doorgaans in het JSON Lines-formaat (
.jsonl). Dit formaat is zeer geschikt voor fine-tuning van LLM’s vanwege de structuur, die efficiënte verwerking van grote datasets mogelijk maakt. Een typisch.jsonl-bestand voor fine-tuning kan er zo uitzien:Elke regel in een
.jsonl-bestand is een afzonderlijk JSON-object dat een enkel trainingsexample vertegenwoordigt, metprompt- encompletion-sleutels die respectievelijk de invoertekst en de verwachte modelrespons aangeven, zoals we tijdens inferentie zouden verwachten. Daarnaast vergemakkelijkt dit formaat het incrementeel toevoegen van nieuwe data aan de kennisbasis van het model.Trainings- en inferentieparameters
Modelparameters zijn ook belangrijk bij het inrichten van onze LLMOps-infrastructuur, omdat ze impact hebben op kenmerken zoals modelgrootte en resourceverbruik.
Wat betreft trainingsparameters is het belangrijk om deze te optimaliseren om de complexiteit van het model in balans te brengen met deploybeperkingen zoals geheugengebruik. Deze optimalisatie is cruciaal om modellen in uiteenlopende omgevingen met verschillende resourcecapaciteiten te kunnen uitrollen, zodat modellen niet alleen geavanceerd zijn, maar ook praktisch voor real-world toepassingen.
Wat betreft inferentieparameters stelt het aanpassen van parameters zoals temperature en max tokens je in staat de lengte en willekeurigheid van de antwoorden te sturen. Deze instellingen worden beheerd als onderdeel van het LLMOps-proces om de modeluitvoer in lijn te brengen met de specifieke toepassingsvereisten en de intentie van de gebruiker.
Prompt engineering en -beheer
Prompt-engineeringtechnieken blijken de standaardcapaciteiten van LLM’s te verbeteren. Een reden hiervoor is dat ze helpen het model te contextualiseren. Bijvoorbeeld door het model te instrueren zich als expert in een specifiek domein te gedragen of het model richting een gewenst outputformaat te sturen. Prompt Engineering en Management zijn cruciale componenten die in onze LLMOps-setup moeten worden opgenomen.
Tot de meest effectieve prompt-engineeringpraktijken behoren few-shot prompting en chain-of-thought reasoning. Laten we deze technieken kort bespreken en aangeven hoe we ze in onze LLMOps-setup kunnen integreren:
Het implementeren van technieken zoals few-shot prompting en chain-of-thought-reasoning binnen onze LLMOps-setup kan effectief worden gerealiseerd met behulp van prompttemplates.
Prompttemplates
Prompttemplates zijn vooraf gedefinieerde structuren om het redeneren van LLM’s te sturen. Ze bieden een consistente structuur, zorgen ervoor dat vergelijkbare verzoeken uniform worden gedaan of helpen om prompt-engineeringtechnieken onzichtbaar voor de gebruiker op te nemen.
Het ontwikkelen en beheren van een repository met goed ontworpen prompttemplates voor verschillende usecases is cruciaal in een LLMOps-setup. De selectie van de juiste prompttemplate voor een specifieke usecase is meestal een voorbereidende stap die tijdens de preprocessingfase wordt uitgevoerd voordat de query naar het model wordt gestuurd.
Voor few-shot prompting moeten de templates worden ontworpen om meerdere voorbeelden op te nemen die de taak of de verwachte responsstijl van het model demonstreren. Evenzo moeten, om chain-of-thought-reasoning te integreren, de prompttemplates zorgvuldig worden ontworpen om een stapsgewijze gedachtegang te bevatten. In essentie moeten ze het model begeleiden in hoe elke gegeven probleemstelling methodisch kan worden benaderd en opgesplitst in eenvoudigere, beter beheersbare stappen.
Het opnemen van kennis uit externe bronnen kan een stap zijn in chain-of-thought-reasoning, vooral nuttig in frameworks zoals LangChain, waar het model de instructie krijgt om informatie van internet op te halen als de bestaande kennisbasis ontoereikend is.
Zowel bij few-shot prompting als bij chain-of-thought-reasoning is het gebruik van A/B-testen van prompts zeer waardevol. Dit houdt in dat je gecontroleerde experimenten uitvoert door verschillende subsets van gebruikers aan verschillende promptversies bloot te stellen, hun prestaties objectief te meten en op basis van de resultaten de meest effectieve te selecteren. Bovendien is het in beide gevallen belangrijk om te vertrouwen op prestatiegegevens om onze prompttemplates iteratief te verbeteren.
Deployment en monitoring
Als het basismodel is getraind of gefinetuned en we tevreden zijn met het resultaat, is het tijd om het model te deployen. Deployment van een model in de context van LLMOps verwijst naar het proces waarbij een taalmodel beschikbaar wordt gemaakt voor gebruik in een productieomgeving. Dit omvat het weghalen van het model uit de trainingsomgeving en het integreren in de productie-infrastructuur. Deze stap is in oranje aangegeven in ons gebruikelijke diagram:
LLMOps-workflow: de deploystap (in oranje) uitgelicht in onze generieke workflow. Deze stap houdt in dat het model wordt “verplaatst” van de ontwikkelomgeving naar productie.
De deployment omvat ook het opzetten van de interface die we zullen gebruiken om met het model te communiceren zodra het in productie staat. Over het algemeen is de interface afhankelijk van onze verwerkingsmodus:
De API’s kunnen worden uitgerold op webservers of cloudplatformen, zodat ze toegankelijk zijn voor gebruikers of systemen die met het model moeten interacteren. Onze LLMOps-setup moet ervoor zorgen dat de API de verwachte load aankan, met aandacht voor opschalen, load balancing en failovermechanismen.
Voor batchusecases kun je batchjobs inplannen met tools als cron (in Unix-achtige systemen) of cloudgebaseerde jobplanners. Deze jobs draaien het model op de nieuwe data op de opgegeven intervallen, verwerken de data en slaan de resultaten op.
Tot slot omvat het deployen van het model naar de productie-setup normaal gesproken modelpackaging en -versiebeheer:
CI/CD-pipelines
Continuous Integration (CI) en Continuous Delivery (CD)-pipelines automatiseren de stappen die nodig zijn om een model van de ontwikkelomgeving naar productie te brengen, zodat het model betrouwbaar, up-to-date en efficiënt gedeployed is.
In LLMOps zorgt CI ervoor dat, wanneer nieuwe code of wijzigingen aan het model worden geïntroduceerd (zoals hyperparametertuning, aanpassingen aan de modelarchitectuur of nieuwe trainingsdata), deze wijzigingen automatisch worden getest. Dit omvat het draaien van unittests, integratietests en andere checks om te valideren dat de wijzigingen het model niet breken of de prestaties niet verslechteren. In die zin is CI een manier om ons model continu te monitoren.
Zodra de wijzigingen alle tests in de CI-fase doorstaan, automatiseert CD de deployment van het model naar de productieomgeving. Zo draait in de LLMOps-productive setup altijd de meest stabiele, geteste versie van het model. CD faciliteert ook een snelle rollback naar eerdere versies als er een probleem wordt gedetecteerd in de productieomgeving, waardoor downtime tot een minimum wordt beperkt en de betrouwbaarheid van de dienst gewaarborgd blijft.
Orchestratie
Tot slot is er nog één aspect dat we nog niet hebben besproken: hoe ordenen we onze LLMOps-componenten zodat we een logische keten van stappen vormen?
Orchestratie omvat het definiëren en beheren van de volgorde van operaties in de LLMOps-setup, waarmee de zogeheten workflow wordt gevormd. Bijvoorbeeld het bepalen van de volgorde van pre- en postprocessingstappen of van de verschillende tests die een nieuw model moet doorlopen totdat het klaar is om te worden gedeployed.
In de LLM-context omvat orchestratie normaal gesproken het doorgeven van data tussen verschillende componenten van de workflow. Dit wordt vaak beheerd door datapaden of werkruimtes te specificeren waar de output van de ene stap wordt opgeslagen en vervolgens wordt opgepikt door de volgende stap.
Orchestratie wordt vaak beheerd via configuratiebestanden, doorgaans geschreven in YAML (Yet Another Markup Language). Deze bestanden definiëren de componenten, hun volgorde en de parameters voor elke stap in de workflow. Domain Specific Languages (DSL’s) worden in deze configuratiebestanden vaak gebruikt om een intuïtievere en gespecialiseerde syntaxis te bieden voor het definiëren van workflows.
Tot slot zijn workflows normaal gesproken geautomatiseerd. Dat zorgt ervoor dat zodra de workflow wordt gestart, alle bijbehorende stappen soepel zonder handmatige interventie verlopen, van de ene stap naar de volgende, waardoor de noodzaak voor handmatige uitvoering van taken wordt verminderd om problemen te voorkomen.
Geavanceerde technieken in LLMOps
In dit artikel hebben we de kerncomponenten van een LLMOps-infrastructuur en hun bestaansreden besproken. Er zijn echter andere geavanceerde technieken die de prestaties van je LLMOps-infrastructuur kunnen verbeteren:
Omgaan met beveiligingskwesties
Het waarborgen van dataprivacy en gebruikersbescherming in onze LLMOps-infrastructuur is essentieel voor het bouwen van een betrouwbare dienst.
Het implementeren van robuuste data-anonimisatietechnieken is bijvoorbeeld cruciaal. Technieken zoals differential privacy, k-anonimiteit of datamasking kunnen worden gebruikt om ervoor te zorgen dat de trainingsdata geen gevoelige persoonlijke informatie onthullen die tijdens het samenstellen van de trainingsdatasets is verzameld. Bovendien, als we van plan zijn om real-world data te gebruiken om onze modellen iteratief te verbeteren, moet de gebruiker daarvan op de hoogte zijn en moeten hun gegevens worden geanonimiseerd voordat ze in de fine-tuningloop worden opgenomen.
Een ander aspect met betrekking tot beveiliging is wanneer we van plan zijn om privégebruikersinformatie in ons systeem op te slaan, zoals de gespreksgeschiedenis in ChatGPT. In dat geval moeten we ervoor zorgen dat alle data veilig wordt verwerkt en in overeenstemming is met gegevensbeschermingsregels zoals de AVG (GDPR). Dit omvat het waarborgen van veilige dataopslag en versleutelde datatransmissie in onze infrastructuur.
Ten slotte moeten we zorgen voor robuuste toegangscontroles in de LLMOps-infrastructuur, zodat alleen geautoriseerde personen toegang hebben tot het model, de data en de trainingsomgeving, en zodat er geen lekken ontstaan die persoonlijke informatie van gebruikers blootstellen.
Conclusie
LLM-aangedreven toepassingen zijn sinds vorig jaar in opmars, gedreven door de verbeterde capaciteiten van recente LLM-iteraties. Deze toepassingen leveren LLM’s as-a-service, wat een robuust raamwerk voor hun beheer en optimalisatie vereist, bekend als de LLMOps-infrastructuur.
In dit artikel hebben we de cruciale rol van LLMOps verkend als de ruggengraat van een succesvolle, efficiënte en klantgerichte LLM-dienst. Eerst hebben we de reis van een prompt bekeken vanaf het moment dat een gebruiker deze naar het model stuurt tot het antwoord wordt ontvangen. LLMOps zorgt ervoor dat al deze stappen “achter de schermen” gestroomlijnd en efficiënt verlopen.
Vervolgens hebben we onderzocht hoe LLMOps modeltraining, deployment, monitoring en onderhoud omvat. LLMOps omvat ook het opschalen van resources om variabele loads efficiënt aan te kunnen, waarmee de schaalbaarheid en betrouwbaarheid van onze op LLM’s gebaseerde toepassingen wordt gegarandeerd. Daarnaast hebben we geavanceerde best practices besproken om onze LLMOps-infrastructuur te verfijnen.
Tot slot hebben we onderkend hoe LLMOps ook betrokken is bij het waarborgen van de integriteit en veiligheid van LLM’s as-a-service. Aangezien deze modellen vaak gevoelige data verwerken, zijn robuuste LLMOps-praktijken essentieel om strenge beveiligingsmaatregelen af te dwingen, zodat dataprivacy en naleving van regelgeving worden gewaarborgd.
Kortom, na het lezen van dit artikel hoop ik je van één belangrijk aspect te hebben overtuigd: LLMOps is niet alleen een operationele noodzaak, maar een strategisch kapitaal dat de waarde, betrouwbaarheid en duurzaamheid van LLM’s as-a-service vergroot.
Klaar om theorie in de praktijk te brengen? Duik dieper in de wereld van Large Language Models met onze hands-on tutorial: "How to Build LLM Applications with LangChain". Begin vandaag nog met het omzetten van je kennis in toepasbare vaardigheden!