Evolutionary Approach for Building, Exploring and Recommending Complex Items With Application in Nutritional Interventions

Over the last few years, the ability of recommender systems to help us in different environments has been increasing. Several systems try to offer solutions in highly complex environments such as nutrition, housing, or traveling. In this paper, we present a recommendation system capable of using different input sources (data and knowledge-based) and producing a complex structured output. We have used an evolutionary approach to combine several unitary items within a flexible structure and have built an initial set of complex configurable items. Then, a content-based approach refines (in terms of preferences) these candidates to offer a final recommendation. We conclude with the application of this approach to the healthy diet recommendation problem, addressing its strengths in this domain.


I. INTRODUCTION
Recommendation systems (hereinafter referred to as RS) are a type of information filtering system that seeks to predict the preference a user would give to a set of items [1]. In our daily lives, RS usually serve as tools to simplify our experience in technology-based services (such as e-commerce) by offering items to users based on their characteristics or specific requests. However, RS are used in a variety of areas, each with its own unique features that present new and different challenges.
RS have two main characteristics that define the ''recommendation problem'': the data used (both raw and processed) and the recommendation model.
When describing the data, RS use two sources of information to a greater or lesser extent: users and items. These The associate editor coordinating the review of this manuscript and approving it for publication was Pasquale De Meo . sources can be combined or used in different sub-processes of the system. Users can be defined as entities (not only people) that request recommendations. From these users, depending on our recommendation strategy, we will obtain information about them, their search requirements, or their historical interactions with the items. Secondly, the items are the elements that we are going to recommend to our users. Again, we can have a wide variety of information about them, such as their intrinsic characteristics, the tags that describe them, or the type of users that rate them positively.
In addition to the aforementioned categories, there exists another significant category known as a knowledge-based data source. This particular category is not universally present in all recommendation strategies [2], and we shall make reference to it whenever we utilize data sources that do not align with either the Users or Items category. Examples of such data sources include contextual information, expert opinions, and temporal decisions. In numerous scenarios, incorporating this additional knowledge is crucial for providing high-quality recommendations, particularly in situations where multiple factors are at play or can influence the user's life and choices. In essence, we employ these sources when we believe that gaining a broader and more expert perspective on the problem at hand enhances the final recommendation.
The manner in which we incorporate these three data sources into the recommendation process serves as a broad categorization of the type of recommendation we are formulating and the strategies we can employ. Consequently, employing item characteristics to anticipate user preferences, as in the case of content-based filtering, differs from utilizing the preferences of a large user base to predict the preferences of a new user, which is a technique referred to as collaborative filtering.
However, as we have seen, the new opportunities presented by the processing of large amounts of different data (using technologies such as deep learning [3]) have led to the creation of increasingly hybrid systems. These systems are able to encode and use a more complex representation of user, contextual, and item data, leading us to a research landscape where many systems operate in a hybrid way.
These changes affect not only the algorithms and recommender strategies but also the problems that we can solve through these systems.
While much of the research focuses on what we might call simple items, access to more data allows us to work on more challenging everyday problems. To exemplify this difference, we can compare the problem of recommending a unique dish for dinner versus recommending a weekly diet [4].
If we wanted to recommend a single dish, we would have a well-defined and bounded item with a finite set of characteristics. We may have a lot of information about a specific dish, both objective (cooking, nutritional value) and subjective (many people like it, it is popular, it is very spicy). However, the item is defined and bounded. To recommend a diet, on the other hand, we must consider not only the factors mentioned above but also the food benefits for the user, the combinations of ingredients we can offer, the combinations that can negatively affect the user, and even the elements we should recommend, even if they do not align with the culinary preferences of our user.
Therefore, the problem becomes more complex, partly due to the possible internal structure of the recommendation (viewing a diet as a structure built by different dishes) and partly due to the significant impact it can have on the user's life (a single dinner versus a daily diet over time).
These two characteristics (complexity, structure) define the types of problems we intend to address in this work and motivate the recommendation system we propose, along with its main features.
After the introduction, in Section II, we will provide a formal definition of the terms describing our problem, along with examples of these terms. Section III will describe the theoretical details of our recommender system, outlining its different components. Next, we will explain how to apply our approach to a real-world application and discuss their benefits in Section IV. Finally, we will conclude the article with Section V, where we will discuss some considerations regarding our model and outline future research directions.

II. RELATED WORK: STRUCTURED RECOMMENDATIONS IN COMPLEX SCENARIOS
As mentioned in the introduction, this study and the recommendation model proposed focus on specific problems that fulfill this scenario: we want to recommend a structured object from a set of simpler items and we want to deal with multiple objectives that have different levels of precision. We are going to refer to this two fundamental characteristics as structured recommendation and multiobjetive recommendation.
• Multiobjetive recommendation: Multi-objective recommendation involves generating personalized recommendations that consider multiple conflicting objectives or criteria simultaneously. This area has become quite relevant, since we have now bigger amount of data to produce the recommendations process. But despite its use on several areas [5], [6], some of these works focus on specific aspects of the recommendation process (diversity, novelty), that is not our case. We are going to deal with scenarios from real-world applications. We call this scenario ''complex scenarios''. Complex scenarios force us to deal with the sources of constraint: knowledge-based constraints, expert-advise constraint and user-based rules (or user preferences). The complexity of the input is often determined by the problem and the data we can access. Examples of application areas facing such situations are those related to tourism or housing choice [7], [8], [9]. But it is in health recommender systems [10] where we found natural examples of multiple constraint from multiple sources. As examples, it is already common to have systems to help us decide what to eat [11] (more on this topic in Section IV), how we should exercise [12], [13] or what to do when we are ill [14].

• Structured recommendation:
If the items we recommend have a structure (and this structure is involved in the recommendation process) our system will be a structured recommender system. This type of system is often explored in the scientific literature through sequential or set recommender systems in multiple areas (fashionable sets of [15], [16], and [17] or cultural travel [18], [19]). However, in this paper, we will refer to a structured recommendation when we recommend a set of interrelated items, following a design/structure that can be customized according to the user. It should be noted that both the structure, and the set of items in it, as a whole, are the output of the system and is presented as such to the user. The system output does not constitute a recommendation sequence in time, with multiple items one after another. Although this approach could affect the adaptability of the output, it gives our system a greater ability to incorporate more relationships and rules. Furthermore, the system can be re-evaluated if the user or the situation requires modifications. As a consequence, any part of the structure can be modified, to a certain limit.

III. EVOLUTIONARY STRUCTURED RECOMMENDATION ALGORITHM
In this Section, we are going to present our proposed algorithm (see Figure 1) for complex structured recommendations. During the text, some brief examples will appear to clarify the concepts discussed. We will expand these applications upon Section IV. It is worth noting that definitions in the next subsections can be adapted to fulfill the specific requirements of our problem. This flexibility is necessary due to the different nature of the problems approachable with this model. We offer a secondary figure 3 where all variables depicted in this section can be easily consulted.

A. SOURCES OF DATA AND MAIN OBJECTIVE OF THE STUDY
One of the crucial parts of any recommendation process is the acquisition of the necessary data. In our case, the data sources needed may vary in nature, extent and characteristics, but they always correspond to three essential elements in our system.
The first two, as in any recommendation, are the space of Items to recommend and the space of Users. We denote the spaces of these elements by I and U respectively. The elements of each of these spaces belong to p-dimensional, q-dimensional space and are encoded by an array of parameters, {i 1 , . . . , i p } = I and {u 1 , . . . , u q } = U. Moreover, we need an additional source of information that contain expert knowledge K about our problem. This last source of data can affect any phase of the recommendation, often formulated as a set of parameters or constraints on the set I denoted by K = {k 1 , . . . , k l }. In both U, K we have all the information related to the structure of our future recommendation and the relationships between items.
The final items recommended are not those elements of our initial data source I. Items in I are just a lower conceptual unit with no structure and no relationship between its parts. In some problems, we may obtain a rich source of data that contains complex objects. But in reality, this is far from usual, and not realistic at all dealing with personalized problems. From now on we will denote the elements of I as sub-items in order to differentiate them from the definitive Items.
Thus, our first goal is the generation of the definitive Items which built our final recommendation. In the next subsection we elaborate further on their generation, but we identify here that the set of these items obeys the form L(I, U, K) = {{1 i , . . . , a i }, . . . , {1 i , . . . , b i }}. This form represents sets of elements of I that are dependent on the sub-items which will form it, the constraints proposed by the user and the characteristics proposed by other knowledge-based sources. For simplicity, we will denote it asǏ = L(I, U, K) from now on. Note that this set may not be a subset of the set of parts of I, up to this point, unless otherwise stated, repetitions of elements of I could occur in it.
With these sets we can now define the objective of our system: Given an initial set I = {1 i , . . . , n i } we want to obtain a subset of structured combinations of elements of I denotedǏ for each user from the set U = {1 u , . . . , m u }, so that it optimizes the needs and some preferences of each user as well as the parameters from K = {k 1 , . . . , k l }.
To better understand this definition, we can think of a classic recommendation problem such as personalized nutrition. In this case, we would have the recipes as the elements of I with their respective quantities of ingredients. U would be the set of users of the application, each one with different characteristics such as weight, age, or what pathologies they may suffer from. In addition, K would be the set of all the parameters that a healthy diet needs to satisfy (percentage of kilocalories, fat, or seasonality, amongst others). The objects that will appear inǏ will be groups of recipes (associated with a meal structure) depending on the user and the nutritional information we have.

