Slot Resolver strategy inference suggestions

This is really detailed, Andrew — and the generate_structured_value_action with confidence scoring is a clever workaround.

That said, a lot of what you're describing should be achievable with the right slot configuration today, and we'd love to understand more about what you're building end-to-end — it's a little hard to tell from the post alone exactly where the friction is. Would you be open to walking us through the specific use case?

• What does the object schema look like for the slots where inference is struggling?
• When you say mid-conversation changes aren't reliable — what does the user say, and what does the bot do in response?
• How many of your plugins are using the structured value workaround today?

That way we can best advise on whether there's a configuration path or a real gap here.

For choosing some options, there is a description and other fields that are useful in helping the bot and user choose the correct option. For example, I could have a list of options returned from an API like the following:

[
    {
        "name": "option 1",
        "id": 1234,
        "bu": "IT",
        "description": "Only for use by IT. There are other sites specifically for other BUs."
    },
    {
        "name": "option 2",
        "id": 12345,
        "bu": "Security",
        "description": "Only for use by Security. There are other sites specifically for other BUs."
    },
    {
        "name": "option 2",
        "id": 123456,
        "bu": "Marketing",
        "description": "Only for use by Marketing. There are other sites specifically for other BUs."
    }
]

If I pass this full object to a slot resolver, it will not be able to resolve properly as it is then an object, not a string, and fails to function properly. If I have it just be a string list of the names, it will work, but then the bu and description are completely lost an not able to be used to help make the decision. The id is also lost so I cannot get the id to be used in a further api call without making the same api call again.

In newer situations, I am doing the list of strings, but what this has resulted in is making the api to get the options twice. First in the slot resolver and second in the conversational process just so I am able to filter on the options to get the id. This causes the plugin to be slower, double the api calls, and a loss of the description and bu attributes in helping to make the decision. Therefore, it is preferred to have the slot be an object to reduce the number of api calls and plugin length.

For the proposed solution #2, the bot does show the selected value most of the time, but not 100% and changing the value to something else does not reliably work.

Proposed solution #3 and $4 are still applicable. 

To fully answer your questions:

1. Object schema is similar to the json shown above
2. If I say “I need help with XYZ”, the slot resolves to a long description of “user needs help with XYZ and had done abc made up troubleshooting steps”. I am sometimes shown this description before the ticket is created. If I say no, the description is just “I need help with XYZ”, it might change the value shown to the user to be that string, but the slot is still resolving to “user needs help with XYZ and had done abc made up troubleshooting steps”.
   1. Another issue could be decision trees. If a slot is inferred incorrectly to be “A”, more or less information may be collected via decision trees. If the conversational process doesn’t go back to where that slot was made mandatory, the request may be missing information, or have collected incorrect information.
3. I have around 4 where it was preferred to do this over the list of strings approach. They are high usage plugins however (onboarding / access requests).