A method for distributing request text data, an electronic device, and a storage medium.

Abstract

This invention discloses a method, electronic device, and storage medium for distributing and processing request text data, relating to the field of text data processing technology. The method includes: receiving request text data to be processed; classifying the request text data into a first type of service request or a second type of service request using a binary classifier; extracting target entity features from the first type of service request using named entity recognition, and then matching it with a historical knowledge base to determine the first type of subject and data interaction interface address; processing the second type of service request using multimodal feature fusion, and then inputting it into a multi-classifier to determine the second type of subject and associated interface information; finally, outputting the unique identifier of the subject and the corresponding interface information to complete the request processing. This invention improves the feature representation and discrimination capabilities of the distribution system for heterogeneous requests, optimizes the resource allocation efficiency of data processing and model inference, and thus, at the technical level, contributes to the automated request processing in complex cross-domain scenarios.

Description

Technical Field

[0001] This invention relates to the field of text data processing technology, and in particular to a method for distributing requested text data, an electronic device, and a storage medium. Background Technology

[0002] Automated processing and precise matching of service requests are key to improving management efficiency. Currently, the core technological bottleneck in achieving this goal lies in how to enable computer systems to deeply understand user requests that are complex, ambiguous, and accompanied by multi-dimensional contextual information, just like experienced human workers, and to make reliable distribution decisions.

[0003] Existing technical solutions mainly fall into two categories. The first category is a matching method based on fixed rules, which achieves distribution by simply matching preset keywords with the request text. This method inherently lacks true semantic understanding capabilities and cannot handle requests with diverse expressions, implicit elements, or complex logic, resulting in low distribution accuracy and weak generalization ability.

[0004] The second category comprises methods based on machine learning models, such as the invention patent CN117726104B, "A method, apparatus, device, and storage medium for distributing hotline work orders." This approach represents technological advancements in the field, improving the automation level of distribution by building predictive models. However, in-depth analysis reveals limitations in achieving deep, accurate, and adaptive distribution: 1. Limited Model Feature Representation and Insufficient Utilization of Contextual Information: This approach primarily relies on the textual semantic features of the request, failing to fully and structurally integrate multimodal contextual information closely related to the distribution decision. This includes the precise spatial location of the request, temporal characteristics (such as whether it falls during peak or emergency periods), and historical behavioral patterns of the same initiating entity. Consequently, the computer system's understanding of the request remains at the literal level, lacking real-world scenario embedding. This limits its judgment when faced with semantically ambiguous or context-dependent complex requests.

[0005] 2. Closed knowledge sources and lack of domain knowledge integration mechanisms: Its model relies entirely on historical labeled data for training and inference, making it a closed system. It struggles to proactively access and utilize external, structured domain knowledge (such as the latest organizational responsibility lists and emergency response procedures), resulting in the distribution system's inability to adapt to dynamic adjustments in business rules, subjects, or processing procedures, thus limiting its flexibility and maintainability.

[0006] 3. Strong dependence on labeled data and weak generalization ability in scenarios with few samples: The model's performance is highly coupled with labeled historical work order data. For emerging business areas with sparse data or new types of requests that have never appeared before, the model performs poorly due to the lack of training samples, making it difficult to achieve reliable zero-sample or few-sample distribution, thus limiting its application scope.

[0007] Therefore, there is a need for a request text data processing and distribution technology that can deeply integrate multi-dimensional contextual information, effectively integrate external domain knowledge, and maintain robust generalization capabilities under conditions with few tags, in order to solve the technical problems of insufficient semantic understanding depth, limited environmental adaptability, and strong data dependence in the current system. Summary of the Invention

[0008] To address the aforementioned technical problems, the technical solution adopted by this invention is as follows: According to a first aspect of the present invention, a method for distributing request text data is provided, the method comprising the following steps: S100, receive request text data to be processed, the request text data includes event description text and associated metadata, the associated metadata includes request subject associated data, spatial associated data and time series associated data.

[0009] S200, the request text data is input into a preset binary classifier, and the classification result is output, which is either a first type of service request or a second type of service request.

[0010] S300, if the classification result is a first type of service request, the target entity features in the request text data are extracted by the named entity recognition model; the target entity features are used as retrieval conditions to match in a preset historical knowledge base to determine the corresponding first type of subject and associated interface information.

[0011] S400, if the classification result is a second type of service request, perform multimodal feature fusion processing on the request text data to obtain a fused feature dataset; input the fused feature dataset into a preset multi-classifier, and output the corresponding second type of subject and associated interface information.

[0012] S500: Output the unique identifier of the first type of subject or the second type of subject and the corresponding interface information to complete the processing of the request text data.

[0013] According to a second aspect of the present invention, an electronic device is provided, including a processor and a memory; the processor executes the steps of the method described in the first aspect of the present invention by invoking a program or instructions stored in the memory.

[0014] According to a third aspect of the present invention, a computer-readable storage medium is provided that stores a program or instructions that cause a computer to perform the steps of the method described in the first aspect of the present invention.

[0015] The present invention has at least the following beneficial effects: 1. Improved classification and matching accuracy in complex request scenarios: By introducing a binary classifier and a differentiated downstream processing pipeline, accurate diversion of cross-domain requests was first achieved. For the first type of service request, combined with domain-optimized named entity recognition and hierarchical knowledge base retrieval, rapid and accurate matching of massive heterogeneous external service entities was achieved. For the second type of service request, multimodal feature fusion technology was used to integrate text, spatiotemporal, and historical context information, and domain knowledge was injected using event semantic graphs. This enabled the multi-classifier to consider semantic associations and business rules simultaneously in feature representation and decision-making, thereby improving the subject matching accuracy in complex scenarios such as ambiguous request descriptions, missing elements, or overlapping responsibilities.

[0016] 2. Optimized processing efficiency and resource utilization: The phased processing architecture and targeted feature engineering design avoid computational redundancy caused by a single complex model handling all requests. The binary classifier performs lightweight initial screening, with the first type of service request path relying on efficient entity matching, while the second type of service request path focuses on deep multimodal analysis. This division of labor reduces unnecessary feature computation and model inference overhead, lowers response latency and data storage and interaction load, and achieves an optimized balance between processing efficiency and resource cost.

[0017] 3. Enhanced scalability and domain adaptability: The method, through modular design (such as an independently updatable historical knowledge base, an online learning-enhanced multi-classifier, and a dynamically expandable event semantic graph) and a decision-making mechanism based on structured knowledge (such as element association features and business rule associations), can quickly adapt to newly emerging first-type service platforms, second-type entities, or business rules without reconstructing the core model by updating the knowledge base and graph content. This improves the adaptability of the technical solution to changes in different domains and business scenarios.

[0018] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A flowchart of a request text data processing method provided in an embodiment of the present invention. Detailed Implementation

[0021] 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. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of this invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0023] It should be noted that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe the steps as sequential processes, many of these steps can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the steps can be rearranged. A process can be terminated when its operation is complete, but it may also have additional steps not included in the figures. A process can correspond to a method, function, procedure, subroutine, subroutine, etc.

[0024] This invention addresses the limitations of existing request text data processing technologies, namely, the limited depth of semantic understanding and the insufficient utilization of multimodal information. Specifically, traditional methods fail to fully achieve structured alignment and deep fusion of unstructured text with spatiotemporal, historical, and other multi-dimensional contextual information. This results in limited semantic representation and generalization capabilities of the model for complex requests, low levels of system automation, and the need for significant manual intervention. To facilitate the description of the technical solution of this invention, some terms appearing in this document are defined as follows. These definitions are only used to explain the embodiments of this invention and do not constitute a limitation on the scope of protection of this invention.

[0025] Request text data: refers to the complete set of information submitted by the requesting object, including event description text and associated metadata. The event description text is unstructured content expressed in natural language, and the associated metadata includes request subject-related data, spatial related data, and temporal related data.

[0026] Category 1 services refer to service types involving commercial transactions and consumption activities, including but not limited to commodity transactions, order processing, after-sales service, and logistics distribution, with the processing entity being a commercial entity. Accordingly, a Category 1 service request refers to a request text data that reflects matters falling within the scope of Category 1 services, a Category 1 entity refers to a commercial entity responsible for processing Category 1 service requests, and a Category 1 service platform refers to a system platform used to receive and process Category 1 service requests.

[0027] Category II services refer to service types other than Category I services, involving social affairs management and people's livelihood security, including but not limited to infrastructure maintenance, environmental order management, social welfare affairs, and emergency response, etc., and are handled by non-commercial entities. Accordingly, a Category II service request refers to a request text data that reflects matters falling within the scope of Category II services, a Category II entity refers to a non-commercial entity responsible for handling Category II service requests, and a Category II service platform refers to a system platform used to receive and process Category II service requests.

[0028] The distinction between the two types of service requests is automatically determined by a pre-defined binary classifier based on text semantics and associated metadata.

[0029] Entity: Refers to the execution unit responsible for processing requests, including Type I entities and Type II entities. Each entity has a unique identifier and associated interface information within the system, used for the flow and interaction of request data.

[0030] Event Semantic Graph: This refers to a domain knowledge base organized in a graph structure, where nodes are core elements (including event elements, subject elements, and rule elements), and edges represent the logical relationships between elements. This graph is used to semantically augment and verify request text during multimodal feature fusion.

[0031] The above terminology definitions are used throughout this invention and will not be further explained in subsequent embodiments. This invention aims to overcome the technical shortcomings of existing request text data processing technologies, namely, shallow semantic understanding and insufficient utilization of multimodal information. Specifically, traditional methods fail to effectively achieve structured alignment and deep fusion of unstructured text with multi-dimensional contextual information such as spatiotemporal and historical information, resulting in weak semantic representation capabilities and poor generalization of complex requests, low system automation, and reliance on extensive manual intervention.

[0032] To address the aforementioned technical problems, this invention provides a solution for deep processing and analysis of request text data. By employing a domain-adaptive large model for deep semantic parsing and structured transformation, and combining multimodal feature fusion methods and event semantic graph technology, this solution constructs a technical process capable of accurately extracting, associating, and utilizing the embedded semantics, spatiotemporal attributes, and domain knowledge of requests. This process improves the quality of feature representation and classification capabilities for complex requests, thereby achieving high-precision automated processing of requests.

[0033] Specifically, embodiments of the present invention provide a method for distributing and processing request text data, such as... Figure 1 As shown, the method includes the following steps: S100, receive request text data to be processed, the request text data includes event description text and associated metadata.

