Constraint-Aware Shopping Copilot

Reliable recommendations from evolving shopper conversations

Constraint-Aware Shopping Copilot is an offline conversational shopping agent that turns natural-language shopping requests into structured catalog constraints and ranked product recommendations.

Instead of relying on a language model to remember preferences or generate product names, the system maintains an explicit session state and searches a frozen 50,000-item Amazon catalog. This makes every recommendation catalog-grounded, deterministic, and reproducible.

The problem

Shopping conversations are rarely static. A shopper may begin with a broad request, add a colour or material preference, set a budget, reject an option, or completely change their mind.

Generic LLM-first shopping assistants can:

invent products or product attributes;
ignore strict price, size, or category requirements;
lose earlier preferences across multiple turns;
require repeated model calls, increasing latency and cost.

The challenge is therefore not only finding similar products. It is preserving the shopper’s evolving constraints while reaching the correct catalog item quickly.

Our solution

The copilot processes each turn through an explainable, deterministic pipeline:

Intent classification
Identifies whether the shopper is making a precise Buying request or exploring through Browsing.
Structured constraint state
Tracks preferences such as category, colour, material, size, price, brand, style, use case, and features. It also records explicit negations such as “no leather.”
Stateful updates
New preferences are added across turns. Updated values, such as a new budget or size, replace outdated values. Intent overrides clear superseded soft preferences and refresh the candidate set.
Catalog retrieval
SQLite FTS5 searches the frozen catalog and creates a candidate pool using product titles, descriptions, features, categories, and structured facets.
Facet-aware reranking
Candidates are scored against active constraints, price limits, exclusions, category matches, feature coverage, and previously shown products.
Single follow-up policy
The agent asks at most one supported attribute per turn, reducing shopper effort while collecting information that can improve retrieval.

The public API remains unchanged: the agent returns a customer-facing message, one optional ask_attribute, and up to ten ordered parent_asin recommendations.

Results

Using the official local evaluator on the 200 released development sessions, the final agent achieved:

TechnicalScore: 0.845444
Hit Rate@10: 0.995
MRR: 0.621480
MTTC: 2.925 turns
Runtime tokens: 0

This improved the supplied BM25 starter from a TechnicalScore of 0.125000 to 0.845444. The correct product appeared in the Top 10 in 199 of 200 public sessions.

The agent also achieved:

Buying Hit Rate@10: 0.9875
Browsing Hit Rate@10: 1.0000
Intent Override Hit Rate@10: 1.0000
Boundary Hit Rate@10: 1.0000

How we built it

Development tools

Python 3.10+
PowerShell/terminal
Official TechJam local evaluator
Interactive demo.py terminal demonstration

APIs used

No external APIs are used by the submitted agent.

Libraries and frameworks

The project uses Python’s standard library:

sqlite3 with SQLite FTS5
json
re
dataclasses
pathlib
unittest

No third-party machine-learning framework or model is required.

Datasets and assets

Frozen Clothing_Shoes_and_Jewelry product catalog containing 50,000 products.
Catalog fields include titles, descriptions, features, categories, prices, stores, and structured product metadata.
The catalog is derived from the Amazon Reviews 2023 data published by the McAuley Lab at UCSD.
public_set.jsonl contains 200 labeled development sessions used by the local evaluator.
catalog_index.sqlite is an optional catalog-derived SQLite search index generated locally.
No product images, external assets, private labels, or hidden evaluation data are used by the runtime agent.

Limitations and future work

The current system uses deterministic lexical and catalog-facet evidence. This makes it fast and explainable, but it can be less flexible when shoppers use unfamiliar synonyms or highly indirect descriptions.

A local semantic-retrieval prototype was tested but not shipped because it produced plausible substitutes while reducing exact-ASIN recovery on the evaluated scenarios.

With more time, we would add semantic retrieval only as a tightly gated fallback for weak lexical searches, while preserving the deterministic system as the official fallback. We would also evaluate on larger and more diverse conversation sets.