Travel intention prediction and active dialogue planning method based on user data

Abstract

The invention discloses a travel intention prediction and active dialogue planning method based on user data. According to the method, user input is analyzed through voice interaction and intention recognition, and intention categories and key slot positions are obtained; a dialog management module updates the travel plan variable based thereon and generates a guided query for the missing field; when the planning condition is met, the travel generation module combines the pre-training model and the external service interface data to generate a travel scheme; in the travel execution stage, the travel accompanying module compares position and time information in real time, recognizes deviations such as travel delay, environment conflict or resource unavailability and automatically modifies local fields; and finally, the user variable database module persistently stores the updated plan variables and the long-term preference model based on actual behavior learning. According to the invention, accurate intention understanding, automatic generation and intelligent dynamic adjustment of an execution stage of the travel scheme are realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of computer information processing and artificial intelligence, in particular to a travel intention prediction and active dialogue planning method based on user data. BACKGROUND

[0002] With the popularization of mobile internet technology, digital travel planning is mostly dependent on OTA platforms or mobile applications. Users usually need to manually input complete information such as destination, time and budget, and switch between different service panels for comparison. This passive interaction mode requires users to have clear intentions at the beginning of planning. When the input information is ambiguous or key elements (such as specific time constraints) are missing, existing systems often have difficulty in actively identifying and generating targeted guided inquiries, resulting in planning processes that are difficult to proceed due to incomplete information.

[0003] Although voice interaction devices have gradually become popular, existing systems are mostly based on single-turn instructions and lack the ability to manage complex multi-turn dialogue states. The generated travel plan is usually presented as static text and lacks real-time environmental data linkage in the execution phase. In actual travel, if uncontrollable factors such as sudden weather changes, traffic congestion, or temporary closure of attractions, static plans cannot sense deviations and automatically trigger time shifting or node replacement for re-planning logic, and users still need to manually adjust.

[0004] In addition, existing data architectures often lack variable isolation and long-term management mechanisms for specific users. The system often treats planning data as a one-time consumable and cannot track real behavior data (such as the difference between actual stay time and planned time) in actual travel, making it difficult to use post-travel feedback data to calibrate the user's long-term preference model, resulting in the system's inability to evolve the intention prediction accuracy as the interaction accumulates. SUMMARY

[0005] To overcome the shortcomings of the prior art, the present application provides a travel intention prediction and active dialogue planning method based on user data, which solves the problems of cumbersome operation, information fragmentation of existing travel planning tools, and the lack of multi-turn dialogue memory and complex planning capabilities of general voice assistants. It overcomes the defect that traditional static travel plans cannot sense real-time environmental changes (such as weather, congestion, and closure) during travel and automatically adjust. In addition, the present application also solves the problem of lack of independent isolation and long-term memory mechanism for multi-user data management.

[0006] To achieve the above purpose, the present application is implemented by the following technical scheme: a travel intention prediction and active dialogue planning method based on user data, comprising the following steps: Firstly, the voice interaction module processes the user's input voice signal. In the processing process, the voice activity detection technology based on short-time energy is used to intercept the effective voice segment, exclude the interference of silence and noise, and perform inverse text normalization processing on the text sequence converted by recognition, so as to convert the spoken numbers and dates into the standard format. Subsequently, the intent recognition module encodes the text by using a deep neural network encoder, and splices the previous round of dialogue history and the current text as a joint input. This mechanism generates a feature vector sequence, and performs intent classification prediction and slot filling tasks in parallel, so as to accurately analyze the user's intent category and key slot information in multiple rounds of interaction.

[0007] At the data management level, the application introduces a travel plan variable as a core data structure. The user variable database module uses a consistent hash algorithm to locate user data shards in a distributed database, ensuring data read-write efficiency under high concurrency. The dialogue management module maps the travel element data to the target field of the travel plan variable according to the parsed intent and slot. Different types of fields are updated differently: single-value fields are overwritten, and collection-type fields are incrementally appended and de-duplicated. At the same time, the system performs integrity scanning on the travel plan variable, identifies missing fields according to the field priority rule, and generates guided inquiries. This priority rule sets spatial constraints as the priority over time constraints, and time constraints as the priority over resource constraints, ensuring that the dialogue logic conforms to the convergence law of the planning path.

[0008] In the itinerary generation phase, the system uses a mode in which a large language model and external service interfaces work together. The itinerary generation module fills the travel plan variable into the prompt word template, generates a preliminary text framework containing the information to be filled in through a pre-trained language model. The external tool calling module performs named entity recognition on the framework to extract information slots and build interface requests accordingly. When building the request, the system loads the service registry to check the required parameters. If there are missing parameters, the system builds a directed acyclic graph-based dependency relationship, retrieves the prerequisite interfaces that can output the missing parameters, and performs chain calling in topological order to automatically fill the response data of the prerequisite interfaces into the downstream interfaces, finally obtains the complete service response data and fuses to generate the itinerary.

[0009] In the itinerary execution and accompanying phase, the application realizes dynamic deviation identification and adjustment based on real-time data. The system monitors the location and time information in real time and performs the following deviation determination logic: when the current time exceeds the sum of the node scheduled time and the threshold value and the distance is still greater than the spatial threshold, it is determined that the itinerary is delayed; when severe weather is detected and the node has an outdoor attribute, it is determined that there is an environmental conflict; when the real-time operation state returned by the external interface is closed or sold out, it is determined that the resource is unavailable.

