Systems and methods for dynamically expanding natural language processing agent capacity

A system described herein may provide for the adaptation and/or expansion of a natural language processing (“NLP”) platform, that supports only a limited quantity of intents, such that the described system may support an unlimited (or nearly unlimited) quantity of intents. For example, a hierarchical structure of agents may be used, where each agent includes multiple intents. A top-level (e.g., master) agent may handle initial user interactions, and may indicate a next-level agent to handle subsequent interactions.

BACKGROUND

Natural language processing (“NLP”) is a technique that allows for individuals to interact with devices or systems in a conversational manner. Existing NLP-related systems, such as the Dialogflow® system, provide services to assist with NLP techniques. Briefly, existing NLP-related systems may make use of “intents,” which are data structures that are used to handle user input and process them accordingly. However, existing NLP-related systems may have static limits on the number of supported intents (e.g., a maximum of 2,000 intents). This hard limit may limit or prevent NLP implementations where a higher number of intents are desired to be supported.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Natural language processing (“NLP”) techniques may involve the use of “black box” or “off-the shelf” components or systems. Some existing systems, such as the Dialogflow® system, provide for a maximum quantity of intents, in order to process user input in accordance with design objectives of a developer or entity who wishes to use such systems. While the maximum quantity may be suitable for some purposes, other purposes may require a higher quantity of intents to be supported. While one solution would be for the maximum quantity of supported intents to be raised by a vendor or other entity that provides these systems, it may not be technically or financially feasible to raise this quantity. Further, because NLP systems may be built, maintained, etc. by entities that are separate from entities that implement or use these systems, it may not be possible to adjust the structure of the NLP systems themselves. Thus, a need exists for adapting existing NLP systems (e.g., which only support a specified hard limit of intents) to support more intents.

While discussed in greater detail herein, the term “intent” generally refers to information that can be used to handle a given user input, in the context of what has already been received from and outputted to the user. The handling may include determining an appropriate response for the user, determining an item of content (e.g., a video, an image, an audio clip, etc.) to provide to the user, and/or performing some other action. The handling may also include storing and/or modifying context information, such that subsequent user interactions can refer back to the present interaction (e.g., which can give the user the impression of carrying on a dialog or conversation).

In some embodiments, NLP systems may use NLP agents (sometimes referred to herein simply as “agents”), which may include a set of intents, as well as logic to determine which agent should process a given user input. However, as mentioned above (and as discussed further below with respect toFIG. 2), each agent may have a maximum limit on the quantity of intents supported.

Some embodiments may utilize agents in a hierarchical manner, which may vastly enhance the number of available intents that can be supported by an NLP system. Further, the techniques described herein require no modification of the definitions of existing NLP systems, and are thus useable in a variety of scenarios. For example,FIG. 1shows a Master Agent (which may be considered a higher, or highest, level in the hierarchy) and Agents1-N (which may be considered a lower level in the hierarchy than the Master Agent). Also pictured is an Agent Routing Component (“ARC”), which may route user input to an appropriate agent (e.g., the Master Agent or one of the lower level agents, such as Agent_1, Agent_47, or Agent_N).

As shown, the ARC may receive (at1) user input. The user input may be received from a user device, such as mobile phone, a tablet computer, a desktop computer, an interactive kiosk, etc. The user input may include, in some embodiments, a natural language phrase spoken by a user of the user device. Additionally, or alternatively, the user input may include the selection of a graphical element in a graphical user interface (“GUI”), a selection of an interactive voice response (“IVR”) menu, a haptic input (e.g., a swipe or a touch on a touchscreen), and/or some other input. For the purposes of this example, assume that the input received (at1) is the first input from the particular user device by the ARC. The ARC may receive the input and may determine (at2) whether any active conversations exist for the user (or for the user device). In this example, the ARC may determine (at2) that an active conversation does not exist for the user. Based on the determination that a conversation is not active for the user, the ARC may provide (at3) the user input to the Master Agent.

As shown, the Master Agent may determine (at4) how to handle the user input. For example, the Master Agent may evaluate the user input and may determine that the user input is the starting point for a given conversation. As described below, the intents included in the Master Agent may each correspond to a starting point for different conversations, and the Master Agent may identify to which conversation the user input is related. In the example shown inFIG. 1, the Master Agent has identified that the user input is related to a particular conversation (“Conversation_1,787”). This identification may include determining that the intent, associated with Conversation_1,787, specifies a set of parameters (e.g., an input context) that matches the user input.

