Drinking water recommendation method and device, electronic equipment and computer program product

Abstract

The invention is suitable for the technical field of drinking water recommendation, and provides a drinking water recommendation method and device, electronic equipment and a computer program product.The method is applied to a water cup and comprises the steps that real-time state data is obtained; wherein the real-time state data comprises water cup state data and user state data; determining drinking water characteristic data according to the water cup state data and the user state data; wherein the water drinking characteristic data is used for representing the current state of the water cup and the current state of a user associated with the water cup; determining a user hydration state corresponding to the drinking water characteristic data by using a preset evaluation model, and determining a user predicted demand quantity according to the drinking water characteristic data; and obtaining a drinking water recommendation result according to the drinking water characteristic data, the user hydration state and the user predicted demand quantity. The accuracy of drinking water recommendation can be improved.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of drinking water recommendation, and particularly relates to a drinking water recommendation method and device, an electronic device, and a computer program product. BACKGROUND

[0002] Hydration status affects body temperature regulation, metabolism, cognitive function, athletic performance, and even mood, so maintaining an appropriate hydration status is crucial for human health. However, due to individual physiological differences, activity levels, environmental conditions, dietary habits, and other factors, the actual drinking water needs of each person to maintain an appropriate hydration status are highly individualized and dynamically changing.

[0003] Currently, drinking water recommendation can be performed in a time-based manner (e.g., setting a fixed time) or a quantity-based manner (e.g., setting a fixed recommended drinking water amount), but such a manner is difficult to adapt to the real needs of users, resulting in poor accuracy of drinking water recommendation. SUMMARY

[0004] The embodiments of the present application provide a drinking water recommendation method, device, electronic device, and computer program product, which can improve the accuracy of drinking water recommendation.

[0005] In a first aspect, the embodiments of the present application provide a drinking water recommendation method,

[0006] Applied to a water cup, comprising:

[0007] Obtaining real-time state data; wherein the real-time state data includes water cup state data and user state data;

[0008] Determining drinking water feature data according to the water cup state data and the user state data; wherein the drinking water feature data is used to represent the current state of the water cup and the user associated with the water cup;

[0009] Determining the user hydration status corresponding to the drinking water feature data using a preset evaluation model, and determining the user predicted demand amount according to the drinking water feature data;

[0010] Obtaining a drinking water recommendation result according to the drinking water feature data, the user hydration status, and the user predicted demand amount.

[0011] In a second aspect, the present application further provides a drinking water recommendation device applied to a water cup, comprising:

[0012] A data acquisition module for acquiring real-time state data; wherein the real-time state data includes water cup state data and user state data;

[0013] a feature generation module configured to determine drinking water feature data according to the water cup state data and the user state data, wherein the drinking water feature data is used to represent a current state of the water cup and a user associated with the water cup;

[0014] a state evaluation module configured to determine a user hydration state corresponding to the drinking water feature data by using a preset evaluation model, and determine a user predicted demand amount according to the drinking water feature data;

[0015] a drinking water recommendation module configured to obtain a drinking water recommendation result according to the drinking water feature data, the user hydration state and the user predicted demand amount.

[0016] In a third aspect, an electronic device is provided, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the steps of the method in the first aspect when executing the computer program.

[0017] In a fourth aspect, a computer readable storage medium is provided, which stores a computer program, and the computer program implements the steps of the method in the first aspect when executed by a processor.

[0018] In a fifth aspect, a computer program product is provided, which, when executed on an electronic device, causes the electronic device to perform the method in the first aspect.

[0019] Compared with the prior art, the embodiments of the present application have the following beneficial effects:

[0020] In the embodiments of the present application, real-time state data is obtained, and drinking water feature data is determined according to water cup state data and user state data included in the real-time state data. Since the drinking water feature data is used to represent a current state of a water cup and a user associated with the water cup, i.e., the drinking water feature data reflects the current state of the water cup and the current state of the user at the same time, the user hydration state corresponding to the drinking water feature data can be more accurately determined by using a preset evaluation model, and the accuracy of determining the user predicted demand amount is also improved. In addition, the drinking water recommendation result is obtained according to the drinking water feature data, the user hydration state and the user predicted demand amount, which means that the drinking water recommendation takes into account the current state of the water cup, the current state of the user, the user hydration state and the user predicted state, i.e., more rich context information is considered in the drinking water recommendation, and therefore the accuracy of the drinking water recommendation can be improved. BRIEF DESCRIPTION OF DRAWINGS

[0021] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description only some of the embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0022] Figure 1 is a flowchart of a drinking water recommendation method provided by an embodiment of the present application;

[0023] Figure 2 is a structural diagram of a drinking water recommendation device provided by an embodiment of the present application;

[0024] Figure 3 is a structural diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0025] In the following description, specific details are set forth in order to provide a thorough understanding of the embodiments of the present application. However, persons skilled in the art will understand that the present application can be practiced without these specific details. In other instances, well-known systems, devices, circuits, and methods have not been described in detail so as not to obscure the description of the present application.

[0026] It should be understood that, when used in the present application and the appended claims, the term "comprising" indicates the presence of the described features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0027] It should also be understood that the term "and / or" as used in the present application and the appended claims means any combination of one or more of the associated listed items and all possible combinations thereof, and includes these combinations.