[0034] In this invention, the request text data is a complete set of information submitted by the requesting party to the request processing system, reflecting the request matter. Its data sources cover multiple channels, such as hotlines, mobile applications, and mini-programs, supporting multi-source data access from both first-class and second-class service platforms. The event description text is the core content of the request text data, referring to the natural language expression of the requesting subject regarding its own request matter. Its content typically presents a narrative logic of "problem description—impact explanation—processing requirements," fully covering the core object of the event, the scope of impact, and the expected solution, without needing to follow a fixed format, thus preserving the original intent of the initiator. The associated metadata is auxiliary information with a clear structure that accompanies the event description text. The purpose of introducing associated metadata is to provide key spatiotemporal and subject background for machine understanding of text, breaking through the limitations of only analyzing the literal meaning of the text. Associated metadata mainly includes three categories: Request subject association data: refers to the identifying information related to the request subject, used to establish the association between the request subject and historical requests. The data sources include active reporting by the request subject or automatic collection by the platform. The specific content may include anonymized information such as the request subject's anonymous user ID and contact information hash value, as well as historical record identifiers used to associate the subject with past request items.

[0035] Spatial correlation data refers to geographic information related to the location where the request occurred, used to accurately locate the spatial range of the request. There are two ways to obtain it: one is to extract address information from the event description text and perform structured parsing to obtain hierarchical address data of province, city, district, street, community, and specific location; the other is to directly obtain the location correlation data of the incoming call terminal with the authorization of the requesting subject to obtain latitude and longitude coordinate information. The two methods can be used alone or in combination to improve the accuracy of spatial positioning. Time-series related data refers to time information related to the submission time of a request. It includes two dimensions: first, the original timestamp of the request submission, i.e., the request reception time accurate to the minute and second; second, time period division data based on the original timestamp according to preset rules. The preset rules are set according to the business characteristics of the second type of service processing, specifically divided into morning peak hours, working hours, evening peak hours, and non-working hours. An exemplary time period division standard is: morning peak hours are 7:00-9:00, working hours are 9:00-17:00, evening peak hours are 17:00-19:00, and non-working hours are 19:00 to 7:00 the next day.

[0036] The request text data received through step S100 integrates unstructured semantic information and structured scene information, providing comprehensive and accurate input data support for subsequent processing procedures such as binary classification and multimodal feature fusion.

[0037] S200, the request text data is input into a preset binary classifier, and the classification result is output, which is either a first type of service request or a second type of service request.

[0038] This step is used to initially classify requests based on the semantic features and associated metadata of the request text data, outputting either a first-class or second-class service request. After classification, the first-class service requests enter a processing flow that matches external service entities based on a historical knowledge base; the second-class service requests enter a precise distribution flow based on multimodal feature fusion and event semantic graphs. Through this classification, requests from different domains can be diverted to the corresponding processing modules, reducing the system performance loss and distribution errors that may be caused by mixed processing, and providing a foundation for subsequent differentiated processing.

[0039] The construction process of the pre-defined binary classifier revolves around the core logic of high-quality training data preparation, effective feature extraction, and robust model training, and specifically includes the following steps: S201, obtain request text data within a preset historical time period, manually annotate the request text data to obtain two types of tags, namely a first tag corresponding to the first type of service request and a second tag corresponding to the second type of service request.

[0040] The purpose of this step is to construct a high-quality labeled dataset to provide supervision signals for training the binary classification model. The selection of the preset historical time period needs to balance data timeliness and sample coverage: for example, selecting historical data with a one-year time period as an illustrative example ensures a sufficient number of samples (covering the request characteristics of different seasons and business rule cycles, such as peak e-commerce complaint periods during holidays, emergency response and handling in specific scenarios, etc.) while avoiding labeling bias caused by changes in business scenarios due to excessively long historical data (such as the addition of a second type of service function or emerging e-commerce models).

[0041] The manual annotation process must follow standardized specifications: First, establish clear labeling criteria. The first label, "1," corresponds to the first type of service request, specifically including scenarios such as transaction disputes, logistics and delivery, and after-sales service. Examples of such requests include "obstruction of returning goods with quality issues after online shopping" and "claiming compensation for lost express parcels." The second label, "0," corresponds to the second type of service request, specifically including categories such as social affairs support, infrastructure maintenance, and order management. Typical request examples include text descriptions reflecting missing facilities in a certain area and requesting their replacement, or text descriptions inquiring about the procedures and rules for handling certain types of affairs. Then, at least two professional annotators independently annotate the data. Samples with inconsistent annotations are confirmed through cross-checking and expert review to ensure an annotation accuracy rate of no less than 95%, avoiding annotation noise from affecting model training. The final annotated dataset is divided into a training set and a validation set according to a preset ratio (e.g., 7:3), used for model training and hyperparameter tuning, respectively.

[0042] S202 involves text cleaning of the labeled request text data, removing interfering features such as HTML tags, emoticons, and stop words, while retaining relevant core features.

[0043] This step aims to remove meaningless interference information and retain the core features that are highly relevant to distinguishing between the first and second types of service requests, thereby reducing the computational complexity of the model and improving the accuracy of feature representation. The specific cleaning operations and logic are as follows: Disruptive Feature Removal: HTML tags are commonly found in online request data submitted by second-category service apps and e-commerce platforms (such as those carried by copied and pasted webpage content). Tags and (Label), the emoji is an emotional symbol added when the request object freely expresses (such as "[angry emoji] The express delivery is delayed for a long time"), and the stop words are general words without specific semantics (such as "of, already, at"). Such information has limited ability to distinguish request scenarios and may even dilute the core semantics, and is batch removed through regular matching and stop word dictionary matching; Core features are retained: The core features retained in this step are all the key bases to support the scenario determination of the binary classifier, specifically including three categories: Numeric features: Order numbers, transaction amounts corresponding to the first type of service scenario, and matter acceptance numbers, business handling numbers, etc. of the second type of service scenario (such as "Order 123456789 return" "Inquiry about the progress of matter 678"). Such features can quickly distinguish the "transaction type" and "non-transaction type" request attributes and are important identifiers for initial scenario judgment; Network address features: Mostly product links and store links of the first type of service platform (such as "https: / / xxx.com Complaint about product quality"). Such features have strong scenario directivity and can directly determine that the request belongs to the e-commerce platform related scenario; Subject name features: The subject includes the first type of subject and the second type of subject. Among them, the first type of subject corresponds to the first type of service request, and its name covers commercial entity names such as e-commerce platforms, merchants, and logistics service providers (such as "E-commerce platform P" "Logistics service provider Q"); the second type of subject corresponds to the second type of service request, and its name covers the identifiers of relevant affair handling subjects (such as "Subject A" "Subject B"). Such features are the core semantic units extracted from the request text based on the named entity recognition model and provide key bases for request category determination and subject matching.

[0044] For the above core features, differential extraction means are adopted: numeric features and network address features are extracted by regular expression matching, and subject name features are accurately identified by the named entity recognition model; after feature extraction, all interfering information is removed to form standardized text data, providing high-quality input for subsequent feature engineering processing.

[0045] S203. Perform feature engineering processing on the cleaned request text data to generate TF-IDF features, character-level n-gram features of a preset length, and preset keyword boolean features related to the target scenario.

[0046] The core of this step is to convert the standardized text data into numerical features recognizable by the model, while taking into account general semantic capture and scenario precise matching, breaking through the limitation of traditional shallow feature extraction relying only on single keywords. The generation logic, functions, and detailed implementation examples of each feature are as follows: TF-IDF feature: Employing a 1-2 gram word-level partitioning method, this feature quantifies the semantic importance of words by calculating the term frequency (TF) in a single request text and the inverse document frequency (IDF) in the entire request text. For example, words related to the second type of service request have lower IDF values ​​and higher weights in the second type of service corpus, while words related to the first type of service request have lower IDF values ​​and higher weights in the first type of service corpus. This feature effectively captures the general semantic information of the text, avoiding feature omissions due to differences in expression (such as "lost package" versus "package not received").

[0047] Character-level n-gram features: Employing a 3-5 gram phrase-level segmentation, continuous character combinations in the text are extracted using a sliding window to capture contextualized phrase semantics that cannot be expressed by a single word. These phrases are the core semantic units that distinguish between the first and second types of service requests. Selecting a length range of 3-5 grams ensures the integrity of phrase semantics while avoiding feature sparsity caused by excessively long grams.

[0048] Pre-defined keyword Boolean features: For the core business pain points of the first type of service scenario, keywords such as "returns," "refunds," "logistics," "orders," "products," "transactions," "after-sales service," and "stores" are selected to construct a keyword dictionary. For each request text, if it contains a keyword from the dictionary, it is assigned a value of 1; otherwise, it is assigned a value of 0. This feature can quickly identify the core requests of the first type of service scenario, improving the classification model's sensitivity in recognizing this scenario.

[0049] Finally, the three types of features are concatenated according to their feature dimensions to form a feature matrix with uniform dimensions, which serves as the input data for the binary classification model.

[0050] S204. Based on the dataset after feature engineering, a preset binary classification model is trained to obtain the binary classifier.

[0051] This step involves selecting a model suitable for the text classification scenario, optimizing hyperparameters, and conducting multi-dimensional evaluation to build a robust and accurate binary classifier. Specific technical details and logic are as follows: Binary classification model selection: Choose either LinearSVC (Linear Support Vector Classification) or SGDClassifier (Stochastic Gradient Descent Classifier). Both are suitable for classifying high-dimensional text feature matrices and offer advantages such as high training efficiency and strong generalization ability. LinearSVC maintains stable classification accuracy in small-sample, high-dimensional data scenarios, while SGDClassifier trains faster on large-scale data. The choice can be made flexibly based on the actual amount of training data. Hyperparameter optimization: Optimal hyperparameters are determined using a grid search combined with 5-fold cross-validation. The grid search iterates through preset hyperparameter combinations (e.g., the regularization parameter C of LinearSVC ranges from [0.1, 1, 10], and the learning rate of SGDClassifier ranges from [0.001, 0.01, 0.1]). 5-fold cross-validation randomly divides the training set into 5 parts, using 4 parts for training and 1 part for validation in turn, avoiding hyperparameter overfitting caused by a single data partition. Model Evaluation and Judgment: The F1 score is used as the core evaluation metric, while also considering accuracy, precision, and recall. The F1 score balances precision (avoiding misclassifying second-category service requests as first-category service requests) and recall (avoiding omitting first-category service requests), adapting to the business requirement of prioritizing accurate request classification and eliminating omissions. A classification judgment threshold of 0.5 is used. When the predicted probability output by the model is greater than 0.5, it is judged as a first-category service request (first label "1"), otherwise it is judged as a second-category service request (second label "0"). This threshold is a conventional and reasonable value for binary classification tasks, ensuring the balance of classification results. Model combination optimization: To further improve classification stability, a soft-voting combination of the LinearSVC model and the SGDClassifier model can be used. The final prediction result is obtained by weighted averaging the prediction probabilities of the two models. Combining the advantages of the two models reduces the generalization error of a single model and improves the classification accuracy in extreme scenarios (e.g., requests involving both transaction issues of the first type of service platform and transactions under the jurisdiction of the second type of entity).

