Tourism customization service method, apparatus, device, medium, and program product

Abstract

The present application relates to a tourism customized service method, device, equipment, medium and program product, the method comprises the following steps: in response to the conversation request initiated by the user, creating an independent conversation space, carrying out multi-round language conversation in the independent conversation space, and analyzing corresponding travel demand information; demand analysis is carried out on the travel demand information, and the travel demand image is obtained; according to the travel demand image, the available data of the cultural and tourism products of the destination and the travel environment dynamic data are obtained, and the resource landing constraint set is constructed; based on the travel demand image and the resource landing constraint set, the trip is constructed, the customized trip scheme is obtained, and the customized trip scheme is pushed to the independent conversation space. The present application can combine the service resource set verified in real time to carry out trip arrangement and oral incremental modification, and guarantee that the scheme can be landed and adjusted efficiently.

Description

Technical Field

[0001] This invention relates to the technical field of customized tourism, and in particular to a method, apparatus, equipment, medium, and program product for customized tourism services. Background Technology

[0002] With the widespread adoption of online travel services, customized travel services primarily rely on one-on-one communication with human agents or structured data collection tools based on fixed forms. Human customization faces limitations in agent concurrency during peak travel seasons, resulting in long user wait times and linearly increasing labor costs with business scale. Fixed form methods require users to accurately fill in pre-defined fields, leading to stiff interaction, inconsistent with everyday conversational communication, and high abandonment rates. Furthermore, existing solutions generally lack real-time resource data for itinerary planning, relying solely on static attraction and hotel information without simultaneously verifying dynamic data such as ticket availability, weather conditions, and transportation capacity. This results in frequent resource unavailability issues when the generated itinerary is implemented offline. Additionally, once generated, existing itineraries are fixed; users often need to resubmit forms to adjust them, lacking a convenient iterative modification mechanism. Therefore, the industry urgently needs a customized travel technology solution that can collect user needs through natural language interaction, automatically plan implementable itineraries by linking with real-time resource data, and support flexible adjustments. Summary of the Invention

[0003] The main objective of this invention is to provide a method, apparatus, equipment, medium, and program product for customized tourism services. By collecting needs through multi-round dialogue and parsing them into travel profiles, and combining them with a real-time verified service resource set for itinerary arrangement and conversational incremental modifications, the invention reduces human intervention while ensuring the feasibility and efficient adjustment of the plan.

[0004] To achieve the above objectives, the present invention provides a method for customized tourism services, comprising: In response to a user-initiated session request, an independent session space is created, where multi-turn language dialogue takes place, and the corresponding travel demand information is parsed. The travel demand information is analyzed to obtain a travel demand profile; Based on the travel demand profile, obtain available data on cultural and tourism products at the destination and dynamic data on the travel environment, and construct a resource landing constraint set; Based on the travel demand profile and the resource landing constraint set, a customized itinerary is constructed to obtain a customized itinerary plan, which is then pushed to the independent session space.

[0005] Furthermore, in response to a user-initiated session request, an independent session space is created, where multi-turn language dialogue takes place, and corresponding travel demand information is parsed, including: In response to the user initiating the session request, an independent session space is created for the user and the travel request template is initialized; Within the independent conversation space, multiple rounds of language dialogue are conducted with the user to extract the user's expressed basic travel attributes and travel preference features, and integrate them into explicit travel needs; The characteristics of travelers and travel restrictions mentioned by users in multi-round natural language dialogues are captured and integrated into implicit travel needs; The explicit travel demand and the implicit travel demand are aggregated into the travel template to obtain the travel demand information.

[0006] Furthermore, the step of parsing the travel demand information to obtain a travel demand profile includes: The dialogue content is segmented and tagged with parts of speech, and modal particles and irrelevant chatter are filtered out to obtain valid dialogue text; The travel demand information is processed to extract elements, resulting in a demand element set. The effective dialogue text and the structured demand elements are respectively matched with the feature word sets corresponding to each predefined travel intention type. The number of feature word matches for each travel intention type is counted. The travel intention type with the highest number of feature word matches that exceeds the preset number of matches is determined as the travel intention type. Based on the travel intention type, retrieve the corresponding rigid constraint label from the preset constraint condition set corresponding to the feature word set; The travel demand information, the travel intention type, and the rigid constraint label are integrated to obtain the travel demand profile.

[0007] Furthermore, determining the travel intention type as the type with the highest number of feature word hits exceeding a preset hit threshold also includes: When multiple travel intention types have the same number of feature word hits and all exceed the preset hit number threshold, the preset priority weight of each travel intention type is obtained, and the travel intention type with the same number of feature word hits and the highest preset priority weight is determined as the travel intention type. When the feature word set identified as the travel intention type contains mutually exclusive tags, according to the conflict resolution rules corresponding to the mutually exclusive tags, one of the travel intention types with mutually exclusive relationships is retained, and the other is marked as a secondary intention type.

[0008] Furthermore, the step of obtaining available data on cultural and tourism products at the destination and dynamic data on the travel environment based on the travel demand profile includes: Based on the destination information in the travel demand profile, multi-source data interfaces are invoked in parallel to obtain the corresponding cultural and tourism product inventory data, weather data, cross-border travel policy data, and regional transportation capacity data. The bookable resources in the cultural and tourism product inventory data are classified as the available cultural and tourism product data, and the real-time weather data, the cross-border travel policy data, and the regional traffic data are classified as the dynamic travel environment data.

[0009] Furthermore, the constructed resource landing constraint set includes: Based on the demand tags in the travel demand profile, each resource item in the available data of cultural and tourism products is matched and filtered with each data item in the dynamic data of the travel environment. Resource items and data items that do not conform to the demand tags are removed. The remaining available data of cultural and tourism products and the dynamic data of the travel environment are then merged to construct the available service resource set.

[0010] Furthermore, the step of constructing a customized itinerary based on the travel demand profile and the set of available service resources, and then pushing the customized itinerary to the independent session space, includes: Based on the travel demand profile, target scenic spots and available hotel resources are filtered from the available service resources set; Based on the available time slots and geographical location of the target scenic area resources, a daily itinerary is generated, and the nearest target hotel is matched from the available hotel resources according to the start and end points of the daily itinerary. Based on the transportation demand between scenic spots in the daily itinerary, extract the corresponding available transportation capacity data and construct a transportation connection plan. The daily itinerary, the target hotel, and the transportation plan are combined into the customized itinerary and pushed to the independent chat space.

[0011] Furthermore, before combining the daily itinerary, the target hotel, and the transportation plan into the customized itinerary, the following steps are also included: Detect whether the travel rhythm of the daily itinerary matches the travel rhythm preference in the travel demand profile; Detect whether the target hotel matches the budget tier recorded in the travel demand profile; Detect whether the itinerary arrangement boundaries in the daily itinerary plan meet the population matching conditions in the travel demand profile; Once all three tests are passed, the combined operation is performed.

[0012] Furthermore, it also includes, upon receiving user feedback, semantically decomposing the feedback to obtain trip adjustment elements, and iteratively updating the customized trip plan based on these elements to obtain an updated trip plan: When the user provides natural language feedback on the customized itinerary plan that has been pushed to us, the feedback is semantically decomposed to determine the itinerary adjustment elements corresponding to the feedback. Based on the itinerary adjustment elements, retrieve the available resource data corresponding to the itinerary adjustment elements from the available service resource set; Based on the trip adjustment elements and the available resource data, the corresponding parts of the customized trip plan are partially updated, while other parts of the customized trip plan that do not involve the trip adjustment elements remain unchanged, and the updated trip plan is pushed to the independent session space.

[0013] The present invention also provides a travel customization service device, applied to any of the travel customization service methods described above, comprising: The conversation interaction module is used to respond to conversation requests initiated by users, create an independent conversation space, conduct multi-turn language dialogue in the independent conversation space, and parse the corresponding travel demand information. A profile analysis module is used to analyze the travel demand information to obtain a travel demand profile. The resource association module is used to obtain available data of cultural and tourism products at the destination and dynamic data of the travel environment based on the travel demand profile, and to construct a resource landing constraint set. The itinerary scheduling module is used to construct itineraries based on the travel demand profile and the resource landing constraint set, obtain customized itinerary plans, and push the customized itinerary plans to the independent session space.

[0014] The present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the travel customization service method as described in any of the preceding claims.

[0015] The present invention also provides a readable storage medium storing a computer program that, when executed by a processor, implements the steps of the travel customization service method as described in any of the preceding claims.

[0016] The present invention also provides a computer program product comprising a computer program that, when executed by a processor, implements the steps of the customized travel service method described in any of the preceding claims. The present invention provides a method, apparatus, equipment, medium, and program product for customized tourism services, which has the following beneficial effects: By creating independent conversational spaces and collecting travel demand information through multi-turn natural language dialogues, this approach replaces the manual questioning and recording of human agents, reducing reliance on human intervention, supporting a higher number of concurrent conversations, thereby reducing user waiting time and saving labor costs. By identifying travel types and tagging demand information with dialogue content, a structured travel demand profile is created. This eliminates the need for users to fill out fixed forms, conforms to conversational interaction habits, lowers the user interaction threshold, and improves the completion rate of demand collection and the accuracy of subsequent itinerary planning input. By obtaining available data on destination cultural and tourism products and dynamic travel environment data based on the travel demand profile and constructing a set of available service resources, itinerary planning is based on real-time verified available resources. This ensures that all resource items in the generated customized itinerary can be actually implemented, avoiding the problem of itinerary implementation failure due to reliance on static information. When user modification feedback is received, semantic decomposition is performed to determine itinerary adjustment elements, corresponding available resource data is re-acquired, and the generated itinerary is partially iterated and updated. This eliminates the need for users to re-enter or fully regenerate itineraries, reducing the operational complexity and time cost of itinerary adjustments and improving the flexibility and responsiveness of customized tourism services. Attached Figure Description

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

[0018] Figure 1 This is a schematic diagram of a tourism customization service system according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating a method for providing customized tourism services according to an embodiment of the present invention; Figure 3 This is a flowchart illustrating a method for providing customized tourism services according to an embodiment of the present invention; Figure 4 This is a flowchart illustrating a method for providing customized tourism services according to an embodiment of the present invention; Figure 5 This is a flowchart illustrating a method for providing customized tourism services according to an embodiment of the present invention; Figure 6 This is a schematic diagram of a tourism customization service device according to an embodiment of the present invention; Figure 7This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention.

[0019] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. It should also be understood that, as used in this specification and the appended claims, the term "and / or" refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0022] Furthermore, in the description of this invention and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

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

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

[0025] To illustrate the technical solution of the present invention, specific embodiments are described below.

[0026] With the widespread adoption of online travel services, customized travel services primarily rely on one-on-one communication with human agents or structured data collection tools based on fixed forms. Human customization faces limitations in agent concurrency during peak travel seasons, resulting in long user wait times and linearly increasing labor costs with business scale. Fixed form methods require users to accurately fill in pre-defined fields, leading to stiff interaction, inconsistent with everyday conversational communication, and high abandonment rates. Furthermore, existing solutions generally lack real-time resource data for itinerary planning, relying solely on static attraction and hotel information without simultaneously verifying dynamic data such as ticket availability, weather conditions, and transportation capacity. This results in frequent resource unavailability issues when the generated itinerary is implemented offline. Additionally, once generated, existing itineraries are fixed; users often need to resubmit forms to adjust them, lacking a convenient iterative modification mechanism. Therefore, the industry urgently needs a customized travel technology solution that can collect user needs through natural language interaction, automatically plan implementable itineraries by linking with real-time resource data, and support flexible adjustments.

