Travel scheme recommendation method and system, travel server and program

Abstract

The embodiment of the invention provides a travel scheme recommendation method and system, a travel server and a program. The method comprises the following steps: determining a user departure place and a user destination; according to the user departure place, the user destination and the search graph data, determining a one-way path to be recommended; a transfer point search constraint condition is defined at least through a transfer point reservation set between the user departure place and the user destination, a to-be-recommended multi-pass path is determined based on the transfer point search constraint condition and the search graph data, and the multi-pass path passes through a transfer point; wherein the transfer point reserved between any two traffic stations is updated regularly based on the ticket quantity inventory condition of the traffic shift edge associated with the transfer point; forming a plurality of paths to be recommended based on the one-way path to be recommended and the multi-way path to be recommended; and according to user preferences, sorting the to-be-recommended paths, and taking the sorted paths as recommendation results of the travel scheme. The embodiment of the invention can improve the performance of recommending the travel scheme by the travel service platform.

Description

Technical Field

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

[0002] Travel service platforms are online platforms that provide travel services to users, such as OTP (Online Travel Platform), OTA (Online Travel Agency) platforms, etc. Recommending travel plans to users is one of the core functions of travel service platforms. Specifically, when users provide information such as departure and destination to the travel service platform, the travel service platform can recommend travel plans from the departure point to the destination for users. In this context, how to improve the performance of travel service platforms in recommending travel plans has become a technical problem that technicians in this field need to solve urgently. 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 objectives, the embodiments of the present application provide the following technical solutions.

[0005] In a first aspect, an embodiment of the present application provides a travel plan recommendation method, which is applied to a travel service platform, and the method includes: Determine the user's departure point and the user's destination; According to the user's departure place and the user's destination, the graph data is searched to determine the one-way path to be recommended from the user's departure place to the user's destination; wherein the graph data includes a plurality of nodes and 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 direct transportation schedules between transportation stations, the transfer edges represent non-transportation schedule transfers between transportation stations, and the transportation schedule edges have dynamically updated price library data; And, at least a reserved set of transfer points between a user's departure point and a user's destination is used to define a transfer point search constraint condition, and based on the transfer point search constraint condition, graph data is searched to determine a multi-trip path to be recommended from the user's departure point to the user's destination, wherein the multi-trip path passes through the transfer point; wherein the reserved set of 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 status of the transportation schedule edge associated with the transfer point; Based on the one-way path to be recommended and the multi-way path to be recommended, forming a plurality of paths to be recommended; According to user preferences, the multiple recommended paths are sorted, and the sorted multiple paths are used as recommendation results of travel plans.

[0006] In a second aspect, an embodiment of the present application provides a travel plan recommendation system, which is applied to a travel service platform, and the system includes: The online path search module is used to determine the user's departure place and the user's destination; according to the user's departure place and the user's destination, search the graph data to determine the one-way path to be recommended from the user's departure place to the user's destination; wherein the graph data includes a plurality of nodes and 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 of non-transportation schedules between transportation stations, and the transportation schedule edges have dynamically updated price library data; and, at least based on the user's departure place and the user's destination, the graph data includes a plurality of nodes and 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, and the transfer situations of non-transportation schedules between transportation stations, and the transportation schedule edges have dynamically updated price library data. The reserved set of transfer points between destinations defines transfer point search constraints, and based on the transfer point search constraints, searches the graph data to determine a multi-trip path to be recommended from the user's departure point to the user's destination, wherein the multi-trip path passes through the transfer point; wherein the reserved set of 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 status of the transportation schedule edge associated with the transfer point; based on the one-way path to be recommended and the multi-trip path to be recommended, multiple paths to be recommended are formed; The sorting recommendation module is used to sort the multiple recommended paths according to user preferences and use the sorted multiple paths as the recommendation results of the travel plan.

[0007] In a third aspect, an embodiment of the present application provides a travel server, comprising a memory and a processor, wherein the memory stores computer-executable instructions, and the processor calls the computer-executable instructions to execute the travel plan recommendation method as described in the first aspect above.

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

[0009] The travel plan recommendation method provided in the embodiment of the present application can pre-construct graph data, represent transportation stations as nodes in the graph data, and the connecting edges between the nodes 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 the transfer situations of non-transportation schedules between transportation stations, and the transportation schedule edges have dynamically updated price library data; thus, through the graph data and the dynamically updated price library data of the transportation schedule edges, the embodiment of the present application can track the price and ticket inventory of each transportation schedule, avoiding outdated or erroneous information from being recommended to users; in terms of searching and recommending multi-trip paths, the embodiment of the present application considers a reserved set of transfer points that are updated regularly between transportation stations, and the reserved transfer points between transportation stations are based on the associated transportation schedule edges. The ticket inventory status is updated regularly, so when searching the graph data for the multi-trip path to be recommended from the user's departure point to the user's destination, the embodiment of the present application defines the transfer point search constraints based on the reserved set of transfer points between the user's departure point and the user's destination, so as to constrain the transfer points passed during the multi-trip path search, which can greatly reduce unnecessary search operations and calculations; that is, the embodiment of the present application improves the search performance of the travel service platform for multi-trip paths, especially the search performance of paths with more than two legs, by regularly updating the transfer points reserved between transportation stations; further, after searching for the one-way path to be recommended and the multi-trip path to be recommended, the embodiment of the present application combines the user's preferences to sort the paths, ensuring that the recommendation results meet the user's needs and improving the accuracy of the recommendations.

[0010] Therefore, the embodiments of the present application improve the accuracy and efficiency of recommendations on mixed one-way routes and multi-trip routes on the travel service platform through dynamically updated graph data of price library data, scheduled updates of transfer points retained between transportation stations, and personalized recommendation sorting, optimizes the quality of recommendation results, and improves the performance of the travel service platform in recommending travel plans, and can provide more flexible and accurate travel plans under the situation of diversified user needs. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0012] Figure 1 An example diagram of the stages of the recommendation process for recommending a two-way path.

[0013] Figure 2 This is an example diagram of the stages of the travel plan recommendation method provided in an embodiment of the present application.

[0014] Figure 3A A flowchart for constructing graph data provided in an embodiment of the present application.

[0015] Figure 3B This is an example diagram of the content of the node attributes.

[0016] Figure 3C This is an example diagram of the content of the edge attributes of the traffic schedule edge.

[0017] Figure 3D This is an example diagram of the content of the edge attribute of the transit edge.

[0018] Figure 3E This is an example diagram for updating price library data.

[0019] Figure 4 A flowchart of offline path planning provided in an embodiment of the present application.

[0020] Figure 5A A flowchart for determining a reserved set of transit points provided in an embodiment of the present application.

[0021] Figure 5B This is a training example graph for the prediction model.

[0022] Figure 5C This is an example diagram of the application of graph neural network.

[0023] Figure 6 A flowchart of the online path service provided in an embodiment of the present application.

[0024] Figure 7 A flowchart for determining a two-trip path to be recommended provided in an embodiment of the present application.

[0025] Fig. 8A A flowchart for sorting multiple paths to be recommended provided in an embodiment of the present application.

[0026] Figure 8B An example diagram of the processing of the recommendation scoring model.

[0027] Fig. 9 A block diagram of a travel plan recommendation system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0028] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0029] 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 used 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 must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0030] In the embodiment of the present application, a travel plan refers to a path from the departure point to the destination. The path from the departure point to the destination is divided into: a one-way path from the departure point to the destination (referred to as a one-way path), and a multi-trip path from the departure point that requires a transfer before reaching the destination (referred to as a multi-trip path). Specifically, based on whether a transfer is required from the departure point to the destination, the travel plan is divided into a direct travel plan corresponding to the one-way path and a multi-trip travel plan corresponding to the multi-trip path.

[0031] In a more specific description, a direct travel plan does not require intermediate transfers from the departure point to the destination, for example, the user takes a transportation service of a certain mode of transportation directly from the departure point to the destination, such as the user takes a flight directly from the departure point to the destination, or takes a train service directly from the departure point to the destination, etc.

[0032] It should be noted that the transportation mode referred to in the embodiments of the present application corresponds to airplanes, trains, cars (here cars refer to passenger cars), and other set means of transportation for which users need to purchase transportation tickets; transportation schedules, such as airplane flights, train schedules, and car schedules, depend on the specific transportation mode, and the embodiments of the present application do not limit this.

[0033] For multi-trip travel plans that require transfers from the departure point to the destination, users need to switch to different modes of transportation at the transfer point (the place of transfer) to complete the trip, or switch to different transportation services of the same mode of transportation to complete the trip. For example, users first take a train from the departure point to the transfer city, and then transfer to a plane from the transfer city to the destination.

[0034] The multi-trip path corresponding to the multi-trip travel plan can be composed of multiple modes of transportation and / or the same mode of transportation, that is, the modes of transportation used in the multi-trip path can be different or the same. Specifically, for a multi-trip path, a combination of multiple modes of transportation, such as a combination of different types of transportation such as trains and airplanes, cars and airplanes, and a combination of the same mode of transportation, such as a combination of multiple trains or multiple airplanes, are used.

[0035] By way of example, the following takes two-leg and three-leg multi-leg paths as examples to illustrate possible scenarios of multi-leg paths.

[0036] The transportation modes of the two routes can be the same or different. Possible combinations of transportation modes include: train <-> plane, first take the train from the departure place to the transit city, and then transfer to a plane to the destination; train <-> car, first take the train from the departure place to the transit city, and then transfer to a car to the destination; plane <-> car, first take the plane from the departure place to the transit city, and then transfer to a car to the destination; plane <-> plane, take the plane from the departure place to the transit city, and then take a plane in the transit city to the destination; train <-> train, take the train from the departure place to the transit city, and then take the train in the transit city to the destination.

[0037] Similarly, the modes of transportation for three-leg paths can be the same or different. Possible combinations of transportation modes include: train<->train<->train, train<->plane<->train, train<->plane<->plane, etc. The same applies to four-leg paths and multi-leg paths with more legs, which will not be expanded here.

[0038] Multi-trip routes can provide users with multi-trip travel plans from the departure point to the destination through a combination of the same or different modes of transportation and transfer points, thereby providing users with more flexible travel options to meet their travel needs. For example, during peak travel periods such as holidays, direct travel plans from the departure point to the destination may face a shortage of tickets or excessively high fares, and cannot meet the travel needs of a large number of users. By recommending multi-trip travel plans from the departure point to the destination to users, flexible travel options can be provided to users to meet their travel needs; for example, there may be no direct transportation between the departure point and the destination, such as no direct flights or direct trains between the departure point and the destination. At this time, it is necessary to recommend multi-trip travel plans from the departure point to the destination to users to achieve smooth travel from the departure point to the destination; for example, in the context of long-distance travel or overseas travel, direct flight fares are often high. At this time, users may choose to use multi-trip flight transfers in the hope of reducing travel costs and pursuing higher cost-effectiveness. Therefore, the travel plans recommended by the travel service platform to users include multi-trip travel plans (i.e. multi-trip routes), so users can flexibly choose appropriate travel plans based on actual conditions and budget to meet their travel needs.

[0039] A recommendation process for recommending two-way paths can be as follows Figure 1 As shown, Figure 1 An example diagram of the stages of the recommendation process for recommending a two-way path is shown, 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 .

[0040] 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 when the multi-leg path is a two-leg path. Specifically, all two-leg paths from the departure point to the destination are generated by a Cartesian product method. The Cartesian product operation combines each element in the two sets to generate all possible combinations; specifically in the path planning stage of a two-leg path, the first of the two sets represents all transportation modes or routes for the first leg, and the second set represents all transportation modes or routes for the second leg. Therefore, the Cartesian product operation can generate all possible combinations of transportation modes or routes for the two-leg path based on the above two sets.

[0041] The online real-time price library filtering stage 120 corresponds to the sorting stage of the recommendation process, which is used to filter the generated two-leg paths by price library using online query to obtain 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 users.

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

