Trip planning method and device, electronic equipment, storage medium and program product

Abstract

The invention provides an itinerary planning method and device, electronic equipment, a storage medium and a program product, and relates to the technical field of machine learning, the method comprises the steps that user demand description and a large language model are acquired, and the large language model comprises an intention recognition sub-model, a candidate position retrieval sub-model and an itinerary planning sub-model; inputting the user demand description into an intention recognition sub-model for intention recognition, and obtaining a user travel intention corresponding to the user demand description; inputting a display demand and an implicit demand in the travel intention of the user into a candidate position retrieval sub-model for position retrieval, and obtaining a destination corresponding to the travel intention of the user and a candidate address list corresponding to the destination; and inputting the display demand, the implicit demand, the destination and the candidate address list into the itinerary planning sub-model for itinerary planning, and outputting itinerary planning information matched with the travel intention of the user, thereby automatically processing user demand description and itinerary planning, reducing time and cost of manual planning, and improving service efficiency.

Description

Technical Field

[0001] This invention relates to the field of machine learning technology, and in particular to a journey planning method, a journey planning device, an electronic device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] Trip planning refers to the arrangement and preparation process surrounding various aspects such as destination, time, budget, transportation, accommodation, dining, and activities in order to achieve the purpose of travel. This process includes determining the departure and destination, planning travel and return dates, selecting places to visit, developing a travel itinerary, and allocating the budget and choosing suitable modes of transportation. Trip planning aims to ensure that travelers' needs are met while minimizing time and cost and improving the travel experience. However, trip planning is a complex optimization problem that requires consideration of multiple constraints, and users encounter at least the following problems when developing trip plans:

[0003] 1. Information retrieval and integration: It is necessary to collect information about the destination from different sources (such as travel websites, social media, travel guides, etc.), effectively integrate this information, and extract the most useful information for one's own trip.

[0004] 2. Personalization: Every traveler has unique needs and preferences, including travel destinations, budgets, accommodation standards, transportation choices, and activity preferences. Therefore, trips need to be highly personalized. Ensuring that the plan meets the specific needs of individual travelers and their unique travel vision is a challenge.

[0005] 3. Time Management and Arrangement: It's necessary to rationally plan the order of sightseeing and the duration of each stop within a limited timeframe. Ensure a reasonable allocation of time between different attractions and activities to avoid wasting time, while maintaining flexibility in the itinerary to accommodate unforeseen circumstances.

[0006] 4. Balancing Cost-Effectiveness: Trip planning often requires finding a balance between enjoyment and budget. How can we minimize expenses while ensuring the quality of the trip? Summary of the Invention

[0007] This invention provides a method, apparatus, electronic device, computer-readable storage medium, and computer program product for trip planning, in order to solve or partially solve the problems of high difficulty in information integration, poor personalization, and high planning costs in the trip planning process.

[0008] This invention discloses a trip planning method, comprising:

[0009] Obtain user demand descriptions and a large language model, wherein the large language model includes at least an intent recognition sub-model, a candidate location retrieval sub-model, and a trip planning sub-model;

[0010] The user demand description is input into the intent recognition sub-model for intent recognition to obtain the user travel intent corresponding to the user demand description. The user travel intent includes at least explicit demand and implicit demand.

[0011] The display requirements and the implicit requirements are input into the candidate location retrieval sub-model to perform location retrieval, thereby obtaining the destination corresponding to the user's travel intention and a list of candidate addresses corresponding to the destination.

[0012] The displayed requirements, the implicit requirements, the destination, and the candidate address list are input into the trip planning sub-model to perform trip planning, and the trip planning information that matches the user's travel intention is output.

[0013] In some optional embodiments, the step of inputting the display requirement and the implicit requirement into the candidate location retrieval submodel for location retrieval to obtain the destination corresponding to the user's travel intention and the candidate address list corresponding to the destination includes:

[0014] The candidate location retrieval sub-model processes the display requirements and the implicit requirements to obtain the destination retrieval request;

[0015] The candidate location retrieval sub-model is used to process the destination retrieval request in order to retrieve the destination and obtain the destination corresponding to the destination retrieval request, as well as the basic information of the target corresponding to the destination.

[0016] The candidate location retrieval sub-model processes the display requirements, the implicit requirements, and the basic description of the target to obtain candidate location retrieval requests.

[0017] The candidate location retrieval sub-model processes the candidate location retrieval request to retrieve candidate addresses and obtain a list of candidate addresses corresponding to the destination.

[0018] In some optional embodiments, the candidate location retrieval sub-model includes at least a first retrieval sub-model and a first retrieval interface corresponding to the first retrieval sub-model. The destination retrieval request includes either a first destination retrieval request or a second destination retrieval request. Processing the destination retrieval request through the candidate location retrieval sub-model to retrieve the destination and obtain the destination corresponding to the destination retrieval request and a basic description of the target corresponding to the destination includes:

[0019] If the display requirement includes a first destination, then the first search interface is called through the first search sub-model to process the search request for the first destination, so as to search for the first destination and obtain the first basic introduction corresponding to the first destination;

[0020] If the display requirement does not include the first destination, the first search interface is called through the first search sub-model to process the second destination search request, so as to search for the destination, obtain the second destination corresponding to the second destination search request, and the second basic introduction corresponding to the second destination;

[0021] The second destination is either the first destination or another destination different from the first destination.

[0022] In some optional embodiments, the candidate location retrieval sub-model includes at least a second retrieval sub-model and a second retrieval interface corresponding to the second retrieval sub-model. The candidate location retrieval request includes either a first candidate location retrieval request or a second candidate location retrieval request. Processing the candidate location retrieval request through the candidate location retrieval sub-model to retrieve candidate addresses and obtain a list of candidate addresses corresponding to the destination includes:

[0023] If the display requirement includes a first destination, then the second search interface is called through the second search sub-model to process the first candidate location search request, so as to perform candidate address search for the first destination and obtain the first candidate address list corresponding to the first destination;

[0024] If the display requirement does not include the first destination, the second search interface is called through the second search sub-model to process the second candidate location search request, so as to perform candidate address search for the second destination and obtain the second candidate address list corresponding to the second destination.

[0025] In some optional embodiments, the trip planning sub-model includes at least a trip map generation sub-model, a macro-planning sub-model, and a time planning sub-model. The step of inputting the explicit requirements, the implicit requirements, the destination, and the candidate address list into the trip planning sub-model for trip planning, and outputting trip planning information matching the user's travel intention, includes:

[0026] The spatial attributes corresponding to the candidate address list are processed by the trip map generation sub-model to construct the trip map and obtain the trip map corresponding to the destination.

[0027] The macro-planning sub-model processes the itinerary map, the explicit requirements, and the implicit requirements to divide the itinerary map into sub-maps corresponding to the itinerary map.

[0028] The time planning sub-model processes the itinerary map, the displayed requirements, and the implied requirements to perform itinerary planning on the itinerary sub-map and obtain the itinerary route corresponding to the itinerary sub-map.

[0029] In some optional embodiments, the candidate address list includes at least two candidate addresses, and the step of inputting the spatial attributes corresponding to the candidate address list into the trip map generation sub-model to construct a trip map and obtain a trip map corresponding to the destination includes:

[0030] The text description and spatial information corresponding to the candidate address are obtained from the spatial attributes by generating a sub-model from the travel map;

[0031] The spatial distance between two candidate addresses is calculated using the spatial information generated by the trip diagram sub-model.

[0032] The itinerary map generation sub-model constructs nodes corresponding to each candidate address in the map corresponding to the destination according to the spatial information, adds text descriptions to the nodes, and adds corresponding spatial distances between two nodes to obtain the itinerary map corresponding to the destination.

[0033] In some optional embodiments, the itinerary graph includes nodes corresponding to candidate addresses in the candidate address list, the display requirement includes at least the number of travel days, and the step of processing the itinerary graph, the display requirement, and the implicit requirement through the macro-planning sub-model to divide the itinerary in the itinerary graph and obtain a itinerary sub-graph corresponding to the itinerary graph includes:

[0034] The nodes included in the itinerary diagram are vector-encoded using the macro-planning sub-model to obtain node representation information corresponding to the nodes;

[0035] The macro-planning sub-model is used to extract features from the text description and spatial information corresponding to the node to obtain the text representation information corresponding to the node.

[0036] The macro-planning sub-model uses the node representation information, text representation information, display requirements, and implicit requirements to divide the itinerary in the itinerary map, thereby obtaining an itinerary sub-map that matches the number of days in the itinerary. Each itinerary sub-map corresponds to a day's itinerary planning.

[0037] In some optional embodiments, the step of processing the itinerary map, the explicit requirements, and the implicit requirements through the time planning sub-model to perform itinerary planning and obtain the itinerary route corresponding to the itinerary sub-map includes:

[0038] The nodes included in the itinerary diagram are vector-encoded using the time planning sub-model to obtain node representation information corresponding to the nodes;

[0039] The time planning sub-model sorts the node representation information according to the display requirements and the implicit requirements to obtain the travel routes corresponding to each travel sub-graph.

[0040] This invention also discloses a trip planning device, comprising:

[0041] The data acquisition module is used to acquire user demand descriptions and a large language model, wherein the large language model includes at least an intent recognition sub-model, a candidate location retrieval sub-model, and a trip planning sub-model.

[0042] The intent recognition module is used to input the user demand description into the intent recognition sub-model for intent recognition, and obtain the user travel intent corresponding to the user demand description. The user travel intent includes at least explicit demand and implicit demand.

[0043] The retrieval module is used to input the display requirements and the implicit requirements into the candidate location retrieval sub-model to perform location retrieval and obtain the destination corresponding to the user's travel intention and the candidate address list corresponding to the destination;

[0044] The planning module is used to input the displayed requirements, the implicit requirements, the destination and the candidate address list into the trip planning sub-model to perform trip planning, and output trip planning information that matches the user's travel intention.

[0045] In some optional embodiments, the retrieval module is specifically used for:

[0046] The candidate location retrieval sub-model processes the display requirements and the implicit requirements to obtain the destination retrieval request;

[0047] The candidate location retrieval sub-model is used to process the destination retrieval request in order to retrieve the destination and obtain the destination corresponding to the destination retrieval request, as well as the basic information of the target corresponding to the destination.

[0048] The candidate location retrieval sub-model processes the display requirements, the implicit requirements, and the basic description of the target to obtain candidate location retrieval requests.

[0049] The candidate location retrieval sub-model processes the candidate location retrieval request to retrieve candidate addresses and obtain a list of candidate addresses corresponding to the destination.

[0050] In some optional embodiments, the candidate location retrieval submodel includes at least a first retrieval submodel and a first interface corresponding to the first retrieval submodel, the destination retrieval request includes either a first destination retrieval request or a second destination retrieval request, and the retrieval module is specifically used for:

[0051] If the display requirement includes a first destination, then the first search interface is called through the first search sub-model to process the search request for the first destination, so as to search for the first destination and obtain the first basic introduction corresponding to the first destination;

[0052] If the display requirement does not include the first destination, the first search interface is called through the first search sub-model to process the second destination search request, so as to search for the destination, obtain the second destination corresponding to the second destination search request, and the second basic introduction corresponding to the second destination;

[0053] The second destination is either the first destination or another destination different from the first destination.

[0054] In some optional embodiments, the candidate location retrieval sub-model includes at least a second retrieval sub-model and a second interface corresponding to the second retrieval sub-model, the candidate location retrieval request includes either a first candidate location retrieval request or a second candidate location retrieval request, and the retrieval module is specifically used for:

[0055] If the display requirement includes a first destination, then the second search interface is called through the second search sub-model to process the first candidate location search request, so as to perform candidate address search for the first destination and obtain the first candidate address list corresponding to the first destination;

[0056] If the display requirement does not include the first destination, the second search interface is called through the second search sub-model to process the second candidate location search request, so as to perform candidate address search for the second destination and obtain the second candidate address list corresponding to the second destination.

[0057] In some optional embodiments, the itinerary planning sub-model includes at least an itinerary map generation sub-model, a macro-planning sub-model, and a time planning sub-model, and the planning module is specifically used for:

[0058] The spatial attributes corresponding to the candidate address list are processed by the trip map generation sub-model to construct the trip map and obtain the trip map corresponding to the destination.

[0059] The macro-planning sub-model processes the itinerary map, the explicit requirements, and the implicit requirements to divide the itinerary map into sub-maps corresponding to the itinerary map.

[0060] The time planning sub-model processes the itinerary map, the displayed requirements, and the implied requirements to perform itinerary planning on the itinerary sub-map and obtain the itinerary route corresponding to the itinerary sub-map.

[0061] In some optional embodiments, the candidate address list includes at least two candidate addresses, and the planning module is specifically used for:

[0062] The text description and spatial information corresponding to the candidate address are obtained from the spatial attributes by generating a sub-model from the travel map;

[0063] The spatial distance between two candidate addresses is calculated using the spatial information generated by the trip diagram sub-model.

[0064] The itinerary map generation sub-model constructs nodes corresponding to each candidate address in the map corresponding to the destination according to the spatial information, adds text descriptions to the nodes, and adds corresponding spatial distances between two nodes to obtain the itinerary map corresponding to the destination.

[0065] In some optional embodiments, the itinerary graph includes nodes corresponding to each candidate address in the candidate address list, the display requirement includes at least the number of travel days, and the planning module is specifically used for:

[0066] The nodes included in the itinerary diagram are vector-encoded using the macro-planning sub-model to obtain node representation information corresponding to the nodes;

[0067] The macro-planning sub-model is used to extract features from the text description and spatial information corresponding to the node to obtain the text representation information corresponding to the node.

[0068] The macro-planning sub-model uses the node representation information, text representation information, display requirements, and implicit requirements to divide the itinerary in the itinerary map, thereby obtaining an itinerary sub-map that matches the number of days in the itinerary. Each itinerary sub-map corresponds to a day's itinerary planning.

[0069] In some optional embodiments, the planning module is specifically used for:

[0070] The nodes included in the itinerary diagram are vector-encoded using the time planning sub-model to obtain node representation information corresponding to the nodes;

[0071] The time planning sub-model sorts the node representation information according to the display requirements and the implicit requirements to obtain the travel routes corresponding to each travel sub-graph.

[0072] This invention also discloses an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0073] The memory is used to store computer programs;

[0074] When the processor executes a program stored in the memory, it implements the method described in the embodiments of the present invention.

[0075] This invention also discloses a computer-readable storage medium storing instructions that, when executed by one or more processors, cause the processors to perform the methods described in this invention.

[0076] This invention also discloses a computer program product, including a computer program / instruction, wherein when the computer program / instruction is executed, it implements the method described in this invention.

[0077] The embodiments of the present invention have the following advantages:

[0078] In this embodiment of the invention, by acquiring user demand descriptions and a large language model, which includes at least an intent recognition sub-model, a candidate location retrieval sub-model, and a trip planning sub-model, the user demand description is then input into the intent recognition sub-model for intent recognition to obtain the user's travel intent corresponding to the user demand description. The user's travel intent includes at least explicit and implicit demands. Then, the explicit and implicit demands are input into the candidate location retrieval sub-model for location retrieval to obtain the destination corresponding to the user's travel intent and a list of candidate addresses corresponding to the destination. Finally, the explicit and implicit demands, the destination, and the list of candidate addresses are input into the trip planning sub-model for trip planning, outputting trip planning information that matches the user's travel intent. Thus, by analyzing the user's explicit and implicit demands, customized travel solutions can be provided to the user, improving user satisfaction and travel experience. The automated processing of user demand descriptions and trip planning reduces the time and cost of manual planning and improves service efficiency. Attached Figure Description

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

[0080] Figure 1 This is a flowchart of the steps of a trip planning method provided in an embodiment of the present invention;

[0081] Figure 2 This is a schematic diagram of the structure of the large language model provided in this embodiment of the invention;

[0082] Figure 3 This is a schematic diagram of a text-image alignment model provided in an embodiment of the present invention;

[0083] Figure 4 This is a schematic diagram of the planning information provided in the embodiments of the present invention;

[0084] Figure 5 This is a structural block diagram of a trip planning device provided in an embodiment of the present invention;

[0085] Figure 6 This is a block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0086] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0087] As an example, there are three main methods for itinerary planning: The first is a human-based method, which relies entirely on the expertise of human specialists. Experts communicate with users to understand their intentions, retrieve and integrate information, and develop a travel plan based on experience and reference materials. This method is labor-intensive, requiring significant time and effort to understand customer needs, research destination information, and create the travel plan. It is slow, costly, and offers inconsistent service quality.

[0088] The second approach is based on combinatorial optimization, which structures user needs after human experts have extracted the information. The system uses this structured demand information as constraints and solves for the optimal travel plan using the retrieved information. While this method can produce a plan that meets user needs, it requires complex modeling and predefinition for specific scenarios or users, and lacks generalization ability. Furthermore, this method remains highly inefficient in extracting user needs, relying on the assistance of human experts.

[0089] The third approach is based on large language models. Large language models possess excellent comprehension, training, and generalization capabilities, allowing them to replace human experts in understanding users' implicit and explicit needs. They integrate information retrieved externally using the RAG (Retrieval Augmented Generation) link to provide superior travel plans. The information integration process can be divided into two categories: landmark information and existing travel plan information. For the former, limited by the natural language learning paradigm, large language models have weak capabilities in solving complex planning problems, often failing to effectively meet user needs and returning unusable travel results. For the latter, large language models cannot meet personalized requirements by integrating existing travel plans.

