Inspiration
Online shopping search hasn't really changed in 20 years — you type keywords into a box, get a wall of results, and manually apply filters until you narrow it down. But real shopping conversations aren't like that. When you ask a friend for a recommendation, they ask you questions back: "What's your budget?", "Do you need it waterproof?" We wanted to build a shopping assistant that behaves like that friend — understanding not just what you typed, but what you actually need, and asking the right follow-up questions to get you there faster.
What it does
IGREN Shopping Copilot is a conversational AI agent that helps users find products through natural back-and-forth dialogue instead of static filters. Given a vague or specific request, it:
- Retrieves relevant candidates from the product catalog using a hybrid search pipeline (keyword + semantic)
- Uses an LLM to intelligently re-rank those candidates based on how well they actually match the user's stated and implied preferences
- Proactively asks a single, well-chosen clarifying question each turn — picking whichever attribute (color, material, budget, etc.) will most effectively narrow down the results
- Adapts gracefully if the user changes their mind mid-conversation, resetting outdated constraints instead of getting stuck
- Returns the best matching product as early in the conversation as possible, minimizing the number of turns needed to reach a satisfying recommendation
How we built it
We split the system into two layers:
Retrieval layer: A hybrid pipeline combining BM25 keyword search (SQLite FTS5) with an optional dense vector retrieval track (FAISS + MiniLM-L6-v2 embeddings), merged via Reciprocal Rank Fusion. A constraint-extraction module parses the conversation to accumulate structured preferences turn by turn, including support for multiple simultaneous requirements on the same attribute (e.g. "waterproof AND breathable").
LLM reasoning layer: The top 20 retrieved candidates are handed to an LLM (OpenAI's open-weight gpt-oss-20b model, hosted via the Groq API for fast, free inference) which re-ranks them down to a final top 10 based on genuine semantic matching against the user's constraints — not just keyword overlap. The same LLM layer selects which attribute to ask about next by reasoning over which question would most narrow the remaining candidate pool, and generates the natural-language reply shown to the user.
We built and iterated using VS Code, with Git/GitHub for version control, and uv for Python dependency management.
Challenges we ran into
Our biggest challenge was getting reliable structured output from a reasoning model under tight latency and token constraints. gpt-oss-20b internally "thinks" before answering, and we discovered that if max_tokens was too low, the model would spend its entire budget on internal reasoning and return an empty final answer — a completely silent failure mode, since our error handling was (by design) falling back gracefully to the non-LLM ranking order rather than crashing.
We debugged this by tracing the raw API response object rather than trusting the parsed output, which revealed the model's reasoning field was full of genuinely correct analysis that never made it into the final content field. We resolved this by tuning Groq's reasoning_effort parameter and increasing our token budget, balancing between "too shallow" (fast but low-quality rankings) and "too verbose" (high-quality reasoning that ran out of budget before writing an answer).
We also hit a string of environment-setup issues specific to Windows development — file encoding mismatches when reading the catalog (UTF-8 vs. the OS default codepage), a broken Python packaging configuration, and a deprecated model name that had been silently retired by our LLM provider — all of which needed to be diagnosed one layer at a time before we could even begin prompt engineering.
Accomplishments that we're proud of
- Getting a genuinely reliable LLM re-ranking pipeline working end-to-end on top of a strong retrieval baseline (0.853 composite score with retrieval alone, an 8x improvement over the competition's naive baseline)
- Correctly diagnosing a subtle reasoning-model token-budget bug that was silently degrading our results without throwing any errors
- Building a robust fallback system so that LLM failures (rate limits, malformed JSON, empty responses) never break the user experience — the system always returns a usable result
What we learned
We learned firsthand how differently reasoning models behave compared to standard chat models — the separation between "thinking" and "answering" tokens is easy to overlook but has a real, measurable impact on output reliability. We also learned the value of tracing raw API responses rather than just the parsed output when debugging LLM integrations, since silent fallbacks can mask real problems for a long time if you're only looking at aggregate scores.
What's next for IGREN Shopping Copilot
- Further tuning of the LLM's reasoning depth to consistently beat our retrieval-only baseline across all scenario types, especially high-intent "buying" sessions where precision matters most
- Incorporating the user's long-term profile and preference history into the ranking and attribute-selection logic, which is currently available in our data but not yet used
- Experimenting with prompt-level techniques (few-shot examples, stricter output schemas) to reduce reliance on
max_tokenstuning altogether
Below is our YouTube Video: https://youtu.be/jsp40vEXrWY
Log in or sign up for Devpost to join the conversation.