Vehicle message pushing method and device and vehicle

Abstract

The embodiment of the invention provides a vehicle message pushing method and device and a vehicle, and relates to the technical field of message processing. The method comprises the steps that multi-modal data and message features corresponding to a message pushing task are acquired, the multi-modal data are at least used for representing vehicle state features and user behavior features, and the message features are at least used for representing message content features of the message pushing task; the multi-modal data and the message features are utilized to drive a message decision model to make a push decision and determine a target message corresponding to a message push task, the message decision model is obtained by utilizing historical feedback data to carry out model parameter fine adjustment, the historical feedback data are user feedback data corresponding to historical push messages, and the user feedback data are user feedback data corresponding to the historical push messages. The historical push message is determined after the message decision model executes a push decision last time; and pushing the target message to the user side. According to the invention, the technical problems of poor dynamic adaptability and poor user experience of a vehicle message pushing method in the prior art are solved.

Description

Technical Field

[0001] This application relates to the field of message processing technology, and in particular to a vehicle message push method, device, and vehicle. Background Technology

[0002] With the development of intelligent connected vehicle technology, in-vehicle message push has become an important part of vehicle-machine interaction. In related technologies, in-vehicle system message push strategies typically rely on offline training methods for updates. This results in a long update cycle for these strategies, making it difficult to adapt to dynamically changing real-time application scenarios and leading to poor dynamic adaptability of vehicle message push methods.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a vehicle message push method, device, and vehicle, aiming to improve the technical problems of poor dynamic adaptability and poor user experience in related technologies.

[0005] According to one aspect of the embodiments of this application, a vehicle message push method is provided, comprising: acquiring multimodal data and message features corresponding to a message push task, wherein the multimodal data is used to characterize at least vehicle state features and user behavior features, and the message features are used to characterize at least message content features of the message push task; using the multimodal data and message features to drive a message decision model to make a push decision, and determining a target message corresponding to the message push task, wherein the message decision model is obtained by fine-tuning model parameters using historical feedback data, the historical feedback data being user feedback data corresponding to historical push messages, and the historical push messages being determined by the message decision model after the last push decision is executed; and pushing the target message to the user terminal.

[0006] The vehicle message push method provided in this application achieves the following technical effects: By acquiring multimodal data and message features corresponding to the message push task, more comprehensive information can be provided to the message decision model, especially information combined with the real-time application scenario of the vehicle, laying a data foundation for the subsequent push decision-making of the message decision model; further, based on the message decision model's previous push decision, historical push messages are determined, and the user feedback data corresponding to the historical push messages is used as historical feedback data. The model parameters are fine-tuned using the historical feedback data to obtain the message decision model. Through the above-mentioned mechanism for updating the model parameters of the message decision model, a closed-loop online learning process for the message decision model is formed. The message decision model can better adapt to dynamic scene changes, thereby using multimodal data and message features to determine target messages with better dynamic adaptability, improving the push decision performance of the message decision model; further, the target message is pushed to the user terminal, enhancing the user experience. Thus, this application achieves the goal of updating the parameters of the message decision model online to obtain target messages with better dynamic adaptability, realizing the technical effects of improving the dynamic adaptability of the vehicle message push method and enhancing the user experience, thereby solving the technical problems of poor dynamic adaptability and poor user experience in related technologies.

[0007] Optionally, the vehicle message push method further includes: obtaining target feedback data corresponding to the target message, wherein the target feedback data is generated based on the interactive operation performed on the target message; and using the target feedback data to fine-tune the model parameters of the message decision model and update the message decision model.

[0008] The above-mentioned optional embodiments of this application can achieve the following technical effects: generating target feedback data based on the user's interactive operation on the target message, and further, using the target feedback data to fine-tune the model parameters of the message decision model and update the message decision model, which can dynamically respond to changes in real-time application scenarios, enhance the message decision performance of the message decision model, and thus obtain a target message that is more in line with the real-time application scenario.

[0009] Optionally, obtaining multimodal data corresponding to the message push task includes: obtaining the task type and vehicle location data corresponding to the message push task; performing scenario analysis based on the task type and location data to obtain scenario analysis results, wherein the scenario analysis results are used to determine whether the vehicle is in the task-related scenario corresponding to the vehicle message; determining the data collection range based on the task type and the data collection frequency based on the scenario analysis results; and collecting multimodal data within the data collection range according to the data collection frequency.

[0010] The above-mentioned optional embodiments of this application can achieve the following technical effects: by combining the task type corresponding to the message push task and the vehicle's location data for scene analysis, the scene analysis results are obtained; furthermore, the data collection range is determined according to the task type, and the data collection frequency is determined according to the scene analysis results, thereby realizing task-driven data collection, which can reduce the collection of invalid data and reduce the consumption of vehicle computing and storage resources.

[0011] Optionally, the message decision model includes a message filtering model, a prediction model, and multi-level scenario decision rules. Utilizing multimodal data and message features, the message decision model drives push decisions to determine the target message for the push task. This includes: using multimodal data and message features to drive the message filtering model to perform filtering processing to obtain a candidate message pool; using multimodal data to drive the prediction model to predict the click-through rate (CTR) of the candidate message pool to obtain a predicted CTR value; and determining the target message from the candidate message pool based on the predicted CTR value and the multi-level scenario decision rules.

[0012] The above-mentioned optional embodiments of this application can achieve the following technical effects: by using a message filtering model to filter messages that are not highly relevant to the message push task, the candidate message pool can be obtained, which can reduce the processing load of the prediction model and improve the overall processing efficiency; furthermore, by using the prediction model to predict the click-through rate of the candidate message pool, the message click-through rate prediction value can be obtained, and combined with multi-level scenario decision rules, the target message can be accurately determined.

[0013] Optionally, the vehicle message push method further includes: updating the initial interaction matrix corresponding to the message filtering model based on historical feedback data to obtain a target interaction matrix, wherein the elements contained in the target interaction matrix are used to reflect the user's preference for historical push messages; and using the target interaction matrix to fine-tune the model parameters of the message filtering model and update the message filtering model.

[0014] The above-mentioned optional embodiments of this application can achieve the following technical effects: by updating the initial interaction matrix corresponding to the message filtering model according to historical feedback data, the target interaction matrix is ​​obtained, and the model parameters of the message filtering model are further fine-tuned using the target interaction matrix to update the message filtering model, thereby improving the message filtering accuracy of the message filtering model and enhancing the performance of the message filtering model.

[0015] Optionally, the multimodal data includes vehicle state data corresponding to vehicle state features. The vehicle state data includes the current road type and vehicle speed. The vehicle message push method further includes: calling a map interface to obtain the road speed limit data corresponding to the current road type in real time from the map data; adjusting the initial driving speed threshold according to the current road type and road speed limit data to obtain the target driving speed threshold; comparing the vehicle speed with the target driving speed threshold to determine the current driving scenario information corresponding to the vehicle; adjusting the initial multimodal feature weights corresponding to the prediction model based on the current driving scenario information to obtain the target multimodal feature weights; and fine-tuning the model parameters of the prediction model using the target multimodal feature weights and historical feedback data to update the prediction model.

[0016] The above-mentioned optional embodiments of this application can achieve the following technical effects: Based on the current road type and road speed limit data, the initial driving speed threshold can be dynamically adjusted to obtain a more accurate target driving speed threshold and determine more accurate current driving scenario information; furthermore, based on the current driving scenario information, the initial multimodal feature weights corresponding to the prediction model can be adjusted to obtain target multimodal feature weights with better dynamic adaptability. By using the target multimodal feature weights and historical feedback data to fine-tune the model parameters of the prediction model and update the prediction model, the dynamic adaptability of the prediction model to real-time application scenarios can be enhanced, thereby improving the click-through rate prediction performance of the prediction model.

[0017] Optionally, the candidate message pool includes multiple candidate messages, and the multi-level scenario decision rules include multi-level scenario prediction thresholds and additional conditions. The multi-level scenario prediction thresholds are obtained by correcting historical feedback data. Determining the target message from the candidate message pool based on the message click-through rate prediction value and the multi-level scenario decision rules includes: traversing the candidate messages in the candidate message pool that meet the additional conditions; comparing the message click-through rate prediction value corresponding to the candidate message with the current scenario prediction threshold to obtain a comparison result, where the candidate message is the one currently being compared and analyzed during the traversal, and the current scenario prediction threshold is determined from the multi-level scenario prediction threshold based on the current driving scenario information. The comparison result is used to determine whether the candidate message needs to be pushed; in response to the comparison result indicating that the candidate message needs to be pushed, the candidate message is determined as the target message.