[0043] It can be seen that the above recommendation process can efficiently implement two-trip path planning and complete the sorting recommendation of two-trip paths when recommending two-trip paths. However, multi-trip paths include two-trip paths and paths with more than two trips (paths with more than two trips, such as three-trip and more than three-trip paths). The above recommendation process has obvious performance bottlenecks when processing paths with more than two trips, resulting in insufficient performance of the travel service platform in recommending travel plans, which is specifically manifested in the following aspects: There are difficulties in generating paths with more than two legs. When using 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 to choose from, the possible combinations of transportation modes for a three-legged path are N. 3 , the possible combination of transportation modes for the four-way path is N 4, so the number of paths with more than two legs increases exponentially; and with the exponential growth of the number of paths with more than two legs, the time and space complexity of offline calculations will increase rapidly, resulting in huge consumption of computing resources, so that more than two legs of paths may not be produced within the specified time, making path planning difficult to complete; Price database query requests take too much time. For routes with more than two legs, each route segment in the two legs needs to query the price database, that is, a route with more than two legs contains multiple route segments, so multiple price database query requests need to be initiated. For example, a three-leg route contains three route segments. Assuming that each route segment has M possible traffic schedules, it is necessary to initiate M price database queries for each route segment. This leads to a sharp increase in the processing complexity of the online real-time filtering price database stage. Especially when there are a large number of routes with more than two legs and a large number of route segments, the query request time may be uncontrollable, resulting in a performance bottleneck for the travel service platform. Poor reusability. The path planning stage of the above recommendation process needs to develop paths for different combinations of transportation modes. For example, if a two-way path of train and train has been developed, if a two-way path of train and car is to be added, the code and logic of the developed two-way path of train and train cannot be reused. It is necessary to redevelop the path for the new transportation mode of train and car, which increases the development and maintenance costs and makes it difficult to flexibly expand the combination of new transportation modes. In other words, different transportation modes have different path characteristics and requirements. For example, the departure time, ticket price, and transfer requirements of trains and cars are quite different. These differences make it difficult to achieve modularization and high reusability in path development, so a lot of customized development is required, resulting in poor reusability. Poor personalization. The sorting stage of the above recommendation process relies on the two dimensions of price and time to sort the two-leg routes, and lacks personalized recommendations based on user preferences. For example, some users may pay more attention to price and are willing to spend more time on transfers for cheaper fares, while some users may pay more attention to time and are willing to pay higher fares to shorten travel time. In other words, due to the lack of full consideration of users' historical behaviors and personalized needs, it is impossible to accurately meet users' preferences and lack personalized recommendation results.

[0044] Based on this, the embodiment of the present application provides an improved travel plan recommendation method, which considers dynamic graph data, integrates path planning and price library filtering, improves the performance of the travel service platform in recommending travel plans, and sorts the one-way and multi-way paths recommended to users based on user preferences, thereby recommending travel plans that meet user needs and improving the accuracy of travel plan recommendations.

[0045] As an optional implementation, Figure 2The example diagram of the stages of the travel plan recommendation method provided by the embodiment of the present application is exemplarily shown. The travel plan recommendation method provided by the embodiment of the present application can be applied to travel service platforms, such as OTP, OTA platform, etc. In an optional implementation, the travel service platform (such as OTP, OTA platform) may include a server on the service side, called a travel server (such as OTP server, OTA server), so that the travel plan recommendation method provided by the embodiment of the present application can be specifically applied to the travel server; in an optional implementation, the travel service platform (such as OTP, OTA platform) can be regarded as an online service platform formed by a server cluster formed by the travel server by setting a variety of software and hardware functional architectures.

[0046] like Figure 2 As shown, the stages of the travel plan recommendation method provided in the embodiment 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 mixed personalized output stage 240.

[0047] The dynamic graph data construction stage 210 is used to construct a graph data that describes transportation stations and the transportation travel relationship between transportation stations, and the price library data is dynamically updated to provide basic data support for subsequent stages. It should be noted that graph data organizes and stores data in a graph structure. In graph data, data is represented as a collection of nodes (Node) and edges (Edge); wherein nodes represent entities or objects, edges represent the relationship or connection between nodes, and each node can have node attributes for describing the information of the node, and each edge can have edge attributes for describing the relationship between nodes. Specifically in the travel plan recommendation scenario, the embodiment of the present application mainly uses graph data in the dynamic graph data construction stage to describe transportation stations and the transportation travel relationship between transportation stations, and uses dynamically updated price library data to describe the price and ticket inventory of transportation shifts between transportation stations.

[0048] As an optional implementation, in an embodiment of the present application, graph data may include node data and edge data; wherein the node data represents transportation stations in the transportation network (such as train stations, airports, bus stations, etc.), that is, transportation stations such as train stations, airports, bus stations in the transportation network exist as entities in the graph database, and are represented as nodes, and are provided with node attributes. For example, a transportation station is represented as a node and is provided with node attributes. The node data will not change within a certain period of time, for example, the node data will not change within a day. Therefore, relative to the dynamically updated price library data, the node data can be regarded as static data.

[0049] Edge data represents the traffic travel relationship between transportation stations, and is abstracted as connection edges between nodes (i.e., connection edges between transportation stations) in the graph database, and is set with edge attributes. In graph data, connection edges can be divided into traffic schedule edges and transfer edges; among them, traffic schedule edges represent direct traffic schedules between connected transportation stations, such as a direct traffic schedule between two transportation stations is represented as a traffic schedule edge, and is set with edge attributes; transfer edges represent non-traffic schedule transfers between connected transportation stations, and users need to transfer between transportation stations by walking, urban transportation, or taxis.

[0050] The dynamically updated price library data mainly refers to the price library data corresponding to the traffic schedule edge of the graph data, which needs to be dynamically updated. For example, the dynamically updated price library data can exist in the edge attributes of the traffic schedule edge.

[0051] As an optional implementation, Figure 3A The flowchart of constructing graph data provided by the embodiment of the present application is shown as an example, referring to Figure 3A , the process may include the following steps.

[0052] Step S310: Represent each traffic station as a node in the graph data, and set a node attribute associated with the traffic station for each node.

[0053] A node is a basic constituent element of graph data. In the embodiment of the present application, it represents a transportation station in a transportation network. The embodiment 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, so as to facilitate the processing of the relationship between different transportation stations in the graph data.

[0054] The embodiment of the present application can set node attributes for each node separately to describe the transportation station represented by the node; that is, the node attributes are detailed information or characteristics attached to the node. The embodiment of the present application can set node attributes for the node based on the detailed information or characteristics of the transportation station represented by the node, thereby setting node attributes associated with the transportation station for the node.

[0055] As an optional implementation, the node attributes of a node may include but are not limited to: The unique identifier of the node. Each node has a unique identifier in the graph data to distinguish different nodes. In an optional implementation, the unique identifier of the node can be set to the node number. The station type of a node indicates the type of transportation station represented by the node, so different station types can distinguish different types of transportation stations. For example, railway stations, airports, bus stations, etc. are different types of transportation stations, so the nodes corresponding to railway station type transportation stations, airport type transportation stations, and bus station type transportation stations have different station types. The distinction between station types helps to distinguish different modes of transportation in graph data. The basic attributes of a node are used to describe the basic information of the transportation station represented by the node, including but not limited to the station name (i.e. the name of the transportation station, such as the name of a train station, the name of an airport, etc.), the station city name (e.g. the name of the city where the transportation station is located), the station city code (i.e. the code of the city where the transportation station is located, each city can have a unique code to distinguish different cities), the station city ID (i.e. the ID of the city where the transportation station is located, each city can have a unique ID), etc.

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

[0057] For further understanding, Figure 3B An example diagram of the content of node attributes is shown for reference. In it, long is a programming language data type used to represent a 64-bit signed integer. Long can store larger values ​​than standard integers (such as int); string is a data type that represents a text string and is used to store a series of characters such as letters, numbers, and symbols.

[0058] Step S320, based on the traffic travel relationship between the transportation stations, set the traffic schedule edge and the transfer edge between the nodes; wherein the traffic schedule edge represents the direct traffic schedule between the transportation stations corresponding to the connected nodes, and the transfer edge represents the transfer situation of non-traffic schedule between the transportation stations corresponding to the connected nodes.

[0059] A connecting edge is an element in graph data that identifies the relationship between nodes. In an embodiment of the present application, a connecting edge represents the transportation travel relationship between transportation stations. Specifically, a connecting edge can be a directed edge, and it connects from one transportation station to another transportation station, indicating a transportation travel relationship from one transportation station to another transportation station, such as direct transportation routes between transportation stations or transfer situations of non-transportation routes.

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

[0061] The transfer edge represents the transfer situation between the two connected transportation stations that is not a transportation schedule. That is to say, the transfer edge represents 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 by walking, city transportation, or taking a taxi, instead of transferring by set means of transportation such as airplanes, trains, and buses.

[0062] In an optional 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 service between the two transportation stations, and set transportation service edges at the two nodes corresponding to the graph data for the two transportation stations with direct transportation services. At the same time, the transfer situation of non-transportation services between the two transportation stations is analyzed, and the transfer edges are set.

[0063] It should be noted that since the connecting edge is a directed edge (not limited to a traffic schedule edge or a transfer edge), for the two nodes connected by the connecting edge, the node that issues the connecting edge is the departure node, and the corresponding transportation station is the departure station of the connecting edge. The node to which the connecting edge points is the arrival node, and the corresponding transportation station is the arrival station of the connecting edge.

[0064] In an optional implementation example, for any two transportation stations, the embodiment of the present application can determine the departure station and the arrival station of the two transportation stations when setting the connecting edge, and then analyze and determine whether there is a direct transportation service from the departure station to the arrival station based on the transportation route database; if there is a direct transportation service, then based on each direct transportation service, a transportation service edge pointing to the node corresponding to the arrival station is set for the node corresponding to the departure station in the graph database, that is, each direct transportation service between the two transportation stations is respectively set with a corresponding transportation service edge; at the same time, the transfer situation of non-transportation services between the two transportation stations is analyzed, so as to set a transfer edge between the two transportation stations.

[0065] In a further optional implementation, the embodiment of the present application may define a transfer edge setting condition, so as to set a transfer edge between traffic stations that meet the transfer edge setting condition. For example, the transfer edge setting condition includes but is not limited to: The transportation stations for setting up transfer edges are in the same geographical area. For example, transfer edges can be set up between different transportation stations in the same city. The distance between the transportation stations where the transfer edge is set shall not exceed the preset distance. For example, for any two transportation stations in different cities, the embodiment of the present application may analyze the distance between the two transportation stations. If the distance does not exceed the preset distance, the embodiment of the present application may set a transfer edge for the two transportation stations across cities. If the distance exceeds the preset distance, the embodiment of the present application may not set a transfer edge for the two transportation stations across cities. In other words, if the distance between the two transportation stations across cities is far, the possibility of non-transportation transfer is low, and a transfer edge may not be set.

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

[0067] It should be noted that the traffic route database records the traffic schedule information of various modes of transportation (such as trains, airplanes, cars, etc.). The traffic schedule information includes the route data of the traffic schedule, such as the transportation stations where the transportation schedule departs, the transportation stations passed, the transportation stations arrived, etc., so based on the route data of each transportation schedule in the traffic route database, it is possible to analyze and confirm whether the transportation relationship between two transportation stations is direct.

[0068] Step S330: setting edge attributes for the traffic shift edge and setting edge attributes for the transfer edge.

[0069] When setting connection edges between nodes, an embodiment of the present application can set edge attributes for the connection edges. Based on the connection edges being divided into traffic schedule edges and transit edges, an embodiment of the present application can set edge attributes for the traffic schedule edges, as well as set edge attributes for the transit edges.

