Papers
Topics
Authors
Recent
Search
2000 character limit reached

OneRetrieval: Editable Generative E-commerce Search

Updated 5 July 2026
  • OneRetrieval is a unified generative retrieval framework that replaces fragmented multi-branch systems with a single, editable model using Keyword-Aligned Encoding.
  • It converts item text into interpretable structured identifiers, allowing real-time updates through reserved slots without retraining.
  • The framework employs a four-stage fine-tuning pipeline and information-theoretic codebook construction to achieve deep-recall parity and operational robustness.

OneRetrieval most commonly denotes a production-scale generative retrieval framework for e-commerce search that replaces a hand-merged multi-branch retrieval stage with a single model while preserving a property that conventional generative retrieval had largely lacked: real-time editability. In the Kuaishou system described in “OneRetrieval: Unifying Multi-Branch E-commerce Retrieval with an Editable Generative Model,” retrieval is cast as autoregressive generation of structured identifiers, but those identifiers are no longer opaque quantization codes or unconstrained free-form strings. Instead, they are built through Keyword-Aligned Encoding, which ties each identifier position to an interpretable attribute word and supports post-deployment binding of new words to reserved code slots without retraining (Zhang et al., 11 Jun 2026). In a broader research sense, the term also names a design objective pursued across recent retrieval work: collapsing heterogeneous retrieval branches, retrieval-generation loops, or separate query-encoding subsystems into a single coordinated retrieval layer (Zhang et al., 2024, Sun et al., 2024, Jiang, 9 Mar 2026, Baek et al., 28 May 2026).

1. Industrial setting and the unification problem

In the Kuaishou deployment setting, the retrieval stage serves hundreds of millions of items through multiple parallel branches, including a sparse inverted-index branch, dense-vector branches, and collaborative branches such as itemCF, SASRec, and SIM (Zhang et al., 11 Jun 2026). These branches are trained independently and merged by hand-tuned rules rather than joint optimization. This creates a fragmented retrieval stack with uneven interpretability and substantial maintenance overhead.

A central observation in the paper is that the inverted-index branch persists despite lower conversion than the platform average because it is almost the only branch that operations can edit in real time. A new term can be injected by updating synonym or tag dictionaries and incrementally rebuilding the index, and the change takes effect within hours without model retraining (Zhang et al., 11 Jun 2026). This makes editability, rather than pure retrieval accuracy, a hard production requirement.

Existing generative retrieval methods did not satisfy that requirement. Closed-codebook approaches such as DSI, TIGER, LC-Rec, OneRec, and OneSearch fix identifier slots to quantized embeddings at training time, while open-vocabulary approaches such as SEAL, GLEN, GenR-PO, GRAM, and LTRGR leave routing of new terms to model generalization (Zhang et al., 11 Jun 2026). This suggests that replacing a multi-branch system with a single generative retriever is gated not only by recall quality but by whether the identifier space itself is operationally editable.

The paper formalizes retrieval in terms of a structured identifier, or SID, si=(si(1),,si(L))\mathbf{s}_i = (s_i^{(1)}, \dots, s_i^{(L)}), assigned to each item, and a policy

πθ(sq,cu)==1Lπθ(s()s(<),q,cu),\pi_\theta(\mathbf{s} \mid q, \mathbf{c}_u) = \prod_{\ell=1}^{L} \pi_\theta\bigl(s^{(\ell)} \mid s^{(<\ell)}, q, \mathbf{c}_u\bigr),

where qq is the query and cu\mathbf{c}_u is user context. Candidate generation is then expressed as

R(q,cu)=T ⁣(TopKsπθ(sq,cu)),\mathcal{R}(q, \mathbf{c}_u) = \mathcal{T}\!\Big( \operatorname*{TopK}_{\mathbf{s}} \pi_\theta(\mathbf{s} \mid q, \mathbf{c}_u) \Big),

with T\mathcal{T} mapping each generated SID to the set of items bearing that SID (Zhang et al., 11 Jun 2026).

2. Keyword-Aligned Encoding and the editable identifier space

The defining mechanism of OneRetrieval is Keyword-Aligned Encoding, or KAE. Rather than deriving item identifiers from quantized dense vectors, KAE ties each SID position to a key attribute word drawn from an internal attribute dictionary containing about 1.08×1061.08 \times 10^6 attribute words (Zhang et al., 11 Jun 2026). These words are typed into 18 attribute categories, which are later merged into six codebook groups.

For an item or query, the system applies deterministic dictionary matching with Aho–Corasick over text such as title, structured fields, detail-page text, OCR, or the query string itself. For each merged group \ell, it selects a representative attribute word using LLM-derived primary-subject precedence and behavioral importance, then maps that word to a code in the corresponding per-position codebook (Zhang et al., 11 Jun 2026). The resulting SID has fixed length L=6L = 6 in the main deployed configuration.