[0018] The above-mentioned optional embodiments of this application can achieve the following technical effects: by using additional conditions to perform preliminary screening of candidate conditions in the candidate message pool, the number of traversals can be reduced, and the overall efficiency of the vehicle message push method can be improved; furthermore, based on the current driving scenario information, the current scenario prediction threshold is determined from the multi-level scenario prediction threshold, and the candidate messages currently being compared and analyzed during the traversal are taken as candidate messages. The message click rate prediction value corresponding to the candidate message is compared and analyzed with the current scenario prediction threshold. The current scenario prediction threshold can be corrected in real time according to the current driving scenario information, thereby obtaining a more accurate comparison result and more accurately determining the target message.

[0019] Optionally, message features are also used to characterize the push method weight. The vehicle message push method further includes: updating the push method weight based on historical feedback data, historical push methods corresponding to historical push messages, push method weight thresholds, and weight adjustment ratios; determining the target push method corresponding to the target message from multiple candidate push methods based on multimodal data and push method weights; and pushing the target message to the user terminal according to the target push method.

[0020] The above-mentioned optional embodiments of this application can achieve the following technical effects: based on historical feedback data, historical push methods corresponding to historical push messages, push method weight thresholds and weight adjustment ratios, the push method weights can be dynamically updated, making the dynamic adaptability of push method weights better, thereby enabling the target message to be pushed to the user terminal according to the push method preferred by the user, thus enhancing the user experience.

[0021] According to another aspect of the embodiments of this application, a vehicle message push device is also provided, comprising: an acquisition module, configured to acquire multimodal data and message features corresponding to a message push task, wherein the multimodal data is used to characterize at least vehicle state features and user behavior features, and the message features are used to characterize at least the message content features of the message push task; a decision module, configured to use the multimodal data and message features to drive a message decision model to make push decisions and determine the target message corresponding to the message push task, wherein the message decision model is obtained by fine-tuning model parameters using historical feedback data, the historical feedback data being user feedback data corresponding to historical push messages, and the historical push messages being determined by the message decision model after the last push decision; and a push module, configured to push the target message to the user terminal.

[0022] The vehicle message push device provided in this application embodiment achieves the following technical effects: By using the acquisition module to acquire multimodal data and message features corresponding to the message push task, more comprehensive information can be provided to the message decision model, especially information combined with the real-time application scenario of the vehicle, laying a data foundation for the subsequent push decision-making of the message decision model; further, by using the decision module to determine the historical push message based on the last push decision executed by the message decision model, the user feedback data corresponding to the historical push message is used as historical feedback data, and the model parameters are fine-tuned using the historical feedback data to obtain the message decision model. Through the above-mentioned mechanism for updating the model parameters of the message decision model, a closed-loop online learning process of the message decision model is formed. The message decision model can better adapt to dynamic scene changes, thereby using multimodal data and message features to determine target messages with better dynamic adaptability, improving the push decision performance of the message decision model; further, by using the push module to push the target message to the user terminal, the user experience is enhanced, thereby enhancing the dynamic adaptability of the target message pushed by the vehicle message push device and improving the performance of the vehicle message push device.

[0023] According to another aspect of the embodiments of this application, a vehicle is also provided, including an on-board memory and an on-board processor, wherein the on-board memory is used to store a computer program; and the on-board processor is used to execute the computer program stored in the memory to implement the method of any one of the above.

[0024] The vehicle provided in this application embodiment achieves the following technical effects: By acquiring multimodal data and message features corresponding to the message push task, it can provide more comprehensive information for the message decision model, especially by combining information from the vehicle's real-time application scenario, laying a data foundation for the subsequent push decision-making of the message decision model; further, based on the message decision model's previous push decision, historical push messages are determined, and the user feedback data corresponding to these historical push messages is used as historical feedback data. The model parameters are then fine-tuned using this historical feedback data to obtain the message decision model. Through the above-mentioned mechanism for updating the model parameters of the message decision model, a closed-loop online learning process for the message decision model is formed. The message decision model can better adapt to dynamic scene changes, thereby using multimodal data and message features to determine target messages with better dynamic adaptability, improving the push decision performance of the message decision model; furthermore, pushing the target message to the user terminal improves the user's satisfaction with the overall performance of the vehicle. Attached Figure Description

[0025] Figure 1 This is a flowchart of a vehicle message push method provided in an embodiment of this application;

[0026] Figure 2 This is a schematic diagram of a vehicle message push method provided in an embodiment of this application;

[0027] Figure 3 This is a structural block diagram of a vehicle message push device provided in an embodiment of this application;

[0028] Figure 4 This is a structural block diagram of a vehicle provided in one embodiment of this application;

[0029] Figure 5 This is a hardware structure block diagram of a computing terminal provided in an embodiment of this application;

[0030] Figure 6 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0031] To make the technical problems, technical solutions, and beneficial effects solved by this application clearer, the following detailed description is provided in conjunction with embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0032] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0033] This application provides a vehicle message push method. Please refer to [link / reference]. Figure 1 This includes the following steps:

[0034] S10: Obtain the multimodal data and message features corresponding to the message push task. The multimodal data is used to characterize at least the vehicle status features and user behavior features, and the message features are used to characterize at least the message content features of the message push task.

[0035] The aforementioned multimodal data can refer to a dataset from multiple information sources. This multimodal data may include vehicle status data corresponding to the aforementioned vehicle status features and user behavior data corresponding to the aforementioned user behavior features. The aforementioned vehicle status data may include current vehicle status data and historical vehicle status data, and the aforementioned user behavior data may include current user behavior data and historical user behavior data.

[0036] Specifically, the aforementioned vehicle status data may also include spatiotemporal data, which can be obtained through spatiotemporal analysis of current and historical vehicle status data. For example, the current and historical vehicle status data can be processed using Fourier transform to extract the weekly periodicity corresponding to the vehicle. This weekly periodicity can be used to determine the high-frequency time period corresponding to a certain user behavior under preset conditions, such as the high-frequency shopping time period on Friday evenings. When the number of times behavior G occurs within a certain time period exceeds a threshold, that time period can be considered the high-frequency time period corresponding to behavior G.

[0037] The aforementioned vehicle status data may include, but is not limited to: vehicle physical status (e.g., vehicle speed, gear status, acceleration, remaining battery percentage, battery state of charge, battery charging status, vehicle charging port status, steering angle), and vehicle surrounding environment data (e.g., location of charging stations, parking lots, restaurants, and weather data). The aforementioned user behavior data may include, but is not limited to: historical click-through rates for similar messages, push notification method preference data (this preference can be determined by analyzing historical user behavior data; for example, if a user closes more pop-ups per month than the expected number of pop-up notifications, it can be assumed that the user dislikes pop-up notifications, and the weight of the corresponding push notification method can be reduced), and real-time interaction data (e.g., current navigation usage status, current music playback status, etc.).

[0038] The aforementioned message features are used at least to characterize the message content features of a push notification task. In particular, these message features can also be used to characterize push notification method preferences. The aforementioned message content features may include, but are not limited to: message category (e.g., security alert category, service recommendation category, entertainment information category), timeliness window, and the business scenario corresponding to the push notification task.

[0039] It is easy to understand that in this application, by obtaining multimodal data and message features corresponding to the message push task, more comprehensive information can be provided for the message decision model. In particular, by combining information from the real-time application scenario of the vehicle, a data foundation is laid for the subsequent driving of the message decision model to make push decisions.

[0040] S20: Utilize multimodal data and message features to drive the message decision model to make push decisions and determine the target message corresponding to the message push task. The message decision model is obtained by fine-tuning the model parameters using historical feedback data, which is the user feedback data corresponding to the historical push messages. The historical push messages are determined by the message decision model after the last push decision is executed.

[0041] The aforementioned message decision model can refer to an intelligent algorithm that integrates multimodal data and message features. This message decision model can be used to analyze vehicle status and user behavior, predict the probability that a specific message will be received by the user, and thus determine the message push strategy (including at least the target information to be pushed, and in particular, the message push method).

[0042] The aforementioned message decision-making model is obtained by fine-tuning the model parameters using historical feedback data. This historical feedback data consists of user feedback data corresponding to previous push messages, which are determined by the message decision-making model after its last push decision. This means that the message decision-making model can be iteratively optimized online using historical feedback data. Specifically, after the message decision-making model makes its last push decision, it can determine the historical push message (i.e., the target message determined in the previous push decision-making process), push this historical push message to the user, and obtain user feedback data corresponding to the historical push message. This historical feedback data is then used to fine-tune the model parameters to update the message decision-making model's parameters.

