Program travel itinerary planning and pushing method and system, computer equipment and storage medium
By generating and analyzing user tags, establishing time-series and scenario-based user memory relationships, and combining real-time demand data and multimedia data, this solves the problem that existing Chinese travel itinerary planning technologies do not align with user preferences, thus achieving more precise personalized services and more effective multimedia push notifications.
Patent Information
- Application Number
- CN202511380390.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-25
- Publication Date
- 2025-10-31
- Estimated Expiration
- 2045-09-25
AI Technical Summary
Existing technologies fail to construct structured user memory associations based on temporal and scenario-based correlations in multimodal interaction data, resulting in travel itinerary planning that does not align with overall user preferences and fails to meet personalized service needs.
By acquiring interaction data, multiple user tags are generated, tag types are analyzed and tag weights are determined, user memory associations are established, trip planning is determined in combination with real-time demand data, and multimedia data is inserted based on the trip planning to form multimedia push content.
It achieves more precise itinerary planning and more effective multimedia push notifications, improves the smoothness of user experience and the relevance of multimedia push notifications, and solves the problem of blindness in itinerary planning and push notifications in existing technologies.
Smart Images

Figure CN120875472A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing, and in particular to a method, system, computer equipment, and storage medium for planning and pushing travel itineraries. Background Technology
[0002] With the deep integration of mobile internet and cultural tourism services, users' demand for personalized cultural tourism itinerary planning and push is increasing. Currently, mainstream cultural tourism itinerary service systems can obtain user needs through multimodal interaction methods such as voice and text, and attempt to generate user tags based on interaction data to support services.
[0003] However, the existing technology planning methods cannot be combined with standardized content delivery, making it difficult to meet users' needs for precise and personalized travel itinerary services.
[0004] In view of the above, this application is hereby submitted. Summary of the Invention
[0005] The purpose of this application is to propose a method, system, computer device, and storage medium for planning and pushing cultural and tourism itineraries, in order to solve the technical problem that the existing technology only processes multimodal interactive data in isolation and labeling, without building a structured user memory association relationship that includes time-series association and scene association, which leads to itinerary planning not matching the user's overall preferences, blind multimedia push, and failure to meet the needs of personalized cultural and tourism services.
[0006] To address the aforementioned technical problems, this application provides a document travel itinerary planning and push method, employing the following technical solution: A method for planning and promoting cultural and tourism itineraries includes the following steps: S1. Obtain interaction data, and generate multiple user tags based on the interaction data and preset classification dimensions; S2. Analyze each user tag to obtain the tag type corresponding to each user tag; S3. Based on the tag type, determine the tag weight of each user tag; S4. Based on the tag weights and the interaction data, establish a user memory association relationship; S5. Obtain real-time demand data, and determine the itinerary plan based on the user memory association relationship and the real-time demand data; S6. Acquire multimedia data, determine candidate insertion nodes based on the trip planning, filter target multimedia data from the multimedia data based on the user memory association, insert the target multimedia data into the candidate insertion nodes, and obtain multimedia push content.
[0007] Furthermore, the analysis of the user tags to obtain tag types includes: Based on the interaction data, determine whether the source of the user tag meets the condition of the user actively conveying the need; if so, the user tag is an explicit tag. Based on the interaction data, determine whether the source of the user tag meets the preset preference association conditions; if so, the user tag is an implicit tag.
[0008] Furthermore, determining the tag weight for each user tag based on the tag type includes: S31. If the user tag is an explicit tag, then extract the first interaction frequency from the interaction data, and determine the first initial weight of the explicit tag based on the first interaction frequency and the preset explicit weight. If the user tag is an implicit tag, then the second interaction frequency and time parameter are extracted from the interaction data, and the time decay factor is determined based on the time parameter; Based on the second interaction frequency and the time decay factor, the second initial weight of the implicit label is determined; S32. Obtain real-time interactive data, and adjust the first initial weight and the second initial weight based on the real-time interactive data to obtain the first final weight and the second final weight respectively.
[0009] Furthermore, establishing user memory associations based on the tag weights and the interaction data includes: S41. Extract the time features and scene features corresponding to the user tags from the interaction data; S42. Based on the time characteristics, the user tags are divided into recent tag groups and historical tag groups; S43. Select user tags whose tag weight is higher than a preset threshold in the recent tag group as the first core tag, and select user tags whose tag weight is higher than a preset threshold in the historical tag group as the second core tag; S44. Analyze the correlation between the first core tag and the second core tag. If the correlation meets the preset correlation conditions, then establish the temporal correlation between the recent tag group and the historical tag group. S45. Based on the scene characteristics, filter user tags that frequently appear in the same interaction scene to obtain scene combination tags; S46. Establish scene association relationships based on the scene combination tags and the user tags; S47. Integrate the temporal association and the scene association to obtain the user memory association.
[0010] Furthermore, the step of acquiring real-time demand data and determining trip planning based on the user's memory association and the real-time demand data includes: S51. Obtain real-time demand data, which includes destination demand data, itinerary constraint data, and real-time location data; S52. Extract the temporal correlation features and scenario correlation features of the destination demand data; S53. Based on the temporal correlation features, the scene correlation features and the destination demand data, multiple preference information related to the destination demand data are matched and filtered from the user memory correlation relationship, and the preference information is integrated to obtain the user's core itinerary demand. S54. Based on the itinerary constraint data and the destination demand data, determine the geographical scope of the itinerary planning; S55. Based on the geographical scope of the itinerary plan and the user's core itinerary needs, candidate cultural and tourism resources are selected from the preset cultural and tourism resource database; S56. Based on the real-time location data and the candidate cultural and tourism resources, determine the itinerary plan.
[0011] Furthermore, multimedia data is acquired, candidate insertion nodes are determined based on the trip planning, target multimedia data is filtered from the multimedia data based on the user memory association, and the target multimedia data is inserted into the candidate insertion nodes to obtain multimedia push content, including: S61. Based on the user memory association relationship, extract relevant user tags related to the itinerary planning from multiple user tags; S62. Determine the matching degree between the relevant user tags and multiple multimedia data in a preset multimedia database, and filter out target multimedia data whose matching degree meets the preset requirements from the multiple multimedia data; S63. Extract the core attributes of key travel segments in the travel planning, and determine candidate insertion nodes for multimedia data based on the core attributes; S64. Based on the core attributes, the target multimedia data is adapted to obtain the content to be promoted; S65. Based on the time nodes of the trip planning and the user's memory association, set the trigger conditions for pushing the pending promotional content; S66. Based on the candidate insertion nodes and the triggering conditions, the pending promotion content is organized, and finally the multimedia push content is generated.
[0012] A travel itinerary planning and push system, used to execute the aforementioned travel itinerary planning and push method, includes: The data processing module is used to acquire interaction data and generate multiple user tags based on the interaction data and preset classification dimensions; The tag type analysis module is communicatively connected to the interaction data acquisition and tag generation module, and is used to receive user tags output by the interaction data acquisition and tag generation module, analyze each user tag, and obtain the tag type corresponding to each user tag; The tag weight calculation module is communicatively connected to the tag type analysis module, and is used to receive the tag type output by the tag type analysis module, and determine the tag weight of each user tag based on the tag type; The association establishment module is communicatively connected to the tag weight determination module and the interaction data acquisition and tag generation module, respectively, and is used to receive the tag weight output by the tag weight determination module and the interaction data output by the interaction data acquisition and tag generation module, and establish user memory associations based on the tag weight and the interaction data. The itinerary planning module communicates with the user memory association module to obtain real-time demand data and determine the itinerary plan based on the user memory association and the real-time demand data. The push module is communicatively connected to the real-time demand processing and itinerary planning module and the user memory association module, respectively. It is used to acquire multimedia data, determine candidate insertion nodes based on the itinerary planning, filter target multimedia data from the multimedia data based on the user memory association, and insert the multimedia data into the candidate insertion nodes to obtain multimedia push content.
[0013] To address the aforementioned technical problems, this application also provides a computer device that employs the following technical solution: A computer device includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the document travel itinerary planning and push method as described above.
[0014] To address the aforementioned technical problems, this application also provides a computer-readable storage medium, employing the technical solution described below: A computer-readable storage medium storing computer-readable instructions, which, when executed by a processor, implement the steps of the document travel planning and pushing method described above.
[0015] Compared with the prior art, the embodiments of this application have the following main advantages: This application acquires interaction data and generates user tags according to preset classification dimensions, structuring multimodal data such as voice and text to lay the foundation for subsequent preference analysis and avoid judgment bias caused by data fragmentation. Next, by analyzing tag types and determining tag weights, it distinguishes between explicit tags (actively expressed) and implicit tags (inferred from behavior), adapting different weight logics, quantifying preference strength, and ensuring timeliness, thus addressing the deficiency of static tags in reflecting changing needs. Then, based on tag weights and interaction data, it establishes user memory associations, transforming isolated tags into a structured network with temporal and scenario-based associations, avoiding fragmented itinerary recommendations. Subsequently, itinerary planning is determined by combining real-time demand data with memory associations, solving the problem of static itineraries being disconnected from real-time needs. Finally, multimedia data is inserted based on itinerary and memory associations to avoid blindly pushing content that interferes with users. Overall, this forms a closed loop of data, memory, and service, significantly improving itinerary accuracy, user experience smoothness, and the effectiveness of multimedia push notifications. Attached Figure Description
[0016] To more clearly illustrate the solutions in this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0017] Figure 1 This is an exemplary system architecture diagram to which this application can be applied; Figure 2 This is a flowchart of an embodiment of the document travel itinerary planning and push method according to this application; Figure 3 This is a structural diagram of an embodiment of the document travel itinerary planning and push system according to this application; Figure 4 This is a schematic diagram of the structure of one embodiment of the computer device according to this application. Detailed Implementation
[0018] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings of this application, are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings of this application are used to distinguish different objects, not to describe a particular order.
[0019] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.
[0020] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.
[0021] like Figure 1 As shown, system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. Network 104 serves as the medium for providing communication links between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.
[0022] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social media platform software, etc.
[0023] Terminal devices 101, 102, and 103 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, e-book readers, MP3 (Moving Picture Experts Group Audio Layer III) players, MP4 (Moving Picture Experts Group Audio Layer IV) players, laptops, and desktop computers, etc.
[0024] Server 105 can be a server that provides various services, such as a backend server that supports the pages displayed on terminal devices 101, 102, and 103.
[0025] It should be noted that the document travel itinerary planning and push method provided in this application embodiment is generally executed by the terminal device, and correspondingly, the document travel itinerary planning and push system is generally set in the terminal device.
[0026] It should be understood that Figure 1The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.
[0027] Continue to refer to Figure 2 The diagram illustrates a flowchart of an embodiment of the method according to this application. The document travel itinerary planning and push method includes the following steps: S1. Obtain interaction data, and generate multiple user tags based on the interaction data and preset classification dimensions; In this embodiment, the document travel itinerary planning and push method runs on an electronic device (e.g., Figure 1 The terminal device shown can send or receive data via wired or wireless connection. It should be noted that the aforementioned wireless connection methods may include, but are not limited to, 3G / 4G / 5G connections, WiFi connections, Bluetooth connections, WiMAX connections, Zigbee connections, UWB (ultrawideband) connections, and other currently known or future wireless connection methods.
[0028] Existing cultural and tourism systems often fail to accurately capture user preferences because user needs are scattered in unstructured interactive data (such as voice fragments and scattered text). Multimodal data collection and classification are needed to transform scattered needs into structured tags. Based on this, this step is used to solve the above problems.
[0029] In this embodiment, interaction data refers to multimodal data generated when a user interacts with the cultural tourism itinerary planning system. Specifically, interaction data includes text data output by voice interaction via Automatic Speech Recognition (ASR) (e.g., the text translated from the user's voice "I want to go to a place with ancient architecture and also want to eat light food"), text content actively input by the user (e.g., "Short trip, anytime within 3 days" "Want to avoid crowded places"), interaction timestamps (accurate to the second, e.g., 9:15:40 AM on [Date], used to record the timing of actions), and interaction context information (e.g., the current query result page for "ancient architecture-related attractions" and the initial geographical location range during the query, "the area surrounding the user's current city"). Simultaneously, the interaction data undergoes preprocessing: regular expressions are used to filter out interjections such as "oh" and "um," as well as repeated characters; the BERT-CRF model is used to correct typos in the text (e.g., "ancient architecture" is corrected to "ancient buildings"), ensuring data validity.
[0030] After acquiring the interaction data, it needs to be categorized based on preset classification dimensions. This is primarily to standardize preference analysis and prevent inconsistent dimensions from causing subsequent tag association issues. The preset classification dimensions include five core dimensions used for structured categorization of the interaction data, specifically: 1. Attraction Preference Dimensions: Covering subcategories such as natural landscapes (lakes, mountains, etc.), historical sites (ancient buildings, ancient towns, etc.), and leisure and entertainment (theme parks, pedestrian streets, etc.); 2. Food taste dimension: covering subcategories such as light, spicy, sweet and sour, salty and savory, as well as negative subcategories such as "low interest"; 3. Consumption level dimension: Covering subcategories including economy (average consumption per person < 100 yuan), comfort (average consumption per person 100-300 yuan), and high-end (average consumption per person > 300 yuan); 4. Time Management Habits: This includes subcategories such as morning tours, afternoon tours, evening activities, and lunch break preferences; 5. Emotional Tendency Dimension: This includes subcategories such as preference for quiet, preference for lively atmosphere, emphasis on experience, and emphasis on cost-effectiveness.
[0031] After classifying the interaction data, a quantifiable user preference identifier is generated based on the interaction data and the above classification dimensions. The generated format is "dimension + subcategory + specific preference content (if any)", which is the user tag.
[0032] The format of user tags is shown below: In the user's speech-to-text translation of "I want to go to a place with historical buildings", the "attraction preference - cultural relics" dimension is matched to generate the tag "attraction preference - cultural relics - historical buildings"; From the user's input "want to eat non-spicy dishes", match the "food flavor - non-spicy" dimension to generate the tag "food flavor - non-spicy"; Based on the user's statement "want to avoid crowded areas", the "emotional tendency - preference for quiet" dimension is matched to generate the tag "emotional tendency - preference for quiet".
[0033] S2. Analyze each user tag to obtain the tag type corresponding to each user tag; In this embodiment, the tag types include explicit tags (generated by user-initiated statements, such as "want to visit historical buildings" generating "attraction preference - cultural relics - historical buildings") and implicit tags (generated by behavior inference, such as "skipping "theme parks" multiple times generating "leisure and entertainment - theme parks - low interest"). Specifically, explicit tags refer to tags generated directly from user-expressed interaction data, that is, tags formed after users actively convey their needs through voice, text, etc. For example, if a user explicitly says "I want to go to a place with historical buildings," the corresponding generated tag "Attraction Preferences - Cultural Relics - Historical Buildings" is an explicit tag; or, if a user actively inputs "I want to eat non-spicy food," the corresponding generated tag "Food Flavor - Non-Spicy" is an explicit tag.
[0034] Implicit tagging refers to tags generated by indirectly inferring user preferences through analysis of user interaction behavior (such as clicks, pauses, and skips). For example, if a user clicks the "skip" button three times consecutively when the system recommends information related to "lively themed parks," and this is combined with the "leisure and entertainment" dimension, it can be inferred that the user has low interest in themed parks, generating the tag "leisure and entertainment - themed parks - low interest." Or, if a user spends significantly more time viewing "morning tour guide for historical buildings" (2 minutes and 40 seconds) than viewing "afternoon tour guide" (50 seconds), and this is combined with the "time management habits" dimension, it can generate the tag "time management habits - morning tour - high preference."
[0035] Among these, tags from different sources have varying degrees of credibility in representing user preferences. In other words, explicit tags represent direct user needs and are highly credible, while implicit tags are indirect inferences and require different treatment. Failing to differentiate tag types may lead to treating "unexpressed user behavior" and "active needs" interchangeably, resulting in significant biases in preference judgments. Therefore, this step identifies and categorizes user tags to provide a basis for subsequent tag weight calculations (explicit tags should emphasize frequency, while implicit tags should emphasize timeliness), thus improving the accuracy of weighting.
[0036] S3. Based on the tag type, determine the tag weight of each user tag; In this embodiment, the tag weight is a parameter used to quantify the strength of a user's preference for a tag. The value range is 0-5 (the higher the value, the stronger the preference). This range can be selected according to the actual situation. The calculation of the tag weight needs to be combined with the tag type, and incorporate factors such as interaction frequency and time decay to ensure that the weight can be dynamically updated to reflect the user's latest preferences. Each tag type has its own corresponding calculation logic.
[0037] Specifically, explicit tags are calculated based on "interaction frequency" and "preset explicit base weight," where the "preset explicit base weight" is the system's pre-set base score for explicit tags (set to 0.8 in this embodiment). For example, if a user mentions "wanting to go to places with historical buildings" in two interactions, the interaction frequency is 2, then the initial weight of "attraction preference - cultural relics - historical buildings" = 2 × 0.8 = 1.6. If the user then adds "hoping for guided tours of historical buildings" in a third interaction, the interaction frequency is updated to 3, and the weight is updated accordingly to 3 × 0.8 = 2.4.
[0038] Implicit tagging is based on "interaction frequency" and "time decay factor," where the "time decay factor" is a coefficient set according to the time difference since the tag was generated (in this embodiment, the time decay factor is 1.0 within 1 week, 0.9 for 1-2 weeks, and 0.7 for more than 2 weeks). For example, if a user skips the "Lively Theme Park" recommendation 4 times within 1 week, the interaction frequency is 4, and the time decay factor is 1.0, then the initial weight of "Leisure and Entertainment - Theme Park - Low Interest" = 4 × 1.0 = 4.0. After 2 weeks, if the user no longer interacts with "Theme Park," the time decay factor is updated to 0.7, and the weight is adjusted accordingly to 4 × 0.7 = 2.8.
[0039] Furthermore, if new real-time user interaction data is obtained (such as when a user mentions "historical buildings" again on the same day), the tag weights are updated based on the new interaction frequency or behavior to ensure that the weights always remain consistent with the user's latest preferences.
[0040] In this step, the "preference strength" of the same type of tag varies (e.g., a user mentioning "historical buildings" 3 times has a stronger preference than mentioning it once), and implicit tags become invalid over time (e.g., "dislikes themed parks" from 2 weeks ago may change). It is necessary to quantify the strength and timeliness through weights (to solve the problem of "preferences not being quantified and unable to be dynamically updated" in the "background technology" section of the handover document). If no weights are set, subsequent itinerary planning cannot determine "which preference to prioritize" (e.g., which is more important, "likes historical buildings" or "wants to eat non-spicy food"), resulting in disordered recommendations.
[0041] In other words, this step quantifies the intensity of user preferences, with high-weight tags corresponding to core needs, ensuring that subsequent itinerary planning prioritizes the needs that users care about most (such as recommending related scenic spots with high weight "historical buildings"). At the same time, it can dynamically adapt to changes in preferences, and the time decay factor avoids "outdated preferences" from affecting recommendations (such as the weight of "dislike of theme parks" which decreased 2 weeks ago, but can be increased again if the user pays attention to it later), ensuring that the weight always reflects the latest preferences.
[0042] S4. Based on the tag weights and the interaction data, establish a user memory association relationship; In this embodiment, the user memory association is a structured relationship network centered on the "user-tag-scene" node-edge model, used to reflect the temporal and scene associations between user tags. The establishment process requires combining tag weights (prioritizing the association of tags with weights higher than a preset threshold, which is set to 1.5 in this embodiment) and interaction data (extracting time features and scene features). The establishment of user memory associations includes steps such as establishing temporal associations, establishing scene associations, and storing associations. The specific establishment process is as follows: First, based on the timestamps in the interaction data, a sliding window algorithm is used to divide recent tags (generated within the last month) into historical tags (generated more than one month ago). The correlation between the content of tags with weights higher than a preset threshold is analyzed. If the tags belong to the same category dimension and have similar subcategories, a temporal correlation is established. For example, the recent high-weight tag "Attraction Preference - Cultural Relics - Historical Buildings" (weight 2.4) and the historical high-weight tag "Attraction Preference - Cultural Relics - Ancient Villages" (generated 2 months ago, weight 1.9) both belong to the "Attraction Preference - Cultural Relics" dimension, and a temporal correlation is established (labeled "Continued Preference for Cultural Relics").
[0043] Subsequently, based on the contextual information in the interaction data (the co-occurrence of multiple tags in the same query scenario), the Apriori algorithm is used to mine frequently co-occurring tag combinations (co-occurrence times ≥ 2), generate scenario combination identifiers, and establish associations. For example, interaction data shows that "attraction preference - cultural relics - historical buildings" (weight 2.4), "food taste - not spicy" (weight 2.1), and "time arrangement habit - morning visit" (weight 1.7) co-occur twice in the user's "short trip query" scenario, generating the scenario combination identifier "morning visit to historical buildings + non-spicy food", and establishing scenario associations between the three tags and this identifier.
[0044] Finally, a non-relational graph database (such as Neo4j) is used to store the relationships, where "user", "tag", and "scene combination identifier" are nodes, the tag weight is the strength of the "user-tag" edge, and the relationship type (time series / scene) is the attribute of the "tag-scene combination identifier" edge. For example: "User-(weight 2.4)→attraction preference-cultural relics-historical buildings-(scene association)→morning visit to historical buildings + non-spicy dining".
[0045] This step establishes user memory associations because a single tag cannot reflect the "relevance of preferences" (e.g., if a user likes "historical buildings" and "visits in the morning," a combination recommendation is necessary to make it reasonable). Furthermore, it is necessary to link historical and recent preferences to avoid "gap" relationships. If no association is established, subsequent itinerary planning may "isolate and satisfy a single preference" (e.g., recommending historical buildings but arranging for afternoon visits), resulting in a poor experience.
[0046] S5. Obtain real-time demand data, and determine the itinerary plan based on the user memory association relationship and the real-time demand data; In this embodiment, real-time demand data refers to the dynamic data directly related to the trip that the user just expressed when planning the trip. Specifically, it includes destination demand data, trip constraint data, and real-time location data. Among them, destination demand data is the user's clearly defined core direction of the trip (such as "short trip, want to go to historical building areas with guided tours"). Trip constraint data is the trip restrictions set by the user (such as "1-day trip, total budget within 1200 yuan, moderate physical strength, need to control the daily walking distance to no more than 8000 steps"). Real-time location data is the real-time geographical location of the user's trip starting point (such as "the user's real-time location on the day of the trip is around the train station in their city").
[0047] Furthermore, the determination of the itinerary plan is based on the user's memory associations (providing preference direction) and real-time demand data (providing specific constraints), and a structured itinerary is generated by screening candidate cultural and tourism resources and optimizing routes; Specifically, determining the itinerary plan includes two steps: screening candidate cultural and tourism resources and determining the itinerary route.
[0048] Candidate cultural and tourism resources are selected based on destination demand data ("historical buildings with guided tours"), combined with high-weight tags from user memory associations ("attraction preference - cultural relics - historical buildings", "dining preference - non-spicy", "time schedule habit - morning visit") and scene combination identifiers ("historical buildings morning visit + non-spicy dining"). Candidate resources are then filtered around the user's real-time location. For example: Attraction: XX Historical Building Scenic Area (Professional guided tours are available; morning visitor density is below the preset threshold; matches "historical buildings + preference for quiet"). Dining: XX Light Cuisine Restaurant (located within 500 meters of the historical building scenic area, with an average cost of 70 yuan per person, matching the "non-spicy dining + budget constraints"). Transportation: The subway from the user's real-time location to the historical building scenic area (takes 35 minutes, 300 meters walking distance after exiting the station, and is matched with the "medium physical strength" constraint).
[0049] Following this, route optimization employs route planning algorithms (such as Dijkstra's algorithm) to calculate an initial route that balances "time-distance-interest matching degree," combined with optimization algorithms (such as genetic algorithms) to find the optimal solution under constraints such as "1-day trip" and "1200 yuan budget," ultimately generating a structured itinerary plan. For example: 08:30-09:05: Take the subway from the user's real-time location (around the train station) to the XX Historical Building Scenic Area; 09:15-11:45: Visit the XX Historical Building Scenic Area (participate in the 9:30 professional guided tour, matching the "historical building + guided tour service" needs); 12:00-13:00: Dine at XX Light Cuisine Restaurant (steamed dishes and mushroom dishes are recommended to match the preference for "non-spicy food"); 13:15-13:50: Take the subway back to the vicinity of the user's real-time location; Estimated total cost: Transportation 16 yuan + Scenic spot entrance ticket (including guided tour) 98 yuan + Food 70 yuan = 184 yuan (in line with the budget constraint of 1200 yuan).
[0050] S6. Acquire multimedia data, determine candidate insertion nodes based on the trip planning, filter target multimedia data from the multimedia data based on the user memory association, insert the multimedia data into the candidate insertion nodes, and obtain multimedia push content.
[0051] In this embodiment, the multimedia data is visual or audio content stored in the system's preset multimedia database, specifically including short videos of scenic spots, pictures of food and beverages, audio narration clips, etc., which are used to enrich the itinerary display and cater to user preferences.
[0052] Multimedia data insertion and push content generation: Combining key aspects of itinerary planning with user memory associations, push content is generated through the logic of "content matching - node determination - trigger setting," as follows: 1. Multimedia Data Filtering: Extract key elements from the itinerary planning ("Visiting XX Historical Building Scenic Area", "Dining at XX Light Cuisine Restaurant"), and combine them with high-weight tags from user memory associations to filter highly relevant content from the multimedia database. For the "Historical Building Scenic Area Tour" segment: Select 1 minute and 30 second short videos of the core buildings of the XX Historical Building Scenic Area (including guided tour introduction, marked "Highlights of Historical Building Tour", matched with "Attraction Preferences - Cultural Relics - Historical Buildings"). For the "Dining at Light Cuisine Restaurants" section: Select high-resolution images of steamed and mushroom dishes from XX Light Cuisine Restaurant (labeled "Recommended Non-Spicy Dishes" and matched with "Food Flavor - Non-Spicy").
[0053] 2. Insertion Node and Trigger Condition Settings: Based on the time nodes of the trip planning and the user's possible location changes, determine the insertion nodes and trigger methods for multimedia data: Short videos of historical building scenic spots: The insertion node is "08:30-09:05 (during subway journey)", and the trigger condition is "automatically play a 15-second preview when the user opens the journey page, and click to view the full video"; Images of dishes at light-flavored restaurants: Insert the node "12:00 (before dining)" and the trigger condition is "display in a pop-up window on the itinerary page when the user arrives within 300 meters of the historical building scenic area".
[0054] 3. Multimedia push content generation: The filtered multimedia data is integrated with the itinerary planning text to form structured push content. Each key link on the itinerary planning page is accompanied by a corresponding multimedia entry point, labeled "Click to view videos of historical buildings and scenic spots" or "Click to view pictures of recommended dishes". Users can view them as needed, which not only caters to user preferences but also avoids interfering with the itinerary viewing experience.
[0055] In some optional implementations of this embodiment, the step of analyzing the user tags to obtain the tag type described above includes: Based on the interaction data, determine whether the source of the user tag meets the condition of the user actively conveying the need; if so, the user tag is an explicit tag. In this embodiment, the system first presets three quantifiable criteria for judging proactive demand, covering common forms of users directly expressing preferences in cultural and tourism scenarios. Meeting any one of these criteria is considered to meet the "conditions for proactively conveying demand," as detailed below: 1. Clear expression in voice interaction: The text translated by voice recognition (ASR) of user voice input contains keywords that point to cultural and tourism preferences, such as "want XX", "want XX", "like XX", and the keywords can accurately correspond to the core content of the tag (e.g., if the tag contains "traditional architecture", the translated text must contain similar expressions such as "traditional architecture" or "old architecture"). 2. Active text input: The text content that users fill in in the system input box (not the system preset options) directly includes a preference description related to the tag (e.g., if the tag is "spicy - low interest", the text input must include clear negative preferences such as "don't eat spicy food" or "don't choose spicy food"). 3. Active confirmation of operation interaction: On the system's "Preference Settings" and "Trip Initialization" pages, users can actively click or check the preset preference options, and the content of the options must be completely consistent with the core content of the tag (e.g., if the tag contains "depart in the morning", the user needs to actively check the "morning" time period option).
[0056] Based on the system's pre-defined conditions for proactively transmitting needs, information is extracted from the system's stored multimodal interaction logs according to the correspondence between "tags" and "interaction data" to ensure data traceability and verifiability. Specifically, data can be obtained from three directions: voice, text, and operation. Among them, voice interaction data is obtained by acquiring the user's speech-to-text and timestamp—08:45:20 on [Date], 2024, the translated result is "Want to go to a place with traditional architecture, leave in the morning, don't want to choose spicy food for lunch," and the page scene at the time of the interaction is extracted (the current page is the "Attraction Type Filter Page"); text interaction data is obtained by reading the input box operation log—08:48:10 on [Date], 2024, the user entered "Don't want to choose spicy food for lunch" in the "Supplement Dining Preferences" input box; operation interaction data is obtained by reading the page click log—08:50:30 on [Date], 2024, the user clicked the "Morning" option on the "Time Selection" page (not the system's default selected state).
[0057] After obtaining the data, key entity recognition and intent matching techniques (such as the BERT-CRF model) are used to verify the consistency between the core content of the tags to be analyzed and the actively expressed information. The specific judgment process is shown in the following example: When analyzing the tag "attraction preference - historical sites - traditional architecture", the core content of the tag "traditional architecture" can be extracted. It perfectly matches the key entity "traditional architecture" in the speech-to-text "want to go to places with traditional architecture", which meets the standard of "explicit expression in voice interaction". Therefore, it is determined that the tag generation meets the condition of "user actively conveying needs" and is identified as an explicit tag. When analyzing the tag "Time Management Habits - Departing in the Morning", the core content of the tag "Departing in the Morning" can be extracted. It matches both the speech-to-text "Departing in the Morning" ("Morning" and "Morning" overlap in time period) and the "Morning" option actively clicked by the user. It meets the two criteria of "clear expression in voice interaction" and "active confirmation in operation interaction". The double verification meets the conditions and is determined to be an explicit tag. When analyzing the tag "Food Taste - Spicy - Low Interest", we can extract the core content of the tag "Spicy - Low Interest". By searching all actively expressed data (voice, text, and actions), only the text input "I don't want to choose spicy food" mentions "spicy". However, "I don't want to choose spicy food" is a negative and vague expression (it does not explicitly say "I don't like spicy food" and may only be a single request). It cannot be directly determined as "actively conveying a request". Therefore, it is excluded as an explicit tag and proceeds to the next step of implicit tag judgment.
[0058] Based on the interaction data, determine whether the source of the user tag meets the preset preference association conditions. If so, the user tag is an implicit tag.
[0059] In this embodiment, the system presets a "behavior-preference" mapping rule, inferring potential preferences based on users' involuntary operational behaviors (skip, stay, close). The core rules are as follows: 1. Rule for skipping similar content repeatedly: If a user repeatedly performs the "skip" or "close" operation on the same type of cultural and tourism content (such as spicy food recommendations or non-traditional architectural attractions) pushed by the system, and skips the content ≥ 2 times, it can be inferred that the user has low interest in this type of content; 2. Dwell Time Difference Rule: If a user's dwell time on a certain type of cultural and tourism content is more than 50% lower than the system average dwell time for that type of content, it can be inferred that the user has low interest in that type of content; 3. Actively Ignore Operation Rules: When a user clicks the "Not Interested" or "Don't Recommend Again" button in the system's push content, it can be directly inferred that the user has low interest in this type of content. In this embodiment, based on historical data statistics, the average dwell time for "Spicy Food Recommendations" is 1 minute. Therefore, "dwell time < 30 seconds" is set as the judgment threshold of "less than 50% of the average dwell time".
[0060] Furthermore, extract user behavior information related to "spicy food" within the past 7 days from the system operation logs, such as: On [Date] at 08:52:15: The system pushed out a list of "Local Spicy Dishes Restaurants Ranking". The user clicked the "Close" button (considered as skipping the operation). On [Date] at 09:20:40: the system displayed a "Spicy Hot Pot" card in the "Restaurant Recommendation" module. The user paused for 22 seconds and then clicked "Skip". On [Date] at 10:15:30: A system pop-up recommends "Spicy Snack Street," and the user directly clicks "Close" (skipped for the 3rd time). There are no records of users clicking the "Not interested" button.
[0061] Next, the extracted behavioral data is compared one by one with the rules of the "preset preference association conditions" to determine whether the mapping relationship is satisfied: First, the skip frequency was verified. The number of times the user skipped the content related to "spicy food" was 3 times, which is ≥2 times of the preset threshold, thus meeting the "rule of skipping similar content continuously". Next, the dwell time was verified. The user's dwell time for viewing the "Spicy Hot Pot" card was 22 seconds < 30 seconds (50% of the average dwell time of 1 minute), which met the "dwell time difference rule". Ultimately, a comprehensive assessment was conducted, and both types of behavior met the "preset preference association conditions," with no opposite behavior (such as actively clicking on spicy food recommendations). Therefore, the generation of the tag "food flavor - spicy - low interest" satisfies the "preset preference association conditions" and is identified as an implicit tag.
[0062] As a reference, by following the steps above, the type analysis of the three user tags is completed, and the final output results are as follows: Explicit tags: "Attraction preferences - Historical sites - Traditional architecture" and "Time management habits - Departing in the morning" (both meet the condition of "users actively conveying their needs"); Implicit label: "Food taste - spicy - low interest" (satisfies "preset preference association conditions").
[0063] In the steps above, the type of user tag has been determined, where: Explicit tags: "Attraction preferences - Historical sites - Ancient towns" (the user proactively mentioned "want to visit an ancient town" 3 times), "Time management habits - Morning visits" (the user proactively selected "morning time slot" 2 times); Implicit tag: "Food taste - spicy - low interest" (The user skipped spicy food recommendations 4 times; the tag was generated 10 days ago).
[0064] In some optional implementations of this embodiment, the step of determining the tag weight of each user tag based on the tag type, as described above, includes: S31. If the user tag is an explicit tag, then extract the first interaction frequency from the interaction data, and determine the first initial weight of the explicit tag based on the first interaction frequency and the preset explicit weight. In this step, the first interaction frequency refers to the "number of interactions in which the user actively conveys their needs" corresponding to the explicit label, which needs to be extracted from the system interaction log—only valid interactions in which the user explicitly expresses their needs through voice, actively inputs text, and actively confirms their actions (the three types of active conditions defined in claim 2) are counted, excluding duplicate and invalid interactions (such as repeatedly inputting the same content within 1 minute); the preset explicit weight is a basic coefficient of the explicit label that is pre-set by the system, used to amplify the impact of interaction frequency on the weight, and is set to 0.8 in combination with the stability of preferences in cultural and tourism scenarios (the value range is 0.5-1.0, and the coefficient takes a higher value because the explicit label has high credibility); the formula for calculating the first initial weight is first initial weight = first interaction frequency × preset explicit weight.
[0065] Specifically, the processing of explicit tags can be referenced in the following process: For the explicit tag "Attraction Preferences - Historical Sites - Ancient Towns", valid interaction records were extracted from the interaction logs - 09:00 (voice "Want to visit an ancient town"), 09:15 (text "Recommend ancient town attractions"), 10:30 (check "Ancient town preference"), a total of 3 valid interactions, i.e., the first interaction frequency = 3; the first initial weight = 3 × 0.8 = 2.4.
[0066] For the explicit tag "Time Management Habits - Morning Tour": Extract valid interaction records - 09:20 on [Date] (with "Morning Time" selected) and 11:10 (voice message "Leaving home in the morning"), a total of 2 valid interactions, first interaction frequency = 2; first initial weight = 2 × 0.8 = 1.6.
[0067] If the user tag is an implicit tag, then the second interaction frequency and time parameter are extracted from the interaction data, and the time decay factor is determined based on the time parameter; Based on the second interaction frequency and the time decay factor, the second initial weight of the implicit label is determined; In this step, the second interaction frequency refers to the number of times the user triggers the preset preference association conditions corresponding to the implicit label, which needs to be extracted from the operation log - only count the valid behaviors that meet the "continuous skip" and "difference in dwell time" (implicit conditions defined in claim 2), and exclude erroneous operations (such as withdrawing within 10 seconds after clicking "skip"). The time parameter refers to the number of days (Δt) between the implicit tag generation time and the current calculation time. It is obtained by reading the tag creation time from the tag generation log and subtracting it from the current system time. The time decay factor is a coefficient set based on the time parameter, used to weaken the impact of outdated behavior on the weight. The rules are: when Δt ≤ 7 days (within 1 week), the factor = 1.0; when 7 days < Δt ≤ 14 days (1-2 weeks), the factor = 0.9; when Δt > 14 days (more than 2 weeks), the factor = 0.7. In summary, the formula for calculating the second initial weight is: Second initial weight = Second interaction frequency × Time decay factor.
[0068] Specifically, the processing of implicit tags can be referenced as follows: First, the second interaction frequency was extracted by reading the valid actions from the operation log: 09:30 (skipping Sichuan cuisine recommendations), 10:00 (closing the hot pot pop-up), 14:20 (skipping spicy snack recommendations), and 16:10 (closing the spicy dish ranking), totaling 4 valid actions, i.e., the second interaction frequency = 4. The time parameter was also extracted, for example, the tag generation time was 2024-09-09 (10 days ago), and the current calculation time was 2024-09-09 + 10 days, Δt = 10 days (belonging to the category of 7 days < Δt ≤ 14 days). Then, the time decay factor was determined: 0.9 according to the rules. Finally, the second initial weight was calculated as 4 × 0.9 = 3.6.
[0069] S32. Obtain real-time interactive data, and adjust the first initial weight and the second initial weight based on the real-time interactive data to obtain the first final weight and the second final weight respectively.
[0070] In this step, the real-time interaction data refers to the new interaction data related to the tag generated by the user within 24 hours after the initial weight is calculated in step S31. This includes: new active expressions (voice / text) and new operational behaviors (skip / stay / check). The data needs to be cleaned (filtering interjections and correcting typos) before use. The weights are adjusted based on real-time interactive data, and the adjustment rules are as follows: Explicit label: If a new active expression is added, the first interaction frequency is added to the number of new entries, and the first final weight is recalculated according to the "first initial weight calculation formula" to obtain the first final weight; if no new entries are added, the first final weight = the first initial weight. Implicit label: If a new operation is added, the second interaction frequency is added to the number of new operations, and the time parameter (Δt is updated to "the interval between the label generation time and the real-time interaction time") and the time decay factor are recalculated. The second final weight is obtained by recalculating according to the "second initial weight calculation formula". If there is no new operation, the second final weight = the second initial weight.
[0071] For reference, here is an example of extracting real-time interaction data and adjusting the weights: The first final weight adjustment for explicit tags: For "Attraction Preferences - Historical Sites - Ancient Towns", extract real-time interaction data—8 hours after step S31, a user's voice statement "Want to visit an ancient town with old alleys" (a new proactive statement) adds 1 valid interaction, updating the first interaction frequency to 3+1=4; the first final weight = 4×0.8=3.2. For "Time Management Habits - Morning Visits", no new proactive statements were added within 24 hours, so the first final weight = 1.6 (consistent with the first initial weight).
[0072] The second final weight adjustment for the implicit tag: For "Food Flavor - Spicy - Low Interest", extract real-time interaction data - 12 hours after step S31, the user skips "Spicy Grilled Fish Recommendation" (which is a new operation behavior), adding 1 valid behavior, and the second interaction frequency is updated to 4+1=5; recalculate the time parameter: the real-time interaction time is 12 days after the tag is generated, Δt=12 days (still belonging to 7 days < Δt ≤ 14 days), and the time decay factor remains at 0.9; the second final weight = 5 × 0.9 = 4.5.
[0073] In some optional implementations of this embodiment, the above-described method of establishing user memory associations based on the tag weights and the interaction data includes: S41. Extract the time features, scene features, and behavioral features corresponding to the user tags from the interaction data; In this embodiment, the three types of features need to cover the three dimensions of "time-scene-behavior" generated by the label, and the extraction source is the system multimodal interaction log (stored in the MySQL interaction log table, which can be read by calling the SQL interface through Python script). Among them, time features refer to the precise time information when the tag is generated, including the interaction timestamp (accurate to the second, used to trace the generation timing) and the interval between the tag generation time and the current calculation time (denoted as Δt, used for subsequent time dimension division); scene features refer to the interaction scene information when the tag is generated, including the current operation page (such as "Ancient Town Scenic Spot Recommendation Page" and "Dining Preference Settings Page", extracted from page jump logs), the user's current demand scenario (such as "Short Trip Inquiry" and "Daily Dining Selection", inferred from interaction context keywords), and scene-related keywords (such as "morning" in the user's voice "Want to visit the ancient town, go in the morning", extracted from ASR translated text); and behavioral features refer to the user operation behavior corresponding to the tag generation, including behavior type (voice input / text input / page click / skip, extracted from operation type logs), behavior frequency (such as the "Ancient Town" tag corresponding to 3 active voices, counted from repeated interaction records), and behavior duration (such as the dwell time when viewing the Ancient Town Recommendation Page, extracted from page dwell logs).
[0074] Specifically, log parsing scripts written in Python (using the pymysql library to connect to the log database) can extract data according to the one-to-one correspondence between "label" and "feature". The results are as follows: 1. For the tag "Attraction Preferences - Historical Sites - Ancient Towns": Time characteristics: Interaction timestamp 2024 Month X Day 09:00:00, Δt=3 days (the difference between the current calculation time and the tag generation time); Scenario characteristics: The operation page is a "recommendation page for ancient town attractions", the demand scenario is "short trip query", and the scenario-related keywords are "ancient town" and "short trip". Behavioral characteristics: The behavior type is "voice input + text supplement" (1 voice "want to visit the ancient town", 2 text supplements "recommendation of ancient towns"), the behavior frequency is 3 times, and the page stay time is 2 minutes and 30 seconds.
[0075] 2. Regarding the tag "Time Management Habits - Morning Sightseeing": Time characteristics: Interaction timestamp 2024 Month X Day 09:15:00, Δt=3 days; Scenario characteristics: The operation page is a "time period selection page", the demand scenario is "short-distance trip query", and the scenario-related keyword is "morning"; Behavioral characteristics: The behavior type is "page check" (checking the "morning" option twice), the frequency of the behavior is 2 times, and the page stay time is 45 seconds.
[0076] 3. Regarding the tag "Food Flavor - Spicy - Low Interest": Time characteristics: Interaction timestamp 2024 Month X Day 10:30:00, Δt=10 days; Scenario characteristics: The operation page is a "restaurant recommendation page", the demand scenario is "daily restaurant selection", and the scenario-related keywords are "spicy" and "restaurant". Behavioral characteristics: The behavior type is "skip + close pop-up" (skipping spicy food recommendations 4 times and closing hot pot pop-up once), the frequency of behavior is 5 times, and the page stay time is 22 seconds.
[0077] S42. Based on the time characteristics, the user tags are divided into recent tag groups and historical tag groups; In this embodiment, based on the sliding window algorithm logic and considering the short-term preference cycle of users in cultural and tourism scenarios (usually within one month), the time segmentation threshold is set to 30 days (sliding window duration = 30 days). The specific rules are as follows: Recent tag group: The interval Δt between the tag generation time and the current calculation time is ≤30 days (i.e., tags generated within 30 days, reflecting the user's latest preferences); Historical tag group: The interval Δt between the tag generation time and the current calculation time is greater than 30 days (i.e., tags generated 30 days ago, reflecting the user's historical preferences). By using a sliding window algorithm to iterate through the Δt values of all labels (obtained from the time features extracted from S41), the labels are automatically classified into their corresponding label groups without manual intervention. The algorithm code can be implemented using the pandas library in Python (data is filtered by the Δt threshold).
[0078] Based on the Δt data extracted from S41, the division is as follows: Recent tag groups (Δt≤30 days): "Attraction preference - Cultural relics - Ancient towns" (Δt=3 days), "Time management habits - Morning visits" (Δt=3 days), "Food taste - Spicy - Low interest" (Δt=10 days); Historical tag groups (Δt > 30 days): Retrieve tags generated 30 days ago from the system tag library (MySQL table storing historical tags) - "Attraction Preference - Natural Landscape - Lakes" (weight 2.1, Δt = 45 days) and "Food Taste - Light - High Interest" (weight 2.8, Δt = 50 days).
[0079] S43. Select user tags whose tag weight is higher than a preset threshold in the recent tag group as the first core tag, and select user tags whose tag weight is higher than a preset threshold in the historical tag group as the second core tag; In this embodiment, a preset threshold for core tags can be set to 1.5 (tags below this value are considered weak user preferences and are not included in the association, thus avoiding diluting core needs). The selection logic is as follows: Recent tag group: Iterate through the "final weight" of all tags (calculated by claim 3), and select tags with a weight > 1.5 as the first core tags; Historical tag group: Iterate through the "historical final weight" of all tags (extracted from the system's historical weight log table, which is the calculation result of claim 3 when the tag was generated), and filter out tags with a weight > 1.5 as the second core tags.
[0080] The specific selection results are as follows: The first core tags (recent tag group, weight > 1.5): "Attraction preference - cultural relics - ancient towns" (weight 3.2), "Time arrangement habits - morning visits" (weight 1.6), "Food taste - spicy - low interest" (weight 4.5); The second core tags (historical tag group, weight > 1.5): "Attraction preference - natural landscape - lake" (weight 2.1), "Food taste - light - high interest" (weight 2.8).
[0081] S44. Analyze the correlation between the first core tag and the second core tag. If the correlation meets the preset correlation conditions, then establish the temporal correlation between the recent tag group and the historical tag group. In this embodiment, this step uses a similarity algorithm to calculate the correlation between tags, and the specific settings are as follows: The correlation calculation dimension only considers the "category dimension + subcategory" of the tag (e.g., "Scenic Spot Preference - Historical Sites" and "Scenic Spot Preference - Natural Landscape" have the same category dimension but different subcategories), excluding the influence of "specific content" (e.g., "ancient town" and "lake") to ensure dimension consistency; the similarity value can range from 0 to 1, and the closer the value is to 1, the higher the correlation between tags (the stronger the semantic correlation of subcategories under the same dimension); the preset correlation condition can be correlation ≥ 0.7 (that is, the tags belong to the same category dimension and the subcategories have a semantic complementary or continuous relationship, which is considered to meet the correlation requirement).
[0082] In this embodiment, cosine similarity calculation is implemented using Python's scikit-learn library (calculating after converting "classification dimension + sub-category" into a vector). The specific process is as follows: 1. Calculate the correlation between “Attraction Preference - Historical Sites - Ancient Towns” (first core label) and “Attraction Preference - Natural Landscapes - Lakes” (second core label): Both are classified under the dimension of “Attraction Preference”, but the semantic similarity between the subcategories “Historical Sites” and “Natural Landscapes” is 0.3 (lower than 0.7), which does not meet the preset correlation conditions, and no temporal correlation is established. 2. Calculate the correlation between "Food Flavor - Spicy - Low Interest" (first core label) and "Food Flavor - Mild - High Interest" (second core label): Both are categorized under "Food Flavor," and the subcategories "Spicy - Low Interest" and "Mild - High Interest" have complementary preferences (users who avoid spicy food prefer mild food). The semantic similarity is 0.8 (≥0.7), satisfying the preset correlation conditions. Establish a temporal correlation: Record "Correlation Type = Temporal Correlation," "Labels of Both Parties = Food Flavor - Spicy - Low Interest / Food Flavor - Mild - High Interest," and "Time Difference = 40 days" (historical label Δt50 days - recent label Δt10 days) in the correlation log. 3. Calculate the correlation of "Time Management Habits - Morning Tour" (first core tag). There are no tags in the historical tag group with the "Time Management Habits" category dimension, no related objects, and no time sequence relationship is established.
[0083] S45. Based on the scene characteristics, filter user tags that frequently appear in the same interaction scene to obtain scene combination tags; In this embodiment, based on the Apriori algorithm logic (used to discover high-frequency co-occurrence patterns), the filtering parameters are set as follows: The same interaction scenario refers to the continuous operations of a user under the same demand scenario (such as the "short trip query" scenario is all the interactions when the user queries a short trip, and the "daytime dining selection" scenario is all the interactions when the user selects a restaurant for the day). It is determined from the "demand scenario" field of the scenario features extracted from S41. The high-frequency co-occurrence threshold is when a tag appears at the same time in the same scenario ≥ 2 times (i.e., the number of co-occurrences ≥ 2 is considered as a stable preference combination of users in that scenario). Based on the above conditions, the label list under each scenario is traversed using the Apriori algorithm (extracted from the features of scenario S41), the number of co-occurrences of labels is counted, and the label combinations that meet the frequency threshold are selected. The algorithm code can be implemented based on the mlxtend library in Python (by calling the apriori function to set the minimum support = 2 / total number of interactions).
[0084] For reference, the following example of this step is analyzed: Analyzing the short-distance trip query scenario, the tags appearing in this scenario are "Attraction Preference - Historical Sites - Ancient Town" and "Time Management Habits - Morning Visit". According to the interaction log statistics, both appeared simultaneously in the user's three "Short-Distance Trip Query" operations, with a co-occurrence count of 3 times (≥2 times), meeting the high-frequency co-occurrence condition. Therefore, the scenario combination tag "Short-Distance Trip - Morning Visit to Ancient Town" is generated (naming rule: demand scenario + core tag combination). Alternatively, for reference, analyzing the "Daily Dining Selection" scenario, the tags appearing in this scenario are "Dining Flavor - Spicy - Low Interest" and "Dining Flavor - Light - High Interest". The co-occurrence count is 2 times (≥2 times), meeting the high-frequency co-occurrence condition. Therefore, the scenario combination tag "Daily Dining - Light Preference (Avoid Spicy)" is generated.
[0085] S46. Establish scene association relationships based on the scene combination tags and the user tags; In this embodiment, based on the "node-edge" model logic (user-tag-scene as nodes, association relationship as edges), scene association is established with "scene combination tags as core nodes, user tags as associated nodes," and the rules are as follows: The associated object is only associated with the user tags involved in the generation of each scene combination tag (i.e., tags that frequently co-occur in S45). The association attributes are labeled "Association Type = Scene Association", "Co-occurrence Frequency" (the number of times the tag co-occurs in the scene, obtained from the S45 statistics) and "Association Strength" (Association Strength = Tag Weight / 5, with the weight normalized to 0-1 to ensure that the strength is comparable). The association storage is to record the association relationships in the association table of the Neo4j graph database (nodes are scene combination labels / user labels, and edges are association attributes).
[0086] Here are two examples for reference: 1. Scene combination tag "Short trip - Morning tour of the ancient town": Related tag 1: "Attraction preference - Cultural relics - Ancient town", with the association attributes of "co-occurrence frequency 3 times, association strength 0.64" (3.2 / 5); Related tag 2: "Time management habits - morning tour", with the association attributes of "co-occurrence frequency 3 times, association strength 0.32" (1.6 / 5); 2. Scene combination tag "Daily Dining - Light Preference (Avoid Spicy Food)": Associated tag 1: "Food taste - spicy - low interest", with the association attributes of "co-occurrence frequency 2 times, association strength 0.9" (4.5 / 5); Related tag 2: "Food taste - light - high interest", with the association attributes of "co-occurrence frequency 2 times, association strength 0.56" (2.8 / 5).
[0087] S47. Integrate the temporal association and the scene association to obtain the user memory association.
[0088] In this embodiment, Neo4j, a non-relational graph database (suitable for storing node-edge relationships), is used for integration. The nodes and edges are defined as follows: the core nodes are user nodes (storing user IDs, such as "U001") and scene combination tag nodes (such as "short trip - morning tour of the ancient town"); the intermediate nodes are user tag nodes (such as "attraction preference - cultural relics - ancient town"); the edge attributes are the edge label "weight" between users and tags (calculated by claim 3), the edge label "association type = scene association", "co-occurrence frequency", and "association strength" between tags and scene combination tags, and the label "association type = time association" and "time difference" between tags with time-series association.
[0089] Integration operations are implemented using Neo4j's Cypher statements (e.g., creating a node: CREATE(t:Tag{name:'Attraction Preferences-Historical Sites-Ancient Town',weight:3.2}); creating an edge: MATCH(u:User),(t:Tag)WHEREu.id='U001'ANDt.name='Attraction Preferences-Historical Sites-Ancient Town'CREATE(u)-[r:has_preference{weight:3.2}]->(t)).
[0090] The resulting graph database structure is shown below: User U001 - (has_preference, weight: 3.2) -> Attraction Preferences - Historical Sites - Ancient Towns - (scene_relation, type:scene-related, frequency: 3, strength: 0.64) -> Short Trip - Morning Visit to the Ancient Town; User U001 - (has_preference, weight: 1.6) -> Time management habits - Morning tour - (scene_relation, type: scene association, frequency: 3, strength: 0.32) -> Short trip - Morning tour of the ancient town; User U001 - (has_preference, weight: 4.5) -> Food taste - spicy - low interest - (time_relation, type: time-series correlation, time_diff: 40 days) -> Food taste - light - high interest; User U001 - (has_preference, weight: 4.5) -> Food taste - spicy - low interest - (scene_relation, type: scene association, frequency: 2, strength: 0.9) -> Today's food - light preference (avoid spicy); User U001 - (has_preference, weight: 2.8) -> Food taste - light - high interest - (scene_relation, type: scene association, frequency: 2, strength: 0.56) -> Today's food - light preference (avoid spicy food).
[0091] In some optional implementations of this embodiment, the steps described above for obtaining real-time demand data and determining trip planning based on the user memory association and the real-time demand data include: S51. Obtain real-time demand data, which includes destination demand data, itinerary constraint data, and real-time location data; In this embodiment, destination demand data refers to the user's currently explicitly stated core destination and detailed needs, which are obtained through the system's multimodal interaction module. This includes voice input data, text input data, and preference supplementation. Specifically, voice input data is the user stating their needs through the system's voice interface, which are then translated into text by Automatic Speech Recognition (ASR), such as "I want to go to a nearby ancient town where I can take pictures of old buildings on the weekend, preferably less crowded." Text input data is the user filling in keywords in the system's "Destination Supplementation" input box, such as "ancient towns around Y city, Ming and Qing dynasty old buildings." Preference supplementation data is the user's selection of "avoiding peak hours" and "needing guided tours" in a system pop-up prompt, which is then added to the destination demand data.
[0092] Trip constraint data refers to the trip restrictions set by the user, which can be obtained through the system's "Trip Constraint Settings" page. The page provides preset options and custom input boxes: specific trip constraint data includes total trip days, total budget amount, and physical fitness level, etc. Among them, the total trip days are selected by the user to check "1 day" (the system presets "1 day / 2 days / 3 days+" options), the total budget amount is entered by the user in the custom input box as "within 800 yuan", and the physical fitness level is selected by the user to check "medium" (the system presets three levels "weak / medium / strong", corresponding to "single day walking ≤6000 steps / 8000 steps / 12000 steps", with medium physical fitness corresponding to ≤8000 steps).
[0093] Real-time location data refers to the user's current geographic coordinates, obtained through the system's positioning module. Real-time location data includes positioning method, positioning frequency, and location mapping. The positioning method can be achieved by calling GPS / BeiDou positioning function through the mobile APP, returning latitude and longitude with an accuracy of within 10 meters (e.g., "30.1234°N, 120.5678°E"). The positioning frequency can be set to once every 5 minutes to avoid frequent positioning and consume battery power, while ensuring real-time location accuracy. Location mapping can be achieved by converting latitude and longitude into specific geographic location names through the map API, such as "City Center of Y (near the intersection of XX Road and XX Road)".
[0094] The specific steps to obtain the results are as follows. The final real-time demand data for this trip planning is as follows: Destination demand data: "Weekend visits to ancient towns around Y City, including Ming and Qing dynasty buildings, with guided tours available, and priority given to areas with fewer crowds"; Trip constraints: "Total trip 1 day, total budget ≤ 800 yuan, physical fitness moderate (daily walking ≤ 8000 steps)"; Real-time location data: "City center of Y (30.1234°N, 120.5678°E)".
[0095] S52. Extract the temporal correlation features and scenario correlation features of the destination demand data; In this embodiment, based on the time-series association records in the established user memory association relationship, tag association information related to destination demand data ("ancient town + old buildings") is filtered: Recent tags: "Attraction preferences - Historical sites - Ancient towns" (weight 3.2, generated 3 days ago, claim 4 recent tag group); Historical tags: "Attraction preferences - Cultural relics - Ancient villages" (weight 1.9, generated 45 days ago, claim 4 historical tag group); Based on the above tags, both belong to the "attraction preference - cultural relics" dimension. The semantic correlation between the subcategories "ancient town" and "ancient village" is ≥0.7 (calculated by cosine similarity algorithm), which meets the temporal correlation condition. This correlation is extracted as a temporal correlation feature.
[0096] Furthermore, based on the scene combination tags in the established user memory association relationships, scene information that matches the destination demand data ("ancient town + less crowded") is filtered: Target scenario combination tag: "Short trip - Morning visit to the ancient town" (generated by claim 4, associated with "Attraction preference - Cultural relics - Ancient town" and "Time arrangement habits - Morning visit"); Supplementary preference matching: The "emotional tendency - preference for quiet" (weight 2.2, implicit label) associated with this scenario's combined label matches the destination's "less crowded" requirement, and the "morning visit" time period corresponding to the scenario aligns with the requirement to "avoid peak crowds" (historical data shows that the crowd density in the ancient town is 40% lower in the morning than in the afternoon). Feature integration combines scene combination labels and associated preferences into scene-related features.
[0097] The specific extraction results are as follows: the temporal correlation feature is "the preference for cultural and historical sites continues (recent preference for 'ancient towns' → preference for historical 'ancient villages'), and the core demand direction is 'cultural and historical sites with traditional buildings'"; the scenario correlation feature is "in the case of short-distance travel, the morning is the preferred time to visit ancient towns, and it needs to match the demand for 'quiet (low flow of people)', and is also associated with the preference for light meals".
[0098] S53. Based on the temporal correlation features, the scene correlation features and the destination demand data, multiple preference information related to the destination demand data are matched and filtered from the user memory correlation relationship, and the preference information is integrated to obtain the user's core itinerary demand. In this embodiment, it is necessary to first determine whether the "demand direction" of the time-series correlation feature is consistent with the "core destination type" of the destination demand data. For example, the "cultural and historical sites" of the time-series correlation feature and the "ancient towns (including Ming and Qing dynasty old buildings)" of the destination demand data both belong to the category of cultural and historical sites, with a matching degree of 100%. The corresponding preference information "prefer to select ancient towns with traditional buildings" is retained.
[0099] It is also necessary to determine whether the "scene elements" of the scene-related features match the "refined requirements" of the destination demand data, for example: The scene-related feature of "morning tour time" matches the destination's need to "avoid peak hours", and the preference information "the ancient town tour time is set to the morning" is retained; Alternatively, the scene-related feature of "preferring quiet (low crowds)" matches the destination's need for "low crowds," so the preference information is retained to "filter ancient towns with low real-time crowd density." Alternatively, the scene-related features "food taste - light - high interest" (weight 2.8) need to be matched synchronously, retaining the preference information "pairing the trip with light food".
[0100] Next, prioritize according to tag weights (the higher the weight, the higher the priority): prioritize ancient towns with traditional architecture and cultural relics (corresponding to "Attraction Preference - Cultural Relics - Ancient Towns" weight 3.2, priority 1); include light meals in the itinerary (corresponding to "Food Taste - Light - High Interest" weight 2.8, priority 2); filter ancient towns with low real-time crowd density (corresponding to "Emotional Tendency - Preference for Quiet" weight 2.2, priority 3); set the time for visiting ancient towns to be in the morning (corresponding to "Time Management Habits - Morning Visit" weight 1.6, priority 4).
[0101] The integrated requirements form a structured core demand: "Visit ancient towns around Y City that contain historical sites and cultural relics, including Ming and Qing dynasty buildings, within one day. Prioritize visiting ancient towns in the morning when the real-time crowd density is low. Include light meals in the itinerary. The total budget must be ≤800 yuan, the daily walking distance must be ≤8000 steps, and the ancient towns must support guided tours."
[0102] S54. Based on the itinerary constraint data and the destination demand data, determine the geographical scope of the itinerary planning; In this embodiment, determining the geographical scope requires first obtaining the core constraint parameters, then calculating the scope based on the core constraint parameters, and finally obtaining the specific geographical scope result.
[0103] The core constraint parameters include time constraints, destination constraints, and transportation mode coverage. Specific examples are as follows: The time constraint is a total trip of 1 day, and the one-way travel time must be ≤1.5 hours (to avoid excessive travel time compressing the sightseeing time); the destination constraint can be based on "ancient towns around Y City" as the core, combined with real-time location data (Y City center) to define the scope; transportation mode coverage can include driving and public transportation / subway (if the user does not specify a transportation mode, the mainstream options must be covered).
[0104] Furthermore, the system uses Python's geopy library in conjunction with a map API (such as Baidu Maps API). Inputting the real-time location (city center of Y) and a travel time threshold (1.5 hours), the system obtains the travel time for different modes of transportation via the map API: a 1.5-hour driving range (average speed 60 km / h, coverage radius approximately 90 km) and a 1.5-hour bus / subway range (coverage radius approximately 50 km). The final geographic range is defined as the intersection of the coverage areas of the two modes of transportation (ensuring that users can reach the destination within 1.5 hours regardless of whether they choose driving or public transportation), and the system outputs the latitude and longitude of the range boundaries (e.g., "30.0000°N-30.2500°, 120.3000°E-120.8000°").
[0105] For example, the geographical scope of the itinerary planning is "starting from the city center of Y City, covering the intersection of a 1.5-hour drive and a 1.5-hour bus / subway journey, specifically including the administrative areas of A Ancient Town, B Ancient Town and C Ancient Town under the jurisdiction of Y City, as well as supporting restaurants and transportation stations in the area (such as bus stops and parking lots around A Ancient Town)".
[0106] S55. Based on the geographical scope of the itinerary plan and the user's core itinerary needs, candidate cultural and tourism resources are selected from the preset cultural and tourism resource database; The pre-set cultural and tourism resource database stores information on cultural and tourism resources whose geographical coordinates match the geographical scope of the itinerary plan. Specifically, it includes scenic spot resources (including types such as natural landscapes and historical sites, and attributes such as real-time visitor flow, opening hours, and service capabilities), catering resources (including attributes such as taste type, consumption level, and location), transportation resources (including attributes such as route, time, and cost), and supporting service resources (including attributes such as guided tours and parking facilities). All resource information is associated with feature tags that can match the user's core itinerary needs (such as preferences for scenic spot types, catering tastes, and service needs).
[0107] In this embodiment, the candidate resource classification and screening mainly includes three dimensions: attractions, restaurants, and transportation.
[0108] The candidate attraction selection can combine information obtained from the user's core travel needs and real-time demand data interfaces. The selection criteria are as follows: Type matching: Ancient towns with cultural relics and historical sites containing old buildings from the Ming and Qing dynasties (matching keywords such as "Ming and Qing architecture" and "old courtyards" through scenic area description text); Crowd control: Real-time crowd density < 50 people / thousand square meters (data obtained through the scenic area's real-time crowd flow API, such as 38 people / thousand square meters for Ancient Town A, 62 people / thousand square meters for Ancient Town B, and 45 people / thousand square meters for Ancient Town C). Service matching: Guided tours are supported (by checking the scenic area ticketing API, it can be found that Ancient Town A offers guided tours, Ancient Town C offers electronic audio guide rentals, and Ancient Town B does not offer guided tours). Opening hours: Open after 8:00 AM (to accommodate morning visits, Ancient Town A is open from 8:30 AM to 5:00 PM, and Ancient Town C is open from 8:00 AM to 5:30 PM). Based on the above screening criteria, the candidate scenic spots are Ancient Town A and Ancient Town C.
[0109] For reference, the selection of candidate restaurants can be combined with a preference for "light dining" and budget constraints. The selection criteria are as follows: Flavor matching: The type of restaurant is light cuisine (such as Zhejiang cuisine or Cantonese cuisine). The dish tags are obtained through the catering platform API, and restaurants with tags such as "steamed", "blanched" and "light" are selected. Location constraints: Located within 1 kilometer of the candidate ancient town (to reduce walking distance, such as Restaurant D near Ancient Town A, or Restaurant E near Ancient Town C). Budget constraint: Average spending per person ≤ 100 yuan (total budget within 800 yuan, average spending per person at Restaurant D is 75 yuan, average spending per person at Restaurant E is 85 yuan). Based on the above screening criteria, the candidate restaurants are Restaurant D (around A Ancient Town) and Restaurant E (around C Ancient Town).
[0110] Furthermore, the candidate transportation filtering can combine real-time location with candidate attractions to filter mainstream transportation modes: By car: It takes 1 hour and 20 minutes to drive from the city center of Y to A Ancient Town and 1 hour and 40 minutes to drive to C Ancient Town (both ≤ 1.5 hours, meeting the time constraints). There are 3 parking lots along the way (searchable via map API). Public Transportation: There are direct bus lines from the city center of Y City to Ancient Town A (1 hour and 30 minutes) and to Ancient Town C (1 hour and 25 minutes), both of which support real-time arrival tracking. Based on the above screening criteria, the candidate transportation options are "driving (A / C Ancient Town)" and "public transportation (A / C Ancient Town)".
[0111] After obtaining the three dimensions of screening criteria—attractions, dining, and transportation—the candidate cultural and tourism resources are summarized as follows: Candidate attractions: Town A (including Ming and Qing dynasty buildings, guided tours, open in the morning, low visitor flow), Town C (including Ming and Qing dynasty buildings, electronic guided tours, open in the morning, low visitor flow); Candidate restaurants: Restaurant D (near A Ancient Town, light flavors, 75 RMB per person), Restaurant E (near C Ancient Town, light flavors, 85 RMB per person); Candidate transportation options: by car (1 hour 20 minutes for Town A, 1 hour 40 minutes for Town C), by public transport (1 hour 30 minutes for Town A, 1 hour 25 minutes for Town C).
[0112] S56. Based on the real-time location data and the candidate cultural and tourism resources, determine the itinerary plan.
[0113] In this embodiment, determining the route planning requires selecting a path calculation algorithm, followed by route optimization and constraint verification.
[0114] Specifically, the Dijkstra algorithm (suitable for calculating the optimal solution of the shortest path) can be used for path calculation. Starting from the "real-time location (city center of Y)" and ending at candidate attractions, the path is calculated by combining time parameters, interest matching degree, and number of steps taken. A specific example is as follows: Time parameters: travel time (driving / public transportation), sightseeing time (3.5 hours for Town A and 3 hours for Town C, calculated based on the area of the scenic spot and walking route), and dining time (1 hour). Interest matching degree: The degree of matching between candidate attractions and core needs (Ancient Town A includes guided tours, matching degree 90%; Ancient Town C provides electronic guided tours, matching degree 80%). Walking steps: Approximately 5,000 steps for the A Ancient Town tour route and approximately 4,500 steps for the C Ancient Town tour (both ≤ 8,000 steps, in line with physical fitness requirements).
[0115] After obtaining the route, itinerary optimization and user experience constraints are necessary. Optimization can be performed from three dimensions: time optimization, budget verification, and secondary confirmation of passenger flow. Specific examples are as follows: Time optimization can prioritize a more balanced combination of "transportation time + sightseeing time", such as "driving to A Ancient Town (1 hour 20 minutes) + sightseeing 3.5 hours + dining 1 hour + return trip 1 hour 20 minutes", with a total time of 7 hours 10 minutes (can be completed within 1 day). For budget verification, you can refer to the following example: A Ancient Town entrance fee 80 yuan + self-driving fuel cost 60 yuan + D Restaurant meal 150 yuan (for 2 people), total cost 290 yuan (≤800 yuan, within budget constraints). The flow of people can be reconfirmed through the scenic area's real-time flow API to confirm the real-time flow density of A Ancient Town (35 people / thousand square meters, which still meets the low flow requirement).
[0116] After optimization and verification, the final plan can be obtained, for example: 08:30-09:50 Depart for Ancient Town A: Drive from the city center of Y City, along the XX Expressway (the navigation route is generated by the map API, prioritizing uncongested sections), and finally arrive at the South Gate Parking Lot of Ancient Town A (driving time 1 hour 20 minutes, estimated fuel cost 60 yuan, ample parking spaces, online reservations supported). 10:00-13:30 Ancient Town Tour: Meet at the South Gate Visitor Center of Ancient Town A at 10:00 and follow a guided tour (guided tour from 10:00-12:30, fee included in the ticket price) to tour the Ming and Qing Dynasty architectural complex, focusing on XX Courtyard (a representative of Qing Dynasty residential buildings) and XX Ancient Street (a well-preserved stone-paved street). 12:30-13:00 Short rest in the rest area of the ancient town (20 minutes). The entire tour takes 3 hours and 30 minutes. Ticket price is 80 yuan / person. Approximately 5000 steps are required. 13:40-14:40 Dining: Walk 5 minutes from the south gate of A Ancient Town to D Restaurant. Recommended dishes are steamed fish (signature dish) and stir-fried seasonal vegetables (light flavor, matching the "dining taste - light - high interest" preference). The estimated cost is 75 yuan per person, and the total cost for 2 people is 150 yuan. The meal takes 1 hour and involves walking about 800 steps. 14:50-16:10 Return trip: Walk 5 minutes from Restaurant D back to the South Gate Parking Lot of Ancient Town A, then drive back to the city center of Y (driving time 1 hour 20 minutes, estimated fuel cost 60 yuan, navigation route avoids evening rush hour). Additional itinerary notes: Total time: 7 hours and 10 minutes, total cost: 350 yuan (2 people), approximately 5800 steps walked. An alternative plan is also provided: If Ancient Town A suddenly implements visitor restrictions (e.g., real-time crowd density > 50 people / 1000 square meters), the itinerary will be changed to: "10:00 Take bus 302 to Ancient Town C (1 hour 25 minutes, 8 yuan / person) + 11:25-14:25 Visit Ancient Town C (electronic guide rental 20 yuan / unit) + 14:35-15:35 Dinner at Restaurant E (85 yuan per person) + 15:45 Take bus 302 back." The alternative plan costs a total of 320 yuan (2 people), ensuring the feasibility of the itinerary.
[0117] In some optional implementations of this embodiment, the process of acquiring multimedia data, determining candidate insertion nodes based on the trip planning, filtering target multimedia data from the multimedia data based on the user memory association, and inserting the target multimedia data into the candidate insertion nodes to obtain multimedia push content includes: S61. Based on the user memory association relationship, extract relevant user tags related to the itinerary planning from multiple user tags; In this embodiment, relevant user tags refer to tags in the user's memory association that highly match the attributes of key aspects of the trip planning. They must simultaneously meet two conditions: "the category dimension to which the tag belongs is consistent with the attributes of the trip aspect" and "the tag weight is greater than or equal to the set core tag threshold of 1.5". The extraction process relies on the constructed Neo4j graph database and is implemented using Cypher queries. First, the attributes of key aspects of the itinerary planning are broken down. For example, "A Ancient Town Tour" corresponds to the attributes "Attraction Type - Historical Sites (Ancient Town), Time of Day - Morning, Need - Quiet (Low Crowd)". "D Light Dining Restaurant" corresponds to the attributes "Dining Flavor - Light, Location - Surrounding Area of A Ancient Town". Then, tags from user memory associations are linked. Matching "Attraction Type - Historical Sites" extracts "Attraction Preference - Historical Sites - Ancient Town", matching "Time of Day - Morning" extracts "Time Management Habits - Morning Tour", matching "Need - Quiet" extracts "Emotional Tendency - Preference for Quiet", and matching "Dining Flavor - Light" extracts "Dining Flavor - Light - High Interest". Finally, the extracted results are organized according to the Softcom template's "Tag Structured Format" into attraction-related tags "Attraction Preference - Historical Sites - Ancient Town" and "Emotional Tendency - Preference for Quiet", dining-related tags "Dining Flavor - Light - High Interest", and time-of-day related tags "Time Management Habits - Morning Tour".
[0118] S62. Determine the matching degree between the relevant user tags and multiple multimedia data in a preset multimedia database, and filter out target multimedia data whose matching degree meets the preset requirements from the multiple multimedia data; In this embodiment, the preset multimedia database contains basic information, tag attributes, and format parameters for each piece of multimedia data. The basic information includes the content ID, title, and storage path. The tag attributes label 2-3 core tags, and the format parameters include the short video duration, image resolution, and audio segment duration. The matching degree is calculated using a tag matching algorithm, combined with the weights of relevant user tags to construct the formula: "Matching Degree = Σ (Semantic Similarity between Candidate Content Tag and Relevant User Tag × Relevant User Tag Weight) / Σ Relevant User Tag Weight." The semantic similarity is calculated using the Word2Vec model and ranges from 0 to 1. The preset matching degree threshold is set to the recommended 0.7. In the specific filtering process, firstly, relevant user tags were entered to retrieve 10 multimedia data entries from the database. Then, the matching degree was calculated for each entry. For example, the short video "A Tour Route of Ming and Qing Architecture in Ancient Town" was tagged with "Ancient Town - Ming and Qing Architecture" and "Morning Tour". It had a semantic similarity of 0.9 with "Attraction Preference - Cultural Relics - Ancient Town" and 0.8 with "Time Arrangement Habits - Morning Tour". The matching degree was calculated as (0.9×3.2 + 0.8×1.6) / (3.2+1.6)≈0.86, which met the threshold requirement. The image "Steamed Fish + Vegetable Set Meal" was tagged with "Light - Steamed Dishes" and "Dining Around Ancient Town". It had a semantic similarity of 0.95 with "Dining Taste - Light - High Interest". The matching degree was 0.95, which met the threshold requirement. Finally, 7 multimedia data entries with a matching degree ≥0.7 were selected, including 2 short videos of ancient towns, 3 images of light dining, and 2 audio descriptions.
[0119] S63. Extract the core attributes of key travel segments in the travel planning, and determine candidate insertion nodes for multimedia data based on the core attributes; In this embodiment, the core attributes of key itinerary links refer to the characteristics of links in itinerary planning that have a direct impact on user experience, including time attributes, type attributes, and location attributes. The time attribute includes the start / end time and duration of the link, the type attribute refers to the type of content of the link, and the location attribute is the geographical location where the link occurs. The core attributes of three key itinerary links are extracted from the itinerary planning: "08:30-09:50 Driving to Ancient Town A" has the time attribute "Start at 08:30", the type attribute is "Transportation", and the location attribute is "City Center Y → Ancient Town A"; "10:00-13:30 Sightseeing in Ancient Town A" has the time attribute "Start at 10:00", the type attribute is "Sightseeing", and the location attribute is "Ancient Town A"; and "13:40-14:40 Light Dining at Restaurant D" has the time attribute "Start at 13:40", the type attribute is "Dining Experience", and the location attribute is "Restaurant D". The selection of candidate insertion nodes is based on the contextualized node selection logic, adhering to the principles of not interfering with trip viewing and providing advance guidance to users. The insertion node for the transportation segment is set to "10 minutes before the segment starts", the insertion node for the attraction tour segment is set to "5 minutes after the segment starts", and the insertion node for the dining experience segment is set to "20 minutes before the segment starts". The final candidate insertion nodes are: the "Pre-trip Guidance" node associated with "Driving to Ancient Town A" at time "08:20", the "Key Tips During the Tour" node associated with "Tour of Ancient Town A" at time "10:05", and the "Pre-dining Recommendation" node associated with "Light Dining at Restaurant D" at time "13:20". The node information is organized according to the node structure format.
[0120] S64. Based on the core attributes, the multimedia data is adapted to obtain the content to be promoted; In this embodiment, the adaptation process needs to be adapted from the perspectives of format adaptation, content adaptation, and preference adaptation. Format adaptation adjusts the content format according to the scenario of the inserted node (e.g., users may use a small mobile phone screen during the transportation process, so the short video length is controlled to 1-2 minutes; during the tour process, a full 3-minute video can be played). Content adaptation supplements information related to the core attributes of the itinerary (e.g., marking time, location, and precautions), and generates adapted text through NLG technology. Preference adaptation incorporates the preferences of relevant user tags (e.g., the "prefers quiet" tag, which marks "areas with fewer people in the morning" in the ancient town content).
[0121] Specifically, a two-step method of "formatting adjustment + text supplementation" can be used, employing Python's OpenCV (video editing), Pillow (image processing), and NLG module (text generation): Formatting adjustments: Short videos are edited to extract core segments, and images are adjusted to a mobile-friendly resolution (1080×1920). Text supplement: Generate guiding text based on the core attributes of the process, such as "
Tourist Tips for Town A
[0122] For reference, the multimedia data filtered by S62 was adapted to obtain 3 core pending promotional content items (other content items are as alternatives): Pending content 1 (related node 1): Short video "Overview of Ancient Town A" (original length 3 minutes, adapted to 1 minute 30 seconds, retaining the introduction of the ancient town entrance and parking lot location), supplemented with NLG text "[Departure Tip] There are 10 minutes left to go to Ancient Town A. This video includes parking lot navigation instructions. Click to view". Pending content 2 (related node 2): Short video "Explanation of Ming and Qing architecture in Ancient Town A" (original length 2 minutes 30 seconds, adapted to 2 minutes, focusing on XX courtyard), supplemented with text "[Tourist Tips] You have entered Ancient Town A. This video contains a guided tour of key points. The current area has fewer people, so you can visit it first." Pending content 3 (related node 3): Image "Steamed Fish + Vegetable Set Meal" (resolution adapted to 1080×1920), supplementary text "[Dining Recommendation] 20 minutes away from D Restaurant. This set meal is light and mild, matching your dining preferences. 75 yuan per person."
[0123] S65. Based on the time nodes of the trip planning and the user's memory association, set the trigger conditions for pushing the pending promotional content; In this embodiment, the triggering conditions are divided into two categories: The first is time-triggered: Based on the time nodes of the itinerary planning (such as "08:20" in node 1), combined with the "time arrangement habits" tag in the user's memory association relationship (such as "morning tour" with a weight of 1.6, indicating that the user is used to preparing in advance in the morning), set "automatic trigger when the time is up"; The second method is location-triggered: Based on the location attributes of the trip (such as A Ancient Town, D Restaurant), a GPS fence is set through the GPS positioning interface (Softcom template "Positioning Interface Specification"). When the user enters the fence area, it is triggered. The fence radius is set according to the scenario (500 meters for scenic spots, 300 meters for restaurants).
[0124] For each pending promotional content, a dual-insurance model of "primary trigger condition + backup trigger condition" is adopted: the primary trigger condition is the core attribute of the priority matching scenario (such as time trigger for transportation, and location trigger for sightseeing / dining); the backup trigger condition is the backup condition (such as time trigger) if the primary condition is not triggered (such as weak GPS signal).
[0125] For further reference, the specific trigger condition settings are as follows: 1. Pending content 1 (Node 1): Main trigger condition: Time trigger (automatically triggered when the system time reaches 08:20); Alternative trigger condition: Location trigger (triggered when the user leaves the city center of Y City and enters the main road leading to Ancient Town A); 2. Pending content 2 (Node 2): Main trigger condition: Location trigger (triggered when the user enters the 500-meter GPS fence range of Ancient Town A); Alternate trigger condition: Time trigger (automatically triggered when the system time reaches 10:05); 3. Pending content 3 (Node 3): Main trigger condition: Location trigger (triggered when the user enters the 300-meter GPS fence range of Restaurant D); Alternate trigger condition: Time trigger (automatically triggered when the system time reaches 13:20).
[0126] S66. Based on the candidate insertion nodes and the triggering conditions, the pending promotion content is organized, and the multimedia push content is finally generated; If the triggering conditions are met, the pending promotional content will be inserted into the candidate insertion node to obtain multimedia push content.
[0127] In this embodiment, the organization process follows the principle of one-to-one correspondence between nodes, content, and triggering conditions. First, candidate insertion nodes and pending promotion content are bound to triggering conditions. Then, the display format is defined according to the content type. Short videos are set to "auto-play 15-second preview + click to watch the full video", and images are set to "pop-up display + manual closure". Finally, the integrated content is embedded into the generated itinerary planning page. Each key link is accompanied by a "multimedia entry" label. The whole process must meet the requirements of structured push, including four elements: "link identifier, content preview, triggering method, and display format", and is presented using a combination of text and icons. For example, the "08:30-09:50 Self-driving to Ancient Town A" section is marked "View Ancient Town A Navigation Video" as a multimedia entry point. The content preview is a short video cover, and the trigger prompt is marked "Automatic push at 08:20 / Push after leaving the city". The display format is that a 15-second preview is automatically played when pushed, and clicking the cover can view the full video. The "10:00-13:30 Tour of Ancient Town A" section is marked "View Explanation of Ming and Qing Architecture". The content preview is a short video cover of the main gate of XX Courtyard. The trigger prompt is marked "Push after entering Ancient Town A 500 meters / Automatic push at 10:05". The display format is that a pop-up plays the full video and includes crowd flow information. The "13:40-14:40 Light Dining at Restaurant D" section is marked "View Recommended Dishes". The content preview is a thumbnail of a steamed fish set meal. The trigger prompt is marked "Push after entering Restaurant D 300 meters / Automatic push at 13:20". The display format is that a pop-up displays a high-definition image and NLG recommendation text. In accordance with the experience protection rules, the system was set to "no more than 5 multimedia push notifications per day" and "60-minute cooldown time for the same type of content". This push only had 3 notifications and no duplicate content, which meets the experience protection requirements.
[0128] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware through computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).
[0129] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.
[0130] Further reference Figure 3 As a response to the above Figure 2 The implementation of the method shown in this application provides an embodiment of a document travel itinerary planning and push system. This device embodiment is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.
[0131] like Figure 3 As shown, the travel itinerary planning and push system 300 described in this embodiment includes: a data processing module 301, a tag type analysis module 302, a tag weight calculation module 303, a relationship establishment module 304, an itinerary planning module 305, and a push module 306. Wherein: The data processing module 301 is used to acquire interaction data and generate multiple user tags based on the interaction data and preset classification dimensions; The tag type analysis module 302 is communicatively connected to the interactive data acquisition and tag generation module, and is used to receive user tags output by the interactive data acquisition and tag generation module, analyze each user tag, and obtain the tag type corresponding to each user tag. The tag weight calculation module 303 is communicatively connected to the tag type analysis module and is used to receive the tag type output by the tag type analysis module and determine the tag weight of each user tag based on the tag type. The association establishment module 304 is communicatively connected to the tag weight determination module and the interaction data acquisition and tag generation module, respectively, and is used to receive the tag weight output by the tag weight determination module and the interaction data output by the interaction data acquisition and tag generation module, and establish user memory association based on the tag weight and the interaction data. The itinerary planning module 305 is communicatively connected to the user memory association module, and is used to obtain real-time demand data and determine the itinerary plan based on the user memory association and the real-time demand data; The push module 306 is communicatively connected to the real-time demand processing and itinerary planning module and the user memory association module, respectively. It is used to acquire multimedia data, determine candidate insertion nodes based on the itinerary planning, filter target multimedia data from the multimedia data based on the user memory association, and insert the multimedia data into the candidate insertion nodes to obtain multimedia push content.
[0132] To address the aforementioned technical problems, embodiments of this application also provide a computer device. Please refer to [link / reference needed]. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.
[0133] The computer device 4 includes a memory 41, a processor 42, and a network interface 43 that are interconnected via a system bus. It should be noted that only the computer device 4 with components 41-43 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described here is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.
[0134] The computer device can be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device can interact with the user via a keyboard, mouse, remote control, touchpad, or voice control.
[0135] The memory 41 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, disk, optical disk, etc. In some embodiments, the memory 41 may be an internal storage unit of the computer device 4, such as the hard disk or memory of the computer device 4. In other embodiments, the memory 41 may also be an external storage device of the computer device 4, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 4. Of course, the memory 41 may also include both the internal storage unit and its external storage device of the computer device 4. In this embodiment, the memory 41 is typically used to store the operating system and various application software installed on the computer device 4, such as computer-readable instructions of the # method, etc. In addition, the memory 41 can also be used to temporarily store various types of data that have been output or will be output.
[0136] In some embodiments, the processor 42 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 42 is typically used to control the overall operation of the computer device 4. In this embodiment, the processor 42 is used to execute computer-readable instructions stored in the memory 41 or to process data, for example, to execute computer-readable instructions of the # method.
[0137] The network interface 43 may include a wireless network interface or a wired network interface, which is typically used to establish communication connections between the computer device 4 and other electronic devices.
[0138] This application also provides another embodiment, namely, a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the document travel planning and push method described above.
[0139] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.
[0140] Obviously, the embodiments described above are only some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the patent scope of this application. This application can be implemented in many different forms; rather, the purpose of providing these embodiments is to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of patent protection of this application.
Claims
1. A method for planning and pushing cultural tourism itineraries, characterized in that, Includes the following steps: S1. Obtain interaction data, and generate multiple user tags based on the interaction data and preset classification dimensions; S2. Analyze each user tag to obtain the tag type corresponding to each user tag; S3. Based on the tag type, determine the tag weight of each user tag; S4. Based on the tag weights and the interaction data, establish a user memory association relationship; S5. Obtain real-time demand data, and determine the itinerary plan based on the user memory association relationship and the real-time demand data; S6. Acquire multimedia data, determine candidate insertion nodes based on the trip planning, filter target multimedia data from the multimedia data based on the user memory association, insert the target multimedia data into the candidate insertion nodes, and obtain multimedia push content.
2. The method for planning and pushing cultural and tourism itineraries according to claim 1, characterized in that, The analysis of the user tags yields tag types, including: Based on the interaction data, determine whether the source of the user tag meets the condition of the user actively conveying the need; if so, the user tag is an explicit tag. Based on the interaction data, determine whether the source of the user tag meets the preset preference association conditions; if so, the user tag is an implicit tag.
3. The method for planning and pushing cultural and tourism itineraries according to claim 2, characterized in that, The step of determining the tag weight for each user tag based on the tag type includes: S31. If the user tag is an explicit tag, then extract the first interaction frequency from the interaction data, and determine the first initial weight of the explicit tag based on the first interaction frequency and the preset explicit weight. If the user tag is an implicit tag, then the second interaction frequency and time parameter are extracted from the interaction data, and the time decay factor is determined based on the time parameter; Based on the second interaction frequency and the time decay factor, the second initial weight of the implicit label is determined; S32. Obtain real-time interactive data, and adjust the first initial weight and the second initial weight based on the real-time interactive data to obtain the first final weight and the second final weight respectively.
4. The method for planning and pushing cultural and tourism itineraries according to claim 1, characterized in that, The step of establishing user memory associations based on the tag weights and the interaction data includes: S41. Extract the time features and scene features corresponding to the user tags from the interaction data; S42. Based on the time characteristics, the user tags are divided into recent tag groups and historical tag groups; S43. Select user tags whose tag weight is higher than a preset threshold in the recent tag group as the first core tag, and select user tags whose tag weight is higher than a preset threshold in the historical tag group as the second core tag; S44. Analyze the correlation between the first core tag and the second core tag. If the correlation meets the preset correlation conditions, then establish the temporal correlation between the recent tag group and the historical tag group. S45. Based on the scene characteristics, filter user tags that frequently appear together in the same interaction scene to obtain scene combination tags; S46. Establish scene association relationships based on the scene combination tags and the user tags; S47. Integrate the temporal association and the scene association to obtain the user memory association.
5. The method for planning and pushing cultural and tourism itineraries according to claim 1, characterized in that, The step of acquiring real-time demand data and determining trip planning based on the user's memory associations and the real-time demand data includes: S51. Obtain real-time demand data, which includes destination demand data, itinerary constraint data, and real-time location data; S52. Extract the temporal correlation features and scenario correlation features of the destination demand data; S53. Based on the temporal correlation features, the scene correlation features and the destination demand data, multiple preference information related to the destination demand data are matched and filtered from the user memory correlation relationship, and the preference information is integrated to obtain the user's core itinerary demand. S54. Based on the itinerary constraint data and the destination demand data, determine the geographical scope of the itinerary planning; S55. Based on the geographical scope of the itinerary plan and the user's core itinerary needs, candidate cultural and tourism resources are selected from the preset cultural and tourism resource database; S56. Based on the real-time location data and the candidate cultural and tourism resources, determine the itinerary plan.
6. The method for planning and pushing cultural and tourism itineraries according to claim 1, characterized in that, The process of acquiring multimedia data, determining candidate insertion nodes based on the trip planning, filtering target multimedia data from the multimedia data based on the user's memory association, and inserting the target multimedia data into the candidate insertion nodes to obtain multimedia push content includes: S61. Based on the user memory association relationship, extract relevant user tags related to the itinerary planning from multiple user tags; S62. Determine the matching degree between the relevant user tags and multiple multimedia data in a preset multimedia database, and filter out target multimedia data whose matching degree meets the preset requirements from the multiple multimedia data; S63. Extract the core attributes of key travel segments in the travel planning, and determine candidate insertion nodes for multimedia data based on the core attributes; S64. Based on the core attributes, the target multimedia data is adapted to obtain the content to be promoted; S65. Based on the time nodes of the trip planning and the user's memory association, set the trigger conditions for pushing the pending promotional content; S66. Based on the candidate insertion nodes and the triggering conditions, the pending promotion content is organized, and finally the multimedia push content is generated.
7. A travel itinerary planning and recommendation system, used to execute the travel itinerary planning and recommendation method according to any one of claims 1 to 6, characterized in that, include: The data processing module is used to acquire interaction data and generate multiple user tags based on the interaction data and preset classification dimensions; The tag type analysis module is communicatively connected to the interaction data acquisition and tag generation module, and is used to receive user tags output by the interaction data acquisition and tag generation module, analyze each user tag, and obtain the tag type corresponding to each user tag; The tag weight calculation module is communicatively connected to the tag type analysis module, and is used to receive the tag type output by the tag type analysis module, and determine the tag weight of each user tag based on the tag type; The association establishment module is communicatively connected to the tag weight determination module and the interaction data acquisition and tag generation module, respectively, and is used to receive the tag weight output by the tag weight determination module and the interaction data output by the interaction data acquisition and tag generation module, and establish user memory associations based on the tag weight and the interaction data. The itinerary planning module communicates with the user memory association module to obtain real-time demand data and determine the itinerary plan based on the user memory association and the real-time demand data. The push module is communicatively connected to the real-time demand processing and itinerary planning module and the user memory association module, respectively. It is used to acquire multimedia data, determine candidate insertion nodes based on the itinerary planning, filter target multimedia data from the multimedia data based on the user memory association, and insert the multimedia data into the candidate insertion nodes to obtain multimedia push content.
8. A computer device, characterized in that, The method includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the document travel itinerary planning and push method as described in any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the document travel itinerary planning and push method as described in any one of claims 1 to 6.
Citation Information
Patent Citations
Scenic spot recommendation method and device based on user information and storage medium
CN110765361A
Analysis system based on smart travel big data
CN117235362A
Travel guide data pushing method and system and computer equipment
CN117828199A
Tourism service information pushing method and system based on artificial intelligence
CN118410239A
Smart tourism operation media data management system
CN120070003A