Annotate Corpus Conversations for currentSpeechContext
To visualize a conversation for the Insights page, we use the GET conversation-node-summary API that calls an elastic search query to build a map. Using the currentSpeechContext lines as a ‘node’ allows us to process data into elastic search.
{"currentSpeechContext":"{\"id\":\"Welcome\",\"intent\":\"\",\"type\":\"Entry\"}","eventType":"state","session":"9f6f9e87-a626-46ac-82c3-3b51d8c6d4b0","speechState":"speaking","time":1653521542197085},
In order to get currentSpeechContext lines in the logs, we need to manually annotate the conversation corpus. This can be achieved by passing the variables in the corpus at each intent or node:
Note: Only conv_id
is required to get currentSpeechContext to show in the logs. The combination of all of these will create a unique conversation node that will be used in conversation-node-summary.
Variable Name | Required | Description | Example data | Default |
---|---|---|---|---|
conv_id | Yes | unique ID. Unique description of the position in the corpus. | This can be a node id as defined by the NLP system. Alternatively consider manually setting using a context variable to be human readable and allow you to distinguish various responses within a single node. | "not-provided" |
conv_type | No | Classification for a given node type. | "Terminal", "Entry", "Chit-Chat", "Conversation Management" |
|
conv_tag | No | User defined, more granular classification for a given node type. This is intended to be used in conjunction with 'type'. | Terminal nodes could have an "Escalation" tag or "Conversation End" tag. These values to be defined by each client. | "no-tag" |
conv_intent | No | The name of the highest confidence intent or other context information that determines conversation direction. | "Welcome"; "AnythingElse" etc. Any intent defined in corpus. |
|
conv_workspace_id | No | A string that uniquely identifies the corpus in use. | This can be human readable, but we recommend using a workspace id |
|
conv_dialog_turn_count | No | The number of conversation turns in the current interaction. |
|
|
Type Definitions
Type | Description |
---|---|
Entry | Very first node in conversation, usually a greeting. |
Terminal | Node that marks conversation as completed, could be a good-bye, escalation or similar node that does not need a follow-up by persona. This would be useful to identify conversations that are abandoned mid-path. |
Chit-Chat | Parts of conversation that mimic small-talk, usually would not have a clear goal and are more suited to keep user engaged. e.g. "How are you today?" |
Conversation Management | Nodes that ask for clarification from the user. Most common option here would be speech to text management "Could you repeat that?", "I did not understand" |
DialogFlowES
For each intent, add parameters:
DialogFlowCX
It can be implemented anywhere "Parameter Presets" are available.
Routes:
Entry Fulfillment:
Watson
Dialog Node:
Microsoft Azure Bot Service (Composer)
Use the “Set Properties” card type just before the DP response in your flow. In the “Property” field, input the annotation parameter with a “conversation.” prefix before the parameter name, e.g. conversation.conv_id. In the “Value” field, input the desired node name or type category, e.g. 1.0-welcome.