[0043] The methods for fine-tuning the aforementioned model parameters can include supervised learning and reinforcement learning. The specific process for using supervised learning is as follows: Historical feedback data and historical push messages are used as the training set; historical input data (including historical message features and historical multimodal data) corresponding to the historical push messages are used as the input data; historical feedback data is used as the label data corresponding to the input data; and a loss function (e.g., binary cross-entropy loss) is used to guide parameter optimization, thereby adjusting the model parameters of the message decision model so that it can push messages with better adaptability. The specific process for using reinforcement learning is as follows: A reinforcement learning environment is constructed, using historical feedback data as reward / penalty signals. The objective of the message decision model can be to minimize the loss or maximize the reward (e.g., click-through rate). The policy parameters of the message decision model are updated using a reinforcement learning algorithm to optimize the future decision-making process of the message decision model.

[0044] The aforementioned user feedback data may include, but is not limited to: interactive behaviors performed in response to system-pushed messages (e.g., clicking, ignoring, converting), and interaction duration (e.g., the time period between the moment the message is pushed to the user's device and the moment the user clicks on the message).

[0045] It is easy to understand that the above-mentioned model parameter update mechanism forms a closed-loop online learning process for the message decision model. The message decision model can gradually learn and adapt to user preferences and real-time, dynamic scene changes, thereby improving the push decision performance of the message decision model and being able to determine target messages with better dynamic adaptability.

[0046] S30: Push the target message to the user's device.

[0047] The aforementioned user terminal can refer to the device or platform through which the user directly interacts with the vehicle. It is understood that after the system pushes the target message to the user terminal, it can display the target message on the corresponding display interface on the user terminal, or it can sample the corresponding voice broadcast system on the user terminal to broadcast the target message aloud. The aforementioned user terminal can include, but is not limited to: cockpit display systems and mobile terminals connected to the vehicle.

[0048] The vehicle message push method provided in this application achieves the following technical effects: By acquiring multimodal data and message features corresponding to the message push task, more comprehensive information can be provided to the message decision model, especially information combined with the real-time application scenario of the vehicle, laying a data foundation for the subsequent driving of the message decision model to make push decisions; further, based on the message decision model's previous push decision, historical push messages are determined, and the user feedback data corresponding to the historical push messages is used as historical feedback data. The model parameters are fine-tuned using the historical feedback data to obtain the message decision model. Through the above-mentioned mechanism for updating the model parameters of the message decision model, a closed-loop online learning process for the message decision model is formed. The message decision model can better adapt to dynamic scene changes, thereby using multimodal data and message features to determine target messages with better dynamic adaptability, improving the push decision performance of the message decision model; furthermore, pushing the target message to the user terminal enhances the user experience. Therefore, the embodiments of this application achieve the goal of updating the parameters of the message decision model by utilizing an online learning mechanism to obtain target messages with better dynamic adaptability, thereby improving the dynamic adaptability of the vehicle message push method and enhancing the user experience. This solves the technical problems of poor dynamic adaptability and poor user experience in related technologies.

[0049] The vehicle message push method provided in this application uses an online learning mechanism to update the parameters of the message decision model, thereby obtaining target messages with better dynamic adaptability. It can be widely applied in multiple application scenarios, such as scenarios in the field of passenger cars: commuting autonomous driving scenarios, artificial intelligence (AI) chauffeur driving scenarios for passenger cars, and intelligent navigation-guided pilot (NGP) scenarios in urban or highway areas.

[0050] Furthermore, the aforementioned preset application scenarios may also include, but are not limited to: intelligent driving scenarios for intelligent trucks in the logistics and transportation field, and message push scenarios for intelligent robots (such as cleaning robots, service robots, delivery robots, etc.). When the aforementioned preset application scenarios are scenarios in fields other than the passenger car field, those skilled in the art should understand that by replacing the vehicle in the above vehicle message push method with other objects (such as agricultural machinery, drones, robots, etc.), correspondingly, the vehicle status characteristics are replaced with status characteristics related to other objects, the user behavior characteristics are replaced with the interactive personnel behavior characteristics related to other objects, and the user feedback data is replaced with the interactive personnel feedback data related to other objects. Based on this, this application embodiment takes the passenger car field as an example to illustrate the specific implementation of the above vehicle message push method.

[0051] Optionally, the above vehicle message push method further includes the following steps:

[0052] S40: Obtain the target feedback data corresponding to the target message, wherein the target feedback data is generated based on the interactive operation performed on the target message;

[0053] S50: Use target feedback data to fine-tune the model parameters of the message decision model and update the message decision model.

[0054] The aforementioned interactive operations refer to the user's actions in response to the target message. These interactive operations may include, but are not limited to: click operations (it is understood that when a user is interested in the target message, the probability of the user performing a click operation on the target message is higher), ignore operations, close operations (it is understood that when a user is averse to the target message, the probability of the user performing a close operation on the target message is higher), and conversion operations (for example, further actions performed by the user after clicking on the target message, behaviors that directly reflect the commercial value of the target message; the aforementioned further actions include, but are not limited to, purchasing, registering, or subscribing).

[0055] The aforementioned target feedback data can be obtained in the following two ways: Method 1: The system directly generates target feedback data in response to the interactive operation performed on the target message; Method 2: When the target message is pushed to a mobile terminal connected to the vehicle, the mobile terminal generates target feedback data by performing an interactive operation on the target message. Furthermore, the mobile terminal, as the sender, sends the generated target feedback data to the system, and the system, as the receiver, obtains the target feedback data corresponding to the target message.

[0056] The process of fine-tuning the model parameters described above can be referred to the content introduced earlier. When using the target feedback data to fine-tune the model parameters of the message decision model and update the message decision model, the historical feedback data mentioned earlier can be replaced with the target feedback data. This will not be elaborated here.

[0057] The above-mentioned optional embodiments of this application can achieve the following technical effects: generating target feedback data based on the user's interactive operation on the target message, and further, using the target feedback data to fine-tune the model parameters of the message decision model and update the message decision model, which can dynamically respond to changes in real-time application scenarios, enhance the message decision performance of the message decision model, and thus obtain a target message that is more in line with the real-time application scenario.

[0058] Optionally, in step S10 above, obtaining the multimodal data corresponding to the message push task includes the following steps:

[0059] S11: Obtain the task type and vehicle location data corresponding to the message push task;

[0060] S12: Perform scenario analysis based on task type and location data to obtain scenario analysis results. The scenario analysis results are used to determine whether the vehicle is in the task-related scenario corresponding to the vehicle message.

[0061] S13: Determine the data collection scope based on the task type, and determine the data collection frequency based on the scenario analysis results;

[0062] S14: Collect multimodal data within the data acquisition range according to the data acquisition frequency.

[0063] The task type mentioned above refers to the content category of the push notification task, which can be used to determine the specific purpose of the push notification task. This task type may include, but is not limited to: safety alerts, service recommendations, and information updates. The safety alert type may include, but is not limited to: road condition warnings and vehicle health reports. The service recommendation type may include, but is not limited to: charging (e.g., a push notification for charging discounts), navigation, restaurant reservations, and shopping mall promotions. The information update type may include, but is not limited to: weather forecasts (e.g., a push notification for heavy rain warnings) and news.

[0064] Understandably, by obtaining the task type corresponding to the push notification task, the urgency and related scenarios of the push notification task can be analyzed. Based on the task type, the data types that the system needs to collect can be determined, and these data types constitute the data collection scope, thereby achieving the collection of multimodal data strongly correlated with the push notification task. For example, when the push notification task is of the charging type, the data within the data collection scope may include: battery charge status, charging port status, and charging station location information around the vehicle; when the push notification task is of the navigation type, the data within the data collection scope may include: real-time vehicle speed, steering angle, information on restaurants near the destination, and parking information near the destination.

[0065] The aforementioned location data can refer to the vehicle's current geographic coordinates and additional data related to the vehicle's location. This location data may include, but is not limited to: the vehicle's latitude and longitude coordinates, altitude, and surrounding environmental data (e.g., the location of a type of place of interest). This location data can be obtained through several methods: vehicle positioning systems (e.g., Global Positioning System), high-precision map data, standard-precision map data, and onboard sensors. In practical applications, one or more of these location acquisition methods can be used.

[0066] The aforementioned task-related scenarios refer to the environment associated with the push notification task. For example, when a vehicle enters or leaves a preset geographical area (such as near a charging station or a shopping mall parking lot), the vehicle can be considered to be in a task-related scenario. The aforementioned data collection frequency refers to the frequency at which the system collects multimodal data, and this data collection frequency can be dynamically adjusted according to the task type.

[0067] The above scenario analysis results can be used to determine whether a vehicle is in a task-related scenario corresponding to a vehicle message. These results can be obtained in several ways: methods based on a pre-defined scenario rule base and machine learning models, combined with deep learning models and environmental perception technologies. The specific process of the method based on a pre-defined scenario rule base and machine learning models can be as follows: First, identify task characteristics based on the task type. These characteristics can be used to determine the data that the message push task focuses on (i.e., the data collection scope), for example, a safety reminder task focuses on vehicle health data. Second, map the vehicle's location data to geofences on a map, combine this with additional data related to the vehicle's location to determine the vehicle's real-time status (e.g., whether it is near a charging station), and use a machine learning model to analyze and determine whether the vehicle is in a task-related scenario, thus obtaining the scenario analysis result.

[0068] In one exemplary application scenario, such as Figure 2 As shown, when a message push task is created, a task identifier corresponding to the message push task is generated. Using this task identifier and the identifier type mapping table, the task type corresponding to the message push task can be determined, and the vehicle's location data can be determined based on high-precision map data. Furthermore, a method based on a pre-set scene rule base and machine learning model is used to perform scene analysis based on the task type and location data to obtain scene analysis results. Based on the scene analysis results, it is determined whether the vehicle is in the task-related scene corresponding to the vehicle message. For example, when the vehicle is within 3 kilometers of the charging station, it can be considered that the vehicle is in the task-related scene corresponding to the vehicle message. Further, the scene-based data monitoring module is activated according to the task type. At this time, the scene-based data monitoring module can collect multimodal data within the data collection range, and the data collection frequency of the scene-based data monitoring module is determined according to the scene analysis results. When the system determines that the vehicle is not in the task-related scene corresponding to the vehicle message based on the scene analysis results, the data collection frequency is set to 5 minutes / time; when the system determines that the vehicle is in the task-related scene corresponding to the vehicle message based on the scene analysis results, the data collection frequency is adjusted to 30 seconds / time. Therefore, the scenario-based data monitoring module can collect multimodal data within the data collection range according to the data collection frequency.

[0069] In some application scenarios, after the system collects the above-mentioned multimodal data, it can perform data preprocessing, including: using differential privacy technology to desensitize sensitive data such as user location and charging status; and filtering out accidental touch operations by users while driving through a sliding window.

[0070] The above-mentioned optional embodiments of this application can achieve the following technical effects: by combining the task type corresponding to the message push task and the vehicle's location data for scene analysis, the scene analysis results are obtained; furthermore, the data collection range is determined according to the task type, and the data collection frequency is determined according to the scene analysis results, thereby realizing task-driven data collection, which can reduce the collection of invalid data and reduce the consumption of vehicle computing and storage resources.

[0071] Optionally, the message decision model includes a message filtering model, a prediction model, and multi-level scenario decision rules. In step S20 above, using multimodal data and message features to drive the message decision model to make push decisions and determine the target message corresponding to the message push task includes the following steps:

[0072] S21: Utilize multimodal data and message features to drive the message filtering model to perform filtering processing and obtain a candidate message pool;

[0073] S22: Using multimodal data, drive the prediction model to predict the click-through rate of the candidate message pool and obtain the predicted click-through rate value of the message;

[0074] S23: Determine the target message from the candidate message pool based on the predicted message click rate and multi-level scenario decision rules.

[0075] The aforementioned candidate message pool can be obtained by filtering a preset message set. The predicted click-through rate (CTR) value can be used to characterize the predicted probability that a user will click on each candidate message in the pool. The predicted CTR value can range from 0 to 1. It can be understood that the higher the predicted CTR value for a candidate message, the higher the probability that the user will click on each candidate message in the pool; that is, the higher the degree of matching between the candidate message and the user's current real-time application scenario.

[0076] The aforementioned multi-level scenario decision rule can refer to a hierarchical decision logic. The parameters of this multi-level scenario decision rule may include, but are not limited to: multi-level scenario prediction thresholds, push method weights, and additional conditions. This multi-level scenario decision rule can be used to determine target messages from a candidate message pool based on different driving scenarios.

[0077] In one exemplary application scenario, it is still as follows Figure 2As shown, the message decision model uses historical push messages determined after the last push decision to obtain user feedback data corresponding to the historical push messages, and uses this user feedback data to fine-tune the model parameters. By leveraging multimodal data and message features, a message decision model with fine-tuned parameters is driven to make push decisions and determine the target message corresponding to the push task. Specifically, multimodal data is used to characterize vehicle state features and user behavior features, while message features are used to characterize the content features and push method weights corresponding to the push task. User embedding vectors are constructed using vehicle state features and user behavior features, and message embedding vectors are constructed using the content features and push method weights corresponding to the push task. Furthermore, these user embedding vectors and message embedding vectors are used as input data for the message filtering model in the message decision model. The message filtering model predicts the relevance of a preset message set corresponding to the push task, obtaining the relevance between each preset message in the preset message set and the push task. Each preset message in the preset message set is sorted in descending order of relevance, and the top 20 preset messages in the preset message set are used as a candidate message pool. Thus, the message filtering model filters out 80% of the preset messages that are irrelevant to the push task.

[0078] Still within the aforementioned application scenario, before the message filtering model performs filtering, a three-level scenario segmentation can be determined based on multimodal data to identify the vehicle's current driving scenario information (e.g., the vehicle is parked, traveling at low speed, or traveling at high speed). Before the message filtering model performs filtering, feature engineering (including periodic analysis and geofencing analysis) can also be performed based on the multimodal data to obtain feature engineering results. Furthermore, during the message filtering process, the current driving scenario information and feature engineering results can be used as auxiliary information to improve the filtering accuracy of the message filtering model. It should be noted that periodic analysis in feature engineering can be implemented using Fourier transform, and the period of the Fourier transform can be automatically adjusted (for example, when the system detects a user's monthly consumption cycle, the Fourier transform period window can be adjusted from 7 days to 30 days). Geofencing analysis in feature engineering can be implemented using dynamic fence clustering algorithms. Dynamic fence clustering parameters (e.g., density threshold) can be adjusted in real time based on the distribution information of frequently visited locations to optimize the dynamic fence clustering parameters. Furthermore, the dynamic fence radius can be adjusted based on the type and distribution density of frequently visited locations. For example, when the frequently visited location type is urban, the dynamic fence radius can be adjusted to 500m; when the frequently visited location type is suburban, the dynamic fence radius can be adjusted to 1000m; when the distribution density of frequently visited locations is high, the dynamic fence radius can be adjusted to 300m. Understandably, a distribution density threshold can be set; when the distribution density of frequently visited locations is greater than or equal to the distribution density threshold, the distribution density of frequently visited locations can be considered high.