[0010] For identified deviations, the system implements differentiated modification strategies. For trip delays, a time shift operation is performed; for environmental conflicts or resource unavailability, a node replacement operation is performed. During node replacement, alternative locations are retrieved centered on the original node, and a weighted scoring algorithm is used to rank these locations. The algorithm's calculation logic is as follows: it calculates the semantic similarity between the alternative location and the user's preference tags, using this as the content matching score; it also calculates the normalized distance between the alternative location and the current location, using this as the distance cost score; finally, it performs a weighted sum of the content matching score and the distance cost score, and selects the optimal alternative location based on the calculation results to update the local fields of the travel plan variable.

[0011] Furthermore, this invention also includes a preference learning mechanism based on actual behavior. When persistently storing the updated travel plan variable, the system extracts the attribute labels of the user's actual adopted nodes and calculates the ratio of the actual stay duration to the standard stay duration, defining this ratio as an interest coefficient. The system then weights and accumulates this interest coefficient with the corresponding label weights in the long-term preference model and performs normalization processing on all weights in the model, thereby achieving automatic iteration and updating of the user profile.

[0012] Through the above-mentioned technical solution, this invention achieves full automation from accurate intent parsing to dynamic itinerary generation, and can adaptively adjust according to environmental changes and real-time status during the execution phase, effectively improving the usability and personalization of travel planning.

[0013] This invention provides a method for predicting travel intentions and planning proactive dialogue based on user data. It has the following beneficial effects: 1. This invention utilizes a voice interaction module in conjunction with a dialogue management module to achieve multi-turn dialogue-based itinerary planning using natural language. The system can automatically parse the intent category and key slots in the user's text input, and generate guided queries for missing fields that have not yet been assigned values ​​but are necessary conditions for planning, until the preset planning conditions are met. This approach changes the cumbersome manual input mode of traditional static forms, reducing the user's operational threshold while ensuring the accurate acquisition of the elements required for itinerary planning, thereby efficiently generating structured travel arrangement results.

[0014] 2. This invention utilizes a travel companion module to perform real-time status monitoring and deviation identification during trip execution. By comparing the user's real-time location and current time with the planned trip parameters, the system can automatically trigger time shifting or node replacement strategies when it detects trip delays, environmental conflicts caused by severe weather, or resource unavailability returned by external interfaces. This dynamic adjustment mechanism based on in-trip context awareness effectively solves the problem that traditional static itinerary plans cannot cope with sudden situations or environmental changes, ensuring the continuity and availability of the travel plan during actual execution.

[0015] 3. This invention constructs a data isolation and long-term management mechanism based on user identifiers through a user variable database module. The system utilizes technologies such as consistent hashing to ensure the independence of travel plan variables and profile data for different users at the storage level, preventing data confusion and privacy leaks. Simultaneously, the system can record users' historical travel status and actual travel behavior. By calculating interest coefficients and updating the label weights in the long-term preference model, the system can continuously refine its intent prediction model as interaction data accumulates, thereby providing users with more accurate and personalized proactive planning services. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the overall architecture of the user data-based travel intention prediction and proactive dialogue planning system of the present invention. Figure 2 This is a schematic diagram illustrating the process of the user data-based travel intention prediction and proactive dialogue planning method of the present invention.

[0017] Among them, 10 is the user interaction terminal; 20 is the cloud server; 201 is the voice interaction module; 202 is the intent recognition module; 203 is the user variable database module; 204 is the dialogue management module; 205 is the itinerary generation module; 206 is the travel companion module; and 207 is the external tool calling module. Detailed Implementation

[0018] The technical solutions in 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 embodiments of the present invention, and not all embodiments. 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.

[0019] See attached document Figure 1 This invention provides a travel intention prediction and proactive dialogue planning system based on user data. The system includes a user interaction terminal 10 and a cloud server 20. The user interaction terminal 10 is connected to the cloud server 20 via a communication network. The user interaction terminal 10 is equipped with an audio acquisition device and an audio playback device for acquiring the user's voice signal and playing feedback voice.

[0020] The cloud server 20 is configured with multiple functional modules for processing business logic, including a voice interaction module 201, an intent recognition module 202, a user variable database module 203, a dialogue management module 204, an itinerary generation module 205, a travel companion module 206, and an external tool invocation module 207. Specifically, the voice interaction module 201 handles the conversion between voice signals and text data. The intent recognition module 202 parses the intent categories and parameter slots in the text data. The user variable database module 203 stores travel plan variables bound to user identifiers and user profile data, and implements data isolation between different users. The dialogue management module 204 maintains session state, performs missing information detection, and controls business flow. The itinerary generation module 205 generates itinerary plans based on travel plan variables. The travel companion module 206 provides location- and time-based response services during the itinerary execution phase. The external tool invocation module 207 encapsulates and invokes third-party service interfaces.

[0021] See attached document Figure 2 The travel intention prediction and proactive dialogue planning method based on user data provided by the present invention mainly includes steps S1 to S8.

[0022] In step S1, the voice interaction module 201 performs the user voice input acquisition step. The voice interaction module 201 receives natural voice input uploaded by the user interaction terminal 10. The voice interaction module 201 uses automatic speech recognition technology to convert the natural voice input into text input data and transmits the text input data to the intent recognition module 202.

[0023] In step S2, the intent recognition module 202 performs a travel intent recognition step. The intent recognition module 202 receives text input data and performs semantic analysis on it. The intent recognition module 202 determines whether the text input data contains travel-related intents and classifies the identified intents into at least one type: travel plan formulation, travel plan completion, in-trip inquiry, or travel plan modification. The intent recognition module 202 outputs intent type labels and key slot information contained in the text.

