AWSAWS Certified Generative AI Developer - Professional2026-100 Prerequisites

Align vector representations before comparing similarity

Completed by the knowledge check

Learning objective

Understand embeddings, dimensions, similarity metrics, and semantic search.

Core idea

For an architect designing search, an embedding is a numerical representation used to compare meaning or other learned properties. It is not a compressed answer, a document identifier, or a probability that a claim is true. An embedding model maps content into a vector; a retrieval system compares compatible vectors to find candidate evidence.

Semantic search works only when the document and query representations share a compatible contract: model, preprocessing, dimensions, representation, and similarity metric. Two arrays of the same length are not automatically comparable. They must represent content in the same learned space. Compatibility can mean a documented asymmetric pair: Cohere Embed v3 uses input_type: search_document for stored passages and input_type: search_query for queries, rather than identical settings on both sides. This lesson explains the foundations; see 1.4.7 for retrieval economics and 1.5.3 for embedding selection.

How it works

Embeddings represent content as coordinates

Amazon Bedrock defines embedding as transforming input into a vector of numerical values so objects can be compared through a shared representation. Text embeddings can place passages with related meanings near one another even when they use different words. For example, a query about “ending a subscription” can retrieve a passage titled “Cancel your plan” without an exact phrase match.

Amazon Titan Text Embeddings V2, identified as amazon.titan-embed-text-v2:0, is a concrete text embedding model. Its native request takes inputText; its output includes the embedding and inputTextTokenCount. It transforms text into a representation. AWS explicitly distinguishes this from similarity computation and retrieval, which the vector database performs.

An individual coordinate is not a labeled business field. Do not interpret the first vector value as “refund likelihood” or the second as “policy confidence.” The useful meaning lies in how the learned representation supports comparison. Keep the original passage and its provenance so retrieval can return readable evidence rather than an unexplained array.

Dimensions define the vector shape

A vector’s dimension is the number of coordinates it contains. Titan Text Embeddings V2 supports dimensions values of 1,024, 512, and 256, with 1,024 as the default. This is an output representation choice, not the number of words, chunks, search results, or input tokens.

For a fixed numeric representation, fewer coordinates reduce raw vector storage and comparison work. That potential saving is not proof that a smaller vector preserves the retrieval quality your corpus needs. Evaluate representative queries, including product terminology and confusingly similar passages, before choosing the smaller representation. Dimensionality changes a resource and quality trade-off rather than establishing an absolute quality ranking.

The index must agree with the returned shape. Amazon OpenSearch Service’s knn_vector field declares a dimension; a 512-coordinate embedding must target a field configured for that shape. Using a different dimension for query and stored vectors violates the search contract. Changing an embedding model or its dimension is a representation migration, not a harmless query-time adjustment. See 1.5.4 for the publication contract.

Titan V2 also supports normalize, which defaults to true, and embeddingTypes, which can request float, binary, or both. For this introductory example, keep the representation explicitly floating point. Binary embeddings require their own compatible storage and distance treatment; do not feed a binary array into a float-vector path because both are numerical lists.

Similarity metrics ask different geometric questions

A similarity metric defines what “near” means. AWS documents Euclidean distance, cosine similarity, and dot product similarity for the OpenSearch Serverless vector engine. The conceptual differences matter before you tune an index:

Euclidean distance measures separation between coordinates. Smaller distance means closer vectors under that metric.
Cosine similarity measures directional alignment. It divides the dot product by the vectors’ lengths, so magnitude does not dominate the comparison.
Dot product similarity sums coordinate-wise products. Without normalization, vector magnitude can affect the result as well as direction.

For unit-length vectors, these measures have related rankings: the squared Euclidean distance equals two minus twice their dot product, and their cosine similarity equals their dot product. That mathematical relationship does not make backend score fields interchangeable. A search service can transform a raw distance into a returned score, and approximate indexing can affect the candidate set.

OpenSearch Serverless’s documented index examples use space_type: "l2" for Euclidean distance. Select the metric and mapping supported by the actual backend, and interpret scores using that backend’s contract. A threshold such as “0.8” has no universal meaning across models, metrics, or score transformations. See 1.4.7 for deeper metric configuration and 1.5.7 for relevance thresholds.

Semantic search returns candidates, not conclusions

A basic semantic-search path embeds stored passages, indexes their vectors, embeds an incoming query with a compatible model configuration, and retrieves nearby candidates. The application then uses the readable passages to answer the question or perform another task. The embedding model does not produce those retrieved passages by itself.

A near match can still be the wrong evidence. “Refunds are available” and “Refunds are unavailable” discuss the same topic but imply different answers. Similarly, an obsolete policy can be semantically closer than an effective revision. Retain version, source, and authorization metadata outside the vector and validate candidate evidence before generation. See 1.4.6 for access filtering and 1.5.11 for authorized context assembly.

Semantic and lexical search also serve different needs. Semantic search helps with paraphrase and related meanings. Literal identifiers and exact product codes can require lexical matching or a hybrid approach. Do not replace exact-match requirements with vector proximity solely because the application uses an LLM.

Key distinctions and trade-offs

Embedding versus generation: A vector supports comparison. A generated answer expresses a conclusion. A retrieval pipeline often needs both, with separate acceptance checks.

Same dimension versus same space: Array length validates shape. It does not prove that different models use compatible coordinates.

Similarity versus evidence: A related passage might not support the requested claim. Similarity is also not permission to disclose a passage.

Higher dimensions versus better retrieval: More coordinates can increase resource use. Measured relevance on the actual corpus determines whether that cost earns its place.

Architecture / decision scenario

A team indexes cancellation policies with Titan V2 at 1,024 dimensions. To reduce query latency, a developer changes only query embeddings to 256 dimensions. A second developer proposes switching the query model while keeping the same vector length.

Both proposals break the representation contract. The first changes shape; the second can change the learned coordinate space. Instead, the team evaluates a separate 256-dimension index built with matching document and query embeddings. It records model ID, dimensions, normalize, and embeddingTypes, and aligns the knn_vector.dimension and selected distance metric.

The test set includes paraphrased cancellation requests, literal plan codes, and opposite policies for different revisions. The team checks whether the returned passages answer the query, not whether the scores exceed an arbitrary shared number. It keeps lexical matching for plan identifiers and verifies effective policy versions before supplying evidence to a language model. This evaluates storage savings, metric behavior, and semantic relevance without conflating any of them with answer correctness.

Common exam traps

Treating an embedding as generated prose or factual confidence.
Assuming equal dimensions make different embedding models compatible.
Confusing dimension count with input-token or result-count limits.
Computing query vectors under a different representation from stored vectors.
Reusing a similarity threshold across unrelated metrics and backends.
Assuming semantic proximity proves entailment, freshness, or authorization.

What to remember

Embeddings create comparable numerical representations; the vector store performs search. Keep ingest and query contracts compatible, align vector dimensions with the index, and understand how the metric defines proximity. Evaluate retrieved evidence independently of similarity before using it to support an answer.