[0090] In this invention, user needs descriptions and a large language model are obtained. The large language model includes at least an intent recognition sub-model, a candidate location retrieval sub-model, and a trip planning sub-model. The user needs description is then input into the intent recognition sub-model for intent recognition to obtain the user's travel intent, which includes at least explicit and implicit needs. The explicit and implicit needs are then input into the candidate location retrieval sub-model for location retrieval to obtain the destination and a list of candidate addresses corresponding to the destination. Finally, the explicit and implicit needs, the destination, and the candidate address list are input into the trip planning sub-model for trip planning, outputting trip planning information that matches the user's travel intent. By analyzing the user's explicit and implicit needs, customized travel solutions can be provided, improving user satisfaction and travel experience. The automated processing of user needs descriptions and trip planning reduces the time and cost of manual planning and improves service efficiency.

[0091] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, some technical features involved in the embodiments of the present invention are explained and described below:

[0092] User requirement descriptions are content input by users to express their needs, such as text, voice, and images. By analyzing user requirement descriptions, itinerary planning that meets user needs can be developed.

[0093] Trip planning information refers to a series of detailed information provided to users about how to travel, including planning and suggestions on destination, transportation, accommodation, activities, and dining.

[0094] Basic information can be information about the destination, such as city name, geographical location, tourist attractions, landmarks, special events and festivals, natural scenery, food and dining, transportation and accommodation, and climate.

[0095] The destination can be the user's intended travel location. The first destination can be a location explicitly stated in the explicit requirements; the second destination can be a location that matches the user's needs, derived from implicit requirements analysis. Correspondingly, the candidate address list can include recommended tourist attractions located at the destination.

[0096] A travel map can be a travel planning map corresponding to a destination. It can be a weighted complete graph composed of candidate addresses, with each candidate address corresponding to a node. Each node has corresponding spatial attributes, which characterize the geographic features and location information of the candidate addresses. Spatial attributes can include text descriptions and spatial information. The text descriptions can be introductory information about the candidate addresses; the spatial information can be the location information corresponding to the candidate addresses, such as their geographic coordinates. Based on the location information of two candidate addresses, the spatial distance between them can be calculated.

[0097] In addition, the itinerary map can include itinerary sub-maps, each of which can correspond to a day's itinerary. The number of itinerary sub-maps corresponds to the number of days in the user's itinerary. For example, if the number of days in the itinerary is n, then the number of itinerary sub-maps is also n.

[0098] Reference Figure 1 The diagram illustrates a flowchart of a trip planning method provided in an embodiment of the present invention, which may specifically include the following steps:

[0099] Step 101: Obtain user demand description and large language model, wherein the large language model includes at least an intent recognition sub-model, a candidate location retrieval sub-model, and a trip planning sub-model;

[0100] The large language model mainly includes an intent recognition sub-model, a candidate location retrieval sub-model, and a trip planning sub-model. The intent recognition sub-model is used to obtain the user's hard constraints (such as destination, travel time, budget, number of people, must-see destinations, etc.) and soft constraints (such as personal preferences, travel preferences, and itinerary expectations) based on the user's input description of needs, trained through the large language model. The candidate location retrieval sub-model takes the hard and soft constraints output by the previous intent recognition sub-model as input and generates a query through the large language model. The generated query request can be input into the corresponding retrieval model to perform city search (when the destination is unclear) and Top-k candidate location retrieval, outputting the destination and a list of candidate addresses for the destination city. The trip planning sub-model processes the hard and soft constraints output by the aforementioned two modules, as well as the list of candidate addresses for the destination city. This sub-model first generates a trip map from the candidate address list using a spatial analyzer, then performs two stages of trip planning: macro-planning and specific schedule planning, ultimately outputting a complete travel plan.

[0101] In one example, refer to Figure 2 This diagram illustrates the structure of a large language model provided in an embodiment of the present invention. The large language model may include an intent recognition sub-model, a candidate location retrieval sub-model, and a trip planning sub-model. The intent recognition sub-model may include a visible requirement extraction sub-module and an implicit requirement extraction sub-module. By inputting a user requirement description into the visible requirement extraction sub-module, visible requirements corresponding to the user requirement description can be extracted. By inputting a user requirement description into the implicit requirement extraction sub-module, implicit requirements corresponding to the user requirement description can be extracted. Then, the visible and implicit requirements extracted by the intent recognition sub-model can be input into the candidate location retrieval sub-model (which includes at least a first retrieval sub-model and a second retrieval sub-model, etc.) for querying, generating corresponding... The system receives a query request and then queries the corresponding destination and a list of candidate addresses for that destination city. The explicit and implicit requirements, the destination, and the list of candidate addresses are all input into the trip planning sub-model. The trip plan generation sub-model generates a corresponding trip plan, the macro-planning sub-model generates a corresponding macro-plan, and the time planning sub-model generates a corresponding schedule. By analyzing the user's explicit and implicit requirements, the system can provide customized travel solutions, improve user satisfaction and travel experience, automate user requirement descriptions and trip planning, reduce the time and cost of manual planning, and improve service efficiency.

[0102] Optionally, embodiments of the present invention can be applied to corresponding applications that can provide users with functions such as itinerary planning. Specifically, users can input their needs in a conversational manner within the application, and the application can provide corresponding itinerary planning suggestions based on the user's input. The application can deploy the large language model described in the above embodiments, thereby analyzing the user's explicit and implicit needs. On the one hand, it can provide users with customized travel solutions, improving user satisfaction and travel experience; on the other hand, it automates the processing of user need descriptions and itinerary planning, reducing the time and cost of manual planning and improving service efficiency; and on the other hand, it reduces the need for reliance on human experts for intent understanding, information retrieval, and integration, significantly improving itinerary planning efficiency while reducing costs associated with human resource investment.

[0103] Step 102: Input the user demand description into the intent recognition sub-model for intent recognition to obtain the user travel intent corresponding to the user demand description. The user travel intent includes at least explicit demand and implicit demand.

[0104] In this embodiment of the invention, users can input their corresponding user needs descriptions through dialogue. The large language model can then use an intent recognition sub-model to identify the user's travel intent corresponding to the user's needs description. The user's travel intent can include at least explicit and implicit needs. Explicit needs can be fixed settings in trip planning, which are constraints that must be met; while implicit needs can be flexible settings in the trip, which are constraints that can be partially compromised in the trip plan.

[0105] Optionally, explicit requirements can be hard constraints. When hard constraints are not met, the trip plan is unavailable, such as missing trip days, number of people, budget, or inability to identify the destination. Implicit requirements can be soft constraints. The higher the degree to which soft constraints are met, the higher the evaluation of the trip plan and the more it meets the user's needs. Implicit requirements can include information such as travel preferences, travel companion preferences, lifestyle habits, and travel expectations.

[0106] In its implementation, the intent recognition sub-model aims to extract the user's explicit needs (hard constraints) and implicit needs (soft constraints) from single-turn or multi-turn dialogues using natural language input. Optionally, the intent recognition sub-model can define the intent for both hard and soft constraints. After definition, training data can be constructed based on manual annotations and other large language models, and the intent recognition sub-model can be fine-tuned on an open-source platform to enable it to perceive intent.

[0107] In some examples, the data structure for the intent recognition sub-model can be as follows:

[0108] {

[0109] 'source':'human'

[0110] instruction':'You are a travel planning consultant. Please extract the user's hard and soft constraints based on the following dialogue:'

[0111] 1. Hard constraints refer to fixed settings in travel, which are constraints that must be met during itinerary planning. When hard constraints are not met, the itinerary planning is unusable. These include information such as the number of days, number of people, budget, and destination.

[0112] 2. Soft constraints refer to flexible settings in travel planning; they are constraints that can be partially compromised. The higher the degree to which soft constraints are met, the higher the evaluation of the trip. These include information such as travel preferences, travel companion preferences, lifestyle habits, and travel expectations.

[0113] 3. Analyze the dialogue step by step, and provide the hard and soft constraints and their corresponding reasons for each one.

[0114] 'query': My girlfriend and I want to go to Beijing for three days, with a budget of 3000 yuan. I don't like a very tight schedule, but I hope to see as many of Beijing's landmarks as possible. I think the Great Wall and the Forbidden City are a must-see. The rest can be arranged flexibly. We like natural scenery and ancient architecture. We will arrive and depart from Daxing Airport.

[0115] 'Anwser':'

[0116] Hard constraints:

[0117] i. Trip duration: 3 days -- The user explicitly stated that they wanted to spend "three days" in Beijing.

[0118] ii. Number of people: 2 -- Use "me and my girlfriend" to indicate that it is a trip for two.

[0119] iii. Budget: 3000 yuan -- The user mentions "budget of 3000 yuan", indicating that this is the upper limit of the travel expenses.

[0120] iv. Destination: Beijing -- The user specified "Beijing" as the destination for the trip.

[0121] v. Must-see attractions: Great Wall, Forbidden City -- The mention of "the Great Wall and the Forbidden City are must-sees" indicates that these two locations are not optional on the visit list.

[0122] vi. Arrival and Departure: Daxing Airport -- Users indicate that they will arrive and depart from Daxing Airport, which gives the specific locations where the trip begins and ends.

[0123] Soft constraints:

[0124] i. Flexible schedule: Users indicated that they "do not like overly tight schedules," which suggests a need for a certain degree of freedom and rest time.

[0125] ii. Landmark Tours: While it is mentioned that we should “visit as many of Beijing’s landmarks as possible,” it is also mentioned that “others can be arranged flexibly.” This means that, apart from the Great Wall and the Forbidden City, the order and duration of visits to other landmarks can be flexible.

[0126] i. Interests and preferences: Users mentioned "we like natural landscapes and ancient architecture", which suggests that the travel plan should include activities and attractions that match these preferences.

[0127] Based on user descriptions, we can summarize that hard constraints are mainly immutable conditions that must be followed, while soft constraints involve user preferences and desires, which can be handled flexibly to some extent depending on the circumstances. When making travel plans, hard constraints must be strictly followed, while soft constraints should be satisfied as much as possible to ensure the quality of the travel experience.

[0128] }

[0129] Through the above training process, an intent recognition sub-model that can predict user intent can be effectively trained, so as to effectively identify user travel intent during the trip planning process.

[0130] Step 103: Input the display requirements and the implicit requirements into the candidate location retrieval sub-model to perform location retrieval and obtain the destination corresponding to the user's travel intention and the candidate address list corresponding to the destination;

[0131] After identifying the user's explicit and implicit needs, these needs can be input into the candidate location retrieval sub-model for location retrieval. This process effectively identifies the user's desired travel destination and a list of candidate addresses that meet the user's needs. This candidate address list can include attractions within the destination city.

[0132] In some feasible implementations, a candidate location retrieval sub-model can be used to process explicit and implicit requirements to obtain destination retrieval requests. These requests are then processed to retrieve the destination and its basic information. Next, explicit, implicit, and basic information are processed to obtain candidate location retrieval requests. These requests are then processed to retrieve candidate addresses and obtain a list of candidate addresses corresponding to the destination. Thus, the candidate location retrieval sub-model can effectively identify the user's travel destination, retrieve a list of candidate addresses related to the destination, and obtain relevant search results from external sources through a retrieval interface. This effectively alleviates the problems of knowledge obsolescence and illusions in large language models, ensuring the effectiveness of the retrieval.

[0133] The candidate location retrieval sub-model includes at least a first retrieval sub-model (which can also be a city retrieval sub-model) and a first retrieval interface corresponding to the first retrieval sub-model. For the destination retrieval process, the first retrieval sub-model can first determine whether the displayed requirement includes the corresponding first destination, that is, the user's input requirement description explicitly indicates the desired travel destination. Specifically, if the displayed requirement includes the first destination, the first retrieval sub-model calls the first retrieval interface to process the first destination retrieval request, thereby retrieving the first destination and obtaining its corresponding first basic introduction. If the displayed requirement does not include the first destination, the first retrieval sub-model calls the first retrieval interface to process the second destination retrieval request, thereby retrieving the second destination corresponding to the second destination retrieval request and its corresponding second basic introduction. The second destination is either the first destination or another destination different from the first destination. This allows for quick retrieval of the corresponding destination based on the user's needs, enabling further candidate address retrieval based on the destination, ensuring retrieval efficiency while improving retrieval accuracy.

[0134] Accordingly, the candidate location retrieval sub-model also includes at least a second retrieval sub-model (which can also be a Top-k landmark retrieval sub-model, i.e., retrieving the top k landmarks in the destination and adding these landmarks to the candidate address list) and a second interface corresponding to the second retrieval sub-model. The candidate location retrieval request includes either a first candidate location retrieval request or a second candidate location retrieval request. In the process of retrieving candidate addresses, the retrieval can also be based on whether the user has clearly specified the travel destination in the user's requirement description. If the displayed requirement includes the first destination, the second retrieval sub-model calls the second retrieval interface to process the first candidate location retrieval request, so as to retrieve candidate addresses for the first destination and obtain the first candidate address list corresponding to the first destination. If the displayed requirement does not include the first destination, the second retrieval sub-model calls the second retrieval interface to process the second candidate location retrieval request, so as to retrieve candidate addresses for the second destination and obtain the second candidate address list corresponding to the second destination. Thus, after the destination is specified, the landmarks of the destination can be further retrieved to find a candidate address list that meets the user's requirements, ensuring that the final generated itinerary planning information can meet the user's needs and guarantee the user's travel experience.

[0135] It should be noted that the candidate location retrieval sub-model aims to retrieve destinations and candidate addresses using hard and soft constraints extracted from user requirements. In this process, the candidate location retrieval sub-model can be configured with corresponding retrieval interfaces. Based on the retrieval interfaces, external information can be integrated through the modeling model to obtain corresponding retrieval results from outside the model, thereby alleviating the problems of knowledge obsolescence and illusion in large language models and ensuring the effectiveness of retrieval. At the same time, by performing city retrieval and Top-k candidate location retrieval, the basic and characteristic information of the destination city is effectively integrated, which not only improves the accuracy of information retrieval but also ensures that the itinerary planning can fully consider the real and comprehensive situation of the destination.

[0136] In some examples, when the destination is determined, the city search module (i.e., the first retrieval sub-model) can be used to obtain a basic description of the destination city, helping the large language model better understand the city's characteristics. When the destination is uncertain, the city search module obtains a basic description of the target city that best matches the user's description. During the city search, the hard and soft constraints obtained from the previous module can be processed to perform the city search, for example:

[0137] Before the city search module processes display and implicit requirements:

[0138] Hard constraints:

[0139] 1. Trip duration: 3 days -- The user explicitly stated that they wanted to spend "three days" in Beijing.

[0140] 2. Number of people: 2 -- Using "me and my girlfriend" indicates that it is a trip for two people.

[0141] 3. Budget: 3000 yuan -- The user mentioned "budget of 3000 yuan", indicating that this is the upper limit of the travel expenses.

[0142] 4. Destination: Beijing -- The user specified "Beijing" as the destination for their trip.

[0143] 5. Must-see attractions: Great Wall and Forbidden City -- The mention of "the Great Wall and Forbidden City are must-sees" indicates that these two locations are not optional on the visit list.

[0144] 6. Arrival and Departure: Daxing Airport -- Users indicate that they will arrive and depart from Daxing Airport, which gives the specific locations where the trip begins and ends.

[0145] Soft constraints:

[0146] Flexible schedule: Users indicated that they "don't like overly tight schedules," which suggests a need for a certain degree of freedom and rest time.

[0147] Landmark Visits: While mentioning the goal of "visiting as many Beijing landmarks as possible," it also states that "others can be arranged flexibly," implying that the order and duration of visits to landmarks other than the Great Wall and the Forbidden City can be flexible. Interests and Preferences: Users mentioned "we like natural landscapes and ancient architecture," suggesting that the travel plan should include activities and attractions that match these preferences.

[0148] After processing the display and implicit requirements, the city search module:

[0149] The client has specific hard requirements for this trip, specifically requesting Beijing as the destination. Please provide basic information about Beijing to help us better understand and plan a travel itinerary that meets the client's needs.

[0150] Through the above processing, after obtaining the processed query, the system can invoke the tool by calling the retrieval API (Application Programming Interface) of the retrieval model.

[0151] Accordingly, for the Top-k landmark retrieval sub-model (i.e., the second retrieval sub-model, where k can be a positive integer), after specifying the destination, the Top-k landmark retrieval sub-model retrieves a list of candidate landmark locations that meet the user's needs from the destination. Similar to city search, the query in this module is obtained after processing with soft and hard constraints, for example:

[0152] Before the Top-k landmark retrieval sub-model processes explicit and implicit requirements:

[0153] Hard constraints:

[0154] 1. Trip duration: 3 days -- The user explicitly stated that they want to spend "three days" in Beijing.

[0155] 2. Number of people: 2 -- Using "me and my girlfriend" indicates that it is a trip for two people.

[0156] 3. Budget: 3000 yuan -- The user mentioned "budget of 3000 yuan", indicating that this is the upper limit of the travel expenses.

