Travel Plan Recommendation Method, System, Travel Server and Program

Abstract

An embodiment of the present application provides a travel plan recommendation method, system, travel server, and program. The method includes: determining a user's departure location and destination; searching graph data based on the user's departure location and destination to determine a one-way path to be recommended; defining transfer point search constraints at least based on a set of transfer points reserved between the user's departure location and destination, and searching graph data based on the transfer point search constraints to determine a multi-way path to be recommended, where the multi-way path passes through transfer points; among them, the transfer points reserved between any two transportation stations are updated regularly based on the ticket volume inventory of the transportation schedule edges associated with the transfer points; forming multiple paths to be recommended based on the one-way path and multi-way path to be recommended; sorting the multiple paths to be recommended according to user preferences, and using the sorted multiple paths as the recommended result of the travel plan. The embodiments of the present application can improve the performance of the travel service platform in recommending travel plans.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer Internet technologies, and particularly to a travel plan recommendation method, system, travel server, and program. Background Art

[0002] A travel service platform is an online platform that provides travel services for users, such as an OTP (Online Travel Platform) or an OTA (Online Travel Agency) platform. Recommending travel plans for users is one of the core functions of a travel service platform. Specifically, when a user provides information such as a departure location and a destination to the travel service platform, the travel service platform can recommend a travel plan from the departure location to the destination. In this context, how to improve the performance of the travel service platform in recommending travel plans has become a technical problem that needs to be urgently solved by those skilled in the art. Summary of the Invention

[0003] In view of this, the embodiments of the present application provide a travel plan recommendation method, system, travel server, and program to improve the performance of the travel service platform in recommending travel plans.

[0004] To achieve the above object, the embodiments of the present application provide the following technical solutions.

[0005] In a first aspect, the embodiments of the present application provide a travel plan recommendation method applied to a travel service platform. The method includes:

[0006] Determine a user's departure location and a user's destination;

[0007] According to the user's departure location and the user's destination, search graph data to determine a to-be-recommended one-way path from the user's departure location to the user's destination; wherein, the graph data includes multiple nodes and connection edges between the nodes, the nodes represent transportation stations, the connection edges are divided into transportation schedule edges and transfer edges, the transportation schedule edges represent direct transportation schedules between transportation stations, the transfer edges represent non-transportation-schedule transfer situations between transportation stations, and the transportation schedule edges have dynamically updated price and inventory data;

[0008] And, at least define a transfer point search constraint condition with a set of reserved transfer points between the user's departure location and the user's destination. Based on the transfer point search constraint condition, search the graph data to determine a to-be-recommended multi-way path from the user's departure location to the user's destination, and the multi-way path passes through transfer points; wherein, the set of reserved transfer points between any two transportation stations includes the reserved transfer points between any two transportation stations, and the reserved transfer points between any two transportation stations are updated regularly based on the ticket inventory situation of the transportation schedule edges associated with the transfer points;

[0009] Based on the to-be-recommended one-way path and the to-be-recommended multi-way path, form multiple to-be-recommended paths;

[0010] According to user preferences, sort the multiple to-be-recommended paths, and use the sorted multiple paths as the recommended results of the travel plan.

[0011] In a second aspect, an embodiment of the present application provides a travel plan recommendation system, which is applied to a travel service platform. The system includes:

[0012] An online path search module, configured to determine a user's departure location and a user's destination; according to the user's departure location and the user's destination, search graph data to determine a to-be-recommended one-way path from the user's departure location to the user's destination; wherein, the graph data includes multiple nodes and connection edges between the nodes, the nodes represent transportation stations, the connection edges are divided into transportation schedule edges and transfer edges, the transportation schedule edges represent direct transportation schedules between transportation stations, the transfer edges represent non-transportation-schedule transfer situations between transportation stations, and the transportation schedule edges have dynamically updated price library data; and at least define transfer point search constraint conditions based on the set of reserved transfer points between the user's departure location and the user's destination, and based on the transfer point search constraint conditions, search the graph data to determine a to-be-recommended multi-way path from the user's departure location to the user's destination, and the multi-way path passes through transfer points; wherein, the set of reserved transfer points between any two transportation stations includes the reserved transfer points between any two transportation stations, and the reserved transfer points between any two transportation stations are updated regularly based on the ticket inventory situation of the transportation schedule edges associated with the transfer points; based on the to-be-recommended one-way path and the to-be-recommended multi-way path, form multiple to-be-recommended paths;

[0013] A sorting and recommendation module, configured to sort the multiple to-be-recommended paths according to user preferences, and use the sorted multiple paths as the recommended results of the travel plan.

[0014] In a third aspect, an embodiment of the present application provides a travel server, including a memory and a processor. The memory stores computer execution instructions, and the processor calls the computer execution instructions to execute the travel plan recommendation method as described in the first aspect above.

[0015] In a fourth aspect, an embodiment of the present application provides a computer program product, including computer execution instructions, which when executed, implement the travel plan recommendation method as described in the first aspect above.

[0016] The travel plan recommendation method provided by the embodiments of this application can pre-construct graph data, represent transportation stations as nodes in the graph data, and divide the connecting edges between nodes into transportation schedule edges and transfer edges. The transportation schedule edges represent the direct transportation schedules between transportation stations, and the transfer edges represent the transfer situations between transportation stations that are not transportation schedules. Moreover, the transportation schedule edges have dynamically updated price database data. Thus, through the graph data and the price database data of the dynamically updated transportation schedule edges, the embodiments of this application can track the price and ticket inventory of each transportation schedule, avoiding the recommendation of outdated or incorrect information to users. In terms of searching and recommending multi-hop paths, the embodiments of this application consider the set of transfer points reserved between transportation stations that is updated regularly, and the reserved transfer points between transportation stations are updated regularly based on the ticket inventory situation of the associated transportation schedule edges. Therefore, when searching for the multi-hop paths to be recommended from the user's departure location to the user's destination in the graph data, the embodiments of this application define transfer point search constraints based on the set of transfer points reserved between the user's departure location and the user's destination to restrict the transfer points passed through during the multi-hop path search process, which can significantly reduce unnecessary search operations and calculations. That is to say, the embodiments of this application improve the search performance of the travel service platform for multi-hop paths, especially for paths with two or more hops, by regularly updating the transfer points reserved between transportation stations. Further, after obtaining the one-way paths to be recommended and the multi-hop paths to be recommended, the embodiments of this application perform path ranking in combination with user preferences, ensuring that the recommendation results meet the user's needs and improving the accuracy of the recommendation.

[0017] Therefore, the embodiments of this application improve the recommendation accuracy and efficiency of the travel service platform in terms of mixed one-way paths and multi-hop paths through the graph data with dynamically updated price database data, the regular update of the transfer points reserved between transportation stations, and personalized recommendation ranking, optimize the quality of the recommendation results, improve the performance of the travel service platform in recommending travel plans, and can provide more flexible and accurate travel plans under the condition of diverse user needs. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only the embodiments of this application. For those of ordinary skill in the art, other drawings can be obtained according to the provided drawings without creative efforts.

[0019] Figure 1 It is a stage example diagram of the recommendation process for recommending two-hop paths.

[0020] Figure 2 It is a stage example diagram of the travel plan recommendation method provided by the embodiments of this application.

[0021] Figure 3A It is a flowchart for constructing graph data provided by an embodiment of the present application.

[0022] Figure 3B It is an example diagram of the content of node attributes.

[0023] Figure 3C It is an example diagram of the content of the edge attributes of the transportation shift edge.

[0024] Figure 3D It is an example diagram of the content of the edge attributes of the transfer edge.

[0025] Figure 3E It is an example diagram for updating price library data.

[0026] Figure 4 It is a flowchart for offline path planning provided by an embodiment of the present application.

[0027] Figure 5A It is a flowchart for determining the set of reserved transfer points provided by an embodiment of the present application.

[0028] Figure 5B It is an example diagram for training a prediction model.

[0029] Figure 5C It is an example diagram of the application of a graph neural network.

[0030] Figure 6 It is a flowchart for online path service provided by an embodiment of the present application.

[0031] Figure 7 It is a flowchart for determining the two-way paths to be recommended provided by an embodiment of the present application.

[0032] Figure 8A It is a flowchart for sorting multiple paths to be recommended provided by an embodiment of the present application.

[0033] Figure 8B It is an example diagram of the processing of a recommendation scoring model.

[0034] Figure 9 It is a block diagram of a travel plan recommendation system provided by an embodiment of the present application. Detailed implementation manners

[0035] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0036] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. And the collection, use, and processing of relevant data need to comply with the relevant laws, regulations, and standards of relevant countries and regions, and corresponding operation entrances are provided for users to choose to authorize or refuse.

[0037] In the embodiments of this application, a travel plan refers to a passage from a departure place to a destination. The passage from a departure place to a destination is divided into: a one-way passage directly from the departure place to the destination (simply referred to as a one-way path), and a multi-way passage that needs to transfer midway after departing from the departure place and then reach the destination (simply referred to as a multi-way path). Specifically, based on whether a transfer is needed midway from the departure place to the destination, the travel plan is divided into a direct travel plan corresponding to the one-way path and a multi-way travel plan corresponding to the multi-way path.

[0038] In a more specific description, the direct travel plan does not require a transfer midway from the departure place to the destination. For example, a user directly travels from the departure place to the destination through a transportation shift of a certain transportation mode. For example, a user takes a flight of an airplane and directly arrives at the destination from the departure place, or takes a train of a train and directly arrives at the destination from the departure place, etc.

[0039] It should be noted that the transportation modes referred to in the embodiments of this application correspond to set transportation tools such as airplanes, trains, and cars (here, cars refer to passenger cars) for which users need to purchase transportation tickets; transportation shifts such as flights of airplanes, trains of trains, and shifts of cars depend on the specific transportation mode, and the embodiments of this application do not have any limitations.

[0040] For the multi-way travel plan, a transfer is needed midway from the departure place to the destination. Then the user needs to transfer different transportation modes at the transfer point (the place for midway transfer) to complete the travel, or transfer different transportation shifts of the same transportation mode to complete the travel. For example, a user first takes a train from the departure place to the transfer city, and then transfers to an airplane in the transfer city to reach the destination.

[0041] The multi-way path corresponding to the multi-way travel plan can be composed of multiple transportation modes and / or the same transportation mode, that is, the transportation modes used for the multi-way path can be different or the same. Specifically, for the multi-way path, combinations of multiple transportation modes such as trains and airplanes, cars and airplanes, etc., are combinations of different types of transportation tools, and combinations of the same transportation mode such as multi-way trains or multi-way airplanes are combinations of the same transportation mode multiple times.

[0042] Exemplarily, taking multi-hop paths with two hops and three hops as examples, the possible situations of multi-hop paths will be illustrated by examples.

[0043] The transportation modes of a two-hop path can be the same or different. Possible combinations of transportation modes are, for example: train <-> plane, first taking a train from the departure place to the transfer city, and then transferring to a plane to reach the destination; train <-> car, first taking a train from the departure place to the transfer city, and then transferring to a car to reach the destination; plane <-> car, first taking a plane from the departure place to the transfer city, and then transferring to a car to reach the destination; plane <-> plane, taking a plane from the departure place to the transfer city, and then taking a plane in the transfer city to reach the destination; train <-> train, taking a train from the departure place to the transfer city, and then taking a train in the transfer city to reach the destination.

[0044] Similarly, the transportation modes of a three-hop path can be the same or different. Possible combinations of transportation modes are, for example: train <-> train <-> train, train <-> plane <-> train, train <-> plane <-> plane, etc. The situations of four-hop paths and multi-hop paths with more hops can be referred to similarly, and will not be elaborated here.

[0045] Multi-hop paths can provide users with multi-hop travel plans from the departure place to the destination through combinations of the same or different transportation modes and transfer points, thereby providing users with more flexible travel options to meet their travel needs. For example, during peak travel seasons such as holidays, the direct travel plan from the departure place to the destination may face the situation of tight ticket sources or high ticket prices, unable to meet the travel needs of a large number of users. By recommending multi-hop travel plans from the departure place to the destination to users, flexible travel options can be provided to meet the travel needs of users; another example is that there may be no direct transportation schedules between the departure place and the destination. For example, there is no direct flight or direct train between the departure place and the destination. In this case, it is necessary to recommend multi-hop travel plans from the departure place to the destination to achieve a smooth journey from the departure place to the destination; yet another example is that in the context of long-distance travel or overseas travel, the direct flight ticket price is often high. At this time, users may choose to use the multi-hop flight transfer method in the hope of reducing travel costs and pursuing higher cost performance. Therefore, if the travel plans recommended by the travel service platform to users include multi-hop travel plans (i.e., multi-hop paths), users can flexibly select appropriate travel plans according to the actual situation and budget to meet their travel needs.

[0046] A recommendation process for a two-hop path can be as Figure 1 shown, Figure 1 showing an example diagram of the stages of the recommendation process for a two-hop path, as Figure 1As shown, the recommendation process may include an offline full-path generation stage 110 and an online real-time price library filtering stage 120.

[0047] The offline full-path generation stage 110 corresponds to the path planning stage of the recommendation process and is used to plan the full path for the case where the multi-leg path is two legs. Specifically, through the Cartesian product method, all two-leg paths from the departure place to the destination are generated.

[0048] The Cartesian product operation combines each element in the two sets to generate all possible combinations. Specifically, in the path planning stage of the two-leg path, the first set in the two sets represents all transportation modes or routes of the first leg, and the second set represents all transportation modes or routes of the second leg. Therefore, the Cartesian product operation can generate combinations of all possible transportation modes or route combinations of the two-leg path based on the above two sets.

[0049] The online real-time price library filtering stage 120 corresponds to the sorting stage of the recommendation process and is used to utilize online queries to filter the generated two-leg paths through the price library to obtain the filtered two-leg paths, and then sort the filtered two-leg paths based on the two dimensions of price and time and recommend them to the user.

[0050] It should be noted that the price library is the abbreviation of price and ticket volume inventory, which is recorded in the price library database. A specific price library database can record the real-time price data and ticket volume inventory data of each transportation shift of one or more transportation modes. For example, the price library database of airline tickets records the price, seat ticket volume inventory, and flight information of each flight of the airline; the price library database of train tickets records the ticket price and remaining ticket volume of each train shift. Among them, each transportation shift of transportation modes such as airplanes and trains may have different seat types (for example, trains have seat types such as hard seats, soft seats, hard sleepers, and soft sleepers). In the price library database, the prices of each seat type are different, and the ticket volume inventory may also be different.

