Request text data distribution processing method, electronic equipment and storage medium

Abstract

The invention discloses a request text data distribution processing method, electronic equipment and a storage medium, and relates to the technical field of text data processing. The method comprises the steps of receiving to-be-processed request text data; dividing the request text data into a first class of service requests or a second class of service requests through a binary classifier; after the first-class service request is subjected to named entity recognition and target entity features are extracted, a historical knowledge base is matched to determine a first-class subject and a data interaction interface address; after multi-modal feature fusion processing is carried out on the second-class service request, the second-class service request is input into the multi-classifier to determine second-class main bodies and associated docking interface information; and finally, outputting the unique identifier of the main body and the corresponding docking interface information to complete request processing. According to the method, the feature characterization and discrimination capability of a distribution system on heterogeneous requests is improved, and the resource allocation efficiency of data processing and model reasoning is optimized, so that automatic request processing in a cross-domain complex scene is facilitated in the technical level.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of text data processing, in particular to a request text data distribution processing method, an electronic device and a storage medium. BACKGROUND

[0002] The automatic processing and subject precise matching of service requests are the key to improving management efficiency. Currently, the core technical bottleneck to achieve this goal is: how to enable the computer system to deeply understand the user requests that are mixed, ambiguous and accompanied by multi-dimensional context information, like experienced staff, and make reliable distribution decisions.

[0003] The existing technical solutions are mainly divided into two categories. The first category is a matching method based on fixed rules, which realizes distribution by matching pre-set keywords with request texts. This method essentially lacks true semantic understanding ability 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 is a method based on machine learning models, such as the invention patent "A hotline work order distribution method, device, equipment and storage medium" with publication number CN117726104B. This solution represents the technical progress in this field by building a prediction model to improve the automation level of distribution. However, through in-depth analysis, this existing technology has technical limitations in achieving deep, accurate and adaptive distribution: 1. Single model feature representation, insufficient use of context information: This solution mainly relies on the semantic features of the request text and fails to fully and structurally integrate multi-modal context information closely related to distribution decisions, such as the exact spatial location of the request, time characteristics (such as whether it belongs to a peak or emergency period), and the historical behavior patterns of the same initiator. This results in the computer system's understanding of the request remaining at the literal level, lacking real-world scenario embedding, and limited judgment when facing ambiguous semantics or context-dependent complex requests.

[0005] 2. Closed knowledge source, lack of domain knowledge fusion mechanism: The model completely relies on historical labeled data for training and reasoning, and is a closed system. It is difficult to actively access and utilize external structured domain knowledge (such as the latest institutional responsibility list, emergency handling process), making it difficult for the distribution system to adapt to dynamic adjustments of business rules, subjects or processing procedures, limiting flexibility and maintainability.

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

[0007] Therefore, there is a need for a request text data processing and distribution technical solution that can deeply integrate multi-dimensional context information, effectively integrate external domain knowledge, and maintain robust generalization ability under few-label conditions, to solve the technical problems of current systems such as insufficient semantic understanding depth, limited environmental adaptability, and strong data dependence. SUMMARY

[0008] To solve the above technical problems, the technical solution adopted by the present application is as follows: According to the first aspect of the present application, a request text data distribution processing method is provided, which comprises the following steps: S100, receiving request text data to be processed, the request text data containing event description text and associated metadata, the associated metadata including request subject associated data, spatial associated data and time sequence associated data.

[0009] S200, inputting the request text data into a preset binary classifier, and outputting a classification result, the classification result being 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, extracting target entity features in the request text data through a named entity recognition model; and matching in a preset historical knowledge base to determine corresponding first type of subject and associated docking interface information, using the target entity features as retrieval conditions.

[0011] S400, if the classification result is a second type of service request, performing multi-modal feature fusion processing on the request text data to obtain a fusion feature data set; inputting the fusion feature data set into a preset multi-classifier to output corresponding second type of subject and associated docking interface information.

[0012] S500, outputting the unique identifier of the first type of subject or the second type of subject and the corresponding docking interface information, and completing the processing of the request text data.

[0013] According to the second aspect of the present application, an electronic device is provided, comprising a processor and a memory; the processor is configured to execute the steps of the method according to the first aspect of the present application by calling programs or instructions stored in the memory.

[0014] According to a third aspect of the present application, a computer readable storage medium is provided, which stores a program or instructions for causing a computer to perform the steps of the method according to the first aspect of the present application.

[0015] The present application 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, the method first achieves accurate shunting of cross-domain requests. For the first type of service request, combined with domain-optimized named entity recognition and hierarchical knowledge base retrieval, it realizes fast and accurate matching of a large number of heterogeneous external service subjects. For the second type of service request, through multi-modal feature fusion technology, it integrates text, spatial and historical context information, and injects domain knowledge using an event semantic graph, so that the multi-classifier considers semantic association and business rules in feature representation and decision-making, thereby improving the subject matching accuracy in complex scenarios such as ambiguous request expression, missing elements or overlapping responsibilities.

[0016] 2. Optimized processing efficiency and resource utilization: The phased processing architecture and targeted feature engineering design avoid the computational redundancy caused by a single complex model processing all requests. The binary classifier performs a lightweight preliminary screening, the first type of service request path relies on efficient entity matching, and the second type of service request path focuses on in-depth multi-modal analysis. This division of labor reduces unnecessary feature calculation and model inference overhead, reduces response time delay and the load of data storage and interaction, and achieves an optimized balance between processing efficiency and resource cost.

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

[0018] It should be understood that the content described in this section is not intended to identify key or important features of the embodiments of the present application, nor is it used to limit the scope of the present application. Other features of the present application will become apparent through the following description. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings needed in the embodiment description. Obviously, the drawings described below only illustrate some of the embodiments of the present application, and for those skilled in the art, other drawings can be obtained without creative labor based on these drawings.

[0020] Figure 1 The flowchart of the request text data processing method provided by the embodiments of the present application is shown in the figure. DETAILED DESCRIPTION