[0027] To address the aforementioned issues, this application proposes a method, apparatus, equipment, medium, and program product for customized tourism services. By creating an independent conversation space and collecting travel demand information through multi-turn natural language dialogue, it can replace the manual inquiry and recording of individual customer service representatives, reducing reliance on human intervention, supporting a higher number of concurrent conversations, thereby reducing user waiting time and saving labor costs. By identifying travel types and tagging demand information with the dialogue content, a structured travel demand profile is formed. This eliminates the need for users to fill out fixed forms, conforms to conversational interaction habits, lowers the user interaction threshold, and improves the completion rate of demand collection and the accuracy of subsequent itinerary planning input. By obtaining available data on cultural and tourism products at the destination and dynamic data on the travel environment based on the travel demand profile and constructing a set of available service resources, itinerary planning is based on real-time verified available resources. This ensures that all resource items in the generated customized itinerary plan can be actually implemented, avoiding the problem of itinerary implementation failure due to reliance on static information. By semantically decomposing user feedback to determine itinerary adjustment elements, re-acquiring corresponding available resource data, and performing partial iterative updates on the generated itinerary, the complexity and time cost of itinerary adjustments are reduced, eliminating the need for users to re-enter or fully regenerate itineraries. This enhances the flexibility and responsiveness of customized travel services.

[0028] The customized travel service method provided in this embodiment of the invention can be applied to, for example... Figure 1 The tourism customization service system shown includes tourism customization services and tourism customization service devices, wherein the terminal devices communicate with the server through a network or bus.

[0029] The customized travel service device can be a terminal device, which refers to a device that corresponds to a server and provides local services to customers. This terminal device includes, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices.

[0030] Among them, the customized tourism service device can also be a server, which can be implemented by a standalone server or a server cluster composed of multiple servers.

[0031] like Figure 2 As shown, the present invention provides a method for customized tourism services, comprising: Step S100: In response to the user's initiated session request, create an independent session space, conduct multi-turn language dialogue in the independent session space, and parse the corresponding travel demand information; Specifically, in response to a user's conversation request initiated through any channel—such as a pop-up window in a travel app, a chat window in a mini-program, or a private message in a public account—a unique encrypted conversation identifier is assigned to the user. A unique, independent conversation space is created for that user, and a blank set of travel demand information and a contextual dialogue cache are initialized. The user is not forced to perform any pre-registration or privacy permission authorization operations, allowing them to enter a natural conversation state with zero pre-operation barriers. Within this independent conversation space, relying on a large language model fine-tuned specifically for cultural tourism, a long-term, multi-turn contextual memory caching mechanism is activated. Through multiple rounds of natural language dialogue with the user, the system proactively guides them to express their travel time, destination range, number of companions, budget level, travel pace, dietary preferences, and transportation preferences. The user's expressed information is extracted as explicit travel parameters, marked, and written into the travel demand information set.

[0032] The aforementioned dialogue interaction process is driven by a specially tuned large language model for cultural tourism. This model has been specifically fine-tuned for cultural tourism travel scenarios and possesses professional cultural tourism knowledge such as travel route arrangement logic, budget tiered understanding, and scenic spot opening and closing rules. Simultaneously, it incorporates a multi-turn context long-term memory unit. After each round of dialogue, the dialogue content is written into the context dialogue cache. Cross-turn semantic association is performed on the dialogue fragments accumulated from multiple rounds of dialogue to capture the user's mentions of elderly care, children traveling with children, people with mobility impairments, pets traveling with children, dietary restrictions, and niche preferences. This captured content is marked as implicit travel needs and written into the travel need information set, thus completing the collection of travel need information.

[0033] Step S200: Analyze the travel demand information to obtain a travel demand profile; Specifically, the dialogue content written into the context dialogue cache in step S100, as well as the explicit travel parameters and implicit travel needs written into the travel demand information set in step S100, are obtained. The dialogue content is segmented and tagged with parts of speech, and interjections and casual chatter unrelated to travel needs are filtered out. At the same time, structured demand elements are extracted from the explicit travel parameters and implicit travel needs.

[0034] The filtered valid dialogue text and extracted structured demand elements are compared with the predefined feature word sets corresponding to each travel intention type to determine the hit rate. The number of feature word hits for each travel intention type is counted, and the travel intention type with the highest number of hits and exceeding the preset threshold is determined as the user's travel intention type. The travel intention types include at least leisure vacation, parent-child study tour, health and wellness travel, outdoor hiking, business travel, and cross-border travel.

[0035] Automatically match preset constraint sets to different travel intentions: Parent-child study tour type: Mandatory labeling of low-intensity routes and essential mother-and-baby support facilities; Types of cross-border exits: Mandatory labeling for visa verification, multilingual support, and essential cross-border transportation. Health and wellness travel type: Mandatory labeling of gentle travel routes and nearby medical emergency needs; Outdoor hiking types: mandatory labeling of physical fitness level and required safety equipment; Business travel type: Mandatory labeling of travel time and meeting-related tags; Leisure and vacation type: mandatory labeling of flexible pace and unique experience tags.

[0036] The aforementioned population suitability conditions, itinerary rhythm restrictions, and supporting facility requirements are integrated into a rigid constraint label. The data structure of this rigid constraint label includes a population suitability field, a rhythm restriction field, and a supporting requirement field, serving as a hard boundary that cannot be violated in subsequent itinerary arrangement.

[0037] Based on the determined travel intention type, corresponding population suitability conditions, travel pace restrictions, and supporting facility requirements are retrieved from the preset constraint set corresponding to the feature word set. The retrieved results are used as rigid constraint labels for this travel demand information. The travel demand information, the determined travel intention type, and the rigid constraint labels are then linked and integrated to obtain the user's travel demand profile.

[0038] Step S300: Based on the travel demand profile, obtain available data of cultural and tourism products and dynamic data of the travel environment at the destination, and construct a set of available service resources; Specifically, the destination information contained in the travel demand profile obtained in step S200 is extracted, and multi-source heterogeneous real-time data interfaces are called in parallel based on the destination information. The multi-source heterogeneous real-time data interfaces include at least the cultural and tourism product inventory interface, the weather forecast interface, the cross-border travel policy interface, and the regional transportation capacity interface.

[0039] By concurrently calling the aforementioned multi-source heterogeneous real-time data interfaces, the system acquires tourism product inventory data, destination weather and environmental data, cross-border travel policy data, and regional transportation capacity data for the destination. The acquired multi-source data is then categorized: resources marked as bookable in the tourism product inventory data are classified as available tourism product data; and the destination weather and environmental data, cross-border travel policy data, and regional transportation capacity data are classified as dynamic travel environment data.

[0040] The available data of the cultural and tourism products and the dynamic data of the travel environment obtained from the classification are synchronized to the cache area in real time. The availability status of each data item in the cache area is checked one by one. Data items that are sold out or unavailable are filtered out. The data items that pass the check are matched and compared with the demand tags in the travel demand profile. Data items that do not meet the demand tags are removed. The remaining available data of the cultural and tourism products and the dynamic data of the travel environment are used to construct a set of available service resources corresponding to the destination.

[0041] Step S400: Based on the travel demand profile and the set of available service resources, construct a travel itinerary to obtain a customized travel itinerary plan, and push the customized travel itinerary plan to the independent session space.

[0042] Specifically, the system uses travel demand profiles as the basis for arrangement and available service resource sets as data support. It selects target scenic spots from these resources that match the demand tags in the travel demand profile, and combines this with the available time slot availability and geographical location information of each target scenic spot recorded in the available service resource set. This process involves daily sorting and time slot allocation to generate daily time-slot itineraries corresponding to the travel demand profile. During the arrangement process, multiple constraints are simultaneously considered, including budget levels, travel pace, demographic suitability, and available offline resources.

[0043] The system first filters target hotels that match the basic travel elements and demographic suitability criteria in the available service resources. Then, based on the start and end points of each scenic spot in the daily itinerary, it matches hotels from the target hotel resources that are closest to those points. Finally, based on the transportation demand between scenic spots in the daily itinerary, it extracts available transportation capacity data for the corresponding segments from the available service resources, matches the connection methods between scenic spots, and generates a transportation connection plan.

[0044] Using the demand tags in the travel demand profile, the consistency of the daily time-sharing itinerary, the matched hotel, and the transportation connection plan is verified item by item to confirm whether all rigid constraint tags in the demand tag are met. After the verification is passed, the daily time-sharing itinerary, the matched hotel, and the transportation connection plan are combined into the customized itinerary plan, and the customized itinerary plan is pushed to the independent conversation space in the form of a structured itinerary card. At the same time, the natural language interpretation text corresponding to the customized itinerary plan is generated.

[0045] This invention provides a method for customized tourism services. By creating an independent conversation space and collecting travel demand information through multi-turn natural language dialogue, it can replace the manual inquiry and recording of human agents, reducing reliance on human intervention, supporting a higher number of concurrent conversations, thereby reducing user waiting time and saving labor costs. By identifying travel types and tagging demand information with the dialogue content, a structured travel demand profile is formed. This eliminates the need for users to fill out fixed forms, conforms to conversational interaction habits, lowers the user interaction threshold, and improves the completion rate of demand collection and the accuracy of subsequent itinerary planning input. By obtaining available data on cultural and tourism products at the destination and dynamic data on the travel environment based on the travel demand profile, and constructing a set of available service resources, itinerary planning is based on real-time verified available resources. This ensures that all resource items in the generated customized itinerary plan can be actually implemented, avoiding the problem of itinerary implementation failure due to reliance on static information. By semantically decomposing user feedback to determine itinerary adjustment elements, re-acquiring corresponding available resource data, and performing partial iterative updates on the generated itinerary, the complexity and time cost of itinerary adjustments are reduced, eliminating the need for users to re-enter or fully regenerate itineraries. This enhances the flexibility and responsiveness of customized travel services.

[0046] like Figure 3 As shown, in one embodiment, step S100: In response to a user-initiated session request, creating an independent session space, conducting multi-turn language dialogue in the independent session space, and parsing the corresponding travel demand information includes: Step S110: In response to the user initiating the session request, create an independent session space for the user and initialize the travel demand template; The travel demand template is a data container that is initialized to a blank state. It contains an explicit travel demand storage area and an implicit travel demand storage area. It is used to gradually collect various travel demand information extracted from the dialogue content during subsequent conversations. The template is empty at the beginning of the conversation and is gradually filled in as the conversation progresses.

[0047] Specifically, when a user clicks on a conversation entry point through any interaction channel—whether it's an embedded chat window within a travel app, a mini-program dialogue interface, or a private message entry point on a public account—a conversation request is generated. Upon receiving this request, the backend conversation management unit assigns a unique, encrypted conversation identifier to the current user. Based on this identifier, a unique conversation space is created, uniquely corresponding to that user, to isolate conversation data, request profiles, and context caches between different users, preventing cross-data leakage. No prior registration or privacy permissions are required; users immediately enter the conversation upon clicking the entry point, with no pre-operation barriers, catering to the convenient usage needs of users of all ages.

[0048] After creating the independent conversation space, initialize a blank travel demand template within the independent conversation space. This travel demand template contains two data storage areas: an explicit travel demand storage area and an implicit travel demand storage area. The explicit travel demand storage area is used to store structured travel parameters extracted during subsequent conversations, such as travel time, destination range, number of companions, budget level, travel pace, dietary preferences, and transportation preferences. The implicit travel demand storage area is used to store unstructured travel constraint information captured during subsequent conversations, such as elderly care, children accompanying, mobility impairments, pets accompanying, dietary restrictions, and niche preferences. Both storage areas are empty during the initialization phase and are gradually filled as the conversation progresses.