[0079] Continuing with the aforementioned application scenario, multimodal data is used to drive a prediction model to predict the click-through rate (CTR) of candidate messages, yielding predicted CTR values. Specifically, multimodal data can be used to determine a three-level scenario segmentation process, identifying the current driving scenario information corresponding to the vehicle. This information is then used to drive the prediction model to predict the CTR of candidate messages within the current driving scenario, resulting in predicted CTR values ​​for messages within that specific driving scenario. In particular, assuming the current driving scenario information for the vehicle has already been determined based on multimodal data before the message filtering model performs its filtering process, this already determined information can be used directly. Furthermore, a prediction threshold corresponding to the current driving scenario information is determined from a multi-level scenario prediction threshold set based on the current driving scenario information. When the predicted CTR value of any candidate message in the candidate message pool exceeds the prediction threshold corresponding to the current driving scenario information, that candidate message is identified as the target message.

[0080] It should be noted that in practical applications, if the predicted click-through rate of a candidate message exceeds the prediction threshold corresponding to the current driving scenario information, the candidate message can be directly pushed as the target message without processing the other candidate messages in the candidate message pool; alternatively, the predicted click-through rate of all candidate messages in the candidate message pool can be compared with the multi-level scenario decision rules, and all candidate messages in the candidate message pool that meet the preset conditions (e.g., the predicted click-through rate of the candidate message exceeds the prediction threshold corresponding to the current driving scenario information) can be used as the target message.

