Intelligent order operation system, method, electronic device and storage medium

Abstract

The application provides a system, method, electronic device and storage medium for intelligent order operation, which is applied to the technical field of order distribution and comprises a task planning module, which is used for acquiring N orders and target information and calling a destination prediction module to determine a destination; the task planning module is also used for calling an exception detection module to determine whether an operation exception occurs for a rider; when the operation exception occurs, the task planning module is also used for determining a processing result and displaying the processing result; the task planning module is also used for calling a demand detection module to determine whether an operation demand exists for the rider; when the operation demand exists, the task planning module is also used for determining a response result and displaying the response result. The system can actively predict the destination of the rider, the demand and the exception when the rider goes to the destination and actively respond to the demand and solve the exception in the process in which the rider processes the orders, thereby providing a one-stop intelligent order service from active perception to active solution for the rider and optimizing the distribution experience of the rider.

Description

Technical Field

[0001] This application relates to the field of order delivery technology, and more specifically, to a system, method, electronic device, and storage medium for intelligent order processing in the field of order delivery technology. Background Technology

[0002] Currently, the on-demand retail sector encompasses various on-demand retail services, such as fresh food retail, supermarket and convenience store retail, pharmaceutical retail, and food delivery retail. When riders process orders for these various retail services, the intelligent services offered by major retail platforms primarily focus on real-time order reminders and the automatic execution of subsequent tasks.

[0003] For example, taking on-demand retail services as an example of food delivery services, the processing of food delivery orders typically includes the following stages (or events): order acceptance → arrival at the store → food pickup → delivery → arrival. Taking the arrival at the store event as an example, during the order delivery process, if the platform detects that the rider currently meets the arrival conditions, it will remind the rider whether to arrive at the store. If the rider replies yes, the platform will automatically perform the arrival at the store operation to complete the processing of the arrival at the store event.

[0004] The aforementioned lack of proactive awareness of rider needs or abnormalities when riders are fulfilling retail service orders results in a low level of intelligence in order processing and insufficient proactive care for riders. Summary of the Invention

[0005] This application provides a system, method, electronic device, and storage medium for intelligent order processing. The various modules in the system can work together to proactively predict the rider's destination and the needs and anomalies on the way to the destination during the rider's order processing, and proactively respond to the needs and resolve the anomalies, providing the rider with a one-stop intelligent order service from proactive perception to proactive resolution, thus optimizing the rider's delivery experience.

[0006] Firstly, an intelligent order processing system is provided, applied to a server. This system includes a task planning module, a destination prediction module, an anomaly detection module, and a demand detection module. The task planning module, based on the execution rules of the intelligent order processing system, determines multiple processing steps that need to be executed sequentially during a rider's delivery order. These multiple processing steps include a destination prediction step, an anomaly prediction step, and a demand prediction step. In the destination prediction step, the task planning module further obtains N orders to be delivered by the rider and the target information associated with the rider, and calls the destination prediction module so that the destination prediction module determines the rider's destination based on the target information and the N orders, where N is a positive integer greater than or equal to 1. In the anomaly prediction step, the task planning module... The task planning module also calls the anomaly detection module to determine, based on the target information, whether an operational anomaly occurs when the rider is processing the target order (which is an order associated with the destination) during the rider's journey to the destination. If an operational anomaly occurs, the task planning module also determines and displays the corresponding processing result. In the demand forecasting stage, the task planning module also calls the demand detection module to determine, based on the target information, whether there is an operational demand when the rider is processing the target order during the rider's journey to the destination. If there is an operational demand, the task planning module also determines and displays the corresponding response result.

[0007] In the aforementioned technical solution, this application provides an intelligent order processing system. The various modules within this system work collaboratively to proactively predict the rider's destination and potential needs and anomalies during the order processing process. It also proactively responds to needs and resolves anomalies, providing riders with a one-stop intelligent order service from proactive perception to proactive resolution, thus optimizing the rider's delivery experience. Furthermore, by proactively responding to needs and resolving anomalies, this application's system can improve anomaly resolution efficiency and avoid delays caused by manual handling. In summary, the intelligent order processing system of this application provides riders with a one-stop intelligent order service from proactive perception to proactive strategy provision, optimizing the rider's delivery experience and reducing rider complaints.

[0008] In conjunction with the first aspect, in some possible implementations, the target information includes the order status of the target order, the distance between the rider's location and the destination, the rider's profile information and abnormal trajectory type, the weather type, and multiple movement states and spatiotemporal sequence information of the rider within a preset time period. The task planning module is specifically used to: predict the rider's current operational anomaly based on the multiple movement states and the weather type, or based on the abnormal trajectory type, the distance between the rider's location and the destination, and the order status of the target order; and call the anomaly detection module so that the anomaly detection module determines whether the rider has experienced the predicted operational anomaly based on the profile information, the weather type, and the spatiotemporal sequence information.

[0009] In the aforementioned technical solution, when detecting whether an operational anomaly occurs during a rider's journey to their destination, the task planning module in this application first predicts the rider's current operational anomaly based on multiple dimensions such as the rider's movement status, weather, trajectory, and order status. This allows for timely identification of potential anomalies during the rider's order processing. Furthermore, based on the predicted operational anomalies, to verify the accuracy of the prediction, the task planning module calls the anomaly detection module. Using the rider's profile information, weather type, and spatiotemporal sequence information, it determines whether the predicted anomaly has occurred. This enables more accurate identification of actual operational anomalies, reduces false positives, and improves the accuracy of anomaly detection.

[0010] In conjunction with the first aspect and the above implementation methods, in some possible implementations, the system further includes a location encoding module and an event encoding module. The profile information includes statistical information on the rider's historical order processing process, and the spatiotemporal sequence information includes a location state sequence and an operation event sequence for the target order. The anomaly detection module is specifically used to: call the location encoding module to encode the location state sequence to obtain a first location feature; call the event encoding module to encode the operation event sequence for the target order to obtain a first operation event feature; and determine whether the rider has experienced the predicted operational anomaly based on the first location feature, the first operation event feature, the statistical information, and the weather type.

[0011] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, the anomaly detection module is further configured to: perform pooling and splicing processing on the first location feature, the first operation event feature, the statistical information, and the weather type to obtain a spliced ​​first low-dimensional joint feature; perform multi-level nonlinear transformation on the first low-dimensional joint feature to obtain a first high-dimensional joint feature; determine the probability of occurrence of the predicted operation anomaly based on the first high-dimensional joint feature; determine that the rider has committed the predicted operation anomaly when the probability of occurrence is greater than or equal to a first preset probability; and determine that the rider has not committed the predicted operation anomaly when the probability of occurrence is less than the first preset probability.

[0012] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, the task planning module is also used to: determine the exception handling strategy and the job service associated with the exception handling strategy based on the job exception; call the job service associated with the exception handling strategy to execute the exception handling strategy, and obtain the processing result corresponding to the job exception.

[0013] In the above technical solution, when a rider encounters an abnormality in the target operation, the task planning module automatically calls the corresponding operation service to automatically execute the target operation abnormality handling strategy, realizing full-link automation from abnormality detection to result generation. This avoids the problems of delay and long work cycle caused by manual abnormality handling, ensures the timeliness and efficiency of abnormality handling, and improves the rider's delivery experience.

[0014] Combining the first aspect and the above implementation methods, in some possible implementation methods, the target information includes statistical information on the rider's historical order processing process, the rider's delivery preferences and familiarity with the destination, traffic information, weather type, attribute information of the destination, and the rider's spatiotemporal sequence information within a preset time period; the task planning module is specifically used to: predict the rider's current job demand based on the delivery familiarity or based on the traffic information and delivery preferences; and call the demand detection module so that the demand detection module determines whether the rider has predicted job demand based on the delivery preferences, delivery familiarity, attribute information of the destination, statistical information, weather type, and spatiotemporal sequence information.

[0015] In the aforementioned technical solution, when detecting whether there is a work demand while the rider is traveling to the destination, the task planning module in this application first predicts the rider's current work demand based on multiple dimensions such as the rider's delivery habits, delivery familiarity, and traffic conditions of the surrounding environment. This allows for timely identification of potential demands during the rider's order processing. Furthermore, based on the predicted work demand, to verify the accuracy of the prediction, the task planning module calls the demand detection module. Through rider profile information, weather type, destination-related attribute information, and spatiotemporal sequence information, it determines whether the predicted demand exists. This enables more accurate identification of actual work demands, reduces misidentification of work demands, and improves the accuracy of work demand identification.

[0016] In conjunction with the first aspect and the above implementation methods, in some possible implementations, the system further includes a location encoding module and an event encoding module. The destination's attribute information includes points of interest and regions of interest, and the spatiotemporal sequence information includes a location state sequence and an operation event sequence for the target order. The demand detection module is specifically used to: call the event encoding module to encode the operation event sequence for the target order to obtain a first operation event feature; call the location encoding module to encode the points of interest and regions of interest, the location state sequence, the delivery familiarity, and the delivery preference to obtain a second location feature; and determine whether the rider has the predicted job demand based on the second location feature, the first operation event feature, the statistical information, and the weather type.

[0017] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, the demand detection module is further configured to: perform pooling and splicing processing on the first operation event feature, the second location feature, the statistical information, and the weather type to obtain a spliced ​​second low-dimensional joint feature; perform multi-level nonlinear transformation on the second low-dimensional joint feature to obtain a second high-dimensional joint feature; determine the probability of the existence of the predicted job demand based on the second high-dimensional joint feature; determine that the rider has the predicted job demand when the existence probability is greater than or equal to a second preset probability; and determine that the rider does not have the predicted job demand when the existence probability is less than the second preset probability.

[0018] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, the task planning module is also used to: determine the demand response strategy and the job service associated with the demand response strategy based on the job requirement; call the job service associated with the demand response strategy to execute the demand response strategy and obtain the response result corresponding to the job requirement.

[0019] In the above technical solution, when a rider has a target job request, the task planning module automatically calls the corresponding job service to automatically execute the response strategy for the target job request, realizing full-link automation from request detection to result generation. This avoids the problems of delay and long work cycle caused by manual handling of anomalies, ensures the timeliness and efficiency of request processing, and improves the rider's delivery experience.

[0020] Combining the first aspect and the above implementation methods, in some possible implementation methods, the target information includes the rider's location, the delivery scenario in which the rider is located, and the spatiotemporal sequence information of the rider within a preset time period; the task planning module is specifically used for: when N is greater than 1, if the delivery scenario is a food pickup scenario, obtaining the N merchant locations associated with the N orders; determining M candidate destinations from the N merchant locations based on the rider's location, where M is less than or equal to N; or, if the delivery scenario is a food delivery scenario, obtaining the N user locations associated with the N orders; determining the M candidate destinations from the N user locations based on the rider's location; obtaining M attribute information of the M candidate destinations and M processing progress information corresponding to the M orders, where the M orders are orders associated with the M candidate destinations; and calling the destination prediction module so that the destination prediction module determines the destination from the M candidate destinations based on the M attribute information, the M processing progress information, and the spatiotemporal sequence information.

[0021] In conjunction with the first aspect and the above implementation methods, in some possible implementations, the system further includes a location encoding module and an event encoding module. The M attribute information includes M points of interest and M regions of interest, and the spatiotemporal sequence information includes a location state sequence and a sequence of M operation events for the M orders. The destination prediction module is specifically used to: for any candidate destination among the M candidate destinations, concatenate the processing progress information associated with the candidate destination to obtain a dense processing progress feature of the candidate destination; call the location encoding module to encode the M points of interest, the M regions of interest, and the location state sequence to obtain a third location feature; call the event encoding module to encode the M operation event sequences to obtain a second operation event feature; and determine the destination from the M candidate destinations based on the dense processing progress feature of the M candidate destinations, the third location feature, and the second operation event feature.

[0022] In conjunction with the first aspect and the above implementation methods, in some possible implementation methods, the destination prediction module is further used to: perform pooling and concatenation processing on the second operation event feature and the third location feature to obtain a concatenated third low-dimensional joint feature; perform multi-level nonlinear transformation on the third low-dimensional joint feature to obtain a third high-dimensional joint feature; determine the M output probabilities corresponding to the M candidate destinations based on the dense processing progress features of the M candidate destinations and the third high-dimensional joint feature; and determine the candidate destination corresponding to the probability that is greater than or equal to the third preset probability among the M output probabilities as the destination.

[0023] Combining the first aspect and the above implementation methods, in some possible implementation methods, the target information includes the rider's location, the order status of the N orders, the merchant's location, and the user's location; the destination prediction module is also used to: when N equals 1, if the order status is "accepted" or the rider's location is gradually approaching the merchant's location, determine the destination as the merchant's location; if the order status is "picked up" or the rider's location is gradually approaching the user's location, determine the destination as the user's location.

[0024] In the above technical solution, when a rider has only one order to deliver, the system can determine the rider's destination through simple location matching. The above process is simple and efficient, without the need for complex judgment logic, and provides the correct location information for subsequent determination of the rider's needs and anomalies.

[0025] Secondly, an intelligent order management method is provided, applied to a server. This method includes: based on the execution rules of intelligent order management, determining multiple processing steps that need to be executed sequentially during a rider's delivery order process. These multiple processing steps include a destination prediction step, an anomaly prediction step, and a demand prediction step. In the destination prediction step, obtaining N orders to be delivered by the rider and the target information associated with the rider, where N is a positive integer greater than or equal to 1; determining the rider's destination based on the target information and the N orders; in the anomaly prediction step, during the rider's journey to the destination, determining whether an operational anomaly occurs when the rider processes the target order based on the target information, where the target order is an order associated with the destination; when an operational anomaly occurs, determining and displaying the corresponding processing result; in the demand prediction step, during the rider's journey to the destination, determining whether there is an operational demand when the rider processes the target order based on the target information; and when there is an operational demand, determining and displaying the corresponding response result.

[0026] Thirdly, an intelligent order processing method is provided, applied to the user end. This method includes: obtaining target information associated with a rider; sending the target information to a server, so that the server determines the rider's destination based on the target information and N orders to be delivered by the rider, where N is a positive integer greater than or equal to 1; receiving and displaying the processing result corresponding to a task exception sent by the server, wherein the task exception is determined by the server based on the target information during the rider's journey to the destination to process the target order, the target order being an order associated with the destination, and the processing result corresponding to the task exception being determined by the server based on the task exception; and / or receiving and displaying the response result corresponding to a task request sent by the server, wherein the task request is determined by the server based on the target information during the rider's journey to the destination to process the target order, and the response result corresponding to the task request being determined by the server based on the task request.

[0027] Fourthly, an electronic device is provided, including a memory and a processor. The memory is used to store executable program code, and the processor is used to call and run the executable program code from the memory, causing the electronic device to perform the method described in the second aspect.

[0028] Fifthly, an electronic device is provided, including a memory and a processor. The memory is used to store executable program code, and the processor is used to call and run the executable program code from the memory, causing the electronic device to perform the method described in the third aspect.

