Fast Retail

Inspiration

Our solution tackles the conversational e-commerce search challenge by prioritizing what matters most in high-volume retail environments: zero-latency responses, absolute determinism, and zero API costs. Rather than relying on expensive and slow Large Language Models (LLMs) that can hallucinate or exceed rate limits, we wanted to prove that a highly optimized sparse-retrieval baseline can effectively navigate buying and browsing scenarios.

What it does

Fast-Retail is a completely local, stateless retrieval engine. It instantly tokenizes natural language queries, strips stopwords, and matches customer intents against a 50,000-item catalog in milliseconds. It efficiently handles conversational e-commerce searches while ensuring that sensitive user preferences are never sent to third-party APIs.

How we built it

We engineered the solution using purely local development tools—specifically VSCode, Emacs, and Neovim—ensuring our code is modular, production-ready, and lightweight without relying on Jupyter Notebooks or Colab.

We relied entirely on the Python Standard Library, utilizing:

sqlite3 for in-memory virtual tables and FTS5/BM25 fast retrieval.
re (Regex) for aggressive query tokenization and stopword removal.
json and pathlib for data pipeline management.

Datasets used: We built this using the provided frozen catalog.jsonl (50,000 items from Amazon Reviews 2023) and utilized public_set.jsonl for offline evaluation and iterative regex tuning.

Challenges we ran into

While we tried our hands with different LLM API models including the free Gemini API, Groq API as well as locally hosted models on Ollama, the result has been less than satisfactory with high latency, and low accuracy due to significant expansion of word range. This makes the retrieval harder and less focused. Most of the time, the words are often used directly in our very verbose database so a semantic match with scoring and ranking would give a better result generally. Furthermore, since users can change their mind at any time, keeping too long of a context window can be detrimental to the accuracy of the LLMs, even with context decay implemented. Overall, based on accuracy and benchmarks, and given the limited amount of time and resources, we decide to go with Fast Retail, a zero latency, zero API implementation of a Shopping Copilot.

Accomplishments that we're proud of

We successfully built a conversational agent that guarantees 100% data privacy and entirely bypasses the token limits, latency, and financial costs associated with cloud LLM APIs. We proved that you don't need a massive neural network to parse intents and return highly relevant products at scale.

What we learned

We learned that traditional Information Retrieval techniques, when highly optimized with tools like SQLite FTS5, are incredibly powerful. We discovered that a well-crafted sparse-retrieval baseline can effectively handle complex e-commerce interactions when combined with smart, deterministic state management.

What's next for Fast Retail

We plan to implement a Waterfall Hybrid Architecture. We will keep our SQLite BM25 engine as the Tier-1 primary retriever to handle 80% of obvious queries instantly. We would only trigger a lightweight, local cross-encoder or LLM (Tier-2) as a fallback if the BM25 confidence score drops below a specific threshold, giving us the best of both worlds: extreme efficiency with semantic safety nets.