Optimization tips

• How do sentiment models work?
• Dashboard
  • Create a sentiment model
  • Add an example sentiment model
• Sentiment Models
  • Multiwords
  • Settings
  • Build/Test a model
  • Import/Export a model
  • Using a model
• Entries
  • Subentries
  • Advanced settings
• Fine tuning
  • Checking your results
  • Optimization tips

There are some scenarios you may come accross when defining your sentiment model where the results obtained are not exactly what you expected. This are some of the things you can check out:

• Multiwords defined in your model

  The definition of multiwords is a key part of the model definition, as their grouping defines how the entries are going to be evaluated. For instance, if you have the following scenario:

  • An entry for "wifi"
  • An entry for "have" with a subentry for the cases when it appears with "wifi connection"

  In this case, for the sentence "The wifi connection is great" the sentiment behavior associated to "wifi" will not apply as the multiword "wifi connection" is detected first.

  The same thing happens with other multiwords. If you have defined an entry for "free wifi", and another one for "wifi connection", in the sentence "They do not have free wifi connection", the first multiword found is "free wifi", and so the entry for "wifi connection" will not apply.

  A good practice is always to review the multiwords defined for a model, checking those than can clash with other entries.

• Sentiment behavior inherited from the base model

  Much the same way as in the previous point, there may be an issue with the sentiment behavior defined in the base model associated to your sentiment model. You will be able to identify these cases through the polarity_terms detected in the output.

  In this case there are two possible ways to approach this:

  • Manually overwriting the sentiment behavior
  • Erasing the sentiment behavior

  The first approach is very simple: it just involves creating an entry/subentry with the same definition as the inherited behavior you don't want and then changing it to the value needed. For instance, if you do not want "happy" to be positive, you could create an entry for "happy" in your model with entry type polarity and value NONE, and that's the sentiment behavior that would be taken into account in your analysis.

  The second approach also involves creating an entry for the word or multiword that's causing the issue, but in this case, instead of assigning it a sentiment behavior, you'd have to enable the field dismiss base model entries (from the advanced settings section) to dismiss all the sentiment behaviors of the entry in the base model inherited. This way, the sentiment behavior inherited will be ignored and the one from your model will be used.

  The second approach may affect more than one sentiment behavior from the inherited model, so we always recommed to start with the first approach.