Skip to content

CONCEPT Cited by 1 source

Retailer-partitioned index

Definition

A retailer-partitioned index is the post-decode mapping layer in a multi-tenant generative retrieval system: an index keyed by (retailer_id, SID) that maps a generated Semantic ID to available, attributed ad products for the current retailer's catalog only. It sits between the generative retrieval model's output (a list of SIDs) and the downstream ranker (which receives candidate products).

Quote (Source: sources/2026-06-02-instacart-from-scoring-to-spelling-rebuilding-ads-retrieval-at-instacart):

"Finally, these generated sequences are mapped against a retailer-partitioned index to retrieve a diverse variety of relevant, available ad products. … the generated SIDs are mapped back to active ad products via a specialized, highly efficient retailer-partitioned index, ensuring that only relevant, available, and correctly attributed ads are retrieved."

Why partitioning is required

Three constraints stack to make retailer-partitioning the right shape:

  1. Multi-retailer marketplace. Instacart hosts many retailers' catalogs. The generative retriever produces SIDs over the global codebook; only the products available at the current retailer should be candidates.
  2. Product availability changes per retailer. A product's SID is global (codebook-derived); whether the product is in stock / purchasable / advertised at a given retailer is a per-(retailer, product) property.
  3. Ad-attribution is per-retailer. Carrot Ads runs both Instacart's own ads and per-retailer ad businesses (see systems/instacart-carrot-ads); the partition ensures the correct attribution ledger is hit.

Architectural shape

Generative retriever output:
  beam_search(prompt) → [SID_1, SID_2, ..., SID_K]
                                │
                                ▼
              retailer-partitioned index lookup
              key:  (current_retailer_id, SID_i)
              value: list of (product_id, availability, ad_metadata)
                                │
                                ▼
              filter: in-stock + ad-eligible + attributable
                                │
                                ▼
              candidate set → downstream Carrot Ads ranker

The partition by retailer_id is the substrate property that ensures the catalog scope at retrieval matches the catalog scope at auction.

Why this is more than just a filter

A naive implementation could generate SIDs globally then filter to the retailer's catalog. This is functionally equivalent but operationally suboptimal:

  • Generated SIDs may not map to any product at this retailer — beam search effort wasted on out-of-catalog SIDs.
  • Beam diversity dilutes — if a beam mostly contains SIDs not in the retailer's catalog, the effective candidate count is smaller than the beam width suggests.

A retailer-partitioned index lets the system reason about the retailer-specific catalog at index-lookup time, while keeping the generative model itself catalog-agnostic.

Sibling architectures elsewhere on the wiki

Retailer-partitioned indexes are an instance of the broader per-tenant data isolation family applied to recsys retrieval. Other on-wiki instances at different altitudes:

Caveats

  • Index implementation (key-value store, in-memory hash, sharded service) not disclosed.
  • Update cadence (when product availability changes — does the index update in real-time?) not disclosed.
  • Cardinality envelope (number of products per (retailer, SID) bucket) not disclosed.
  • Cross-retailer SID popularity skew (whether SIDs that are popular at one retailer dominate the beam at another) not addressed.
  • The post calls the index "highly efficient" without benchmarking — the lookup cost vs scoring-retrieval cost not compared in the headline numbers (which already include the index-lookup cost in the −10–17% latency reduction).

Seen in

Last updated · 542 distilled / 1,571 read