Findly

An adaptive shopping copilot that understands changing intent, remembers preferences, and combines keyword, semantic, and constraint-aware search to find the right product in fewer turns.

Comment

Findly: Conversational Shopping Copilot

TikTok TechJam 2026
Track 4: Shopping Copilot
Team Members: Rann Liu, Aricia Ng

1. Project Overview

Findly is a conversational shopping copilot designed to help users discover suitable products through natural, multi-turn conversations.

Traditional product search often assumes that shoppers already know exactly what they want. In reality, shopping is usually iterative — users may begin with a broad request and gradually reveal preferences such as product type, colour, material, use case or style.

Findly addresses this by maintaining an evolving understanding of the shopper throughout the conversation. Instead of treating every message as an isolated search query, it accumulates useful preferences, detects when the user changes direction, asks targeted clarification questions when necessary, and continually refines product retrieval using the provided Amazon product catalogue.

The final system combines:

  • Multi-turn conversational memory
  • Structured preference extraction
  • Intent-override and stale-state handling
  • Proactive clarification
  • Structured BM25 retrieval using SQLite FTS5
  • Cross-turn candidate consensus
  • Product category/type-aware reranking
  • Debug logging and offline failure diagnostics

2. How Findly Addresses the Problem Statement

The challenge requires a shopping agent that moves beyond rigid search filters and is able to adapt to changing customer needs throughout a conversation.

Findly focuses on four areas: retrieval architecture, multi-turn dialogue, dynamic context adaptation, and recommendation efficiency.

I. Core Architecture: Retrieval Pipeline

Findly uses the provided Amazon Clothing, Shoes and Jewelry dataset to build a fast, in-memory searchable index using SQLite FTS5 with BM25 ranking.

Instead of treating every product as one unstructured block of text, Findly indexes multiple structured fields:

  • Title
  • Category
  • Features
  • Description/details
  • Store/brand
  • Department
  • Material
  • Colour

This allows different forms of product evidence to contribute appropriately to retrieval. For example, a match in the product title or category is generally more useful than the same word appearing incidentally within a long description.

The final pipeline is:

User message → Preference extraction → Session-state update → Multi-field BM25 retrieval → Cross-turn candidate consensus → Product-type reranking → Top recommendations

After BM25 retrieval, Findly applies a lightweight product category/type relevance bonus. Products whose titles and categories more closely match the shopper's requested product type receive a small ranking advantage without applying a strict filter.

Although the challenge proposes separate buying/browsing routing and dense or LLM-based retrieval, these were not included in our final system. We experimented with more complex routing and semantic retrieval approaches during development, but they did not consistently outperform our deterministic retrieval pipeline. We therefore retained the architecture that produced the most reliable results.

II. Dialog Strategy: Multi-Turn Scenario Evolution

Findly treats shopping as an evolving conversation rather than a sequence of independent searches.

Information Accumulation

The agent maintains a structured session state and adds new preferences as they are revealed.

For example:

User: "I need a jacket."
category = jacket

User: "Prefer black."
category = jacket, colour = black

User: "Something waterproof."
category = jacket, colour = black, feature = waterproof

These accumulated preferences are then used to construct increasingly focused retrieval queries.

Intent Override

Findly also recognises when a shopper changes direction completely.

For example:

"I want running shoes."

followed by:

"Actually, show me jackets instead."

Keeping both requests in memory would introduce conflicting information. Findly therefore detects major changes in product intent and performs stale-state cleanup, removing outdated preferences before rebuilding the state around the new request.

This allows Findly to support both incremental information accumulation and abrupt intent override within the same conversation.

III. Self-Evolution: Dynamic Context Programming

Findly dynamically adapts its behaviour using the conversation history.

The accumulated session context determines:

  • Which shopper preferences are already known
  • Which missing attribute should be clarified next
  • How the retrieval query is constructed
  • Which old preferences should be removed after an override
  • Which previously strong product candidates should retain ranking support

Proactive Clarification

If a request is still too broad, Findly can ask a targeted clarification question instead of repeatedly returning generic recommendations.

Its clarification strategy prioritises:

use case → material → colour → feature → style → size

The goal is to obtain useful information early while avoiding unnecessary questions that make the shopping process longer.

Cross-Turn Candidate Consensus

Findly also remembers strong candidates from previous query states.

A relevant product may rank strongly during an earlier turn but fall later as the query changes. Instead of discarding this earlier evidence completely, Findly combines candidate rankings across multiple turns using a Reciprocal Rank Fusion-style consensus mechanism.

This allows the conversation itself to become part of the ranking context and makes the system more robust to temporary ranking fluctuations.

The current system focuses on short-term session context. Long-term customer profiles across separate sessions are not implemented in the final version.

IV. Evaluation Matrix: Product & Efficiency Metrics

Findly was developed using the challenge evaluator and designed to balance both recommendation quality and conversational efficiency.

The key evaluation metrics are:

  • Hit Rate@10 — whether the correct product appears within the Top 10 recommendations
  • Mean Reciprocal Rank (MRR) — rewards placing the correct product closer to rank 1
  • Mean Turns to Conversion (MTTC) — measures how quickly the correct product is successfully recommended

The challenge's efficiency component is calculated as:

Efficiency = max(0, min(1, (11 - MTTC) / 10))

The recommended technical score combines the three metrics as:

Technical Score = 0.50 × Hit@10 + 0.30 × MRR + 0.20 × Efficiency

