An Introduction to Virtual Assistants

(From Creating Virtual Assistants by Andrew Freed)

This article gives you an introduction to creating useful virtual assistants with the Command Interpreter pattern.

(Take 40% off Creating Virtual Assistants by entering fccfreed into the discount code box at checkout at manning.com.)

A common use of virtual assistant technology is in the Command Interpreter pattern. This is prevalent in "smart" devices: your phone, your TV remote, your appliances. The command interpreter deals with a limited vocabulary - enough to invoke the commands it supports - and the interaction is finished as soon as the information needed to execute the task is collected. A smart television remote is tuned to recognize words like “channel” and “volume” but won’t recognize a command like “Set air temperature to 76 degrees”. Table 1 shows example command interpreters and commands that in their vocabulary.

Table 1 Example command interpreters and supported commands

My favorite command on my phone is the "set alarm" command which has two parameter slots: the alarm time and the alarm reason. On my phone the alarm time is a required parameter and the alarm reason is optional. In the first example below, I've mapped out the simplest "set alarm" invocation: "Set an alarm". The interpreter knows that setting an alarm without an alarm time is impossible and it prompts me for the alarm time.

The command interpreters you’re most familiar with require activation either via a physical button or a "wake word". Several wake words you may be familiar with include "Hey Siri", "Ok Google", and "Alexa". Devices that wake via a button don't start listening until you press that button. Devices which are always listening don't jump into action until you use a wake word.

The diagram below demonstrates how several command interpreters parse your input into an actionable command. Try experimenting with your devices to see how many different ways you can execute a command, either by changing the words ("create alarm" vs "set an alarm") or changing the order of the information given.

Figure 1 Exploring the parts of a command

Figure 2 Alternate terminology for the command interpreter pattern

The command interpreter’s job is to identify a command (ex: “set alarm”) and fill all of the parameter "slots" (ex: time of alarm) for that command. When the command interpreter is invoked it asks as many follow-up questions as needed to fill all of the required slots - no more questions and no less. This is similar to how virtual assistants work except that command interpreters only service a single request - the entire conversation is finished when the required parameters are gathered and the initial command is executed.

Do virtual assistants always have “commands”?
Terminology differs. In this article I refer to intents and entities; nearly every virtual assistant platform uses the “intent” terminology. Some platforms use “action” and “intent” interchangeably. In the case of command interpreters, commands are intents and parameters are entities.

Figure 3 A command can require follow-up questions from the command interpreter

Command interpreters can also be coded to receive multiple parameters at once as long as there’s a way to distinguish them. In the next example I provide all of the alarm parameters in a single statement: "Set an alarm for 9PM to write Chapter 1." The phone gladly obliges this request!

Figure 4 When all required parameters are passed to the command interpreter, it completes the command and ends the conversation.

When developing a command interpreter, you need to separate the parameters from the command. In the case of setting an alarm this isn’t too difficult: the command is something like "set an alarm", the alarm time is text that parses to a time, and any remaining text (minus filler words like "for", "to", "at", etc.) is the reason.

If you want to learn more, you can check out the book on Manning’s browser-based liveBook platform here.