Restaurant Ranking and Recommendation Engine for Food Delivery Search

Restaurant Ranking and Recommendation Engine is an advanced machine-learning project that rebuilds the core of food-delivery search: given a user's area, cuisine craving and budget, return restaurants ranked by how well they match — and prove, with an offline evaluation protocol, that the ranking is genuinely better than the obvious baselines.

Most search UIs sort by a single number (rating or vote count), which systematically buries new and niche restaurants and rewards the already-famous. This project treats search as a learning-to-rank problem on a real dataset: the public Zomato Bengaluru restaurants dataset (51,717 restaurants, 17 attributes — ratings, votes, cuisines, cost for two, locality, online-order flags). A two-stage pipeline first generates candidates (hard filters plus content similarity), then scores them with a gradient-boosted ranker trained on engineered features: Bayesian-smoothed rating, vote credibility, cuisine and locality match, cost fit, and service flags. A hybrid content-based recommender (“more like this”) sits alongside, using TF-IDF vectors over cuisine and dish text.

The project's spine is its offline evaluation protocol: graded relevance labels are constructed per query context, the ranker is compared against rating-rank and popularity-rank baselines using Precision@10, NDCG@10, MAP and MRR, and a leave-one-locality-out split proves the model generalises rather than memorising famous neighbourhoods. The stack stays inside the JNTUH R22 toolset — Python, scikit-learn (ML lab, CS604PC), MySQL (CS407PC) and a Django demo app (CS409PC) — with the evaluation results also reported in Power BI (CS308PC). Four members own four modules: data and features, models, evaluation, and the demo application.

Food-delivery search in India is a ranking problem, but the rankings users actually get are one-dimensional. Sorting by rating ignores query intent and vote credibility; sorting by popularity entrenches already-famous restaurants and makes new or niche ones undiscoverable. Neither ordering can answer the user's real question — “which of these places best matches my cuisine, budget and area right now?” — and neither comes with evidence that it is better.

There is a need for a query-aware ranking engine built on real Indian restaurant data, which learns a scoring function over query-item features, offers content-based “more like this” recommendations, and — critically — is judged by a documented offline evaluation protocol with rank-aware metrics (Precision@10, NDCG@10, MAP, MRR) against honest baselines, including a generalisation test on unseen localities, so that every claim of improvement is a number in a table rather than a feeling.

Abstract

This project designs, builds and rigorously evaluates a restaurant ranking and recommendation engine for food-delivery search, using the public Zomato Bengaluru dataset of 51,717 restaurants. A two-stage architecture — candidate generation followed by a gradient-boosted learning-to-rank scorer — returns query-aware rankings for searches like “biryani under ₹600 in Indiranagar”. A hybrid content-based recommender handles the “more like this” path. The contribution the panel will be shown is the evaluation: graded relevance labels, four retrieval metrics, three baselines, and a leave-one-locality-out protocol that demonstrates the learned ranker outperforms rating- and popularity-only ordering on held-out localities.

Introduction

On food-delivery platforms, the search result list is the marketplace: merchants outside the first screen effectively do not exist. Yet the default ordering — raw rating or raw vote count — has well-known failure modes: a 4.5-star restaurant with 40 votes loses to a 4.4-star with 40,000 votes even when the query screams “quiet, new, affordable”. Learning to rank treats ordering as a supervised problem: learn a scoring function from query-item features that places the most contextually relevant items first, and measure success with rank-aware metrics rather than accuracy.

Existing System

• App search sorts by a single signal (rating, delivery time or popularity), ignoring the query's cuisine and budget intent.
• Rating-only ordering is exploitable and vote-biased; new restaurants are structurally invisible.
• Existing analyses of the Zomato Bengaluru dataset stop at exploratory charts of localities and cuisines.
• Limitations: no relevance definition, no baseline comparison, no generalisation check — charts that cannot say “this ordering is better, by this much”.

Proposed System

• Data layer: the Zomato CSV cleaned (mixed 4.1/5 rate formats, NEW/- ratings, comma-grouped costs, list-valued cuisines) into a MySQL catalogue with a derived feature store — Bayesian-smoothed rating, TF-IDF cuisine/dish vectors, locality statistics.
• Two-stage ranking: Stage 1 generates ~100 candidates per query via filters and content similarity; Stage 2 scores candidates with a gradient-boosted regressor trained on query-item features.
• Hybrid recommender: item-to-item content similarity for the “more like this” flow.
• Offline evaluation protocol: graded relevance labels from rating strength, vote credibility and budget fit within each query context; metrics Precision@10, NDCG@10, MAP, MRR; three baselines (rating rank, popularity rank, Bayesian rank); k-fold cross-validation over query groups plus leave-one-locality-out testing.
• Demo: a Django app with a search form, ranked results with per-item explanation chips, and an admin evaluation dashboard (metrics also charted in Power BI).

Feasibility Study

