Skip to content

SYSTEM Cited by 1 source

Instacart Shopping Hub

Shopping Hub is the primary discovery surface inside the Instacart app — the page a customer lands on after selecting a retailer, "guiding them along their entire journey". The page is composed of stacked placements; each placement is a themed group of products (canonical example in the 2026-02-26 post: "Dairy"). Placements can also contain other entities beyond products.

Why the surface matters

From the 2026-02-26 post (Source: sources/2026-02-26-instacart-our-early-journey-to-transform-discovery-recommendations-with-llms):

"What users see here shapes not just what they buy, but how intuitive and enjoyable their experience feels."

Shopping Hub is the surface Instacart runs "dozens of Shopping Hub experiments per year" against — the primary testbed for discovery + recommendations research.

Legacy architecture (pre-LLM)

Three-stage pipeline:

  1. Placement definition — text + visual assets + retrieval sources defined explicitly by humans. Titles are generic ("Dairy"); retrieval sources are narrow. Each placement joins a static content library, served universally across all users.
  2. Runtime retrieval — fetches candidate placements + their products.
  3. Ranking — existing ranking models order products + placements on the page against a static set of business metrics. Each placement is treated as an independent entity within ranking.

Stated limitations of the legacy architecture (post's own words):

  • Difficulty scaling personalized content — the human-driven placement creation is expensive + time-intensive; QA is manual; content libraries can't be rapidly personalised per user, per season, or per shifting business objective.
  • Lack of cohesion — placements are created by different siloed teams with divergent focus areas; the series of placements presents as "a chaotic surface presentation"; users have to scroll without easy navigation.

New architecture — generative content pipeline

The 2026-02-26 post announces a rebuild on a new generative AI content platform. Four-phase cascade (see patterns/top-down-cascaded-page-generation):

  1. Page design & theme generation — LLM page-design agent emits ordered themed placements personalised to the user.
  2. Retrieval keyword generation — teacher–student fine-tuned LLM maps each theme to retrieval-compatible descriptors; RAG candidate pruning cuts context 15–20% per generation.
  3. Quality & diversity filtering — embedding-similarity deduplication + LLM-as-judge + fine-tuned DeBERTa cross-encoder (>99% cheaper than LLM inference).
  4. Product & pagewise ranking — existing mature ranking infra, unchanged. Cached Phase-3 outputs are consumed by the existing ranking services.

Key architectural stance: the generative component is decoupled from the existing ranking stack. "This design modularizes the system, decoupling generative retrieval from mature ranking systems and providing a path to deeper pagewise control as the generative component matures."

North-star objectives for the rebuild

Named in the 2026-02-26 post:

  • Delightful personalization — rich, different-products-for-same-intent retrieval per user. Example: thematic "Breakfast" placement prioritises waffles + pancakes for one user, granola + yogurt for another.
  • Cohesion — every placement intentionally grouped + ordered + aware of others around it.
  • Adaptability — responsive to shifting business environment (relevance vs novelty weightings, seasonal placements spun up + phased out dynamically).

Seen in

Caveats

  • "Early journey." Architecture disclosed, production A/B outcomes not.
  • Phase 4's ranking infra is referenced but not architected in the post.
  • Relationship to the Intent Engine — the same user's queries hit Intent Engine, while their browsing lands on Shopping Hub — is not explicitly diagrammed.
Last updated · 319 distilled / 1,201 read