[0081] The above-mentioned optional embodiments of this application can achieve the following technical effects: by using a message filtering model to filter messages that are not highly relevant to the message push task, the candidate message pool can be obtained, which can reduce the processing load of the prediction model and improve the overall processing efficiency; furthermore, by using the prediction model to predict the click-through rate of the candidate message pool, the message click-through rate prediction value can be obtained, and combined with multi-level scenario decision rules, the target message can be accurately determined.

[0082] Optionally, the above vehicle message push method further includes the following steps:

[0083] S60: Update the initial interaction matrix corresponding to the message filtering model based on historical feedback data to obtain the target interaction matrix, wherein the elements contained in the target interaction matrix are used to reflect the user's preference for historical push messages.

[0084] S70: Use the target interaction matrix to fine-tune the model parameters of the message filtering model and update the message filtering model.

[0085] The aforementioned initial interaction matrix can refer to the mathematical structure used in a message filtering model to represent the preference relationship between users and historical push messages. This initial interaction matrix may include user feature data and message feature data, such as user identifiers, user feedback interaction weight data, and message identifiers. This initial interaction matrix can be pre-constructed based on historical data.

[0086] In an exemplary application scenario, historical feedback data (including user identifiers of those performing interactive operations, historical push message identifiers, and interaction types) is collected. This historical feedback data undergoes data cleaning (e.g., filtering interactions caused by accidental user touches). Based on user characteristic data and message characteristic data dimensions, the historical feedback data is added to an initial interaction matrix to obtain a target interaction matrix. This target interaction matrix is ​​then used to fine-tune the parameters of the message filtering model, updating the model. It can be understood that during vehicle development, an initial interaction matrix corresponding to the message filtering model can be constructed based on zero clicks or weak preferences. This initial interaction matrix is ​​then continuously updated based on historical feedback data, gradually forming a target interaction matrix reflecting user preferences, improving the accuracy and personalized push capabilities of the message filtering model. This matrix update mechanism ensures the online learning mechanism of the message filtering model.

[0087] The above-mentioned optional embodiments of this application can achieve the following technical effects: by updating the initial interaction matrix corresponding to the message filtering model according to historical feedback data, the target interaction matrix is ​​obtained, and the model parameters of the message filtering model are further fine-tuned using the target interaction matrix to update the message filtering model, thereby improving the message filtering accuracy of the message filtering model and enhancing the performance of the message filtering model.

[0088] Optionally, the multimodal data includes vehicle state data corresponding to vehicle state features. The vehicle state data includes the current road type and vehicle speed. The above vehicle message push method also includes the following steps:

[0089] S80: Call the map interface to obtain the road speed limit data corresponding to the current road type from the map data in real time;

[0090] S90: Adjust the initial driving speed threshold based on the current road type and road speed limit data to obtain the target driving speed threshold;

[0091] S91: Compare the vehicle's speed with the target speed threshold to determine the current driving scenario information corresponding to the vehicle;

[0092] S92: Based on the current driving scenario information, adjust the initial multimodal feature weights corresponding to the prediction model to obtain the target multimodal feature weights;

[0093] S93: Use the target multimodal feature weights and historical feedback data to fine-tune the model parameters of the prediction model and update the prediction model.

[0094] The aforementioned map interface refers to the communication channel connecting the system and the online map service platform. Through this map interface, the system can obtain data related to the vehicle's current location (i.e., map data) from the online map service platform in real time. This map data may include, but is not limited to: road type (e.g., urban roads, highways, rural roads), road speed limits, and information about buildings around the vehicle (e.g., gas stations, charging stations). It is understood that legal speed limits differ for different road types. Therefore, by calling the map interface, the current road type can be determined from the map data based on the vehicle's current location. Furthermore, based on the current road type and the vehicle's current location, the corresponding road speed limit data can be obtained from the map data in real time.

[0095] The aforementioned initial driving speed threshold can be preset. This initial driving speed threshold can refer to a standard speed limit used to distinguish different driving scenarios (e.g., normal parking scenario, low-speed driving scenario, high-speed driving scenario, etc.). For example, when a vehicle is driving on congested roads or urban roads, it is more likely to be in a low-speed driving scenario; when a vehicle is on an expressway or highway, it is more likely to be in a high-speed driving scenario. This initial driving speed threshold may include, but is not limited to: speed threshold for normal parking scenario, speed threshold for low-speed driving scenario, and speed threshold for high-speed driving scenario. It is understood that, based on the current road type and road speed limit data, the initial driving speed threshold can be dynamically adjusted to obtain a more accurate target driving speed threshold, thereby determining more accurate current driving scenario information. The aforementioned current driving scenario information can be used to characterize the driving scenario in which the vehicle is currently located.

[0096] In an exemplary application scenario, the aforementioned target driving speed threshold may include a speed threshold for a normal parking scenario (e.g., 0 km / h) and a speed threshold for a low-speed driving scenario (e.g., 15 km / h). Further, the vehicle's speed is compared with the target driving speed threshold. If the vehicle's speed is less than or equal to the low-speed driving scenario speed threshold and greater than the normal parking scenario speed threshold, the vehicle is considered to be in a low-speed driving scenario, and the corresponding current driving scenario information is determined as such. If the vehicle's speed is greater than the low-speed driving scenario speed threshold, the vehicle is considered to be in a high-speed driving scenario, and the corresponding current driving scenario information is determined as such.

[0097] Still within the aforementioned application scenario, specifically, when the vehicle's driving speed equals the speed threshold for a normal parking scenario, further information is obtained regarding the vehicle's gear position, acceleration, and the duration for which the vehicle's driving speed equals the speed threshold for a normal parking scenario. When the vehicle's gear position is in parking gear (i.e., P gear) and the acceleration is less than or equal to the acceleration threshold (e.g., 0.1 m / s²), further information is obtained.2 If the vehicle's speed is equal to the speed threshold for a normal parking scenario for an extended period (e.g., 15 minutes), the system further determines whether this duration exceeds the parking time threshold. If the duration exceeds the threshold, the vehicle is considered to be in a deep parking scenario, and the current driving scenario information is confirmed as such. If the duration does not exceed the threshold, the vehicle is considered to be in a normal parking scenario, and the current driving scenario information is confirmed as such. In some applications, the scenario switching logic for the current driving scenario information can be optimized. For example, when the system detects a vehicle entering a parking lot, the current driving scenario information can be switched from a low-speed driving scenario to a normal parking scenario.

[0098] It should be noted that the speed threshold, acceleration threshold, and parking time threshold for the aforementioned low-speed driving scenario can all be adjusted according to actual application. For example, if the current road type is a highway, after adjusting the initial driving speed threshold based on the current road type and road speed limit data, the speed threshold for the aforementioned low-speed driving scenario can be 30 km / h. If the current road type is an urban road, after adjusting the initial driving speed threshold based on the current road type and road speed limit data, the speed threshold for the aforementioned low-speed driving scenario can be 15 km / h. As another example, the parking time threshold can be adjusted based on the user's historical parking habit data. For instance, if the user's average commuting parking time is determined to be 10 minutes based on historical parking habit data, the parking time threshold can be adjusted to 10 minutes.

[0099] The aforementioned initial multimodal feature weights refer to the relative importance of different types of data in the multimodal data when calculating the predicted click-through rate (CTR) value during the click-through rate prediction process of the prediction model. These initial multimodal feature weights can be dynamically adjusted based on the current driving scenario information. For example, when the vehicle is in a normal parking scenario, the weights of data related to the area of ​​interest and time periods can be increased; similarly, when the vehicle is in a low-speed driving scenario, the weights of navigation destination data and road congestion index can be increased. In one application scenario, after obtaining the target multimodal feature weights, the attention mechanism weights of the prediction model can be adjusted based on historical feedback data. For example, when the vehicle is driving in rainy weather, the feature association between "weather-car wash service" in the attention mechanism weights can be enhanced. Understandably, after adjusting the initial multimodal feature weights corresponding to the prediction model based on the current driving scenario information, a target multimodal feature weight that is more adapted to the current application scenario can be obtained. Furthermore, by using the target multimodal feature weights and historical feedback data to fine-tune the model parameters and update the prediction model, the dynamic adaptability of the prediction model to the real-time application scenario can be enhanced, thereby improving the performance of the prediction model in predicting click-through rates.

