Logistics order timeliness monitoring method and device, storage medium and server

Abstract

The embodiment of the invention discloses a logistics order timeliness monitoring method and device, a storage medium and a server, and relates to the technical field of logistics. According to the method, the attribute data of the logistics order is acquired in real time, the pre-trained machine learning model is utilized to process the data, and the predicted delay reason is output. And automatically matching a corresponding disposal strategy according to the prediction reason, generating a urging early warning event, and pushing the event to a related digital board and a regional principal. And at the same time, processing result data of the early warning event is obtained and displayed on the digital board. And when the updating condition of the machine learning model is met, optimizing model parameters based on the urging delay records in the historical time interval. According to the invention, active early warning and intelligent disposal of the delay event are realized, the occurrence source of the customer urging event is effectively reduced, and the response speed and the processing efficiency are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the logistics technical field, and in particular to a logistics order timeliness monitoring method and device, a storage medium and a server. BACKGROUND

[0002] When a logistics order is delayed, it is often dependent on the customer to initiate a piece inquiry, and then the customer service personnel intervene to handle it. The customer service personnel need to manually query the current logistics node of the order according to the order number, and contact the operation personnel of the node for urging. This method is essentially a passive response after the event, and cannot realize early warning and intervention, and it is difficult to reduce the occurrence of piece inquiry events from the source. At the same time, due to the lack of effective analysis means, the customer service personnel need to spend a lot of time for multi-party communication and manual investigation, and it is still difficult to accurately locate the root cause of the order delay. Therefore, the existing technology has the problems of insufficient response timeliness, low problem positioning accuracy and low processing efficiency for the timeliness monitoring of the logistics order. SUMMARY

[0003] The embodiments of the present application provide a logistics order timeliness monitoring method and device, a storage medium and a server, which can solve the problems of insufficient response timeliness, low problem positioning accuracy and low processing efficiency for the timeliness monitoring of the logistics order in the prior art. The technical solution is as follows: In a first aspect, the embodiments of the present application provide a logistics order timeliness monitoring method, which comprises: real-time acquisition of order attribute data of a logistics order; inputting the order attribute data into a pre-trained machine learning model to obtain a predicted delay reason; matching a corresponding treatment strategy according to the predicted delay reason, generating a piece inquiry early warning event according to the treatment strategy and the predicted delay reason; pushing the piece inquiry early warning event to a digital board corresponding to the logistics order and a regional person in charge; acquiring treatment result data of the piece inquiry early warning event, and pushing the treatment result data on the digital board; when it is detected that a machine learning model update condition is met, acquiring a plurality of piece inquiry delay records in a historical time interval, the piece inquiry delay records comprising attribute data and actual delay reasons of logistics orders, and updating network parameters of the machine learning model according to the plurality of piece inquiry delay records.

[0004] In a second aspect, the embodiments of the present application provide a logistics order timeliness monitoring device, which comprises: an acquisition unit configured to acquire order attribute data of a logistics order in real time; a prediction unit configured to input the order attribute data into a pre-trained machine learning model to obtain a predicted delay cause; a generation unit configured to match a corresponding treatment strategy according to the predicted delay cause, and generate a reminder warning event according to the treatment strategy and the predicted delay cause; a pushing unit configured to push the reminder warning event to a digital board corresponding to the logistics order and a regional person in charge; a monitoring unit configured to obtain treatment result data of the reminder warning event, and push the treatment result data on the digital board; an updating unit configured to, when a machine learning model updating condition is detected, obtain a plurality of reminder delay records in a historical time interval, the reminder delay records including attribute data and actual delay causes of logistics orders, and update network parameters of the machine learning model according to the plurality of reminder delay records.

[0005] In a third aspect, an embodiment of the present application provides a computer storage medium, which stores a plurality of instructions, the instructions being suitable for being loaded by a processor and performing the method steps described above.

[0006] In a fourth aspect, an embodiment of the present application provides a terminal device, which can include a processor and a memory; wherein the memory stores a computer program, the computer program being suitable for being loaded by the processor and performing the method steps described above.

[0007] The technical solutions provided by some embodiments of the present application have at least the following beneficial effects: By analyzing logistics order attribute data in real time and predicting delay causes by using a machine learning model, active early warning and intelligent treatment of potential delay events are realized. The present application changes the traditional post-processing into pre-intervention, effectively reducing the source of reminder events. By automatically matching treatment strategies and pushing warning information, the response speed and processing efficiency are significantly improved. BRIEF DESCRIPTION OF DRAWINGS

[0008] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed in the embodiment or prior art description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application, and those skilled in the art can obtain other drawings according to these drawings without creative labor.

[0009] Figure 1 is a network architecture schematic diagram provided by an embodiment of the present application; Figure 2 is a flowchart schematic diagram of a time limit monitoring method for a logistics order provided by an embodiment of the present application; Figure 3 is a structural schematic diagram of a logistics order timeliness monitoring device provided by the present application; Figure 4 is a schematic diagram of a computer storage medium provided by an embodiment of the present application; Figure 5 is a structural schematic diagram of a server provided by the present application. DETAILED DESCRIPTION

[0010] To make the purpose, technical solutions and advantages of the present application clearer, the embodiments of the present application will be further described in detail below with reference to the drawings.

[0011] It should be noted that the logistics order timeliness monitoring method provided by the present application is generally executed by a server, and accordingly, the logistics order timeliness monitoring device is generally arranged in the server.

[0012] Figure 1 An exemplary system architecture that can be applied to the logistics order timeliness monitoring method or the logistics order timeliness monitoring device of the present application is shown.

[0013] As shown in Figure 1 , the system architecture can include a terminal device 101 and a server 102. The terminal device 101 and the server 102 can communicate with each other through a network, which is a medium for providing a communication link between the above-mentioned units. The network can include various types of wired communication links or wireless communication links, for example, the wired communication links include optical fibers, twisted pairs or coaxial cables, etc., and the wireless communication links include Bluetooth communication links, wireless fidelity (WIreless-FIdelity, Wi-Fi) communication links or microwave communication links, etc.

[0014] Among them, the server 102 is deployed with a pre-trained machine learning model, and the machine learning model is encapsulated as an API, and the terminal device 101 calls the API, sends the real-time collected order attribute data to the server 102, inputs the order attribute data into the pre-trained machine learning model to obtain a predicted delay reason; according to the predicted delay reason, a corresponding treatment strategy is matched, a part urging warning event is generated according to the treatment strategy and the predicted delay reason; the part urging warning event is pushed to the digital watchboard and the regional person in charge corresponding to the logistics order; the treatment result data of the part urging warning event is obtained, and the treatment result data is pushed on the digital watchboard; when it is detected that the machine learning model updating condition is met, a plurality of part urging delay records in a historical time interval are obtained, the part urging delay record includes the attribute data of the logistics order and the actual delay reason, and the network parameters of the model are updated according to the plurality of part urging delay records.

[0015] It should be noted that the terminal device 101 and the server 102 can be either hardware or software. When the terminal device 101 and the server 102 are hardware, they can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When the terminal device 101 and the server 102 are software, they can be implemented as multiple software programs or software modules (for example, to provide distributed services), or as a single software program or software module; no specific limitations are made here.

[0016] The terminal device of this application can be equipped with various communication client applications, such as video recording applications, video playback applications, voice interaction applications, search applications, instant messaging tools, email clients, social platform software, etc.