[0028] As used in the present application and the appended claims, the term "if" can be interpreted as "when" or "upon" or "in response to a determination" or "in response to detecting" depending on the context. Similarly, the phrases "if it is determined" or "if [a described condition or event] is detected" can be interpreted to mean "upon determining" or "in response to determining" or "upon detecting [a described condition or event]" or "in response to detecting [a described condition or event]", depending on the context.

[0029] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0030] With the emergence of various smart devices (such as smart bracelets, smart water bottles, and smart water meters), smart devices can recommend water intake to users through timed or quantitative recommendations to maintain proper hydration. For example, smart devices can determine the recommended water intake based on a small amount of static information (such as age, gender, and weight) entered by the user during initial setup and push it to the user.

[0031] However, the above-mentioned water recommendation methods have the following drawbacks: 1. The recommendation method and basis are too simple: the user's basic static information is the foundational factor and it is difficult to reflect the individual's daily dynamic changes. At the same time, the recommendation goal is often to determine a fixed total daily water intake and then evenly distribute reminders, which is difficult to dynamically adjust according to individual activity scenarios; 2. Lack of utilization of the user's real-time water cup information: since the recommendation reminder may only be triggered based on a preset time interval, it ignores the fact that the user may have just drunk a lot of water, making it difficult to accurately judge the user's drinking intention and state; 3. Insufficient integration of contextual information: the human body's hydration needs are affected by a wide range of factors. Existing recommendation methods only consider the user's basic information or basic activities to make water recommendations, often ignoring many important contextual information (such as the user's real-time activities, physiological state, etc.), which leads to the water recommendation strategy often being out of touch with the user's actual comprehensive state.

[0032] Therefore, the above-mentioned drinking water recommendation methods are difficult to meet the personalized needs of different individuals, resulting in inaccurate drinking water recommendations.

[0033] To improve the accuracy of drinking water recommendations, this application proposes a drinking water recommendation method. In this method, real-time status data, including water cup status data and user status data, is acquired. Based on the water cup status data and the user status data, drinking water feature data representing the current status of the water cup and the user associated with it is determined. A preset evaluation model is used to determine the user's hydration status corresponding to the drinking water feature data. Furthermore, the user's predicted hydration needs are determined based on the drinking water feature data. Finally, a drinking water recommendation result is obtained based on the drinking water feature data, the user's hydration status, and the user's predicted hydration needs.

[0034] In order to illustrate the technical solutions described in the present application, the drinking water recommendation method provided by the embodiments of the present application is described below with reference to the accompanying drawings.

[0035] Figure 1 A flowchart of a drinking water recommendation method provided by an embodiment of the present application is shown, and the method is applied to a water cup, which is described in detail as follows.

[0036] S11, real-time state data is acquired; wherein the real-time state data includes water cup state data and user state data.

[0037] It should be understood that the water cup state data is data reflecting the state of the water cup after the user drinks water using the water cup, including but not limited to: the water cup record of the last N hours of drinking water record (such as drinking water volume, drinking water frequency, etc.), current water temperature, current water volume, water cup activity state (such as long time not used, just used), etc. The user state data is data reflecting the user's activity state and / or physiological state, including but not limited to: user profile data (such as age, weight, gender, set daily drinking water target, health condition label (such as pregnancy, high-intensity exerciser)), user exercise data (such as the number of steps in the past 24 hours, the type of the last exercise, duration, intensity, etc.), user sleep data (such as sleep duration, quality score, etc.), user diet data (such as manually recorded meal type (high salt, high sugar, soup, etc.)), user feeling data (such as actively marked thirst, fatigue state, etc.), user environment data (such as weather, temperature, humidity, etc.), user future activity data (such as calendar recorded meetings, exercise activities, etc.), etc.

[0038] It should also be understood that the water cup or water cup base can be provided with various sensors and transmission devices, including: weight / flow sensor (sensing device for accurately measuring drinking volume), temperature sensor (for estimating water temperature and / or measuring ambient temperature), humidity sensor (for estimating water cup humidity and / or measuring ambient humidity), motion sensor (for sensing base movement, picking up and putting down, etc.), cup body recognition unit, chip unit (such as MCU / SoC), communication unit (such as Wi-Fi), and output interface (such as LED light, speaker, vibration motor), etc. It should be noted that the water cup can be associated with other terminal devices of the user (such as smart phone, smart watch, etc.).

[0039] Specifically, the server can receive data streams from the cup (or the cup base) and associated devices (such as a mobile phone App or an external service API interface (such as a weather service API, a user calendar API)) by using a message queue (such as Kafka), obtain real-time state data, store real-time updated data in a first database, and store non-real-time updated data in a second database. Among them, the real-time updated data includes the cup state data and the user state data with stronger real-time performance (such as user motion data, etc.), and the non-real-time updated data includes the user state data with stronger real-time performance (such as user profile data, etc.). The first database can be a time series database (such as InfluxDB), and the first database can be a relational database (such as PostgreSQL) or a NoSQL database (such as MongoDB).

[0040] It should be noted that, in order to balance the power consumption and real-time performance of different sensors, different data acquisition frequencies can be used for different sensors. For example, for a motion sensor, the corresponding cup state data can be acquired and reported in real time when the cup motion state changes (including position changes, angle changes, etc.); for a weight / flow sensor, the corresponding cup state data can be acquired and reported in real time when the cup water state changes (including weight changes, flow changes, etc.); and for temperature and humidity sensors, the corresponding cup state data can be acquired and reported according to a preset acquisition period (such as every 5-10 minutes). In the embodiments of the present application, by obtaining the real-time state data, more rich user associated data can be obtained.

[0041] S12, determining drinking water feature data according to the cup state data and the user state data; wherein the drinking water feature data is used to represent the current state of the cup and the user associated with the cup.

[0042] Specifically, feature engineering based on the cup state data and the user state data can be performed, that is, the cup state data and the user state data are converted into numerical or categorical features to obtain drinking water feature data.

[0043] For example, the drinking water feature data can include total drinking water volume in the past 1 / 3 / 6 hours, time since last drinking water, current drinking water target completion rate, daily cumulative activity volume, sleep deviation from baseline, environmental temperature and humidity index, whether there is a motion arrangement in the next hour, etc.

[0044] It should be noted that, to improve the accuracy of feature engineering, a data preprocessing process may be included before determining the drinking water feature data based on the aforementioned cup status data and user status data. This data preprocessing process includes at least one of the following: data cleaning, data imputation, and data normalization or standardization. For example, the collected real-time status data can be cleaned (e.g., outlier removal, noise smoothing), then missing data can be imputed (e.g., using interpolation or time-series prediction methods), and finally, data of different dimensions (e.g., drinking water volume, user activity level) can be normalized or standardized to eliminate the impact of dimensional differences on the subsequent evaluation model and improve the accuracy of the evaluation model's predictions.

[0045] In this embodiment of the application, feature engineering can be used to integrate the relationship between the above-mentioned water cup status data and the above-mentioned user status data, so as to obtain multi-dimensional contextual information and more accurately reflect the user's current status.

[0046] S13. Determine the user's hydration status corresponding to the above drinking water characteristic data using a preset evaluation model, and determine the user's predicted demand based on the above drinking water characteristic data.

[0047] Specifically, the aforementioned drinking water characteristic data can be used as input to a preset evaluation model to obtain the user's hydration status. Simultaneously, the user's predicted demand can be determined from the drinking water characteristic data based on a preset prediction mapping relationship. The preset evaluation model can be a gradient boosting tree (e.g., XGBoost) or a neural network model trained on historical state data. The preset prediction mapping relationship can include: a mapping relationship between weather conditions and the user's predicted demand, a mapping relationship between exercise and the user's predicted demand, and a mapping relationship between drinking time and the user's predicted demand, etc. These preset prediction mapping relationships can be set according to actual conditions and are not limited here. Alternatively, a demand prediction model can be trained based on historical state data and historical user demand. This demand prediction model is similar to the preset evaluation model and will not be elaborated further.

[0048] For example, if it is determined from drinking water characteristic data that there will be high-intensity exercise in the next hour, the user's predicted demand can be determined to be 150-250ml based on the mapping relationship between the exercise and the user's predicted demand.

[0049] S14. Based on the above drinking water characteristic data, the above user hydration status, and the above user predicted demand, drinking water recommendation results are obtained.

[0050] The above-mentioned drinking water recommendations may include one or more of the following: timing of drinking water, recommended amount of water, recommended type of liquid or temperature.

[0051] Specifically, based on the aforementioned drinking water characteristic data, the user's hydration status, and the user's predicted demand, as well as preset constraints, it can be determined whether to make a drinking water recommendation. Then, when it is determined to make a drinking water recommendation, the corresponding recommendation result is output using the drinking water recommendation model. It should be understood that the aforementioned drinking water recommendation model can be based on a reinforcement learning model (e.g., a model optimized based on the user's historical status data and health outcome feedback), or a combination of a complex rule system and machine learning (e.g., gradient boosting trees, neural networks).

[0052] For example, the aforementioned preset constraints may include do-not-disturb conditions (such as whether it is at a specific time at night, or whether the water cup is in use).

[0053] In this embodiment, real-time status data is acquired, and drinking characteristic data is determined based on the water cup status data and user status data included in the real-time status data. Since the drinking characteristic data is used to characterize the current status of the water cup and the user associated with the water cup, that is, the drinking characteristic data reflects both the current status of the water cup and the current status of the user, the user's hydration status corresponding to the drinking characteristic data can be determined more accurately using the preset evaluation model, which also improves the accuracy of determining the user's predicted demand. In addition, the drinking recommendation result is obtained based on the drinking characteristic data, the user's hydration status, and the user's predicted demand, which means that the drinking recommendation considers the current status of the water cup, the user's current status, the user's hydration status, and the user's predicted status. That is, richer contextual information is considered in the drinking recommendation, thus improving the accuracy of the drinking recommendation.

[0054] In some embodiments, the user status data includes user activity status data and user physiological status data; determining drinking characteristic data based on the water cup status data and the user status data includes:

[0055] The first feature data is determined based on the above water cup status data and its corresponding quantification rules; wherein, the above first feature data is used to characterize the user's drinking status;

[0056] The second feature data is determined based on the aforementioned user activity status data and its corresponding quantification rules; wherein, the aforementioned second feature data is used to characterize the user activity status;

[0057] The third feature data is determined based on the aforementioned user physiological state data and its corresponding quantification rules; wherein, the aforementioned third feature data is used to characterize the user's physiological state.

[0058] The first characteristic data includes recent water intake and water intake completion rate; the second characteristic data includes current activity level, future activity type, and sleep activity deviation; and the third characteristic data includes environmental comfort index and physiological state index.

[0059] Specifically, for the first feature data mentioned above, the recent water intake corresponding to a specific time in the past (e.g., 1, 3, 6 hours) can be obtained by dividing the time interval according to a preset sliding window and accumulating the data. Then, the water intake completion rate can be obtained by comparing the user's current water intake with the ratio set by the user. For the second feature data mentioned above, the current activity level can be calculated based on the user's height, weight, age, and the basal metabolic rate corresponding to the age. Then, the type of future activity can be determined based on calendar activities (e.g., a meeting or exercise in 1 hour). Finally, the sleep activity deviation can be determined based on the difference between the user's current sleep volume and the preset target sleep volume. For the third feature data mentioned above, the physiological state index can be calculated based on the user's physiological activity data (e.g., heart rate) and a preset physiological activity formula. At the same time, the environmental comfort index can be calculated based on the user's environmental data and a preset environmental comfort formula.

[0060] Optionally, the aforementioned current activity level can be metabolic equivalents (METs) within 1 hour; the aforementioned physiological state index can be the heart rate variability (HRV) within 5 minutes; and the aforementioned environmental comfort index can be one or more of the following: temperature and humidity index (THI), wet-bulb spherical temperature (WBGT), mean radiant temperature (MRT). Of course, other drinking water characteristic data can also be set according to actual conditions, and this is not limited here.

[0061] In this embodiment of the application, by calculating the first feature data, the second feature data and the third feature data mentioned above, the user's drinking water-related data can be characterized more accurately.

[0062] In some embodiments, the aforementioned preset evaluation model includes a hydration state evaluation model trained based on historical state data. For example, taking the aforementioned hydration state evaluation model as an XGBoost model, historical state data over a certain period can be collected, and then corresponding historical drinking water feature data can be obtained through feature engineering. The XGBoost model can then be trained using the historical drinking water feature data to obtain the aforementioned hydration state evaluation model. The collection of the aforementioned historical state data and feature engineering can be referred to the embodiments described above, and will not be repeated here.

[0063] Correspondingly, the above-mentioned determination of the user's hydration status corresponding to the aforementioned drinking water characteristic data using a preset evaluation model includes:

[0064] The first feature data, the second feature data, and the third feature data are used as inputs to the hydration status assessment model to obtain the user hydration status; wherein, the user hydration status includes user hydration classification and the priority corresponding to the hydration classification.

[0065] Specifically, the first feature data, the second feature data, and the third feature data can be combined using a preset combination order to obtain combined features, which are then input into the hydration status assessment model. The hydration status assessment model is then used to output the user's hydration classification and the corresponding priority of each classification. The user's hydration classification can include one of the following: normal, low risk of dehydration, or high risk of dehydration, with corresponding labels of 0, 1, and 2, respectively, and the priority of each label increasing sequentially.

[0066] For example, a combination feature can be obtained through a preset combination order: [vol_1h,vol_3h,mets_1h,THI,rmssd_5min,goal_rate,sleep_dev], where vol_1h is the recent water intake within 1 hour, vol_3h is the recent water intake within 3 hours, mets_1h is the metabolic equivalent within 1 hour, rmssd_5min is the heart rate variability index within 5 minutes, goal_rate is the water intake completion rate, and sleep_dev is the sleep activity deviation.

[0067] In some embodiments, obtaining the drinking water recommendation result based on the drinking water characteristic data, the user's hydration status, and the user's predicted demand includes:

[0068] Determine the current user shortage based on the above user status data;

[0069] Based on the current water shortage, hydration status, and projected water demand of the users, the recommended water intake for each user is calculated.

[0070] Whether to trigger a drinking water recommendation is determined based on a preset recommendation decision logic; wherein, the preset recommendation decision logic is a recommendation logic set based on one or more of the above drinking water characteristic data, the user's current water deficit, the user's hydration status, and the user's predicted water demand.

[0071] When the above drinking water recommendation is triggered, a drinking water recommendation template is matched, and the drinking water recommendation template is filled according to one or more of the above drinking water feature data, the user's current water deficit, the user's hydration status, and the user's predicted water demand, as well as the user's recommended drinking water volume, to obtain the above drinking water recommendation result.

[0072] It should be understood that the aforementioned current water shortage for users refers to the theoretically insufficient amount of water they need to drink. The aforementioned preset recommendation decision logic can be a recommendation rule determined at the rule engine level (e.g., IF-THEN logic). The aforementioned water recommendation template includes the slots to be filled.

[0073] For example, the aforementioned pre-defined recommendation decision logic may include, but is not limited to: IF user hydration status is assessed as "high risk of dehydration" THEN immediately trigger drinking water recommendation; IF high-intensity exercise is predicted in the next hour THEN trigger drinking water recommendation 30 minutes in advance, recommending replenishment of an appropriate amount of water (e.g., 150-250ml); IF currently within the recommendation time window AND (time since last drinking > threshold OR recent cumulative water intake < current water deficit) THEN trigger drinking water recommendation; IF user calendar shows "in meeting" OR water cup shows "still" for a long time (possibly while sleeping) THEN reduce recommendation priority or delay recommendation; IF user recently reported too many recommendations THEN reduce recommendation frequency. The above recommended hydration template may include, but is not limited to: Hot weather ({temp}℃ / THI{thi}), you have not drunk water for {gap} hours, it is recommended to drink {vol}mL of water to prevent dehydration; You will be performing {activity} in {t_minus} minutes, drinking {vol}mL of water beforehand can help maintain performance; For your weight loss goals, drinking {vol}mL of water {t_minus} minutes before meals helps control appetite; ({temp}℃ / THI{thi}), {gap}, and {vol} are preset slots.

[0074] Specifically, the user's current water deficit can be determined based on the difference between the user's recent water intake and the user's target water intake in the user status data. Then, the user's current water deficit, hydration status, and predicted water demand are used as inputs to a preset water recommendation model to obtain the user's recommended water intake. Next, based on the preset recommendation decision logic and one or more of the above-mentioned water feature data, current water deficit, hydration status, and predicted water demand, it is determined whether to trigger a water recommendation action. When it is determined to trigger a water recommendation action, a water recommendation template is matched based on one or more of the above-mentioned water feature data, current water deficit, hydration status, and predicted water demand. Finally, the water recommendation template is filled with the above-mentioned water feature data, current water deficit, hydration status, and predicted water demand, as well as the user's recommended water intake, to obtain the water recommendation result.

[0075] It should also be noted that, in order to improve the user interaction experience, the above drinking water recommendation results can be input into a pre-built Natural Language Generation (NLG) model for polishing or adjustment. For example, the drinking water recommendation results can be used to generate concise and easy-to-understand reasons, so as to facilitate user comprehension.

[0076] In this embodiment, after obtaining the current water shortage, water recommendations are made based on the user's current water shortage, hydration status, and predicted demand, which improves the accuracy of the water recommendation calculation. Simultaneously, by determining the timing of water recommendations based on a preset recommendation decision logic and by filling in a water recommendation template, targeted water recommendation results can be generated based on the user's current state, further improving the accuracy of water recommendations.

[0077] It should be noted that after obtaining the above drinking water recommendations, a recommendation instruction (including recommended amount, time window, priority, and explanatory text ID or content) can be generated based on these recommendations. This instruction is then sent to the application on the terminal device via a push service (such as FCM / APNS). Upon receiving the instruction, the application displays a detailed notification. Furthermore, the instruction is sent to the water cup or its base via a transmission protocol (such as MQTT) or polling method. The water cup or its base then determines when to remind the user via light (such as a blue breathing light to indicate a drinking suggestion) or sound, based on priority and current status (whether it is convenient to be disturbed).

[0078] It should also be noted that the actual drinking behavior of users can be recorded for a period of time after the drinking water recommendation. The corresponding drinking water characteristic data can be used as data points to retrain the hydration status assessment model periodically, thereby continuously improving the accuracy of the hydration status assessment model.

[0079] In some embodiments, in order to comprehensively consider user activity status and physiological status, the above-mentioned determination of the user's current gap based on the user status data includes:

[0080] The baseline demand is determined based on the aforementioned user physiological status data.

[0081] Adjustment factors are calculated based on the aforementioned user activity status data and user physiological status data; wherein, the aforementioned adjustment factors are factors characterizing changes in user physiological status and activity status;

[0082] The theoretical demand is obtained by adjusting the baseline demand using the aforementioned adjustment factors.

[0083] Based on the theoretical demand and the user's current water consumption determined by the above water cup status data, calculate the user's current water shortage.

[0084] Specifically, the baseline requirement can be determined based on the user's weight and a preset baseline intake formula, or the user's target water intake can be set as the baseline requirement. Then, one or more adjustment factors can be calculated based on the user's activity status data and physiological status data. The theoretical requirement can be determined by multiplying the baseline requirement and the adjustment factors. Finally, the difference between the theoretical requirement and the user's current water intake can be calculated to obtain the user's current water deficit.

[0085] Optionally, the preset baseline intake formula can be: Baseline requirement (ml) = Body weight (kg) × 30 - 40. The adjustment factors can include activity intensity adjustment factor f1, environmental temperature and humidity adjustment factor f2, and physiological state adjustment factor f3, where f1 = 1 + 0.015 × a, where a is the parameter corresponding to the metabolic equivalent; f2 = 1 + max(0, (THI-75) / 12) × 0.1, where THI is the heart rate variability index; and f3 = 1.2 (fever state) or 1.0 (normal state).

[0086] Wherein, the above theoretical demand is equal to the baseline demand multiplied by f1, f2, and f3.

[0087] In this embodiment of the application, the above-mentioned baseline demand is adjusted by combining adjustment factors. Since the above-mentioned adjustment factors take into account user activity status and physiological status, the accuracy of theoretical demand calculation can be improved.

[0088] In some embodiments, before calculating the recommended water intake based on the user's current hydration deficit, the user's hydration status, and the user's predicted water demand, the method further includes:

[0089] Define a state space based on historical state data and the user hydration state corresponding to the historical state data, and define the recommended actions that can be taken in the state space.

[0090] The reward function is determined based on the aforementioned historical state data and the corresponding user hydration status. The reward function is used to evaluate the effect of the preset drinking water recommendation model outputting the aforementioned recommendation action.

[0091] The above-mentioned reward function is used to train the preset drinking water recommendation model to obtain the trained drinking water recommendation model.

[0092] It should be understood that the above reward function can provide positive or negative rewards to guide the system to learn an optimal recommendation strategy to maximize the user's long-term hydration health. The reward function can be designed with the following reward logic: Short-term goal achievement: "Did the user drink water as recommended after the recommendation? Was the daily water intake goal achieved?", and a positive reward is given upon achievement; Hydration status maintenance: "Based on the hydration status assessment model, determine whether the user has maintained a 'normal' hydration status for an extended period? Or whether they have avoided entering a 'high risk of dehydration' state?, and a positive reward is given upon achievement"; User feedback: "Positive evaluations of the recommendation rating or reported health improvements (such as increased energy) by the user" are given, and "Negative rewards are given if the user reports inaccurate recommendations or being disturbed." Of course, reward logic can be added or reduced according to actual circumstances, and this is not limited here.

[0093] Specifically, a state space can be defined first, which includes historical state data, historical drinking characteristics corresponding to the historical state data, and the user's hydration status. Then, the drinking recommendation actions that can be taken can be defined, such as recommending drinking X milliliters of water at the next time step (X can be several discrete levels, such as 0ml, 100ml, 200ml, 300ml), or not issuing a drinking recommendation. Then, a reward function is designed based on the historical state data and the user's hydration status corresponding to the historical state data. The model parameters of the preset drinking recommendation model are continuously adjusted according to the reward signal generated by the reward function until the reward signal generated by the reward function is greater than or equal to the preset reward value, thus obtaining the trained drinking recommendation model.

[0094] For example, suppose the reward function = w1 × [hydration compliance reward] + w2 × [hydration risk reward] + w3 × [user evaluation reward] + w4 × [overhydration reward] + w5 × [interference evaluation reward] + w6 × [completion rate reward] + w7 × [physiological state reward], where [hydration compliance reward] is positively rewarded when the user drinks water according to the recommendations, and negatively rewarded otherwise; [hydration risk reward] is positively rewarded when the hydration risk decreases, and negatively rewarded otherwise; [user evaluation reward] is positively rewarded when the user... A positive reward is given for liking a post, and a negative reward for disliking it; [Overhydration Reward] is given a negative reward when [actual water intake > 1.5 × baseline requirement], and a positive reward otherwise; [Disruption Evaluation Reward] is given a negative reward when triggered by a meeting or sleep, and a positive reward or zero otherwise; [Completion Rate Reward] is given a positive reward when the user achieves the user's recommended water intake, and a negative reward or zero otherwise; [Physiological State Reward] is given a positive reward when the user's physiological state improves (e.g., increased HRV or increased subjective energy), and a negative reward or zero otherwise. Furthermore, since the time periods for which different rewards can be statistically analyzed differ, rewards can be aggregated in a tiered manner based on short / long time periods, i.e., rewards for short time periods are aggregated first, followed by rewards for long time periods.

[0095] In this embodiment, the reward function described above enables the system to autonomously explore and learn complex recommendation strategies to maximize long-term health benefits for users, thereby better adapting to individual differences and environmental changes and continuously improving the accuracy of drinking water recommendations.

[0096] Correspondingly, the above-mentioned calculation of the recommended water intake for the user based on the user's current water deficit, the user's hydration status, and the user's predicted water demand includes:

[0097] Using the user's current water shortage, hydration status, and predicted demand as inputs to the trained drinking water recommendation model, the recommended drinking water volume for the user is obtained.

[0098] Specifically, after obtaining the user-recommended water intake from the trained water recommendation model, smoothing can be performed to suppress abrupt changes and improve the stability of the output.

[0099] In some alternative embodiments, after training the preset drinking water recommendation model using the reward function to obtain the trained drinking water recommendation model, the method further includes:

[0100] The reward function is adjusted in real time based on the recommended water intake for the user, and the trained water recommendation model is then fine-tuned using the adjusted reward function.

[0101] Specifically, after the water recommendation model is deployed to a local server or a cloud server, the reward function can be adjusted in real time based on the user's recommended water intake and the current user status data. Alternatively, the reward function can be adjusted by collecting user's recommended water intake and user status data over a period of time. The trained water recommendation model can then be adjusted based on the reward signal updated by the reward function, thereby continuously fine-tuning the model parameters and improving the accuracy of water recommendations.

[0102] For example, the trained drinking water recommendation model can be dynamically fine-tuned using the Auto-RL reward shaping method.

[0103] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0104] Corresponding to the recommended drinking water method described in the above embodiments, Figure 2 A schematic diagram of the drinking water recommendation device provided in the embodiments of this application is shown. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0105] Reference Figure 2The device may include a drinking water recommendation device 21. The first drinking water recommendation device 21 may be applied to a local server or a cloud server.

