In the second project phase of Resolve's chatbot we needed the ability to determine what model to query as the user asks a question. I spoke vaguely about this in the last article I wrote about Resolve, or in the article where I spoke about callbacks to select model to be specifically - But the problem condensed is that Resolve have multiple products, and therefor needed no less than 3 machine learning models, while all these had one support interface.
This implies we'll need somehow the ability for the user to select which model to query as he is given support.In the screenshot below you can see how we solved the UI parts.
The basic idea is that we've got a
select drop-down list allowing the user to select what product he or she needs support for. This changes the actual model we're using as we're sending queries to the backend.
Notice, the above script is the only script needed to include, since it dynamically injects the chatbot script itself, without needing to explicitly link in this. You also need to change the
If you're creating similar types of chatbots yourself, you'll need to modify the URL, in addition to modifying the
<script src="https://your-cloudlet.us.ainiro.io/chatbot.js?v=16.10.1" async></script>
How it works
ainiroInitializeChatWindow function exists on the window object, and if it does, it will invoke this function as it's being created.
This function will then dynamically insert a
select drop-down list into the chatbot's primary container element, containing one
option element for each value in the above
ainiro_all_types list. The active model is tracked both in the session object and in the
ainiro_active_type variable. this might be redundant, and arguably a violation of the "single source of truth" principle, but I'll leave it an exercise to you to simplify it if you wish.
As the user changes the selected value of the
select element, the active model is changed, which again the chatbot's internals will query using the
getAiniroChatbotType function - Which is another global "sink" the chatbot will invoke if it exists every time it needs to determine the model in the backend to use.
All in all a pretty OK solution I would say for scenarios where you have one chatbot UI, but needs to dynamically determine which model to query on the backend parts of your solution.