The Master Agent may perform actions specified in the identified intent, including outputting (at5) a response to the ARC (where some or all of the response includes information, content, etc., to be provided to the user device, such as an answer to a question or a request for further user input). The response (outputted at5) may also include an indication of which conversation was identified (e.g., Conversation_1,787) in this example. In some embodiments, the response may include an indication of which agent (e.g., which agent, at a level below the Master Agent in the hierarchy) includes intents related to Conversation_1,787(i.e., Agent_47in this example). Additionally, or alternatively, the ARC may store mapping information that maps conversations to agents. The Master Agent may also provide context information, which may be used for handling subsequent user input.

The ARC may forward (at6) the response to the user device. After this response is provided to the user device, the user device may provide (at7) further user input. The ARC may determine (at8) that an active conversation exists for the user, and may thus attempt to route the user input to the correct agent (e.g., Agent_47, which is the agent that includes the intents for the identified Conversation_1,787). The ARC may forward (at9) the user input, as well as the context for the user, to the identified Agent_47. In some embodiments, the ARC may also include information indicating which conversation (i.e., Conversation_1,787, in this example) the user input is associated with. Agent_47may evaluate the user input and the context, and determine that the user input and/or context match a particular agent associated with Conversation_1,787, and may forward the user input and/or context to the particular agent. Note that, for illustrative purposes,FIG. 1shows a single box for Conversation_1,787. As discussed below, this may be a conceptual illustration to represent multiple intents that are related to the conversation.

The intent to which the input is routed (at9) may perform a specified set of actions on the received input, which may include outputting (at10) a response. As discussed above, the response may include an answer to a question and/or other content or information. An output context may also be outputted (at10), which may include one or more items included in the input context (provided at9), and/or may include additional or different items as included in the input context. The ARC may proceed to output (at11) the response to the user device.

As may be apparent, the hierarchical system of embodiments described herein (e.g., similar to that discussed with respect toFIG. 1), may allow for significantly more intents than a traditional single-agent implementation. An example of a single-agent implementation is shown inFIG. 2. As shown, typically a user (or user device) is able to communicate with a single agent, which may route user input to a given intent based on the user input and any existing context for the user. However, the hard limit (e.g., 2,000 in this example) imposed by a provider of the agent means that only 2,000 intents can be supported. More robust interactions, which may necessitate or otherwise benefit from more than 2,000 intents would thus be impossible. As mentioned above, the limit may be imposed by the provider based on technical constraints, financial constraints, and/or other considerations.

In contrast, embodiments described herein may support significantly more intents, without requiring the provider of an agent to alter the architecture, algorithms, or other aspects of the agents. For example, using a two-level hierarchy (e.g., one Master Agent and corresponding next-level agents) may allow for up to 4,002,000 intents to be supported (e.g., 2,000 intents in the Master Agent, where each intent in the Master Agent points to a discrete agent that itself supports 2,000 intents).

Additionally, the embodiments described herein provide a performance improvement by virtue of using a hierarchical agent structure, rather than using a “flat” or “single” agent structure. For example, in a flat or single agent structure, an agent may incur greater overhead (e.g., exponential, or otherwise increasing) processing time and/or resources when attempting to use a greater quantity of intents to determine how to handle a given user input and/or context. In contrast, in the hierarchical structure described herein, each agent may include comparatively fewer agents than a “flat” or “single” agent structure (e.g., that supports a comparable total quantity of agents). Accordingly, each agent has to evaluate a smaller quantity of intents (e.g., by one particular agent at a given level in the hierarchy), thereby consuming less processing resources and/or time while evaluating a greater quantity of intents (e.g., as compared to evaluating intents in a “flat” or “single” agent structure, in which the agent may include numerous intents that are not related to a given user input or context).

FIG. 3illustrates an example environment300, in which one or more embodiments, described herein, may be implemented. As shown inFIG. 3, environment300may include user device305, ARC310, one or more agents315, and network320. The quantity of devices and/or networks, illustrated inFIG. 3, is provided for explanatory purposes only. In practice, environment300may include additional devices and/or networks; fewer devices and/or networks; different devices and/or networks; or differently arranged devices and/or networks than illustrated inFIG. 3. For example, while not shown, environment300may include devices that facilitate or enable communication between various components shown in environment300, such as routers, modems, gateways, switches, hubs, etc. Alternatively, or additionally, one or more of the devices of environment300may perform one or more functions described as being performed by another one or more of the devices of environments300. Devices of environment300may interconnect with each other and/or other devices via wired connections, wireless connections, or a combination of wired and wireless connections. In some implementations, one or more devices of environment300may be physically integrated in, and/or may be physically attached to, one or more other devices of environment300.