[0070] In the optional implementation, the edge attributes of the traffic schedule edge include not only the information of the departure node (corresponding to the departure station) and the arrival node (corresponding to the arrival station), but also multiple attribute information describing the traffic schedule. For ease of understanding, Figure 3C An example diagram showing the content of the edge attributes of the traffic schedule edge is shown in combination with Figure 3C As shown, the edge attributes of the traffic schedule edge include but are not limited to: src_id, which indicates the unique identifier of the departure node of the traffic schedule edge, and is used to identify the node that sends the traffic schedule edge in the graph data; dst_id, which represents the unique identifier of the arrival node of the traffic shift edge, is used to identify the node to which the traffic shift edge points in the graph data; the two fields src_id and dst_id in the edge attributes of the traffic shift edge define the starting point and end point of the traffic shift edge; time stamps, used to identify the timestamp identifier of the traffic shift corresponding to the traffic shift edge, for example, the timestamp identifier can be used to distinguish different traffic shifts with the same departure station, and / or the same arrival station, and / or the same departure time, and / or the same arrival time; for example, the time stamps can be initially set to be the same as the departure time of the traffic shift corresponding to the traffic shift edge, so that if there are other traffic shift 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 traffic shift edges, the time stamps of the traffic shift edges can be fine-tuned, such as adding 1 second or subtracting 1 second to the time stamps of the traffic shift edges, so that multiple traffic shift edges with the same departure station, arrival station, departure time, arrival time, etc. have different time stamps; dep_date, which indicates the departure date of the transportation schedule corresponding to the transportation schedule edge, and is used to describe the departure date information of the transportation schedule; traffic_code, which indicates the code of the traffic schedule corresponding to the traffic schedule edge, such as the train number when the traffic schedule is a train number; src_station, which indicates the departure station of the traffic schedule edge, that is, the traffic station corresponding to the departure node of the traffic schedule edge, such as the name of the departure station; dst_station, which indicates the arrival station of the traffic schedule edge, that is, the traffic station corresponding to the arrival node of the traffic schedule edge, such as the name of the arrival station; dep_city_code, which indicates the code of the city where the departure station is located, that is, the code of the departure city; arr_city_code, which indicates the code of the city where the arrival station is located, that is, the code of the arrival city; dep_city_id, indicating the ID of the departure city; arr_city_id, indicating the ID of the arrival city; cost_time, which indicates the time taken by the traffic shift from the departure station to the arrival station, and the time taken is measured in seconds; dep_time, which indicates the departure time of the transport shift corresponding to the transport shift edge, expressed in the format of unix time stamps; arr_time, which indicates the arrival time of the transport shift corresponding to the transport shift edge, expressed in the format of unix time stamps; update time, the update timestamp of the price database data, which indicates the timestamp of the last update time of the price and ticket inventory of the transportation schedule edge corresponding to the transportation schedule edge. Since the price and ticket inventory of the transportation schedule edge are dynamically changing, the update timestamp of the price database data can be used to confirm the timeliness of the price database data contained in the edge attributes of the transportation schedule edge; status, indicating the status of the transportation schedule corresponding to the transportation schedule edge, such as whether the transportation schedule is running normally. For example, a transportation schedule may be delayed or cancelled due to transportation failure or weather reasons, resulting in abnormal operation; stock_info, which indicates the ticket inventory of the transport shift corresponding to the transport shift edge, such as the remaining tickets of the transport shift. The stock_info field is used to clarify whether the transport shift has remaining tickets, thereby providing ticket availability information for the transport shift; price_info, which indicates the price of the transportation class corresponding to the transportation class edge, such as the minimum price corresponding to the remaining tickets with stock; in an optional implementation example, the above stock_info can also be expressed as the stock of tickets corresponding to the minimum price among the remaining tickets of the transportation class; stock_type indicates the seat type of the remaining tickets for the transportation schedule corresponding to the transportation schedule edge, such as the seat type corresponding to the minimum price among the remaining tickets.

[0071] It should be noted that in Figure 3C 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 to standard integers (such as int), bigint can store larger values. It is worth noting that although bigint and long are both 64-bit signed integer types, bigint is a data type in the database, while long is a data type in the programming language. 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).

[0072] In an optional implementation, the edge attributes of the transit edge can have the unique identifier of the departure node and the unique identifier of the arrival node, and describe the characteristics of the transit situation through a series of attributes. For ease of understanding, Figure 3D An example diagram showing the content of the edge attribute of the transit edge is shown in combination with Figure 3D As shown, the edge attributes of the transit edge include but are not limited to: src_id, which indicates the unique identifier of the starting node of the transit edge, and is used to identify the node that issues the transit edge in the graph data; dst_id, which represents the unique identifier of the arrival node of the transit edge, is used to identify the node to which the transit edge points in the graph data; the two fields src_id and dst_id in the edge attributes of the transit edge define the starting point and end point of the transit edge; time stamps, which indicates the timestamp identifier, is used to align the format with the time stamps of the traffic schedule edge. For the transfer edge, the value of the time stamps can be set to a meaningless value, such as zero; src_type, which indicates 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; dst_type, which indicates 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; edge_type, indicating that the edge type of the connection edge is a transit edge; specifically, in the graph data, the edge types of the connection edge are divided into traffic schedule edges and transit edges. In the edge attributes of the transit edge, the type of the connection edge corresponding to edge_type is a transit edge; src_station, which indicates the departure station of the transfer edge, such as the name of the departure station; dst_station, indicating the arrival station of the transfer edge, such as the name of the arrival station; dep_city_code, which indicates the code of the city where the departure station is located, that is, the code of the departure city; arr_city_code, which indicates the code of the city where the arrival station is located, that is, the code of the arrival city; dep_city_id, indicating the ID of the departure city; arr_city_id, indicating the ID of the arrival city; cost_time, which indicates the time taken for transfer, measured in seconds; min_price, which indicates the estimated minimum price of the transfer.

[0073] It can be seen that compared with the edge attributes of the traffic schedule edge and the edge attributes of the transfer edge, the edge attributes of the traffic schedule edge contain price library data, that is, the price data and ticket inventory data of the traffic schedule. Since the price and ticket inventory of the traffic schedule are dynamically changing, the embodiment of the present application sets the nodes corresponding to the transportation stations in the graph data, as well as the traffic schedule edges and transfer edges between the nodes, and it is also necessary to dynamically update the price library data of the traffic schedule edges to ensure that the price library data of the traffic schedule edges in the graph data remain timely.

[0074] Step S340: Update the price storage data according to the price library data of the traffic shifts and use the cache mechanism as the edge attribute of the traffic shift edge corresponding to the traffic shifts.

[0075] In an optional implementation, the travel service platform can obtain the price library data of the traffic schedule periodically or in real time through the message middleware, and then update the price storage data for the edge attributes of the traffic schedule edge corresponding to the traffic schedule in the graph data, that is, update the price data and ticket inventory data. Among them, the message middleware is a technology used to transmit messages between different system components. The message middleware can efficiently transmit messages from producers to consumers and ensure that messages are transmitted reliably and efficiently. Therefore, the embodiment 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 of the travel service platform that updates the price library data for the traffic schedule edge, so as to ensure that the travel service platform maintains high efficiency when updating and processing a large amount of price library data (such as price library data of multiple traffic schedules).

[0076] In a further optional implementation, the travel service platform can use the message middleware to periodically and actively obtain the real-time price library data of each transportation schedule of various transportation modes from multiple price library databases, and then update the price storage data based on the edge attributes of the transportation schedule edges corresponding to the transportation schedule in the graph data; wherein, a price library database can record the real-time price library data of each transportation schedule of at least one transportation mode, that is, real-time price data and ticket inventory data.

[0077] For example, the travel service platform can connect to the price databases of various transportation companies and transportation management bureaus through interfaces, including but not limited to the price databases of train tickets of railway companies and railway management bureaus, the price databases of air tickets of airlines, and the price databases of bus tickets of bus passenger transport companies, so that the travel service platform can actively obtain the real-time price database data of various transportation schedules of various transportation tools (such as trains, planes, cars, etc.) through the connected price databases, and the obtained price database data is transmitted to the travel service platform through the message middleware; then, the travel service platform can update the price storage data for the edge attributes of each transportation schedule in the graph data. In other words, the travel service platform can connect to the price databases related to transportation tickets such as train tickets, air tickets and bus tickets through the open data interfaces of train tickets, air tickets and bus tickets, so as to obtain the real-time price database data of various transportation schedules of various transportation tools such as trains, planes, cars, etc. on a regular or real-time basis.

[0078] In other optional implementations, the source of the travel service platform's price library data for transportation schedules may also be the exposure data of ticket searches. For example, the travel service platform may provide users with search functions for transportation tickets such as train tickets, air tickets, and bus tickets. As a result, when users of the travel service platform search for transportation tickets such as train tickets, air tickets, and bus tickets, corresponding exposure data will be generated. These exposure data include real-time price library data for multiple transportation schedules of various types of transportation tools such as trains, airplanes, and cars, and can reflect the user's real-time travel needs. Therefore, they can serve as the source of price library data for the travel service platform to update the transportation schedules in the graph data, and be transmitted through the message middleware, such as through the message middleware between the ticket search engine of the travel service platform and the component of the travel service platform that updates the price library data for the transportation schedules.

[0079] That is to say, the price database data of the transportation schedules are derived from multiple price databases and / or exposure data of ticket searches. For example, the travel service platform can combine the above price databases and the above exposure data to obtain the real-time price database data of each transportation schedule of various transportation modes, and transmit and consume the price database data through the message middleware (consumption processing is to use the transmitted price database data to update the price data and ticket inventory data of the transportation schedule).

[0080] In order to reduce the update processing burden of the price library data of the traffic shift, the embodiment of the present application introduces a caching mechanism to avoid repeated and invalid price library data updates on the traffic shift; specifically, the travel service platform can cache the acquired price library data of the traffic shift according to the preset caching time, that is, after the travel service platform collects the price library data of the traffic shift, there is a caching mechanism for caching the collected price library data of the traffic shift, and if the cached price library data of the traffic shift exceeds the preset caching time, the cached price library data of the traffic shift expires; thus, for any traffic shift, when the price library data of the newly acquired traffic shift is the same as the price library data of the cached traffic shift, the embodiment of the present application can cancel the update of the price library data for the traffic shift corresponding to the traffic shift until the cached price library data of the traffic shift expires, or, when the price library data of the newly acquired traffic shift is different from the cached price library data of the traffic shift, the price library data for the traffic shift corresponding to the traffic shift is updated based on the newly acquired price library data of the traffic shift.

[0081] For ease of understanding, Figure 3E An example diagram of updating price library data is shown as follows: Figure 3EAs shown in the figure, each mode of transportation has corresponding price database data, such as train ticket price database data (including real-time price database data of each train schedule), airplane ticket price database data (including real-time price database data of each flight schedule), bus ticket price database data (including real-time price database data of each bus schedule), and price database data corresponding to other modes of transportation. These price database data are transmitted through the message middleware in the corresponding message topic. In order to reduce the burden of updating the price library data on the traffic schedule side of the graph data, the embodiment of the present application introduces a cache mechanism. By setting a message cache, the real-time price library data of each traffic schedule of various transportation modes transmitted by the message middleware is cached, and the cache validity period of the message cache for the price library data of any traffic schedule is a preset cache time (for example, 10 minutes). That is, if the storage time of the price library data of any traffic schedule in the message cache reaches the preset cache time, it is deemed expired, and the newly acquired price library data of the traffic schedule needs to be re-cached; Furthermore, after the travel service platform obtains the real-time price library data of the transportation schedule through the message middleware each time, it can check whether the price library data of the newly obtained transportation schedule is the same as the price library data of the cached transportation schedule, that is, check whether the price data and ticket inventory data of the newly obtained transportation schedule have changed compared with the cached price data and ticket inventory data of the transportation schedule; if the price library data of the newly obtained transportation schedule is the same as the price library data of the cached transportation schedule, the price library data of the corresponding transportation schedule will not be updated, because the price library data has not changed, thereby avoiding unnecessary update of the price library data of the transportation schedule; if the price library data of the newly obtained transportation schedule is different from the price library data of the cached transportation schedule, it is necessary to update the price library data for the corresponding transportation schedule in the graph data based on the price library data of the newly obtained transportation schedule, cache the price library data of the newly obtained transportation schedule, and reset the cache time.

[0082] For example, taking the preset cache time of 10 minutes as an example, when the travel service platform obtains the price library data of a certain transportation schedule for the first time, it can cache the price library data of the transportation schedule in the message cache, and set the cache time of 10 minutes, and update the price library data for the corresponding transportation schedule in the graph database; within the next 10 minutes, if the newly acquired 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 embodiment of the present application will not update the price library data for the corresponding transportation schedule; if the newly acquired price library data of the transportation schedule is the same as the cached data, If the cached data is different (i.e. the price and / or ticket inventory of the transport service has changed), the price library data for the corresponding transport service is updated, and the newly acquired price library data for the transport service is re-cached, and a cache time of 10 minutes is set; after the cache time reaches 10 minutes, regardless of whether the newly acquired price library data for the transport service is the same as the cached data, the embodiment of the present application will use the newly acquired price library data for the transport service to update the price library data for the corresponding transport service, and re-cache the newly acquired price library data for the transport service, and set a cache time of 10 minutes, and so on.

[0083] Through the caching mechanism, the embodiment of the present application avoids updating the graph data every time the price library data of the new transportation schedule is obtained. The graph data is updated only when necessary (data changes or cache times out), thereby reducing unnecessary update operations and reducing the update burden.

[0084] At this point, the embodiment of the present application has completed the construction of graph data, and the graph data includes nodes corresponding to each transportation station (such as train stations, airports, bus stations, etc.), and connecting edges (transportation schedule edges and transfer edges) corresponding to the transportation travel relationships between transportation stations, and 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 processing in subsequent stages.

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

[0086] In an optional implementation, the one-way path between transportation stations can be determined based on the traffic schedule edges between transportation stations, that is, the traffic schedule edges between transportation stations represent the direct traffic schedules between transportation stations, corresponding to the one-way path between transportation stations. The two-way path between transportation stations can be completed by the path search algorithms integrated in the graph database, such as bidirectional BFS (Breadth First Search) and DFS (Depth First Search), that is, the two-way path can directly rely on the characteristics of the graph data itself to ensure the smooth progress of the path search. It should be noted that the graph data can be saved in the graph database, and the graph database has a basic path search algorithm integrated inside to search for paths between nodes in the graph data.

