NLU Performance Statistics Source

gustavocami
Tera Contributor

Hello, dear colleagues!

 

I was searching for the source of the statistics displayed on the NLU Model Performance for Virtual Agent

bars (screenshot attached to this post), but I couldn't find it. I need to replicate that data on a dashboard. 

 

Does anybody know the table/Indicator name that produces those statistics?

 

 

 
 

 

2 REPLIES 2

pr8172510
Giga Guru

Hi @gustavocami,

These NLU performance stats are not coming from a single direct table, which is why it’s hard to find them straight away.

They are mainly derived from Virtual Agent conversation data, specifically:

  • sys_cs_conversation
  • sys_cs_conversation_turn
  • sys_cs_intent / sys_cs_intent_match (depending on version)
  • NLU prediction + user confirmation data stored during VA interactions

The key part is the user confirmation step (correct / incorrect / no response), which gets captured as part of the conversation turns and is then aggregated for this report.

For dashboard replication, what you can do is:

  1. Start with sys_cs_conversation_turn
  2. Filter on:
    • NLU prediction events
    • Confirmation responses (Yes/No/No input)
  3. Build indicators like:
    • Confirmed correct
    • Confirmed incorrect
    • No confirmation

Note: The UI you’re seeing is powered by internal aggregation (not a ready-made PA indicator), so you’ll need to recreate the logic using conditions on these tables.

If you're using Performance Analytics, you can create scripted indicators based on these conditions.

Hello, @pr8172510 

These tables that you provided don't exist (except for the sys_cs_conversation). I recommend that you read the Virtual Agent documentation to know more about the main table names.  Here is the link https://www.servicenow.com/docs/r/washingtondc/servicenow-platform/virtual-agent/configure-virtual-a...


Non-existing tables:

  • sys_cs_conversation_turn
  • sys_cs_intent / sys_cs_intent_match

Furthermore, the filter logic of virtual agent tables doesn't work as straightforwardly as you said; it has complex field values, similar to payload structures, and with lots of related tables, therefore, your "solution" wouldn't help so much.

If you can bring me something meaningful, I'd appreciate it.