[0017] A terminal device can be either hardware or software. When the terminal device is hardware, it can be various terminal devices with a display screen, including but not limited to smartphones, tablets, laptops, and desktop computers. When the terminal device is software, it can be installed on the terminal devices listed above. It can be implemented as multiple software programs or software modules (e.g., used to provide distributed services) or as a single software program or software module; no specific limitation is made here.

[0018] When the terminal device is hardware, it can also be equipped with a display device and a camera. The display device can be any device capable of displaying information, and the camera is used to capture video streams. For example, the display device can be a cathode ray tube display (CR), a light-emitting diode display (LED), an e-ink screen, a liquid crystal display (LCD), a plasma display panel (PDP), etc. Users can use the display device on the terminal device to view displayed text, images, videos, and other information.

[0019] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is for illustrative purposes only. Depending on implementation needs, there can be any number of terminal devices, networks, and servers.

[0020] The following will be combined with the appendix Figure 2 This application provides a detailed description of the logistics order timeliness monitoring method provided in the embodiments of this application. The logistics order timeliness monitoring device in the embodiments of this application can be... Figure 1 The server shown.

[0021] Please see Figure 2This document presents a flowchart illustrating a method for monitoring the timeliness of logistics orders, as provided in this embodiment. Figure 2 As shown, the method described in this application embodiment may include the following steps: S1. Obtain order attribute data for logistics orders in real time.

[0022] The order attribute data is a set of data describing various status characteristics, environmental factors, and historical performance related to the timeliness of logistics orders during the fulfillment process. The order attribute data comprehensively reflects the operational status and environmental conditions of the entire chain from sorting to delivery from multiple dimensions. The server obtains the order attribute data of logistics orders in real time by integrating internal business systems and external data sources. The acquisition period can be in minutes, hours, or days, depending on the actual needs.

[0023] Order attribute data includes: sorting time, number of delivery personnel, weather conditions, complexity of delivery address, weight of goods, volume of goods, delivery distance, order placement time, sorting center processing capacity, delivery area type (urban, suburban, township and rural), historical number of delays on delivery routes, and traffic congestion index.

[0024] Sorting time represents the total time that goods take from arrival at the sorting center to completion of sorting and preparation for shipment. The server can automatically record the inbound timestamp of goods arriving at the sorting center and the outbound timestamp of goods completing sorting, and the difference between the two timestamps is the sorting time.

[0025] The number of delivery personnel represents the total number of available delivery personnel assigned to the geographical area or specific batch of goods for a logistics order during delivery, measured in persons. The server queries the delivery area management or personnel scheduling system in real time to obtain the area or batch code defined for the current delivery task, and counts the total number of delivery personnel marked as "on duty" or "available" in the system.

[0026] Weather conditions indicate the predominant weather conditions in the area along the order's delivery route. These conditions are typically quantified by the level or type of impact on delivery efficiency, such as sunny, rainy, snowy, or foggy. The server can call the application programming interface (API) of an external weather data service to obtain weather forecasts or real-time weather data for a preset time period based on the order's delivery address or the geographical information of the planned route.

[0027] Address complexity refers to a numerical value calculated based on the delivery address information filled in on the order, used to characterize the ease of delivery to that address through a set of quantitative rules. The server executes a complexity calculation rule. First, an address hierarchy integrity score is performed, breaking down the address information into five basic levels: province, city, district / county, street, and house number. Each existing level receives a corresponding score, while missing levels are penalized. This section has a maximum score of 10 points. Second, a fuzzy information correction score is performed, using text matching technology to detect whether the address contains specific fuzzy words, deducting points based on the number of occurrences. No fuzzy expressions result in a base score of 5 points. Finally, a historical delivery record reference score is performed, querying the address's delivery records over the past year, counting the number of failures due to address issues, and deducting points accordingly. No such records result in a base score of 5 points. The three scores are added together to obtain a final complexity score ranging from 0 to 20, with higher scores indicating more complex addresses.

[0028] Cargo weight represents the total mass of all goods included in a single logistics order. Upon order receipt, the weight is measured using automated weighing equipment deployed on conveyor belts or workbenches, and the obtained weight is synchronized to the server by the warehouse management system.

[0029] Cargo volume refers to the space occupied by goods in a single logistics order, usually calculated in terms of length, width, and height. When an order is received, volume measuring instruments deployed in the sorting center, such as a 3D vision scanning system, automatically capture the external dimensions of the goods and calculate their volume, which is then synchronized to the server.

[0030] Delivery distance represents the spatial path length between the delivery station and the delivery address of a logistics order. The server can calculate the straight-line distance between the delivery station and the delivery address based on their geographical coordinates.

[0031] The order placement time indicates the specific moment when a customer successfully submits a logistics order on the e-commerce platform. The order timestamp is automatically recorded and synchronized to the server when the order is created.

[0032] The sorting center's processing capacity represents the total number of orders or goods that a particular sorting center needs to process within a specific statistical period, such as the current hour, day, or shift. The server aggregates real-time operational data from the sorting centers and calculates the number of orders or goods processed within a specified time period.

[0033] Delivery area type indicates the category of an area based on the geographical location and population density of the order's delivery address, such as urban area, suburbs, town, or rural area. The server converts the delivery address into latitude and longitude coordinates using a geocoding service and spatially matches it with pre-stored geographic area boundary data to automatically determine its delivery area type.

[0034] Historical delay counts represent the cumulative number of delivery delay events occurring on the same delivery route within a preset historical period. The server can query the historical order database, filter relevant orders based on route identifiers, and count the number of orders whose actual delivery time was later than the promised delivery time.

[0035] The traffic congestion index is an indicator used to describe the smoothness of traffic along an order delivery route in the current or predicted period. A higher value generally indicates greater congestion. The server connects to a third-party real-time traffic data platform and, based on the planned delivery route information, obtains the average travel speed or overall congestion index for that route in the current or future period.

[0036] S2. Input the order attribute data into a pre-trained machine learning model to obtain predicted delay reasons. The predicted delay reasons are: low sorting efficiency, insufficient delivery personnel, unclear delivery address, severe weather, cargo problems, and traffic congestion.

[0037] The server inputs real-time order attribute data into a machine learning model pre-trained with a large amount of sample data. The machine learning model internally constructs a complex non-linear mapping relationship from multi-dimensional features to specific delay results. When feature data representing the current state of an order is input into the machine learning model, the model abstracts and synthesizes the input information layer by layer through its internal multi-layered network structure.

[0038] Within the machine learning model, each order attribute data point is transformed into a feature vector. These feature vectors undergo weighted combination and nonlinear transformations, ultimately forming a probability distribution for different delay causes at the output layer. The machine learning model then compares these probability values ​​to determine one or more of the most likely dominant delay causes. These delay causes correspond to common problem categories in logistics practice, including: low sorting efficiency, insufficient delivery personnel, unclear delivery addresses, severe weather, cargo issues, and traffic congestion.

[0039] Low sorting efficiency refers to situations where the time spent processing logistics orders at the sorting center exceeds the standard operating time, resulting in delays and slower order flow. The root cause lies in bottlenecks in the internal resource allocation or process execution of the sorting center. Typical examples include, but are not limited to: insufficient on-site personnel to meet the current sorting demands; malfunctions in automated sorting machinery or scanning equipment; and unreasonable aspects of the established sorting workflow, leading to circuitous routes or repetitive operations.

[0040] Insufficient delivery personnel refers to a situation where, within a specific delivery area or time period, the total number of delivery personnel available for dispatch is less than the number of personnel required to complete all current order delivery tasks in a timely manner, resulting in delays in the timely allocation and execution of some orders.

