A method for customizing personalized script tasks for real-time dynamic tourism scenarios

Abstract

This invention relates to the field of smart tourism service data processing technology, specifically a method for customizing personalized script tasks for real-time dynamic tourism scenarios. The method includes the following steps: generating a scene feature set by frequently collecting regional activity and user location information through a GIS interface; constructing a user preference model by deeply analyzing historical user behavior using a collaborative filtering algorithm; generating large-scale model prompts and producing script tasks by combining scene features and preference weights; filtering suitable tasks after verifying the matching degree between the tasks and the real-time scene; converting the tasks into a mobile terminal visual format and pushing them to users; and collecting user feedback data to iteratively optimize model weights. This invention solves the technical problem of traditional static template customization methods failing to adapt to dynamic scene changes and lacking personalized experiences through the synergistic effect of real-time dynamic scene perception and user preference modeling. It improves the accuracy of task-scene matching, enhances user immersion, and increases service satisfaction.

Description

Technical Field

[0001] This invention relates to the field of smart tourism service data processing technology, and in particular to a method for customizing personalized script tasks for real-time dynamic tourism scenarios. Background Technology

[0002] Tourism smart service data processing refers to various technical means of collecting, analyzing, and applying geospatial data, user behavior data, and service resource data during the tourism process using modern information technology. The aim is to improve the tourism experience and management efficiency through digitalization. Traditional tourism task customization technology refers to a static processing model where operators manually modify task content based on fixed scenic area templates to suit specific user needs. This relies on manual experience for mechanical adjustments to template content and typically involves basic text editing tools and static database queries.

[0003] Existing technologies have significant shortcomings in actual operation. First, due to the lack of automatic perception of real-time data, the generated tasks cannot respond to dynamic changes such as the activation of regional activities or changes in user location, resulting in customized content being out of touch with the current game scenario. The method of using a uniform template for patching cannot deeply explore users' personalized interests, resulting in homogenized generated tasks. Due to the high dependence on manual intervention, the efficiency of single task customization is low, making it difficult to meet the real-time customization needs of a large number of users during peak tourist seasons. Summary of the Invention

[0004] To address the technical problems existing in the prior art, embodiments of the present invention provide a method for customizing personalized script tasks for real-time dynamic tourism scenarios, comprising the following steps:

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a method for customizing personalized script tasks for real-time dynamic tourism scenarios, comprising the following steps:

[0006] S1: Call the GIS interface to collect real-time data of the tourism scene. The real-time data includes regional activity information, user real-time location coordinates and scene status information, and parse the real-time data to obtain a scene feature set.

[0007] S2: Obtain the user's historical behavior data, construct a user preference model using a collaborative filtering algorithm, and output the corresponding preference weight vector from the user preference model;

[0008] S3: Generate input prompts for a large model based on the scene feature set and the preference weight vector, and input the input prompts into a preset tourism vertical large model to generate initial script task content;

[0009] S4: Calculate the matching degree value between the initial script task content and the real-time data, and determine whether the matching degree value is greater than the preset matching threshold. If so, mark the initial script task content as an adapted task.

[0010] S5: Convert the content of the adaptation task into a mobile terminal-compatible format and send it to the user terminal through the push service channel;

[0011] S6: Collect user feedback data on the adaptation task, and adjust the weight parameters of the user preference model based on the feedback data to complete the model iteration.

[0012] As a further aspect of the present invention, the step S1 of calling the GIS interface to collect real-time data of the tourism scene specifically includes:

[0013] The sampling frequency is configured to 1Hz to read data through the GIS interface, wherein the acquisition accuracy of the user's real-time location coordinates is within ±5 meters, and the scene status information includes regional pedestrian flow level data;

[0014] The process of parsing real-time data to obtain a scene feature set specifically includes:

[0015] The collected real-time data is converted into structured data in JSON format, and the name of the business district where the user is currently located, the current status of promotional activities, and the real-time pedestrian flow level are extracted to form the scene feature set.

[0016] As a further aspect of the present invention, the construction of the user preference model in S2 specifically includes:

[0017] Feature extraction is performed on the interest tags, playtime, and task type preferences in the historical behavior data. The interest tags include food tags and shopping tags.

[0018] The collaborative filtering algorithm is used to calculate the user's interest weights in different dimensions, generating the preference weight vector that includes food weight values ​​and shopping weight values.