User device305may include any computation and communication device that is capable of communicating with one or more networks (e.g., network320). For example, user device305may include a device that receives content, such as web pages (e.g., that include text content and/or image content), streaming audio and/or video content, and/or other content, via an Internet connection and/or via some other delivery technique. User device305may also receive user interactions (e.g., voice input, touches on a touchscreen, “clicks” via an input device such as a mouse, etc.). In some implementations, user device305may be or may include a radiotelephone, a personal communications system (“PCS”) terminal (e.g., a device that combines a cellular radiotelephone with data processing and data communications capabilities), a personal digital assistant (“PDA”) (e.g., a device that includes a radiotelephone, a pager, etc.), a smart phone, a laptop computer, a tablet computer, a camera, a television, a personal gaming system, a wearable device, and/or another type of computation and communication device.

ARC310may include one or more devices (e.g., a server device or a distributed set of devices, such as a cloud computing system) that perform one or more actions described herein. For example, ARC310may handle input from UE305by routing the input to a suitable agent315.

Agents315may include one or more devices (e.g., a server device or a distributed set of devices, such as a cloud computing system) that perform one or more actions described herein. For example, a particular agent315may include a set of intents, which may be used to process user input. A detailed example of an agent315, in accordance with some embodiments, is described below with respect toFIG. 4.

Network320may include one or more radio access networks (“RANs”), via which user device305may access one or more other networks or devices, a core network of a wireless telecommunications network, an IP-based packet data network (“PDN”), a wide area network (“WAN”) such as the Internet, a private enterprise network, and/or one or more other networks. In some implementations, network320may be, or include, a cellular network, such as a Long-Term Evolution (“LTE”) network, a Third Generation (“3G”) network, a Fourth Generation (“4G”) network, a Fifth Generation (“5G”) network, a Code Division Multiple Access (“CDMA”) network, etc. User device305may connect, via network320, to data servers, application servers, other user devices305, etc. Network320may be connected to one or more other networks, such as a public switched telephone network (“PSTN”), a public land mobile network (“PLMN”), and/or another network.

FIG. 4conceptually illustrates an example agent400. As shown, agent400may include input/output (“I/O”) component402, input routing component404, and one or more contexts406(e.g., contexts406-1through406-Z, which may be referred to herein individually as “context406” or in plural as “contexts406”). In some embodiments, agent400may include additional, fewer, different, and/or differently arranged components. One or more of the components discussed herein (e.g., with regard toFIG. 4) may include (and/or may be implemented via) hardware circuitry, which may include one or more processors executing processor-executable instructions to perform one or more actions described herein.

I/O component402may receive user input from one or more devices, and/or may output information to one or more devices. For example, I/O component402may receive user input from UE305, ARC310, and/or some other device or system, and may output information (e.g., text content, instructions for an application programming interface (“API”), hyperlinks, images, and/or other information specified by one or more intents410included in agent400) to UE305, ARC310, and/or some other device or system.

Input routing component404may receive user input (e.g., from I/O component402), and may determine which intent410should handle the user input. In some embodiments, input routing component404may evaluate the user input, as well as some or all of the context406associated with the same user as the user input. For instance, input routing component404may receive user input, which may include (e.g., as metadata, as header information, and/or as some sort of other identifier) an identifier of a particular user or of a particular user device. Additionally, contexts406may also include identifiers that map each context406to a given user or user device. Input routing component404may identify the matching context406for the user or user device associated with user input based on matching the identifier, associated with the user input, to the identifier associated with context406.

Context406may, generally, include information that can be used (e.g., by intents410) to maintain the status of an interaction with a given user or device. The information stored in context406may include, and/or may be derived from, user input (e.g., as received via I/O component402), information provided by one or more intents410, and/or one or more other sources.

As discussed herein, interactions are discussed in terms of interactions with a “user.” It is to be understood that when discussed herein, receiving input “from a user” may include receiving input from multiple different devices associated with that user. For instance, a user may provide first input via a first device (e.g., by speaking into a microphone of a “smart” watch), and then may subsequently provide second input via a second device (e.g., by selecting a button displayed in a GUI on a tablet computer). Thus, in these scenarios, the first and second inputs may be described herein as being received “from the user.”

