---
title: 'OneRetrieval: Editable Generative E-commerce Search'
url: https://www.emergentmind.com/topics/oneretrieval
type: topic
---

# OneRetrieval: Editable Generative E-commerce Search

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 [2606.13533]. 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 [2409.05152] [2403.01999] [2603.08429] [2605.29250].

## 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 [2606.13533]. 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 [2606.13533]. 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 [2606.13533]. 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, $\mathbf{s}_i = (s_i^{(1)}, \dots, s_i^{(L)})$, assigned to each item, and a policy
$$
\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 $q$ is the query and $\mathbf{c}_u$ is user context. Candidate generation is then expressed as
$$
\mathcal{R}(q, \mathbf{c}_u) = \mathcal{T}\!\Big( \operatorname*{TopK}_{\mathbf{s}} \pi_\theta(\mathbf{s} \mid q, \mathbf{c}_u) \Big),
$$
with $\mathcal{T}$ mapping each generated SID to the set of items bearing that SID [2606.13533].

## 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 \times 10^6$ attribute words [2606.13533]. 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 [2606.13533]. The resulting SID has fixed length $L = 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 [2606.13533].

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 $X$ and $Y$ indicating the presence of categories on items, the information loss of merging them is defined as
$$
\mathrm{IL}(X, Y)
= \tfrac{1}{2}\big(H(X \mid Y) + H(Y \mid X)\big)
= \tfrac{1}{2}\big(H(X) + H(Y)\big) - \mathrm{MI}(X, Y).
$$
Cluster-to-cluster distance is then the average $\mathrm{IL}$ 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 [2606.13533].

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 [2606.13533].

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 $V_\ell^{\text{rsv}} = 10$ slots per position, for 60 reserved slots in total, and these slots are not bound to words during training [2606.13533]. 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 [2606.13533]. 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 $K$, while IAR@K measures whether the injected attribute word’s code is activated in at least one of the top-$K$ retrieved SIDs [2606.13533]. 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 [2606.13533]. Against BM25, OneRetrieval reaches IAR@350 = 0.5530 versus 0.7610 for BM25, while substantially exceeding BM25 in retrieval quality [2606.13533].

## 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 [2606.13533]. The stages are distinct in purpose rather than interchangeable.

| Stage | Purpose | Representative supervision |
|---|---|---|
| Stage 0 | Attribute–SID alignment | attribute word/category $\leftrightarrow$ SID token |
| Stage 1 | Content alignment | query/title/category $\leftrightarrow$ SID |
| Stage 2 | Co-occurrence alignment | query SID $\leftrightarrow$ item SID |
| Stage 3 | Personalized retrieval and reserved-slot routing | $(q,\mathbf{s}_q,hist_q,hist_s)\to \mathbf{s}_i$ |

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 [2606.13533]. 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 [2606.13533].

Stage 2 introduces collaborative and co-occurrence structure through tasks such as $q \to title_i$, $title_i \to q$, $\mathbf{s}_q \to \mathbf{s}_i$, and $\mathbf{s}_i \to \mathbf{s}_q$ on click and order logs [2606.13533]. This stage is crucial for editability: removing Stage 2 leaves HR@350 almost unchanged but collapses IHR@350 from 0.1340 to 0.0030 [2606.13533].

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 [2606.13533]. 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 [2606.13533].

Training uses token-level cross-entropy across all stages. The reported setup uses H800 GPUs, learning rate $1\times10^{-4}$, 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 [2606.13533].

## 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 [2606.13533].

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 [2606.13533].

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 [2606.13533]. 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 [2606.13533]. 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 [2606.13533].

The system is deployed at Kuaishou and serves hundreds of millions of page views daily [2606.13533]. 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 [2606.13533]. 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 [2606.13533]. 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 [2606.13533].

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 [2606.13533] 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” [2409.05152]. 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 [2403.01999]. The paper explicitly frames this as compatible with an LLM-centric, “OneRetrieval”-style unified retrieval paradigm [2403.01999].

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 [2605.29250]. 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 [2603.08429]. 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 [2602.21553]. 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 [2506.15862].

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 [2606.13533]. 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 [2606.13533] [2409.05152] [2403.01999] [2605.29250] [2603.08429].

Source: https://www.emergentmind.com/topics/oneretrieval