B. CREATION OF THE ITEM SPACE
The final item spaceǏ is the space in which the logic of our recommender system operates. Obtaining a space of this complexity can be a hard and time-consuming task due to difficulties in finding and processing useful databases. For this reason, our system uses data with a lower conceptual level as bricks to build the final dataset.
This approach will favour the adaptation of the spaceǏ to the initial information and to those parameters of K and U involved in this part.
This task works through an evolutionary algorithm whose objective is to obtain a subset of elements fromǏ that satisfies {u 1+x , . . . , u q+x } y {k 1+z , . . . , k l−z }.
Note that these parameters, by notation, are a sub-set of the total parameters. It is worth remarking this, since some of them may be used elsewhere in the system or with other functions.
Within these parameters, there are two distinct types: • On the one hand, we will denote E(U, K) as those parameters that intervene in the generation of the structure.
Although they affect characteristics such as convergence or the speed of the algorithm, they do not intervene directly in the evaluation of that candidate. We can think of them as parameters that only admit two values, whether they are in the final item or not, and therefore we will eliminate any element that does not have them or, if necessary, we will mark them as a condition to be fulfilled before evaluating the fitness of these objects. This step can also be considered as a preprocessing step if the constraint affect solely to the items that are VOLUME 11, 2023  considered in the creation of the bundles. However, these constraints can also affect to the whole structure. For example: certain elements are sufficiently spaced within the recommendation or the proportion of them follows a rule (as on per bundle).
• On the other hand, denoted as V(U, K) are those parameters on which the fitness functions of the genetic algorithm act and which admit adjustments and variations during the generation process.
During the first part of the generation step, we will randomly create elements ofǏ. This set, which we will call H ⊂Ǐ, verifies E(U, K) by construction. We then need to describe the fitness function that evaluates which changes of the elements bring us closer to satisfying the parameters in V(U, K).
For example: in a dietary advice recommender, this step should produce a menu by filling in the selected structure (such as breakfast, lunch, and dinner). This structure is part of the parameters E(U, K). In this set, we can also have information about allergens or intolerances, which rule out which elements of I cannot be within the structure.
In V(U, K) we have characteristics such as ''expected total purchase price'', ''seasonality'', ''amount of an ingredient'', or ''amounts of different nutrients'', all of them are that the recommendation should have. However their amount have different ranges of acceptability, i.e. total kilocalory consumption in the day may be more or less than 100 kilocalories without affecting the user if the daily average stays close to the objective.

1) FITNESS FUNCTION
In this Section we will focus on those parameters that appear in the set V(U, K). We denote V U as the set of parameters from the user personalization and V K as the set of parameters from alternative data sources. Then we define the fitness function of our genetic algorithm as: where W V U is the weight associated to user's parameters and W V K is the weight associated to extra data sources and expert knowledge that is taken into account.
The functions f U and f K are defined: in this case optimal k,u represents the optimal value to be reached by k, u. In addition, v(optimal k,u ) is defined as : v(optimal k,u ) = optimal k,u * C/(k, u range ) 2 (4) where k, u range are the specific range of acceptance for k, u and C is the global optimum of the criterion (if we establish that our convergence criterion is acceptable when the value is less than 10, this function changes the scale of our acceptance function, in order to punish solutions that fall outside this interval). We treated this set of constraints as a set of different ranges of values. Inside them, the most optimal (with the smallest score) value will be the midpoint of that range. These ranges are a translation on what is defined by user's or expert's opinion.
For simplicity, we have omitted those parameters that act as modifiers, but, for completeness, we develop them here: Some parameters in K o U, do not generate modifications directly in x ∈ I, they will affect other parameters as g ′ k : An example of these parameters in the nutrition application would be a reduction on the limits of the daily cholesterol consumption due to the existence of a pathology.
In the discussion below, it is assumed that these parameters are applied in the functions and that, by construction, they have the form described above.
Thanks to the fitness function we can summarize the optimization problem describe in this subsection as follows:

2) OTHER FUNCTIONS ASSOCIATED TO THE GENERATION PROCESS
The rest of the associated functions that make up the evolutionary algorithm are often associated with different characteristics of the generation process. Thus, the classical crossover, mutation and selection functions are determined according to our objective concerning the variation of the solutions, the avoidance of local minima, and the structure of the elements ofǏ. In our case they will be defined as follows: • Selection function: The selection functions are based on the fitness function. These functions select those objects fromǏ with a higher score to be the candidates to expand their genome in the next generation. In situations where we are interested in a large variety, such as those presented in the paper, we have opted for a probabilistic function based on subsets of n elements. In our case, this function is able to produce high diversity. At the same time, it is capable of generating solutions with huge potential in the next steps (which can be obtained later with crossover and mutations).
• Crossover function: In our applications, the objects that make up the chromosome are directly related to the structure of the elements that are recommended. Thus, during the crossover, elements of I that are in a similar position relative to each other (and relative to each of their structures) that are part ofǏ can be swapped. The frequency and arrangement in which they do so will depend on what features we are looking for. In our work, we have opted for a classical crossover that splits two solutions into two different sections and exchanges one part with the other.
• Mutation function: Mutation functions alter elements of I within the structure. They are therefore an interesting parameter to adjust in terms of their form and action. These functions can act on concrete or general subsets of the final structure. For example, in a nutritional recommendation system, the structure has a series of subsets related to each meal and filled with elements of our base dataset I. These elements also have a quantity associated with them. The mutation, in this case, could be done (with a given probability) on a block of food, half of the structure, a particular meal, or a particular size.