[0021] The technical solutions in the embodiments of the present application will be described clearly and completely in the following with reference to the drawings of the embodiments of the present application. Obviously, the described embodiments only represent some of the embodiments of the present application, rather than all the embodiments. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[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 application belongs. The terminology used in the description of the application herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this description, the singular forms "a", "an" and "the" include plural references unless the context clearly dictates otherwise. The term "and / or" includes any and all combinations of one or more of the associated listed items.

[0023] It is noted that some example embodiments are described as processes depicted as flow diagrams. Although the processes are described in a particular sequence, many of the steps can be performed in parallel, concurrently or simultaneously. In addition, the order of steps can be re-arranged. The processes can be terminated when their operations are completed, but can also have additional steps not included in the figure, which can also be performed after the operations of the processes are completed. The processes can correspond to methods, functions, procedures, subroutines, subprograms, etc.

[0024] The present application aims at the problems of limited semantic understanding depth and insufficient multi-modal information utilization in the existing request text data processing technology. Specifically, the traditional method fails to fully realize the structured alignment and deep fusion of unstructured text and multi-dimensional context information such as time and space, history, etc., resulting in limited semantic representation ability and generalization ability of the model on complex requests, low degree of system automatic processing, and still requiring more manual intervention. In order to facilitate the description of the technical solutions of the present application, some terms appearing in the text are defined as follows. The definition is only used to explain the embodiments of the present application, and does not constitute a limitation on the protection scope of the present application.

[0025] Request text data: refers to the full information set submitted by the request object, including event description text and associated metadata. Among them, the event description text is unstructured content expressed in natural language, and the associated metadata includes request subject associated data, spatial associated data and time sequence associated data.

[0026] First type of service: refers to the service type related to commercial transactions and consumption activities, including but not limited to commodity transactions, order processing, after-sales service, logistics distribution, etc., and its processing subject is a commercial entity. Accordingly, the first type of service request refers to the matter reflected by the request text data belonging to the first type of service category, the first type of subject refers to the commercial entity responsible for processing the first type of service request, and the first type of service platform refers to the system platform used to receive and process the first type of service request.

[0027] Second type of service: refers to the service type other than the first type of service, which is related to the field of social affairs management and people's livelihood guarantee, including but not limited to infrastructure maintenance, environmental order management, social welfare affairs, emergency response, etc., and its processing subject is a non-commercial subject. Accordingly, the second type of service request refers to the matter reflected by the request text data belonging to the second type of service category, the second type of subject refers to the non-commercial subject responsible for processing the second type of service request, and the second type of service platform refers to the system platform used to receive and process the second type of service request.

[0028] The above two types of service requests are distinguished by a preset binary classifier based on text semantics and associated metadata.

[0029] Subject: refers to the execution unit responsible for processing the request matter, including the first type of subject and the second type of subject. Each subject has a unique identifier and associated interface information in the system, which is used for request data flow and interaction.

[0030] Event semantic graph: refers to a domain knowledge base organized in a graph structure, whose nodes are core elements (including event elements, subject elements, rule elements), and edges are logical association relationships between elements. The graph is used for semantic expansion and knowledge verification of the request text in the multi-modal feature fusion process.

[0031] The above definitions are used throughout the present invention and will not be described again in subsequent examples. The present invention aims to overcome the technical defects of insufficient shallow semantic understanding and multi-modal information utilization in existing request text data processing technology. Specifically, the traditional method fails to effectively realize the structured alignment and deep fusion of unstructured text and multi-dimensional context information such as time and space, history, etc., resulting in weak semantic representation ability of the model for complex requests, poor generalization, low system automation and dependence on a large amount of manual intervention.

[0032] To solve the above technical problems, the application provides a scheme for deep processing and analysis of request text data. By using a domain adaptive large model for deep semantic analysis and structured conversion, and combining a multi-modal feature fusion method and an event semantic graph technology, the scheme constructs a technical process that can accurately extract, correlate and utilize the embedded semantics, spatio-temporal attributes and domain knowledge of the request. This process improves the feature representation quality and classification discrimination ability of complex requests, thereby realizing high-precision automated processing of the request.

[0033] Specifically, the application embodiment provides a request text data distribution processing method, as shown in Figure 1 The method comprises the following steps: S100, receiving request text data to be processed, the request text data comprising event description text and associated metadata.

[0034] In the application, the request text data is a full information set submitted by a request object to a request processing system to reflect a request matter. Its data sources cover various channels, such as hotlines, mobile applications, and small programs, supporting multi-source data access from first-class service platforms and second-class service platforms. The event description text is the core content of the request text data, which refers to the natural language expression of the request subject for the request matter. Its content usually presents a narrative logic of "problem description-impact explanation-treatment demand", completely covering the core objects, impact range and solution expectations of the event, without following a fixed format, thereby preserving the original intention of the initiator. The associated metadata is auxiliary information with a clear structure that accompanies the event description text. The purpose of introducing the associated metadata is to provide key spatio-temporal and subject background for machine understanding of the text to break through the limitation of only analyzing the literal text. The associated metadata mainly includes three types: Request subject associated data: refers to the identification information related to the request subject, which is used to establish the association between the request subject and the historical requests, and the data sources include the request subject's active reporting or platform automatic collection, and the specific content can include the request subject's anonymous user ID, contact method hash value, and other desensitization information, as well as the historical record identifier for associating the subject's past request matters.

[0035] Spatial association data: refers to geographic information related to the location of the request matter, which is used to accurately locate the spatial range of the request, and the acquisition method includes two types, one is to extract address information from the event description text and perform structured analysis to obtain hierarchical address data of province, city, district, street, community, and specific point; the other is to directly obtain the positioning associated data of the call terminal under the authorization of the request subject, to obtain the latitude and longitude coordinate information, and the two methods can be used alone or in combination to improve the accuracy of spatial positioning; Timing-related data: refers to the time information related to the submission time of the request, which contains two dimensions of content. One is the original timestamp of the request submission, that is, the request receiving time accurate to seconds; the second is the time period division data based on the preset rules, which is set according to the business characteristics of the second type of service processing, and is specifically divided into early peak period, working period, late peak period and non-working period. The exemplary period division standard is: early peak period is 7:00-9:00, working period is 9:00-17:00, late peak period is 17:00-19:00, and non-working period is 19:00 to next day 7:00.

[0036] The request text data received through the S100 step integrates unstructured semantic information and structured scene information, which can provide comprehensive and accurate input data support for subsequent binary classification screening, multi-modal feature fusion and other processing procedures.

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

[0038] This step is used to preliminarily classify the request based on the semantic features and associated metadata of the request text data, and output the first type of service request or the second type of service request. After classification, the first type of service request enters the processing procedure of matching external service subjects based on the historical knowledge base, and the second type of service request enters the precise distribution procedure based on multi-modal feature fusion and event semantic graph. Through this classification, requests in different fields can be diverted to corresponding processing modules to reduce the system performance loss and distribution error caused by mixed flow processing, and provide a basis for subsequent differentiated processing.

[0039] The construction process of the preset binary classifier is developed around the core logic of high-quality training data preparation-effective feature extraction-robust model training, and specifically includes the following steps: S201, obtaining request text data in a preset historical time period, manually labeling the request text data to obtain two types of labels, which are respectively a first label corresponding to a first type of service request and a second label corresponding to a second type of service request.

[0040] The purpose of this step is to build a high-quality labeled data set to provide a supervision signal for training a binary classification model. The selection of the pre-set historical time period needs to take into account data timeliness and sample coverage: for example, selecting 1 year of historical data as an illustrative embodiment can ensure sufficient sample size (covering different seasons, different business rule cycles, such as holiday e-commerce complaint peaks, emergency response and processing in specific scenarios, etc.), and can avoid annotation bias caused by changes in business scenarios (such as the addition of a second type of service function and emerging e-commerce models) over time.

[0041] The manual annotation process needs to follow standardized specifications: first, establish clear label determination criteria, where the first label "1" corresponds to the first type of service request, including transaction disputes, logistics distribution, after-sales service, etc. Examples of requests include "online shopping quality problem return blocked" and "express package loss claim"; the second label "0" corresponds to the second type of service request, including social affairs support, infrastructure state maintenance, order management, and related categories. Typical request examples include text descriptions reflecting the lack of facilities in a certain area and requesting additional settings, or text descriptions of inquiries about certain transaction processing procedures and rules. Then, at least two professional annotators independently annotate the samples, and samples with inconsistent annotations are confirmed through cross-reviews and expert reviews to ensure that the annotation accuracy is not less than 95%, avoiding the impact of annotation noise on model training effectiveness. The final labeled data set is divided into training and validation sets in a pre-determined ratio (e.g., 7:3) for model training and hyperparameter tuning.

[0042] S202, text cleaning is performed on the labeled request text data to remove HTML tags, emoticons, and stop words, and to retain relevant core features.

[0043] This step aims to remove meaningless interference information and retain core features highly relevant to distinguishing between the first and second types of service requests, in order to reduce model computation complexity and improve feature representation accuracy. The specific cleaning operations and logic are as follows: Interference feature removal: HTML tags are commonly found in online request submission data from second-type service APPs and e-commerce platforms (such as copied and pasted web content carrying Labels and Emoticons are emotional symbols added by the requester when expressing freely (e.g., "[angry emoticon] express late"), stop words are general words with no specific semantics (e.g., "de, le, in"), such information has limited ability to distinguish the request scenarios, and even dilutes the core semantics, which are removed in batches through regular matching and stop word dictionary matching; Core feature reservation: the core features reserved in this step are all key basis for supporting the judgment of the binary classifier scenario, specifically including three categories: Digital features: order numbers, transaction amounts corresponding to the first type of service scenarios, and matter handling numbers, business handling numbers, etc. (e.g., "order 123456789 return" "matter 678 progress consultation") of the second type of service scenarios. This type of feature can quickly distinguish "transaction" and "non-transaction" request attributes, and is an important identifier for initial judgment of the scene; Network address features: mostly links to goods and shop links of the first type of service platform (e.g., "https: / / xxx.com commodity quality problem complaint"), this type of feature has strong scene directionality, and can directly determine that the request belongs to the e-commerce platform related scene; Subject name features: the subject includes the first type of subject and the second type of subject. The name of the first type of subject corresponds to the first type of service request, which covers the names of commercial entities such as e-commerce platforms, merchants, and logistics service providers (e.g., "e-commerce platform P" "logistics service provider Q"); the name of the second type of subject corresponds to the second type of service request, which covers the identification of related transaction processing subjects (e.g., "subject A" "subject B"). This type of feature is a core semantic unit extracted from the request text based on a named entity recognition model, and provides a key basis for request category determination and subject matching.

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

[0045] S203, the request text data after cleaning is subjected to feature engineering processing to generate TF-IDF features, character-level n-gram features of a predetermined length, and predetermined keyword Boolean features related to the target scene.

[0046] The core of this step is to convert standardized text data into numerical features recognizable by the model, while considering general semantic capture and accurate scene matching, breaking through the limitations of traditional shallow feature extraction relying on only single keywords. The generation logic, role, and implementation details of each feature are as follows: TF-IDF features: Adopt 1-2 gram word-level division method, calculate the word frequency (TF) of words in a single request text and the inverse document frequency (IDF) in the full request text, and quantify the semantic importance of words. For example, the words related to the second type of service request have a lower IDF value and a higher weight in the second type of service corpus, and the words related to the first type of service request have a lower IDF value and a higher weight in the first type of service corpus. This feature can effectively capture the general semantic information of the text and avoid missing features due to differences in expression (such as "express loss" and "package not received").

[0047] Character-level n-gram features: Adopt 3-5 gram phrase-level division method, extract continuous character combinations in the text through sliding window, and capture scenario-based phrase semantics that cannot be expressed by single words. Such phrases are the core semantic units that distinguish the first type of service request from the second type of service request. Select the length range of 3-5 grams to ensure the integrity of the phrase semantics and avoid the problem of feature sparsity caused by too long grams.

[0048] Pre-set keyword Boolean features: For the core business pain points of the first type of service scenario, filter keywords such as "return, refund, logistics, order, commodity, transaction, after-sales, and store" to construct a keyword dictionary. For each request text, if it contains keywords in the dictionary, assign a value of 1, otherwise assign a value of 0. This feature can quickly lock the core request of the first type of service scenario and improve the recognition sensitivity of the classification model for the first type of service scenario.

[0049] Finally, the three types of features are concatenated according to the feature dimension to form a unified feature matrix, which is used as the input data of the binary classification model.

[0050] S204, based on the data set processed by the feature engineering, train the pre-set binary classification model to obtain the binary classifier.

[0051] This step builds a robust and accurate binary classifier by selecting a model that fits the text classification scenario, optimizing hyperparameters, and multi-dimensional evaluation. The specific technical details and logic are as follows: Binary classification model selection: LinearSVC (Linear Support Vector Classification) model or SGDClassifier (Stochastic Gradient Descent Classifier) model is selected. Both are suitable for high-dimensional text feature matrix classification tasks, with the advantages of high training efficiency and strong generalization ability. LinearSVC model has stable classification accuracy in small sample and high-dimensional data scenarios, and SGDClassifier model has faster training speed for large-scale data. The actual training data volume can be flexibly selected; Hyperparameter optimization: Grid search combined with 5-fold cross-validation is used to determine the optimal hyperparameters. Grid search traverses the preset hyperparameter combinations (such as LinearSVC regularization parameter C value range [0.1, 1, 10], SGDClassifier learning rate value range [0.001, 0.01, 0.1]), 5-fold cross-validation randomly divides the training set into 5 parts, and uses 4 parts for training and 1 part for validation, avoiding hyperparameter overfitting caused by single data division; Model evaluation and decision: F1 value is used as the core evaluation index, while considering accuracy, precision, and recall. F1 value can balance precision (avoiding misjudging second-class service requests as first-class service requests) and recall (avoiding missing first-class service requests), adapting to the business demand of prioritizing request classification accuracy and no missing; 0.5 is used as the classification decision threshold. When the model output prediction probability is greater than 0.5, it is judged as a first-class service request (first label "1"), otherwise it is judged as a second-class service request (second label "0"). This threshold is a reasonable value for binary classification tasks, which can ensure the balance of classification results; Model combination optimization: To further improve the classification stability, LinearSVC model and SGDClassifier model can be combined by soft voting. The final prediction result is obtained by weighted average of the prediction probabilities of the two models, which reduces the generalization error of a single model and improves the classification accuracy in extreme scenarios (e.g., requests involving both transaction problems of first-class service platform and transactions of second-class subject jurisdiction).

[0052] Through the above steps S201-S204, the binary classifier constructed can effectively extract the deep semantic features of the request text and accurately distinguish between first-class service requests and second-class service requests, providing reliable classification basis for subsequent scene-specific accurate processing.

[0053] S300, if the classification result is a first type of service request, extracting a target entity feature in the request text data through a named entity recognition model; taking the target entity feature as a retrieval condition, matching in a preset historical knowledge base to determine a corresponding first type of subject and associated interface information.

[0054] This step is based on the binary classification result of S200, and is a first type of service scene specific processing flow. The core purpose is to accurately match the corresponding first type of subject and interface information based on the core entity feature of the request text data, to realize the automatic shunting processing of the first type of service request, reduce the efficiency loss of manual retrieval of interface information, and reduce the request flow delay caused by subject matching errors.

[0055] In the present application, a pre-trained large model optimized by field adaptation 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 scene, ensuring the extraction accuracy of first type of service field specific entities.

[0056] Model fine-tuning strategy: select request corpus of typical scenes of the first type of service platform transaction dispute, after-sales service, logistics distribution, etc. (such as "the first type of service platform P order 123456789 return blocked" and "the first type of service platform Q logistics package lost") as fine-tuning corpus. On the basis of the general pre-trained large model, an AdamW optimizer is used, an initial learning rate of 5e-5 is set, and the model is fine-tuned through 3 rounds of incremental training; at the same time, five types of core entity types are set as recognition targets, which are the first type of service platform name, order number, store name, logistics service provider name, and transaction dispute type, which comprehensively cover the core associated elements of the first type of service request processing.

[0057] Entity extraction and type labeling: input the cleaned first type of service request text data into the above named entity recognition model, and the model automatically identifies and labels the target entity feature in the text. The example extraction result is: "[first type of service platform name: first type of service platform P] [order number: 123456789] [dispute type: return blocked]". In order to avoid errors or invalid information in the extracted entities (such as incorrectly identified order numbers and non-existent first type of 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 verification: for entities with fixed format specifications (such as order numbers and logistics numbers), the format is matched by regular expression (such as order numbers are "8-digit numbers + 2-letter combinations" and logistics numbers are "12-digit numbers"), and invalid entities that do not meet the format are removed. Rationality check: For the first type of service platform name, logistics service provider name and other entities with clear scope, compare with the preset first type of service platform whitelist (such as first type of service platform P, first type of service platform Q, first type of service platform R) and logistics service provider whitelist, and eliminate the wrong entities (such as the model mistakenly identifies "a second type of service platform" as a first type of service platform name) not in the whitelist; Check result closed loop processing: Keep the effective target entity features passing the double check, and eliminate invalid or error entities; If the number of extracted effective entities is 0, mark the request as "to be manually reviewed" and push it to the operation and maintenance terminal for manual annotation of core entities by staff; At the same time, the manual review results are synchronized to the model fine-tuning corpus for iterative optimization of the model, continuously improving the entity extraction accuracy.

[0058] In the present application, the historical knowledge base is a first type of service request processing exclusive knowledge base, which contains two core sub-bases, and both are configured with real-time updating mechanism: First type of service platform interface information base: Store the official subject name, service contact identifier and data interaction interface address of each first type of service platform, synchronize the interface update announcement of each first type of service platform monthly to ensure the timeliness of the interface information; First type of service request processing case base: Store the matching records of entity features and subjects of historical first type of service requests, incrementally update the new cases monthly to continuously enrich the matching samples.

[0059] In the present application, the hierarchical matching principle is adopted: preferentially performing accurate matching, that is, when the extracted first type of service platform name, order number and other entities match the records in the first type of service platform interface information base with 100% matching degree, directly matching the corresponding first type of subject; If there is no result of accurate matching (such as the first type of service platform in the request text is a new platform, the order number format is not standardized, the store name has a nickname / alias, etc. which is not included in the first type of service platform interface information base), then perform fuzzy matching, based on the dispute type, logistics service provider name and other entities in the request text, use the cosine similarity algorithm to calculate the similarity with the historical cases in the case base, select the top M (for example, M=3) cases with similarity higher than a preset similarity threshold, for example, 0.85, and determine the optimal matching subject combined with the dispute type weight, the specific process is as follows: (1) Construct feature vectors for the historical cases in the first type of service request processing case base and the current request to be matched respectively: For historical cases: extract their labeled core entity features (dispute type, logistics service provider name, request keywords, handling subject), based on the pre-set first-class service field word vector dictionary (such as the first-class service request exclusive word vector trained by the Word2Vec model), convert discrete entity features into dimension-unified numerical feature vectors, and set the vector dimension to 256 to ensure that the semantic correlation of the features can be quantified. For the current request to be matched: extract the valid entity features that pass the verification (such as "dispute type: logistics delay", "logistics service provider name: certain pass", "request keywords: package not delivered"), use the same word vector dictionary as the historical cases, and convert them into feature vectors of the same dimension to ensure comparability.

[0060] (2) Use the cosine similarity algorithm to calculate the similarity values of the current request feature vector and all historical case feature vectors in the case library. The cosine similarity value ranges from -1 to 1. The closer the value is to 1, the higher the semantic similarity between the current request and the historical case, 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) According to the calculated similarity values, sort all historical cases in descending order, and select historical cases with similarity values higher than the pre-set 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 all selected cases are high-correlation cases and avoid low-similarity cases interfering with the matching results.

[0062] To further improve the matching accuracy, introduce a dispute type weight coefficient based on the historical case handling success rate: for high-frequency dispute types such as return and refund, logistics loss, and product quality, combine their historical handling success rates (such as the average handling success rate of return and refund disputes is 95%, and the handling success rate of logistics delay disputes is 92%) to set different weight coefficients (such as the return and refund weight is 0.8, the logistics delay weight is 0.7, and the product quality weight is 0.9).

[0063] The specific weighting calculation rules are: For each candidate case, calculate the weighted similarity value = cosine similarity value x weight coefficient of corresponding dispute type; Sort the weighted similarity values of the candidate cases in descending order again, and select the subject corresponding to the case with the highest weighted similarity value as the optimal matching subject for the current request; If the weighted similarity values of multiple candidate cases are the same, select the subject corresponding to the case with the highest historical handling success rate to improve the practicality and reliability of the matching result.

[0064] Taking the request of "a new first-class service platform involves a logistics service provider's logistics delay" as an example: after the precise matching fails to be included in the platform, the fuzzy matching extracts the feature vector of "dispute type: logistics delay" and "logistics service provider: logistics service provider A", and calculates the weighted similarity value with the three high-similarity historical cases in the case library (the similarity values are 0.91, 0.88 and 0.86 respectively). Finally, the "official after-sales subject of logistics service provider A" corresponding to the case with the highest weighted value is selected as the matching result, and the precise connection of the subject is completed. After matching to the corresponding first-class subject, the associated connection interface information of the subject is extracted synchronously, and the connection interface information includes two types of core contents: one is the service subject contact identifier, such as the official customer service hotline of the first-class service platform, the after-sales processing mailbox, and the WeChat connection account of the enterprise, which is used for manual synchronous feedback of the request information; the other is the data interaction interface address, such as the after-sales work order connection API interface and order information query interface opened by the first-class service platform, which is used for automatic data interaction between the request text data and the internal system of the first-class service platform.

[0065] Through the above-mentioned whole-process automatic processing of entity extraction-verification-hierarchical matching, the output of the first-class subject and the connection interface information can directly support the subsequent processing and transfer of the request. According to the actual measurement, the subject matching accuracy of the first-class service request in this step can reach more than 98%, and the matching error of the connection interface information is less than 0.5%. Compared with the traditional keyword matching method, the manual intervention rate is reduced by more than 80%, and the processing efficiency of the first-class service request is greatly improved.

[0066] S400, if the classification result is a second-class service request, performing multi-modal feature fusion processing on the request text data to obtain a fusion feature data set; inputting the fusion feature data set into a preset multi-classifier to output corresponding second-class subjects and associated connection interface information.

[0067] This step is connected with the binary classification result determination of S200, and is a second-class service scene exclusive processing procedure. The core purpose is to integrate the semantic features, spatio-temporal features, historical association features or domain knowledge features of the request text through multi-modal feature fusion technology, to construct a high-recognition fusion feature data set; and then to accurately match the corresponding subjects and associated connection interface information through a preset multi-classifier, to improve the shallow limitations of the traditional keyword matching, and to realize the accurate distribution of the second-class service request.

[0068] For multi-modal feature fusion processing, the application provides two parallel implementation manners, which can be flexibly selected according to the historical data reserve and request type richness of the second-class service request, as follows: Implementation manner one: multi-modal feature fusion based on historical association request data The embodiment is suitable for the second type of service scene with sufficient historical request data and relatively stable request type, and the core is to improve the accuracy of subject matching based on the processing rules of historical requests. Specifically, the following steps are included: S401, performing text enhancement processing on the request text data to obtain enhanced text; and splicing the enhanced text with the request title, request subject content, spatial correlation data and time sequence correlation data to generate spliced text containing complete context information.

[0069] The text enhancement processing on the request text data includes enhancement processing such as text denoising, synonym replacement, missing information completion, etc. on the original request text data.

[0070] The time sequence correlation data includes the original timestamp of the request submission and time dimension subdivision features, which are divided into early peak period, working period, late peak period and non-working period according to the business characteristics of the second type of service processing, which can assist in determining the urgency and processing window of the request.

[0071] An exemplary splicing result is: "[Request title: exemplary event state description] [Request content: exemplary environmental conditions cause a certain area to have a specific state change, which affects normal activities] [Spatial correlation data: XX City, XX District, XX Street, XX Community] [Time sequence correlation data: 2025-07-10 08:30 early peak period]". The splicing result integrates the core semantic information (title and content) of the request, the geographical level information (province / city / district / street / community), and the refined time context (timestamp and period identifier) through structured fields, forming a standardized request record containing complete space, time and event description, providing a unified input format for subsequent feature extraction and classification determination.

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

[0073] The request text content in the spliced text is composed of the enhanced text, the request theme and the request subject content. The TF-IDF features are obtained based on the request text content in the spliced text, and the core is to quantify the semantic importance of core business vocabulary. The specific steps are as follows: (1) Text preprocessing The request text content in the spliced text is processed by Chinese word segmentation, and the Jieba word segmentation tool is used in combination with the second type of service field dictionary to complete accurate word segmentation; at the same time, the second type of service scene general stop words (such as "de", "le", "please", "hope" and other non-business value words) are removed to obtain standardized word segmentation results.

[0074] (2) Term Frequency (TF) calculation For the word segmentation result of a single request text, the term frequency of each business vocabulary is calculated, and the formula is: TF wi = N wi / N total , where TF wi is the term frequency of vocabulary w in the i-th request text; N wi is the number of occurrences of vocabulary w in the i-th request text; N total is the total number of words in the i-th text.

[0075] (3) Inverse Document Frequency (IDF) calculation Based on the full second type of service request text corpus, the inverse document frequency of each business vocabulary is calculated to quantify the discriminability of the vocabulary. If a vocabulary appears in most texts, the IDF value is low and the discriminability is weak; if it only appears in a specific request type, the IDF value is high and the discriminability is strong. The formula is: IDFw=log(Nc / Nw), where IDFw is the inverse document frequency of vocabulary w; Nc is the total number of texts in the corpus; Nw is the number of texts containing vocabulary w; and the denominator plus 1 is to avoid the denominator being 0 when the vocabulary does not appear.

[0076] (4) TF-IDF feature vector generation The TF-IDF value of each business vocabulary is calculated, and a fixed-length feature vector is constructed based on the vocabulary table of the corpus; each dimension of the vector corresponds to a business vocabulary, and the dimension value is the TF-IDF value of the vocabulary in the current text, finally generating the TF-IDF feature vector of the request text content.

[0077] The spatial correlation data is hierarchical geographic information (such as XX province-XX city-XX district-XX street-XX community), and the specific steps for obtaining the one-hot encoding feature are as follows: (1) Geographic information standardization Clean and standardize the spatial correlation data in the request text: first, unify the expression of geographic names (such as standardizing "XX district XX street office" to "XX district XX street"); second, complete the missing hierarchical information (such as filling in "XX community" based on the geographic information database to complete the city, district, and street); third, eliminate invalid geographic information (such as "nearby" and "around" ambiguous expressions), and obtain structured five-level hierarchical geographic information.

[0078] (2) Construct hierarchical geographic dictionary Based on the full geographic division data, a hierarchical geographic dictionary is constructed, and an independent vocabulary set is established for each level (province, city, district, street, and community), for example: District-level dictionary: {XX district, YY district, ZZ district…}; Street-level dictionary: {XX Street, AA Street, BB Street, …}

[0079] (3) Hierarchical one-hot encoding Use one-hot encoding tools (such as sklearn.OneHotEncoder) to encode the standardized five-level geographic information hierarchically: For each level of geographic name, generate a binary vector consistent with the length of the dictionary at that level; If the current request contains a certain level of vocabulary, assign the corresponding vector dimension to 1, and the rest to 0; For example: XX district is ranked 3rd in the district-level dictionary, so the district-level encoding vector is [0, 0, 1, 0, …, 0].

[0080] (4) Concatenate to generate spatial feature vector Concatenate the one-hot encoding vectors of the province, city, district, street, and community five levels in order to form a spatial correlation data one-hot encoding feature vector with fixed dimensions. This vector can be directly recognized by a multi-classification model to accurately locate the request's jurisdiction.

[0081] Request category one-hot encoding features are based on a pre-set 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 According to the division of functions, a standardized request classification system is preset, divided into primary and secondary categories, and the example classification is as follows:

[0082] (2) Request text pre-classification Use "keyword matching + rule determination" to pre-classify the enhanced request text: Build a category keyword dictionary based on the classification system; Calculate the keyword matching degree of the request text with each secondary category, and the category with the highest matching degree is the pre-classification result of the request; For requests with a matching degree lower than the preset threshold (such as 0.6), mark them as "to be manually reviewed" to ensure classification accuracy.

[0083] (3) Build category dictionary and encode Based on the pre-set secondary request categories, build a complete category dictionary; Use one-hot encoding tools to encode the pre-classification results: Generate a binary vector consistent with the length of the category dictionary; If the request pre-classification result is a certain secondary category, assign the corresponding vector dimension to 1, and the rest to 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 fusion 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] The full amount of the second type of service request text data is accurately extracted by the domain adaptive large model. The domain adaptive large model is fine-tuned based on the second type of service domain-specific corpus (such as request event processing cases, business rule set texts, and subject responsibility lists) to strengthen the recognition ability of the core elements of the second type of service scenario. The extracted core elements are divided into three categories: Event core elements: specific business objects to which the request is directed, such as "state A", "scenario B", "impact C", "transaction D", etc. Subject elements: corresponding to the second subject, such as "unit A", "unit B", "unit C", etc. Business rule set elements: 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, relationship modeling based on the event core elements and logical association relationships, and construction of an event semantic graph.

[0091] First, based on the extracted core elements, the logical association relationships between the elements are constructed, and the association attributes and weights of different elements are determined, including: Business processing association: the correspondence between event core elements and subject elements (such as "state A" -> "unit A (weight 0.8), unit B (weight 0.2)"); Business rule support association: the correspondence between event core elements and business rule set elements (such as "impact C" -> "related domain rule B"); Scenario expansion association: the association relationship of similar event core elements (such as "specific condition state A" -> "derivative state B" -> "specific response process C").

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

[0093] Based on the graph, multi-modal feature fusion is carried out, including the following steps: S410, text enhancement processing is performed on the request text data to obtain enhanced text; the enhanced text is spliced with the request title, request subject content, spatial association data, and time sequence association data to generate a spliced text containing complete context information; the time sequence association data contains time dimension subdivision features.

[0094] In accordance with the text enhancement processing logic of S401, the added text, request title, request body content, spatial correlation data, and time sequence correlation data are structured and spliced to generate spliced text containing complete context information, providing a basis for subsequent feature extraction.

[0095] S420, TF-IDF features of request text data, one-hot encoding features of spatial correlation data, and one-hot encoding features of request categories in the spliced text are extracted to obtain a basic feature set.

[0096] In accordance 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 in the spliced text are extracted to form a structured basic feature set.

[0097] S430, based on the event semantic graph, the event core elements in the request text content in the spliced text are semantically expanded to generate element correlation features. The specific process is as follows: Event core element extraction: from the request text content in the spliced text, extract the core elements of the current request, such as "specific condition state A", "specific location B", and "potential risk C"; Graph knowledge retrieval and correlation: input the extracted core elements into the event semantic graph to trigger multi-dimensional knowledge retrieval: Retrieve corresponding subject elements: "specific condition state A" -> "unit A (weight 0.8), unit B (weight 0.2)" Retrieve corresponding business rule set elements: "specific condition state A" -> "related domain rule document A XXth"; retrieve corresponding scenario expansion elements: "specific location state A" -> "specific emergency handling process C".

[0098] Numerical feature vector generation: convert the retrieved correlation knowledge into a numerical element correlation feature vector, which has the following dimensions: Core element and subject correlation weight; Core element and business rule set matching degree; Core element corresponding emergency handling priority; Finally, a fixed-dimension element correlation feature vector is generated, realizing the conversion of unstructured domain knowledge to structured features.

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

[0100] In the splicing process, differentiated weights (such as weight coefficient 1.2) are given to the element correlation feature vectors, and the guiding role of domain knowledge on the distribution decision is strengthened; the finally generated fusion feature data set simultaneously contains the semantic features, the space-time features, the business category features, and the responsibility correlation features, the business rule matching features and the priority features based on the knowledge graph, which can effectively solve the distribution difficulty problem of emerging requests caused by the lack of historical data.

[0101] In an illustrative embodiment, the fusion feature vector FM corresponding to the fusion feature data set satisfies the following conditions: , wherein F r is the rth original feature vector, such as text semantic features from domain large model coding, spatial features from GIS coordinate coding, and time sequence features from work order submission timestamp coding, the value of r is 1 to D, D is the number of feature types, D = 3, corresponding to text semantic features F1, spatial position features F2, and time sequence features F3; WB r is the basic weight of the rth feature, which is obtained by normalizing the feature contribution degree Contrib r , Contrib r is the contribution value of the feature to the improvement of distribution accuracy, which is obtained by training a domain adaptive large model, c r is the domain adaptation coefficient of the rth feature, c r =1+λ·Sim(F r , G), G is a domain knowledge graph, Sim(F r , G) represents the semantic similarity between F r and G, the value range is 0-1, which is calculated by the cosine similarity between the feature vector and the graph node vector. λ is the domain adaptation intensity factor, the value range is 0.1-0.5, which is calibrated by domain samples.

[0102] In the present application, the domain knowledge graph is a static and structured general knowledge system constructed for the second type of service request processing scenario. Its core is to integrate the core entities, entity attributes and logical relationships between entities in the domain through semantic correlation, forming a bottom-layer knowledge network covering subjects, responsibilities, rules and transactions, and providing standardized knowledge support for subject matching of the second type of service request. The domain knowledge graph has the following technical features: Static generality: the knowledge content is pre-constructed based on domain business specifications and standard documents, and does not change with single request events, which can support the processing needs of all types of second type of service requests; Authority compliance: the responsibility division and rule provisions in the graph are derived from structured public domain data, ensuring that the subject matching process has traceable rule basis; Structured association: Break through the limitations of traditional unstructured documents, convert scattered domain knowledge into triples of "entity-relation-attribute", support efficient semantic retrieval and matching calculation.

[0103] The core components of the domain knowledge graph include three types of core elements: Core entities: Participants, business objects, rule files, etc., such as subjects (unit A, unit G), request types, and rule files (related domain rule documents A).

[0104] Entity attributes: Key information describing entity characteristics, such as unit A attributes: responsible area, core responsibilities; business rule attributes: effective time, applicable scope.

[0105] Association relationship: Logical association between entities, such as unit A → responsibility → specific regional state maintenance; domain rule document A → applicable event → specific condition state request.

[0106] The construction of the domain knowledge graph follows the whole-process logic of "demand-driven-data integration-knowledge processing-storage and maintenance", and the specific steps are as follows: 1. Constructing requirements and data source analysis Requirement anchoring: Clearly define the core service objectives of the graph, support subject matching, 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 collection: Integrate relevant authoritative data sources, including: Authoritative public data sources: Function description files, function lists, rule set texts, and regional division files of relevant units; Historical business data: Historical request ticket data, subject processing records, and business handling process manuals; Industry standard data: Related domain big data classification standards, request event classification and coding specifications.

[0108] 2. Knowledge extraction: Extract core elements from unstructured data A hybrid method combining rule extraction and domain adaptive model extraction is used to extract knowledge elements from multi-source data: Entity extraction: Based on domain dictionaries (such as related unit name dictionaries, request type dictionaries), combined with BERT and other domain adaptive models, extract core entities such as related units, rule files, and request types from text; Relationship extraction: Through rule templates (such as "XX unit is responsible for XX affairs") and deep learning models (such as relationship extraction BERT model), identify the association relationship between entities; Attribute extraction: Extract key attributes of entities from structured forms (such as function list tables) and unstructured text (such as rule provisions), such as the "responsible area" and "interface identifier" of relevant units, and the "effective time" and "responsibility division clause" of rule files.

[0109] 3. Knowledge fusion: Eliminate ambiguity and achieve knowledge standardization In view of the heterogeneity and redundancy of multi-source data, knowledge cleaning and fusion are carried out to ensure the consistency of the graph: Entity disambiguation: Unify different expressions of the same entity, such as merging "Unit A" and "Unit H" into the same entity and assigning a unique code; Relationship standardization: Based on domain rules, define standardized relationship types, such as classifying "responsible" and "undertake" 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 files), the latest and most authoritative published function description is used as the basis for correction.

