Flavor Recommendations for a Smart Kitchen Appliance

Overview

A food-tech startup is building a smart spice dispenser paired with a mobile app. We were engaged to deliver the ML core: a system that understands recipes and recommends spice blends and ingredient substitutions. Over the engagement, we designed the data/ML pipeline, trained models on hundreds of thousands of recipes, and shipped a Python web API that the client’s backend consumes.

At a glance

Industry

Food-tech/IoT

Goal

Augment the client’s IoT device with a system that understands recipes and suggests spice blends and ingredient substitution to enrich consumer experience

Tech highlights

Python, scikit-learn, Gensim (embeddings), REST API

Core Business Challenge

• Make software “understand” ingredients. Recipes are subjective and inconsistent (units, naming, styles).

• Two core use cases, one engine. Recommend blends to elevate taste and suggest substitutions from what the user has.

• Productize the models. Deliver a service that the app can call: reliable, versioned, and easy to expand.

Our Approach

• Experiment, then converge. Tested graph/co-occurrence methods, clustering, frequent-pattern mining, and NLP embeddings; selected a hybrid approach that balanced accuracy and control.

• Data curation at scale. Built a normalised corpus from 400k–500k+ recipes, standardised measures (grams, tsp, etc.), de-duplicated and canonicalised ingredient names.

• Tight loop with domain experts. Iterated with the client’s culinary team to validate “makes sense” suggestions before hardening the API.

• Ship as a service. Packaged models behind a Python REST service with unit tests and monitoring hooks.

AI Solution

• Recipe understanding (NLP): Tokenisation + normalisation → ingredient embeddings (Gensim) and co-occurrence features; captures which items “belong together” across cuisines.

• Blend recommender: For any recipe, ranks complementary herbs/spices; a classification/regression head predicts which and how much to add (top-N with quantity hints).

• Substitution engine: Given pantry constraints, proposes replacements using similarity in the embedding space + rule-based guards (diet, cuisine, role in dish).

• Extensibility: Catalog currently covers hundreds of flavorings and is designed to grow toward 1,000+; roadmap includes taste-profile personalisation (e.g., “spicier”, “earthier”).

• MLOps: Dataset/model versioning, repeatable training, offline eval (precision@k / nDCG) tracked per release; API is versioned and load-tested.

Outcome

• Two use cases in one API: elevate taste (blend suggestions) and make it work (substitutions).

• Scale-ready data foundation: normalized corpus (hundreds of thousands of recipes) and a growing flavor catalog.

• Productised delivery: deployable REST service powering the client’s MVP; easy to expand with new cuisines and spices.

• Clear path to personalisation: architecture supports user taste profiles without retraining the entire stack.