Building an E-commerce AI Agent with AWS Serverless: Building Product Search and RAG (3/7)
Build a serverless product ingestion pipeline with embeddings, vector search, reranking, and automated updates.
Series: Building an E-commerce AI Agent with AWS Serverless (7 articles)
- …
- 3Building an E-commerce AI Agent with AWS Serverless: Building Product Search and RAG (3/7) This article
From Product Pages to Vector Search
An essential part of our AI agent is Retrieval-Augmented Generation (RAG). It allows the agent to answer questions and recommend products using actual webshop data rather than relying solely on the LLM's training knowledge. We already explained how RAG and different search methods work in Part 1: Understanding AI Agents , in the section Search and Retrieval-Augmented Generation (RAG).
To make RAG work, we need to prepare our product data and generate embeddings that allow us to search products by meaning. This means collecting product pages, cleaning their content, splitting it into chunks when necessary, generating embeddings, and storing everything in a vector database.
In this chapter, we'll build a serverless data ingestion pipeline for this process. We'll also explore embedding and reranking models, compare vector database options, and discuss how to keep our product data up to date.
Collecting and Cleaning Product Data
The first step is to collect product information from our webshop. Ideally, we would get this data directly through an export, feed, or API. Structured data is easier to process and more reliable than extracting information from HTML pages.
However, one of our goals is to integrate the AI agent into an existing webshop with as few changes as possible. Scraping publicly available product pages may therefore be the simplest approach.
There are several ways to download product pages:
HTTP requests: The simplest and cheapest option. Works well for pages where the content is already available in the HTML.
Headless browser: Some websites render content using JavaScript or use Cloudflare and other bot protection. A real browser can render these pages and may handle simple bot protection challenges.
Running Chromium inside AWS Lambda is possible, but it can be unreliable. Amazon Bedrock AgentCore Browser provides a managed browser that we can control using Playwright. It also turns out to be reasonably affordable at moderate scale.
From raw HTML we need to extract the useful information and convert it into clean text, preferably Markdown. This includes product names, descriptions, features, specifications, and other relevant details.
Preparing Content for Embeddings: Chunking
Before generating embeddings, we need to decide how to organize the collected content in our vector database.
Ideally, each record should represent a single meaningful piece of information. If we embed an entire large document, its vector may represent several unrelated topics, making it harder to find the relevant information.
This is where chunking comes in. A chunk is a piece of text that we convert into an embedding and store as a searchable record.
For our e-commerce AI agent, one product should ideally be one chunk, containing its name, description, and main features. Additional information, such as product ID, URL, brand, or size, can be stored as metadata.
However, longer product descriptions, manuals, and articles may contain several distinct topics. In these cases, splitting the content into smaller chunks can improve retrieval accuracy.
Common chunking strategies include:
- By headings: Split content into logical sections.
- By length: Split text into chunks of a fixed number of tokens, optionally with some overlap to preserve context.
- By meaning: Group sentences that discuss the same topic.
How large should chunks be? There is no universally optimal chunk size. Small chunks may lack context, while large chunks may contain unrelated information and consume more of the LLM's context window. A practical starting point is 300–600 tokens per chunk (roughly 200–450 English words), with an upper limit of approximately 1,000 tokens before splitting longer sections. These are guidelines, not strict rules. A short product description can remain a single chunk, even if it contains only 100 tokens. Ultimately, the best chunk size depends on our content and should be evaluated using real customer search queries.
Building a Serverless Data Ingestion Pipeline
We need a pipeline that automatically processes product data and keeps our vector database up to date.
We'll build a serverless ETL pipeline using AWS Lambda, SQS, S3, and DynamoDB Vector Search. It consists of three main stages: downloading product pages, converting HTML to Markdown, and generating embeddings.
How the pipeline works
- Discover product pages: It discovers product URLs and sends each one to an SQS queue.
- Download HTML: A Lambda downloads each page using HTTP requests or a headless browser when necessary, then saves the raw HTML to S3.
- Convert HTML to Markdown: An S3 event notification sends a message to an SQS queue. A Lambda cleans the HTML and stores the resulting Markdown in S3.
- Generate embeddings: Another S3 event notification triggers the next queue. A Lambda checks whether the content has changed and generates embeddings only when needed.
- Store in vector database: The embeddings and product metadata are stored in DynamoDB Vector Search, ready for semantic search.
Each SQS queue has a dead-letter queue (DLQ) for messages that repeatedly fail. Because intermediate results are stored in S3, we can retry individual stages without restarting the entire pipeline.
Lambda workers must handle duplicate messages safely. Product IDs and content versions help make processing idempotent, while partial batch responses allow failed messages to be retried independently.
Content hashes let us skip unchanged products, avoiding unnecessary embedding generation.
Embedding and ranking models
We covered how embeddings, vector search, and reranking work in Part 1: Understanding AI Agents , in the section Search and Retrieval-Augmented Generation (RAG). Part 7: The Sample Application shows the embedding and product-search implementation in the sample application.
Choosing the right embedding and reranking models is an important part of building a good product-search experience. If we are not building exclusively for English, language support should be one of the first selection criteria. Strong English benchmark results do not guarantee the same retrieval quality in other languages, especially those with richer morphology.
For this type of application, embedding price is usually not a major consideration. Documents are embedded mainly during indexing and when content changes, while user queries are short. Embedding cost is therefore generally small compared with the LLM calls made by the agent. Retrieval quality and latency should matter more.
Good managed multilingual embedding options include:
- Voyage AI: voyage-4-large, voyage-4, voyage-4-lite
- Cohere: embed-v4.0
- Google: gemini-embedding-2
- Jina AI: jina-embeddings-v5-text-small
- OpenAI: text-embedding-3-large Good managed multilingual reranking options include:
- Cohere: rerank-v4.0-pro
- Voyage AI: rerank-3 (currently in Preview; rerank-2.5 is the established alternative)
- Jina AI: jina-reranker-v3.5
Query and document embeddings
Some embedding models distinguish between queries and documents. Voyage, for example, exposes an
input_type parameter with query and document values. This matters because a search query and the document that answers it can be written very differently. The model can optimize the two representations for asymmetric retrieval: one vector represents what the user is looking for, while the other represents information that could satisfy that request. This usually improves retrieval compared with embedding both as generic text.Embedding models usually cannot be mixed
Documents and queries normally need to be embedded using the same model. Different models learn different vector spaces, so their vectors are generally not comparable even when they have the same number of dimensions. Changing the embedding model therefore normally means re-embedding the documents, updating the vector index, and using the new model for queries.
There are exceptions. The Voyage 4 family uses a shared embedding space, so voyage-4-large, voyage-4, and voyage-4-lite embeddings are compatible when matching dimensions are used. This enables a useful optimization: documents can be indexed with voyage-4-large for maximum quality while high-volume queries can use the faster and cheaper voyage-4-lite, without rebuilding the document index.
Choosing a Vector Database
AWS offers several databases with vector search capabilities.
DynamoDB Vector Search
With the introduction of native vector indexes in August 2026, DynamoDB has become one of the most attractive options for serverless vector search.
It provides single-digit-millisecond similarity search, automatic scaling, and usage-based pricing. If our product data already lives in DynamoDB, we can store embeddings alongside other attributes, eliminating the need for a separate vector database.
For our e-commerce AI agent, DynamoDB Vector Search is probably the best fit.
S3 Vectors
S3 Vectors is a cheaper, cost-optimized alternative, but search latency is higher. It is a bit more suitable for background workloads and agents that are not directly user-facing.
OpenSearch Service / OpenSearch Serverless
OpenSearch is interesting when we need more advanced search capabilities, including full-text, vector, hybrid, and sparse neural search, filtering, and advanced ranking.
OpenSearch Serverless is not truly serverless. It uses OpenSearch Compute Units (OCUs) for billing. Newer collections can scale to zero, but restarting capacity introduces cold-start latency.
Other AWS vector databases:
- Aurora PostgreSQL with pgvector
- RDS PostgreSQL with pgvector
- ElastiCache for Valkey
- MemoryDB
- DocumentDB
- Neptune Analytics
PostgreSQL with pgvector is especially interesting if our data already lives in PostgreSQL.
Bedrock Knowledge Bases
Amazon Bedrock Knowledge Bases provides a managed RAG solution that handles document ingestion, chunking, embedding generation, indexing, and retrieval.
AWS offers two types of Knowledge Bases:
- Customer-managed Knowledge Base: We choose and manage the vector database, such as OpenSearch, Aurora PostgreSQL, or S3 Vectors. Data can be ingested from S3 or through a custom connector/API.
- Bedrock Managed Knowledge Base: AWS manages the entire storage and retrieval infrastructure, including embeddings, indexing, and retrieval. We don't need to provision or manage a vector database. It supports a wider range of data sources, including S3, SharePoint, Confluence, Google Drive, OneDrive, Web Crawler, and other enterprise applications.
Series: Building an E-commerce AI Agent with AWS Serverless (7 articles)
- …
- 3Building an E-commerce AI Agent with AWS Serverless: Building Product Search and RAG (3/7) This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article