[0024] In step S3, the user variable database module 203 performs the trip variable reading step. The user variable database module 203 obtains the unique identifier of the current user. Based on the unique identifier, the user variable database module 203 retrieves and reads the current travel plan variable bound to that user from the database. If the current travel plan variable for that user does not exist in the database, the user variable database module 203 initializes a preset travel plan variable template as the current travel plan variable.

[0025] In step S4, the dialogue management module 204 performs information extraction and writing steps. The dialogue management module 204 combines the user's current text input data and the key slot information output by the intent recognition module 202 to extract the determined travel element data. The travel element data includes destination, time, number of people, or budget parameters. The dialogue management module 204 writes the extracted travel element data into the corresponding field of the current travel plan variable. When the corresponding field already has a value, the dialogue management module 204 performs an overwrite operation to update the value of that field.

[0026] In step S5, the dialogue management module 204 performs a missing detection and completion guidance step. The dialogue management module 204 performs an integrity scan of the fields in the current travel plan variables. The dialogue management module 204 identifies missing key fields that have not yet been assigned values ​​and are necessary conditions for the plan. Based on preset field priority rules, the dialogue management module 204 generates guided query text for the missing key fields and sends it to the user interaction terminal 10 via the voice interaction module 201 to obtain the user's completion information.

[0027] In step S6, the itinerary generation module 205 executes the travel plan generation step. When the dialogue management module 204 determines that the key fields in the current travel plan variables meet the preset planning conditions, it triggers the itinerary generation module 205. The itinerary generation module 205 reads the status data of the current travel plan variables and calls the external data service interface through the external tool calling module 207 to obtain flight, hotel, or attraction data. The itinerary generation module 205 combines the obtained data with the current travel plan variables to generate a structured, phased travel arrangement result.

[0028] In step S7, the travel companion module 206 executes the real-time service steps during the trip. During the execution period of the travel plan, the travel companion module 206 receives real-time inquiries or change instructions from the user. On the one hand, the travel companion module 206 receives real-time inquiries or change instructions from the user; on the other hand, it can also proactively trigger prompts or suggestions based on the comparison results between the time information and real-time location information in the current travel plan variables. The travel companion module 206 modifies the affected local fields in the current travel plan variables without regenerating the entire travel plan.

[0029] In step S8, the user variable database module 203 performs a state storage and continuous update step. After each information update in step S4, plan generation in step S6, or real-time adjustment in step S7, the user variable database module 203 writes the latest current travel plan variable state data to the database for persistent storage. This step ensures that the user can reload and continue to use the updated travel plan variable data in subsequent interaction sessions.

[0030] Based on the above system architecture, steps S1 to S2 involve the transformation process from raw acoustic signals to structured semantic information. The specific implementation logic of these two steps is described in detail below.

[0031] Reference Appendix Figure 2 The user voice input acquisition step S1 can specifically include the following sub-steps: Sub-step S101: The voice interaction module 201 receives the audio data stream in real time through the audio acquisition interface of the user interaction terminal 10. The voice interaction module 201 performs voice activity detection on the audio data stream. The voice activity detection algorithm, based on short-time energy and zero-crossing rate characteristics, determines whether the audio frame contains a valid voice signal, thereby filtering out environmental background noise and silent segments, and extracting valid voice segments containing user commands. For the specific implementation of the voice activity detection algorithm, those skilled in the art can use existing signal processing techniques, which are well-known in the field and will not be elaborated here.

[0032] Sub-step S102: The voice interaction module 201 performs automatic speech recognition on the extracted valid speech segments. This process utilizes acoustic and language models to decode the continuous acoustic feature sequence into a natural language text sequence. After decoding, the voice interaction module 201 performs inverse text normalization processing on the generated text sequence. This processing specifically includes: converting content expressed in Chinese numerals in the speech into Arabic numerals (e.g., converting 3500 to 3500); converting colloquial relative date descriptions into standard date formats (e.g., converting the day after tomorrow to 202X-XX-XX); and removing interjections and meaningless pause words from the text. After the above processing, standardized text input data is finally formed.

[0033] The core of step S2, the tourism intent recognition step, lies in mapping unstructured natural language text into computer-processable intent categories and parameter slots. This embodiment employs a semantic analysis architecture based on a pre-trained language model to implement this step.

[0034] Step S2 specifically includes the following sub-steps: Sub-step S201: The intent recognition module 202 receives text input data from the voice interaction module 201. The intent recognition module 202 uses a deep neural network encoder to encode the text input data, extracting the contextual semantic features of the text and generating a feature vector sequence containing high-dimensional semantic information. To handle the referential resolution problem in multi-turn dialogues, the intent recognition module 202 concatenates the text history of the previous turn with the current text input data as a joint input, thereby enabling the generated feature vector to encompass historical contextual information.

[0035] Sub-step S202: The intent recognition module 202 performs intent classification prediction based on the feature vector sequence. The intent recognition module 202 calculates the confidence score of the input text belonging to each predefined intent category. The predefined intent category set includes at least: travel plan creation (user requests to create a new itinerary), travel plan completion (user responds to follow-up questions from the system), real-time inquiry during the trip (user queries information during the itinerary), and travel plan modification (user changes existing arrangements). The intent recognition module 202 selects the category with the highest confidence score that exceeds a preset threshold as the final intent recognition result.

[0036] Sub-step S203: The intent recognition module 202 executes the slot filling task in parallel. This task uses sequence labeling to perform entity recognition on each character or word in the text input data, extracting the key elements required for the travel plan. The slot types corresponding to the key elements include: destination, departure date, number of trip days, number of companions, budget range, and preference tags. The intent recognition module 202 outputs all entity fragments identified in the text and their corresponding slot types.

