Choose embeddings with representative retrieval evidence

Learning objective

Select Amazon Titan or other embedding models by language, domain fit, quality, dimensionality, and cost.

Core idea

An embedding model defines the coordinate system in which your documents and queries become comparable. The right choice retrieves the required evidence for your workload’s languages and terminology within your storage, latency, and cost constraints. A model’s input capacity or vector length alone does not establish that fit.

Amazon Bedrock supplies embedding inference; the vector database performs similarity computation and retrieval. Separate model quality from index configuration. First compare models on representative evidence retrieval, then validate the winning model with the intended vector-store integration. Batch compatibility belongs to 1.5.4, and store setup belongs to 1.5.5.

How it works

Check the language and domain boundary

Amazon Titan Text Embeddings V2 uses model ID amazon.titan-embed-text-v2:0. AWS describes it as optimized for English, lists more than 100 languages in preview, and warns that cross-language queries can return suboptimal results. Do not translate a long language list into a guarantee that a German query retrieves a Korean document as accurately as an English-to-English query.

Evaluate language pairs that actually occur in your application. A same-language corpus, a multilingual corpus queried in one common language, and a corpus queried across language boundaries are distinct workloads. Include abbreviations, product codes, specialist terms, and ambiguous words in the labeled query set. A model that performs well on general prose can still confuse two domain-specific procedures whose wording overlaps.

Cohere Embed English (cohere.embed-english-v3) is an alternative demonstrated in the Embed v3 parameter documentation. AWS’s Embed Multilingual model card identifies the multilingual candidate as cohere.embed-multilingual-v3. Treat the multilingual option as a candidate for testing, not as evidence of universal cross-language correctness. Verify the selected model’s availability and interface rather than assuming every embedding provider shares Titan’s request format or input limits.

Domain fit is an empirical property in this decision. Label which source passages answer each query, then compare whether they appear in the retrieved candidates. Include cases where there is no valid source and cases where a similar document belongs to a different product version. The desired result is evidence discrimination, not an embedding vector that merely looks valid. Use an Amazon Bedrock retrieve-only RAG evaluation job to compare retrieved data from knowledge bases that differ only in their embedding model; see 5.1.8 for retrieval evaluation and metrics. For image, audio, or video evidence, evaluate a native multimodal embedding path rather than assuming text extraction preserves every required modality; see 1.5.1.

Preserve the model-specific request contract

Titan V2 takes a nonempty inputText and supports up to 8,192 tokens or 50,000 characters. Both documented limits matter; a character estimate is not a substitute for the model’s token boundary. AWS recommends segmenting documents into logical passages for retrieval even though the model accepts long inputs.

Its optional dimensions values are 1024, 512, and 256, with 1024 as the default. normalize defaults to true. embeddingTypes accepts float, binary, or both, and defaults to float. The response includes inputTextTokenCount and embeddingsByType; the ordinary embedding field is absent for a binary-only request. These are representation choices that the consuming vector store must support.

Cohere Embed v3 accepts a texts array with up to 96 texts per call. AWS documents a 512-token maximum for each text, alongside a 2,048-character limit. Its retrieval input roles are explicit: use input_type: search_document for corpus passages and input_type: search_query for queries. Those complementary roles belong to the same retrieval system; they are not a reason to use unrelated models for the two sides.

Cohere’s truncate parameter accepts NONE, START, or END; END is the default. NONE returns an error for an input exceeding the token limit. Select that behavior when silent omission of an exception would invalidate a passage, and make your chunk preparation satisfy the limit. The floating-point response contains 1,024 elements per embedding. Do not carry Titan’s configurable dimensions into this model’s interface.

Compare dimensionality without inventing quality guarantees

For Titan V2, test all dimension settings that meet your store requirements. Reducing the dimension count reduces the number of coordinates per vector, but total index size also includes metadata and index structures. It does not prove a proportional reduction in total database cost or model inference price.

Compare retrieval outcomes before accepting the smaller representation. Record whether required passages appear in the first candidate set and whether closely related but incorrect passages displace them. Hold chunking, corpus contents, and query labels constant so the experiment can identify the embedding change rather than an unrelated ingestion change.

Normalization and similarity settings are part of this experiment. Store the chosen normalize value with the model configuration and apply the intended query-side behavior. Do not combine measurements from incompatible representations and conclude that a model is worse. An integration error can look like a quality regression.

Calculate the cost of the retrieval workload

Use the Amazon Bedrock pricing page for the selected model and processing mode. AWS’s Cohere embedding pricing example charges for input tokens; embedding cost is not the price of a generated answer. Include initial corpus embedding, recurring document changes, query embeddings, and any full re-embedding required by a model replacement.

Also include vector storage and search in the workload comparison. A lower per-token model price can lose its advantage if it requires more candidates or additional processing to meet the evidence-quality target. Conversely, a larger representation is not justified solely because it is larger. Compare cost per successful evidence retrieval at the required latency, using a declared acceptance criterion.

Avoid quoting a universal dollar rate for every model or Region. Build the estimate from the applicable provider entry and the workload’s measured input volume. For general model benchmarking discipline, see 1.2.2; here the success condition is retrieval evidence rather than answer fluency.

Key distinctions and trade-offs

Use a comparison that separates eligibility from measured quality:

A multilingual model can improve eligibility without settling quality. A high-quality model can still be unusable if its output type or dimension is incompatible with the selected Knowledge Bases store. Make both decisions explicit.

Architecture / decision scenario

A support assistant serves English maintenance articles and multilingual product notices. Specialist abbreviations frequently resemble unrelated product identifiers. The team tests Titan V2 for English retrieval and Cohere Embed Multilingual for the multilingual workload.

It holds chunks constant, labels correct passages by product version, and tests both same-language and cross-language questions. Titan’s 256-dimensional configuration meets the English target with less vector data than its 1,024-dimensional configuration. The team does not assume that this also changes its token price. For multilingual notices, it tests Cohere’s search_document and search_query roles and rejects silent truncation through truncate: NONE.

The selected configurations must pass the full store-backed benchmark. The team includes re-embedding the existing corpus in the cost estimate, rather than reporting only the price of future query embeddings. Its release record identifies the model, input contract, dimension, representation, and evaluation set.

Common exam traps

• Treating Titan’s preview language coverage as equal-quality cross-language support.
• Selecting the longest vector without measuring evidence retrieval.
• Assuming a smaller dimension automatically lowers embedding token prices.
• Using Cohere’s document role for both documents and queries.
• Copying Titan’s dimensions parameter into another provider’s request.
• Comparing models while silently truncating different parts of the corpus.

What to remember

• Choose embeddings for the workload’s languages, domain, and evidence needs.
• Titan V2 supports configurable dimensions and normalization.
• Cohere Embed v3 uses explicit document and query roles.
• Model output must match the vector store’s representation contract.
• Compare ingestion, query, storage, and migration costs together.

Knowledge check

References

• AWS, Amazon Titan Text Embeddings models

• AWS, Amazon Titan Embeddings G1 - Text

• AWS, Cohere Embed v3

• AWS, Amazon Bedrock pricing

• AWS, Evaluate the performance of RAG sources using Amazon Bedrock evaluations