[0049] The entire process does not force users to complete any pre-registration procedures or authorize privacy permissions. Users can immediately enter the conversation state after clicking the chat entry point, without any pre-operation threshold, making it suitable for the convenient use needs of users of different ages.

[0050] Step S120: Conduct multi-turn dialogues with the user in the independent conversation space, extract the trip attributes and travel preference features expressed by the user from the dialogue content of the multi-turn dialogues, and integrate them into explicit travel needs; Among them, trip attributes refer to the structured information elements directly related to travel expressed by users in the conversation, including travel time, destination range, number of people traveling with them, and budget level. This information can be extracted by matching through a preset demand slot list.

[0051] Travel preference characteristics: These refer to the personalized travel needs expressed by users in conversations, which tend to reflect their subjective choices. These include the pace of travel, dietary preferences, and preferred modes of transportation. This information reflects users' personalized expectations for their travel experience.

[0052] Explicit travel demand: The structured data set formed by integrating and merging the extracted trip attributes and travel preference features. It is marked as explicit because these are travel parameters that users actively express or explicitly state after being guided by dialogue.

[0053] Specifically, within an independent conversation space, the dialogue engine initiates the first round of dialogue with the user, guiding them to express their travel plans using natural language. Each response from the user is captured in real-time and stored in the context dialogue cache. After each round of dialogue, the dialogue content is matched against a pre-defined list of demand slots. This list includes slots for travel time, destination, number of companions, budget tier, travel pace, food preferences, and transportation preferences. When a statement in the dialogue matches a slot, the corresponding slot value is extracted. For example, the travel time slot value is extracted as a travel time parameter, the destination slot value as a destination range parameter, the number of companions slot value as a number of companions parameter, and the budget tier slot value as a budget tier parameter.

[0054] For the travel rhythm slot, food preference slot, and transportation preference slot, when the dialogue content matches these slots, the extracted rhythm description is mapped to a preset rhythm level value, the food description is mapped to a preset food type value, and the transportation description is mapped to a preset transportation mode value. The parameter values ​​corresponding to the travel attributes extracted in this round of dialogue and the level values ​​corresponding to the travel preference features are integrated into an explicit travel demand fragment for the current round and written into the explicit travel demand storage area of ​​the travel demand template.

[0055] When entering the next round of dialogue, the dialogue engine guides the dialogue based on the parameters already filled in the explicit travel demand storage area, prioritizing the slots that have not yet been acquired, until all the required slots in the preset demand slot list have acquired valid parameter values, thus completing the collection and integration of explicit travel demands.

[0056] Step S130: Capture the travel demographics and travel restrictions mentioned by the user in the conversation and integrate them into implicit travel needs; Among them, traveler characteristics refer to the attributes of fellow travelers mentioned casually in conversations, rather than being directly expressed in the form of needs. This includes the needs of elderly caregivers, children traveling with them, the travel needs of people with mobility impairments, and the needs of pets traveling with them. This information does not directly correspond to the preset needs slots, but it has a constraining effect on the adaptation of the traveler group in the subsequent itinerary arrangement.

[0057] Travel restrictions: These refer to personalized restrictions on travel activities mentioned by users in conversations, including dietary restrictions and niche attraction preferences. These restrictions are indirectly revealed by users in conversations rather than being actively filled in.

[0058] Implicit travel demand: This is an unstructured constraint data set formed by aggregating the captured travel population characteristics and travel restrictions. It is marked as implicit because this information is not a travel parameter directly declared by the user, but is silently captured by the dialogue engine through correlation analysis of multiple rounds of dialogue fragments during the conversation.

[0059] Specifically, after each round of dialogue, the remaining dialogue fragments, excluding the explicit expressions of travel needs extracted from the dialogue content of that round, are matched with a preset implicit constraint word set. The preset implicit constraint word set includes a subset of population characteristics and a subset of restrictive conditions. The subset of population characteristics includes keywords for elderly care, children accompanying, people with mobility impairments, and pets accompanying. The subset of restrictive conditions includes keywords for dietary restrictions and niche preferences.

[0060] When a conversation fragment contains a statement that matches any keyword in the subset of demographic characteristics, that statement is extracted and marked as a travel demographic characteristic of the corresponding type. For example, if the user's conversation fragment contains keywords related to elderly caregivers, it is marked as an elderly caregiver travel demographic characteristic; if it contains keywords related to children traveling with parents, it is marked as a children traveling with parents; if it contains keywords related to people with mobility impairments, it is marked as a people with mobility impairments; and if it contains keywords related to pets traveling with parents, it is marked as a pet traveling demographic characteristic. Similarly, when a conversation fragment contains a statement that matches any keyword in the subset of restrictive conditions, that statement is extracted and marked as a travel restriction condition of the corresponding type. For example, if the user's conversation fragment contains keywords related to dietary restrictions, it is marked as a dietary restriction travel restriction condition; and if it contains keywords related to niche preferences, it is marked as a niche preference travel restriction condition.

[0061] The travel population characteristics and travel restrictions obtained from the current round of labeling are merged into the implicit travel demand fragments of this round and written into the implicit travel demand storage area of ​​the travel demand template. This data is stored in parallel with the explicit travel demand storage area data in step S120, thus completing the collection and integration of implicit travel demands.

[0062] Step S140: Collect the explicit travel demand and the implicit travel demand into the travel template to obtain the travel demand information.

[0063] Specifically, after completing the data collection process in steps S120 and S130, when all the required slots in the preset demand slot list have obtained valid parameter values ​​and the number of dialogue rounds has reached the preset minimum dialogue round threshold, all parameters written in the explicit travel demand storage area and all constraint identifiers written in the implicit travel demand storage area in the travel demand template are summarized and collected to form the travel demand information for this session.

[0064] The travel demand information includes explicit parameter fields and implicit constraint fields. Explicit parameter fields record values ​​for various parameters such as travel time, destination range, number of companions, budget level, travel pace, dietary preferences, and transportation preferences. Implicit constraint fields record indicators for elderly companionship, children accompanying, mobility impairments, pets accompanying, dietary restrictions, and niche preferences. The collected travel demand information is written to the data output buffer in an independent session space, serving as input data for step S200, thus completing the travel demand information collection process.

[0065] The method provided in this embodiment guides users to express their travel needs through multi-turn dialogues and extracts them as explicit travel needs. Simultaneously, it silently captures casually mentioned travel demographics and restrictions as implicit travel needs, eliminating the need for users to fill out fixed forms during the needs collection process. This lowers the interaction threshold for specific groups and reduces the likelihood of users abandoning the process due to cumbersome form-filling. By matching the dialogue content with a preset list of needs slots and a preset set of implicit constraint terms, the method can distinguish between actively declared travel parameters and indirectly revealed constraint information, improving the completeness and accuracy of travel needs information collection. By creating an independent encrypted session space for each user and initializing a blank travel needs template, the method achieves session data isolation and needs information aggregation without requiring prior registration or privacy permissions. This ensures data security in multi-user concurrent scenarios and allows for convenient access for users of all ages with zero upfront operational barriers.

[0066] like Figure 4 As shown, in one embodiment, step S200: performing demand parsing on the travel demand information to obtain a travel demand profile includes: Step S210: Perform word segmentation and part-of-speech tagging on the dialogue content, filter out modal particles and idle chatter fragments unrelated to travel, and obtain valid dialogue text; Specifically, all the dialogue content written into the context dialogue buffer in step S100 is acquired, word segmentation processing is performed on the dialogue content sentence by sentence, each continuous natural language text of each sentence is segmented into an independent word fragment sequence according to semantic units, and each word fragment retains its sequence information in the original sentence. After the word segmentation processing is completed, part-of-speech tagging is performed on each word fragment in the word fragment sequence one by one, and each word fragment is tagged as a corresponding part-of-speech category according to a pre-set part-of-speech tagging mapping table for the travel field. The part-of-speech categories at least include a noun category, a verb category, an adjective category, a modal particle category, and a conjunction category, wherein the noun category covers travel-related entity words such as destination names, scenic spot names, transportation mode names, and food type names. After the part-of-speech tagging is completed, the word fragment sequence is traversed, the word fragments tagged as the modal particle category are removed from the sequence, the modal particle category at least includes colloquial common terms with no substantial travel information such as "ba", "ne", "a", and "ma", and the word fragments tagged as the conjunction category and carrying no travel semantic association are removed at the same time.

[0067] For the remaining word fragment sequence after removing the modal particles and irrelevant conjunctions, the word fragment sequence is further matched with a pre-set travel-unrelated chat word set, the original sentence fragments corresponding to the word fragments of greeting category, weather chat category, and emotion expression category that are matched and hit are removed from the dialogue content, and substantial dialogue fragments related to travel demands are retained. The dialogue content retained after removing the chat fragments is reorganized, and spliced into a coherent text according to the original dialogue turn order to form an effective dialogue text corresponding to the session, and the effective dialogue text is written into the intermediate data buffer of the current session as the input text for performing feature word hit determination in step S230.

[0068] Step S220: performing element extraction on the travel demand information to obtain a demand element set; Specifically, the travel demand information written into the independent session space data output buffer in step S140 is acquired, and the explicit parameter field and implicit constraint field of the travel demand information are read. For the explicit parameter fields, the travel time parameter value, destination range parameter value, number of accompanying people parameter value, budget level parameter value, travel pace level value, food preference type value, and transportation preference mode value recorded therein are extracted item by item, each extracted parameter value is encapsulated into an explicit travel element item, the data structure of each explicit travel element item includes an element type identifier and element value content, the element type identifiers respectively correspond to a travel time type, a destination type, a number of accompanying people type, a budget level type, a travel pace type, a food preference type, and a transportation preference type, the element value content is filled with the correspondingly extracted parameter value, and the source mark is set as an explicit source identifier.

[0069] For the implicit constraint field, the records for elderly caregiver, child companion, mobility impairment, pet companion, dietary restrictions, and niche preferences are read item by item. Each constraint is evaluated, and when a constraint is valid, it is encapsulated as an implicit travel element item. The data structure of this implicit travel element item also includes an element type identifier and an element value. The element type identifier corresponds to the elderly caregiver type, child companion type, mobility impairment type, pet companion type, dietary restrictions type, and niche preference type, respectively. The element value is filled with the corresponding identifier status value, and the source marker is set to an implicit source identifier. All explicit and implicit travel element items are aggregated into a demand element set, which retains the distinguishing markers between explicit and implicit sources. This demand element set is written to the intermediate data cache of the current session as the element input data for matching and determining with the feature word set in step S230.

[0070] Step S230: The effective dialogue text and the set of demand elements are respectively matched with the predefined feature word sets corresponding to each of the travel intention types. The number of feature word matches for each intention type is counted. The travel intention type with the highest number of feature word matches that exceeds the preset number of matches is determined as the travel intention type. Among them, travel intention type refers to the travel scenario classification pre-divided according to the travel purpose and travel mode preference expressed by the user in the conversation. It is divided into at least six categories: leisure and vacation, parent-child study tour, health and wellness travel, outdoor hiking, business travel and cross-border travel. Each category corresponds to different itinerary arrangement logic and constraint configuration.

[0071] Preset hit count threshold: This refers to the minimum number of feature word hits that are pre-set to determine whether the travel intent type is effectively identified. Travel intent types below this threshold are not considered valid matches of the current user's travel intent.