[0157] Destination: Beijing -- The user specified "Beijing" as the destination for their trip.

[0158] Must-see attractions: Great Wall, Forbidden City -- The mention of "the Great Wall and the Forbidden City are must-sees" indicates that these two locations are not optional on the visit list.

[0159] 6. Arrival and Departure: Daxing Airport - Users indicate that they will arrive and depart from Daxing Airport, which gives the specific starting and ending points of their trip.

[0160] Soft constraints:

[0161] 1. Flexible Schedule: Users indicated they "dislike overly tight schedules," suggesting a need for some freedom and rest time. Landmark Visits: While mentioning the desire to "visit as many Beijing landmarks as possible," they also noted that "other arrangements can be flexible," implying some flexibility in the order and duration of visits to landmarks other than the Great Wall and the Forbidden City. 2. Interests and Preferences: Users mentioned "we like natural landscapes and ancient architecture," suggesting the travel plan should include activities and attractions that align with these preferences.

[0162] After processing the explicit and implicit requirements, the Top-k landmark retrieval sub-model is as follows:

[0163] Beijing is a city that blends rich historical heritage with a modern urban landscape. For this trip, the client has a strict constraint of a 3-day itinerary, traveling with two people and a budget of 3000 yuan, planning to depart and return from Daxing Airport. Their core attractions include the Great Wall and the Forbidden City, two landmarks representing Beijing's profound historical heritage. Regarding soft constraints, the client prefers a less packed schedule, hoping for ample time to explore Beijing's landmarks, and has a particular fondness for natural landscapes and ancient architecture. Based on this information, please provide relevant information on representative landmarks in Beijing, especially natural landscapes and ancient architecture.

[0164] Through the above processing, after obtaining the processed query, the system can retrieve relevant attractions in the destination city by calling the retrieval API of the retrieval model, and add the retrieved attractions to the candidate address list so as to generate itinerary planning information later.

[0165] Step 104: Input the displayed requirements, the implicit requirements, the destination and the candidate address list into the trip planning sub-model to perform trip planning, and output trip planning information that matches the user's travel intention.

[0166] The trip planning sub-model, which can be the core of the large language model, can include a trip map generation sub-model, a macro-planning sub-model, and a time planning sub-model. These three sub-modules are cascaded. During the trip planning process, the trip map generation sub-model can process the spatial attributes corresponding to the candidate address list to construct a trip map and obtain a trip map corresponding to the destination. Then, the macro-planning sub-model processes the trip map, explicit requirements, and implicit requirements to divide the trip into sub-maps and obtain a trip map corresponding to the trip map. Finally, the time planning sub-model processes the trip map, explicit requirements, and implicit requirements to plan the trip map and obtain the trip route corresponding to the trip map.

[0167] In some feasible implementations, the candidate address list includes at least two candidate addresses. For the process of generating the itinerary map, the itinerary map generation sub-model can first obtain the text description and spatial information corresponding to the candidate addresses from the spatial attributes. Then, the spatial information is used to calculate the spatial distance between the two candidate addresses. Then, according to the spatial information, nodes corresponding to each candidate address are constructed in the map corresponding to the destination, and text descriptions are added to the nodes, as well as the corresponding spatial distances are added between the two nodes, to obtain the itinerary map corresponding to the destination. By constructing the itinerary map, users can intuitively and quickly perceive the global situation of the destination.

[0168] After obtaining the itinerary map, which includes nodes corresponding to each candidate address in the candidate address list and displays at least the number of travel days, the nodes in the itinerary map can be vector-encoded using the macro-planning sub-model to obtain node representation information. Then, the text description and spatial information corresponding to the nodes are used as fusion structure information, and features are extracted from the fusion structure information to obtain text representation information corresponding to the nodes. The itinerary map is then divided using node representation information, text representation information, displayed requirements, and implicit requirements to obtain several itinerary sub-maps matching the number of travel days. By performing itinerary planning in the itinerary map, itinerary sub-maps matching the user's number of travel days are obtained, allowing the user to know their daily itinerary and improving the user's awareness of itinerary planning so that the user can adjust their itinerary planning according to their own needs.

[0169] Furthermore, after determining the various subgraphs in the itinerary map, the itinerary for each can be further planned. The nodes included in the itinerary map can be vector-encoded using a time planning sub-model to obtain the node representation information corresponding to each node. The node representation information is then sorted according to explicit and implicit requirements to obtain the itinerary routes corresponding to each subgraph. Thus, in the above process, by introducing the itinerary map, the complex itinerary planning problem is transformed into an itinerary subgraph partitioning problem and a shortest path planning problem. This allows for more refined handling of various constraints in the travel process and effectively ensures that the generated itinerary plan not only meets user needs but is also logically feasible and practically operable.

[0170] In some examples, the trip planning sub-model is the core of the system, comprising three parts: trip graph generation, macro-planning, and schedule planning. These three parts are cascaded. The module first constructs a weighted complete graph based on the spatial attributes of the candidate address list, where addresses are nodes and edge weights are the road network reachability distances between two candidate addresses. Next, a pre-trained graph encoder and adapter are used to embed node representations containing graph structure information into the input of the large language model. The large language model utilizes the trip graph and performs two-stage planning with hard and soft constraints. The first stage performs macro-planning, dividing the trip graph into daily activity trip subgraphs. The second stage performs micro-planning, finding the shortest routes that satisfy both hard and soft constraints on each daily activity trip subgraph.

[0171] In the process of generating the itinerary map, due to the weak spatial imagination, understanding, and training capabilities of large language models, simply inputting textual descriptions of locations is insufficient for them to capture the relationships between locations. In itinerary planning, the spatial relationships between locations directly determine the rationality and comfort of the itinerary. Because, in a scenario requiring frequent travel, we want the locations visited each day to be as close as possible, and the routes between them to be convenient. This is the foundation for itinerary planning to meet both hard and soft constraints. The itinerary map is a weighted complete graph composed of candidate addresses. Each node contains its textual description and spatial information. The system uses a spatial analyzer to calculate the road network reachable distance (directed distance) between every two points, which serves as the weight of the edge.

[0172] The macro-planning process determines the spatial scope in which each day of the trip falls. Specifically, this problem is modeled as a subgraph partitioning problem of a travel itinerary graph. Using a large language model, nodes with fused structural information are divided into L groups (L derived from hard constraints), with each group being a travel itinerary subgraph.

[0173] The process of trip planning determines the specific schedule for each day of the trip. Specifically, this problem can be modeled as a shortest path problem on a subgraph of the trip. By using a large language model to plan routes on the subgraph based on soft and hard constraints, the goal is to find an optimal route that satisfies all constraints.

[0174] It should be noted that, in the above process, conventional large language models do not naturally possess the ability to handle graph structures. Therefore, in this embodiment of the invention, the understanding and training ability of the large language model to understand graph structures can be improved, enabling it to perform macro-level planning and schedule planning based on the generated itinerary graph. In some feasible implementations, a text-graph alignment paradigm can be used. This involves introducing a pre-trained large language model and a graph model, which respectively encode the graph structure and node representations of the model. Specifically, in the graph encoding branch, the node text of the itinerary graph is not used; instead, the nodes are vector-encoded, and the graph model is used to obtain the encoded node representation information. In the text branch, the node text of the itinerary graph is input into the text model to obtain the text representation information of each node. There is a natural pairwise relationship between the text representation information and the graph representation of each node in a set of data samples. Contrastive learning can be used for training and optimization. It is important to note that during training, the parameters of the graph encoder and text encoder are fixed; we introduce an adapter (projector) to align the two representation spaces. During training, only the text encoder and the adapter are used.

[0175] For example, refer to Figure 3This diagram illustrates a text-graph alignment model provided in an embodiment of the present invention. For nodes in a travel graph, the nodes can be vector-encoded, and a graph decoder can be used to obtain the encoded node representation information (i.e., the nodes are input into a graph encoder for vector encoding to obtain the corresponding node representation information). Simultaneously, in the text branches, the text corresponding to each node is input into a text encoder to obtain the text representation information corresponding to each node (i.e., the text description corresponding to the node is input into a text encoder for encoding to obtain the corresponding text representation information). Then, a pairwise relationship is established between the text representation information corresponding to each node and the graph identifier in a set of data samples, and then training is performed. During the training process, a text encoder and adapter are used. By introducing a corresponding graph decoder into the large language model, it can effectively recognize the content of the travel graph, and perform travel planning based on the recognition results, effectively ensuring the accuracy and effectiveness of the travel planning.

[0176] Furthermore, regarding the run-length subgraph partitioning capability of large language models, fine-tuning of the large language model can be performed based on manually annotated data. The instructions require the model to divide the input node sequence into k groups, and the specific instruction format can be as follows:

[0177] {

[0178] 'instruction': "Based on the input query, hardlimit, and softlimit, the input graph is divided into trip subgraphs. Specifically, the input graph can be divided into groups corresponding to the number of trip days:"

[0179] 'hard limit':'

[0180] i. Trip duration: 3 days -- The user explicitly stated that they want to spend "three days" in Beijing.

[0181] ii. Number of people: 2 -- Use "me and my girlfriend" to indicate that it is a trip for two.

[0182] iii. Budget: 3000 yuan -- The user mentions "budget of 3000 yuan", indicating that this is the upper limit of the travel expenses.

[0183] iv. Destination: Beijing -- The user specified "Beijing" as the destination for the trip.

[0184] v. Must-see attractions: Great Wall, Forbidden City -- The mention of "the Great Wall and the Forbidden City are must-sees" indicates that these two locations are not optional on the visit list.

[0185] vi. Arrival and Departure: Daxing Airport -- Users indicate that they will arrive and depart from Daxing Airport, which gives the specific locations where the trip begins and ends.

[0186] 'soft limit':"

[0187] i. Flexible schedule: Users indicated that they "do not like overly tight schedules," which suggests a need for a certain degree of freedom and rest time.

[0188] Landmark Tours: While it is mentioned that we should "visit as many of Beijing's landmarks as possible", it is also mentioned that "other landmarks can be visited flexibly as they are nearby". This means that apart from the Great Wall and the Forbidden City, the order and duration of visits to other landmarks can be flexible.

[0189] i. Interests and Preferences: The user mentioned "We like natural landscapes and ancient architecture," which suggests that the travel plan should include activities and attractions that match these preferences.

[0190] 'query': Given a travel graph, nodes represent addresses, and edges represent spatial distances between addresses. Node list: [0, 1, 2, 3, 4, 5, 6, 7] Edge list: [5689.32, 400.95] Node content: <nodetoken0> ， <nodetoken7>"answer':'Group 1: [1, 0, 3, 7], Group 2: [2], Group 3: [4, 5, 6]

[0191] }

[0192] Through the above training process, the macro-planning sub-model in the large language model can effectively divide the itinerary map into several itinerary sub-maps, each of which corresponds to a day's itinerary planning.

[0193] Furthermore, for the training of the shortest path capability submodule within the large language model, the model can be fine-tuned using manually labeled data. This involves instructing the model to reorder the input node sequence and, under both hard and soft constraints, output the shortest planned path for users to refer to when traveling. The data format for these fine-tuning instructions can be as follows:

[0194] {

[0195] 'instruction': 'Based on the input query, hard limit, and soft limit, perform shortest path planning on the input graph. Specifically, this can involve reordering the input node sequence.'

[0196] 'hard limit':'

[0197] i. Trip duration: 3 days - The user explicitly stated that they wanted to spend "three days" in Beijing.

[0198] ii. Number of people: 2 -- Use "Me and my girlfriend" to indicate that it is a trip for two.

[0199] iii. Budget: 3000 yuan -- The user mentioned "budget of 3000 yuan", indicating that this is the upper limit of the travel expenses.

[0200] iv. Destination: Beijing -- The user specified "Beijing" as the destination for the trip.

[0201] v. Must-see attractions: Great Wall, Forbidden City -- The mention of "the Great Wall and the Forbidden City are must-sees" indicates that these two locations are not optional on the visit list.

[0202] vi. Arrival and Departure: Daxing Airport -- Users indicate that they will arrive and depart from "Daxing Airport," which gives the specific locations where the trip begins and ends.

[0203] 'soft limit':'

[0204] i. Flexible schedule: Users indicated that they "do not like overly tight schedules," which suggests a need for a certain degree of freedom and rest time.

[0205] ii. Landmark Tours: Although it is mentioned that we should "visit as many landmarks in Beijing as possible", it is also mentioned that "others can be arranged flexibly". This means that apart from the Great Wall and the Forbidden City, the order and duration of visits to other landmarks can be flexible.

[0206] ii. Interests and Preferences: The user mentioned "We like natural landscapes and ancient architecture," which suggests that the travel plan should include activities and attractions that match these preferences.

[0207] 'query': Given a travel graph, nodes represent addresses, and edges represent spatial distances between addresses. Node list: [1, 0, 3, 7] Edge value list: [986.81, ..., 498.65] Node content:<node token 1> ,<node token7> '

[0208] 'answer':'The rearranged sequence is: [3, 7, 1, 0]'

[0209] }

[0210] Through the above training process, the graph structure processing capability of the large language model is trained by applying the text-graph alignment paradigm, and specialized training is carried out for the ability to partition the trip subgraph and the shortest route. This enables the large language model to be applicable to graph structure data, transforming node text information and spatial information into the basis for travel plan reasoning. This realizes reasoning based on structured spatial data in the large language model, allowing automatic planning of travel routes that meet both hard and soft constraints.

[0211] In one example, refer to Figure 4 This illustration shows a schematic diagram of planning information provided in an embodiment of the present invention. Once the user's display requirements, implicit requirements, destination, and candidate location list are determined, trip planning can be performed based on this data, including trip map generation, macro-planning, and schedule planning, etc. Figure 4 As shown, the itinerary map can display corresponding nodes (i.e., attractions, etc.) and the distances between different attractions. It can also display daily itinerary plans, such as:

[0212] Departure: xx Airport

[0213] Day 1

[0214]

Attraction ①

[0215] [Distance] 10min

[0216]

Attraction ②

[0217] [Distance] 1 hour

[0218]

Attraction ③

[0219] [Distance] 15min

[0220]

Attraction ④

[0221] Day 2

[0222]

Attraction ①

[0223] Day 3

[0224]

Attraction ①

[0225] [Distance] 10min

[0226]

Attraction ②

[0227] [Distance] 30min

[0228]

Attraction ③

[0229] Departure: xx Airport

[0230] In the itinerary map, daily travel plans can be distinguished by different colors, so that users can intuitively understand their daily travel plans. By analyzing users' explicit and implicit needs, customized travel solutions can be provided, improving user satisfaction and travel experience. The automated processing of user needs descriptions and itinerary planning reduces the time and cost of manual planning and improves service efficiency.

[0231] It should be noted that the embodiments of the present invention include, but are not limited to, the examples described above. It is understood that those skilled in the art can make further settings according to actual needs under the guidance of the ideas in the embodiments of the present invention, and the present invention does not limit such settings.

[0232] In this embodiment of the invention, by acquiring user demand descriptions and a large language model, which includes at least an intent recognition sub-model, a candidate location retrieval sub-model, and a trip planning sub-model, the user demand description is then input into the intent recognition sub-model for intent recognition to obtain the user's travel intent corresponding to the user demand description. The user's travel intent includes at least explicit and implicit demands. Then, the explicit and implicit demands are input into the candidate location retrieval sub-model for location retrieval to obtain the destination corresponding to the user's travel intent and a list of candidate addresses corresponding to the destination. Finally, the explicit and implicit demands, the destination, and the list of candidate addresses are input into the trip planning sub-model for trip planning, outputting trip planning information that matches the user's travel intent. Thus, by analyzing the user's explicit and implicit demands, customized travel solutions can be provided to the user, improving user satisfaction and travel experience. The automated processing of user demand descriptions and trip planning reduces the time and cost of manual planning and improves service efficiency.

[0233] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0234] Reference Figure 5 The diagram shows a structural block diagram of a trip planning device provided in an embodiment of the present invention, which may specifically include the following modules:

[0235] The data acquisition module 501 is used to acquire user demand descriptions and a large language model, wherein the large language model includes at least an intent recognition sub-model, a candidate location retrieval sub-model, and a trip planning sub-model.

[0236] The intent recognition module 502 is used to input the user demand description into the intent recognition sub-model for intent recognition, and obtain the user travel intent corresponding to the user demand description. The user travel intent includes at least explicit demand and implicit demand.

[0237] The retrieval module 503 is used to input the display requirements and the implicit requirements into the candidate location retrieval sub-model to perform location retrieval and obtain the destination corresponding to the user's travel intention and the candidate address list corresponding to the destination;

[0238] The planning module 504 is used to input the displayed requirements, the implicit requirements, the destination and the candidate address list into the trip planning sub-model to perform trip planning, and output trip planning information that matches the user's travel intention.

[0239] In some optional embodiments, the retrieval module 503 is specifically used for:

[0240] The candidate location retrieval sub-model processes the display requirements and the implicit requirements to obtain the destination retrieval request;

[0241] The candidate location retrieval sub-model is used to process the destination retrieval request in order to retrieve the destination and obtain the destination corresponding to the destination retrieval request, as well as the basic information of the target corresponding to the destination.