[0019] As a further aspect of the present invention, S3 specifically includes:

[0020] The input prompts are constructed in the format of "Based on real-time scenario: {scenario feature set}, user preferences: {preference weight vector}, generate personalized tourism script tasks";

[0021] The input prompts are analyzed using the tourism vertical big model to generate the initial script task content, which includes a description of the task objective, scene-related links, and 5 to 8 interactive nodes.

[0022] As a further aspect of the present invention, S4 specifically includes:

[0023] Analyze the consistency between the activity elements involved in the initial script task content and the current area activities in the scene feature set, and calculate the matching degree value between 0 and 100.

[0024] The preset matching threshold is set to 80 points. If the matching score is less than 80 points, the task generation step of the tourism vertical big model is triggered to be re-executed.

[0025] As a further aspect of the present invention, S5 specifically includes:

[0026] The content of the adaptation task is encapsulated into a combined format that includes text descriptions, map marker data, and interactive button instructions;

[0027] The combined data packets are pushed to the user's terminal through a third-party push service channel, and the arrival receipt of the push message is verified.

[0028] As a further aspect of the present invention, S6 specifically includes:

[0029] Collect feedback data, which includes task completion status, task abandonment status, and satisfaction ratings from 1 to 5 stars.

[0030] If a user completes a specific type of task, the weight value corresponding to that type will be increased in the user preference model;

[0031] The model update cycle is set to perform an iterative calculation once every 10 pieces of feedback data collected.

[0032] As a further aspect of the present invention, the tourism vertical big model is a generative artificial intelligence model fine-tuned by data from the cultural and tourism field, and the tourism vertical big model is configured to process the input scene feature set using an attention mechanism.

[0033] As a further aspect of the present invention, S1 also includes offline caching of the collected real-time data, with the retention period of the cached data set to 2 hours.

[0034] As a further aspect of the present invention, after adjusting the weight parameters of the user preference model in step S6, the method further includes:

[0035] New script tasks are generated using the updated user preference model, and new matching scores are calculated to verify the effectiveness of the model update.

[0036] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0037] This invention achieves intelligent and precise script task generation by constructing a closed-loop system of real-time dynamic scene perception and user preference modeling. First, by collecting and analyzing scene data in real time, it ensures a high degree of consistency between task content and the current spatiotemporal environment, improving the matching degree between tasks and scenes and effectively solving the problem of task-scene disconnect in traditional technologies. Second, a personalized preference model built based on a collaborative filtering algorithm enables deep customization of "one person, one task," enhancing the personalized matching capability of tasks. The use of large-scale automated model generation technology to replace manual editing significantly shortens the customization time for a single task. Through a feedback iteration mechanism, the model weights are continuously optimized, gradually improving user immersion and service satisfaction. Attached Figure Description

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

[0039] Figure 1 This is a schematic diagram of the steps of the present invention. Detailed Implementation

[0040] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0041] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0042] Please see Figure 1 This invention provides a technical solution, a method for customizing personalized script tasks for real-time dynamic tourism scenarios, comprising the following steps:

[0043] S1: Call the GIS interface to collect real-time data of the tourism scene. The real-time data includes regional activity information, user real-time location coordinates and scene status information, and parse the real-time data to obtain the scene feature set.

[0044] The specific steps for collecting real-time data of tourism scenes by calling the GIS interface in S1 include: configuring the sampling frequency to 1Hz to read data through the GIS interface, wherein the accuracy of collecting the user's real-time location coordinates is within ±5 meters, and the scene status information includes regional population flow level data.

[0045] The process of parsing real-time data to obtain a scene feature set specifically includes: converting the collected real-time data into structured data in JSON format, extracting the name of the business district where the user is currently located, the current status of promotional activities, and the real-time pedestrian flow level to form a scene feature set.

[0046] S1 also includes offline caching of the collected real-time data, with the cached data retention period set to 2 hours.