[0072] Specifically, the effective dialogue text generated in step S210 and the demand element set generated in step S220 are obtained from the intermediate data cache of the current session. At the same time, the feature word sets corresponding to the six predefined travel intention types are loaded. The six travel intention types include at least leisure vacation type, parent-child study tour type, health and wellness travel type, outdoor hiking type, business travel type and cross-border travel type.

[0073] For the feature word set corresponding to the leisure and vacation type, perform first-dimensional matching with the effective dialogue text. Iterate through each feature word in the feature word set and compare it word by word in the effective dialogue text. Count the number of feature words in the feature word set that are matched by the effective dialogue text. At the same time, perform second-dimensional matching with the demand element set. Iterate through each feature word in the feature word set and compare it with the value content of each element in the demand element set. Count the number of feature words in the feature word set that are matched by the demand element set. Add the number of matches in the first-dimensional matching and the number of matches in the second-dimensional matching to obtain the number of feature words matched for the leisure and vacation type.

[0074] Following the statistical methods of the first and second dimension matching described above, matching statistics were performed on the feature word sets corresponding to parent-child study tours, health and wellness travel, outdoor hiking, business travel, and cross-border travel, respectively, to obtain the feature word hit count for each travel intention type. The feature word hit count for each of the six travel intention types was compared with a preset hit count threshold, and travel intention types with hit counts below the preset threshold were removed from the candidate pool. Among the remaining travel intention types with hit counts reaching the threshold, they were sorted from highest to lowest hit count, and the travel intention type with the highest hit count was determined as the current user's travel intention type.

[0075] When multiple travel intention types have the same number of hits and are all the highest, the pre-configured priority weight values ​​for each travel intention type are obtained, and the travel intention type with the highest priority weight value is determined as the current user's travel intention type. The determined travel intention type is written to the intermediate data cache of the current session as the input basis for retrieving the constraint conditions in step S240.

[0076] Step S240: Based on the travel intention type, retrieve the corresponding rigid constraint label from the preset constraint condition set corresponding to the feature word set; Among them, the preset constraint set is a set of constraints pre-configured for each travel intention type. This set stores various constraint items corresponding to the travel intention type. Each constraint item is stored according to the constraint dimension, which includes at least the population suitability dimension, the travel rhythm dimension, and the supporting facilities dimension.

[0077] Audience matching conditions: refers to the preset matching restrictions for fellow travelers for a specific travel intention type. These restrictions are used to constrain the selection range of attraction types and the difficulty level of the route in the itinerary arrangement, ensuring that the generated itinerary is suitable for the travel group corresponding to that travel intention type.

[0078] Trip Pace Restriction: Refers to the upper or lower limit of the trip pace preset for a specific travel intention type. It is used to restrict the upper limit of the number of attractions in the daily itinerary or the upper limit of the duration of activities on a single day, so as to ensure that the intensity of the trip is in line with the travel habits of that travel intention type.

[0079] Supporting facilities requirements: These refer to the pre-defined supporting service facilities requirements for a specific travel intention type. They are used to constrain the necessary conditions for hotel selection and surrounding facilities in the itinerary arrangement, ensuring that all supporting resources in the generated itinerary meet the basic requirements of this travel intention type.

[0080] Rigid constraint labels: These are an inviolable set of constraints formed by integrating population suitability conditions, itinerary pace restrictions, and supporting facility requirements. They serve as hard constraint boundaries that must be met in subsequent itinerary construction steps. Resource items that do not conform to rigid constraint labels will be directly eliminated in the resource screening stage.

[0081] Specifically, the travel intention type determined in step S230 is retrieved from the intermediate data cache of the current session, and the corresponding preset constraint set is located based on the type identifier of the travel intention type. Within this preset constraint set, each constraint item under the population adaptation dimension is retrieved sequentially according to the constraint dimension classification. Specifically, the retrieved content includes a list of allowed and prohibited attraction types for the travel intention type. Attraction types in the allowed list can be selected during subsequent itinerary planning, while those in the prohibited list are directly filtered during subsequent resource screening. Simultaneously, the age adaptation range limit and physical fitness level limit corresponding to the travel intention type are retrieved for subsequent verification of whether the itinerary arrangement exceeds the traveler's capacity. Under the itinerary rhythm dimension, the daily maximum number of attractions and the daily maximum activity duration corresponding to the travel intention type are retrieved, with different maximum numbers and durations configured for different travel intention types.

[0082] Under the dimension of supporting facilities, retrieve the hotel supporting facility requirements and scenic spot surrounding facility requirements corresponding to the travel intention type. Integrate and merge the retrieved population suitability conditions, itinerary pace restrictions, and supporting facility requirements to form a rigid constraint label for the travel demand information. The data structure of this rigid constraint label includes three fields: population suitability, pace restriction, and supporting facility requirements. The population suitability field records the list of permitted attraction types, the list of prohibited attraction types, the age range, and the physical fitness level. The pace restriction field records the daily maximum number of attractions and the daily maximum activity duration. The supporting facility requirements field records the hotel supporting facility requirements and the supporting facility requirements around the scenic spot. Write the integrated rigid constraint label into the intermediate data cache of the current session, serving as the constraint input for step S250 (travel demand profile integration) and subsequent steps S300 and S400 (resource filtering and itinerary scheduling).

[0083] Step S250: Integrate the travel demand information, the travel intention type, and the rigid constraint label to obtain a travel demand profile; Specifically, the system acquires travel demand information, travel intent type, and rigid constraint tags. Using the unique encrypted session identifier of the current session as the primary key, the travel demand information, travel intent type, and rigid constraint tags are linked and bound together. The resulting data entity constitutes the user's travel demand profile. This travel demand profile uses a hierarchical data structure: the first layer is the user identifier layer, recording the unique encrypted session identifier to associate with the current session; the second layer is the basic travel information layer, containing all the explicit parameter fields and implicit constraint fields in the travel demand information; the third layer is the intent classification layer, recording the determined travel intent type identifier; and the fourth layer is the constraint boundary layer, containing all constraint entries in the population matching field, pace restriction field, and supporting requirement field of the rigid constraint tags.

[0084] The method provided in this embodiment improves the accuracy of intent recognition by segmenting and filtering dialogue content, extracting elements, removing colloquial noise, and preserving substantive travel semantics. By performing a two-dimensional match determination between the effective dialogue text and the set of demand elements and the feature word sets of each travel intent type, using a hit count threshold constraint and priority weight as the judgment criteria, it reduces intent misjudgments caused by single-dimensional matching. By automatically retrieving and integrating population suitability conditions, itinerary rhythm restrictions, and supporting facility requirements based on the travel intent type into rigid constraint labels, the travel demand profile carries deterministic constraints for subsequent itinerary arrangement, avoiding matching deviations between the proposed plan and the specific needs of the travel population.

[0085] In one embodiment, determining the travel intention type as the type with the highest number of feature word hits exceeding a preset hit threshold further includes: When multiple travel intention types have the same number of feature word hits and all exceed the preset hit number threshold, the preset priority weight of each travel intention type is obtained, and the travel intention type with the same number of feature word hits and the highest preset priority weight is determined as the travel intention type. Among them, the preset priority weight is a priority quantification value pre-configured for each travel intention type. It is used to perform secondary sorting when the number of feature words hit by multiple travel intention types is the same and all exceed the threshold. The travel intention type with the higher weight value is given priority as the current user's travel intention type under the same hit conditions. The priority weight of each travel intention type is set comprehensively based on the frequency of occurrence of the type in actual travel scenarios and the coverage of the user group.

[0086] Specifically, after completing the statistics of the number of feature words hits for the six travel intent types, the number of feature words hits for each travel intent type is compared with the preset hit threshold, and the travel intent types that reach the threshold are selected as the candidate intent type set.

[0087] When the candidate intent type set contains only one travel intent type, that travel intent type is directly determined as the current user's travel intent type, and the priority weight determination process is not triggered. When the candidate intent type set contains two or more travel intent types, and multiple of these travel intent types have the same number of feature word hits, which are all the highest number of hits in the candidate intent type set, the priority weight determination sub-process is triggered. In the priority weight determination sub-process, the preset priority weight values ​​corresponding to these multiple travel intent types with the same number of hits and all being the highest are obtained from the pre-configured travel intent type priority weight table. These multiple travel intent types are sorted from high to low according to the preset priority weight values, and the travel intent type that is ranked first after sorting is determined as the current user's travel intent type.

[0088] The preset priority weights for each travel intent type are pre-defined and stored in a priority weight table based on the distribution ratio of actual travel demand in the business scenario. This priority weight table is loaded into the determination cache for use each time an intent is determined. The determined travel intent type is written to the intermediate data cache of the current session, along with a priority weight determination flag that records the priority weight determination process. This flag indicates that the intent determination has undergone priority weight-assisted determination rather than a single hit count determination, allowing subsequent steps to backtrack the determination path when necessary.

[0089] When the feature word set identified as the travel intention type contains mutually exclusive tags, according to the conflict resolution rules corresponding to the mutually exclusive tags, one of the travel intention types with mutually exclusive relationships is retained, and the other is marked as a secondary intention type.

[0090] Among them, mutual exclusion markers refer to the mutually exclusive attribute labels pre-marked for certain feature words in the feature word set. When a feature word is marked with a mutual exclusion marker, it indicates that the travel intention type associated with the feature word has an incompatible and mutually exclusive relationship with another travel intention type in terms of itinerary arrangement logic. The mutual exclusion relationship includes at least the mutual exclusion relationship of the movement intensity between outdoor hiking type and health and wellness travel type, and the mutual exclusion relationship of the itinerary rhythm between parent-child study tour type and business travel type. Mutual exclusion markers are used to perform rationality verification and conflict resolution after the intention determination is completed.

[0091] Conflict resolution rules: These are pre-defined selection and retention rules for travel intention types that have a mutual exclusion relationship. When two mutually exclusive travel intention types appear in the judgment result at the same time, the rules decide to retain one and downgrade the other. The specific rules for resolving conflicts are based on the degree of difference in the number of feature word hits or the preset mutual exclusion priority order to determine which type to retain.

[0092] Secondary intent types: These refer to travel intent types that are downgraded during conflict resolution. Secondary intent types do not participate in the retrieval of subsequent rigid constraint labels, but are retained in the auxiliary fields of the travel demand profile for the trip scheduling module to use as an auxiliary reference, provided that the primary intent type constraints are met.

[0093] Specifically, after determining the travel intention type and writing it into the intermediate data cache, the mutual exclusion flag configuration table of the feature word set corresponding to the travel intention type is loaded. The mutual exclusion flag configuration table records each feature word in the feature word set that is marked with a mutual exclusion flag and the mutually exclusive travel intention type pointed to by each mutual exclusion flag.

[0094] Iterate through all the feature words marked with mutual exclusion in the feature word set corresponding to the travel intention type, and check whether these feature words with mutual exclusion marks also appear in the hit feature word list of other candidate intention types in the hit determination statistics results of step S230. When there are mutually exclusive mark feature words that are hit by both the travel intention type and another candidate intention type, it is determined that there is a mutual exclusion conflict between the travel intention type and the other candidate intention type, triggering the conflict resolution processing sub-process.

[0095] In the conflict resolution subprocess, the number of feature word hits for the travel intention type and the mutually exclusive travel intention type are compared. When the number of feature word hits for the travel intention type is higher than the number of hits for the mutually exclusive travel intention type, and the difference exceeds the preset mutual exclusion resolution difference threshold, the travel intention type is retained as the primary intention type, and the mutually exclusive travel intention type is marked as the secondary intention type.

