-
Notifications
You must be signed in to change notification settings - Fork 0
Prototype v3: SUPost Battle for Software Fair
For our previous v2 prototype Bookworm, while algorithm design and code implementation was at the forefront of our minds, in order to be able to rapidly iterate and get quick feedback we initially structured our codebase to be heavily centered around the Amazon books dataset relevant to this demo. While the core elements of find and filter still existed, our codebase itself was directly referencing the configuration of this dataset and was not attuned to the B2B software product we now saw as Kenja's main value add. Thus the next step we took was restructuring our code base in order to be able to process any structured csv and run FaF on the data in order to allow companies to easily run this new form of search on their platforms.
The first stage in the new pipeline for our backend revolves around the dataset itself. As noted above, we decided to first structure our approach around structured csv data, as we felt like this formatting is extremely common and pretty ubiquitous. Similar to standard databases, the csv data provided needed to have an identifier (id) to every row in order for us to be able to properly track data in the backend. We also made sure to have functionality where users could provide multiple csv files provided that each row of all the csv files provided contained a column with the relevant identifier. The user lets us know the identifier on the front end when we process our data. Once the all the csv files are provided by the user, we combine all of them in to a single pandas dataframe to make data processing easier at the cost of a larger memory footprint. This increased memory usage is a cost that we were willing to make in order to iterate more quickly, but in the future is something that we would optimize in order to keep a lower memory footprint which would be more crucial when dealing with large-scale datasets.
Within FaF, querying our vector database is a key part of the algorithm. In order to do so, we must utilize a distance function to decide how similar the query embedding and candidate embedding are to one another. The default distance function utilized by our vector database library, chromaDB, is the squared L2 norm. However, when investigating the open-source embedding model from Nomic AI
Once this initial data processing stage is completed, we then move on to iteratively funneling down the dataset until only a few candidates remain to be provided to the user as the result of their search query. The first step in this process is noun querying. This step in the pipeline is a direct result of the team's learnings from Breakathon, for we found that the original version of FaF without this stage was not able to handle more traditional keyword based searches very robustly. Thus, we decided to add this initial layer to better select more relevant candidates in the initial stages of the pipeline relating to the user's query to be passed on to the later stages. With noun querying, we first extract out all the nouns in each row of the combined pandas dataframe and create embeddings for each row based on all of the nouns that they individually contain. We do the same for the user's query then run cosine similarity between the user's query embedding and each of these noun embeddings and keep only keep a specified subset of the original dataset which are revealed to be the most similar. This approach is meant to ground potential candidates in their core aspects so that other details that might be contained in details do not overly confuse the algorithm too early in the process. For example, if a user searched "blue sunglasses" but the dataset contained "blue shoes," we do not want the detail of "blue" to cause the shoes to be presented. At the same time, we still want a large enough state space to provide interesting candidates for more exploratory rather than keyword-based searches (think "I am looking for something nice for my lawn"), so we try to strike a balance between the two and utilize the later stages of FaF.
For other information, check out our team's Google Drive. For a daily stream of thoughts, check this document.
- OKRs and KPIs
- Team Coding Standards
- Real Customer Profile
- Launch Week Recap
- Unusual Academy Pitch Event
- Final Reflection
- 1/23 - Jay Borenstein
- 1/26 - Chris Oh
- 1/30 - Glenn Reid
- 1/30 - Adam Heher
- 1/31 - Samantha Phillips
- 1/31 - Chris Tsakalakis
- 2/2 - MZ Zaveri and Kasey Zhang
- 1/25 - Introduction
- 2/1 - Proposing a Product
- 2/13 - OKRs and KPIs
- 2/27 - Catching up for Last Weeks of Winter
- 3/5 - Demo + Discussion
- 4/2 - New Quarter
- Strategy for Search for Shopping
- Ideal Customer Profile Brainstorming
- Outreach Messaging
- Tracking Outreach
- Discovery Call Outline
- Feedback from Unusual on Slides
- Meeting with Seena from Nike
- Meeting with Mike from Launch
- Meeting with Heather from Walmart
- Meeting with Sandy from Walmart
- Demo Call Outline
- Prototype v0: A New Shopping Experience
- Prototype v1: Updated Bookworm for Demo Day
- Prototype v3: SUPost Battle for Software Fair