Loading project
Preparing this case study...
Preparing this case study...
A FastAPI and pgvector backend that ingests e-commerce product catalogues and answers product questions through a strict OpenAI-powered RAG pipeline.
Project Snapshot
Technical Footprint
Ecommerce Backend AI Assistant is a FastAPI backend that gives online stores an AI-powered product question-answering layer.
The system is built around a multi-tenant RAG pipeline. A store can ingest its product catalogue through the backend, the system stores the products in PostgreSQL, generates product embeddings with OpenAI, saves them using pgvector, and then answers customer questions using only the retrieved product context.
The core flow is simple but powerful: product catalogue in, natural-language product question out. When a user asks a question, the backend embeds the query, searches the product catalogue using pgvector cosine similarity, reranks the results with keyword matching, builds a structured catalogue context, and sends that context to OpenAI with strict instructions not to invent products or answer outside the available catalogue.
The project includes multi-tenant store isolation using store_id, product ingestion with hash-diff detection, background embedding generation, product retrieval, context assembly, OpenAI response generation, chat session creation, conversation logging, Alembic migrations, integration tests, and Locust load testing.
A key technical detail is the ingestion engine. Products are compared using a SHA-256 hash of their core fields, so unchanged products are skipped and do not need to be re-embedded. That makes catalogue refreshes more efficient and avoids unnecessary OpenAI embedding calls.
The backend also stores conversation messages with the context used and latency, which makes the assistant easier to inspect and debug. This turns the project into more than a basic chatbot demo it is a backend skeleton for a product-aware e-commerce AI assistant.
This is not a full e-commerce platform yet. It does not include authentication, payments, order lookup, product updates, customer accounts, a frontend widget, or Shopify/WooCommerce connectors. It is also not fully agentic because it does not take actions or use tools. Its real value is the backend RAG architecture for product catalogue Q&A.
I built the FastAPI backend structure, including the product ingestion endpoint, catalogue question-answering endpoint, database models, Pydantic schemas, and service layer.
I implemented the multi-tenant RAG pipeline: product ingestion, hash-diff detection, embedding generation, pgvector similarity search, keyword reranking, context assembly, OpenAI response generation, and conversation logging.
I designed the database structure around stores, products, embeddings, sessions, messages, and store settings, with Alembic migrations to support the schema.
I also added integration tests, a load test, development seed scripts, and safeguards for test mode so the system can be tested without making live OpenAI calls.
One of the main challenges was building the assistant around real catalogue data rather than generic AI answers. The system needed to make sure the model answered only from the store’s own product catalogue and did not invent products, prices, or details.
Another challenge was making catalogue ingestion efficient. Product catalogues can change often, so the backend needed a way to detect which products had changed and only regenerate embeddings where necessary. The hash-diff approach helps avoid unnecessary processing and repeated embedding calls.
Multi-tenant isolation was also important. The backend is designed so multiple stores can exist in the same system, with product retrieval, sessions, messages, embeddings, and settings scoped by store_id.
A further challenge was balancing vector search with practical keyword matching. Semantic retrieval helps with natural language questions, but exact or partial product name matches still matter in e-commerce. The system combines pgvector search with keyword reranking to improve product relevance.
A current limitation is that the project is not production-secure yet. There is no authentication, no API key validation, no rate limiting, and the endpoints are open. The project also has a hardcoded SKU filter that would need to be removed or generalised before real store onboarding.
This project provides the backend foundation for an AI shopping assistant that can answer customer questions from a store’s own product catalogue.
It could support e-commerce widgets, product discovery tools, support assistants, buying guides, and catalogue-aware customer chat experiences.
As a portfolio project, it shows strong backend AI architecture: FastAPI, PostgreSQL, pgvector, SQLAlchemy, Alembic, OpenAI embeddings, OpenAI chat, retrieval logic, context building, multi-tenant scoping, conversation logging, integration tests, and load testing.
It also demonstrates a commercially relevant pattern. Many e-commerce stores need product-aware AI assistants, but the assistant is only useful if it can stay grounded in the actual catalogue.
This project helped me understand the full RAG backend pattern in a practical business context: ingestion, embeddings, vector storage, retrieval, context assembly, model prompting, response generation, and logging.
I learnt that the most important part of an e-commerce AI assistant is not the chat interface. It is the backend data pipeline that keeps catalogue context clean, scoped, searchable, and auditable.
The project also reinforced the importance of tenant boundaries. Every query, embedding, session, and message needs to be scoped to the right store, otherwise the assistant could leak or mix product data across stores.
Another learning was that RAG systems need operational discipline. You need migrations, tests, seed data, fallback paths, logging, and load testing before the project becomes more than a simple AI demo.
I help founders and teams turn messy ideas into reliable systems — from MVPs and APIs to AI-enabled automation workflows.