[0096] When the difference in the number of feature word hits between the two types does not exceed the mutual exclusion resolution difference threshold, a preset mutual exclusion priority order table is retrieved. The priority retention order of the travel intention type and the mutually exclusive travel intention type is checked in this table. The travel intention type ranked higher is retained as the primary intention type, and the travel intention type ranked lower is marked as a secondary intention type. The travel intention type marked as a secondary intention type is removed from the primary intention type cache of the current session and written to the auxiliary field of the travel demand profile for later use. The resolved primary intention type is used as the final travel intention type for subsequent steps to retrieve rigid constraint labels.

[0097] The method provided in this embodiment introduces a preset priority weight for secondary sorting when multiple travel intention types have the same number of hits and all exceed a threshold. This avoids the deficiency of relying solely on the number of hits in cases where primary and secondary intentions cannot be distinguished in parallel situations, thus improving the stability and accuracy of intention determination results in scenarios where user expression is ambiguous. By traversing and verifying the mutually exclusive markers in the feature word set corresponding to the determined travel intention types, and performing conflict resolution based on the difference in the number of feature word hits or the preset mutual exclusion priority order when mutual exclusion conflicts are detected, it prevents the simultaneous adoption of logically contradictory travel intention types in itinerary planning, avoiding matching deviations in itinerary plan in terms of route intensity or itinerary rhythm caused by intention conflicts. By marking the mutually exclusive travel intention types that have been downgraded after resolution as secondary intention types and retaining them in an auxiliary field, it preserves the user's multi-dimensional travel preference information while ensuring that the constraints of the primary intention type are executed first, providing a data foundation for auxiliary reference in subsequent itinerary planning.

[0098] In one embodiment, step S300: obtaining available data of cultural and tourism products at the destination and dynamic data of the travel environment based on the travel demand profile, and constructing a resource landing constraint set, includes: Step S310: Based on the destination information in the travel demand profile, concurrently call multi-source data interfaces to obtain the corresponding cultural and tourism product inventory data, real-time weather data, cross-border travel policy data, and regional transportation capacity data. Among them, the multi-source data interfaces constitute a multi-source heterogeneous real-time cultural and tourism information source, specifically including cultural and tourism product inventory interface, weather forecast interface, cross-border travel policy interface and regional transportation capacity interface. These interfaces are respectively connected to the real-time database of cultural and tourism products, the national authoritative hourly refined weather interface, the entry and exit government affairs disclosure service interface and the transportation capacity dynamic interface, breaking the traditional static data silo barrier and realizing full-dimensional offline resource survey and verification before itinerary generation.

[0099] Cultural and tourism product inventory data: refers to the inventory information of bookable tourism resources related to the destination returned through the cultural and tourism product inventory interface, including the remaining number of hotel rooms available for sale under each room type, the number of scenic spots available for reservation in each time period, and the real-time inventory balance of cultural and tourism packages.

[0100] Meteorological data: refers to the meteorological observation and forecast information of the destination for the current and future preset time period returned through the meteorological forecast interface, including temperature values, rainfall probability, wind speed level and extreme weather warning level.

[0101] Cross-border travel policy data: refers to information on visa application requirements, port clearance time, and entry control measures currently in effect at the destination and port of departure, returned through the cross-border travel policy interface.

[0102] Regional transportation capacity data refers to the remaining capacity information of public transportation and connecting transportation in the destination area returned through the regional transportation capacity interface, including the remaining number of tickets available for high-speed rail lines, the remaining number of seats on intercity passenger buses, and the number of available parking spaces in parking lots around scenic spots.

[0103] Specifically, the destination range parameter value is read from the travel demand profile generated in step S250. This destination range parameter value records one or more candidate destinations mentioned by the user in the dialogue. Using this destination range parameter value as the interface query condition, parallel call requests are constructed for four types of multi-source data interfaces. The parallel call requests are simultaneously sent to four independent interface endpoints: the cultural tourism product inventory interface, the weather forecast interface, the cross-border travel policy interface, and the regional transportation capacity interface. Each interface request carries a destination identifier parameter as a filtering condition.

[0104] The response data returned by the cultural and tourism product inventory interface includes records of hotel room availability, scenic spot time-slot reservation quotas, and cultural and tourism package inventory for the destination identifier. Each record records the resource item name, type, available quantity, available time period, and booking deadline timestamp. The response data returned by the weather forecast interface includes the current temperature value, hourly rainfall probability value, average wind speed level value, and extreme weather warning level value for the destination identifier. The extreme weather warning level value is divided into five levels from low to high: no warning, blue warning, yellow warning, orange warning, and red warning.

[0105] The response data returned by the cross-border travel policy interface includes a summary text of the new visa regulations, port clearance policies, and entry control requirements for the destination. Each text field is returned in structured key-value pair format. The response data returned by the regional transportation capacity interface includes the number of remaining high-speed rail tickets, the number of remaining seats on intercity buses, and the number of available parking spaces around scenic spots in the region where the destination is located. After the response data of the four types of interfaces is returned, it is uniformly written to the data receiving buffer, stored separately according to the interface type, and an interface source mark and request timestamp are attached to each response data record to form the full return data set of this data call, which serves as the raw input for data classification in step S320.

[0106] Step S320: Classify the bookable resource items in the cultural and tourism product inventory data as the available data of cultural and tourism products, and classify the real-time weather data, the cross-border travel policy data and the regional traffic data as dynamic travel environment data; Among them, the bookable resource items refer to the various tourism resource items in the cultural and tourism product inventory data that are confirmed to be available for users to book after the availability status is judged. The judgment is based on the fact that the available quantity field of the resource item is greater than zero. The resource items include at least hotel room resource items, scenic spot time-sharing reservation resource items, and cultural and tourism package resource items.

[0107] Available data for cultural and tourism products: This is a structured data set formed by classifying and aggregating all the selected bookable resources according to resource type. Each record in this data set points to a real cultural and tourism product that can be booked at present, and serves as a pool of candidate resources for subsequent itinerary planning.

[0108] Dynamic travel environment data: This is a collection of environmental data formed by unifying and aggregating real-time weather data, cross-border travel policy data, and regional transportation capacity data. This data collection describes the current external environment of the destination. The data items are not directly used for booking, but serve as a reference for judging the feasibility and safety of the itinerary during itinerary planning.

[0109] Specifically, the full set of returned data written to the data receiving buffer in step S310 is obtained, and the data returned by the cultural and tourism product inventory interface is extracted separately to the cultural and tourism product data queue according to the interface source tag. Each resource record in the cultural and tourism product data queue is traversed, and the value of the available quantity field in each resource record is read. Resource records with an available quantity field value greater than zero are determined as bookable resource items, and a bookable tag is written to the classification tag field of the resource record.

[0110] For resource records where the available quantity field is zero, they are determined to be unbookable resource items. A sold-out flag is written to the category flag field of the resource record, and it is removed from the unprocessed data queue. All resource records carrying the bookable flag are grouped according to resource type: hotel room resource records are grouped into the hotel resource subset, scenic spot time-sharing reservation resource records are grouped into the scenic spot resource subset, and cultural tourism package resource records are grouped into the package resource subset.

[0111] The three resource subsets are uniformly encapsulated into usable data for cultural and tourism products and written into the usable data storage partition for cultural and tourism products in the data classification cache. The metadata of this storage partition records the total number of resource items classified this time and the statistical values ​​of the type distribution of each resource. At the same time, all response data returned by the weather forecast interface in the data receiving cache are marked as the classification source of weather forecast data, all response data returned by the cross-border travel policy interface are marked as the classification source of cross-border travel policy data, and all response data returned by the regional transportation capacity interface are marked as the classification source of regional transportation capacity data. The data returned by these three types of interfaces are uniformly collected into dynamic travel environment data and written into the dynamic travel environment data storage partition of the data classification cache.

[0112] Step S330: Based on the demand tags in the travel demand profile, match and filter each resource item in the available cultural and tourism product data with each data item in the dynamic travel environment data, remove resource items and data items that do not conform to the demand tags, and merge the remaining available cultural and tourism product data and the dynamic travel environment data to construct the available service resource set; Among them, demand tags refer to the tagged representation of each constraint item in the rigid constraint tag set carried in the travel demand profile generated in step S250. These include the list of allowed attraction types and the list of prohibited attraction types under the population adaptation dimension, the daily upper limit of the number of attractions and the daily upper limit of the activity duration under the rhythm restriction dimension, and the hotel support requirements and the surrounding scenic area support requirements under the supporting requirements dimension.

[0113] Specifically, demand tags are extracted from the travel demand profile generated in step S250. These demand tags must include at least three dimension tag groups: demographic suitability dimension tag, pace restriction dimension tag, and supporting requirements dimension tag. All resource items are retrieved from the available data storage partition of the cultural and tourism products written to the data classification cache in step S320, and each resource item is traversed to perform item-by-item matching and filtering.

[0114] For each resource item, it is first compared with the audience fit dimension label. If the resource type of the resource item belongs to the type listed in the prohibited attraction type list in the audience fit dimension label, the resource item is directly marked as a removed item; if the resource type of the resource item belongs to the type listed in the allowed attraction type list, the item passes the audience fit dimension screening.

[0115] Resource items filtered by the audience fit dimension will be compared with the supporting requirements dimension tag. For hotel resources, it will be verified whether the hotel has the supporting facilities listed in the supporting requirements item of the hotel supporting requirements dimension tag. Hotel resources that do not meet the supporting requirements will be marked as rejected. For scenic spot resources, it will be verified whether the scenic spot is surrounded by the convenient facilities listed in the supporting requirements item of the scenic spot surrounding supporting requirements dimension tag. Scenic spot resources that do not meet the supporting requirements will be marked as rejected.

[0116] Meanwhile, data items are retrieved from the dynamic data storage partition of the travel environment in the data classification cache area. The meteorological data is matched with the demand tags. When the extreme weather warning level in the meteorological data reaches or exceeds the preset warning level threshold, the meteorological warning information corresponding to the meteorological data is marked as a constraint prompt and retained for subsequent itinerary planning to perceive weather risks.

[0117] The system matches cross-border travel policy data with the population-matching dimension tags in the demand tags. When the travel intention type corresponding to the travel demand profile is cross-border outbound travel, all cross-border travel policy data items are retained. When the travel intention type is not cross-border, only the basic policy summary data item of the destination region is retained. The system also matches regional transportation capacity data with the supporting requirements dimension tags in the demand tags. Transportation capacity data items corresponding to the transportation connection methods in the supporting requirements dimension tag are retained, while transportation capacity data items unrelated to the transportation connection methods are removed.

[0118] All resource items with retention tags after matching and filtering across all dimensions in the available data of cultural and tourism products, as well as all data items with retention tags in the dynamic data of travel environment, are uniformly merged into the available service resource set. The metadata of the available service resource set records the total number of resource items participating in the merger, the total number of data items, and the number of items filtered and removed.

[0119] The method provided in this embodiment acquires and categorizes real-time bookable resources and dynamic environmental data of the destination by concurrently calling multi-source data interfaces. This ensures that the data upon which itinerary planning relies is synchronized with the actual offline status, avoiding itinerary failures due to reliance on static information. By matching and filtering demand tags and resource items in the travel demand profile item by item, resources that do not meet type constraints and matching requirements are eliminated. This ensures that the resource items retained in the available service resources are all adapted to the user's travel constraint boundaries, reducing matching conflicts in itinerary planning. By merging the filtered environmental data and resource data to construct an available service resource set, a unified data input carrying both resource availability status and environmental reference information is provided for itinerary planning, reducing the risk of itinerary failure due to the separation of resource and environmental data.