C. SOLUTION REFINEMENT
The above procedure has allowed us to create a set of items adjusted to the selected parameters from the user and other additional sources of information. Furthermore, this set of solutions has a selected structure and it items preserve the relationships imposed during the generation process. This set is also highly diverse. Its variability is not intrinsic to the model and is produced by the genetic algorithm. Parameters such us the stopping condition, the number of generations, the initialization of the population, the mutation rate or the types of mutation, can affect and generate different combinations. These features can also prevent the convergence of the algorithm to its global optimum, offering local sub-optimalities that can be refined in later phases and are sufficiently different from the previous ones.
We also make special emphasis on the initialization of the algorithm, as it can offer another customizable parameter and relegates much of the weight to the initial dataset. One of the downsides of these approaches is that it forces us to have a sufficiently well-annotated and diverse initial dataset or at least varied in those characteristics where we want to have huge variability.
At this point, thanks to all the previous conditions, we have a set of solutions that satisfy a series of imposed restrictions VOLUME 11, 2023 (to a greater or lesser extent, but always between the marked limits). This allows us to obtain a space of solutions or a subset of it, on which we can apply more specific algorithms of RS, but without depending on many constraints.
In the nutritional case, the solutions obtained so far meet the main characteristics associated with the healthiness of the model and the user's objectives, as these directly affect the final amount of nutrients. We can now focus on selecting from these alternatives, the one that best aligns with their preferences and tastes.
This improvement, using the same measures, will be done in three steps as described in Figure 2. First, we will have an evaluation phase where we analyze those elements that conform to our solutions. Through them, we will be able to know if any of the elements of I are marked by the user as non-preferential (or close to a non-preferential item). Notice that this may happen in this phase, since we are talking about preferences that may not be fulfilled for the sake of a recommendation adapted to the user's needs and constraints.
Once we have analyzed those elements of our structure that have room for improvement, we will look for elements in our database that are similar in the desired characteristics (V(U, K)), but that are not marked as non-preferred by the user (either because they are marked as liked or because they lack a negative evaluation).
We make as many changes as possible (or up to a specific changing rate) without altering our initial structure and move on to the last evaluation.
Finally, we select one of the generated and refined recommendations. We compute the scores associated with the user's preferences (at the conceptual levels we have chosen) to give a weighted average of the final score of the menu. An application example can be found in Figure 4.

D. CONTENT BASED SYSTEM
For both the evaluation and refinement steps, a content-based system is the natural step to take. This is due to several characteristics: • First, the objects we are recommending already have a high degree of conceptualization. They are composite objects with a lot of data and relationships between them, so an approach based on exploiting precisely that information is very relevant.
• The content-based system is robust to cold start, which may be the case of several items in our database.
• Finally, we must not forget that the starting dataset can be very diverse (or the system has diversity conditions when it is generated), which means that, if we generate the initial population on which to apply the second phase, we will find unique objects, which would cause a user/item matrix to be very sparse.
These characteristics, while relevant, can be addressed with other types of systems, or even with hybrid systems. On the other hand, in order to use other methods such as collaborative approaches, we would need another source of information in our system (i.e. a user database and their interactions). We discuss this type of improvements in Section V.

1) SIMILARITY MEASURES
This section is highly variable depending on the area of application. However, as we have already mentioned, due to the large amount of information we have on the products, several similarity measures associated with different aspects can be established.
Each element that makes up our final items has a set of characteristics, denoted as i 1 , . . . , i p . These characteristics can range from specific values to multivalued or Boolean labels (possesses a quality or does not possess a quality).
This fact allows us to transform these elements into vectors of a multidimensional space on which to apply different metrics. These metrics can be evaluated from the user's own profile, or by collecting those elements that the user has rated positively. Which one we apply will depend on our objectives and the nature of our data.
In particular, given that we are working with items created from the combination of another set, the characteristics we use can be a very high dimensional space. Therefore, the similarity metrics used in natural language processing, adapted to this kind of similar nature, are applicable in our approach.
Moreover, as we have been pointing out throughout the text, the presence of bi-valued or Boolean variables may also be common. This is why if we assume that k is the number of features of the elements of I appearing in the sub-set of H selected for the recommendation process, we highlight two similarity measures: • For those variables that encode information of a different nature, operations such as weighted cosine similarity provide a metric that works optimally with large amounts of data even though the data are sparse: i j i j define the j-th parameter of x or y in I where the value w i j of those selected can represent different motivations (explained later in one of the applications).
• For those scores that are evaluated with a characteristic array composed of bi-valued variables, we can also use Jaccard's Similarity, especially useful if we seek to design a metric where we detect items whose composition is very similar (whether it is a desirable quality or not). We could transform some parameters into a binary set or use a generalized version of the Jaccard index for real valued vectors: i max x i , y i i j define the j-th parameter of x or y in I Once again, we highlight that other measures of similarity or distance are easily usable, and this will depend on the nature of our data and objectives whether we use one or the other. Lastly this evaluation can be taken into account with the fitness evaluation from the first part as another important weighted factor. A final score, weighted sum of all the score used, is set as the final threshold to surpass.