This makes the identifier space interpretable in a way that conventional generative retrieval codebooks are not. A position corresponds to an attribute group, and a slot corresponds to a specific attribute word or cluster of words. The paper explicitly frames this as the basis for targeted interventions: operations can reason about which code corresponds to which word, update the dictionary, and redirect routing without modifying model weights (Zhang et al., 11 Jun 2026).

This design differs sharply from closed-codebook methods, where each slot is bound to a quantized embedding, and from open-vocabulary methods, where new-term routing depends on unconstrained generation. A plausible implication is that OneRetrieval shifts the locus of control from latent embedding geometry to a semi-symbolic SID alphabet whose semantics are externally inspectable and incrementally mutable.

3. Information-theoretic codebook construction and reserved slots

The six-position SID is not chosen arbitrarily. OneRetrieval begins from 18 attribute categories and merges them into six groups using an information-theoretic criterion. For binary random variables XX and πθ(sq,cu)==1Lπθ(s()s(<),q,cu),\pi_\theta(\mathbf{s} \mid q, \mathbf{c}_u) = \prod_{\ell=1}^{L} \pi_\theta\bigl(s^{(\ell)} \mid s^{(<\ell)}, q, \mathbf{c}_u\bigr),0 indicating the presence of categories on items, the information loss of merging them is defined as

πθ(sq,cu)==1Lπθ(s()s(<),q,cu),\pi_\theta(\mathbf{s} \mid q, \mathbf{c}_u) = \prod_{\ell=1}^{L} \pi_\theta\bigl(s^{(\ell)} \mid s^{(<\ell)}, q, \mathbf{c}_u\bigr),1

Cluster-to-cluster distance is then the average πθ(sq,cu)==1Lπθ(s()s(<),q,cu),\pi_\theta(\mathbf{s} \mid q, \mathbf{c}_u) = \prod_{\ell=1}^{L} \pi_\theta\bigl(s^{(\ell)} \mid s^{(<\ell)}, q, \mathbf{c}_u\bigr),2 across category pairs, and agglomerative clustering is used to merge categories. The entity category is kept as a singleton, and the cumulative information-loss curve yields a knee at six groups, denoted ECOM6 (Zhang et al., 11 Jun 2026).

Capacity is then allocated non-uniformly because attribute densities vary strongly across groups. In the best trade-off configuration, three dense positions receive 2048 slots and three sparser positions receive 1024, for a total of 9216 core slots. The paper denotes this configuration L6-D3 and reports that it is nearly as strong as larger-capacity alternatives while keeping generation cost lower (Zhang et al., 11 Jun 2026).

Each per-position codebook has four blocks: an empty slot, cluster slots for tail words, solo slots for high-frequency words, and reserved slots. The reserved block contains πθ(sq,cu)==1Lπθ(s()s(<),q,cu),\pi_\theta(\mathbf{s} \mid q, \mathbf{c}_u) = \prod_{\ell=1}^{L} \pi_\theta\bigl(s^{(\ell)} \mid s^{(<\ell)}, q, \mathbf{c}_u\bigr),3 slots per position, for 60 reserved slots in total, and these slots are not bound to words during training (Zhang et al., 11 Jun 2026). Their role is purely post-deployment.

The reserved-slot mechanism is the system’s main editability primitive. To inject a new term, operations assign it to an attribute group, choose an unused reserved slot in that group, update the dictionary so the term maps to that slot, and update the SID-to-item index so relevant items are encoded with the same slot (Zhang et al., 11 Jun 2026). Because the model is trained to preserve reserved-slot identity in Stage 3, these codes remain generatable and routable after deployment.

The paper evaluates editability with two metrics. IHR@K measures whether a fabricated intervention target is retrieved within top πθ(sq,cu)==1Lπθ(s()s(<),q,cu),\pi_\theta(\mathbf{s} \mid q, \mathbf{c}_u) = \prod_{\ell=1}^{L} \pi_\theta\bigl(s^{(\ell)} \mid s^{(<\ell)}, q, \mathbf{c}_u\bigr),4, while IAR@K measures whether the injected attribute word’s code is activated in at least one of the top-πθ(sq,cu)==1Lπθ(s()s(<),q,cu),\pi_\theta(\mathbf{s} \mid q, \mathbf{c}_u) = \prod_{\ell=1}^{L} \pi_\theta\bigl(s^{(\ell)} \mid s^{(<\ell)}, q, \mathbf{c}_u\bigr),5 retrieved SIDs (Zhang et al., 11 Jun 2026). Against quantized generative baselines, KAE achieves total IHR@350 = 0.0806, whereas RQ-VAE, RQ-kmeans, and RQ-OPQ are around 0.0021–0.0030 (Zhang et al., 11 Jun 2026). Against BM25, OneRetrieval reaches IAR@350 = 0.5530 versus 0.7610 for BM25, while substantially exceeding BM25 in retrieval quality (Zhang et al., 11 Jun 2026).