[0120] In one embodiment, step S400: constructing a customized itinerary based on the travel demand profile and the available service resource set, and pushing the customized itinerary to the independent session space includes: Step S410: Based on the travel demand profile, filter out target scenic spot resources and available hotel resources from the set of available service resources; Specifically, a subset of scenic area resources is extracted from the available service resources set. This subset includes all scenic area resource items, each carrying the scenic area name, geographical coordinates, a list of available time slots for reservations, a suggested visit duration, and a scenic area type tag. Travel time parameters, number of companions, travel pace level, and the demographic and pace restriction dimension tags from the travel demand profile are retrieved. Based on the list of permitted attraction types in the demographic matching dimension tags, each scenic area resource item in the subset is type-matched. Scenic area resource items whose type tags fall within the permitted attraction type list are marked as candidate scenic area resources, while those whose type tags fall within the prohibited attraction type list or are not within the permitted list are removed from the candidate pool. The daily maximum number of attractions in the pace restriction dimension tags is retrieved and used as the constraint boundary for the number of scenic areas selected per day. Based on the geographical coordinates of each scenic spot resource item in the candidate scenic spot resources, the geographical distance between each pair of different scenic spots is calculated. The geographical distance value is used as the main sorting basis for grouping by day, and candidate scenic spot resources with similar geographical coordinates are grouped into the same travel date. At the same time, it is ensured that the number of scenic spots allocated within each travel date does not exceed the daily limit for the number of attractions.

[0121] After grouping the scenic area resources by day, for each scenic area within the same travel date, the order of visits is arranged according to the suggested visit duration and the differences in scenic area type. Scenic areas of the same or similar type within the same date are distributed to avoid a monotonous visit experience. For time slot allocation for each scenic area, the time slot reservation availability list of each scenic area resource item is read. This time slot reservation availability list records the number of remaining reservation slots for each time slot as an index. The number of people in the same group is compared with the number of remaining reservation slots for each time slot. Time slots with a number of remaining reservation slots greater than or equal to the number of people in the same group are selected as candidate time slots. Within the candidate time slots, non-overlapping entry time slots are allocated to each scenic area according to the order of visits.

[0122] The resources of each scenic spot that have been sorted by day and allocated by time period are integrated together with their assigned visit dates and entry times into a daily itinerary. The daily itinerary records the visit order, entry time, and resource configuration information of each scenic spot within that date, using the travel date as the organizational unit, and writes it into the itinerary scheduling cache of the current session.

[0123] Step S420: Generate a daily itinerary based on the remaining time-sharing reservations and geographical location of the target scenic area resources, and match the nearest target hotel from the available hotel resources according to the start and end points of the daily itinerary; Specifically, a subset of hotel resources is extracted from the available service resources set. This subset includes all hotel-related resource items, each carrying attribute fields such as hotel name, geographical coordinates, room type and price list, a list of supporting facilities, and available room availability. Budget tier parameters, number of companions, travel time parameters, and supporting facility requirements dimension tags from the rigid constraint tags are retrieved from the travel demand profile.

[0124] Budget tier validation is performed on each hotel resource item in the hotel resource subset. The daily price value of the room type and price list that matches the number of travelers is read from the room type and price list of each hotel resource item. The daily price value is compared with the budget range corresponding to the budget tier parameter value. Hotel resource items whose daily price value falls within the budget range are selected as the budget-filtered hotel set.

[0125] After budget screening, each hotel resource item in the hotel pool is validated for its supporting requirements. The supporting requirements items in the dimension tags are read, and each hotel resource item's supporting facility list is verified to ensure it meets all required facilities. Hotel resource items whose supporting facility lists include all required facilities are retained as available hotel resources. From the daily itinerary, the starting and ending scenic area coordinates for each day's trip are extracted one by one. For each travel date, each hotel resource item in the available hotel resource pool is iterated through, and the first distance from each hotel resource item's geographical coordinates to the starting scenic area's geographical coordinates and the second distance to the ending scenic area's geographical coordinates are calculated.

[0126] The first and second distance values ​​are weighted and summed to obtain a comprehensive distance value. All hotel resources in the available hotel resource set are sorted in ascending order of comprehensive distance value. The hotel with the smallest comprehensive distance value is selected as the target hotel for the given travel date. The hotel name, geographical coordinates, room type, daily price, and amenities information of the target hotel are then linked to the travel date and written into the hotel configuration field for that travel date in the itinerary scheduling cache, completing the hotel matching for each travel date.

[0127] Step S430: Based on the transportation demand between scenic spots in the daily itinerary, extract the corresponding available transportation capacity data and construct a connection plan; Specifically, the sorted scenic spot sequence for each day is read from the daily itinerary according to the travel date. For each scenic spot sequence within the travel date, the process starts from the second scenic spot and iterates through them. For each pair of adjacent scenic spots, the geographical coordinates of the exit point of the previous scenic spot and the geographical coordinates of the entry point of the next scenic spot are extracted, and the geographical distance between the two points is calculated.

[0128] Regional transportation capacity data is extracted from available service resources. This data includes public transportation route information indexed by segment, shuttle bus schedules, and remaining capacity. When the geographical distance between two points is less than a preset walking distance threshold, the connection method for that segment is determined to be walking transfer, and the segment is recorded as a walking connection segment in the transportation connection plan.

[0129] When the geographical distance between two points is greater than or equal to the preset walking distance threshold, the available public transportation routes corresponding to that section are queried in the regional transportation capacity data. When there is a public transportation route that matches that section and the remaining capacity of that route meets the number of passengers, the connection method for that section is determined to be public transportation. The bus route number, the expected waiting time, and the remaining capacity of that section are recorded in the transportation connection plan.

[0130] When there is no matching public transportation route for a certain section or the remaining capacity of the public transportation route is insufficient to meet the number of passengers, the available shuttle bus schedules for that section are queried in the regional transportation capacity data. When a matching schedule is found and the number of remaining seats meets the number of passengers, the shuttle bus schedule for that section is determined to be the shuttle bus schedule, and the corresponding shuttle bus schedule number, departure time and number of remaining seats for that section are recorded in the transportation shuttle plan.

[0131] After traversing all adjacent scenic spot pairs within the travel date, the connection methods for each connecting segment under that travel date are recorded and summarized into a transportation connection sub-plan for that travel date. All transportation connection sub-plans for each travel date are then bound to their respective travel dates and written into the itinerary scheduling cache to generate a complete transportation connection plan.

[0132] Step S440: Combine the daily itinerary, the target hotel, and the transportation plan into the customized itinerary and push it to the independent chat space. Specifically, the daily itinerary, target hotel, and transportation plan are retrieved from the itinerary scheduling cache, and these three are horizontally integrated using the travel date as the primary key. For each travel date, the list of attractions to be visited and the entry times for those attractions are extracted from the daily itinerary to form the content of the itinerary display area for that date. The name and geographical coordinates of the target hotel associated with that date are used as the content of the accommodation display area for that date. The connection methods and estimated travel times for each connection segment in the corresponding transportation plan are used as the content of the transportation display area for that date. These three display areas are encapsulated into a structured itinerary card template organized by the travel date.

[0133] After the structured itinerary card template for each travel date is filled in, the itinerary cards for each day are arranged in ascending order of travel date. An overview of the itinerary is added before the first card, including the total number of travel days, destination range, and travel start and end dates. After the structured itinerary cards are completed, natural language interpretation text is generated based on the information about each attraction and target hotel in the daily itinerary.

[0134] The natural language interpretation text generation process includes sequentially traversing the daily itinerary, matching target hotels and transportation plans for each travel date, converting the order of sightseeing, entry time of scenic spots, hotel check-in information and the connection methods used for each connection segment into coherent natural language description sentences, and embedding itinerary highlight reminder tags and travel precaution reminder tags in the description sentences.

[0135] The completed structured itinerary cards and the generated natural language interpretation text are uniformly packaged into a customized itinerary plan. This customized itinerary plan is then pushed to the user within their independent session space via a message channel. The customized itinerary plan pushed to the independent session space carries both structured itinerary card format data and natural language interpretation text format data. The structured itinerary card includes eight integrated modules: a comprehensive travel overview, daily time-based precise route planning, differentiated explanations of attractions, compliant and optimal hotel recommendations, seamless transportation plans, nearby convenient amenities guidance, real-time weather and travel tips, and cross-border travel compliance information. Both formats are simultaneously rendered and presented in the message display area of ​​the independent session space. After the push is completed, a complete copy of the customized itinerary plan is retained in the itinerary scheduling cache, and a version number is marked on this copy. This version number increments with each iteration update operation in step S600, for version retrospective and modification comparison.

[0136] When a customized itinerary is pushed to a separate chat space, the AI ​​chat assistant instantly pushes a structured itinerary card within the existing chat window, without requiring the user to navigate to a third-party page or download any additional files. This structured itinerary card comprises the following eight integrated modules: Overview of travel across the region (total number of days, destination range, start and end dates); precise daily time-based itinerary planning (entry times for each scenic spot, order of visits, recommended visit duration); differentiated explanations of attractions (attraction features, suitable groups, travel tips); compliant and optimal hotel recommendations (hotel name, star rating, distance, facilities); seamless transportation connection plan (connection methods for each segment, estimated travel time, available capacity); nearby convenient facilities guide (location of restaurants, medical facilities, restrooms, etc.); real-time weather and travel tips (temperature, rainfall, warning information); compliance information for cross-border travel (visa, customs clearance, overseas epidemic prevention, etc.).

[0137] The app uses conversational and easy-to-understand language to explain the core highlights of the itinerary, daily travel priorities, key transportation connections, nearby shelters and rest areas, essential documents for cross-border clearance, and ticket booking deadlines. The language is designed for everyday conversation, making it easy to understand and highlighting key points, allowing even seniors and first-time travelers to quickly grasp the overall itinerary. The itinerary is automatically archived to the user's personal cloud storage center, supporting one-click review and easy sharing with family and friends.

[0138] The method provided in this embodiment filters target scenic area resources based on travel demand profiles and allocates them by day based on time-sharing reservation availability and geographical location, ensuring that the selection of attractions for each day's itinerary matches the real-time available reservation capacity, avoiding over-scheduling and time slot conflicts. By matching the nearest hotels that meet budget and accommodation requirements based on the start and end points of each day's itinerary, and extracting available transportation capacity data based on the transportation demand between scenic areas to construct segmented connecting routes, the method ensures close connection between accommodation and travel routes, and guarantees transportation capacity for each segment, reducing the risk of disconnection between itinerary segments. By integrating daily itinerary arrangements, target hotels, and transportation connection plans by date into a customized itinerary plan and simultaneously pushing it out using structured cards and natural language text, the method lowers the barrier to understanding the itinerary content for users.

[0139] In one embodiment, before combining the daily itinerary, the target hotel, and the transportation plan into the customized itinerary, the method further includes: Detect whether the travel rhythm of the daily itinerary matches the travel rhythm preference in the travel demand profile; Among them, travel rhythm preference refers to the travel rhythm tendency value recorded in the travel demand profile, which is expressed by the user in the conversation or determined after the conversation. This value is represented by preset rhythm levels. Different levels correspond to different daily upper limits for the number of attractions and daily activity duration. Rhythm preference directly affects the density of the daily itinerary.

[0140] Specifically, after generating the daily itinerary in step S410 and before performing the combined operation in step S440, the daily itinerary density verification process is initiated. The rhythm level value corresponding to the travel rhythm preference is read from the travel demand profile. Based on the rhythm level value, the corresponding daily maximum number of attractions and daily maximum activity duration are looked up in the preset rhythm constraint mapping table. The preset rhythm constraint mapping table uses the rhythm level value as an index, and each rhythm level records the maximum number of attractions that can be arranged daily and the maximum daily activity duration in minutes corresponding to that level.

