How to design the model?

[xbrtll]

Or more specifically: what trade-offs are there to consider?

Hi there! As a minimal examples to illustrate my questions:

1. Are two intents "lightsOn" (expression: "turn lights on") and "lightsOff" (expression: "turn lights off") cheaper in terms of performance than one intent "switchLight" with expression "turn lights $state:state" with slot "state" having the elements "on" and "off"?

2. How about the equivalent, but less intuitive option of a single intent "switchLight" with expressions "$dummy:on lights on" and "$dummy:off lights of" with the slot "dummy" having just the one element "turn"? This is admittedly a bad example, but I think the general idea to just have an expression put a dummy value into a specifically named slot could come in handy sometimes - unless it's always better to create a separate intent for some reason...

3. Is it helpful to define sort of sub-slots (e.g. have a slot with all the days and a separate one with just the workdays) and use the more specific one where the other options are not valid? Or just put the general slot and filter the invalid results later, in your application, to avoid cluttering the model?

4. Do I put everything into a single model or does it make sense to have multiple smaller models and just let Rhino listen for the one that is expected/allowed in the current situation? If neither performance nor colliding expressions are an issue, a single model might be easier to have, but its a bit hard to manage in the console because you cannot re-order elements (at least not as far as I have seen).

And while I'm here, a question regarding licensing: what do you mean by # Voice Interactions (per month): 1000 on the pricing page? And can I at least switch between devices as I am allowed just one? Or would it even be acceptable to run the software on multiple computers as long as they are all my machines, located in different rooms of my home? (might be easier than having to send the data from all microphones to a single instance)

[kenarsa]

1- In terms of accuracy or runtime this specific example doesn't make a difference. You can have one intent with a slot for state or two separate intents. It is really about how much typing you want to save in this specific case.
2- I wouldn't do the dummy slot.
3- If you are going to accuracy definitely define specific slots that each value is valid. this is you taking advantage of the context of your application/use case
4- this is more like an art. When do you break a function into multiple ones? You need to decide based on the situation and also your own personal preference.

Every command inference counts as voice interaction. Device refers to a physical machine you deploy the software to.

hope it helps!

[xbrtll]

Thank you for your answers! I'll think about them some more when extending the model.

Just one follow up: does this mean that I have to track all inferences myself and stop at 1000 if I'm being strict about the licensing terms?

[xbrtll]

Sorry to bother you about this again, but as you suggested to avoid dummy slots (which save separate intents in some cases) and and define specific slots instead of more generic ones (which increases the number of slots): I just noticed that both the intents and the slots are limited to 20. It came a bit as a suprise to me, as the FAQ page states that "There is no technical limit on the number of commands (expressions) or slot values Rhino can understand.". Is that another limitation of the personal account then or in fact a general limit of the Rhino engine?

The possibility to import larger yaml files suggests the former, but I could not find this mentioned anywhere. And if so, are there any plans on offering "affordable" licences for personal use that are not subject to these limitations?

[kenarsa]

Hey - happy to help out. We will look into the limits. In the meantime can you please export the YAML version of context and share with me? I'll see if there are some tips we can pass to you based on that in the meanwhile.

[xbrtll]

Thanks for your offer! The link is https://github.com/xbrtll/smarthome/blob/master/src/main/resources/Lighting.yml, I think you still have access to it. (Side note: this is the file I created the model from; the exported version is a bit inconsistent in using quotation marks around the individual expressions, but that does not seem to matter when importing.)

After a bit of restructuring, I'm back down at 19 intents. Probably 16 could work by using a slot like "lightProperty: color, brightness, temperature" to unify the light-related intents. Maybe 15 with sort of messy options like putting mediaInfo (where no expression uses slots) into mediaFlow (where all expressions use a slot) so you can distinguish them later.

I don't think much more can be saved while preserving at least most of the alternative commands, but maybe you can surprise me. 😉