[0047] First, a secure encrypted transmission channel is established to initialize the connection session with the Geographic Information System (GIS) interface. This process uses the Transport Layer Security (TLS) 1.3 protocol for handshake interaction to ensure the security of the data transmission link. In the sampling frequency configuration phase, a configuration command packet is sent to the GIS server, setting the data polling time interval to 1000 milliseconds, or a sampling frequency of 1 Hz, to ensure real-time synchronization of the data stream. For the acquisition of the user's real-time location coordinates, this process performs high-precision coordinate capture. By fusing GPS signals and base station positioning auxiliary data, double-precision floating-point format longitude and latitude values ​​are obtained, and the Kalman filter algorithm is used to denoise and smooth the original coordinate data. The execution logic of the Kalman filter algorithm is as follows: First, the position estimate and error covariance of the previous moment are obtained. Combined with the current observation value (original GPS coordinates), the Kalman gain is calculated. This gain reflects the relative reliability of the observation value and the estimate. Then, the Kalman gain is used to correct the position estimate to obtain the optimal position coordinates at the current moment, while the error covariance is updated for the next iteration. This filtering process effectively eliminates outliers caused by signal drift, ensuring that the final output coordinate accuracy is strictly controlled within an error range of ±5 meters.

[0048] When acquiring scene status information, this process reads the number of base station connections and the real-time count data captured by cameras in the target area in parallel, and performs quantitative calculations of pedestrian density. The calculation logic is as follows: First, the geometric area of ​​the target area is obtained, in square meters; simultaneously, the aggregated pedestrian count value of the area at the current moment is obtained, in people; then, the aggregated pedestrian count value is divided by the geometric area value to obtain the pedestrian density value per square meter. For example, when the area of ​​the collected business district is 5000 square meters and the current aggregated pedestrian count value is 1200 people, the pedestrian density value is 0.24 people per square meter through division. Based on this, the density value is mapped to specific pedestrian level data according to a preset density grading standard. The preset standard is set as follows: when the density value is less than 0.1 people per square meter, it is judged as the comfortable level; when the density value is between 0.1 people per square meter and 0.5 people per square meter, it is judged as the moderate level; and when the density value is greater than 0.5 people per square meter, it is judged as the crowded level. Substituting the calculated value of 0.24 people per square meter into the judgment logic, the scene status information of the area is then interpreted as moderate.

[0049] Subsequently, real-time data parsing and structured transformation are performed. This process constructs a key-value pair JSON object container, mapping the cleaned latitude and longitude coordinates to the `location` field and the crowd level data to the `crowd_level` field. Simultaneously, a reverse geocoding algorithm is used to parse the coordinate data, retrieving the polygonal area attribute corresponding to the current coordinates from a pre-set vector map database, extracting the corresponding business district name text (e.g., "Century Square"), and filling it into the `district_name` field of the JSON object. For extracting the promotional activity status, this process queries the associated business activity database, using the business district name as the index key, to check if the current timestamp falls within the time interval of any ongoing activity. The retrieval logic is as follows: obtain the current timestamp, iterate through the start and end timestamps of all activities under that business district, and determine if there exists a record where the current timestamp is greater than or equal to the start timestamp and less than or equal to the end timestamp. If it exists, extract the activity's status code and fill it into the `promotion_status` field; otherwise, fill in an empty status code.

[0050] After assembling the structured data, the process immediately generates a scene feature set. This feature set, as a standardized data package, contains feature values ​​for three core dimensions: business district name, promotional activity status, and real-time pedestrian flow level. To improve response efficiency and reduce the pressure of repeated calls to upstream interfaces, the process further performs offline data caching. A memory-based key-value store instance, such as a Redis instance, is initialized. The generated scene feature set is serialized into a string format as the storage value, using a combination of the user's unique identifier and the current time period as the storage key. When writing data, the time-to-live (TTL) parameter for this key-value pair is explicitly set to 7200 seconds, or 2 hours. This means that the data remains valid for 2 hours after being written to memory; once this timeout is exceeded, the caching mechanism will automatically trigger an expiration deletion policy to release memory space.

[0051] As shown in Table 1, this table details the data structure examples of the parsed scene feature sets and the meanings of their fields.

[0052] Table 1 Example of Scene Feature Set Data Structure

[0053] Field Name Data types Example values Explanation of Chinese meaning district_name String Happy Coast Name of the business district the user is currently in promotion_active Boolean value 1 Is there a current promotion? 1 represents yes. crowd_density_val floating-point numbers 0.24 Calculated crowd density values crowd_level_tag String Moderate Mapped crowd congestion levels coordinates array 113.95，22.53 Longitude and latitude coordinate combination timestamp Long plastic surgery 1769587200 UNIX timestamp during data acquisition

