Patent Application
20220260376
The embodiments generally relate to computerized systems for real-time rideshare matching using spatio-temporal search methods, and more particularly to computerized systems for rideshare matching in real-time using locality sensitive hashing.
Sharing rides is extremely beneficial for planning urban transportation as it promises to provide a solution for the serious urban challenges of excessive traffic congestion, resource consumption and air pollution, while providing efficient, flexible and affordable mobility options. Real-time information and monitoring of urban mobility as well as the ability to do large scale computation efficiently on the cloud allow on-demand shared mobility platforms to enable real-time sharing of rides at unprecedented levels. Several studies have confirmed the potential of real-time urban-scale ridesharing to reduce the burden on urban transportation. To realize this potential, these platforms must solve the rideshare matching problem of forming rideshare trips where each trip consists of a driver route and one or more riders, minimizing the inconvenience to riders (increased pick-up wait and travel time, detour, etc.) and maximizing the benefits of sharing (reduced cost of serving rides). However, solving this problem in real-time and at urban scale with a match pool of tens of thousands of rides and driver routes is a very hard combinatorial problem and presents formidable computational challenges.
Most successful approaches to solving the rideshare matching problem uses the graph-theoretic notion of shareability networks. The nodes of the network are rides and driver routes in the match pool. Edges of the network can be thought of as potential rideshare matches. An edge between two ride nodes signifies feasibility to serve them together, while an edge between a ride node and a driver route node signifies the feasibility to add the ride to the driver's route.
Once the shareability network is constructed (in particular, potential rideshare matches are known), there are several approaches to combine such matches and form rideshare trips such as dynamic programming, greedy methods, constraint satisfaction programs etc. Computing the shareability network in real time is computationally very hard. Brute force comparison of every pair of nodes has a quadratic complexity and is ruled out.
Prior works for constructing shareability networks are all heuristic methods. These prior solutions have a number of shortcomings. For example, these solutions only compare and form edges between spatially nearby nodes (rides and driver routes). While some compute haversine overlap between nodes to find edges of the network. The heuristic methods have several disadvantages including limited trip choices, lack of robustness, ignorance of the road network, inability to handle realistic cost functions, and insensitivity to real-time traffic conditions. Those having limited trip choices lose achievable match utility due to ignoring trips between non-nearby nodes (especially problematic if some rides are pre-scheduled and thus can be far away without violating pickup constraints). The lack of robustness manifests when many rides arrive at the same time within a geographically constrained area (train stations, concert venues), which results in the heuristic of comparing nearby nodes fail. Heuristics which have ignorance of the road network are insensitive to the real road network, and thus lose match utility. Heuristics having inability to handle realistic cost functions depend only on the distance metric and cannot optimize for realistic cost functions. Ride costs often depend on a combination of several factors such as time, distance, tolls, fees etc. Heuristics which are insensitive to real-time traffic conditions are unable to adapt to real-time traffic conditions such as weather, events, construction zones, accidents, etc.
This summary is provided to introduce a variety of concepts in a simplified form that is disclosed further in the detailed description of the embodiments. This summary is not intended to identify key or essential inventive concepts of the claimed subject matter, nor is it intended for determining the scope of the claimed subject matter.
The embodiments provided herein relate to a system for rideshare matching using locality sensitive hashing is disclosed, including at least one rider device and at least one driver device in operable connection with a network. A rideshare application is in operable communication with the network and configured for matching a driver to a rider within a match pool via an artificial intelligence engine operating a locality sensitive hashing module.
A method for rideshare matching using locality sensitive hashing is disclosed, including constructing a space-time discretized route for each of a plurality of ride routes and driver routes. Next a preprocessing vector representation is constructed for each of the plurality of ride routes and driver routes. A locality sensitive hashing data structure is constructed with the preprocessing vector representations. Further, a query vector representation is constructed for each of the plurality of ride routes and driver routes. A matching ride route and driver route is found for each ride request using the locality sensitive hashing data structure and at least one rideshare trip is constructed from the retrieved potential matches.
In one aspect, the method provided herein can handle rides and driver routes uniformly due to its rigorous mathematical formulation of the problem. The method is efficient in runtime as it employs the Artificial Intelligence search technique of locality sensitive hashing that works very well with high dimensional data, allowing its use in real-time.
In one aspect, the method is robust as it is not based on the assumption of having only a few rides within a geographical constrained area at a given time and is based on principled, robust and scalable search techniques instead.
In one aspect, the method does not lose efficiency by restricting trips to be formed only between nearby rides and driver routes. Rather, it searches for potential matches with best match utilities globally in the match pool.
In one aspect, the method exploits the knowledge of the real physical road network which the prior works do not. This contributes significantly to its optimality in terms of match utility.
In one aspect, the method effectively adapts to real-time traffic conditions which prior works do not. Such real-time traffic conditions include weather, events, road closures, diversions, constructions, accidents etc. that can change the cost of routes.
In one aspect, the method can handle all linear functions for defining cost of routes and, hence, match utility. A linear cost function is such that the total cost along a route is the sum of the costs incurred along the route segments. This includes almost all realistic cost functions such as distance travelled, time of travel, tolls and fees along the route etc., and any linear combination of these. Prior works mostly consider only the distance cost function.
In one aspect, the method can handle both current rides and future pre-scheduled rides together in the same match pool, providing additional matching utility and marketplace efficiency.
A complete understanding of the present embodiments and the advantages and features thereof will be more readily understood by reference to the following detailed description when considered in conjunction with the accompanying drawings wherein:
The specific details of the single embodiment or variety of embodiments described herein are to the described system and methods of use. Any specific details of the embodiments are used for demonstration purposes only, and no unnecessary limitations or inferences are to be understood thereon.
Before describing in detail exemplary embodiments, it is noted that the embodiments reside primarily in combinations of components and procedures related to the system. Accordingly, the system components have been represented, where appropriate, by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present disclosure so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.
In general, the embodiments provided herein relate to a system and method of rideshare matching based on the Artificial Intelligence technique of locality sensitive hashing (LSH). LSH is a technique for efficient similarity search employed in a wide variety of engineering and scientific domains. However, its use had not been introduced for rideshare matching in the prior art. The method and system for efficient rideshare matching in real-time from a match pool of tens of thousands of ride requests (henceforth simply called rides) and driver routes is provided to efficiently and effectively match rides with suitable drivers. The method depends on a novel efficient randomized spatio-temporal search algorithm.
The embodiments include a novel efficient randomized spatio-temporal search method for finding potential rideshare matches. As stated above, once the potential matches are found efficiently, rideshare trips can be constructed using a variety of approaches such as dynamic programming, greedy methods, solving constraint satisfaction programs etc. and the rideshare matching problem can be solved. The method works by transforming the potential match finding problem into a similarity search problem and employing the technique of locality sensitive hashing for similarity search.
The method includes the steps of transforming rides and driver routes into vector representations in a high-dimensional space capturing their essential spatial properties (physical route in the real road network) as well as temporal properties (arrival time, service time constraints etc.). Next, the method includes the step of deriving a similarity measure for this vector space that captures the notion of match utility, rides and driver routes with high utility from being matched together have similar representations (according to the defined similarity measure); while those that are not feasible to be matched together or have low utility from being matched together have dissimilar representations. The method further includes the step of employing locality sensitive hashing technique for similarity searches in this space. This amounts to finding, for each ride, top rides and driver routes with highest match utility with it.
The system utilizes the artificial intelligence technique of locality sensitive hashing. A vector representation for rides and driver routes is provided which preserves their essential spatio-temporal features important for rideshare matching (physical route in the real road network, time of arrival, maximum allowed delay etc.). The system provides a similarity measure on spatio-temporal vector representations for rides and driver routes that capture utility of matching them together.
The method can very efficiently incorporate the information of the real road network in making ride matching decisions. Further, the method can work with a hybrid match pool of current as well as future pre-scheduled rides. Any cost function can be handled while defining the utility of matching as long as it is linear in the route (I.e., the total cost along a route is the sum of costs incurred along the segments of the route). Examples include distance traveled, time of travel, tolls and fees along the route, etc. or any linear combination of these. The method is dynamic and can adapt to changing traffic conditions (weather, accidents, events, closures, constructions etc.) as costs of route segments change (as long as this information is available in real-time which is the case with most modern routing systems). Prior heuristic methods are static and do not adapt.
Processors 110 suitable for the execution of a computer program include both general and special purpose microprocessors and any one or more processors of any digital computing device. The processor 110 will receive instructions and data from a read-only memory or a random-access memory or both. The essential elements of a computing device are a processor for performing actions in accordance with instructions and one or more memory devices for storing instructions and data. Generally, a computing device will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks; however, a computing device need not have such devices. Moreover, a computing device can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive).
A network interface may be configured to allow data to be exchanged between the computer system 100 and other devices attached to a network 130, such as other computer systems, or between nodes of the computer system 100. In various embodiments, the network interface may support communication via wired or wireless general data networks, such as any suitable type of Ethernet network, for example, via telecommunications/telephony networks such as analog voice networks or digital fiber communications networks, via storage area networks such as Fiber Channel SANs, or via any other suitable type of network and/or protocol.
The memory 120 may include application instructions 150, configured to implement certain embodiments described herein, and a database 160, comprising various data accessible by the application instructions 150. In one embodiment, the application instructions 150 may include software elements corresponding to one or more of the various embodiments described herein. For example, application instructions 150 may be implemented in various embodiments using any desired programming language, scripting language, or combination of programming languages and/or scripting languages (e.g., C, C++, C#, JAVA®, JAVASCRIPT®, PERL®, PYTHON, GOLANG etc.).
The steps and actions of the computer system 100 described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium may be coupled to the processor 110 such that the processor 110 can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integrated into the processor 110. Further, in some embodiments, the processor 110 and the storage medium may reside in an Application Specific Integrated Circuit (ASIC). In the alternative, the processor and the storage medium may reside as discrete components in a computing device. Additionally, in some embodiments, the events or actions of a method or algorithm may reside as one or any combination or set of codes and instructions on a machine-readable medium or computer-readable medium, which may be incorporated into a computer program product.
Also, any connection may be associated with a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. “Disk” and “disc,” as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc where disks usually reproduce data magnetically, while discs usually reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.
In some embodiments, the system is world-wide-web (www) based, and the network server is a web server delivering HTML, XML, etc., web pages to the computing devices. In other embodiments, a client-server architecture may be implemented, in which a network server executes enterprise and custom software, exchanging data with custom client applications running on the computing device.
In some embodiments, to encode the spatial properties of rides, the system and method utilize the entire physical route of the ride. However, to capture spatial proximity, the system and method discretizes space as shown in
For example, suppose ride r traverses S, A, B, C, D, T in time intervals I0, I1, I2, I3, I4, and I5 respectively. Similarly, ride r′ traverses S′, A, B, C, T′ in time intervals I0, I1, I2, I3, and I4 respectively. The rides r and r′ are represented with their space-time discretized routes of <(S, I0), (A, I1), (B, I2), (C, I3), (D, I4), (T, I5)> and <(S′, I0), (A, I1), (B, I2), (C, I3), (T′, I4)>, respectively. The segment <(A, I1), (B, I2)> and <(B, I2), (C, I3)> are the common space-time discretized segments.
Finally, the system turns the space-time discretized routes into vector representations. The vector space is a high-dimensional space with each possible space-time discretized route segment as a dimension. Each ride and driver route has two vector representations including a pre-preprocessing vector representation and a query vector representation. The pre-processing vector representation includes a vector with a “0” in every dimension except for dimensions that correspond to a segment in its space-time discretized route, in which case it is the cost of that segment. The query vector representation is similar to the pre-processing vector representation but there is simply a ‘1’ in dimensions that correspond to a segment in its space-time discretized route.
In general, there can be other methods of vectorization that encodes the spatio-temporal properties of rides and driver routes that are significant for ride matching. The pre-processing vector representation and the query vector representation mentioned here are examples of such vectorization of the spatio-temporal properties of rides and driver routes.
In the next step, the system derives the similarity. The match utility between two rides or a ride and a driver route is proportional to the total cost of the common segments, which would translate to savings if they are served together. As shown in
In some embodiments, the preprocessing vector representation is used while constructing the asymmetric locality sensitive hashing dataset and the query vector representation is used while querying the asymmetric locality sensitive hashing dataset to find overlapping matches for a ride. With the above two vector representations the sum of the costs of the common edges in the intersection of the spatio-temporal routes of rides r and r′ is the inner product between the preprocessing vector representation of r and the query vector representation of r′. Thus, approximate overlapping match search can be solved via approximate maximum inner product search (MIPS).
In general, the similarity measure will depend upon the specific vectorization method used. For example, inner product is a suitable similarity measure with the vectorization scheme presented here that constructs a preprocessing vector representation and a query vector representation for each ride and driver route.
Next, the system performs the similarity search. With representations defined mathematically in a vector space, the system can use the technique of locality sensitive hashing to find similar rides and driver routes as matches.
In some embodiments with similarity defined as inner product, for the purpose of similarity search, the system combines an asymmetric LSH construction that transforms Maximum Inner Product search problem to Maximum Cosine Similarity Search with a LSH scheme for Maximum Cosine Similarity Search. For example, the cross-polytope LSH construction for Maximum Cosine Similarity Search can be used for this purpose.
In some embodiments, to improve the success probability of finding high utility potential matches for a ride, the system may consider multiple alternate routes for rides and driver routes. In this alternative, the system constructs vector representations for all the alternate routes to represent the corresponding ride or driver route. Combining ride matches obtained from alternate routes significantly improves success probability.
In some embodiments, the system may discretize space and time in different granularities which will give rise to multiple representations for each ride and driver route. The system then uses a hybrid method repeating the original method with different discretizations and combining the results.
In some embodiments, the system can persist the constructed LSH data structure and incrementally add the newly arrived rides while deleting the rides already assigned or picked up. Driver routes should be replaced in the data structure whenever they get updated and also periodically to prevent them from becoming too stale. This incremental approach can improve runtime efficiency in real-time operation.
In some embodiments, the system can include current as well as pre-scheduled future rides in the same match pool. The temporal aspect of the method and system presented here can effectively find matches between such rides. For example, a current ride or driver route can be matched to a future ride pre-scheduled to arrive 30-minutes from now if the current ride or driver route is expected to reach the pickup of the future ride in that time and have good overlap with its route thereafter.
In some embodiments, the system may use stochastic optimization methods to make matches predicting for future ride arrivals. Some of the possibilities include stochastic programming, approximate dynamic programming and neural methods.
Many different embodiments have been disclosed herein, in connection with the above description and the drawings. It will be understood that it would be unduly repetitious and obfuscating to describe and illustrate every combination and subcombination of these embodiments. Accordingly, all embodiments can be combined in any way or combination, and the present specification, including the drawings, shall be construed to constitute a complete written description of all combinations and subcombinations of the embodiments described herein, and of the manner and process of making and using them, and shall support claims to any such combination or subcombination.
An equivalent substitution of two or more elements can be made for any one of the elements in the claims below or that a single element can be substituted for two or more elements in a claim. Although elements can be described above as acting in certain combinations and even initially claimed as such, it is to be expressly understood that one or more elements from a claimed combination can in some cases be excised from the combination and that the claimed combination can be directed to a subcombination or variation of a subcombination.
It will be appreciated by persons skilled in the art that the present embodiment is not limited to what has been particularly shown and described hereinabove. A variety of modifications and variations are possible in light of the above teachings without departing from the following claims.
