Integration Options in Knowledge

Language Detection Overview

The Knowledge API and JS Client provide respectively an endpoint and a method, that allow you to detect the language of the user question. With this, you can then suggest which one of your Inbenta instances would be the best suited to provide results to this question. If you have only one instance, it becomes the best one.

Language detection at Inbenta only provides detection of language within your instances. If you have greater requirements, you may need to use another language detection systems among those available in the market.

Integration Options

There are several ways you can use the language detector functionality. The diagram below illustrate the two solutions more frequently used by Inbenta clients:

  • Option one (left, recommended by Inbenta), does the search first. Then, if it does not get results, it checks the languages of the user question. If the question is in the expected language, the flow proceeds with the "no results" process. 
  • Option two (right) checks the language of all incoming user questions, then decides to do the search or not, depending on the result.

There are two factors to consider when you decide to adopt one solution over the other:

  • the number of API requests (and thus the cost of the solution), and
  • the number of user questions that you receive in an unexpected language.

You must take into account that if you use the first option, all user question, including the ones in unexpected languages, are registered in the system as user questions.

The solution that perform less requests to the API, and thus is more cost effective, depends on the number of user questions that you receive that are in an unexpected language. This is why Inbenta recommends the first option: if you get very few of these questions, then the second option is very expensive for minimal gains. It only becomes cheaper if you typically receive roughly a third or more of your user questions in an unexpected language.