[0051] It can be seen that the above recommendation process can efficiently implement two-leg path planning and complete the sorting and recommendation of two-leg paths when recommending two-leg paths. However, multi-leg paths include two-leg paths and paths with more than two legs (paths with more than two legs such as three-leg and above paths). The above recommendation process has obvious performance bottlenecks when processing paths with more than two legs, resulting in insufficient performance of the travel service platform in recommending travel plans, which is specifically manifested in the following aspects:

[0052] There are difficulties in generating paths with more than two legs. When using the Cartesian product to generate paths with more than two legs, the number of paths with more than two legs grows exponentially. For example, assuming there are N transportation modes available for selection, the possible combinations of transportation modes for a three-leg path are N 3, the number of possible combinations of travel modes for a four-leg path is N 4 , so the number of paths with more than two legs grows exponentially; as the number of paths with more than two legs grows exponentially, the spatio-temporal complexity of offline calculation will increase rapidly, resulting in huge consumption of computing resources, so it may not be possible to generate paths with more than two legs within the specified time, making it difficult to complete path planning;

[0053] The price library query request takes too much time. For paths with more than two legs, each path segment in the paths with more than two legs needs to query the price library, that is, the paths with more than two legs contain multiple path segments, so multiple price library query requests need to be initiated; for example, a three-leg path contains three path segments. Assuming that each path segment has M possible transportation schedules, M price library queries need to be initiated for each path segment respectively, which leads to a sharp increase in the processing complexity in the online real-time filtering price library stage. Especially when the number of paths with more than two legs is large and the number of path segments is large, the time consumption of query requests may be uncontrollable, resulting in a performance bottleneck of the travel service platform;

[0054] Poor reusability. In the path planning stage of the above recommendation process, paths need to be developed separately for different combinations of travel modes. For example, if a two-leg path of train and train has been developed, if a two-leg path of train and car is to be added, the code and logic of the developed two-leg path of train and train cannot be reused, and paths need to be redeveloped for the new combination of travel modes of train and car, which leads to an increase in development and maintenance costs and is difficult to flexibly expand new combinations of travel modes; that is to say, the path characteristics and requirements of different travel modes are different. For example, the departure times, ticket prices, and transfer requirements of trains and cars vary greatly. These differences make it difficult to modularize and highly reuse path development, so a large amount of customized development is required, resulting in poor reusability;

[0055] Poor personalization. The sorting stage of the above recommendation process relies on two dimensions of price and time to sort two-leg paths, lacking personalized recommendation based on user preferences. For example, some users may value price more and are willing to spend more time transferring for a cheaper ticket price, while some users may value time more and are willing to pay a higher ticket price to shorten the travel time; that is to say, due to the lack of full consideration of the user's historical behavior and personalized needs, it is impossible to accurately meet the user's preferences, and there is a lack of personalized recommendation results for users.

[0056] Based on this, the embodiments of the present application provide an improved travel plan recommendation method, which considers based on dynamic graph data, integrates path planning and price library filtering, improves the performance of the travel service platform in recommending travel plans, and sorts and recommends one-way paths and multi-leg paths to users on the basis of considering user preferences, so as to recommend travel plans that meet user needs and improve the recommendation accuracy of travel plans.

[0057] As an alternative implementation, Figure 2 An exemplary stage diagram of the travel plan recommendation method provided by the embodiments of the present application is shown. The travel plan recommendation method provided by the embodiments of the present application can be applied to a travel service platform, such as an OTP or OTA platform. In an alternative implementation, the travel service platform (such as an OTP or OTA platform) may include a server on the service side, referred to as a travel server (such as an OTP server or an OTA server). Therefore, the travel plan recommendation method provided by the embodiments of the present application can be specifically applied to the travel server. In an alternative implementation, the travel service platform (such as an OTP or OTA platform) can be regarded as an online service platform formed by a server cluster formed by travel servers through setting various software and hardware functional architectures.

[0058] As Figure 2 shown, the stages of the travel plan recommendation method provided by the embodiments of the present application may include: a dynamic graph data construction stage 210, an offline path planning stage 220, an online path service and pruning stage 230, and a travel plan mixing and personalized output stage 240.

[0059] The dynamic graph data construction stage 210 is used to construct a graph data that describes traffic stations and the traffic travel relationships between traffic stations, and whose price library data is dynamically updated, so as to provide basic data support for subsequent stages. It should be noted that the graph data organizes and stores data in a graph structure. In the graph data, the data is represented as a set of nodes and edges. Among them, the nodes represent entities or objects, the edges represent the relationships or connections between the nodes, and each node can have node attributes to describe the information of the node, and each edge can have edge attributes to describe the relationships between the nodes. Specifically in the travel plan recommendation scenario, in the dynamic graph data construction stage of the embodiments of the present application, the graph data method is mainly used to describe traffic stations, the traffic travel relationships between traffic stations, and use the dynamically updated price library data to describe the prices and ticket volume inventories of traffic schedules between traffic stations.

[0060] As an alternative implementation, in the embodiments of the present application, the graph data may include node data and edge data. Among them, the node data represents traffic stations in the traffic network (such as railway stations, airports, bus stations, etc.). That is to say, traffic stations such as railway stations, airports, and bus stations in the traffic network exist as entities in the graph database and are represented as nodes, and node attributes are set. For example, a traffic station is represented as a node and node attributes are set. The node data does not change within a certain period of time. For example, the node data does not change within a day. Therefore, compared with the dynamically updated price library data, the node data can be regarded as static data.

[0061] Edge data represents the transportation relationship between transportation stations, which is abstracted as the connecting edges between nodes in the graph database (i.e., the connecting edges between transportation stations), and edge attributes are set. In graph data, the connecting edges can be divided into transportation schedule edges and transfer edges; among them, the transportation schedule edge represents the direct transportation schedule between the connected transportation stations. For example, a direct transportation schedule between two transportation stations is represented as a transportation schedule edge, and edge attributes are set; the transfer edge represents the transfer situation between the connected transportation stations that is not a transportation schedule, and users need to transfer between transportation stations on foot, by urban transportation, by taxi, etc.

[0062] The price database data that is dynamically updated mainly refers to that the price database data corresponding to the transportation schedule edges of the graph data needs to be dynamically updated. For example, there can be dynamically updated price database data in the edge attributes of the transportation schedule edges.

[0063] As an optional implementation, Figure 3A Exemplarily shows the flowchart of constructing graph data provided by the embodiments of the present application. Refer to Figure 3A , this process can include the following steps.

[0064] Step S310: Represent each transportation station as a node in the graph data, and set node attributes associated with the transportation station for each node respectively.

[0065] A node is a basic constituent element of graph data. In the embodiments of the present application, it represents a transportation station in the transportation network. The embodiments of the present application can represent each transportation station in the transportation network (such as each railway station, each airport, each bus station, etc.) as a node in the graph data respectively, so as to facilitate processing the relationships between different transportation stations in the graph data.

[0066] The embodiments of the present application can set node attributes for each node respectively to describe the transportation station represented by the node; that is to say, the node attribute is detailed information or features attached to the node. The embodiments of the present application can set node attributes for the node based on the detailed information or features of the transportation station represented by the node, so as to achieve setting node attributes associated with the transportation station for the node.

[0067] As an optional implementation, the node attributes of the node can include but are not limited to:

[0068] The unique identifier of the node. Each node has a unique identifier in the graph data to be used to distinguish different nodes; in the optional implementation, the unique identifier of the node can be set as the node number;

[0069] The site type of a node represents the type of transportation site represented by the node, so that different site types can distinguish different types of transportation sites; for example, railway stations, airports, bus stations, etc. belong to different types of transportation sites, so the nodes corresponding to transportation sites of the railway station type, the nodes corresponding to transportation sites of the airport type, and the nodes corresponding to transportation sites of the bus station type have different site types; by distinguishing the site types, it helps to distinguish different transportation modes in the graph data;

[0070] The basic attributes of a node are used to describe the basic information of the transportation site represented by the node, including but not limited to the site name (i.e., the name of the transportation site, such as the name of a railway station, the name of an airport, etc.), the name of the city where the site is located (for example, the name of the city where the transportation site is located), the city code of the site (i.e., the code of the city where the transportation site is located, and each city can have a unique code to distinguish different cities), the city ID of the site (i.e., the ID of the city where the transportation site is located, and each city can have a unique ID), etc.

[0071] It should be noted that the site city code (code) can be the geographical area identifier of the site city (the city where the transportation site is located), such as the area code of the site city; the site city ID (Identity, identity identifier) can be the identifier of the site city used internally by the travel service platform. For example, the travel service platform may use an automatically generated digital ID internally to represent the site city ID, so as to facilitate the travel service platform to query and associate the data of the site city.

[0072] For the convenience of further understanding, Figure 3B An exemplary content example diagram of node attributes is shown for reference. Among them, long is a programming language data type used to represent a 64-bit signed integer, and long can store a larger numerical value than the standard integer type (such as int); string is a data type representing a text string and is used to store a series of characters such as letters, numbers, and symbols.

[0073] Step S320: Based on the transportation relationship between transportation sites, set transportation schedule edges and transfer edges between nodes; among them, the transportation schedule edge represents the direct transportation schedule between the transportation sites corresponding to the connected nodes, and the transfer edge represents the transfer situation of non-transportation schedules between the transportation sites corresponding to the connected nodes.

[0074] The connection edge is an element in the graph data that identifies the relationship between nodes. In the embodiments of the present application, the connection edge represents the transportation relationship between transportation sites. Specifically, the connection edge can be a directed edge and is connected from one transportation site to another transportation site, representing the transportation relationship from one transportation site to another transportation site, such as the direct transportation schedule between transportation sites or the transfer situation of non-transportation schedules.

[0075] In an alternative implementation, the connecting edges are divided into transportation schedule edges and transfer edges; a transportation schedule edge indicates that there is a direct transportation schedule between the two connected transportation stations, that is, a direct transportation travel relationship. That is to say, the user does not need to transfer midway and can directly reach another transportation station pointed to by the transportation schedule edge from one transportation station through the direct transportation schedule.

[0076] A transfer edge indicates the transfer situation between the two connected transportation stations that is not a transportation schedule. That is to say, a transfer edge indicates the transfer situation between the two connected transportation stations, and the transfer does not depend on the transportation schedule. For example, the user transfers between the two transportation stations connected by the transfer edge on foot, by urban transportation, or by taxi, etc., rather than by using scheduled transportation means such as airplanes, trains, or buses for transfer.

[0077] In an alternative implementation, for any two transportation stations, the travel service platform can analyze the transportation travel relationship between the two transportation stations based on the transportation route database, so as to confirm whether there is a direct transportation schedule between the two transportation stations, and set a transportation schedule edge for the two nodes corresponding to the two transportation stations with a direct transportation schedule in the graph data. At the same time, analyze the transfer situation between the two transportation stations that is not a transportation schedule and set a transfer edge.

[0078] It should be noted that since the connecting edge is a directed edge (regardless of whether it is a transportation schedule edge or a transfer edge), for the two nodes connected by the connecting edge, the node that emits the connecting edge is the departure node, and the corresponding transportation station is the departure station of the connecting edge. The node pointed to by the connecting edge is the arrival node, and the corresponding transportation station is the arrival station of the connecting edge.

[0079] In an example of an alternative implementation, for any two transportation stations, when setting the connecting edge in the embodiments of the present application, the departure station and the arrival station among the two transportation stations can be determined, and then based on the transportation route database, analyze and judge whether there is a direct transportation schedule from the departure station to the arrival station; if there is a direct transportation schedule, then based on each direct transportation schedule, respectively set a transportation schedule edge in the graph database for the node corresponding to the departure station, pointing to the node corresponding to the arrival station, that is, each direct transportation schedule between the two transportation stations is respectively corresponding to a set transportation schedule edge; at the same time, analyze the transfer situation between the two transportation stations that is not a transportation schedule, so as to set a transfer edge between the two transportation stations.

[0080] In a further alternative implementation, the embodiments of the present application can define the transfer edge setting conditions, so as to set transfer edges between the transportation stations that meet the transfer edge setting conditions. By way of example, the transfer edge setting conditions include but are not limited to:

[0081] The transportation stations where transfer edges are set are in the same geographical area. For example, transfer edges can be set between different transportation stations in the same city;

[0082] The distance between the transportation stations where transfer edges are set does not exceed a preset distance. For example, for any two transportation stations in different cities, the embodiments of the present application can analyze the distance between the two transportation stations. If the distance does not exceed the preset distance, the embodiments of the present application can set transfer edges for the two transportation stations across cities. If the distance exceeds the preset distance, the embodiments of the present application do not set transfer edges for the two transportation stations across cities; that is to say, the distance between two transportation stations across cities is relatively far, and the possibility of non-transportation shift transfer is relatively low, so transfer edges can be not set.

[0083] Of course, the embodiments of the present application can also consider other possible transfer edge setting conditions to restrict the transportation stations where transfer edges are set in the graph data, and are not limited to the examples of the above transfer edge setting conditions.

[0084] It should be noted that the transportation route database records the transportation schedule information of various transportation modes (such as trains, airplanes, cars, etc.). The transportation schedule information includes the route data of the transportation schedule, such as the transportation stations from which the transportation schedule departs, the transportation stations passed through, and the transportation stations reached. Therefore, based on the route data of each transportation schedule in the transportation route database, it can be analyzed and confirmed whether the transportation relationship between two transportation stations is direct.

[0085] Step S330, set edge attributes for transportation schedule edges and transfer edges.

[0086] When setting connection edges between nodes, the embodiments of the present application can set edge attributes for the connection edges. Based on the connection edges being divided into transportation schedule edges and transfer edges, the embodiments of the present application can set edge attributes for transportation schedule edges and transfer edges.

[0087] In an alternative implementation, the edge attributes of transportation schedule edges not only include the information of the departure node (corresponding to the departure station) and the arrival node (corresponding to the arrival station), but also include multiple attribute information describing the transportation schedule. For ease of understanding, Figure 3C An exemplary content example diagram of the edge attributes of transportation schedule edges is shown in combination with Figure 3C As shown, the edge attributes of transportation schedule edges include but are not limited to:

[0088] src_id, representing the unique identifier of the departure node of the transportation schedule edge, used to identify the node that emits the transportation schedule edge in the graph data;

[0089] dst_id represents the unique identifier of the arrival node on the transportation schedule edge, which is used to identify the node pointed to by the transportation schedule edge in the graph data; in the edge attributes of the transportation schedule edge, the two fields src_id and dst_id define the start and end points of the transportation schedule edge;