[0052] Through the steps S201-S204 above, the constructed binary classifier can effectively extract deep semantic features of the request text, accurately distinguish between the first type of service request and the second type of service request, and provide a reliable classification basis for subsequent accurate processing according to different scenarios.

[0053] S300, if the classification result is a first type of service request, the target entity features in the request text data are extracted by the named entity recognition model; the target entity features are used as retrieval conditions to match in a preset historical knowledge base to determine the corresponding first type of subject and associated interface information.

[0054] This step follows the binary classification result determination of S200 and is a dedicated processing flow for the first type of service scenario. Its core purpose is to accurately match the corresponding first type of subject and interface information based on the core entity characteristics of the request text data, so as to realize the automated diversion processing of the first type of service requests, reduce the efficiency loss of manual retrieval of interface information, and reduce the delay in request flow caused by incorrect subject matching.

[0055] In this invention, a pre-trained large model with domain adaptive optimization is used as the named entity recognition model. This model is not a general pre-trained model, but is fine-tuned and optimized for the first type of service scenario to ensure the extraction accuracy of domain-specific entities of the first type of service.

[0056] Model fine-tuning strategy: Select request corpora from typical scenarios such as transaction disputes, after-sales service, and logistics delivery on the first type of service platform (e.g., "First type of service platform P order 123456789 return obstructed" "First type of service platform Q logistics package lost") as fine-tuning corpora. Based on the general pre-trained large model, the AdamW optimizer is used with an initial learning rate of 5e-5, and the model is fine-tuned after 3 rounds of incremental training. At the same time, five core entity types are set as recognition targets, namely the name of the first type of service platform, order number, store name, logistics service provider name, and transaction dispute type, which comprehensively covers the core related elements of the first type of service request processing.

[0057] Entity Extraction and Type Labeling: The cleaned first-category service request text data is input into the named entity recognition model described above. The model automatically identifies and labels the target entity features in the text. An example extraction result is: "[First-category service platform name: First-category service platform P][Order number: 123456789][Dispute type: Return blocked]". To avoid errors or invalid information in the entities extracted by the named entity recognition model (such as incorrectly identified order numbers or non-existent first-category service platform names), an entity type verification mechanism is performed on the extracted target entity features to improve the accuracy of subsequent matching. The specific verification rules are as follows: Format validation: For entities with fixed format specifications (such as order numbers and tracking numbers), regular expressions are used to match preset formats (such as order numbers being "8 digits + 2 letters" and tracking numbers being "12 digits"). Invalid entities that do not conform to the format are removed. Reasonableness verification: For entities with a clear scope, such as the name of a first-class service platform and the name of a logistics service provider, the model compares them with the preset whitelist of first-class service platforms (such as first-class service platform P, first-class service platform Q, and first-class service platform R) and the whitelist of logistics service providers, and removes erroneous entities that are not in the whitelist (such as the model mistakenly identifying "a certain second-class service platform" as the name of a first-class service platform). Closed-loop processing of verification results: retain the features of valid target entities that pass the double verification, and remove invalid or erroneous entities; if the number of valid entities extracted is 0, mark the request as "pending manual review" and push it to the operation and maintenance terminal, where staff will manually annotate the core entities; at the same time, synchronize the manual review results to the model fine-tuning corpus for iterative optimization of the model and continuous improvement of entity extraction accuracy.

[0058] In this invention, the historical knowledge base is a dedicated knowledge base for the first type of service request processing, comprising two core sub-bases, both of which are configured with a real-time update mechanism: The database for connecting to Category I service platforms stores the official entity name, service contact identifier, and data interaction interface address of each Category I service platform. It also synchronizes the interface update announcements of each Category I service platform monthly to ensure the timeliness of the connection information. The first type of service request processing case library stores the matching records of entity characteristics and subjects of historical first type of service requests, and adds new cases monthly to continuously enrich the matching samples.

[0059] In this invention, a hierarchical matching principle is adopted: precise matching is prioritized, meaning that when the extracted entities such as the name of the first type of service platform and the order number match 100% with the records in the database of the first type of service platform, the corresponding first type of subject is directly matched; if precise matching yields no results (e.g., the first type of service platform in the request text is an emerging platform, the order number format is not standardized, or the store name has an abbreviation / alias, etc., and is not included in the database of the first type of service platform), then fuzzy matching is performed. Based on entities such as the dispute type and the name of the logistics service provider in the request text, the cosine similarity algorithm is used to calculate the similarity with historical cases in the case library, and the top M cases (e.g., M=3) with a similarity higher than a preset similarity threshold, such as 0.85, are selected. The optimal matching subject is determined by combining the dispute type weight. The specific process is as follows: (1) Construct feature vectors for historical cases and current requests to be matched in the first type of service request processing case library respectively: For historical cases: extract the core entity features (dispute type, logistics service provider name, request keywords, and handling entity) and transform the discrete entity features into numerical feature vectors with unified dimensions based on the pre-set first-class service domain word vector dictionary (such as the first-class service request-specific word vectors trained by the Word2Vec model). The vector dimension is set to 256 dimensions to ensure that the semantic relevance of the features can be quantified. For the current request to be matched: extract the valid entity features that have passed the verification (such as "dispute type: logistics delay", "logistics service provider name: XTO Express", "request keyword: package not delivered"), and use the same word vector dictionary as historical cases to transform them into feature vectors of the same dimension to ensure the comparability of the two.

[0060] (2) The cosine similarity algorithm is used to calculate the similarity value between the current request feature vector and the feature vectors of all historical cases in the case library. The cosine similarity value ranges from [-1, 1]. The closer the value is to 1, the higher the semantic similarity between the current request and the historical cases, and the stronger the matching degree of the request scenario; the closer the value is to -1, the greater the semantic difference between the two.

[0061] (3) Based on the calculated similarity value, sort all historical cases in descending order and select historical cases with a similarity value higher than the preset threshold of 0.85. If the number of cases that meet the conditions exceeds K, select the top K cases as candidate matching cases. If the number of cases that meet the conditions is less than K, include all of them in the candidate matching cases to ensure that the selected cases are all highly relevant cases and avoid low similarity cases interfering with the matching results.

[0062] To further improve matching accuracy, a dispute type weighting coefficient is introduced. This coefficient is set based on the success rate of historical cases: for high-frequency dispute types such as returns and refunds, lost goods, and product quality, a differentiated weighting coefficient is set based on their historical success rates (e.g., the average success rate for returns and refunds is 95%, and for logistics delays it is 92%) (e.g., returns and refunds have a weight of 0.8, logistics delays have a weight of 0.7, and product quality has a weight of 0.9).

[0063] The specific weighted calculation rules are as follows: For each candidate case, calculate the weighted similarity value = cosine similarity value × weight coefficient of the corresponding dispute type; The candidate cases are sorted in descending order by weighted similarity values, and the subject corresponding to the case with the highest weighted similarity value is selected as the optimal matching subject for the current request. If multiple candidate cases have the same weighted similarity value, the subject corresponding to the case with the highest historical processing success rate is selected to improve the practicality and reliability of the matching results.

[0064] Taking a request regarding "a logistics delay involving a logistics service provider on a certain emerging Category I service platform" as an example: After precise matching fails due to the platform not having included the data, fuzzy matching extracts the feature vectors of "dispute type: logistics delay" and "logistics service provider: logistics service provider A". This feature vector is then compared with three highly similar historical cases in the case library (similar values ​​of 0.91, 0.88, and 0.86 respectively) to calculate a weighted similarity value. Finally, the case with the highest weighted value, corresponding to "the official after-sales service entity of logistics service provider A", is selected as the matching result, completing the precise connection of the entity. After matching the corresponding Category I entity, the associated connection interface information of that entity is extracted simultaneously. This connection interface information includes two core types of content: first, the service entity's contact identifier, such as the official customer service hotline, after-sales processing email, and WeChat account of the Category I service platform, used for manual synchronous feedback of the request information; second, the data interaction interface address, such as the after-sales work order API interface and order information query interface opened by the Category I service platform, used for automated data interaction between the request text data and the internal system of the Category I service platform.

[0065] Through the fully automated process of entity extraction, verification, and hierarchical matching described above, the output of the first type of subject and interface information can directly support the subsequent processing flow of the request. Actual testing shows that this step achieves a subject matching accuracy of over 98% for the first type of service request, with an interface information matching error of less than 0.5%. Compared to traditional keyword matching methods, the manual intervention rate is reduced by over 80%, significantly improving the processing efficiency of the first type of service requests.

[0066] S400, if the classification result is a second type of service request, perform multimodal feature fusion processing on the request text data to obtain a fused feature dataset; input the fused feature dataset into a preset multi-classifier, and output the corresponding second type of subject and associated interface information.

[0067] This step follows the binary classification result determination of S200 and is a dedicated processing flow for the second type of service scenario. Its core purpose is to integrate the semantic features, spatiotemporal features, historical association features, or domain knowledge features of the request text through multimodal feature fusion technology to construct a highly recognizable fusion feature dataset. Then, it accurately matches the corresponding subject, the second type of subject, and the associated interface information through a preset multi-classifier, thereby improving the shallow limitations of traditional keyword matching and achieving accurate distribution of the second type of service request.

[0068] For multimodal feature fusion processing, this invention provides two parallel implementation methods, which can be flexibly selected based on the historical data reserves and request type richness of the second type of service request, as follows: Implementation Method 1: Multimodal Feature Fusion Based on Historical Related Request Data This implementation method is applicable to the second type of service scenario with sufficient historical request data and relatively stable request types. The core lies in improving the accuracy of entity matching based on the processing rules of historical requests. The specific steps are as follows: S401, perform text enhancement processing on the request text data to obtain enhanced text; splice the enhanced text with the request title, request body content, spatial association data, and temporal association data to generate a spliced text containing complete context information.

