TrueML #22 - Machine Learning Platform en LLM's @ Voiceflow

We zijn terug met weer een nieuwe aflevering van  True ML Talks. Hierin duiken we diep in het ML Platform van Voiceflow en LLM's, en we spreken met Denys Linkov

Denys leidt het machine learning-team bij Voiceflow. Hij begon er als eerste ML engineer. Daarvoor werkte hij als senior cloud architect voor een wereldwijde bank, waar hij werkte aan datasystemen, MLOps en kerninfrastructuur. 

📌

Onze gesprekken met Adhitihya behandelen de volgende aspecten:
- Machine Learning bij Voiceflow
- Voiceflow's MLOps-traject
- Automatiseren van model deployment en observabiliteit om context-switching te verminderen en efficiëntie te verhogen
- Real-time inferencing-pipeline: voordelen en uitdagingen
- Voiceflow's benadering van generatieve AI

Bekijk de volledige aflevering hieronder:

Machine Learning @ Voiceflow

Voiceflow is een no-code platform waarmee bedrijven conversational AI-toepassingen kunnen bouwen en deployen. Het kan worden gebruikt voor het maken van chatbots, virtuele assistenten en andere conversational interfaces voor een breed scala aan industrieën, waaronder:

1. E-commerce
2. Vastgoed
3. Bankwezen
4. Automotive
5. Nutsbedrijven
6. Overheid

Het NLU-model van Voiceflow is in staat om een breed scala aan industrieën te bestrijken, omdat het is getraind op een enorme dataset van tekst en code uit verschillende bronnen. Hierdoor kan Voiceflow een breed scala aan queries in natuurlijke taal begrijpen en beantwoorden, ongeacht de sector.

Bijvoorbeeld: Een Voiceflow-chatbot zou door een e-commercebedrijf kunnen worden gebruikt om klanten te helpen producten te vinden, vragen over producten te beantwoorden en bestellingen te plaatsen. Een Voiceflow-chatbot zou ook door een vastgoedbedrijf kunnen worden gebruikt om potentiële kopers te helpen huizen te vinden, afspraken in te plannen met makelaars en meer te leren over het aankoopproces van een woning.

Eén van de uitdagingen bij het bouwen van een NLU-model dat al deze industrieën kan bestrijken, is dat elke sector zijn eigen unieke taal en vakjargon heeft. Het NLU-model van Voiceflow is echter in staat om deze verschillen na verloop van tijd te leren naarmate het wordt blootgesteld aan meer data uit verschillende industrieën.

Voiceflow's MLOps-traject: Machine Learning-modellen bouwen en deployen voor Conversational AI

Eén van de eerste uitdagingen waar Voiceflow voor stond, was de beslissing om eigen modellen te bouwen of externe modellen te gebruiken. Voiceflow besloot beide opties te verkennen en bouwde een paar proof-of-concepts. De eerste functie die Voiceflow bouwde was utterance generation, dat machine learning gebruikt om voorbeelden te genereren die een gebruiker moet toevoegen om zijn eigen datamodel te verrijken.

Om het utterance generation-model in productie te deployen, bouwde Voiceflow zijn MLOps-platform uit. Het doel van het platform was om erg snel meerdere experimenten in productie te kunnen deployen, en om de omgevingen te beheren.

Het utterance generation-model was het eerste model dat werd ingehaald door de uitrol van ChatGPT, een geavanceerder generatief model. Dit leerde Voiceflow hoe belangrijk het is om flexibel te zijn en bereid te zijn om eigen ontwikkelingen te schrappen als dat nodig is, om te kunnen focussen op wat het beste is voor de klantervaring.

Voiceflow bespreekt ook de enorme verschuiving die heeft plaatsgevonden in het conversational AI-domein sinds de lancering van instruction-tuned GPT-gebaseerde modellen. Voiceflow geeft toe dat het een strategische fout was om destijds niet na te denken over het gebruik van GPT-3, maar het leerde ook dat het belangrijk is om wendbaar te zijn en bereid te zijn om van aanpak te veranderen naarmate het vakgebied evolueert.

Hier is een blog die u kunt lezen over het creëren van de Voiceflow NLU:

‍

Inside Voiceflow | Voiceflow

Laat ons u vermaken met productaankondigingen, een exclusief kijkje achter de schermen bij Voiceflow en producttips en -tricks van onze community.

Voiceflow

‍

Model deployment en observabiliteit automatiseren om context-switching te verminderen en efficiëntie te verhogen

In het traditionele ontwikkelproces van machine learning trainen data scientists modellen in Jupyter notebooks en dragen ze vervolgens over aan machine learning engineers of backend engineers om ze in productie te deployen. Dit kan leiden tot context-switching en vertragingen, aangezien de engineers het model en de data moeten begrijpen om het succesvol te deployen.

Automatiseer model deployment en observabiliteit

Eén manier om deze uitdaging aan te pakken is het automatiseren van model deployment en observabiliteit. Dit kan worden gedaan door een reeks tools en processen te maken waarmee data scientists hun modellen in productie kunnen deployen en monitoren zonder andere engineers te hoeven inschakelen.

Een voorbeeld hiervan is het gebruik van een cloud-gebaseerd platform dat beheerde diensten biedt voor model deployment en observabiliteit. Deze platforms kunnen uiteenlopende functies bieden, zoals:

1. Automatische model deployment en schaling
2. Real-time model monitoring
3. Drift-detectie en waarschuwingen
4. Modelversiebeheer en rollback

Ontwikkel uw eigen aangepaste tools en processen

Een andere benadering voor het automatiseren van model deployment en observabiliteit is het ontwikkelen van uw eigen aangepaste tools en processen. Dit kan u meer flexibiliteit en controle geven, maar vereist ook meer investeringen.

Hier is een specifiek voorbeeld van hoe één bedrijf model deployment en observabiliteit heeft geautomatiseerd met behulp van deze benadering:

1. Het maken van een set geautomatiseerde scripts die een cloudomgeving opzetten met alle benodigde services voor het deployen en monitoren van hun modellen.
2. Het ontwikkelen van een CLI-tool die het eenvoudig maakte om nieuwe modellen naar de cloudomgeving te deployen.
3. De CLI-tool maakte automatisch alle benodigde mappen en Terraform-bestanden aan om het model te deployen.
4. De CLI-tool specificeerde ook de omgeving waarin het model moest worden gedeployed.

Dankzij deze automatisering konden de data scientists van het bedrijf hun modellen in productie deployen en monitoren zonder dat er andere engineers bij betrokken hoefden te worden.

Uitdagingen bij het ontwikkelen van uw eigen aangepaste tools en processen

Er zijn ook enkele uitdagingen waar rekening mee moet worden gehouden bij het ontwikkelen van uw eigen aangepaste tools en processen voor model deployment en observabiliteit:

1. Complexiteit: Het ontwikkelen van uw eigen aangepaste tools en processen kan complex en tijdrovend zijn.
2. Debugging: Het kan moeilijk zijn om problemen te debuggen wanneer ze zich voordoen, vooral als data scientists geen volledig inzicht hebben in de gebouwde pipelines.
3. Onderhoud: Aangepaste tools en processen vereisen doorlopend onderhoud en ondersteuning.

Hoe de uitdagingen te beperken

Er kunnen een paar dingen worden gedaan om de uitdagingen van het ontwikkelen van uw eigen aangepaste tools en processen voor model deployment en observabiliteit te beperken:

1. Begin klein: Begin met het ontwikkelen van een basisset van tools en processen die aan uw onmiddellijke behoeften voldoen. Na verloop van tijd kunt u meer functies en functionaliteit toevoegen.
2. Gebruik open-source tools en libraries: Er zijn een aantal open-source tools en libraries beschikbaar die u kunnen helpen bij het ontwikkelen van uw eigen aangepaste tools en processen. Het gebruik van deze tools en libraries kan de hoeveelheid benodigd ontwikkelwerk verminderen.
3. Documenteer uw tools en processen: Documenteer uw tools en processen grondig, zodat data scientists en andere engineers ze gemakkelijk kunnen begrijpen en gebruiken.
4. Bied training en ondersteuning: Bied training en ondersteuning aan data scientists en andere engineers over het gebruik van uw aangepaste tools en processen.

