AWSAWS Certified Generative AI Developer - Professional2026-101.4 Design and implement vector store solutions

Align ingest and query embedding contracts

Completed by the knowledge check

Learning objective

Use the Amazon OpenSearch Service Neural plugin to generate embeddings with Amazon Bedrock models at ingest and query time.

Core idea

Neural search moves embedding generation into the search path. At ingestion, a processor turns selected document text into vectors. At query time, a neural query turns the search text into a compatible vector and searches the index. The index stores document embeddings; it does not train the embedding model.

AWS names the capability Neural Search and documents semantic search for OpenSearch Service starting with OpenSearch 2.9. The objective’s “Neural plugin” wording refers to this capability, working with ML Commons connectors and vector search. Amazon Bedrock hosts the embedding model; OpenSearch owns the connector configuration, processing pipeline, and index.

This is an application-managed search design. It is distinct from asking Amazon Bedrock Knowledge Bases to orchestrate ingestion and retrieval; see 1.4.2. Decide which system owns embeddings before configuring both and accidentally processing the same content twice.

How it works

Connect the search service to the embedding model

For managed OpenSearch domains, the console Integrations page offers the Integrate with Amazon Titan Text Embeddings model through Amazon Bedrock CloudFormation template. It creates an IAM role and a Lambda function that has the domain create the connector through ML Commons. AWS provides a separate VPC-domain template and templates for Cohere Embed and Titan Multimodal Embeddings.

An ML connector describes the remote inference call. POST /_plugins/_ml/connectors/_create returns a connector_id. Register a remote model through POST /_plugins/_ml/models/_register, associating that connector with the OpenSearch model resource. The resulting model_id is an OpenSearch identifier, not the Bedrock foundation-model identifier. AWS documents automatic deployment on first invocation starting with OpenSearch 2.13; earlier managed-domain engines require manual deployment of the registered model.

For the documented Titan Text Embeddings V2 connector, protocol: aws_sigv4 signs calls to Bedrock, credential.roleArn names the invoking role, and service_name is bedrock. Its action invokes the Bedrock runtime model endpoint. The connector must translate the processor’s input into the model request and translate the response back into the vector representation the processor expects.

Keep the provisioning caller and the runtime role separate. AWS documents iam:PassRole and es:ESHttpPost for connector creation, plus ML role mapping when fine-grained access control is enabled. Passing a role does not establish that its inference permissions or trust policy are correct. Validate a prediction before sending a corpus through the pipeline.

For semantic field index creation, AWS also documents the remote registration model_config requirement, including model_type: TEXT_EMBEDDING and embedding_dimension. Do not copy the example’s dimension independently of the chosen model configuration.

Define the ingest mapping

The text_embedding ingest processor selects source and destination fields through field_map. Its model_id refers to the registered OpenSearch model. A minimal pipeline body is:

{
  "processors": [
    {
      "text_embedding": {
        "model_id": "EMBEDDING_MODEL_ID",
        "field_map": { "content": "content_vector" }
      }
    }
  ]
}

Replace EMBEDDING_MODEL_ID with the OpenSearch model identifier. content and content_vector are example field names that must match your documents and index mapping. The processor belongs in an ingest pipeline created under /_ingest/pipeline/PIPELINE_NAME; documents must actually pass through that pipeline to receive its vectors.

Define the vector destination as a knn_vector field with a compatible dimension. Keep original chunk text and application metadata beside the vector so retrieval can return usable evidence. Perform source validation and chunk preparation before this processor; it is an embedding step, not a guarantee that a whole document is an appropriate evidence unit.

For Titan Text Embeddings V2, inputText is required. dimensions accepts 1,024, 512, or 256, with 1,024 as the default. normalize defaults to true, and embeddingTypes can request float, binary, or both. Select the intended output explicitly and ensure the connector extracts the representation your index expects.

These choices form an embedding contract: model version, preprocessing, dimensionality, output type, normalization, and index distance configuration. Matching vector length alone is insufficient. Two different models can emit equally long vectors without producing a shared semantic space.

Apply the same contract to queries

A neural query names the vector field, query text, registered model, and candidate count. Its relevant query fragment is:

{
  "neural": {
    "content_vector": {
      "query_text": "How do I replace a damaged part?",
      "model_id": "EMBEDDING_MODEL_ID",
      "k": 10
    }
  }
}

Replace EMBEDDING_MODEL_ID with the registered model compatible with the indexed vectors. Here, k: 10 is an example retrieval choice, not a universal recommendation. The neural path generates the query embedding; a plain vector query supplied with a precomputed vector assigns that responsibility to the caller instead.

Both paths reach the Bedrock model through the same registered model and meet at the same vector field.

Verify query processing separately from indexing. A successful bulk load proves neither that natural-language queries invoke the intended model nor that they search the correct field. Test an identifiable document, an unanswerable question, and a query whose answer depends on metadata constraints. Authorization belongs outside the embedding model; see 1.4.6.

Treat embedding changes as corpus migrations

If you change the model or its vector contract, build a compatible destination and regenerate the affected document embeddings. Route queries to the matching contract only after evaluating retrieval against that corpus. Do not send queries embedded with the replacement model to vectors produced by the previous one merely because both fields have the same length.

The failure boundary also changes with this architecture. Inference failures can interrupt ingestion or query processing. Preserve source identifiers and a repeatable ingestion process so failed work can be retried without losing traceability. If query embedding fails, return an explicit application failure or a separately validated fallback; an empty answer is not evidence that the corpus lacks relevant content.

Key distinctions and trade-offs

Connector versus model: The connector defines the remote call. The registered model gives processors and queries an OpenSearch resource to reference. Neither resource contains locally trained Bedrock weights.

Ingest versus query pipeline: Ingest-time embeddings persist document representations. Query-time embeddings represent the question. Search-result processing, such as hybrid search combining lexical and semantic scores, is a separate concern.

Managed domain versus Serverless: AWS documents neural search for both, but Serverless supports only remote models and does not require deploying or removing those models. Use its own permission and capability documentation rather than transferring every managed-domain operation unchanged.

Moving inference into search reduces application-side embedding orchestration, but couples search availability to the remote model path. Evaluate that dependency under representative ingestion and interactive query load.

Architecture / decision scenario

A maintenance assistant uses a managed OpenSearch domain and approved text chunks from manuals. The team uses the console Integrations template to create the connector, registers a Titan V2 connector-backed model, chooses 512-dimensional float embeddings, maps content to content_vector, and checks that the stored vector length matches the mapping.

Queries use the registered model through neural, with the same dimensionality and normalization contract. When a replacement embedding model is proposed, the team builds a separate index and compares retrieval on repair questions, ambiguous part names, and unanswerable requests. It switches the query and index together after the evidence passes.

A proposed Serverless deployment receives a separate review of remote-model setup and permissions. The team does not carry over local deployment assumptions from the managed domain.

Common exam traps

Supplying a Bedrock model name where OpenSearch expects model_id.
Creating a connector without registering a model for the processor.
Assuming pipeline creation automatically embeds existing records.
Treating equal dimensions as proof of embedding compatibility.
Confusing a generative model with an embedding model.
Treating query-time inference failure as “no matching documents.”

What to remember

Connect, register, map, ingest, and query are distinct responsibilities.
Keep the document and query embedding contracts compatible.
Name text_embedding, field_map, knn_vector, and neural precisely.
Rebuild derived vectors when the embedding contract changes.
Verify managed-domain and Serverless behavior separately.