To store and access multiple embedding types per product, you need a structured approach that separates embeddings by type while maintaining clear associations with the product. Start by designing a database schema that includes a table for products and a related table for embeddings. The embeddings table should have columns for the product ID, embedding type (e.g., “text,” “image,” “user_behavior”), and the vector data. For example, in a PostgreSQL database, you might use a product_embeddings table with a vector column (using the vector extension), a product_id foreign key, and an embedding_type string. This structure allows you to store multiple embeddings per product, each tagged with a type identifier. If using a vector database like Pinecone, you can organize embeddings into separate namespaces or collections per type, linked to a product ID metadata field.
Accessing these embeddings requires querying by both product ID and embedding type. For relational databases, a simple SQL query like SELECT vector FROM product_embeddings WHERE product_id = 123 AND embedding_type = 'text' retrieves the specific embedding. In vector databases, you might use an API call that specifies the namespace or filter criteria (e.g., pinecone.Query(namespace="text", filter={"product_id": "123"})). To optimize retrieval, consider caching frequently accessed embeddings in a key-value store like Redis, using composite keys such as product:123:embedding:text. For applications like search or recommendations, you might fetch all embeddings for a product at once and process them in memory, or selectively load the type needed for a specific task (e.g., image embeddings for visual similarity checks).
Performance and scalability depend on indexing and storage choices. In relational databases, add indexes on product_id and embedding_type to speed up lookups. Vector databases inherently optimize for similarity searches but benefit from partitioning data by type to reduce query scope. Precompute embeddings during product ingestion to avoid runtime latency, and version them (e.g., embedding_type = 'text_v2') if models change over time. For security, restrict access at the application layer—ensure services fetching user-behavior embeddings have higher privileges than those accessing public text embeddings. Tools like Hugging Face’s sentence-transformers or OpenAI’s API can generate embeddings, which you then store with type labels, enabling flexible reuse across tasks like search, recommendations, or clustering without recomputation.