[0100] The above-mentioned optional embodiments of this application can achieve the following technical effects: Based on the current road type and road speed limit data, the initial driving speed threshold can be dynamically adjusted to obtain a more accurate target driving speed threshold and determine more accurate current driving scenario information; furthermore, based on the current driving scenario information, the initial multimodal feature weights corresponding to the prediction model can be adjusted to obtain target multimodal feature weights with better dynamic adaptability. By using the target multimodal feature weights and historical feedback data to fine-tune the model parameters of the prediction model and update the prediction model, the dynamic adaptability of the prediction model to real-time application scenarios can be enhanced, thereby improving the click-through rate prediction performance of the prediction model.

[0101] Optionally, the candidate message pool includes multiple candidate messages, and the multi-level scenario decision rules include multi-level scenario prediction thresholds and additional conditions. The multi-level scenario prediction thresholds are obtained by correcting historical feedback data. In step S23 above, determining the target message from the candidate message pool based on the message click-through rate prediction value and the multi-level scenario decision rules includes the following steps:

[0102] S231: Traverse the candidate messages in the candidate message pool that meet the additional conditions;

[0103] S232: Compare and analyze the predicted click-through rate of the message corresponding to the candidate message with the current scenario prediction threshold to obtain the comparison result. The candidate message is the candidate message currently being compared and analyzed during the traversal. The current scenario prediction threshold is determined from the multi-level scenario prediction threshold based on the current driving scenario information. The comparison result is used to determine whether the candidate message needs to be pushed.

[0104] S233: In response to the need to push candidate messages in response to the comparison result representation, the candidate message is determined as the target message.

[0105] The aforementioned multi-level scenario prediction threshold refers to the prediction threshold set for multi-level scenarios in the multi-level scenario decision rules. This multi-level scenario prediction threshold can be used to determine whether the predicted click-through rate of a message is sufficient to trigger the expected push notification under different driving scenarios. For example, the aforementioned multi-level scenario prediction threshold may include, but is not limited to: threshold for ordinary parking scenarios, threshold for deep parking scenarios, threshold for low-speed driving scenarios, and threshold for high-speed driving scenarios.

[0106] The above additional conditions can be used to help identify the target message. These additional conditions may include, but are not limited to: time period restrictions (e.g., do-not-disturb periods), message urgency level (e.g., emergency security level, non-security level), and destination relevance.

[0107] In one exemplary application scenario, it is still as follows Figure 2 As shown, based on the current driving scenario information (which can be determined by referring to the description above), additional conditions corresponding to the current driving scenario information are determined from the multi-level scenario prediction thresholds. It is then determined whether each candidate message in the candidate message pool meets the additional condition. For example, when the vehicle is in a deep parking scenario, the additional condition can be "allow push notifications during non-do-disturb periods (22:00-7:00)". In this case, it is necessary to obtain the current time to determine whether each candidate message in the candidate message pool meets the additional condition. Another example is when the vehicle is in a low-speed driving scenario, the above additional condition can be "prioritize push notifications related to the destination during navigation". Yet another example is when the vehicle is in a high-speed driving scenario, the above additional condition can be "block non-safety level messages". Therefore, it is possible to identify candidate messages in the candidate message pool that meet the additional conditions. Furthermore, the above-mentioned multi-level scenario prediction thresholds may include: a deep parking scenario threshold (e.g., 0.6) and a low-speed driving scenario threshold (e.g., 0.8). The candidate messages in the candidate message pool that meet the additional conditions are traversed, and the candidate message currently being compared and analyzed during the traversal is determined as the candidate message. The current scenario prediction threshold is determined from the multi-level scenario prediction thresholds based on the current driving scenario information.

[0108] Continuing with the aforementioned application scenario, the predicted click-through rate (CTR) of the candidate messages is denoted as CTR. For example, assuming the current driving scenario information indicates the vehicle is in a deep parking situation, the current scenario prediction threshold (i.e., deep parking scenario threshold 0.6) is determined from the multi-level scenario prediction thresholds based on the current driving scenario information. The predicted CTR of the candidate messages is compared with the current scenario prediction threshold. If the predicted CTR of the candidate messages is greater than or equal to 0.6, the comparison result indicates that the candidate messages need to be pushed. In another example, assuming the current driving scenario information indicates the vehicle is in a low-speed driving situation, the current scenario prediction threshold (i.e., low-speed driving scenario threshold 0.8) is determined from the multi-level scenario prediction thresholds based on the current driving scenario information. The predicted CTR of the candidate messages is compared with the current scenario prediction threshold. If the predicted CTR of the candidate messages is greater than or equal to 0.8, the comparison result indicates that the candidate messages need to be pushed. It should be noted that the threshold values ​​for the deep parking scenario and the low-speed driving scenario mentioned above can be adjusted based on historical feedback data. For example, the threshold value for the deep parking scenario can range from 0.4 to 0.8. The user click-through rate of system-pushed messages in the deep parking scenario can be determined based on historical feedback data, and the threshold can be adjusted every 10 minutes based on this user click-through rate, with an adjustment increment of 0.05. It can be understood that the adjusted deep parking scenario threshold must meet the specified range. Furthermore, the deep parking scenario threshold can also be combined with user click-through rates over multiple days, such as the click-through rates over three consecutive days. If the click-through rates for these multiple days are all greater than the industry average, the deep parking scenario threshold can be adjusted to 0.5. Similarly, for the low-speed driving scenario threshold, if historical feedback data determines that the user close rate of system-pushed messages in the low-speed driving scenario is greater than the close rate threshold (e.g., 40%), the low-speed driving scenario threshold can be increased to 0.9.

[0109] Continuing with the aforementioned application scenario, when the predicted click-through rate of the candidate message is less than the current scenario's prediction threshold, or when the vehicle is traveling at high speed and the candidate message is not an emergency safety-level candidate message, the comparison result is determined to postpone pushing the candidate message. Furthermore, the message push task can be cached, and real-time data changes can be monitored. Information related to the message push task can be recorded, and the message push conditions can be checked periodically to determine whether the candidate message meets the push conditions. If the candidate message meets the push conditions during the periodic check, it is designated as the target message. If the candidate message does not meet the push conditions, the check will wait for the next check cycle. It is understandable that when the vehicle is traveling at high speed, pushing messages would interfere with the driver; therefore, only emergency safety-level candidate messages (e.g., fault warnings) are pushed.

[0110] The above-mentioned optional embodiments of this application can achieve the following technical effects: by using additional conditions to perform preliminary screening of candidate conditions in the candidate message pool, the number of traversals can be reduced, and the overall efficiency of the vehicle message push method can be improved; furthermore, based on the current driving scenario information, the current scenario prediction threshold is determined from the multi-level scenario prediction threshold, and the candidate messages currently being compared and analyzed during the traversal are taken as candidate messages. The message click rate prediction value corresponding to the candidate message is compared and analyzed with the current scenario prediction threshold. The current scenario prediction threshold can be corrected in real time according to the current driving scenario information, thereby obtaining a more accurate comparison result and more accurately determining the target message.

[0111] Optionally, message features are also used to characterize the push method weight, and the above vehicle message push method further includes the following steps:

[0112] S94: Update the push method weight based on historical feedback data, historical push methods corresponding to historical push messages, push method weight thresholds, and weight adjustment ratios;

[0113] S95: Based on multimodal data and push method weights, determine the target push method corresponding to the target message from a variety of candidate push methods;

[0114] S96: Push the target message to the user terminal according to the target push method.

[0115] The aforementioned historical push notification methods may include, but are not limited to: pop-up push notifications, banner push notifications, and notification center push notifications. The weights for these push notification methods may include, but are not limited to: pop-up push notification weights, banner push notification weights, and notification center push notification weights. The weight thresholds for these push notification methods may include a lower weight limit and a higher weight limit. The weight adjustment ratios may include weight decay ratios and weight increase ratios. The aforementioned candidate push notification methods can be referenced from the historical push notification methods mentioned above, and will not be elaborated upon here.

[0116] In an exemplary application scenario, the aforementioned weight adjustment ratio includes a weight decay ratio (e.g., 20%) and a weight increase ratio (e.g., 10%), the aforementioned push method weight threshold includes a weight lower limit (e.g., 0.2) and a weight upper limit (e.g., 1.2), and the aforementioned push method weight can include pop-up push weight (e.g., 1.0) and notification center push weight (e.g., 0.4). The specific process for updating the push method weight based on historical feedback data, the historical push methods corresponding to historical push messages, the push method weight threshold, and the weight adjustment ratio can be as follows: When the historical push method corresponding to a historical push message is a pop-up push, when the system determines, based on historical feedback data, that the user's interaction operation with respect to the historical push message is a close operation, the target pop-up weight is calculated based on the weight decay ratio and the pop-up push weight. Further, it is determined whether the target pop-up weight is greater than the weight lower limit. If the target pop-up weight is greater than the weight lower limit, the pop-up push weight is updated using the target pop-up weight; if the target pop-up weight is less than or equal to the weight lower limit, the pop-up push weight is updated using the weight lower limit.