[0054] S2: Obtain users' historical behavior data, construct a user preference model using a collaborative filtering algorithm, and output the corresponding preference weight vector from the user preference model.

[0055] The construction of the user preference model in S2 specifically includes: extracting features from historical behavior data such as interest tags, playtime, and task type preferences. Interest tags include food tags and shopping tags; using collaborative filtering algorithms to calculate user interest weights in different dimensions, and generating a preference weight vector containing food weight values ​​and shopping weight values.

[0056] First, historical behavior data logs of the target user are retrieved from a distributed database. These logs contain all user interaction records from the past 180 days. The feature extraction process for this historical behavior data is as follows: First, each behavior record is traversed, and the interest tag field is parsed. This field is predefined to include two main categories: "Food" and "Shopping." For the feature extraction of playtime, this process calculates the difference in dwell time at each specific POI (Point of Interest) in the historical record, i.e., the difference between the departure timestamp and the entry timestamp, yielding the playtime value in minutes. For task type preference, this process counts the frequency of the task categories in which the user clicked "Accept" or "Complete" in the historical tasks.

[0057] Subsequently, the process utilizes a collaborative filtering algorithm to construct a user preference model. This model employs a user-based collaborative filtering strategy, namely UserCF. The specific calculation logic is as follows: First, a user-tag rating matrix is ​​constructed. The rows of the matrix represent different users, and the columns represent different interest dimensions, including dimensions such as food, shopping, sightseeing, and entertainment. The element values ​​in the matrix represent the user's preference for that dimension, and this preference is represented by the normalized historical interaction frequency. For example, if user A visited food locations 20 times and shopping locations 10 times in their historical behavior, for a total of 50 visits, then the original rating for the food dimension is 20 divided by 50, resulting in 0.4, and the original rating for the shopping dimension is 10 divided by 50, resulting in 0.2.

[0058] After constructing the rating matrix, a similarity calculation is performed to find the set of neighboring users whose interests are most similar to the current target user. The process, described logically using the cosine similarity formula, is as follows: First, obtain the rating vectors of the target user and the candidate neighboring users; then, calculate the dot product of these two vectors, which is the sum of the products of the rating values ​​in corresponding dimensions; next, calculate the magnitude of each vector, which is the square root of the sum of the squares of the rating values ​​in each dimension; finally, divide the dot product by the product of the two magnitudes to obtain a cosine similarity value ranging from 0 to 1. The closer this value is to 1, the more similar the interests of the two users.

[0059] For example, suppose the feature vector of the target user is [0.4, 0.2], and the feature vector of a candidate user is [0.5, 0.3]. First, calculate the dot product: 0.4 multiplied by 0.5 plus 0.2 multiplied by 0.3, resulting in 0.26. Next, calculate the magnitude of the target user's vector: 0.4 squared (0.16) plus 0.2 squared (0.04) equals 0.2, then take the square root to get approximately 0.447. Calculate the magnitude of the candidate user's vector: 0.5 squared (0.25) plus 0.3 squared (0.09) equals 0.34, then take the square root to get approximately 0.583. Finally, calculate the cosine similarity: 0.26 divided by the product of 0.447 and 0.583, then 0.26 divided by 0.2606, resulting in approximately 0.997. This extremely high similarity indicates that the candidate user can be considered a strongly related neighbor. The five neighboring users with the highest similarity are selected. The average rating weights of these five neighboring users in the food and shopping dimensions are combined with the similarity as a weighting coefficient to predict the final preference weight of the target user.

[0060] The final process for generating the preference weight vector is as follows: For the food dimension, multiply the food ratings of all selected neighboring users by their corresponding similarity coefficients, sum them, and then divide by the sum of all similarity coefficients to obtain the target user's food weight value. The shopping weight value is calculated similarly. For example, after weighted calculation, the resulting food weight value is 0.75, and the shopping weight value is 0.65. These two values ​​form a two-dimensional preference weight vector [0.75, 0.65], which clearly quantifies the user's relative preference for food and shopping experiences at the current moment. The food weight of 0.75 is significantly higher than the shopping weight of 0.65, indicating that the user currently prefers dining-related activities. This preference weight vector is then output and cached as input constraints for the subsequent generation of the larger model.