[0110] 4. Knowledge storage: Build an efficient and queryable graph structure Adopt a storage architecture of "graph database as the main, relational database as the auxiliary", taking into account the semantic association ability and query efficiency of the graph: Graph database storage: Store "entity-relation-attribute" triples in Neo4j, JanusGraph and other graph databases to support efficient semantic path queries; Relational database storage: Store the basic attributes of entities (such as unit code and business rule number) in MySQL and other relational databases for fast attribute retrieval and data association.

[0111] 5. Knowledge update and maintenance: Ensure the timeliness of the graph Due to dynamic changes such as unit adjustment and business rule revision in related systems, a dual maintenance mechanism of regular update and trigger update is established: Regular update: Quarterly / annual review of relevant function adjustment files and newly published business rule sets to update entity attributes and associated relationships in the graph in batches; Triggered update: When receiving manual feedback on relevant unit responsibility adjustments (such as unit merger information submitted by the operation terminal), trigger local update of the graph immediately to ensure the accuracy of subject matching.

[0112] In the request processing technical solution of the present application, the domain knowledge graph plays a core role in supporting underlying knowledge: Provide a domain knowledge benchmark for S440 multi-modal feature fusion, calculate the semantic similarity between the request features and the graph to obtain a domain adaptation coefficient, and improve the fit degree of the second type of service scenario for the fused features; To provide a basic data source for dynamic generation of event semantic graph, when a specific request event is received, relevant responsibilities and business rule knowledge are called from the domain knowledge graph to quickly build a dedicated semantic graph for the event.