[0106] Depending on the functions implemented, the drinking water recommendation device 21 may include a data acquisition module 211, a feature generation module 212, a status evaluation module 213, and a drinking water recommendation module 214.

[0107] Reference Figure 2 The drinking water recommendation device 21 includes:

[0108] The data acquisition module 211 is used to acquire real-time status data; wherein, the real-time status data includes water cup status data and user status data;

[0109] The feature generation module 212 is used to determine drinking feature data based on the water cup status data and the user status data; wherein the drinking feature data is used to characterize the current status of the water cup and the user associated with the water cup.

[0110] The status assessment module 213 is used to determine the user's hydration status corresponding to the above drinking water characteristic data using a preset assessment model, and to determine the user's predicted demand based on the above drinking water characteristic data.

[0111] The drinking water recommendation module 214 is used to obtain drinking water recommendation results based on the above drinking water characteristic data, the above user hydration status, and the above user predicted demand.

[0112] In some embodiments, the user status data includes user activity status data and user physiological status data; when the feature generation module 212 determines drinking characteristic data based on the water cup status data and the user status data, it includes:

[0113] The first feature data is determined based on the above water cup status data and its corresponding quantification rules; wherein, the above first feature data is used to characterize the user's drinking status;

[0114] The second feature data is determined based on the aforementioned user activity status data and its corresponding quantification rules; wherein, the aforementioned second feature data is used to characterize the user activity status;