[0037] Sub-step S204: The intent recognition module 202 normalizes the identified entity fragments. The intent recognition module 202 calls the basic data service to convert the entities described in natural language into a standard data format that can be computed internally by the system. Specific processing logic includes: for time-related entities, mapping relative time descriptions to specific calendar timestamps; for numerical entities, converting ambiguous quantitative descriptions to specific numerical ranges or integer values; for location-related entities, mapping them to standard administrative division names or point-of-interest names. After the above processing, the intent recognition module 202 outputs a determined intent type label and a list of key slot information in key-value pair format, providing structured data support for the subsequent information processing of the dialogue management module 204.

[0038] After completing intent recognition and slot extraction, the context management process begins, namely steps S3 to S4.

[0039] Reference Appendix Figure 2 Step S3, the process variable reading step, specifically includes the following sub-steps: Sub-step S301: The user variable database module 203 parses the user's unique identifier from the request message sent by the user interaction terminal 10. This unique identifier serves as the primary key index or namespace prefix for database queries. Based on the user's unique identifier, the user variable database module 203 locates the corresponding user data shard in the cloud-based distributed database. The distributed database uses a consistent hashing algorithm based on the user's unique identifier for data routing, ensuring that read and write requests from the same user always land on the same storage node, thereby achieving isolation of different user data at the physical storage level. For specific distributed database routing rules, those skilled in the art can use existing database middleware technologies, which are well-known in the field and will not be elaborated upon here.

[0040] Sub-step S302: Within the located user data fragment, query the trip plan variable object whose status is marked as active. The trip plan variable object is stored in the storage medium as a JavaScript object abbreviation format or a serialized binary object. If the query returns a non-empty result, read the object and deserialize it into structure data in memory, restoring the context state of the previous round of dialogue; if the query result is empty, instantiate a new trip variable template object.

[0041] Sub-step S303: The itinerary variable template object contains a predefined key-value pair structure. This structure includes: single-value fields for storing unique constraints, including departure point, destination, departure date, and budget limit; set fields for storing cumulative attributes, including a list of preference tags and a list of avoided items; and status control fields, including a current planning stage marker. The initialization operation sets the values ​​of the above fields to null or the system default initial values.

[0042] Reference Appendix Figure 2 The information extraction and writing step S4 specifically includes the following sub-steps: Sub-step S401: The dialogue management module 204 receives the list of key slot information output in step S2 and iterates through each key-value pair in the list. The system maintains a field mapping table, which defines the correspondence between natural language slot names and run variable template field names. Based on this mapping table, the identified slot information is matched to the corresponding template field.

[0043] Sub-step S402: The dialogue management module 204 executes a differentiated update strategy based on the data type of the target field. If the target field is a single-value field (such as destination or departure date), an overwrite update operation is performed, writing the newly identified value into the field and discarding the old value. If the target field is a set field (such as preference tags), an incremental append operation is performed, adding the new value to the end of the list and deduplicating the list. This logic ensures that the system can respond to the user's modification commands (overwriting old values) and supplementary commands (adding preferences).

[0044] Sub-step S403: After updating the fields of the variable object in memory, the dialogue management module 204 performs a persistence operation. The system calls the database write interface, using the user's unique identifier as the key, to serialize and overwrite the updated itinerary plan variable object to the cloud database. The write operation uses an atomic transaction mechanism to ensure data consistency. Through this step, the user's itinerary planning status is saved in real time, supporting session continuation across devices.

[0045] After updating the user's trip variable status, the system enters the logical judgment stage, namely steps S5 to S6.

[0046] Reference Appendix Figure 2 Step S5, the missing detection and completion guidance step, specifically includes the following sub-steps: Sub-step S501: The dialogue management module 204 reads the currently updated itinerary plan variable object and loads the preset set of planning constraint rules. The set of planning constraint rules is stored in system memory or a database as a configuration file, defining the core field identifiers required to generate the minimum feasible itinerary and the validity validation logic for each field. This list includes at least: destination, departure date, number of trip days, and number of travelers. The dialogue management module 204 iterates through each field in the itinerary plan variable object, using validation logic to check whether the field values ​​are null, empty strings, or invalid formats. The system stores all core field identifiers determined to be invalid in the missing element list.

[0047] Sub-step S502: The dialogue management module 204 prioritizes the fields in the missing element list. The system has a pre-set field priority weight table, which sets values ​​based on the dependence of each field on trip generation. The specific sorting logic is as follows: spatial constraint fields (destination) have higher priority than time constraint fields (departure date, trip days), time constraint fields have higher priority than resource constraint fields (budget, number of people), and resource constraint fields have higher priority than attribute preference fields (accommodation, food). Based on this weight table, the dialogue management module 204 selects the highest priority field from the missing element list as the target to be queried. To prevent information overload in a single interaction, the system sets a single-round follow-up question threshold, limiting the number of follow-up question variables generated in a single session to no more than two. Sub-step S503: If the missing element list is not empty, the system generates guided voice questions based on the selected target to be queried. The system calls the natural language generation component and uses slot filling technology to inject the name of the field to be queried into the pre-set question template, or inputs the missing field as a constraint into the text generation model to construct a question statement targeting the missing field. For example, if the departure date is missing, the system generates a voice command to inquire about the departure time. This guiding question is sent to the user interaction terminal 10 for playback, and the system simultaneously marks the dialogue state machine as waiting for slot filling, ending the current round of processing and waiting for user input. If the list of missing elements is empty, it indicates that the current itinerary planning variable object has met the minimum planning conditions, and the system automatically triggers step S6.