[0041] A vague delivery address refers to a delivery address provided by the customer that is incomplete, inaccurate, or contains uncertain descriptions, making it difficult for delivery personnel to quickly and accurately locate the exact delivery location, resulting in a prolonged search time and subsequent delays.

[0042] Severe weather refers to abnormal weather conditions in the order delivery route or target area that are sufficient to hinder normal transportation activities or significantly increase operational risks, thereby causing delivery delays directly or indirectly. Such weather is usually sudden and uncontrollable, such as heavy rain, heavy snow, dense fog, typhoons, etc., and its impact manifests as road closures, a sharp decrease in visibility, or the forced suspension of outdoor operations for safety reasons.

[0043] Cargo issues refer to delays in the order process caused by abnormalities in the physical properties, packaging condition, or compliance of the goods themselves, necessitating additional processing, verification, or reinforcement before sorting, loading, or delivery. Specifically, issues may manifest as goods exceeding standard weight or volume, damaged packaging requiring repackaging during transit, or suspected contraband requiring security checks.

[0044] Traffic congestion refers to delivery delays caused by excessively high vehicle density or unexpected road incidents on planned delivery routes, resulting in average vehicle speeds significantly lower than normal and travel times substantially longer. Common factors contributing to traffic congestion include traffic accidents, planned road construction, and periodic commuting peaks.

[0045] The server obtains structured prediction delay results by calling the API interface of the machine learning model. These prediction delay results not only include the specific reasons for the prediction delay, but also the corresponding confidence score.

[0046] S3. Match the corresponding handling strategy according to the predicted delay cause, and generate an expedited delivery warning event according to the handling strategy and the predicted delay cause.

[0047] After obtaining the predicted cause of the delay, the server immediately initiates a matching process for handling strategies. The server maintains a strategy knowledge base that pre-stores standardized response plans for different delay causes. Each predicted delay cause is mapped to one or more optimized handling strategies in this knowledge base.

[0048] The matching process is automatically completed by the server based on predefined logical relationships. The server uses the identified predicted delay causes as query keywords to search the policy knowledge base, thereby identifying one or more corresponding handling policies.

[0049] After successfully matching a handling strategy, the server enters the stage of generating an expedited delivery warning event. This stage doesn't simply present the cause and strategy side-by-side; instead, it combines them with the original order attribute data, using an event generation engine to synthesize a complete and comprehensive expedited delivery warning event. This event is a digital object, and its data structure typically includes several core fields. The event description field clearly explains the delay and its predicted cause. The handling suggestion field details the specific response measures derived by the system. The associated order information field ensures that the event can be accurately traced back to the corresponding logistics order. Furthermore, the server assigns a priority identifier to the event based on the severity of the delay cause and the urgency of its impact.

[0050] For example, suppose the server predicts that the delay of a logistics order is due to low sorting efficiency. When performing strategy matching, the server will search for "low sorting efficiency" as an index in its internal strategy knowledge base. The corresponding strategies preset in the knowledge base may include "activating the emergency personnel deployment plan for the sorting center", "notifying the equipment maintenance team to inspect critical sorting equipment", and "temporarily activating the backup sorting line".

[0051] Once the server successfully matches the above strategy, it will call the event generation engine to integrate the reason "low sorting efficiency", the multiple matching handling strategies, and the specific information of the order, such as the order number "12345" and the current abnormal sorting time data, to generate an expedited warning event.

[0052] The specific details of the event will be structured as follows: the event description will record "Order 12345 is at risk of delay due to low efficiency in the sorting process"; the handling recommendations will clearly list three measures: "implement emergency personnel deployment", "arrange equipment inspection", and "activate backup production line"; the order number "12345" will be bound to the associated order information; and the server will automatically determine its priority as "high" according to preset rules.

[0053] S4. Push the expedited delivery warning event to the digital dashboard and regional manager corresponding to the logistics order.

[0054] The server determines the corresponding delivery area for an order based on the order information carried in the expedited delivery warning event, and then retrieves the account information of the person in charge of that area from the system database. Simultaneously, the server determines the target digital dashboard whose displayed content needs to be updated based on the order's progress status or sorting center affiliation.

[0055] The server adaptively encapsulates the data structure for expedited event alerts. For digital dashboards, the server converts the event content into a format conforming to the dashboard data interface specification, ensuring that key information, including event description, handling suggestions, and priority, can be correctly parsed by the dashboard system and displayed in specific areas of its visualization interface. For regional managers, the server may encapsulate event information into specific notification message formats, such as SMS, in-app push notifications, or emails.

[0056] Subsequently, the server executes the push operation through its internally integrated communication channels. The server invokes message middleware or application programming interfaces (APIs) to send the formatted event data to the message queue of the target digital dashboard and the message receiving terminal of the regional manager. Throughout the push process, the server records the push status to ensure reliable information delivery, thus completing the execution loop from internal system decision-making to external outreach.

[0057] For example, suppose the server generates an expedited delivery alert for order number NL20240520001. The predicted cause of this event is traffic congestion, the suggested action is to replan the route, and it is marked as high priority. Its delivery area is District B in City A.

[0058] When the server executes the push notification, it first performs a target retrieval. Based on the key field "City A, District B" in the order information, it finds the designated person in charge for that region as Li Moumou in the regional person in charge configuration table and obtains the push identifier of the mobile device bound to him. At the same time, based on the order path, the server determines that the order status information should be displayed on the digital dashboard of Operation Center C, numbered DB-BJ-01.

[0059] Next, the server encapsulates the data, generating a display data package for the digital dashboard that includes the order number, reason for delay, handling suggestions, and priority indicator. For the regional manager, Mr. Li, a concise alarm notification is generated, covering the order number, a summary of the core issue, and key handling points.

[0060] Finally, the server initiates a push notification, sending the data packet to the receiving address of the digital dashboard DB-BJ-01 via its internal messaging service. The dashboard then highlights the event in the "High Priority Warning" area. Simultaneously, an immediate alert message is sent to the mobile work terminal of the person in charge, Mr. Li, via the push gateway. Mr. Li's mobile phone immediately receives a notification informing him of a high-priority delay warning for order NL20240520001 that requires immediate attention, thus achieving dual information delivery.

[0061] S5. Obtain the handling result data of the expedited delivery warning event, and push the handling result data to the digital dashboard.

[0062] After pushing an alert for expedited delivery, the server initiates a process to monitor and collect the handling results data. Through a predefined data interface, the server actively listens for and obtains handling results data from regional managers or relevant business systems. This handling results data is a structured feedback data packet, whose core data fields explicitly include a status indicator indicating whether the event has been resolved, and the actual handling time from the alert being pushed to the completion of the issue.

[0063] After acquiring the handling results data, the server initiates an information synchronization mechanism. The server standardizes the acquired handling results data and pushes it to the digital dashboard system associated with the logistics order. Upon receiving this updated data, the digital dashboard dynamically refreshes the display status of the alert event on its visual interface. Specific updates typically include marking the event status as resolved or unresolved and displaying the specific time taken for the handling. This process achieves transparency and visualization of the operational handling loop, enabling all management and operational personnel monitoring the dashboard to keep abreast of the latest developments and final handling efficiency.

[0064] For example, when Mr. Li, the regional manager, received a traffic congestion warning for order NL20240520001 via his mobile terminal, he took measures to replan the route. After the vehicle successfully arrived and completed the delivery according to the new route, Mr. Li submitted the "Resolved" status and the "45 minutes" processing time from receiving the warning to completing the delivery to the system through the function button on the terminal application.