[0087] However, as described above, the number of routes with more than two legs (such as routes with three legs or more) grows exponentially, and routes with more than two legs contain multiple route segments. It is very time-consuming to query the price database data of the transportation schedules for each route segment. Therefore, the embodiment of the present application considers optimizing the route planning of at least two legs of routes in the offline route planning stage, and planning at least two legs of routes and corresponding transfer points for any two transportation stations.

[0088] In other optional implementations, the offline path planning stage may also involve planning two-leg paths for any two transportation stations, rather than being limited to planning only two or more legs of paths; for example, for any two transportation stations, the offline path planning stage may plan two-leg paths and more than two legs of paths, as well as corresponding transfer points.

[0089] That is to say, the multi-trip path planned for any two traffic stations in the offline path planning stage may be a path of more than two trips, or a path of two trips and a path of more than two trips.

[0090] The embodiment of the present application plans a multi-trip route (especially a route with more than two trips) and corresponding transfer points for any two traffic stations in the offline route planning stage, which can facilitate the processing of the subsequent online route service and pruning stage. Furthermore, in the offline route planning stage, the embodiment of the present application can solve the route planning difficulties existing in the Cartesian product operation based on the use of graph data and the use of path search algorithms such as the Dijkstra algorithm.

[0091] As an optional implementation, Figure 4 The flowchart of offline path planning provided by the embodiment of the present application is exemplarily shown. Figure 4 The process shown in the figure, the embodiment of the present application can plan a multi-trip path and a corresponding transfer point for any two transportation stations. The multi-trip path planned here can be a path with more than two trips, or a path with two trips and a path with more than two trips. Figure 4 , the process may include the following steps.

[0092] Step S410, based on the graph database, using a path search algorithm, generates multiple multi-trip paths between any two transportation stations.

[0093] In the offline path planning process, multi-trip path generation is implemented based on graph data, and with the help of path search algorithms, a multi-trip path that is passable between any two transportation stations is found; that is, with the help of path search algorithms, whether the path is passable is considered, so as to find a multi-trip path between any two transportation stations in the graph data. Specifically, in the graph data, for any two nodes, a multi-trip path is issued from the departure node, and based on the path search algorithm, the path is extended along the connecting edges (traffic schedule edges, or, traffic schedule edges and transfer edges), so as to pass through multiple transfer nodes (the nodes passed in the middle of the multi-trip path are transfer points), and finally arrive at the arrival node, and the number of traffic schedule edges contained in a multi-trip path corresponds to the number of trips of the multi-trip path. Furthermore, each transfer node and traffic schedule edge passed by the generated multi-trip path can be recorded.

[0094] The embodiment of the present application can generate multi-trip paths of various lengths for any two nodes of the graph data (corresponding to any two transportation stations). For example, for paths of more than two legs, paths of various lengths such as three legs and four legs can be generated, thereby obtaining multiple multi-trip paths between any two transportation stations; wherein, one length of a multi-trip path between two transportation stations can correspond to one or more paths, for example, a three-leg path between two transportation stations can correspond to one or more paths.

[0095] In an optional implementation, the path search algorithm used in the embodiment of the present application includes but is not limited to any of the following: Dijkstra's algorithm is used to search for the shortest path, such as searching for multi-path paths of various lengths with the shortest path from the starting node to the arrival node. For example, for paths with more than two legs, searching for paths with the shortest three-legged, four-legged, and other lengths from the starting node to the arrival node. Depth-first search algorithm is used to search all multi-paths. For example, for paths with more than two legs, it searches for all accessible paths with more than two legs of various lengths from the departure node to the arrival node. Breadth-first search algorithm is used to find the shortest path in an unweighted graph. For example, when the connecting edges of the graph data have no weights (i.e., in the case of an unweighted graph), it searches for multi-paths of various lengths with the shortest path from the starting node to the arrival node. Heuristic search algorithm optimizes path finding through heuristic search. Compared with Dijkstra's algorithm, the heuristic search algorithm adds heuristic evaluation to optimize the search process by estimating the cost of the path.

[0096] Furthermore, when using a path search algorithm to generate multiple multi-trip paths between two transportation stations, for any multi-trip path, the embodiment of the present application can use vector data to store the departure node of the multi-trip path, the traffic schedule edges passed, the transfer nodes passed, the arrival node of the multi-trip path, and other detailed information related to the path of the multi-trip path.

[0097] Step S420, for each multi-trip path between any two transportation stations, the value score of the multi-trip path is evaluated according to multiple path evaluation features to obtain the value score of each multi-trip path between any two transportation stations.

[0098] After generating multiple multi-trip paths between any two traffic stations based on graph data, the embodiment of the present application can evaluate the value score of each multi-trip path for any two traffic stations. When evaluating the value score of a multi-trip path, it depends on multiple path evaluation features corresponding to the multi-trip path, including but not limited to: The time consumption of a multi-trip path, that is, the total time from the departure station to the arrival station of the multi-trip path, can be calculated by the time consumption of each traffic shift corresponding to each traffic shift edge passed by the multi-trip path, and the time consumption of transfer at each transfer node passed; that is, by accumulating the time consumption of each traffic shift passed by the multi-trip path and the time consumption of transfer at each transfer node, the time consumption of the multi-trip path can be estimated and calculated; The price of a multi-trip path, that is, the sum of the travel costs from the departure point to the arrival point of the multi-trip path, can be calculated by the price of the transportation route corresponding to each transportation route edge passed by the multi-trip path, and the estimated price of transfer at each transfer node passed by.

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

[0100] After determining the time consumption, price and other path evaluation features of each multi-leg path, for each multi-leg path, the embodiment of the present application can fuse the time consumption, price and other path evaluation features of the multi-leg path to obtain the value score of the evaluated multi-leg path. In an optional implementation, the process of fusing the time consumption, price and other path evaluation features of the multi-leg path can include but is not limited to: Normalization processing is to normalize the various path evaluation features such as the time consumption and price of the multi-trip path to obtain the normalized results of the various path evaluation features of the multi-trip path; through normalization processing, different types of path evaluation features of the multi-trip path can be converted into the same scale, so that different types of path evaluation features such as the time consumption and price of the multi-trip path can be compared with each other; for example, assuming that the price range of the multi-trip path is 100 yuan to 1,000 yuan, and the time consumption range is 1 hour to 12 hours, through normalization processing, the price and time consumption of the multi-trip path can be converted into values ​​between 0 and 1, which is convenient for subsequent calculations; Weighted summation. After normalization, the embodiment of the present application can perform weighted summation based on the weights of each path evaluation feature and the normalized results of each path evaluation feature of the multi-path, so as to obtain the value score of the multi-path; for example, the normalized result of the time consumption of the multi-path is multiplied by the weight of the time consumption to obtain a product, and the normalized result of the price of the multi-path is multiplied by the weight of the price to obtain another product. The two products are added to complete the weighted summation process to obtain the value score of the multi-path.

[0101] In a further optional implementation, the embodiments of the present application may also use methods such as exponential weighting to determine the value score of a multi-leg path based on multiple path evaluation features such as the time consumption and price of the multi-leg path; for example, an index may be used to amplify the influence of a certain path evaluation feature (such as time consumption or price) of a multi-leg path, so that the path evaluation feature has a greater impact on the value score obtained by the evaluation.

[0102] Step S430, for any two transportation stations, determine the multi-trip paths planned between the two transportation stations according to the value score of each multi-trip 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 multi-trip paths planned between the two transportation stations, and form a transfer point planning set between any two transportation stations.

[0103] After obtaining the value score of each multi-trip path between any two transportation stations, for any two transportation stations, the embodiment of the present application can sort the multi-trip paths based on the value score of each multi-trip path between the two transportation stations, such as sorting the multi-trip paths in descending order according to the value score, so as to use a set number of multi-trip paths with the highest value scores, or multi-trip paths whose value scores meet the set score standards, as the multi-trip paths planned between the two transportation stations, so as to obtain a path planning set between the two transportation stations.

[0104] Furthermore, for any two transportation stations, after obtaining the planned multi-trip path between the two transportation stations, the embodiment of the present application can use the transfer nodes passed by the planned multi-trip path as the planned transfer points between the two transportation stations to obtain a planned transfer point set between the two transportation stations.

[0105] Therefore, any two traffic stations follow Figure 4 By following the process shown in the figure, we can determine the path planning set between any two transportation stations and the corresponding transfer point planning set. In other words, any two nodes in the graph data can be connected by Figure 4 The process shown outputs a set of path plans (including planned multi-trip paths) and a corresponding set of transfer point plans (including planned transfer points) for use in subsequent stages.

[0106] 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, each leg path can have a corresponding path planning subset, including the path planned for each leg; for example, for any two transportation stations, the path planning set can include the path planning subset for the first leg (including the path planned for the first leg), the path planning subset for the second leg (including the path planned for the second leg), the path planning subset for the third leg (including the path planned for the third leg), and so on. Of course, setting path planning subsets for each leg is only a further optional implementation.

[0107] At this point, the embodiment of the present application completes offline path planning, and is implemented to plan multi-leg paths (especially paths with more than two legs) and corresponding transfer points for any two transportation stations, obtain a path planning set and a corresponding transfer point planning set between any two transportation stations, and solve the path planning difficulty problem of Cartesian product operation.

[0108] The online path serving and pruning phase 230 consists of online path serving and online path pruning.

[0109] The online path service is used to: search graph data based on the user's departure point and the user's destination to determine the one-way path to be recommended between the user's departure point and the user's destination; and define a transfer point search constraint condition based on at least a reserved set of transfer points between the user's departure point and the user's destination, and search graph data based on the transfer point search constraint condition to determine the multi-trip path to be recommended between the user's departure point and the user's destination; thereby, the one-way path to be recommended and the multi-trip path to be recommended form multiple paths to be recommended; wherein, the reserved set of transfer points between any two transportation stations includes the reserved transfer points between any two transportation stations.

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

[0111] That is to say, the online path service is user-oriented, and through graph data search, it generates recommended one-way paths and multi-way paths (such as two-way paths and paths with more than two-way paths) between the user's departure point and the user's destination. In the embodiment of the present application, the multi-way path to be recommended should at least meet the constraints of the transfer point, which is determined by the reserved set of transfer points between the user's departure point and the user's destination; further, the traffic schedule edges in the one-way path to be recommended and the multi-way path to be recommended should at least meet the constraints such as ticket inventory.

[0112] For the one-way path to be recommended, the embodiment of the present application can query the graph data, perform a path search on the graph data, determine the traffic schedule edge directly connected between the user's departure point and the user's destination, and form the one-way path to be recommended. Furthermore, in the search process of the one-way path to be recommended, at least constraints such as ticket inventory can be introduced to constrain the searched traffic schedule edge to meet the ticket inventory requirements, thereby ensuring that the one-way path to be recommended can meet the user's travel needs. Furthermore, in the search process of the one-way path to be recommended, the constraint of the update timestamp of the price library data can also be introduced to constrain the timeliness of the searched traffic schedule edge that meets the ticket inventory requirements, 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. The constraints involved in the above-mentioned search process of the one-way path to be recommended can be achieved by setting the corresponding search constraints of the traffic schedule edge.

[0113] For the multi-trip paths to be recommended (especially paths with more than two trips), the embodiment of the present application combines the reserved set of transfer points between the transportation stations that are regularly updated by online path pruning as the transfer points reserved when searching for multi-trip paths between transportation stations. Therefore, when searching for the multi-trip paths to be recommended between the user's departure point and the user's destination, the embodiment of the present application can introduce the reserved set of transfer points between the user's departure point and the user's destination to define the transfer point search constraints, that is, constrain the multi-trip paths between the user's departure point and the user's destination to pass through the reserved transfer points, but not through the unreserved transfer points, thereby reducing the search complexity of the multi-trip paths to be recommended. Furthermore, in the search process of the multi-trip paths to be recommended, in addition to introducing the constraints of the reserved set of transfer points, at least constraints such as ticket inventory can be introduced to constrain the searched transportation schedules to meet the ticket inventory requirements, thereby ensuring that the multi-trip paths to be recommended can meet the travel needs of users. Furthermore, in the search process of the multi-trip path to be recommended, the update timestamp constraint of the price library data can also be introduced to constrain the timeliness of the searched traffic schedule edge that meets the ticket inventory requirements. 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. The constraints involved in the search process of the multi-trip path to be recommended can be achieved by setting the corresponding search constraints for the traffic schedule edge. Furthermore, since the multi-trip path to be recommended may also involve transfer edges, search constraints can also be set for transfer edges.

[0114] As an optional implementation, Figure 5A The flowchart of determining the reserved set of transit points provided in the embodiment of the present application is exemplarily shown. The flowchart can be regarded as an optional implementation process of online path pruning. Figure 5A , the process may include the following steps.