[0048] Reference Appendix Figure 2 Step S6, the travel plan generation step, specifically includes the following sub-steps: Sub-step S601: The itinerary generation module 205 constructs prompts for generating the itinerary framework. This construction process employs a prompt template injection technique: the system calls a pre-set itinerary generation prompt template, reads structured data (such as destination and number of days) from the itinerary plan variable object, and fills it into the variable slots corresponding to the template. Simultaneously, the system appends constraints such as the daily attraction visit order and reserved travel time to the prompt sequence. The system inputs the constructed prompt sequence into a pre-trained language model, and the model, based on contextual reasoning, outputs a semi-structured text framework containing daily visit nodes, approximate time arrangements, and suggested activities.

[0049] Sub-step S602: The external tool calling module 207 parses the generated text frame and identifies the information slots that require real-time data support. The parsing process uses a named entity recognition algorithm or a regular expression matching algorithm based on specific tags. The system scans the text frame and extracts the attraction entity name, geographical coordinates, and time node. Based on the extracted entity information, it dynamically constructs a call request for the external service interface. Specifically, this includes: extracting the attraction name from the text frame, calling the attraction information query interface to obtain the attraction's opening hours, ticket price, and suggested visit duration; extracting the destination city and date information, calling the weather query interface to obtain weather forecast data for the next few days; and extracting traffic node information, calling the route planning API to calculate the travel time between attractions.

[0050] Sub-step S603: The itinerary generation module 205 receives real-time data returned by various external service interfaces and integrates it into a text framework. The system executes rule-based post-processing logic to verify and correct the original framework. The system maintains a scene attribute mapping table, which defines the correspondence between environmental attributes and itinerary actions. For example, if the weather interface returns the attribute of heavy rain, the system triggers the outdoor-to-indoor rule according to the mapping table, and searches for nearby indoor venues (such as museums and shopping malls) to replace the originally planned outdoor attraction entity; if the attraction interface returns a closed status, the node is removed from the itinerary chain or adjusted to another date. For the specific communication protocols and data parsing methods of the external service interfaces, those skilled in the art can use existing expressive state transition application programming interface (API) calling technologies, which are well-known technologies in the field and will not be elaborated here.

[0051] Sub-step S604: The system converts the final itinerary plan, after data fusion and logical verification, into a natural language description. This description not only includes the itinerary arranged chronologically but also integrates comprehensive information such as flight reference prices, hotel recommendations, and weather reminders. The final generated text is converted into a speech stream using speech synthesis technology and read aloud to the user by the user interaction terminal 10, completing a full itinerary planning loop.

[0052] To support the acquisition and fusion of real-time data in step S6, the system is configured with an external tool call module 207, which executes the following specific service call and data processing flow, namely steps S610 to S640.

[0053] Reference Appendix Figure 2 The service interface registration and resolution step S610 specifically includes the following logic: Sub-step S611: During the system initialization phase, the external tool calls module 207 to load a pre-configured service registry. This registry is stored in the form of key-value pairs or JavaScript object simplification configuration files, and defines in detail the technical metadata of each external service interface. The technical metadata includes at least: a unique identifier for the interface, a communication protocol type, a request method, a service endpoint URL, request parameter definitions (including lists of required and optional parameters), response parameter definitions (including the field names and data types returned by the interface), and authentication credentials. For example, for a weather query interface, the registry records that it requires longitude, latitude, and date as input parameters, and explicitly defines that its output data includes fields such as temperature, precipitation probability, and weather conditions.

[0054] Sub-step S612: When an external service call request is received from step S602, the external tool call module 207 retrieves the corresponding interface configuration from the service registry based on the service intent identifier in the request. The system performs a parameter integrity check, matching the entity information extracted from the text frame with the required parameters defined in the registry. If any required parameters are missing, i.e., the current context cannot provide the necessary input fields required by the interface, the system triggers a parameter completion mechanism.

[0055] Reference Appendix Figure 2 The chain dependency processing and parameter construction steps in step S620 specifically include the following logic: Sub-step S621: For the parameter completion mechanism, the system constructs a service call dependency relationship using a directed acyclic graph structure, where nodes represent service interfaces and edges represent data input / output dependencies. When the system detects that the input parameters (such as latitude and longitude) required by the target interface (such as the weather interface) are missing, it traverses the response parameter definitions in the service registry and retrieves the preceding service interface (such as the geocoding interface) that can output the missing parameter. The system inserts this preceding service interface as the parent node into the execution queue, forming a chained call sequence.

[0056] Sub-step S622: The external tool invocation module 207 executes the invocation task according to the topological order determined by the dependency graph. After completing the invocation of the front-end interface, the system parses its response data, extracts the field values ​​with the same names as the input parameters of the downstream interface, and fills them into the request parameter body of the downstream interface to realize cross-interface data transfer. For example, the coordinate data returned by the geocoding interface is automatically filled into the request body of the weather query interface.

[0057] Reference Appendix Figure 2 The concurrent execution and circuit breaker steps in step S630 specifically include the following logic: Sub-step S631: For independent service nodes that do not have a sequential dependency relationship in the dependency graph, the external tool invocation module 207 uses a multi-threaded or asynchronous coroutine mechanism to make parallel invocations. For example, when querying detailed information about attraction A, the system simultaneously initiates query requests for attractions B and C to reduce the overall network I / O wait time.