[0065] The server captured this feedback message sent by Mr. Li's terminal through its open data interface. The server then verified and formatted the message, and then sent an updated data packet containing "Status: Resolved" and "Processing Time: 45 minutes" precisely to the digital dashboard DB-BJ-01 in the C Operations Center through the internal message channel.

[0066] After parsing the data packet, the digital dashboard system immediately locates the corresponding warning entry on the display interface, changes its background color from yellow (representing a warning) to green (representing resolution), and scrolls the text "Resolved, 45 minutes" below the entry. This allows all personnel in the operations center to clearly see that the delay has been handled efficiently.

[0067] In one possible embodiment of this application, it further includes: S6. When the conditions for updating the machine learning model are met, multiple delay records within the historical time interval are obtained, and the network parameters of the machine learning model are updated according to the multiple delay records. The delay records include: order attribute data of the logistics order and the actual reason for the delay.

[0068] The server continuously monitors metrics related to model performance. When the system determines that preset machine learning model update conditions are met, it automatically initiates the model optimization and iteration process. These machine learning model update conditions are typically triggered by two mechanisms: one is time-based periodic triggering, such as executing once every month; the other is performance threshold triggering, such as when the model's prediction accuracy for recent delay causes drops below a specific critical value.

[0069] Once the update conditions are met, the server retrieves multiple delay records accumulated within the historical time interval from the business database. These records constitute a high-quality training sample set, with each record containing two key parts: complete order attribute data for the historical logistics order and a verified actual reason for the delay.

[0070] Subsequently, the server retrains the pre-trained model using the latest delay records. In this process, the server uses order attribute data as input features and the actual cause of delay as the target label. Through a specific machine learning algorithm, it calculates the difference between the model's predicted output and the actual situation. Based on this difference, the algorithm automatically adjusts tens of thousands of network parameters within the model, such as the connection weights between neurons.

[0071] The purpose of this parameter update is to enable the model to better learn new patterns and correlations emerging in recent operational data, thereby enhancing the model's predictive ability and adaptability to future delays. After the update, the new model will seamlessly take over the prediction task, enabling the prediction system to self-evolve and continuously optimize.

[0072] For example, one of the conditions set for updating the machine learning model on the server is a periodic time trigger, meaning it is automatically executed at the end of each quarter. When the system time reaches the end of the third quarter, this condition is met, and the server then starts the update process.

[0073] The server first retrieves 10,000 order records from the database that were marked as "urgent" and ultimately confirmed to be delayed within the current quarter, i.e., the past three months. Each record contains attribute data such as the initial sorting time, number of delivery personnel, and weather conditions, as well as the actual reason for the delay, such as "traffic congestion" or "low sorting efficiency".

[0074] Next, the server uses these 1,000 records as a new training set to retrain the existing prediction model. During training, the algorithm discovers that the model is not good at predicting congestion caused by the new factor of "temporary traffic control," so it adjusts the internal network parameters related to "traffic congestion index" and "delivery area type" to enable the model to more accurately capture this correlation.

[0075] In one possible embodiment of this application, S1, the real-time acquisition of order attribute data for logistics orders includes: S11. Collect raw order attribute data in real time from the logistics server and external service interface; S12. The original order attribute data is cleaned and standardized to eliminate outliers and unify the data format; S13. The processed order attribute data is used as the final order attribute data; the order attribute data includes: sorting time, number of delivery personnel, weather conditions, delivery address complexity, cargo weight, cargo volume, delivery distance, order placement time, sorting center processing volume, delivery area type, historical delay count of delivery route, and traffic congestion index.

[0076] Specifically, the server executes the data acquisition process, continuously acquiring raw order attribute data from the internal logistics server and various external service interfaces. The internal logistics server provides core business data for orders, while external service interfaces supplement real-time information related to the delivery environment. By establishing stable data connection channels, the server ensures that data can be streamed to the data processing center in real-time or near real-time, providing a comprehensive and timely data foundation for subsequent analysis.

[0077] In the data cleaning and standardization process, the server performs a series of quality improvement operations on the collected raw order attribute data. Data cleaning mainly focuses on identifying and processing abnormal data, such as using statistical methods to detect and correct values ​​that clearly exceed reasonable ranges. Standardization aims to unify the data formats and units from different sources, converting time information into a unified timestamp format, mapping text descriptions to standard enumeration values, and normalizing numerical data to ensure it falls within a uniform numerical range. This eliminates the heterogeneity of data sources and guarantees data quality and consistency.

[0078] After cleaning and standardization, the server encapsulates the processed order attribute data into a structured data object, which serves as the final output of the order attribute data. This data object integrates all verified and standardized feature information, has a well-organized structure and reliable content, and can be directly applied to subsequent predictive analysis tasks in machine learning models.

[0079] In one possible embodiment of this application, S2, the step of inputting the order attribute data into a pre-trained machine learning model to predict the cause of the delay, includes: S21. Convert the order attribute data into an order feature vector; S22. The order feature vector is transformed and abstracted nonlinearly through multiple hidden layers within the machine learning model; S23. Obtain the probability values ​​of multiple delay cause categories output by the machine learning model; S24. Based on the probability value, determine the one with the highest probability value from the multiple delay cause categories as the predicted delay cause.

[0080] Specifically, in step S21, the server converts the final order attribute data into a mathematical representation suitable for processing by a machine learning model, namely, an order feature vector. This process essentially maps raw data of various types and dimensions into a fixed-dimensional vector composed of numerical values ​​through specific encoding and normalization rules. In this vector, the value in each dimension corresponds to a specific order attribute feature, thereby transforming unstructured business data into standardized input that the model can recognize.

[0081] Subsequently, in step S22, the server feeds the generated order feature vectors into a pre-trained machine learning model. This model contains a complex network structure consisting of multiple hidden layers. As the feature vectors flow through these hidden layers, each layer performs a non-linear mathematical transformation and combination on the input data, extracting and abstracting complex patterns from low-level features to high-level features layer by layer. This series of transformations aims to uncover deep, non-intuitive correlations between various order attributes and potential delay outcomes, providing an informational basis for the final classification judgment.

[0082] After completing the forward propagation calculation, in step S23, the server obtains the result from the output layer of the machine learning model. This result is a probability distribution vector, where each component represents the probability of occurrence corresponding to a predefined category of delay cause. The sum of the probabilities of all components is one.

[0083] Finally, in step S24, the server analyzes the output probability distribution vector. It identifies and selects the delay cause category with the highest probability value. The server formally determines this category as the final output of this prediction, i.e., the predicted delay cause, thus completing the entire intelligent analysis process from data input to decision-making.

[0084] For example, the server can convert the attribute data of an order, such as weight 5 kg, volume 0.2 cubic meters, traffic index 80, etc., into a numerical feature vector such as [5, 0.2, 80, ...].

[0085] After being input into the model, the vector undergoes complex weighting and nonlinear function processing in the hidden layer, resulting in multiple transformations and recombinations of its internal features. The model ultimately outputs a probability distribution, for example: low sorting efficiency (15%), insufficient delivery personnel (10%), unclear delivery address (5%), severe weather (8%), cargo problems (2%), and traffic congestion (60%). Based on this, the server selects "traffic congestion," with a probability as high as 60%, as the predicted cause of delay for this order.