[0061] S3: Generate input prompts for a large model based on scene feature sets and preference weight vectors. Input the prompts into a pre-set tourism vertical large model to generate the initial script task content.

[0062] S3 specifically includes: constructing input prompts in the format of "based on real-time scenario: {scenario feature set}, user preference: {preference weight vector}, generating personalized tourism script tasks"; calling a large tourism vertical model to parse the input prompts and generate initial script task content containing task objective descriptions, scenario-related links, and 5 to 8 interactive nodes.

[0063] The tourism vertical big model is a generative artificial intelligence model that has been fine-tuned with data from the cultural and tourism field, and the tourism vertical big model is configured to use an attention mechanism to process the input scene feature set.

[0064] First, the structured construction of input prompts is performed based on the output scene feature set and the preference weight vector output in step S2. The construction logic is as follows: the pre-built string template engine is called to load the format template "Based on real-time scene: {scene feature set}, user preference: {preference weight vector}, generate personalized travel script task". Specific values ​​are filled into the template slots. For example, the JSON format scene feature set text "{'district_name':'Happy Coast', 'promotion_active':1, 'crowd_level':'moderate'}" is filled into the first slot, and the preference weight vector "[0.75, 0.65]" is filled into the second slot. The generated complete input prompt is: "Based on real-time scene: {'district_name':'Happy Coast', 'promotion_active':1, 'crowd_level':'moderate'}, user preference: [0.75, 0.65], generate personalized travel script task".

[0065] Subsequently, the input prompt is fed into a large-scale tourism vertical model. This model is a generative AI model based on the Transformer architecture, internally consisting of 12 encoder layers and 12 decoder layers. Each layer comprises a multi-head self-attention mechanism sublayer and a feedforward neural network sublayer. During the attention mechanism processing, the model first converts the input prompt text into a high-dimensional word embedding vector and injects sequence information through positional encoding. For each key feature in the input scene feature set, the model uses the attention mechanism to calculate its weight distribution. Specifically, the model generates a query vector (Query), a key vector (Key), and a value vector (Value) for each input token. The dot product of the transpose of the Query vector and the Key vector is calculated to obtain the original attention score. This score is then divided by a scaling factor of the vector dimension (e.g., √768 for a dimension of 768) and subjected to Softmax normalization to obtain the attention weight matrix. This weight matrix reflects the degree of attention the model pays to different parts of the input prompt when generating the current word. For example, when the model detects a high value of 0.75 for food in the preference weight vector, the attention mechanism will give higher attention weights to words related to "restaurant", "snacks" and "tasting", thereby guiding the subsequent generation process to lean towards the food theme.

[0066] In the feedforward neural network sublayer, the model uses the ReLU activation function to perform a non-linear transformation on the data. The execution logic of the ReLU function is: for an input value x, if x is greater than 0, then output x; if x is less than or equal to 0, then output 0. This ensures that the model can capture complex non-linear relationships. After layers of processing, the model decoder finally outputs a series of probability distributions, employing a beam search strategy with a beam width of 5 to select the optimal text sequence with the highest cumulative probability as the initial script task content.

[0067] The generated initial script task content includes a clear task objective description, such as "finding the hidden seafood stall," scene-related elements, such as "going to the Happy Coast Fountain Square to find clues," and 5 to 8 specific interactive nodes. For example, the first generated interactive node is "taking a photo of the fountain," the second is "scanning the store's QR code to get a coupon," and so on up to the fifth node, "completing the check-in and receiving a souvenir." The entire generation process is driven entirely by the model's internal parameters, requiring no manual intervention. This large-scale tourism vertical model has been pre-tuned and trained on a corpus specifically for the cultural tourism field. The corpus contains over 100,000 high-quality travel guides and tour guide narrations, enabling the model to accurately understand the deeper meanings of industry terms such as "business district," "promotion," and "crowd flow."

[0068] S4: Calculate the matching degree between the initial script task content and the real-time data, and determine whether the matching degree is greater than the preset matching threshold. If so, mark the initial script task content as an adapted task.

[0069] S4 specifically includes: analyzing the consistency between the activity elements involved in the initial script task content and the current area activities in the scene feature set, and calculating the matching degree value between 0 and 100; setting a preset matching threshold of 80 points, and if the matching degree value is less than 80 points, triggering the tourism vertical big model to re-execute the task generation step.