In this sense, a particular context406may maintain information that should be used whenever input is received from one particular user, independent of a unique identifier of a device via which the input is received. Additionally, or alternatively, a particular context406may be associated with a particular device (e.g., may include a device identifier, such as an International Mobile Subscriber Identity (“IMSI”) value, International Mobile Station Equipment Identity (“IMEI”), media access control (“MAC”) address, and/or another type of device identifier), such that a given context406may be device-specific, rather than user-specific.

In some embodiments, some or all of the context406for a particular user may be stored by one or more devices in addition to, or in lieu of, agent400. For example, in some embodiments, context406may be stored by ARC310. ARC310may obtain the context by making calls to an API of agent400to request the context from agent400. In this manner, a current state of context406may be stored by ARC310, and may be able to be provided by ARC310to another device or system. For example, ARC310may receive context406for a user from a Master Agent, and may provide some or all of the context406for the user to an agent400that is determined, by ARC310, to handle subsequent interactions for the user.

FIG. 4further shows multiple conversations410, included in agent400. As discussed herein, a “conversation” refers to a set of intents410that are interrelated in a way that may be meaningful to a user that is engaging in an interaction with an NLP system (e.g., an NLP system that utilizes agent400). The concept of a “conversation” may, in some embodiments, not be explicitly stored or recognized by agent400. However, embodiments herein are described as conceptually including conversations, as this concept may aid in understanding of such embodiments. The dashed lines inFIG. 4reflect that, in some embodiments, “conversations” are not explicitly stored or acted upon by agent400(whereas intents410are stored and acted upon by agent400).

This interrelation may involve information in one410that refers to another intent410. Specifically, the intents410that make up a given conversation may interrelate, directly or indirectly, with each other by way of specifying that the input context415of a first intent410must include information that relates to a second intent410(e.g., an identifier of the second intent410). In some embodiments, the input context415of a given intent410specifies conditions, rules, and/or other types of information that can be used to determine whether the given intent410matches user input (e.g., as received via402) and the current context406for the user.

Thus, when selecting a suitable intent410to receive user input (e.g., as received via I/O component402), input routing component404may evaluate the user input and the context406to determine whether the user input and the current context406match the conditions specified in input context415for one or more intents410. For example, the user input “No” may be routed differently (e.g., to different intents410) based on the context406(e.g., one context406may indicate that the user was asked whether he or she would like to cancel a service, while another context406may indicate that the user was asked if he or she would like to purchase a particular product).

Output context420, for a particular intent410, may include instructions, conditions, etc., that indicate parameters that should be outputted by the particular intent410when the particular intent410handles user input. For example, output context420may include an identifier of intent410(e.g., to indicate that intent410has been involved in the interaction with the user), may include an instruction to erase some or all prior items (e.g., specific identifiers of data to erase, such as file names; regular expressions that can be pattern matched to determine text to delete; or types of data to erase, such as file or content types) stored in output context420, may include information (e.g., variables) to be used by other intents410, etc.

Actions425for a particular intent410may indicate actions that should be performed by intent410when intent410receives user input and context406. For example, actions425may include one or more API calls, performing a method or subroutine using some or all of the user input and/or context406, generating a response, modifying output context420, providing user output via I/O component402, etc.

While some embodiments do not utilize explicit information related to conversations,FIG. 5Aillustrates an example embodiment in which the concept of “conversations” is maintained within individual intents410. For example, intents410-1,410-2, and410-4are associated with Conversation_1, while intent410-3is associated with Conversation_2. Specifically, for instance, intent410-1may include an identifier of Conversation_1(shown inFIG. 5Aas “Conversation_1) in the input context415-1. Including identifiers of conversations may be useful to differentiate between intents that have similar input contexts415(e.g., similar or the same conditions specified in the input contexts), but have different output contexts420or actions425. For example, if a user input is the word “No,” and two different input contexts415of two different intents410include the condition that a user was asked if he or she would like to purchase a product, different conversations405may be used for different products (e.g., one conversation405may include subsequent intents415that relate to recommending cheaper products, while another conversation405may include subsequent intents415that relate to no longer asking if the user is interested in purchasing a product).

FIG. 5Aalso shows different context information505stored in input contexts415and output contexts420. The distinct numbering (e.g.,505-1,505-2, etc.) denotes distinct items stored within contexts415and/or420. For example, context information505-1may include a name of a given user (e.g., as provided via user input and/or determined from a user account, with the explicit consent of the user), while context information505-2may include a phrase previously spoken by the user while engaged in an NLP dialog.