[0086] In one possible embodiment of this application, S3, the step of matching the corresponding handling strategy according to the predicted delay cause, and generating an expedited delivery warning event according to the handling strategy and the predicted delay cause, includes: S31. Using the predicted delay cause as an index, search the pre-configured strategy knowledge base to match one or more handling strategies.

[0087] S32. Prioritize the multiple disposal strategies and select the disposal strategy with the highest evaluation score as the final disposal strategy.

[0088] S33. The predicted delay cause and the final handling strategy are combined to generate a structured expedited delivery warning event, which includes: event description, handling instructions and priority identifier.

[0089] Specifically, in step S31, the server uses the determined predicted delay cause as the key query basis to perform a precise search in a pre-configured strategy knowledge base. This strategy knowledge base is a structured database that stores the mapping relationship between various delay causes and corresponding handling strategies. Through query operations, the server can match one or more candidate handling strategies associated with the current delay scenario. These strategies constitute a preliminary set of solutions to address the current potential delay problem.

[0090] Subsequently, in step S32, if the number of multiple handling strategies is greater than or equal to two, the server performs a priority evaluation on the matched candidate handling strategies. This evaluation process is based on a comprehensive quantitative evaluation model that considers multiple dimensions, including the expected handling effect of each strategy, the required resource cost, and the urgency of the current event. The server calculates a comprehensive evaluation score for each strategy and, based on comparison logic, selects the strategy with the highest evaluation score as the final handling strategy to guide subsequent operations. If the number of matched handling strategies is equal to one, no priority evaluation is required, and it is directly used as the final handling strategy.

[0091] Finally, in step S33, the server initiates the information synthesis process. It logically correlates and integrates the abstract predicted causes of delays with specific final handling strategies, generating a complete and clearly defined expedited warning event. This event is a standardized data object, whose core structure includes several key parts. The event description clearly explains the current delay risk. The handling instructions are directly derived from the final handling strategy, providing clear operational guidance. Furthermore, the server assigns a priority identifier to the event based on the severity and urgency of the delay cause to guide subsequent resource allocation.

[0092] In one possible embodiment of this application, The prioritization evaluation of multiple handling strategies includes: The priority evaluation score for each processing strategy is calculated using the following formula: P i =α*E i +β*(1-C i )+γ*U i .

[0093] Among them, P i E represents the priority evaluation score of the i-th disposal strategy; i The expected effect coefficient of the i-th handling strategy is a normalized value between 0 and 1, which is quantified based on the average success rate of the handling strategy in solving similar delay causes in historical data. C i The resource cost coefficient of the i-th disposal strategy is a normalized value between 0 and 1, which is related to the time cost, human cost and economic cost required to execute the disposal strategy. U i The urgency coefficient represents the urgency level of the i-th handling strategy. The urgency coefficient is a normalized value between 0 and 1, which is jointly determined by the severity level of the predicted delay cause and the remaining fulfillment time margin of the logistics order. α, β, and γ are the weights corresponding to the expected effect coefficient, resource cost coefficient, and urgency coefficient, respectively, and satisfy α+β+γ=1. The weights are preset through business rules or machine learning.

[0094] Specifically, the expected effect coefficient E i This is used to quantify the effectiveness of the treatment strategy in solving similar problems in historical applications. Its calculation relies on statistical analysis of historical data, and the specific steps are as follows: The server retrieves all historical records from the historical handling record database that indicate the predicted delay cause is the same as the current cause and that the i-th handling strategy was executed.

[0095] The server determines whether the processing in each historical record was successful based on the final status of the order. The criterion for success is that, after executing the policy, the order is delivered within the promised timeframe or is no longer in a delayed state.

[0096] The server counts the total number of retrieved historical records, N. total And the number N of those marked as successful success .

[0097] Expected effect coefficient E i This is obtained by calculating the historical success rate, i.e., E. i =N success / N total The result is a value between 0 and 1, with a higher value indicating a better expected effect of the strategy.

[0098] For example, the strategy of activating a backup sorting line has been used 100 times in history to address low sorting efficiency, successfully preventing delays 85 times. What is its expected effectiveness coefficient E? i =85 / 100=0.85.

[0099] The resource cost coefficient C i This coefficient is used to quantify the overall cost required to implement the disposal strategy. It is a weighted average of time cost, labor cost, and economic cost, calculated as follows: Time cost T i Calculate the ratio of the estimated time required to execute the strategy to the standard processing time, and then normalize it.

[0100] Labor costs L i Calculate the ratio of the number of personnel required to implement the strategy to the standard manpower configuration, and then normalize the ratio.

[0101] Economic cost M i Calculate the ratio of the additional cost incurred in implementing this strategy to the standard cost threshold, and then normalize it.

[0102] Weighted aggregation: The three normalized cost dimensions mentioned above are weighted according to their business importance. t w l w m (satisfies w) t +w l +w m =1), perform weighted summation to obtain the preliminary comprehensive cost C. i_preliminary =w t *T i +w l *L i +w m *M i .

[0103] The resource cost coefficient is ultimately calculated as C. i =C i_preliminary In the priority evaluation formula, through (1-C i The logic of lower cost and higher priority is reflected in the form of ) .

[0104] For example, the strategy of dispatching aircraft for emergency delivery has a very short time cost T. i =0.1, but with extremely high human and economic costs L i =0.9, M i =0.95. If the weight is w t =0.3、w l =0.3、w m =0.4, then its C i = 0.3*0.1 + 0.3*0.9 + 0.4*0.95 = 0.03 + 0.27 + 0.38 = 0.68. This indicates that the overall resource cost of this strategy is very high.

[0105] The urgency coefficient U i It is determined by two factors: the severity level of the delay (S) and the order time leeway (R).

[0106] The severity level S of the delay cause is preset with a severity weight for each type of predicted delay cause. For example, severe weather is set to 0.9 (high), and insufficient delivery personnel is set to 0.6 (medium). This weight value S is read directly from the preset configuration table.

[0107] The order time leeway R is calculated as follows: First, obtain the current time T. current And the latest promised delivery time T of the order promised Then, the remaining time T is calculated. remaining = T promised - T current Finally, the remaining time is compared with a standard delivery time T.standard In comparison, the time sufficiency R=T remaining / T standard When R is greater than 1, the value is 1, indicating that there is ample time.

[0108] Urgency level coefficient U i The calculation formula is U i = S * (1 - R). This formula shows that the more serious the cause of the delay and the more pressing the remaining time, the higher the urgency coefficient.

[0109] For example: An order may be delayed due to severe weather (S=0.9), with a remaining time of 2 hours, while the standard delivery time for this segment is 1 hour. Therefore, the time leeway R = 2 / 1 = 2, which is greater than 1, so we take 1. The urgency coefficient U... i = 0.9 * (1 - 1) = 0. This result is logical: although the weather is bad, the urgency is not high because there is plenty of time. If the remaining time is only 0.5 hours, then R = 0.5 / 1 = 0.5, U i = 0.9 * (1 - 0.5) = 0.45, at which point the urgency level increases significantly.

[0110] The weighting coefficients α, β, and γ can be set using one of the following two main methods: First, it is based on pre-defined business rules. This method involves domain experts manually assigning values ​​according to business strategy. For example, if the primary business objective is to ensure customer experience, a higher weight α might be assigned to the expected effect coefficient; if the current focus is on controlling operating costs, a higher weight β might be assigned to the resource cost coefficient.

[0111] Secondly, dynamic optimization is based on machine learning. This approach utilizes accumulated historical data, with the optimization objective of minimizing overall delays or maximizing customer satisfaction. By solving a linear regression or programming problem, it derives the optimal weight combination that best matches the actual business needs to ensure the predicted results. This method allows the weight coefficients to adapt to changes in business requirements.