[0029] Sixthly, a computer program product is provided, comprising: computer program code, which, when executed on a computer, causes the computer to perform the method of the second aspect or the method of the third aspect described above.

[0030] In a seventh aspect, a computer-readable storage medium is provided that stores computer program code, which, when executed on a computer, causes the computer to perform the methods described in the second and third aspects. Attached Figure Description

[0031] Figure 1 This is a schematic diagram of a graphical user interface (GUI) for manually grabbing orders provided in an embodiment of this application;

[0032] Figure 2 This is a GUI diagram illustrating a manual process for reporting store arrivals, provided in an embodiment of this application.

[0033] Figure 3This is a GUI diagram illustrating a system for reporting store arrival via voice, as provided in an embodiment of this application.

[0034] Figure 4 This is a GUI diagram illustrating a push request response information provided in an embodiment of this application;

[0035] Figure 5 This is a schematic diagram of the structure of an intelligent order processing framework provided in an embodiment of this application;

[0036] Figure 6 This is a structural diagram of an intelligent order processing system provided in an embodiment of this application;

[0037] Figure 7 This is a flowchart of a destination prediction module provided in an embodiment of this application;

[0038] Figure 8 This is a flowchart of the workflow of a GeoEncoder provided in an embodiment of this application;

[0039] Figure 9 This is a flowchart of the workflow of an EventEncoder provided in an embodiment of this application;

[0040] Figure 10 This is a flowchart of an anomaly detection module provided in an embodiment of this application;

[0041] Figure 11 This is a flowchart of a requirement detection module provided in an embodiment of this application;

[0042] Figure 12 This is a schematic flowchart illustrating an intelligent order processing method provided in an embodiment of this application;

[0043] Figure 13 This is a schematic flowchart illustrating another intelligent order processing method provided in an embodiment of this application;

[0044] Figure 14 This is a flowchart illustrating the implementation of an intelligent order processing method provided in an embodiment of this application.

[0045] Figure 15 This is a schematic diagram of the structure of an intelligent order processing device provided in an embodiment of this application;

[0046] Figure 16 This is a schematic diagram of the structure of another intelligent order processing device provided in an embodiment of this application;

[0047] Figure 17 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0048] Figure 18This is a schematic diagram of the structure of another electronic device provided in an embodiment of this application. Detailed Implementation

[0049] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0050] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0051] Before introducing the solutions of the embodiments of this application, the names of the technical terms that may be involved in the embodiments of this application will be explained first.

[0052] Instant retail: a new retail model that relies on online platforms and offline physical stores to meet consumers' immediate needs for goods through instant delivery services.

[0053] An agent is a computational entity capable of autonomously perceiving its environment, making decisions, and executing actions to achieve a specific goal. An agent system typically consists of one or more agents that work together to accomplish complex tasks through interaction and collaboration.

[0054] Tongyi Qianwen Model: A large language model independently developed by Alibaba Cloud, it is an important application in the field of Artificial Intelligence Generated Content (AIGC) and has powerful language and multimodal data processing capabilities.

[0055] After introducing the technical terms that may be involved in the embodiments of this application, the application scenarios of the embodiments of this application will be introduced below.

[0056] Currently, common on-demand retail services include, but are not limited to, fresh food retail, supermarket and convenience store retail, pharmaceutical retail, and food delivery retail. When processing various retail service orders, delivery riders use two methods: one is manual operation to complete all order tasks; the other is based on the intelligent services provided by major retail platforms, which provide real-time order reminders to riders and ask if they need automatic order processing. If the rider confirms, the corresponding order processing is automatically executed.

[0057] Taking food delivery services as an example, the delivery process for riders can be roughly divided into the following stages (or tasks): accepting orders (or grabbing orders) → arriving at the store → picking up the food → delivery → arrival.

[0058] For example, taking the delivery to a store as an example, the general process for a rider to manually complete the delivery to a store is as follows: Based on the food delivery application (App) installed on the user's terminal (i.e., the rider's smart device), the rider clicks the icon of the food delivery app, and the user terminal responds to the click operation by displaying the order acceptance interface. On this order acceptance interface, the rider accepts the order by clicking. In addition, this order acceptance interface also includes a "route planning" icon. After the order is successfully accepted, the rider can also click the "route planning" icon on the order acceptance interface, and the user terminal responds to the click operation by displaying the arrival at the store interface. This arrival at the store interface displays the planned route to the store based on the rider's location and the store's location, as well as the real-time distance between the rider's location and the store's location. Based on this arrival at the store interface, the rider can travel to the store according to this route. In addition, the arrival at the store interface also includes a "confirm arrival" control. During the rider's journey to the store, the arrival at the store route and the real-time distance are updated in real time. The rider can determine whether they have arrived at the store based on the real-time distance displayed on the arrival at the store interface. When a rider determines that they have arrived at a merchant, they can click the "Confirm Arrival" control on the arrival screen to complete the arrival reporting process and indicate that the rider has arrived at the store.

[0059] The following is through Figures 1 to 2 The process of riders manually "reporting arrival at the store" is explained in detail.

[0060] Figure 1 This is a GUI diagram illustrating a manual order-grabbing method provided in an embodiment of this application.

[0061] For example, such as Figure 1 Image (a) shows the user interface 101 displayed in unlock mode. Figure 1As shown in (a), interface 101 displays a weather clock component and multiple applications. These applications include a phone, messaging, settings, and food delivery software (hereinafter referred to as "Application A"). It should be understood that interface 101 may also include other applications, and this embodiment of the application does not limit this.

[0062] like Figure 1 As shown in (a), after the rider clicks the icon of application A in interface 101, the user terminal displays the following in response to the rider's click operation: Figure 1 The display interface 102 of the order-grabbing page of application A shown in (b) can also be referred to as the "homepage of application A". The display interface 102 displays the order list of currently pending orders, the "order setting" icon, the "route planning" icon, the "go online now" control, the "personal center" icon, and the rider's work status display box, etc. This application embodiment does not limit the displayed content, font size, and display format of the displayed content on the display interface 102.

[0063] On display interface 102, the order list of pending orders can display the order parameters of one or more pending orders. Riders can view more order parameters by swiping up and down. Optionally, the order parameters of each pending order include one or more of the following: the name of the merchant (or store) associated with the order, the merchant's location, the location of the user to be delivered, the estimated delivery time, the basic delivery fee, the order-grabbing control for the order, the distance between the rider and the merchant's location, and the distance between the rider and the location of the user to be delivered. For example, Figure 1 As shown in (b), in the list of orders to be grabbed, the order parameters of the first order to be grabbed include: Merchant Name A (XXX Store), Merchant Location: Shopfront, No. X, Unit X, Floor X, Row X, District X, City X, Province X, Location of the User to be Delivered: Unit X, Floor X, XX-X, XX Community X, District X, City X, Estimated Delivery Time: Within 30 minutes, Basic Delivery Fee: 3.9, Order Grabbing Control for this Order, Distance between Rider and Merchant Location: 969m, Distance between Rider and User to be Delivered: 1.5km.

[0064] In addition, the work status display box of the display interface 102 includes status icons and status prompts to indicate whether the rider's work status is active. For example... Figure 1 As shown in (b), when the rider has not started working, the work status display box displays a "Waiting to go online" status icon and a "Offline" status prompt, which indicates that the rider's work status is not active.

[0065] When a rider starts work, they can click the "Go Online Now" control in the lower right corner of the display interface 102. In response to the click, the user terminal will display as follows: Figure 1The display interface 103 of the order-grabbing page shown in (c) is compared to... Figure 1 In the display interface 102 shown in (b), the status icon in the work status display box of the display interface 103 changes to an "Online" status icon, and the status prompt changes from "Offline" to "Online," indicating that the rider's work status has been activated. In addition, when the rider is online, the control in the lower right corner of the display interface 103 changes from the original "Online Now" control to a "Refresh Orders" control, which allows the rider to refresh the list of orders waiting to be accepted in the display interface 103 in real time during the delivery process.

[0066] Based on the list of orders to be accepted displayed on the display interface 103, riders can receive the delivery task for at least one order by clicking the "accept order" control for at least one order.

[0067] For example, such as Figure 1 As shown in (c), in the display interface 103, the rider clicks the "Grab Order" control for the first order in the list of orders to be grabbed. In response to this click, the interactive state of the "Grab Order" control switches from an active state to a grayed-out state. Optionally, this embodiment does not limit the number of orders a rider can grab on the display interface 103. This embodiment uses a grabbing quantity of 1 order as an example in its description.

[0068] After the order is accepted, the following steps will be taken: Figure 2 This section explains how to manually execute the reporting process after accepting an order.

[0069] Figure 2 This is a GUI diagram illustrating a manual process for reporting store arrivals, provided in an embodiment of this application.

[0070] For example, in combination Figure 1 In section (c), on display interface 103, after the order is accepted, the rider can click the "Route Planning" icon on display interface 103. In response to this click, the user terminal displays as follows: Figure 2 The display interface 201 (or the arrival interface 201) of the pending pickup page shown in (a) is shown in the figure. The display interface 201 includes a navigation path display area, order parameters of the pending pickup order, an "online chat" icon, a "contact" icon, and a "confirm arrival" control. The navigation path display area displays the navigation path between the merchant's location and the rider's location (i.e., the arrival path or pickup path), as well as a distance prompt box between the merchant's location and the rider's location, which is used to display the distance prompt text between the rider's location and the merchant's location.

[0071] For example, such as Figure 2As shown in (a), the navigation path display area of ​​the display interface 201 displays the navigation path between the location of Merchant A (XXX store) and the rider's location, and the distance prompt text in the distance prompt box is "distance 1km", which is used to indicate that the distance between the current rider's location and the merchant's location is 1km.

[0072] Riders can follow the navigation path displayed in the navigation route area to pick up their meals. The navigation path and distance information will be updated in real time as the rider travels to the restaurant. Riders can determine whether they have arrived at the restaurant based on the distance between their own location and the restaurant's location. Once confirmed, riders can manually report their arrival by clicking the "Confirm Arrival" button.

[0073] like Figure 2 As shown in (b) of the diagram, the navigation path displayed in the navigation path display area of ​​the display interface 202 changes, and the distance prompt text becomes "Distance 12m", indicating that the distance between the current rider location and the merchant location is 12m. Once the rider confirms they have arrived near the merchant location, they manually click the "Confirm Arrival" control. In response to this click, the user client can change the interactive state of the "Confirm Arrival" control from active to grayed out (not shown in the diagram), thus confirming to the user client that the rider has arrived at the merchant location and allowing them to proceed with subsequent processes, such as reminding the merchant to prepare the food as soon as possible.

[0074] The above example demonstrates how riders can manually report arrival at the store during the delivery process by clicking on the button.

[0075] Another example is the use of intelligent services provided by food delivery platforms. The user's client can interact with the server corresponding to that client to achieve automatic store arrival. The user's client receives the rider's request and sends it to the server. The server then determines the corresponding execution instructions based on the rider's request and sends them back to the user's client. The user's client then performs the operations related to the rider's request based on the execution instructions.

[0076] In the process of achieving automatic store arrival, the food delivery app installed on the user's device allows the rider to access an AI assistant (hereinafter referred to as the "AI Smart Assistant") built into the app. During order processing, the AI ​​Smart Assistant can interact with the rider via voice, and the user's device will automatically arrive at the store based on the results of the voice interaction.

[0077] Specifically, the general process by which the food delivery platform automatically completes the delivery process for riders to the store is as follows:

[0078] Riders can accept orders by clicking the icon of the food delivery app, and the user's device will then display an order acceptance interface. This interface also includes a "route planning" icon. After successfully accepting an order, the rider can issue a voice command, "Please help me plan the route," on the order acceptance interface. The user's device receives this voice command and sends it to the server. The server responds by automatically planning the route to the restaurant and displaying the arrival screen on the user's device. This screen shows the planned route based on the rider's and restaurant's locations, as well as the real-time distance between the two locations. The rider can then proceed to the restaurant based on this route. The arrival screen also includes a "confirm arrival" control. The arrival route and real-time distance are updated continuously as the rider travels to the restaurant. The server can determine whether the rider has arrived at the restaurant based on the distance displayed on the arrival screen. When the server determines that the rider has arrived, it generates an arrival reminder voice message and sends it to the food delivery app. The app then broadcasts this message through its AI assistant to remind the rider to confirm arrival. When the rider replies "yes", the server controls the client to automatically gray out the "Confirm Arrival" control, completing the reporting of arrival at the store, indicating that the rider has arrived at the store.

[0079] The following is through Figure 3 The process of automatically executing "reporting to the store" is described in detail.

[0080] Figure 3 This is a GUI diagram illustrating a voice-based reporting of store arrival, provided in an embodiment of this application.

[0081] For example, such as Figure 3 As shown in (a) in the figure, combined with Figure 1 and Figure 2 When the rider clicks the icon of application A in the display interface 101 of the unlock mode, the user terminal displays the following in response to the click operation. Figure 1 The display interface 102 of the waiting order page of application A shown in (b) is shown in the figure.

[0082] When an AI smart assistant is built into application A, the AI ​​smart assistant can be displayed on display interface 102 by default (not shown in the figure) when application A is first launched on the user's end. Alternatively, the rider can choose whether to display it on display interface 102 according to their manual settings.

[0083] It should be noted that the AI ​​intelligent assistant is a visual interactive carrier. A visual interactive carrier can carry intelligent interactive functions in an intuitive and vivid way. It refers to the technology or tool that carries information through graphical and dynamic interface elements and supports riders to complete human-computer interaction through intuitive operations (such as dragging, clicking, and voice wake-up).

[0084] When the AI ​​assistant icon is displayed on the display interface 102, and there is no voice interaction between the rider and the AI ​​assistant, the AI ​​assistant icon can be displayed on the display interface 102 in a static or cyclical manner, indicating that the AI ​​assistant is in a "dormant state".

[0085] Based on the AI ​​intelligent assistant displayed in the display interface 102, riders can perform a series of operations such as "going online - grabbing orders - route planning" by interacting with the AI ​​intelligent assistant by voice. Alternatively, riders can also manually complete the "going online - grabbing orders - route planning" operations.

[0086] After route planning is completed, during the rider's journey to pick up the food from the merchant, the user's app can display the following: Figure 3 The display interface 301 of the pending pickup page shown in (a) is shown in the image. Figure 2 Compared to the pickup page display interface 201 shown in (a), display interface 301 displays an AI intelligent assistant icon 3011. Since the rider's current location is too far from the merchant's location to meet the arrival reminder conditions, the AI ​​intelligent assistant is in a dormant state. Apart from this, the remaining display content of display interface 301 is exactly the same as display interface 201, as detailed above. Figure 2 The introduction in the text.

[0087] During the rider's journey to the merchant, when the server determines that the distance between the rider's location and the merchant's location is relatively close, it can control the display on the user's device to show, for example... Figure 3 The display interface 302 of the pending pickup page is shown in (b) in the figure. The display interface 302 includes a navigation path display area, and the distance prompt box in the navigation path display area displays the distance prompt text between the current rider location and the merchant location - "12m away", which means that the distance between the rider location and the merchant location is 12m, indicating that the rider is currently close to the merchant.

