I build AI systems in production. Now I want to understand them properly.

At NV Store: AI product description generator

Problem

Writing a good description for every product took time, and quality varied by who wrote it.

Approach

Staff enter what they know: name, material, size, color, a few notes. The system builds a prompt from a fixed template, generates a draft, and puts it in front of a person to accept or edit before it goes live.

What I learned

• A model is one step in a pipeline. Input cleanup and a human review step matter as much as the prompt.
• Consistent output needs explicit structure and examples, not just instructions.

Open questions I’d like to study

• How do you measure description quality in a way that tracks what customers actually read?
• When is a small fine-tuned model better than a large general one for a narrow task like this?

At NV Store: AI customer detail parser

Problem

Customers send their details as free text in chat, mixed Bangla and English, in any order. Moderators had to copy each field into the order form by hand.

Approach

The moderator pastes the raw message into the order screen. A model extracts name, phone, address and order details into a fixed schema. Validation checks the phone format and matches the address against known districts and areas. The form is filled, and the moderator reviews it before saving.

What I learned

• A strict output schema plus validation catches most bad extractions before a person sees them.
• Phone numbers and addresses need rule-based checks after the model, not instead of it.

Open questions I’d like to study

• How should a system express uncertainty per field, so people only check the fields that need it?
• How well do current models handle code-mixed Bangla-English text, and how would you evaluate that fairly?

At NV Store: Vector product search

Problem

Customers and staff often know what a product looks like but not what it is called. Keyword search fails them.

Approach

Each product’s images and text are passed through an embedding model and stored as vectors in MariaDB next to the product row. A search query, typed or uploaded as a photo, is embedded the same way, and the nearest products come back ranked by similarity.

What I learned

• Text and images in a shared embedding space make one search box work for both.
• Keeping vectors next to the product data in MariaDB made filtering and consistency much simpler than a separate store.

Open questions I’d like to study

• How do you evaluate retrieval quality for a small catalog without a labelled dataset?
• How much does domain-specific fine-tuning of the embedding model help versus better product images and text?