Need Decoder

Cover
Shopping interface

Inspiration

Most people do not begin shopping with a complete list of requirements. Usually, they describe a situation first: where they are going, what they will be doing, what the weather is like, or what kind of event they are preparing for.

Someone getting ready for a company retreat, for example, might ask for walking shoes and mention outdoor activities, hot weather, and a business-casual dinner. They may never explicitly ask for grip, breathability, comfort, or versatility, even though those details can completely change which shoes make sense.

That became the idea behind Need Decoder. The goal was to build a shopping copilot that could turn conversational context into useful product requirements and keep updating them as the shopper provides more information.

What it does

Need Decoder maintains a structured summary of the shopper's current requirements throughout the conversation. Product category, budget, exclusions, stated preferences, and practical needs inferred from the situation are all tracked as part of the current shopping brief.

Preferences are not treated as permanent. A shopper might initially prefer leather shoes, then later mention that they will spend most of the day outdoors in hot weather. In that case, the leather preference can be removed while useful information such as the budget and planned activities remains. Breathability can then become more important in the ranking.

Each recommendation also includes an explanation of the factors that influenced it. This makes it possible to see why a product ranked highly and why the results changed after the shopper added or corrected information.

How I built it

Need Decoder was built in Python, with the workflow divided into four main parts: conversation state tracking, hidden-need inference, product retrieval, and ranking with explanations.

Every incoming message updates a structured representation of the shopper's current needs. Contextual information is then mapped to practical product attributes through a controlled set of inference rules. Long outdoor walks, for example, can increase the importance of comfort and grip, while hot weather can make breathability more relevant.

Product retrieval uses a local SQLite FTS5 index built from the public Amazon Reviews 2023 dataset. An initial search produces a pool of candidate products, and those candidates are reranked using explicit requirements, inferred needs, budget fit, available product evidence, and conflicts with the current brief.

The ranking system is deterministic, meaning the same conversation produces the same result. That made debugging and evaluation much easier because changes in ranking could be traced back to specific inputs or rules. The full demo also runs locally without depending on a retailer API or an internet connection.

Challenges I ran into

Handling corrections naturally was one of the more difficult parts of the project. Resetting the entire conversation whenever one preference changed would remove useful information, but keeping every previous preference would allow outdated requirements to continue affecting later recommendations.

The solution was to separate persistent information from replaceable preferences. A detail such as budget or planned activity can remain valid across several turns, while something like a material preference can be updated or removed when the shopper changes their mind.

Hidden-need inference required some restraint as well. Broad rules made the system too eager to invent requirements, so the final approach uses narrower mappings and keeps the evidence behind each inferred need visible.

Local execution also shaped the retrieval design. Search needed to be fast enough for an interactive demo without adding a hosted search service, and SQLite FTS5 ended up being a practical fit.

Accomplishments that I'm proud of

Need Decoder was evaluated on 200 labelled shopping sessions covering budgets, exclusions, contextual needs, conflicting requirements, and preference changes. All 23 automated tests pass.

The evaluation results were:

Hit@10: 99%
MRR: 0.610
Mean turns to conversion: 2.055
Technical score: 0.8569

Another result I am particularly happy with is the way the system handles changing preferences without forcing the shopper to restart the conversation. Earlier information can stay when it is still useful, while outdated preferences stop influencing the ranking.

The fact that the full system runs locally is also useful for demonstration and testing. Product retrieval, state updates, ranking, and explanations can all be shown without relying on external service availability.

What I learned

Building the project made it clear that conversational shopping involves much more state management than I initially expected. Retrieving products is relatively straightforward compared with deciding which pieces of information should still matter after several turns of conversation.

Explanation data also became an important development tool. When a recommendation looked strange, the ranking could be inspected to see whether the issue came from state tracking, inference, retrieval, or scoring rather than treating the result as a black box.

Because the entire project was built independently, the work also involved connecting several different areas at once: conversation handling, information retrieval, ranking, evaluation, and the demo experience. That helped me understand how decisions in one part of the system affect the rest.

What's next for Need Decoder

A natural next step is connecting Need Decoder to a live retailer catalogue and testing it with a broader range of real shopping conversations. More product categories would also make the hidden-need rules more useful outside the current demo scenarios.

Multilingual input and preference learning from shopper feedback are other areas I would like to explore. As those features are added, keeping the recommendation process understandable and inspectable would remain an important part of the design.