[0088] In this case, the display interface 302 also includes a pop-up window 3021, which includes an AI smart assistant icon 3011, an interaction status prompt text—"Xiao E is broadcasting," a report arrival prompt text—"You have arrived at Merchant A (XXX store), do you want to report arrival?", and a close control. The report arrival prompt text—"You have arrived at Merchant A (XXX store), do you want to report arrival?"—is used to remind the rider that they are currently close to the merchant and whether they need to perform the report arrival action. The interaction status prompt text—"Xiao E is broadcasting"—indicates that the AI ​​smart assistant is currently broadcasting a voice message, which is the voice message corresponding to the report arrival prompt text (i.e., the report arrival prompt voice message).

[0089] Optionally, the voice / text message for reporting arrival at the store can also be "You have arrived at Merchant A (XXX store), do you want to confirm your arrival?" This application embodiment does not limit this.

[0090] In display interface 302, after the rider clicks the close control, in response to this click, the user can close pop-up window 3021 to end the current voice interaction process. At the same time, the AI ​​intelligent assistant returns to "sleep mode".

[0091] Upon receiving the rider's response to the reported arrival notification, the user's app can display, as shown below. Figure 3 The display interface 303 of the pending pickup page is shown in (c). A pop-up window 3031 is displayed at the bottom of the display area of ​​the display interface 303.

[0092] For example, such as Figure 3 As shown in (c), pop-up window 3031 includes an AI smart assistant icon 3011, an interaction status prompt text—"Xiao E is listening...", a text corresponding to the voice reply—"Please help me report to the store" and a close control.

[0093] Optionally, the voice / text reply can also be "Please help me confirm arrival at the store", "Report arrival at the store", "Confirm arrival at the store", etc., and this application embodiment does not limit this.

[0094] In display interface 303, after the rider clicks the close control, in response to this click, the user can close pop-up window 3031 to end the current voice interaction process. At the same time, the AI ​​intelligent assistant returns to "sleep mode".

[0095] In response to the rider's voice reply to the arrival notification, the user client can send this voice reply to the server. Based on the voice reply, the server determines the processing instruction for the arrival notification and sends it to the user client. In response to the processing instruction for the arrival notification, the user client can display something like this: Figure 3 The display interface 304 of the pending pickup page is shown in (d) in the diagram. The display interface 304 includes the user's execution result of the above-mentioned reply voice (or, the processing instruction to report arrival at the store).

[0096] For example, such as Figure 3 As shown in (d), in response to the rider's reply voice, the execution result displayed on the user terminal is as follows: in the display interface 304, the interactive state of the "Confirm Arrival" control is switched from the active state to the grayed-out state, and the text label of the control is switched from "Confirm Arrival" to "Arrived at the store".

[0097] In addition, the bottom of the display area of ​​the display interface 304 includes a pop-up window 3041. Pop-up window 3041 includes an AI intelligent assistant icon 3011, a close control, and an interaction status prompt text—"Xiao E is broadcasting," and a prompt text for the aforementioned execution result—"Your arrival at the store has been reported." The interaction status prompt text—"Xiao E is broadcasting"—indicates that the AI ​​intelligent assistant is currently broadcasting a voice message to the rider; the specific voice message is the same as the voice message in the aforementioned execution result prompt text.

[0098] In display interface 304, after the rider clicks the close control, in response to this click, the user can close pop-up 3041 to end the current voice interaction process. At the same time, the AI ​​intelligent assistant returns to "sleep mode".

[0099] In another implementation, such as Figure 3 In the display interface 302 shown in (b), the pop-up window 3021 also includes a "Close" control and a "Confirm Arrival" control. After the AI ​​intelligent assistant reminds the rider whether to report arrival at the store, in addition to automatically reporting arrival at the store upon receiving the rider's reply voice, the rider can manually report arrival at the store by clicking the "Confirm Arrival" control in the pop-up window 3021, or the rider can manually cancel reporting arrival at the store by clicking the "Close" control in the pop-up window 3021.

[0100] Correspondingly, when the rider clicks the "Confirm Arrival" control in pop-up window 3021, the interactive state of the "Confirm Arrival" control in display interface 302 will also become grayed out, and the text label in the control will switch from "Confirm Arrival" to "Arrived at Store".

[0101] Through the above Figure 3 The interface shown allows riders to request voice commands, enabling the user terminal to automatically complete the reporting process upon arrival at the store.

[0102] The above Figures 1 to 2 The problem with the manual operation shown is that when riders have difficulty operating the system, the manual clicking method is not intelligent enough, thus increasing the difficulty of operation for riders and reducing their delivery experience. The aforementioned... Figure 3 The problem with the automated operation shown is that, when using intelligent assistance to assist riders in their work, the food delivery platform can only provide some intelligent reminder functions, but cannot cover the proactive perception of rider operation abnormalities and work needs, resulting in a narrow scope of intelligent coverage.

[0103] To address the aforementioned issues, this application provides an intelligent order processing system. The various modules within this system can work together to proactively predict the rider's destination and any needs or anomalies encountered while the rider is processing an order. The system also proactively responds to needs and resolves anomalies, providing riders with a one-stop intelligent order service that integrates proactive perception and proactive resolution, thereby optimizing the rider's delivery experience.

[0104] The following is through Figure 4 This application describes the process of providing a one-stop intelligent order service, from proactive perception to proactive resolution, as provided in the embodiments of this application.

[0105] Figure 4 This is a GUI diagram illustrating a push request response information provided in an embodiment of this application.

[0106] For example, such as Figure 4 As shown in (a) in the figure, combined with Figure 3 After the server completes route planning, the user's client displays the "Pending Pickup" page, interface 401. Interface 401 and... Figure 3 The display interface 301 shown in (a) is exactly the same. Please refer to the above introduction for details, which will not be repeated here.

[0107] Based on the solution in this application embodiment, during the process of a rider going to a merchant's location to pick up food, the server can determine whether the rider has previously picked up food at that merchant's location or whether the rider is a new rider based on the rider's profile information. If the server determines that the rider has not picked up food at the merchant's location or is a new rider, the server can determine that the rider currently has a navigation need. The server can then promptly push or display a request response information to the rider based on the rider's location and the merchant's location.

[0108] For example, when the server determines that the rider is about to reach the merchant's location, it can display something like this: Figure 4 The display interface 402 of the pending pickup page is shown in (b) above. The display interface 402 includes a navigation path display area. The distance prompt box in the navigation path display area displays the distance prompt text between the current rider location and the merchant location - "300m from pickup", which means that the distance between the rider location and the merchant location is 300m, indicating that the rider is currently close to the merchant.

[0109] In this case, the display interface 402 also includes a pop-up window 4021 and an AI smart assistant icon 3011. Pop-up window 4021 includes the following request response text: "We have detected that you have not previously picked up a meal at this merchant. We are now providing you with the following pickup instructions: Starting from your current location, go straight ahead and turn right at the second traffic light. After turning right, ride approximately 100 meters to reach the merchant. The pickup location is at the front desk; you will need to show your pickup code." This request response text is designed to guide riders to the merchant quickly.

[0110] In addition, pop-up 4021 includes two controls for riders to choose from: an "Accept" control and a "Decline" control. After pop-up 4021 is displayed on the user's device, if the rider confirms acceptance of the current request response information, they can click the "Accept" control. In response to this click, pop-up 4021 will remain displayed on the user's device until the rider arrives at the merchant's location. If the rider determines that they do not need navigation guidance and does not accept the current request response information, they can click the "Decline" control. In response to this click, pop-up 4021 will automatically close on the user's device.

[0111] It should be understood that the above Figure 4 The GUI diagram shown is merely an illustrative example of the scenario in which the method of this application embodiment is applicable.

[0112] In passing Figure 4 After introducing the GUI diagrams illustrating the proactive perception and proactive resolution in the embodiments of this application, the following will be presented through... Figure 5 The service architecture on which the embodiments of this application are implemented and the working process of the service architecture are described.

[0113] Figure 5 This is a schematic diagram of the structure of an intelligent order operation framework provided in an embodiment of this application.

[0114] For example, such as Figure 5 As shown, the intelligent order operation framework 500 provided in this embodiment is functionally divided into a basic operation data layer 501, an active perception layer 502, and a perception decision layer 503. Based on the collaborative interaction between the above-mentioned business layers, the working process of the entire intelligent order operation framework 500 is as follows:

[0115] The basic operation data layer 501 is mainly used to provide real-time sensing information and use truth values ​​to characterize and reconstruct the operation process. This real-time sensing information includes, but is not limited to, […]. Figure 5 The system tracks the weather, location, and movement of riders during real-time delivery, and uses road matching to determine the rider's current road or section. Furthermore, the basic operational data layer 501 is used to determine the rider's delivery scenario based on their real-time perception information.

[0116] The active perception layer 502 is used to actively perceive the rider's needs and anomalies in the current work scenario based on the delivery scenario, the rider's environmental information, the rider's profile information, and the rider's short-term and long-term memory information determined by the basic operation data layer 501. The purpose is to assist the rider in making needs / anomaly-related decisions. The rider's short-term memory information includes... Figure 5 The cylindrical image on the left shows the rider's actions and location status over a short period of time. The rider's long-term memory information includes... Figure 5 The cylindrical image on the left shows the rider's operational information and location status over a longer period of time.

[0117] The active perception layer 502, based on its service scope, can be divided into four types of perception items or units to achieve the above functions: arrival / delivery perception items, operation anomaly perception items, navigation and guidance perception items, and traffic safety perception items. The specific functions of each perception item are as follows:

[0118] The delivery and pickup sensing component is mainly responsible for sensing order processing operations, including arrival at the store, delivery check-in, forgotten pickup, delivery reminders, fake arrivals, card meal identification, food preparation, and pickup calibration.

[0119] The Traffic Safety Perception component is primarily responsible for perceiving order-based operations, including detecting speeding, driving against traffic, running red lights, and driving on high-risk road sections; proactively discovering and reporting traffic accidents based on events, time, and location; and reconstructing traffic accidents.

[0120] The task anomaly detection item is mainly responsible for detecting order task operations, including road closure detection, detour detection, merchant / user not found detection, and indoor / outdoor route guidance.

[0121] The navigation guidance perception item is mainly responsible for perceiving order operation business, including the distance between rider and destination, navigation needs, and route updates.

[0122] When the proactive perception layer 502 detects any abnormalities or needs from a rider, it can invoke the corresponding operational services in the perception decision layer 503 for processing. For example, the safety service in the perception decision layer 503 can be invoked by the proactive perception layer 502 when a rider falls; the navigation service can be invoked when a rider needs navigation; the route update service can be invoked when a rider needs to change delivery routes; and the penalty service is invoked by the proactive perception layer 502 when a rider makes a false arrival or false report. The fulfillment anomaly service is invoked by the proactive perception layer 502 when a rider's delivery is late or the order's delivery status is abnormal. The intelligent check-in service is an auxiliary service used in conjunction with the penalty service. For example, when a rider makes a false arrival, the proactive perception layer can invoke the intelligent check-in service to determine whether the rider has indeed engaged in false arrival behavior. The platform strategy center is used to manage and update the service rules for each service.

[0123] After introducing the intelligent order processing framework 500, the following will be discussed... Figure 6 This application provides a detailed description of an intelligent order processing system based on embodiments of the present application. It should be understood that this intelligent order processing system can be applied to the server of a food delivery platform or to a user terminal. The user terminal refers to a smart device with a food delivery app installed. Specifically, in this application embodiment, because the intelligent order processing involves the acquisition and processing of a large amount of order data, and given the server's vast storage resources and computing power, the intelligent order processing system in this application embodiment is primarily deployed on the server side.

[0124] Figure 6 This is a structural diagram of an intelligent order processing system provided in an embodiment of this application.

[0125] For example, such as Figure 6 As shown in the illustration, an intelligent order processing system 600 provided in this application includes a task planning module, a destination prediction module, an anomaly detection module, and a demand detection module. When the server implements intelligent order processing through the intelligent order processing system 600, it mainly achieves this through calls or interactions between the task planning module and the destination prediction module, the anomaly detection module, and the demand detection module.

[0126] Specifically, the functions of each module are as follows:

[0127] The task planning module is used to determine the multiple processing steps that need to be executed sequentially during the rider's delivery order process based on the execution rules of intelligent order operation. These multiple processing steps include destination prediction, anomaly prediction, and demand prediction.

[0128] In the destination prediction stage, the task planning module is also used to obtain the N orders that the rider has to deliver and the target information associated with the rider, and call the destination prediction module so that the destination prediction module can determine the rider's destination based on the target information and the N orders, where N is a positive integer greater than or equal to.

[0129] In the anomaly prediction stage, the task planning module is also used to call the anomaly detection module so that the anomaly detection module can determine whether an operational anomaly occurs when the rider is processing the target order based on the target information during the rider's journey to the destination. The target order is the order associated with the destination.

[0130] When a rider experiences a work-related error, the task planning module is also used to determine the corresponding handling result and display the result.

[0131] In the demand forecasting stage, the task planning module is also used to call the demand detection module so that the demand detection module can determine whether there is a job demand when the rider is processing the target order based on the target information during the rider's journey to the destination.

[0132] When a rider has a task requirement, the task planning module is also used to determine the corresponding response result and display the response result.

[0133] The task planning module, as its name suggests, is used to break down, sequence, and match strategies for the entire intelligent order processing workflow. It uses business flow knowledge as its basic input. Business flow knowledge includes the execution rules of intelligent order processing, such as the various processing steps within the intelligent order processing workflow. Based on this, the task planning module can plan multiple processing steps in the rider delivery order process according to the execution rules of intelligent order processing, that is, determine the multiple processing steps that need to be executed sequentially in the rider delivery order process.

[0134] Optionally, in the embodiments of this application, the multiple processing steps include a destination prediction step, an anomaly prediction step, and a demand prediction step.

[0135] Based on the above processing steps, the task planning module begins to execute the intelligent order operation tasks of each processing step in sequence. First, the task planning module executes the destination prediction step.

[0136] In the destination prediction stage, it should be understood that during the delivery process, the rider's destination will vary depending on the order processing status and the number of orders. Furthermore, the surrounding environment and traffic conditions differ at different destinations. Therefore, the task planning module first needs to determine the rider's current destination to accurately identify any anomalies or needs.

[0137] It should be understood that, see also Figure 1As shown, during the delivery process, riders can accept orders on the waiting list page. A rider can accept one or more orders at a time. After successfully accepting an order, the N accepted orders become the N orders the rider needs to deliver. Here, N is greater than or equal to 1 and is a positive integer.

[0138] When predicting a rider's destination, the task planning module can obtain the rider's N orders to be delivered and the target information associated with the rider as a data source for intelligent perception.

[0139] For example, for each of the N orders, when a rider clicks the "grab" control for a particular order on the order-grabbing page, the user can send the order-related information to the server in response to the click, thereby allowing the task planning module to obtain the N orders.