Real-time inferencing-pipeline: voordelen en uitdagingen

Real-time inferencing-pipelines bieden een aantal voordelen, waaronder:

1. Lagere latency: Real-time inferencing-pipelines kunnen voorspellingen aan gebruikers leveren met minimale vertraging.
2. Hogere schaalbaarheid: Real-time inferencing-pipelines kunnen omhoog of omlaag worden geschaald om aan de vraag te voldoen, wat ze ideaal maakt voor toepassingen met een hoog volume.
3. Verbeterde flexibiliteit: Real-time inferencing-pipelines kunnen worden gebruikt om een verscheidenheid aan machine learning-modellen te implementeren, waaronder classificatie, regressie en objectdetectie.

Real-time inferencing-pipelines brengen echter ook enkele uitdagingen met zich mee, zoals:

1. Toegenomen complexiteit: Real-time inferencing-pipelines kunnen complex zijn om te ontwerpen en te implementeren, wat expertise vereist in machine learning, gedistribueerde systemen en infrastructuur.
2. Hogere kosten: Real-time inferencing-pipelines kunnen duurder zijn in gebruik dan batch inferencing-pipelines, vanwege de noodzaak van krachtigere hardware en infrastructuur.
3. Verhoogd risico op fouten: Real-time inferencing-pipelines kunnen gevoeliger zijn voor fouten dan batch inferencing-pipelines, vanwege de noodzaak om data te verwerken en voorspellingen in real-time te genereren.

Autoscaling in een real-time machine learning-pipeline

Eén van de uitdagingen bij het bouwen en deployen van een real-time machine learning-pipeline is hoe het systeem automatisch kan worden geschaald om veranderingen in het verkeer op te vangen. Er zijn een aantal factoren om rekening mee te houden, zoals de voorspelbaarheid van de verkeerspatronen, de latency-vereisten van de modellen en de complexiteit van het autoscaling-algoritme.

Eén benadering voor het automatisch schalen van een real-time machine learning-pipeline is het gebruik van een queuing-systeem. Hiermee kunt u de producers (die de inference-verzoeken genereren) ontkoppelen van de consumers (die de inference-verzoeken verwerken). Dit geeft u meer flexibiliteit in de manier waarop u het systeem schaalt.

Om een op queuing gebaseerd systeem automatisch te schalen, kunt u een verscheidenheid aan metrics gebruiken, zoals het aantal berichten in de wachtrij, de gemiddelde latency van de verzoeken of het CPU-gebruik van de workers. U kunt ook een combinatie van deze metrics gebruiken.

Het is belangrijk om het autoscaling-algoritme zorgvuldig af te stellen om over-scaling of under-scaling van het systeem te voorkomen. Over-scaling kan leiden tot verspilling van middelen, terwijl under-scaling kan leiden tot prestatieproblemen.

Hier zijn enkele aanvullende gedachten over het automatisch schalen van een op queuing gebaseerd systeem voor real-time inference:

1. Gebruik een cloud-gebaseerd platform: Cloud-gebaseerde platforms kunnen het eenvoudiger maken om uw systeem automatisch te schalen naarmate uw verkeerspatronen veranderen. U kunt bijvoorbeeld een cloud-gebaseerde loadbalancer gebruiken om het verkeer over uw pods te verdelen en het aantal pods naar behoefte omhoog of omlaag te schalen.
2. Gebruik een queuing-systeem dat autoscaling ondersteunt: Sommige queuing-systemen ondersteunen autoscaling, wat betekent dat ze automatisch het aantal workers kunnen opschalen of afschalen op basis van het aantal berichten in de wachtrij. Dit kan u helpen ervoor te zorgen dat uw systeem pieken in het verkeer kan opvangen zonder handmatige tussenkomst.
3. Monitor uw systeem: Het is belangrijk om uw systeem nauwlettend te monitoren om eventuele problemen met autoscaling te identificeren. Het kan bijvoorbeeld nodig zijn om de drempelwaarden die opschalen of afschalen triggeren aan te passen, of u moet specifieke knelpunten in uw systeem identificeren en aanpakken.

