Explains how vectors, matrices, and tensors represent data for search, related-item discovery, and personalized recommendations in e-commerce.
Welcome — I’m Alan Chapman from KodeKloud.In this lesson we’ll see how computers use linear algebra — vectors, matrices, and tensors — to represent, compare, and process data. These primitives are the foundation for search, related-item discovery, and recommendations in real-world systems.
We’ll cover practical, concrete examples: finding the right product with search, discovering related items, and creating personalized recommendations.Have you ever wondered how software recommends a product, ranks search results, or predicts what you might want next? At a high level, computers organize data into three fundamental shapes:
Vectors — ordered lists of numbers that represent single items or queries (often called feature vectors or embeddings).
Matrices — 2D arrays that express relationships across collections of items (for example, item-by-feature or user-by-item matrices).
Tensors — higher-dimensional arrays used for richer interactions (user × item × context, multi-modal data, etc.).
Each structure is chosen based on the complexity of the data and the modeling task: vectors for single-item similarity, matrices for pairwise relationships and linear transforms, tensors for multi-way relationships.
Soon you’ll see how these shapes power typical e-commerce behaviors.Meet Jay, who launched an e-commerce app called Nile. As ML engineers we make shopping on Nile easy and personalized. We’ll focus on three tasks:
Search — convert user queries into vectors and match them to product vectors.
Related products — surface complementary or similar items using vector/matrix comparisons.
Recommendations — learn from user behavior using matrices and tensors.
Machine learning models learn from user actions — searches, clicks, purchases — and translate that data into numeric representations that can be compared and ranked efficiently. The core idea: convert text, images, and attributes into numbers the computer can reason about.
Example scenario: Alice searches for a “blue gym bag.” We’ll follow her journey to illustrate how data is encoded and used for search and recommendations.When Alice first types “bag” she sees many categories: handbags, backpacks, briefcases. Not very useful. When she narrows to “blue gym bag” the results improve because the system encodes both products and queries as vectors and compares them with similarity measures (e.g., dot product, cosine similarity).Computers only understand numbers, so we must encode words and attributes as numeric features. There are many encoding strategies (binary, categorical codes, one-hot, embeddings); below we show a simple illustrative approach for product attributes.At the lowest level data can be binary (for illustration):
More usefully for search, we build structured numeric features. For our bag example we might map common product attributes to numeric codes:
Attribute
Example encoding
Notes
Type
01 = backpack, 02 = gym bag, 03 = tote
Use one-hot or learned embeddings in production to avoid implying order
Color
150 = red, 250 = green, 415 = light blue, 450 = blue, 490 = dark blue
Use ranges so similar shades have nearby codes; embeddings or color vectors are often better
Price
23.40
Normalize prices for distance-based comparisons (e.g., scale to 0–1)
Combine these feature values into a vector for each product. Think of the mapping from attributes to numbers as a dictionary the system can read.
Integer categorical codes here are illustrative. In production, raw ordinal integers can mislead similarity calculations because they imply scale. Prefer one-hot encoding, normalized numeric features, or learned embeddings for categorical attributes. When a query omits a feature, systems commonly mask that dimension so it doesn’t affect similarity.
For example, a blue gym bag priced at $23.40 could be represented as:
When a customer searches, the system converts the query into a query vector and compares it with stored product vectors using vector math (dot product, cosine similarity, or L2 distance) to find the closest matches. Query dimensions that are unspecified can be masked or treated as wildcards.
Using a wildcard (an underscore or None in implementation) indicates the query doesn’t constrain that feature. The search logic then ignores that dimension when ranking matches.
Nile precomputes product vectors for all inventory items and stores them for fast nearest-neighbor lookup (vector indexes, ANN libraries). Example product catalog vectors:
When she refines to gym bag, the query vector sets the type to 02 and filters out non-gym-bag types. When she further specifies blue gym bag, the color dimension is set to 450 (or nearby codes for light/dark shades) and the results are ranked by closeness in the color and price dimensions.Filtered example results for blue gym bag:
Numeric color codes allow the system to distinguish light blue from navy; similarity measures rank the closest shades higher.
Alice found a light-blue gym bag for $23 and wants similar items — same type, similar color, and comparable price. To support this, Nile uses vector comparisons for similarity and may employ matrices or tensors for richer recommendations (for example, item-by-item co-purchase matrices or user × item × context tensors).What we covered in this lesson:
How vectors encode item attributes and user queries for search and similarity.
Why categorical encodings should be handled carefully (one-hot, embeddings, normalization).
How masking unspecified query dimensions improves search relevance.
How precomputed vectors and fast nearest-neighbor indexes enable responsive search and related-item suggestions.
Next lessons will explore matrices and tensors: how they express relationships across many items and users and how they power collaborative filtering, matrix factorization, and multi-dimensional recommendation models.Further reading and references:
