Menu generation method and device and storage medium

Abstract

The embodiment of the invention provides a menu generation method and device and a storage medium, and belongs to the technical field of data processing. The method comprises the steps of obtaining a first menu, and performing quality evaluation on the first menu according to a preset verification rule to obtain a first evaluation result; wherein the first menu is an initialized menu generated based on a preset dish matching rule or an updated initialized menu; dishes in the first menu are converted to obtain a second menu, and whether a second evaluation result of the second menu is superior to the first evaluation result or not is judged; wherein the second evaluation result is obtained by performing quality evaluation on the second menu according to a preset verification rule; and if the second evaluation result is superior to the first evaluation result, updating the first menu based on the second menu. According to the method and the device, dishes can be matched more diverse.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a menu generation method, apparatus and storage medium. Background Technology

[0002] In the catering industry, traditional menu generation mainly relies on handwritten paper menus, which is time-consuming and labor-intensive. With the development of computer technology, menus no longer need to be handwritten but can be generated using various menu design software. Users can enter the desired dish information into the menu design software and quickly generate a menu using the rich design materials provided by the software, simplifying the menu production process.

[0003] Even when using menu design software, users still need to consider factors such as the rationality and diversity of dish pairings when selecting dishes. Manually pairing dishes makes it difficult to guarantee a reasonable combination of items on the menu. Summary of the Invention

[0004] This application provides a menu generation method, apparatus, and storage medium, which can solve the technical problem that "manual dish pairing makes it difficult to guarantee a reasonable combination of dishes on the menu." The technical solution provided by this application is as follows:

[0005] In a first aspect, embodiments of this application provide a menu generation method, including:

[0006] Obtain the first menu and evaluate its quality according to preset verification rules to obtain a first evaluation result; wherein, the first menu is an initial menu generated based on preset side dish rules or an updated initial menu;

[0007] The dishes in the first menu are changed to obtain a second menu, and it is determined whether the second evaluation result of the second menu is better than the first evaluation result; wherein, the second evaluation result is obtained by evaluating the quality of the second menu according to the preset verification rules;

[0008] If the second evaluation result is better than the first evaluation result, then the first menu is updated based on the second menu.

[0009] Secondly, embodiments of this application provide a menu generation apparatus, comprising:

[0010] The quality evaluation module is used to obtain a first menu and evaluate the quality of the first menu according to preset verification rules to obtain a first evaluation result; wherein, the first menu is an initial menu generated based on preset side dish rules or an updated initial menu;

[0011] The menu transformation module is used to transform the dishes in the first menu to obtain the second menu;

[0012] The aforementioned quality evaluation module is also used to determine whether the second evaluation result of the second menu is better than the first evaluation result; wherein, the second evaluation result is obtained by performing a quality evaluation on the second menu according to the preset verification rules;

[0013] The menu update module is used to update the first menu based on the second menu if the second evaluation result is better than the first evaluation result.

[0014] Thirdly, embodiments of this application provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the method described in the first aspect.

[0015] In the various embodiments of this application, generating an initial menu through preset dish pairing rules avoids manual dish pairing, simplifies the menu generation process, and improves menu generation efficiency. Furthermore, evaluating the menu quality based on preset verification rules, and continuously changing and optimizing the menu according to the evaluation results, can improve menu quality and make dish pairings more reasonable and diverse.

[0016] Furthermore, by pre-setting dish pairing rules to specify the categories and quantities of dishes, the composition structure of a menu can be determined. Then, based on the preset dish pairing rules, corresponding dishes can be randomly selected from a preset dish library to generate an initial menu. Subsequent calculations can then update the menu based on this random initial menu, ensuring that the final menu is also randomized. This allows for greater diversity in dish combinations.

[0017] In the process of retrieving the second menu, pre-set local search rules can be used to determine how the first menu is transformed. This narrows the search scope, reduces blind searches, and improves search efficiency as the search attempts to find a better menu. Furthermore, filtering the searched candidate menus allows for the rapid identification of superior options, thus improving overall menu quality.

[0018] During the menu update process, the first menu can be updated with a certain probability based on the second menu, which has a lower quality. This allows for the search for better menus based on the lower-quality ones, helping to improve the quality of the first menu until the best-quality menu is found globally. Furthermore, by introducing randomness through random numbers and determinism through probability calculation, this combination of randomness and determinism ensures that the menu update process maintains a degree of flexibility while gradually approaching the optimal solution.

[0019] Furthermore, the probability of a second menu item being accepted gradually decreases as the menu update time or frequency increases. Thus, in early menu updates, a lower-quality second menu item has a higher probability of being accepted, making it more likely to accept the poor solution for a broader search, avoiding local optima and obtaining a globally optimal menu. In later menu updates, the probability of a lower-quality second menu item being accepted is lower, allowing for more fine-tuning and optimization of already good menu solutions, thereby improving menu quality while reducing computational load.

[0020] In addition, menus can be planned in advance on a cyclical basis. By pre-setting multiple sub-rules for side dishes, multiple sub-menus can be generated. Thus, a menu composed of multiple sub-menus can provide more food choices to meet the needs of menu diversification. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 A flowchart illustrating a menu generation method provided in an embodiment of this application;

[0023] Figure 2A A schematic diagram of the menu matching rules setting interface of a client device provided in an embodiment of this application;

[0024] Figure 2B A schematic diagram of the menu verification rule setting interface of a client device provided in an embodiment of this application;

[0025] Figure 2C A schematic diagram of the menu plan settings interface of a client device provided in an embodiment of this application;

[0026] Figure 3A A schematic diagram of a menu structure provided for an embodiment of this application;

[0027] Figure 3B A schematic diagram of a menu item structure provided in an embodiment of this application;

[0028] Figure 3C This is a schematic diagram of a dish attribute information structure provided in an embodiment of this application;

[0029] Figure 4 A schematic diagram of a menu structure provided for an embodiment of this application;

[0030] Figure 5A flowchart illustrating another menu generation method provided in this application embodiment;

[0031] Figure 6 A surface plot of the evaluation result of a global menu provided in an embodiment of this application;

[0032] Figure 7 A surface plot of the evaluation results for another global menu provided in an embodiment of this application;

[0033] Figure 8 A flowchart illustrating another menu generation method provided in this application embodiment;

[0034] Figure 9 A schematic diagram of a natural exponential function provided in this application embodiment;

[0035] Figure 10 This is a schematic diagram of a menu generation device provided in an embodiment of this application. Detailed Implementation

[0036] In the catering industry, menus are not only a reference for customers ordering food, but also an important tool for restaurants to showcase the characteristics of their dishes. Traditional menu creation often relies on chefs or restaurant managers manually writing down each dish. This then involves a series of tedious steps such as printing and binding to produce the final paper menu. When a new dish is introduced or removed from the menu, the above steps must be repeated to generate a new menu. Clearly, this method of menu creation is inefficient and time-consuming.

[0037] With the development of computer technology, menus no longer rely on handwriting but can be generated using various menu design software. Users of menu design software can quickly generate a menu by entering the desired menu information and utilizing the rich design resources provided by the software. This simplifies the menu creation process and improves efficiency. Furthermore, when menu items need to be updated, users only need to make corresponding modifications in the menu design software to quickly generate a new menu version. This allows for easy menu updates, keeping the menu fresh and attractive.

[0038] However, even when using menu design software to create menus, users still need to manually consider various factors such as the rationality and diversity of dish pairings when selecting dishes. Manually pairing dishes makes it difficult to guarantee a reasonable combination of items on the menu.

[0039] Based on this, this application proposes a menu generation method. This method generates an initial menu by pre-setting dish pairing rules, which avoids manual dish pairing, simplifies the menu generation process, and improves menu generation efficiency. Furthermore, by evaluating the quality of the menu based on pre-set verification rules and continuously optimizing the menu based on the evaluation results, the quality of the menu can be improved, making the dish pairings more reasonable and diverse.

[0040] It is worth mentioning that the menu generation methods provided in the various embodiments of this application can be applied to a server. Users can send a menu generation request to an online system deployed on the server via a client device. The online system then executes the menu generation method and returns the final menu to the client device. Alternatively, the menu generation methods provided in the various embodiments of this application can also be applied to the user's client device, where the client device generates and outputs the menu locally. This application does not limit the device on which the menu generation method is executed.

[0041] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0042] It should be understood that the described embodiments are merely some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0043] In the description of this application, it should be understood that the terms "first," "second," "third," etc., are used only to distinguish similar objects and are not necessarily used to describe a specific order or sequence, nor should they be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0044] Figure 1 This is a flowchart illustrating a menu generation method provided in an embodiment of this application. The following will, in conjunction with a specific implementation, take an example where a user sends a menu generation request to an online system deployed on a server via a client device, and the online system then generates and updates the menu. Figure 1 The processing flow shown is explained in detail below:

[0045] S102, obtain the first menu, and evaluate the quality of the first menu according to the preset verification rules to obtain the first evaluation result.

[0046] In implementation, for ease of description, the menu currently awaiting update can be referred to as the first menu. The first menu can be an initial menu generated based on preset ingredient rules, or it can be an updated initial menu that needs to be updated again. The menu's quality is evaluated according to preset verification rules, for example, through a penalty point mechanism. This allows for an objective measurement of menu quality based on preset verification rules, which helps in determining whether to update the menu subsequently.

[0047] In one embodiment, the processing prior to step S102 may further include: receiving a menu generation request input by the user on the menu settings interface, and determining the preset side dish rules and preset verification rules corresponding to the menu generation request.

[0048] Specifically, the client device displays a menu settings interface on its screen. Users can input a menu generation request on this interface, causing the client device to send the request to the server. The menu generation request can include basic menu information entered by the user in the menu settings interface. This basic information identifies each menu item to distinguish it from others, and may include one or more pieces of information such as the applicable item name, applicable restaurant name, and dining type. For example, see... Figure 2C Users can enter menu generation requests on the menu plan settings interface, including: entering basic menu information and creating a menu plan, so that the client device can send the corresponding menu generation request to the online system deployed on the server.

[0049] Next, the server can receive menu generation requests sent by client devices, which are entered by users on the menu settings interface, and determine the preset ingredient matching rules and preset validation rules corresponding to the received menu generation request. The server stores a mapping relationship between basic menu information and preset ingredient matching and validation rules. Based on the basic menu information carried in the menu generation request, the server can look up the corresponding preset ingredient matching and validation rules in these mapping relationships. Then, the server can generate and update the initial menu for each user according to the corresponding preset ingredient matching and validation rules, and send the final menu back to each user's client device.

[0050] In one embodiment, the user can also pre-enter menu ingredient rules and menu validation rules on the client device's menu settings interface. The client device then stores the preset ingredient rules locally or uploads them to the server. For example, see... Figure 2A and Figure 2B Users can pre-enter menu ingredient rules in the menu ingredient rule settings interface and pre-enter menu validation rules in the menu validation rule settings interface.

[0051] In one embodiment, the preset verification rules may include any one or more rules such as "each meal must have 2 spicy dishes", "the names of dishes within the specified daily dish category must not be repeated", and "the main meat dishes must not be repeated weekly".

[0052] In this embodiment, the OptaPlanner planning engine can be used to evaluate the quality of each menu item. Before using the OptaPlanner engine to evaluate the menu quality, a series of OptaPlanner key elements need to be defined to construct a menu planning model for generating the menu. The preset validation rules can be represented by constraints in the OptaPlanner engine, and these constraints can be expressed in a streaming manner using the Stream API. Specifically, the defineConstraints() method provided by the OptaPlanner engine can be used to call various APIs provided by the ConstraintFactory parameter to define constraints corresponding to the preset validation rules. Then, by applying penalties to the menu based on these constraints, the evaluation result of the menu can be obtained. A score of 0 can be used as the starting score for the menu; if the menu violates the constraints, points are deducted. Finally, the evaluation result of the menu will be a negative score.

[0053] It is worth mentioning that, in addition to using the Stream API to express constraints in a streaming manner, constraints can also be expressed using the Drools rule language, and so on. This application does not restrict the way constraints are expressed.

[0054] In addition, the key elements that need to be defined may include the Problem Fact Collection Property, the Planning Entity, the Planning Variable, and the Planning Solution.

[0055] The problem fact set comprises multiple problem facts. During the OptaPlanner solution process, there exists a pre-defined, fixed dataset of business entities, which can be called the problem fact set, and the business entities within it can be called problem facts. Problem facts are read-only and will not be modified during the solution process.

[0056] Planning entities are objects in a solution that need to be optimized or adjusted, while planning variables are attributes of planning entities that can be adjusted.

[0057] The solution, as a global representation of the planning problem, can be the starting point and the end point of the optimization process. It includes all planning entities, problem facts, and the current state of planning variables, and represents a possible solution to the planning problem.

[0058] See also Figures 3A-3C In the menu planning model, the set of problem facts can be the set of optional dishes (which can be denoted as a List). <restdish>The problem entity can be a menu item (referred to as a RestDish), and the planning variable can be the selected dish from that menu item. The solution can be a complete menu, including a list of menu items (referred to as a List). <menuitem>The menuitemlist consists of individual menu items, each requiring a specific dish to be selected. Through local search, an initial menu can be created and updated progressively, resulting in a menu of increasingly higher quality.

[0059] It's worth noting that the attribute information of each dish can be pre-recorded in the menu library, allowing for the selection of a set of available dishes from the library based on these attributes. Dish attribute information can include any one or more of the following: category (e.g., categorized by ingredient or by dish), dish name, whether it contains offal, whether it contains processed ingredients, whether it contains marinated ingredients, cooking method, color, flavor, star rating, etc.

[0060] In one embodiment, to facilitate restaurant staff in accurately determining the ingredients required for the menu, the ingredient information for each dish can be recorded in a menu library. Correspondingly, the menu generation method may further include: recording the ingredient information for each dish in a preset menu library; obtaining the ingredient information for each dish included in the first menu; and calculating the ingredient information required for the first menu.

[0061] In implementation, ingredient information includes the types and quantities of raw materials. For example, the types and quantities of main ingredients and auxiliary ingredients. Then, based on the ingredient information of each dish in the first menu and the restaurant's expected serving size for each dish, the required ingredient information for the first menu can be calculated. Furthermore, once the final menu is generated, restaurant staff can easily purchase ingredients as needed, avoiding over-preparation and facilitating cost control.

[0062] In one embodiment, the first menu includes daily menus for the seven days of the week, and each daily menu further includes meal menus for three meals a day. Taking the preset verification rule of "two spicy dishes per meal" as an example, the quality evaluation of the first menu may include the following evaluation steps:

[0063] 1. Iterate through all menu items in the first menu.

[0064] 2. Filter the menu items according to meal time (which can be denoted as Meal Time) to obtain the menu items corresponding to each meal. For example, obtain the menu items corresponding to lunch.

[0065] 3. Group the selected dishes in each menu item according to the week (can be denoted as Week) and meal time, and obtain the corresponding flavor set for each meal time of each week based on taste (can be denoted as Dish Taste). For example, the group for Monday lunch includes "spicy" flavor set, "sweet" flavor set, "salty" flavor set, etc.

[0066] It is worth mentioning that a dish may have multiple flavors at the same time, and then the dish can be classified into multiple flavor sets.

[0067] 4. Iterate through each group obtained in step 3, count the number of dishes in the "spicy" flavor set, and if the number of spicy dishes is not equal to 2, then determine that the current group violates the constraint of "2 spicy dishes per meal".

[0068] 5. Penalties will be imposed on the first menu item. For example, 2 points will be deducted for violating the rule of "2 spicy dishes per meal".

[0069] In practice, the preset validation rules can be converted into constraints in the OptaPlanner planning engine. The constraints corresponding to the above steps can be expressed in the way supported by the OptaPlanner planning engine, which will not be elaborated in this application.

[0070] In one embodiment, the first menu includes daily menus for seven days of the week, and each daily menu further includes meal menus for three meals a day. Specifically, Monday lunch has three spicy dishes, Wednesday dinner has one spicy dish, Thursday breakfast has zero spicy dishes, and all other meals have two spicy dishes. Therefore, the first menu violates the constraint of "two spicy dishes per meal" three times. Based on the evaluation steps included in the above constraints, the evaluation result for the first menu can be calculated as -6 points.

[0071] In one embodiment, the preset validation rules may include mandatory rules and rules that should be satisfied as much as possible but are not mandatory. The OptaPlanner planning engine can represent the mandatory and non-mandatory preset validation rules through hard constraints and soft constraints, respectively. Accordingly, the final score of the menu may include two parts: HardScore + SoftScore. HardScore represents the final score for violating hard constraints, and SoftScore represents the final score for violating soft constraints.

[0072] It's worth noting that constraints can be divided into hard constraints and soft constraints. Hard constraints specify whether a solution is feasible, corresponding to pre-defined validation rules that must be met. Violating hard constraints results in an infeasible solution. Soft constraints define the quality of a solution, corresponding to pre-defined validation rules that should be met as much as possible, but are not mandatory. The fewer times soft constraints are violated, the higher the quality of the resulting solution.

[0073] In one embodiment, a menu may include multiple dish categories, and each category may include multiple dishes. Correspondingly, preset dish pairing rules may include multiple specified dish categories and a specified quantity corresponding to each specified dish category. In this case, the menu generation method may further include: filtering from a preset dish library to select a set of optional dishes corresponding to each specified dish category; randomly selecting a specified quantity of dishes from each set of optional dishes; and summarizing all dishes selected from multiple sets of optional dishes to obtain an initial menu.

[0074] In implementation, the preset menu library contains a large number of dishes. To generate an initial menu, pre-set dish pairing rules can be used to specify the categories and quantities of dishes; these preset rules determine the structure of a menu. Then, based on these rules, corresponding dishes can be randomly selected from the preset menu library to generate the initial menu. Subsequent calculations can then update the menu based on this randomized initial menu, ensuring that the final menu is also randomized. This allows for greater diversity in dish combinations.

[0075] For example, the preset menu rules are: 10 vegetarian dishes, 20 meat dishes, 5 cold dishes, 8 soups, and 10 beverages. That is, the specified dish categories in this preset menu rule include: vegetarian dishes, meat dishes, cold dishes, soups, and beverages, with the corresponding quantities for each category being 10, 20, 5, 8, and 10, respectively. Correspondingly, sets of vegetarian dishes, meat dishes, cold dishes, soups, and beverages can be selected from the preset menu library. Then, 10 dishes are randomly selected from the vegetarian set; 20 dishes are randomly selected from the meat set; 5 dishes are randomly selected from the cold dish set; 8 soups are randomly selected from the soup set; and 10 beverages are randomly selected from the beverage set. Finally, all dishes selected from the multiple optional menu sets are aggregated to obtain an initial menu containing 10 vegetarian dishes, 20 meat dishes, 5 cold dishes, 8 soups, and 10 beverages.

[0076] In one embodiment, the preset side dish rules may include multiple side dish sub-rules. Correspondingly, the menu generation method may also include: generating multiple initial sub-menus according to the multiple side dish sub-rules; and summing up the multiple initial sub-menus to obtain an initial menu.

[0077] In practice, for group meal scenarios such as company cafeterias and school canteens, menus often have a cyclical nature, requiring the use of multi-level menus. In other words, a menu can consist of multiple sub-menus, with different sub-menus corresponding to different time periods within a cycle. Accordingly, before generating the initial menu, the menu generation cycle can be considered, and multiple side dish sub-rules can be pre-set. Subsequently, multiple sub-menus are generated based on the preset side dish sub-rules, and the collection of these sub-menus constitutes a complete menu.

[0078] For example, seven pre-set sub-rules for side dishes can be used on a daily or weekly basis, and then seven different sub-menus can be generated based on these rules. The restaurant can then use these seven sub-menus sequentially from Monday to Sunday. Alternatively, fifteen pre-set sub-rules for side dishes can be used on a two-day or monthly basis, generating fifteen different sub-menus. This allows the restaurant to change its sub-menus every two days within a month.

[0079] For example, three sub-rules for side dishes can be preset for the restaurant on a per-meal basis and a per-day cycle, thereby generating three different sub-menus. In this way, breakfast, lunch, and dinner can use these three sub-menus in sequence.

[0080] For example, using meal sessions as the unit, with days as the first cycle and weeks as the second cycle, three sub-rules for different meal sessions can be generated for the restaurant. These can then be further divided into seven sub-rules for different weeks, resulting in 3 x 7 = 21 different sub-menus. In other words, breakfast, lunch, and dinner from Monday to Sunday can sequentially use these 21 sub-menus. (See also...) Figure 4 The initial menu generated based on multiple side dish sub-rules is the weekly menu. A complete weekly menu consists of 7 daily menus, and each daily menu consists of 3 meal menus.

[0081] In this way, by planning the menu in advance on a cyclical basis and pre-setting multiple sub-rules for side dishes, multiple sub-menus can be generated. Thus, a menu composed of multiple sub-menus can offer a wider selection of dishes to meet diverse menu needs.

[0082] It is worth mentioning that the number of side dish sub-rules can also be determined based on the actual number of meals provided by the restaurant, thereby determining the number of sub-menus generated; this application does not impose any restrictions on this. For example, if the restaurant does not provide breakfast, two side dish sub-rules can be preset for lunch and dinner; if the restaurant adds afternoon tea, four side dish sub-rules can be preset for breakfast, lunch, afternoon tea, and dinner.

[0083] It should be noted that for situations requiring periodic menu generation, users only need to pre-set the ingredient selection rules and validation rules once to generate new menus for each period. Furthermore, the menu's structure can be adjusted by simply modifying the ingredient selection and validation rules, significantly improving menu generation efficiency.

[0084] In one embodiment, different food pairing rules and verification rules can be pre-set for different restaurants. Then, when the menu generation device executes these pre-set food pairing rules and verification rules, it can generate different menus for different restaurants. Correspondingly, the menu generation method may further include: establishing a mapping relationship between a first menu and a target restaurant, and setting corresponding pre-set food pairing rules and verification rules for the target restaurant.

[0085] In implementation, different project entities (such as businesses, schools, hospitals, etc.) require different menus for their restaurants. Furthermore, each project entity may own one or more restaurants. In these cases, it's necessary to generate different menus for different restaurants belonging to different project entities simultaneously. To generate different menus for different restaurants, menus can be linked to restaurants or simultaneously linked to both projects and restaurants, establishing a mapping relationship between menus and restaurants. Different preset dish pairing rules and preset validation rules can then be set for different restaurants. This facilitates the subsequent expansion of the menu generation service's scope, supporting the simultaneous provision of menu generation services to multiple restaurants. In other words, different menus can be generated for different restaurants, better matching their positioning and image, and highlighting the unique characteristics of their dishes.

[0086] In one embodiment, the restaurant may further include different food lines (e.g., different food stalls), and different food lines may require different menus. Therefore, the preset dish preparation rules and preset validation rules set for the target restaurant can be refined to rules specific to each food line.

[0087] In one embodiment, some restaurants may also consider the characteristics of the dining group and control the nutritional content and portion size of the dishes. In this case, dish pairing rules related to the dining type can be pre-set to generate a corresponding initial menu, and verification rules related to the dining type can be pre-set to evaluate the quality of the corresponding menu.

[0088] For example, if the meal type is a patient meal, a light diet can be provided. In this case, the preset dish preparation rules can include: generating 5 light-flavored dishes for lunch, and the preset verification rules can include: no more than 10 light-flavored dishes per day, and at least 1 porridge dish per meal.

[0089] For example, if the meal type is children's meals, small portions of nutritious dishes can be provided. In this case, the preset side dish rules can include: generating 3 small bowl dishes per meal, and the preset validation rules can include: each meal includes a boiled egg.

[0090] For example, if the meal type is a maternal meal, it can provide fresh dishes with comprehensive nutrition. In this case, the preset meal rules can include: lunch includes 2 kinds of fresh fruit and no less than 3 kinds of meat and vegetables. The preset verification rules can include: 5 kinds of high-calcium dishes every day.

[0091] By considering dining types during the initial menu generation and update processes, the needs of different dining groups can be met, thereby increasing the applicability and diversity of the menu.

[0092] S104, change the dishes in the first menu to obtain the second menu, and determine whether the second evaluation result of the second menu is better than the first evaluation result.

[0093] In practice, the second evaluation result can be obtained by evaluating the quality of the second menu according to preset verification rules. For the specific processing of evaluating the quality of the second menu, please refer to step S102, which details the specific method for evaluating the quality of the first menu according to preset verification rules; this application will not elaborate further here.

[0094] In one embodiment, see Figure 5 The second menu is obtained by changing the dishes in the first menu. This can be understood as finding a second menu that is somewhat similar to the first menu through a local search. Accordingly, step S104 may specifically include the following processing:

[0095] S1041, according to the preset local search rules, the dishes in the first menu are transformed to obtain multiple candidate menus.

[0096] In implementation, a neighborhood search can be performed on the first menu, that is, to obtain menus similar to the first menu, and then identify the higher-quality menus from among them. Specifically, one or more rules can be pre-set for the first menu to determine how it can be transformed. For ease of description, these rules can be called local search rules. Then, the first menu can be transformed according to the methods specified by the pre-set local search rules to obtain multiple possible menus, and these possible menus can be used as candidate menus. In other words, one can move around the first menu within the area defined by the pre-set local search rules, and each move will obtain a new menu as a candidate menu.

[0097] The preset local search rules can include swapping dishes between two meals or replacing dishes in a specific meal. These rules can be determined and adjusted according to the actual application scenario and business needs, and this application does not impose any restrictions on them.

[0098] S1042, perform quality evaluation on multiple candidate menus according to preset verification rules, and determine the candidate menu with the best evaluation result as the second menu.

[0099] In implementation, multiple potential candidate menus can be found through local search. To determine the quality of these candidate menus, each candidate menu can be evaluated according to preset verification rules. Then, the best-performing candidate menu can be selected as the second menu. Subsequent updates to the first menu will be based on the second menu.

[0100] In this way, by pre-setting local search rules to determine the transformation method of the first menu, the search scope can be narrowed during the process of trying to find a better menu, reducing the randomness of the search and improving search efficiency. Furthermore, filtering the searched candidate menus can quickly find better menus and improve menu quality.

[0101] For example, see Figure 6 Point A represents the first menu. When step S1041 is executed on the first menu, it's equivalent to moving from point A to the candidate points adjacent to A; the menus corresponding to these candidate points are the candidate menus. When step S1042 is executed on the first menu, it's equivalent to determining the highest point, point B, from all points adjacent to A. At this point, the quality of the second menu corresponding to point B is higher than the quality of the first menu corresponding to point A. It can be understood that if point A is the highest point, then all candidate points obtained by moving from point A will be lower than point A. In other words, if the first menu's initial evaluation result is higher than the scores of all candidate menus, then the quality of the second menu corresponding to point B is lower than the quality of the first menu corresponding to point A.

[0102] In the above embodiments, the menu quality evaluation strategy is as follows: when a menu violates a preset verification rule, points are deducted. The higher the score, the better the evaluation result of the menu, i.e., the higher the quality. Of course, in other embodiments, the menu quality evaluation strategy can also be: when a menu violates a preset verification rule, points are added. Correspondingly, the lower the score, the better the evaluation result of the menu.

[0103] S106, If the second evaluation result is better than the first evaluation result, then the first menu is updated based on the second menu.

[0104] In implementation, generating an initial menu through preset ingredient pairing rules avoids manual ingredient pairing and simplifies the menu generation process. Subsequently, the menu is evaluated for quality based on preset validation rules, and the first menu is updated based on a higher-quality second menu, thus improving the overall quality of the menu and making the dish combinations more reasonable and diverse.

[0105] In one embodiment, the quality of the first menu can be gradually improved by repeatedly updating the first menu through steps S104 and S106 until the first menu reaches the condition for stopping updates.

[0106] The stop-update condition can be a preset time period, such as stopping updates and outputting the first menu if the time spent generating and updating the first menu reaches the preset time. Another stop-update condition is that the menu quality no longer improves; for example, stopping updates and outputting the first menu if the second evaluation result is worse than the first evaluation result. Of course, multiple stop-update conditions can be set simultaneously according to the actual application scenario. Updates will stop and the first menu will be output when any one or more of these conditions are met.

[0107] In practice, after the server stops updating the menu, it can send the final output first menu to the corresponding client device, so that the user can view the generated menu on their client device.

[0108] In one embodiment, see Figure 7 Point A is a local optimum, and point C is a global optimum. This means that the quality of the first menu corresponding to point A has reached a local optimum, and a higher quality menu cannot be obtained through simple transformations, thus making it impossible to obtain the globally highest quality menu corresponding to point C. To avoid getting trapped in local optima, the menu generation method can further include: if the second evaluation result is worse than the first evaluation result, calculating the acceptance probability of the second menu; generating a random number and determining whether the acceptance probability is greater than the random number; if the acceptance probability is greater than the random number, updating the first menu based on the second menu.

[0109] For example, see Figure 8 Menu generation methods may include:

[0110] S202, obtain the first menu, and evaluate the quality of the first menu according to the preset verification rules to obtain the first evaluation result.

[0111] In practice, the specific processing of step S202 can be found in step S102, and will not be repeated here.

[0112] S204, change the dishes in the first menu to obtain the second menu.

[0113] S206, evaluate the second menu according to the preset verification rules and obtain the second evaluation result.

[0114] S208, determine whether the second evaluation result of the second menu is better than the first evaluation result.

[0115] In implementation, the specific processing of steps S206 and S208 can be found in step S104, and will not be repeated here. If the second evaluation result is better than the first evaluation result, it means that the quality of the second menu is higher than that of the first menu, and step S210 can be executed. If the second evaluation result is not better than the first evaluation result, it means that the quality of the second menu is the same as that of the first menu, or the quality of the second menu is lower than that of the first menu, and step S212 can be executed.

[0116] S210, update the first menu based on the second menu.

[0117] In practice, the specific processing of step S210 can be found in step S106, and will not be repeated here.

[0118] S212, calculate the probability of the second menu item being accepted.

[0119] S214, determine whether the probability of being accepted is greater than a random number.

[0120] In implementation, if the acceptance probability is greater than a random number, it means that the lower-quality second menu can be accepted, and step S210 is executed to update the first menu based on the second menu. If the acceptance probability is not greater than the random number, it means that the lower-quality second menu cannot be accepted, and the first menu remains unchanged, and step S216 is executed.

[0121] S216, output the first menu.

[0122] In implementation, if a quality evaluation is performed on all possible menus globally according to preset verification rules, a visual surface plot can be used to represent the transformation relationship and evaluation results of each menu for ease of understanding. The corresponding surface plot may contain one or more peaks. For cases where the surface plot contains multiple peaks, please refer to [the relevant documentation / reference]. Figure 7 If a lower peak (i.e., a local optimum) is calculated, in order to progressively calculate higher peaks, or even the highest peak (i.e., the global optimum), a lower-quality solution can be accepted with a certain probability. Specifically, the probability of accepting a lower-quality second menu item can be calculated using a certain method, and this probability can be compared with a random number to determine whether to accept the second menu item. By accepting a point lower than point A, a move towards point C can be made with a certain probability. For example, in the OptaPlanner planning engine, simulated annealing can be used to calculate the probability of accepting the second menu item.

[0123] In this way, updating the first menu based on the second menu (which has a lower quality) with a certain probability allows for the continued search for higher-quality menus, helping to improve the quality of the first menu until the best-quality menu in the world is found. Furthermore, by introducing randomness through random numbers and determinism through probability calculation, the combination of randomness and determinism ensures that the menu update process maintains a certain degree of flexibility while gradually approaching the optimal solution.

[0124] In one embodiment, the formula for calculating the probability of the second menu item being accepted can be:

[0125] P(accept)=exp((newScore-currentScore) / temperature)

[0126] Where P(accept) is the probability of being accepted; exp is the natural exponential function; newScore is the second evaluation result; currentScore is the first evaluation result; temperature is the temperature parameter, which decreases as the number of menu updates increases, and the temperature parameter is a non-negative number.

[0127] In implementation, the acceptance probability (or move selection probability) determines the likelihood of updating the first menu based on the second menu in step S104. See also Figure 9 It's understandable that when the quality of the second menu item is better than the quality of the first menu item, `newScore - currentScore > 0`, then `P(accept) ≥ 1`. In this case, the better-quality second menu item is always accepted. When the quality of the second menu item is worse than the quality of the first menu item, `newScore - currentScore < 0`, then `P(accept) < 1`. In this case, the worse-quality second menu item may or may not be accepted. Therefore, we can determine whether to accept the worse-quality second menu item by judging whether `P(accept)` reaches a specified probability value. For example, the specified probability value can be a random number `r` randomly generated in the interval [0,1). By judging whether the probability of acceptance is greater than this random number, we can determine whether to accept the worse-quality second menu item. If `P(accept) > r`, then the second menu item is accepted, and the first menu item is updated based on the second menu item; otherwise, the current first menu item is kept unchanged.

[0128] In one embodiment, the temperature can be calculated using the following formula:

[0129] temperature=initialTemperature*(1-iteration / maxIterations)

[0130] Where temperature represents the current temperature, initialTemperature represents the initial temperature, iteration represents the current iteration number, and maxIterations represents the maximum iteration number.

[0131] In implementation, the initial temperature and the maximum number of iterations can be set using the default configuration in the OptaPlanner planning engine, or they can be determined and adjusted according to the actual application scenario and business needs. This application does not impose any restrictions on this.

[0132] To obtain the globally optimal menu and reduce computational cost, a temperature parameter can be introduced into the formula for calculating the acceptance probability, and the value of the temperature parameter gradually decreases as the menu is updated. That is, in early menu updates, the probability of accepting a lower-quality second menu item is higher, making it more likely to accept the poorer solution for a broader search, avoiding getting trapped in local optima and obtaining the globally optimal menu. In later menu updates, the probability of accepting a lower-quality second menu item is lower, allowing for more fine-tuning and optimization of already better menu solutions, thus improving menu quality while reducing computational cost.

[0133] It should be noted that, due to space limitations, this application specification does not exhaustively list all possible implementation methods. Those skilled in the art should be able to conceive after reading this application specification that, as long as the technical features do not contradict each other, any combination of technical features can constitute an optional implementation method.

[0134] Based on the same technical concept, embodiments of this application also provide a menu generation device. See also Figure 10 The menu generation device may include:

[0135] The instruction receiving module is used to receive the menu generation request entered by the user on the menu settings interface, and determine the preset side dish rules and preset verification rules corresponding to the menu generation request.

[0136] The quality evaluation module is used to obtain the first menu and evaluate its quality according to preset verification rules to obtain the first evaluation result; wherein, the first menu is an initial menu generated based on preset side dish rules or an updated initial menu;

[0137] The menu transformation module is used to transform the dishes in the first menu to obtain the second menu;

[0138] The aforementioned quality evaluation module is also used to determine whether the second evaluation result of the second menu is better than the first evaluation result; wherein, the second evaluation result is obtained by performing a quality evaluation on the second menu according to preset verification rules;

[0139] The menu update module is used to update the first menu based on the second menu if the second evaluation result is better than the first evaluation result.

[0140] The menu output module is used to output the first menu if the first menu reaches the stop updating condition.

[0141] In one embodiment, the preset dish-matching rules include multiple specified dish categories and a specified quantity corresponding to each specified dish category. The menu generation device may further include an initial menu generation module, used for:

[0142] Select a set of optional dishes corresponding to each specified dish category from the preset dish library;

[0143] Randomly select a specified number of dishes from each set of available dishes;

[0144] The initial menu is generated by summing all the dishes selected from multiple sets of optional dishes.

[0145] In one embodiment, the menu transformation module is specifically used for:

[0146] According to the preset local search rules, the dishes in the first menu are transformed to obtain multiple candidate menus;

[0147] Based on preset verification rules, multiple candidate menus are evaluated for quality, and the candidate menu with the best evaluation result is selected as the second menu. 。

[0148] In one embodiment, the menu update module is also used for:

[0149] If the second evaluation result is worse than the first evaluation result, then calculate the acceptance probability of the second menu;

[0150] Generate a random number and determine if the probability of acceptance is greater than that of the random number.

[0151] If the probability of acceptance is greater than the random number, then the first menu is updated based on the second menu.

[0152] In one embodiment, the formula for calculating the probability of acceptance is:

[0153] P(accept)=exp((newScore-currentScore) / temperature)

[0154] Where P(accept) is the probability of acceptance; exp is the natural exponential function; newScore is the second evaluation result; currentScore is the first evaluation result; and temperature is the temperature parameter, which decreases as the number of menu updates increases.

[0155] In one embodiment, the preset side dish rules include multiple side dish sub-rules. The menu generation device may further include an initial menu generation module, used for:

[0156] Multiple initialization sub-menus are generated based on multiple side dish rules;

[0157] The initialization menu is obtained by combining multiple initialization submenus.

[0158] In one embodiment, the menu generation apparatus may further include a rule setting module, used for:

[0159] Establish a mapping relationship between the first menu and the target restaurant, and set corresponding preset side dish rules and preset verification rules for the target restaurant.

[0160] In one embodiment, the menu generation device may further include a recipe library module and an ingredient calculation module.

[0161] The recipe database module is used to record the ingredient information for each dish; the ingredient information includes the type and quantity of ingredients.

[0162] The ingredient calculation module is used to obtain the ingredient information of each dish in the first menu and calculate the ingredient information required for the first menu.

[0163] It should be noted that the menu generation device provided in the above embodiments is only illustrated by the division of the above functional modules when executing the menu generation method. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the menu generation device and the menu generation method embodiments provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0164] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This menu-generating software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including storing several instructions to cause an electronic device to execute the methods described in various embodiments or some parts of the embodiments.

[0165] The above description is only a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.< / menuitem> < / restdish>

Claims

1. A menu generation method characterized by, The method comprises: receiving a menu generation request input by a user on a menu setting interface, determining preset dish arrangement rules and preset verification rules corresponding to the menu generation request; obtaining a first menu and performing quality evaluation on the first menu according to the preset verification rules to obtain a first evaluation result; wherein the first menu is an initial menu or an updated initial menu generated based on the preset dish arrangement rules; transforming dishes in the first menu to obtain a second menu and determining whether a second evaluation result of the second menu is better than the first evaluation result; wherein the second evaluation result is obtained by performing quality evaluation on the second menu according to the preset verification rules; if the second evaluation result is better than the first evaluation result, updating the first menu based on the second menu; if the first menu reaches a stop updating condition, outputting the first menu.

2. The method of claim 1, wherein, The preset dish arrangement rules include a plurality of specified dish categories and a specified number corresponding to each specified dish category; the method further comprises: filtering a set of selectable dishes corresponding to each specified dish category from a preset dish library; randomly selecting a specified number of dishes from each set of selectable dishes; summarizing all dishes selected from the plurality of sets of selectable dishes to obtain the initial menu.

3. The method of claim 1, wherein, The transformation of dishes in the first menu to obtain the second menu comprises: transforming dishes in the first menu according to a preset local search rule to obtain a plurality of candidate menus; According to the preset check rule, the plurality of candidate menus are respectively evaluated in quality, and the candidate menu with the best evaluation result is determined as the second menu 。 4. The method of claim 1, wherein, The method further comprises: if the second evaluation result is worse than the first evaluation result, calculating an acceptance probability of the second menu; generating a random number and determining whether the acceptance probability is greater than the random number; if the acceptance probability is greater than the random number, updating the first menu based on the second menu.

5. The method of claim 4, wherein, The calculation formula of the acceptance probability is: P(accept)=exp((newScore-currentScore) / temperature) wherein P(accept) is the acceptance probability; exp is the natural exponential function; newScore is the second evaluation result; currentScore is the first evaluation result; temperature is a temperature parameter that decreases with the increase of the number of menu updates.

6. The method of claim 1, wherein, The preset dish arrangement rules include a plurality of dish arrangement sub-rules; the method further comprises: generating a plurality of initial sub-menus according to the plurality of dish arrangement sub-rules; summarizing the plurality of initial sub-menus to obtain the initial menu.

7. The method of claim 1, wherein, The method further comprises: establishing a mapping relationship between the first menu and a target restaurant, and setting corresponding preset dish arrangement rules and preset verification rules for the target restaurant.

8. The method of claim 2, wherein, The method further comprises: recording the material information corresponding to each dish in the preset dish library; wherein the material information includes the type and amount of raw materials; obtaining the material information of each dish included in the first menu, and calculating the menu material information required by the first menu.

9. A menu generating apparatus characterized by comprising: ​ The instruction receiving module is configured to receive a menu generation request input by a user on a menu setting interface, and determine a preset dish arrangement rule and a preset verification rule corresponding to the menu generation request; The quality evaluation module is configured to obtain a first menu, and perform quality evaluation on the first menu according to the preset verification rule to obtain a first evaluation result; the first menu is an initial menu or an updated initial menu generated based on the preset dish arrangement rule; The menu transformation module is configured to transform dishes in the first menu to obtain a second menu; The quality evaluation module is further configured to determine whether a second evaluation result of the second menu is better than the first evaluation result; the second evaluation result is obtained by performing quality evaluation on the second menu according to the preset verification rule; The menu updating module is configured to update the first menu based on the second menu if the second evaluation result is better than the first evaluation result; The menu output module is configured to output the first menu if the first menu reaches a stop updating condition.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a plurality of instructions, which are suitable for being loaded and executed by the processor to perform the method of any one of claims 1-8.

Images