[0069] Among them, performing text enhancement processing on the request text data includes performing enhancement processing such as text denoising, synonym replacement, and missing information supplementation on the original request text data.

[0070] The temporal association data includes the original timestamp when the request is submitted and the time dimension subdivision features. The time dimension subdivision features are divided into morning peak hours, working hours, evening peak hours, and non-working hours according to the business characteristics of the second type of service processing, which can assist in determining the urgency of the request and the processing window.

[0071] An exemplary splicing result is: "[Request title: Exemplary event status description][Request content: Exemplary environmental conditions lead to specific status changes in a certain area, affecting normal activities][Spatial association data: XX Community, XX Street, XX District, XX City][Temporal association data: 2025-07-10 08:30 morning peak hours]". This splicing result integrates the core semantic information (title and content) of the request, geographical level information (province / city / district / street / community), and refined time context (timestamp and period identifier) through structured fields, forming a standardized request record containing complete spatial, time, and event descriptions, providing a unified input format for subsequent feature extraction and classification determination.

[0072] S402, extract the TF-IDF features of the request text content in the spliced text, the one-hot encoding features of the spatial association data, and the one-hot encoding features of the request category to obtain a basic feature set.

[0073] Among them, the request text content in the spliced text consists of enhanced text, request topic, and request body content. The TF-IDF features are obtained based on the request text content in the spliced text. The core is to quantify the semantic importance of core business vocabulary. The specific steps are as follows: (1) Text preprocessing Perform Chinese word segmentation on the request text content in the spliced text, and use the Jieba word segmentation tool combined with the exclusive dictionary in the second type of service field to complete accurate word segmentation; at the same time,剔除 the general stop words in the second type of service scenario (such as words without business value like "的", "了", "请", "希望", etc.) to obtain a standardized word segmentation result.

[0074] (2) Term Frequency (TF) Calculation For the word segmentation results of a single request text, calculate the term frequency (TF) of each business term using the formula: TF wi =N wi / N total , among which, TF wi Let w be the word frequency of the i-th request text; N wi Let N be the number of times word w appears in the i-th request text; total Let be the total number of words in the i-th text.

[0075] (3 Inverse Document Frequency (IDF) Calculation) Based on a full corpus of second-type service request texts, the inverse document frequency (IDF) of each business term is calculated to quantify its discriminative power. If a term appears in most texts, its IDF value is low, indicating weak discriminative power; if it appears only in specific request types, its IDF value is high, indicating strong discriminative power. The formula is: IDFw = log(Nc / Nw), where IDFw is the IDF of term w; Nc is the total number of texts in the corpus; Nw is the number of texts containing term w; adding 1 to the denominator avoids a denominator of 0 when the term does not appear.

[0076] (4) TF-IDF feature vector generation Calculate the TF-IDF value of each business term and construct a fixed-length feature vector based on the vocabulary of the corpus; each dimension of the vector corresponds to a business term, and the dimension value is the TF-IDF value of that term in the current text, and finally generate the TF-IDF feature vector of the request text content.

[0077] Spatial association data is hierarchical geographic information (e.g., XX Province-XX City-XX District-XX Street-XX Community). The acquisition of one-hot encoded features aims to eliminate semantic ambiguity in geographic names. The specific steps are as follows: (1) Geographic information standardization The spatial association data in the request text is cleaned and standardized: First, the geographical names are standardized (e.g., "XX District XX Subdistrict Office" is standardized to "XX District XX Subdistrict"); second, missing hierarchical information is supplemented (e.g., when only "XX Community" is filled in, the city, district, and subdistrict are supplemented based on the geographic information database); third, invalid geographical information (e.g., vague expressions such as "nearby" and "surrounding area") is removed to obtain structured five-level hierarchical geographical information.

[0078] (2) Constructing a hierarchical geographical dictionary Based on the full geographical regionalization data, a hierarchical geographical dictionary is constructed, with each level (province, city, district, street, community) having its own independent vocabulary set. For example: District-level dictionary: {XX District, YY District, ZZ District...}; Street-level dictionary: {XX Street, AA Street, BB Street...}.

[0079] (3) Hierarchical unique heat coding Hierarchical coding of the standardized five-level geographic information is performed using a one-hot coding tool (such as sklearn.OneHotEncoder): For each level of geographical name, generate a binary vector with the same length as the dictionary for that level; If the requested geographic information contains a certain level of vocabulary, the corresponding vector dimension is assigned a value of 1, and the other dimensions are assigned a value of 0; for example, if XX district is ranked 3rd in the district-level dictionary, then the district-level encoding vector is [0,0,1,0,……,0].

[0080] (4) Concatenate to generate spatial feature vectors The one-hot encoded vectors of the five levels of province, city, district, street and community are concatenated in sequence to form a spatial correlation data one-hot encoded feature vector with fixed dimensions. This vector can be directly identified by multi-classification models to accurately locate the jurisdiction to which the request belongs.

[0081] The one-hot encoding features of request categories are obtained based on a pre-defined request classification system and are used to construct discrete features of request types. The specific steps are as follows: (1) Determine the request classification system Based on the functional division of the main body, a standardized request classification system is pre-defined, divided into primary categories and secondary categories, as exemplified below:

[0082] (2) Request text preclassification The enhanced request text is pre-classified using a "keyword matching + rule-based judgment" approach. Constructing a category keyword dictionary based on a classification system; Calculate the keyword matching degree between the request text and each secondary category, and the category with the highest matching degree is the pre-classification result of the request; Requests with a matching accuracy below a preset threshold (e.g., 0.6) are marked as "awaiting manual review" to ensure classification accuracy.

[0083] (3) Construct a category dictionary and encode it. Based on the preset secondary request categories, construct a complete category dictionary; One-hot coding is used to encode the pre-classification results: Generate a binary vector with the same length as the category dictionary; If the requested preclassification result is a certain second-level category, then the corresponding vector dimension is assigned a value of 1, and the other dimensions are assigned a value of 0.

[0084] (4) Generate request category feature vector The binary vector obtained by one-hot encoding is directly used as the one-hot encoded feature vector of the request category. This vector can clearly represent the business type to which the request belongs, providing a category basis for subsequent accurate distribution.

[0085] After the three types of features are obtained, the feature vectors need to be normalized (e.g., using Min-Max normalization to map the feature values ​​to the [0, 1] interval) to eliminate the dimensional differences between different feature dimensions, and then be assembled in order into a basic feature set with a unified dimension.

[0086] S403, the basic feature set is fused with the historical associated request data features to obtain the fused feature dataset.

[0087] The historical associated request data features include two core dimensions: first, the historical request processing record features of the same associated subject, namely the regularity features of the request type, subject, and processing result of the request submitting subject in the past; second, the processing record features of the same type of request in the same spatial range, namely the subject matching record and processing success rate of historical requests in the same region and of the same type as the current request.

[0088] The fusion method uses feature dimension concatenation + weight assignment: fields in historical features that have a high degree of matching with the current request (such as the main matching records of the same type of request in the same region) are given higher weights (such as a weight coefficient of 1.2) to strengthen the guiding role of historical patterns in the current distribution task; finally, a fused feature dataset containing semantics, spatiotemporal, and historical patterns is generated.

[0089] Implementation Method 2: Multimodal Feature Fusion Based on Event Semantic Graph This implementation method is suitable for the second type of service scenario, characterized by a large number of emerging request types and frequent updates to business rule sets. Its core is to leverage domain knowledge graphs to mine deep semantic relationships between requests, overcoming the limitations of historical data. This implementation method requires first constructing an event semantic graph, and then performing multimodal feature fusion based on the graph. Preliminary step: Event semantic graph construction This step provides core knowledge support for feature fusion based on event semantic graphs. Through deep semantic mining of the second type of service request text, a structured knowledge graph containing business logic, business rule basis, and processing associations is constructed. The specific process is as follows: Step 1: Extract concepts from the request text data corresponding to the second type of service request using the domain adaptive large model, and extract the core elements of the event and the logical relationships between the elements.

[0090] A domain-adaptive large-scale model is used to accurately extract concepts from the full dataset of second-type service request text data. This model is fine-tuned based on domain-specific corpora for second-type services (such as request event handling cases, business rule sets, and lists of main responsibilities) to enhance its ability to identify core elements of second-type service scenarios. The extracted core elements are divided into three categories: The core elements of an event are the specific business objects to which the request points, such as "state A", "scenario B", "impact C", "transaction D", etc. Main elements: These correspond to the second type of subject, such as "Unit A", "Unit B", "Unit C", etc. Business rule set elements: These are the business rules that support request processing, such as "Related Domain Rule Document A", "Specific Domain Management Specification B", "Special Service Handling Specification C", etc. Step 2: Based on the core elements and logical relationships of the event, perform relationship modeling to construct an event semantic graph.

[0091] First, based on the extracted core elements, logical relationships between elements are constructed, and the association attributes and weights of different elements are clarified, specifically including: Business processing association: The correspondence between core elements of an event and main elements (e.g., "State A" → "Unit A (weight 0.8), Unit B (weight 0.2)"). Business rules support association: the correspondence between core elements of an event and elements of the business rule set (e.g., "impact C" → "related domain rule B"); Scenario extension and association: The relationship between core elements of similar events (e.g., "specific condition state A" → "derived state B" → "specific response process C").

[0092] Next, based on the above elements and relationships, a structured event semantic graph is constructed. The event semantic graph includes domain knowledge relationships of service request events, business rule sets, and emergency scenarios. The nodes of the graph are the core elements, main elements, and business rule set elements of the event. The node attributes include element definition, frequency of occurrence, processing priority, etc. The edges of the graph are the logical relationships between elements. The edge attributes include association weight, confidence level, business rule basis, etc., forming a complete knowledge system of elements-relationships-knowledge.

[0093] Multimodal feature fusion based on graphs specifically includes the following steps: S410, perform text enhancement processing on the request text data to obtain enhanced text; concatenate the enhanced text with the request title, request body content, spatial association data and temporal association data to generate concatenated text containing complete context information; the temporal association data contains time dimension subdivision features.

[0094] Consistent with the text enhancement processing logic of S401, the added text, request title, request body content, spatial correlation data, and temporal correlation data are structurally concatenated to generate concatenated text containing complete contextual information, providing a foundation for subsequent feature extraction.

[0095] S420: Extract the TF-IDF features of the request text data, the one-hot encoding features of the spatial correlation data, and the one-hot encoding features of the request category from the concatenated text to obtain the basic feature set.

