Before comparing vectors, find out what one vector stands for. It might describe one token in a worked example, an item prefix in a recommendation system, or a passage stored for search. Those are different units. The Hugging Face retrieval tutorial computes embeddings for document chunks, while the DECOR research paper studies representations used to recommend items [2][3]. A list of numbers on its own does not tell you which of those jobs it performs.

A lookup table gives us a manageable way to examine the distinction. We will define a small imaginary table, choose one identifier, and read its row. Later, we will introduce an equally explicit rule that uses surrounding tokens. The numbers and rules are invented teaching examples, so their behaviour can be checked directly. A separate discussion of DECOR shows how its authors describe fixed lookup and context-guided composition in their particular recommender [3]. Keeping the example and the reported research separate lets you learn the mechanism without assuming that every language model uses the same design.

An embedding claim is incomplete until its represented unit and processing stage are specified. In the Hugging Face cookbook, the indexed embeddings represent document chunks; in the DECOR paper, token representations participate in generative recommendation of items [2][3]. Neither an array's length nor its visual appearance identifies its unit. A token-level vector, a representation associated with an item prefix, and an encoder's passage output should therefore be named explicitly before their properties are compared.

The example below defines lookup as a mathematical row-selection operation. We stipulate its vocabulary size, dimension, identifiers, and values, then add a separate context-dependent operation. These assumptions describe the exercise rather than an observed deployment. The DECOR paper supplies an independently attributed example involving a fixed prefix embedding and a contextual composition mechanism [3]. The purpose of comparing them is to distinguish what follows from a defined operation from what a particular paper actually reports. No result about the exercise establishes the architecture, semantic behaviour, or quality of an unspecified production model.

Now define a table containing 1,000 rows, each with eight numbers. Put the invented row (2, 0, 1, 0, 0, 0, 0, 0) at address 417. Our lookup rule simply returns the row at the supplied address. Looking up 417 twice returns those same eight numbers because we have kept the table unchanged. No sentence interpretation happens inside this rule: it has only an address and a table to use.

Looking up all five identifiers produces five eight-number rows. There are therefore 40 numbers in the result, arranged as five rows rather than one passage vector. This is arithmetic about our defined table, not a report of a model's dimensions. A separate real research example appears in DECOR: its authors describe one fixed representation for the item prefix (1,276), attributing that result to deterministic lookup in their recommendation case study [3]. That prefix should not be relabelled as an ordinary word or used to prove how every text embedding works.

Let E be the hypothetical table with shape 1,000 by 8. Define the lookup L(c) = E[c], and set row 417 to (2, 0, 1, 0, 0, 0, 0, 0). For a fixed E, L(417) is fixed by definition. Neither the surrounding sequence nor a sentence meaning is an argument of L. Applying L independently to the five stipulated identifiers yields a 5 by 8 collection of values. The dimensions, coordinates, and row label are assumptions of the exercise.

This construction illustrates a specific kind of operation without asserting that the entire model is context independent. A later operation could take both E[c] and the sequence as arguments. DECOR provides a separate empirical context for the lookup distinction: its Scientific-dataset case study describes a single fixed embedding for prefix (1,276) before contextual composition [3]. The reported object is an item prefix in a generative recommender. Its representation and the paper's visual comparison should not be treated as measurements of the illustrative table or of a natural-language word.

The five rows in our table exercise should not be confused with the vector a search system stores for a passage. The Hugging Face example computes embeddings for chunks of its knowledge base [2]. Microsoft also notes that a page covering several topics may be poorly represented as one vector, even when the page fits the input limit; smaller chunks may help [1]. Those examples concern the choice of text represented by each search record.

Imagine a retrieval design that stores one vector for a paragraph about river paths and another for a paragraph about bank fees. Under that stated design, there are two passage records. Their token counts need not be two, and the example does not specify how the encoder produces either vector. To compare the records, keep each passage attached to its vector and give it a stable label. That makes it possible to ask what text a result represents, rather than guessing from a coordinate or a familiar word inside the passage.

Representation granularity is independent of the shape of an individual numeric array. The cookbook embeds knowledge-base chunks for retrieval [2]; the toy table instead maps individual identifiers to rows. Microsoft's chunking guidance explains why a multi-topic page can be an unsuitable unit for one vector and suggests considering finer units [1]. This is a selection of the represented text, not evidence that a passage embedding is an average of the token rows illustrated here.

For an explicitly hypothetical collection with two passages and one stored embedding per passage, define two records with their own text and identifiers. The number of records follows from that indexing choice. It says nothing about the passages' token counts, internal token representations, pooling method, or embedding dimension. Those properties belong to the chosen encoder and configuration. Keeping the representation unit in the record makes the comparison inspectable: a query can retrieve a specific passage, and an evaluator can inspect that passage rather than treating all uses of the word 'embedding' as the same operation.

DECOR studies generative recommendation, where item representations are used to generate recommendations. Its authors describe a pipeline that creates semantic identifiers from item information, followed by recommender training on interactions. They argue that the objectives of these stages can be misaligned and that fixed assignments can be too inflexible for different uses of an item [3]. This is a claim about the recommendation setting investigated in the paper.

Their composition method uses historical embeddings to build a context vector, then uses that context when combining candidate token embeddings [3]. In a case study on the Scientific dataset, the authors contrast a fixed representation for prefix (1,276) with contextually composed prefix representations. They report a more coherent relationship to valid next-token candidates in their visualization [3]. The useful lesson is to identify which operation changed and what evidence was shown. A case study of a recommender prefix is not a measured demonstration of the imaginary 'bank' row or a guarantee about another model.

The DECOR paper separates item tokenization from recommender training and attributes limitations to their differing reconstruction and interaction-modelling objectives [3]. Its contextualized token composition is a specified mechanism within that framework. The context computation aggregates fused embeddings from the historical sequence using attention-based pooling, followed by a learned transformation into a context vector [3]. This description should retain the framework's scope rather than being presented as the universal implementation of contextual language-model embeddings.

For composition, the paper selects candidate token embeddings from the same RQ-VAE codebook layer and combines them under the guidance of the computed context [3]. Its Scientific-dataset case study visualizes the prefix (1,276) before and after that operation, reporting improved coherence with valid next-token candidates [3]. The visualization is evidence the authors use for that case; it supplies neither the coordinates in our toy table nor a general claim about word senses. Evaluating a different system would require its own representation definitions, procedure, and results.