Conversational Product Search Agent

Inspiration

Traditional e-commerce search works best when users already know exactly what they want. Real shoppers often begin with vague requests, reveal preferences gradually, or change their minds after seeing initial recommendations.

For TikTok TechJam 2026 Track 4, Team NPC wanted to explore whether a lightweight and deterministic search agent could handle these conversational changes without relying on a hosted large language model, external API, or expensive infrastructure.

What it does

Conversational Product Search Agent is a stateful, multi-turn product-search agent that:

searches a frozen catalog of 50,000 products;
identifies whether the user is browsing or showing buying intent;
extracts category, material, color, size, use case, and budget information;
maintains an isolated state for each conversation;
detects explicit changes in user preferences;
asks structured clarification questions;
reranks products whenever new information is provided; and
returns up to 10 ranked parent_asin identifiers through the official Agent interface.

The system recommends products and asks a clarification question in the same turn. This allows it to collect useful information without delaying the opportunity to retrieve the correct product.

How we built it

We implemented the agent in Python using only standard-library components.

The frozen product catalog is loaded into an in-memory SQLite FTS5 index. Searchable fields include product titles, categories, features, details, stores, and descriptions.

Our retrieval pipeline contains the following stages:

Intent and constraint extraction
Each customer message is analyzed for product categories, preferences, budget constraints, and intent-change signals.
Session-state tracking
The agent stores active search terms, structured preference slots, user-profile context, previously asked attributes, and intent-override information.
Precision-first retrieval
The agent first performs a strict AND query to retrieve products that satisfy multiple active terms.
OR fallback
If the strict query returns too few candidates, an OR query expands the candidate pool.
Weighted BM25 ranking
Product fields receive different weights, with stronger emphasis placed on titles, features, and product details.
Budget-aware reranking
When the user supplies a budget, products within budget are prioritized over products with unknown or higher prices.
Clarification selection
The agent asks about one unrequested attribute while continuing to return ranked recommendations.

The implementation follows the organizer-provided Python Agent contract and works with the unchanged official simulator and evaluator.

Built with

Development tools

Python
Cursor
macOS Terminal
GitHub
Official TechJam local evaluator

Libraries and frameworks

sqlite3 with FTS5 and BM25
json
re
pathlib

APIs and models

External APIs: None
Hosted language models: None
API keys: Not required
GPU: Not required
Model token usage: 0

Dataset

We used the official frozen TechJam dataset, including:

a 50,000-product catalog derived from the Amazon Reviews 2023 Clothing_Shoes_and_Jewelry category;
200 public development sessions;
the official deterministic dialogue simulator;
the official local evaluator; and
the published Agent API contract.

The product catalog remains read-only, and the agent does not modify the evaluation data or inject product identifiers.

Challenges we faced

Balancing precision and recall

A strict query improves precision when the user provides several compatible constraints, but it can also return too few products. We addressed this with a two-stage AND-to-OR retrieval strategy.

Managing changing intent

Users may replace an earlier preference during the conversation. The agent must recognize the override and prevent outdated constraints from dominating the latest request.

Asking versus recommending

Asking too many questions increases the number of turns, while recommending too early can reduce ranking accuracy. We designed the agent to recommend and clarify within the same response.

Working without semantic models

BM25 depends on lexical overlap and may miss paraphrases or semantically related products. We improved its effectiveness through field weighting, conversational term cleaning, persistent state, and structured constraint extraction.

Maintaining reproducibility

The evaluator measures exact parent_asin matches. We therefore kept the complete pipeline deterministic and ensured that the same inputs consistently produce the same ranked results.

Accomplishments that we are proud of

Using the unchanged official evaluator across all 200 public sessions, our agent achieved:

Metric	Official weak baseline	Our agent
Hit Rate@10	12.5%	96.0%
MRR	0.068034	0.6475
MTTC — lower is better	9.81	2.88
Efficiency	0.119	0.812
Technical Score	0.10671	0.83665

The agent achieved a Hit Rate@10 of at least 90% in every public scenario category, including Buying, Browsing, Intent Override, and Boundary cases.

The complete system runs locally on CPU with no network dependency, API credentials, model-token costs, or GPU requirement.

These figures are public-development-set results and are not claims about the hidden private evaluation set.

What we learned

We learned that conversational search does not always require a large generative model. Strong state management, careful query construction, clarification handling, and field-aware ranking can substantially improve a lexical retrieval system.

We also learned that evaluation metrics reveal different aspects of system quality:

Hit Rate@10 measures whether the correct product appears;
MRR rewards placing it near the top; and
MTTC measures how quickly the agent reaches the correct result.

Improving one metric does not automatically improve the others, so the complete interaction must be considered when designing the retrieval pipeline.

What's next

Given more time, we would add:

lightweight semantic embeddings and reciprocal-rank fusion;
separate retrieval strategies for Buying and Browsing intent;
value-based clarification selection;
stronger category, material, color, and size constraints;
recency-aware handling of preference overrides;
adversarial and paraphrase-based tests; and
an optional local semantic reranker with a deterministic BM25 fallback.

Our goal would be to improve generalization while preserving the current system's low cost, privacy, speed, and reproducibility.

Team contributions

Team member	Contribution
Xin Shu (舒欣)	Designed the core retrieval-system architecture and foundational search pipeline.
Sijia Zhu (朱思嘉)	Developed and iteratively tuned the retrieval logic to improve recommendation accuracy.
Xuetong Wu (吴雪桐)	Conducted performance analysis, technical testing, and evaluator-result verification.
Xiaoyue Yu (於晓越)	Prepared and refined the project README and reproducibility documentation.
Jiayi Yang (杨嘉仪)	Prepared the Devpost submission and designed, produced, and published the demo video.