[0112] In one possible embodiment of this application, S4, the step of pushing the expedited delivery warning event to the digital dashboard and regional manager corresponding to the logistics order, includes: S41. Based on the delivery area of ​​the logistics order, determine the area manager and digital dashboard corresponding to the delivery area; S42. Convert the expedited delivery warning event into a visual data format, and push the visual data format to the digital dashboard; S43. Encapsulate the specified field value of the expedited delivery warning event into a notification message, and push the notification message to the terminal device of the person in charge of the region through a message push server.

[0113] In step S41, the server performs target identification and association operations. Based on the logistics order delivery area information contained in the expedited delivery warning event, the server performs a precise query in a pre-configured regional resource mapping table. The delivery area refers to a logistics service zone defined by geographical scope or administrative division. Through this query, the server identifies the designated personnel responsible for managing the delivery area, i.e., the regional manager, and simultaneously locates the electronic display device (digital dashboard) deployed within the regional operations center for centrally displaying logistics dynamic information. This step ensures that the warning information can be accurately routed to the corresponding human-machine interface for that region.

[0114] In step S42, the server performs data transformation and push for visualization. The server converts structured reminder and early warning events into a visual data format conforming to the digital dashboard's parsing rules using a data rendering engine. This format is typically a data structure that defines graphic elements, layout, colors, and dynamic effects. Subsequently, the server actively pushes the converted visual data packet to the target digital dashboard's network address via an internal network communication protocol. Upon receiving the data packet, the digital dashboard's rendering program parses it and dynamically displays the early warning information in a graphical, highly visual format on its screen interface, thereby achieving group early warning for the operations team.

[0115] In step S43, the server performs message encapsulation and push for personal terminals. The server extracts specified field values ​​from the expedited delivery warning event, such as order number, predicted delay reason, and final handling strategy, and encapsulates them into a notification message format suitable for display and notification on mobile devices. This notification message is processed by a dedicated push server, which establishes connections with the push services of major mobile operating system vendors or telecom operators to ensure reliable delivery of the notification message to the smart terminal device held by the regional manager, such as a mobile phone or tablet, and triggers reminder mechanisms such as sound, vibration, or pop-up windows to achieve precise individual reach to the manager.

[0116] For example, when the server generates an expedited delivery alert for order number NL2024001, the delivery area information for that order is displayed as "City A, District B, Village C".

[0117] Based on this area information, the server retrieved the area manager for this region from the mapping table, which was identified as Wang Moumou, and the digital dashboard he was responsible for monitoring was numbered DB-ZGC-01.

[0118] The server converts the alert event into a visual data packet containing a red alert border, a highlighted order NL2024001, and a scrolling list of handling instructions, and pushes it to the DB-ZGC-01 dashboard. The dashboard then renders this alert information in the "Emergency Events" area.

[0119] The server simultaneously encapsulated the specified field value "Order NL2024001, predicted delay reason: traffic congestion, please execute: replan route" into a push notification and sent it to Wang's mobile phone via the push server. Wang's mobile phone immediately received the notification and displayed a pop-up prompt, thus completing the complete information transmission link from the system to the person in charge.

[0120] In one possible embodiment of this application, S5, obtaining the handling result data of the expedited delivery warning event and pushing the handling result data on the digital dashboard, includes: S51. Receive processing result data from the terminal device or business system of the person in charge of the region, wherein the processing result data includes: resolution status identifier and processing completion time point; S52. Calculate the processing time based on the generation time of the expedited warning event and the processing completion time. S53. Combine the resolution status identifier with the processing time into feedback information, and push the feedback information to the digital dashboard for updating and display.

[0121] Specifically, in step S51, the server continuously listens for and acquires the handling result data submitted by external systems through a preset data receiving interface. This data may originate from feedback submitted by the regional manager through their mobile terminal application, or from a status report automatically generated by the automated business system after the handling strategy has been executed. The server performs format validation on the received data to ensure that it contains two key fields: one is a resolution status identifier, a binary status quantity used to characterize whether the delay issue has been eliminated; the other is the handling completion time point, a timestamp data that precisely records the moment the handling operation was completed.

[0122] In step S52, the server executes the time interval calculation logic. First, the server extracts the generation time of the event from the stored reminder warning event records. Then, it subtracts this generation time from the processing completion time obtained in step S51, obtaining a time difference value in units of time. This time difference represents the total processing time from when the system issues a warning to when the problem is actually handled. This processing time, as an important efficiency indicator, is recorded by the server.

[0123] In step S53, the server synthesizes and pushes feedback information. The server combines the resolution status identifier and the calculated handling time into a structured feedback information data packet. This data packet follows the data exchange protocol agreed upon with the digital dashboard. Subsequently, the server proactively sends this feedback information data packet to the corresponding digital dashboard system. Upon receiving the data packet, the digital dashboard system immediately locates the corresponding warning event entry on its visualization interface and updates the display status of that entry using the received feedback information, thereby providing operators with real-time visual feedback on the handling results.

[0124] For example, after receiving a warning about order A on his mobile phone, Mr. Zhang, the regional manager, took action and clicked the "Processed" button on the terminal application. The system automatically recorded the click time as 2:30 PM on May 20, 2024.

[0125] The server received this feedback data, in which the resolution status was marked as "Resolved" and the completion time was 2024-05-20 14:30:00.

[0126] The server query showed that the expedited delivery alert for order A was generated at 14:15:00 on May 20, 2024. Calculating the time difference, the processing time was determined to be 15 minutes.

[0127] The server combines the "Resolved" status and the "15-minute" processing time into a feedback message and pushes it to the digital dashboard in the operations center. Upon receiving the message, the dashboard immediately changes the color of the warning entry for order A from yellow to green and displays the text "Processed, 15 minutes" below it, making the entire processing process and result clear to all relevant personnel.

[0128] In one possible embodiment of this application, it further includes: A1. Obtain multiple historical delay records; the historical delay records include the order attribute data of the logistics order and the actual reason for the delay of the logistics order.

[0129] Specifically, the server first retrieves multiple historical delay records from the storage system. These records include order attribute data for the logistics orders and the actual reasons for the delays. The order attribute data covers various information related to the logistics orders, such as the order creation time, estimated delivery time, actual delivery time, shipping location, receiving location, and order type. The actual reasons for delays refer to the specific factors that caused the order to fail to arrive on time during the actual logistics process, such as abnormal weather, traffic congestion, or warehousing problems. The server collects these records by accessing the database or log files to ensure data integrity and availability, providing a foundation for subsequent processing.

[0130] For example, the server retrieves overdue records from the logistics management system's database for the past year, which includes order attribute data such as order number, shipping date, and delivery route, as well as the actual reasons for the delays, such as road closures due to heavy rain or delivery delays caused by peak holiday periods.

[0131] A2. Perform data cleaning, feature encoding, and feature filtering on the multiple historical delay records to obtain a sample dataset.

[0132] Specifically, the server performs data cleaning, feature encoding, and feature filtering on multiple historical delay records to form a sample dataset. Data cleaning involves removing duplicate records, correcting erroneous data, and filling in missing values ​​to ensure data accuracy and consistency. Feature encoding converts non-numerical data into numerical representations, for example, mapping textual delay reasons to numerical identifiers. Feature filtering selects the features most relevant to delay prediction from all available features, such as evaluating feature importance based on statistical methods or domain knowledge, thereby reducing redundancy and improving model efficiency. Finally, the server generates a structured sample dataset suitable for machine learning training.