[0117] Continuing in the aforementioned application scenarios, when the historical push notification method for the historical push message was a pop-up push, if the system determines from historical feedback data that the user's interaction with the historical push message was a click, then the target pop-up weight is calculated based on the weight increase ratio and the pop-up push weight. Further, it is determined whether the target pop-up weight is greater than the weight cap. If the target pop-up weight is greater than the weight cap, the pop-up push weight is updated using the weight cap; if the target pop-up weight is less than or equal to the weight cap, the pop-up push weight is updated using the target pop-up weight. When the historical push notification method for the historical push message was a notification center push, if the system determines from historical feedback data that the user's interaction with the historical push message was a click, and the user clicks three times consecutively on a message pushed via the notification center push method, then the average value of the notification center push method is considered greater than the average value of similar methods. In this case, the notification center push weight can be adjusted to 0.6. In some application scenarios, the notification center push weight can also be adjusted as follows: for each click by the user on a message pushed via the notification center method, the notification center push weight is increased by 5%.

[0118] Still in the above application scenarios, still as Figure 2 As shown, after updating the push method weights, the current driving scenario information can be determined based on multimodal data. Further, based on the current driving scenario information, several candidate push methods corresponding to the current driving scenario are determined. For example, for a deep parking scenario, candidate push methods may include pop-up push, banner push, and notification center push. In this scenario, the weights of pop-up push, banner push, and notification center push can be set to 1.0, 0.7, and 0.4 respectively. For a low-speed driving scenario, candidate push methods may include banner push and notification center push. In this scenario, the weights of banner push and notification center push can be set to 0.7 and 0.4 respectively. Further, based on the multimodal data and push method weights, the target push method corresponding to the target message is determined from the multiple candidate push methods. Specifically, in determining the target push method, the task requirements and task type of the message push task can also be used as auxiliary information. After determining the target push method, the target message is pushed to the user terminal according to the target push method.

[0119] The above-mentioned optional embodiments of this application can achieve the following technical effects: based on historical feedback data, historical push methods corresponding to historical push messages, push method weight thresholds and weight adjustment ratios, the push method weights can be dynamically updated, making the dynamic adaptability of push method weights better, thereby enabling the target message to be pushed to the user terminal according to the push method preferred by the user, thus enhancing the user experience.

[0120] In one optional application scenario, after pushing the target message to the user, the target feedback data corresponding to the target message is obtained. Furthermore, this target feedback data is used to update the policy parameters (including the parameters of the reinforcement learning algorithm and the model parameters of the message decision model), thereby ensuring that the updated policy parameters can be used to complete the vehicle message push in the next process. A reinforcement learning algorithm is used to fine-tune the model parameters using historical feedback data to obtain the message decision model. This reinforcement learning algorithm can be the Proximal Policy Optimization (PPO) algorithm. The parameters of the reinforcement learning algorithm include greedy policy parameters (e.g., ε-Greedy exploration rate) and a reward function decay factor (i.e., delayed reward discount). The default value for the ε-Greedy exploration rate can be set to 10%, and the default value for the reward function decay factor can be set to 0.95. When the ε-Greedy exploration rate is 10%, the optimal strategy is used 90% of the time, and new push combinations are randomly tested in 10% of the time. By adjusting the ε-Greedy exploration rate, the diversity of strategies and the utilization rate of the optimal strategy can be balanced. When the predicted click-through rate (CTR) of a message output by the predictive model in the message decision-making model continues to decline, the ε-Greedy exploration rate can be adjusted to 15% to enhance strategy diversity. When the user feedback frequency is greater than the feedback frequency threshold, it can be considered a high-frequency feedback frequency, and the reward function decay factor can be adjusted to 0.9. When the user feedback frequency is less than or equal to the feedback frequency threshold, it can be considered a low-frequency feedback frequency, and the reward function decay factor can be adjusted to 0.8. Specifically, when the predicted CTR of the target message is greater than 80% and the user's interaction with the target message is a close operation, the historical push messages output by the message decision-making model after the last push decision are evaluated. If the predicted CTR of the historical push messages is greater than 80% and the user's interaction with the historical push messages is a close operation, the predicted CTR of the message output by the predictive model can be considered to be continuously declining. In practical applications, the target feedback data can be processed and the policy parameters updated according to the reinforcement learning algorithm update cycle (e.g., 10 minutes) through the stream processing function (e.g., Flink stream function) in an open-source distributed processing framework (e.g., Apache Flink framework).

[0121] This application also provides a vehicle message push device 300, please refer to... Figure 3The system includes: an acquisition module 310, used to acquire multimodal data and message features corresponding to the message push task, wherein the multimodal data is used to characterize at least vehicle state features and user behavior features, and the message features are used to characterize at least the message content features of the message push task; a decision module 320, used to drive a message decision model to make push decisions using the multimodal data and message features, and determine the target message corresponding to the message push task, wherein the message decision model is obtained by fine-tuning the model parameters using historical feedback data, and the historical feedback data is user feedback data corresponding to historical push messages, and the historical push messages are determined by the message decision model after the last push decision is executed; and a push module 330, used to push the target message to the user terminal.

[0122] The vehicle message push device provided in this application embodiment achieves the following technical effects: Using the acquisition module 310, by acquiring multimodal data and message features corresponding to the message push task, more comprehensive information can be provided to the message decision model, especially information combined with the real-time application scenario of the vehicle, laying a data foundation for the subsequent driving of the message decision model to make push decisions; further, using the decision module 320, historical push messages are determined based on the last push decision executed by the message decision model, and the user feedback data corresponding to the historical push messages is used as historical feedback data. The model parameters are fine-tuned using this historical feedback data to obtain the message decision model. Through the above-mentioned mechanism for updating the model parameters of the message decision model, a closed-loop online learning process for the message decision model is formed. The message decision model can better adapt to dynamic scene changes, thereby using multimodal data and message features to determine target messages with better dynamic adaptability, improving the push decision performance of the message decision model; further, using the push module 330, the target message is pushed to the user terminal, enhancing the user experience, thereby enhancing the dynamic adaptability of the target messages pushed by the vehicle message push device and improving the performance of the vehicle message push device.

[0123] This application also provides a vehicle 400, please refer to... Figure 4 It includes an on-board memory 410 and an on-board processor 420, wherein the on-board memory 410 is used to store computer programs; and the on-board processor 420 is used to execute the computer programs stored in the memory to implement the vehicle message push method of any embodiment.

[0124] The vehicle provided in this application embodiment achieves the following technical effects: By acquiring multimodal data and message features corresponding to the message push task, it can provide more comprehensive information for the message decision model, especially by combining information from the vehicle's real-time application scenario, laying a data foundation for the subsequent push decision-making of the message decision model; further, based on the message decision model's previous push decision, historical push messages are determined, and the user feedback data corresponding to these historical push messages is used as historical feedback data. The model parameters are then fine-tuned using this historical feedback data to obtain the message decision model. Through the above-mentioned mechanism for updating the model parameters of the message decision model, a closed-loop online learning process for the message decision model is formed. The message decision model can better adapt to dynamic scene changes, thereby using multimodal data and message features to determine target messages with better dynamic adaptability, improving the push decision performance of the message decision model; furthermore, pushing the target message to the user enhances the user's satisfaction with the overall performance of the vehicle.

[0125] Those skilled in the art will understand that, similarly, the aforementioned vehicle can also be a computing terminal. Figure 5 This is a hardware structure block diagram of a computing terminal used to implement a vehicle message push method according to an embodiment of this application, such as... Figure 5 As shown, the computing terminal 500 (e.g., computer terminal, mobile smart terminal, vehicle terminal, or cloud computing virtual terminal, etc.) may include: one or more processors 502 (e.g., processors 502a, 502b, ..., 502n), a memory 508 for storing data, and a transmission device 506 for implementing communication functions. The processor 502 may include, but is not limited to, processing components such as microprocessors (MCUs) or field-programmable gate arrays (FPGAs).

