If a word I am saying appears incorrectly recognised (e.g. I said 'Close' but the text in the utterance shows as 'Lows') the guidance seems to imply that I should correct the text then validate. Is that correct? But if it consistently becomes misinterpreted, is it ok to add the incorrect word to the list of keywords for the entity?
How can you add context to the interpretation of utterances? I'm specifically thinking of ones that might be using the same words but have different meanings (or 'intents').
For example "Let's play ball" - assigned to the scene_load intent, with 'ball' as the entity which has the Role of scene_name and resolves to 'basketball' (the Unity scene name)
However, in the same app, if I want to detect "Pass me the ball" but mapped to another response (e.g. npc_command) with 'ball' this time being an entity with the Role of object_name, or even "Let's play ball" uttered in this new scene but this time needing to trigger a different intent (perhaps npc_command with the entity resolving to approach_player)
Hope that makes sense! Any thoughts on how best to approach this?
Some of my older Wit.Ai applications have 'live utterances' i.e. audio recordings in the Understanding section that need that need to be listened to and confirmed before they can be trained.
I've a few questions about this:
1. Why does my current app not do this? Is it because it is set to public whereas the others are private? If mnot, why not? (has it been disabled recently? Is there a setting that needs to be set?)
2. What does making an app public actually mean?
3. Are there not some serious privacy implications at being able to replay the actual audio from a user's run through your app? In my initial tests when I was still learning about how to properly sign post that the mic was activated, I was getting recordings of people talking in their home without them really knowing this was happening. Seems to me that there should be some very clear guidance to developers that they need to make this explicit to players. The generic "Do you allow this app to have access to your Mic" app manifest warning doesn't quite seem to cover this.