IV. APPLICATIONS
In this Section we offer a complete walkthrought of a possible application of the theoretical recommender system develop on this topic. After this example, will briefly discuss other possible scenarios.
The field of personalized nutrition, which is experiencing great growth [20], [21], and we believe can benefit greatly from our approach.

A. DIETARY LONG-TERM ADVICE
Recommending a long-term diet is a highly complex but critical important problem. This is mainly due to some differences between this environment and similar ones that only focus on single and simpler recommendations.
An ideal long-term food recommendation system must be flexible enough to deal with the trade-off between personalized food preference/interest and nutritional/health requirements. We must take into account food preferences since it is unrealistic to think that subjects will drastically change their diet or tastes based on our suggestions. However, pathologies, allergies or other medical conditions that directly affect the subject's health (such as intestinal microbiota [22] or genomics [23]) must be taken into account.
Furthermore, we need to correctly understand what role the intrinsic characteristics of food play, and how they affect the predisposition of a user to choose a dish. That is to say, we may choose a quite different dish to eat for a midday dessert or a main dish for dinner.
Finally, is essential to understand how physical activity, pathology and user are related, and how they impact diet choices. Whether our objective is to change from one physical situation to another (weight loss) or to palliate any deficiency produced by a pathology (anemia), the system must be able to offer different recommendations that deal with the different objectives and states of users.
Earlier works on these topics mostly focus on dealing with user preferences when recommending (as for example in a restaurant). Then, works where health plays a leading role appears [24]. Along them, another relevant corpus on how to extract information and ontology's from recipes, textual and visual data references [25] evolve and they become another central part of these food recommendation systems.
Finally, in recent years, more recommender systems try to deal with users preferences and nutritional values, given the importance of a healthy nutrition in our lives [26]. Then the objective shift on how to deal with multiple constrain and preferences. Works like [27] combine several parameter while classifying ingredients. More recently [28] focus on certain health issues to recommend food for CKD patients, but in return they focus on fulfill only specific parameters for them. Evolutionary algorithms has also been used with good results. Works like [13] and [29] began to explore the possibility of using evolutionary algorithms to produces bundles or sets to be recommended (and extra source of recommendation with physical exercises).
However, our approach specifically focus on recipes, which give a context to the ingredients. On this behalf recent approaches has already use a multiobjetive optimization approach [30], which again state that evolutionary algorithm are useful for the recommendation of food. However, while this system learn a recipe pattern, most plans and nutritional intervention follows a more standard approach. Our system is more focused in this type of scenarios, as we have full control on the relations that we obtain when creating the initial population of menus. Moreover, this also improve the time performance of the algorithm. At the same time we can VOLUME 11, 2023 use the system to explore which set con parameters can not produce feasible combinations, that can offer the experts a starting point for completing the recipe database or let the user know if their pattern can be problematic to fullfill (for example if a user is physically active but eat small isolated portions of food).
Therefore, the nutritional application of our recommendation system is an application based on evolutionary algorithms, which are used for the creation and refinement of daily menus capable of incorporating constraints and rules at different levels of restriction. These rules can be specified at the precision level of different nutrients and are robust against user choices.
A graphic summary of this application can be found on Figure 3.

1) SOURCES OF DATA
Personalized nutrition problems usually have a set of different data sources. In our case we are going to follow the notation described in Section III, classifying them into three categories: • I: The space of items will be created based on the [31] and [32] databases that have data about recipes and their nutritional values. Most of the time, the recommendation processes use ingredients to give nutritional advice [20]. But we do not understand food in our daily lives like this. For that reason we define our primary sub-item space as a set of different recipes. Recipes also have extra information about its seasonality or cooking methods that can be used in the recommendation. Thus, recipes in I will form the menu that will be recommended to users.
• U: The user space stores all the users of the application with the characteristics that have a direct impact on the system. The user's preferences as well as physical and health status are part of these parameters. Other parameters such as the usual quantities of certain recipes consumed by the user, the structure of his menu or their fitness goals must be taken into account during the generation process. Finally, in this category, we will also find parameters that define the user at a biometric level, such as BMI, weight or height, necessary to calculate the energy expenditure throughout the day.
• K: Expert knowledge will be the most diverse set of parameters in this problem. Within this set, we will have information about the choices the user can make regarding some of its parameters (i.e. the different menu structures supported). These parameters also encode the nutritional values associated with the healthy amount of each nutrient. These amounts will be affected according to the user's condition, physical activity or pathologies. Any additional information from nutrition experts will be stored in this set.

