Inspiration
What it does## Inspiration
Online shopping rarely starts with a perfect query. A customer may begin with “a jacket,” later mention a budget or material, and then suddenly say “actually, I need shoes instead.” Traditional keyword search treats these messages as isolated filters; it does not reliably preserve useful context or erase preferences that no longer apply.
We built Muse to make conversational shopping more practical under real deployment constraints: it should recommend products on every turn, guide the conversation efficiently, work without a network connection, and remain reproducible in a constrained evaluation environment.
What it does
Muse is an offline conversational shopping Agent for a frozen catalog of
50,000 Clothing, Shoes and Jewelry products. It keeps a structured session
state, accumulates disclosed preferences, detects strong Intent Override
signals, and returns an ordered Top-10 recommendation list on every turn.
For clarification, Muse uses an evaluator-compatible
other-until-exhausted policy. It requests additional preferences while they
are still available, but does not delay recommendations in order to ask
questions. On Turn 10, it stops asking and still returns a valid Top-10 list.
How we built it
Our production pipeline is:
StateManager → SQLite FTS5 Lexical Top-200 → ConstraintRanker → Top-10
RecommendationValidator → QuestionPolicy → official Agent response
StateManager separates preference accumulation from replacement: incremental
messages add constraints, while strong replacement language resets the affected
intent state. SQLite FTS5 provides fast local lexical retrieval over the
catalog. The ConstraintRanker applies structured positive evidence, negative
constraints, budget handling, and cumulative query coverage to the retrieved
candidates.
A key design choice is conservative color handling. A catalog parent_asin
represents a parent product and can cover several SKU variants. Therefore, an
explicit matching color receives a bonus, but a non-matching color is not
treated as a hard filter or negative penalty.
The Agent is written in Python 3.11 and uses the Python standard library,
SQLite FTS5, pytest, Git, and GitHub. We used the organizer-provided frozen
catalog and released local evaluator, which are derived from Amazon Reviews
- We used no external APIs, no external LLM, no model weights, and no hidden-label reconstruction.
Challenges and what we learned
The most difficult part was balancing early conversion with safe conversation state management. Asking too aggressively wastes turns, while treating every new message as an override destroys useful constraints. We also had to ensure that every response remains valid even if retrieval returns no candidates or a component fails at runtime.
We addressed this through deterministic regression tests, explicit fallback contracts, stable catalog-valid Top-10 fallback recommendations, and repeated evaluation against the released simulator. We learned that a lightweight, well-tested lexical system can be both competitive and operationally realistic when its state, ranking, and failure behavior are designed carefully.
Results
On the released 200-session local evaluator, Muse achieved:
- TechnicalScore: 0.759858
- Hit Rate@10: 0.880000
- MRR: 0.554861
- MTTC: 3.330000
- Efficiency: 0.767000
The verified official starter baseline TechnicalScore was 0.106710. These are released local-evaluator results; private-evaluation results may differ.
Muse runs fully offline, reports zero prompt tokens and zero completion tokens, and has an estimated external API cost of $0.
Future improvements
The current system is optimized for the released template-based simulator.
Future work would evaluate semantic parsing and P2-Dense + RRF retrieval only
after runtime, package-size, and model-weight constraints are confirmed. The
main remaining challenge is improving recall after complex Intent Override
events without sacrificing reliability or offline reproducibility.
Log in or sign up for Devpost to join the conversation.