[0133] A3. Use the random forest algorithm to train the sample dataset to obtain the initial model.

[0134] Specifically, the server uses the Random Forest algorithm to train the sample dataset, generating an initial machine learning model. The Random Forest algorithm is an ensemble learning method that improves the model's accuracy and robustness by constructing multiple decision trees and combining their predictions. The server divides the sample dataset into input features and output labels, where input features include order attribute data and output labels represent the true causes of delays. During training, the server iteratively optimizes the parameters of the decision trees, enabling the model to learn the correlation between features and causes of delays, thus forming the initial prediction model.

[0135] A4. The initial model is validated and its parameters are adjusted using 5-fold cross-validation to obtain the final machine learning model.

[0136] Specifically, the server uses a 5-fold cross-validation method to validate and tune the initial model to obtain the final machine learning model. 5-fold cross-validation randomly divides the sample dataset into five equal subsets. The server sequentially uses four of these subsets for model training, and the remaining subset for testing, repeating this process five times to ensure each subset is used for testing. By evaluating the accuracy and stability of each test, the server identifies shortcomings in the initial model and adjusts parameters such as the number or depth of trees to optimize model performance. Finally, based on the validation results, the server selects the optimal parameter configuration to generate an optimized machine learning model.

[0137] A5. Encapsulate the machine learning model as a REST API.

[0138] Specifically, the server encapsulates the final machine learning model into a REST API, allowing external systems to access and use it via standard network protocols. The encapsulation process involves converting the model into a deployable service interface, defining input and output formats—for example, input being order attribute data for logistics orders, and output being predicted delay reasons. The server ensures that the API adheres to REST architecture principles, supports common HTTP request methods such as POST requests for submitting prediction data, and returns structured responses. In this way, the model can be integrated into existing logistics management systems to achieve real-time prediction capabilities.

[0139] This embodiment systematically processes historical delay records and applies machine learning technology to build predictive models, enabling efficient and accurate identification of the causes of logistics order delays. This helps improve the intelligence level of logistics management, reduce manual intervention, enhance the timeliness and reliability of delay response, and ultimately optimize overall logistics operational efficiency.

[0140] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0141] Please see Figure 3 This illustration shows a structural diagram of a logistics order timeliness monitoring device provided in an exemplary embodiment of this application, hereinafter referred to as device 3. Device 3 can be implemented as all or part of a server through software, hardware, or a combination of both. Device 3 includes: The acquisition unit 301 is used to acquire the order attribute data of logistics orders in real time; The prediction unit 302 is used to input the order attribute data into a pre-trained machine learning model to predict the cause of the delay. The generation unit 303 is used to match the corresponding handling strategy according to the predicted delay cause, and generate an expedited delivery warning event according to the handling strategy and the predicted delay cause; Push unit 304 is used to push the expedited delivery warning event to the digital dashboard and regional manager corresponding to the logistics order; The monitoring unit 305 is used to acquire the handling result data of the expedited warning event and to push the handling result data on the digital dashboard; In one or more possible embodiments, the real-time acquisition of order attribute data for logistics orders includes: Raw order attribute data is collected in real time from logistics servers and external service interfaces; The original order attribute data is cleaned and standardized to eliminate outliers and unify the data format; The processed order attribute data will be used as the final order attribute data; the order attribute data includes: sorting time, number of delivery personnel, weather conditions, delivery address complexity, cargo weight, cargo volume, delivery distance, order placement time, sorting center processing volume, delivery area type, historical delay count of delivery route, and traffic congestion index; The step of inputting the order attribute data into a pre-trained machine learning model to predict the cause of the delay includes: Convert the order attribute data into an order feature vector; The order feature vector is nonlinearly transformed and abstracted through multiple hidden layers within the machine learning model; Obtain the probability values ​​of multiple delay cause categories output by the machine learning model; Based on the probability value, the one with the highest probability value among the multiple delay cause categories is determined as the predicted delay cause.

[0142] In one or more possible embodiments, the step of matching a corresponding handling strategy based on the predicted delay cause, and generating an expedited delivery warning event based on the handling strategy and the predicted delay cause, includes: Using the predicted delay reasons as an index, a search is performed in the pre-configured strategy knowledge base to match one or more handling strategies; The multiple handling strategies are prioritized and the handling strategy with the highest evaluation score is selected as the final handling strategy. The predicted causes of delays are combined with the final handling strategy to generate a structured expedited delivery warning event, which includes: an event description, a handling instruction, and a priority identifier.

[0143] In one or more possible embodiments, prioritizing the multiple disposal strategies includes: The priority evaluation score for each processing strategy is calculated using the following formula: Pi =α*E i +β*(1-C i ) + γ*U i ; Among them, P i E represents the priority evaluation score of the i-th disposal strategy; i The expected effect coefficient of the i-th handling strategy is a normalized value between 0 and 1, which is quantified based on the average success rate of the handling strategy in solving similar delay causes in historical data. C i The resource cost coefficient of the i-th disposal strategy is a normalized value between 0 and 1, which is related to the time cost, human cost and economic cost required to execute the disposal strategy. U i The urgency coefficient represents the urgency level of the i-th handling strategy. The urgency coefficient is a normalized value between 0 and 1, and is jointly determined by the severity level of the predicted delay cause and the remaining fulfillment time margin of the logistics order. α, β, and γ are the weights corresponding to the expected effect coefficient, resource cost coefficient, and urgency coefficient, respectively, and satisfy α+β+γ= 1. The weights are preset through business rules or machine learning.

[0144] In one or more possible embodiments, pushing the expedited delivery warning event to the digital dashboard and regional manager corresponding to the logistics order includes: Based on the delivery area of ​​the logistics order, determine the area manager and digital dashboard corresponding to the delivery area; The expedited delivery warning event is converted into a visual data format, and the visual data format is pushed to the digital dashboard; The specified field value of the expedited delivery warning event is encapsulated into a notification message, and the notification message is pushed to the terminal device of the person in charge of the region through a message push server.

[0145] In one or more possible embodiments, acquiring the handling result data of the expedited delivery warning event and pushing the handling result data on the digital dashboard includes: Receive processing result data from the terminal device or business system of the person in charge of the region, the processing result data including: resolution status indicator and processing completion time; The processing time is calculated based on the generation time of the expedited warning event and the processing completion time. The resolution status identifier and the processing time are combined into feedback information, and the feedback information is pushed to the digital dashboard for updating and display.

[0146] In one or more possible embodiments, it also includes: The update unit is used to detect when the machine learning model update conditions are met, acquire multiple delay records within a historical time interval, and update the network parameters of the machine learning model based on the multiple delay records; the delay records include the attribute data of the logistics order and the actual reasons for the delay; the machine learning model update conditions include: reaching a preset model time; or the number of collected delay records reaching a preset number threshold.

[0147] In one or more possible embodiments, it also includes: The training unit is used to acquire multiple historical delay records for expedited shipments; the historical delay records include order attribute data of the logistics orders and the actual reasons for the delays of the logistics orders; Data cleaning, feature encoding, and feature filtering were performed on the multiple historical delay records to obtain a sample dataset. An initial model is obtained by training the sample dataset using the random forest algorithm; The initial model was validated and its parameters were adjusted using 5-fold cross-validation to obtain the final machine learning model. The machine learning model is encapsulated as a REST API.