4. Four-stage fine-tuning pipeline

The OneRetrieval model uses BART-base with an extended vocabulary containing SID tokens, and it is trained with a four-stage fine-tuning pipeline designed to jointly secure retrieval quality and editability (Zhang et al., 11 Jun 2026). The stages are distinct in purpose rather than interchangeable.

Stage Purpose Representative supervision
Stage 0 Attribute–SID alignment attribute word/category πθ(sq,cu)==1Lπθ(s()s(<),q,cu),\pi_\theta(\mathbf{s} \mid q, \mathbf{c}_u) = \prod_{\ell=1}^{L} \pi_\theta\bigl(s^{(\ell)} \mid s^{(<\ell)}, q, \mathbf{c}_u\bigr),6 SID token
Stage 1 Content alignment query/title/category πθ(sq,cu)==1Lπθ(s()s(<),q,cu),\pi_\theta(\mathbf{s} \mid q, \mathbf{c}_u) = \prod_{\ell=1}^{L} \pi_\theta\bigl(s^{(\ell)} \mid s^{(<\ell)}, q, \mathbf{c}_u\bigr),7 SID
Stage 2 Co-occurrence alignment query SID πθ(sq,cu)==1Lπθ(s()s(<),q,cu),\pi_\theta(\mathbf{s} \mid q, \mathbf{c}_u) = \prod_{\ell=1}^{L} \pi_\theta\bigl(s^{(\ell)} \mid s^{(<\ell)}, q, \mathbf{c}_u\bigr),8 item SID
Stage 3 Personalized retrieval and reserved-slot routing πθ(sq,cu)==1Lπθ(s()s(<),q,cu),\pi_\theta(\mathbf{s} \mid q, \mathbf{c}_u) = \prod_{\ell=1}^{L} \pi_\theta\bigl(s^{(\ell)} \mid s^{(<\ell)}, q, \mathbf{c}_u\bigr),9

Stage 0 teaches the model explicit slot semantics. Prompts such as “Attribute word is <attr>, category <cate>, id is:” map attribute words and categories to SID tokens, and inverse prompts map SID tokens back to words or categories (Zhang et al., 11 Jun 2026). This stage mainly supports editability rather than raw recall.

Stage 1 aligns surface content with SIDs using query–SID, title–SID, and category-prediction tasks. The paper’s ablation indicates that removing Stage 1 worsens HR@350, making it the main retrieval-quality driver (Zhang et al., 11 Jun 2026).

Stage 2 introduces collaborative and co-occurrence structure through tasks such as qq0, qq1, qq2, and qq3 on click and order logs (Zhang et al., 11 Jun 2026). This stage is crucial for editability: removing Stage 2 leaves HR@350 almost unchanged but collapses IHR@350 from 0.1340 to 0.0030 (Zhang et al., 11 Jun 2026).

Stage 3 trains the deployment policy on inputs containing the current query, the query SID, recent user queries, and SIDs of recently interacted items, with the target being the SID of the interacted item (Zhang et al., 11 Jun 2026). It also adds synthetic self-routing supervision for reserved slots, so that a prefix containing a reserved slot maps to a target SID with the same reserved slot. This ensures that reserved tokens remain usable identity routers after deployment (Zhang et al., 11 Jun 2026).

Training uses token-level cross-entropy across all stages. The reported setup uses H800 GPUs, learning rate qq4, batch size 512, and stage-specific data scales ranging from about 0.8M examples in Stage 0 to 74.3M in Stage 1, with 40 epochs in Stage 3 (Zhang et al., 11 Jun 2026).

5. Retrieval pipeline, offline performance, and online deployment

Offline item encoding begins by concatenating item text fields, matching attribute words, selecting representative attributes per group, and mapping them into the six-position SID. The system then builds a SID-to-item index that supports one-to-many resolution because multiple items can share the same SID (Zhang et al., 11 Jun 2026).

At inference, the same KAE pipeline produces a query SID from the query text. The model then conditions on the query, the query SID, and user history, and generates candidate SIDs with unconstrained beam search. In offline experiments beam size is 512. Each generated SID is resolved to up to five items, which are deduplicated and forwarded to downstream ranking (Zhang et al., 11 Jun 2026).