[0126] The aforementioned computing terminal 500 may further include: a display, an input / output interface, a Universal Serial Bus (USB) port (which can be used as one of the ports of a computer bus, not shown in the figure), a network interface (not shown in the figure), a power supply (not shown in the figure), and a camera (not shown in the figure).

[0127] It should be noted that one or more processors 502 and / or other data processing circuits in the aforementioned computing terminal 500 may be wholly or partially embodied in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuitry may be a single, independent processing module, or may be wholly or partially integrated into any other element in the computing terminal 500 (or mobile device).

[0128] The memory 508 can be used to store software programs and modules of application software, such as the program instructions and data storage devices corresponding to the vehicle message push method in this embodiment. The processor 502 executes various functional applications and data processing by running the software programs and modules stored in the memory 508, thereby realizing the aforementioned vehicle message push method. The memory 508 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 508 may further include memory remotely located relative to the processor 502, and these remote memories can be connected to the vehicle terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0129] The transmission device 506 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the vehicle terminal's communication provider. In one example, the transmission device 506 includes a Network Interface Controller (NIC) and a network interface, which can be connected to other network devices via a base station to communicate with the Internet. The transmission device 506 can use wired and / or wireless network connections for data communication. In one example, the transmission device 506 can be a Radio Frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0130] The input / output interface can be connected to the corresponding input / output device of the computing terminal 500 to realize input / output functions. This input / output device may include, but is not limited to, a cursor control device, a keyboard, and a display. The aforementioned input / output device may be built into the computing terminal 500 or an external device connected to the computing terminal 500.

[0131] Those skilled in the art will understand that Figure 5 The structure of the computing terminal 500 shown is for illustrative purposes only and does not impose strict limitations on the structure of the computing terminal 500 described above. For example, the computing terminal 500 may also include components such as... Figure 5 The more or fewer components shown, or the computing terminal 500 may have the same Figure 5 The components are shown in different categories.

[0132] This application also provides an electronic device 600, please refer to... Figure 6It includes a memory 610 and a processor 620, wherein the memory 610 is used to store computer programs; and the processor 620 is used to execute the programs stored in the memory 610 to implement the vehicle message push method described in any embodiment of this application.

[0133] Those skilled in the art will understand that Figure 6 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones (such as Android phones, iOS phones, etc.), tablets, PDAs, and mobile internet devices (MIDs) and other terminal devices. Figure 6 This does not limit the structure of the aforementioned electronic device. For example, electronic device 600 may also include components that are more... Figure 6 The more or fewer components shown (e.g., network interface, display device, etc.), or having the same Figure 6 The different configurations shown.

[0134] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the vehicle message push method described in any embodiment of this application.

[0135] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0136] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0137] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0138] In this application, "multiple" refers to two or more.

[0139] In this application, unless otherwise expressly defined, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0140] The terms “first,” “second,” “third,” “fourth,” etc., in this application (if present) are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0141] In this application, the term "and / or" is merely a description of 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. Additionally, in this application, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0142] Unless otherwise specified, all steps in this application may be performed sequentially or randomly. For example, if the method includes steps A and B, it means that the method may include steps A and B performed sequentially, or it may include steps B and A performed sequentially. For example, if the method may also include step C, it means that step C may be added to the method in any order. For example, the method may include steps A, B, and C, or it may include steps A, C, and B, or it may include steps C, A, and B, etc.

[0143] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A vehicle message push method, characterized in that, include: Obtain multimodal data and message features corresponding to the message push task, wherein the multimodal data is used to characterize at least vehicle status features and user behavior features, and the message features are used to characterize at least the message content features of the message push task; Using the multimodal data and the message features, a message decision model is driven to make push decisions and determine the target message corresponding to the message push task. The message decision model is obtained by fine-tuning the model parameters using historical feedback data, which is user feedback data corresponding to historical push messages. The historical push messages are determined by the message decision model after the last push decision is made. The target message is pushed to the user's device.

2. The vehicle message push method according to claim 1, characterized in that, The vehicle message push method also includes: Obtain target feedback data corresponding to the target message, wherein the target feedback data is generated based on the interactive operation performed on the target message; Using the target feedback data, the model parameters of the message decision model are fine-tuned, and the message decision model is updated.

3. The vehicle message push method according to claim 1, characterized in that, The multimodal data obtained for the message push task includes: Obtain the task type and vehicle location data corresponding to the message push task; Based on the task type and the location data, a scenario analysis is performed to obtain a scenario analysis result, wherein the scenario analysis result is used to determine whether the vehicle is in the task-related scenario corresponding to the vehicle message; The data collection range is determined based on the task type, and the data collection frequency is determined based on the scenario analysis results; The multimodal data within the data acquisition range is collected according to the data acquisition frequency.

4. The vehicle message push method according to claim 1, characterized in that, The message decision model includes a message filtering model, a prediction model, and multi-level scenario decision rules. It utilizes the multimodal data and message features to drive the message decision model to make push decisions, determining the target message corresponding to the message push task, including: Using the multimodal data and the message features, the message filtering model is driven to perform filtering processing to obtain a candidate message pool; Using the multimodal data, the prediction model is driven to predict the click-through rate of the candidate message pool, thereby obtaining the predicted click-through rate value of the message; The target message is determined from the candidate message pool based on the predicted message click-through rate and the multi-level scenario decision rules.

5. The vehicle message push method according to claim 4, characterized in that, The vehicle message push method also includes: The initial interaction matrix corresponding to the message filtering model is updated based on the historical feedback data to obtain the target interaction matrix, wherein the elements contained in the target interaction matrix are used to reflect the user's preference for the historical push messages. The message filtering model is fine-tuned using the target interaction matrix, and the message filtering model is updated.

6. The vehicle message push method according to claim 4, characterized in that, The multimodal data includes vehicle state data corresponding to the vehicle state features, and the vehicle state data includes the current road type and vehicle speed. The vehicle message push method further includes: Call the map interface to obtain the road speed limit data corresponding to the current road type from the map data in real time; Based on the current road type and the road speed limit data, the initial driving speed threshold is adjusted to obtain the target driving speed threshold; The vehicle's speed is compared with the target speed threshold to determine the current driving scenario information corresponding to the vehicle. Based on the current driving scenario information, the initial multimodal feature weights corresponding to the prediction model are adjusted to obtain the target multimodal feature weights; The prediction model is updated by fine-tuning its parameters using the target multimodal feature weights and the historical feedback data.

7. The vehicle message push method according to claim 6, characterized in that, The candidate message pool includes multiple candidate messages, and the multi-level scenario decision rule includes a multi-level scenario prediction threshold and additional conditions. The multi-level scenario prediction threshold is obtained by correcting the historical feedback data. Based on the predicted message click-through rate and the multi-level scenario decision rules, the target message is determined from the candidate message pool as follows: The candidate messages in the candidate message pool that meet the additional conditions are traversed. The predicted click-through rate of the candidate message is compared and analyzed with the current scenario prediction threshold to obtain the comparison result. The candidate message is the candidate message currently being compared and analyzed during the traversal. The current scenario prediction threshold is determined from the multi-level scenario prediction threshold based on the current driving scenario information. The comparison result is used to determine whether the candidate message needs to be pushed. In response to the comparison result indicating the need to push the candidate message, the candidate message is determined as the target message.

8. The vehicle message push method according to any one of claims 1 to 7, characterized in that, The message features are also used to characterize the push method weight, and the vehicle message push method further includes: The push method weight is updated based on the historical feedback data, the historical push method corresponding to the historical push message, the push method weight threshold, and the weight adjustment ratio. Based on the multimodal data and the push method weights, the target push method corresponding to the target message is determined from a variety of candidate push methods; The target message is pushed to the user terminal according to the target push method.

9. A vehicle message push device, characterized in that, include: The acquisition module is used to acquire multimodal data and message features corresponding to the message push task, wherein the multimodal data is used to characterize at least vehicle status features and user behavior features, and the message features are used to characterize at least the message content features of the message push task; The decision module is used to drive the message decision model to make push decisions using the multimodal data and the message features, and to determine the target message corresponding to the message push task. The message decision model is obtained by fine-tuning the model parameters using historical feedback data. The historical feedback data is user feedback data corresponding to historical push messages. The historical push messages are determined by the message decision model after the last push decision is executed. The push module is used to push the target message to the user terminal.

10. A vehicle, characterized in that, Including on-board storage and on-board processor, among which, Onboard storage is used to store computer programs; An on-board processor is used to execute a computer program stored in a memory to implement the method described in any one of claims 1 to 8.

Images