Service provider scheduling method and system for intra-city distribution

Abstract

The invention is applied to the field of logistics management, and discloses an intra-city delivery service provider scheduling method and system, and the method comprises the steps: obtaining real-time heterogeneous service data of each delivery service provider and real-time context data corresponding to an intra-city delivery request in response to the intra-city delivery request; performing protocol conversion on each piece of real-time heterogeneous service data to obtain standardized distribution service data; splicing the standardized distribution service data with the real-time context data to generate distribution feature vectors corresponding to distribution service providers; inputting each delivery feature vector into a pre-trained scheduling decision model, screening a target delivery service provider based on a model output result, and generating a standard scheduling instruction of the target delivery service provider; performing reverse protocol conversion on the standard scheduling instruction to obtain a target execution instruction adaptive to the target distribution service provider; and executing the target execution instruction to complete the city-wide distribution request. According to the method provided by the invention, the service scheduling efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of logistics management technology, and in particular to a method and system for scheduling same-city delivery service providers. Background Technology

[0002] With the rapid development of e-commerce and local life services, upstream applications (such as e-commerce platforms and ERP systems) often need to connect with multiple same-city delivery service providers to meet diverse delivery needs.

[0003] In existing delivery scheduling methods, upstream applications integrate services by directly connecting one-to-one with the private open APIs of each same-city delivery service provider. This means that upstream applications need to register a developer account and obtain a unique key for each service provider's open platform, and then develop independent interface call logic and data adaptation code based on the service provider's technical documentation. They then directly send requests to the corresponding service provider's private API to complete operations such as order placement and status query.

[0004] However, the open APIs of various service providers exhibit significant heterogeneity. Not only do their interface specifications, parameter definitions, signature algorithms, status codes, and callback mechanisms differ, but the representation and units of core business fields (such as price and timeliness) also vary. This necessitates upstream applications developing separate adaptation code and maintaining independent access logic for each service provider. This requires significant manpower to repeatedly learn multiple sets of technical specifications, and also results in strong coupling between the system and specific service providers. Adding or changing service providers necessitates modifying core business code, leading to long development cycles, poor scalability, and severely hindering business efficiency improvements. Summary of the Invention

[0005] This invention provides a method and system for scheduling service providers in the same city delivery market, in order to solve the technical problem of how to improve the existing methods for scheduling service providers in the same city delivery market, and to improve the efficiency of scheduling operations.

[0006] To address the aforementioned technical problems, the present invention provides a method for scheduling service providers for same-city delivery, comprising: in response to a same-city delivery request, acquiring real-time heterogeneous service data of each delivery service provider and real-time context data corresponding to the same-city delivery request; Each of the aforementioned real-time heterogeneous service data is converted according to a protocol to obtain standardized delivery service data; The standardized delivery service data is concatenated with the real-time context data to generate a delivery feature vector corresponding to each of the delivery service providers; Each of the aforementioned delivery feature vectors is input into a pre-trained scheduling decision model. Based on the model output results, target delivery service providers are selected, and standard scheduling instructions for the target delivery service providers are generated. The standard scheduling instructions are reverse-protocol converted to obtain target execution instructions adapted to the target delivery service provider; wherein, the reverse protocol conversion is designed to map the common parameters of the standard scheduling instructions to private parameters that match the target delivery service provider; Execute the target execution instruction to complete the same-city delivery request.

[0007] As one preferred embodiment, the step of sequentially performing protocol conversion and encapsulation processing on each of the real-time heterogeneous service data to obtain standardized delivery service data includes: Identify the heterogeneous field types in the real-time heterogeneous service data corresponding to each delivery service provider, wherein the heterogeneous field types include price fields, time-of-delivery fields, and service quality fields; The price fields are sequentially subjected to unit conversion and field mapping to obtain standardized price data; The time-sensitive fields are sequentially parsed and their values ​​are normalized to obtain standardized time-sensitive data. The service quality fields are sequentially subjected to feature extraction and standardized encoding to obtain standardized service quality data; The standardized price data, standardized timeliness data, and standardized service quality data are integrated, and the integrated standardized data is packaged to obtain the standardized delivery service data corresponding to each of the delivery service providers.

[0008] As one preferred embodiment, the real-time context data includes real-time traffic data, real-time weather data, and capacity saturation data of various delivery service providers; The standardized delivery service data is concatenated with the real-time context data to generate delivery feature vectors corresponding to each delivery service provider, including: The real-time traffic data, the real-time weather data, and the capacity saturation data are normalized respectively to obtain real-time context features; Extract delivery service features from the standardized delivery service data, and concatenate the delivery service features with the real-time context features to obtain a multi-dimensional feature set; The multi-dimensional feature set is subjected to consistency processing to generate delivery feature vectors corresponding to each of the delivery service providers.

[0009] As one preferred embodiment, the training process of the scheduling decision model includes: Obtain historical same-city delivery full-link data from each delivery service provider, wherein the historical same-city delivery full-link data includes historical heterogeneous service data, historical context data, and historical order fulfillment result data; Feature extraction is performed on the historical heterogeneous service data and the historical context data respectively, and the results of feature extraction are fused to obtain a structured delivery feature set; The historical order fulfillment result data is quantified to obtain an order evaluation feature set; An initial scheduling decision model is constructed, and the initial scheduling decision model is iteratively trained using the structured delivery feature set as training data and the order evaluation feature set as training labels to obtain a trained scheduling decision model.

[0010] As one preferred embodiment, before executing the target execution instruction, the method further includes: Perform a health check on the API interface corresponding to the target delivery service provider, and execute the corresponding execution instructions based on the health check results; If the health status test result is normal, then the target execution instruction is executed; If the health check result is a network timeout, DNS resolution failure, or abnormal interface response status code, then an exponential backoff retry operation is performed or the target execution instruction is updated.

[0011] Another aspect of the present invention provides a same-city delivery service provider dispatch system, comprising: The acquisition module is used to respond to same-city delivery requests by acquiring real-time heterogeneous service data of various delivery service providers and real-time context data corresponding to the same-city delivery request. The conversion module is used to perform protocol conversion on each of the real-time heterogeneous service data to obtain standardized delivery service data. The splicing module is used to splice the standardized delivery service data with the real-time context data to generate delivery feature vectors corresponding to each of the delivery service providers; The generation module is used to input each of the delivery feature vectors into a pre-trained scheduling decision model, filter target delivery service providers based on the model output results, and generate standard scheduling instructions for the target delivery service providers. An adaptation module is used to perform reverse protocol conversion on the standard scheduling instructions to obtain target execution instructions adapted to the target delivery service provider; wherein, the reverse protocol conversion is designed to map the common parameters of the standard scheduling instructions to private parameters that match the target delivery service provider; The execution module is used to execute the target execution instructions to complete the same-city delivery request.