[0115] The third feature data is determined based on the aforementioned user physiological state data and its corresponding quantification rules; wherein, the aforementioned third feature data is used to characterize the user's physiological state.

[0116] In some embodiments, the aforementioned preset evaluation model includes a hydration state evaluation model trained based on historical state data. For example, taking the aforementioned hydration state evaluation model as an XGBoost model, historical state data over a certain period can be collected, and then corresponding historical drinking water feature data can be obtained through feature engineering. The XGBoost model can then be trained using the historical drinking water feature data to obtain the aforementioned hydration state evaluation model. The collection of the aforementioned historical state data and feature engineering can be referred to the embodiments described above, and will not be repeated here.

[0117] Correspondingly, when the aforementioned state assessment module 213 determines the user's hydration status corresponding to the aforementioned drinking water characteristic data using a preset assessment model, it includes:

[0118] The first feature data, the second feature data, and the third feature data are used as inputs to the hydration status assessment model to obtain the user hydration status; wherein, the user hydration status includes user hydration classification and the priority corresponding to the hydration classification.

[0119] In some embodiments, when the drinking water recommendation module 214 obtains a drinking water recommendation result based on the drinking water characteristic data, the user's hydration status, and the user's predicted demand, it includes:

[0120] Determine the current user shortage based on the above user status data;