[0113] The above-mentioned fusion feature generation method, which is different from the traditional fixed weight weighted sum mode, introduces a dynamic weight distribution mechanism driven by feature contribution degree, and uses a domain adaptation coefficient to integrate domain knowledge into the feature fusion process. This method enables the final generated fusion features to more accurately adapt to the scene requirements of the second type of service request distribution processing, helping to improve the existing technology's limited generalization ability and insufficient domain adaptability in multi-modal feature fusion, thereby improving the representation accuracy of the second type of service request features. After generating the fusion feature dataset through the above steps, it is input into the pre-set multi-classifier, which outputs the corresponding second type of subject and associated docking interface information based on the high recognition semantic and scene information of the fusion features, completing the accurate distribution processing of the second type of service request.

[0114] Further, the construction process of the pre-set multi-classifier includes: S10, screening the request text data corresponding to the second label, taking the second type of subject actually processed in history as the label, screening the label categories with a sample number greater than a pre-set number threshold, and obtaining an initial training dataset.

[0115] The core purpose of this step is to build high-quality supervised training samples to ensure that the model can learn the request matching rules of various second type of subjects. The specific details are as follows: Label alignment: clearly "second label" corresponds to "second type of service request", "second type of subject" is the second type of subject (such as unit A, unit B, unit C, etc.), ensuring that the terminology is completely consistent with the previous text; Sample selection logic: the pre-set number threshold is set based on the principle of "ensuring category distinguishability", and the example threshold is set to 50, i.e. only the second type of subject categories with a sample number ≥ 50 are retained, and the small categories with insufficient sample size (such as special special processing departments) are removed, reducing the impact of sample scarcity on model learning and thus reducing distribution bias; Data cleaning and supplement: invalid data (such as missing request text and records with ambiguous historical subject labels) are removed synchronously during the screening process, and finally an initial training dataset is obtained, which corresponds one-to-one to "request text data-second type of subject label".