[0096] Consistent with the feature extraction logic of S402, TF-IDF features of request text data, one-hot encoding features of spatial correlation data, and one-hot encoding features of request categories are extracted from the concatenated text to form a structured set of basic features.

[0097] S430, based on the event semantic graph, semantically expand the core event elements in the request text content of the concatenated text to generate element association features. The specific process is as follows: Extraction of core elements of the event: Extract the core elements of the current request from the request text content in the concatenated text, such as "specific condition status A", "specific location B", and "potential risk C"; Graph Knowledge Retrieval and Association: Inputting the extracted core elements into the event semantic graph triggers multi-dimensional knowledge retrieval. Retrieve the corresponding main elements: "Specific condition state A" → "Unit A (weight 0.8), Unit B (weight 0.2)" Retrieve the corresponding business rule set elements: "Specific condition status A" → "Related domain rule document A, Article XX"; Retrieve the corresponding scenario extension elements: "Specific location status A" → "Specific emergency handling process C".

[0098] Numerical Feature Vector Generation: This process transforms retrieved association knowledge into numerical feature vectors representing element associations. These vectors contain the following dimensions: The correlation weight between core elements and the main body; The degree of matching between core elements and the set of business rules; Emergency response priorities corresponding to core elements; Ultimately, a fixed-dimensional feature vector of related elements is generated, realizing the transformation of unstructured domain knowledge into structured features.

[0099] S440, the basic feature set and the element association features are spliced ​​and fused to obtain the fused feature dataset.

[0100] During the assembly process, differentiated weights (such as a weight coefficient of 1.2) are assigned to the feature vectors associated with elements to strengthen the guiding role of domain knowledge in distribution decisions. The final fused feature dataset contains semantic features, spatiotemporal features, business category features of the request, as well as responsibility association features, business rule matching features, and priority features based on knowledge graphs. This can effectively solve the problem of distribution difficulties caused by the lack of historical data for emerging requests.

[0101] In one illustrative embodiment, the fused feature vector FM corresponding to the fused feature dataset satisfies the following condition: , of which F r This is the original feature vector of the r-th class. For example, textual semantic features come from the domain large model encoding, spatial features come from GIS coordinate encoding, and temporal features come from the work order submission timestamp encoding. The value of r ranges from 1 to D, where D is the number of feature types. D=3 corresponds to textual semantic features F1, spatial location features F2, and temporal features F3; WB r The basic weights for the r-th class features are derived from the feature contribution Contrib. r Normalization yields Contrib r The contribution value of this feature to the improvement of distribution accuracy is obtained through training a domain-adaptive large model, c. r Let c be the domain fit coefficient of the r-th feature. r =1+λ·Sim(F r G), where G is the domain knowledge graph, and Sim(F) is the domain knowledge graph. r G) represents F r The semantic similarity between G and G, ranging from 0 to 1, is calculated using the cosine similarity between the feature vector and the graph node vector. λ is the domain adaptation strength factor, ranging from 0.1 to 0.5, calibrated through training with domain samples.

[0102] In this invention, the domain knowledge graph is a static, structured, and general knowledge system built for the second type of service request processing scenario. Its core is to integrate core entities, entity attributes, and logical relationships between entities within the domain through semantic association, forming a low-level knowledge network covering subjects, responsibilities, rules, and transactions, providing standardized knowledge support for subject matching in the second type of service requests. This domain knowledge graph possesses the following technical features: Static universality: The knowledge content is pre-built based on domain business specifications and standard documents, and does not change with a single request event, which can support the processing needs of all types of second-class service requests; Authoritative and Compliance: The division of responsibilities and rule provisions in the graph are all derived from structured publicly available domain data, ensuring that the subject matching process has a traceable rule basis; Structured association: Breaking through the limitations of traditional unstructured documents, it transforms scattered domain knowledge into a "entity-relationship-attribute" triple structure, supporting efficient semantic retrieval and matching calculation.

[0103] The core components of a domain knowledge graph include three types of core elements: Core entities: participating entities, business objects, rule documents, etc. For example, entities (unit A, unit G), request types, and rule documents (relevant domain rule document A).

[0104] Entity attributes: Key information describing the characteristics of an entity. For example, for Unit A, attributes include: responsible area and core responsibilities; for business rule attributes, attributes include: effective time and scope of application.

[0105] Relationships: Logical relationships between entities, for example, unit A → responsibility → maintenance of specific area status; domain rule document A → applicable events → specific condition status requests.

[0106] The construction of a domain knowledge graph follows a complete process logic of "demand-driven - data integration - knowledge processing - storage and maintenance", with the specific steps as follows: 1. Build requirements and data source analysis Demand Anchoring: Define the core service objectives of the graph, support subject matching of requests, rule compliance verification and rule mapping, and determine the knowledge coverage of the graph, including five core dimensions: subject, responsibility description, rule text, request type, and regional scope.

[0107] Multi-source data acquisition: Integrating authoritative data sources in relevant fields, specifically including: Authoritative and publicly available data sources: functional description documents, function lists, rule sets, and regional division documents from relevant units; Historical business data: historical work order data, main processing records, and business processing manual; Industry standard data: Big data classification standards, request event classification and coding specifications in related fields.

[0108] 2. Knowledge Extraction: Extracting core elements from unstructured data. A hybrid approach combining rule extraction and domain-adaptive model extraction is employed to extract knowledge elements from multi-source data. Entity extraction: Based on a domain dictionary (such as a dictionary of relevant unit names and a dictionary of request types), and combined with the BERT domain-adaptive model, core entities such as relevant units, rule files, and request types are extracted from the text; Relationship extraction: Identify the relationships between entities by using rule templates (such as "XX unit is responsible for XX affairs") and deep learning models (such as the BERT relation extraction model); Attribute extraction: Extract key attributes of entities from structured forms (such as job list tables) and unstructured text (such as rule clauses), such as the "responsible area" and "interface identifier" of relevant units, and the "effective time" and "division of responsibilities" of rule documents.

[0109] 3. Knowledge Integration: Eliminating ambiguity and achieving knowledge standardization. To address the heterogeneity and redundancy of multi-source data, knowledge cleaning and fusion are performed to ensure the consistency of the knowledge graph. Entity disambiguation: unifying different representations of the same entity, such as merging "Unit A" and "Unit H" into the same entity and assigning it a unique code; Relationship standardization: Based on domain rules, define standardized relationship types, such as classifying "responsible for" and "undertaken" as "responsibility association" relationships; Conflict resolution: For contradictory attributes of the same entity (such as different descriptions of the functions of a unit in different documents), the latest authoritative description of the functions is used as the benchmark for correction.

[0110] 4. Knowledge Storage: Constructing an efficient and queryable knowledge graph structure The storage architecture adopts a "graph database as the primary database and relational database as the secondary database" approach, balancing the semantic association capabilities of the graph with query efficiency. Graph database storage: Store "entity-relationship-attribute" triples in graph databases such as Neo4j and JanusGraph, supporting efficient semantic path queries; Relational database storage: Store the basic attributes of entities (such as unit code, business rule number) in relational databases such as MySQL for fast attribute retrieval and data association.

[0111] 5. Knowledge updates and maintenance: Ensuring the timeliness of the map. Due to dynamic changes in the relevant system, such as unit adjustments and revisions to business rules, a dual maintenance mechanism of regular updates + triggered updates is established: Regular updates: Review relevant functional adjustment documents and newly released business rules on a quarterly / annual basis, and update entity attributes and relationships in the graph in batches; Triggered Updates: When manual feedback on adjustments to the responsibilities of relevant units is received (such as unit merger information submitted by the operation and maintenance terminal), a partial update of the map is immediately triggered to ensure the accuracy of subject matching.

[0112] In the request processing technical solution of this application, the domain knowledge graph plays a core role in providing underlying knowledge support: It provides a domain knowledge benchmark for S440 multimodal feature fusion, and obtains the domain adaptation coefficient by calculating the semantic similarity between request features and the graph, thereby improving the fit of the fused features to the second type of service scenarios. It provides a basic data source for the dynamic generation of event semantic graphs. When a specific request event is received, it retrieves relevant responsibilities and business rules from the domain knowledge graph to quickly build a dedicated semantic graph for that event.

[0113] The aforementioned fusion feature generation method differs from the traditional fixed-weighted summation model. It introduces a dynamic weight allocation mechanism driven by feature contribution and incorporates domain knowledge into the feature fusion process using a domain adaptation coefficient. This method enables the final generated fusion features to more accurately adapt to the scenario requirements of second-type service request distribution processing. It helps improve the limited generalization ability and insufficient domain adaptability of existing technologies in multimodal feature fusion, thereby enhancing the representation accuracy of second-type service request features. After generating the fusion feature dataset through the above steps, it is input into a preset multi-classifier. Based on the high-discrimination semantics and scenario information of the fusion features, the multi-classifier outputs the corresponding second-type subject and associated interface information, completing the accurate distribution processing of second-type service requests.

[0114] Furthermore, the construction process of the preset multi-classifier includes: S10, filter the request text data corresponding to the second label, use the second type of subject that has been actually processed in history as the label, filter the label categories with a sample number greater than the preset threshold, and obtain the initial training dataset.

[0115] The core objective of this step is to construct high-quality supervised training samples to ensure that the model can learn the request matching patterns of various types of second-class subjects. Specific details are as follows: Label alignment: Clearly define "second label" as "second type of service request" and "second type of subject" as the second type of subject (such as unit A, unit B, unit C, etc.) to ensure that the terminology is completely consistent with the preceding text; Sample selection logic: The preset quantity threshold is set according to the principle of "ensuring the distinguishability of categories". For example, the threshold is set to 50, that is, only the second main category with ≥50 samples is retained, and the niche categories with too few samples (such as special special processing departments) are removed to reduce the impact of sample scarcity on model learning and thus reduce the distribution bias. Data cleaning and supplementation: During the screening process, invalid data (such as records with missing request text or unclear historical subject labels) are removed simultaneously, and the initial training dataset with "request text data - second type of subject label" is finally obtained.

[0116] S11, Perform multimodal feature fusion processing on the initial training dataset to obtain a fused feature dataset for training.