[0121] Based on the current water shortage, hydration status, and projected water demand of the users, the recommended water intake for each user is calculated.

[0122] Whether to trigger a drinking water recommendation is determined based on a preset recommendation decision logic; wherein, the preset recommendation decision logic is a recommendation logic set based on one or more of the above drinking water characteristic data, the user's current water deficit, the user's hydration status, and the user's predicted water demand.

[0123] When the above drinking water recommendation is triggered, a drinking water recommendation template is matched, and the drinking water recommendation template is filled according to one or more of the above drinking water feature data, the user's current water deficit, the user's hydration status, and the user's predicted water demand, as well as the user's recommended drinking water volume, to obtain the above drinking water recommendation result.

[0124] In some embodiments, in order to comprehensively consider user activity status and physiological status, the water recommendation module 214, when determining the user's current water deficit based on the aforementioned user status data, includes:

[0125] The baseline demand is determined based on the aforementioned user physiological status data.

[0126] Adjustment factors are calculated based on the aforementioned user activity status data and user physiological status data; wherein, the aforementioned adjustment factors are factors characterizing changes in user physiological status and activity status;

[0127] The theoretical demand is obtained by adjusting the baseline demand using the aforementioned adjustment factors.

[0128] Based on the theoretical demand and the user's current water consumption determined by the above water cup status data, calculate the user's current water shortage.

