IntelliCart | AI and Machine Learning Commerce Capstone

Project Overview

IntelliCart is my final year project at Kabul University, dated July 3, 2025. I built it as a commerce prototype with two connected artificial intelligence features: an optional Gemini assistant that drafts product descriptions for sellers, and a content based recommendation method that compares products using TF IDF and cosine similarity. The aim was to make catalog creation easier for sellers and product discovery more relevant for customers.

The project also includes a customer storefront, a separate seller dashboard, and a Django REST API. Customers can browse products, read details and reviews, and begin a checkout flow. Sellers can manage products and media and inspect orders containing their items. PostgreSQL stores the catalog, accounts, reviews, and orders. The two AI features operate on top of this shared product data rather than in isolated demonstrations.

The research value of IntelliCart is the relationship between those features. A useful recommendation depends on useful product content. Description drafting can help a seller create that content, but the seller must check its accuracy before saving it. The saved title, description, tags, and category then become the evidence used by the recommendation method.

The Problem and Research Approach

Many new stores have little customer behavior data. A recommendation system based on purchase history or browsing patterns cannot do much for a new product or a new customer. IntelliCart therefore explores a content based approach: recommend products whose catalog text is similar to the item a customer is viewing. This gives the system a path to recommendations without first collecting a large interaction history.

Catalog quality creates a second challenge. Sellers must write descriptions that are clear enough for shoppers and informative enough for text comparison. IntelliCart offers AI drafting as an authoring aid, then leaves editing and publication with the seller. These are distinct methods: Gemini generates prose, while TF IDF and cosine similarity compare existing product records. The recommendation code does not train or fine tune Gemini, and it does not personalize results to an individual customer.

System Architecture

The repository contains three applications. A React and Vite storefront handles customer discovery. A second React and Vite application provides seller tools. Django REST Framework manages identity, products, categories, media, reviews, and orders, with PostgreSQL configured as its database. Token authentication protects account operations, and seller product queries are scoped to the authenticated vendor.

This division keeps public browsing separate from catalog administration while allowing both interfaces to use the same product records. The storefront requests recommendations from a Django endpoint when a product detail page is opened. The seller dashboard calls Gemini from the product creation form and saves the reviewed description through the ordinary product API.

How the AI Features Connect

This chart follows the implemented data path. Gemini drafting is optional. A manually written description can enter the same catalog, and recommendations are calculated from saved product records rather than from the model response itself.

The chart is an explanation of the pipeline, not a performance graph. The repository contains no measured recommendation accuracy, conversion improvement, or seller time savings, so I do not assign numbers to those outcomes.

AI Assisted Description Writing

In the seller product creation form, the seller enters a title and can select AI Generate. The form code sends a prompt asking Gemini for a detailed product description based on that title. The configured model is Gemini 2.0 Flash. Its response fills the description field, where the seller can revise the text before submitting the product. Generation does not publish anything automatically.

The prompt currently uses the title alone. It does not provide specifications, media, stock data, or verified manufacturer facts. As a result, the draft may sound plausible without being accurate; seller review is a necessary part of the workflow, not an optional quality check. The Gemini call is made from the dashboard browser using a Vite environment value. A production design would put model access behind an authenticated server endpoint to control credential exposure, usage, and error handling.

Content Based Product Recommendations

The recommendation function first loads the product being viewed and gathers other products from its category. It then builds one text document per candidate from the title, description, tags, and category name. Tags and the category name are repeated in that document to give them more weight in the text representation.

TF IDF converts the documents into vectors that emphasize terms useful for distinguishing products in this small catalog. Cosine similarity compares the target product vector with the candidate vectors. The function excludes the target itself and selects up to five candidate identifiers with the highest computed similarity. A public API endpoint serializes the selected products, and the storefront requests them for the recommended products slider on the product detail page.

This is a reasonable starting method for a catalog without user behavior data, but its boundaries are important. Products are compared only within the same category, and a category containing only the target product produces no recommendations. The vectorizer is rebuilt for each request rather than using a prepared index. The candidate query does not filter unavailable products. Although identifiers are selected by similarity score, the final database query does not preserve that score order, so the displayed order is not guaranteed to be the similarity ranking. Repeating the category term also offers limited distinction when every candidate already belongs to that category.

These observations do not erase the method's value. They define the next research and engineering questions: whether the text features predict human judgments of relevance, how to handle sparse categories, and how to preserve ranking when results are returned to the interface.

Evaluation and Future Improvements

The repository demonstrates the algorithm and its user interface integration, but it does not include a labeled relevance dataset, an experiment against a baseline, or a reported precision score. I would evaluate the next version by asking reviewers to judge related products for a sample of catalog items, then comparing the top five results with a simple category or popularity baseline. I would separately review Gemini drafts for factual accuracy and the amount of seller editing required. Those are proposed evaluations, not results claimed for this version.

An improved implementation would preserve similarity order in the API response, exclude unavailable items, and test what happens when categories have very few products. As the catalog grows, preparing or caching the text representation would avoid fitting the vectorizer again for every product request. For description generation, providing verified product attributes to the prompt and keeping the seller approval step would make the draft more useful without treating generated claims as product facts.

Commerce Experience and Prototype Boundaries

The customer storefront supports category browsing, product details, reviews, cart interactions, a wishlist, and product comparison. Cart, wishlist, and comparison data are stored in the current browser, so those lists are not synchronized across devices. Customers can read reviews, and authenticated customers can submit one review per product.

The seller dashboard provides product and media management together with order views. The backend checks vendor ownership for product operations and derives order item prices from stored products rather than trusting browser supplied totals. Stripe Checkout initiation and a signature checked webhook are present in the backend.

The complete buying experience remains a prototype. The configured success URL points to a storefront route that is not defined, and the cart clears when a payment URL is returned rather than after payment confirmation. Some order history and dashboard chart content uses sample values. The backend requirements file also omits packages imported by the recommendation and filtering code, so a clean setup needs those dependencies before the API can run. Automated tests and verified deployment or transaction results are not provided in the repository. I would resolve these issues before treating IntelliCart as a launched store.

Academic Outcome

IntelliCart was the capstone through which I connected a classical text similarity method, a generative writing assistant, and a multi vendor commerce architecture. My Kabul University project defense record documents the academic presentation and lists 90 marks for the proposal stage and 84 marks for the final defense.

The most important lesson was to distinguish a promising AI feature from a measured result. The code shows how descriptions can be drafted and how related products can be selected and displayed. It also shows where a stronger study needs labeled relevance judgments, factual review of generated text, reproducible setup, and a complete transaction flow. Those boundaries make the project a more useful foundation for further research and development.