Model servers voor latency-gevoelige real-time systemen

Het kiezen van een model server voor latency-gevoelige toepassingen kan om een aantal redenen uitdagend zijn. Ten eerste zijn er veel verschillende model servers beschikbaar, elk met zijn eigen sterke en zwakke punten. Ten tweede kunnen de vereisten voor latency-gevoelige toepassingen sterk variëren, afhankelijk van de specifieke toepassing en de typen modellen die worden gebruikt. Ten slotte is het vaak moeilijk te voorspellen hoe een model server zal presteren in een productie-omgeving.

Factoren om rekening mee te houden

Bij het kiezen van een model server voor een latency-gevoelige toepassing is het belangrijk om rekening mee te houden met de volgende factoren:

1. Model latency: De latency van de model server moet laag genoeg zijn om aan de vereisten van de toepassing te voldoen.
2. Schaalbaarheid: De model server moet kunnen schalen om aan de verkeersvereisten van de toepassing te voldoen.
3. Flexibiliteit: De model server moet flexibel genoeg zijn om de specifieke behoeften van de toepassing te ondersteunen, zoals verschillende frameworks en hardwareplatforms.
4. Gebruiksgemak: De model server moet eenvoudig te gebruiken en te beheren zijn.
5. Benchmarks: Het is belangrijk om verschillende model servers te benchmarken om te zien welke het beste presteert voor uw specifieke behoeften.
6. Ondersteuning: Overweeg het niveau van ondersteuning dat beschikbaar is voor de model server.
7. Community: Overweeg de omvang en activiteit van de community rond de model server.

💡

Andere inzichten rond het ML-platform bij Voiceflow:
Voiceflow gebruikt een combinatie van AWS en GCP, aangezien verschillende enterprise-klanten verschillende vereisten hebben. Ze hebben het gebruik van Karpenter of Autopilot nog niet verkend, omdat ze hun infrastructuur al aan het uitbouwen waren toen deze functies werden uitgebracht. Ze moeten ook T4 GPU's gebruiken voor veel van hun workloads, die niet optimaal zijn voor Autopilot. Over het algemeen geven ze voorlopig prioriteit aan engineering-tijd en zullen ze uiteindelijk migreren naar geavanceerdere infrastructuuroplossingen naarmate ze verder opschalen.

Voiceflow's benadering van generatieve AI

Voiceflow neemt een voorzichtige houding aan ten opzichte van open-source generatieve AI. Ze zijn zich bewust van de potentiële voordelen van deze modellen, maar ze zijn zich ook bewust van de uitdagingen die ermee gepaard gaan. Ze zetten zich in om hun gebruikers de best mogelijke ervaring te bieden, en ze zullen overstappen op open-source modellen wanneer het het juiste moment is voor hun bedrijf.

Uitdagingen van open-source generatieve AI

Er zijn enkele uitdagingen verbonden aan open-source generatieve AI:

1. Snelle evolutie: Open-source generatieve AI-modellen evolueren snel, wat het moeilijk kan maken om op de hoogte te blijven van de nieuwste optimalisaties.
2. Kosten: Open-source generatieve AI-modellen kunnen computationeel duur zijn om te trainen en te deployen.
3. Ondersteuning: Open-source generatieve AI-modellen hebben mogelijk niet hetzelfde niveau van ondersteuning als propriëtaire modellen.

Voordelen van open-source generatieve AI

Ondanks de uitdagingen bieden open-source generatieve AI-modellen ook een aantal voordelen:

1. Transparantie: Open-source generatieve AI-modellen zijn transparanter dan propriëtaire modellen, wat betekent dat gebruikers beter kunnen begrijpen hoe ze werken en de resultaten kunnen vertrouwen.
2. Reproduceerbaarheid: Open-source generatieve AI-modellen zijn beter reproduceerbaar dan propriëtaire modellen, wat betekent dat gebruikers de resultaten van experimenten kunnen dupliceren en hun werk met anderen kunnen delen.
3. Aanpasbaarheid: Open-source generatieve AI-modellen kunnen worden aangepast en uitgebreid om aan specifieke behoeften te voldoen.