[0129] In some embodiments, the water recommendation device further includes a training module, which, before calculating the recommended water intake based on the user's current hydration deficit, the user's hydration status, and the user's predicted hydration needs, includes:

[0130] Define a state space based on historical state data and the user hydration state corresponding to the historical state data, and define the recommended actions that can be taken in the state space.

[0131] The reward function is determined based on the aforementioned historical state data and the corresponding user hydration status. The reward function is used to evaluate the effect of the preset drinking water recommendation model outputting the aforementioned recommendation action.

[0132] The above-mentioned reward function is used to train the preset drinking water recommendation model to obtain the trained drinking water recommendation model.

[0133] Correspondingly, when the aforementioned drinking water recommendation module 214 calculates the recommended drinking water volume for the user based on the user's current water deficit, the user's hydration status, and the user's predicted water demand, it includes:

[0134] Using the user's current water shortage, hydration status, and predicted demand as inputs to the trained drinking water recommendation model, the recommended drinking water volume for the user is obtained.

[0135] In some alternative embodiments, the above-mentioned drinking water recommendation device further includes a fine-tuning module, which is used to train the preset drinking water recommendation model using the above-mentioned reward function, and after obtaining the trained drinking water recommendation model, includes:

[0136] The reward function is adjusted in real time based on the recommended water intake for the user, and the trained water recommendation model is then fine-tuned using the adjusted reward function.

