Findy

Inspiration

Online shopping is not just one perfect search query. It requires time and effort from the customer to realise his true hidden demands. It's not a straight forward decision and most of the time ends with the customer closing the app. Traditional search treats each message as a separate query, while simply combining the whole conversation risks retaining preferences that are no longer relevant.

We built Findy to facilitate this step: track and update the shopper's intent as the conversation develops. Our goal was to create a conversational product-search agent that is fast, reproducible and capable of running completely locally.

What it does

Findy is a fully local conversational product-search agent that retains the shopper's preferences and evolves every turn.

Instead of forcing shoppers to create a perfect search query, Findy lets them describe what they are looking for naturally and refine it over multiple messages. Users can add or remove preferences, set a budget, or change their mind without restarting the search.

For example, someone could begin by asking for running shoes, request a black pair under $100, and later switch to white. Findy preserves everything that still matters, updates what has changed, and continuously returns recommendations based on the shopper’s latest preferences.

The result is a faster, more natural product-discovery experience that runs entirely locally, without requiring an external API or internet connection.

How we built it

We divided conversational search into understanding, state management, retrieval, ranking, and clarification.

Each message is processed by a deterministic intent and constraint parser, which identifies details such as category, budget, preferences and references to earlier turns. This information is stored in an explicit session state, allowing it to update the requirements without losing the rest of the conversation.

An intent router determines whether the shopper is just exploring or has a strong buying intent. The query builder then converts the active state into a lexical query and retrieval plan. SQLite FTS5 retrieves a broad pool of candidates from the catalog. A category and constraint- aware reranker then scores them against the user's current needs.

Finally, Findy returns the most relevant product recommendations through a response builder and can continue refining the as the conversation progresses. The complete pipeline runs locally without external APIs.

The submitted runtime uses Python and SQLite/FTS5. During development, we also used PyTorch, Hugging Face Transformers, sentence-transformers, scikit-learn, pandas, and NumPy to evaluate semantic retrieval and local student models. Our workflow included Visual Studio Code, Git, GitHub, Python command-line tools, and custom evaluation scripts.

We also used the OpenAI Responses API with GPT-5.6 Terra during offline experimentation. Structured state transitions were generated locally first, and Terra rendered natural-language utterances expressing those transitions. Groq was evaluated during earlier experimentation. Neither service is used by the final runtime.

Challenges we ran into

The hardest challenge was not retrieving relevant products, but maintaining the shopper’s intent correctly across multiple turns. A small mistake in state interpretation could carry through the rest of the session, for example, keeping a preference the user had already removed or dropping one that still mattered. Our diagnostics showed that when the retrieval and ranking pipeline received the correct conversational state, performance improved substantially, confirming that state understanding was the main bottleneck.

We therefore tested several neural approaches, but small generative models were not reliable enough for structured state updates, while MiniLM improved selected difficult cases without consistently outperforming the deterministic system on the full public benchmark. Hybrid routing also offered too little complementary gain to justify the added complexity.

At the same time, deployment constraints mattered: online models introduced latency, API dependencies, cost, rate limits, and network risk. The final challenge was therefore to balance conversational understanding with speed, reliability, and reproducibility.

Accomplishments that we're proud of

Our final system delivered the strongest result on the complete public development benchmark while remaining fully local and deterministic. Across all 200 public development sessions, Findy achieved an 85.0% Hit@10 rate, with 170 successful sessions, an MRR of 0.514, and an average of 3.625 turns to convergence.

The system also remained lightweight and reliable in deployment, with a mean CPU latency of approximately 19.6 milliseconds per turn, zero external API calls, zero runtime errors, and zero invalid outputs.

Importantly, the deterministic design does not reduce Findy to a simple keyword-search system. It maintains conversational state across turns, supports preference changes, routes intent, retrieves candidate products, and reranks them according to active constraints.

Overall, Findy’s strongest advantage was its ability to treat user intent as an evolving state while maintaining speed, locality, and operational reliability.

What we learned

Our biggest lesson was that conversational search is only as good as its understanding of the user's current intent. A powerful retrieval system cannot compensate for a preference that was misunderstood, forgotten, or incorrectly retained.

We also learned to evaluate the complete experience rather than individual components in isolation. Some neural approaches performed well on difficult examples but introduced regressions across ordinary conversations. Improvements at the model level did not always translate into better end-to-end results.

Finally, complexity should earn its place. After testing semantic retrieval, language models, student models, and hybrid approaches, the deterministic architecture delivered the best overall balance of accuracy, speed, reliability and portability. The strongest solution was the one that performed most consistently across the entire system, not the most sophisticated one.

What's next for Findy

The next step for Findy would be to handle more natural and complex conversations. We envision Findy as an approachable shopping companion that helps users quickly find their needs from just a vague idea. We want find to understand paraphrased requests, resolving references to earlier products or searches, and recognising when a users preferences are unclear or conflicting. We also want Findy to ask smarter follow-up questions rather than following a fixed sequence. A lightweight local semantic layer could improve how everyday language maps to product categories and features while preserving Findy's speed and reliability.

Built With

• numpy
• pandas
• python
• scikit-learn
• sentence-transformers
• sqlite