[0070] The process involves calculating and verifying the match between the initial script task content and real-time data. The matching score is calculated using a weighted semantic matching algorithm. First, a set of keywords is extracted from the initial script task content, such as "seafood," "fountain," and "coupon." Simultaneously, corresponding state values ​​are extracted from the scene feature set of the real-time data. The calculation process is divided into two dimensions: consistency of activity elements and adaptability of scene states.

[0071] To ensure consistency of activity elements, the overlap between the task keywords and the description of the current business district's promotional activities is calculated. The calculation logic is as follows: count the number of times the task keywords appear in the business district's activity description, and divide by the total number of task keywords. For example, if the task has three keywords: "seafood," "fountain," and "coupon," and the business district's activity description contains the words "fountain" and "coupon," then the score for this dimension is 2 divided by 3, which gives approximately 0.66. Multiply this by 100 and normalize to 66 points.

[0072] For scenario-state adaptability, it determines whether the activity type suggested in the task conflicts with the current crowd level. A pre-defined logical rule table is provided, such as "When the crowd level is 'crowded,' avoid recommending large-scale gathering activities." If the task content does not contain conflicting activities, this dimension scores 100 points; if it does, the corresponding points are deducted.

[0073] The final matching score is obtained by weighted summation of the scores from the two dimensions mentioned above. The weighting coefficient for activity element consistency is set to 0.6, and the weighting coefficient for scene state adaptability is set to 0.4. Continuing with the previous example, if the activity element consistency score is 66 and the scene state adaptability score is 100, the final matching score is calculated as follows: 66 multiplied by 0.6 equals 39.6, 100 multiplied by 0.4 equals 40, and the sum of the two is 79.6.

[0074] Subsequently, the calculated matching score of 79.6 is compared with the preset matching threshold of 80. The judgment logic is: if the matching score is greater than or equal to 80, it is considered qualified; if it is less than 80, it is considered unqualified. In this example, 79.6 is less than 80, so the initial script task content is judged to be unqualified. At this time, a negative feedback mechanism is triggered, encoding the specific reason for the mismatch, such as "insufficient matching degree of activity elements," as an additional constraint condition and feeding it back to the tourism vertical large model in step S3, forcing the model to re-execute the generation step until the matching score of the generated task content exceeds 80. Suppose that in the second generation, the model adjusts the task content, improving the consistency of activity elements to 90. The new matching score calculated at this time is 90 multiplied by 0.6 plus 100 multiplied by 0.4, that is, 54 plus 40 equals 94. 94 is greater than 80, so it is judged to pass, and the content is marked as an adapted task. This strict threshold filtering mechanism effectively eliminates invalid tasks caused by model illusions or information lag, ensuring that the script tasks pushed to users are highly executable.

[0075] S5: Convert the content of the adaptation task into a mobile terminal-compatible format and send it to the user terminal through the push service channel.

[0076] S5 specifically includes: encapsulating the content of the adaptation task into a combined format containing text descriptions, map marker data, and interactive button instructions; pushing the combined format data packet to the user terminal through a third-party push service channel, and verifying the arrival receipt of the push message.

[0077] The verified adaptation task content will undergo format conversion to meet the rendering requirements of mobile terminals. First, a multimedia mixed-format data packet will be constructed, encapsulated using a JSON structure. The encapsulation process includes: assigning the task's text description string to the `text_content` field; converting the geographical coordinates involved in the task into map marker objects, including longitude, latitude, and icon style IDs, and assigning them to the `map_markers` array field; and encapsulating the interactive operation logic into button instruction objects, such as the trigger action URI for the "Click to Check In" button, and assigning it to the `action_buttons` field.

[0078] Subsequently, the API interface of the third-party push service channel is invoked. This process establishes a connection with the push server via HTTPS encryption and sends the encapsulated data packet as the payload. To ensure message delivery, a unique message ID is included in the sending request. Upon receiving the request, the push service channel distributes the data packet to the specific user terminal device via a persistent connection.