[0115] Step S510, for each traffic schedule edge included in the path planning set between any two traffic stations, predict the ticket inventory status of the traffic schedule edge at a future time, and obtain the ticket inventory prediction result of the traffic schedule edge.

[0116] For any two transportation stations, the path planning set includes multi-trip paths (such as more than two-trip paths) planned for the two transportation stations, and each planned multi-trip path includes a transportation schedule edge. Therefore, for any two transportation stations, the embodiment of the present application can determine the transportation schedule edges included in the path planning set between any two transportation stations, and then for each transportation schedule edge included in the path planning set, the embodiment of the present application can perform ticket inventory prediction separately to predict the ticket inventory status of the transportation schedule edge at a future moment (such as the next moment).

[0117] For example, it is possible to predict whether there is a ticket inventory at the future time on the transportation schedule, or the ticket inventory value at the future time, so as to predict the ticket inventory situation at the future time on the transportation schedule, and obtain the ticket inventory prediction result at the transportation schedule. In other words, the ticket inventory situation at the future time on the transportation schedule can be represented by whether there is a ticket inventory at the future time on the transportation schedule, or by the specific ticket inventory value at the future time on the transportation schedule.

[0118] In an optional implementation, the embodiments of the present application may use a prediction model (such as a machine learning model such as a deep neural network classification model) to predict the ticket inventory status of the traffic shift side at a future moment (such as the next moment). For example, the characteristic information of the traffic shift corresponding to the traffic shift side is input into the prediction model, thereby predicting the ticket inventory status of the traffic shift side at a future moment (such as the next moment) and obtaining the ticket inventory prediction result of the traffic shift side.

[0119] In an optional implementation, the prediction model uses prediction methods including but not limited to: Machine learning regression algorithm is used to predict continuous values. In the ticket inventory prediction of the traffic schedule edge, the machine learning regression algorithm can be used to predict the ticket inventory value of the traffic schedule corresponding to the traffic schedule edge at a certain time. The graph-based time series prediction algorithm predicts the ticket inventory of transportation schedules by combining time series data with graph data. Graph data involves the relationship between nodes and connecting edges, which can help the prediction model understand the dependencies between transportation stations. A deep neural network classification algorithm, such as a prediction model using a deep neural network classification model, predicts whether a traffic shift will have ticket inventory at the next moment by learning the historical data characteristics of the traffic shift; for example, the deep neural network classification model can be used to process binary classification problems, such as in an embodiment of the present application, to predict whether a traffic shift corresponding to a certain traffic shift edge will have ticket inventory at the next moment.

[0120] In an optional implementation, taking a machine learning model such as a deep neural network classification model as an example, Figure 5B The training example diagram of the prediction model is shown as an example. Figure 5B As shown, the feature data used for training includes but is not limited to: The basic features of the traffic schedule edge are used to describe the basic information of the traffic schedule edge, such as the identifier of the traffic schedule edge (each traffic schedule edge in the graph data can be set with a unique identifier, such as the code of the traffic schedule edge), the associated upstream and downstream stations (such as the departure station and arrival station corresponding to the traffic schedule edge), the traffic schedule corresponding to the traffic schedule edge, and other basic information; Time features, various 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 on which the ticket inventory is predicted to exist on the traffic schedule), the predicted time period (the predicted time period is the time period when the ticket inventory is predicted to exist on the traffic schedule), etc. The inventory characteristics of the upstream and downstream stations associated with the traffic schedule edge at the current moment, that is, the ticket inventory of the traffic schedules of the upstream and downstream stations related to the traffic schedule edge; The inventory sequence feature of the traffic schedule edge represents the ticket inventory change of the traffic schedule corresponding to the historically recorded traffic schedule edge, such as the historical change of the ticket inventory of the corresponding traffic schedule over time, which is used to help the model understand the ticket inventory change trend of the corresponding traffic schedule.

[0121] Specific, combined Figure 5B As shown in the figure, the basic features of the traffic schedule edge, the time features, and the inventory features of the upstream and downstream stations associated at the current moment are processed by the embedding layer of the prediction model to obtain the corresponding vector representation; the embedding layer is used to convert the input into a low-dimensional vector representation; The inventory sequence features of the traffic schedule edge are processed by the gated recurrent unit (GRU) of the prediction model to capture the time dependency in the inventory sequence features of the traffic schedule edge; that is, the inventory sequence features of the traffic schedule edge are time series data, and the time dependency in the time series data can be captured by the gated recurrent unit; Then, the concatenation layer of the prediction model merges and concatenates the vector representation output by the embedding layer and the temporal dependency output by the gated recurrent unit into a unified feature vector for subsequent processing. The multi-layer perceptron layer (MLP Layer) of the prediction model is composed of at least a plurality of fully connected layers, which are used for multi-layer nonlinear transformation, so that the unified feature vector output by the splicing layer is processed by the multi-layer perceptron layer for multi-layer nonlinear transformation to output the prediction result of whether there is a ticket inventory on the side of the traffic schedule; The loss function is the objective function of the prediction model optimization. The prediction model optimizes the model parameters by minimizing the value of the loss function. Specifically, the loss function can use the cross entropy loss. The cross entropy loss is used for classification problems, especially for 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 of the traffic schedule edge (i.e., the binary classification prediction of whether the traffic schedule edge will have ticket inventory or no ticket inventory in the future), the cross entropy loss is used to measure the difference between the ticket inventory prediction result of the traffic schedule edge output by the prediction model and the actual label. The actual label can be obtained by marking the historical data of the traffic schedule corresponding to the traffic schedule edge, such as marking whether the traffic schedule edge actually has ticket inventory at the next historical moment at any historical moment based on the historical data of the traffic schedule.

[0122] After training the prediction model, the embodiment of the present application can use the prediction model to predict the ticket inventory of the traffic schedule. Specifically, the embodiment of the present application can determine the prediction input data of the traffic schedule, and the prediction input data can correspond to the feature data used for training, such as the basic characteristics of the traffic schedule, time characteristics, inventory sequence characteristics, and inventory characteristics of the upstream and downstream stations associated with the traffic schedule at the current moment; thereby, the prediction input data of the traffic schedule is input into the prediction model, and the prediction model can output the ticket inventory prediction results of the traffic schedule at the future moment.

[0123] In other optional implementations, the embodiments of the present application may also utilize graph neural networks to predict ticket inventory on the side of transportation schedules. For example, in the prediction of ticket inventory on the side of transportation schedules, space (the relationship and influence between transportation stations) and time (the change of ticket inventory on the side of transportation schedules over time) are two key factors. Therefore, the space-time graph neural network can be used in combination to predict the ticket inventory situation of the transportation schedule at future time points.

[0124] For example, Figure 5C The following is an example diagram showing the application of graph neural network: Figure 5C As shown in the figure, the input series can be time series data, which represents the historical data of the traffic schedule, such as the ticket inventory information of the traffic schedule at different time points; the target series is the expected predicted ticket inventory result of the traffic schedule, such as the expected predicted ticket inventory result of the traffic schedule at the next moment, which can be specifically whether the expected predicted traffic schedule has ticket inventory at the next moment or not; The spatial-temporal graph neural network (Spatial-Temporal GNN) is used to process the input sequence, combining the input sequence with the graph data (i.e., the graph data constructed in the embodiment of the present application), thereby combining the structural information of the graph with the input sequence to consider the relationship between space and time; the prediction layer, such as the multi-layer perceptron layer, is used to predict the ticket inventory status of the traffic schedule at future times based on the output of the spatial-temporal graph neural network, thereby outputting the ticket inventory prediction result of the traffic schedule; further, the difference between the ticket inventory prediction result of the prediction layer and the target sequence is compared, and the prediction accuracy is measured and the parameters are optimized through the forecasting loss (prediction loss function).

[0125] The embodiment of the present application supports the use of a graph neural network model to combine the relationship between space and time in the ticket inventory prediction of the traffic schedule edge, so as to consider the historical data of the traffic schedule edge and the mutual influence of other traffic schedule edges and nodes associated with the traffic schedule edge in the graph data, thereby improving the prediction accuracy.

[0126] Step S520, 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 removed and the transfer points to be retained, and obtain the transfer point retention set between any two transportation stations.

[0127] For any two transportation stations, after obtaining the ticket inventory prediction results of each transportation schedule edge in the path planning set, the embodiment of the present application can perform node pruning according to the ticket inventory prediction results; specifically, for any two transportation stations, the node pruning operation can be concentrated on the transfer points of the transfer point planning set. For example, if a transfer point planned between two transportation stations has insufficient ticket inventory for the transportation schedule edge associated with it in the corresponding path planning set, then the transfer point and the transportation schedule edge associated with the transfer point will be eliminated, thereby avoiding recommending a path with insufficient ticket inventory to the user.

[0128] In an optional implementation, for each transfer point in the transfer point planning set between any two transportation stations, the embodiment of the present application can determine the transportation schedule edge associated with the transfer point (such as the transportation schedule edge connecting the transfer point in the path planning set of the two transportation stations), and thus check the validity of the transfer point based on the ticket inventory prediction result of the transportation schedule edge associated with the transfer point to determine whether the transfer point should be retained.

[0129] As an optional implementation example, taking the ticket inventory prediction result as whether there is ticket inventory on the traffic schedule edge as an example, the embodiment of the present application can define a future time range, such as the next 30 minutes, the next hour, etc., and the future time range is used to predict the future ticket 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 embodiment of the present application can determine the number of traffic schedule edges associated with the transfer point that have ticket inventory within the future time range based on the ticket inventory prediction result of the traffic schedule edges associated with the transfer point within the future time range; wherein the future time range is composed of multiple future moments, and the traffic schedule edges associated with the transfer point in the future can be analyzed. The ticket inventory prediction results for each future moment within the time range are obtained, so as to determine the traffic schedule edges with ticket inventory in the future time range from the traffic schedule edges associated with the transfer point, so as to obtain the number of traffic schedule edges associated with the transfer point with ticket inventory in the future time range; then the above number of edges is compared with the threshold to determine whether the above number of edges meets the threshold, such as whether it is not lower 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 traffic schedule edges need to be eliminated; in the above manner, the transfer points retained between any two transportation stations can be determined to form a reserved set of transfer points between any two transportation stations.

[0130] The embodiment of the present application performs the node pruning operation shown above on the planned set of transfer points between any two transportation stations, thereby determining the transfer points to be retained and the transfer points to be removed between any two transportation stations, thereby forming a reserved set of transfer points between any two transportation stations, which is used for searching for multi-trip paths to be recommended between the subsequent user destination and the user's departure point.

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

[0132] It should be noted that for the travel service platform, offline processing such as the offline route planning stage refers to the preprocessing and calculation performed by the travel service platform, and the offline processing is not directly facing the user; online processing such as online route services refers to the processing performed by the travel service platform for the user.

[0133] As an optional implementation, Figure 6The flowchart of the online path service provided by the embodiment of the present application is exemplarily shown. Figure 6 The process shown can be regarded as a real-time response process of the travel service platform based on user requests, searching for recommended one-way routes and multi-way routes for users, referring to Figure 6 , the process may include the following steps.

[0134] Step S610, determining the user's departure point and the user's destination.

[0135] In an optional implementation, the user can input information such as the user's departure place and the user's destination through the page provided by the travel service platform, so that the travel service platform can determine the departure place and destination given by the user. The departure place given by the user is the user's departure place, and the destination given by the user is the user's destination. For example, when a user uses the travel service platform to search for air tickets, train tickets and other transportation tickets, the user can enter information such as the user's departure place and the user's destination on the search page; for another example, when a user requires the travel service platform to provide a travel plan, the user can enter the user's departure place 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 place to the user's destination. The travel plan is not limited to a single mode of transportation, and can be a combination of multiple modes of transportation. In an optional implementation, the embodiment of the present application supports users to give one or more user departure places, and supports users to give one or more user destinations.

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

[0137] The relevant contents of the graph data can refer to the previous description and will not be expanded here. Based on the pre-constructed graph data, step S620 determines the one-way path to be recommended between the user's departure point and the user's destination by performing a path search in the graph data. The path search algorithm used in the path search may include but is not limited to a depth-first search algorithm, a breadth-first search algorithm, a heuristic search algorithm, etc. For example, the embodiment of the present application can determine the node corresponding to the user's departure point in the graph data (referred to as the user's departure point node), and the node corresponding to the user's destination in the graph data (referred to as the user's destination node), so as to search in the graph data through the path search algorithm, and connect the user's departure point node and the user's destination node. The traffic schedule edge is used to obtain the one-way path to be recommended. In other words, the one-way path to be recommended starts from the user's departure point node, passes through the searched traffic schedule edge connected to the user's destination node, and reaches the user's destination node.