[0012] As one preferred embodiment, the conversion module is specifically used for: Identify the heterogeneous field types in the real-time heterogeneous service data corresponding to each delivery service provider, wherein the heterogeneous field types include price fields, time-of-delivery fields, and service quality fields; The price fields are sequentially subjected to unit conversion and field mapping to obtain standardized price data; The time-sensitive fields are sequentially parsed and their values ​​are normalized to obtain standardized time-sensitive data. The service quality fields are sequentially subjected to feature extraction and standardized encoding to obtain standardized service quality data; The standardized price data, standardized timeliness data, and standardized service quality data are integrated, and the integrated standardized data is packaged to obtain the standardized delivery service data corresponding to each of the delivery service providers.

[0013] As one preferred embodiment, the real-time context data includes real-time traffic data, real-time weather data, and capacity saturation data of various delivery service providers; The splicing module is specifically used for: The real-time traffic data, the real-time weather data, and the capacity saturation data are normalized respectively to obtain real-time context features; Extract delivery service features from the standardized delivery service data, and concatenate the delivery service features with the real-time context features to obtain a multi-dimensional feature set; The multi-dimensional feature set is subjected to consistency processing to generate delivery feature vectors corresponding to each of the delivery service providers.

[0014] As one preferred embodiment, the generation module is further configured to: Obtain historical same-city delivery full-link data from each delivery service provider, wherein the historical same-city delivery full-link data includes historical heterogeneous service data, historical context data, and historical order fulfillment result data; Feature extraction is performed on the historical heterogeneous service data and the historical context data respectively, and the results of feature extraction are fused to obtain a structured delivery feature set; The historical order fulfillment result data is quantified to obtain an order evaluation feature set; An initial scheduling decision model is constructed, and the initial scheduling decision model is iteratively trained using the structured delivery feature set as training data and the order evaluation feature set as training labels to obtain a trained scheduling decision model.

[0015] As one preferred embodiment, the execution module is further configured to: Perform a health check on the API interface corresponding to the target delivery service provider, and execute the corresponding execution instructions based on the health check results; If the health status test result is normal, then the target execution instruction is executed; If the health check result is a network timeout, DNS resolution failure, or abnormal interface response status code, then an exponential backoff retry operation is performed or the target execution instruction is updated.

[0016] Compared with the prior art, the beneficial effects of the present invention are at least one of the following: 1) This invention significantly reduces the integration threshold and connection cost of same-city delivery services through multi-source data integration and bidirectional protocol conversion mechanisms. On the one hand, this invention simultaneously acquires real-time heterogeneous service data from delivery service providers and real-time contextual data such as traffic, weather, and capacity saturation, comprehensively covering the core information dimensions required for delivery decisions. On the other hand, through targeted protocol conversion strategies, it not only standardizes heterogeneous fields such as price, timeliness, and service quality from different service providers, but also reverse-maps standard scheduling instructions into private parameters adapted to the target service provider. This completely solves the pain points of inconsistent interface formats and data meanings in traditional multi-service provider integration, allowing upstream applications to call the capabilities of multiple delivery service providers by connecting to only one standard interface, greatly shortening the development cycle and improving system integration efficiency and data availability.

[0017] 2) This invention leverages AI-driven intelligent scheduling and a robust fault-tolerance mechanism to achieve efficient optimization and reliable fulfillment of delivery services. By concatenating standardized delivery service data with normalized contextual data into a multi-dimensional feature vector, the pre-trained scheduling decision model can dynamically make decisions based on historical fulfillment data and real-time scenario factors, accurately selecting the target service provider with the best timeliness and service quality, thus overcoming the limitations of traditional static rule-based scheduling. Furthermore, the pre-execution API interface health check, exponential backoff retries, and instruction updates, among other fault-tolerance designs, effectively address abnormal scenarios such as network fluctuations and service provider interface failures, ensuring that orders are not lost and processes are not interrupted. This not only improves the overall satisfaction of delivery services but also enhances the robustness and stability of the system in complex business environments. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating a service provider scheduling method for same-city delivery in one embodiment of the present invention. Figure 2 This is a structural block diagram of a same-city delivery service provider dispatching system in one embodiment of the present invention; Figure label: Among them, 11. Acquisition module; 12. Conversion module; 13. Concatenation module; 14. Generation module; 15. Adaptation module; 16. Execution module. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The purpose of providing these embodiments is to make the disclosure of the present invention more thorough and comprehensive. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0020] In the description of this application, the terms "first," "second," "third," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined with "first," "second," "third," etc., may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0021] In the description of this application, it should be noted that, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to fixed connections, detachable connections, or integral connections; they can refer to mechanical connections or electrical connections; they can refer to direct connections or indirect connections through an intermediate medium; and they can refer to the internal communication between two components. The terms "vertical," "horizontal," "left," "right," "upper," "lower," and similar expressions used herein are for illustrative purposes only and do not indicate or imply that the device or component referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as limiting the invention. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0022] In the description of this application, it should be noted that, unless otherwise defined, all technical and scientific terms used in this invention have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in this specification is for the purpose of describing specific embodiments only and is not intended to limit the invention. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0023] It's important to note that existing technologies in the same-city delivery service sector present significant pain points: upstream applications (such as e-commerce platforms and enterprise ERP systems) need to interface with multiple heterogeneous delivery service providers (such as local courier companies). However, the open API interface formats, data field definitions, and parameter naming conventions of these service providers are inconsistent (for example, service provider A uses "fee" to represent fees, while service provider B uses "amount," with units of cents and yuan respectively). This necessitates upstream applications developing separate integration logic for each service provider, resulting in long development cycles and high integration costs. Furthermore, traditional scheduling decisions rely solely on localized data from a single service provider, lacking integration with real-time traffic, weather, and regional capacity data. This leads to insufficient scientific rigor in scheduling results, making it difficult to balance delivery costs, timeliness, and service quality.