Input contexts415, shown inFIG. 5A, also include a “Last intent” field. This field (or similar information) may be used to enforce the transition from one intent415to another, with a given set of user input. For example, input contexts415-1and415-2, in this figure, have the same context information items505-1,505-2,505-3, and505-4. However, input context415-1specifies a condition that the last intent was “Master,” while input context415-2a condition that the last intent was “Intent_1.” Thus, in this sense, the last intent410that handled previous user input may be a differentiating factor for determining which intent410should handle present user input. Output contexts420, shown inFIG. 5A, may also include (and/or may result from) rules specifying that intents410should specify themselves in the “Last intent” field.

Additionally, or alternatively, input routing component404may maintain state information that indicates which intents410have handled input for a particular user or context406, and may use such information when selecting an intent410to handle user input. For example,FIG. 5Billustrates a similar arrangement asFIG. 5A, but without information relating to conversations405stored in intents410(e.g., stored in input or output contexts415or420). Additionally, inFIG. 5B, output contexts420may not explicitly specify that intents410should modify a “Last intent” field. For example, as discussed above, input routing component404may maintain information indicating which intents410have handled user input for a particular user.

FIG. 6provides another representation of how a conversation with a user can be arranged (e.g., as a tree), as well as how this representation relates to the agents and intents described herein (e.g., as discussed above with respect toFIGS. 5A and 5B). The tree shown inFIG. 6may be a portion of a structured conversation “C1” that has root node “C1_R” as an entry point to the conversation. For example, C1_R may be reached when a user input matches a particular pattern (e.g., as specified in an input context for an intent410that is used to implement C1_R).

Once C1_R has been reached, it may be recognized and/or determined (e.g., by input routing component404of an agent400that implements C1_R) that the input context for the user should include an identifier of C1_R (e.g., as a “last intent,” and/or in a history or record of intents410that have been used in the conversation). Additionally, or alternatively, input routing component404may include information indicating that the last intent410in the conversation was a “Master” intent (e.g., a root node in a conversation). Input routing component404may include this information when a conversation state associated with the user indicates that a previous intent410has not been used in the conversation with the user.

Node C1_1_1may be a “next level” node in the tree (e.g., with respect to C1_R). As shown, an input context for C1_1_1may specify items505-1,505-2,505-3, and505-4, as well as a “Last intent” of “Master.” Referring, for example, toFIG. 5B, input context415-1of intent410-1also specifies these same parameters. In this manner, C1_1_1(inFIG. 6) may represent, or may be implemented by, intent410-1(inFIG. 5B).

Similarly, the “next level” nodes in the tree, with respect to C1_1_1, are C1_2_1and C1_2_2. As shown inFIG. 6, C1_2_1may share the same input context parameters as intent410-2inFIG. 5B. Thus, C1_2_1(inFIG. 6) may represent, or may be implemented by, intent410-2(inFIG. 5B). Similarly, C1_2_2(inFIG. 6) may represent, or may be implemented by, intent410-4(inFIG. 5B).

In some scenarios (e.g., provided the quantity of intents is below a maximum quantity for an agent), the conversation represented by the tree shown inFIG. 6may be implemented by a single agent, as shown inFIG. 2. However, some embodiments may adapt a “flat” agent structure (e.g., where an entire conversation is implemented by one agent) to a hierarchical structure, in order to realize the benefits (e.g., increased capacity for intents) of the hierarchical structure.

For example, as shown inFIG. 7, adapting the conversation (shown inFIG. 6) to the hierarchical structure may involve moving C1_R to a Master Agent (e.g., placing an intent410, which implements C1_R, in an agent400that is recognized by ARC310as a “top level” agent400), and moving the next level nodes into other agents (e.g., placing intents410, which implement the other nodes, in one or more agents400that are recognized by ARC310as “lower level” agents with respect to the “top level” agent400). The removal of the root of the tree (e.g., the conceptual removal of C1_R, inFIG. 7) may be considered to result in two trees, where C1_1_1is the root of one tree, and C1_1_2is the root of the other tree. In some embodiments, ARC310may enforce a restriction that the intents410that implement the tree, of which C1_1_1is the root, must be placed in the same agent400, and that the intents410that implement the tree, of which C1_1_2is the root, must be placed in the same agent400. In some scenarios, this may result in the intents410, that implement both trees, being placed in the same agent400. In other scenarios, this may result in the intents410, that implement both trees, being placed in two different agents400.