Omgaan met latency

Latency is een kritieke factor om te overwegen bij het kiezen van een model voor een retrieval augmented generation-systeem. De beste aanpak is om gebruikers de keuze te geven uit verschillende modellen en voorlichting te geven over wat ze voor verschillende taken moeten gebruiken.

Als latency bijvoorbeeld de belangrijkste factor is, wordt het gebruik van een op NLU gebaseerde benadering met intense utterances en statische antwoorden aanbevolen. NLU-modellen zijn doorgaans veel sneller dan generatieve modellen, en statische antwoorden kunnen met een zeer lage latency worden geleverd.

Als de gebruiker een hogere precisie of betere opmaak nodig heeft, wordt het gebruik van een generatief model zoals GPT-4 aanbevolen. Generatieve modellen zijn krachtiger dan NLU-modellen en kunnen tekst genereren die natuurlijker en boeiender is. Het is echter belangrijk op te merken dat generatieve modellen ook veel trager zijn dan NLU-modellen.

Een andere manier om latency te verminderen is het gebruik van een gedistribueerde architectuur. In een gedistribueerde architectuur worden de retrieval- en generatietaken op afzonderlijke servers uitgevoerd. Hierdoor kan het systeem schalen om te voldoen aan de behoeften van zelfs de meest veeleisende toepassingen.

Het bouwen van een hoogwaardig Retrieval Augmented Generation-systeem

Retrieval augmented generation (RAG)-systemen zijn een krachtige nieuwe benadering van tekstgeneratie die de sterke punten van retrieval- en generatieve modellen combineert. RAG-systemen werken door eerst relevante passages uit een kennisbank op te halen en vervolgens een generatief model te gebruiken om tekst te genereren op basis van de opgehaalde passages.

RAG-systemen kunnen voor een verscheidenheid aan taken worden gebruikt, waaronder vraagbeantwoording, samenvatten en creatief schrijven. Het bouwen van een hoogwaardig RAG-systeem kan echter een uitdaging zijn.

In deze blogpost bespreken we enkele van de belangrijkste factoren waarmee u rekening moet houden bij het bouwen van een RAG-systeem, waaronder:

1. Modelselectie: Er is een verscheidenheid aan verschillende retrieval- en generatieve modellen beschikbaar. Het is belangrijk om modellen te kiezen die geschikt zijn voor uw specifieke behoeften. Als u bijvoorbeeld tekst in een specifieke taal moet genereren, moet u een model kiezen dat is getraind op tekst in die taal.
2. Dataselectie: De kwaliteit van de data die u gebruikt om uw systeem te trainen, heeft een aanzienlijke invloed op de prestaties ervan. Het is belangrijk om data te kiezen die relevant is voor uw doeltaken en vrij is van fouten.
3. Hardwareselectie: De hardware die u gebruikt, heeft ook een aanzienlijke invloed op de prestaties van uw systeem. Het gebruik van GPU's kan bijvoorbeeld de retrieval- en generatietaken aanzienlijk versnellen.
4. Systeemarchitectuur: RAG-systemen kunnen op verschillende manieren worden geïmplementeerd. Het is belangrijk om een systeemarchitectuur te kiezen die geschikt is voor uw specifieke behoeften. Als u uw systeem in productie moet deployen, moet u een architectuur kiezen die schaalbaar en betrouwbaar is.

Naast de hierboven genoemde factoren is het ook belangrijk om in gedachten te houden dat RAG-systemen complex zijn en moeilijk te generaliseren kunnen zijn. Het domein en de use case van elke gebruiker zullen anders zijn, dus het is belangrijk om gebruikers de mogelijkheid te bieden om hun eigen prompts, verwerkings- en chunking-strategieën te testen. Hiermee kunnen gebruikers het systeem aanpassen aan hun specifieke behoeften.

Hier kunt u meer lezen over hoe u een RAG-architectuur kunt deployen op TrueFoundry:

‍

LLM-powered QA Chatbot op uw data in uw Cloud

Breng een vraag-antwoord-bot op uw data in uw cloudomgeving naar productie met behulp van open-source LLMs en RAG (Retrieval-Augmented Generation).