[0024] To address the aforementioned problems, one embodiment of the present invention provides a method for dispatching service providers for same-city delivery. For details, please refer to [link / reference needed]. Figure 1 , Figure 1 The diagram shown is a flowchart illustrating a same-city delivery service provider scheduling method according to one embodiment of the present invention, which includes steps S1-S6: S1: In response to a same-city delivery request, obtain real-time heterogeneous service data of each delivery service provider and real-time context data corresponding to the same-city delivery request.

[0025] Among them, real-time heterogeneous service data refers to service-related data provided by different delivery service providers with inconsistent data formats, field definitions, and units. This includes dynamic data such as real-time quotations and estimated delivery times, as well as static data such as historical fulfillment results. It is the core data source for the integration of multiple service providers.

[0026] Real-time contextual data refers to external environmental data that affects delivery efficiency, including traffic conditions, weather conditions, and capacity saturation. It is characterized by real-time updates and dynamic changes, and is an important reference dimension for intelligent scheduling decisions.

[0027] In this embodiment, when an upstream intelligent agent application (such as a fresh food e-commerce platform or a chain store ERP system) generates a same-city delivery request, this request is triggered through the unified API gateway provided by the platform, and the request strictly follows the standardized MCP protocol format. The request data packet adopts a structured design and must include the following fields: First, details of the delivered items, including category (such as fresh produce, 3C digital products, medicine), weight (unit: kg, accurate to one decimal place), volume (length × width × height, unit: cm), and value (unit: yuan, used for insurance determination). Secondly, the sender / recipient address information uses both administrative division codes and WGS84 coordinate system latitude and longitude coordinates to avoid delivery deviations caused by ambiguous addresses; Thirdly, user preferences and constraints, including expected delivery time window, whether insurance is required (Boolean value: true / false), and whether a dedicated delivery person is required.

[0028] When receiving a request, the unified API gateway synchronously completes high-concurrency asynchronous processing and security authentication. Through request buffering and breakpoint resume mechanisms, it ensures that request data is not lost in network fluctuation scenarios, thus achieving reliable data access.

[0029] This embodiment deploys a pluggable service provider protocol adapter cluster to pull real-time heterogeneous service data from various access service providers in parallel, avoiding the inefficiency caused by serial acquisition. The pluggable service provider protocol adapter cluster is deployed using a microservice architecture, with each adapter corresponding to one delivery service provider. The specific implementation process is as follows: Each service provider is pre-configured with an independent adapter module. Each adapter contains the service provider's open API call parameters (such as the interface URL, request method, and signature algorithm). Upon receiving a delivery request trigger signal, each adapter simultaneously initiates a data request to the corresponding service provider's open API. The acquired real-time dynamic data core includes two types: The first is real-time quote data, which is the instant fee returned by the service provider based on the current delivery route (calculated based on the latitude and longitude of the sender / recipient) and the attributes of the item (weight, volume). For example, service provider A returns "fee=1200" (unit: cents) and service provider B returns "amount=12.5" (unit: yuan). Second, estimated delivery time data, such as "estimated minutes = 45" returned by service provider A, and "time_interval = 15:30-16:10" (time interval format) returned by service provider B.

[0030] By using a parallel acquisition mechanism, the time required to acquire data from multiple service providers can be controlled within 500ms, meeting the time requirements for real-time scheduling.

[0031] To obtain external environmental data that affects delivery efficiency, this embodiment retrieves three types of core context data in real time through a third-party service interface: First, real-time traffic data is obtained by calling the open API in the navigation APP to obtain the traffic index (0-10 levels, where 0 represents smooth traffic and 10 represents severe congestion) of the area where the current delivery route is located. The data is updated every 1 minute. Second, real-time weather data is obtained by calling the open API of Weather.com to obtain the weather conditions of the delivery area for the next 2 hours, including the probability of precipitation (0%-100%), wind force level (0-17), and temperature range (unit: ℃). The data is updated every 10 minutes. Thirdly, regional capacity saturation heat map data is generated by analyzing the ratio of the number of uncompleted orders to the number of online riders in the current region in real time. The capacity saturation index (0-1, where 0 represents sufficient capacity and 1 represents saturated capacity) is then presented in the form of a heat map, with the data update frequency being once every 30 seconds.

[0032] All the aforementioned third-party interfaces are integrated through a standardized SDK. When an interface call fails, a retry mechanism is triggered (up to 3 times, with a 1-second retry interval) to ensure the real-time performance and availability of context data.

[0033] S2: Perform protocol conversion on each of the aforementioned real-time heterogeneous service data to obtain standardized delivery service data.

[0034] In this embodiment, the field type classification of real-time heterogeneous service data from various service providers is achieved through the field identification rules built into the pluggable service provider protocol adapter cluster. Specifically, for each access service provider, a "field name-field type" mapping table is pre-configured in the corresponding adapter. This mapping table is preset according to the service provider's API documentation and supports dynamic updates.

[0035] Preferably, in one embodiment of the present invention, each real-time heterogeneous service data is sequentially subjected to protocol conversion and encapsulation processing to obtain standardized delivery service data, including: Once the adapter receives the heterogeneous data returned by the service provider, it automatically identifies three core field types through keyword matching and format validation, including: Price-related fields: These are fields related to delivery costs. They are identified by field names containing keywords such as "fee," "amount," and "cost," and by field values ​​being numeric. Time-sensitive fields refer to fields related to delivery time. Their identifying characteristics are that the field name contains keywords such as "time", "duration", and "interval", and the field value can be a number, a string (time range), or a text description format. Service quality fields refer to fields related to performance quality. Their identifying characteristics are that the field name contains keywords such as "score", "rate", "complain", and "intact", and the field value can be a number, a boolean value, or an enumeration value.

[0036] For example, when adapter A connects to service provider A's API, the mapping table identifies "fee" as a price field, "estimated minutes" as a time-sensitive field, and "user_score" as a service quality field; when adapter B connects to service provider B's API, it identifies "amount" as a price field, "time_interval" as a time-sensitive field, and "complain_flag" as a service quality field.

[0037] For identified price fields, standardization is performed according to a fixed process of "unit conversion → field mapping". Specifically, a unified target unit (yuan, floating-point number, two decimal places) is preset, and the conversion rules between the original unit and the target unit for each service provider's price field are configured in the adapter. For example, the unit of service provider A's "fee" field is "fen" (cents), and the conversion rule is "value ÷ 100". If the original data is "1250", it will be converted to "12.50". The unit of service provider C's "cost" field is "jiao" (cents), and the conversion rule is "value ÷ 10". If the original data is "85", it will be converted to "8.50". The unit of service provider B's "amount" field is already "yuan", so the original value is directly retained (e.g., "10.8" is converted to "10.80").