[0117] This step requires ensuring that the feature fusion strategy during the training phase is completely consistent with that in the subsequent inference phase (S400) to guarantee the adaptability of model training and inference: Fusion strategy matching: Based on the actual application scenario, select one of the two multimodal feature fusion implementation methods described in S400 above (fusion based on historical associated request data / fusion based on event semantic graph). Consistency Guarantee: Use the exact same feature extraction parameters as in the inference stage (such as TF-IDF vocabulary, one-hot encoding dictionary, feature vector dimension) to avoid model performance deviations caused by parameter differences; Output: The final result is a training fusion feature dataset with uniform dimensions and standardized format. Each sample in the dataset contains the correspondence between "fusion feature vector - second type subject label".

[0118] S12, Based on the training fusion feature dataset, train a preset multi-classification model; during the training process, increase the class weight of label categories whose sample proportion is lower than the preset proportion threshold, and use a comprehensive classification performance evaluation index to optimize the model.

[0119] The core of this step is to address the class imbalance problem of the second type of subject samples and improve the model's recognition accuracy for niche categories (subjects corresponding to low-frequency requests). Specific details are as follows: Multi-classification model selection and strategy: The multi-classification model adopts the "One-vs-Rest" strategy of Linear Support Vector Classifier (LinearSVC) or Stochastic Gradient Descent Classifier (SGDClassifier) ​​model; the "One-vs-Rest" strategy decomposes "multiple second-class subject classification" into multiple "binary classification tasks", which is suitable for scenarios with a large number of second-class subject categories and can clearly define the classification confidence of each category; Category imbalance optimization: A preset percentage threshold is set to 5% for example. If the sample percentage of a certain second-category main category is less than 5%, the weight of that category is increased through the category weight parameter. This allows the model to focus more on niche category samples during training, preventing the model from favoring the mainstream category with a large sample size. Specific weight adjustment methods include automatic balancing and manual fine-tuning, which can be flexibly selected based on the category distribution characteristics of the second-category service requests.

[0120] 1. Automatic load balancing strategy (recommended for the second type of service scenario) In one illustrative embodiment, a balanced strategy can be used, assigning weights inversely proportional to the sample proportion. The core formula is: w k =N total / N k ×M. Where: w k N represents the weight of the k-th second-class subject category, where k ranges from 1 to M, and M is the total number of second-class subject categories; total N represents the total number of samples in the training dataset. k Let be the number of samples in the k-th second-class subject category; Example calculation: If the total number of samples in the training set is N total =10000, total number of categories M=10, sample size N of a niche category (e.g., "Unit I") k =500 (5% of the total, lower than the preset percentage threshold of 5%), then the weight w of this category is... k =10000 / (500×10)=2; while the sample size N of the mainstream category (such as "Unit A") k =3000, weight w k =10000 / (3000×10)≈0.33. Using this strategy, the model automatically amplifies the weight of niche categories and reduces the weight of mainstream categories when calculating the loss function, preventing the model from favoring categories with larger sample sizes.

[0121] 2. Manual fine-tuning strategy (adapted to extreme imbalance scenarios) For niche categories with extremely low sample percentages (such as the second category with a percentage of <2%), the weights are further manually increased based on the automatic balancing strategy. The specific rules are as follows: Sample percentage ≥ 5% (preset percentage threshold): Weight = value calculated by automatic balancing strategy; For samples with a percentage of 2% or less but less than 5%, the weight is calculated as 1.5 times the value calculated by the automatic balancing strategy. Sample percentage < 2%: Weight = Automatic balancing strategy calculated value × 2.0.

[0122] Example adjustment: The weight of "Unit I" (5% of the total) is 2. If a certain category accounts for 1%, then the weight = (10000 / (100×10))×2=20, which further strengthens the model's learning of the most niche categories.

[0123] During model training, the weight parameters are passed to the multi-class classification model (linear support vector classifier / stochastic gradient descent classifier) ​​through the category weight parameters, and the recall rate of the niche category is monitored by 5-fold cross-validation. If the recall rate of the niche category increases by less than 5% after weight adjustment, the weight coefficients are iteratively adjusted until the expected result is met.

[0124] Hyperparameter and evaluation optimization: The model hyperparameters (such as the regularization parameter C of the linear support vector classifier and the learning rate of the stochastic gradient descent classifier) ​​are optimized by using grid search combined with 5-fold cross-validation. The comprehensive classification performance evaluation index is defined as "macro average F1 score, micro average F1 score, accuracy, and recall", with the macro average F1 score as the core optimization index. This comprehensive classification performance evaluation index can reflect the classification performance of each category (especially niche categories) in a balanced way, which meets the business requirement of accurate and complete classification of all categories in the second type of service distribution.

[0125] S13, Select historical request text data and corresponding actual processing record data as test dataset, and verify the performance of the trained multi-classification model based on the test dataset. Use the multi-classification model whose performance verification results meet the preset requirements as the preset multi-classifier.

[0126] This step verifies the model's generalization ability using an independent test dataset, ensuring the model's stability and reliability in real-world scenarios. Specific details are as follows: Test dataset construction: The test dataset is independently extracted from the historical second type of service request data, with no overlap with the training dataset, and follows the principle that the category distribution is consistent with the real business scenario (such as the proportion of mainstream categories and niche categories being the same as the actual request distribution). For example, it is divided according to the ratio of "training set: test set = 7:3". Performance Verification Standards: The preset requirement is that the values ​​of all evaluation indicators in the comprehensive classification performance assessment must be greater than the corresponding preset thresholds. Specific threshold settings are formulated in conjunction with the business objectives of distributing second-category service requests. Example thresholds are as follows: Core indicator macro average F1 score ≥ 0.92 (ensuring overall classification accuracy across all categories); overall classification accuracy ≥ 0.90 (ensuring accurate distribution of mainstream categories); recall rate of all second-category main categories ≥ 0.85 (ensuring no niche category requests are missed). The threshold settings for these indicators balance overall classification accuracy and niche category coverage. This avoids both excessive pursuit of overall accuracy leading to missed distribution of niche category requests and sacrificing the classification effect of mainstream categories by focusing on niche categories, thus meeting the core business requirement of accurate distribution and no omissions in the second-category service request distribution.

[0127] Model selection and iteration: If the trained model does not meet the preset requirements, return to S12 to adjust the hyperparameters or class weight coefficients and retrain and verify; if it meets the preset requirements, the model is determined to be a candidate multi-classifier at the algorithm level. After final confirmation that it is adapted to the production environment deployment requirements of the second type of service request distribution, it is officially put into use as the preset multi-classifier.

[0128] Furthermore, to achieve the engineering implementation of the multi-classifier in the second type of service request processing system, after the multi-classifier is trained and passes performance verification, the process of model solidification, format conversion, and service deployment is executed, as follows: (1) Solidification and preservation of models and related tools The Joblib tool was used to persistently save the model and its components. The saved content includes: The trained multi-classifier model (linear support vector classifier / stochastic gradient descent classifier); The TF-IDF vectorizer (TfidfVectorizer) that accompanies the model is the core tool for TF-IDF feature extraction of request text. Its vocabulary, feature dimensions, stop word list and other configuration parameters need to be saved synchronously to ensure that the feature extraction logic in the inference stage is completely consistent with that in the training stage. Auxiliary configuration file: contains a mapping table between the second type of main body labels and unique identifiers, feature dimension descriptions, and category weight configuration records to avoid problems such as feature dimension mismatch and label parsing errors during the inference stage.

[0129] (2) Model cross-language format conversion To adapt to the mainstream Java or Go language inference environment of the second type of service system (rather than the Python environment during the training phase), the saved multi-classifier model is converted to the Open Neural Network Exchange (ONNX) format using the sklearn-onnx tool (Scikit-learn to ONNX conversion tool) or the sklearn-porter tool (Scikit-learn model conversion tool): Before conversion, model compatibility needs to be verified: ensure that the hyperparameters and feature input dimensions of the multi-classifier match the conversion rules of the ONNX format to avoid distortion of the model's inference logic after conversion; After conversion, a consistency check is performed: 100 test samples are selected and inferred in the native Python model and the ONNX format model respectively. The difference rate of classification results and confidence scores is required to be ≤0.5% to ensure that the converted model has the same performance as the original model.

[0130] (3) Model service deployment and output specifications Deploy the converted ONNX format model as a RESTful microservice to adapt to the distributed deployment architecture of the second type of service system. Specific requirements are as follows: Deployment framework: RESTful interfaces are built using FastAPI or SpringBoot (adapted to Java environment) / Gin (adapted to Go environment), supporting HTTP / HTTPS protocol calls, with interface response latency ≤50ms (meeting the real-time distribution requirements of the second type of service requests); Service output format: Adopts the standardized JSON format, containing the following core fields to ensure compatibility with downstream modules of the second type of service processing system: Classification result: Secondary category of the second type of service request; The second type of entity's unique identifier: the standardized code of the second type of entity (such as the unit A code "010502"), which is compatible with the entity ledger of the second type of service system; Confidence score: A value in the range of 0-1, representing the confidence level of the model classification result (e.g., 0.98). A score ≥0.85 is directly distributed, and a score <0.85 triggers manual review.

[0131] To verify the actual processing performance of the multi-classifier in this solution, 26,602 anonymized historical data entries of real second-category service requests were selected as an independent test set (the acquisition and use of this test set comply with relevant data security and personal information protection laws and regulations, and have been authorized accordingly). Full-dimensional performance tests were conducted on the multi-classifiers trained using the LinearSVC algorithm and the SGDClassifier algorithm. Test results show that both models achieve an overall matching accuracy of approximately 96% for the second-category subjects, which can meet the business requirements for accurate matching of second-category service requests. Specific test data is as follows: 1. LinearSVC classifier test results

[0132]

[0133] 2. SGDClassifier Classifier Test Results

[0134]

[0135] Note: The main numbers in the table are for illustrative purposes only; in actual applications, they correspond to specific codes.

[0136] The test results above show that: Overall Performance: Test results show that both LinearSVC and SGDClassifier models achieved an overall distribution accuracy of 0.96, with weighted average precision, recall, and F1 score also all at 0.96. This demonstrates that both models exhibit stable and consistent classification performance in the second-type service request distribution scenario, meeting the core business requirement of high-accuracy distribution. Distribution Performance for Mainstream Subjects: For core second-type subjects with sufficient sample size, the model's precision and recall metrics are both no less than 0.95, indicating that its distribution accuracy for high-frequency requests is close to perfect matching, reliably distributing most second-type service requests to the correct subjects.

