In een vorige blogpost hebben we de stopzetting besproken van Google Conversational Actions en wat dat precies inhoudt. We gaven drie alternatieven mee om een conversationele toepassing te voorzien. In deze blogpost gaan we dieper in op het derde alternatief, dat van de “custom assistant”.

Om na te gaan wat het inhoudt om een custom assistant te voorzien, raken we hieronder de verschillende benodigde componenten aan. Die componenten zijn samengevat in onderstaand schema: de gebruikersinterface (gebruikerservaring), het conversational platform, de spraakdiensten en de back-end.

Gebruikerservaring

Een eerste aspect is de gebruikerservaring. Bij een integratie met een virtuele assistent, zoals Conversational Actions in Google Assistant, kunnen we gebruik maken van het volledige ecosysteem van de virtuele assistent. Conversationele ervaringen kunnen dan aangeboden worden op tal van toestellen waaronder smartphone, smart speaker, tot in de auto toe. Als we een eigen assistant bouwen, dan kunnen we geen gebruik meer maken van dat ecosysteem en verliezen we voor een stuk het gebruiksgemak dat daarmee gepaard gaat, zoals het aanroepen van een assistant met één druk op de knop of een trigger word. We moeten zelf een gebruikersinterface voorzien, doorgaans in de vorm van een app of webtoepassing.

Standaard kan het er voor een gebruiker uitzien als een chattoepassing waarbij input kan gegeven worden via zowel tekst als spraak. Op het scherm kan de gebruiker de historiek zien van de volledige conversatie. In het voorbeeld hieronder is een rudimentaire interface te zien. Uiteraard kan de look & feel naar believen aangepast worden. Dit is een dialoog-gedreven interface waarbij er na elke input van de gebruiker feedback wordt gegeven door de toepassing via tekst en spraak.

Daarnaast kunnen we ons een klassieke interface inbeelden met inputvelden, waarbij spraak als extra feature wordt toegevoegd om parameters aan te leveren. Er is dan geen echte dialoog over-en-weer, maar de mogelijkheid om via continue spraak-input parameters aan te leveren. Een voorbeeld hiervan is Speechly, een tool die toelaat om intents en parameters te herkennen uit een audio-inputstream en daar events aan koppelt. Die events kunnen dan gebruikt worden in de gebruikersinterface om de gedetecteerde parameters in te vullen in velden op het scherm. In de screenshot hieronder is te zien hoe je met een hold-to-talk knop parameters kan ingeven via spraak. De ingesproken tekst is links bovenaan zichtbaar (“book a flight from Brussels to Paris“). De parameters (Brussels en Paris) worden automatisch ingevuld in de betreffende velden van het formulier. De demo kan je hier zelf uitproberen. Momenteel ondersteunt Speechly enkel Engels en Fins.

Conversational platform

Naast de front-end hebben we uiteraard een conversational platform nodig om een custom assistant te bouwen. Die staat in voor het herkennen van intents en entities (parameters), dialoogbeheer en het capteren van alle benodigde parameters om op een vraag te kunnen antwoorden (slot filling). Naast de features en kwaliteit van het conversational platform kan het deployment model van belang zijn in functie van gegevensbescherming en privacy: wordt het platform gehost in de public cloud, of kan het platform in een meer gecontroleerde omgeving draaien (private cloud of on-premise op eigen infrastructuur)? Heel wat aanbieders, zoals Chatlayer, Google en Oswald, bieden een conversational platform onder SaaS-vorm aan in de public cloud. FOD BOSA biedt een raamcontract voor een ‘bot platform as managed service’ dat gebaseerd is op een SaaS-platform. Enkele aanbieders, zoals Cognigy en Nuance bieden daarnaast ook de mogelijkheid om het platform on-premise te draaien.

De keerzijde van het zelf hosten van een oplossing is dat we dan ook zelf moeten instaan voor de infrastructuur waarop het draait, waarbij de nodige aandacht moet uitgaan naar beschikbaarheid, performantie, veiligheid, etc. Die aspecten brengen een zekere kost met zich mee.

Spraakdiensten

Om naast een tekstuele interface ook een spraakinterface aan te bieden zijn er diensten nodig voor spraakherkenning (speech-to-text) en spraaksynthese (text-to-speech). Net zoals bij de conversationele platformen zijn er heel wat spraakdiensten beschikbaar in de public cloud, zoals Amazon, Google en Microsoft. Daarnaast zijn er oplossingen die ook on-premise kunnen gehost worden, zoals Deepgram, Microsoft, Nuance en Speechmatics. De Microsoft speech services uit de Azure cloud kunnen elders gehost worden onder de vorm van Docker containers, in een private cloud of on-premise. Het is zo dat in beide gevallen (Azure public cloud en containers) er een pay-per-use verbruiksmodel gehanteerd wordt.

Bij het zelf hosten van een dergelijke oplossing winnen we hiermee enerzijds aan controle: de verwerkte spraakgegevens verlaten onze eigen infrastructuur niet. Anderzijds moeten we zelf instaan voor de hosting, wat gepaard gaat met extra kosten zoals hierboven beschreven bij het conversational platform.

Tot slot

Eén van de weinige voorbeelden van een custom spraakassistent is KBC Kate. Die laat toe om bepaalde info op te vragen of transacties uit te voeren vanuit de KBC Mobile app via tekst of spraak. In principe zijn de tools voorhanden om een dergelijke custom assistant te bouwen. Een belangrijk aandachtspunt is evenwel gegevensbescherming en privacy. Indien public cloud services geen optie zijn, kunnen we gebruik maken van on-premise alternatieven. Die betekenen echter een extra kost op vlak van hosting, en niet elke aanbieder biedt de mogelijkheid tot een on-premise deployment. Om te experimenteren met dergelijke technologie kan gekozen worden voor een oplossing die zowel in de public cloud als on-premise beschikbaar is. Op die manier kan relatief goedkoop gestart worden met een public cloud oplossing en indien nodig overgeschakeld worden naar een on-premise installatie om tegemoet te komen aan vereisten rond gegevensbescherming en privacy.

---

Dit is een ingezonden bijdrage van Bert Vanhalst, IT consultant bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.