[0137] It should be noted that the information interaction and execution process between the devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0138] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 3 As shown, the electronic device 3 of this embodiment includes: at least one processor 30 ( Figure 3 Only one is shown in the diagram), memory 31, and computer program 32 stored in said memory 31 and executable on said at least one processor 30. When the processor 30 executes said computer program 32, it implements the steps in any of the various method embodiments.

[0139] The electronic device 3 can be a desktop computer, laptop, handheld computer, or cloud server, etc. The electronic device may include, but is not limited to, a processor 30 and a memory 31. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or combine certain components, or different components. For example, the electronic device may also include input transmitting devices, network access devices, buses, etc.

[0140] The processor 30 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0141] In some embodiments, the memory 31 may be an internal storage unit of the electronic device 3, such as a hard disk or memory of the electronic device 3. The memory 31 may also be an external storage device of the electronic device 3, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc., equipped on the electronic device 3. Furthermore, the memory 31 may include both internal and external storage units of the electronic device 3. The memory 31 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 31 can also be used to temporarily store data that has been sent or will be sent.

[0142] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the division of the functional units and modules is only described as an example. In practical applications, the functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0143] This application also provides a network device, which includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, wherein the processor executes the computer program to implement the steps in any of the various method embodiments.

[0144] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the various method embodiments.