[0141] The system iterates through each travel date in the daily itinerary, counts the number of scenic spots allocated for each travel date, and compares this number with the daily maximum number of attractions corresponding to that pace level. When the number of allocated scenic spots for a travel date exceeds the daily maximum number of attractions, the daily itinerary density for that travel date is determined to exceed the pace requirement, triggering a density adjustment flag. The itinerary verification status field for that travel date records the density exceeding flag and the difference in the number of exceeding flags.

[0142] Simultaneously, the suggested visit duration for each scenic spot within each travel date is summed with the estimated transfer time between scenic spots to obtain the total estimated activity duration for each travel date. This total estimated activity duration is then compared with the daily activity duration limit. If the total estimated activity duration for a certain travel date exceeds the daily activity duration limit, it is determined that the travel date has exceeded the time limit, and the time limit exceedance flag and the difference in time exceeding the limit are recorded in the itinerary verification status field for that travel date.

[0143] For travel dates that trigger density adjustment flags and duration exceedance flags, the flag information along with the exceedance difference is fed back to the scenic spot allocation sub-process in step S410, triggering the reduction of the number of scenic spots or the replacement of scenic spots on the exceedance date. The adjusted daily itinerary re-enters the verification process until the verification status field of each travel date has no exceedance flags, and the verification passes.

[0144] Detect whether the target hotel matches the budget tier recorded in the travel demand profile; Specifically, the budget tier parameter value is read from the travel demand profile. Based on the budget tier parameter value, the corresponding lower limit of the allowed range of hotel star rating, upper limit of the allowed range of hotel star rating, and upper limit of daily room rate are found in the preset budget tier constraint mapping table. The preset budget tier constraint mapping table uses the budget tier identifier as an index. Under each budget tier, the minimum requirement of hotel star rating, the maximum limit of hotel star rating, and the upper limit of daily room rate are recorded.

[0145] Step S420 retrieves hotel resource items for the target hotel, extracting the star rating and daily price for each target hotel. For each daily target hotel, the star rating is compared with the lower and upper limits of the allowed star rating range corresponding to the budget tier. If the hotel's star rating is lower than the lower limit of the allowed star rating range, the target hotel's star rating is determined to be lower than the user's minimum expectation for the budget tier, generating a low-star-rating verification anomaly flag. If the hotel's star rating is higher than the upper limit of the allowed star rating range, the target hotel's star rating is determined to be higher than the user's maximum expectation for the budget tier, generating a high-star-rating verification anomaly flag.

[0146] The daily price of the target hotel is compared with the daily room rate cap. If the daily price exceeds the daily room rate cap, the target hotel is deemed to have exceeded the budget limit, and a budget overrun verification anomaly is generated. The difference in excess amount is recorded in the verification status field of the target hotel. For target hotels that generate low-star, high-star, or budget overrun verification anomaly flags, the anomaly flag information is fed back to the hotel matching sub-process in step S420, triggering a replacement operation for the abnormal target hotels. Alternative hotel resources that meet the budget level constraints are re-selected from the available hotel resource set, and the start and end point distance matching is re-executed. The adjusted target hotels re-enter the verification process until all target hotels have no anomaly flags in their verification status fields and all hotels' daily prices do not exceed the daily room rate cap, at which point the verification is successful.

[0147] Detect whether the itinerary arrangement boundaries in the daily itinerary plan meet the population matching conditions in the travel demand profile; Among them, the intensity of the movement route refers to the comprehensive physical exertion value of each scenic spot tour route in the daily itinerary. The intensity of the movement route takes into account multiple physical exertion factors such as walking distance, altitude rise and difficulty of terrain within the scenic area. Different intensity levels of the movement route correspond to different requirements for the carrying capacity of the population.

[0148] Rigid constraint label: refers to the set of inviolable hard constraint items carried in the travel demand profile. In the population adaptation dimension, it specifically includes physical strength level restrictions, age adaptation range restrictions, and a list of prohibited attraction types. These constraint items are retrieved from the preset constraint condition set and written into the travel demand profile in step S240 as the condition boundaries that the itinerary arrangement must meet.

[0149] Population suitability conditions: This refers to the collective term for all the restrictions related to the physical endurance of the travel population in the rigid constraint label. The intensity of the movement in the itinerary plan must match the population suitability conditions. Itinerary arrangements that do not meet the population suitability conditions shall not be delivered.

[0150] Specifically, the travel demand profile extracts the population adaptation dimension field of rigid constraint labels. This population adaptation dimension field includes physical strength level limit value, lower and upper limit values ​​of age adaptation range, and a list of prohibited attraction types.

[0151] Read the scenic spot sequence for each travel date in the daily itinerary, and extract the physical exertion level attribute value and the tour terrain difficulty attribute value for each scenic spot resource item. The physical exertion level attribute value is divided into three levels from low to high: light exertion, moderate exertion and high intensity exertion. The tour terrain difficulty attribute value is divided into three difficulty levels from easy to difficult: flat terrain, gentle slope terrain and steep terrain.

[0152] For the physical exertion level attribute values ​​of each scenic area resource item, light exertion is mapped to the first intensity value, moderate exertion to the second intensity value, and high exertion to the third intensity value. For the terrain difficulty attribute values ​​of each scenic area resource item, flat terrain is mapped to the first difficulty value, gentle slope terrain to the second difficulty value, and steep terrain to the third difficulty value. For all scenic area resource items within each travel date, the intensity and difficulty values ​​of each scenic area within that date are weighted and summed to obtain the comprehensive route intensity value for that travel date.

[0153] The overall route intensity value for each travel date is compared one by one with the physical fitness level limit value in the population suitability dimension field. When the overall route intensity value for a travel date exceeds the physical fitness level limit value, the route intensity for that travel date is determined to be excessive, and an anomaly flag is generated. Simultaneously, the scenic area type tags for each scenic area resource item are traversed, and each scenic area type tag is compared one by one with the list of prohibited scenic area types in the population suitability dimension field. When the scenic area type tag for a scenic area resource item matches any item in the list of prohibited scenic area types, the scenic area is determined to be inconsistent with the population suitability conditions, and a prohibited type verification anomaly flag is generated.

[0154] For travel dates or scenic area resources that generate anomaly flags indicating excessive intensity or prohibited types, the anomaly flag information is fed back to the scenic area allocation sub-process in step S410. This triggers the replacement of scenic area resources that do not meet the population suitability conditions or the reduction of scenic area resources for travel dates with excessive travel intensity. The adjusted daily itinerary re-enters the verification process until all verification anomaly flags are cleared, and the verification passes. After all three verifications pass, the combined operation process in step S440 is initiated.

[0155] The method provided in this embodiment avoids delivering an itinerary that deviates from the user's expected pace by verifying the match between the number of attractions on the daily itinerary and the user's preferred travel rhythm before combining the itinerary. It also intercepts accommodation overruns caused by matching discrepancies by verifying the consistency between the target hotel's star rating and price and the budget range before combining the itinerary. Finally, it excludes scenic spots unsuitable for specific groups and ensures the physical fitness and safety of the itinerary by verifying the suitability of the activity route for the target population before combining the itinerary.

[0156] In one embodiment, the method further includes, upon receiving user feedback, semantically decomposing the feedback to obtain trip adjustment elements, and iteratively updating the customized trip plan based on the trip adjustment elements to obtain an updated trip plan. When the system receives natural language modification suggestions from the user regarding the customized itinerary plan that has been pushed to it, the system performs semantic decomposition of the modification suggestions to determine the itinerary adjustment elements corresponding to the modification suggestions.

[0157] Specifically, after the customized itinerary plan is pushed to the independent session space in step S440, the message listening unit of the independent session space continuously listens for new messages entered by the user through the dialog window. When the user views the pushed customized itinerary plan and enters natural language text containing the intention to modify in the dialog window, the natural language text is captured by the message listening unit as a natural language modification opinion and written to the modification opinion receiving buffer.

[0158] The complete text of the natural language modification suggestion is retrieved from the suggestion receiving buffer, and semantic decomposition is performed on the text. The semantic decomposition process first segments and tags the natural language modification suggestion text, identifying verb terms, noun terms, and adjective terms appearing in the text. The identified verb terms are then matched against a pre-defined modification operation lexicon. This lexicon includes subsets of replacement, addition / deletion, and quantification adjustment terms. The replacement subset includes verbs such as "change," "modify," "replace," and "replace," along with their synonyms. The addition / deletion subset includes verbs such as "remove," "delete," "add," "add," and "supplement," along with their synonyms. The quantification adjustment subset includes verbs such as "slow down," "speed up," "reduce," "increase," "improve," and "lower," along with their synonyms.

[0159] Based on the matching results with the preset modification operation lexicon, the operation type corresponding to the matched terms is written into the adjustment direction field of the itinerary adjustment element. The possible values ​​for the adjustment direction field include at least replacement operation type, add / delete operation type, and quantitative adjustment operation type. Noun terms in the word segmentation results are matched with the preset itinerary object lexicon, which includes scenic spot object terms, hotel object terms, transportation object terms, and rhythm object terms, as well as their associated synonyms. After a match is found, the corresponding itinerary object type is written into the adjustment object field of the itinerary adjustment element.

[0160] Adjective and degree adverb terms are extracted from the word segmentation results. Combined with the matching results of noun terms, the expected value or tendency of the user regarding the adjustment object expressed in the modification comments is determined. This expected value or tendency is then written into the adjustment reference field of the itinerary adjustment element. The generated itinerary adjustment element is written into the modification processing cache as the basis for subsequent resource re-acquisition and partial plan updates.

[0161] Based on the itinerary adjustment element, retrieve the available resource data corresponding to the itinerary adjustment element from the available service resource set. Specifically, the itinerary adjustment elements are read from the modification processing cache, and the values ​​of the adjustment object field and adjustment reference field are extracted from the itinerary adjustment elements. Based on the adjustment object field value, the type of resource that needs to be reacquired is determined. When the adjustment object field value is a scenic spot object type, a new query request is initiated to the scenic spot resource subset of the available service resource set. The desired scenic spot attribute description in the adjustment reference field is used as the query filter condition. Scenic spot resource items that match the desired scenic spot attribute description are selected from the scenic spot resource subset. The selected scenic spot resource items, along with their time-sharing reservation availability and geographical location information, are used as the available resource data to be reacquired.

[0162] When the adjustment object field value is of type hotel object, a new query request is initiated to the hotel resource subset of the available service resource set. The expected star rating range or expected price range in the adjustment reference field is used as the query filter condition. Simultaneously, budget level constraints and amenity requirements constraints from the travel demand profile are combined to filter hotel resource items from the hotel resource subset that meet the comprehensive constraints. The filtered hotel resource items, along with their room type prices, geographical coordinates, and amenity list, are then used as the newly acquired available resource data. When the adjustment object field value is of type rhythm object, there is no need to obtain new resource item data from the available service resource set. The expected rhythm adjustment direction in the adjustment reference field is directly used as the newly acquired available resource data. The rhythm adjustment direction includes two values: slowing down the rhythm and accelerating the rhythm.

[0163] When the value of the adjustment object field is of type transportation object, a new query request is initiated to the regional transportation capacity data subset of the available service resource set. The desired mode of transportation type in the adjustment reference field is used as the query filter. Available transportation capacity items corresponding to the desired mode of transportation type and covering the target connecting section are selected from the regional transportation capacity data subset. These selected transportation capacity items are then used as the newly acquired available resource data. All newly acquired available resource data are bound to the itinerary adjustment elements and written to the modification processing cache as the replacement data source for subsequent partial update operations.

