Vector Embeddings

3 posts

aws3 min readCurated summary

Amazon DynamoDB now supports real-time vector search at any scale | Amazon Web Services

Amazon DynamoDB now offers native vector search, allowing applications to store embeddings beside operational data and query them without a separate vector database. The serverless service provides single-digit millisecond latency, 99%+ recall, horizontal scaling, and support for trillions of vectors. This removes synchronization pipelines, data movement, and additional infrastructure for applications already built on DynamoDB. ## Native Vector Search in DynamoDB - Embeddings are stored directly in DynamoDB as lists of floating-point numbers. - Similarity searches use the `SearchVectors` API and return up to 100 ranked results. - Vector indexes scale horizontally without storage limits or servers to manage. - Pricing follows DynamoDB’s pay-per-request model. - Common use cases include: - Agent memory - Retrieval-augmented generation - Recommendations - Personalized experiences - Anomaly detection ## Supported Search Capabilities - Supports vectors with up to 4,096 dimensions. - Offers three distance functions: - **Cosine**: Useful for semantic text similarity. - **Euclidean**: Useful when vector magnitude is meaningful. - **Dot product**: Useful when both direction and magnitude affect relevance. - Supports optional partition keys to distribute data and scope searches. - Supports inline exact-match filters, but not range operators such as `BETWEEN` or `BEGINS_WITH`. - Search results can include operational attributes through index projections. ## Adding Embeddings to an Existing Table - Generate embeddings with a model such as Amazon Bedrock Titan Text Embeddings, Cohere Embed, or OpenAI embeddings. - Store them in a new attribute, such as `descriptionEmbedding`, using `UpdateItem` or other AWS tooling. - No new DynamoDB data type or schema migration is required because vectors use the existing `List` and `Number` types. ## Creating and Using a Vector Index - Create a vector index on the embedding attribute. - Configure: - Index name - Vector attribute - Embedding dimensions - Distance function - Optional partition key - Filter attributes - Generate a query embedding with the same model used for stored data. - Call `SearchVectors` with the query vector, result count, partition key, and filters. - Scores depend on the distance function: - Lower scores indicate greater similarity for Cosine and Euclidean distance. - Higher scores indicate greater similarity for Dot product. ## Example: Product Catalog Search - A `ProductCatalog` table stores product details such as `productId`, `name`, `description`, `category`, `marketplace`, and `price`. - Product descriptions receive embeddings stored in `descriptionEmbedding`. - A `ProductDescriptionIndex` can use: - `marketplace` as the partition key - `category` as an inline filter - Cosine distance for semantic matching - A query such as “lightweight running shoes for summer” can return the five most relevant footwear products in the US marketplace, along with attributes such as name and price. DynamoDB vector search is best suited to applications whose operational data already resides in DynamoDB and need semantic retrieval without operating a second database or synchronization system.

Read original(opens in new tab)
pinterest3 min readCurated summary

PinLanding: Turn Billions of Products into Instant Shopping Collections with Multimodal AI