[0242] The candidate location retrieval sub-model processes the display requirements, the implicit requirements, and the basic description of the target to obtain candidate location retrieval requests.

[0243] The candidate location retrieval sub-model processes the candidate location retrieval request to retrieve candidate addresses and obtain a list of candidate addresses corresponding to the destination.

[0244] In some optional embodiments, the candidate location retrieval sub-model includes at least a first retrieval sub-model and a first interface corresponding to the first retrieval sub-model, the destination retrieval request includes either a first destination retrieval request or a second destination retrieval request, and the retrieval module 503 is specifically used for:

[0245] If the display requirement includes a first destination, then the first search interface is called through the first search sub-model to process the search request for the first destination, so as to search for the first destination and obtain the first basic introduction corresponding to the first destination;

[0246] If the display requirement does not include the first destination, the first search interface is called through the first search sub-model to process the second destination search request, so as to search for the destination, obtain the second destination corresponding to the second destination search request, and the second basic introduction corresponding to the second destination;

[0247] The second destination is either the first destination or another destination different from the first destination.

[0248] In some optional embodiments, the candidate location retrieval sub-model includes at least a second retrieval sub-model and a second interface corresponding to the second retrieval sub-model, the candidate location retrieval request includes either a first candidate location retrieval request or a second candidate location retrieval request, and the retrieval module 503 is specifically used for:

[0249] If the display requirement includes a first destination, then the second search interface is called through the second search sub-model to process the first candidate location search request, so as to perform candidate address search for the first destination and obtain the first candidate address list corresponding to the first destination;

[0250] If the display requirement does not include the first destination, the second search interface is called through the second search sub-model to process the second candidate location search request, so as to perform candidate address search for the second destination and obtain the second candidate address list corresponding to the second destination.

[0251] In some optional embodiments, the itinerary planning sub-model includes at least an itinerary map generation sub-model, a macro-planning sub-model, and a time planning sub-model, and the planning module 504 is specifically used for:

[0252] The spatial attributes corresponding to the candidate address list are input into the itinerary map generation sub-model to construct the itinerary map and obtain the itinerary map corresponding to the destination.

[0253] The macro-planning sub-model processes the itinerary map, the explicit requirements, and the implicit requirements to divide the itinerary map into sub-maps corresponding to the itinerary map.

[0254] The time planning sub-model processes the itinerary map, the displayed requirements, and the implied requirements to perform itinerary planning on the itinerary sub-map and obtain the itinerary route corresponding to the itinerary sub-map.

[0255] In some optional embodiments, the candidate address list includes at least two candidate addresses, and the planning module 504 is specifically used for:

[0256] The text description and spatial information corresponding to the candidate address are obtained from the spatial attributes by generating a sub-model from the travel map;

[0257] The spatial distance between two candidate addresses is calculated using the spatial information generated by the trip diagram sub-model.

[0258] The itinerary map generation sub-model constructs nodes corresponding to each candidate address in the map corresponding to the destination according to the spatial information, adds text descriptions to the nodes, and adds corresponding spatial distances between two nodes to obtain the itinerary map corresponding to the destination.

[0259] In some optional embodiments, the itinerary graph includes nodes corresponding to each candidate address in the candidate address list, the display requirement includes at least the number of travel days, and the planning module 504 is specifically used for:

[0260] The nodes included in the itinerary diagram are vector-encoded using the macro-planning sub-model to obtain node representation information corresponding to the nodes;

[0261] The macro-planning sub-model is used to extract features from the text description and spatial information corresponding to the node to obtain the text representation information corresponding to the node.

[0262] The macro-planning sub-model uses the node representation information, text representation information, display requirements, and implicit requirements to divide the itinerary in the itinerary map, thereby obtaining an itinerary sub-map that matches the number of days in the itinerary. Each itinerary sub-map corresponds to a day's itinerary planning.

[0263] In some optional embodiments, the planning module 504 is specifically used for:

[0264] The nodes included in the itinerary diagram are vector-encoded using the time planning sub-model to obtain node representation information corresponding to the nodes;

[0265] The time planning sub-model sorts the node representation information according to the display requirements and the implicit requirements to obtain the travel routes corresponding to each travel sub-graph.

[0266] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0267] In addition, this invention also provides an electronic device, including: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the various processes of the above-described travel planning method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0268] Furthermore, this embodiment of the invention also provides a computer program product, including a computer program / instruction, wherein when the computer program / instruction is executed, it implements the above-described travel planning method embodiment and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0269] This invention also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described route planning method embodiments and achieves the same technical effects. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0270] Figure 6 A schematic diagram of the hardware structure of an electronic device for implementing various embodiments of the present invention.

[0271] The electronic device 600 includes, but is not limited to, components such as: a radio frequency unit 601, a network module 602, an audio output unit 603, an input unit 604, a sensor 605, a display unit 606, a user input unit 607, an interface unit 608, a memory 609, a processor 610, and a power supply 611. Those skilled in the art will understand that the electronic device structure involved in the embodiments of the present invention does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. In the embodiments of the present invention, the electronic device includes, but is not limited to, mobile phones, tablet computers, laptop computers, PDAs, in-vehicle terminals, wearable devices, and pedometers.

[0272] It should be understood that, in this embodiment of the invention, the radio frequency unit 601 can be used for receiving and transmitting signals during information transmission or calls. Specifically, it receives downlink data from the base station and processes it with the processor 610; additionally, it transmits uplink data to the base station. Typically, the radio frequency unit 601 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low-noise amplifier, a duplexer, etc. Furthermore, the radio frequency unit 601 can also communicate with networks and other devices through a wireless communication system.

[0273] The electronic device provides users with wireless broadband internet access through the network module 602, such as helping users send and receive emails, browse web pages, and access streaming media.

[0274] The audio output unit 603 can convert audio data received by the radio frequency unit 601 or the network module 602 or stored in the memory 609 into audio signals and output them as sound. Furthermore, the audio output unit 603 can also provide audio output related to specific functions performed by the electronic device 600 (e.g., call signal reception sound, message reception sound, etc.). The audio output unit 603 includes a speaker, a buzzer, and a receiver, etc.

[0275] Input unit 604 is used to receive audio or video signals. Input unit 604 may include a graphics processing unit (GPU) 6041 and a microphone 6042. GPU 6041 processes image data of still images or videos acquired by an image capture device (such as a camera) in video capture mode or image capture mode. The processed image frames can be displayed on display unit 606. The image frames processed by GPU 6041 can be stored in memory 609 (or other storage medium) or transmitted via radio frequency unit 601 or network module 602. Microphone 6042 can receive sound and process such sound into audio data. The processed audio data can be converted into a format that can be transmitted to a mobile communication base station via radio frequency unit 601 in telephone call mode.

[0276] The electronic device 600 also includes at least one sensor 605, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor includes an ambient light sensor and a proximity sensor. The ambient light sensor can adjust the brightness of the display panel 6061 according to the ambient light level, and the proximity sensor can turn off the display panel 6061 and / or backlight when the electronic device 600 is moved to the ear. As a type of motion sensor, an accelerometer sensor can detect the magnitude of acceleration in various directions (generally three axes). When stationary, it can detect the magnitude and direction of gravity and can be used to identify the posture of the electronic device (such as landscape / portrait switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc. The sensor 605 may also include a fingerprint sensor, pressure sensor, iris sensor, molecular sensor, gyroscope, barometer, hygrometer, thermometer, infrared sensor, etc., which will not be described in detail here.

[0277] The display unit 606 is used to display information input by the user or information provided to the user. The display unit 606 may include a display panel 6061, which may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), or the like.

[0278] User input unit 607 can be used to receive input numerical or character information, and to generate key signal inputs related to user settings and function control of electronic devices. Specifically, user input unit 607 includes a touch panel 6071 and other input devices 6072. Touch panel 6071, also known as a touch screen, can collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near touch panel 6071). Touch panel 6071 may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch position and the signal generated by the touch operation, and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 610, which receives and executes commands from the processor 610. In addition, touch panel 6071 can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. Besides touch panel 6071, user input unit 607 may also include other input devices 6072. Specifically, other input devices 6072 may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, joysticks, etc., which will not be described in detail here.

[0279] Furthermore, the touch panel 6071 can cover the display panel 6061. When the touch panel 6071 detects a touch operation on or near it, it transmits the information to the processor 610 to determine the type of touch event. Subsequently, the processor 610 provides corresponding visual output on the display panel 6061 according to the type of touch event. It is understood that in one embodiment, the touch panel 6071 and the display panel 6061 are implemented as two independent components to realize the input and output functions of the electronic device. However, in some embodiments, the touch panel 6071 and the display panel 6061 can be integrated to realize the input and output functions of the electronic device. The specific implementation is not limited here.

