IBM Watson JSON Nem Guide

Du ved sikkert allerede, at du kan bygge Watson Chatbots ved at bruge Watsons GUI til at oprette Intents, Entities og Dialogues, og derefter lime dem effektivt sammen til et Watson Skill. For mindre og simple Skills, med mindre end 10 til 20 af de nævnte elementer, vil det virke fint. Men for større skills, som skal gro og vedligeholdes, der bliver GUI’en alt for omstændig og tidskrævende at arbejde med, specielt med mange Dialogues som refererer til mange Intents.

Derfor har IBM gjort det muligt at repræsentere et Skill vha. det beskrivende sprog JSON, der som XML eller HTML, er ren tekst, og kan være computer genereret. Dette blogindlæg forklarer basic komponenterne i Watson JSON strukturen, og er primært for udviklere og Watson arkitekter.

Den bedste metode til udvikling af effektive Watson Assistant Chatbots, med gode og omfattende Dialog Skills, er ved programmeringsmæssigt at generere JSON koden, som definerer et Skill, og derefter importere det til sin Watson Assistant i IBM Cloud.

Selve JSON koden er meget struktureret, og består kun af 4 forskellige blokke, som jeg vil forklare for dig herunder.

Det er en god idé at bruge en ”JSON checker” mens man udvikler koden, idet en forkert syntax i JSON koden er en af de størtste kilder til fejl, når man importerer Skills via JSON!

Der findes flere gode online værktøjer til at checke JSON syntax, og jeg bruger ofte værktøjet JSONFormatter:

https://jsonformatter.org/json-parser

Mit eksempel viser en simpel chatbot, hvor brugeren kan spørge om firmaets adresse, og spørge på forskellige måder, men hver gang få svaret “Our business is located in ‘Watson Square 5, NY 10040″ and “Discovery Avenue, AZ 85010” eller standardsvaret “I didn’t get your meaning.” hvis bot’en ikke kunne finde noget i spørgsmålet, der trickede et intent.

Som du kan se ovenfor, så starter INTENTS sektionen i bot’en med ordet “intents”, efterfulgt af et “[” og en descriptor “intent”: “descriptor_name”, hvilket i vores tilfælde er “business_address“.

Herefter lister man alle sine spørge-eksempler for det Intent, som overordnet er defineret af descriptoren “examples”, efterfulgt af hvert eksempel.

En Watson Assistant Chatbot vil normalt indeholde mange forskellige Intents, og de er listed som sektioner under det første Intent. “intents” sektionen slutter med tegnet “]”, hvilket fortæller importeren, at alle intents er blevet defineret til import.

Husk at følge reglerne for JSON ved sætte alle tegnene “{“, “}”, “[“, “]” og alle kommaer rigtigt!

Ligesom for Intents, så har Entites sin egen sektion “entities” og en descriptor “entity“:”descriptor_name” som er definitionen på det specifikke entity, som i dette tilfælde er “business“.

Herefter lister du alle entity synonymerne som “values“. Indstillingen “fuzzy_match”: true betyder at du ikke behøver at skrive den eksakte stavemåde for at få et match – et delvist match (like bureau <> bureu) vil også virke, hvilket dog ikke altid er det bedste valg.

En Watson Assistant Chatbot vil normalt indeholde mange forskellige entities, og de er listed som sektioner under det første entity. Sektionen “entities” ender med tegnet “]”, hvilket fortæller importrutinen, at alle entities er blevet defineret til import.

Sektionen DIALOG_NODES består normalt af mindst 3 undersektioner, hvor den første hedder “Welcome” og den sidste hedder “Anything_else” (error handling).

Alle de andre undersektioner indeholder de reelle dialoger med brugeren, og bruges til at håndtere de tidligere beskrevne intents.

Hver undersektion har et navn, defineret af descriptoren “dialog_node” : “node name”. I vores eksempel er nodenavnene: “Welcome“, “Business_Address” og “Anything_Else“.

For at gøre det muligt at definere den rigtige rækkefølge af dialogerne ved import, har hver dialog descriptoren “previous_sibling“, som selvfølgelig ikke findes for dialogen “Welcome”, som jo er den dialog der initierer hele flowet.

Nogle af descriptorerne er systemspecifikke til Watson, såsom “type” og “output”, hvor andre er en del af det aktuelle flow. Den descriptor som linker en dialog med et specifikt intent er descriptoren “conditions”.

For dialog noden “Business_Address” er conditions givet ved sin værdi “#business_address”, og som du måske ved fra Watson GUI, så definerer tegnet ”#” et intent. Det betyder, at “Business_Address” dialogen bliver triggered af spørgsmålene i intentet #business_address.

Svaret (som returneres til brugeren) fra dialog_node er defineret i values, og i det dette tilfælde returnerer den 2 adresser for det aktuelle firma vi har som case.

Den sidste blok i vores skill hedder ”MAIN”, og den indeholder primært en masse system specifikke descriptorer til brug for IBM Watson JSON. Den vigtigste descriptor for brugeren er den der hedder “name”, som definerer navnet på det samlede skill. I vores tilfælde hedder den “Business Address Skill”.

Der kan være mange descriptorer der definerer et skill, og som gør hele spørgetræet i skill’et temmelig komplekst og sofistikeret, men dem som er vist i dette blogindlæg, viser kun de enkle og mest nødvendige!

Til venstre kan du se hvordan du uploader JSON koden til dig IBM cloud, for på den måde at kunne generere dit Watson Skill.

Som du kan se er der også et ”Download” i menuen, og det var der jeg først lærte om Watson JSON, for her kan du også eksportere JSON koden fra et eksisterende Skill, og kan undersøge det og videreudvikle det i tekst, og senere importere/uploade det til dig IBM Cloud.