CombDiet: Combinatorial Meal Planning & Optimization

• CombDiet is a combinatorial approach to meal planning that formulates multi-day dietary selections by considering complete meal compositions rather than individual recipes.
• It balances nutrition and convenience through structured recipe representations, user-specific constraints, and contextual bandit algorithms to optimize meal recommendations.
• The framework leverages a multimodal R3 schema and the BEACON system to integrate automated recipe conversion with personalized, long-horizon meal planning.

Searching arXiv for the cited CombDiet-related papers and adjacent diet optimization work. CombDiet denotes a class of combinatorial diet and meal-planning formulations in which the decision variable is a combination of foods rather than a single item. In recent arXiv usage, the term is most directly associated with a long-horizon meal recommendation setting that constructs multi-component meals over multiple days while balancing convenience and nutrition through structured recipe representations, goodness measures, and contextual bandits in the BEACON prototype system (Nagpal et al., 2024). Closely related work situates this setting within the broader tradition of diet optimization, especially least-cost nutrient-adequate diets formulated as linear programs (Wallingford et al., 2023, Prajapati et al., 7 Jan 2025). A distinct homonymous usage appears in machine vision, where “CombDiet” denotes a two-phase self-supervised learning curriculum rather than a food-planning method (Cai et al., 18 Nov 2025).

1. Problem domain and formal scope

In the meal-recommendation literature, CombDiet is fundamentally a combined meal recommendation problem rather than a single-item recommender. The central object is a meal plan $\mathcal{MP}$, represented as a structured set of meals over a configurable horizon. The system takes as input a set of recipes $\mathcal{R}$ in R3 format, a user profile $\mathcal{U}$ containing dietary condition and ternary food preferences such as likesDairy, likesNuts, and likesMeat, and meal-plan constraints $\mathcal{C}$. The output is a meal plan in JSON, produced by one of three methods: random selection, sequential selection, or bandit-based selection (Nagpal et al., 2024).

Meals are represented as compositions of food roles. The paper specifies roles including Beverage, Main, Side, and Dessert, and allows the meal-plan schema to define daily meal names, the number of meals per day, the components required for each meal, and the length of the plan in days. A simulated default configuration consists of Breakfast as Main Course plus Beverage, Lunch as Main Course plus Side plus Beverage, and Dinner as Main Course plus Side plus Dessert plus Beverage (Nagpal et al., 2024).

The temporal dimension is constitutive rather than incidental. The recommender is evaluated over $t_1$ = 1 day, $t_2$ = 3 days, and $t_3$ = 5 days, which makes the setting explicitly long-horizon. This distinguishes CombDiet from one-shot recommenders and aligns it with the observation that dietary decisions are distributed across days rather than isolated at the level of one dish or one transaction (Nagpal et al., 2024).

A common misconception is to interpret this formulation as merely “recipe recommendation.” The BEACON paper instead defines meal planning as a structured, multi-item, multi-day construction problem with configurable meal formats and user-level constraints, which places it closer to combinatorial planning than to conventional top-$k$ retrieval (Nagpal et al., 2024).

2. Tradeoffs, constraints, and goodness measures

The BEACON formulation defines CombDiet around a specific tradeoff: nutrition versus convenience. Nutrition is described through salt and sugar levels, nutrition content, explicit macronutrients and micronutrients, and binary ingredient indicators such as hasDairy, hasMeat, and hasNuts. Convenience is proxied by cost, speed to access, cuisine type, and food source type. The recipe base includes items from McDonald’s, Taco Bell, soul food dishes, and some general recipes, so convenience is operationalized partly through food availability and source characteristics (Nagpal et al., 2024).

The balance is not expressed as a single global constrained optimization problem. Instead, recommendation quality is scored by a weighted goodness function over three metrics: duplicate avoidance, meal-role coverage, and user-constraint satisfaction. For duplicate control, the paper defines

$dm = \frac{1}{n}\sum_{i=1}^{n} dm_i$