[0140] The target information associated with riders specifically covers any information related to the rider, such as environmental information, profile information, location information, and operational information on the interface. The specific categories of information included in the target information vary depending on the purpose or process being achieved. The process of acquiring different types of information will be described in detail below when introducing the specific process of the embodiments of this application.

[0141] In the destination prediction module of the intelligent order operation system 600, the task planning module can call the destination prediction module in the destination prediction stage, so that the destination prediction module can determine the rider's destination based on the target information and N orders.

[0142] Specifically, in this embodiment of the application, when the task planning module calls the destination prediction module to determine the rider's destination, there are two scenarios.

[0143] Case 1: N equals 1 among the N orders to be delivered.

[0144] In one possible implementation, the target information includes the rider's location, the order status of N orders, the merchant's location, and the user's location; the destination prediction module is also used for:

[0145] When N equals 1, if the order status is "order accepted" or the rider's location is gradually approaching the merchant's location, the destination is determined to be the merchant's location; if the order status is "order picked up" or the rider's location is gradually approaching the user's location, the destination is determined to be the user's location.

[0146] It should be understood that when N is 1, it means that the rider has 1 order on their back, and there is only 1 user location and 1 merchant location for each order to be delivered. The location the rider needs to go to is either the merchant location or the user location for the current order. Therefore, when N is 1, determining the rider's destination only requires judging whether the rider's destination is the merchant location or the user location based on the current order processing stage or the rider's location.

[0147] Based on this, when determining the rider's destination using the target information and N orders, the destination prediction module first checks if N equals 1. When N equals 1, the target information includes the rider's location, the order status associated with the N orders, the merchant's location, and the user's location.

[0148] The following section will introduce several processes for obtaining target information.

[0149] For example, regarding rider location, during the rider's order processing process, the user's client can obtain the rider's location in real time through the built-in positioning system and send it to the server.

[0150] As described above, the order processing flow includes four stages: "Order Acceptance - Arrival at Store - Food Pickup - Delivery," each corresponding to a different order status. "Order Acceptance" corresponds to the status "Order Accepted," indicating that the order has been successfully accepted. "Arrival at Store" indicates that the rider has arrived at the merchant's location and is waiting to pick up the food. "Food Pickup" indicates that the rider has picked up the food from the merchant and is preparing to go to the user's location. "Delivery" indicates that the rider has delivered the food to the user, and the delivery is complete.

[0151] For the order status associated with N orders, based on the aforementioned Figures 1 to 3 The user interface displays a page for orders to be accepted. If a rider clicks the order-accepting control for an order, the user can send this click event to the server. The server responds to the click event by updating the order status to "accepted." Furthermore, the server can determine the control command corresponding to the click event and send it to the user to ensure synchronous updates. Specifically, the control command corresponding to the click event changes the order-accepting control from active to grayed-out and changes the control's text label from "accepted" to "accepted." Thus, the server can determine that the current order status is "accepted." The methods for obtaining other order statuses and the "accepted" status are similar and will not be elaborated upon here.

[0152] For N orders associated with merchant and user locations, once a user successfully places an order, the new order is created successfully. The server can obtain the order information associated with each successfully created order and generate a unique order identifier for each order. Simultaneously, the server sends the order information and order identifier associated with each successfully created order to the user's client. When a rider successfully accepts an order, the user's client can determine the order identifier associated with the accepted order and send it to the server. Based on the order identifier, the server determines which specific order it is and the order information associated with it. This order information includes the merchant and user locations associated with the current order.

[0153] After obtaining the rider's location, the order statuses associated with N orders, the merchant's location, and the user's location, when N is 1, the destination prediction module determines the rider's destination as follows: If the order status is "accepted," it means the rider is currently on their way to pick up the food; in this case, the destination prediction module determines the destination to be the merchant's location. Alternatively, if the rider's location is gradually approaching the merchant's location, it also indicates the rider is currently on their way to pick up the food, and the destination prediction module also determines the destination to be the merchant's location. Conversely, if the order status is "picked up," it means the rider is currently delivering the food; in this case, the destination prediction module determines the destination to be the user's location. Alternatively, if the rider's location is gradually approaching the user's location, it also indicates the rider is currently on their way to deliver the food, and the destination prediction module also determines the destination to be the user's location.

[0154] Therefore, when N is 1, the task planning module can determine the rider's destination by calling the destination prediction module.

[0155] In the above technical solution, when a rider has only one order to deliver, the system can determine the rider's destination through simple location matching. The above process is simple and efficient, without the need for complex judgment logic, and provides the correct location information for subsequent determination of the rider's needs and anomalies.

[0156] Scenario 2: N is greater than 1 among the N orders to be delivered.

[0157] In one possible implementation, the target information includes the rider's location, the delivery scenario in which the rider is located, and the rider's spatiotemporal sequence information within a preset time period; the task planning module is specifically used for:

[0158] When N is greater than 1, if the delivery scenario is a food pickup scenario, obtain the N merchant locations associated with the N orders; based on the rider's location, determine M candidate destinations from the N merchant locations, where M is less than or equal to N; or...

[0159] If the delivery scenario is food delivery, obtain the N user locations associated with N orders; based on the rider's location, determine M candidate destinations from the N user locations;

[0160] Obtain M attribute information for M candidate destinations, and M processing progress information for M orders, where the M orders are orders associated with the M candidate destinations;

[0161] The destination prediction module is invoked so that it can determine the destination from M candidate destinations based on M attribute information, M processing progress information, and spatiotemporal sequence information.

[0162] When N is greater than 1, it means that there are more than one merchant and one user corresponding to the N orders. In this case, the rider's destination may be at least one of the multiple merchant locations, or at least one of the multiple user locations. The destination prediction module cannot determine the destination through simple location matching alone.

[0163] In this case, when the task planning module calls the destination prediction module to determine the destination, it is divided into two steps. First, the task planning module initially determines the candidate destinations through the target information. Then, it calls the destination prediction module to select the destination that best matches the current scenario from the candidate destinations through the target information.

[0164] Specifically, when N is greater than 1, the target information when the task planning module determines the candidate destination mainly includes the rider's location and the delivery scenario in which the rider is located.

[0165] For example, the process of obtaining rider location is described above.

[0166] The delivery scenarios for riders include both food pickup and food delivery scenarios.

[0167] It should be understood that when a rider has multiple orders on their back, the order status of each order will be different during the rider's order processing.

[0168] In delivery scenarios, the task planning module can determine the rider's delivery scenario based on the order status of each order. For example, consider N orders: Order A, Order B, and Order C. If the order status of Order A, Order B, and Order C are all "accepted," it means each order is in the pickup stage, and the task planning module determines the rider's delivery scenario as a pickup scenario. Conversely, if the order status of Order A, Order B, and Order C are all "picked," it means each order is in the delivery stage, and the task planning module determines the rider's delivery scenario as a delivery scenario.

[0169] In another scenario, when the order statuses of N orders are inconsistent, the task planning module can determine the delivery scenario of the rider based on the rider's location. For example, if there are many shopping malls or restaurants around the rider's location, the task planning module can determine that the rider's delivery scenario is a food pickup scenario, even if the order statuses of the different orders are inconsistent. Similarly, if there are many schools or residential areas around the rider's location, the task planning module can determine that the rider's delivery scenario is a food delivery scenario, even if the order statuses of the different orders are inconsistent.

[0170] After obtaining the rider's location and the delivery scenario in which the rider is located, the task planning module can first use these two pieces of information to make a coarse-grained estimate of the destination and determine several possible destinations for the current rider, thereby narrowing down the range of destinations.

[0171] Specifically, when N is greater than 1, if the current delivery scenario is a food pickup scenario, it means the rider's destination must be a merchant location. The task planning module can first obtain the N merchant locations associated with the N orders. Further, based on the rider's location, the task planning module can determine N first distances between the rider's location and the N merchant locations. The merchant locations corresponding to the M first distances whose values ​​are less than or equal to a preset distance are then identified as M candidate destinations, where M is less than or equal to N. If the current delivery scenario is a food delivery scenario, it means the rider's destination must be a user location. The task planning module can first obtain the N user locations associated with the N orders. Further, based on the rider's location, the server can determine N second distances between the rider's location and the N user locations. The user locations corresponding to the M second distances whose values ​​are less than or equal to a preset distance are then identified as M candidate destinations.

[0172] It should be understood that the above M candidate destinations are destinations with a relatively high probability of being visited by riders. In order to accurately determine the destinations visited by riders, the task planning module needs to call the destination prediction module so that the destination prediction module can combine the regional characteristics of the candidate destinations (i.e., attribute information), the rider's processing progress information of the M orders corresponding to the M candidate destinations, and the rider's behavior trajectory in continuous time (i.e., spatiotemporal sequence information) to accurately determine the rider's destination.

[0173] In one possible implementation, the system further includes a location encoding module and an event encoding module. The M attribute information includes M points of interest and M regions of interest, and the spatiotemporal sequence information includes a location state sequence and a sequence of M operation events for the M orders. The destination prediction module is specifically used for:

[0174] For any candidate destination among the M candidate destinations, the processing progress information associated with the candidate destination is concatenated to obtain the dense processing progress feature of the candidate destination.

[0175] The location encoding module is invoked to encode M points of interest, M regions of interest, and a sequence of location states to obtain the third location feature.

[0176] The event encoding module is invoked to encode the sequence of M operation events, thereby obtaining the second operation event characteristics;

[0177] The destination is determined from the M candidate destinations based on the dense processing progress characteristics, the third location characteristics, and the second operational event characteristics.

[0178] Specifically, when determining the destination, the attribute information of the candidate destination includes the Area of ​​Interest (AOI) and Point of Interest (POI) associated with the candidate destination. The spatiotemporal sequence information includes the rider's location status sequence within a preset time period prior to the current moment, and the sequence of M operation events performed by the rider on M orders within the preset time period. The processing progress information associated with the candidate destination mainly includes the distance between the rider's current location and the candidate destination, the estimated time of arrival (ETA) for the rider to reach the candidate destination, and the actual processing time for the orders corresponding to the candidate destination.

[0179] For example, taking a candidate destination as an example, the task planning module can calculate the distance between the rider's location and the candidate destination based on the rider's location. For the ETA required for the rider to reach the candidate destination, the task planning module can call the route planning interface of the map service based on the rider's location and the candidate destination to determine the ETA for the rider to reach the candidate destination; alternatively, the task planning module can determine the time required for the rider to reach the candidate destination based on the rider's average speed during the current processing process and the distance between the rider's location and the candidate destination, and the sum of the current time and the time is the ETA for the rider to reach the destination.

[0180] Regarding the actual processing time of orders corresponding to candidate destinations by riders, when the order status of the order corresponding to the candidate destination is "accepted", the task planning module can record the start time of the processing of the order and obtain the actual processing time of the order by the difference between the current time and the start time of processing.

[0181] The AOI associated with a candidate destination represents the AOI where the candidate destination is located, indicating the area corresponding to the candidate destination. This area comprises all locations centered on the candidate destination and within a certain distance range from it. The POI associated with a candidate destination represents the location type of the candidate destination; for example, POIs include shopping districts, restaurants, convenience stores, and residential areas.

[0182] For example, the AOI and POI associated with a location are usually manually assigned. After identifying candidate destinations, the task planning module can directly match the candidate destinations with map data to obtain the AOI and POI associated with the candidate destinations.

[0183] A location-state sequence refers to a sequence of positions and states corresponding to multiple consecutive moments within a preset time period prior to the current moment. Position refers to the rider's location or positional information. State refers to the rider's movement state, such as cycling, walking, standing still, or riding an elevator.

[0184] For example, if the preset time period includes 5 consecutive moments, the location state sequence can be represented as {Location 1, State 1; Location 2, State 2; Location 3, State 3; Location 4, State 4; Location 5, State 5}. The rider's location can be obtained through the user's location system.

[0185] Regarding the rider's movement status, in one scenario, the server can obtain the rider's location through the positioning system in the user's terminal and determine the movement status based on the frequency of location changes, or it can obtain the movement status based on the accelerometer in the user's terminal.

[0186] For example, if the rider's position change frequency is almost 0 or the rider's acceleration is 0, the server determines the rider's motion state as stationary; if the rider's position change frequency is low or the acceleration is very small, the server determines the rider's motion state as walking; if the rider's position change frequency is high or the acceleration is high, the server determines the rider's motion state as cycling.

[0187] In another scenario, the server can also obtain the rider's motion status through the gyroscope on the user's device. For example, when the server determines through the gyroscope that the rider is experiencing a change in acceleration in the vertical direction, the server can determine that the rider's motion status is that of riding an elevator.

[0188] An operation event sequence refers to a sequence of operation events occurring at multiple consecutive moments within a preset time period prior to the current moment. Specifically, operation events refer to events performed by the rider on the display interface of the food delivery app, such as click events, swipe events, zoom-in / zoom-out events, etc.

[0189] For example, when a rider performs an operation on the display page, the user client can use the event listener interface at the code layer to capture the rider's operation behavior in the food delivery app in real time and send it to the server.

[0190] After the task planning module obtains the M attribute information of M candidate destinations and the processing progress information of M orders, it can send the above information to the destination prediction module.

[0191] After obtaining the above information, the following steps will be taken... Figure 7 The process of determining the destination by the destination prediction module is introduced.

[0192] Figure 7 This is a flowchart of a destination prediction module provided in an embodiment of this application.

[0193] For example, such as Figure 7 As shown, the destination prediction module, specifically the destination prediction model, has an overall structure including an encoding layer, a pooling and concatenation layer, a multilayer perceptron (MLP), and an output layer. The encoding layer comprises two encoders: GeoEncoder (i.e., the location encoding module or model) and EventEncoder (i.e., the event encoding module or model). GeoEncoder primarily encodes location-related information, while EventEncoder primarily encodes operational event information. These two encoding modules are two trained encoding models with different functions. Before introducing the overall destination prediction process, the training process of the two encoding modules will be described first.

[0194] (1) Training process of GeoEncoder

[0195] The following is through Figure 8 The training process of GeoEncoder is described in detail.

[0196] Figure 8 This is a flowchart of the workflow of a GeoEncoder provided in an embodiment of this application.

[0197] For example, such as Figure 8 As shown, in this embodiment of the application, GeoEncoder can be obtained by pre-training based on the existing MGeo model. The MGeo model is specifically designed for processing geographic information.

[0198] Specifically, when pre-training the MGeo model, for any historical order among multiple historical orders in the historical order processing process, the input information includes the merchant location and user location corresponding to the historical order, the AOI and POI associated with the merchant location corresponding to the historical order, the road network (i.e., delivery route) between the merchant location and user location corresponding to the historical order, and the location status sequence of the rider delivering the historical order.

[0199] During pre-training, the various information items corresponding to each historical order can be input into the MGeo model. The MGeo model mines and learns the inherent connections and patterns between different types of geographic information in order to better represent them. The MGeo model processes the aforementioned geographic information, transforming these originally diverse and dimensional geographic data into a unified embedding representation.