These metrics influenced our design decisions. For example, clarification can improve retrieval accuracy, but asking too many questions increases MTTC. Findly therefore aims to ask useful clarifications while still converging quickly.

3. How the Agent Works

Findly's final architecture was developed in four main phases, with each phase addressing a different weakness identified through evaluation and debugging.

Phase 1 — Conversational Memory and Preference Extraction

The starter system primarily behaved like a conventional lexical search engine. We added:

  • Persistent session memory
  • Attribute extraction
  • Preference accumulation
  • Multi-turn query construction
  • Basic clarification questions

This allows Findly to understand that a response such as "black" is an additional preference for the current product rather than a completely new search.

Phase 2 — State Management and Intent Overrides

Simply accumulating every preference can create stale or contradictory state when the user changes their mind.

We therefore added:

  • Improved category extraction
  • Attribute-only update detection
  • Intent-override detection
  • Stale-state removal
  • Improved query construction

This allows the agent to distinguish between a refinement such as "make it black" and an override such as "actually, I want a handbag instead".

Phase 3 — Structured Retrieval and Clarification Optimisation

We replaced simple unstructured search with a structured SQLite FTS5 index containing separate product fields such as title, category, material, colour and features.

BM25 field weighting allows more important product information to contribute more strongly to retrieval.

We also refined the clarification strategy so that high-value missing preferences are requested earlier while limiting unnecessary conversation turns.

We chose SQLite FTS5 because it provides:

  • Fast local retrieval
  • Built-in BM25 ranking
  • Deterministic results
  • No network latency
  • No external API dependency
  • Efficient searching over the fixed product catalogue

Phase 4 — Cross-Turn Consensus and Final Reranking

Our diagnostics showed that a relevant product could sometimes rank well on an earlier turn and then fall significantly after later query changes.

We therefore introduced cross-turn candidate consensus, which retains ranking evidence from multiple query states.

The final stage also applies a small category/product-type relevance bonus so that products matching the shopper's intended product type are favoured over candidates that only share isolated keywords.

A soft bonus was chosen instead of strict filtering because strict filters can incorrectly eliminate relevant products when catalogue metadata is incomplete or inconsistent.

Debug Logging and Self-Diagnosis

We also built optional debug logging and offline diagnostic tools to understand why individual sessions succeeded or failed.

Diagnostics include:

  • Current session state
  • Extracted attributes
  • Query terms
  • Clarification decisions
  • Candidate rankings
  • Target-rank movement across turns
  • Cross-turn consensus behaviour
  • Scenario-specific failure patterns

This helped us improve the system based on observed failure modes rather than relying only on aggregate benchmark scores.

4. Development Tools Used

Visual Studio Code

Used as the primary development environment for:

  • Python development
  • Code review
  • Debugging
  • Running experiments
  • Managing the project repository

Git and GitHub

Used for:

  • Version control
  • Collaboration between team members
  • Maintaining known-good agent versions
  • Tracking experimental changes
  • Hosting the final public repository

PowerShell / Terminal

Used to:

  • Run the official evaluator
  • Execute diagnostic scripts
  • Configure debugging options
  • Manage Git workflows
  • Reproduce experiments

Python

Used to implement the agent, retrieval pipeline, evaluator integration and diagnostic tooling.

5. APIs Used

Findly does not require any external API during runtime.

The final agent performs retrieval and ranking locally and therefore has:

  • No LLM API dependency
  • No external search API dependency
  • No paid inference requirement
  • No network dependency during evaluation

This keeps Findly deterministic, reproducible and free from API latency, rate limits or service availability issues.

6. Libraries and Frameworks Used

Findly intentionally uses a lightweight technology stack.

SQLite / SQLite FTS5

SQLite FTS5 is used to build the in-memory product search index and provides:

  • Full-text indexing
  • Fast lexical retrieval
  • BM25 relevance scoring
  • Weighted structured product fields

Python Standard Library

The final system primarily relies on Python's standard library, including modules for:

  • JSON parsing
  • Regular expressions
  • SQLite access
  • Session-state management
  • Environment configuration
  • File and data loading
  • Ranking and debug logic

The final runtime system does not require heavyweight machine-learning frameworks such as PyTorch or TensorFlow.

7. Dataset and Assets Used

Findly uses the challenge dataset derived from Amazon Reviews 2023 — Clothing, Shoes and Jewelry.

The supplied catalogue contains approximately 50,000 products, with fields including:

  • parent_asin
  • Title
  • Category
  • Features
  • Details
  • Description
  • Store/brand
  • Price
  • Additional product metadata

The challenge also provides public development sessions for local evaluation and separate hidden sessions for final judging.

The public sessions were used only for development, evaluation and diagnostics.

The runtime agent never accesses the target parent_asin or other ground-truth answers when producing recommendations. Ground truth is used only by the evaluator to calculate performance metrics.

8. Summary

Findly transforms product search from a one-shot keyword lookup into a stateful conversational retrieval process.

The agent:

understands the latest request → accumulates preferences → detects intent changes → asks targeted clarifications → retrieves from structured Amazon product data → preserves useful evidence across turns → reranks for product-type relevance → returns focused recommendations

By combining structured conversational memory, efficient BM25 retrieval, proactive clarification, cross-turn ranking evidence and systematic diagnostics, Findly provides a lightweight and reproducible approach to conversational shopping without requiring an external model at runtime.

Share this project:

Updates

Submission history