[0058] Sub-step S632: The system monitors the response status code and response time of each service call. If a service interface does not respond or returns an error code within a preset timeout period, the system executes a preset circuit breaker strategy. This strategy includes: a retry mechanism, which performs a limited number of retry calls within a short period of time; and a degradation mechanism, which returns a preset default value or historical cached data when retries are ineffective, and adds a non-real-time data identifier to the returned result, thereby ensuring that the entire process generation process is not blocked due to a single point of failure.

[0059] Reference Appendix Figure 2 The data standardization and adaptation steps in step S640 specifically include the following logic: Sub-step S641: Due to the different data structures returned by different third-party services, an adapter layer is configured within the external tool call module 207. The adapter layer contains multiple parsing scripts or mapping rules for specific interfaces. The system runs the corresponding adapter scripts to convert the heterogeneous raw response data into a unified data format within the system. For example, it maps non-standard coordinate fields returned by different map service providers to the system's standard latitude and longitude fields.

[0060] Sub-step S642: The system performs business logic filtering on the standardized data. Based on user preferences in the itinerary planning variables, data items that do not meet the requirements are removed. For example, after obtaining a list of recommended hotels in the vicinity, the system filters and removes hotel options that exceed the user's budget limit, retaining only the candidate set that meets the criteria. The standardized and filtered data is finally returned to step S603 for text frame fusion and filling. The specific sending of HTTP requests and the serialization and deserialization of JSON data can be implemented using existing network communication libraries by those skilled in the art, which are well-known technologies in the field and will not be elaborated upon here.

[0061] During the trip execution phase, the system tracks the user's status and external environment in real time through the built-in travel companion module 206, and dynamically adjusts the trip plan based on the tracking results, specifically executing steps S710 to S740.

[0062] Reference Appendix Figure 2 The real-time status monitoring and data acquisition step S710 specifically includes the following logic: Sub-step S711: The travel companion module 206 establishes a communication connection with the user's mobile terminal and acquires the user's real-time geographical location coordinates at a preset sampling frequency. The travel companion module 206 calculates the spatial distance between the current geographical location and the target node corresponding to the current time period in the itinerary plan. At the same time, the travel companion module 206 reads the system time of the mobile terminal and marks it as the current timestamp.

[0063] Sub-step S712: The travel companion module 206, based on the current geographical coordinates, calls the external meteorological service interface and traffic situation interface through the external tool calling module 207 to obtain the real-time weather conditions (including precipitation type, temperature, wind force level) and the estimated travel time to the next destination in the area.

[0064] Sub-step S713: The travel companion module 206 performs structured storage on the real-time data collected above to form a current state vector. This state vector includes at least: user latitude and longitude, current time, current weather status code, road congestion index, and estimated arrival time of the next node.

[0065] Reference Appendix Figure 2 The deviation identification and rule matching step S720 specifically includes the following logic: Sub-step S721: The travel companion module 206 loads the itinerary plan table generated in step S6 and compares the current state vector obtained in step S710 with the predetermined parameters in the plan table. The travel companion module 206 sets a time deviation threshold (e.g., 15 minutes) and a spatial deviation threshold (e.g., 500 meters). If the current time exceeds the sum of the predetermined start time of the current node in the plan and the time deviation threshold, and the spatial distance between the user's current location and the current node is still greater than the spatial deviation threshold, the travel companion module 206 determines that the trip is delayed.

[0066] Sub-step S722: The travel companion module 206 performs environmental constraint verification. The travel companion module 206 extracts the attribute tags of the current plan node and its subsequent nodes, and checks whether they contain features such as outdoor or open-air conditions that are affected by weather. If the current weather status code is detected as severe weather (such as heavy rain or strong winds), and the corresponding itinerary node has the outdoor attribute, the travel companion module 206 determines it to be an environmental conflict state.

[0067] Sub-step S723: The travel companion module 206 calls module 207 through an external tool to query the third-party ticketing interface or the scenic spot operation status interface. If it receives a status code indicating that the reserved scenic spot is closed, undergoing temporary maintenance, or sold out, the travel companion module 206 determines that the resource is unavailable.

[0068] Step S730, the adjustment strategy generation and replanning step, specifically includes the following logic: Sub-step S731: When the travel companion module 206 determines that there is a travel delay, it triggers a time shifting strategy. The travel companion module 206 maintains the original order of the travel nodes and recalculates the estimated start and end times of all subsequent nodes based on the current time and the estimated travel time. If the end time of a shifted node exceeds the closing time of the venue, the travel companion module 206 marks the node as to be removed or replaced; for nodes marked as to be replaced, the travel companion module 206 automatically triggers the node replacement strategy in the subsequent sub-step S732.

[0069] Sub-step S732: When the travel companion module 206 determines that there is an environmental conflict, resource unavailability, or business hour conflict due to time shift, it triggers a node replacement strategy. The travel companion module 206 uses the geographical location of the original planned node as the center and a preset distance (e.g., 2 kilometers) as the radius to perform a surrounding search. The search criteria are: candidate locations with indoor attributes (for severe weather) or business status (for resource unavailability and time conflicts) and that match user preference data. The travel companion module 206 uses a weighted scoring algorithm to sort the retrieved candidate locations. The specific logic is as follows: read the user preference tags stored in the user variable database module 203, calculate the semantic similarity between the attribute tags of the candidate locations and the user preference tags, and use it as the content matching score; calculate the distance between the candidate locations and the original planned node, normalize it, and use it as the distance cost score; sum the content matching score and the distance cost score according to preset weights to obtain the final recommendation score. The travel companion module 206 selects the location with the highest recommendation score as the replacement node.