[0200] After obtaining a unified embedding representation, a suitable loss function is defined for the MGeo model to measure the difference between the model's predictions and the true labels. Specifically, the true label is the true embedding representation corresponding to each historical order. By calculating the difference between the output embedding representation and the true embedding representation, the model's loss function is calculated, and the model's parameters are continuously adjusted to minimize the loss function as training progresses until the model is successfully trained.

[0201] Thus, through the above process, the successfully trained MGeo model, namely GeoEncoder, can be obtained in the embodiments of this application.

[0202] (2) Training process of EventEncoder

[0203] The following is through Figure 9 The training process of EventEncoder is introduced.

[0204] Figure 9 This is a flowchart of the workflow of an EventEncoder provided in an embodiment of this application.

[0205] For example, such as Figure 9 As shown, the training process of EventEncoder can be roughly divided into the following steps:

[0206] (1) According to the Origin-Destination (OD) segment of the order, count the rider's operation events, sort all the operation events in the order of their occurrence time, and form the operation event sequence corresponding to the OD segment.

[0207] Optionally, the OD segment can refer to the order receiving location-merchant location, the merchant location-user location, or the order receiving location-user location. This application embodiment does not limit this.

[0208] For example, taking the OD segment as the order receiving location - merchant location, the corresponding operation event sequence might be: enter the order list page - click the order details card - view the merchant location - use navigation.

[0209] (2) For the above-mentioned sequence of operation events, this embodiment can draw on the concept of text language processing, analogizing each operation event in the sequence to a "word (token)," and the sequence of operation events within an OD segment to a "sentence," to represent an ordered combination of a series of operation events. For a rider, the sequence of operation events in the OD segments corresponding to multiple orders processed within a wave is analogous to an "article." Through the above process, discrete operation events can be organized into a structured sequence of operation events according to task logic.

[0210] For any one of the operation events, in this embodiment of the application, when encoding the operation event through EventEncoder, the principle of Enhanced Graph Embedding with SideInformation (EGES) model is relied upon to convert the information related to each operation event into a comprehensive vector through embedding technology, making it a feature vector that can be directly used for calculation.

[0211] Figure 9 (a) in the diagram shows the overall structure of the EGES model. The EGES model includes a sparse feature layer, a dense embedding layer, a hidden representation, an output matrix, and a sampled softmax classifier.

[0212] Based on the above structure, the information related to each operation event includes the event identifier (event_id), the event's position identifier in the operation event sequence (i.e., event position identifier) ​​(event_pos_id), the functional module identifier (i.e., event module identifier) ​​(event_module_id), and the page identifier (i.e., event page identifier) ​​(event_page_id). This original operation event-related information is essentially discrete ID-type data, representing the sparse characteristic of events.

[0213] The EGES model transforms these sparse features into continuous, low-dimensional, dense embedding vectors, obtaining embedding vectors related to multiple operation events. The EGES model then weights and fuses these embedding vectors to obtain a comprehensive hidden layer representation (i.e., a comprehensive vector). Finally, a matrix and classifier are used to complete the classification task. The final step of using a matrix and classifier for classification is not involved in the encoding process.

[0214] Based on the encoding principle of EventEncoder described above, Figure 9 (b) is a flowchart of the training process of a multimodal alignment model provided in the embodiment of this application, which is the further processing after encoding the operation event sequence, specifically including the following step (3).

[0215] (3) By introducing a modal alignment layer, the vectors encoded by EventEncoder are aligned to the text space. Specifically, the event lookup table is used to perform text escaping to obtain the text description of the operation event. For example, the text description corresponding to a certain operation event is to zoom in on the map on the order details page; EventEncoder is used to encode the event (including page, module, location, etc.), and a text encoding model or text encoder is used to encode the escaped text; TextEncoder can use different language representation models; the two types of encoding are aligned to a unified space through a multimodal interaction layer; modal alignment is performed by training the model through a loss function.

[0216] like Figure 9 As shown in (b), for a sequence of operation events, EventEncoder can... Figure 9 The encoding process shown in (a) is used to encode the operation event to obtain a comprehensive vector. Secondly, in this embodiment, the operation event and the mapping relationship between the operation event and the text description can be used to obtain the text description corresponding to each operation event, and the text description can be encoded using TextEncoder to obtain a text description vector.

[0217] Furthermore, the vectors output from the two encoders are concatenated to obtain a concatenated vector, which is then input into a multi-modal interaction (MDI) transformer layer. This MDI layer, combining multiple transformer layers, uses the transformer's self-attention mechanism to capture the interaction relationships between different modal features, allowing for the full fusion of the two features and resulting in more expressive cross-modal features, or cross features. A loss function, such as contrastive loss or triplet loss, is then used to train the MDI alignment model until successful training.

[0218] The multimodal alignment training process described above is a method for training the EventEncoder. Its purpose is to make the vectors generated by the EventEncoder more accurate from the perspective of text semantics. When the multimodal alignment model is successfully trained, it means that the EventEncoder is also successfully trained.

[0219] After the two encoding modules are successfully trained, when it is necessary to predict the rider's destination, the destination prediction module can be further trained by combining GeoEncoder and EventEncoder in this embodiment of the application.

[0220] like Figure 7 As shown, during the training of the destination prediction module, technicians can select processing progress information related to multiple candidate destinations in the actual order processing process, including distance, ETA, and the actual processing time for the rider to process the corresponding order. Secondly, technicians also need to obtain the AOI and POI associated with the candidate destinations, the location status sequence of the rider during the historical time during order processing, and the sequence of multiple operation events of the rider for orders corresponding to multiple candidate destinations.

[0221] The GeoEncoder takes location state sequences, associated AOIs and POIs of candidate destinations as input. It encodes this location-related information, transforming it into vectors with geospatial feature representation capabilities, and mines the correlations between locations and geospatial patterns and features to obtain location features.

[0222] Multiple operation event sequences are taken as input to the EventEncoder, which encodes them to obtain operation event characteristics.

[0223] Among them, the processing progress information related to the above-mentioned multiple candidate destinations is itself a directly computable numerical feature. Without complex encoding, it can be directly integrated into a unified vector, i.e., dense processing progress feature, by concatenating the multi-dimensional numerical features.

[0224] Furthermore, the destination prediction module performs pooling operations (such as max pooling, average pooling, etc.) on the location features output by GeoEncoder and the operation event features output by EventEncoder to extract key information or reduce dimensionality. Then, the pooled results are concatenated to integrate different types of features into a comprehensive feature that includes geography and operation behavior.

[0225] The concatenated comprehensive features are input into the MLP, which consists of multiple fully connected layers. Through nonlinear transformation, the complex relationships between features are further extracted and learned, and the comprehensive features are processed in depth to obtain high-dimensional comprehensive features.

[0226] The high-dimensional integrated features output by the MLP and the directly input processing progress features are finally fused at the nodes before the output layer (e.g., vector concatenation or weighted summation) to form the final integrated features. The final integrated features are then converted into predicted probabilities for each candidate destination (e.g., which location is most likely the final destination) by the output layer. These probabilities are then compared with the true labels using the Cross Entropy Loss function to inversely optimize the model parameters (including the fusion weights of the GeoEncoder, EventEncoder, MLP, and output layer) until the destination prediction module is successfully trained.

[0227] Once the destination prediction module is successfully trained, during application, such as Figure 7 As shown, candidate point 1 is candidate destination 1, candidate point 2 is candidate destination 2, and so on, with candidate point m being candidate destination M. The destination prediction module can concatenate the processing progress information of each candidate destination to obtain dense processing progress features of M candidate destinations. In addition, the destination prediction module can also encode the M AOIs and M POIs associated with the M candidate destinations, as well as the rider's position state sequence, using GeoEncoder to obtain the third position feature, and encode the M operation event sequences using EventEncoder to obtain the second operation event feature.

[0228] Furthermore, the destination prediction module can determine the destination from the M candidate destinations based on the dense processing progress characteristics, the third location characteristics, and the second operation event characteristics of the M candidate destinations.

[0229] Combination Figure 7The training process, including the process of determining the destination, is further as follows.

[0230] In one possible implementation, the destination prediction module is also used for:

[0231] The second operational event feature and the third location feature are pooled and concatenated to obtain the concatenated third low-dimensional joint feature.

[0232] A multi-level nonlinear transformation is performed on the third low-dimensional joint feature to obtain the third high-dimensional joint feature;

[0233] Based on the dense processing progress characteristics of the M candidate destinations and the third high-dimensional joint features, determine the M output probabilities corresponding to the M candidate destinations;

[0234] The candidate destinations corresponding to the probabilities that are greater than or equal to the third preset probability among the M output probabilities are determined as the destinations.

[0235] Specifically, such as Figure 7 As shown, the destination prediction module pools and concatenates the third location feature and the second operation event feature to obtain the third low-dimensional joint feature. The third low-dimensional joint feature is then input into the MLP layer for multi-layer nonlinear transformation to obtain the third high-dimensional joint feature. The dense processing progress features of the M candidate destinations and the third high-dimensional joint feature are then input into the output layer, which transforms them into the prediction probabilities of the M candidate destinations, i.e., the M output probabilities.

[0236] In this embodiment of the application, a third preset probability can be preset to filter destinations. For example, the third preset probability can be 0.8.

[0237] After obtaining M output probabilities, the destination prediction module can determine the candidate destinations whose probabilities are greater than or equal to a third preset probability from among the M output probabilities as the destinations. Optionally, the number of destinations can be one or more.

[0238] Thus, through the above process, the task planning module obtains the rider's destination by calling the destination prediction module or directly through distance matching.

[0239] After predicting the rider's destination, the task planning module completes the destination prediction phase. Next, it proceeds to the anomaly prediction phase.

[0240] In the intelligent order management system 600, the anomaly detection module and task planning module can call the anomaly detection module during the anomaly prediction phase. This allows the anomaly detection module to determine, based on target information, whether an operational anomaly has occurred while the rider is processing the target order during their journey to the destination. The target order is an order associated with the destination among N orders.

[0241] Specifically, the task planning module's call to the anomaly detection module to determine whether a rider has experienced an operational anomaly involves two stages. The first stage involves the task planning module combining target information and historical datasets to predict the rider's current operational anomaly. The next step involves calling the anomaly detection module, combined with target information, to verify whether the predicted operational anomaly has occurred.

[0242] In one possible implementation, the target information includes the order status of the target order, the distance between the rider's location and the destination, the rider's profile information and abnormal trajectory types, weather type, multiple movement states of the rider within a preset time period, and spatiotemporal sequence information; the task planning module is specifically used for:

[0243] Predict the rider's current operational anomalies based on multiple motion states and weather types, or based on abnormal trajectory types, the distance between the rider's location and the destination, and the order status of the target order;

[0244] The anomaly detection module is invoked so that it can determine whether the rider has experienced a predicted operational anomaly based on the rider profile information, weather type, and spatiotemporal sequence information.

[0245] When determining whether a rider has experienced an operational anomaly, the target information includes the distance between the rider's location and the destination, the order status of the target order, the rider's profile information and the type of abnormal trajectory, the weather type, and the rider's multiple movement states and spatiotemporal sequence information within a preset time period.

[0246] Optionally, the rider's abnormal trajectory types include U-turns, speeding, and abnormal stops.

[0247] For example, the above-mentioned abnormal trajectory types can be obtained through rider location, the distance between the rider's location and the destination, and rider speed. For instance, if the server detects that the rider's location repeats itself over a period of time, it determines the abnormal trajectory type as a U-turn. As another example, if the server detects that the distance between the rider's location and the destination gradually decreases and then gradually increases, it determines the abnormal trajectory type as a U-turn. Furthermore, if the server determines that the rider's location has not changed or the rider's speed is 0 over a period of time, it determines that the rider has an abnormal stop.

[0248] For example, rider profile information includes statistical information from the rider's historical processing history, which the server can obtain by analyzing the rider's order processing data. For instance, the statistical information includes the rider's average delivery time, total number of orders received, rider's late delivery rate, and rider's on-time delivery rate.

[0249] Regarding weather type, the server can obtain the current weather type at the rider's location through a third-party weather interface.

[0250] The process of obtaining the order status, movement status, and rider's spatiotemporal sequence information associated with the target order is described above and will not be repeated here.

[0251] When determining whether a rider has experienced an operational anomaly, the task planning module can first combine historical delivery data and the rider's current information to predict the possible operational anomalies that the rider may experience under the current delivery scenario and environmental conditions. Then, it can further verify whether the rider has experienced the predicted operational anomaly by using the rider's current information.

[0252] Specifically, the task planning module can predict rider's current operational anomalies based on the rider's multiple movement states and weather types, or based on abnormal trajectory types, the distance between the rider's location and the destination, and the order status of the target order.

[0253] For example, consider a scenario where multiple riders are stationary and the weather is rainy. In the historical order processing dataset, other riders experienced falls under the same conditions. The task planning module, by analyzing the correspondence between movement states, weather types, and anomalies in the historical order dataset, can determine that the current rider may have experienced a fall.

[0254] Another example, taking the merchant's location as the candidate destination, if the distance between the rider's location and the destination is large, and the rider's abnormal trajectory type is speeding, and the order status has changed to "arrived at store," it indicates that the rider performed the "arrival at store" operation before actually reaching the merchant. In the same scenario described above, other riders have experienced false arrival anomalies in the historical order processing dataset. Therefore, the task planning module, through the correspondence between the above three pieces of information and anomalies in the historical order dataset, matches the current rider and determines that a false arrival anomaly may have occurred.

[0255] Based on the above-mentioned operational anomalies predicted using historical datasets, in order to further verify the accuracy of the anomalies, the task planning module can call the anomaly detection module in system 600 to determine whether the rider has indeed experienced the predicted operational anomaly, based on the rider's profile information, weather type, and the rider's spatiotemporal sequence information.

[0256] In the aforementioned technical solution, when detecting whether an operational anomaly occurs during a rider's journey to their destination, the task planning module in this application first predicts the rider's current operational anomaly based on multiple dimensions such as the rider's movement status, weather, trajectory, and order status. This allows for timely identification of potential anomalies during the rider's order processing. Furthermore, based on the predicted operational anomalies, to verify the accuracy of the prediction, the task planning module calls the anomaly detection module. Using the rider's profile information, weather type, and spatiotemporal sequence information, it determines whether the predicted anomaly has occurred. This enables more accurate identification of actual operational anomalies, reduces false positives, and improves the accuracy of anomaly detection.

[0257] To facilitate understanding of the workflow of the anomaly detection module in the embodiments of this application, the following is a brief explanation. Figure 10 The working process and training process of the anomaly detection module are introduced.

[0258] Figure 10 This is a flowchart of an anomaly detection module provided in an embodiment of this application.

[0259] For example, such as Figure 10 As shown, this is the anomaly detection module, also known as the anomaly detection model. The structure of the anomaly detection module is similar to... Figure 7 The structure of the mid-term prediction module is roughly the same, including an encoding layer, a pooling and splicing layer, a multilayer perceptron, and an output layer.

[0260] The training process for the two encoders in the coding layer is described above. Figures 8 to 9 The details of that will not be repeated here.