[0137] Niche Subject Matching Performance: For subject categories with smaller sample sizes, the model maintained a high distribution precision (no less than 0.94), effectively controlling the misclassification rate. Although its recall rate was lower than that of mainstream categories, it remained at an acceptable level. This performance characteristic aligns with the core business requirement of "prioritizing distribution accuracy and strictly controlling distribution errors" in the second type of service scenario. Model Performance Analysis: The LinearSVC model exhibits better precision when handling niche categories, while the SGDClassifier model shows a slightly higher recall rate for specific subjects (such as "subject 12 in the second category"). Both models can achieve an overall distribution accuracy of approximately 96%, providing an objective performance basis for model selection under different business priorities (precision-first or recall-first).

[0138] Furthermore, in S400, the step of inputting the fused feature dataset into a preset multi-classifier and outputting the corresponding second-type subject and associated interface information is essentially about improving the accuracy of second-type service distribution through a dual mechanism of model prediction and knowledge graph verification. Specifically, this includes the following sub-steps: S441, input the fused feature dataset into a preset multi-classifier and output the corresponding second-class subject candidate result.

[0139] The fused feature dataset is input into a pre-defined multi-classifier (a RESTful microservice after engineering deployment). Based on the semantic, spatiotemporal, and domain knowledge features of the fused features, the model outputs multiple candidate results for the second type of subject and their corresponding initial confidence scores. The specific output format is as follows: Candidate results list: contains 2-3 second-class subjects with the highest matching degree (such as "Unit A" "Unit G"); Initial confidence score: The confidence level of each candidate subject (a value in the range of 0-1), directly output by the multi-classifier, reflecting the degree of feature matching at the model level; Auxiliary information: Standardized category labels corresponding to candidate entities, used for subsequent graph query association.

[0140] S442, query the domain knowledge association relationship between the candidate results and the event semantic graph.

[0141] Based on the candidate subjects and auxiliary category labels output by S441, the event semantic graph constructed above is queried to extract domain knowledge relationships strongly associated with the candidate results. The core query content includes three types of core information: The scope of responsibilities of candidate entities is related: for example, the core responsibilities of "unit A" such as "handling specific states and maintaining related facilities"; The request category is associated with the candidate entity's historical processing history: for example, under the category of "specific status processing, related facility maintenance", the historical processing success rate and matching frequency of "Unit A"; Business rule sets are appropriately matched and associated: such as the division of responsibilities of the main body clearly defined in the business rule basis for "specific status processing and related facility maintenance" (such as "relevant field rule document A" clearly states "unit A is responsible for the status processing of a specific area").

[0142] The query generates a mapping table of "candidate subject - domain knowledge association relationship", which provides a basis for subsequent adaptation verification.

[0143] S443, the association fit of the candidate results is verified based on the domain knowledge association relationship to obtain the comprehensive fit of each candidate result, and the confidence score of each candidate result is adjusted based on the comprehensive fit, and the second type of subject and associated interface information with the best confidence score is output.

[0144] The core logic of the association compatibility verification is as follows: using the second type of service domain knowledge (responsibilities, business rules, historical data) in the event semantic graph as an objective basis, the compatibility assessment is completed for the candidate subjects output by the multi-classifier by first quantifying the dimensions and then summarizing them comprehensively. This ensures that the verification results meet the core requirements of the second type of service distribution responsibility coverage, business rule compliance, and effective processing. The specific process is as follows: 1.1 Pre-verification: Clarify basic inputs and core criteria Core inputs: a list of candidate entities output by the multi-classifier (e.g., "Unit A" "Unit G"), and the initial confidence score of each candidate entity; Verification criteria: Three core domain knowledge categories retrieved from the event semantic graph: ① List of legal responsibilities of candidate entities; ② Set of business rules (including division of responsibilities) matching the current request; ③ Historical processing records of similar requests (including processing success rate). Preset rules: Pre-set the three-dimensional verification weights (responsibility matching degree 0.5, business rule adaptability 0.3, historical processing adaptability 0.2) and the comprehensive adaptability screening threshold (≥0.6) to ensure that the verification standards are uniform and reusable.

[0145] 1.2 Dimensional Quantitative Verification (Core Step) Following the priority order of "Responsibilities → Business Rules → History", each dimension was quantitatively scored (with a maximum score of 1.0). The verification of each dimension relied on the event semantic graph to achieve objective evaluation. Dimension 1: Job Responsibility Matching Verification (Weight 0.5) Logic: Determine whether the legal responsibilities of the candidate entity cover the core requirements of the current request; Steps: ① Parse the core request requirements from the enhanced text content (e.g., "restoration of functional status of a specific area"); ② Retrieve the responsibility nodes of candidate subjects in the event semantic graph (e.g., "Unit A → maintenance of status of a specific area"); ③ Quantify the score according to the rules of "complete match (1.0 point), partial match (0.6-0.9 points), no match (0.0-0.5 points)" (the matching basis is the "responsibility-request keyword mapping relationship" predefined in the graph).

[0146] Dimension 2: Business rule compatibility verification (weight 0.3) Logic: Verify whether the candidate entity conforms to the clearly defined division of responsibilities in the business rule set to ensure the legitimacy of service request distribution; Steps: ① Retrieve the business rule clauses corresponding to the request in the event semantic graph (e.g., "Related domain rule document A"); ② Extract the main division of labor in the clauses (e.g., "A certain department is responsible for handling specific types of status"); ③ Quantify the score according to the rules of "clear subject (1.0 point), collaborating subject (0.5-0.8 points), no related responsibility (0.0-0.4 points)".

[0147] Dimension 3: Historical processing adaptability verification (weight 0.2) Logic: Based on historical data, determine the actual ability of candidate entities to handle similar requests to ensure effective distribution; Steps: ① Retrieve historical processing records of similar requests in the event semantic graph; ② Calculate the historical processing success rate of candidate subjects (number of successful cases / total number of processed cases); ③ Directly use the processing success rate as the score for this dimension (e.g., a success rate of 96% would result in a score of 0.96).

[0148] 1.3 Summary of Overall Adaptability The three-dimensional scores are weighted and summed according to preset weights to obtain the comprehensive suitability score for each candidate subject. The formula is as follows: Overall fit score = Responsibility matching degree × 0.5 + Business rule fit × 0.3 + Historical processing fit × 0.2.

[0149] Then, the selection is based on a preset threshold (≥0.6): candidates with a score ≥0.6 are retained, and those <0.6 are directly removed (determined to be insufficiently adaptable and unable to meet the distribution requirements).

[0150] The comprehensive fit score of each candidate subject obtained through the above-mentioned correlation fit verification is the core basis for subsequent confidence adjustment. The verification stage selects candidate subjects with qualified fit, and the adjustment stage corrects the initial confidence of the model based on the comprehensive fit, ultimately achieving the dual guarantee of algorithm prediction + business knowledge calibration.

[0151] In this invention, the core logic of confidence adjustment is to correct the initial confidence of the multi-classifier output with the comprehensive fit score, weaken the bias of pure algorithm prediction, and allow the final confidence to reflect both feature matching degree (model level) and business fit degree (domain knowledge level). The specific process is as follows: 2.1 Calculation of final confidence level In one illustrative embodiment, the final confidence score for each retained candidate subject is calculated using a modified formula of "initial model confidence score × overall fit score", as follows: C u =C initial ×S. Where C u C represents the final confidence score of the candidate subject after dynamic correction. initial S represents the initial confidence score output by the multi-classifier, and S represents the overall fitness score.

[0152] In another illustrative embodiment, to adapt to the dynamic adjustment requirements of candidate subjects in the second type of service scenario, a dynamic state correction factor γ for candidate subjects is introduced to optimize the correction formula, specifically as follows: .

[0153] The value of the candidate subject's dynamic state correction factor is dynamically calculated based on the candidate subject's current state. The specific calculation rules are as follows: .

[0154] Where b is the state influence coefficient, ranging from 0.1 to 0.3, dynamically adjusted by historical candidate entities during case training calibration, used to quantify the influence intensity of different states on confidence; U is the current state identifier of the candidate entity, U=1 indicates a new state, U=2 indicates a merged state, U=3 indicates a normal state, and U=4 indicates a responsibility adjustment state; A is the number of similar work orders already undertaken by the candidate entity in the new state; A total γ1 represents the average number of work orders received by core candidate entities of the same type, used to assess the business adaptation maturity of the new entity; γ2 and γ1 are the historical status correction factors of the two original candidate entities participating in the merger under the merged state (i.e., the γ values ​​of the two entities before the merger); Δt is the time span (in days) after the candidate entity completes the responsibility adjustment; T is the adaptation period threshold after the responsibility adjustment (default 90 days), during which the negative impact of the status on the confidence level is gradually reduced.

[0155] In this invention, a work order is a standardized processing document generated based on request text data after classification, feature extraction, and subject matching. Its core information originates from the analysis results of the request text data and is used to support the subsequent distribution, flow, and processing tracking of requests. The "new" status refers to a newly established second-category service candidate entity that is accessing this request processing system for the first time (such as a newly added second-category service center or a newly established department after functional transfer); the "merged" status refers to two or more existing candidate entities being integrated into a new entity (such as "Unit A" and "Unit D" being merged into "Unit G"). The two units before the merger refer to the two original second-category entities participating in this integration; the "normal" status refers to a candidate entity whose scope of responsibility and organizational structure remain unchanged and is in a state of routine business operation; the "responsibility adjustment" status refers to a candidate entity whose core responsibilities have been added, reduced, or transferred, but whose organizational structure has not been merged or split.

[0156] This embodiment quantifies the impact of candidate subject dynamic state on distribution confidence by introducing a candidate subject dynamic state correction factor, achieving flexible adaptation to dynamic scenarios such as addition, merging, and responsibility adjustment. It solves the core pain point of existing technologies where distribution models rely on fixed candidate subject information, making it difficult to adapt to the dynamic adjustments of second-type service units. It can quickly address candidate subject state changes without model reconstruction, reducing system iteration and maintenance costs.

[0157] 2.2 Optimal Candidate Selection and Backup Mechanism Optimal result selection: Sort the remaining candidate entities in descending order of final confidence score, and select the entity with the highest score as the optimal second-class entity; simultaneously extract the associated interface information of the entity (such as service hotline, work order API, standardized code).

[0158] The fallback mechanism is triggered if either of the following two extreme situations occurs: ① All candidate subjects have an overall fit score of <0.6 (no qualified candidates); ② The remaining candidate subjects have a final confidence score of <0.5 (qualified candidates but insufficient credibility). In this case, the request will be marked as "awaiting manual review" and a complete verification detail will be output (including the three-dimensional scores, overall fit, and initial / final confidence scores of each candidate subject) to provide a comprehensive basis for manual decision-making.