[0145] This application provides a computer program product that, when run on an electronic device, enables the electronic device to perform the steps described in the various method embodiments.

[0146] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the embodiments described in this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or some intermediate form. The computer-readable medium can include at least: any entity or device capable of carrying the computer program code to a photographic device / electronic device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0147] In the embodiments described, each embodiment has its own emphasis. For parts not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0148] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0149] In the embodiments provided in this application, it should be understood that the disclosed apparatus / network devices and methods can be implemented in other ways. For example, the apparatus / network device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0150] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0151] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for recommending drinking water, characterized in that, The method is applied to a water cup and includes: Acquire real-time status data; wherein, the real-time status data includes water cup status data and user status data; Drinking characteristic data is determined based on the water cup status data and the user status data; wherein, the drinking characteristic data is used to characterize the current status of the water cup and the user associated with the water cup; The user's hydration status corresponding to the drinking water characteristic data is determined using a preset evaluation model, and the user's predicted demand is determined based on the drinking water characteristic data. The drinking water recommendation results are obtained based on the drinking water characteristic data, the user's hydration status, and the user's predicted demand.

2. The drinking water recommendation method as described in claim 1, characterized in that, The user status data includes user activity status data and user physiological status data; The step of determining drinking characteristic data based on the water cup status data and the user status data includes: The first feature data is determined based on the water cup status data and its corresponding quantization rules; wherein, the first feature data is used to characterize the user's drinking status; The second feature data is determined based on the user activity status data and its corresponding quantization rules; wherein, the second feature data is used to characterize the user activity status; The third feature data is determined based on the user's physiological state data and its corresponding quantification rules; wherein, the third feature data is used to characterize the user's physiological state.

3. The drinking water recommendation method as described in claim 2, characterized in that, The preset evaluation model includes a hydration status evaluation model trained based on historical status data; determining the user's hydration status corresponding to the drinking water characteristic data using the preset evaluation model includes: The first feature data, the second feature data, and the third feature data are used as inputs to the hydration status assessment model to obtain the user's hydration status; wherein, the user's hydration status includes the user's hydration classification and the priority corresponding to the hydration classification.

4. The drinking water recommendation method as described in claim 2 or 3, characterized in that, The step of obtaining drinking water recommendation results based on the drinking water characteristic data, the user's hydration status, and the user's predicted demand includes: Determine the current gap amount for each user based on the user status data; Calculate the recommended water intake for the user based on the user's current water deficit, the user's hydration status, and the user's predicted water demand. Whether to trigger a drinking water recommendation is determined according to a preset recommendation decision logic; wherein, the preset recommendation decision logic is a recommendation logic set based on one or more of the drinking water feature data, the user's current water deficit, the user's hydration status, and the user's predicted water demand. When the water recommendation is triggered, a water recommendation template is matched, and the water recommendation template is filled according to one or more of the water feature data, the user's current water deficit, the user's hydration status, and the user's predicted water demand, as well as the user's recommended water intake, to obtain the water recommendation result.

5. The drinking water recommendation method as described in claim 4, characterized in that, Determining the user's current deficit based on the user status data includes: Determine the baseline demand based on the user's physiological state data; An adjustment factor is calculated based on the user activity status data and the user physiological status data; wherein, the adjustment factor is a factor characterizing changes in the user's physiological and activity status; The baseline demand is adjusted using the adjustment factor to obtain the theoretical demand. Based on the theoretical demand and the user's current water consumption determined by the water cup status data, the user's current water deficit is calculated.

6. The drinking water recommendation method as described in claim 4, characterized in that, Before calculating the recommended water intake for the user based on the user's current hydration deficit, the user's hydration status, and the user's predicted water needs, the method further includes: A state space is defined based on historical state data and the user hydration state corresponding to the historical state data, as well as recommended actions that can be taken in the state space. A reward function is determined based on the historical state data and the user hydration status corresponding to the historical state data, wherein the reward function is used to evaluate the effect of the recommended action output by the preset drinking water recommendation model; The preset drinking water recommendation model is trained using the reward function to obtain the trained drinking water recommendation model; The step of calculating the recommended water intake for the user based on the user's current hydration deficit, the user's hydration status, and the user's predicted water needs includes: The user's current hydration deficit, the user's hydration status, and the user's predicted hydration needs are used as inputs to the trained hydration recommendation model to obtain the recommended hydration amount for the user.

7. The drinking water recommendation method as described in claim 6, characterized in that, After training the preset drinking water recommendation model using the reward function to obtain the trained drinking water recommendation model, the method further includes: The reward function is adjusted in real time based on the user's recommended water intake, and the trained water recommendation model is fine-tuned using the adjusted reward function.

8. A drinking water recommendation device, applied to a water cup, comprising: The data acquisition module is used to acquire real-time status data; wherein, the real-time status data includes water cup status data and user status data; A feature generation module is used to determine drinking feature data based on the water cup status data and the user status data; wherein, the drinking feature data is used to characterize the current status of the water cup and the user associated with the water cup; The status assessment module is used to determine the user's hydration status corresponding to the drinking water characteristic data using a preset assessment model, and to determine the user's predicted demand based on the drinking water characteristic data. The drinking water recommendation module is used to obtain drinking water recommendation results based on the drinking water characteristic data, the user's hydration status, and the user's predicted demand.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, Includes a computer program, which, when executed, implements the method as described in any one of claims 1 to 7.

Images