2) CREATION OF THE ITEM SPACE AND FIRST GENERATION
Once we have defined the initial items, we proceed with the creation of the final item space. This first part is already an element of the recommendation process, since some user characteristics U, as well as the constraints of K, are taken into account in this creation. From U we collect all the parameters that build a biomedical profile of our user (with data such as BMI, weight, height or the amount of body fat).
On the other hand, with respect to K we collect two types of constraints. Those that directly relate the healthy amount of nutrients the user should have, according to their data. And those that intervene in the menu generation: type of cuisine, seasonality, possible menu structures.
It is particularly relevant to point out how the structure of the menu is selected. In this case the final structure of the recommendation depends both on the user and on the parameters of K. In this model we make use of expert knowledge and propose common food patterns. This generates a first set of structures that we can use. However, in order to make the system flexible, it is up to the user to choose which of these structures is the most appropriate for their daily diet.
All the parameters selected are included in the final item space considered by our system. This space is made up of daily menus composed of dishes, which follow a structure and relationships set by the user and the expert knowledge.
Finally, the first module, configured as stated in Section III, produces a sub-set of the processed item space. This generation process tries to find which generated items are closer to our objective, defined by the fitness evaluation. The size of the initial sub-set of the item database and the mutation functions of the genetic algorithm allow us to ensure some variability in the results.

3) SOLUTION REFINEMENT AND RECOMMENDATION
At this point we have a structure filled with sub-items from I that verify the main constraints selected for the first part of our recommendation process.
From here we move on to the second phase where we refine these solutions according to a more classical approach, based on (mainly) user preferences. A graphic summary can be found in Figure 4.
This procedure consists of two parts. On the one hand, the personalization of the generated menus (corresponding to Evaluation and Refinement in Figure 4) and on the other hand, the choice of the menus that best fit the user's preferences (corresponding to Content-based final evaluation in Figure 4).
Firstly, given the dishes that are associated with our menu (i.e. the elements of I that appear in H), we can choose those that are negatively valued by the user. These items must be replaced by a similar dish. For them, we will use euclidean similarity, looking for those dishes that are very similar nutritionally speaking, but that are marked as indifferent or liked  by the user rather than disliked. It is possible that we are unable to find a realistic improvement in this structure. If this is the case, we still keep the solution for the last phase.
Finally, from the set of secondary recommendations, we will evaluate which is closer to the user's tastes (using the similarities define in section III-D1). In this case we recover some information from I to develop three types of evaluated and weighted scores: 1) Dish category: Those menus that have a higher frequency of labels common to the dishes valued positively by the user: meats, salads, fruit, etc. We will compare the set of tags from a menu with the set of tags from the user and derive a distance from it. 2) Fitness functions: Fitness of the menus evaluated.
We will use a cosine similarity metric to compare set of normalize nutrients.
The weighting of these characteristics not only reflects the relative importance of each of the similarities compared to the rest, but can also be related to other types of information. In the nutritional case, similarity could be scored more positively if it is found in a main dish within the menu structure, as there is a correlation between the overall quantity and significance of the main dish compared to smaller side dishes or desserts. Another option could be to assign extra value to the fitness function evaluations.

