Where Do You Nom
Restaurant dishes linked to their recipes, so nutrition comes from ingredient data
Where Do You Nom, a U.S. food discovery startup, had restaurants, menus, recipes and ingredients that did not connect. We treated it as a linking problem first: clean every set, match menu items to recipes at scale, and let nutrition come from the linked records, never from a model.
Healthcare & WellnessFood search and recommendationsBuilt from zero
The challenge
Restaurants, menus, recipes and ingredients sat in separate data sets with branded dish names and free text ingredient lines, and nothing linked them, so no dish could show its nutrition.
What we did
We cleaned and normalized every set, parsed ingredient lines into fields, matched menu items to recipes with word2vec, n-gram search and hashing, then built a hybrid recommender on the linked data.
The outcome
Each menu item now reaches its recipe and ingredients, so a dish shows nutrition computed from source data, and recommendations run on that linked base.
- Linked
- Menu items to recipes to ingredients
- Training data
- 200,000 menu items labeled by course
- Matching
- word2vec, n-gram search and hashing
- Phase two
- Hybrid recommender on a graph database
The starting point
Where Do You Nom is a U.S. startup building food discovery and nutrition: people find dishes at restaurants across states and get food suggestions from their nutrition plan. It held large JSON sets of restaurants, menu items, recipes and ingredients, plus 200,000 menu items labeled into six courses, from appetizers to desserts.
What had to change
Menu names were branded, categories inconsistent, recipe names personal and ingredient lines mixed quantity, unit, item and preparation in one string. Nothing linked ingredients to recipes or recipes to menu items, so no dish could show its nutrition.
What could not break
- Millions of recipe names matched against menu items from restaurants across U.S. states
- Matching as close to real time as possible
- Every restaurant names the same dish its own way
- Nutrition values come from recipe and ingredient data, never from a model
The calls we made
We framed this as a linking problem before an AI problem: clean and normalize first, link second, and recommend only once the links existed.
- 01
Models match, data supplies the facts
Models only normalize and match names and rank suggestions. Calories and nutrition always come from the linked recipe and ingredient records, so every number traces back to source data.
- 02
Hashing to narrow the search
Comparing every menu item with every recipe does not scale, so locality sensitive hashing narrows the candidates first. That made similarity search over the full set several times faster.
- 03
Search before recommendations
A recommender on unlinked data would suggest foods it could not describe, so we sequenced the work: real time search and linking in phase one, the recommender on top of it in phase two.
How the system fits together
What we built
Cleaning and normalization
Branded dish names given a generic second name, categories such as Starters and Beginnings folded into Appetizers, personal recipe names cleaned and near duplicate ingredients merged.
Ingredient line parser
Free text ingredient lines split into quantity, unit, item and preparation, so each ingredient can carry its calories.
Menu to recipe matching
word2vec representations of menu items and recipes, unigram and bigram search and locality sensitive hashing link each menu item to its closest recipe.
Hybrid recommender
Matrix factorization for collaborative filtering plus similarity based content filtering, on a graph database of users, foods and nutrition.
How it works
Raw exports come in
Restaurant, menu, recipe and ingredient files arrive as JSON or CSV.
Records are cleaned
Names, categories and ingredient lines are normalized into structured fields.
Dishes are linked
Each menu item is matched to a recipe, and each recipe to its ingredients.
Nutrition is read, not guessed
A dish's nutrition is computed from the linked ingredients' own values.
Suggestions follow the plan
The recommender ranks foods from the user's nutrition plan and history.
What changed
Where Do You Nom went from disconnected data sets to linked records where a menu item reaches its recipe and ingredients, so a dish can show nutrition computed from source data. On that base we built a recommender that suggests foods from a user's plan and history.
Under the hood
- Datics role
- Product built by Datics
- Data boundary
- Models normalize, match and rank only; nutrition values come from linked recipe and ingredient data.
- Matching
- word2vec embeddings, unigram and bigram text search and locality sensitive hashing for fast similarity search.
- Storage
- Cleaned records in a relational or NoSQL store, with a graph database for relationships between users, foods and nutrition.
Apps and APIs
Also in the stack
How it shipped
Phase one: clean, link and search
Menu items, recipes and ingredients cleaned and normalized, ingredient lines parsed, and menu items matched to recipes for real time food search with nutrition per dish.
Phase two: recommendations
A hybrid recommender on a graph database, built on the linked records, suggesting foods from a user's nutrition plan and history.
Two phases, each standing on the last
Real time search and linking came first, and the recommender was built on top of it in a second phase.
From the client's own data
We worked from the client's existing exports and its 200,000 labeled menu items rather than collecting new data.
What this unlocked
With linked, searchable food data in place, features such as filtering dishes by diet or fitness goal no longer depend on guesses.
Related work
Have a product with the same kind of constraints?
Tell us what already exists and what you want it to do. We will tell you what it takes.