[0116] S11, multi-modal feature fusion processing is performed on the initial training dataset to obtain a training fusion feature dataset.

[0117] This step needs to ensure that the feature fusion strategy in the training phase is consistent with the subsequent reasoning phase (S400), ensuring the adaptability of model training and reasoning: Fusion strategy matching: according to the actual application scenario, one of the two multi-modal feature fusion implementation manners described in S400 of the preceding text (fusion based on historical associated request data / fusion based on event semantic graph) is selected; Consistency guarantee: the same feature extraction parameters (such as the vocabulary table of TF-IDF, the dictionary of one-hot encoding, and the dimension of the feature vector) as in the reasoning phase are adopted to avoid model performance deviation caused by parameter differences; Output result: a training fusion feature dataset with unified dimensions and standardized format is finally generated, and each sample of the dataset contains the corresponding relationship of "fusion feature vector-second subject label".

[0118] S12, based on the training fusion feature dataset, a preset multi-classification model is trained; during the training process, the class weight of a label category with a sample proportion lower than a preset proportion threshold is adjusted, and a comprehensive classification performance evaluation index is used for model optimization.

[0119] The core of this step is to solve the problem of unbalanced second subject sample categories and improve the recognition accuracy of the model for small categories (low-frequency request corresponding subjects). The specific details are as follows: Multi-classification model selection and strategy: the multi-classification model adopts a linear support vector classifier (LinearSVC) model or a stochastic gradient descent classifier (SGDClassifier) model with a "one-vs-rest" strategy; the "one-vs-rest" strategy decomposes "multi-second subject classification" into multiple "binary classification tasks", which is suitable for scenarios with a large number of second subject categories and can clearly determine the classification confidence of each category; Class imbalance optimization: the preset proportion threshold is exemplarily set to 5%, if the sample proportion of a certain second subject category is <5%, the weight of this category is adjusted by adjusting the class weight parameter, so that the model pays more attention to the small category samples during the training process, and avoids the model biasing towards the mainstream categories with large sample sizes. The specific weight adjustment method includes automatic balancing strategy and manual fine-tuning strategy, which can be flexibly selected according to the category distribution characteristics of the second service request.