where $dm_i$ is the ratio of unique items to total items in meal $\mathcal{R}$0. User-constraint satisfaction is averaged analogously across meals. Overall goodness is written as

$\mathcal{R}$1

with weights tailored to user preferences (Nagpal et al., 2024).

This formulation has two important consequences. First, health-related behavior is mediated through constrained selection and weighting rather than by solving a nutrient-feasibility LP. Second, the objective is partly longitudinal: avoiding undesirable repetition and maintaining meal-format coverage across a planning horizon are treated as first-class recommendation criteria. This suggests a recommender that optimizes compatibility with a structured meal schema as much as it optimizes individual recipe desirability (Nagpal et al., 2024).

3. Data model, multimodal recipe representation, and reasoning

A major technical contribution associated with CombDiet is the use of R3, a multimodal rich recipe representation. R3 includes the recipe name, macronutrients, food roles, ingredients, allergen or feature flags such as hasDairy, hasMeat, and hasNuts, preparation and cook time, serving size, structured instructions, and modality fields such as image or video references. The intended advantage is that R3 captures both recipe content and preparation process, enabling reasoning over ingredient composition, nutrition, procedural structure, and meal-role suitability within a single schema (Nagpal et al., 2024).

The paper defines three recipe-conversion pipelines. $\mathcal{R}$2 is manual curation, with twenty-five RecipeQA recipes manually converted to R3. $\mathcal{R}$3 is a hybrid LLM-assisted pipeline with zero-shot prompting for ingredients and nutrients extraction, chain-of-thought plus few-shot prompting for instruction extraction, and LLM-based meal-component annotation, with binary food features manually annotated. $\mathcal{R}$4 is fully automated LLM conversion using Mixtral-8x7B-Instruct-v0.1 to generate complete R3 JSON from text recipes, exploring temperatures $\mathcal{R}$5, 1-shot/3-shot/5-shot prompting, and two example types, with the best reported configuration being 1-shot, $\mathcal{R}$6, and temperature 0.3 (Nagpal et al., 2024).

The conversion results are technically significant because they expose the present reliability boundary of LLM-based structured recipe extraction. The paper reports that LLMs alone do not reliably generate valid JSON R3, that only one of 24 Mixtral prompting configurations consistently produced valid JSON, that semantic preservation was generally better for LLM-based methods than manual baselines, and that manual curation had the best semantic fidelity. The stated conclusion is that dependable text-to-R3 conversion still requires rule-based or manual support, or further fine-tuning (Nagpal et al., 2024).

4. Recommendation methodology and learning pipeline

The recommendation engine is data-driven and relational. User and item information are represented as logical facts such as preference(user_5, negative_nuts), item(food_18, has_nuts), and recommendation(user_18, food_22), which are split into train and test sets and used by a relational boosted bandit method derived from Kakadiya et al. The system compares three recommendation strategies: M0: Random, M1: Sequential, and M2: Relational Boosted Bandit (Nagpal et al., 2024).

Operationally, the bandit predicts the probability that a user will prefer a recipe item given user and item features, and meal plans are then assembled from high-probability items subject to meal-format constraints. The workflow consists of representing users and items as predicate pairs, training boosted bandits on preference and recommendation examples, inferring preference probabilities on test pairs, and choosing items that maximize likely user preference while satisfying the meal schema (Nagpal et al., 2024).

Empirical evaluation is conducted across three time horizons and three user configurations, $\mathcal{R}$7, $\mathcal{R}$8, and $\mathcal{R}$9, described as decreasing strictness in user preferences. Metrics include $\mathcal{U}$0, $\mathcal{U}$1, $\mathcal{U}$2, and combinations such as $\mathcal{U}$3, $\mathcal{U}$4, $\mathcal{U}$5, and $\mathcal{U}$6. The main finding is that M2 outperforms random and sequential selection on user-constraint satisfaction, meal coverage, and combined metrics; M1 performs well on duplicate avoidance but lacks personalization; and M0 is weaker overall. Within the paper’s scope, this establishes contextual bandit learning as the strongest tradeoff method among the three evaluated recommenders (Nagpal et al., 2024).