4) EXPERIMENTAL OFFLINE EVALUATION
For the first evaluation of the model we followed a offline test based on different user profiles. Those where selected in the Stance4Health project. The Stance4Health project (Smart Technologies for personalized Nutrition and Consumer Engagement) (S4H) is a project funded by European Union's Horizon 2020 research and innovation program. Our main focus was to show that this approach can achieve reasonable results for a realistic user in a nutrition intervention. The ability to produce healthy menus has already been validated by nutritionist in [33] for different micronutrients. However In this section we will show that the model can obtain healthy menus from different configuration, showing its robustness to different patterns, sizes or restrictions.
Moreover we will offer novel insights on the secondary recommendation module. For this task we choose a standard healthy male human, with a normal IMC, moderately active which result in a General Metabolic Rate of 2000 kcal a day. For this user we have design the following scenarios, along with and explanation on which situation they can be useful: • S0:User does not take anything in the morning and single recipes for lunch and dinner. Its portions are standard portions.(Adapt to user behaviour) • S1:User make 3 meals a day • S2: User make 4 meals a day • S3; User make 5 meals a day (Calorie surplus) • s4: User demand fish as the main ingredient of lunch and dinner (ability to adapt to certain type of dish, this is necessary to provide not daily, but weekly recommendation, where we can incorporate Mediterranean patterns in the diet) • s5: User demand meat as the main ingredient of lunch and dinner (ability to adapt to certain type of dish, this is necessary to provide not daily, but weekly recommendation, where we can incorporate Mediterranean patterns in the diet) • s6: User is allergic to milk • s7: User demand higher portion of dishes (have a good appetite, vegan diets) • s8: User demand the smallest quantity possible. (Troubles eating, inability to cook) An example of the output menu can be seen in figure 2. We divided the tests in different stages, one for the nutritional adjustments of the menu (which is the main focus of the first part) And one for the second part, centered in the content based recommendation system.
For the evaluation of the genetic evolution process we run a set of 30 different menus modifying the algorithmic-centered parameters, those are: number of generations, fitness functions, initial population, type of crossover, probability of crossovers. Based on the first set of tests, we chose the parameters described in table 3 for the next part of the evaluation. For the threshold we base our results on the scores of the nutritional validation [33].
With this set of values we then run the primary recommendation system throught 50 different days in each scenario. In this process we start using the most basic fitness function declare in III taking only the data from the kcalories. We re run this experiments using a more advance definition of the fitness function taking into account kcalories and macronutrient levels. Finally, we produce the last batch of experiments using the most advanced fitness function. As we can see in figures 5-10 along 200 steps in the generation process, all fitness functions stay below their acceptance threshold, but the variability of data force us to reach between 250 and 300 generations to stay below the accepted level in all situations. These evaluations use all the three possible fitness functions built with the nutrient levels. It is worth noting that we are using only the last one for evaluating the population, where all the parameters are encoded as the formula presented in (5). The two upper plots represent how these less complex fitness functions built as Eq. (5) but with less nutritional parameters decay as well as the most complex one is used.
On the second part of the recommendation we proceed to change the menus according to the preferences in food types the user give us. Every recipe in the dataset has two set of characteristics: one with a general pyramid-type of food and other ontological related to that one related to the type of dish (over 35 different categories). We use that information and the user preferences to calculate the distance between the user preferences in terms of food types and the user disfavors in term of the menu food types. For that we use a Jaccard similarity type as boolean vector of length 35 (has this food type, do not have it) and evaluate to both types of preferences.   Ideally the distance of like categories will decrease while the distance to the disliked types will increase.
However we still have to take into account the nutritional score. Throughout the preference metrics we will add up the fitness score function to penalize those menu changes that diverge too much from the recommendation (due to the absence of similar dishes that match the preferences).
We perform this second part with a random assignation of like and dislike dishes, and two more oriented one: only like meat and no vegetables and the opposite: plant-based diet with little to no-meat. The variability of the distance from the liked-by-user pattern and disliked-by-user pattern is shown in Table 4. Moreover a kcal and all nutrient oscillations are also shown.  For this section we force at least one change in the menu for all the menus created before. However two or more changes were discarded if they disrupt the healthy level of nutrients. On overall we get an decrease in the like metrics while a increase in the distance form the dislike options. Along this changes, most of the nutritional level stayed close to the original ones and the objective one.

V. DISCUSSIONS AND RESEARCH LINES
There are several remarks to be made about this type of system. We want to highlight some of them along with the research directions that would improve our results.

A. DATA SOURCES AND EXPECTED OUTCOME
Having a sufficiently large dataset can prove highly advantageous for establishing an initial set of recipes, denoted as I, that is substantial enough to offer a significant range of choices to users. However, further research is still needed to explore the impact of various factors on the recommendation process. Specifically, we posit that investigating the optimal number of recipes required, the number of user recipes that can be incorporated into the original dataset, and the types of recipes to be added to the initial dataset are pivotal considerations. Such investigations are crucial not only for narrowing down the search space but also for presenting users with options that closely align with their preferences.
Furthermore, constructing complete dataset with recipes and multiple nutrients information would facilitate the comprehensive evaluation of menus from a broader perspective. By considering multiple nutrients, such a system would enable the assessment of whether a set of recipes can yield healthy values across various menu configurations. This type of system would also prove valuable in nutritional intervention scenarios like Stance4Health, where users are more inclined to adopt complete recipes as opposed to isolated ingredients. From the expert standpoint, this system would empower the generation of comprehensive menus based on user requirements, preferences, and nutrient levels.