On 31 days of Kuaishou search logs, with 5M query–interaction logs for training and about 30K click and 30K order samples for testing, OneRetrieval reaches deep-recall parity with OneSearch, the strongest prior generative baseline (Zhang et al., 11 Jun 2026). At HR@350 on orders it obtains 0.5482 versus 0.5550 for OneSearch, and at HR@350 on clicks it reaches 0.6055 versus 0.6007 (Zhang et al., 11 Jun 2026). It substantially exceeds DPR and all other generative baselines at that depth. Its MRR@350 is lower than OneSearch, which the paper attributes to OneSearch being tuned more aggressively for bringing the very best item high in the list rather than serving strictly as a deep-recall branch (Zhang et al., 11 Jun 2026).

The system is deployed at Kuaishou and serves hundreds of millions of page views daily (Zhang et al., 11 Jun 2026). In online A/B testing, replacing only the inverted-index branch with OneRetrieval yields +0.710% order volume and +0.450% buyer count, while item CTR change is +0.074% and insignificant (Zhang et al., 11 Jun 2026). Replacing nearly the entire lexical and dense retrieval stage holds conversion while improving item CTR by +0.821%, with order change +0.255% and buyer change -0.028%, both insignificant (Zhang et al., 11 Jun 2026). The paper also reports positive CTR gains in 16 of the top 20 industries, with the largest gains in attribute-rich verticals such as Women’s Shoes, Underwear, Toys, Men’s Wear, Women’s Wear, and Beauty (Zhang et al., 11 Jun 2026).

A common misconception would be to treat OneRetrieval as merely a stronger deep-recall model. The deployment evidence suggests that its significance lies equally in operational substitution: it can replace the manually editable inverted-index branch while preserving most of that branch’s intervention capability and simultaneously contributing higher-quality candidates.

6. OneRetrieval as a broader research paradigm

The e-commerce system in (Zhang et al., 11 Jun 2026) is the most explicit use of the term as a named framework, but related work shows that “OneRetrieval” also functions as a broader unification agenda across retrieval research.

OneGen treats retrieval as a native token role inside a causal LLM. Special tokens such as [RQ] and [RD] let the same autoregressive forward pass perform both generation and vector retrieval, making it “the first to enable LLMs to conduct vector retrieval during the generation” (Zhang et al., 2024). This is a one-pass retrieval-generation interpretation of the same unification impulse.

LMORT approaches unification from frozen LLM representations. It identifies alignment-rich and uniformity-rich layers in a decoder-only LLM and learns a small retrieval tuner on top, allowing a single LLM instance to serve as both generator and retrieval backbone without modifying the base model (Sun et al., 2024). The paper explicitly frames this as compatible with an LLM-centric, “OneRetrieval”-style unified retrieval paradigm (Sun et al., 2024).

A different strand addresses not one model but one retrieval interface. OmniRetrieval argues that unification should not collapse heterogeneous sources into a single representation space; instead it should provide one natural-language interface that selects sources, emits native SQL, SPARQL, Cypher, or document-search queries, and consolidates evidence across 309 knowledge bases (Baek et al., 28 May 2026). This suggests that “OneRetrieval” can mean one orchestration layer rather than one embedding space.

Native query-side retrieval from LLM hidden states pushes unification even further. “One Model Is Enough: Native Retrieval Embeddings from LLM Agent Hidden States” equips an LLM agent with a lightweight projection head that maps generation hidden states directly into an embedding space, eliminating the separate embedding model while retaining 97% of baseline retrieval quality and reducing per-query latency from 43.5 ms to 2.0 ms on QReCC (Jiang, 9 Mar 2026). This is a one-model interpretation of the same design target.

Finally, ensemble analyses complicate any simplistic “one algorithm” reading of the term. MIGRASCOPE shows that retriever families have complementary and redundant information profiles and that carefully selected ensembles outperform single retrievers on multi-hop QA, suggesting that a realistic “OneRetrieval” may be a principled meta-retrieval framework rather than a monolithic retriever (Zheng et al., 25 Feb 2026). MoR reaches a similar conclusion from a zero-shot mixture-of-retrievers perspective, showing that a weighted combination of sparse, dense, and even simulated human retrievers can outperform every individual retriever and larger 7B models on average (Kalra et al., 18 Jun 2025).

Taken together, these works indicate that OneRetrieval is not a single settled architecture. In the narrow sense, it is the editable generative e-commerce retriever introduced in (Zhang et al., 11 Jun 2026). In the wider literature, it names a family resemblance across systems that try to replace fragmented retrieval pipelines with a unified retrieval substrate—whether by a single generative model, a single LLM backbone, a single orchestration layer, or a single query-dependent mixture controller (Zhang et al., 11 Jun 2026, Zhang et al., 2024, Sun et al., 2024, Baek et al., 28 May 2026, Jiang, 9 Mar 2026).

Topic to Video (Beta)

No one has generated a video about this topic yet.

Whiteboard

No one has generated a whiteboard explanation for this topic yet.

Follow Topic

Get notified by email when new papers are published related to OneRetrieval.