[0079] After receiving the data packet, the user terminal parses the JSON data and renders it on the application interface. The text description is rendered as a task card, map markers are drawn on the embedded map control, and interactive buttons are rendered as clickable UI components. Simultaneously, after successfully receiving and rendering the message, the user terminal automatically generates an acknowledgment packet and sends it back to the server. The server listens for and records this acknowledgment message to verify the arrival status of the push message. If no acknowledgment is received within the preset timeout period of 30 seconds, an exponential backoff retry strategy will be executed, i.e., retransmission will be performed at the 1st, 2nd, and 4th seconds, until an acknowledgment is received or the maximum number of retries (3) is reached.

[0080] S6: Collect user feedback data on the adaptation task, and adjust the weight parameters of the user preference model based on the feedback data to complete the model iteration.

[0081] S6 specifically includes: collecting feedback data, including task completion status, task abandonment status, and satisfaction ratings from 1 to 5 stars; if a user completes a specific type of task, increasing the weight value of that type in the user preference model; and setting the model update cycle to perform an iterative calculation once every 10 pieces of feedback data collected.

[0082] After adjusting the weight parameters of the user preference model in S6, it also includes: generating new script tasks using the updated user preference model and calculating new matching scores to verify the effectiveness of the model update.

[0083] Initiate a closed-loop user feedback mechanism. Deploy listening probes on the task interface of the user terminal to collect user actions on the adapted tasks in real time. Feedback data specifically includes: task completion status, divided into "completed" and "incomplete"; task abandonment status, i.e., whether the user actively clicked the "abandon task" button; and the satisfaction rating submitted by the user after the task is completed, which is an integer star rating from 1 to 5.

[0084] The collected feedback data is transmitted back to the server in real time and used to adjust the weight parameters of the user preference model. The parameter adjustment logic adopts an incremental update algorithm based on gradient descent. Specifically, the logic is as follows: First, an error function is defined, which is the square of the difference between the user's actual rating and the model's predicted rating. For example, if the model predicts a user's liking for a food task to be 0.75 (corresponding to 3.75 stars), and the user actually gives a 5-star rating, then the error value is 5 minus 3.75, resulting in 1.25. This error value is then used to calculate the weight adjustment amount. The formula is described as follows: the new weight value equals the old weight value plus the learning rate multiplied by the error value multiplied by the input feature value. The learning rate is set to 0.1.

[0085] Suppose that for a task related to "food," the old weight was 0.75, the error was 1.25, and the input feature value was 1, indicating that the user actually performed this type of task. Substituting these values ​​into the calculation: 0.1 multiplied by 1.25 multiplied by 1 gives an adjustment increment of 0.125. The new weight is 0.75 plus 0.125, which equals 0.875. This calculation shows that because the user gave a higher-than-expected positive review, the model significantly increased the user's preference weight for food-related tasks from 0.75 to 0.875.

[0086] The model update cycle is set to perform a batch iteration every 10 feedback data points collected. When the accumulated number of feedback data points reaches 10, the current weight parameter service is paused, and the model parameters are updated uniformly using the average adjustment increment calculated from these 10 data points.

[0087] Immediately after the update, model validity verification is performed. This verification process uses the updated user preference model to regenerate a new test scenario task and calculates the matching degree between the new task and the latest user feedback data. For example, using the updated food weight of 0.875 to generate a new task, if the deviation between the predicted score of the new task and the user's historical average score is less than 0.5 points, the model update is deemed valid, and this parameter version is officially launched; otherwise, it is rolled back to the previous version of the parameters, and the update is marked as abnormal, triggering a manual review process.

[0088] As shown in Table 2, this table presents the parameter comparison and verification results before and after the model weight update.

[0089] Table 2 Validation Table for Updating Weight Parameters of User Preference Model

[0090] Parameter Dimensions Weight values ​​before update User feedback rating Learning rate setting Calculate adjustment increment Updated weight values Verification status Food preferences 0.75 5.0 0.1 0.125 0.875 efficient Shopping preferences 0.65 2.0 0.1 -0.15 0.50 efficient Tourism preferences 0.40 3.0 0.1 -0.05 0.35 efficient

[0091] The experimental results show that by introducing iterative calculations based on real-time feedback data, the user preference model can sensitively capture the dynamic changes in user interests, increasing the weight of the food dimension by approximately 16.7%, effectively correcting the prediction bias of the initial model, and making the subsequently generated script tasks more in line with the user's immediate needs.

[0092] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of protection of the described technical solutions.