PinLanding is a production pipeline for turning billions of products into searchable shopping collections using multimodal AI. Rather than relying mainly on historical queries or manual curation, it derives structured product attributes from images and metadata, then aligns those attributes with real user search behavior. The system combines multimodal LLMs, embedding-based consolidation, a CLIP-style classifier, and distributed infrastructure to produce scalable, precise shopping feeds. ## Understanding Shopping Intent - Pinterest analyzes search history, autocomplete use, filters, and browsing paths to estimate shopping demand. - Existing systems handle high-volume queries such as “black cocktail dress” well, but provide weaker coverage for: - Long-tail queries - Conversational requests - Contextual intents such as “what to wear for an Italian summer vacation” - The analysis identifies: - Product areas with strong demand but poor collection coverage - Important attribute dimensions, including color, occasion, style, fit, price, and brand - The goal is to expand and improve collection coverage, not replace query understanding. ## Generating and Curating Shopping Topics - Each product is represented by an image plus metadata such as title, description, merchant tags, and price. - A vision-language model generates normalized key-value attributes rather than free-form descriptions. - Raw model output has high recall but produces: - Excessively specific attributes - Near-duplicates such as “boho,” “bohemian,” and “boho-chic” - Sparse attributes that apply to very few products - PinLanding builds a compact vocabulary through: - Frequency filtering to remove rarely useful attributes - Embedding-based clustering to merge semantically similar terms - Manual and LLM-assisted review - An LLM judge evaluates generated topics for semantic coherence, realistic shopping intent, and alignment with natural search phrasing. ## Scalable Attribute Assignment - Running the vision-language model over every product is too expensive and operationally fragile. - PinLanding trains a CLIP-inspired dual encoder: - One encoder embeds product images and text - Another embeds attribute phrases - Matching product-attribute pairs are trained as positives, while mismatches are negatives - A bidirectional contrastive loss aligns related products and attributes. - At inference, products and attributes are embedded once, and attributes are assigned when similarity exceeds a calibrated threshold. - This produces fewer distinct attributes while increasing the average number assigned to each product, creating a denser and more consistent attribute graph. ## Distributed Feed Construction - Ray handles large-scale batch inference across millions of products and topics. - The pipeline separates: - CPU-based image and metadata loading, tokenization, and serialization - GPU-based classifier inference - Streaming allows preprocessing and inference to overlap, while heterogeneous CPU and GPU clusters can scale independently. - The classifier pipeline reportedly completes in about 12 hours using eight NVIDIA A100 GPUs, at an estimated cost of roughly $500 per training run. - Feed construction uses approximate-nearest-neighbor techniques and strict attribute matching. - Topics are represented as attribute tuples, such as: - Category: dress - Color: yellow - Season: summer - Occasion: party - Apache Spark computes topic-product relevance using shared attributes and confidence weights, with partitioning and overlap filters reducing unnecessary candidate comparisons. The core recommendation is to combine user-behavior signals with content-first multimodal modeling. This approach can expand shopping coverage into conversational and long-tail intents while remaining practical through attribute consolidation, contrastive retrieval, and distributed inference.

Read original(opens in new tab)
googleOriginal article

MUVERA: Making multi-vector retrieval as fast as single-vector search (opens in new tab)

MUVERA is a state-of-the-art retrieval algorithm that simplifies the computationally intensive process of multi-vector retrieval by converting it into a single-vector Maximum Inner Product Search (MIPS). By transforming complex multi-vector sets into Fixed Dimensional Encodings (FDEs), the system maintains the high accuracy of models like ColBERT while achieving the speed and scalability of traditional search infrastructures. This approach allows for efficient retrieval across massive datasets by leveraging highly optimized geometric search techniques that were previously incompatible with multi-vector similarity measures. ## The Limitations of Multi-Vector Retrieval While traditional models use a single embedding for an entire document, multi-vector models generate an embedding for every token, providing superior semantic depth but creating significant overhead. * Multi-vector representations lead to a massive increase in embedding volume, requiring more storage and processing power. * Similarity is typically calculated using "Chamfer matching," a non-linear operation that measures the maximum similarity between query tokens and document tokens. * Because Chamfer similarity is more complex than a standard dot-product, it cannot directly use sublinear search algorithms, often necessitating expensive exhaustive comparisons. ## Fixed Dimensional Encodings (FDEs) The core innovation of MUVERA is the reduction of multi-vector sets into a single, manageable vector representation that preserves mathematical relationships. * FDEs are single vectors designed so that their inner product closely approximates the original multi-vector Chamfer similarity. * The transformation process is "data-oblivious," meaning the mapping does not need to be trained on or adjusted for specific datasets or changes in data distribution. * By squeezing group information into a fixed-length format, MUVERA allows complex data points to be stored and queried using existing single-vector indexing structures. ## The MUVERA Retrieval Pipeline The algorithm functions as a multi-stage process that prioritizes both speed and precision through a retrieve-and-rerank architecture. * **FDE Generation:** Query and document multi-vector sets are mapped into FDEs to capture essential similarity information. * **MIPS-based Retrieval:** A standard MIPS solver indexes the document FDEs and rapidly identifies a set of likely candidates for a given query. * **Re-ranking:** The initial candidates are refined using the original, exact Chamfer similarity score to ensure the highest possible accuracy in the final results. MUVERA provides a practical framework for scaling high-accuracy multi-vector models to massive datasets without the traditional latency penalties. Its ability to bridge the gap between complex semantic modeling and optimized search infrastructure makes it a versatile tool for modern information retrieval systems.