[0164] Based on the trip adjustment elements and the available resource data, the corresponding parts of the customized trip plan are partially updated, while other parts of the customized trip plan that do not involve the trip adjustment elements remain unchanged. The updated trip plan is then pushed to the independent session space. Specifically, the system reads trip adjustment elements and reacquired available resource data from the modification processing cache, and reads a complete data copy of the currently pushed customized trip plan from the trip data storage area in the independent session space. The execution strategy for the partial update operation is determined based on the values ​​of the adjustment object field and the adjustment direction field in the trip adjustment elements.

[0165] When the adjustment direction field value is a replacement operation type, locate the storage location of the scheme sub-item indicated by the adjustment object field value in the data copy of the customized itinerary scheme, replace the original resource item data at that location with the new resource item data in the newly acquired available resource data, and at the same time extract the attribute values ​​of the original resource item data and the new resource item data to generate a comparison record before and after modification, and attach the comparison record before and after modification to the update log of this update.

[0166] When the adjustment direction field value is of the add / delete operation type, the resource item insertion or removal operation is performed in the attraction sequence or transportation connection sequence indicated by the adjustment object field value in the customized itinerary plan. The subsequent scenic spot sorting, time period allocation and connection method affected by the insertion or removal operation are rearranged in sequence, and the rearranged plan sub-item data is written to the corresponding position of the data copy.

[0167] When the adjustment direction field value is a quantitative adjustment operation type and the adjustment object field value is a rhythm object type, the rhythm adjustment direction value in the adjustment reference field is read. When the rhythm adjustment direction is to slow down the rhythm, the scenic spot reduction operation is performed on the travel dates in the daily itinerary that exceed the upper limit of the number of attractions after adjustment. When the rhythm adjustment direction is to speed up the rhythm, the scenic spot replenishment operation is performed on the travel dates in the daily itinerary that are lower than the lower limit of the number of attractions after adjustment. The scenic spot replenishment is selected from the candidate scenic spot resource items in the available service resource set according to the matching degree with the theme of the itinerary of the day from high to low.

[0168] After the partial update operation is completed, ensure that the travel dates, hotel configurations, and transportation connection plans in the customized itinerary plan data copy that are not covered by the adjusted object field values ​​are completely consistent with the original plan, without any modifications. Increment the version number of the partially updated data copy to generate the updated itinerary plan. Push the updated itinerary plan to the user's independent session space using the same structured itinerary card and natural language interpretation text encapsulation format as in step S440. When pushing, display the update version number and a summary of the update highlights in the message display area to complete the iterative update loop of the itinerary plan.

[0169] The method provided in this embodiment semantically decomposes the colloquial modification requests input by users, identifies the operational intent words and target object words, and converts them into structured trip adjustment elements. This allows users to express their modification requests without returning to fixed forms or following specific instruction formats, lowering the operational threshold for trip adjustments. By retrieving corresponding available resource data from the available service resource set based on the trip adjustment elements, it ensures that the resource items on which the modification operation depends are synchronized with the current real-time availability status, avoiding the problem of modified trips not being implemented due to changes in resource status. By only partially replacing or adjusting the parts of the customized trip plan that are hit by the trip adjustment elements, while keeping other parts of the plan unchanged, the plan iteration can be completed without rearranging the entire trip, reducing the computational overhead and response latency of a single modification operation.

[0170] In one embodiment, the customized tourism service method further includes a multilingual two-way intelligent interaction step specifically for cultural and tourism purposes, which supports customized cross-border inbound and outbound tourism services.

[0171] Specifically, a dedicated multilingual semantic interaction module for cultural and tourism industries is used. This module is equipped with a specialized multilingual thesaurus for cultural and tourism, which includes professional terms related to scenic spot names, cross-border visa terminology, inbound and outbound transportation tickets, and customs and taboos of overseas destinations, enhancing the ability to accurately translate between cultural and tourism scenarios. This module supports bidirectional real-time semantic understanding and generation in Chinese, English, Japanese, Korean, and Southeast Asian languages.

[0172] When foreign tourists input inquiries about customized inbound tourism in their native language through an independent conversation space, the system automatically identifies the language type, calls the corresponding multilingual semantic understanding engine, converts the native language inquiry text into structured travel demand information, and generates customized itinerary plans that conform to the characteristics of inbound tourism according to steps S100 to S400. Then, the plan is pushed to the foreign tourist through natural language interpretation.

[0173] When domestic outbound users need to inquire about overseas destinations, they can switch to multilingual mode with one click. The system automatically loads the corresponding outbound cultural and tourism terminology database, identifies the user's outbound needs, matches resources, and links with cross-border travel policy interfaces in real time to obtain data such as new visa policies and port clearance times. It then generates an itinerary plan that includes cross-border compliance information and outputs itinerary cards and explanatory texts in the user's specified language.

[0174] This embodiment enables barrier-free customized consultation services for inbound and outbound tourism in multiple languages, including Chinese, English, Japanese, Korean, and Southeast Asian, covering the entire region and making up for the shortcomings in international service technology.

[0175] like Figure 6 As shown, the present invention also provides a travel customization service device, applied to any of the travel customization service methods described above, comprising: The conversation interaction module is used to respond to conversation requests initiated by users, create an independent conversation space, conduct multi-turn language dialogue in the independent conversation space, and parse the corresponding travel demand information. A profile analysis module is used to analyze the travel demand information to obtain a travel demand profile. The resource association module is used to obtain available data of cultural and tourism products at the destination and dynamic data of the travel environment based on the travel demand profile, and to construct a resource landing constraint set. The itinerary scheduling module is used to construct itineraries based on the travel demand profile and the resource landing constraint set, obtain customized itinerary plans, and push the customized itinerary plans to the independent session space.

[0176] This application also provides a computer device, such as... Figure 7 As shown, the computer device includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor. When the processor executes the computer program, it implements the steps in any of the above method embodiments, or when the processor executes the computer program, it implements the functions of each module / unit in the above device embodiments.

[0177] For example, the computer program may be divided into one or more modules / units, which are stored in the memory and executed by the processor to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the computer device.

[0178] Those skilled in the art will understand that Figure 7 The computer device described is merely an example and does not constitute a limitation on the computer device. It may include more or fewer components than shown, or combine certain components, or different components. For example, the computer device may also include input / output devices, network access devices, buses, etc.

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

[0180] The memory can be an internal storage unit of the computer device, such as a hard drive or RAM. The memory can also be an external storage device of the computer device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory can include both internal and external storage units of the computer device.

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

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

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

[0184] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

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

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

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

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

Claims

1. A method for providing customized tourism services, characterized in that, include: In response to a user-initiated session request, an independent session space is created, where multi-turn language dialogue takes place, and the corresponding travel demand information is parsed. The travel demand information is analyzed to obtain a travel demand profile; Based on the travel demand profile, obtain available data on cultural and tourism products at the destination and dynamic data on the travel environment, and construct a resource landing constraint set; Based on the travel demand profile and the resource landing constraint set, a customized itinerary is constructed to obtain a customized itinerary plan, which is then pushed to the independent session space.

2. The method for providing customized tourism services according to claim 1, characterized in that, In response to a user-initiated session request, an independent session space is created, where multi-turn language dialogue takes place, and corresponding travel demand information is parsed, including: In response to the user initiating the session request, an independent session space is created for the user and the travel request template is initialized; Within the independent conversation space, multiple rounds of language dialogue are conducted with the user to extract the user's expressed basic travel attributes and travel preference features, and integrate them into explicit travel needs; The characteristics of travelers and travel restrictions mentioned by users in multi-round natural language dialogues are captured and integrated into implicit travel needs; The explicit travel demand and the implicit travel demand are aggregated into the travel template to obtain the travel demand information.

3. The method for providing customized tourism services according to claim 1, characterized in that, The process of parsing the travel demand information to obtain a travel demand profile includes: The dialogue content is segmented and tagged with parts of speech, and modal particles and irrelevant chatter are filtered out to obtain valid dialogue text; The travel demand information is processed to extract elements, resulting in a demand element set. The effective dialogue text and the structured demand elements are respectively matched with the feature word sets corresponding to each predefined travel intention type. The number of feature word matches for each travel intention type is counted. The travel intention type with the highest number of feature word matches that exceeds the preset number of matches is determined as the travel intention type. Based on the travel intention type, retrieve the corresponding rigid constraint label from the preset constraint condition set corresponding to the feature word set; The travel demand information, the travel intention type, and the rigid constraint label are integrated to obtain the travel demand profile.

4. The method for providing customized tourism services according to claim 1, characterized in that, The process of obtaining available data on cultural and tourism products and dynamic data on the travel environment of the destination based on the travel demand profile includes: Based on the destination information in the travel demand profile, multi-source data interfaces are invoked in parallel to obtain the corresponding cultural and tourism product inventory data, weather data, cross-border travel policy data, and regional transportation capacity data. The bookable resources in the cultural and tourism product inventory data are classified as the available cultural and tourism product data, and the real-time weather data, the cross-border travel policy data, and the regional traffic data are classified as the dynamic travel environment data.

5. The method for providing customized tourism services according to claim 1, characterized in that, The process of constructing a customized itinerary based on the travel demand profile and the available service resource set, and then pushing the customized itinerary to the independent session space includes: Based on the travel demand profile, target scenic spots and available hotel resources are filtered from the available service resources set; Based on the available time slots and geographical location of the target scenic area resources, a daily itinerary is generated, and the nearest target hotel is matched from the available hotel resources according to the start and end points of the daily itinerary. Based on the transportation demand between scenic spots in the daily itinerary, extract the corresponding available transportation capacity data and construct a transportation connection plan. The daily itinerary, the target hotel, and the transportation plan are combined into the customized itinerary and pushed to the independent chat space.

6. The method for providing customized tourism services according to claim 1, characterized in that, It also includes, upon receiving user feedback, semantically decomposing the feedback to obtain itinerary adjustment elements, and iteratively updating the customized itinerary plan based on these elements to obtain an updated itinerary plan. When the user provides natural language feedback on the customized itinerary plan that has been pushed to us, the feedback is semantically decomposed to determine the itinerary adjustment elements corresponding to the feedback. Based on the itinerary adjustment elements, retrieve the available resource data corresponding to the itinerary adjustment elements from the available service resource set; Based on the trip adjustment elements and the available resource data, the corresponding parts of the customized trip plan are partially updated, while other parts of the customized trip plan that do not involve the trip adjustment elements remain unchanged, and the updated trip plan is pushed to the independent session space.

7. A device for customized tourism services, characterized in that, The method for providing customized travel services according to any one of claims 1-6 includes: The conversation interaction module is used to respond to conversation requests initiated by users, create an independent conversation space, conduct multi-turn language dialogue in the independent conversation space, and parse the corresponding travel demand information. A profile analysis module is used to analyze the travel demand information to obtain a travel demand profile. The resource association module is used to obtain available data of cultural and tourism products at the destination and dynamic data of the travel environment based on the travel demand profile, and to construct a resource landing constraint set. The itinerary scheduling module is used to construct itineraries based on the travel demand profile and the resource landing constraint set, obtain customized itinerary plans, and push the customized itinerary plans to the independent session space.

8. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the travel customization service method as described in any one of claims 1 to 6.

9. A readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the travel customization service method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, enables the implementation of the steps of the travel customization service method as described in any one of claims 1 to 6.

Images