[0120] 1. Automatic balancing strategy (recommended for second service scenarios) In an illustrative embodiment, a balanced strategy can be used to assign weights in inverse proportion to the sample proportion, and the core formula is: w k =N total / N k ×M. Wherein: w k is the weight of the kth second subject category, k takes a value from 1 to M, and M is the total number of second subject categories; N total is the total number of training dataset samples; N k The number of samples for the kth second subject category; Example calculation: if the total number of samples in the training set N total = 10000, the total number of categories M = 10, the number of samples of a small category (such as "Unit I") N k = 500 (accounting for 5%, below the preset proportion threshold of 5%), the weight w k = 10000 / (500x10) = 2 of this category; while the number of samples of a mainstream category (such as "Unit A") N k = 3000, the weight w k = 10000 / (3000x10) ≈ 0.33. Through this strategy, the model automatically reduces the weight of the mainstream category when calculating the loss function, avoiding the model biasing towards categories with more samples.

[0121] 2. Manual fine-tuning strategy (for extreme imbalance scenarios) For small categories with extremely low sample proportion (such as the second category with a proportion of <2%), further manually adjust the weight based on the automatic balancing strategy, with specific rules as follows: Sample proportion ≥ 5% (preset proportion threshold): weight = automatically balanced strategy calculation value; 2% ≤ sample proportion < 5%: weight = automatically balanced strategy calculation value x 1.5; Sample proportion < 2%: weight = automatically balanced strategy calculation value x 2.0.

[0122] Example adjustment: the weight of the above "Unit I" (5%) is 2, if a category has a proportion of 1%, the weight = (10000 / (100x10))x2 = 20, further strengthening the model's learning of extremely small categories.

[0123] During model training, the weight parameter is passed to the multi-classification model (linear support vector classifier / stochastic gradient descent classifier) through the category weight parameter, and the 5-fold cross-validation is used to monitor the recall rate change of the small category. If the recall rate of the small category after weight adjustment improves <5%, the weight coefficient is iteratively adjusted until the expectation is met.

[0124] Hyperparameter and evaluation optimization: use grid search combined with 5-fold cross-validation to optimize model hyperparameters (such as the regularization parameter C of the linear support vector classifier and the learning rate of the stochastic gradient descent classifier); the comprehensive classification performance evaluation index is clearly "macro-averaged F1 value, micro-averaged F1 value, accuracy, recall rate", among which the macro-averaged F1 value is the core optimization indicator. This comprehensive classification performance evaluation index can balance the classification performance of each category (especially small categories), meeting the business needs of accurate and complete service distribution for all categories.

[0125] S13, select historical request text data and corresponding actual processing record data as a test data set, perform performance verification on the trained multi-classification model based on the test data set, and take the multi-classification model whose performance verification result meets the preset requirement as the preset multi-classifier.

[0126] This step verifies the generalization ability of the model through an independent test data set, ensuring that the model is stable and reliable in actual scenarios. The specific details are as follows: Test data set construction: The test data set is independently extracted from the historical second-class service request data, has no intersection with the training data set, and follows the principle of consistent category distribution and real business scenario (such as the same proportion of mainstream categories and rare categories as the actual request distribution). For example, the ratio of "training set: test set = 7:3" is divided; Performance verification standard: The preset requirement is that all evaluation index values in the comprehensive classification performance evaluation index need to be greater than the corresponding preset threshold. The specific threshold setting is made in combination with the business goal of the second-class service request distribution. The example threshold is as follows: the core index macro-average F1 value ≥ 0.92 (to ensure the overall classification accuracy of all categories); the overall classification accuracy ≥ 0.90 (to ensure the accuracy of mainstream category distribution); the recall rate of all second-class subject categories ≥ 0.85 (to ensure that rare category requests are not missed). The threshold settings of the above indexes take into account the overall classification accuracy and rare category coverage, avoiding the omission of rare category request distribution due to excessive pursuit of overall accuracy, and preventing the sacrifice of classification effect of mainstream categories due to the emphasis on rare categories, which meets the core business needs of accurate distribution and no omission of second-class service requests.

[0127] Model selection and iteration: If the trained model does not meet the preset requirements, return to S12 to adjust the hyperparameters or category weight coefficients, retrain and verify; if it meets the preset requirements, determine the model as a candidate multi-classifier at the algorithm level, and after final confirmation of the production environment deployment requirements for the second-class service request distribution, it is officially used as the preset multi-classifier.

[0128] Further, to realize the engineering landing of the multi-classifier in the second-class service request processing system, after the multi-classifier training is completed and the performance verification is passed, the model solidification, format conversion and service deployment process are performed, as follows: (1) Model and associated tool solidification and preservation The joblib tool is used to complete the persistent storage of the model and supporting components, and the saved content includes: The trained multi-classifier model (linear support vector classifier / stochastic gradient descent classifier); TfidfVectorizer, which is the core tool for TF-IDF feature extraction for the request text, needs to save its vocabulary, feature dimension, stop word list, and other configuration parameters synchronously to ensure that the feature extraction logic in the inference stage is exactly the same as in the training stage; Auxiliary configuration file: contains the mapping table of the second type of subject label and unique identifier, feature dimension description, and category weight configuration record, to avoid problems such as mismatch of feature dimension and errors in label analysis in the inference stage.

