Note: This article in copy is also present on authors other social media accounts as well.
When a query is put on a chatbot be it be chatGPT, copilot, or any other chatbot, the response is based on what query is being asked. Now chatGPT has proposed to use clever AI (see reference [1] below) which remembers users’ query history. That is it would remember whatever the user has asked the bot. And this should make the bot clever for sure.
But is this enough?
Let’s understand the headache of a user who needs to make chatbot aware of all its preferences, yes now that chatbot is intelligent with the memory of chats, but still, the user needs to introduce himself to the bot.
So, here we propose a method to make chatbots intelligent about the personal preferences of a user. The user accesses a lot of data on the internet, some data is in browsing history, other data in logs some data in cookies, caches, and more.
Where is a user all internet information stored on the client side? Why not do a client-side analysis for better results from chatbots?
Yes, this is called client-side filtering systems or sieves.
A similar work for information retrieval was done by Dey and Singh [2] for information retreival. This work is motivated by both [1] and [2].
Note, that the client-side filtering system just does not use the chat history with a chatbot, it also uses other information about the user, or about the browsing history of that hour, or maybe be browsing history of a day. If nothing of these the user wants to share with chatbots, then at least feedback from the user can be saved on the client side, and if allowed by the user be shared on the server to learn to improve algorithms.
In this way sending more information to the server of the chatbot. This should make the results more efficient. However, we need to perform experiments on this note on client-side filtering systems.
Other uses of client-side filtering systems for chatbots are as follows:
-We don’t need to tell everything about a user to chatbots, again all this depends on how much a user wants a chatbot to know about him. The user can optionally upload his details or allow access to cookies, or more as explained above.
-Once learned this can improve the results produced by chatbots depending on what the user wants. So, it all depends on the user.
-Again, the user can vary the flexibility to know its search logs, its browsing history, and read cookies, as and when needed.
-This can significantly improve results but this needs experimental proofs.
-User-side profiling can save a lot of server-side algorithmic issues and server-side processing, making it faster.
-User-side or client-side (as some may call it) profiling can save users’ private data to be uploaded on servers and hence save privacy concerns for users.
-Users can delete or add any specific information in a user-friendly way provided by settings in the chatbot, this needs to be implemented.
-Here, queries can also be enhanced by query expansion techniques, which can be based on popular query expansion techniques, such as Nayes Bayes, SVM, Information Gain, and so on.
–The user can also provide feedback to improve chatbot results, this way it would make chatbots more efficient and know users well.
-Feedback can be and should be provided by users as these chatbots are generative bots and are in the experimental stage now. May be points can be given to users for genuine and sincere feedback on results produced by the chatbots.
-Users should help with the feedback. With feedback one can perform supervised query expansions and without feedback unsupervised query expansions can be performed.
-Users can provide keywords of the expanded queries if not private data to the server so that chatbot owners can check algorithms in a way to help a wider goal and to improve for a much larger algorithm post-processing by chatbots.
Here is a brief overview of the things discussed in the article with a figure.

References
[2] Singh, S., & Dey, L. (2005). A rough-fuzzy document grading system for customized text information retrieval. Information processing & management, 41(2), 195–216.