B. EVALUATION AND USER ADHERENCE
One of the main concerns in recommender system is the evaluation process. Finding an optimal way to measure how correct are our recommendations, and how users may perceive them, is a crucial step. In addition how we translate this feedback into the recommendation process is also a relevant task. For example, upgrading our system to give more weight to users' preferences may please the user, but at the same time it could affect to the different constraints and rules that are significantly knowledge-based as dietary patterns or nutrient levels. Moreover, bundle recommendation and sequence recommendation produce new specific challenges. When evaluating a set of objects, we may have a single item in the bundle that could transform our decent recommendation into a bad one. Or perhaps a slightly positive collection of products is better rated by the user than a set where one item is rated very positively, but the rest are unknown. Evaluating these factors can make a big difference to the final result.
Some studies already suggest the possibility of evaluating how constraints can affect the optimization of recommendations [6], [28], [34]. In our case, we believe that our system has a great potential to study how different rules are correlated, if they can produce acceptable outputs or even if we need certain types of simple items in our database that enables the later creation of complex items that fulfill our necessities.
This evaluation is not only important for the performance of the system. In addition, the complexity of the recommendations makes it difficult to compare the system with other similar systems. This problem itself also opens another line of interesting research that we would like to explore in near future.
Finally, it is worth noting that some scenarios presented in Section IV are meant to be used continuously in time. Specifically in these situations, a positive evaluation will be key to maximizing user's adherence to the system, which may be needed for long-lasting changes.

C. INTERPRETABILITY OF THE SYSTEM
In Section III we defined E(U, K) and V(U, K). These two sets of parameters encode the two categories that should be differentiated when attempting interpretability strategies: • The fixed constraint that will mostly obey very strict rules and admit only small variations • Those characteristics that function as parameters or rules that admit modification by the user.
Within these two categories, a significant portion of the information can be classified into the user-based and itembased explanations, as proposed in Zhang et al. [35]. These categories, along with feature-based explanations, have the potential to provide substantial information to the user, aiding their decision-making process.
Certain application areas may involve subjective factors for the user. Hence, it becomes crucial to evaluate which aspects the user deems most important in order to enhance acceptance and adherence to our recommendations.
Identifying the pertinent information to display, considering factors such as the user's prior knowledge, and determining the optimal way to present it, pose significant and intriguing challenges within our system. The complexity arises from the extensive conceptual load and intricate interrelationships that must be considered during the recommendation process. However, addressing this challenge will be a pivotal aspect in improving the interpretability of the system for the user.

D. ETHICS AND FAIRNESS
As we have been pointing out throughout the survey, two of the main (defining) characteristics of RS in complex scenarios are complexity and high impact. Complexity because of the large number of relationships and structures involved, and impact, because of the ability of these systems to significantly affect people's lives.
The characteristics of these systems, and the areas where they are applied, make an excellent case for delving into the repercussions of RS on our society. And therefore, how they affect us and how they should affect us. With the contributions to Ethics and Fairness becoming more and more relevant [36], and looking at the technologies described in this study, the analysis of the ethics and impact of RS will gradually become more and more important.
This study will be fundamental to ensure that the synergies between these systems and our lives are made with the greatest possible guarantees for the user, but also for all the stakeholders involved [37]. It is also worth noting that these complex situations often lead to ethical considerations. A clear example of this will be how to offer a recommendation that may contain aspects the user could (in some degree) dislike, due to its benefits in the long term.

E. HYBRIDIZATION
In addition to content-based filtering we could use other types of filtering during the recommender process. However, in most cases we would have to deal with additional information that is added to the system. Specifically collaborative filtering can be a good starting point to hybridize our system and get the benefits of it, when we have a sufficiently large mass of users. For this we would have to decide which model to use, both in the collaborative section and in the hybridization process. It should be noted that some advantages of the collaborative approach, such as serendipity, are to some extent covered by the randomness of the first phase of our recommendation.
Other advantages of this hybridization also depend on the problem we want to solve. Areas such as nutrition have more important constraints to meet and do not need a greater capacity for ''surprise'' to satisfy the user. On the contrary, when we work with problems where we apply less significance to the items and more to the structure, this type of hybridization may offer more desirable features. This would be the case for podcasts.
Overall, we can hybridize our system with collaborative filtering and other recommendation approaches depending on our objectives, such as those based on sessions or reinforcement, which allow us to capture useful contextual information for the user. These add-ons will probably allow us to apply our approach to more problems, but further research on them is required.

VI. CONCLUSION
Given the remarkable success and widespread adoption of Recommendation Systems in our society, their application to complex scenarios is expected to continue expanding. This growth can be attributed, in part, to the incorporation of various sources of conceptual, relational, and contextual information into these systems, along with advancements in algorithms capable of effectively integrating such information.
These advancements in understanding and incorporating information empower us to develop systems that can assist us in making decisions of high complexity in our daily lives. In particular, we have proposed a system that combines two computational processes, each operating on information of different nature: preferences and constraints. This approach enables us to construct recommended items from simpler components, thereby introducing a structured framework with relationships and order among sub-items. Furthermore, the secondary recommendation module allows us to dynamically adjust the recommendations to align with the user's preferences or requirements.
The manner in which our system incorporates and processes information is particularly well-suited for tackling complex problems such as nutritional recommendation. However, with appropriate modifications, it can be adapted to similar situations where simple items, user preferences, and domain experts define the constraints and preferences that need to be fulfilled.