Two-Stage Fine-Tuning of Language Models for Hyperlocal Food Search

swiggy · E-commerce · 2024 · source Agentic: no · promotional bias: low · summary-only (no fetched source) · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Hyperlocal food search relevance

Swiggy needed better semantic retrieval for complex Indian food-search queries that combine cuisine, diet, time, preparation style, and regional intent under strict real-time latency constraints.

Constraints:

Food delivery is hyperlocal, with restaurants usually within about 5km.
The catalog spans hundreds of thousands of restaurants and millions of food items.
Real-time query embedding had a hard 100ms latency requirement.
The model had to run within CPU-based search infrastructure.
Training data used LLM augmentation but still required manual verification.

Architecture

Swiggy fine-tuned small embedding models in two stages. Stage 1 used TSDAE unsupervised domain adaptation on historical order-derived text. Stage 2 used supervised fine-tuning over manually curated and LLM-augmented query-item pairs, with Multiple Negatives training, to improve semantic food-search relevance while staying under the 100ms embedding latency target.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  historical_order_corpus["Historical order corpus"] --> tsdae_domain_adaptation["TSDAE domain adaptation"]
  base_sentence_embedding_model["Base sentence embedding model"] --> tsdae_domain_adaptation
  tsdae_domain_adaptation --> supervised_retrieval_fine_tuning["Supervised retrieval fine-tuning"]
  llm_metadata_augmentation["LLM metadata augmentation"] --> curated_query_item_pairs["Curated query-item pairs"]
  curated_query_item_pairs --> supervised_retrieval_fine_tuning
  supervised_retrieval_fine_tuning --> food_search_ranking_service["Food search ranking service"]

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Historical order corpus`	Provides successful query-item examples for domain adaptation.	`TSDAE domain adaptation`
`TSDAE domain adaptation`	Unsupervised fine-tunes the sentence model on Swiggy food-search text.	`Historical order corpus`, `Base sentence embedding model`, `Supervised retrieval fine-tuning`
`Base sentence embedding model`	Provides the starting model for food search embeddings.	`TSDAE domain adaptation`, `Supervised retrieval fine-tuning`
`LLM metadata augmentation`	Generates additional cuisine, ingredient, preparation, and time-slot metadata.	`Curated query-item pairs`
`Curated query-item pairs`	Supervised training data verified by humans.	`LLM metadata augmentation`, `Supervised retrieval fine-tuning`
`Supervised retrieval fine-tuning`	Optimizes the embedding model for query-item relevance.	`Base sentence embedding model`, `Curated query-item pairs`, `Food search ranking service`
`Food search ranking service`	Uses the fine-tuned model under real-time latency constraints.	`Supervised retrieval fine-tuning`

Data flow

Historical successful orders produce query-item-taxonomy text documents. TSDAE corrupts and reconstructs these texts to adapt the sentence model to food semantics. Then curated query-item pairs, augmented with cuisine/ingredient/preparation/time metadata, fine-tune the model for retrieval. At serving time, the model embeds user queries for real-time search.

3 supporting quotes

“first performing unsupervised domain adaptation using TSDAE on historical order data, followed by supervised fine-tuning with manually curated query-item pairs augmented by LLMs.”summary, stated

“These documents are constructed from successful order histories, combining the search query that led to the order with the purchased item name and metadata”summary, stated

“The second stage involves supervised fine-tuning using over 300,000 manually curated query-item pairs.”summary, stated

Why this architecture

Swiggy chose small fine-tuned embedding models because large LLMs could not meet real-time food-search latency and infrastructure constraints, while two-stage adaptation captured domain semantics from actual orders and curated examples.

“Swiggy set a hard requirement of 100 milliseconds for real-time query embedding generation to support their existing CPU-based search infrastructure”summary, stated

“The decision to use smaller models rather than larger LLMs for the core embedding task demonstrates a pragmatic production-oriented approach.”summary, stated

Models used: all-mpnet-base-v2 · all-MiniLM-L6-v2 · TSDAE · LLMs for metadata augmentation

Scale

Swiggy operates across hundreds of thousands of restaurants and millions of food items.
“operating across hundreds of thousands of restaurants and serving millions of food items.”summary, stated
Restaurant availability is roughly within 5km of the customer.
“where only restaurants within approximately 5km can serve a customer”summary, stated
Real-time embedding generation had a 100ms latency target.
“Swiggy set a hard requirement of 100 milliseconds for real-time query embedding generation”summary, stated
Stage 1 used approximately 996,000 historical text documents.
“unsupervised fine-tuning on approximately 996,000 historical text documents.”summary, stated
Stage 2 used over 300,000 curated query-item pairs.
“over 300,000 manually curated query-item pairs.”summary, stated

Alternatives considered (roads not taken)

Use larger LLMs for retrieval embeddings

Rejected because: They could not meet Swiggy's real-time latency and CPU infrastructure constraints.

“While larger models might offer better quality, the latency and infrastructure requirements would not be feasible for Swiggy's real-time search use case.”summary, stated

Use simple string matching

Rejected because: Complex queries require semantic understanding beyond dish-name matching.

“Unlike simple string-matching scenarios (e.g., searching for "pizza"), complex queries like "healthy snacks for office time"”summary, stated

Trust LLM-augmented training samples without review

Rejected because: All training samples were manually verified and edited.

“all training samples underwent manual verification and editing.”summary, stated

Patterns

`fine-tuning-adaptation` (search embeddings)

Swiggy adapted a sentence embedding model with unsupervised domain adaptation and supervised fine-tuning.

“The methodology employs a two-stage fine-tuning approach that separates domain adaptation from task-specific learning:”summary, stated

`synthetic-data-generation` (training data augmentation)

LLMs generated additional metadata used to construct diverse query templates.

“augmented it using large language models to generate additional metadata including regional cuisine, main ingredient, preparation style, and preferred consumption time slots.”summary, stated

`human-in-the-loop-gate` (data quality)

Humans verified and edited training samples produced with LLM augmentation.

“Importantly, the authors note that all training samples underwent manual verification and editing. This human-in-the-loop approach ensures data quality despite the use of LLMs for augmentation—a responsible practice that acknowledges LLM outputs require validation.”summary, stated

`latency-optimization` (real-time search)

Model choice was constrained by a 100ms query embedding target.

“A critical LLMOps consideration in this case study is the explicit attention to latency constraints. Swiggy set a hard requirement of 100 milliseconds for real-time query embedding generation to support their existing CPU-based search infrastructure and handle production traffic levels.”summary, stated

Tradeoffs

Use small language models for embeddings.

Chose all-mpnet-base-v2 / all-MiniLM-L6-v2 over Larger LLM embedding or reasoning models.

Rationale: Small models balanced semantic quality with 100ms production latency.

“They specifically selected "all-mpnet-base-v2" and "all-MiniLM-L6-v2" from the HuggingFace repository as baseline models, choosing these for their balance of semantic search performance and inference speed.”summary, stated

Separate domain adaptation from supervised retrieval training.

Chose TSDAE followed by curated query-item fine-tuning over One supervised training stage only.

Rationale: The first stage teaches food-domain relationships, while the second optimizes the search task.

“This stage serves as domain adaptation, helping the model understand food-related vocabulary and the relationships between different food items”summary, stated

Gotchas (what bit them)

Real-time search may require small models even when larger models are higher quality.

Root cause: Latency and CPU infrastructure constraints dominate production search.

Resolution: Fine-tune small embedding models for the domain.

“They specifically selected "all-mpnet-base-v2" and "all-MiniLM-L6-v2" from the HuggingFace repository as baseline models”summary, stated

LLM augmentation still needs manual quality gates.

Root cause: Generated metadata can introduce noisy or wrong training examples.

Resolution: Manually verify and edit all training samples.

Evaluation

Swiggy evaluated hyperlocal search using Mean Average Precision and Precision@5 across dense and sparse regions, plus qualitative examples of complex food queries.

Metrics: 100ms embedding latency constraint. · Approximately 996,000 historical documents. · Over 300,000 curated query-item pairs. · Mean Average Precision. · Precision@5.

“they achieved improved Mean Average Precision and Precision@5 metrics across both dense and sparse hyperlocal regions.”summary, stated

Outcomes

The fine-tuned model retrieved contextually relevant food items for complex queries.
The system improved MAP and Precision@5 in dense and sparse regions.
The feature was being tested with a small user cohort.

The feature targets a catalog across hundreds of thousands of restaurants and millions of items, with 100ms query embedding latency.

“successfully retrieves contextually relevant items for complex queries like "gym snacks" or "Karnataka famous sweets."”summary, stated

“The approach successfully retrieves contextually relevant items for complex queries like "gym snacks" or "Karnataka famous sweets." As of the publication, this feature was in experimental phase being tested with a small user cohort.”summary, stated