[0038] After the unit conversion is completed, the field mapping process is performed: all price data that has undergone unit conversion is uniformly mapped to the predefined standard field "standardized_price", the field type is floating point number, and two decimal places are retained.

[0039] The standardization of time-sensitive fields follows a process of "format parsing → numerical normalization," with the core objective of converting time-sensitive data in different formats into integer values ​​in minutes. Specifically, differentiated parsing logic is used for different formats of time-sensitive data: if the field value is a pure number (such as "45" or "60"), it is directly determined as "minutes" without additional parsing; if the field value is a time range (such as "09:00-10:00"), the duration is obtained by calculating the difference between the start and end times of the range (e.g., the difference in the above range is 60 minutes); if the field value is a text description (such as "about 1 hour" or "about half an hour"), it is parsed using a preset text-to-value mapping table (e.g., "about 1 hour" is mapped to 60 minutes, and "about half an hour" is mapped to 30 minutes).

[0040] The parsed duration data is uniformly converted into integer values, with the unit fixed in "minutes," and mapped to the standard field "standardized_duration." For example, service provider A's "estimated minutes = 45" is directly normalized to 45 after parsing and mapped to "standardized_duration=45"; service provider B's "time_interval = 09:30-10:15" is parsed to a duration of 45 minutes, normalized to 45, and mapped to "standardized_duration=45"; service provider C's "duration = approximately 1.5 hours" is parsed to 90 minutes, normalized to 90, and mapped to "standardized_duration=90." The parsing logic and normalization rules are built into the adapter, supporting the expansion of the parsing template based on the time format of newly added service providers, ensuring the scalability of the technical solution.

[0041] Standardization of service quality fields is achieved through "feature extraction → standardized coding," transforming scattered service quality-related data into quantifiable and comparable standard features. Specifically, core features directly related to performance quality are extracted from heterogeneous data, including historical average on-time rate (e.g., "on_time_rate=98%" returned by service provider A), item integrity rate (e.g., "intact_flag=95%" returned by service provider B), user rating (e.g., "user_score=4.8" returned by service provider C), and complaint rate (e.g., "complain_rate=0.5%" returned by service provider A). The extraction rules are preset by technical personnel based on service quality assessment requirements.

[0042] The corresponding encoding method is adopted for different types of features: percentage features (such as on-time rate, integrity rate, complaint rate) are converted to floating-point numbers (such as "98%" is converted to 0.98, "0.5%" is converted to 0.005); rating features (1-5 points) directly retain the original values ​​to ensure quantitative consistency; Boolean features (such as "whether there is a complaint") are converted to 0-1 encoding (true=1, false=0).

[0043] After coding, all service quality-related features are uniformly mapped to a set of standard fields, including "standardized_on_time_rate" (historical average on-time rate), "standardized_intact_rate" (item integrity rate), "standardized_user_score" (user rating), and "standardized_complain_rate" (complaint rate), forming standardized service quality data.