[0138] Furthermore, when searching for a one-way route to be recommended, a search constraint condition for the traffic schedule edge can be introduced. The search constraint condition for the traffic schedule edge should at least include a constraint on ticket inventory, so as to constrain the ticket inventory data (included in the edge attribute) of the traffic schedule edge to meet the ticket inventory requirement, such as the ticket inventory value corresponding to the ticket inventory data of the traffic schedule edge meets the ticket inventory value requirement, or the ticket inventory of the traffic schedule edge is not a situation of no ticket inventory; through the constraint of ticket inventory, the embodiment of the present application can ensure that the searched one-way route to be recommended meets the ticket inventory requirement and can meet the travel needs of users. Furthermore, when searching for a one-way route to be recommended, the search constraint condition for the traffic schedule edge can also include constraints such as price, update timestamp of price library data, transportation mode, and transportation schedule time.

[0139] For example, the search constraints for the traffic schedule edge used when searching for a one-way route to be recommended include but are not limited to: Transportation mode, constraining the type of transportation that can be found on the searched transportation schedule edge, such as train, airplane, etc. Traffic schedule time, constraining the departure time and / or arrival time of the searched traffic schedule edge; Price, constrains the price of the searched transportation schedule edge. The price data of the transportation schedule edge is included in the edge attribute and is updated dynamically; Ticket inventory: The ticket inventory data of the traffic schedule edge should meet the ticket inventory requirements. The ticket inventory data of the traffic schedule edge is included in the edge attributes and is updated dynamically. The update timestamp of the price library data constrains the update timestamp of the price library data of the traffic 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 traffic schedule edge.

[0140] Furthermore, when searching for a one-way route to be recommended, the arrival node of the searched traffic schedule edge is constrained to be the user's destination node.

[0141] Step S630: define a transfer point search constraint condition based on at least a reserved set of transfer points between the user's departure point and the user's destination, search graph data based on the transfer point search constraint condition, and determine a multi-trip path to be recommended from the user's departure point to the user's destination.

[0142] Step S630 determines a multi-trip route to be recommended between the user's departure point and the user's destination by performing a route search in the graph data, such as searching for more than two routes to be recommended, or searching for both two routes and more than two routes to be recommended.

[0143] In an optional implementation, if the offline route planning stage considers planning a two-leg path between transportation stations, and the online route pruning considers the transfer points of the two-leg path, the online route service can consider searching for a two-leg path to be recommended from the user's departure point to the user's destination through a reserved set of transfer points between the user's departure point and the user's destination.

[0144] In an optional implementation, if the offline path planning stage only considers the planning of more than two-leg paths between transportation stations, and the online path pruning only considers the transfer points of more than two-leg paths, the online path service can consider searching for more than two-leg paths to be recommended from the user's departure point to the user's destination through the reserved set of transfer points between the user's departure point and the user's destination. At this time, the two-leg path to be recommended from the user's departure point to the user's destination can rely on the characteristics of the graph data itself for path search, without relying on the reserved set of transfer points between the user's departure point and the user's destination.

[0145] That is to say, for more than two legs of the multi-leg paths to be recommended, the reserved set of transfer points between the user's departure point and the user's destination must be used for search, and whether the two-leg paths use the reserved set of transfer points for search depends on whether the two-leg paths are considered in the offline path planning stage and the online path pruning.

[0146] In an optional implementation, the path search algorithm used to search for the multi-trip path to be recommended may include but is not limited to a depth-first search algorithm, a breadth-first search algorithm, a heuristic search algorithm, etc. When searching for the multi-trip path to be recommended between the user's departure point and the user's destination, the embodiment of the present application introduces a transfer point reservation set between the user's departure point and the user's destination that is updated regularly. Specifically, based on the transfer point reservation set between any two transportation stations that is updated regularly, the transfer point reservation set between the user's departure point node and the user's destination node can be obtained, that is, the transfer point reservation set between the user's departure point and the user's destination, which includes the transfer points reserved between the user's departure point node and the user's destination node; Furthermore, based on the reserved set of transfer points between the user's departure point and the user's destination, the transfer point search constraints during the multi-trip path search are defined. Then, a multi-trip path (such as two or more trips of various lengths, or a two-trip path and two or more trips of various lengths) starting from the user's departure point node, passing through one or more transfer points that meet the transfer point search constraints, and finally reaching the user's destination node can be searched in the graph data, thereby obtaining a multi-trip path to be recommended from the user's departure point to the user's destination.

[0147] Furthermore, when performing a multi-trip path search, the transfer point search constraint can be included in the search constraint of the traffic schedule edge and the search constraint of the transfer edge. Specifically, the search constraint of the traffic schedule edge is used to constrain the searched traffic schedule edge. When searching for a multi-trip path to be recommended, the transfer point search constraint is included in the search constraint of the non-last trip traffic schedule edge, which is used to constrain the arrival node of the non-last trip traffic schedule edge to belong to the reserved transfer point; for example, for a multi-trip path of any length, the transfer point search constraint is used to constrain the arrival node of the non-last trip traffic schedule edge to belong to the reserved transfer point, wherein the arrival node of the last trip traffic schedule edge should be the user's destination node. The transfer edge search constraint is used to constrain the searched transfer edge. In the transfer edge search constraint, the transfer point search constraint is used to constrain the arrival node of the transfer edge to belong to the reserved transfer point.

[0148] Furthermore, when searching for a multi-trip route to be recommended, the search constraint conditions of the traffic schedule edge may include at least the ticket inventory constraint of the traffic schedule edge in addition to the reserved transfer points, so as to constrain the ticket inventory of the searched traffic schedule edge, thereby ensuring that the searched multi-trip route to be recommended meets the ticket inventory requirement and can meet the travel needs of users. Furthermore, when searching for a multi-trip route to be recommended, the search constraint conditions of the traffic schedule edge may also include constraints such as price, update timestamp of price database data, transportation mode, and transportation schedule time.

[0149] For example, the search constraints for the traffic schedule edge are as follows: Transportation mode, constraining the type of transportation that can be found on the searched transportation schedule edge, such as train, airplane, etc. Traffic schedule time, constraining the departure time and / or arrival time of the searched traffic schedule edge; Arrival node, constrains the arrival node of the searched traffic schedule edge. When the arrival node of the traffic schedule edge is not the destination node, the arrival node of the traffic schedule edge corresponds to the transfer node, which is defined by the transfer point search constraint condition; specifically, the arrival node of the non-last trip traffic schedule edge (i.e., the transfer point involved in the multi-trip path to be recommended) is determined by the reserved set of transfer points between the user's departure point and the user's destination; Price, constrains the price of the searched transportation schedule edge, and the price data is included in the edge attribute of the transportation schedule edge; Ticket inventory, constrains the ticket inventory of the searched traffic schedule edge. Specifically, the ticket inventory data in the edge attribute of the searched traffic schedule edge should meet the ticket inventory requirements. For example, the ticket inventory value corresponding to the ticket inventory data of the traffic schedule edge meets the ticket inventory value requirement, or the ticket inventory of the traffic schedule edge is not a situation of no ticket inventory. The update timestamp of the price library data constrains the update timestamp of the price library data of the traffic 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 traffic schedule edge.

[0150] For example, the search constraints for transit edges are as follows: Transfer time, constrains the time taken to search for transfer edges; The arrival node constrains the arrival node of the transit edge searched, corresponding to the transit node, which is defined by the transit point search constraint; specifically, the arrival node of the transit edge (i.e., the transit point involved in the multi-trip path to be recommended) is determined by the reserved set of transit points between the user's departure point and the user's destination.

[0151] In an optional implementation example, taking the example of a reserved set of transfer points applicable to searching for two-leg routes to be recommended, an embodiment of the present application may search in the graph data through a path search algorithm for two-leg traffic schedule edges corresponding to the search constraints of the traffic schedule edges; or, an embodiment of the present application may search in the graph data through a path search algorithm for two-leg traffic schedule edges corresponding to the search constraints of the traffic schedule edges, and a transfer edge corresponding to the search constraints of the transfer edge, and the two-leg traffic schedule edges are connected through the transfer edge.

[0152] It should be noted that there are two situations for the two-way path between the user's departure point and the user's destination: In the first case, the transportation stations of the two transportation routes from the user's departure point to the user's destination are continuous, that is, the transportation stations of the first transportation route edge and the second transportation route edge are continuous, for example, the arrival node of the first transportation route edge is the departure node of the second transportation route edge; In the second case, the transportation stops of the two transportation routes from the user's departure point to the user's destination are not continuous, and there are transfer edges. For example, the arrival node of the first transportation route edge is the departure node of the transfer edge, and the arrival node of the transfer edge is the departure node of the second transportation route edge.

[0153] As an optional implementation example, taking the second case of the above two-way path as an example, Figure 7 The flowchart of determining the two-way path to be recommended provided by the embodiment of the present application is shown as an example, referring to Figure 7 , the process may include the following steps.

[0154] Step S710, at least retain a set of transfer points between the user's departure point and the user's destination, define the search constraints of the first-leg transportation schedule edge, and search for the first-leg transportation schedule edge in the graph data, starting from the user's departure point node, based on the search constraints of the first-leg transportation schedule edge.

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

[0156] For example, the search constraints for the first-leg transportation schedule edge include: transportation mode, which constrains the type of transportation on the first-leg transportation schedule edge; transportation schedule time, which constrains the departure time and / or arrival time of the first-leg transportation schedule edge; arrival node, which constrains the arrival node of the first-leg transportation schedule edge, which is a node for transfer between the two paths and is determined by the reserved transfer point; price, which constrains the price of the first-leg transportation schedule edge; ticket inventory, which constrains the ticket inventory on the first-leg transportation schedule edge; update timestamp of price library data, which constrains the update timestamp of price library data on the first-leg transportation schedule edge.

[0157] Step S720, at least retain a set of transfer points between the user's departure point and the user's destination, define search constraints for transfer edges, and search for transfer edges in the graph data, starting from the arrival node of the first-leg traffic schedule edge, based on the search constraints for transfer edges.

[0158] In this implementation example, the searched transfer edge represents the transfer process corresponding to the arrival node of the first-leg traffic schedule edge to the departure node of the second-leg traffic schedule edge, that is, from the arrival node of the first-leg traffic schedule edge, through the transfer edge, to the departure node of the second-leg traffic schedule edge. For example, the search constraints of the transfer edge are as follows: transfer time, which constrains the time from the arrival node of the first-leg traffic schedule edge to the departure node of the second-leg traffic schedule edge; arrival node, which constrains the arrival node of the transfer edge, and the arrival node of the transfer edge is also the departure node of the second-leg traffic schedule edge, which is a node for transfer between the two paths, and is determined by the reserved transfer point.

[0159] Step S730, starting from the arrival node of the transfer edge in the graph data, based on the search constraint condition of the second leg traffic schedule edge, search for the second leg traffic schedule edge, and the arrival node of the second leg traffic schedule edge is the user destination node.

[0160] In this implementation example, the second-leg traffic schedule edge connects the arrival node of the transfer edge and the user destination node, that is, the arrival node of the second-leg traffic schedule edge is the user destination node, so that 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-leg traffic schedule edge. For example, the search constraints of the second-leg traffic schedule edge include: the transportation mode, traffic schedule time, arrival node (the arrival node of the second-leg traffic schedule edge is constrained to be the user destination node), price, ticket inventory, and update timestamp of price library data.

[0161] Step S740: Based on the searched first-leg traffic schedule edge, transfer edge, and second-leg traffic schedule edge, a two-leg route to be recommended from the user's departure point to the user's destination is formed.

[0162] In this implementation example, the embodiment of the present application defines a user departure node and a user destination node, and gradually searches in the graph data for a first-leg transportation schedule edge that satisfies the search constraints of the first-leg transportation schedule edge, a transfer edge that satisfies the search constraints of the transfer edge, and a second-leg transportation schedule edge that satisfies the search constraints of the second-leg transportation schedule edge, and the transfer points involved in the two-leg path are determined by a reserved set of transfer points between the user's departure point and the user's destination, thereby forming a two-leg path to be recommended that starts from the user's departure node, passes through two-leg transportation schedules and intermediate transfers, and finally arrives at the user's destination node, and the two-leg path to be recommended has ticket inventory, thereby meeting the user's travel needs.

[0163] The search for more than two routes to be recommended can be referred to in a similar way, that is, when the user's departure node and the user's destination node are defined, the nodes passed by the more than two routes are searched step by step, and the passed nodes satisfy the transfer point search constraints (determined by the reserved set of transfer points between the user's departure point and the user's destination), so as to finally search for more than two routes to be recommended with ticket inventory. The specific content can be referred to the previous description in a similar way and will not be expanded here.