[0129] (2) Model cross-language format conversion To adapt to the mainstream Java or Go language inference environment (rather than the Python environment in the training stage) of the second type of service system, the saved multi-classifier model is converted to the open neural network exchange format (ONNX) through the sklearn-onnx tool (Scikit-learn to ONNX tool) or sklearn-porter tool (Scikit-learn model conversion tool): Before conversion, verify model compatibility: 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 inference logic of the converted model; After conversion, perform consistency check: select 100 test samples to infer in the Python native model and the ONNX format model respectively, and require that the difference rate of classification results and confidence scores be ≤0.5% to ensure that the performance of the converted model is consistent with that of the original model.

[0130] (3) Model service deployment and output specification Deploy the converted ONNX format model as a RESTful microservice to adapt to the distributed deployment architecture of the second type of service system, with the following specific requirements: Deployment framework: use FastAPI or SpringBoot (adapt to Java environment) / Gin (adapt to Go environment) to build RESTful interface, support HTTP / HTTPS protocol call, interface response delay ≤50ms (meet the real-time distribution demand of the second type of service request); Service output format: use JSON standardized format, which contains the following core fields to ensure compatibility with the downstream modules of the second type of service processing system: Classification result: the second category of the second type of service request; Second subject unique identifier: the standardized code of the second subject (such as unit A code "010502"), which adapts to the subject account of the second type of service system; Confidence score: a number in the interval of 0-1, representing the reliability of the model classification result (e.g. 0.98), scores ≥ 0.85 are directly distributed, < 0.85 triggers manual review.

[0131] To verify the actual processing effect of the multi-classifier in this scheme, 26602 desensitization-processed real second-class service request historical data are 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 obtained the corresponding authorization), and the multi-classifiers trained based on LinearSVC algorithm and SGDClassifier algorithm are respectively subjected to full-dimension performance test. The test results show that the overall accuracy of the two types of models for matching the second-class subjects is about 96%, which can meet the business requirements of accurate matching of second-class service requests. The specific test data are as follows: 1. LinearSVC classifier test results

[0132]

[0133] 2. SGDClassifier classifier test results

[0134]

[0135] Note: The subject number in the table is only an example, and the actual application corresponds to a specific code.

[0136] From the above test results, it can be seen that: Overall performance: The test results show that the overall distribution accuracy of the two types of models LinearSVC and SGDClassifier is 0.96, and the weighted average precision, recall and F1 score are also 0.96. This result proves that the two types of models have stable and consistent classification performance in the second-class service request distribution scenario, and can meet the core business requirements of high-accuracy distribution. Mainstream subject distribution effect: For the core second-class subjects with sufficient sample size, the precision and recall indicators of the model are not less than 0.95, indicating that the distribution accuracy of high-frequency requests is close to complete matching, and most second-class service requests can be reliably distributed to the correct subject.

[0137] Minor subject matching effect: For the subject categories with small sample size, the model maintains a high distribution accuracy (not less than 0.94) and effectively controls the misdistribution rate. Although the recall rate is lower than that of the mainstream category, it is still maintained at an acceptable level. This performance characteristic meets the core business needs of the second service scenario, which is to prioritize distribution accuracy and strictly control distribution errors. Model performance characteristic analysis: The LinearSVC model exhibits better accuracy when dealing with minor categories, while the SGDClassifier model shows slightly higher recall rate on specific subjects (such as "second subject 12"). Both models can achieve an overall distribution accuracy of about 96%, providing an objective performance basis for model selection under different business priorities (accuracy first or recall first).

[0138] Further, in S400, the fusion feature dataset is input into a preset multi-classifier to output corresponding second-class subjects and associated docking interface information. The core is to improve the accuracy of second-class service distribution through a dual mechanism of model prediction and knowledge graph verification. The specific steps include: S441, input the fusion feature dataset into a preset multi-classifier to output corresponding second-class subject candidate results.

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

[0140] S442, query the domain knowledge association relationship in the event semantic graph corresponding to the candidate result.

[0141] Based on the candidate subjects and auxiliary category labels output by S441, the event semantic graph constructed previously is queried to extract the domain knowledge association relationship strongly associated with the candidate results. The core query content includes three types of core information: Responsibility range association of candidate subjects: such as "Unit A" corresponding to "specific state handling, related facility maintenance", etc. Request category is associated with the historical processing of the candidate subject: such as "specific state processing, related facility maintenance" category, the historical processing success rate and matching frequency of "unit A"; Business rule set adaptation association: such as "specific state processing, related facility maintenance" corresponding to the business rules specified in the subject division (such as "related field rule document A" specifies that "unit A is responsible for the state processing of specific areas").

[0142] After querying, the mapping table of "candidate subject-field knowledge association relationship" is generated, which provides the basis for subsequent adaptation degree verification.

[0143] S443, based on the field knowledge association relationship, the association adaptation degree of the candidate result is verified, the comprehensive adaptation degree corresponding to each candidate result is obtained, and the confidence score of each candidate result is adjusted based on the comprehensive adaptation degree, and the second type of subject and the associated docking interface information with the optimal confidence score are output.

[0144] The core logic of association adaptation degree verification is: taking the second type of service field knowledge (responsibility, business rule, historical data) in the event semantic graph as the objective basis, the candidate subjects output by the multi-classifier are quantified by dimension first and then summarized to complete the adaptation degree evaluation, to ensure that the verification result meets 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 Verification preposition: clear basic input and core basis Core input: candidate subject list output by multi-classifier (such as "unit A" and "unit G"), initial confidence score of each candidate subject; Verification basis: three types of core field knowledge retrieved from the event semantic graph: ① the legal responsibility list of the candidate subject; ② the business rule set articles (including responsibility division) matched with the current request; ③ the historical processing records (including processing success rate) of the same type of request; Pre-set rule: set the three-dimensional verification weight (responsibility matching degree 0.5, business rule adaptation 0.3, historical processing adaptation 0.2) and the comprehensive adaptation degree screening threshold (≥0.6) in advance to ensure the uniformity and reusability of the verification standard.

[0145] 1.2 Dimensional quantification verification (core link) According to the priority order of "responsibility → business rule → history", the quantification scoring of each dimension is completed one by one (the full score is 1.0), and the verification of each dimension relies on the event semantic graph for objective evaluation: Dimension 1: responsibility matching degree verification (weight 0.5) Logic: judge whether the legal responsibility of the candidate subject covers the core demand of the current request; Step: ① Parse the core requirements from the text-enhanced content (e.g., "functional status recovery of a specific area"); ② Retrieve the responsibility nodes of candidate subjects in the event semantic graph (e.g., "Unit A -> specific area state maintenance"); ③ Quantify the score according to the rules of "complete match (1.0 points), partial match (0.6-0.9 points), no match (0.0-0.5 points)" (matching basis is the pre-defined "responsibility-request keyword mapping relationship" in the graph).

[0146] Dimension 2: Business rule adaptability verification (weight 0.3) Logic: Verify whether the candidate subject meets the responsibility division of the business rule set to ensure the legality of service request distribution; Step: ① Retrieve the business rule clauses corresponding to the request in the event semantic graph (e.g., "related domain rule document A"); ② Extract the subject division in the clauses (e.g., "a certain department is responsible for handling a specific type of state"); ③ Quantify the score according to the rules of "clear subject (1.0 points), collaborative 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: Judge the actual ability of the candidate subject to handle similar requests based on historical data to ensure the effectiveness of distribution; Step: ① Retrieve the historical processing records of similar requests in the event semantic graph; ② Calculate the historical processing success rate of the candidate subject (number of successful cases / total number of processing cases); ③ Directly use the processing success rate as the score of this dimension (e.g., a success rate of 96% scores 0.96 points).

[0148] 1.3 Comprehensive adaptability score The three-dimensional scores are weighted and summed according to the pre-set weights to obtain the comprehensive adaptability score of each candidate subject, the formula is: Comprehensive adaptability score = responsibility matching degree x 0.5 + business rule adaptability x 0.3 + historical processing adaptability x 0.2.

[0149] Then filter according to the pre-set threshold (≥0.6): keep the candidate subjects with a score ≥0.6, and directly eliminate those with a score <0.6 (determined as insufficient adaptability, unable to meet the distribution requirements).

[0150] The comprehensive adaptability score of each candidate subject obtained through the above correlation adaptability verification is the core basis for subsequent confidence adjustment. The candidate subjects with qualified adaptability are selected in the verification stage, and the initial confidence is corrected based on the comprehensive adaptability correction model in the adjustment stage, finally realizing the dual protection of algorithm prediction and business knowledge calibration.

[0151] In the present application, the core logic of confidence adjustment is to correct the initial confidence of multi-classifier output with comprehensive adaptation score, to weaken the deviation of pure algorithm prediction, and to make the final confidence reflect both feature matching degree (model level) and business adaptation degree (domain knowledge level). The specific process is as follows: 2.1 Final confidence calculation In an illustrative embodiment, the final confidence of each retained candidate subject is calculated using the correction formula "model initial confidence x comprehensive adaptation score", and the formula is: C u =C initial x S. Wherein C u is the final confidence score of the candidate subject after dynamic correction, C initial is the initial confidence score output by the multi-classifier, and S is the comprehensive adaptation score.

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