[0070] Sub-step S733: If the above adjustments result in a gap in the itinerary, the travel companion module 206 triggers a gap-filling strategy. The travel companion module 206 searches for points of interest near the current area in the user's favorites or browsing history and inserts them into the gap in the itinerary. If no suitable points of interest are found, the travel companion module 206 recommends general leisure-type nodes (such as cafes or rest areas) based on the current time period to fill the gap and generates a revised itinerary suggestion draft.

[0071] Reference Appendix Figure 2 The interactive confirmation and data synchronization steps in step S740 specifically include the following logic: Sub-step S741: The travel companion module 206 encapsulates the revised draft itinerary suggestion into a notification message and pushes it to the user's mobile terminal via the voice interaction module 201 and the communication network. This notification visually displays the reason for the change (such as heavy rain detected, severe congestion detected) and a comparison of the solutions before and after the change.

[0072] Sub-step S742: The travel companion module 206 receives feedback instructions from the user. If the user chooses to confirm the change, the travel companion module 206 uses the revised itinerary suggestion draft to overwrite the corresponding record in the user variable database module 203, and synchronously updates the calendar view and navigation route on the user's terminal; if the user chooses to refuse the change or manually adjust, the original plan is retained or the user is redirected to the manual editing page.

[0073] In order to achieve long-term management of user trip data and continuous optimization of personalized models, the system is configured with a user variable database module 203. The user variable database module 203 executes the following specific data processing and storage process, namely steps S810 to S840.

[0074] Reference Appendix Figure 2 The process state serialization and version control steps in step S810 specifically include the following logic: Sub-step S811: After the itinerary plan generated in step S6 is confirmed by the user, or the dynamic adjustment in step S7 is executed, the user variable database module 203 triggers a state saving instruction. The user variable database module 203 serializes the current itinerary plan variables in memory, converting them into structured text in JavaScript object notation or Extensible Markup Language format. The structured text fully records all elements of the itinerary, including destination, node order, time schedule, involved point of interest IDs, and current status markers.

[0075] Sub-step S812: The user variable database module 203 assigns a unique version number and timestamp to the generated structured text and writes it as a snapshot record to the trip history table of the user variable database. If the current operation is a modification of an existing trip, the user variable database module 203 does not directly overwrite the old record, but instead adds a new version record pointing to the same trip ID. This incremental version control mechanism allows the system to respond to the user's undo command in subsequent interactions, or to rewind the historical state of each change during trip review.

[0076] Reference Appendix Figure 2 The user data isolation and access control steps in step S820 specifically include the following logic: Sub-step S821: The user variable database module 203 adopts a multi-tenant logical isolation architecture. The system assigns a globally unique user identifier to each registered user. In the underlying database storage, all table structures contain the user identifier as a partition key or primary index field.

[0077] Sub-step S822: The user variable database module 203 deploys a middleware interceptor at the data access layer. When any read or write request is received, the interceptor forcibly verifies the authentication token in the request context, extracts the corresponding user identifier, and automatically appends the user identifier to the filtering conditions of the database query statement. Through this mandatory filtering mechanism, the system ensures that a specific user's query operation can only retrieve data records belonging to that user identifier, thereby logically constructing an independent data space and preventing cross-user data leakage or obfuscation.

[0078] Reference Appendix Figure 2 The preference model update and continuous learning steps in step S830 specifically include the following logic: Sub-step S831: At the end of the trip or a specific interaction node, the user variable database module 203 initiates a preference learning task. The user variable database module 203 extracts the attractions, hotels, and restaurants actually adopted by the user during this trip and retrieves the attribute tags corresponding to these nodes.

[0079] Sub-step S832: The user variable database module 203 reads the stored user long-term preference model. The user long-term preference model consists of a series of labels and their corresponding weight values. The user variable database module 203 calls the itinerary execution log generated by the travel companion module 206 to extract the actual dwell time data of the user in each node area. The user variable database module 203 performs a label weight update operation: First, it calculates the ratio of the actual dwell time to the preset standard tour time and uses the ratio as the interest coefficient; second, it weights and accumulates the interest coefficient with the corresponding label weights to obtain the updated intermediate weight value; finally, it normalizes the weight values ​​of all labels and maps the sum of all weights to a preset numerical range, thereby maintaining the stability of the model values ​​and preventing the weight values ​​from expanding infinitely with the increase of the number of interactions.

[0080] Sub-step S833: The user variable database module 203 writes the updated preference model back to the archive area to guide the initial parameter settings for the next trip planning. Through this data iterative update mechanism, the system can continuously optimize the accuracy of predicting user intent as the number of interactions increases.

[0081] Reference Appendix ​ Step S840, the multi-terminal data synchronization and consistency maintenance step, specifically includes the following logic: Sub-step S841: When a user logs in or activates the system on any terminal device, the device sends a synchronization request to the cloud server 20, which carries the last update timestamp stored locally on the device.

[0082] Sub-step S842: The cloud system (i.e., user variable database module 203) queries the database to retrieve all trip change records and preference update records generated by the user after the last update timestamp. If updated data exists, the user variable database module 203 sends the difference data packet to the requesting device. After receiving the data, the device updates the locally cached trip view and user configuration to ensure that the user can obtain a continuous and consistent trip status and interactive experience when switching between different devices. For data transmission encryption and specific conflict resolution strategies, those skilled in the art can use existing data synchronization protocols for implementation, which are well-known technologies in the field and will not be elaborated here.

Claims