5. BEACON as implementation and usage-inspired system

BEACON is the prototype system that operationalizes the CombDiet formulation. It is implemented as a web application with a React frontend, Django backend, REST APIs via Django REST Framework, R3 recipes stored in a NoSQL or JSON-like schema, meal plans stored as JSON, and user profiles maintained in relational storage (Nagpal et al., 2024).

The system exposes three user-facing interfaces. Meal Preference Configuration supports entry of health conditions, food preferences, cuisine preferences, and meal names and times. Meal Plan Presentation supports meal-plan viewing, regeneration of individual meals, goodness-score inspection, favorite saving, access to instructions, and optional ingredient ordering or meal customization. Dietary Insights and Analytics presents daily carbohydrate intake, hydration indicators, diversity scores, blood sugar stability, and meal composition visualizations (Nagpal et al., 2024).

The paper describes BEACON as usage-inspired because it is organized around realistic deployment scenarios, including diabetic users, culturally specific preferences, busy professionals, and medical professionals recommending meal plans. This characterization matters because the prototype is not framed solely as a benchmark artifact; it is explicitly aligned with practical meal-selection workflows and with recommendation contexts in which health conditions and convenience pressures coexist (Nagpal et al., 2024).

The paper also states several limitations. The dataset is small, at roughly 52 recipes; LLM-based recipe conversion is not yet robust; only three ingredient constraints—dairy, meat, and nuts—are modeled explicitly; evaluation is preliminary and not based on large-scale human studies; convenience is represented indirectly through proxies rather than through a formal utility function; and the experiments rely on simulated meal structures and fixed time frames. Future work includes expanding the recipe dataset, adding more ingredient and allergen features, trying more recommendation algorithms, further exploring R3, conducting qualitative evaluation, and fine-tuning LLMs for text-to-R3 conversion (Nagpal et al., 2024).

6. Relation to classical diet optimization and terminological ambiguity

CombDiet sits adjacent to, but is not identical with, the classical least-cost diet problem. In that literature, the diet is modeled as food quantities $\mathcal{U}$7 or $\mathcal{U}$8, the objective is to minimize cost, and nutrient adequacy is imposed through lower and upper bounds. A canonical formulation is

$\mathcal{U}$9

subject to non-negativity, an energy-balance equality, and nutrient lower and upper bounds, where nutrient intake is linearly additive in the food quantities (Wallingford et al., 2023). A recent Gurobi-based formulation uses continuous food weights $\mathcal{C}$0, minimizes $\mathcal{C}$1, and adds a diversity constraint

$\mathcal{C}$2

so that no ingredient exceeds 20% of the total meal weight (Prajapati et al., 7 Jan 2025).

The distinction is methodological and semantic. Least-cost diet models solve for nutrient-adequate bundles at minimum monetary cost and are often treated as LPs. The BEACON-style CombDiet problem instead outputs structured JSON meal plans with named meals, meal-role constraints, multi-day horizons, ingredient-preference satisfaction, and duplicate control. The two traditions therefore share the idea of selecting food combinations under constraints, but they differ in representational granularity, objective structure, and intended application domain (Nagpal et al., 2024, Prajapati et al., 7 Jan 2025).

A further source of ambiguity is terminological. In a separate arXiv line of work on self-supervised vision, CombDiet denotes a two-phase training curriculum defined as CATDiet warm-up + standard SSL training, while keeping TDiet active. There, it refers to grayscale-to-color and blur-to-sharp developmental schedules plus temporal continuity, evaluated on CO3D and SAYCam, and has no relation to food recommendation or diet optimization (Cai et al., 18 Nov 2025). For that reason, the term “CombDiet” currently requires domain disambiguation: in food-related research it denotes a combinatorial meal or diet selection setting, whereas in machine vision it is a curriculum-learning label attached to infant-inspired SSL (Nagpal et al., 2024, Cai et al., 18 Nov 2025).