Claims

1. A method for customizing personalized script tasks for real-time dynamic tourism scenarios, characterized in that, Includes the following steps: S1: Call the GIS interface to collect real-time data of the tourism scene. The real-time data includes regional activity information, user real-time location coordinates and scene status information, and parse the real-time data to obtain a scene feature set. S2: Obtain the user's historical behavior data, construct a user preference model using a collaborative filtering algorithm, and output the corresponding preference weight vector from the user preference model; S3: Generate input prompts for a large model based on the scene feature set and the preference weight vector, and input the input prompts into a preset tourism vertical large model to generate initial script task content; S4: Calculate the matching degree value between the initial script task content and the real-time data, and determine whether the matching degree value is greater than the preset matching threshold. If so, mark the initial script task content as an adapted task. S5: Convert the content of the adaptation task into a mobile terminal-compatible format and send it to the user terminal through the push service channel; S6: Collect user feedback data on the adaptation task, and adjust the weight parameters of the user preference model based on the feedback data to complete the model iteration; The process of collecting real-time data of tourism scenarios by calling the GIS interface in S1 specifically includes: The sampling frequency is configured to 1Hz to read data through the GIS interface, wherein the acquisition accuracy of the user's real-time location coordinates is within ±5 meters, and the scene status information includes regional pedestrian flow level data; The process of parsing real-time data to obtain a scene feature set specifically includes: The collected real-time data is converted into structured data in JSON format, and the name of the business district where the user is currently located, the current promotional activity status, and the real-time pedestrian flow level are extracted to form the scene feature set; S4 specifically includes: Analyze the consistency between the activity elements involved in the initial script task content and the current area activities in the scene feature set, and calculate the matching degree value between 0 and 100. The preset matching threshold is set to 80 points. If the matching score is less than 80 points, the task generation step of the tourism vertical big model is triggered to be re-executed.

2. The method for customizing personalized script tasks for real-time dynamic tourism scenarios according to claim 1, characterized in that, The construction of the user preference model in S2 specifically includes: Feature extraction is performed on the interest tags, playtime, and task type preferences in the historical behavior data. The interest tags include food tags and shopping tags. The collaborative filtering algorithm is used to calculate the user's interest weights in different dimensions, generating the preference weight vector that includes food weight values ​​and shopping weight values.

3. The method for customizing personalized script tasks for real-time dynamic tourism scenarios according to claim 1, characterized in that, S3 specifically includes: The input prompts are constructed in the format of "Based on real-time scenario: {scenario feature set}, user preferences: {preference weight vector}, generate personalized tourism script tasks"; The input prompts are analyzed using the tourism vertical big model to generate the initial script task content, which includes a description of the task objective, scene-related links, and 5 to 8 interactive nodes.

4. The method for customizing personalized script tasks for real-time dynamic tourism scenarios according to claim 1, characterized in that, S5 specifically includes: The content of the adaptation task is encapsulated into a combined format that includes text descriptions, map marker data, and interactive button instructions; The combined data packets are pushed to the user's terminal through a third-party push service channel, and the arrival receipt of the push message is verified.

5. The method for customizing personalized script tasks for real-time dynamic tourism scenarios according to claim 1, characterized in that, S6 specifically includes: Collect feedback data, which includes task completion status, task abandonment status, and satisfaction ratings from 1 to 5 stars. If a user completes a specific type of task, the weight value corresponding to that type will be increased in the user preference model; The model update cycle is set to perform an iterative calculation once every 10 pieces of feedback data collected.

6. The method for customizing personalized script tasks for real-time dynamic tourism scenarios according to claim 3, characterized in that, The tourism vertical big model is a generative artificial intelligence model that has been fine-tuned with data from the cultural and tourism field, and the tourism vertical big model is configured to use an attention mechanism to process the input scene feature set.

7. The method for customizing personalized script tasks for real-time dynamic tourism scenarios according to claim 1, characterized in that, S1 also includes offline caching of the collected real-time data, with the cached data retention period set to 2 hours.

8. The method for customizing personalized script tasks for real-time dynamic tourism scenarios according to claim 1, characterized in that, After adjusting the weight parameters of the user preference model in step S6, the method further includes: New script tasks are generated using the updated user preference model, and new matching scores are calculated to verify the effectiveness of the model update.

Images