[0280] Interface unit 608 serves as an interface for connecting external devices to electronic device 600. For example, external devices may include a wired or wireless headphone port, an external power supply (or battery charger) port, a wired or wireless data port, a memory card port, a port for connecting a device with an identification module, an audio input / output (I / O) port, a video I / O port, a headphone port, and so on. Interface unit 608 can be used to receive input from external devices (e.g., data, power, etc.) and transmit the received input to one or more components within electronic device 600, or it can be used to transmit data between electronic device 600 and external devices.

[0281] The memory 609 can be used to store software programs and various data. The memory 609 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback, image playback, etc.), etc.; the data storage area may store data created based on the use of the mobile phone (such as audio data, phonebook, etc.). Furthermore, the memory 609 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0282] The processor 610 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 609, and by calling data stored in the memory 609, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. The processor 610 may include one or more processing units; preferably, the processor 610 may integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 610.

[0283] The electronic device 600 may also include a power supply 611 (such as a battery) for supplying power to various components. Preferably, the power supply 611 is logically connected to the processor 610 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system.

[0284] In addition, the electronic device 600 includes some functional modules not shown, which will not be described in detail here.

[0285] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0286] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0287] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of the present invention.

[0288] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this invention 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 implementations should not be considered beyond the scope of this invention.

[0289] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0290] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of 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.

[0291] 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.

[0292] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0293] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

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

Claims

1. A trip planning method, characterized in that, include: Obtain user demand descriptions and a large language model, wherein the large language model includes at least an intent recognition sub-model, a candidate location retrieval sub-model, and a trip planning sub-model; The user demand description is input into the intent recognition sub-model for intent recognition to obtain the user travel intent corresponding to the user demand description. The user travel intent includes at least explicit demand and implicit demand. The display requirements and the implicit requirements are input into the candidate location retrieval sub-model to perform location retrieval, thereby obtaining the destination corresponding to the user's travel intention and a list of candidate addresses corresponding to the destination. The displayed requirements, the implicit requirements, the destination, and the candidate address list are input into the trip planning sub-model to perform trip planning, and the trip planning information that matches the user's travel intention is output.

2. The method according to claim 1, characterized in that, The step of inputting the displayed demand and the implicit demand into the candidate location retrieval submodel to perform location retrieval, and obtaining the destination corresponding to the user's travel intention and the candidate address list corresponding to the destination, includes: The candidate location retrieval sub-model processes the display requirements and the implicit requirements to obtain the destination retrieval request; The candidate location retrieval sub-model is used to process the destination retrieval request in order to retrieve the destination and obtain the destination corresponding to the destination retrieval request, as well as the basic information of the target corresponding to the destination. The candidate location retrieval sub-model processes the display requirements, the implicit requirements, and the basic description of the target to obtain candidate location retrieval requests. The candidate location retrieval sub-model processes the candidate location retrieval request to retrieve candidate addresses and obtain a list of candidate addresses corresponding to the destination.

3. The method according to claim 2, characterized in that, The candidate location retrieval sub-model includes at least a first retrieval sub-model and a first retrieval interface corresponding to the first retrieval sub-model. The destination retrieval request includes either a first destination retrieval request or a second destination retrieval request. The process of processing the destination retrieval request through the candidate location retrieval sub-model to retrieve the destination and obtain the destination corresponding to the destination retrieval request and a basic description of the target corresponding to the destination includes: If the display requirement includes a first destination, then the first search interface is called through the first search sub-model to process the search request for the first destination, so as to search for the first destination and obtain the first basic introduction corresponding to the first destination; If the display requirement does not include the first destination, the first search interface is called through the first search sub-model to process the second destination search request, so as to search for the destination, obtain the second destination corresponding to the second destination search request, and the second basic introduction corresponding to the second destination; The second destination is either the first destination or a destination different from the first destination.

4. The method according to claim 3, characterized in that, The candidate location retrieval sub-model includes at least a second retrieval sub-model and a second retrieval interface corresponding to the second retrieval sub-model. The candidate location retrieval request includes either a first candidate location retrieval request or a second candidate location retrieval request. Processing the candidate location retrieval request through the candidate location retrieval sub-model to retrieve candidate addresses and obtain a list of candidate addresses corresponding to the destination includes: If the display requirement includes a first destination, then the second search interface is called through the second search sub-model to process the first candidate location search request, so as to perform candidate address search for the first destination and obtain the first candidate address list corresponding to the first destination; If the display requirement does not include the first destination, the second search interface is called through the second search sub-model to process the second candidate location search request, so as to perform candidate address search for the second destination and obtain the second candidate address list corresponding to the second destination.

5. The method according to any one of claims 1 to 4, characterized in that, The trip planning sub-model includes at least a trip map generation sub-model, a macro-planning sub-model, and a time planning sub-model. The step of inputting the explicit requirements, the implicit requirements, the destination, and the candidate address list into the trip planning sub-model for trip planning, and outputting trip planning information matching the user's travel intention, includes: The spatial attributes corresponding to the candidate address list are processed by the trip map generation sub-model to construct the trip map and obtain the trip map corresponding to the destination. The macro-planning sub-model processes the itinerary map, the explicit requirements, and the implicit requirements to divide the itinerary map into sub-maps corresponding to the itinerary map. The time planning sub-model processes the itinerary map, the displayed requirements, and the implied requirements to perform itinerary planning on the itinerary sub-map and obtain the itinerary route corresponding to the itinerary sub-map.

6. The method according to claim 5, characterized in that, The candidate address list includes at least two candidate addresses. The step of inputting the spatial attributes corresponding to the candidate address list into the itinerary map generation sub-model to construct the itinerary map and obtain the itinerary map corresponding to the destination includes: The text description and spatial information corresponding to the candidate address are obtained from the spatial attributes by generating a sub-model from the travel map; The spatial distance between two candidate addresses is calculated using the spatial information generated by the trip diagram sub-model. The itinerary map generation sub-model constructs nodes corresponding to each candidate address in the map corresponding to the destination according to the spatial information, adds text descriptions to the nodes, and adds corresponding spatial distances between two nodes to obtain the itinerary map corresponding to the destination.

7. The method according to claim 6, characterized in that, The itinerary diagram includes nodes corresponding to candidate addresses in the candidate address list. The display requirement includes at least the number of travel days. The process of processing the itinerary diagram, the display requirement, and the implicit requirement through the macro-planning sub-model to divide the itinerary in the itinerary diagram and obtain a itinerary sub-diagram corresponding to the itinerary diagram includes: The nodes included in the itinerary diagram are vector-encoded using the macro-planning sub-model to obtain node representation information corresponding to the nodes; The macro-planning sub-model is used to extract features from the text description and spatial information corresponding to the node to obtain the text representation information corresponding to the node. The macro-planning sub-model uses the node representation information, text representation information, display requirements, and implicit requirements to divide the itinerary in the itinerary map, thereby obtaining an itinerary sub-map that matches the number of days in the itinerary. Each itinerary sub-map corresponds to a day's itinerary planning.

8. The method according to claim 5, characterized in that, The process of processing the itinerary map, the explicit requirements, and the implicit requirements through the time planning sub-model to perform itinerary planning and obtain the itinerary route corresponding to the itinerary sub-map includes: The nodes included in the itinerary diagram are vector-encoded using the time planning sub-model to obtain node representation information corresponding to the nodes; The node representation information is sorted according to the display requirements and the implicit requirements to obtain the travel routes corresponding to each of the travel subgraphs.

9. A travel planning device, characterized in that, include: The data acquisition module is used to acquire user demand descriptions and a large language model, wherein the large language model includes at least an intent recognition sub-model, a candidate location retrieval sub-model, and a trip planning sub-model. The intent recognition module is used to input the user demand description into the intent recognition sub-model for intent recognition, and obtain the user travel intent corresponding to the user demand description. The user travel intent includes at least explicit demand and implicit demand. The retrieval module is used to input the display requirements and the implicit requirements into the candidate location retrieval sub-model to perform location retrieval and obtain the destination corresponding to the user's travel intention and the candidate address list corresponding to the destination; The planning module is used to input the displayed requirements, the implicit requirements, the destination and the candidate address list into the trip planning sub-model to perform trip planning, and output trip planning information that matches the user's travel intention.

10. An electronic device, characterized in that, Includes a processor, communication interface, memory, and communication bus, among which: The processor, the communication interface, and the memory communicate with each other through the communication bus; The memory is used to store computer programs; When the processor executes a program stored in the memory, it implements the method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, It stores instructions that, when executed by one or more processors, cause the processors to perform the method as described in any one of claims 1-8.

12. A computer program product, characterized in that, It includes a computer program / instruction, wherein when the computer program / instruction is executed, it implements the method as described in any one of claims 1-8.

Images