[0090] time stamps are used to identify the time stamp identifier of the transportation schedule corresponding to the transportation schedule edge. For example, the time stamp identifier can be used to distinguish different transportation schedules with the same departure station, and / or the same arrival station, and / or the same departure time, and / or the same arrival time; by way of example, time stamps can be initially set to be the same as the departure time of the transportation schedule corresponding to the transportation schedule edge. Thus, if there are other transportation schedule edges with the same departure station, and / or the same arrival station, and / or the same departure time, and / or the same arrival time in the graph data, in order to further distinguish the transportation schedule edges, the time stamps of the transportation schedule edges can be fine-tuned, such as adding 1 second or subtracting 1 second from the time stamps of the transportation schedule edges, so that multiple transportation schedule edges with any one of the departure station, arrival station, departure time, arrival time, etc. being the same have different time stamps;

[0091] dep_date represents the departure date of the transportation schedule corresponding to the transportation schedule edge, which is used to describe the date information of the transportation schedule departure;

[0092] traffic_code represents the code of the transportation schedule corresponding to the transportation schedule edge, such as the train number in the case of a train schedule;

[0093] src_station represents the departure station of the transportation schedule edge, that is, the transportation station corresponding to the departure node of the transportation schedule edge, such as the name of the departure station;

[0094] dst_station represents the arrival station of the transportation schedule edge, that is, the transportation station corresponding to the arrival node of the transportation schedule edge, such as the name of the arrival station;

[0095] dep_city_code represents the code of the city where the departure station is located, that is, the code of the departure city;

[0096] arr_city_code represents the code of the city where the arrival station is located, that is, the code of the arrival city;

[0097] dep_city_id represents the ID of the departure city;

[0098] arr_city_id represents the ID of the arrival city;

[0099] cost_time represents the time taken for the transportation schedule corresponding to the transportation schedule edge to travel from the departure station to the arrival station, and the time is measured in seconds;

[0100] dep_time represents the departure time of the transportation schedule corresponding to the transportation schedule edge, and is expressed in the format of unix time stamps;

[0101] arr_time represents the arrival time of the transportation schedule corresponding to the transportation schedule edge, and is expressed in the format of unix time stamps;

[0102] update time is the update time stamp of the price library data, which represents the time stamp of the last update time of the price and ticket inventory of the transportation schedule corresponding to the transportation schedule edge. Since the price and ticket inventory of the transportation schedule are dynamically changing, the timeliness of the price library data included in the edge attributes of the transportation schedule edge can be confirmed through the update time stamp of the price library data;

[0103] status represents the schedule status of the transportation schedule corresponding to the transportation schedule edge. For example, whether the schedule status of the transportation schedule is operating normally. For example, the transportation schedule may be delayed or cancelled due to vehicle failure or weather reasons, resulting in abnormal operation;

[0104] stock_info represents the ticket inventory of the transportation schedule corresponding to the transportation schedule edge, such as the remaining tickets of the transportation schedule. The stock_info field is used to clarify whether there are any remaining tickets for the transportation schedule, so as to provide ticket availability information for the transportation schedule;

[0105] price_info represents the price of the transportation schedule corresponding to the transportation schedule edge, such as the minimum price corresponding to the remaining tickets with ticket inventory; In an alternative implementation example, the above stock_info can also be expressed as the ticket inventory corresponding to the minimum price among the remaining tickets of the transportation schedule;

[0106] stock_type represents the seat type of the remaining tickets of the transportation schedule corresponding to the transportation schedule edge, such as the seat type corresponding to the minimum price among the remaining tickets.

[0107] It should be noted that in Figure 3CAmong the contents included in the edge attributes of the example, the bigint type is an integer data type used to store larger integer values, such as a 64-bit signed integer. Compared with the standard integer type (e.g., int), bigint can store larger numerical values. It should be noted that although both bigint and long are 64-bit signed integer types, bigint is a data type in the database, while long is a data type in programming languages. Bool is a boolean data type used to represent two possible states, such as true or false. Boolean values can also be stored as 1 (true) or 0 (false).

[0108] In an alternative implementation, the edge attributes of the transfer edge can have the unique identifier of the departure node and the unique identifier of the arrival node, and describe the characteristics of the transfer situation through a series of attributes. For ease of understanding, Figure 3D An exemplary content example diagram of the edge attributes of the transfer edge is shown in combination with Figure 3D As shown, the edge attributes of the transfer edge include but are not limited to:

[0109] src_id, which represents the unique identifier of the departure node of the transfer edge and is used to identify the node that emits the transfer edge in the graph data;

[0110] dst_id, which represents the unique identifier of the arrival node of the transfer edge and is used to identify the node pointed to by the transfer edge in the graph data; In the edge attributes of the transfer edge, the two fields src_id and dst_id define the starting point and ending point of the transfer edge;

[0111] time stamps, which represents the time stamp identifier and is used to align with the time stamps of the transportation schedule edge in format. For the transfer edge, the value of time stamps can be set to a meaningless value, such as zero;

[0112] src_type, which represents the station type of the departure station of the transfer edge, that is, the station type of the transportation station corresponding to the departure node of the transfer edge;

[0113] dst_type, which represents the station type of the arrival station of the transfer edge, that is, the station type of the transportation station corresponding to the arrival node of the transfer edge;

[0114] edge_type, which represents that the edge type of the connecting edge is a transfer edge; Specifically, in the graph data, the edge types of the connecting edges are divided into transportation schedule edges and transfer edges. In the edge attributes of the transfer edge, the type of the connecting edge corresponding to edge_type is a transfer edge;

[0115] src_station, which represents the departure station of the transfer edge, such as the name of the departure station, etc.;

[0116] dst_station, which represents the arrival station of the transfer edge, such as the name of the arrival station, etc.;

[0117] dep_city_code, which represents the code of the city where the departure station is located, that is, the code of the departure city;

[0118] arr_city_code, which represents the code of the city where the arrival station is located, that is, the code of the arrival city;

[0119] dep_city_id, which represents the ID of the departure city;

[0120] arr_city_id, which represents the ID of the arrival city;

[0121] cost_time, which represents the time consumed for transfer, and is timed in seconds;

[0122] min_price, which represents the estimated minimum price for transfer.

[0123] It can be seen that, compared with the edge attributes of transportation schedule edges and transfer edges, there is price library data in the edge attributes of transportation schedule edges, that is, the price data and ticket inventory data of transportation schedules. Since the prices and ticket inventories of transportation schedules are dynamically changing, after the embodiments of the present application set the nodes corresponding to transportation stations, as well as the transportation schedule edges and transfer edges between the nodes in the graph data, it is also necessary to dynamically update the price library data of transportation schedule edges, so as to keep the price library data of transportation schedule edges in the graph data timely.

[0124] Step S340: According to the price library data of transportation schedules, update the price storage data for the edge attributes of the transportation schedule edges corresponding to the transportation schedules by means of a caching mechanism.

[0125] In an alternative implementation, the travel service platform can obtain the price library data of transportation schedules regularly or in real time through a message middleware, and then update the price storage data for the edge attributes of the transportation schedule edges corresponding to the transportation schedules in the graph data, that is, update the price data and ticket inventory data. Among them, the message middleware is a technology used to transfer messages between different system components. The message middleware can efficiently transfer messages from producers to consumers and ensure reliable and efficient transmission of messages. Therefore, the embodiments of the present application can use the message middleware to transmit large-scale real-time price library data between the provider of the price library data and the component that updates the price storage data for the transportation schedule edges of the travel service platform, so as to ensure the efficiency of the travel service platform when updating and processing a large amount of price library data (such as the price library data of multiple transportation schedules).

[0126] In a further optional implementation, the travel service platform can, through a message middleware, actively and regularly obtain the real-time price database data of each transportation schedule of various transportation modes from multiple price database databases, so as to update the price storage data for the edge attributes of the transportation schedule edges corresponding to the transportation schedules in the graph data based on the obtained real-time price database data of the transportation schedules; among them, one price database database can record the real-time price database data of each transportation schedule of at least one transportation mode, that is, the real-time price data and ticket quantity inventory data.

[0127] For example, the travel service platform can connect to the price database databases of each transportation company and transportation administration through interfaces, including but not limited to the price database database of train tickets of railway companies and railway administrations, the price database database of airline tickets of airlines, and the price database database of bus tickets of bus passenger transport companies. Thus, the travel service platform can actively obtain the real-time price database data of each transportation schedule of various transportation means (such as trains, airplanes, buses, etc.) through the connected price database databases, and the obtained price database data is transmitted to the travel service platform through the message middleware; furthermore, the travel service platform can update the price storage data for the edge attributes of each transportation schedule edge in the graph data. That is to say, the travel service platform can connect to the price database databases related to transportation tickets such as train tickets, airline tickets, and bus tickets through the open data interfaces of train tickets, airline tickets, and bus tickets, so as to regularly or real-time pull the real-time price database data of each transportation schedule of various transportation means such as trains, airplanes, and buses.

[0128] In other optional implementations, the source of the price database data of the transportation schedule obtained by the travel service platform can also be the exposure data of ticket searches. For example, the travel service platform can provide users with search functions for transportation tickets such as train tickets, airline tickets, and bus tickets. Thus, when the users of the travel service platform search for transportation tickets such as train tickets, airline tickets, and bus tickets, corresponding exposure data will be generated. These exposure data contain the real-time price database data of multiple transportation schedules of various transportation means such as trains, airplanes, and buses, and can reflect the real-time travel demand situation of users. Thus, it can be used as the source for the travel service platform to update the price storage data of the transportation schedule edges in the graph data and be transmitted through the message middleware, such as transmitted between the ticket search engine of the travel service platform and the component that updates the price database data for the transportation schedule edges of the travel service platform.

[0129] That is to say, the price database data of the transportation schedule comes from multiple price database databases and / or the exposure data of ticket searches. By way of example, the travel service platform can combine the above price database databases and the above exposure data to obtain the real-time price database data of each transportation schedule of various transportation modes, and perform transmission and consumption processing of the price database data through the message middleware (consumption processing means using the transmitted price database data to update the price data and ticket quantity inventory data of the transportation schedule edges).

[0130] To reduce the burden of updating the price database data on the transportation schedule edge, the embodiments of the present application introduce a caching mechanism to avoid duplicate and invalid updates of the price inventory data on the transportation schedule edge. Specifically, the travel service platform can cache the price database data of the obtained transportation schedules according to a preset caching time. That is to say, after the travel service platform collects the price database data of the transportation schedules, there is a caching mechanism for caching the collected price database data of the transportation schedules. If the cached price database data of the transportation schedules exceeds the preset caching time, the cached price database data of the transportation schedules expires. Thus, for any transportation schedule, when the newly obtained price database data of the transportation schedule is the same as the cached price database data of the transportation schedule, the embodiments of the present application can cancel the update of the price inventory data for the transportation schedule edge corresponding to the transportation schedule until the cached price database data of the transportation schedule expires, or when the newly obtained price database data of the transportation schedule is different from the cached price database data of the transportation schedule, update the price inventory data for the transportation schedule edge corresponding to the transportation schedule based on the newly obtained price database data of the transportation schedule.

[0131] For ease of understanding, Figure 3E an exemplary diagram showing the update of the price database data is presented, as Figure 3E shown. There is corresponding price database data for each mode of transportation. For example, the price database data of train tickets (including the real-time price database data of each train schedule), the price database data of airplane tickets (including the real-time price database data of each flight), the price database data of bus tickets (including the real-time price database data of each bus schedule), and the price database data corresponding to other modes of transportation. These price database data are transmitted through a message middleware with corresponding message topics (themes).

[0132] To reduce the burden of updating the price database data on the transportation schedule edge of the graph data, the embodiments of the present application introduce a caching mechanism. By setting up a message cache, the real-time price database data of each transportation schedule of various modes of transportation transmitted by the message middleware is cached. The effective caching time of the message cache for the price database data of any transportation schedule is the preset caching time (such as 10 minutes). That is, when the preservation time of the price database data of any transportation schedule in the message cache reaches the preset caching time, it is regarded as expired, and the newly obtained price database data of this transportation schedule needs to be re-cached.

[0133] Furthermore, after the travel service platform obtains the real-time price library data of a transportation schedule each time through the message middleware, it can check whether the newly obtained price library data of the transportation schedule is the same as the cached price library data of the transportation schedule, that is, check whether the price data and ticket inventory data of the newly obtained transportation schedule have changed compared with the price data and ticket inventory data of the cached transportation schedule; if the newly obtained price library data of the transportation schedule is the same as the cached price library data of the transportation schedule, no update of the price library data on the corresponding transportation schedule side is performed because the price library data has not changed, thus avoiding unnecessary updates of the price library data on the transportation schedule side; if the newly obtained price library data of the transportation schedule is different from the cached price library data of the transportation schedule, it is necessary to update the price storage data for the corresponding transportation schedule side in the graph data, cache the newly obtained price library data of the transportation schedule, and reset the cache time.

[0134] For example, taking the preset cache time of 10 minutes as an example, when the travel service platform first obtains the price library data of a certain transportation schedule, it can cache the price library data of the transportation schedule in the message cache, set a cache time of 10 minutes, and update the price storage data for the corresponding transportation schedule side in the graph database; within the next 10 minutes, if the newly obtained price library data of the transportation schedule is the same as the cached data (that is, the price and ticket inventory of the transportation schedule have not changed), the embodiments of the present application do not update the price library data for the corresponding transportation schedule side; if the newly obtained price library data of the transportation schedule is different from the cached data (that is, the price and / or ticket inventory of the transportation schedule have changed), the price library data for the corresponding transportation schedule side is updated, and the newly obtained price library data of the transportation schedule is re-cached, and a cache time of 10 minutes is set; after the cache time reaches 10 minutes, regardless of whether the newly obtained price library data of the transportation schedule is the same as the cached data, the embodiments of the present application will use the newly obtained price library data of the transportation schedule to update the price library data of the corresponding transportation schedule side, and re-cache the newly obtained price library data of the transportation schedule, and set a cache time of 10 minutes, and so on.

[0135] Through the cache mechanism, the embodiments of the present application avoid updating the graph data every time the price library data of a transportation schedule is newly obtained, and only update the graph data when necessary (data change or cache timeout), reducing unnecessary update operations and the update burden.

[0136] So far, the embodiments of this application have constructed the graph data, and the graph data includes nodes corresponding to each transportation station (such as railway stations, airports, bus stations, etc.), and connection edges (transportation schedule edges and transfer edges) corresponding to the transportation relationships between transportation stations. Moreover, the price data and ticket inventory data of the edge attributes of the transportation schedule edges can be dynamically updated to reflect the dynamic price, ticket inventory, and other information of each transportation schedule, providing a basis for the processing in the subsequent stages.

[0137] The offline path planning stage 220 is used to plan multi-hop paths and corresponding transfer points for any two transportation stations based on the graph data, especially to plan paths with more than two hops and corresponding transfer points for any two transportation stations.

[0138] In an alternative implementation, the one-hop path between transportation stations can be determined based on the transportation schedule edges between transportation stations. That is, the transportation schedule edges between transportation stations represent the direct transportation schedules between transportation stations, corresponding to the one-hop paths between transportation stations. The two-hop paths between transportation stations can complete path search through path search algorithms integrated in graph databases such as bidirectional BFS (Breadth First Search) and DFS (Depth First Search), that is, the two-hop paths can directly rely on the characteristics of the graph data itself to ensure the smooth progress of path search. It should be noted that the graph data can be stored in a graph database, and basic path search algorithms are integrated inside the graph database for searching paths between nodes in the graph data.

[0139] However, as described above, the number of paths with more than two hops (such as paths with three or more hops) grows exponentially, and paths with more than two hops contain multiple path segments. Querying the price database data of the transportation schedules of each path segment is very time-consuming. Therefore, the embodiments of this application consider optimizing the path planning of paths with more than two hops at least in the offline path planning stage, and planning paths with more than two hops and corresponding transfer points for any two transportation stations at least.

[0140] In other alternative implementations, the offline path planning stage may also involve planning two-hop paths for any two transportation stations, rather than being limited to only planning paths with more than two hops; for example, for any two transportation stations, the offline path planning stage can plan two-hop and paths with more than two hops, as well as corresponding transfer points.

[0141] That is to say, the multi-hop paths planned by the offline path planning stage for any two transportation stations can be paths with more than two hops, or two-hop paths and paths with more than two hops.

[0142] In the offline path planning stage of the embodiments of the present application, multi-stage paths (especially paths with more than two stages) and corresponding transfer points are planned for any two transportation stations, which can facilitate the subsequent online path service and pruning stage. Further, in the offline path planning stage, the embodiments of the present application can solve the difficult path planning problem existing in the Cartesian product operation based on the use of graph data and path search algorithms such as Dijkstra's algorithm.

[0143] As an alternative implementation, Figure 4 Exemplarily, a flowchart of the offline path planning provided by the embodiments of the present application is shown. Based on Figure 4 the shown process, the embodiments of the present application can plan multi-stage paths and corresponding transfer points for any two transportation stations. The multi-stage paths planned here can be paths with more than two stages, or two-stage paths and paths with more than two stages. Referring to Figure 4 , this process may include the following steps.

[0144] Step S410, based on the graph database, use the path search algorithm to generate multiple multi-stage paths between any two transportation stations.

[0145] In the offline path planning process, the generation of multi-stage paths is realized according to the graph data and with the help of the path search algorithm to find passable multi-stage paths between any two transportation stations; that is, with the help of the path search algorithm, considering whether the path is passable, so as to find multi-stage paths between any two transportation stations in the graph data. Specifically, in the graph data, for any two nodes, a multi-stage path starts from the starting node, and based on the path search algorithm, expands along the connecting edges (transportation schedule edges, or transportation schedule edges and transfer edges), thus passing through multiple transferred nodes (the nodes passed through in the middle of the multi-stage path are transfer points), and finally reaching the destination node. Moreover, the number of transportation schedule edges included in a multi-stage path corresponds to the number of stages of the multi-stage path. Further, each transferred node and transportation schedule edge passed through by the generated multi-stage path can be recorded.

[0146] The embodiments of the present application can generate multi-stage paths with various numbers of stages for any two nodes (corresponding to any two transportation stations) in the graph data. For example, for paths with more than two stages, paths with various numbers of stages such as three stages and four stages can be generated, so as to obtain multiple multi-stage paths between any two transportation stations; among them, one number of stages of the multi-stage paths between two transportation stations can correspond to one or more paths. For example, the three-stage paths between two transportation stations can be one or more.

[0147] In an alternative implementation, the path search algorithms used in the embodiments of the present application include but are not limited to any of the following:

[0148] Dijkstra's algorithm is used to search for the shortest path, such as searching for multi-hop paths with various numbers of hops that have the shortest path from the starting node to the ending node. For example, for paths with two or more hops, it searches for two-hop and above paths with various numbers of hops that have the shortest path from the starting node to the ending node, such as three-hop, four-hop, etc.

[0149] Depth-first search algorithm is used to search for all multi-hop paths. For example, for paths with two or more hops, it searches for all passable two-hop and above paths with various numbers of hops from the starting node to the ending node.

[0150] Breadth-first search algorithm is used to find the shortest path in an unweighted graph. For example, in the case where the connecting edges of the graph data have no weights (i.e., in the case of an unweighted graph), it searches for multi-hop paths with various numbers of hops that have the shortest path from the starting node to the ending node.

[0151] Heuristic search algorithm optimizes path finding through heuristic search. Compared with Dijkstra's algorithm, the heuristic search algorithm adds heuristic evaluation and optimizes the search process by estimating the cost of the path.

[0152] Furthermore, when using the path search algorithm to generate multiple multi-hop paths between two transportation stations, for any one multi-hop path, the embodiments of the present application can use vector data to store detailed information related to the path of the multi-hop path, such as the starting node of the multi-hop path, the transportation schedule edges passed through, the transferred nodes passed through, the ending node of the multi-hop path, etc.

[0153] Step S420: For each multi-hop path between any two transportation stations, evaluate the value score of the multi-hop path according to multiple path evaluation features to obtain the value score of each multi-hop path between any two transportation stations.

[0154] After generating multiple multi-hop paths between any two transportation stations based on the graph data, for any two transportation stations, the embodiments of the present application can evaluate the value score of each multi-hop path. When evaluating the value score of a multi-hop path, it depends on multiple path evaluation features corresponding to the multi-hop path, including but not limited to:

[0155] The time consumption of the multi-hop path, that is, the total time from the starting station to the ending station of the multi-hop path. Specifically, it can be calculated through the time consumption of the transportation schedule corresponding to each transportation schedule edge passed through by the multi-hop path and the time consumption for transfer at each transferred node passed through; that is, by accumulating the time consumption of each section of the transportation schedule passed through by the multi-hop path and the time consumption for transfer at each transferred node, the time consumption of the multi-hop path is estimated and calculated.

[0156] The price of a multi - leg path, which is the sum of the travel costs from the departure station to the arrival station of the multi - leg path, can be specifically calculated by the price of each transportation schedule corresponding to the transportation schedule edges passed by the multi - leg path and the estimated price for transfer at each transfer node passed through.

[0157] It should be noted that the above - mentioned path evaluation features of time consumption and price are only optional forms. Embodiments of the present application can also consider other path evaluation features of the multi - leg path, such as the time period in which the departure time of the departure station of the multi - leg path is located, etc.

[0158] After determining multiple path evaluation features such as the time consumption and price of each multi - leg path, for each multi - leg path, embodiments of the present application can integrate multiple path evaluation features such as the time consumption and price of the multi - leg path to obtain the value score of the evaluated multi - leg path. In an alternative implementation, the process of integrating multiple path evaluation features such as the time consumption and price of the multi - leg path may include but is not limited to:

[0159] Normalization processing, normalizing each path evaluation feature such as the time consumption and price of the multi - leg path to obtain the normalization results of each path evaluation feature of the multi - leg path; through normalization processing, different types of path evaluation features of the multi - leg path can be converted into the same scale, enabling different types of path evaluation features such as the time consumption and price of the multi - leg path to be compared and processed with each other; for example, assuming that the price range of the multi - leg path is from 100 yuan to 1000 yuan and the time - consumption range is from 1 hour to 12 hours, through normalization processing, the price and time consumption of the multi - leg path can both be converted into values between 0 and 1, which is convenient for subsequent calculations;

[0160] Weighted summation, after normalization processing, embodiments of the present application can perform weighted summation processing according to the weights of each path evaluation feature and the normalization results of each path evaluation feature of the multi - leg path to obtain the value score of the multi - leg path; for example, the normalization result of the time consumption of the multi - leg path is multiplied by the weight of the time consumption to obtain a product, the normalization result of the price of the multi - leg path is multiplied by the weight of the price to obtain another product, and the two products are added to complete the weighted summation processing to obtain the value score of the multi - leg path.

[0161] In a further alternative implementation, embodiments of the present application can also use methods such as exponential weighting to determine the value score of the multi - leg path based on multiple path evaluation features such as the time consumption and price of the multi - leg path; for example, using exponential amplification to increase the influence of a certain path evaluation feature (such as time consumption or price) of the multi - leg path, so that the path evaluation feature has a greater impact on the evaluated value score.

[0162] Step S430: For any two transportation stations, based on the value scores of each multi-leg path between the two transportation stations, determine the planned multi-leg paths between the two transportation stations to form a path planning set between any two transportation stations; and, for any two transportation stations, determine the transfer nodes passed by the planned multi-leg paths between the two transportation stations to form a transfer point planning set between any two transportation stations.

[0163] After obtaining the value scores of each multi-leg path between any two transportation stations, for any two transportation stations, embodiments of the present application can sort the multi-leg paths based on the value scores of each multi-leg path between the two transportation stations. For example, sort the multi-leg paths in descending order according to the value scores, so as to use the set number of multi-leg paths with the highest value scores, or the multi-leg paths whose value scores meet the set score criteria, as the planned multi-leg paths between the two transportation stations, in order to obtain a path planning set between the two transportation stations.

[0164] Furthermore, for any two transportation stations, after obtaining the planned multi-leg paths between the two transportation stations, embodiments of the present application can use the transfer nodes passed by the planned multi-leg paths as the planned transfer points between the two transportation stations, in order to obtain a transfer point planning set between the two transportation stations.

[0165] Thus, if any two transportation stations are processed according to the Figure 4 shown process, a path planning set between any two transportation stations and the corresponding transfer point planning set can be determined. That is to say, for any two nodes in the graph data, a path planning set (including the planned multi-leg paths) and the corresponding transfer point planning set (including the planned transfer points) can be generated through the Figure 4 shown process for use in subsequent stages.

[0166] In a further optional implementation, for any two transportation stations, the path planning set can also be subdivided into path planning subsets for each leg. That is to say, there can be a corresponding path planning subset for each leg path, including the paths planned for each leg; for example, for any two transportation stations, the path planning set can include a path planning subset for the first leg (including the path planned for the first leg), a path planning subset for the second leg (including the path planned for the second leg), a path planning subset for the third leg (including the path planned for the third leg), and so on. Of course, setting the path planning subsets for each leg is only a further optional implementation method.

[0167] So far, the embodiment of this application has completed the offline path planning, realized the planning of multi-leg paths (especially paths with more than two legs) and corresponding transfer points for any two transportation stations, obtained the path planning set and the corresponding transfer point planning set between any two transportation stations, and solved the difficult problem of path planning in Cartesian product operations.

[0168] The online path service and pruning stage 230 consists of an online path service and online path pruning.

[0169] The online path service is used to: search the graph data according to the user's departure location and the user's destination location, and determine the single-leg path to be recommended between the user's departure location and the user's destination location; and, at least define the transfer point search constraint conditions based on the set of reserved transfer points between any two transportation stations, and search the graph data based on the transfer point search constraint conditions to determine the multi-leg paths to be recommended between the user's departure location and the user's destination location; thus, the single-leg path to be recommended and the multi-leg paths to be recommended form multiple paths to be recommended; where the set of reserved transfer points between any two transportation stations includes the reserved transfer points between any two transportation stations.

[0170] The online path pruning is used to: regularly update the set of reserved transfer points between any two transportation stations, such as the reserved transfer points between any two transportation stations, and regularly update based on the ticket inventory of the transportation schedule edges associated with the transfer points. In an alternative implementation, the set of reserved transfer points between any two transportation stations can be specifically updated regularly based on the path planning set between any two transportation stations, the corresponding transfer point planning set, and the ticket inventory of the transportation schedule edges associated with the transfer points; where the path planning set and the transfer point planning set are pre-generated based on the graph data, such as pre-generated in the offline path planning stage.

[0171] That is to say, the online path service faces user services and outputs the single-leg paths and multi-leg paths (such as two-leg paths and paths with more than two legs) to be recommended between the user's departure location and the user's destination location through graph data search. In the embodiment of this application, the multi-leg paths to be recommended should at least meet the constraints of the transfer points, which are determined by the set of reserved transfer points between the user's departure location and the user's destination location; further, the transportation schedule edges in the single-leg paths to be recommended and the multi-leg paths to be recommended should also at least meet constraints such as ticket inventory.

[0172] For the one-way path to be recommended, embodiments of the present application can perform a path search on the graph data through graph data query, determine the transportation schedule edges directly connected between the user's departure location and the user's destination location, and form the one-way path to be recommended. Further, during the search process of the one-way path to be recommended, constraints such as ticket inventory can be introduced at least to ensure that the searched transportation schedule edges meet the ticket inventory requirements, so as to ensure that the one-way path to be recommended can meet the user's travel needs. Further, during the search process of the one-way path to be recommended, a constraint on the update timestamp of the price database data can also be introduced to restrict the timeliness of the transportation schedule edges that meet the ticket inventory requirements. For example, the time difference between the update timestamp of the price database data and the current time is within a predetermined time difference range. The constraints involved in the above search process of the one-way path to be recommended can be implemented by setting the corresponding search constraint conditions for the transportation schedule edges.

[0173] For the multi-way path to be recommended (especially paths with two or more legs), embodiments of the present application combine the set of reserved transfer points between transportation stations updated regularly by online path pruning as the transfer points to be reserved during the search for multi-way paths between transportation stations. Thus, when searching for the multi-way path to be recommended between the user's departure location and the user's destination location, embodiments of the present application can introduce the set of reserved transfer points between the user's departure location and the user's destination location to define the transfer point search constraint conditions, that is, to restrict the multi-way path between the user's departure location and the user's destination location to pass through the reserved transfer points and not through the unreserved transfer points, thereby reducing the search complexity of the multi-way path to be recommended. Further, during the search process of the multi-way path to be recommended, in addition to introducing the constraint of the set of reserved transfer points, constraints such as ticket inventory can be introduced at least to ensure that the searched transportation schedule edges meet the ticket inventory requirements, so as to ensure that the multi-way path to be recommended can meet the user's travel needs. Further, during the search process of the multi-way path to be recommended, a constraint on the update timestamp of the price database data can also be introduced to restrict the timeliness of the transportation schedule edges that meet the ticket inventory requirements. For example, the time difference between the update timestamp of the price database data and the current time is within a predetermined time difference range. The constraints involved in the above search process of the multi-way path to be recommended can be implemented by setting the corresponding search constraint conditions for the transportation schedule edges. Further, since the multi-way path to be recommended may also involve transfer edges, search constraint conditions can also be set for the transfer edges.

[0174] As an optional implementation, Figure 5A An exemplary flowchart for determining the set of reserved transfer points provided by embodiments of the present application is shown. This process can be regarded as an optional implementation process of online path pruning. Referring to Figure 5A this process may include the following steps.

[0175] Step S510: For each transportation schedule edge included in the path planning set between any two transportation stations, predict the ticket inventory situation of the transportation schedule edge at a future time to obtain the ticket inventory prediction result of the transportation schedule edge.

[0176] For any two transportation stations, the path planning set includes multi-leg paths (such as paths with more than two legs) planned for the two transportation stations, and each planned multi-leg path includes transportation schedule edges. Thus, for any two transportation stations, embodiments of the present application can determine the transportation schedule edges included in the path planning set between any two transportation stations. Furthermore, for each transportation schedule edge included in the path planning set, embodiments of the present application can respectively perform ticket inventory prediction to predict the ticket inventory situation of the transportation schedule edge at a future time (such as the next time).

[0177] For example, it is possible to predict whether there is a ticket inventory for the transportation schedule edge at a future time, or the ticket inventory value at a future time, so as to realize predicting the ticket inventory situation of the transportation schedule edge at a future time and obtain the ticket inventory prediction result of the transportation schedule edge. That is to say, the ticket inventory situation of the transportation schedule edge at a future time can be represented by whether there is a ticket inventory for the transportation schedule edge at a future time, or can be represented by the specific ticket inventory value of the transportation schedule edge at a future time.

[0178] In an alternative implementation, embodiments of the present application can use a prediction model (such as a machine learning model like a deep neural network classification model) to predict the ticket inventory situation of the transportation schedule edge at a future time (such as the next time). For example, input the feature information of the transportation schedule corresponding to the transportation schedule edge into the prediction model, so as to predict the ticket inventory situation of the transportation schedule edge at a future time (such as the next time) and obtain the ticket inventory prediction result of the transportation schedule edge.

[0179] In an alternative implementation, the prediction methods used by the prediction model include but are not limited to:

[0180] Machine learning regression algorithms, which are used to predict continuous values. In the ticket inventory prediction of transportation schedule edges, machine learning regression algorithms can be used to predict the ticket inventory value of the transportation schedule corresponding to the transportation schedule edge at a certain time;

[0181] Graph-based time series prediction algorithms, which predict the ticket inventory situation of transportation schedule edges by combining time series data and graph data. The graph data involves the relationship between nodes and connected edges, which can help the prediction model understand the dependency relationship between transportation stations;

[0182] Deep neural network classification algorithms, such as using a deep neural network classification model in a prediction model, learn the historical data features of traffic shifts to predict whether there is ticket inventory for a traffic shift at the next moment; for example, the deep neural network classification model can be used to handle binary classification problems. For instance, in the embodiments of this application, it is used to predict whether there is ticket inventory for the traffic shift corresponding to a certain traffic shift edge at the next moment.

[0183] In an alternative implementation, taking machine learning models such as deep neural network classification models as an example, Figure 5B An exemplary training example diagram of the prediction model is shown, as Figure 5B shown, the feature data for training includes but is not limited to:

[0184] The basic features of the traffic shift edge, which are used to describe the basic information of the traffic shift edge, such as the identifier of the traffic shift edge (each traffic shift edge in the graph data can be set with a unique identifier, such as the code of the traffic shift edge), the associated upstream and downstream stations (such as the departure station and the arrival station corresponding to the traffic shift edge), the traffic shift corresponding to the traffic shift edge, and other basic information;

[0185] Time features, various types of information related to time, such as the current date, the current time period, the encoding of the current date (encoding the date into a format suitable for model input through cosine transformation), the encoding of the predicted date (the predicted date is the date when predicting whether there is ticket inventory for the traffic shift edge), the predicted time period (the predicted time period is the time period in which the moment when predicting whether there is ticket inventory for the traffic shift edge is located), etc.;

[0186] The inventory features of the upstream and downstream stations associated with the traffic shift edge at the current moment, that is, the ticket inventory of the traffic shifts at the upstream and downstream stations related to the traffic shift edge;

[0187] The inventory sequence features of the traffic shift edge, which represent the change situation of the ticket inventory of the traffic shift corresponding to the historical record of the traffic shift edge, such as the historical situation of the ticket inventory of the corresponding traffic shift changing over time, and are used to help the model understand the change trend of the ticket inventory of the corresponding traffic shift.

[0188] Specifically, as combined with Figure 5B shown, the basic features, time features, and inventory features of the upstream and downstream stations associated with the traffic shift edge at the current moment are respectively processed through the Embedding layer of the prediction model to obtain corresponding vector representations; among them, the Embedding layer is used to convert the input into a low-dimensional vector representation;

[0189] The inventory sequence features on the transportation shift side are processed by the gated recurrent unit (GRU) of the prediction model to capture the temporal dependencies in the inventory sequence features on the transportation shift side; that is, the inventory sequence features on the transportation shift side, as time series data, can capture the temporal dependencies in the time series data through the gated recurrent unit;

[0190] Furthermore, the concatenation layer (Concat Layer) of the prediction model combines and concatenates the vector representation output by the embedding layer and the temporal dependencies output by the gated recurrent unit into a unified feature vector for subsequent processing;

[0191] The multi-layer perceptron layer (MLP Layer) of the prediction model is composed of at least multiple fully connected layers for multi-layer non-linear transformation. Thus, the unified feature vector output by the concatenation layer is processed through the multi-layer perceptron layer for multi-layer non-linear transformation to output the prediction result of whether there is ticket inventory on the transportation shift side;

[0192] The loss function is the objective function for optimizing the prediction model. The prediction model optimizes the model parameters by minimizing the value of the loss function. Specifically, the cross-entropy loss can be used as the loss function. The cross-entropy loss is used for classification problems, especially in dealing with binary classification problems. The cross-entropy loss optimizes the model by measuring the gap between the model prediction result and the actual label. The smaller the cross-entropy loss, the closer the model prediction result is to the actual label. In the binary classification prediction of the ticket inventory on the transportation shift side (i.e., predicting whether there is ticket inventory at a future moment on the transportation shift side or not), the cross-entropy loss is used to measure the difference between the prediction result of the ticket inventory on the transportation shift side output by the prediction model and the actual label. The actual label can be obtained by marking the historical data of the transportation shift corresponding to the transportation shift side. For example, based on the historical data of the transportation shift, mark whether there is actually ticket inventory at the next historical moment for any historical moment on the transportation shift side.

[0193] After training the prediction model, the embodiments of the present application can use the prediction model to predict the ticket inventory on the transportation shift side. Specifically, the embodiments of the present application can determine the prediction input data for the transportation shift side. The prediction input data can correspond to the feature data used for training, such as the basic features, time features, inventory sequence features, and inventory features of the upstream and downstream stations associated with the transportation shift side at the current moment. Thus, the prediction input data for the transportation shift side is input into the prediction model, and the prediction model can output the prediction result of the ticket inventory on the transportation shift side at a future moment.

[0194] In other alternative implementations, embodiments of the present application may also use a graph neural network to predict the ticket volume inventory for the edges of transportation schedules. For example, in the prediction of the ticket volume inventory for the edges of transportation schedules, space (the relationships and influences between transportation stations) and time (the variation of the ticket volume inventory for the edges of transportation schedules over time) are two key factors. Therefore, a spatio-temporal graph neural network can be used in combination to predict the ticket volume inventory for the edges of transportation schedules at future time points.

[0195] Exemplarily, Figure 5C An application example diagram of the graph neural network is exemplarily shown, such as Figure 5C As shown, the input sequence (Input Series) can be time series data representing the historical data of the edges of transportation schedules, such as the ticket volume inventory information for the edges of transportation schedules at different time points; the target sequence (Target Series) is the ticket volume inventory result that is expected to be predicted for the edges of transportation schedules, such as the ticket volume inventory result for the edges of transportation schedules at the next moment that is expected to be predicted. Specifically, it can be whether there is a ticket volume inventory or not for the transportation schedule at the next moment that is expected to be predicted.

[0196] The spatio-temporal graph neural network (Spatial-Temporal GNN) is used to process the input sequence and combine the input sequence with the graph data (i.e., the graph data constructed in the embodiments of the present application), so as to combine the structural information of the graph with the input sequence to consider the relationships of space and time; the prediction layer, such as a multi-layer perceptron layer, is used to predict the ticket volume inventory for the edges of transportation schedules at future moments based on the output of the spatio-temporal graph neural network, so as to output the prediction result of the ticket volume inventory for the edges of transportation schedules; furthermore, the difference between the prediction result of the ticket volume inventory of the prediction layer and the target sequence is compared, and the forecasting loss (prediction loss function) is used to measure the prediction accuracy and optimize the parameters.

[0197] Embodiments of the present application support using a graph neural network model to combine the relationships of space and time in the prediction of the ticket volume inventory for the edges of transportation schedules, so as to consider the historical data of the edges of transportation schedules and the mutual influences of other edges and nodes associated with the edges of transportation schedules in the graph data, and improve the prediction accuracy.

[0198] Step S520: For the set of transfer point plans between any two transportation stations, based on the prediction results of the ticket volume inventory for the edges of transportation schedules associated with each transfer point, determine the transfer points to be excluded and the transfer points to be retained, so as to obtain the set of retained transfer points between any two transportation stations.

[0199] For any two transportation stations, after obtaining the ticket quantity inventory prediction results of each transportation schedule edge in the path planning set, the embodiments of the present application can perform node pruning according to the ticket quantity inventory prediction results. Specifically, for any two transportation stations, the operation of node pruning can be concentrated on the transfer points in the transfer point planning set. For example, if the ticket quantity inventory of the transportation schedule edges associated with a transfer point planned between two transportation stations is insufficient in the corresponding path planning set, then the transfer point and the transportation schedule edges associated with the transfer point will be excluded, so as to avoid recommending paths with insufficient ticket quantity inventory to users.

[0200] In an alternative implementation, for each transfer point in the transfer point planning set between any two transportation stations, the embodiments of the present application can determine the transportation schedule edges associated with the transfer point (such as the transportation schedule edges connected by the transfer point in the path planning set of the two transportation stations), so as to check the validity of the transfer point based on the ticket quantity inventory prediction results of the transportation schedule edges associated with the transfer point, and determine whether the transfer point is retained.

[0201] As an example of an alternative implementation, taking the ticket quantity inventory prediction result as whether there is ticket quantity inventory for the transportation schedule edge, the embodiments of the present application can define a future time range, such as the next 30 minutes, the next 1 hour, etc. This future time range is used to predict the future ticket quantity inventory status within a certain period of time. Thus, for any transfer point in the transfer point planning set between any two transportation stations, the embodiments of the present application can determine the number of edges of the transportation schedule edges associated with the transfer point that have ticket quantity inventory within the future time range based on the ticket quantity inventory prediction results of the transportation schedule edges associated with the transfer point within the future time range. Among them, the future time range is composed of multiple future moments. The ticket quantity inventory prediction results of the transportation schedule edges associated with the transfer point at each future moment within the future time range can be analyzed, so as to determine the transportation schedule edges that have ticket quantity inventory within the future time range from the transportation schedule edges associated with the transfer point, and obtain the number of edges of the transportation schedule edges associated with the transfer point that have ticket quantity inventory within the future time range. Then, the above number of edges is compared with a threshold to determine whether the above number of edges meets the threshold, such as whether it is not less than the threshold. If the above number of edges meets the threshold, the transfer point can be retained. If the above number of edges does not meet the threshold, the transfer point and its associated transportation schedule edges need to be excluded. Through the above method, the retained transfer points between any two transportation stations can be determined, and a transfer point retention set between any two transportation stations can be formed.

[0202] In the embodiment of the present application, by performing the above-mentioned node pruning operation on the set of transfer point plans between any two transportation stations, the transfer points to be retained and the transfer points to be removed between any two transportation stations can be determined. Thus, the transfer points retained between any two transportation stations form a set of retained transfer points between any two transportation stations, which is used for searching for the multi-hop paths to be recommended between the user's destination and the user's departure place in the subsequent process.

[0203] It should be noted that Figure 5A the process of determining the set of retained transfer points between any two transportation stations shown above can be executed regularly. For example Figure 5A the process shown is not executed every time the user requests a travel plan, but is executed regularly as a scheduled task. Exemplarily, the travel service platform can periodically execute Figure 5A the process shown to regularly update the set of retained transfer points between any two transportation stations through the node pruning operation.

[0204] It should be noted that for the travel service platform, the offline processing in the offline route planning stage and the like refers to the travel service platform performing preprocessing and calculations, and the offline processing is not directly oriented to users; the online processing such as the online route service refers to the travel service platform performing processing facing users.

[0205] As an optional implementation Figure 6 an exemplary flowchart of the online route service provided by the embodiment of the present application is shown Figure 6 the process shown can be regarded as the travel service platform performing real-time response processing based on the user's request to search for the single-hop paths and multi-hop paths to be recommended for the user. Referring to Figure 6 , this process may include the following steps.

[0206] Step S610, determine the user's departure place and the user's destination.

[0207] In an alternative implementation, the user can input information such as the user's departure location and the user's destination through the page provided by the travel service platform, so that the travel service platform can determine the given departure location and destination of the user. The given departure location of the user is the user's departure location, and the given destination of the user is the user's destination. For example, when the user uses the travel service platform to search for transportation tickets such as air tickets and train tickets, the user can input information such as the user's departure location and the user's destination on the search page; for another example, when the user requests the travel service platform to provide a travel plan, the user can input the user's departure location and the user's destination through the page provided by the travel service platform, so that the travel service platform can output a travel plan (one-way path and multi-way path) with price library data from the user's departure location to the user's destination. The travel plan is not limited to a single transportation mode and can be a combination of multiple transportation modes. In an alternative implementation, the embodiments of the present application support the user to specify one or more user departure locations and support the user to specify one or more user destinations.

[0208] Step S620: Search the graph data according to the user's departure location and the user's destination, and determine the one-way path to be recommended from the user's departure location to the user's destination.

[0209] For the relevant content of the graph data, reference can be made to the previous description and will not be elaborated here. Based on the pre-constructed graph data, in step S620, a path search is performed in the graph data to determine the one-way path to be recommended between the user's departure location and the user's destination. The path search algorithm used for the path search can include, but is not limited to, depth-first search algorithm, breadth-first search algorithm, heuristic search algorithm, etc. By way of example, the embodiments of the present application can determine the node corresponding to the user's departure location in the graph data (abbreviated as the user departure location node), and the node corresponding to the user's destination in the graph data (abbreviated as the user destination node), and then search in the graph data through the path search algorithm to connect the user departure location node and the user destination node with transportation schedule edges to obtain the one-way path to be recommended. That is to say, the one-way path to be recommended starts from the user departure location node, passes through the searched transportation schedule edges connected to the user destination node, and reaches the user destination node.

[0210] Further, when searching for a one-way path to be recommended, search constraint conditions for transportation schedule edges can be introduced. The search constraint conditions for transportation schedule edges should at least include a constraint on ticket inventory, so as to constrain the ticket inventory data (included in edge attributes) of transportation schedule edges to meet the ticket inventory requirements. For example, the ticket inventory value corresponding to the ticket inventory data of a transportation schedule edge meets the ticket inventory value requirements, or the ticket inventory of the transportation schedule edge is not a situation of no ticket inventory. Through the constraint on ticket inventory, the embodiments of the present application can ensure that the one-way path to be recommended searched meets the ticket inventory requirements and can meet the travel needs of users. Further, when searching for a one-way path to be recommended, the search constraint conditions for transportation schedule edges can also include constraints such as price, update timestamp of price library data, transportation mode, transportation schedule time, etc.

[0211] Exemplarily, the search constraint conditions for transportation schedule edges used when searching for a one-way path to be recommended include but are not limited to:

[0212] Transportation mode, which constrains the type of transportation vehicle of the searched transportation schedule edge, such as train, airplane, etc.;

[0213] Transportation schedule time, which constrains the departure time and / or arrival time of the searched transportation schedule edge;

[0214] Price, which constrains the price of the searched transportation schedule edge. The price data of the transportation schedule edge is included in the edge attributes and is dynamically updated;

[0215] Ticket inventory, which constrains that the ticket inventory data of the transportation schedule edge should meet the ticket inventory requirements. The ticket inventory data of the transportation schedule edge is included in the edge attributes and is dynamically updated;

[0216] Update timestamp of price library data, which constrains the update timestamp of the price library data of the transportation schedule edge. For example, the time difference between the update timestamp of the price library data and the current time is within a predetermined time difference range to ensure the timeliness of the ticket inventory and price in the edge attributes of the transportation schedule edge.

[0217] Further, when searching for a one-way path to be recommended, the arrival node of the searched transportation schedule edge is constrained to be the user destination node.

[0218] Step S630, define the transfer point search constraint conditions at least based on the set of transfer points reserved between the user departure place and the user destination. Based on the transfer point search constraint conditions, search the graph data to determine the multi-way path to be recommended from the user departure place to the user destination.

[0219] Step S630 determines the multi-way path to be recommended between the user departure place and the user destination by performing path search in the graph data. For example, search for a path with two or more legs to be recommended, or search for a path with two legs and a path with two or more legs to be recommended.

[0220] In an alternative implementation, if a two-leg path between transportation stations is considered in the offline path planning phase and the transfer points of the two-leg path are considered in the online path pruning, the online path service can consider searching for the to-be-recommended two-leg path from the user's departure location to the user's destination through the set of reserved transfer points between the user's departure location and the user's destination.

[0221] In an alternative implementation, if only paths with more than two legs between transportation stations are considered in the offline path planning phase and only the transfer points of paths with more than two legs are considered in the online path pruning, the online path service can consider searching for the to-be-recommended paths with more than two legs from the user's departure location to the user's destination through the set of reserved transfer points between the user's departure location and the user's destination. At this time, the to-be-recommended two-leg path from the user's departure location to the user's destination can perform path search relying on the characteristics of the graph data itself, rather than relying on the set of reserved transfer points between the user's departure location and the user's destination.

[0222] That is to say, for paths with more than two legs in the to-be-recommended multi-leg paths, the set of reserved transfer points between the user's departure location and the user's destination needs to be used for search, while whether the two-leg path uses the set of reserved transfer points for search can depend on whether the two-leg path is considered in the offline path planning phase and the online path pruning.

[0223] In an alternative implementation, the path search algorithm used to search for the to-be-recommended multi-leg paths can include, but is not limited to, depth-first search algorithm, breadth-first search algorithm, heuristic search algorithm, etc. When searching for the to-be-recommended multi-leg path between the user's departure location and the user's destination, the embodiments of the present application introduce a set of reserved transfer points between the user's departure location and the user's destination that is updated regularly. Specifically, based on the set of reserved transfer points between any two transportation stations that is updated regularly, the set of reserved transfer points between the user's departure location node and the user's destination node can be obtained, that is, the set of reserved transfer points between the user's departure location and the user's destination, which includes the reserved transfer points between the user's departure location node and the user's destination node;

[0224] Furthermore, based on the set of reserved transfer points between the user's departure location and the user's destination, the transfer point search constraint conditions for multi-leg path search are defined, and then a multi-leg path (such as paths with more than two legs of various leg counts, or two-leg paths and paths with more than two legs of various leg counts) that starts from the user's departure location node, passes through one or more transfer points that meet the transfer point search constraint conditions, and finally reaches the user's destination node can be searched in the graph data, so as to obtain the to-be-recommended multi-leg path from the user's departure location to the user's destination.

[0225] Further, when performing multi - leg path search, the transfer point search constraint conditions can be included in the search constraint conditions of transportation schedule edges and transfer edges. Specifically, the search constraint conditions of transportation schedule edges are used to constrain the searched transportation schedule edges. When searching for a multi - leg path to be recommended, the transfer point search constraint conditions are included in the search constraint conditions of non - last - leg transportation schedule edges, and are used to constrain that the arrival nodes of non - last - leg transportation schedule edges belong to the reserved transfer points. For example, for any number of legs of a multi - leg path, the transfer point search constraint conditions are used to constrain that the arrival nodes of non - last - leg transportation schedule edges belong to the reserved transfer points, where the arrival node of the last - leg transportation schedule edge should be the user's destination node. The search constraint conditions of transfer edges are used to constrain the searched transfer edges. In the search constraint conditions of transfer edges, the transfer point search constraint conditions are used to constrain that the arrival nodes of transfer edges belong to the reserved transfer points.

[0226] Further, when searching for a multi - leg path to be recommended, in addition to including the reserved transfer points, the search constraint conditions of transportation schedule edges can at least include the constraint on the ticket inventory of transportation schedule edges, so as to constrain the ticket inventory of the searched transportation schedule edges, thereby ensuring that the searched multi - leg path to be recommended meets the ticket inventory requirements and can meet the user's travel needs. Further, when searching for a multi - leg path to be recommended, the search constraint conditions of transportation schedule edges can also include constraint conditions such as price, the update timestamp of price database data, transportation mode, transportation schedule time, etc.

[0227] Exemplarily, the search constraint conditions of transportation schedule edges are as follows:

[0228] Transportation mode, which constrains the type of transportation means of the searched transportation schedule edge, such as train, plane, etc.;

[0229] Transportation schedule time, which constrains the departure time and / or arrival time of the searched transportation schedule edge;

[0230] Arrival node, which constrains the arrival node of the searched transportation schedule edge. When the arrival node of the transportation schedule edge is not the destination node, the node corresponding to the transfer of the arrival node of the transportation schedule edge is defined by the transfer point search constraint conditions. Specifically, the arrival nodes of non - last - leg transportation schedule edges (i.e., the transfer points involved in the multi - leg path to be recommended) are determined by the reserved set of transfer points between the user's departure place and the user's destination;

[0231] Price, which constrains the price of the searched transportation schedule edge, and the price data is included in the edge attributes of the transportation schedule edge;

[0232] Ticket quantity inventory, which restricts the ticket quantity inventory of the edges of the searched transportation schedules. Specifically, the ticket quantity inventory data in the edge attributes of the searched transportation schedule edges should meet the ticket quantity inventory requirements. For example, the ticket quantity inventory value corresponding to the ticket quantity inventory data of the transportation schedule edge meets the ticket quantity inventory value requirements, or the ticket quantity inventory of the transportation schedule edge is not a situation of no ticket quantity inventory;

[0233] Update timestamp of price database data, which restricts the update timestamp of the price database data of the transportation schedule edge. For example, the time difference between the update timestamp of the price database data and the current time is within a predetermined time difference range to ensure the timeliness of the ticket quantity inventory and price in the edge attributes of the transportation schedule edge.

[0234] For example, the search constraint conditions for transfer edges are as follows:

[0235] Transfer time consumption, which restricts the time consumption of the searched transfer edge;

[0236] Arrival node, which restricts the arrival node of the searched transfer edge, corresponding to the node of the transfer. It is defined by the search constraint conditions of the transfer point; specifically, the arrival node of the transfer edge (i.e., the transfer point involved in the multi-leg path to be recommended) is determined by the reserved set of transfer points between the user's departure location and the user's destination.

[0237] In an optional implementation example, taking the case where the reserved set of transfer points is applicable to searching for a two-leg path to be recommended as an example, the embodiments of the present application can search in the graph data for two-leg transportation schedule edges corresponding to the search constraint conditions of the transportation schedule edges through a path search algorithm; or, the embodiments of the present application can search in the graph data for two-leg transportation schedule edges corresponding to the search constraint conditions of the transportation schedule edges and transfer edges corresponding to the search constraint conditions of the transfer edges through a path search algorithm, and the two-leg transportation schedule edges are connected by the transfer edge.

[0238] It should be noted that there can be two situations for the two-leg path between the user's departure location and the user's destination:

[0239] The first situation is that the transportation stations of the two-leg transportation schedules from the user's departure location to the user's destination are continuous, that is, the transportation stations of the first-leg transportation schedule edge and the second-leg transportation schedule edge are continuous. For example, the arrival node of the first-leg transportation schedule edge is the departure node of the second-leg transportation schedule edge;

[0240] The second situation is that the transportation stations of the two-leg transportation schedules from the user's departure location to the user's destination are not continuous and there is a transfer edge. For example, the arrival node of the first-leg transportation schedule edge is the departure node of the transfer edge, and the arrival node of the transfer edge is the departure node of the second-leg transportation schedule edge.

[0241] As an optional implementation example, taking the second situation of the above two-leg path as an example, Figure 7Exemplarily shown is a flowchart for determining a two-leg path to be recommended provided by an embodiment of the present application. Referring to Figure 7 , the process may include the following steps.

[0242] Step S710: At least with respect to the set of reserved transfer points between the user's departure location and the user's destination, define the search constraint conditions for the first-leg transportation schedule edge, and in the graph data, starting from the user's departure location node, based on the search constraint conditions for the first-leg transportation schedule edge, search for the first-leg transportation schedule edge.

[0243] In this implementation example, the first-leg transportation schedule edge searched connects the user's departure location node and the transfer node, and the transfer node belongs to the set of reserved transfer points between the user's departure location and the user's destination.

[0244] Exemplarily, the search constraint conditions for the first-leg transportation schedule edge are such as: transportation mode, which restricts the type of transportation vehicle for the first-leg transportation schedule edge; transportation schedule time, which restricts the departure time and / or arrival time of the first-leg transportation schedule edge; arrival node, which restricts the arrival node of the first-leg transportation schedule edge, and the arrival node belongs to the transfer node of the two-leg path and is determined by the reserved transfer points; price, which restricts the price of the first-leg transportation schedule edge; ticket inventory, which restricts the ticket inventory of the first-leg transportation schedule edge; update timestamp of the price database data, which restricts the update timestamp of the price database data of the first-leg transportation schedule edge.

[0245] Step S720: At least with respect to the set of reserved transfer points between the user's departure location and the user's destination, define the search constraint conditions for the transfer edge, and in the graph data, starting from the arrival node of the first-leg transportation schedule edge, based on the search constraint conditions for the transfer edge, search for the transfer edge.

[0246] In this implementation example, the transfer edge searched represents the transfer process from the arrival node of the first-leg transportation schedule edge to the departure node of the second-leg transportation schedule edge, that is, from the arrival node of the first-leg transportation schedule edge, through the transfer edge, to the departure node of the second-leg transportation schedule edge. Exemplarily, the search constraint conditions for the transfer edge are such as: transfer time consumption, which restricts the time consumption from the arrival node of the first-leg transportation schedule edge to the departure node of the second-leg transportation schedule edge; arrival node, which restricts the arrival node of the transfer edge, and the arrival node of the transfer edge is also the departure node of the second-leg transportation schedule edge and belongs to the transfer node of the two-leg path and is determined by the reserved transfer points.

[0247] Step S730: In the graph data, starting from the arrival node of the transfer edge, based on the search constraint conditions for the second-leg transportation schedule edge, search for the second-leg transportation schedule edge, and the arrival node of the second-leg transportation schedule edge is the user's destination node.

[0248] In this implementation example, the second-stage transportation flight edge connects the arrival node of the transfer edge and the user destination node, that is, the arrival node of the second-stage transportation flight edge is the user destination node. Therefore, the embodiment of the present application can start from the arrival node of the transfer edge and reach the user destination node through the second-stage transportation flight edge. For example, the search constraint conditions for the second-stage transportation flight edge are as follows: restricting the transportation mode of the second-stage transportation flight edge, the transportation flight time, the arrival node (the arrival node of the second-stage transportation flight edge is restricted to the user destination node), price, ticket inventory, the update timestamp of the price database data, etc.

[0249] Step S740: Based on the searched first-stage transportation flight edge, transfer edge, and second-stage transportation flight edge, form a two-stage path to be recommended from the user departure place to the user destination.

[0250] In this implementation example, the embodiment of the present application defines the user departure place node and the user destination node, and gradually searches in the graph data for the first-stage transportation flight edge that meets the search constraint conditions of the first-stage transportation flight edge, the transfer edge that meets the search constraint conditions of the transfer edge, and the second-stage transportation flight edge that meets the search constraint conditions of the second-stage transportation flight edge. And the transfer points involved in the two-stage path are determined by the retained set of transfer points between the user departure place and the user destination. Thus, a two-stage path to be recommended is formed, starting from the user departure place node, passing through two-stage transportation flights and intermediate transfers, and finally reaching the user destination node. And there is ticket inventory for the two-stage path to be recommended, thus meeting the user travel demand.

[0251] The search for a two-stage or more path to be recommended can be referred to in the same way. That is, in the case of defining the user departure place node and the user destination node, gradually search for the nodes passed by the two-stage or more path, and the passed nodes meet the transfer point search constraint conditions (determined by the retained set of transfer points between the user departure place and the user destination). Thus, finally, a two-stage or more path to be recommended with ticket inventory is searched. The specific content can be referred to in the same way as the previous description and will not be elaborated here.

[0252] That is to say, in the graph data, the multi-stage path to be recommended starts from the user departure place node corresponding to the user departure place, passes through the searched multiple transportation flight edges, or passes through the searched multiple transportation flight edges and at least one transfer edge, and reaches the user destination node corresponding to the user destination. Among them, the number of the searched transportation flight edges depends on the specific number of stages of the multi-stage path. And the transportation flight edges are searched based on the search constraint conditions of the transportation flight edges, and the transfer edges are searched based on the search constraint conditions of the transfer edges. The transfer point search constraint conditions are included in the search constraint conditions of the transportation flight edges and are used to restrict the arrival node of the transportation flight edge. The transfer point search constraint conditions are included in the search constraint conditions of the transfer edges and are used to restrict the arrival node of the transfer edge.

[0253] In a further optional implementation, there may be multiple multi-hop paths with various numbers of hops from the user's departure location to the user's destination. For example, when searching for two-hop paths, starting from the user's departure location node, different first-hop transportation schedule edges, different transfer edges, and different second-hop transportation schedule edges that meet the transfer point search constraint conditions may be searched in the graph data, resulting in multiple two-hop paths being searched; for any multi-hop path with a certain number of hops, embodiments of the present application can sort the searched multi-hop paths by path duration and limit the number of multi-hop paths of each number of hops to be recommended. Thus, for any multi-hop path with a certain number of hops, the multi-hop path with the shortest searched path duration corresponding to the number of paths to be recommended is used as the multi-hop path to be recommended; for example, sort the searched two-hop paths by path duration and limit the number of two-hop paths to be recommended, so that the two-hop path with the shortest searched path duration corresponding to the number of paths to be recommended is used as the two-hop path to be recommended from the user's departure location to the user's destination.

[0254] In a further optional implementation, when embodiments of the present application search for the one-hop path to be recommended and multi-hop paths with various numbers of hops to be recommended, they can be implemented based on the query language of the graph data and the integrated path search algorithm. The query language of the graph data, such as ISOGQL (International Standard Open Graph Query Language), is used to retrieve information from the graph data structure; by way of example, the query language of the graph data may include transfer point search constraint conditions to constrain that the nodes passed through during the multi-hop path search process belong to the transfer point retention set between the user's departure location and the user's destination. Specifically, embodiments of the present application can construct path search requests for various numbers of hops through the query language of the graph data according to different path search requirements, thereby obtaining path search results for various numbers of hops; for example, according to the path search requirements for various numbers of hops, set search constraint conditions corresponding to paths of various numbers of hops (such as constraining the transportation mode, departure and arrival times of transportation schedules, price, ticket inventory, update timestamp of price database data, transfer points of multi-hop paths, etc.), thereby forming path search requests for various numbers of hops, and then based on the graph data, execute the path search requests for various numbers of hops to obtain path search results for various numbers of hops, that is, the one-hop path to be recommended and the multi-hop paths to be recommended.

[0255] In an optional implementation example, for the search of a one-way path, the path search request may focus on the directly connected transportation schedule edges from the user's departure location to the user's destination without involving transfers; for a two-way path, the path search request may limit the path search to the reserved set of transfer points between the user's departure location and the user's destination, and may further limit the ticket inventory, price, transportation mode, time information for each leg, etc.; for paths with more than two legs, such as three legs or more, the path search request involves constraints for multiple transfers (the transfer points are the reserved transfer points between the user's departure location and the user's destination), and further may involve constraints such as ticket inventory, price, transportation mode, time information for each leg, etc.

[0256] Back to Figure 6 As shown, in step S640, based on the to-be-recommended one-way path and the to-be-recommended multi-way paths, multiple to-be-recommended paths are formed.

[0257] After determining the to-be-recommended one-way paths and the to-be-recommended multi-way paths from the user's departure location to the user's destination, the embodiments of the present application may aggregate the to-be-recommended one-way paths and the to-be-recommended multi-way paths into a to-be-recommended path set, so that the to-be-recommended path set includes multiple to-be-recommended paths (such as one-way, two-way, three-way, etc. paths of various leg numbers) for subsequent processing in the personalized output stage of the travel plan mixing.

[0258] It should be further noted that Figure 5A the process shown is executed regularly by the travel service platform, Figure 6 while the process shown needs to respond to the user's request in real time by the travel service platform, that is, when the user gives the user's destination and the user's departure location, it needs to respond in a timely manner; thus, Figure 5A the process shown and Figure 6 the process shown can be executed asynchronously.

[0259] The personalized output stage 240 of the travel plan mixing is used to sort the multiple to-be-recommended paths according to the user's preferences, and then the sorted multiple paths are used as the recommended results of the travel plan and recommended to the user.

[0260] In an optional implementation, the embodiments of the present application may use a recommendation scoring model to score each of the to-be-recommended paths based on the user's preferences to obtain the sorting scores of the to-be-recommended paths; thus, according to the sorting scores of the to-be-recommended paths, the multiple to-be-recommended paths are sorted in descending order to obtain the sorted multiple paths as the recommended results of the travel plan and recommended to the user. For example, the recommendation scoring model can be an LR (Logistic Regression) model, a DIN (Deep Interest Network) model, etc.

[0261] As an optional implementation, Figure 8A An exemplary flowchart showing the sorting of multiple paths to be recommended provided by the embodiments of the present application is shown. Figure 8B An exemplary processing example diagram of the recommendation scoring model is shown. In combination with Figure 8A and Figure 8B as shown, the process of sorting multiple paths to be recommended may include the following steps.

[0262] Step S810, obtain the user's basic features, user behavior features, user's search context features, and features of the path to be recommended.

[0263] In an optional implementation, the input data of the recommendation scoring model includes, but is not limited to:

[0264] User's basic features, such as basic user information like the user's gender, age, etc.;

[0265] User's search context features, such as the departure place, destination, departure time, departure period, etc. when the user searches for tickets on the travel service platform;

[0266] User behavior features are divided into the user's historical behavior features and real-time behavior features. The user's historical behavior features, such as the historical purchase sequence formed by the user's historical ticket purchase information on the travel service platform, are used to analyze the user's preferences for the price, travel time, etc. of transportation tickets; the user's real-time behavior features, such as the real-time click behavior information on the page provided by the travel service platform, are used to analyze the user's real-time preferences;

[0267] Features of the path to be recommended, that is, the features of the path to be recommended that the recommendation scoring model currently needs to score; such as the departure time, arrival time, duration, price, transportation mode, etc. of each leg of the path to be recommended, such as the first leg, the second leg, etc.; further, if the path to be recommended is a multi-leg path, the features of the path to be recommended may include transfer information, such as transfer type information, and the transfer type information is, for example, off-site transfer (i.e., transfer at different transportation stations, involving transfer edges between different transportation stations), or on-site transfer (i.e., taking different transportation schedules at the same transportation station for transfer).

[0268] Step S820, based on the user behavior features and the features of the path to be recommended, determine the user's preference information for various travel preference factors for the path to be recommended.

[0269] Embodiments of the present application can set various travel preference factors to represent the user's travel preferences. The various travel preference factors include, but are not limited to, price, travel time, departure time, number of transfers, arrival time, transfer destination, etc. Thus, embodiments of the present application can determine the preference information of the user for the to-be-recommended path in various travel preference factors based on the user behavior characteristics and the characteristics of the to-be-recommended path. For example, the user's preference information for price, travel time, departure time, number of transfers, arrival time, transfer destination, etc. for the to-be-recommended path, to represent the degree to which the to-be-recommended path is preferred by the user in various travel preference factors.

[0270] In an alternative implementation, the recommendation scoring model can set attention modules corresponding to various travel preference factors, so that different attention modules can focus on the preference information of the user for the to-be-recommended path in different travel preference factors. By way of example, taking the three travel preference factors of price, travel time, and departure time as an example, as Figure 8B shown, the recommendation scoring model is provided with three attention modules, namely:

[0271] The price attention module focuses on the user's preference for price, and thus determines the user's preference for price for the to-be-recommended path based on the user behavior characteristics and the characteristics of the to-be-recommended path;

[0272] The travel time attention module focuses on the user's preference for travel time, and thus determines the user's preference for travel time for the to-be-recommended path based on the user behavior characteristics and the characteristics of the to-be-recommended path;

[0273] The departure time attention module focuses on the user's preference for departure time, and thus determines the user's preference for departure time for the to-be-recommended path based on the user behavior characteristics and the characteristics of the to-be-recommended path.

[0274] It should be noted that the specific forms of the various travel preference factors can be set according to the actual situation and are not limited to the above examples.

[0275] Step S830, determine the monotonicity information of the to-be-recommended path in terms of travel time and price based on the characteristics of the to-be-recommended path.

[0276] The recommended scoring model is set with a monotonic network module, which can enable the recommended scoring model to focus on the monotonicity of price and time consumption. For example, the monotonicity such as the shorter the time consumption and the lower the price is set to ensure that the prediction of the recommended scoring model conforms to the user's cognition. For example, travel plans with short time and low price are more likely to be accepted by most users. Therefore, when scoring the path to be recommended, the features of the path to be recommended (such as the time consumption and price in the features of the path to be recommended) can be input into the monotonic network module for processing to obtain the monotonicity information of the path to be recommended in terms of time consumption and price.

[0277] Step S840: Concatenate the user's basic features, the user's search context features, the user's preference information for various travel preference factors for the path to be recommended, the monotonicity information, and the features of the path to be recommended to form an overall feature vector.

[0278] The recommended scoring model is set with a concatenation layer; thus, the user's basic features, the user's search context features, the outputs of each attention module (such as Figure 8B the outputs of the exemplary price attention module, time consumption attention module, and departure time attention module), the monotonicity information output by the monotonic network module, and the features of the path to be recommended can be sent to the concatenation layer for concatenation to form an overall feature vector.

[0279] Step S850: Perform multi-layer non-linear transformation on the overall feature vector to obtain the ranking score of the path to be recommended.

[0280] The recommended scoring model is set with a multi-layer perceptron layer; the overall feature vector concatenated by the concatenation layer is sent to the multi-layer perceptron layer for processing, so as to capture the relationship between the overall feature vectors through multi-layer non-linear transformation to obtain the ranking score of the path to be recommended; among them, the multi-layer perceptron layer is at least composed of multiple fully connected layers.

[0281] Furthermore, the recommended scoring model can be set with a loss function, such as cross-entropy loss. Thus, when training the recommended scoring model, the loss function is used to measure the difference between the ranking score predicted by the recommended scoring model and the actual situation to optimize the recommended scoring model.

[0282] Step S860: Based on the ranking scores of each path to be recommended, perform a descending order sorting on the multiple paths to be recommended.

[0283] In an alternative implementation, the embodiments of the present application can use the recommended scoring model to score each path to be recommended to obtain the ranking scores of each path to be recommended, and then perform a descending order sorting on the paths to be recommended according to the ranking scores to form a recommended result of travel plans and recommend it to the user.

[0284] In an alternative implementation, the travel plan recommendation method provided by the embodiments of the present application can be applicable to the intelligent travel scenario of a travel service platform. The intelligent travel scenario is used to recommend personalized travel plans for users. Users can input the user's destination and the user's departure location on the intelligent travel page provided by the travel service platform. Thus, the travel service platform can use the travel plan recommendation method provided by the embodiments of the present application to recommend the recommendation results of travel plans (such as multiple paths to be recommended sorted in descending order) for users. Specifically, the recommendation results of travel plans can be displayed on the result page of the intelligent travel page to be recommended to users. Thus, users can view and select various travel plans between the user's destination and the user's departure location, such as direct travel plans with price and ticket quantity inventory information like airplanes and trains, and multi-leg travel plans with price and ticket quantity inventory information combined with various transportation modes like airplanes and trains.

[0285] In an alternative implementation, the travel plan recommendation method provided by the embodiments of the present application can be applicable to the ticket search scenario of a travel service platform. The ticket search scenario is used to provide search results of transportation tickets such as air tickets and train tickets for users. Thus, users can input the user's destination and the user's departure location on the transportation ticket search page such as the air ticket and train ticket search page of the travel service platform. Furthermore, the travel service platform can use the travel plan recommendation method provided by the embodiments of the present application to recommend the recommendation results of travel plans (such as multiple paths to be recommended sorted in descending order) for users. Specifically, the recommendation results of travel plans can be displayed on the search result page of transportation tickets to be recommended to users.

[0286] The travel plan recommendation method provided by the embodiments of the present application combines path planning and dynamically updated price library data based on graph data, realizes online search for one-way and multi-way paths to be recommended between the user's departure place and the user's destination, improves the path search efficiency, and is convenient for maintenance. By combining offline path planning, online path services, and online path pruning, the travel service platform can support the search for multi-way paths to be recommended, especially the search for multi-way paths with more than two legs, breaking through the bottleneck limitation, so that the travel service platform can provide multi-way travel plans with a larger number of legs. The embodiments of the present application support combinations of different transportation modes. By adding corresponding nodes, transportation schedule edges, and transfer edges in the graph data, it supports the combined use of new transportation modes, reduces the development workload, and has strong scalability. The embodiments of the present application support path search and query for paths with ticket inventory between the user's departure place and the user's destination. By adding factors such as reserved transfer points, ticket inventory, price, and update timestamp of the price library data to the search constraint conditions, various factors are comprehensively considered to optimize the one-way and multi-way paths to be recommended between the user's departure place and the user's destination. In terms of path recommendation ranking, the embodiments of the present application can sort the paths to be recommended according to user preferences to ensure that the results recommended to the user meet the user's needs and preferences.

[0287] The embodiments of the present application also provide a travel plan recommendation system, which is applied to a travel service platform. The relevant content of the travel plan recommendation system described below can be mutually corresponded and referred to the content described above.

[0288] In an alternative implementation, Figure 9 An exemplary block diagram of the travel plan recommendation system provided by the embodiments of the present application is shown. The travel plan recommendation system can be applied to a travel service platform. Specifically, the travel plan recommendation system realizes the travel plan recommendation method provided by the embodiments of the present application through a modular functional architecture.

[0289] Referring to Figure 9 , the travel plan recommendation system may include:

[0290] The online path search module 910 is used to determine the user's departure location and the user's destination; according to the user's departure location and the user's destination, search the graph data to determine the one-way path to be recommended from the user's departure location to the user's destination; wherein, the graph data includes multiple nodes and the connecting edges between the nodes, the nodes represent transportation stations, the connecting edges are divided into transportation schedule edges and transfer edges, the transportation schedule edges represent the direct transportation schedules between transportation stations, the transfer edges represent the transfer situations between transportation stations that are not transportation schedules, and the transportation schedule edges have dynamically updated fare database data; and, at least define the transfer point search constraint conditions based on the set of transfer points reserved between the user's departure location and the user's destination, and based on the transfer point search constraint conditions, search the graph data to determine the multi-way path to be recommended from the user's departure location to the user's destination, and the multi-way path passes through transfer points; wherein, the set of transfer points reserved between any two transportation stations includes the transfer points reserved between any two transportation stations, and the transfer points reserved between any two transportation stations are updated regularly based on the ticket inventory situation of the transportation schedule edges associated with the transfer points; based on the one-way path to be recommended and the multi-way path to be recommended, form multiple paths to be recommended;

[0291] The sorting and recommendation module 920 is used to sort the multiple paths to be recommended according to the user's preferences, and use the sorted multiple paths as the recommended results of the travel plan.

[0292] As an optional implementation, for the travel service platform, the online path search module can be regarded as the modularization of the online path service and the online path service in the pruning stage, and the relevant content can be referred to the previous description. The sorting and recommendation module can be regarded as the modularization of the personalized output stage of the travel plan mixing.

[0293] In the optional implementation, the multi-way path to be recommended starts from the user departure node corresponding to the user's departure location, passes through multiple searched transportation schedule edges, or passes through multiple searched transportation schedule edges and at least one transfer edge, and reaches the user destination node corresponding to the user's destination; the one-way path to be recommended starts from the user departure node, passes through the searched transportation schedule edge connected to the user destination node, and reaches the user destination node; wherein, the transportation schedule edges are searched based on the search constraint conditions of the transportation schedule edges, and the transfer edges are searched based on the search constraint conditions of the transfer edges;

[0294] When searching for the multi-way path to be recommended, the transfer point search constraint conditions are included in the search constraint conditions of the transportation schedule edges of non-the last leg, and are used to constrain the arrival nodes of the transportation schedule edges of non-the last leg, and the transfer point search constraint conditions are included in the search constraint conditions of the transfer edges, and are used to constrain the arrival nodes of the transfer edges.

[0295] In an alternative implementation, the set of reserved transfer points between any two transportation stations is updated at regular intervals based on the set of path plans between any two transportation stations, the corresponding set of transfer point plans, and the ticket inventory status of the transportation schedule edges associated with the transfer points. The set of path plans and the set of transfer point plans are pre-generated based on the graph data;

[0296] Among them, for any two transportation stations, the set of path plans includes multiple multi-leg paths planned for the two transportation stations, and each planned multi-leg path includes transportation schedule edges; for any two transportation stations, the set of transfer point plans includes the transfer points passed by the planned multi-leg paths.

[0297] Furthermore, as shown in Figure 9 the travel plan recommendation system may further include:

[0298] An online path pruning module 930, which is used to predict the ticket inventory status of each transportation schedule edge in the set of path plans between any two transportation stations at future times, to obtain the ticket inventory prediction results of the transportation schedule edges; for the set of transfer point plans between any two transportation stations, based on the ticket inventory prediction results of the transportation schedule edges associated with each transfer point, determine the transfer points to be removed and the transfer points to be reserved, to obtain the set of reserved transfer points between any two transportation stations.

[0299] The online path pruning module can be regarded as the modularization of online path pruning in the online path service and pruning stage, and the relevant content can be referred to the previous description.

[0300] Furthermore, as shown in Figure 9 the travel plan recommendation system may further include:

[0301] An offline path planning module 940, which is used to generate multiple multi-leg paths between any two transportation stations based on the graph database using a path search algorithm; for each multi-leg path between any two transportation stations, evaluate the value score of the multi-leg path according to multiple path evaluation features, to obtain the value score of each multi-leg path between any two transportation stations; for any two transportation stations, determine the multi-leg paths planned between the two transportation stations according to the value scores of each multi-leg path between the two transportation stations, to form the set of path plans between any two transportation stations; and, for any two transportation stations, determine the transfer nodes passed by the multi-leg paths planned between the two transportation stations, to form the set of transfer point plans between any two transportation stations.

[0302] The offline path planning module can be regarded as the modularization of the offline path planning stage, and the relevant content can be referred to the previous description.

[0303] As an alternative implementation, the sorting and recommendation module 920 is used to sort multiple paths to be recommended according to user preferences, including:

[0304] Obtain the user's basic features, user behavior features, user's search context features, and features of the paths to be recommended; based on the user behavior features and the features of the paths to be recommended, determine the user's preference information for the paths to be recommended in various travel preference factors; based on the features of the paths to be recommended, determine the monotonicity information of the paths to be recommended in terms of time consumption and price; splice the user's basic features, the user's search context features, the user's preference information for the paths to be recommended in various travel preference factors, the monotonicity information, and the features of the paths to be recommended to form an overall feature vector; perform multi-layer non-linear transformation on the overall feature vector to obtain the sorting scores of the paths to be recommended; based on the sorting scores of each of the paths to be recommended, perform descending sorting on the multiple paths to be recommended.

[0305] Furthermore, as shown in Figure 9 the travel plan recommendation system may further include:

[0306] A graph data construction module 950 is used to represent each transportation station as a node in the graph data, and set node attributes associated with the transportation station for each node; based on the transportation travel relationships between transportation stations, set transportation schedule edges and transfer edges between nodes; set edge attributes for the transportation schedule edges and set edge attributes for the transfer edges; according to the price database data of the transportation schedules, use a caching mechanism to cache the edge attributes of the transportation schedule edges corresponding to the transportation schedules, and update the price storage data; wherein, the price database data of the transportation schedules is sourced from multiple price database and / or exposure data of ticket searches, and one price database records the real-time price database data of each transportation schedule of at least one transportation mode.

[0307] The graph data construction module can be regarded as the modularization of the dynamic graph data construction stage, and the relevant content can be referred to the previous description.

[0308] In a further alternative implementation, an embodiment of the present application further provides a travel server, regarded as a server or a server cluster set in the travel service platform; in an alternative implementation, the travel server may include a memory and a processor, the memory stores computer execution instructions, and the processor calls the computer execution instructions stored in the memory to execute the travel plan recommendation method provided by the embodiment of the present application.

[0309] In a further alternative implementation, an embodiment of the present application further provides a storage medium, the storage medium stores computer execution instructions, and when the computer execution instructions are executed (such as when the computer execution instructions are executed by a processor), the travel plan recommendation method provided by the embodiment of the present application is implemented.

[0310] In a further alternative implementation, an embodiment of the present application further provides a computer program product, including computer-executable instructions, which, when executed (for example, when the computer-executable instructions are executed by a processor), implement the travel plan recommendation method provided by the embodiments of the present application.

[0311] The above text describes multiple embodiment solutions provided by the embodiments of the present application. The various alternative ways described in each embodiment solution can be combined and cross-referenced with each other without conflict, so as to extend a variety of possible embodiment solutions, all of which can be considered as the embodiment solutions disclosed and made public by the embodiments of the present application.

[0312] Although the embodiments of the present application are disclosed as above, the present application is not limited thereto. Any person skilled in the art can make various changes and modifications without departing from the spirit and scope of the present application. Therefore, the protection scope of the present application should be subject to the scope defined by the claims.

Claims

1. A travel plan recommendation method, characterized in that, Applied to a travel service platform, the method includes: Determine the user's departure location and the user's destination; According to the user's departure location and the user's destination, search the graph data to determine the one-way path to be recommended from the user's departure location to the user's destination; wherein, the graph data includes multiple nodes and the connecting edges between the nodes, the nodes represent transportation stations, the connecting edges are divided into transportation schedule edges and transfer edges, the transportation schedule edges represent the direct transportation schedules between transportation stations, the transfer edges represent the transfer situations between transportation stations that are not transportation schedules, and the transportation schedule edges have dynamically updated fare data; And, at least define the transfer point search constraint conditions based on the set of transfer points reserved between the user's departure location and the user's destination. Based on the transfer point search constraint conditions, search the graph data to determine the multi-way path to be recommended from the user's departure location to the user's destination, and the multi-way path passes through transfer points; wherein, the set of transfer points reserved between any two transportation stations includes the transfer points reserved between any two transportation stations, and the transfer points reserved between any two transportation stations are updated regularly based on the ticket inventory situation of the transportation schedule edges associated with the transfer points. Specifically, based on the ticket inventory prediction results of the transportation schedule edges associated with the transfer points, check the validity of the transfer points to determine whether the transfer points are reserved. Moreover, the transfer point search constraint conditions defined by the set of transfer points reserved between the user's departure location and the user's destination restrict the multi-way path between the user's departure location and the user's destination to pass through the reserved transfer points and not through the unreserved transfer points; Based on the one-way path to be recommended and the multi-way path to be recommended, form multiple paths to be recommended; According to the user's preferences, sort the multiple paths to be recommended, and use the sorted multiple paths as the recommended results of the travel plan.

2. The method according to claim 1, wherein The set of transfer points reserved between any two transportation stations is updated regularly based on the path planning set between any two transportation stations, the corresponding transfer point planning set, and the ticket inventory situation of the transportation schedule edges associated with the transfer points. The path planning set and the transfer point planning set are pre-generated based on the graph data; Wherein, for any two transportation stations, the path planning set includes multiple multi-way paths planned for the two transportation stations, and each planned multi-way path includes transportation schedule edges; for any two transportation stations, the transfer point planning set includes the transfer points passed by the planned multi-way paths.

3. The method according to claim 2, characterized in that, The method further includes: For each transportation schedule edge included in the path planning set between any two transportation stations, respectively predict the ticket inventory situation of the transportation schedule edge at a future time to obtain the ticket inventory prediction results of the transportation schedule edge; For the transfer point planning set between any two transportation stations, based on the ticket inventory prediction results of the transportation schedule edges associated with each transfer point, determine the transfer points to be excluded and the transfer points to be reserved to obtain the set of transfer points reserved between any two transportation stations.

4. The method according to claim 2, wherein The method further includes: Based on the graph database, use the path search algorithm to generate multiple multi-way paths between any two transportation stations; For each multi - leg path between any two transportation stations, evaluate the value score of the multi - leg path according to multiple path evaluation features, so as to obtain the value score of each multi - leg path between any two transportation stations; For any two transportation stations, determine the planned multi - leg path between the two transportation stations according to the value scores of each multi - leg path between the two transportation stations, and form a path planning set between any two transportation stations; and, for any two transportation stations, determine the transfer nodes passed by the planned multi - leg path between the two transportation stations, and form a transfer point planning set between any two transportation stations.

5. The method according to claim 1, wherein The multi - leg path to be recommended starts from the user departure node corresponding to the user departure place, passes through multiple searched transportation schedule edges, or passes through multiple searched transportation schedule edges and at least one transfer edge, and reaches the user destination node corresponding to the user destination; the one - way path to be recommended starts from the user departure node, passes through the transportation schedule edge connected to the user destination node searched, and reaches the user destination node; Among them, the transportation schedule edges are searched based on the search constraint conditions of the transportation schedule edges, and the transfer edges are searched based on the search constraint conditions of the transfer edges; When searching for the multi - leg path to be recommended, the transfer point search constraint conditions are included in the search constraint conditions of the transportation schedule edges of non - the last leg, and are used to constrain the arrival nodes of the transportation schedule edges of non - the last leg. The transfer point search constraint conditions are included in the search constraint conditions of the transfer edges, and are used to constrain the arrival nodes of the transfer edges.

6. The method according to claim 1, wherein The sorting of the multiple paths to be recommended according to user preferences includes: Obtain user basic features, user behavior features, user search context features, and features of the paths to be recommended; Based on the user behavior features and the features of the paths to be recommended, determine the preference information of the user for the paths to be recommended in various travel preference factors; Based on the features of the paths to be recommended, determine the monotonicity information of the paths to be recommended in terms of travel time and price; Concatenate the user basic features, the user search context features, the preference information of the user for the paths to be recommended in various travel preference factors, the monotonicity information, and the features of the paths to be recommended to form an overall feature vector; Perform multi - layer non - linear transformation on the overall feature vector to obtain the sorting score of the paths to be recommended; Based on the sorting scores of each of the paths to be recommended, sort the multiple paths to be recommended in descending order.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: Represent each transportation station as a node in the graph data, and set node attributes associated with the transportation station for each node respectively; Based on the transportation travel relationship between transportation stations, set transportation schedule edges and transfer edges between nodes; Set edge attributes for the transportation schedule edges and set edge attributes for the transfer edges; According to the price database data of transportation schedules, use the caching mechanism to cache the edge attributes of the transportation schedule edges corresponding to the transportation schedules, and update the price storage data; Among them, the price database data of transportation schedules comes from multiple price database and / or exposure data of ticket searches. One price database records the real - time price database data of each transportation schedule of at least one transportation mode.

8. A travel plan recommendation system, characterized in that, Applied to a travel service platform, the system includes: An online path search module for determining a user's departure location and destination; searching graph data based on the user's departure location and destination to determine a single-way path to be recommended from the user's departure location to the destination. The graph data includes multiple nodes and connecting edges between the nodes. The nodes represent transportation stations, and the connecting edges are divided into transportation schedule edges and transfer edges. The transportation schedule edges represent direct transportation schedules between transportation stations, and the transfer edges represent transfer situations between transportation stations that are not transportation schedules. Moreover, the transportation schedule edges have dynamically updated fare data. And at least a set of reserved transfer points between the user's departure location and destination is used to define transfer point search constraints. Based on the transfer point search constraints, the graph data is searched to determine a multi-way path to be recommended from the user's departure location to the destination. The multi-way path passes through transfer points. The set of reserved transfer points between any two transportation stations includes the reserved transfer points between any two transportation stations. And the reserved transfer points between any two transportation stations are updated regularly based on the ticket inventory situation of the transportation schedule edges associated with the transfer points. Specifically, based on the predicted ticket inventory results of the transportation schedule edges associated with the transfer points, the validity of the transfer points is checked to determine whether the transfer points are reserved. Also, the transfer point search constraints defined by the set of reserved transfer points between the user's departure location and destination restrict the multi-way path between the user's departure location and destination to pass through the reserved transfer points and not through the unreserved transfer points. Based on the single-way path to be recommended and the multi-way path to be recommended, multiple paths to be recommended are formed. A sorting and recommendation module for sorting the multiple paths to be recommended according to user preferences and using the sorted multiple paths as the recommended results of the travel plan.

9. A travel server, characterized in that, It includes a memory and a processor. The memory stores computer execution instructions, and the processor calls the computer execution instructions to execute the travel plan recommendation method according to any one of claims 1-7.

10. A computer program product, characterized in that, It includes computer execution instructions. When the computer execution instructions are executed, the travel plan recommendation method according to any one of claims 1-7 is implemented.

Images