• Technical: 51,717 rows is small-data for scikit-learn — training takes seconds on a laptop; the stack (Python, MySQL, Django) is taught in R22 (CS604PC, CS407PC, CS409PC). The main engineering risk is label construction, addressed with a documented, reviewable protocol.
• Economic: ₹0 — public dataset, free tools, no cloud needed.
• Operational: the demo runs locally with a pre-loaded database; retraining is a single command, and the evaluation harness re-runs in under a minute for the viva.

In scope

• The public Zomato Bengaluru restaurants dataset (one snapshot; no scraping of live platforms, no login-protected data).
• Query model: locality × cuisine(s) × budget; ranked result lists and item-to-item recommendations.
• Feature engineering, gradient-boosted ranking model, three baselines, four retrieval metrics, two validation protocols.
• Django demo with explanation chips; Power BI report of evaluation results; pytest suite for data and metric code.

Out of scope (v1)

• Live platform integration, real user clicks, A/B testing or any online evaluation — this is an offline protocol by design.
• Delivery-time or rider-logistics ranking (no such fields exist in the dataset).
• Deep-learning rankers and embeddings beyond TF-IDF (listed as future work; the classic model keeps the viva explainable).
• User accounts, ordering, payments or review writing in the demo app.

The project follows CRISP-DM adapted to an academic two-stage scheme, wrapped in an incremental build: every phase ends with something runnable, and the evaluation harness exists from week 9 onward so the model is never judged by vibes.

Testing approach: unit tests for every cleaning rule and metric implementation (metrics verified against a hand-computed example); golden-query regression tests that pin the top-5 results for ten saved queries and fail the build if a model change silently reshuffles them; evaluation runs are scripted and versioned so the report's tables regenerate exactly.

The system is a classic two-stage retrieval architecture backed by a small catalogue database.

1. Data layer — the cleaned Zomato catalogue in MySQL plus derived feature tables (Bayesian rating, TF-IDF vectors, locality stats). A loader script rebuilds everything from the raw CSV deterministically.
2. Retrieval layer — Stage 1 narrows 51,717 restaurants to ~100 candidates per query using hard filters (locality, budget ceiling) and content similarity; Stage 2 scores candidates with the gradient-boosted ranker and orders them.
3. Serving layer — a Django app exposes the search form, renders ranked results with per-item explanation chips (which features pushed this restaurant up), and serves the item-to-item recommender.
4. Evaluation harness — offline scripts that build relevance labels, run all models and baselines, emit metric tables, and push results to the Power BI report.

flowchart TD
  U["User query<br/>locality · cuisine · budget"] --> CG["Stage 1: candidate generation<br/>filters + content similarity (top ~100)"]
  C[("MySQL catalogue & feature store<br/>51,717 restaurants")] --> CG
  C --> FS["Feature vectors<br/>Bayesian rating · TF-IDF · cost fit"]
  CG --> R["Stage 2: learning-to-rank<br/>gradient-boosted scorer"]
  FS --> R
  R --> X["Explainer<br/>top contributing features"]
  X --> O["Ranked results<br/>Django UI"]
  B["Baselines<br/>rating · popularity · Bayesian"] -.-> EV
  R -.-> EV["Offline evaluation harness<br/>P@10 · NDCG@10 · MAP · MRR"]
  EV --> PBI["Metric tables & Power BI report"]

Catalogue schema (core tables)

erDiagram
  RESTAURANT ||--o{ RESTAURANT_CUISINE : "has"
  CUISINE ||--o{ RESTAURANT_CUISINE : "tags"
  LOCALITY ||--o{ RESTAURANT : "contains"
  QUERY_LOG ||--o{ EVAL_RESULT : "is measured by"

  RESTAURANT {
    int id PK
    string name
    int locality_id FK
    decimal rating
    int votes
    decimal bays_rating
    int cost_for_two
    bool online_order
  }
  LOCALITY {
    int id PK
    string name
    int restaurant_count
  }
  CUISINE {
    int id PK
    string name
  }
  QUERY_LOG {
    int id PK
    int locality_id FK
    string cuisines
    int budget
  }
  EVAL_RESULT {
    int id PK
    int query_id FK
    string model_name
    decimal ndcg_at_10
    decimal precision_at_10
  }

The two-stage split is the point of the architecture: Stage 1 keeps latency and label construction tractable, and Stage 2 sees only plausible candidates, so the learned scorer spends its capacity on ordering, not filtering.

• Real interaction data — deploying the demo internally and collecting consented clicks to move from proxy labels to behavioural evaluation.
• Learning-to-rank libraries — comparing the gradient-boosted scorer against a listwise approach such as LambdaMART.
• Text embeddings — replacing TF-IDF with sentence embeddings for dish and review text to catch semantic cuisine matches.
• Multi-objective ranking — explicitly trading off relevance with promotion of new restaurants (fairness to cold-start items).
• Geo features — distance-decay and locality clustering once coordinates are joined, moving toward a map-first search UI.