[0148] It should be noted that the device 3 provided in the above embodiments, when executing the logistics order timeliness monitoring method, is only illustrated by the division of the above functional modules. 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 above functions. In addition, the logistics order timeliness monitoring device and the logistics order timeliness monitoring method embodiments provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0149] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0150] See Figure 4 The diagram shown is a schematic of a computer storage medium provided in an embodiment of this application. The computer storage medium can store multiple instructions (i.e., ... Figure 4 The computer program shown above), the instructions are adapted to be loaded and executed by a processor as described above. Figure 2 The method steps of the illustrated embodiment can be found in the following documentation for detailed execution. Figure 2 The specific details of the illustrated embodiments will not be elaborated here.

[0151] This application also provides a computer program product that stores at least one instruction, which is loaded and executed by the processor to implement the logistics order timeliness monitoring method as described in the above embodiments.

[0152] Please see Figure 5 This provides a schematic diagram of a server structure for an embodiment of this application. For example... Figure 5 As shown, the server 500 may include: at least one processor 501, at least one network interface 504, a user interface 503, a memory 505, and at least one communication bus 502.

[0153] The communication bus 502 is used to enable communication between these components.

[0154] The user interface 503 may include input units such as a mouse and keyboard.

[0155] The network interface 504 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0156] The processor 501 may include one or more processing cores. The processor 501 connects to various parts of the server 500 via various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 505, and by calling data stored in the memory 505. Optionally, the processor 501 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 501 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also be implemented as a separate chip without being integrated into the processor 501.

[0157] The memory 505 may include random access memory (RAM) or read-only memory. Optionally, the memory 505 may include a non-transitory computer-readable storage medium. The memory 505 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 505 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 505 may also be at least one storage device located remotely from the aforementioned processor 501. Figure 5 As shown, the memory 505, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and application programs.

[0158] exist Figure 5 In the server 500 shown, the user interface 503 is mainly used to provide an input interface for users and obtain user input data; while the processor 501 can be used to call the application program stored in the memory 505 and specifically execute, such as Figure 2 The method shown can be referred to for details. Figure 2 As shown, it will not be elaborated further here.

[0159] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0160] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A method for monitoring the timeliness of logistics orders, characterized in that, include: Real-time acquisition of order attribute data for logistics orders; The order attribute data is input into a pre-trained machine learning model to predict the cause of the delay. Match the corresponding handling strategy according to the predicted delay reasons, and generate an expedited delivery warning event based on the handling strategy and the predicted delay reasons; The expedited delivery warning event is pushed to the digital dashboard corresponding to the logistics order and the regional manager. The system acquires the handling result data of the aforementioned expedited delivery warning event and pushes the handling result data onto the digital dashboard.

2. The method according to claim 1, characterized in that, The real-time acquisition of order attribute data for logistics orders includes: Raw order attribute data is collected in real time from logistics servers and external service interfaces; The original order attribute data is cleaned and standardized to eliminate outliers and unify the data format; The processed order attribute data will be used as the final order attribute data; the order attribute data includes: sorting time, number of delivery personnel, weather conditions, delivery address complexity, cargo weight, cargo volume, delivery distance, order placement time, sorting center processing volume, delivery area type, historical delay count of delivery route, and traffic congestion index; The step of inputting the order attribute data into a pre-trained machine learning model to predict the cause of the delay includes: Convert the order attribute data into an order feature vector; The order feature vector is nonlinearly transformed and abstracted through multiple hidden layers within the machine learning model; Obtain the probability values ​​of multiple delay cause categories output by the machine learning model; Based on the probability value, the one with the highest probability value among the multiple delay cause categories is determined as the predicted delay cause.

3. The method according to claim 1 or 2, characterized in that, The step of matching the corresponding handling strategy based on the predicted delay cause, and generating an expedited delivery warning event based on the handling strategy and the predicted delay cause, includes: Using the predicted delay reasons as an index, a search is performed in the pre-configured strategy knowledge base to match one or more handling strategies; The priority of the multiple disposal strategies is evaluated, and the disposal strategy with the highest evaluation score is selected as the final disposal strategy. The predicted causes of delays are combined with the final handling strategy to generate a structured expedited delivery warning event, which includes: an event description, a handling instruction, and a priority identifier.

4. The method according to claim 3, characterized in that, The prioritization evaluation of multiple handling strategies includes: The priority evaluation score for each processing strategy is calculated using the following formula: P i =a*E i +β*(1-C i )+γ*U i ; Among them, P i E represents the priority evaluation score of the i-th disposal strategy; i C represents the expected effect coefficient of the i-th handling strategy, which is a normalized value between 0 and 1, quantified based on the average success rate of this handling strategy in resolving similar causes of delays in historical data; i This represents the resource cost coefficient of the i-th disposal strategy, where the resource cost coefficient is a normalized value between 0 and 1, and is related to the time cost, labor cost, and economic cost required to execute the disposal strategy; U i The urgency coefficient represents the urgency level of the i-th handling strategy. The urgency coefficient is a normalized value between 0 and 1, which is determined by the severity level of the predicted delay cause and the remaining fulfillment time margin of the logistics order. α, β, and γ are the weights corresponding to the expected effect coefficient, resource cost coefficient, and urgency coefficient, respectively, and satisfy α+β+γ= 1. The weights are preset through business rules or machine learning.

5. The method according to claim 4, characterized in that, The process of pushing the expedited delivery warning event to the digital dashboard and regional manager corresponding to the logistics order includes: Based on the delivery area of ​​the logistics order, determine the area manager and digital dashboard corresponding to the delivery area; The expedited delivery warning event is converted into a visual data format, and the visual data format is pushed to the digital dashboard; The specified field value of the expedited delivery warning event is encapsulated into a notification message, and the notification message is pushed to the terminal device of the person in charge of the region through a message push server.

6. The method according to claim 4 or 5, characterized in that, The process of acquiring the handling result data of the expedited delivery warning event and pushing the handling result data to the digital dashboard includes: Receive processing result data from the terminal device or business system of the person in charge of the region, the processing result data including: resolution status indicator and processing completion time; The processing time is calculated based on the generation time of the expedited warning event and the processing completion time. The resolution status identifier and the processing time are combined into feedback information, and the feedback information is pushed to the digital dashboard for updating and display.

7. The method according to claim 6, characterized in that, Also includes: When the conditions for updating the machine learning model are met, multiple delay records for expedited orders within a historical time interval are obtained, and the network parameters of the machine learning model are updated based on the multiple delay records for expedited orders. The delay record includes the attribute data of the logistics order and the actual reason for the delay; The machine learning model update conditions include: reaching a preset model time; Or the number of collected delay records reaches a preset threshold.

8. A timeliness monitoring device for logistics orders, characterized in that, include: The acquisition unit is used to acquire order attribute data of logistics orders in real time; The prediction unit is used to input the order attribute data into a pre-trained machine learning model to predict the cause of the delay. The generation unit is used to match the corresponding handling strategy according to the predicted delay cause, and generate an expedited delivery warning event according to the handling strategy and the predicted delay cause; The push unit is used to push the expedited delivery warning event to the digital dashboard corresponding to the logistics order and the regional manager; The monitoring unit is used to acquire the handling result data of the expedited early warning event and to push the handling result data on the digital dashboard.

9. A computer storage medium, characterized in that, The computer storage medium stores a plurality of instructions adapted for loading by a processor and executing the steps of the method as described in any one of claims 1 to 7.

10. A server, characterized in that, include: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the steps of the method as described in any one of claims 1 to 7.

Images