Building an AI-Powered Diet Tool

For the last 20 years, I have been the designated cook when the family gets together for the holidays. Some of my relatives are vegetarian or vegan, some are diabetic, and some are low-carb or Paleo. This Thanksgiving I had to cook a meal that accommodated all of these requirements simultaneously. It was a huge undertaking, but absolutely worth it. 

I realized that I had accumulated a vast amount of knowledge in which substitutions work. For example, I can tell you when to use almond flour versus lentil flour as a substitute for wheat flour. I also know that coconut sugar and date sugar both have a very low glycemic index, but date sugar is best in baked goods and coconut sugar is good when you need the sugar to dissolve in a liquid or sauce. I’ve built these substitution rules over years of trial and error. 

This realization inspired me to turn my tribal knowledge into a repeatable diet tool. I’m building a prototype “Diet Bot” designed to help people follow diets by automatically adapting recipes. Behind this seemingly simple idea is a full LLM product architecture that touches on retrieval-augmented generation (RAG), custom rule engines, domain adaptation, and instruction tuning. This project is still in progress, but here’s a look at my product roadmap. 

Why This Project?

People with dietary constraints spend a huge amount of time rewriting recipes by hand, researching substitutions, and figuring out which ingredients fit their diet. LLMs are great at text transformation, but they lack built-in knowledge of specific diet rules.

I wanted to build something that:

• automatically rewrites any recipe to follow dietary rules,

• explains why a substitution works, and 

• uses retrieval to reference my proven techniques.

System Architecture Overview

1. A rule-based domain engine

A lightweight, YAML-driven rule system that defines:

• allowed / illegal / conditional ingredients

• aliases (e.g., “flour” to “wheat_flour”)

• functional roles (binder, thickener, sweetener)

• compliance notes

2. Retrieval-Augmented Generation 

A vector database (FAISS to start, then possibly Pinecone) stores:

• substitution patterns

• cooking technique snippets

• verified diet-safe recipe transformations

3. LLM orchestration layer (FastAPI + function calling)

1. The model receives:

2. user text

3. rule-based analysis

4. relevant retrieved context

5. Outputs are structured into:

6. Compliance notes

7. Rewritten recipe

8. Shopping list

4. Streamlit front-end

A simple, fast UI to:

• paste recipes

• view diff-style rewrites

• explore substitutions

Three Iterations of Model Maturity

A key part of this project is intentionally designing the learning curve for the model. Instead of jumping straight into fine-tuning, I’m building in three stages:

Iteration 1: Prompting + RAG (MVP)

Goal: Validate the workflow using commercial APIs (OpenAI).

• Basic recipe parsing

• Rule engine + compliance detection

• Substitution retrieval

• Single-call recipe rewrite with structured output

Iteration 2: Domain Adaptation 

Goal: Teach the model deeper knowledge of cooking chemistry + SCD.

• Switch to Llama-3 or Mistral for local control

• Continue pretraining on curated recipe + technique corpus

• Embed substitution reasoning (roles, hydration, acidity, fat ratios)

Iteration 3: Instruction Tuning 

Goal: Lock in predictable, structured responses.

• Fine-tune on prompt to response pairs for:

  • diff-style rewrites

  • substitution rationales

  • ingredient role detection

  • 7-day meal plans