TrueFoundry Blog TrueFoundry

‍

Overstappen op generatieve AI: uitdagingen en kansen

Bedrijven die op NLP gebaseerde oplossingen hebben gebouwd met behulp van traditionele methoden, staan nu voor de uitdaging om over te stappen op generatieve AI. Generatieve AI-modellen, zoals GPT-4 en LaMDA, bieden een aantal voordelen ten opzichte van traditionele methoden, waaronder de mogelijkheid om tekst te genereren, talen te vertalen en vragen op een uitgebreide en informatieve manier te beantwoorden. Er zijn echter ook een aantal uitdagingen verbonden aan de overstap naar generatieve AI.

Eén uitdaging is dat generatieve AI-modellen nog in ontwikkeling zijn en duur kunnen zijn in het gebruik. Bovendien is het concept van prompting nog vrij ambigu en uitdagend. Bedrijven moeten effectieve prompting-technieken kunnen ontwikkelen om het maximale uit generatieve AI-modellen te halen.

Een andere uitdaging is het integreren van generatieve AI-modellen in de bestaande infrastructuur. Bedrijven moeten er voor zorgen dat hun systemen de toegenomen belasting en complexiteit van generatieve AI-modellen aan kunnen.

Ondanks de uitdagingen zijn er ook tal van kansen verbonden aan de overstap naar generatieve AI. Generatieve AI-modellen kunnen bedrijven helpen de kwaliteit van hun producten en diensten te verbeteren, taken te automatiseren en nieuwe producten en diensten te creëren.

Hier zijn enkele tips voor bedrijven die overstappen op generatieve AI:

1. Begin met het evalueren van uw behoeften. Wat zijn de specifieke taken die generatieve AI-modellen moeten uitvoeren? Wat zijn uw budgettaire beperkingen? Zodra u een goed inzicht heeft in uw behoeften, kunt u de juiste generatieve AI-modellen voor uw use case gaan identificeren.
2. Experimenteer met verschillende modellen en technieken. Er is geen universele aanpak voor de overstap naar generatieve AI. Bedrijven moeten experimenteren met verschillende modellen en technieken om te ontdekken wat voor hen het beste werkt.
3. Integreer generatieve AI-modellen in uw bestaande infrastructuur. Bedrijven moeten er voor zorgen dat hun systemen de toegenomen belasting en complexiteit van generatieve AI-modellen aan kunnen. Dit kan het opschalen van hun infrastructuur vereisen of het aanbrengen van wijzigingen in hun software.
4. Train uw personeel. Generatieve AI-modellen zijn krachtige middelen, maar het gebruik ervan kan ook complex zijn. Bedrijven moeten hun personeel trainen in het effectief gebruiken van generatieve AI-modellen.

De overstap naar generatieve AI kan een uitdaging zijn, maar het is ook een kans voor bedrijven om hun producten en diensten te verbeteren en nieuwe producten en diensten te creëren. Door de bovenstaande tips te volgen, kunnen bedrijven de overstap naar generatieve AI zo soepel en succesvol mogelijk maken.

Lees onze vorige blogs in de TrueML-serie

‍

True ML Talks #20 - Transformers, Embedding, LLMS @ Turnitin

Diepgaande duik in een nieuwe manier van denken over Transformers en LLMs, via Embeddings. We spreken met Sumeet, Distinguished ML Scientist @ Turnitin.

TrueFoundry Blog TrueFoundry

‍

Blijf kijken naar de TrueML YouTube-serie en lees de hele TrueML blogserie.

TrueFoundry is een ML Deployment PaaS op Kubernetes om de workflows van ontwikkelaars te versnellen, terwijl ze de volledige flexibiliteit behouden bij het testen en deployen van modellen, met gegarandeerde beveiliging en controle voor het infrastructuurteam. Via ons platform stellen we Machine Learning-teams in staat om modellen binnen 15 minuten te deployen en te monitoren met 100% betrouwbaarheid, schaalbaarheid en de mogelijkheid om binnen enkele seconden te roll-backen - waardoor ze kosten besparen, modellen sneller in productie brengen en echte bedrijfswaarde realiseren.