In een vorige blogpost bespraken we eerder theoretisch de mogelijkheden van API’s voor computervertaling. De huidige blogpost is een neerslag van onze praktische ervaringen met dergelijke API’s. Achtereenvolgens bespreken we enkele testen met taaldetectie, vertaling en een meertalige chatbot als praktische case.

Taaldetectie

Als eerste aspect testten we taaldetectie uit: het identificeren van de taal van een tekstfragment. Concreet zetten we een experiment op met de IBM Language Translator API en de Google Cloud Translation API. Beide API’s blijken heel eenvoudig in gebruik. De functies zijn goed gedocumenteerd en de integratie in een eigen toepassing is gemakkelijk op basis van de aangeboden SDK’s. De toegang tot de API’s gebeurt telkens op basis van een API key. De accuraatheid van de taaldetectie lijkt bij beide API’s goed, maar dat aspect is niet ten gronde getest.

Terwijl taaldetectie op basis van tekst-input goed werkt, willen we hier nog meegeven dat taaldetectie bij spraak-input verre van evident is. De enige mogelijkheid vandaag bestaat er in om een speech-to-text (STT) API te gebruiken en een beperkte set van mogelijke talen mee te geven. Zo kan je aan de Google Cloud Speech-to-Text API tot maximum 3 kandidaat-talen meegeven. Op basis van een experiment merken we dat dit in de praktijk het best werkt met korte commando’s; het werkt minder goed bij langere zinnen. Het is bijgevolg moeilijk om vandaag al een scenario te ondersteunen waarbij we de taal willen detecteren van iemand die spreekt zonder het minste idee te hebben over welke taal het zou kunnen gaan.

Vertaling

Naast de functionaliteit voor taaldetectie testten we ook de mogelijkheden uit van de API’s op vlak van tekstvertaling. Vertalingen verlopen met hetzelfde gebruiksgemak als voor taaldetectie: Aan de inputzijde geven we het tekstfragment mee en de doeltaal. Als output krijgen we naast de gedetecteerde taal nu ook de vertaalde tekst terug. Tijdens de experimenten werkten we in 2 stappen: in een eerste stap detecteren we de taal van de input en vervolgens doen we een vertaling naar de doeltaal waarbij we expliciet de brontaal meegeven als parameter. Maar de API’s bieden ook de mogelijkheid om taaldetectie en vertaling in één beweging uit te voeren. Voor het uitvoeren van een vertaling is het niet nodig om een brontaal op te geven; als die weggelaten wordt dan voert de API zelf eerst een taaldetectie uit.

De accuraatheid van de vertalingen is niet ten gronde getest, maar uit de experimenten merken we dat de vertalingen dikwijls goed genoeg zijn als basisvertaling, al worden bepaalde specifieke termen niet altijd “juist” vertaald volgens de context.

We geven nog mee dat de Google API beduidend meer taalmodellen (brontaal-doeltaal paren) ondersteunt dan die van IBM.

Meertalige chatbot

Een interessante case om API’s voor taaldetectie en vertaling in te schakelen is een meertalige chatbot. Het principe is dat je een vraag kan stellen aan de chatbot in om het even welke taal, zolang die ondersteund wordt door de translation API. De vraag wordt dan vertaald naar de taal waarin de chatbot getraind is, in ons geval het Frans. Het Franstalige antwoord van de chatbot wordt tenslotte terug omgezet in de taal waarin de vraag oorspronkelijk gesteld werd.

Concreet hebben we dit uitgetest met de chatbot Student@work die antwoordt op algemene vragen over studentenarbeid. Voor de vertaling kozen we de API van Google omdat die het meeste talen ondersteunt (meer dan 100).

Twee zaken zijn hier belangrijk:

1. De vertaling van de vraag moet van voldoende kwaliteit zijn zodat de chatbot de correcte intentie herkent. We merken dat specifieke termen soms “verkeerd” vertaald worden wat er toe leidt dat de chatbot op het verkeerde been gezet wordt en niet de juiste intentie herkent. We kunnen dit aanpakken door een custom glossary in te schakelen. Dat houdt in dat we een set van overeenkomstige termen (similar terms set) opstellen in verschillende talen zodat de vertalingen accurater zijn in de context van het domein van de chatbot.
   Een voorbeeld: de vraag “is een attest verplicht?” wordt standaard vertaald naar “un certificat est-il requis?”. Dit wordt door de chatbot verkeerdelijk gezien als een intentie over betaalde ziektedagen omdat die intentie getraind werd met voorbeeldzinnen die “certificat médical” bevatten. Dergelijke gevallen kunnen we opvangen via een custom glossary waarbij we aangeven dat de term “attest” moet vertaald worden als “attestation”.
2. De vertaling van het antwoord dient correct en leesbaar te zijn. Hier zien we geen grote problemen. De antwoorden zijn leesbaar en dienen de gebruiker voldoende van antwoord. Verkeerd vertaalde termen kunnen we ook hier opvangen door middel van een custom glossary.

Conclusie

We kunnen concluderen dat het gemakkelijk is om API’s voor taaldetectie en vertaling aan te roepen vanuit een eigen toepassing. Uit de experimenten bleek dat de antwoordtijden heel goed zijn. We moeten echter ook oog hebben voor de kwaliteit van de vertaling. Custom glossaries kunnen helpen om de vertaling beter af te stemmen op de context. Daarnaast moeten we er ons ook van bewust zijn dat de vertalingen uitgevoerd worden in de cloud, wat wellicht niet altijd wenselijk of aanvaardbaar is op vlak van gegevensbescherming.

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.