[0164] That is to say, in the graph data, the multi-trip path to be recommended starts from the user departure node corresponding to the user departure place, passes through multiple searched traffic schedule edges, or passes through multiple searched traffic schedule edges and at least one transfer edge, and arrives at the user destination node corresponding to the user destination; wherein, the number of searched traffic schedule edges depends on the specific number of trips of the multi-trip path; and, the traffic schedule edges are searched based on the search constraints of the traffic schedule edges, and the transfer edges are searched based on the search constraints of the transfer edges; the transfer point search constraints are included in the search constraints of the traffic schedule edges, which are used to constrain the arrival nodes of the traffic schedule edges; the transfer point search constraints are included in the search constraints of the transfer edges, which are used to constrain the arrival nodes of the transfer edges.

[0165] In a further optional implementation, there may be multiple multi-trip paths of various lengths from the user's departure point to the user's destination that are searched. For example, when searching for a two-trip path, starting from the user's departure point node, different first-trip traffic schedule edges, different transfer edges, and different second-trip traffic schedule edges that meet the transfer point search constraint conditions may be searched in the graph data, so that there are multiple two-trip paths that are searched; for any multi-trip path of any length, the embodiment of the present application can sort the searched multi-trip paths according to the path duration, and limit the number of multi-trip paths of various lengths to be recommended, so that for any multi-trip path of any length, the multi-trip path with the shortest path duration and corresponding to the number to be recommended is used as the multi-trip path to be recommended; for example, each searched two-trip path is sorted according to the path duration, and the number of two-trip paths to be recommended is limited, so that the two-trip path with the shortest path duration and corresponding to the number to be recommended is used as the two-trip path from the user's departure point to the user's destination to be recommended.

[0166] In a further optional implementation, the embodiment of the present application can be implemented based on the query language of graph data and an integrated path search algorithm when searching for one-way paths to be recommended and multi-trip paths of various lengths to be recommended. The query language of graph data, such as ISOGQL (International Standard Open Graph Query Language), is used to retrieve information from a graph data structure; by way of example, the query language of graph data may include transit point search constraints to constrain the nodes passed during the multi-trip path search to belong to a reserved set of transit points between the user's departure point and the user's destination. Specifically, the embodiments of the present application can construct path search requests of various lengths through the query language of graph data according to different path search requirements, thereby obtaining path search results of various lengths; for example, according to the path search requirements of various lengths, search constraints corresponding to the paths of various lengths are set (for example, constraints on transportation travel modes, departure and arrival times of transportation schedules, prices, ticket inventory, update timestamps of price library data, transfer points of multi-trip paths, etc.), thereby forming path search requests of various lengths, and then based on the graph data, executing the path search requests of various lengths, obtaining path search results of various lengths, that is, one-way paths to be recommended and multi-trip paths to be recommended.

[0167] 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 from the user's departure point to the user's destination, without involving transfers; for a two-way path, the path search request may limit the path search to a reserved set of transfer points between the user's departure point and the user's destination, and may further limit ticket inventory, price, transportation mode, time information for each trip, etc.; for paths with more than two legs, such as three legs or more, the path search request involves constraints on multiple transfers (the constrained transfer points are transfer points reserved between the user's departure point and the user's destination), and may further involve constraints on ticket inventory, price, transportation mode, time information for each trip, etc.

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

[0169] After determining the one-way paths and multi-way paths to be recommended from the user's departure point to the user's destination, the embodiment of the present application can group the one-way paths and multi-way paths to be recommended into a path set to be recommended, so that the path set to be recommended includes multiple paths to be recommended (such as one-way, two-way, three-way and other paths of various lengths to be recommended) to facilitate the subsequent travel plan mixed arrangement personalized output stage processing.

[0170] It needs to be further explained that Figure 5A The process shown is executed regularly by the travel service platform. Figure 6 The process shown requires the travel service platform to respond to user requests in real time, that is, when the user gives the user's destination and the user's departure point, a timely response is required; thus, Figure 5A The process shown and Figure 6 The illustrated process may be performed asynchronously.

[0171] The travel plan mixed arrangement personalized output stage 240 is used to sort the multiple recommended routes according to the user's preference, and then recommend the sorted multiple routes as the travel plan recommendation results to the user.

[0172] In an optional implementation, the embodiment of the present application can use a recommendation scoring model to score each recommended path based on user preferences to obtain a ranking score of each recommended path; thereby, the multiple recommended paths are sorted in descending order according to the ranking scores of each recommended path, and the sorted multiple paths are obtained as the recommended results of the travel plan and recommended to the user. For example, the recommendation scoring model includes the LR (Logistic Regression) model, the DIN (Deep Interest Network) model, and the like.

[0173] As an optional implementation, Fig. 8A The flowchart for sorting multiple paths to be recommended provided by the embodiment of the present application is exemplarily shown. Figure 8B The following is an example diagram showing the processing of the recommendation scoring model. Fig. 8A and Figure 8B As shown, the process of sorting multiple paths to be recommended may include the following steps.

[0174] Step S810, obtaining user basic features, user behavior features, user search context features, and features of the path to be recommended.

[0175] In an optional implementation, the input data of the recommendation scoring model includes but is not limited to: User basic characteristics, such as gender, age, and other basic information; The 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; User behavior characteristics are divided into historical behavior characteristics and real-time behavior characteristics. The historical behavior characteristics of users, such as the historical purchase sequence formed by the historical ticket purchase information of users on the travel service platform, are used to analyze the user's preferences for the price and time consumption of transportation tickets; the real-time behavior characteristics of users, such as the real-time click behavior information of users on the pages provided by the travel service platform, are used to analyze the user's real-time preferences; The characteristics of the path to be recommended, that is, the characteristics of the path to be recommended that the recommendation scoring model currently needs to score; for example, the departure time, arrival time, duration, price, transportation mode and other information of the first leg, the second leg, etc. of the path to be recommended; further, if the path to be recommended is a multi-leg path, the characteristics of the path to be recommended may include transfer information, such as transfer type information, such as transfer at different stations (i.e., transfer at different transportation stations, involving transfer edges between different transportation stations), or transfer at the same station (i.e., transfer at different transportation services at the same transportation station).

[0176] Step S820, based on the user behavior characteristics and the characteristics of the route to be recommended, determining the user's preference information on various travel preference factors for the route to be recommended.

[0177] The embodiments of the present application can set multiple travel preference factors to indicate the user's travel preferences, including but not limited to price, travel time, departure time, number of transfers, arrival time, transfer destination, etc., so that the embodiments of the present application can determine the user's preference information on various travel preference factors for the path to be recommended based on the user's behavior characteristics and the characteristics of the path to be recommended, such as the user's preference information on price, travel time, departure time, number of transfers, arrival time, transfer destination, etc. for the path to be recommended, to indicate the degree to which the path to be recommended is preferred by the user in terms of various travel preference factors.

[0178] In an optional implementation, the recommendation scoring model can set attention modules corresponding to various travel preference factors, so that different attention modules can focus on the user's preference information for the recommended route in terms of different travel preference factors. For example, taking the three travel preference factors of price, travel time, and departure time as an example, Figure 8B As shown in the figure, the recommendation scoring model is set up with three attention modules, namely: The price attention module focuses on the user's price preference, and thus determines the user's price preference for the path to be recommended based on the user's behavior characteristics and the characteristics of the path to be recommended; The time-consuming attention module focuses on the user's preference for travel time, and thus determines the user's preference for travel time for the recommended route based on the user's behavior characteristics and the characteristics of the route to be recommended; 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 route to be recommended based on the user's behavior characteristics and the characteristics of the route to be recommended.

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

[0180] Step S830: Based on the characteristics of the path to be recommended, determine the monotonicity information of the time consumption and price of the path to be recommended.

[0181] The recommendation scoring model is provided with a monotonic network module, which can make the recommendation scoring model focus on the monotonicity of price and time consumption. For example, the shorter the time consumption and the lower the price, the better the monotonicity is set to ensure that the prediction of the recommendation scoring model is consistent with the user's cognition. For example, a travel plan with a short time and a low price is more likely to be accepted by most users. Therefore, when scoring the recommended path, the characteristics of the path to be recommended (such as the time consumption and price in the characteristics 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.

[0182] Step S840 , concatenating the user basic features, the user search context features, the user preference information on various travel preference factors for the route to be recommended, the monotonicity information, and the features of the route to be recommended to form an overall feature vector.

[0183] The recommendation scoring model is set up with a splicing layer; thus, the user's basic features, the user's search context features, and the output of each attention module (such as Figure 8B The outputs of the price attention module, the time-consuming attention module, and the departure time attention module of the example), 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.

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

[0185] The recommendation scoring model is provided with a multi-layer perceptron layer; the overall feature vector after splicing by the splicing 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 nonlinear transformation to obtain the ranking score of the path to be recommended; wherein the multi-layer perceptron layer is composed of at least multiple fully connected layers.

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

[0187] Step S860: sort the multiple paths to be recommended in descending order based on the ranking scores of the paths to be recommended.

[0188] In an optional implementation, the embodiment of the present application can use a recommendation scoring model to score each path to be recommended, obtain a ranking score for each path to be recommended, and then sort the paths to be recommended in descending order according to the ranking score to form a recommendation result for the travel plan and recommend it to the user.

[0189] In an optional implementation, the travel plan recommendation method provided in the embodiment of the present application can be applied to the smart travel scenario of the travel service platform. The smart travel scenario is used to recommend personalized travel plans for users. Users can enter the user's destination and the user's departure point on the smart travel page provided by the travel service platform, so that the travel service platform can use the travel plan recommendation method provided in the embodiment of the present application to recommend travel plan recommendation results to users (such as multiple routes to be recommended after descending sorting); specifically, the travel plan recommendation results can be displayed on the result page of the smart travel page to recommend to users, so that users can view and select multiple travel plans between the user's destination and the user's departure point, such as direct travel plans with price and ticket inventory information such as airplanes and trains, and multi-trip travel plans with price and ticket inventory information for a combination of multiple transportation modes such as airplanes and trains.

[0190] In an optional implementation, the travel plan recommendation method provided in the embodiment of the present application can be applied to the ticket search scenario of the travel service platform. The ticket search scenario is used to provide users with search results of transportation tickets such as air tickets and train tickets, so that users can enter the user's destination and the user's departure point on the search page of transportation tickets such as air tickets and train tickets on the travel service platform. Then, the travel service platform can use the travel plan recommendation method provided in the embodiment of the present application to recommend travel plan recommendation results to users (such as multiple routes to be recommended after sorting in descending order); specifically, the travel plan recommendation results can be displayed on the search results page of the transportation ticket to recommend it to the user.

[0191] The travel plan recommendation method provided by the embodiment of the present application combines path planning with dynamically updated price library data based on graph data, realizes online search for recommended one-way paths and multi-way paths between the user's departure place and the user's destination, improves the efficiency of path search, and is easy to maintain. By combining offline path planning with online path service and online path pruning, the travel service platform can support the search for multi-way paths to be recommended, especially the search for more than two-way paths to be recommended, breaking through the bottleneck limitation, so that the travel service platform can provide multi-way travel plans with a large number of trips. The embodiment of the present application supports the combination of different transportation modes, and supports the combined use of new transportation modes by adding corresponding nodes, traffic schedule edges and transfer edges in the graph data, reducing the development workload and having strong scalability. The embodiment of the present application supports the search and query of paths with ticket inventory between the user's departure place and the user's destination, and by adding factors such as the reserved transfer point, ticket inventory, price, and update timestamp of the price library data to the search constraints, a variety of factors are comprehensively considered to optimize the searched one-way paths and multi-way paths to be recommended between the user's departure place and the user's destination. In terms of path recommendation sorting, the embodiments of the present application can sort the recommended paths according to user preferences to ensure that the results recommended to the user meet the user's needs and preferences.

[0192] The embodiment of the present application also provides a travel plan recommendation system, which is applied to a travel service platform. The relevant contents of the travel plan recommendation system described below can be referenced to the contents described above.

[0193] In an optional implementation, Fig. 9 The block diagram of the travel plan recommendation system provided in the embodiment of the present application is shown as an example. The travel plan recommendation system can be applied to the travel service platform. Specifically, the travel plan recommendation system implements the travel plan recommendation method provided in the embodiment of the present application through a modular functional architecture.