FIG. 8illustrates an example agent400, which may be designated (e.g., by ARC310) as a Master Agent. Four example intents are shown in this figure, where each of the intents may correspond to a root of a conversation (e.g., as discussed above with respect toFIGS. 6 and 7). Specifically, for example, “Intent_1,999” (inFIG. 8) may represent, or implement, C1_R (inFIGS. 6 and 7).

FIG. 9illustrates an example data structure900, which may include mapping information that can be used by ARC310to route user input to an appropriate agent (e.g., to continue an NLP interaction with a user). For example, ARC310may extract input context parameters from intents410, that implement nodes (e.g., referring to the example representation shown inFIGS. 7 and 8) that are next level nodes with respect to the roots of conversations.

For example, a particular intent410may specify a user input of “I want to look at my bill,” may specify that a “Last intent” should be “Intent_1,997,” and may have additional parameters505-1,505-3, and505-4specified in its input context415. This particular intent410may also be stored in a particular agent, out of a set of agents (e.g., agent400-1, in this example). ARC310may maintain this information in data structure900. For example, when adapting a “flat” agent structure to a hierarchical one (e.g., as mentioned above and as discussed in greater detail below with respect toFIG. 10), ARC310may analyze the input context415of the intents410that implement “next level” nodes (e.g., with respect to root nodes) of conversations to determine the information stored in data structure900.

FIG. 10illustrates an example process1000for adapting a “flat” agent structure to a hierarchical one, in accordance with some embodiments. In some embodiments, some or all of process1000may be performed by ARC310. In some embodiments, one or more other devices and/or systems may perform some or all of process1000in addition to, or in lieu of, ARC310.

As shown, process1000may include receiving (at1005) a specification of an agent. For example, ARC310may receive information, such as computer code, one or more extensible markup language (“XML”) documents, and/or some other form of information that specifies or defines an agent400, including one or more intents410(e.g., as similarly described above).

Process1000may also include analyzing (at1010) the agent to identify conversations, including identifying root nodes of the conversations. For example, in some embodiments, ARC310may identify conversations and their roots based on explicit information included in the intents410of agent400. In some embodiments, ARC310may construct one or more trees, which may be conceptually or actually similar to the tree shown inFIG. 7, based on an analysis of which intents410, of agent400, refer to other agents410. For instance, referring toFIG. 5B, ARC310may identify that Intent_2(i.e., intent410-2) is a “next level” node of Intent_1(i.e., intent410-1), because Intent_1is specified in the input context415-2of Intent_2. Further, a particular intent410may be recognized as a “root” if no other intents410are specified in the input context415of the particular intent410.

Process1000may additionally include placing (at1015) the identified root nodes into a master agent. For example, ARC310may store information that identifies a particular agent400as a master agent. ARC310may place the root node in the master agent by, for example, copying an intent410, that implements the root node, into the master agent (and/or generating a new intent410in the master agent with the some or all of the same parameters as the intent410that implements the root node).

Process1000may also include placing (at1020) sub-nodes (e.g., nodes that are of a lower level than the root nodes) into other agents. For example, ARC310may identify one or more other agents400that are used to store intents410that relate to nodes that are lower level than root nodes, and may copy, generate, and/or otherwise store information in the identified agent400that causes agent400to store intents410that implement the lower level nodes, including storing the input and output contexts415and420.

FIG. 11illustrates an example process1100for placing intents410into an agent400(e.g., according to block1020). For instance, as shown inFIG. 11, process1100may include determining (at1105) a capacity of a current agent400, in which intents410are being placed. For example, ARC310may determine a quantity of intents410that are currently used by in agent400, and compare the used quantity to a maximum quantity of intents410(e.g., 2,000 intents) that are supported by agent400. Additionally, or alternatively, agent400may store explicit information indicating a quantity of available intents410(e.g., if 1,200 intents are currently used by agent400, then the capacity may be 800 intents).

Process1100may also include determining (at1110) whether the available capacity of agent400exceeds a threshold. For example, ARC310may determine whether agent400has at least 300 intents available. In some embodiments, the threshold capacity may vary, based on the quantity of intents410to be copied to agent400. For example, if 200 intents410are to be copied to agent400, then the threshold capacity may be 500 (e.g., 200 intents with a cushion of 300 additional intents).

