What Is Embedding Space?
- 3 days ago
- 34 min read
Type "sneakers for bad knees" into a modern search bar, and you'll get running shoes with cushioned soles—even though not one of those words appears in the product description. Nothing about "bad knees" was matched letter for letter. Instead, the search engine turned your query into a list of numbers, turned every product description into a list of numbers, and asked a simple geometric question: which numbers sit closest together? That numerical world, where meaning gets converted into position, is called embedding space, and it quietly powers search, recommendations, fraud detection, and much of modern AI (Google for Developers, 2025).
TL;DR
Embedding space is a numerical vector space where an embedding model converts objects—words, sentences, images, products, users—into points, positioning similar things near each other (Google for Developers, 2025).
Similarity in embedding space is measured with distance metrics like cosine similarity, dot product, and Euclidean distance—and these three are not interchangeable (Google for Developers, 2025).
Embeddings can be static (one vector per word, like word2vec) or contextual (a vector that shifts with surrounding words, like BERT) (Mikolov et al., 2013; Devlin et al., 2019).
Real systems chain embeddings, vector databases, and nearest-neighbor search together to power semantic search, recommendation engines, and retrieval-augmented generation.
Two-dimensional visualizations of embedding space (like t-SNE or UMAP plots) are useful but can mislead you about true high-dimensional structure (van der Maaten & Hinton, 2008; McInnes et al., 2018).
Embedding quality is always task-dependent—there is no single "best" embedding model for every job.
What Is Embedding Space?
Embedding space is a mathematical vector space where objects—words, sentences, images, or products—are represented as numerical points called embeddings. A model learns to place semantically similar objects near each other and dissimilar ones farther apart, so that distance or angle between points reflects meaningful relationships rather than raw data format.
Table of Contents
What Is Embedding Space?
An embedding space is what you get when you take a collection of objects and represent each one as a point in a numerical vector space, arranged so that geometric relationships—distance, direction, neighborhood—carry meaning. Formally, an embedding model is a function:
f: X → R^d
Here, X is the original domain of objects—sentences, images, product listings, or user profiles. f is the learned or constructed embedding function. R^d is a d-dimensional real-valued vector space, meaning every output is a list of d real numbers. Each object becomes a point described by d coordinates, and the geometry of that space is shaped—through training or design—so that useful relationships can be read off through distance or direction (Google for Developers, 2025).
It helps to separate three related but distinct ideas that all get called "embedding space" in casual conversation. First, there's the mathematical container: R^d itself, an abstract space of all possible d-dimensional vectors. Second, there's the specific arrangement of data points that a trained model actually produces inside that container—the learned geometry. Third, there's an informal usage: people often say "the embedding space" to mean the semantic structure a particular model has learned, as shorthand for "how this model organizes meaning."
This matters because two different embedding models can embed the exact same data—say, the same 10,000 product titles—and produce two entirely different spaces. A model trained to predict clicks will place items differently than one trained to predict returns, even on identical input text, because the training objective shapes which relationships the geometry preserves (Google for Developers, 2025). There is no universal, "correct" embedding space for a dataset; there is only the space a particular model built for a particular purpose.
It's also worth distinguishing an individual embedding (a single vector, one point) from the embedding space (the entire container all such vectors live in, plus the full set of points a model has actually placed there). One is a location; the other is the whole map.
An Intuitive Mental Model
Picture a physical map of a city. Every address is a point defined by two coordinates: latitude and longitude. Addresses that are close together on the map tend to be in the same neighborhood. You can ask meaningful geometric questions—"What's the nearest coffee shop?"—and the answer depends only on distance, not on the street name matching your query.
Embedding space works the same way, except the "map" usually has hundreds or thousands of coordinates instead of two, and the "addresses" are things like sentences, songs, or images instead of physical locations. An embedding model is the process that assigns coordinates to each object. Once every object has coordinates, you can ask "what's near this point?" and get back genuinely related items—even if they don't share a single word or pixel in common.
The analogy breaks down in a few important ways. A city map has exactly two dimensions that humans intuitively understand—north/south and east/west. An embedding space commonly has 256, 768, or 1,536 dimensions, and those dimensions rarely correspond to anything as clean as "north" or "east." There's no guarantee that any single coordinate axis means something like "size" or "sentiment"—the space is more like a distributed code than a spreadsheet with labeled columns (Google for Developers, 2025). Additionally, on a real map, if A is near B and B is near C, A is probably reasonably near C too. In very high-dimensional space, that kind of transitive intuition can fail in surprising ways, a point covered later in this article.
Why Machine-Learning Systems Need Embeddings
Machine-learning models need numbers, not words or pixels, to compute with. The question is which numbers, and how they're organized.
The most naive option is to assign each distinct object an arbitrary ID—user #4821, product #91233. IDs carry no relationship information: ID 4821 isn't "closer" to 4822 in any meaningful sense, so a model can't generalize from one to the other.
A step up is one-hot encoding: represent each of V possible categories as a vector of length V, with a single 1 and the rest 0s. This is simple and lossless, but every one-hot vector is equally far from every other one—there's no way to encode that "cat" and "kitten" are more related than "cat" and "spreadsheet." One-hot vectors are also sparse (mostly zeros) and grow linearly with vocabulary size, which becomes expensive for a vocabulary of hundreds of thousands of words: it means more weights in a downstream neural network, and more data and computation needed to learn well (Google for Developers, 2025).
Dense embeddings solve both problems. Instead of one dimension per category, an embedding uses a fixed, much smaller number of dimensions—say 128 or 768—where almost every coordinate carries some signal (hence "dense," as opposed to "sparse"). Crucially, the values are learned so that semantically related items end up with similar vectors, encoding relationships that one-hot encoding simply cannot represent (Google for Developers, 2025). This isn't a claim that embeddings are always more compact than every conceivable raw representation—a raw pixel image is already a dense numerical array—but for high-cardinality categorical or symbolic data (words, IDs, SKUs), the efficiency and generalization gains are substantial.
This is why text, images, audio, products, users, and even nodes in a graph get embedded: raw formats (characters, pixel grids, categorical IDs) don't expose the relationships a model needs. Embeddings package that structure into a form suited to computation like nearest-neighbor search, clustering, or use as input to another neural network.
How Objects Become Points in an Embedding Space
Turning a raw object into an embedding vector generally follows a pipeline:
Input preparation. Raw data is cleaned and standardized—lowercasing text, resizing images, normalizing audio sample rates.
Tokenization or feature extraction. Text is split into tokens (words or sub-word pieces); images are divided into patches or passed through convolutional filters.
Encoder or embedding model. A trained encoder—which might be a shallow lookup table (as in classic word2vec) or a deep transformer—maps the prepared input to numerical vectors.
Pooling. For sentence or document embeddings, the model typically produces one vector per token, and pooling (averaging, taking the first token's vector, or a learned weighted combination) compresses those into a single representative vector for the whole passage (Reimers & Gurevych, 2019).
Optional normalization. Vectors are often scaled to unit length (norm of 1), which makes certain similarity calculations simpler and more consistent, as discussed in the similarity section below.
Resulting vector. The output is a fixed-length list of real numbers—the embedding.
Storage with identifiers and metadata. In production, the vector is stored alongside an ID pointing back to the original object and any filterable metadata (author, date, category), because the vector alone is not useful without a way to trace it back to source content.
The training objective—what the model was optimized to predict or distinguish—determines which relationships this pipeline preserves. An embedding model trained to detect paraphrase pairs will organize its space around meaning; one trained to predict the next word will organize its space partly around statistical co-occurrence. Not every hidden state produced by a large language model is automatically well-suited for retrieval or similarity tasks—general-purpose language model representations and embeddings tuned specifically for semantic similarity are shaped by different objectives, a distinction explored further below.
How Embedding Spaces Are Learned
Embedding spaces don't appear from nowhere—they're shaped by a training objective that rewards certain geometric arrangements over others.
Distributional and co-occurrence methods rest on the idea, sometimes summarized as the distributional hypothesis, that words appearing in similar contexts tend to have similar meaning. Early approaches counted how often words co-occurred within a window of text and built vectors from those counts.
Predictive methods, most famously word2vec, train a shallow neural network to predict a word from its neighbors (or neighbors from a word), and the byproduct—the weights of the hidden layer—becomes the word's embedding (Mikolov et al., 2013). Google's Machine Learning Crash Course notes that research suggests these trained static embeddings encode meaningful semantic information, with words used in similar contexts landing closer together in the resulting embedding space (Google for Developers, 2025).
Global count-based methods, exemplified by GloVe, instead directly factorize a matrix of global word co-occurrence statistics across an entire corpus, aiming to capture corpus-wide patterns rather than only local context windows (Pennington et al., 2014).
Supervised metric learning trains a model with explicit pairs or triplets labeled as similar or dissimilar, pushing embeddings of similar pairs together and dissimilar pairs apart. Siamese architectures run two copies of the same encoder on two inputs and compare the resulting embeddings, while triplet architectures use an anchor, a positive (similar) example, and a negative (dissimilar) example simultaneously, optimizing so the anchor sits closer to the positive than to the negative by some margin.
Contrastive learning generalizes this idea: for each anchor, the model is trained against one or more positive pairs (truly related examples) and many negative pairs (unrelated examples), often including hard negatives—examples that look superficially similar but are not, which force the model to learn finer-grained distinctions. SimCSE, for instance, builds effective sentence embeddings using a simple contrastive approach where the same sentence passed through the model twice—with different dropout applied each time—produces the positive pair (Gao et al., 2021).
Self-supervised transformer representations, like BERT, are pretrained on masked-token prediction across huge unlabeled text corpora, learning rich contextual representations without hand-labeled examples (Devlin et al., 2019). These general-purpose representations are often subsequently fine-tuned—as in Sentence-BERT—specifically to produce embeddings well-suited for similarity comparison and retrieval, since the raw hidden states of a language model are not automatically optimal for that job (Reimers & Gurevych, 2019).
Multimodal contrastive learning, exemplified by CLIP, trains on paired data—an image and its caption—pulling matching image-text pairs together in a shared space while pushing mismatched pairs apart, so that a single joint space can hold both images and text (Radford et al., 2021). This is covered in more depth below.
Static, Contextual, and Task-Specific Embedding Spaces
Not all embedding spaces serve the same purpose, and the distinction between them matters for practical use.
Static word embeddings, like classic word2vec or GloVe vectors, assign exactly one vector to each word regardless of context. The word "bank" gets a single point in space, blending its financial and riverside meanings together—a genuine limitation, since a single point cannot cleanly represent two unrelated senses at once (Google for Developers, 2025).
Contextual token representations, produced by transformer models like BERT, generate a different vector for the same word depending on its surrounding sentence. "I deposited cash at the bank" and "We sat by the river bank" would produce different embeddings for "bank," because the model incorporates surrounding context into the representation (Devlin et al., 2019).
Sentence embeddings compress an entire sentence into one vector, typically by pooling token-level contextual representations, as in Sentence-BERT (Reimers & Gurevych, 2019). Document embeddings extend the same idea to longer passages, often requiring chunking strategies discussed later in this article, since pooling loses more detail as input length grows.
Domain-specific embeddings are trained or fine-tuned on specialized vocabularies—legal, medical, or code-specific corpora—so that domain jargon is represented more precisely than a general-purpose model would manage. Multilingual embeddings are trained across many languages so that a sentence and its translation land near each other, enabling cross-lingual retrieval.
Beyond text, embeddings exist for images (learned by convolutional networks or vision transformers), audio (spectrogram-based encoders), graphs (node embeddings that capture connectivity), users and products (collaborative-filtering-style embeddings learned from interaction history), and multimodal combinations of these, discussed in the applications section.
Finally, general-purpose versus task-tuned spaces is a distinction worth internalizing: a language model's internal hidden states, useful for generating fluent text, are not automatically the ideal representation for semantic search or clustering. Models like Sentence-BERT exist precisely because researchers found that raw BERT embeddings, without specific fine-tuning for similarity, produced disappointing sentence-similarity performance compared to simpler baselines, motivating a training objective aimed directly at the retrieval task (Reimers & Gurevych, 2019).
The Geometry of Embedding Space
Every embedding is a point, described by a vector—an ordered list of numbers. That vector has a magnitude (its length, roughly how "big" the vector is) and a direction (which way it points, independent of length). Distance measures how far apart two points are; angle measures how similarly two vectors are oriented regardless of their length.
Points that sit near each other form neighborhoods, and groups of points that cluster tightly together relative to the rest of the space form clusters—regions that a clustering algorithm can detect and label. Real embedding spaces often aren't uniformly filled; instead, data tends to concentrate on a lower-dimensional manifold—a curved surface embedded within the larger space—rather than spreading evenly through every dimension.
One of the more striking geometric properties observed in some embedding spaces is that certain linear directions appear to correspond loosely to relationships. The famous example from word2vec research is that the vector arithmetic "king" − "man" + "woman" lands near the vector for "queen" (Mikolov et al., 2013). This is a genuinely interesting empirical finding, but it should be treated as an approximate, model-dependent observation rather than a universal algebraic law that holds for every relationship, every model, or every pair of words—many analogies work far less cleanly, and the effect depends heavily on training data and model architecture.
It's also useful to distinguish local structure (which points are each point's nearest neighbors) from global structure (the overall large-scale shape and arrangement of clusters across the whole space). A model can preserve local neighborhoods faithfully while distorting the global picture, or vice versa—and different visualization techniques, discussed later, prioritize one over the other.
Embedding spaces also have an arbitrary coordinate system: rotating all the vectors in a space by some fixed transformation typically doesn't change the distances or angles between them, meaning the geometry—which points are near which—can be meaningful even though no individual axis has an obvious human-readable label (Google for Developers, 2025).
Measuring Similarity and Distance
To compare two embedding vectors, you need a distance metric or similarity measure. Three are used constantly.
Euclidean distance is the straight-line distance between two points, generalizing the Pythagorean theorem to d dimensions:
d(x, y) = √( Σᵢ (xᵢ − yᵢ)² )
Take a small example: x = [0.12, -0.47, 0.81, 0.05] describes one object with four coordinates (a real embedding commonly has hundreds or thousands, but four keeps the arithmetic visible). If y = [0.20, -0.40, 0.75, 0.10], the squared differences are (0.08)² + (0.07)² + (0.06)² + (0.05)², summing to about 0.0174, and the square root gives a Euclidean distance of roughly 0.132—a small number, suggesting the two points are close. Euclidean distance is intuitive and works well when vector magnitude itself carries meaningful information, but it can be distorted when some vectors are simply "longer" than others for reasons unrelated to similarity—for instance, in some embedding schemes, vector length correlates with how frequently or popularly an item appears in training data, which can inflate distances in misleading ways (Google for Developers, 2025).
The dot product of two vectors x and y is:
x · y = Σᵢ xᵢyᵢ
Geometrically, the dot product combines both the angle between two vectors and their magnitudes: two vectors pointing the same direction with large magnitude produce a large dot product, even if their "true" semantic similarity is average. This means dot product similarity can be skewed toward popular or frequently-seen items whose vectors happen to have grown larger during training (Google for Developers, 2025).
Cosine similarity isolates just the angle, ignoring magnitude entirely:
cos(x, y) = (x · y) / (‖x‖ ‖y‖)
Here ‖x‖ is the Euclidean norm (length) of x, computed as √(Σᵢ xᵢ²). The result ranges from −1 (pointing in exactly opposite directions) to 1 (pointing in exactly the same direction), with 0 meaning the vectors are orthogonal—unrelated in direction. In practice, for embeddings from many text models, cosine similarity values tend to cluster in a positive range rather than spanning the full −1 to 1 spectrum, so relative ranking usually matters more than the absolute number. Using the small vectors above: x · y ≈ (0.12)(0.20) + (-0.47)(-0.40) + (0.81)(0.75) + (0.05)(0.10) ≈ 0.024 + 0.188 + 0.608 + 0.005 = 0.825. With ‖x‖ ≈ 0.951 and ‖y‖ ≈ 0.874, cosine similarity ≈ 0.825 / (0.951 × 0.874) ≈ 0.99—very close to 1, indicating the vectors point in almost the same direction.
When vectors are normalized to unit length (‖x‖ = ‖y‖ = 1), cosine similarity and dot product become identical, and both become monotonically related to Euclidean distance—so ranking by any of the three produces the same order of results (OpenAI, n.d.). This is a specific consequence of normalization, not a general property; for unnormalized vectors, the three metrics can rank the same set of candidates differently, and treating them as interchangeable in that case is a common source of bugs. OpenAI's own documentation notes that because its embeddings are normalized to length 1, cosine similarity can be computed slightly faster via dot product alone, and the two metrics will produce identical rankings (OpenAI, n.d.).
Measure | What It Emphasizes | Effect of Magnitude | Common Use | Main Caution |
Euclidean distance | Absolute geometric distance | Strong—longer vectors increase distance | General-purpose comparison, clustering | Sensitive to vector length differences |
Dot product | Angle and magnitude combined | Strong—rewards large magnitude | Recommendation ranking where "popularity" should count | Can favor frequent/popular items unfairly |
Cosine similarity | Angle only, direction | None—magnitude cancels out | Text and semantic similarity, retrieval | Ignores legitimate magnitude signals when they matter |
Once a similarity score exists between a query and every candidate, a system typically returns the top-k nearest neighbors—the k candidates with the highest similarity (or lowest distance)—rather than trying to interpret any single coordinate in isolation, because meaning in embedding space lives in relative position, not in individual axis values (Google for Developers, 2025).
Visualizing Embedding Space
A real embedding space, with hundreds or thousands of dimensions, cannot be plotted directly—human vision only handles two or three dimensions at once. To inspect embeddings visually, practitioners rely on dimensionality reduction techniques that project high-dimensional points down into 2D or 3D while trying to preserve some notion of structure.
Principal Component Analysis (PCA) finds the directions of greatest variance in the data and projects onto the top few, offering a fast, linear, and reasonably interpretable approximation, though it can miss curved or nonlinear structure.
t-SNE (t-distributed Stochastic Neighbor Embedding) instead focuses on preserving local neighborhoods: it tries hard to keep points that were close in high-dimensional space close in the 2D projection, converting distances into probabilities and minimizing the divergence between the high- and low-dimensional probability distributions (van der Maaten & Hinton, 2008). This often produces visually clean, well-separated clusters, but it can distort or fabricate apparent gaps between clusters, and the relative sizes and distances between clusters in a t-SNE plot are not reliable indicators of true separation in the original space.
UMAP (Uniform Manifold Approximation and Projection) is built on a different mathematical foundation rooted in topological data analysis and manifold learning, and it aims to preserve more of the global structure alongside local neighborhoods, often running faster than t-SNE on large datasets (McInnes et al., 2018).
Google's own Machine Learning Crash Course illustrates this risk directly: a widget flattening 10,000 word2vec vectors into 3D space can be misleading, because points that are truly closest together in the original high-dimensional space may appear farther apart once compressed into three dimensions (Google for Developers, 2025). The exercise even shows that words like "iii," "third," and "three"—semantically related to a human reader—don't necessarily appear as nearest neighbors in the actual embedding space, because they occur in different textual contexts (Google for Developers, 2025).
The practical takeaway: a t-SNE or UMAP plot is exploratory evidence, useful for spotting rough patterns like whether a query lands in a sensible cluster, not proof of exact rankings or true geometric relationships. The visualization is a lossy compression of the real thing, never the real thing itself.
How Embedding Search Works in Practice
A production embedding-search pipeline generally follows these steps:
Collect and clean source data—documents, product listings, support tickets, whatever the corpus is.
Split or chunk content where appropriate—long documents are broken into smaller passages so each chunk embeds a focused unit of meaning.
Generate embeddings for every chunk using a chosen embedding model.
Store vectors, source identifiers, and metadata together, so each vector can be traced back to its original text and filtered by attributes like date or category.
Build a vector index—a data structure optimized for fast similarity search over the stored vectors.
Embed the query using the same (or a compatible) embedding model used for the stored content.
Perform nearest-neighbor search, either exact (brute-force comparison against every stored vector) or approximate.
Apply metadata filters, narrowing results to, say, only documents from the last year or only a specific product category.
Optionally rerank results using a more precise but slower model applied only to the top candidates.
Return results, either directly to a user or as context passed into another system, such as a generative model in a retrieval-augmented pipeline.
Brute-force (exact) nearest-neighbor search compares a query against every single stored vector, guaranteeing the true top-k results but scaling poorly—computation grows linearly with the number of stored vectors, which becomes slow at millions of items.
Approximate nearest-neighbor (ANN) search trades a small amount of accuracy for dramatically faster lookups by using specialized index structures. One widely used approach, Hierarchical Navigable Small World (HNSW) graphs, builds a multi-layered graph where each vector is a node connected to its approximate neighbors; search starts at a sparse top layer and greedily traverses down through denser layers, converging on the query's true neighborhood far faster than scanning every point (Malkov & Yashunin, 2018).
It's worth clarifying the difference between a vector index and a vector database. A vector index is the data structure (like an HNSW graph) that makes similarity search fast. A vector database is a full system built around one or more such indexes, adding storage, metadata filtering, updates, backups, access control, and query APIs—the operational infrastructure needed to run vector search reliably in production. The What Is a Vector Database? guide covers this distinction and the surrounding tooling in more depth.
Real-World Applications
Embedding space underlies a wide range of practical systems:
Semantic search: queries and documents are embedded into the same space, and results are ranked by proximity to the query, catching meaning-based matches that keyword search misses.
Recommendation systems: users and items are embedded so that a user's vector sits near items they're likely to enjoy, based on historical interaction patterns—the foundation of many recommendation engines.
Clustering and topic discovery: unlabeled documents are embedded and then grouped using clustering algorithms, surfacing topics without manual tagging.
Classification: embeddings serve as compact, informative input features for a downstream classifier, often outperforming raw text features.
Deduplication: near-duplicate records—two slightly reworded product listings, for instance—get embedded close together and can be flagged automatically.
Anomaly detection: points that sit unusually far from any dense neighborhood in embedding space can indicate outliers, fraud, or defects.
Retrieval-augmented generation: covered in depth in the next section.
Question answering: candidate passages are embedded and ranked against an embedded question to find the most relevant supporting text.
Matching users, jobs, products, or content: a shared embedding space lets two different object types (resumes and job postings, for example) be compared directly by proximity.
Cross-lingual retrieval: multilingual embedding models place a sentence and its translation near each other, enabling search across languages.
Image-text retrieval: joint embedding spaces, discussed next, let a text query retrieve relevant images.
Few-shot or nearest-example selection: embeddings help a system pick the most relevant labeled examples to show a model before it makes a prediction.
For a multimodal example, consider CLIP, which trains an image encoder and a text encoder together using contrastive learning on paired images and captions, so that a caption like "a photo of a golden retriever" lands near actual photos of golden retrievers in a shared embedding space—despite text and images starting out as completely different data formats (Radford et al., 2021). This joint space is what allows a text query to retrieve relevant images or vice versa, without any hand-built rules linking specific words to specific pixels.
Consider a small illustrative retrieval example (numbers below are invented for teaching, not measured benchmark results). Suppose a user searches "how to reset a forgotten password," and three candidate support articles have been embedded:
Candidate Passage | Illustrative Cosine Similarity to Query |
"Steps to recover access when you've forgotten your login password" | 0.91 |
"How to change your account's display name" | 0.34 |
"Troubleshooting slow page load times" | 0.12 |
Even though the top passage doesn't share the exact phrase "reset password," it ranks highest because its meaning aligns closely with the query—this is the core value proposition of semantic search over plain keyword matching.
A useful ambiguous-word example to keep in mind throughout: "I withdrew cash from the bank" and "We fished along the river bank" both use the word "bank," but a static embedding model like classic word2vec assigns "bank" a single vector blending both senses, while a contextual model like BERT produces two different vectors depending on the surrounding sentence (Devlin et al., 2019). This single example captures much of why contextual embeddings represented a major step forward for tasks that depend on disambiguating meaning.
Embedding Space in Retrieval-Augmented Generation
Retrieval-augmented generation (RAG) combines a retrieval step—powered by embedding space—with a generative language model, letting the model answer questions using specific retrieved documents rather than relying solely on what it memorized during training.
The pipeline typically works as follows: source documents are split into chunks, each chunk is embedded, and those chunk embeddings are stored in a vector database. When a user asks a question, the query is embedded using the same or a compatible model, and the system retrieves the most similar chunks. Those retrieved chunks are assembled into a context window alongside the original question, and a generative model produces an answer grounded in that retrieved material.
Retrieval quality directly constrains answer quality—if the retrieval step misses the relevant passage, the strongest generative model in the world cannot compensate, because it never sees the needed information. This makes decisions like chunk size and overlap consequential: chunks that are too large dilute the embedding with irrelevant surrounding text, while chunks that are too small can lose necessary context, and a modest overlap between adjacent chunks helps avoid splitting a key sentence awkwardly across boundaries.
Metadata filters narrow retrieval to relevant subsets—restricting search to a specific document type, date range, or department, before or alongside the similarity search. Hybrid lexical and vector retrieval combines traditional keyword search (which excels at exact terms, product codes, or names) with embedding-based semantic search (which excels at paraphrase and meaning), often outperforming either approach alone. Reranking applies a slower, more precise model to just the top handful of retrieved candidates, improving final ranking quality without paying that cost across the entire corpus. Citation and provenance tracking—keeping a clear link from generated text back to the specific retrieved chunk it drew from—matters for trust and for verifying that the model isn't fabricating claims beyond what was retrieved.
Common failure modes include retrieving a chunk that's topically related but misses precise numerical detail, retrieving content that's out of date relative to the question's timeframe, or retrieving a passage that shares surface vocabulary with the query but actually answers a different question. It bears repeating: embeddings themselves do not generate answers. They retrieve relevant material; a separate generative model is responsible for producing the final response using that material. Readers looking for a deeper walkthrough can see the dedicated guide on What Is RAG (Retrieval Augmented Generation)?, or explore variants like GraphRAG, Agentic RAG, and evaluation approaches like RAGAS.
How to Evaluate an Embedding Space
Evaluating an embedding model only makes sense relative to a specific task—a model that excels at product-recommendation similarity may perform poorly on legal-document retrieval, because the notion of "similarity" itself differs across tasks.
Intrinsic evaluation measures properties of the embeddings directly, often against human-labeled similarity datasets where people have rated how similar two sentences or words are, checking whether the model's cosine similarity scores correlate with human judgment.
Extrinsic evaluation measures how well embeddings perform when plugged into a downstream task—classification accuracy, clustering quality, or retrieval performance—which is usually the more practically meaningful test. Common extrinsic retrieval metrics include:
Recall@k: of all truly relevant items, what fraction appear somewhere in the top k results?
Precision@k: of the top k results returned, what fraction are actually relevant?
Mean Reciprocal Rank (MRR): the average of 1 divided by the rank position of the first relevant result across many queries—rewarding systems that place the right answer near the very top.
Normalized Discounted Cumulative Gain (nDCG): a ranking metric that credits relevant results more heavily when they appear earlier in the list, accounting for varying degrees of relevance rather than a simple relevant/not-relevant split.
Beyond ranking metrics, teams should track clustering metrics (how cleanly embeddings separate into meaningful groups), classification performance when embeddings feed a downstream classifier, retrieval latency and memory footprint in production, and robustness across domains and languages—a model evaluated only on English news articles may degrade sharply on informal chat text or a different language entirely.
Qualitative nearest-neighbor inspection—manually examining what a handful of real queries retrieve—remains one of the most useful, low-cost sanity checks available, often catching obvious problems that aggregate metrics smooth over. Finally, production A/B tests, measuring real user behavior (click-through, task completion, satisfaction) when comparing two embedding models live, are the closest thing to ground truth for whether a change actually helps.
Limitations, Risks, and Common Failure Modes
Training-data bias: embeddings inherit patterns present in their training data, including cultural and demographic associations that may reflect stereotypes rather than neutral fact. Mitigation: audit embeddings for problematic associations before deployment, and consider debiasing techniques or curated training data where fairness is critical.
Domain mismatch: a model trained on general web text may embed specialized medical or legal terminology poorly. Mitigation: fine-tune or select a domain-specific model, and validate on representative in-domain examples.
Language imbalance: multilingual models often perform noticeably better on high-resource languages than low-resource ones, since training data volume differs drastically across languages. Mitigation: test performance separately per target language rather than assuming uniform quality.
Out-of-distribution inputs: text, images, or other data very different from anything seen during training can produce unreliable, poorly-organized embeddings. Mitigation: monitor for inputs that fall far from any training-data cluster and flag them for review.
Negation and numerical precision: embeddings can struggle to distinguish "the store is open on Sundays" from "the store is not open on Sundays," or to respect exact numbers like "under $50" versus "under $500," because surface-level semantic similarity doesn't guarantee logical precision. Mitigation: pair embedding retrieval with rule-based or keyword checks for negation and numeric constraints, especially in compliance-sensitive contexts.
Long-document information loss: pooling many tokens into one fixed-size vector inevitably compresses and loses detail, especially for long documents. Mitigation: chunk long documents into smaller, embeddable units rather than embedding an entire document as one vector.
Truncation: embedding models have a maximum input length, and text beyond that limit gets silently cut off. Mitigation: check and enforce your model's token limit during preprocessing.
Poor chunking: splitting text at arbitrary character counts can sever a sentence mid-thought, damaging embedding quality. Mitigation: chunk along natural boundaries (paragraphs, sentences) with modest overlap.
Model drift and data drift: the meaning of terms and the distribution of real-world queries shift over time, so an embedding model's usefulness can degrade even without any code changes. Mitigation: monitor retrieval quality over time and periodically re-embed content with updated models.
Stale vectors and mixed embedding-model versions: if some content was embedded with an old model version and new content with an updated one, similarity comparisons between them become meaningless, since the two live in effectively different spaces. Mitigation: re-embed the entire corpus when switching models; never mix vectors from different models in one index.
Metric mismatch: applying a similarity metric the model wasn't optimized for (using Euclidean distance on embeddings meant for cosine comparison) can degrade results. Mitigation: use the metric recommended in the specific model's documentation.
Anisotropy: some embedding spaces exhibit a tendency for vectors to cluster within a narrow cone of the overall space rather than spreading evenly in all directions, which can compress the effective range of similarity scores and make unrelated items appear more similar than they truly are. Mitigation: consider post-processing techniques or models specifically designed to counter this effect, and rely on relative ranking rather than absolute similarity thresholds.
Hubness: in high-dimensional spaces, certain points can become "hubs" that appear as a nearest neighbor to an unusually large number of other points, distorting retrieval results. Mitigation: apply hubness-reduction techniques or evaluate whether a small set of items dominates your top-k results unfairly.
False semantic neighbors: two items can be close in embedding space due to superficial topical overlap while actually answering different questions or serving different intents—the failure example given earlier in this article. Mitigation: add reranking or rule-based checks for critical distinctions like negation, dates, and specific entities.
Privacy and sensitive-data concerns: embeddings can sometimes be partially inverted to recover information about the original input, and storing embeddings of personal data still carries privacy obligations. Mitigation: treat embedding stores with the same access controls and data-handling policies as the original sensitive data.
Adversarial or manipulated content: text or images crafted to trick an embedding model into misclassifying similarity can undermine search or moderation systems. Mitigation: monitor for unusual query patterns and validate embedding behavior against known adversarial examples.
Overinterpreting visualizations: treating a t-SNE or UMAP plot as a faithful picture of true high-dimensional structure, as discussed earlier, is one of the most common analytical mistakes. Mitigation: use visualizations for exploratory hypotheses only, and confirm findings against actual high-dimensional distance calculations.
Distance concentration, sparsity, and failing intuition in high dimensions: as the number of dimensions grows very large, distances between randomly distributed points tend to become relatively similar to one another—a phenomenon sometimes called distance concentration—which can make it harder to distinguish "close" from "far" using naive distance thresholds. High-dimensional spaces are also mostly empty: the volume grows so enormously with each additional dimension that any realistic dataset only sparsely populates a tiny fraction of it. This is part of why human three-dimensional spatial intuition doesn't transfer cleanly, and why local neighborhood structure and global arrangement can tell noticeably different stories about the same space. Mitigation: rely on relative nearest-neighbor rankings rather than absolute distance thresholds, and validate retrieval quality empirically rather than trusting geometric intuition alone.
How to Choose an Embedding Model and Design a System
Selecting an embedding model is a matter of matching model characteristics to task constraints, then validating on real data rather than assuming benchmark leaderboards transfer directly to your use case.
Consider data modality (text, image, audio, or multimodal), language coverage (does your content span multiple languages?), and domain (general web content versus specialized legal, medical, or technical text). Clarify whether the objective is retrieval versus classification, since models optimized for one don't always excel at the other. Check input length limits against your typical document size, and note the model's vector dimension—more dimensions can capture more nuance but increase storage and compute cost; a larger embedding dimension is not automatically better; it's a trade-off against latency, memory, and sometimes even retrieval quality once diminishing returns set in.
Weigh quality against latency and throughput requirements—an interactive search box has very different tolerance for delay than an offline batch-processing job. Factor in storage costs at scale (millions of high-dimensional vectors add up), overall cost per embedding call if using a hosted API, and privacy requirements that might favor a local versus hosted deployment. Review model licensing terms, especially for commercial use, and check whether published benchmark relevance actually reflects your specific domain and query style rather than a generic academic dataset.
Decide whether fine-tuning on your own labeled examples is worth the investment, and whether adding a reranking stage on top of initial retrieval will meaningfully improve result quality for your use case. Above all, evaluation on representative data—your own queries, your own documents, your own users' actual behavior—is the only way to know whether a given model choice will genuinely work, because published benchmarks describe performance on someone else's data distribution, not necessarily yours.
A Small Worked Example
The following Python example demonstrates cosine similarity and nearest-neighbor ranking using small, manually supplied toy vectors. These vectors are for teaching purposes only and were not produced by any real embedding model.
import numpy as np
# Toy vectors representing five short "documents."
# These numbers are illustrative only, not real embedding-model output.
docs = {
"reset_password": np.array([0.90, 0.10, 0.05, 0.02]),
"change_username": np.array([0.30, 0.85, 0.10, 0.05]),
"billing_invoice": np.array([0.05, 0.10, 0.92, 0.15]),
"slow_page_load": np.array([0.02, 0.05, 0.15, 0.95]),
"login_recovery": np.array([0.88, 0.12, 0.04, 0.03]),
}
query = np.array([0.86, 0.15, 0.06, 0.04]) # a toy "query" vector
def cosine_similarity(a, b):
# Dot product divided by the product of vector norms
return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))
# Compute similarity between the query and every document
scores = {name: cosine_similarity(query, vec) for name, vec in docs.items()}
# Rank documents from most to least similar
ranked = sorted(scores.items(), key=lambda item: item[1], reverse=True)
for name, score in ranked:
print(f"{name}: {score:.4f}")
# Expected ranking (highest to lowest similarity):
# login_recovery, reset_password, change_username, billing_invoice, slow_page_loadRunning this script prints each document's cosine similarity score to the query, sorted from highest to lowest. Because the query vector was constructed to point in nearly the same direction as login_recovery and reset_password, those two rank at the top—illustrating, at a small and interpretable scale, exactly the mechanism a real semantic search system relies on: convert everything to vectors, then rank by similarity.
Embedding Space Compared With Related Concepts
Concept | Concise Definition | Overlap or Distinction |
Embedding space | A vector space where learned representations preserve meaningful relationships via distance or direction | The specific term for spaces built to support similarity-based reasoning |
Vector space | Any mathematical space of vectors following the rules of linear algebra | Embedding space is a particular kind of vector space, purpose-built by training |
Feature space | A space defined by chosen or engineered input features, not necessarily learned or dense | May be sparse or hand-crafted; embedding space is typically dense and learned |
Latent space | A space of hidden, unobserved variables a model infers to explain or generate data | Closely related to embedding space; often used interchangeably in generative-model contexts, though "latent" emphasizes hidden generative factors while "embedding" emphasizes representation for comparison |
Semantic space | An informal term for an embedding space specifically organized around meaning | Usually a subtype of embedding space, focused on textual or conceptual meaning |
Representation space | A general term for any space where a model represents input data as vectors | A broader, less specific synonym often used alongside "embedding space" |
Parameter space | The space of all possible values a model's trainable weights could take | Distinct concept entirely—describes the model itself, not its outputs |
Vector database | Software infrastructure for storing, indexing, and searching vectors at scale | The engineering system that operationalizes embedding space for production use |
Knowledge graph | A structured graph of entities and explicit relationships between them | A complementary, symbolic alternative or companion to embedding-based similarity, often combined with it in hybrid systems |
For a deeper look at two of the terms most often confused with embedding space, see the dedicated guides on What Is Latent Space? and What Is Feature Space in Machine Learning?
The Most Important Mental Model
Strip away the terminology, and the whole idea rests on a short chain of logic. An embedding model converts objects—words, sentences, images, users, products—into numerical vectors. The complete collection of every vector that model can produce, arranged in a shared coordinate system, forms an embedding space. The model's training objective shapes the geometry of that space, determining which relationships get preserved as nearby points and which get pushed apart. Similarity measures—cosine similarity, dot product, Euclidean distance—are the tools used to read meaning back out of that geometry, and they are not interchangeable; each emphasizes something slightly different. Every downstream application—semantic search, recommendation systems, retrieval-augmented generation, clustering, and anomaly detection—works by exploiting useful neighborhoods in that space, not by any form of true comprehension. And because the geometry only reflects whatever the training objective rewarded, embedding quality is never absolute—it is always, unavoidably, task-dependent.
FAQ
What is an embedding space in simple terms?
An embedding space is a numerical map where objects like words, sentences, or images become points, positioned so that similar things sit close together and different things sit farther apart. Instead of comparing raw text or pixels directly, a computer compares positions in this map, using distance to represent how related two items are. It's built by a trained model rather than existing naturally in the data.
What is the difference between an embedding and an embedding space?
An embedding is a single vector—one point representing one specific object, like one sentence or one product. Embedding space is the entire container those points live in, plus the complete collection of points a model has actually placed there. Think of an embedding as one address and embedding space as the whole map containing every address a model has generated.
Is embedding space the same as vector space?
Not exactly. A vector space is any mathematical space following the rules of linear algebra—an abstract, general concept. Embedding space is a specific kind of vector space: one purpose-built through training so that distance and direction carry meaningful, learned relationships, rather than being an arbitrary mathematical container.
Is embedding space the same as latent space?
The two terms overlap heavily and are often used interchangeably, but they carry slightly different emphases. "Latent space" usually highlights hidden, unobserved variables a generative model infers to explain or produce data. "Embedding space" usually emphasizes representations built specifically to support similarity comparison and retrieval. In practice, many systems use both terms for what is functionally the same underlying vector space.
Why are similar items close together in embedding space?
Items end up close together because the model was trained with an objective that specifically rewards placing related examples near each other—whether through predicting neighboring words, contrasting positive and negative pairs, or matching paired data like images and captions. Proximity isn't automatic; it's the direct result of the training process pushing related items toward each other and unrelated items apart.
What does each embedding dimension represent?
Usually nothing you could label cleanly on its own. Learned embedding dimensions are typically distributed representations, meaning meaningful concepts are spread across many coordinates working together rather than living in one clean, human-readable axis. A handful of specialized cases show more interpretable dimensions, but assuming every axis has a simple label is a common and mistaken oversimplification.
How many dimensions does an embedding space have?
It varies widely by model and use case, commonly ranging from around 100 to several thousand dimensions. There's a real trade-off: more dimensions can capture finer nuance but increase storage costs, computation time, and sometimes even hurt retrieval quality past a certain point. A higher dimension count is not automatically better—it must be validated against your actual task and data.
How is an embedding space created?
It's created by training a model on a specific objective—predicting neighboring words, distinguishing matching from non-matching pairs, or predicting masked tokens—and then using the model's internal learned weights, often from a hidden layer, as the coordinate-generating function. The resulting geometry reflects whatever relationships that training objective rewarded, which is why different models trained on the same data can produce very different spaces.
What is cosine similarity?
Cosine similarity measures the angle between two vectors, ignoring their length entirely, producing a score from −1 to 1 where higher values mean the vectors point in a more similar direction. It's calculated as the dot product of two vectors divided by the product of their individual lengths (norms). It's especially popular for text embeddings because it isolates meaning-related direction from magnitude, which can otherwise reflect unrelated factors like frequency or popularity.
Can embeddings from different models be compared?
Generally, no—embeddings from different models exist in different, incompatible spaces, even if they happen to have the same number of dimensions. Comparing them directly produces meaningless results, because each model learned its own arbitrary coordinate arrangement during training. If you switch embedding models, you need to re-embed your entire dataset with the new model rather than mixing old and new vectors together.
How do vector databases use embedding spaces?
A vector database stores the embeddings produced by a model, builds a specialized index (often based on approximate nearest-neighbor structures like HNSW) for fast similarity search, and lets applications query "which stored vectors are closest to this new vector?" efficiently, even across millions of items. It also typically manages metadata, filtering, and updates alongside the raw vector data.
How is embedding space used in RAG?
In retrieval-augmented generation, document chunks and user queries are both converted into embeddings in the same space, and the system retrieves the chunks whose embeddings are closest to the query's embedding. Those retrieved chunks are then passed as context to a generative language model, which uses them to produce a grounded answer. Retrieval quality directly limits how good the final generated answer can be.
Can embedding-space visualizations be misleading?
Yes, quite easily. Techniques like t-SNE and UMAP compress hundreds or thousands of dimensions down into two or three for viewing, and that compression can distort apparent cluster sizes, distances, and gaps in ways that don't reflect the true high-dimensional geometry. Visualizations are useful for spotting rough patterns and generating hypotheses, but they shouldn't be treated as literal proof of how the original space is structured.
What makes an embedding model good?
A good embedding model is one that performs well on your specific task and data—there's no universal "best" model across every possible use case. Evaluation should combine intrinsic checks (like correlation with human similarity judgments) with extrinsic, task-specific metrics such as recall@k or classification accuracy, along with hands-on inspection of what real queries retrieve, ideally followed by production testing on genuine user behavior.
Key Takeaways
Embedding space is defined by a mapping f: X → R^d, converting objects into d-dimensional numerical points whose geometry is shaped by a training objective.
Distance and similarity metrics—Euclidean distance, dot product, and cosine similarity—each emphasize different geometric properties and are not universally interchangeable.
Static embeddings assign one vector per word; contextual embeddings adjust the vector based on surrounding context, resolving ambiguity that static approaches cannot.
High-dimensional geometry behaves counterintuitively: distances can concentrate, spaces are sparsely populated, and local neighborhood structure can diverge from global arrangement.
Visualization techniques like PCA, t-SNE, and UMAP are lossy compressions useful for exploration, never a faithful substitute for the original high-dimensional space.
Production embedding search chains together chunking, embedding generation, vector indexing, approximate nearest-neighbor search, filtering, and often reranking.
Retrieval-augmented generation depends entirely on retrieval quality; a strong generative model cannot compensate for embeddings that miss the relevant passage.
Embedding models cannot be freely mixed or compared across different models or versions—each defines its own incompatible space.
Model choice must be validated on your own representative data and task; published benchmarks don't guarantee transfer to your specific use case.
Actionable Next Steps
Identify the exact objects you need to represent (documents, products, users) and the relationship you want the space to capture (semantic similarity, purchase affinity, visual likeness).
Shortlist two or three candidate embedding models suited to your data modality, language coverage, and domain.
Build a small, representative evaluation set of realistic queries and expected relevant results from your own data.
Generate embeddings for that evaluation set and manually inspect nearest-neighbor results for obvious problems.
Choose the similarity measure recommended for your chosen model, and confirm whether normalization is required.
Test retrieval quality using metrics like recall@k and precision@k against your evaluation set, not just a general benchmark.
Add metadata filtering or a reranking stage if initial retrieval quality falls short of your requirements.
Monitor retrieval quality in production over time, and plan to re-embed your corpus whenever you update or switch embedding models.
Glossary
Approximate nearest neighbor (ANN): A search method that finds very likely—but not always mathematically guaranteed—nearest neighbors much faster than exhaustive comparison, using specialized index structures.
Anisotropy: A tendency for embedding vectors to cluster within a narrow directional cone rather than spreading evenly, which can compress the effective range of similarity scores.
Chunking: Splitting a long document into smaller passages before embedding, so each chunk captures a focused, manageable unit of meaning.
Contextual embedding: A vector representation of a word or token that changes depending on its surrounding sentence, as produced by transformer models like BERT.
Cosine similarity: A similarity measure based purely on the angle between two vectors, ignoring their magnitude, ranging from −1 to 1.
Dense vector: A vector where most or all coordinates hold meaningful, non-zero values, as opposed to a sparse vector dominated by zeros.
Dimension: One coordinate axis in a vector space; an embedding with d dimensions has d numerical values per point.
Distance metric: A mathematical rule for measuring how far apart two points or vectors are, such as Euclidean distance.
Dot product: The sum of the products of corresponding coordinates of two vectors, reflecting both angle and magnitude.
Embedding: A numerical vector representing a single object—word, sentence, image, or other item—produced by an embedding model.
Embedding model: A trained function that converts raw objects into embedding vectors, learned so that similar objects map to nearby points.
Embedding space: The full vector space, and the arrangement of points within it, produced by an embedding model.
Encoder: The part of a model responsible for transforming raw input into a vector representation.
Euclidean distance: The straight-line distance between two points in a vector space, generalizing the Pythagorean theorem to any number of dimensions.
Feature space: A space defined by chosen or engineered input features, which may be sparse or hand-crafted rather than learned.
HNSW (Hierarchical Navigable Small World): A graph-based algorithm for fast approximate nearest-neighbor search, widely used inside vector databases.
Hubness: A phenomenon in high-dimensional spaces where certain points become disproportionately frequent nearest neighbors to many other points, distorting retrieval.
Latent space: A space of hidden, unobserved variables a model infers to explain or generate data, closely related to but not always identical to embedding space.
Nearest neighbor: The point (or points) in a space closest to a given query point according to some distance or similarity measure.
Normalization: Scaling a vector so its length (norm) equals a fixed value, typically 1, which simplifies certain similarity calculations.
Pooling: Combining multiple token-level vectors into a single fixed-size vector representing a whole sentence or document.
Reranking: Applying a slower, more precise model to re-score a small set of top retrieved candidates, improving final ranking quality.
Semantic search: A search approach that ranks results by meaning-based similarity in embedding space rather than exact keyword matching.
Static embedding: A fixed vector representation assigned to a word regardless of the surrounding context, as in classic word2vec.
Vector: An ordered list of numbers describing a point's position and direction in a vector space.
Vector database: Software infrastructure for storing, indexing, filtering, and searching large collections of vectors efficiently.
Sources & References
Devlin, J., Chang, M.-W., Lee, K., & Toutanova, K. (2019). BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding. arXiv. https://arxiv.org/abs/1810.04805
Gao, T., Yao, X., & Chen, D. (2021). SimCSE: Simple Contrastive Learning of Sentence Embeddings. arXiv. https://arxiv.org/abs/2104.08821
Google for Developers. (2025). Embeddings. Machine Learning Crash Course. https://developers.google.com/machine-learning/crash-course/embeddings
Google for Developers. (2025). Embeddings: Embedding Space and Static Embeddings. Machine Learning Crash Course. https://developers.google.com/machine-learning/crash-course/embeddings/embedding-space
Google for Developers. (2025). Embeddings: Obtaining Embeddings. Machine Learning Crash Course. https://developers.google.com/machine-learning/crash-course/embeddings/obtaining-embeddings
Google for Developers. (2025). Embeddings: Interactive Exercises. Machine Learning Crash Course. https://developers.google.com/machine-learning/crash-course/embeddings/interactive-exercises
Google for Developers. (2025). Measuring Similarity from Embeddings. Machine Learning Crash Course (Clustering). https://developers.google.com/machine-learning/clustering/dnn-clustering/supervised-similarity
Malkov, Y. A., & Yashunin, D. A. (2018). Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs. arXiv. https://arxiv.org/abs/1603.09320
McInnes, L., Healy, J., & Melville, J. (2018). UMAP: Uniform Manifold Approximation and Projection for Dimension Reduction. arXiv. https://arxiv.org/abs/1802.03426
Mikolov, T., Chen, K., Corrado, G., & Dean, J. (2013). Efficient Estimation of Word Representations in Vector Space. arXiv. https://arxiv.org/abs/1301.3781
OpenAI. (n.d.). Vector Embeddings. OpenAI API Documentation. Accessed July 2026. https://developers.openai.com/api/docs/guides/embeddings
Pennington, J., Socher, R., & Manning, C. D. (2014). GloVe: Global Vectors for Word Representation. Stanford NLP Group. https://nlp.stanford.edu/pubs/glove.pdf
Radford, A., Kim, J. W., Hallacy, C., Ramesh, A., Goh, G., Agarwal, S., Sastry, G., Askell, A., Mishkin, P., Clark, J., Krueger, G., & Sutskever, I. (2021). Learning Transferable Visual Models From Natural Language Supervision. arXiv. https://arxiv.org/abs/2103.00020
Reimers, N., & Gurevych, I. (2019). Sentence-BERT: Sentence Embeddings Using Siamese BERT-Networks. arXiv. https://arxiv.org/abs/1908.10084
van der Maaten, L., & Hinton, G. (2008). Visualizing Data Using t-SNE. Journal of Machine Learning Research, 9, 2579–2605. https://www.jmlr.org/papers/v9/vandermaaten08a.html