[0194] Reference Fig. 9 , the travel plan recommendation system can include: The online path search module 910 is used to determine the user's departure place and the user's destination; according to the user's departure place and the user's destination, search the graph data to determine the one-way path to be recommended from the user's departure place to the user's destination; wherein the graph data includes a plurality of nodes and 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 direct transportation schedules between transportation stations, the transfer edges represent non-transportation schedule transfers between transportation stations, and the transportation schedule edges have dynamically updated price library data; and, at least based on the user's departure place and the user's destination, the user's departure place and the user's destination are searched for graph data to determine the one-way path to be recommended from the user's departure place to the user's destination; wherein the graph data includes a plurality of nodes and 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 direct transportation schedules between transportation stations, the transfer edges represent non-transportation schedule transfers between transportation stations, and the transportation schedule edges have dynamically updated price library data; and The reserved set of transfer points between the user's destination defines a transfer point search constraint condition, searches the graph data based on the transfer point search constraint condition, and determines a multi-trip path to be recommended from the user's departure point to the user's destination, wherein the multi-trip path passes through the transfer point; wherein the reserved set of 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 status of the transportation schedule edge associated with the transfer point; based on the one-way path to be recommended and the multi-trip path to be recommended, multiple paths to be recommended are formed; The sorting and recommendation module 920 is used to sort the multiple recommended paths according to user preferences and use the sorted multiple paths as the recommendation results of the travel plan.

[0195] 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. The relevant content can be referred to in the previous description. The sorting recommendation module can be regarded as the modularization of the mixed arrangement and personalized output stage of the travel plan.

[0196] In an optional implementation, the multi-trip path to be recommended starts from the user departure node corresponding to the user departure point, passes through the searched multiple traffic schedule edges, or passes through the searched multiple traffic schedule edges and at least one transfer edge, and arrives at 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 searched traffic schedule edges connected to the user destination node, and arrives at the user destination node; wherein the traffic schedule edges are searched based on the search constraints of the traffic schedule edges, and the transfer edges are searched based on the search constraints of the transfer edges; When searching for a multi-trip path to be recommended, the transfer point search constraint condition is included in the search constraint condition of the non-last trip traffic schedule edge, which is used to constrain the arrival node of the non-last trip traffic schedule edge. The transfer point search constraint condition is included in the search constraint condition of the transfer edge, which is used to constrain the arrival node of the transfer edge.

[0197] In an optional implementation, the reserved set of transfer points between any two transportation stations is updated regularly based on the path planning set between the any two transportation stations, the corresponding transfer point planning set, and the ticket inventory of the transportation schedule edge associated with the transfer point, and the path planning set and the transfer point planning set are pre-generated based on the graph data; Among them, for any two transportation stations, the path planning set includes multiple multi-trip paths planned for the two transportation stations, and each planned multi-trip path contains a traffic schedule edge; for any two transportation stations, the transfer point planning set includes the transfer points passed by the planned multi-trip paths.

[0198] Further, combined with Fig. 9 As shown, the travel plan recommendation system may also include: The online path pruning module 930 is used to predict the ticket inventory status of each traffic schedule edge at a future moment for each traffic schedule edge included in the path planning set between any two transportation stations, and obtain the ticket inventory prediction result of the traffic schedule edge; for the transfer point planning set between any two transportation stations, based on the ticket inventory prediction results of the traffic schedule edges associated with each transfer point, determine the transfer points to be removed and the transfer points to be retained, and obtain the transfer point retention set between any two transportation stations.

[0199] The online path pruning module can be regarded as the modularization of the online path pruning in the online path service and pruning phase. The relevant content can refer to the previous description.

[0200] Further, combined with Fig. 9 As shown, the travel plan recommendation system may also include: The offline path planning module 940 is used to generate multiple multi-trip paths between any two transportation stations based on a graph database and a path search algorithm; for each multi-trip path between any two transportation stations, the value score of the multi-trip path is evaluated according to multiple path evaluation features to obtain the value score of each multi-trip path between any two transportation stations; for any two transportation stations, the multi-trip path planned between the two transportation stations is determined according to the value score of each multi-trip path between the two transportation stations to form a path planning set between any two transportation stations; and, for any two transportation stations, the transfer nodes passed by the multi-trip path planned between the two transportation stations are determined to form a transfer point planning set between any two transportation stations.

[0201] The offline path planning module can be regarded as the modularization of the offline path planning stage. The relevant content can refer to the previous description.

[0202] As an optional implementation, the sorting recommendation module 920 is used to sort the multiple paths to be recommended according to the user preference, including: Obtain user basic features, user behavior features, user search context features, and features of the path to be recommended; determine the user's preference information for the path to be recommended in various travel preference factors based on the user behavior features and the features of the path to be recommended; determine the monotonicity information of the path to be recommended in terms of time consumption and price based on the features of the path to be recommended; concatenate the user basic features, the user's search context features, the user's preference information for the path to be recommended in various travel preference factors, the monotonicity information, and the features of the path to be recommended to form an overall feature vector; perform multi-layer nonlinear transformation on the overall feature vector to obtain a ranking score for the path to be recommended; and sort the multiple paths to be recommended in descending order based on the ranking scores of the paths to be recommended.

[0203] Further, combined with Fig. 9 As shown, the travel plan recommendation system may also include: The 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; set transportation schedule edges and transfer edges between nodes based on the transportation travel relationship between transportation stations; set edge attributes for transportation schedule edges, and set edge attributes for transfer edges; according to the price library data of the transportation schedule, use a cache mechanism as the edge attributes of the transportation schedule edges corresponding to the transportation schedule to update the price storage data; wherein the price library data of the transportation schedule is derived from multiple price library databases and / or exposure data of ticket search, and a price library database records real-time price library data of each transportation schedule of at least one transportation travel mode.

[0204] The graph data construction module can be regarded as the modularization of the dynamic graph data construction stage. The relevant content can refer to the previous description.

[0205] In a further optional implementation, the embodiment of the present application also provides a travel server, which is regarded as a server or server cluster set up in the travel service platform; in an optional 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 in the embodiment of the present application.

[0206] In a further optional implementation, the embodiment of the present application also provides a storage medium, which stores computer execution instructions. When the computer execution instructions are executed (for example, 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.

[0207] In a further optional implementation, the embodiment of the present application also provides a computer program product, including computer execution instructions. When the computer execution instructions are executed (for example, 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.

[0208] The above describes multiple implementation schemes provided by the embodiments of the present application. The various optional methods introduced in each implementation scheme can be combined and cross-referenced with each other without conflict, thereby extending a variety of possible implementation schemes, which can all be considered as implementation schemes disclosed and open in the embodiments of the present application.

[0209] Although the embodiments of the present application are disclosed above, the present application is not limited thereto. Any person skilled in the art may make various changes and modifications without departing from the spirit and scope of the present application. Therefore, the scope of protection of the present application shall 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 point and the user's destination; According to the user's departure place and the user's destination, the graph data is searched to determine the one-way path to be recommended from the user's departure place to the user's destination; wherein the graph data includes a plurality of nodes and 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 direct transportation schedules between transportation stations, the transfer edges represent non-transportation schedule transfers between transportation stations, and the transportation schedule edges have dynamically updated price library data; And, at least a reserved set of transfer points between a user's departure point and a user's destination is used to define a transfer point search constraint condition, and based on the transfer point search constraint condition, graph data is searched to determine a multi-trip path to be recommended from the user's departure point to the user's destination, wherein the multi-trip path passes through the transfer point; wherein the reserved set of 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 status of the transportation schedule edge associated with the transfer point; Based on the one-way path to be recommended and the multi-way path to be recommended, forming a plurality of paths to be recommended; According to user preferences, the multiple recommended paths are sorted, and the sorted multiple paths are used as recommendation results of travel plans.

2. The method according to claim 1, characterized in that The reserved transfer point set between any two transportation stations is regularly updated based on the path planning set between the any two transportation stations, the corresponding transfer point planning set, and the ticket inventory of the transportation schedule edge associated with the transfer point, and the path planning set and the transfer point planning set are pre-generated based on the graph data; Among them, for any two transportation stations, the path planning set includes multiple multi-trip paths planned for the two transportation stations, and each planned multi-trip path contains a traffic schedule edge; for any two transportation stations, the transfer point planning set includes the transfer points passed by the planned multi-trip paths.

3. The method according to claim 2, characterized in that The method further comprises: For each traffic schedule edge included in the path planning set between any two traffic stations, the ticket inventory of the traffic schedule edge at the future time is predicted respectively, and the ticket inventory prediction result of the traffic schedule edge is obtained; For the planned set of transfer points between any two transportation stations, based on the ticket inventory prediction results of the transportation schedule edges associated with each transfer point, the transfer points to be eliminated and retained are determined to obtain the reserved set of transfer points between any two transportation stations.

4. The method according to claim 2, characterized in that: The method further comprises: Based on the graph database, a path search algorithm is used to generate multiple multi-trip paths between any two transportation stations; For each multi-trip path between any two transportation stations, the value score of the multi-trip path is evaluated according to a plurality of path evaluation features, so as to obtain the value score of each multi-trip path between any two transportation stations; For any two transportation stations, the multi-trip paths planned between the two transportation stations are determined according to the value score of each multi-trip path between the two transportation stations, forming a path planning set between any two transportation stations; and, for any two transportation stations, the transfer nodes passed by the multi-trip paths planned between the two transportation stations are determined, forming a transfer point planning set between any two transportation stations.

5. The method according to claim 1, characterized in that The multi-trip path to be recommended starts from the user departure node corresponding to the user departure point, passes through the searched multiple traffic schedule edges, or passes through the searched multiple traffic schedule edges and at least one transfer edge, and arrives at 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 searched traffic schedule edge connected to the user destination node, and arrives at the user destination node; Among them, the traffic schedule edge is searched based on the search constraint condition of the traffic schedule edge, and the transfer edge is searched based on the search constraint condition of the transfer edge; When searching for a multi-trip path to be recommended, the transfer point search constraint condition is included in the search constraint condition of the non-last trip traffic schedule edge, which is used to constrain the arrival node of the non-last trip traffic schedule edge. The transfer point search constraint condition is included in the search constraint condition of the transfer edge, which is used to constrain the arrival node of the transfer edge.

6. The method according to claim 1, characterized in that The sorting of the multiple paths to be recommended according to the user preference includes: Obtaining user basic features, user behavior features, user search context features, and features of the path to be recommended; Based on the user behavior characteristics and the characteristics of the route to be recommended, determine the user's preference information on various travel preference factors for the route to be recommended; Based on the characteristics of the path to be recommended, determine the monotonicity information of the path to be recommended in terms of time consumption and price; The user basic features, the user search context features, the user preference information on various travel preference factors for the route to be recommended, the monotonicity information, and the features of the route to be recommended are concatenated to form an overall feature vector; Perform multi-layer nonlinear transformation on the overall feature vector to obtain the ranking score of the path to be recommended; Based on the ranking score of each path to be recommended, the multiple paths to be recommended are sorted in descending order.

7. The method according to any one of claims 1 to 6, characterized in that: The method further comprises: Represent each traffic station as a node in the graph data, and set node attributes associated with the traffic station for each node; Based on the traffic travel relationship between transportation stations, traffic schedule edges and transfer edges are set between nodes; Set edge attributes for the traffic shift edge and set edge attributes for the transfer edge; According to the price library data of the traffic schedule, the price storage data is updated by using the cache mechanism as the edge attribute of the traffic schedule edge corresponding to the traffic schedule; The price database data of the transportation schedules are derived from multiple price databases and / or exposure data of ticket searches, and a price database records the real-time price database data of each transportation schedule of at least one mode of transportation.

8. A travel plan recommendation system, characterized in that: Applied to a travel service platform, the system includes: The online path search module is used to determine the user's departure place and the user's destination; according to the user's departure place and the user's destination, search the graph data to determine the one-way path to be recommended from the user's departure place to the user's destination; wherein the graph data includes a plurality of nodes and 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 of non-transportation schedules between transportation stations, and the transportation schedule edges have dynamically updated price library data; and, at least based on the user's departure place and the user's destination, the graph data includes a plurality of nodes and 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, and the transfer situations of non-transportation schedules between transportation stations, and the transportation schedule edges have dynamically updated price library data. The reserved set of transfer points between destinations defines transfer point search constraints, and based on the transfer point search constraints, searches the graph data to determine a multi-trip path to be recommended from the user's departure point to the user's destination, wherein the multi-trip path passes through the transfer point; wherein the reserved set of 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 status of the transportation schedule edge associated with the transfer point; based on the one-way path to be recommended and the multi-trip path to be recommended, multiple paths to be recommended are formed; The sorting recommendation module is used to sort the multiple recommended paths according to user preferences and use the sorted multiple paths as the recommendation results of the travel plan.

9. A travel server, characterized in that: It comprises a memory and a processor, wherein the memory stores computer-executable instructions, and the processor calls the computer-executable instructions to execute the travel plan recommendation method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that It includes computer-executable instructions, which, when executed, implement the travel plan recommendation method as described in any one of claims 1 to 7.

Images