If agent400can support the additional intents410(at1110—YES), then ARC310may place the intents410into agent400. If, on the other hand, agent400cannot support the additional intents410(at1110—NO), then ARC310may place intents410into a new agent400(e.g., may create or instantiate a new agent400, and place intents410into the new agent400).

Returning toFIG. 10, process1000may further include storing (at1025) information mapping root nodes to agents in which the sub-nodes were placed. For example, ARC310may store the information in data structure900, discussed above with respect toFIG. 9. As mentioned above, this mapping information may be derived, at least in part, from intents410that implement “next level” nodes, that directly connect to root nodes in a conceptual conversation tree.

FIG. 12illustrates an example process1200for routing user input in accordance with some embodiments described herein. In some embodiments, some or all of process1200may be performed by ARC310. In some embodiments, one or more other devices and/or systems may perform some or all of process1200in addition to, or in lieu of, ARC310.

As shown, process1200may include receiving (at1205) user input. For example, ARC310may receive input from UE305, such as voice input, text input, selection of a GUI element, or the like.

Process1200may further include determining (at1210) whether a conversation is active for the user. For example, ARC310may determine whether user input has been received from the user before (e.g., prior to the input received at1205), which may generally relate to prior interactions in the same conversation. In some embodiments, ARC310may determine whether a flag or other indicator indicates that a conversation is active for the user (e.g., where unique identifiers may be used to differentiate between users).

FIG. 13illustrates an example data structure1300that may be used by ARC310to determine whether a conversation is active for a user, and which agent400is handling the conversation for which user. For example, in the example shown inFIG. 13, a conversation may be active for User_A, and agent400-1may be handling the conversation for User_A. As also shown, User_C may have previously had a conversation that was handled by agent400-3, but the current state of the conversation may be stored as not active in data structure1300(e.g., the conversation may have concluded).

Returning toFIG. 12, if a context is available (at1210—YES), then process1200may include identifying (at1215) an agent associated with the conversation. For example, the information referenced above (e.g., as also discussed with respect toFIG. 13) may indicate a particular agent400that is handling user input for the particular user. Process1200may further include providing (at1220) the user input to the identified agent, which may handle the input accordingly (e.g., perform one or more actions, such as providing a response to the user.

If, on the other hand, a conversation is not active for the user (at1210—NO), then process1200may include providing (at1225) the user input to an agent that has been designated as a Master Agent. Process1200may further include storing (at1230) information indicating that a conversation is active for the user. For example, ARC310may store, in data structure1300, the information indicating that the conversation is active, and may also indicate the agent to which should handle subsequent interactions in the conversation (e.g., which may be determined based on a response from the Master Agent, which may indicate which agent400should handle the subsequent interactions for the conversation).

After some time, and potentially with one or more other intervening acts (which may include a repeated occurrence of one or more of blocks1205-1230), ARC310may determine (at1235) that the conversation has ended. For example, ARC310may receive an explicit indication from UE305, the particular agent400handling the conversation, and/or from some other source, that the conversation has ended. Additionally, or alternatively, ARC310may automatically determine that the conversation has ended if no user input has been received for a threshold quantity of time (e.g., 5 minutes, 10 minutes, etc.).

ARC310may store (at1240) information indicating that the conversation is not active. For example, ARC310may modify an entry in data structure1300, for the user, indicating that a conversation is not active. Additionally, or alternatively, ARC310may remove the entry in data structure1300for the user.

In some embodiments, a “flat” agent may include one or more intents410that are related to “catch-all” conditions. For example, as shown inFIG. 14A, an agent may conceptually include nodes related to conversation C1(e.g., C1_R, C1_1_1, and C1_1_2), as well as nodes related to catch-all conversation Catch (e.g., Catch_R, Catch_1_1, and Catch_1_2). When adapting the flat agent to a hierarchical structure (e.g., according to process1000), ARC310may copy the entirety of the catch-all conversation to each agent400that is generated.

For example, as shown inFIG. 14B, while adapting conversation C1may involve three separate agents (e.g., a first agent400acting as a Master Agent to include C1_R, a second agent to include C1_1_1(and its sub-nodes), and a third agent to include C1_1_2(and its sub-nodes). As also shown inFIG. 14B, the entirety of the Catch conversation may be placed in each of these three agents. ARC310may identify an intent that is a root of a “catch-all” conversation by, for example, detecting that the set of the input conditions for a given intent has no input conditions, and may detect the other nodes of the catch-all conversation by identifying intents that refer back to the intent that implements the root node.

While the above embodiments are described in terms of one master node, other arrangements are possible in the hierarchical agent structure described herein. For example, as shown inFIG. 15, multiple master agents may be used (e.g., Primary master400-1, Secondary master400-2, and Tertiary master400-3). ARC310may maintain information that indicates that, for new conversations (e.g., when input is received from a user for whom a conversation is not active), the input should be first routed to Primary master400-1(e.g., at arrow1). If a “miss” occurs (e.g., if Primary master400-1is unable to match the input to any of the intents410of Primary master400-1), Primary master400-1may respond to ARC310that no intent410was able to be identified for the user input. ARC310may then, based on being notified that a miss occurred at Primary master400-1, provide the user input to Secondary master400-2(e.g., at arrow2). If a miss occurs at Secondary master400-2, ARC310may then provide the user input to Tertiary master400-3(e.g., at arrow3), and so on. As noted above, each master agent may link to a theoretical maximum of 4,000,000 intents (assuming that the maximum quantity of intents for each agent is 2,000). Thus, utilizing three master agents, as shown inFIG. 15, may allow for a capacity of 12,006,000 intents. Utilizing Q master agents in this way, where each agent supports P intents, would yield the ability to design an NLP system with (Q+1)*P intents.

In some embodiments, multiple levels of hierarchy may be used. For instance, referring to the example ofFIG. 7(and according to, for example, process1000), note that C1_1_1and C1_1_2are the roots of their respective trees after C1_R is removed. The same, or similar, process may be performed to place C1_1_1and C1_1_2into an agent that is subordinate to the master agent in which C1_R is placed, and to place the remaining next level nodes (e.g., C1_2_1, C1_2_2, C1_2_3, and C1_2_4) into one or more agents that are subordinate to the agent(s) in which C1_1_1and C1_1_2are placed.

FIG. 16illustrates example components of device1600. One or more of the devices described above may include one or more devices1600. Device1600may include bus1610, processor1620, memory1630, input component1640, output component1650, and communication interface1660. In another implementation, device1600may include additional, fewer, different, or differently arranged components.

Bus1610may include one or more communication paths that permit communication among the components of device1600. Processor1620may include a processor, microprocessor, or processing logic that may interpret and execute instructions. Memory1630may include any type of dynamic storage device that may store information and instructions for execution by processor1620, and/or any type of non-volatile storage device that may store information for use by processor1620.

Input component1640may include a mechanism that permits an operator to input information to device1600, such as a keyboard, a keypad, a button, a switch, etc. Output component1650may include a mechanism that outputs information to the operator, such as a display, a speaker, one or more light emitting diodes (“LEDs”), etc.

Communication interface1660may include any transceiver-like mechanism that enables device1600to communicate with other devices and/or systems. For example, communication interface1660may include an Ethernet interface, an optical interface, a coaxial interface, or the like. Communication interface1660may include a wireless communication device, such as an infrared (“IR”) receiver, a Bluetooth® radio, or the like. The wireless communication device may be coupled to an external device, such as a remote control, a wireless keyboard, a mobile telephone, etc. In some embodiments, device1600may include more than one communication interface1660. For instance, device1600may include an optical interface and an Ethernet interface.

Device1600may perform certain operations relating to one or more processes described above. Device1600may perform these operations in response to processor1620executing software instructions stored in a computer-readable medium, such as memory1630. A computer-readable medium may be defined as a non-transitory memory device. A memory device may include space within a single physical memory device or spread across multiple physical memory devices. The software instructions may be read into memory1630from another computer-readable medium or from another device. The software instructions stored in memory1630may cause processor1620to perform processes described herein. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

Some implementations are described herein in conjunction with thresholds. To the extent that the term “greater than” (or similar terms) is used herein to describe a relationship of a value to a threshold, it is to be understood that the term “greater than or equal to” (or similar terms) could be similarly contemplated, even if not explicitly stated. Similarly, to the extent that the term “less than” (or similar terms) is used herein to describe a relationship of a value to a threshold, it is to be understood that the term “less than or equal to” (or similar terms) could be similarly contemplated, even if not explicitly stated. Further, the term “satisfying,” when used in relation to a threshold, may refer to “being greater than a threshold,” “being greater than or equal to a threshold,” “being less than a threshold,” “being less than or equal to a threshold,” or other similar terms, depending on the appropriate context.