ThreadSense — Conversational Shopping Copilot
Inspiration
Shopping is naturally conversational. A customer may start with “I need blue running shoes,” then refine the request with “Actually, make them black” or “I need something cheaper.” Traditional search often treats these as separate queries and loses the context behind the change.
ThreadSense is built to understand this evolving intent. It combines structured conversational state with catalog-grounded retrieval, so every recommendation remains valid, relevant, reproducible, and connected to the user’s latest preferences.
What It Does
ThreadSense is a multi-turn shopping assistant for the Clothing, Shoes, and Jewelry catalog. It can:
- Extract shopping preferences including category, colour, material, size, budget, brand, style, features, and use case.
- Maintain structured state across a conversation instead of treating every message independently.
- Detect browsing versus buying intent.
- Recognize explicit preference changes such as “actually,” “instead,” and “ignore my earlier preference.”
- Return a valid, deduplicated Top-10 list from real catalog products.
- Ask one candidate-informed clarification question when it can meaningfully narrow the search.
- Run fully offline by default, with no cloud dependency, API key, or model-token cost.
- Optionally use a local Qwen model through Ollama to identify narrowly scoped, explicitly stated supplementary details.
How We Built It
ThreadSense uses a retrieval-first architecture designed for reliability:
Customer message
↓
Deterministic preference extraction
↓
Structured conversation-state update
↓
Intent routing and override handling
↓
Optional local LLM supplement
↓
SQLite FTS5 catalog retrieval
↓
Deterministic reranking
↓
Top-10 recommendations + clarification question
The default engine indexes the local product catalog in an in-memory SQLite FTS5 search database. It retrieves a bounded lexical candidate set and reranks products using structured signals:
- Category and attribute agreement
- Budget compatibility
- Active versus replaced preferences
- Product rating and review volume
- Stable tie-breaking for reproducible output
This ensures recommendations always come from the actual catalog—never hallucinated product IDs or unsupported items.
The optional local LLM path is intentionally constrained. It cannot access the catalog, generate product IDs, control ranking, or override explicit customer preferences. Its only role is to add a literal feature, brand, style, or use-case detail that is explicitly present in the latest user message. If it fails, times out, or returns invalid output, ThreadSense immediately falls back to the offline system.
Challenges we ran into
The central challenge was balancing flexible language understanding with trustworthy product retrieval.
A purely lexical system can struggle with paraphrases and unusual product wording. On the other hand, allowing a language model to control retrieval can introduce hallucinations, unpredictable results, latency, and cost.
ThreadSense addresses this through a layered design:
- Deterministic logic owns the important decisions: state, retrieval, reranking, catalog validation, and explicit overrides.
- Local AI is optional and limited: it assists only with narrowly defined language understanding.
- Conversation state is structured: outdated preferences can be replaced or negated instead of being blindly accumulated.
For example:
“I need blue shoes.”
“Actually, I need black instead.”
ThreadSense replaces the colour preference while preserving shoes as a soft category hint. This lets the system adapt to the latest request without discarding useful conversation context.
Accomplishments that we're proud of
We are especially proud of building a system that is both conversational and reproducible:
- Built a fully offline deterministic baseline with zero model tokens and no external API requirement.
- Reproduced the final offline evaluation exactly across all 200 public-set sessions.
- Designed robust multi-turn state tracking and explicit preference-override handling.
- Ensured every recommendation is a valid, deduplicated item from the product catalog.
- Added a safe local-AI enhancement without sacrificing deterministic retrieval.
- Improved the Technical Score substantially from the initial system.
| Metric | Initial Version | Final Offline | Optional Local LLM |
|---|---|---|---|
| HitRate@10 | 0.125 | 0.575 | 0.620 |
| MRR | 0.068 | 0.407 | 0.388 |
| MTTC | 9.810 | 7.125 | 6.625 |
| Technical Score | 0.107 | 0.487 | 0.514 |
| Model Tokens | 0 | 0 | 273,432 |
What We Learned
This project showed us that strong conversational search depends on more than retrieval quality.
- State matters. Tracking the lifecycle of each preference is more reliable than concatenating the entire conversation into one query.
- Grounded retrieval matters. Deterministic catalog retrieval prevents invalid products and keeps results explainable.
- Constrained AI can be valuable. A local model is most useful when it supports a clearly bounded language task rather than replacing the retrieval pipeline.
- Reranking improves robustness. A broad candidate pool followed by structured ranking handles incomplete catalog metadata better than overly restrictive filters.
What’s Next
Given more time, we would extend ThreadSense with:
- Local embedding-based semantic retrieval and reranking.
- Stronger synonym normalization for categories, colours, materials, brands, and sizes.
- More nuanced handling of multi-constraint preference updates.
- Recommendation explanations that show which active preferences influenced each result.
- A lightweight interactive product-discovery interface.
- Broader local-model evaluation across accuracy, latency, memory use, token usage, and failure rate.
Log in or sign up for Devpost to join the conversation.