[0159] S500: Output the unique identifier of the first type of subject or the second type of subject and the corresponding interface information to complete the processing of the request text data.

[0160] If the request text data has been matched to the first type of subject after preprocessing, or the optimal second type of subject has been determined after S400 processing (final confidence level ≥ preset fallback threshold), then the unique identifier of the corresponding subject (such as the standardized code of the second type of service) and the standardized interface information (including service contact identifier, work order interface API address, and data interaction protocol specification) are directly output. The unique identifier of the subject and the standardized interface information are integrated with the original request text data to complete the processing of the request text data and generate a complete work order.

[0161] If the final confidence score of the optimal second-class subject output by the multi-classifier is lower than the preset threshold (such as ≥0.5 set in S443 above), a manual intervention fallback process is triggered. Specifically, the top N candidate second-class subjects (N≥2, the specific value can be configured according to the operational efficiency requirements of the second-class service) and the final confidence score corresponding to each candidate second-class subject are output. The candidate list, confidence score details, and the previously verified dimension data (responsibility / business rules / historical adaptation scores) are pushed to the operation and maintenance terminal simultaneously. After obtaining the confirmed target second-class subject from the operation and maintenance terminal (the feedback method includes but is not limited to manual selection and confirmation, system submission and entry), the unique identifier and interface information of the confirmed subject are output, completing the final closed-loop processing of the request text data.

[0162] The technical solution provided by this invention can be widely applied to automated processing scenarios that require interaction with multiple external entities and have complex and diverse request texts.

[0163] One typical application scenario is a request processing system. This system receives a massive number of user requests daily from multiple channels, including telephone, mobile applications, and on-site inspections. These requests cover facility status reports, order management requests, and consumer disputes related to e-commerce and logistics. Traditional processing methods rely on manual screening and distribution, which is inefficient. Using this invention, the system can automatically process all unstructured requests uniformly: First, a binary classifier distinguishes between first-type and second-type service requests; for first-type requests, it quickly matches them to the corresponding first-type service platform's after-sales interface; for second-type requests, by integrating multi-dimensional information such as location, time, and historical processing records, and combining it with an event semantic graph (containing knowledge of subject responsibilities, business rule sets, etc.), it accurately matches them to the corresponding facility maintenance subject, order management subject, or market behavior supervision subject for processing, achieving unified acceptance and collaborative processing of cross-category requests.

[0164] Another typical scenario is the unified customer complaint handling center of a large enterprise or platform. The complaints received may involve transaction disputes on their own e-commerce platform, logistics and delivery issues, and even related feedback on matters concerning the location of merchants on the platform (such as site safety and environmental hygiene). Applying this invention, a knowledge base and graph adapted to the enterprise scenario can be built to achieve integrated classification and triage of internal and external issues: purely transactional issues are matched to the internal customer service system, logistics issues are connected to external logistics service providers, and social affairs-related issues are transferred to relevant external processing systems through standardized interfaces, thereby improving overall customer complaint handling efficiency and user satisfaction.

[0165] This invention optimizes the mechanisms of traditional text processing methods in terms of feature utilization, knowledge fusion, and dynamic adaptation by synergistically employing three technologies: a phased linear discriminant model, multimodal semantic understanding, and event semantic graph. 1. Improved discrimination performance of classification models in complex scenarios. By employing a phased linear model architecture, a binary classifier first performs domain-specific segmentation of requests, followed by deep processing by a dedicated model. This design enables the model to be specifically optimized for feature distributions across different domains. In classification tasks involving multiple core fixed subjects, it achieves high precision and recall, helping to reduce misclassifications and missed classifications that may result from feature confusion in cross-domain, multi-class scenarios using a single model, thereby improving the overall stability of classification.

[0166] 2. Enhanced ability to integrate deep semantic understanding and structured knowledge Unlike keyword-matching-based text processing methods, this approach integrates multimodal features such as text, spatiotemporal context, and historical context. It transforms unstructured requests into structured representations containing semantic relationships through a domain-adaptive large model. Furthermore, it introduces an event semantic graph, fusing external domain knowledge with the request representation in a networked form. This allows the decision-making process to simultaneously consider semantic relationships and business rule constraints, thereby enhancing the depth of understanding and the rationality of decisions when handling complex requests with semantic ambiguity and missing elements.

[0167] 3. Possesses scalability and external knowledge adaptation capabilities. Based on a loosely coupled design of multimodal structured features and event semantic graphs, this method possesses a certain degree of adaptability to external changes. When entities are added, merged, or their responsibilities are adjusted, there is no need to retrain the core classification model. Only incremental updates to the entities, relationships, and attributes in the event semantic graph are required. The new knowledge can then be integrated into the decision-making process through the graph and feature mapping mechanism. This mechanism helps reduce the technical costs and maintenance complexity of large-scale iterations due to changes in business rules.

[0168] This invention also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being configured to perform the method described in this invention.

[0169] This invention also provides a computer-readable storage medium storing computer-executable instructions for performing the methods described in this invention.

[0170] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this invention can be achieved, and this is not limited herein.

[0171] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for distributing and processing request text data, characterized in that, The method includes the following steps: S100, receive request text data to be processed, the request text data includes event description text and associated metadata, the associated metadata includes request subject associated data, spatial associated data and time series associated data; S200, input the request text data into a preset binary classifier and output the classification result, which is either a first type of service request or a second type of service request; S300, if the classification result is a first type of service request, extract the target entity features from the request text data through the named entity recognition model; use the target entity features as retrieval conditions to match in a preset historical knowledge base to determine the corresponding first type of subject and associated interface information; The first type of subject corresponds to the first type of service request, and the processing subject for the first type of service request is a commercial entity. S400, if the classification result is a second type of service request, perform multimodal feature fusion processing on the request text data to obtain a fused feature dataset; input the fused feature dataset into a preset multi-classifier, and output the corresponding second type of subject and associated interface information; The second type of subject corresponds to the second type of service request, and the processing subject for the second type of service request is a non-commercial entity. S500, output the unique identifier of the first type of subject or the second type of subject and the corresponding interface information to complete the processing of the request text data; It also includes the steps for constructing an event semantic graph: By using a domain-adaptive large model, concept extraction is performed on the request text data corresponding to the second type of service request to extract the core elements of the event and the logical relationships between the elements. Relationship modeling is performed based on the core elements and logical relationships of the events to construct an event semantic graph. The event semantic graph includes domain knowledge relationships among service request events, business rule sets, and emergency scenarios. The nodes of the event semantic graph are the core elements of the events, and the edges are the logical relationships between the elements. The process of performing multimodal feature fusion processing on the request text data to obtain a fused feature dataset specifically includes: The request text data is subjected to text enhancement processing to obtain enhanced text; the enhanced text is then concatenated with the request title, request body content, spatial correlation data, and temporal correlation data to generate concatenated text containing complete contextual information; the temporal correlation data includes time-dimension subdivision features; Extract the TF-IDF features of the request text content, the one-hot encoding features of the spatial correlation data, and the one-hot encoding features of the request category from the concatenated text to obtain the basic feature set; Based on the event semantic graph, the core event elements in the request text content of the concatenated text are semantically expanded to generate element association features; The basic feature set and the element association features are concatenated and fused to obtain the fused feature dataset; In S400, the step of inputting the fused feature dataset into a preset multi-classifier and outputting the corresponding second type of subject and associated interface information specifically includes: The fused feature dataset is input into a preset multi-classifier, which outputs the corresponding second-class candidate results. Query the domain knowledge associations with the candidate results in the event semantic graph; The association fit of the candidate results is verified based on the domain knowledge association relationship to obtain the comprehensive fit of each candidate result. The confidence score of each candidate result is adjusted based on the comprehensive fit, and the second type of subject with the best confidence score and the associated interface information are output.

2. The method according to claim 1, characterized in that, The construction process of the preset binary classifier includes: Obtain request text data within a preset historical time period, manually annotate the request text data to obtain two types of tags, namely a first tag corresponding to the first type of service request and a second tag corresponding to the second type of service request; The annotated request text data is cleaned to remove interfering features and retain relevant core features, including numbers, network addresses and subject names. The cleaned request text data is subjected to feature engineering to generate TF-IDF features, character-level n-gram features of preset length, and preset keyword Boolean features related to the target scene; Based on the dataset after feature engineering, a preset binary classification model is trained to obtain the preset binary classifier.

3. The method according to claim 1, characterized in that, The process of performing multimodal feature fusion processing on the request text data to obtain a fused feature dataset specifically includes: The request text data is subjected to text enhancement processing to obtain enhanced text; the enhanced text is then combined with the request title, request body content, spatial association data, and temporal association data to generate a concatenated text containing complete contextual information; the temporal association data includes time-dimension subdivision features. Extract the TF-IDF features of the request text content, the one-hot encoding features of the spatial correlation data, and the one-hot encoding features of the request category from the concatenated text to obtain the basic feature set; The basic feature set is fused with the historical associated request data features to obtain the fused feature dataset; the historical associated request data features include historical request processing records of the same associated subject and processing records of similar requests within the same spatial range.

4. The method according to claim 3, characterized in that, The construction process of the preset multi-classifier includes: Filter the request text data corresponding to the second label, use the second type of subject that has been actually processed in history as the label, filter the label categories with a sample number greater than the preset threshold, and obtain the initial training dataset. The initial training dataset is subjected to multimodal feature fusion processing to obtain a fused feature dataset for training. Based on the training fusion feature dataset, a preset multi-classification model is trained; during the training process, the class weights of label categories whose sample proportions are lower than the preset proportion thresholds are increased, and the model is optimized using a comprehensive classification performance evaluation index. Historical request text data and corresponding actual processing record data are selected as test datasets. The performance of the trained multi-classification model is verified based on the test dataset. The multi-classification model whose performance verification results meet the preset requirements is used as the preset multi-classifier.

5. The method according to claim 1, characterized in that, If the final confidence score of the optimal second-class subject output by the multi-classifier is lower than the preset threshold, the top N candidate second-class subjects and the confidence score corresponding to each candidate second-class subject are output and pushed to the operation and maintenance terminal. After obtaining the confirmed target second-class subject from the operation and maintenance terminal, the final processing of the request text data is completed, N≥2.

6. An electronic device, characterized in that, Including processor and memory; The processor executes the steps of the method as described in any one of claims 1 to 5 by invoking programs or instructions stored in the memory.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a program or instructions that cause a computer to perform the steps of the method as described in any one of claims 1 to 5.

Images