[0153] The value of the candidate subject dynamic state correction factor is calculated dynamically according to the current state of the candidate subject, and the specific calculation rule is: .

[0154] Wherein b is the state influence coefficient, taking the value of 0.1-0.3, which is calibrated by historical candidate subject dynamic adjustment cases, and is used to quantify the influence strength of different states on confidence; U is the current state identifier of the candidate subject, U=1 represents the new state, U=2 represents the merging state, U=3 represents the normal state, and U=4 represents the responsibility adjustment state; A is the number of similar work orders that the new state candidate subject has undertaken; A total is the average number of work orders undertaken by the core candidate subject of the same type, which is used to evaluate the business adaptation maturity of the new subject; γ1 and γ2 are the historical state correction factors of the two original candidate subjects participating in the merging (i.e. the γ values of the two subjects before merging); Δt is the time span after the candidate subject completes the responsibility adjustment (unit: day); T is the adaptation period threshold after responsibility adjustment (default 90 days), and the negative impact of state on confidence is gradually reduced during the adaptation period.

[0155] In the present application, the work order is a standardized processing document generated after classification, feature extraction, subject matching and other processing based on request text data. Its core information comes from the analysis result of the request text data, and is used to support the subsequent distribution and processing tracking of the request. The new state refers to the newly established second type of service candidate subject (such as a newly added second type of service center or a newly established department after function transfer) that first accesses the request processing system. The merged state refers to the integration of two or more original candidate subjects into a new subject (such as the merger of "Unit A" and "Unit D" into "Unit G"). The two units before the merger refer to the two original second type of subjects participating in the integration. The normal state refers to the unchanged responsibility range and organization setup of the candidate subject, which is in the normal business operation state. The responsibility adjustment state refers to the increase or decrease of the core responsibility of the candidate subject, but the subject organization does not merge or split.

[0156] The present embodiment quantifies the influence of the dynamic state of the candidate subject on the distribution confidence by introducing a candidate subject dynamic state correction factor, realizes flexible adaptation to dynamic scenarios such as new, merged, and responsibility adjustment, and solves the core pain points in the prior art that the distribution model relies on fixed candidate subject information and is difficult to adapt to the dynamic adjustment of the second type of service unit. Without reconstructing the model, the state change of the candidate subject can be quickly connected, and the system iteration and maintenance cost is reduced.

[0157] 2.2 Optimal candidate subject screening and bottom-up mechanism Optimal result screening: The retained candidate subjects are sorted in descending order according to the final confidence score, and the subject with the highest score is selected as the optimal second type of subject; the associated interface information of the subject (such as service hotline, work order docking API, and standardized coding) is extracted synchronously.

[0158] Bottom-up mechanism: If the following two extreme cases occur, the bottom-up mechanism is triggered: ① The comprehensive adaptation score of all candidate subjects is less than 0.6 (no qualified candidate); ② The final confidence of the retained candidate subjects is less than 0.5 (qualified candidate but insufficient confidence); at this time, the request is marked as "to be manually reviewed", and the complete verification details (including the three-dimensional score, comprehensive adaptation, initial / final confidence of each candidate subject) are output, providing 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 docking interface information, and complete the processing of the request text data.

[0160] If the pre-processed text data is matched to the first type of subject, or the optimal second type of subject is determined by S400 processing (the final confidence is greater than or equal to the preset bottom threshold), the unique identification (such as the second type of service standardized code) and the standardized interface information (including service contact identification, work order docking API address, data interaction protocol specification) of the corresponding subject are directly outputted, and the unique identification and the standardized interface information of the subject 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 of the optimal second type of subject output by the multi-classifier is lower than the preset threshold (such as the value set in S443 in the foregoing is greater than or equal to 0.5), an artificial intervention bottom-up process is triggered. Specifically, the first N candidate second type of subjects (N is greater than or equal to 2, and the specific value can be configured according to the second type of service operation and maintenance efficiency requirement) and the final confidence scores of the candidate second type of subjects are outputted, and the candidate list, the confidence details and the foregoing verification dimension data (responsibility / business rule / history adaptation score) are synchronously pushed to the operation and maintenance terminal; after obtaining the confirmed target second type of subject (the feedback mode includes but is not limited to manual check confirmation and system submission entry) fed back by the operation and maintenance terminal, the unique identification and the docking interface information of the confirmed subject are outputted, and the final closed-loop processing of the request text data is completed.

[0162] The technical solution provided by the application can be widely applied to the automatic processing scene of a plurality of external subjects and complex request text.

[0163] One of the typical application scenarios is a request processing system. The request processing system receives a large amount of user requests from multiple channels such as telephone, mobile application and on-site patrol every day, and the contents cover facility state report, order management request and consumer dispute involving e-commerce and logistics. The traditional processing method relies on manual screening and distribution, and the efficiency is low. By applying the application, the system can automatically process all unstructured requests: first, the first type of service request and the second type of service request are distinguished by the binary classifier; for the first type of request, it is quickly matched to the corresponding first type of service platform after-sales interface; for the second type of request, the multi-dimensional information such as location, time and historical processing record is fused, and the event semantic graph (containing subject responsibility, business rule set and other knowledge) is combined to accurately match to the corresponding facility maintenance type of subject, order management type of subject and market behavior supervision type of subject for processing, thereby realizing unified acceptance and collaborative processing of cross-class requests.

[0164] Another typical scenario is the unified customer complaint center of a large enterprise or platform. The complaints it receives may involve transaction disputes on its own e-commerce platform, logistics and distribution problems, and even feedback related to the location of the platform's merchants, such as site safety and environmental hygiene. By applying the present application, a knowledge base and graph adapted to the enterprise scenario can be constructed to achieve integrated classification and diversion of internal and external problems: pure transaction problems are matched to the internal customer service system, logistics problems are connected to external logistics service providers, and social affairs-related problems are transferred to relevant external processing systems through standardized interfaces, thereby improving overall complaint handling efficiency and user satisfaction.

[0165] The present application optimizes the mechanisms of traditional text processing methods in feature utilization, knowledge fusion, and dynamic adaptation through the synergy of three technologies: staged linear discriminant model, multi-modal semantic understanding, and event semantic graph. 1. Improved discriminant performance of classification model in complex scenarios Through the staged linear model architecture, the request is first divided by a binary classifier, and then processed in depth by a specialized model. This design enables the model to be optimized for different feature distributions of different domains, achieving high precision and recall rates in classification tasks for multiple core fixed subjects, which helps to reduce misjudgment and omission caused by feature confusion in single models in cross-domain and multi-class scenarios, and improves the stability of overall classification.

[0166] 2. Enhanced deep semantic understanding and structured knowledge fusion capability Unlike keyword-based text processing methods, this solution integrates multi-modal features such as text, time and space, and historical context, and converts unstructured requests into structured representations containing semantic relationships through a domain-adaptive large model. Further introduction of event semantic graph integrates external domain knowledge with request representation in a networked form, allowing the decision-making process to consider both semantic associations and business rule constraints, thereby improving the depth of understanding and rationality of decision-making in handling complex requests with ambiguous semantics and missing elements.

[0167] 3. Scalability and external knowledge adaptation capability The loosely coupled design based on multi-modal structured features and event semantic graph makes the method adaptable to external changes. When the subject is added, merged, or adjusted, the core classification model does not need to be retrained, only the entities, relationships, and attributes in the event semantic graph need to be updated incrementally, and new knowledge can be integrated into the decision-making process through the graph and feature mapping mechanism. This mechanism helps to reduce the technical cost and maintenance complexity of large-scale iteration due to changes in business rules.

[0168] The embodiment of the present application further provides an electronic device, comprising: at least one processor; and a memory connected with the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are configured to execute the method of the embodiment of the present application.

[0169] The embodiment of the present application further provides a computer readable storage medium, which stores computer executable instructions, and the computer executable instructions are used for executing the method of the embodiment of the present application.

[0170] It should be understood that the steps shown above in various forms of flow can be reordered, added or deleted. For example, the steps described in the present application can be executed in parallel, sequentially or in different order, as long as the desired results of the technical solutions disclosed in the present application can be achieved, which is not limited herein.

[0171] The above detailed description does not constitute a limitation on the protection scope of the present application. 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 modification, equivalent replacement and improvement within the spirit and principle of the present application should be included in the protection scope of the present application.

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 using a named entity recognition model; Using the target entity features as search criteria, a matching process is performed in a preset historical knowledge base to determine the corresponding first type of subject and associated interface information; 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; 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.

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, Prior to the multimodal feature fusion process, an event semantic graph construction step is also included: 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.

6. The method according to claim 5, 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 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-related features are concatenated and fused to obtain the fused feature dataset.

7. The method according to claim 6, characterized in that, 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.

8. 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.

9. 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 8 by invoking programs or instructions stored in the memory.

10. 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 8.

Images