Inspiration
Online shopping often becomes difficult not because there are too few options, but because there are too many. Users may begin with vague requests and gradually discover what they actually want through conversation. We wanted to build a shopping assistant that could understand these evolving preferences.
What it does
- The product catalog is loaded into an in-memory SQLite FTS5 index using fields such as title, categories, features, details, store, and description.
- User requirements are extracted and stored in a multi-turn SessionState, allowing preferences and constraints to accumulate or be updated throughout the conversation.
- The current requirements are converted into a weighted FTS5 query, and BM25 retrieves and ranks relevant products.
- Structured constraints, such as budget and product attributes, are used to further refine the candidate results.
- When additional information would improve retrieval, the agent selects a relevant ask_attribute and asks the user a targeted clarification question.
- LLM usage is optional. If an API key is provided, an LLM can assist with understanding complex user requirements and intent changes. Without one, the agent falls back to the fully local rule-based pipeline and remains functional without network access.
Challenges We Ran Into
One of our main challenges was maintaining requirements across multiple turns. A user may add a preference, contradict an earlier preference, or explicitly say that they no longer care about a particular attribute. We needed to distinguish between adding, replacing, clearing, and resetting requirements without losing valid information.
Another challenge was working with a large catalog containing inconsistent and incomplete metadata. Categories, brands, prices, and product descriptions were not always formatted consistently, so we used normalization, catalog-derived vocabularies, and fallback keyword extraction.
We also had to balance recommendation quality with runtime. Each turn can involve classification, retrieval, reranking, and clarification analysis. Caching product information and reusing the classifier helped reduce repeated computation during evaluation.
What We Learned
We learnt that conversational recommendation involves more than finding keyword matches. The quality of the final recommendation depends heavily on how accurately user intent is extracted, remembered, updated, and converted into search queries.
We also learned the importance of evaluating different parts of the pipeline separately. Dataset analysis and scenario-level metrics helped us identify weaknesses in browsing, intent overrides, clarification, and retrieval rather than relying only on a single overall score.
Last but not least, we truly appreciated the opportunity to work as a team. Experiencing both the joys and challenges of real-time collaboration gave us valuable insight into the teamwork and communication skills that will be essential in the workplace.
Built With
- openai
- python
- vscode
Log in or sign up for Devpost to join the conversation.