[0044] Furthermore, the three types of standardized data are integrated and encapsulated according to a predefined unified data model. First, the integration process uses field concatenation to combine the "standardized_price," "standardized_duration," and all service quality standard fields of the same service provider into a complete structured data record, ensuring that each record is associated with its corresponding service provider (bound through the service provider's unique identifier ID). Then, data encapsulation is performed: the integrated structured data is encapsulated according to the format specified in the MCP protocol to generate standardized delivery service data objects. The data format is JSON, and field names, data types, and precision strictly adhere to unified specifications. For example, the encapsulation result for a certain service provider is: {"service_provider_id":"SP001","standardized_price":12.50,"standardized_duration":45,"standardized_on_time_rate":0.98,"standardized_intact_rate":0.99,"standardized_user_score":4.7,"standardized_complain_rate":0.003}.

[0045] After encapsulation, the adapter transmits standardized delivery service data to the AI ​​intelligent scheduling and routing engine through the internal communication interface. The transmission process uses an encryption protocol to ensure data security and supports batch transmission and breakpoint resume to avoid data loss.

[0046] S3: The standardized delivery service data is concatenated with the real-time context data to generate delivery feature vectors corresponding to each delivery service provider.

[0047] In the context of intelligent dispatching for same-city delivery, traditional dispatching decisions rely solely on the standardized service data of the delivery service provider (such as price, delivery time, and historical service quality), ignoring the crucial impact of real-time environmental factors on delivery fulfillment. For example, heavy rain reduces on-time delivery rates, evening rush hour traffic congestion prolongs actual delivery times, and regional capacity saturation leads to order queues. This "single-dimensional data-driven decision-making" model results in AI dispatching models being unable to accurately predict actual fulfillment outcomes, leading to a disconnect between decision results and the actual scenario.

[0048] This embodiment aims to deeply integrate the standardized delivery service data generated in step S2 with real-time contextual data that affects delivery efficiency, and generate a delivery feature vector with complete dimensions and uniform format through standardized splicing and processing.

[0049] Preferably, in one embodiment of the present invention, standardized delivery service data is concatenated with real-time context data to generate delivery feature vectors corresponding to each delivery service provider, including: Real-time context data (real-time traffic data, real-time weather data, and capacity saturation data) are normalized to convert environmental data of different magnitudes and formats into floating-point numbers in the 0-1 range, ensuring compatibility with standardized delivery service data.

[0050] For example, this embodiment quantifies the traffic condition index into levels 0-10 (level 0 = smooth traffic, level 10 = severe congestion), and processes it using the linear normalization formula "normalized value = original index / 10". For instance, if the real-time traffic index of a delivery route is level 7, the normalized result is 0.7; when the index is level 3, the normalized result is 0.3. The standard field can be named "normalized_traffic". The probability of precipitation in the next 2 hours is obtained as 0%-100%, and the percentage value is converted to a floating-point number. For example, when the probability of precipitation is 60%, it is normalized to 0.6; when there is no precipitation, it is normalized to 0.0. The standard field is named "normalized_precipitation". The capacity saturation index is obtained in the range of 0-1 (0 = sufficient capacity, 1 = saturated capacity), and the standard field is named "normalized_capacity_saturation".

[0051] After completing the context data normalization, core features directly related to scheduling decisions are extracted from the standardized delivery service data generated in step S2, ensuring the quantifiability and relevance of the features. The extracted feature fields are clearly defined and fixed, and include at least the following: Standardized price: a floating-point number, in yuan, rounded to two decimal places (e.g., 12.50). Standardized duration: Integer, in minutes (e.g., 45).

[0052] During the extraction process, the data type and value range of each field are automatically verified. If there are outliers (such as negative prices or on-time delivery rates exceeding 1), the historical average of orders of the same category from the same service provider is used to replace them to ensure the validity of the feature data.

[0053] Furthermore, the extracted "delivery service features" and "normalized real-time context features" are combined in a fixed order to form a structured multi-dimensional feature set, ensuring that the feature set dimensions of each delivery service provider are consistent.

[0054] In this embodiment, the splicing order is preset to "delivery service features → real-time context features", that is, first arrange 6 service features, then arrange 3 context features (traffic, precipitation probability, and capacity saturation). If new features are added later, they are added according to the principle of "service features first, context features later" to ensure the consistency of the dimension order.

[0055] The concatenated feature set is encapsulated in array format (supporting JSON arrays or NumPy arrays), with all array elements being floating-point numbers (float32 type). For example, the feature set of service provider A is: [12.50,45,0.98,0.99,0.94,0.003,0.7,0.6,0.85], where the first 6 bits are service features and the last 3 bits are context features. Each feature set is bound to a unique service provider identifier (e.g., "SP001") to ensure accurate mapping to the specific service provider during subsequent model inference, avoiding misalignment between features and the subject. The concatenation process takes less than 50ms, meeting the low latency requirements of real-time scheduling.

[0056] To ensure that the delivery feature vectors of all service providers are fully comparable, the concatenated multi-dimensional feature set needs to be processed for consistency. This consistency processing includes dimension alignment, data type unification, and numerical range verification.

[0057] Specifically, the multi-dimensional feature set is dimensionally aligned. The feature vector is preset to have a fixed dimension of 9. If a service provider is missing a certain feature due to special circumstances, such as no historical complaint rate data, the historical average of the service provider's orders in the same region and category will be automatically filled in. Force all feature elements to float32 type to avoid model input format errors caused by some fields being integers (such as timeliness); Verify the value range of all feature elements (service features are within a preset range, and context features are all 0-1). If outliers still exist (such as a normalized traffic index of 1.2), replace them with the maximum value (1.0) or minimum value (0.0) of that feature. After the consistency processing is completed, the feature set is officially converted into a delivery feature vector, which can be directly input into the AI ​​scheduling model for inference.

[0058] S4: Input each of the delivery feature vectors into the pre-trained scheduling decision model, filter the target delivery service provider based on the model output results, and generate the standard scheduling instructions for the target delivery service provider.

[0059] In same-city delivery scheduling scenarios, existing technologies generally adopt a "static rule matching" model (such as fixed selection of the lowest price or fastest delivery service provider), which has two major pain points: First, it cannot comprehensively balance multiple dimensions of factors such as price, timeliness, service quality, and real-time scenarios (traffic, weather), resulting in one-sided decision-making (such as low-priced service providers may have low on-time rates, while high-priced service providers may have saturated capacity); Second, the decision-making rules are fixed and cannot automatically adjust the weight of each factor according to dynamic scenarios (such as the importance of on-time rate should be higher than price in rainy weather).

[0060] To address the aforementioned issues, a pre-trained machine learning model (scheduling decision model), which forms the core decision-making link of the entire technical solution, is used to achieve a closed-loop transformation from multi-dimensional features to target service providers. This approach not only overcomes the limitations of traditional static rules but also ensures the scientific nature and dynamic adaptability of scheduling decisions.

[0061] Preferably, in one embodiment of the present invention, the training process of the scheduling decision model includes: Acquire historical same-city delivery end-to-end data from each delivery service provider. This historical same-city delivery end-to-end data includes historical heterogeneous service data, historical context data, and historical order fulfillment result data. Historical order fulfillment result data includes actual delivery time, item condition status, user rating (1-5 stars), complaint records, and actual delivery costs. All fields are stored in a structured format, consistent with the real-time data in S1-S3 (e.g., traffic index is 0-10, user rating is floating-point).

[0062] Furthermore, a strategy of missing value imputation and outlier removal is adopted to preprocess the historical same-city delivery full-link data. Specifically, missing historical quotes are imputed with the average of the same service provider, the same route, and the same time period. Outliers (such as actual delivery time exceeding the estimated delivery time by 3 times, user rating of 0 points and no complaint records) are removed using the 3σ principle. The data time range is limited to the past 12 months (to ensure data timeliness), and the effective sample size of a single service provider is no less than 1,000 records (to ensure training reliability).

[0063] For the preprocessed historical heterogeneous service data and historical context data, the same feature extraction and fusion process as S2-S3 is performed to ensure the consistency between training data features and real-time inference features. At the same time, the historical order fulfillment result data is quantified to generate "overall order satisfaction" as a label (order evaluation feature set) for model training, ensuring that the label is quantifiable and comparable.

[0064] Specifically, in this embodiment, four key performance indicators are selected and configured with fixed weights according to business needs (supporting dynamic adjustment): ① On-time rate (weight 0.4): 1 if the actual delivery time of the order is within the expected time window, otherwise 0; ② Goods integrity rate (weight 0.3): 1 for good quality, 0.5 for minor damage, and 0 for severe damage; ③ Price advantage (weight 0.2): Based on the lowest price quoted by all service providers in the same scenario, the lowest price / the current service provider's price is calculated, and the result is mapped to the 0-1 range; ④ No complaint indicator (weight 0.1): 1 for no complaints, and 0 for complaints.

[0065] The label value is generated based on the weighted summation formula, where the overall order satisfaction = (on-time rate × 0.4) + (item integrity rate × 0.3) + (price advantage × 0.2) + (no complaint mark × 0.1). The result is rounded to two decimal places and the value range is 0-1 (1 is the best and 0 is the worst).

[0066] For example, if an order has an on-time rate of 1, a good condition rate of 1, a price advantage of 0.9, and no complaints, the overall satisfaction rate is 1×0.4+1×0.3+0.9×0.2+1×0.1=0.98.

[0067] The model is constructed and trained based on gradient boosting decision trees (XGBoost or LightGBM). Specifically, in this embodiment, the initial scheduling decision model is constructed based on the Python open-source framework XGBoost. Its core parameters can be configured as follows: learning rate 0.1, tree depth 5, minimum number of sample splits 10, maximum number of iterations 1000, and regularization coefficient 0.1 (to prevent overfitting).

[0068] During model training, the structured delivery feature set is divided into a training set (80%) and a validation set (20%) in an 8:2 ratio, and the model is optimized using 5-fold cross-validation. The training objective function is mean squared error (MSE), and the iteration stopping condition is "the validation set MSE does not decrease for 3 consecutive rounds" or the maximum number of iterations is reached. After training, the model file is saved to the platform's distributed storage system and automatically synchronized to the AI ​​scheduling engine, supporting model version management and rollback.

[0069] Furthermore, the 9-dimensional delivery feature vectors of each service provider are input into the pre-trained model in batches. The model calculates through forward propagation and outputs the "comprehensive recommendation score" of each service provider (a predicted value based on the overall satisfaction of the order, ranging from 0 to 100 points, converted from the original predicted value × 100).

[0070] Service providers are sorted in descending order of overall recommendation score, with the top-ranked provider being selected as the initial target service provider. If the overall recommendation score of the top-ranked service provider is below a preset threshold (e.g., 60 points, configurable), multi-service provider joint scheduling is triggered; otherwise, it is directly selected as the target service provider. Example: In a rainstorm evening rush hour scenario, service provider A has an overall recommendation score of 92 points (high on-time performance weight), while service provider B has a score of 75 points (low price but low on-time performance). In this case, service provider A is selected as the target service provider.

[0071] After selecting the target service provider, the AI ​​scheduling engine generates standardized scheduling instructions based on the MCP protocol. The standard scheduling instructions are in JSON format and are based on the "create_order" instruction specification of the MCP protocol. Required fields include: unique order identifier (UUID), target service provider ID (e.g., "SP001"), sender / recipient information (standard administrative division code + latitude and longitude), item details (standardized category, weight, volume), standardized price, standardized delivery time, user preferences (insurance indicator, expected time window), and instruction generation timestamp.

[0072] The system automatically concatenates the above fields to generate a complete instruction. After the instruction is generated, it is transmitted to the MCP protocol conversion layer through an internal encrypted channel. The transmission process supports resuming interrupted transmissions to ensure that the instruction is not lost.

[0073] S5: Perform reverse protocol conversion on the standard scheduling instruction to obtain a target execution instruction adapted to the target delivery service provider; wherein, the reverse protocol conversion is designed to map the common parameters of the standard scheduling instruction to private parameters that match the target delivery service provider.

[0074] In the final implementation of same-city delivery scheduling, there are two major technical pain points: First, the standard scheduling instructions generated by S4 are based on the unified MCP protocol, but the API interfaces of various delivery service providers (such as UU Run and local courier companies) have differences in private parameter definitions, signature algorithms, and request formats (for example, service provider A requires the parameter "order_no", service provider B requires "order_id", and requires exclusive signature verification). Directly issuing standard instructions will cause service providers to be unable to recognize them, and the instructions will fail to be executed. Second, abnormal scenarios such as network fluctuations and temporary failures of service provider interfaces occur frequently. Traditional solutions lack effective fault tolerance mechanisms, which can easily lead to order loss, business process interruption, and affect user experience and fulfillment reliability.

[0075] To address the aforementioned issues, this embodiment employs reverse protocol conversion to adapt standard and proprietary instructions. Combined with interface health checks and multi-layered fault tolerance mechanisms, it ensures accurate instruction execution and business continuity.

[0076] The core of reverse protocol conversion is to map the public parameters of the platform's standard scheduling instructions to the private parameters of the target service provider through a pluggable service provider protocol adapter, thereby achieving precise adaptation between instruction format and interface requirements.

[0077] Specifically, in each service provider's corresponding adapter, a "standard parameter - private parameter" mapping table is pre-configured, which clarifies the rules for field name mapping, format conversion, signature algorithm, etc. The mapping table supports visual configuration and dynamic updates through the platform backend.

[0078] If the service provider requires a signature, the adapter automatically generates a signature field according to a preset algorithm; if the service provider's interface requires a specific request method and data format, the adapter encapsulates the converted private parameters into the corresponding format.

[0079] The converted target execution instruction is validated to ensure that the private parameters are complete, the format is compliant, and the signature is valid. If the validation passes, it is output to the interface calling module and awaits execution. If the validation fails, an error signal is returned to the scheduling engine to trigger parameter completion or re-conversion process.

[0080] S6: Execute the target execution instruction to complete the same-city delivery request.

[0081] Preferably, in one embodiment of the present invention, before executing the target execution instruction, the adapter first performs a health check on the API interface of the target delivery service provider to identify the risk of interface unavailability in advance.

[0082] Specifically, a "short heartbeat packet detection" mechanism is adopted. The adapter sends a lightweight detection request to the service provider's API health detection interface. The request packet only contains necessary fields (such as platform and request timestamp) and does not need to carry complete order parameters, thus reducing detection resource consumption. The core detection indicators include three types of anomalies: ① Network layer error (network timeout, preset timeout time is 1 second); ② DNS resolution error (unable to resolve the service provider's API domain name); ③ Application layer exception (receiving an HTTP 5xx status code response indicates an internal error on the service provider's server).

[0083] If an HTTP 2xx status code (such as 200 OK) is received from the service provider within 1 second, and the "status" field in the response body is "normal", then the interface health status is determined to be "normal". If any of the above abnormal situations occur, it is determined to be "abnormal", and the adapter immediately records the abnormal type (such as "network_timeout") and timestamp, and triggers the subsequent fault tolerance mechanism.

[0084] The fault tolerance mechanisms include offline temporary storage, exponential backoff retry, and dynamic route adjustment.

[0085] Specifically, if the interface health check result is "abnormal", the adapter immediately persists the complete target execution instruction, exception type, initial target service provider ID, order unique identifier and other information as "retry task record" to RedisCluster (distributed key-value store), and marks the status as "pending_retry". At the same time, it records the time of the first exception to ensure that the task data is not lost and supports recovery across adapter nodes.

[0086] Intelligent retries are initiated according to a preset strategy: the first retry interval is 2 seconds, the second is 4 seconds, the third is 8 seconds, the fourth is 16 seconds, and the fifth is 32 seconds, with a maximum of 5 retries. Before each retry, the interface health check is re-executed. If the check is normal, a command is sent; if it is still abnormal, the process continues to wait for the next retry. If the maximum number of retries is reached and the attempt still fails, the task status is updated to "retry_failed", and an alarm notification is triggered (such as notifying technical operations personnel via SMS or email).

[0087] For orders with strict time-sensitive requirements (e.g., the user's expected delivery time window is ≤1 hour), the adapter immediately sends a "target service provider unavailable" signal to the AI ​​intelligent scheduling engine upon first detecting an interface anomaly. Upon receiving the signal, the scheduling engine triggers a lightweight re-decision process. Specifically, it recalculates the overall recommendation score based solely on the feature vectors of currently available service providers (excluding those with anomalies), selects the second-best service provider (e.g., if the original Top 1 service provider is unavailable, the Top 2 is selected), generates a new standard scheduling instruction, and then uses the S5 reverse protocol to generate a new target execution instruction. This process involves health checks and invocation to ensure the order is fulfilled within the timeframe. For example, if a fresh produce order requires delivery within 1 hour, and the target service provider A's interface is unavailable, after two retries (cumulative time 2+4=6 seconds), the scheduling engine immediately selects service provider B, which has the second-highest overall recommendation score, regenerates the instruction, and executes it, ultimately ensuring the order is delivered on time.

[0088] If the interface health check result is "normal", the adapter initiates the formal invocation of the target execution instruction and the state synchronization process.

[0089] Specifically, the target execution command is sent to the target service provider's API through an HTTPS encrypted channel to ensure data transmission security; a request timeout (e.g., 3 seconds) is set when sending the command to avoid prolonged blocking.

[0090] The adapter receives the execution result response from the service provider and parses the response data according to preset rules: for example, if the target service provider returns "{"code":0,"msg":"success","data":{"waybill_no":"WB12345678"}}", it is parsed as "Instruction executed successfully, waybill number WB12345678"; if it returns "{"code":1001,"msg":"Parameter error"}", it is parsed as "Instruction execution failed, reason: parameter error".

[0091] The adapter synchronizes the parsed execution results to the platform's order management module, updates the order status (such as "order accepted" or "pending delivery"), and feeds back to upstream applications (such as e-commerce platforms) through a unified API gateway to ensure that upstream applications can obtain order fulfillment progress in real time. At the same time, the execution results and response data are stored in a distributed database as historical data for subsequent model optimization.

[0092] Another embodiment of the present invention provides a same-city delivery service provider dispatch system. For details, please refer to [link / reference]. Figure 2 , Figure 2 The diagram shown illustrates a structural block diagram of a same-city delivery service provider dispatch system according to one embodiment of the present invention, which includes: The acquisition module 11 is used to acquire real-time heterogeneous service data of each delivery service provider and real-time context data corresponding to the same-city delivery request in response to the same-city delivery request. The conversion module 12 is used to perform protocol conversion on each of the real-time heterogeneous service data to obtain standardized delivery service data; The splicing module 13 is used to splice the standardized delivery service data with the real-time context data to generate delivery feature vectors corresponding to each of the delivery service providers; The generation module 14 is used to input each of the delivery feature vectors into a pre-trained scheduling decision model, filter target delivery service providers based on the model output results, and generate standard scheduling instructions for the target delivery service providers. The adaptation module 15 is used to perform reverse protocol conversion on the standard scheduling instruction to obtain a target execution instruction that is adapted to the target delivery service provider; wherein, the reverse protocol conversion is designed to map the common parameters of the standard scheduling instruction to private parameters that match the target delivery service provider; The execution module 16 is used to execute the target execution instruction to complete the same-city delivery request.

[0093] Preferably, in one embodiment of the present invention, the conversion module is specifically used for: Identify the heterogeneous field types in the real-time heterogeneous service data corresponding to each delivery service provider. The heterogeneous field types include price fields, time-of-delivery fields, and service quality fields. The price fields are sequentially converted to units and mapped to obtain standardized price data. The time-sensitive fields are sequentially parsed and their values ​​are normalized to obtain standardized time-sensitive data. The service quality fields are sequentially subjected to feature extraction and standardized coding to obtain standardized service quality data. By integrating standardized price data, standardized timeliness data, and standardized service quality data, and then encapsulating the integrated standardized data, standardized delivery service data corresponding to each delivery service provider is obtained.

[0094] Preferably, in one embodiment of the present invention, the real-time context data includes real-time traffic data, real-time weather data, and capacity saturation data of each delivery service provider; The splicing module is specifically used for: Real-time traffic data, real-time weather data, and capacity saturation data are normalized to obtain real-time contextual features. Extract delivery service features from standardized delivery service data, and concatenate these features with real-time context features to obtain a multi-dimensional feature set. Consistency processing is performed on the multi-dimensional feature set to generate delivery feature vectors corresponding to each delivery service provider.

[0095] Preferably, in one embodiment of the present invention, the generation module is further configured to: Obtain historical same-city delivery full-chain data from each delivery service provider. This historical same-city delivery full-chain data includes historical heterogeneous service data, historical context data, and historical order fulfillment result data. Feature extraction is performed on historical heterogeneous service data and historical context data respectively, and the results of feature extraction are fused to obtain a structured delivery feature set; Quantitative processing of historical order fulfillment data yields an order evaluation feature set. An initial scheduling decision model is constructed. The initial scheduling decision model is iteratively trained using a structured delivery feature set as training data and an order evaluation feature set as training labels to obtain a trained scheduling decision model.

[0096] Preferably, in one embodiment of the present invention, the execution module is further configured to: Perform a health check on the API interface corresponding to the target delivery service provider, and execute the corresponding execution command based on the health check result; If the health status test result is normal, then the target execution command will be executed. If the health check result is network timeout, DNS resolution failure, or abnormal interface response status code, then perform an exponential backoff retry operation or update the target execution command.

[0097] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. A method for dispatching same-city delivery service providers, characterized in that, include: In response to a same-city delivery request, real-time heterogeneous service data of each delivery service provider and real-time context data corresponding to the same-city delivery request are obtained. Each of the aforementioned real-time heterogeneous service data is converted according to a protocol to obtain standardized delivery service data; The standardized delivery service data is concatenated with the real-time context data to generate a delivery feature vector corresponding to each of the delivery service providers; Each of the aforementioned delivery feature vectors is input into a pre-trained scheduling decision model. Based on the model output results, target delivery service providers are selected, and standard scheduling instructions for the target delivery service providers are generated. The standard scheduling instructions are reverse-protocol converted to obtain target execution instructions adapted to the target delivery service provider; wherein, the reverse protocol conversion is designed to map the common parameters of the standard scheduling instructions to private parameters that match the target delivery service provider; Execute the target execution instruction to complete the same-city delivery request.

2. The same-city delivery service provider dispatching method as described in claim 1, characterized in that, The process of sequentially performing protocol conversion and encapsulation on each of the real-time heterogeneous service data to obtain standardized delivery service data includes: Identify the heterogeneous field types in the real-time heterogeneous service data corresponding to each delivery service provider, wherein the heterogeneous field types include price fields, time-of-delivery fields, and service quality fields; The price fields are sequentially subjected to unit conversion and field mapping to obtain standardized price data; The time-sensitive fields are sequentially parsed and their values ​​are normalized to obtain standardized time-sensitive data. The service quality fields are sequentially subjected to feature extraction and standardized encoding to obtain standardized service quality data; The standardized price data, standardized timeliness data, and standardized service quality data are integrated, and the integrated standardized data is packaged to obtain the standardized delivery service data corresponding to each of the delivery service providers.

3. The same-city delivery service provider dispatching method as described in claim 1, characterized in that, The real-time context data includes real-time traffic data, real-time weather data, and capacity saturation data of various delivery service providers; The standardized delivery service data is concatenated with the real-time context data to generate delivery feature vectors corresponding to each delivery service provider, including: The real-time traffic data, the real-time weather data, and the capacity saturation data are normalized respectively to obtain real-time context features; Extract delivery service features from the standardized delivery service data, and concatenate the delivery service features with the real-time context features to obtain a multi-dimensional feature set; The multi-dimensional feature set is subjected to consistency processing to generate delivery feature vectors corresponding to each of the delivery service providers.

4. The same-city delivery service provider dispatching method as described in claim 1, characterized in that, The training process of the scheduling decision model includes: Obtain historical same-city delivery full-link data from each delivery service provider, wherein the historical same-city delivery full-link data includes historical heterogeneous service data, historical context data, and historical order fulfillment result data; Feature extraction is performed on the historical heterogeneous service data and the historical context data respectively, and the results of feature extraction are fused to obtain a structured delivery feature set; The historical order fulfillment result data is quantified to obtain an order evaluation feature set; An initial scheduling decision model is constructed, and the initial scheduling decision model is iteratively trained using the structured delivery feature set as training data and the order evaluation feature set as training labels to obtain a trained scheduling decision model.

5. The same-city delivery service provider dispatching method as described in claim 1, characterized in that, Before executing the target execution instruction, the following is also included: Perform a health check on the API interface corresponding to the target delivery service provider, and execute the corresponding execution instructions based on the health check results; If the health status test result is normal, then the target execution instruction is executed; If the health check result is a network timeout, DNS resolution failure, or abnormal interface response status code, then an exponential backoff retry operation is performed or the target execution instruction is updated.

6. A same-city delivery service provider dispatch system, characterized in that, include: The acquisition module is used to respond to same-city delivery requests by acquiring real-time heterogeneous service data of various delivery service providers and real-time context data corresponding to the same-city delivery request. The conversion module is used to perform protocol conversion on each of the real-time heterogeneous service data to obtain standardized delivery service data. The splicing module is used to splice the standardized delivery service data with the real-time context data to generate delivery feature vectors corresponding to each of the delivery service providers; The generation module is used to input each of the delivery feature vectors into a pre-trained scheduling decision model, filter target delivery service providers based on the model output results, and generate standard scheduling instructions for the target delivery service providers. An adaptation module is used to perform reverse protocol conversion on the standard scheduling instructions to obtain target execution instructions adapted to the target delivery service provider; wherein, the reverse protocol conversion is designed to map the common parameters of the standard scheduling instructions to private parameters that match the target delivery service provider; The execution module is used to execute the target execution instructions to complete the same-city delivery request.

7. The same-city delivery service provider dispatch system as described in claim 6, characterized in that, The conversion module is specifically used for, including: Identify the heterogeneous field types in the real-time heterogeneous service data corresponding to each delivery service provider, wherein the heterogeneous field types include price fields, time-of-delivery fields, and service quality fields; The price fields are sequentially subjected to unit conversion and field mapping to obtain standardized price data; The time-sensitive fields are sequentially parsed and their values ​​are normalized to obtain standardized time-sensitive data. The service quality fields are sequentially subjected to feature extraction and standardized encoding to obtain standardized service quality data; The standardized price data, standardized timeliness data, and standardized service quality data are integrated, and the integrated standardized data is packaged to obtain the standardized delivery service data corresponding to each of the delivery service providers.

8. The same-city delivery service provider dispatch system as described in claim 6, characterized in that, The real-time context data includes real-time traffic data, real-time weather data, and capacity saturation data of various delivery service providers; The splicing module is specifically used for: The real-time traffic data, the real-time weather data, and the capacity saturation data are normalized respectively to obtain real-time context features; Extract delivery service features from the standardized delivery service data, and concatenate the delivery service features with the real-time context features to obtain a multi-dimensional feature set; The multi-dimensional feature set is subjected to consistency processing to generate delivery feature vectors corresponding to each of the delivery service providers.

9. The same-city delivery service provider dispatch system as described in claim 6, characterized in that, The generation module is further configured to: Obtain historical same-city delivery full-link data from each delivery service provider, wherein the historical same-city delivery full-link data includes historical heterogeneous service data, historical context data, and historical order fulfillment result data; Feature extraction is performed on the historical heterogeneous service data and the historical context data respectively, and the results of feature extraction are fused to obtain a structured delivery feature set; The historical order fulfillment result data is quantified to obtain an order evaluation feature set; An initial scheduling decision model is constructed, and the initial scheduling decision model is iteratively trained using the structured delivery feature set as training data and the order evaluation feature set as training labels to obtain a trained scheduling decision model.

10. The same-city delivery service provider dispatch system as described in claim 6, characterized in that, The execution module is further configured to: Perform a health check on the API interface corresponding to the target delivery service provider, and execute the corresponding execution instructions based on the health check results; If the health status test result is normal, then the target execution instruction is executed; If the health check result is a network timeout, DNS resolution failure, or abnormal interface response status code, then an exponential backoff retry operation is performed or the target execution instruction is updated.

Images