How this addresses the problem statement

The problem statement asked for four things: (1) intent routing between a high-precision "Buying" track and a diverse "Browsing" track over a hybrid multi-route pipeline; (2) a dialogue strategy handling incremental slot- filling and abrupt intent override, with proactive clarification when the candidate pool is too broad; (3) runtime self-evolution via dynamic context distillation and re-orchestration; and (4) measurable coverage, precision, and efficiency. Each is addressed directly and measurably: (1) the Buying/Browsing signal is recomputed every turn and continuously reweights the three retrieval routes, not decided once; (2) the slot-filling state machine detects overrides structurally (not just by phrase), and the clarification policy triggers on live entropy/price-variance signals; (3) a plain-text session summary is rebuilt every turn from the current slot state and fed into re-ranking, and failure-detection triggers (stalled narrowing, emptied filters) visibly change strategy mid-session; (4) all four pillars were validated against Hit Rate@10, MRR, and MTTC on the same 200-session harness the organizer provided, not a private benchmark.

What it does

IntentCart is a conversational shopping agent that finds a customer's hidden target product — out of 50,000 real Amazon catalog items — in as few turns as possible. It routes between precise, filter-heavy search for customers who know what they want and broad, meaning-based search for customers who are still exploring; asks clarifying questions chosen by how much they'd actually narrow the current candidates down; detects when a customer changes their mind mid-conversation and recovers gracefully; and explains every recommendation using the same signals that actually produced it, not a generic template.

Result on the 200-session public evaluation set: Hit Rate@10 0.89, MRR 0.452, MTTC 3.65 turns, TechnicalScore 0.728 — versus 0.107 for the provided starter baseline.

How it was built

Retrieval: three routes — SQLite FTS5 keyword search, a category- taxonomy inverted index, and dense vector similarity via a small local sentence-transformer (all-MiniLM-L6-v2) — fused with Reciprocal Rank Fusion, continuously reweighted by a live Buying-vs-Browsing signal.
A category-first hard filter: category is the one attribute the grading simulator discloses for free and reliably every time, so it's used to narrow the search universe before anything else has to discriminate, rather than as just one more soft vote.
Dialogue state: a slot-filling state machine across the 7 attribute types the simulator actually answers, with structural (not just phrase-based) override detection, abstention memory, and fallback capture for anything that doesn't match a known vocabulary.
Adaptive clarification: decides whether to ask a question based on Shannon entropy of the current candidate pool's category spread and price variance, then picks whichever unanswered attribute would split the pool most usefully.
Re-ranking: a Bayesian-shrunk rating prior, profile-tag overlap, session-summary embedding similarity, and IDF-weighted attribute-match boosts (so a boilerplate word like "imported" — on 15,300 of 50,000 products — barely moves the ranking, while a genuinely rare word moves it much more).
Failure detection: a hard filter that would empty the candidate pool gets dropped instead of returning nothing; stalled narrowing triggers a broader search; low-confidence late turns diversify the results instead of clustering around one guess.

Development tools: Python 3.12, developed and tested in a macOS terminal environment.

Libraries and frameworks used: sentence-transformers (the local all-MiniLM-L6-v2 embedding model for dense retrieval), numpy (vector math), and Python's built-in sqlite3 with its FTS5 extension (BM25 keyword search). scikit-learn appears in requirements.txt only as a transitive dependency of sentence-transformers — it is not directly used by our code, and we're not claiming it as one of our tools.

APIs used: none in the shipped path — see "Model choice" below for what

Challenges I ran into

The most valuable parts of this project came from finding real bugs, not adding features. A non-numeric price field on 117 of 50,000 catalog products was silently crashing the ranking pipeline every time it was hit, invisible in aggregate metrics because the evaluator's own exception handling quietly converted each crash into a miss. Fixing it alone was worth +0.035 TechnicalScore. Several plausible-sounding ideas, stopping clarifying questions after repeated "no preference" answers, restricting extraction to only the asked attribute, and a cross-encoder re-ranking stage, were each implemented, measured on the full evaluation set, found to make things worse, and reverted. We also prototyped an optional Gemini API reranking layer with a full offline fallback, then measured its real latency at 40+ seconds per call, impractical for a 10-turn budget, and removed it rather than ship dead weight.

Accomplishments that I'm proud of

Every claimed capability is backed by a measured before/after number, not a description. We also found and fixed a real, previously-invisible crash bug that had been silently costing score since early development.

What I learnt

That "sounds smart" and "measurably helps" are frequently different things several of our best-reasoned ideas made the system worse, and the discipline of testing every change against the same evaluation harness (and reverting without hesitation) mattered more than any single clever technique.

What's next

The clearest remaining opportunity is a small learned ranking model (logistic regression / gradient-boosted trees over hand-engineered features) trained on synthetic conversations generated from the evaluator's own deterministic session-generation logic applied to more catalog products than we have public labels for a genuine Learning-to-Rank upgrade that needs more time than remained to build and validate without overfitting. we tried and why we removed it.

Datasets and assets used: the organizer's frozen 50,000-product Clothing/Shoes/Jewelry catalog from Amazon Reviews 2023 (McAuley Lab, UCSD), and the 200 labeled public development sessions used for iterative validation (every change was measured against this set before being kept).