Using ML for recommendations is a widespread practice in most food delivery services. However, it requires large user and restaurant datasets. There are a few datasets for related training like Yelp and Zomato. These datasets can not be used for our training because we work with Homechefs, predominantly new or ‘unknown’ chefs, without any publicly available data, such as what might be available for larger food chains like McDonald’s, Cheesecake Factory, etc. Also, our app is based on cultural aspects, and it is difficult to inculcate this value in a pre-trained model generated using potentially irrelevant features (such as restaurant convenience, distance, revenue cut, commissions, and advertisements). Developing a robust ML-based recommendation system would require extensive time frame of atleast a few months. Finally, inclusivity and home-like feeling is our motto, and large pre-trained models suffer from heavy bias.
A safer alternative to ML-based recommendation system is the review-based recommendation system. Our users provide ratings after their orders from different chefs, and we aggregate these reviews over all users and all dishes and provide overall rating for chefs. We give the users the flexibility to filter different cuisines, based on ratings, dietary restrictions, and order frequency. This method is also robust in early stages of our product because its data is more reliable (and sourced from our own users) and immune to biases and spikes (because one outlier does not overwhelm the process, and glitches are smoothened out during aggregation).
However, it is undoubted that ML-based solutions have more potential to offer more dynamic and customized recommendations. Our approach is to recommend users through review-based system in early stages, and use our collected data to train a Reinforcement Learning-based model. In the background, we can evaluate the performance of RL system to the review-based system, and once it surpasses the current performance, we can deploy the RL system for recommending users on the app.
The architecture of the RL system would be as follows:
- Training data: Data collected from our app, and history of user orders and feedbacks.
- Problem presentation: Like most of RL problems, our model will have a triad of (state, action, reward). State refers to accumulated current profiles of all chefs and users. Action refers to preferential mapping of users to different chefs. Reward is a weighted function of a binary value (whether the user orders from our recommendation), and rating given by user after order delivery. The epsilon value can be set based on user preference: picky eaters will have low epsilon (higher exploitation), while foodies will have more epsilon (higher exploration).
- Evaluation: Our model performance can be gauged by relative performance with review-based recommender, and by analysis of overall RL state rewards. We should actively monitor bias and model health through tools such as Truera as well.
- Implementation: Keras-RL can be used to quickly prototype the data flow. However, Pytorch is more efficient, fast, reliable, provides more customization and visualization and is industry-approved, and is the most plausible option for app-wide deployment.