1. A method for predicting travel intentions and planning proactive dialogue based on user data, characterized in that, Includes the following steps: The voice interaction module (201) receives voice input from the user interaction terminal (10) and converts it into text; the intent recognition module (202) parses the intent category and key slots in the text. The user variable database module (203) reads the travel plan variable based on the user identifier, and the dialogue management module (204) extracts travel element data according to the intent category and the key slot and writes it into the travel plan variable. The dialogue management module (204) performs an integrity scan on the travel plan variables to identify missing fields and generates guided queries. When it is determined that the planning conditions are met, the itinerary generation module (205) is triggered. The itinerary generation module (205) reads the travel plan variables and uses the external tool call module (207) to call the external service interface to obtain data in order to generate an itinerary plan; During the trip execution phase, the travel companion module (206) updates local fields of the travel plan variables based on the comparison results of real-time location and time information or user instructions. The user variable database module (203) writes the updated travel plan variables into the database for persistent storage.

2. The method for predicting travel intentions and proactive dialogue planning based on user data according to claim 1, characterized in that, The voice interaction module (201) performs short-time energy-based voice activity detection on the voice input to extract valid segments, and performs inverse text normalization processing, including number conversion and date normalization, on the recognized text sequence.

3. The method for predicting travel intentions and proactive dialogue planning based on user data according to claim 1, characterized in that, The intent recognition module (202) uses a deep neural network encoder to encode the text, concatenates the previous dialogue history with the current text as joint input to generate a feature vector sequence, and performs intent classification prediction and slot filling tasks in parallel based on the feature vector sequence to parse out the intent category and the key slot.

4. The method for predicting travel intentions and proactive dialogue planning based on user data according to claim 1, characterized in that, When the user variable database module (203) performs the step of reading travel plan variables based on user identifier, it specifically includes: A consistent hashing algorithm is used to locate user data shards in a distributed database, and a pre-set travel plan variable template is instantiated as the travel plan variable when the query result is empty; When the dialogue management module (204) performs the step of writing the travel element data into the travel plan variable, it specifically includes: The travel element data is mapped to the target field in the travel plan variable, and differential updates are performed according to the type of the target field: a cover operation is performed on single-value fields, and incremental appending and deduplication operations are performed on set fields.

5. The method for predicting travel intentions and proactive dialogue planning based on user data according to claim 1, characterized in that, The dialogue management module (204) classifies the missing fields into spatial constraint fields, time constraint fields, or resource constraint fields, and generates the guided query based on field priority rules; The field priority rule sets the priority of the spatial constraint field to be higher than that of the time constraint field, and the priority of the time constraint field to be higher than that of the resource constraint field. The dialogue management module (204) prioritizes the missing field with the highest priority to generate the guided query.

6. The method for predicting travel intentions and proactive dialogue planning based on user data according to claim 1, characterized in that, After reading the travel plan variables, the itinerary generation module (205) fills the data of the travel plan variables into the prompt word template and inputs it into the pre-trained language model to generate a preliminary text framework containing the information to be filled. When the external tool calling module (207) performs the step of calling the external service interface, it performs named entity recognition on the preliminary text framework, extracts the information slots used to construct the interface request, uses the information slots to construct the interface request, and executes the interface request to obtain service response data. When performing the step of generating the itinerary plan, the itinerary generation module (205) integrates the service response data into the preliminary text framework to generate the itinerary plan.

7. The method for predicting travel intentions and proactive dialogue planning based on user data according to claim 6, characterized in that, When constructing the interface request, the external tool calling module (207) loads the service registry and checks the required parameters; If the verification finds that the parameter is missing, the external tool calling module (207) constructs the dependency relationship of the directed acyclic graph structure, retrieves the front-end interface that can output the missing parameter, automatically fills the response data of the front-end interface into the request body of the downstream interface, and executes chain calls in topological order to obtain the service response data.

8. The method for predicting travel intentions and proactive dialogue planning based on user data according to claim 1, characterized in that, The travel companion module (206) performs the following deviation identification based on the real-time location and time information to generate the comparison result: When the current time exceeds the sum of the node's predetermined time and the threshold, and the distance is still greater than the spatial threshold, the comparison result is determined to be a trip delay; When severe weather is detected and the node has outdoor attributes, the comparison result is determined to be an environmental conflict. The real-time operational status returned by the external service interface is compared with the travel plan variable. When the status is closed or sold out, the comparison result indicating that the resource is unavailable is generated.

9. The method for predicting travel intentions and proactive dialogue planning based on user data according to claim 8, characterized in that, When the travel companion module (206) updates a local field of the travel plan variable based on the comparison result, it specifically includes the following steps: For the replacement of execution nodes due to trip delays, execution time shifts, environmental conflicts, or resource unavailability, alternative locations are retrieved with the original node as the center and sorted using a weighted scoring algorithm; The weighted scoring algorithm includes calculating the semantic similarity between candidate locations and user preference tags as a content matching score, calculating the normalized distance as a distance cost score, and weighting and summing the two to select the optimal candidate location to update the local fields of the travel plan variable.

10. The method for predicting travel intentions and proactive dialogue planning based on user data according to claim 1, characterized in that, When the user variable database module (203) performs the step of writing the updated travel plan variable into the database for persistent storage, it uses the data of the travel plan variable to perform preference learning: Extract the attribute tags of the nodes actually adopted by the user, and calculate the ratio of the actual dwell time to the standard dwell time as the interest coefficient; The interest coefficient is weighted and accumulated with the label weights in the long-term preference model. After normalizing all weights, the updated long-term preference model is written into the database for persistent storage.

Images