[0261] When training the anomaly detection module, for a large number of historical orders delivered by multiple riders during the historical order delivery process, the server can collect statistical information of multiple riders, the location status sequence of each rider when processing each order, the operation event sequence, and the weather type.

[0262] Upon receiving the aforementioned data, the anomaly detection module can input the rider's location state sequence into the GeoEncoder for encoding to obtain location features, and input the operation event sequence into the EventEncoder for encoding to obtain operation event features. The encoded features, along with statistical information and weather type, are pooled and concatenated to combine features from different sources into a single vector, resulting in a comprehensive feature that integrates multi-dimensional information.

[0263] Furthermore, the model can input the fused comprehensive features into an MLP for multi-level linear transformation. This multi-layer neural network further processes the comprehensive features to obtain higher-dimensional comprehensive features. The model then inputs these higher-dimensional comprehensive features from the MLP into the output layer. The output layer uses a multi-class activation function (e.g., the Softmax function) to normalize the higher-dimensional comprehensive features, outputting the probability of each pre-defined type of operational anomaly. Examples include the probability of a fall, a false arrival at the store, a delivery delay, and a food waste issue.

[0264] Finally, based on the multiple anomaly probabilities output by the anomaly detection module, the server can compare each anomaly probability with the labeled true multi-class anomaly tags.

[0265] Optionally, the true multi-class anomaly labels are in one-hot encoded form. For example, a fall anomaly is labeled as [1,0,0,0], and a false visit anomaly is labeled as [0,1,0,0], etc. The server calculates the multi-class cross-entropy loss function and uses an optimization algorithm to backpropagate and adjust the model parameters so that the loss gradually decreases until the preset convergence condition is met.

[0266] In this embodiment, the actual anomaly labels include, but are not limited to, fall anomalies, false arrival anomalies, delivery timeout anomalies, meal card anomalies, and route deviation anomalies. Based on this, the predicted anomaly probability output by the model is a probability value between 0 and 1 for each type of anomaly (the sum of the probabilities of all categories is 1).

[0267] After the anomaly detection module is successfully trained, it can be used in the application process as described above. Figure 10 The process shown outputs the probability distribution of multiple types of anomalies or the final judgment result, thereby determining whether the rider has experienced a predicted type of operational anomaly.

[0268] In one possible implementation, the system further includes a location encoding module and an event encoding module. The profile information includes statistical information about the rider's historical order processing history, and the spatiotemporal sequence information includes a location status sequence and a sequence of operation events for the target order. The anomaly detection module is specifically used for:

[0269] The position encoding module is invoked to encode the position state sequence and obtain the first position feature;

[0270] The event encoding module is invoked to encode the sequence of operation events for the target order, thereby obtaining the first operation event feature.

[0271] Based on the first location characteristics, the first operational event characteristics, statistical information, and the weather type, it is determined whether the rider has experienced the predicted operational anomaly.

[0272] Specifically, see Figure 10 After acquiring statistical information, location status sequences, and operation event sequences of the target order from the rider's historical order processing process, the anomaly detection module can encode the location status sequences using GeoEncoder to obtain the first location feature, and encode the operation event sequences using EventEncoder to obtain the first operation event feature. Furthermore, the anomaly detection module can input the first location feature, the first operation event feature, statistical information, and weather type into the pooling and concatenation layer to determine whether the rider has experienced a predicted operational anomaly.

[0273] Specifically, the anomaly detection module determines whether a rider has experienced a predicted operational anomaly based on the aforementioned characteristics as follows.

[0274] In one possible implementation, the anomaly detection module is also used for:

[0275] The first location feature, the first operational event feature, statistical information and weather type are pooled and concatenated to obtain the concatenated first low-dimensional joint feature.

[0276] A multi-level nonlinear transformation is performed on the first low-dimensional joint features to obtain the first high-dimensional joint features;

[0277] Based on the first high-dimensional joint features, the probability of predicted operation anomalies is determined;

[0278] When the probability of occurrence is greater than or equal to the first preset probability, it is determined that the rider has experienced the predicted operational anomaly.

[0279] If the probability of occurrence is less than the first preset probability, it is determined that the rider did not experience the predicted operational anomaly.

[0280] For example, such as Figure 10 As shown, the anomaly detection module can input the first location feature, the first operation event feature, statistical information, and weather type into the pooling and splicing layer. First, pooling operations are performed on the three features respectively to compress the feature information to a fixed dimension, resulting in the dimensionality-reduced features of the three features. Then, the dimensionality-reduced features of the three features are spliced ​​to obtain the spliced ​​first low-dimensional joint feature, which is then input into the MLP layer for multi-layer nonlinear transformation. The spliced ​​first low-dimensional joint feature is then mined through a multi-layer neural network to obtain the first high-dimensional joint feature.

[0281] Finally, the anomaly detection module inputs the first high-dimensional joint feature to the output layer, which outputs the anomaly probabilities corresponding to various types of operational anomalies, and the sum of the anomaly probabilities is 1.

[0282] The anomaly detection module can determine the anomaly probability corresponding to the job anomaly predicted by the task planning module from multiple anomaly probabilities, that is, the predicted probability of the job anomaly occurring.

[0283] In this embodiment, a first preset probability can be preset as a critical probability for determining whether the predicted anomaly has occurred. Optionally, the first preset probability is 0.8.

[0284] When the predicted probability of an operational anomaly is greater than or equal to the first preset probability, the anomaly detection module determines that the rider is currently experiencing a predicted operational anomaly; conversely, when the predicted probability of an operational anomaly is less than the first preset probability, the anomaly detection module determines that the rider is currently not experiencing a predicted operational anomaly.

[0285] In addition to determining whether a rider has experienced a predicted operational anomaly through the methods described above, the anomaly detection module can also identify the highest probability from multiple anomaly probabilities and compare the anomaly category corresponding to the highest probability with the predicted operational anomaly. If the anomaly category corresponding to the highest probability matches the predicted operational anomaly, the anomaly detection module determines that the rider experienced the predicted operational anomaly. If the anomaly category corresponding to the highest probability does not match the predicted operational anomaly, the anomaly detection module determines that the rider did not experience the predicted operational anomaly.

[0286] Furthermore, the anomaly detection module can feed back the judgment results to the task planning module.

[0287] When a rider experiences a predicted task anomaly, the task planning module can also determine the corresponding handling outcome.

[0288] In one possible implementation, the task planning module is also used for:

[0289] Based on the job anomalies, determine the anomaly handling strategy and the job services associated with the anomaly handling strategy;

[0290] The exception handling strategy is invoked to execute the associated job service and obtain the processing result corresponding to the job exception.

[0291] The above-mentioned operational anomalies are the predicted operational anomalies.

[0292] Specifically, in the embodiments of this application, multiple job services can be pre-set for handling different exception handling strategies, and different job services store the execution logic (i.e., exception handling strategies) for different job exceptions.

[0293] The task planning module can call the corresponding job service to execute the corresponding exception handling strategy based on the predicted job exceptions, and obtain the handling result of the job exception.

[0294] For example, if the job exception is a fake in-store exception, the corresponding job service is... Figure 5 The penalty service in the system can handle abnormal situations such as false in-store visits by deducting the rider's credit points and a certain amount of money.

[0295] If the job abnormality is a fall, the corresponding job service is the safety service. The safety service's abnormality handling strategy for fall abnormalities may include asking the rider if they need medical assistance and adjusting the rider's order delivery plan.

[0296] After the job service executes the corresponding exception handling strategy, it can display the handling results of the job exception on the user's end for riders to view.

[0297] In the above technical solution, when a rider encounters an abnormality in the target operation, the task planning module automatically calls the corresponding operation service to automatically execute the target operation abnormality handling strategy, realizing full-link automation from abnormality detection to result generation. This avoids the problems of delay and long work cycle caused by manual abnormality handling, ensures the timeliness and efficiency of abnormality handling, and improves the rider's delivery experience.

[0298] After completing the anomaly prediction phase, the task planning module begins the demand prediction phase.

[0299] In the intelligent order management system 600, the demand detection module and task planning module can call the demand detection module during the demand prediction phase. This allows the demand detection module to determine, based on target information, whether there is a demand for the rider to process the target order while the rider is traveling to the destination. The target order is an order associated with the destination among N orders.

[0300] Specifically, the task planning module's process of calling the demand detection module to determine whether a rider has a job requirement involves two stages. The first stage involves the task planning module combining target information and historical datasets to predict the rider's current job requirement. The next step involves calling the demand detection module, combined with target information, to verify whether the rider currently has the predicted job requirement.

[0301] In one possible implementation, the target information includes statistical information on the rider's historical order processing, the rider's delivery preferences and familiarity with the destination, traffic information, weather type, destination attribute information, and the rider's spatiotemporal sequence information within a preset time period; the task planning module is specifically used for:

[0302] Predict the rider's current operational needs based on delivery familiarity or traffic information and delivery preferences;

[0303] The demand detection module is invoked so that it can determine whether the rider has predicted job demand based on delivery preferences, delivery familiarity, destination attribute information, statistical information, weather type and spatiotemporal sequence information.

[0304] In determining the rider's target job requirements, the target information includes statistical information from the rider's historical order processing process, the rider's delivery preferences and familiarity with the destination, traffic information and weather type of the rider's environment, the rider's spatiotemporal sequence information, and destination-related attribute information.

[0305] For details on how riders obtain statistical information, rider location, weather type of the rider's environment, spatiotemporal sequence information, and destination-related attribute information during historical order processing, please refer to the aforementioned description, which will not be repeated here.

[0306] For example, regarding traffic information in the rider's environment, the server can use the rider's location to query the current traffic information on the map to determine whether the road where the rider is currently located is congested.

[0307] Rider delivery preferences refer to the tendencies and preferences that riders exhibit towards various delivery-related elements based on their own needs, habits, experience, and other factors during the delivery process.

[0308] For example, a rider's delivery preferences can include regional preferences, order type preferences, delivery time preferences, and delivery route preferences. Regional preferences refer to the specific areas a rider prefers to deliver to. Order type preferences refer to the type of goods corresponding to the order, such as food orders, pharmaceutical orders, and fresh produce orders. Delivery time preferences refer to the preferred delivery times. Delivery route preferences refer to the route characteristics a rider prefers when delivering orders, such as fewer traffic lights but longer distances, more traffic lights but shorter distances, and avoiding congested areas.

[0309] For example, the server can send a questionnaire to the user's food delivery app to collect riders' delivery preferences in the form of a questionnaire, or the server can analyze riders' operational behavior data and delivery data on the food delivery app to collect and analyze riders' delivery preferences.

[0310] To assess a rider's familiarity with a destination, the server can match the destination with the merchant's and user's locations in the rider's historical orders to determine if the rider has previously delivered to that destination. For example, if a rider is newly registered and has no prior delivery history, their familiarity with the destination is low; conversely, if a rider has a long track record and their historical delivery history includes deliveries to that destination, their familiarity is high. In this embodiment, to quantify a rider's familiarity with a destination, different familiarity levels can be pre-set based on the number of times the rider has delivered to that destination.

[0311] For example, if the number of times a rider makes deliveries to the destination is less than the number of times they made the first delivery, the corresponding delivery familiarity level is determined to be Level 1; if the number of times a rider makes deliveries to the destination is greater than or equal to the number of times they made the first delivery but less than the number of times they made the second delivery, the corresponding delivery familiarity level is determined to be Level 2; if the number of times a rider makes deliveries to the destination is greater than the number of times they made the second delivery, the corresponding delivery familiarity level is determined to be Level 3. Optionally, the number of times they made the first delivery can be two, and the number of times they made the second delivery can be six.

[0312] Similar to the process of identifying operational anomalies, when determining whether a rider has operational needs, the task planning module can combine historical delivery data and various current information about the rider to predict the potential operational needs of the rider under the current delivery scenario and environment. Furthermore, it can verify whether the predicted operational needs exist by using various current information about the rider.

[0313] Specifically, the task planning module can predict the rider's task requirements based on the rider's delivery preferences and familiarity with delivery, or based on traffic information in the rider's environment.

[0314] For example, a rider's delivery familiarity level might be 1, indicating that the rider is unfamiliar with the area around the destination. In the historical order dataset, other riders in the same scenario have navigation needs. The server can then use the mapping between delivery familiarity and needs in the historical order dataset to identify potential navigation needs of the current rider.

[0315] Another example: if the rider is in a congested traffic situation and their delivery preference is to avoid congested areas, it indicates that the rider may need to change their delivery route. In the same scenario described above, other riders in the historical order dataset also have navigation needs. Therefore, the server uses the correspondence between delivery preferences, traffic information, and needs in the historical order dataset to match the current rider's potential need to adjust their delivery route.

[0316] Based on the above-mentioned job demand predicted from historical datasets, in order to further verify the accuracy of the demand, the task planning module can call the demand detection module in system 600 to determine whether the rider actually has the predicted job demand based on the rider's profile information, weather type, rider's spatiotemporal sequence information and destination-related attribute information.

[0317] In the aforementioned technical solution, when detecting whether there is a work demand while the rider is traveling to the destination, the task planning module in this application first predicts the rider's current work demand based on multiple dimensions such as the rider's delivery habits, delivery familiarity, and traffic conditions of the surrounding environment. This allows for timely identification of potential demands during the rider's order processing. Furthermore, based on the predicted work demand, to verify the accuracy of the prediction, the task planning module calls the demand detection module. Through rider profile information, weather type, destination-related attribute information, and spatiotemporal sequence information, it determines whether the predicted demand exists. This enables more accurate identification of actual work demands, reduces misidentification of work demands, and improves the accuracy of work demand identification.

[0318] To facilitate understanding of the workflow of the requirement detection module in the embodiments of this application, the following is a brief explanation. Figure 11 The working process and training process of the demand detection module are introduced.

[0319] Figure 11 This is a flowchart of a requirement detection module provided in an embodiment of this application.

[0320] For example, such as Figure 11 As shown, this is the requirement detection module, also known as the requirement detection model. The structure of the requirement detection module is similar to... Figure 7 Destination prediction module and Figure 10 The structure of the anomaly detection module is roughly the same, including an encoding layer, a pooling and splicing layer, a multilayer perceptron, and an output layer.

[0321] based on Figure 11 The loss function in the demand detection module is the binary cross-entropy loss. When training the demand detection module, a separate binary demand detection module (i.e., a binary demand detection model) can be trained for each type of demand.

[0322] Specifically, when training any binary classification demand detection module, for a large number of historical orders delivered by multiple riders during the historical order delivery process, the server can collect statistical information of multiple riders, the location state sequence of each rider when processing each order, the operation event sequence, the weather type, and the AOI and POI of the historical destination corresponding to each operation event sequence and location state sequence. For example, if the OD segment corresponding to the operation event sequence is order acceptance-merchant, then the AOI and POI of the historical destination refer to the AOI and POI of the merchant location corresponding to that order. If the OD segment corresponding to the operation event sequence is merchant-user, then the AOI and POI of the historical destination refer to the AOI and POI of the user location corresponding to that order.

[0323] For each type of task requirement to be detected (such as navigation requirements, route planning requirements, check-in assistance requirements, etc.), an independent binary classification requirement detection module is built. All binary classification requirement detection modules share the same feature encoding logic.

[0324] After receiving the above data, the binary classification demand detection module inputs the rider's location status sequence, historical destination AOI and POI, rider familiarity, and delivery preferences into the GeoEncoder for encoding to obtain location features; simultaneously, it inputs the operation event sequence into the EventEncoder for encoding to obtain operation event features. The two types of encoded features, along with statistical information and weather type, are pooled and concatenated to combine features from different sources into a single vector, resulting in a comprehensive feature that integrates multi-dimensional information.

[0325] Furthermore, the binary classification demand detection module inputs the fused comprehensive features into the MLP for multi-layer nonlinear transformation. The comprehensive features are further processed by a multi-layer neural network to obtain higher-dimensional comprehensive features. The model then inputs the higher-dimensional comprehensive features obtained from the MLP into the output layer. The output layer uses the Sigmoid activation function to output the probability of the existence of the corresponding demand category (a value between 0 and 1) of the current binary classification demand detection module.

[0326] Subsequently, the server compares the probability of the existence of the demand category output by the binary demand detection module with the corresponding binary true demand labels of the historical orders; calculates the binary cross-entropy loss function, and uses the optimization algorithm to backpropagate and adjust the model parameters so that the loss gradually decreases until the preset convergence conditions are met (such as the loss value being lower than the threshold or the training rounds reaching the set value).

[0327] Optionally, in the embodiments of this application, the real demand tags include, but are not limited to, navigation demand, route planning demand, check-in assistance demand, etc., and each type of demand corresponds to a set of independent binary tags (1 indicates that the demand has occurred, and 0 indicates that the demand has not occurred).

[0328] Based on this, the existence probability output by each binary demand detection module is a probability value between 0 and 1, and the existence probability of each type of demand is then obtained.

[0329] After all binary classification demand detection modules have been successfully trained, during application, the demand detection modules can be performed as described above. Figure 11 The process shown outputs the probability of existence for each type of job demand, thereby determining whether the rider will fulfill the predicted job demand.

[0330] In one possible implementation, the system further includes a location encoding module and an event encoding module. The destination's attribute information includes points of interest and regions of interest, and the spatiotemporal sequence information includes a location state sequence and a sequence of operation events for the target order. The demand detection module is specifically used for:

[0331] The event encoding module is invoked to encode the sequence of operation events for the target order, thereby obtaining the first operation event feature.

[0332] The location encoding module is invoked to encode points of interest and regions of interest, location state sequences, delivery familiarity, and delivery preferences to obtain the second location feature;

[0333] Based on the second location characteristics, the first operational event characteristics, statistical information, and weather type, determine whether the rider has the predicted job demand.

[0334] Specifically, see Figure 11 After acquiring statistical information, location status sequences, and operation event sequences of the target orders from the rider's historical order processing process, any binary demand detection module in the demand detection module encodes the location status sequences, destination-related points of interest and regions of interest, and the rider's delivery preferences and familiarity with delivery using GeoEncoder to obtain the second location feature, and encodes it using EventEncoder to obtain the first operation event feature. Furthermore, the demand detection module can input the second location feature, the first operation event feature, statistical information, and weather type into the pooling and stitching layer to determine whether the rider has experienced a predicted operational anomaly.

[0335] Specifically, the process by which the demand detection module determines whether a rider has experienced a predicted job anomaly is as follows.

[0336] In one possible implementation, the requirement detection module is also used for:

[0337] The first operational event features, the second location features, statistical information, and weather type are pooled and spliced ​​to obtain the spliced ​​second low-dimensional joint features.

[0338] A multi-level nonlinear transformation is performed on the second low-dimensional joint features to obtain the second high-dimensional joint features;

[0339] Based on the second high-dimensional joint features, determine the probability of the existence of the predicted job requirements;

[0340] When the probability of existence is greater than or equal to the second preset probability, it is determined that the rider has the predicted job demand;

[0341] If the probability of existence is less than the second preset probability, it is determined that the rider does not have the predicted job requirements.

[0342] For example, such as Figure 11 As shown, any binary classification demand detection module in the demand detection module inputs the second location feature, the first operation event feature, statistical information, and weather type into the pooling and splicing layer. First, pooling operations are performed on the three features respectively to compress the feature information to a fixed dimension, resulting in the dimensionality-reduced features of the three features. Then, the dimensionality-reduced features of the three features are spliced ​​to obtain the spliced ​​second low-dimensional joint feature, which is then input into the MLP layer. Multi-layer nonlinear transformation is performed on it, and the spliced ​​second low-dimensional joint feature is further mined through a multi-layer neural network to obtain the second high-dimensional joint feature.

[0343] Finally, the binary classification demand detection module inputs the second high-dimensional joint feature to the output layer, and the output layer outputs the probability of the existence of the demand category corresponding to the current binary classification demand detection module.

[0344] Based on this, the requirement detection module can determine the probability of the predicted job requirement from the probability of the existence of each requirement category.

[0345] In this embodiment of the application, a second preset probability can also be preset as a critical probability of whether there is a predicted job demand. Optionally, the second preset probability is 0.8.

[0346] When the probability of the predicted job demand is greater than or equal to the second preset probability, the demand detection module determines that the rider has the predicted job demand; conversely, when the probability of the predicted job demand is less than the second preset probability, the demand detection module determines that the rider does not have the predicted job demand.

[0347] In addition to determining whether a rider has a predicted job requirement through the methods described above, the requirement detection module can also identify the requirement category with the highest probability from multiple requirement categories and compare it with the predicted job requirement. If the requirement category with the highest probability matches the predicted job requirement, the requirement detection module determines that the rider has a predicted job requirement. If the requirement category with the highest probability does not match the predicted job requirement, the requirement detection module determines that the rider does not have a predicted job requirement.

[0348] Furthermore, the requirement detection module can feed back the judgment results to the task planning module.

[0349] When riders have anticipated job requirements, the task planning module can also determine the response results corresponding to the anticipated job requirements.

[0350] In one possible implementation, the task planning module is also used for:

[0351] Based on the task requirements, determine the demand response strategy and the task services associated with the demand response strategy;

[0352] The job service associated with the demand response strategy is invoked to execute the demand response strategy and obtain the response result corresponding to the job demand.

[0353] Specifically, in the embodiments of this application, multiple job services can be pre-set for executing different demand response strategies, and different job services store the execution logic (or demand response strategies) for different job requirements.

[0354] The task planning module can call the corresponding task service to execute the corresponding task response strategy according to the task requirements, and obtain the response result of the task requirements.

[0355] For example, if the job requirement is a navigation requirement, the corresponding job service is a navigation center service. The response strategy of the navigation center service to the navigation requirement can be to obtain the rider's location and destination, and generate a navigation route based on the rider's location and destination.

[0356] If the job requirement is a path update or path switching requirement, the corresponding job service is: Figure 5 The route update service can respond to route switching requests by obtaining multiple navigation routes between the rider's location and destination, as well as the traffic conditions on these routes, and then switching to a navigation route with good traffic conditions.

[0357] After the job service executes the corresponding demand response strategy, it can display the response results corresponding to the target job demand on the user's end for riders to view.

[0358] In the above technical solution, when a rider has a target job request, the task planning module automatically calls the corresponding job service to automatically execute the response strategy for the target job request, realizing full-link automation from request detection to result generation. This avoids the problems of delay and long work cycle caused by manual handling of anomalies, ensures the timeliness and efficiency of request processing, and improves the rider's delivery experience.

[0359] For example, such as Figure 4As shown, after the processing result or response result is displayed on the user's end, the system can also receive feedback from the rider (e.g., accepting or rejecting the result) and feed it back to the task planning module so that the task planning module can continuously optimize its decision-making.

[0360] Corresponding to the system, this application embodiment also provides an intelligent order processing method applied to a server.

[0361] Figure 12 This is a schematic flowchart illustrating an intelligent order processing method provided in an embodiment of this application.

[0362] For example, such as Figure 12 As shown, the method 1200 includes the following steps S1201 to S1205.

[0363] S1201, based on the execution rules of intelligent order operation, determines the multiple processing steps that need to be executed sequentially during the rider's delivery order process. These multiple processing steps include destination prediction, anomaly prediction, and demand prediction.

[0364] S1202, in the destination prediction stage, obtain the N orders to be delivered by the rider and the target information associated with the rider, where N is a positive integer greater than or equal to 1.

[0365] S1203: Determine the rider's destination based on the target information and N orders.

[0366] S1204, In the anomaly prediction stage, during the rider's journey to the destination, based on the target information, it is determined whether an operational anomaly occurs when the rider processes the target order, where the target order is an order associated with the destination; when an operational anomaly occurs, the corresponding processing result is determined and displayed.

[0367] S1205, in the demand forecasting stage, during the rider's journey to the destination, based on the target information, determine whether there is a work requirement when the rider processes the target order; if there is a work requirement, determine the corresponding response result and display the response result.

[0368] The server-side method described above is implemented in the same way as the various modules in the aforementioned System 600. For details, please refer to the introduction of System 600 mentioned above, which will not be repeated here.

[0369] Next, we will proceed through... Figure 13 The implementation process of another intelligent order processing method provided in this application embodiment is described. It should be understood that this method is applied to the user terminal.

[0370] Figure 13This is a schematic flowchart illustrating another intelligent order processing method provided in the embodiments of this application.

[0371] For example, such as Figure 13 As shown, the method 1300 includes the following steps S1301 to S1304.

[0372] S1301, Obtain the target information associated with the rider.

[0373] S1302, send the target information to the server so that the server can determine the rider's destination based on the target information and the N orders to be delivered by the rider, where N is a positive integer greater than or equal to 1.

[0374] S1303, Receive and display the processing result corresponding to the job exception sent by the server. The job exception is determined by the server based on the target information during the rider's journey to the destination to process the target order. The target order is the order associated with the destination. The processing result corresponding to the job exception is determined by the server based on the job exception.

[0375] S1304 Receive and display the response result corresponding to the job request sent by the server. The job request is determined by the server based on the target information during the rider's journey to the destination to process the target order. The response result corresponding to the job request is determined by the server based on the job request.

[0376] It should be understood that the implementation process of the above-mentioned client-side method has the same inventive concept and beneficial effects as the implementation process of the aforementioned server-side method. For details, please refer to the description of the aforementioned method 1200 and system 600, which will not be repeated here.

[0377] Next, we will proceed through... Figure 14 The overall implementation process of the embodiments of this application will be introduced.

[0378] Figure 14 This is a flowchart illustrating the implementation of an intelligent order processing method provided in this application embodiment.

[0379] Exemplary, exemplary Figure 14 (a) in this application is a detailed flowchart of the intelligent order operation system in implementing intelligent order operation in the embodiment of this application.

[0380] Combination Figure 6 The task planning module is mainly responsible for receiving three types of data: sensory data converted into text, abnormal trajectory events during rider operations converted into text, and rider profile information converted into text.

[0381] In this embodiment, the sensing data is mainly processed through a sensing signal calibration module. This module performs multimodal interaction on Global Navigation Satellite System (GNSS) signals, Wireless Fidelity signals, Indoor Outdoor Detection (IOD) signals, Inertial Measurement Unit (IMU) signals, ambient air pressure, and weather type. The data after multimodal interaction is then flattened to perform rider position calibration, status calibration, and scene recognition, thereby obtaining accurate location information, status information, and the rider's current delivery scenario.

[0382] The task planning module receives the above multi-dimensional information and decomposes the task according to business flow knowledge to obtain multiple processing steps that need to be processed in sequence, including destination prediction, anomaly prediction and demand prediction.

[0383] During the destination prediction phase, the task planning module calls the destination prediction module to predict the destination. During the anomaly prediction phase, the task planning module first predicts potential operational anomalies for the rider in the current scenario based on input data and historical delivery data. It then calls the anomaly detection module to determine whether the rider has encountered any of the predicted anomalies. The anomaly detection module obtains a yes / no conclusion and feeds it back to the task planning module.

[0384] When the task planning module receives a "yes" conclusion, it can report the job exception to the decision-making module. The decision-making module then determines the corresponding exception handling strategy based on the job exception and returns it to the task planning module. The task planning module, according to the exception handling strategy, calls the corresponding job service on the right for processing.

[0385] During the demand forecasting phase, the task planning module first predicts the rider's potential operational needs in the current scenario based on input data and historical delivery data. Then, it calls the demand detection module to determine if the rider has encountered the predicted operational needs. The demand detection module obtains a yes / no conclusion and feeds it back to the task planning module.

[0386] When the task planning module receives a "yes" conclusion, it can feed back the job requirements to the decision-making module. The decision-making module then determines the corresponding requirement response strategy based on the job anomaly and returns it to the task planning module. The task planning module, according to the requirement response strategy, calls the corresponding job service on the right for processing.

[0387] After obtaining the processing results for each of the task exceptions and task requirements, the task planning module can return the processing results to the decision module, which will then display them to the rider through the interaction module.

[0388] The three prediction modules (or detection modules) are fed into the calibrated multimodal trajectory, the rider's position state sequence and operation event sequence, and the rider's profile information. The position state sequence is encoded using a position encoding module, and the operation event sequence is encoded using an event encoding module.

[0389] In addition, in this embodiment of the application, the reminder module can also provide real-time reminders to the rider based on the rider's location information, status information, the rider's current delivery scenario, and key events in the rider's operation, such as reminders upon arrival at the store, reminders upon completion of food pickup, or reminders upon completion of delivery, etc.

[0390] like Figure 14 As shown in (b) of this application, it is a general flowchart of the intelligent order processing system in implementing intelligent order processing. Figure 14 A simplified version of the detailed flowchart shown in (a) is provided. The task planning module is the general model. Specifically, in this embodiment, the general model is Alibaba Cloud's self-developed large language model—Qianwen or the Tongyi Qianwen (Qwen) model. Figure 14 The toolset shown in (b) is Figure 14 The prediction modules are shown in (a) above. When implementing each task in the task scenario workflow, the general model calls the corresponding prediction module and sends the processing results to the rider.

[0391] In summary, this application provides an intelligent order processing system. The various modules within this system work collaboratively to proactively predict riders' destinations and potential needs and anomalies during their journey, actively responding to needs and resolving anomalies. This provides riders with a one-stop intelligent order service, from proactive awareness to proactive resolution, optimizing their delivery experience. Furthermore, by proactively responding to needs and resolving anomalies, this system improves anomaly resolution efficiency and avoids delays caused by manual handling. In conclusion, this intelligent order processing system provides riders with a one-stop intelligent order service, from proactive awareness to proactive strategy provision, optimizing their delivery experience and reducing rider complaints.

[0392] Figure 15 This is a schematic diagram of an intelligent order processing device provided in an embodiment of this application. It should be understood that this device is applied to a server.

[0393] For example, such as Figure 15As shown, the device 1500 includes:

[0394] The determination module 1501 is used to determine the multiple processing steps that need to be executed sequentially during the rider delivery order process based on the execution rules of intelligent order operation. The multiple processing steps include destination prediction, anomaly prediction and demand prediction.

[0395] The acquisition module 1502 is used in the destination prediction stage to acquire N orders to be delivered by the rider and the target information associated with the rider, where N is a positive integer greater than or equal to 1;

[0396] The determining module 1501 is also used to determine the rider's destination based on the target information and the N orders;

[0397] The determining module 1501 is further configured to, in the anomaly prediction stage, determine, based on the target information, whether an operational anomaly occurs when the rider is processing a target order, wherein the target order is an order associated with the destination, during the rider's journey to the destination; and when an operational anomaly occurs, determine the processing result corresponding to the operational anomaly and display the processing result.

[0398] The determining module 1501 is further configured to, during the demand forecasting stage, determine whether there is a job requirement when the rider is processing the target order based on the target information, according to the target information; and when there is a job requirement, determine the response result corresponding to the job requirement and display the response result.

[0399] Figure 16 This is a schematic diagram of another intelligent order processing device provided in an embodiment of this application. It should be understood that this device is applied to the user end.

[0400] For example, such as Figure 16 As shown, the device 1600 includes:

[0401] Module 1601 is used to obtain target information associated with the rider.

[0402] The sending module 1602 is used to send the target information to the server, so that the server determines the destination of the rider based on the target information and the N orders to be delivered by the rider, where N is a positive integer greater than or equal to 1;

[0403] Display module 1603 is used to receive and display the processing result corresponding to the operation exception sent by the server, wherein the operation exception is determined by the server based on the target information during the process of the rider going to the destination to process the target order, wherein the target order is an order associated with the destination, and the processing result corresponding to the operation exception is determined by the server based on the operation exception; and / or, to receive and display the response result corresponding to the operation request sent by the server, wherein the operation request is determined by the server based on the target information during the process of the rider going to the destination to process the target order, and the response result corresponding to the operation request is determined by the server based on the operation request.

[0404] Figure 17 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Specifically, this electronic device is a server.

[0405] For example, such as Figure 17 As shown, the electronic device 1700 includes a memory 1701 and a processor 1702. The memory 1701 stores executable program code 17011, and the processor 1702 is used to call and execute the executable program code 17011 to perform an intelligent order operation method.

[0406] Figure 18 This is a schematic diagram of another electronic device provided in an embodiment of this application. Specifically, this electronic device is a rider terminal.

[0407] For example, such as Figure 18 As shown, the electronic device 1800 includes a memory 1801 and a processor 1802. The memory 1801 stores executable program code 18011, and the processor 1802 is used to call and execute the executable program code 18011 to perform a method for intelligent order processing.

[0408] This embodiment can divide the electronic device into functional modules according to the above method example. For example, each module can correspond to a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0409] When each functional module is divided according to its corresponding function, the electronic device may include: an acquisition module and an acquisition module, etc. Alternatively, the electronic device may also include an acquisition module, a transmission module, and a display module, etc. It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0410] The electronic device provided in this embodiment is used to execute the above-described intelligent order processing method, and thus can achieve the same effect as the above-described implementation method.

[0411] When using integrated units, the electronic device may include a processing module and a storage module. The processing module is used to control and manage the operation of the electronic device. The storage module is used to support the execution of relevant program code and data by the electronic device.

[0412] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits shown in conjunction with the disclosure of this application. The processor may also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc., and the storage module may be a memory.

[0413] This embodiment also provides a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, the computer executes the above-described related method steps to implement an intelligent order processing method as described in the above embodiment.

[0414] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement an intelligent order processing method as described in the above embodiment.

[0415] In addition, the electronic device provided in the embodiments of this application may specifically be a chip, component or module. The electronic device may include a connected processor and a memory. The memory is used to store instructions. When the electronic device is running, the processor may call and execute the instructions to make the chip perform an intelligent order operation method in the above embodiments.

[0416] In this embodiment, the electronic device, computer-readable storage medium, computer program product or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0417] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0418] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0419] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A system for intelligent order processing, characterized in that, Applied to a server, the system includes a task planning module, a destination prediction module, an anomaly detection module, and a demand detection module. The task planning module is used to determine the multiple processing steps that need to be executed sequentially during the rider's delivery order process based on the execution rules of intelligent order operation. The multiple processing steps include destination prediction, anomaly prediction and demand prediction. In the destination prediction stage, the task planning module is further used to obtain the N orders to be delivered by the rider and the target information associated with the rider, and call the destination prediction module so that the destination prediction module determines the rider's destination based on the target information and the N orders, where N is a positive integer greater than or equal to 1, the destination is the destination the rider is currently heading to, the target information is used to represent at least one of order information, rider-related feature information and traffic environment information, and the destination prediction module is a trained destination prediction model; In the anomaly prediction stage, the task planning module is also used to call the anomaly detection module so that the anomaly detection module can actively predict whether an operational anomaly occurs when the rider is processing the target order, based on the target information, during the rider's journey to the destination. The target order is an order associated with the destination, and the anomaly detection module is a trained anomaly detection model. When a rider experiences a work-related error, the task planning module is also used to automatically call the work service corresponding to the work-related error to execute the corresponding error handling strategy, obtain the processing result of the work-related error, and display the processing result. In the demand prediction stage, the task planning module is also used to call the demand detection module so that the demand detection module can actively predict whether there is a job demand when the rider is handling the target order, based on the target information, during the process of the rider going to the destination. The demand detection module is a trained demand detection model. When a rider has a job requirement, the task planning module is also used to automatically call the job service corresponding to the job requirement to execute the corresponding requirement response strategy, obtain the response result of the job requirement, and display the response result.

2. The system according to claim 1, characterized in that, The target information includes the order status of the target order, the distance between the rider's location and the destination, the rider's profile information and abnormal trajectory types, weather type, and multiple movement states and spatiotemporal sequence information of the rider within a preset time period; the task planning module is specifically used for: Based on the multiple motion states and the weather type, or based on the abnormal trajectory type, the distance between the rider's location and the destination, and the order status of the target order, predict the rider's current operational anomaly; The anomaly detection module is invoked so that it can determine whether the rider has experienced a predicted operational anomaly based on the profile information, the weather type, and the spatiotemporal sequence information.

3. The system according to claim 2, characterized in that, The system also includes a location encoding module and an event encoding module. The profile information includes statistical information on the rider's historical order processing process, and the spatiotemporal sequence information includes a location state sequence and an operation event sequence for the target order. The anomaly detection module is specifically used for: The location encoding module is invoked to encode the location state sequence to obtain a first location feature; The event encoding module is invoked to encode the sequence of operation events for the target order, thereby obtaining a first operation event feature; Based on the first location feature, the first operation event feature, the statistical information, and the weather type, determine whether the rider has experienced the predicted operation anomaly.

4. The system according to claim 3, characterized in that, The anomaly detection module is also used for: The first location feature, the first operation event feature, the statistical information, and the weather type are pooled and spliced ​​to obtain the spliced ​​first low-dimensional joint feature. The first low-dimensional joint feature is subjected to a multi-level nonlinear transformation to obtain the first high-dimensional joint feature; Based on the first high-dimensional joint feature, the probability of the predicted operation anomaly is determined; When the probability of occurrence is greater than or equal to a first preset probability, it is determined that the rider has experienced the predicted operational anomaly. When the probability of occurrence is less than the first preset probability, it is determined that the rider has not experienced the predicted operational anomaly.

5. The system according to any one of claims 1 to 4, characterized in that, The task planning module is also used for: Based on the job anomaly, determine the anomaly handling strategy and the job service associated with the anomaly handling strategy; The job service associated with the exception handling strategy is invoked to execute the exception handling strategy and obtain the processing result corresponding to the job exception.

6. The system according to claim 1, characterized in that, The target information includes statistical information on the rider's historical order processing, the rider's delivery preferences and familiarity with the destination, traffic information, weather type, destination attribute information, and the rider's spatiotemporal sequence information within a preset time period; the task planning module is specifically used for: Predict the rider's current job requirements based on the delivery familiarity or based on the traffic information and delivery preferences; The demand detection module is invoked so that it can determine whether the rider has a predicted job demand based on the delivery preference, delivery familiarity, destination attribute information, statistical information, weather type, and spatiotemporal sequence information.

7. The system according to claim 6, characterized in that, The system further includes a location encoding module and an event encoding module. The destination's attribute information includes points of interest and regions of interest. The spatiotemporal sequence information includes a location state sequence and an operation event sequence for the target order. The demand detection module is specifically used for: The event encoding module is invoked to encode the sequence of operation events for the target order, thereby obtaining a first operation event feature; The location encoding module is invoked to encode the points of interest and regions of interest, the location state sequence, the delivery familiarity, and the delivery preference to obtain a second location feature; Based on the second location feature, the first operation event feature, the statistical information, and the weather type, it is determined whether the rider has the predicted job requirement.

8. The system according to claim 7, characterized in that, The demand detection module is also used for: The first operation event feature, the second location feature, the statistical information, and the weather type are pooled and spliced ​​to form the second low-dimensional joint feature. The second low-dimensional joint feature is subjected to a multi-level nonlinear transformation to obtain the second high-dimensional joint feature. Based on the second high-dimensional joint feature, determine the probability of the existence of the predicted job requirement; When the probability of existence is greater than or equal to the second preset probability, it is determined that the rider has the predicted job requirement; When the probability of existence is less than the second preset probability, it is determined that the rider does not have the predicted job requirement.

9. The system according to any one of claims 1, 6 to 8, characterized in that, The task planning module is also used for: Based on the job requirements, determine the demand response strategy and the job service associated with the demand response strategy; The job service associated with the demand response strategy is invoked to execute the demand response strategy and obtain the response result corresponding to the job demand.

10. The system according to claim 1, characterized in that, The target information includes the rider's location, the delivery scenario in which the rider is located, and the rider's spatiotemporal sequence information within a preset time period; the task planning module is specifically used for: When N is greater than 1, if the delivery scenario is a food pickup scenario, obtain the N merchant locations associated with the N orders; based on the rider location, determine M candidate destinations from the N merchant locations, where M is less than or equal to N; or, If the delivery scenario is a food delivery scenario, obtain the N user locations associated with the N orders; based on the rider locations, determine the M candidate destinations from the N user locations; Obtain M attribute information of the M candidate destinations and M processing progress information corresponding to the M orders, wherein the M orders are orders associated with the M candidate destinations; The destination prediction module is invoked so that it determines the destination from the M candidate destinations based on the M attribute information, the M processing progress information, and the spatiotemporal sequence information.

11. The system according to claim 10, characterized in that, The system further includes a location encoding module and an event encoding module. The M attribute information includes M points of interest and M regions of interest. The spatiotemporal sequence information includes a location state sequence and a sequence of M operation events for the M orders. The destination prediction module is specifically used for: For any of the M candidate destinations, the processing progress information associated with the candidate destination is concatenated to obtain the dense processing progress feature of the candidate destination. The location encoding module is invoked to encode the M points of interest, the M regions of interest, and the location state sequence to obtain a third location feature; The event encoding module is invoked to encode the M operation event sequences to obtain the second operation event feature; The destination is determined from the M candidate destinations based on the dense processing progress characteristics of the M candidate destinations, the third location characteristics, and the second operation event characteristics.

12. The system according to claim 11, characterized in that, The destination prediction module is also used for: The second operation event feature and the third location feature are pooled and concatenated to obtain the concatenated third low-dimensional joint feature; Perform multi-level nonlinear transformation on the third low-dimensional joint feature to obtain the third high-dimensional joint feature; Based on the dense processing progress characteristics of the M candidate destinations and the third high-dimensional joint features, determine the M output probabilities corresponding to the M candidate destinations; The candidate destination corresponding to the probability that is greater than or equal to the third preset probability among the M output probabilities is determined as the destination.

13. The system according to claim 1, characterized in that, The target information includes the rider's location, the order status of the N orders, the merchant's location, and the user's location; the destination prediction module is also used for: When N equals 1, if the order status is "order accepted" or the rider's location is gradually approaching the merchant's location, the destination is determined to be the merchant's location; if the order status is "food picked up" or the rider's location is gradually approaching the user's location, the destination is determined to be the user's location.

14. A method for intelligent order processing, characterized in that, Applied to a server, the method includes: Based on the execution rules of intelligent order operation, multiple processing steps that need to be executed sequentially during the rider's delivery order process are determined. These multiple processing steps include destination prediction, anomaly prediction, and demand prediction. In the destination prediction stage, N orders to be delivered by the rider and the target information associated with the rider are obtained, where N is a positive integer greater than or equal to 1. The target information is used to represent at least one of order information, rider-related feature information, and traffic environment information. Based on the trained destination prediction model, the target information, and the N orders, the rider's destination is determined, which is the destination the rider is currently heading to; In the anomaly prediction stage, during the rider's journey to the destination, based on the trained anomaly detection model and the target information, it is proactively predicted whether an operational anomaly will occur when the rider processes the target order, where the target order is an order associated with the destination; when an operational anomaly occurs, the corresponding anomaly handling strategy is executed by automatically calling the operation service corresponding to the operational anomaly, and the handling result of the operational anomaly is obtained and displayed. In the demand prediction stage, during the rider's journey to the destination, based on the trained demand detection model and the target information, it is proactively predicted whether there is a job demand when the rider processes the target order; if there is a job demand, the corresponding job service is automatically invoked to execute the corresponding demand response strategy, and the response result of the job demand is obtained and displayed.

15. A method for intelligent order processing, characterized in that, When applied to a user terminal, the method includes: Obtain target information associated with the rider, wherein the target information is used to represent at least one of order information, rider-related feature information, and traffic environment information; The target information is sent to the server so that the server determines the rider's destination based on the trained destination prediction model, the target information, and the rider's N orders to be delivered, where N is a positive integer greater than or equal to 1, and the destination is the destination the rider is currently heading to. The server receives and displays the processing result corresponding to the job exception sent by the server. The job exception is actively predicted by the server based on a trained exception detection model and the target information during the rider's journey to the destination to process the target order. The target order is an order associated with the destination. The processing result corresponding to the job exception is obtained by the server automatically calling the job service corresponding to the job exception to execute the corresponding exception handling strategy. Alternatively, the server receives and displays the response result corresponding to the job request sent by the server. The job request is actively predicted by the server based on a trained demand detection model and the target information during the rider's journey to the destination to process the target order. The response result corresponding to the job request is obtained by the server automatically calling the job service corresponding to the job request to execute the corresponding demand response strategy.

16. An electronic device, characterized in that, The electronic device includes: Memory, used to store executable program code; A processor for calling and running the executable program code from the memory, causing the electronic device to perform the method as described in claim 14.

17. An electronic device, characterized in that, The electronic device includes: Memory, used to store executable program code; A processor for calling and running the executable program code from the memory, causing the electronic device to perform the method as described in claim 15.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the method as described in any one of claims 14 to 15.

Images