Multi-dimensional knowledge extraction construction method and system applied to operation and maintenance technical service

Abstract

The application provides a multi-dimensional knowledge extraction construction method and system applied to operation and maintenance technical services, relates to the field of operation and maintenance technical services, and first acquires operation and maintenance service full record generated in the operation and maintenance technical service process, then carries out associated network construction processing on the operation and maintenance service full record, and obtains a target associated network structure. Based on the structure, a core record cluster is identified, complementary operation and maintenance information is extracted and fused to form an operation and maintenance knowledge module set. Then, the operation and maintenance knowledge module set is subjected to dynamic knowledge system construction processing, and a target operation and maintenance knowledge system with self-adjusting capability is formed. Finally, based on the target operation and maintenance knowledge system, for a newly received operation and maintenance service request, an operation and maintenance service response content containing resource optimization suggestions is generated, and the operation and maintenance service quality and efficiency are effectively improved.

Description

Technical Field

[0001] This invention relates to the field of operation and maintenance technical services, and more specifically, to a method and system for multi-dimensional knowledge extraction and construction applied to operation and maintenance technical services. Background Technology

[0002] In the field of operations and maintenance (O&M) technical services, with the increasing complexity and diversification of information systems, the amount of data generated during O&M is growing explosively. This data covers a variety of O&M scenarios, including but not limited to system fault diagnosis, software update and deployment, and hardware equipment maintenance. Currently, O&M technical services mainly rely on O&M personnel to manually organize and analyze this massive amount of data in order to accumulate O&M experience and form a knowledge system.

[0003] However, existing methods for building operational knowledge have many drawbacks. On the one hand, manually organizing data is inefficient; operations personnel need to spend a significant amount of time and effort sifting through massive amounts of operational service records to extract useful information, and key content is easily overlooked. On the other hand, operational knowledge systems built using traditional methods are often static, lacking flexibility and adaptability. In actual operational scenarios, service execution processes differ across scenarios, and operational needs are dynamically adjusted as systems are continuously updated and changed. Static knowledge systems struggle to update and adjust in a timely manner to these changes, resulting in an inability to provide accurate and effective resource optimization suggestions and operational service responses when faced with new operational service requests, thus affecting the quality and efficiency of operational services. Summary of the Invention

[0004] In view of the aforementioned problems, and in conjunction with the first aspect of the present invention, embodiments of the present invention provide a multi-dimensional knowledge extraction and construction method for operation and maintenance technical services, the method comprising:

[0005] The system acquires a full record of operations and maintenance services generated during the operation and maintenance technical service process. The full record of operations and maintenance services includes service request text, execution operation sequence, resource call record and service effect feedback text under multiple operation and maintenance scenarios, and each operation and maintenance scenario corresponds to at least two sets of service execution process records with differences.

[0006] The entire record of the operation and maintenance service is processed to construct an association network, and the association edges between each operation and maintenance service record are established to obtain the target association network structure.

[0007] Based on the target association network structure, identify the core record clusters with correlation in the target association network structure, extract complementary operation and maintenance information from each operation and maintenance service record in the core record cluster, and fuse them to form an operation and maintenance knowledge module with scenario adaptability, thus obtaining a set of operation and maintenance knowledge modules.

[0008] The set of operation and maintenance knowledge modules is dynamically constructed to form a target operation and maintenance knowledge system with self-adjustment capabilities.

[0009] Based on the target operation and maintenance knowledge system, for newly received operation and maintenance service requests, an operation and maintenance service response content containing resource optimization suggestions is generated.

[0010] In another aspect, embodiments of the present invention also provide a multi-dimensional knowledge extraction and construction system for operation and maintenance technical services, including a processor and a machine-readable storage medium. The machine-readable storage medium is connected to the processor. The machine-readable storage medium is used to store programs, instructions, or code. The processor is used to execute the programs, instructions, or code in the machine-readable storage medium to implement the above-described method.

[0011] Based on the above, by comprehensively acquiring full records of operation and maintenance services containing rich information across multiple operation and maintenance scenarios, and performing relational network construction on these full records, a target relational network structure is formed by establishing correlation edges between records. This structure reveals the inherent connections between records in different operation and maintenance scenarios, uncovering potential knowledge hidden within massive amounts of data. Based on this target relational network structure, core record clusters are identified and complementary operation and maintenance information is extracted and integrated to form a set of operation and maintenance knowledge modules with scenario adaptability. This ensures that each knowledge module accurately corresponds to a specific operation and maintenance scenario, improving the relevance and practicality of the knowledge. Dynamic knowledge system construction is then performed on the set of operation and maintenance knowledge modules to form a self-adjusting target operation and maintenance knowledge system. This system can adjust its content in real time according to changes in operation and maintenance scenarios and new operation and maintenance service requests, ensuring the timeliness and accuracy of the knowledge system. Finally, based on the target operation and maintenance knowledge system, operation and maintenance service response content containing resource optimization suggestions is generated, effectively improving the quality and efficiency of operation and maintenance services and reducing operation and maintenance costs. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of the execution flow of the multi-dimensional knowledge extraction and construction method for operation and maintenance technical services provided in this embodiment of the invention.

[0013] Figure 2 This is a schematic diagram of exemplary hardware and software components of a multi-dimensional knowledge extraction and construction system for operation and maintenance technical services provided in an embodiment of the present invention. Detailed Implementation

[0014] The present invention will now be described in detail with reference to the accompanying drawings. Figure 1 This is a flowchart illustrating a multi-dimensional knowledge extraction and construction method for operation and maintenance technical services provided in one embodiment of the present invention. The following is a detailed description of this multi-dimensional knowledge extraction and construction method for operation and maintenance technical services.

[0015] Step S110: Obtain the full set of operation and maintenance service records generated during the operation and maintenance technology service process. The full set of operation and maintenance service records includes service request texts, execution operation sequences, resource call records, and service effect feedback texts under multiple types of operation and maintenance scenarios, and each type of operation and maintenance scenario corresponds to at least two sets of service execution process records with differences.

[0016] In this embodiment, the operation and maintenance service of Internet of Things intelligent home control is used as the application scenario. The multiple types of operation and maintenance scenarios specifically include operation and maintenance of intelligent lighting control failures, operation and maintenance of intelligent curtain control failures, operation and maintenance of intelligent temperature control equipment failures, operation and maintenance of intelligent security equipment failures, and operation and maintenance of multi-device linkage control failures, etc. The obtained full set of operation and maintenance service records covers the complete service data under the above various scenarios.

[0017] The service request text includes the fault descriptions submitted by users through the intelligent home APP, voice assistant, or customer service hotline, such as "The intelligent lighting in the living room cannot be turned on through the APP", "The response of the intelligent curtain in the bedroom is delayed", "The temperature displayed by the intelligent thermostat does not match the actual temperature", etc. The execution operation sequence is the operation steps executed by the operation and maintenance personnel for the fault. For example, for the fault that the intelligent lighting cannot be turned on, the execution operation sequence may be "Check the device network connection status - Restart the router - Reset the intelligent lighting device - Reconfigure the network - Test the control function".

[0018] The resource call record involves various types of resource information called during the operation and maintenance process, including computing power resources of the remote operation and maintenance platform, firmware upgrade package resources of the device manufacturer, device log query interface resources of the cloud platform, etc. For example, call the instruction sending interface of the remote operation and maintenance platform to send a reset instruction to the intelligent lighting device, and call the cloud server of the device manufacturer to obtain the latest firmware version.

[0019] The service effect feedback text is the evaluation submitted by the user after the operation and maintenance is completed, such as "The fault has been resolved, and the lighting control has returned to normal", "The response speed of the curtain has improved, but it is still occasionally delayed", "The thermostat displays normally, and the usage experience is good", etc. Each type of operation and maintenance scenario includes at least two sets of service execution process records with differences. For example, in the operation and maintenance scenario of intelligent lighting control failure, one set of execution operation sequences includes "Check the network - Restart the device - Reconfigure the network", and the other set includes "Check the power supply - Replace the device module - Reconfigure the network", and there are obvious differences between the two execution processes.

[0020] During the obtaining process, for information containing user privacy (such as user home address, contact information, device usage habits, etc.), privacy protection processing is adopted. Specifically, personal identification information in the service request text and feedback text is removed through data de-sensitization technology, the unique user device identifier in the resource call record is encrypted, stored using a symmetric encryption algorithm, and only authorized operation and maintenance personnel can obtain it through the decryption interface to prevent the leakage of privacy information.

[0021] Step S111: Deploy operation and maintenance service record collection nodes, which are respectively connected to the operation and maintenance service request acceptance system, the operation and maintenance operation execution system, the resource scheduling system and the service evaluation feedback system.

[0022] Distributed data acquisition nodes are deployed in the IoT smart home control and maintenance service platform. These nodes establish stable connections with the maintenance service request acceptance system, maintenance operation execution system, resource scheduling system, and service evaluation feedback system via TCP / IP protocol. Each acquisition node has a built-in data acquisition agent program that supports real-time monitoring of data streams from each system and also features breakpoint resume functionality, automatically re-acquiring recorded data during the interruption period once network interruption is resolved.

[0023] The data collection node is also equipped with a data filtering module, which can filter out invalid data (such as repeatedly submitted empty request text or incorrectly formatted operation sequences) according to preset rules, ensuring the validity of the collected data. In addition, the data collection node and each system use an encrypted transmission channel, and the transmitted data is encrypted using the SSL protocol to prevent the data from being tampered with or stolen during transmission.

[0024] Step S112: Collect the submission time of all service requests, the terminal identifier of all service requests, and the service request text of all service requests from the operation and maintenance service request acceptance system to form a subset of request records.

[0025] The maintenance service request handling system receives service requests from multiple channels, including smart home apps, voice assistants, and customer service hotlines. The data collection node extracts the submission time (accurate to the second), the identifier of the requesting terminal (such as the app's device ID, the voice assistant's device serial number, or the encrypted caller ID of the customer service hotline), and the service request text for each service request from this system.

[0026] For example, a request record from a smart home app includes the submission time, the app device ID, and the service request text "The living room smart security camera cannot record"; a request record from a voice assistant includes the submission time, the voice assistant device serial number, and the service request text "The kitchen smart smoke detector is giving a false alarm". Organizing this information according to the structure "submission time - request initiating terminal identifier - service request text" forms a subset of request records.

[0027] Step S113: Collect the operation execution account, the execution operation sequence, the operation start time, the operation end time, and the operation process log for each service request from the operation and maintenance operation execution system to form a subset of operation records.

[0028] The operation and maintenance execution system provides an interface for operation and maintenance personnel, recording data throughout the entire operation and maintenance process. Data collection nodes are associated with the corresponding operation execution account (operation and maintenance personnel's employee ID), the execution operation sequence (stored as a list of steps), the operation start time, the operation end time, and the operation process log (e.g., "2024-05-20 10:00: Started checking camera network connection, showing offline" and "2024-05-20 10:05: Restarted camera power, device online").

[0029] For example, in response to a service request that “the smart security camera in the living room cannot record,” the collected operation logs include the employee ID of the maintenance personnel, the sequence of operations performed (“check network - restart device - check storage settings - test recording function”), the start time of the operation, the end time of the operation, and a detailed operation process log. The above information is linked and integrated to form a subset of operation logs.

[0030] Step S114: Collect the resource type, resource identifier, start time, end time, and usage status of each service request from the resource scheduling system during the execution of each service request, forming a subset of resource records.

[0031] The resource scheduling system is responsible for managing various resources required during operation and maintenance. The collection nodes collect resource call information corresponding to each service request from this system. Resource types include remote command issuance interfaces, device log query interfaces, firmware upgrade packages, cloud storage space, etc. Resource identifiers are unique identifiers for various types of resources, such as the URL address of the interface, the file number of the firmware upgrade package, the space ID of the cloud storage, etc.

[0032] Simultaneously, the start time, end time, and usage status (e.g., "successful call," "failed call," "resource in use") of resource calls are collected. For example, in the case of a smart camera failing to record video, the collected resource records include the resource type, interface URL, call start time, call end time, and usage status of "successfully obtained logs" for calling the "camera log query interface," and the resource type, space ID, call time, and usage status of "sufficient storage space" for calling "cloud storage space." This information constitutes a subset of the resource records.

[0033] Step S115: Collect the evaluation submission time, evaluation initiation terminal identifier, service effect feedback text, and rating information of each service request from the service evaluation feedback system to form a subset of feedback records.

[0034] The service evaluation feedback system receives evaluation data submitted by users after the completion of operation and maintenance services. The collection nodes collect the evaluation submission time, evaluation initiation terminal identifier (consistent with the request initiation terminal identifier), service effect feedback text, and rating information (usually a satisfaction rating of 1-5 points) for each service request from the system.

[0035] For example, a user's feedback record after a smart light malfunction was fixed includes the evaluation submission time, the APP device ID, the feedback text "Light control is back to normal, and the response is timely," and a rating of 5 points; another user's feedback record regarding the maintenance of smart curtains includes the evaluation submission time, the voice assistant device serial number, the feedback text "The curtain response is still delayed," and a rating of 3 points. This information is integrated to form a subset of the feedback records.

[0036] Step S116: Based on the unique identifier of the service request, associate and integrate the corresponding records in the request record subset, operation record subset, resource record subset and feedback record subset to form each operation and maintenance service record containing complete information. Summarize all the associated and integrated operation and maintenance service records to obtain the full operation and maintenance service record.

[0037] For example, step S1161: Extract the unique service request identifier of each record in the request record subset, and use the unique service request identifier as the associated keyword.

[0038] Each record in the request record subset contains a unique service request identifier automatically generated by the system. This unique identifier consists of a date code, a request channel code, and a random sequence. This unique identifier is extracted as a correlation keyword to associate corresponding records in other subsets. For example, a request record may have the unique identifier "20240520-APP-001," which can be used as a keyword to associate operation, resource, and feedback records.

[0039] Step S1162: In the operation record subset, find all corresponding operation records based on the unique identifier of the service request. If there are multiple operation records, sort them according to the order of the operation start time to form an operation record sequence.

[0040] Within the operation log subset, a search is performed based on the unique service request identifier "20240520-APP-001" to find all corresponding operation records. If multiple operation records are generated during the operation and maintenance process due to the failure to resolve the fault in one go (e.g., the first operation and maintenance failed, and a second operation and maintenance was performed to supplement the operation), the above records are sorted according to the order of operation start time to form an operation record sequence, ensuring the temporal integrity of the operation process.

[0041] Step S1163: In the resource record subset, find all corresponding resource records based on the unique identifier of the service request, align the resource records with the operation record sequence according to the order of resource call start time of the resource records, and determine the resource call record corresponding to each operation step in the operation record sequence.

[0042] The corresponding resource record is located in the resource record subset based on the unique identifier of the service request. Then, the resource records are time-aligned with the operation record sequence according to the order of resource call start times. For example, the resource record corresponding to the step "check device network connection status" in the operation record sequence is "call network status query interface", and the resource record corresponding to the step "reset smart lighting device" is "call device reset command interface". The precise correspondence between each operation step and the resource call is achieved through timestamp matching.

[0043] Step S1164: In the subset of feedback records, find the corresponding feedback record based on the unique identifier of the service request. If there are multiple feedback records, select the feedback record with the latest submission time as the valid feedback record.

[0044] The system searches for the corresponding feedback record in the subset of feedback records based on the unique identifier of the service request. If a user submits multiple feedbacks for the same service request (e.g., the first feedback is not resolved and the maintenance personnel submit a second feedback after handling it again), the feedback record with the latest submission time is selected as the valid feedback record to ensure that the feedback information reflects the final service effect.

[0045] Step S1165: Integrate the fields of the request record, the sorted sequence of operation records, the time-aligned resource call record, and the valid feedback record so that each integrated record contains complete fields of four types of information: request, operation, resource, and feedback.

[0046] The aforementioned associated request records, operation record sequences, resource call records, and valid feedback records are integrated at the field level. Each integrated record includes request fields (submission time, terminal identifier, request text), operation fields (execution account, operation sequence, start and end time, process log), resource fields (resource type, identifier, call time, usage status), and feedback fields (evaluation time, feedback text, rating), thus achieving information integrity for a single service record.

[0047] Step S1166: Perform information integrity verification on each integrated record, check whether there are any missing fields or invalid field content in each integrated record. If so, re-collect the information of the missing or invalid fields from the corresponding collection system and supplement them into the integrated record. The integrated record that passes the verification and has complete information is determined as the operation and maintenance service record containing complete information.

[0048] The integrated records undergo integrity verification to check for issues such as empty request text, missing key steps in the operation sequence, unrecorded resource identifiers, and invalid feedback text. If the "Resource Call Usage Status" field is missing in an integrated record, this field information is retrieved again from the resource scheduling system; if the "Operation Process Log" field is corrupted or invalid, it is retrieved again from the operations and maintenance execution system. The integrated records that pass verification are considered complete operations and maintenance service records, and all such records are aggregated to form the full operations and maintenance service record.

[0049] Step S120: Perform association network construction processing on the full record of the operation and maintenance services, establish association edges between each operation and maintenance service record, and obtain the target association network structure.

[0050] For the full records of IoT smart home control and maintenance services, an association network is constructed by analyzing the correlation between different service records in four dimensions: requests, operations, resources, and feedback. Each maintenance service record is a node in the network. When two records have high correlation in multiple dimensions, an association edge is established between them and a correlation strength value is assigned, ultimately forming a target association network structure that includes nodes, association edges, and strength values.

[0051] Step S121: Perform problem feature extraction processing on the service request text of each operation and maintenance service record, extracting problem type keywords, fault phenomenon description phrases, and service target statements from the service request text to form a request feature vector for each operation and maintenance service record.

[0052] Natural language processing (NLP) techniques are used to extract problem features from service request texts. First, the request text is broken down into independent words using a word segmentation algorithm. Then, nouns, verbs, and other keywords are selected through part-of-speech tagging. Finally, a domain dictionary (containing IoT smart home operation and maintenance terms such as "smart lights," "network connection," "cannot be turned on," and "response delay") is used to extract problem type keywords, fault phenomenon description phrases, and service goal statements.

[0053] For example, for the service request text "The smart lights in the living room cannot be turned on via the APP, and the remote control function needs to be restored," the extracted problem type keywords are "smart lights, APP control, remote control," the fault description phrase is "cannot be turned on via the APP," and the service goal is "restore the remote control function." These features are then vectorized, and each feature is mapped to a fixed-dimensional numerical vector using word embedding technology. These vectors are then concatenated to form the request feature vector for the service record. This request feature vector is a multi-dimensional numerical vector, with each dimension corresponding to the embedding value of a feature.

[0054] Step S122: Calculate the cosine similarity between the request feature vectors of any two operation and maintenance service records, and determine the cosine similarity as the question similarity of the service request text of the two operation and maintenance service records.

[0055] For any two operation and maintenance service records (denoted as record A and record B), obtain their request feature vectors. The process of calculating cosine similarity is as follows: first, calculate the dot product of the two vectors, that is, multiply the corresponding dimension values ​​and then sum them; then, calculate the magnitude of each vector, that is, the square root of the sum of the squares of each dimension value; finally, divide the dot product result by the product of the two magnitudes to obtain the cosine similarity value. The range of this cosine similarity value is between 0 and 1, and the closer it is to 1, the higher the similarity of the service request text questions of the two records.

[0056] For example, the cosine similarity calculated between the request feature vectors of record A and record B is 0.85, indicating that their service requests are highly similar in terms of problem type, fault phenomenon, and service objective, and may both be related to remote control faults in smart lights. This cosine similarity can be directly determined as the problem similarity between the two record service request texts.

[0057] Step S123: Decompose the execution operation sequence of each operation and maintenance service record into multiple consecutive operation step units, count the number of completely identical steps in the operation step units of any two operation and maintenance service records, and determine the step overlap degree of the execution operation sequence of the two operation and maintenance service records by the ratio of the number of steps to the total number of steps in the two operation and maintenance service records.

[0058] The execution sequence of each operation and maintenance service record is broken down into independent operation step units according to the logical order of the operations. For example, the execution sequence "Check device network connection status - Restart router - Reset smart lighting device - Reconfigure network - Test control function" is broken down into five step units: "Check device network connection status", "Restart router", "Reset smart lighting device", "Reconfigure network", and "Test control function".

[0059] For any two records, count the number of steps that are completely identical in both. For example, if record C has steps [step 1, step 2, step 3, step 4] and record D has steps [step 1, step 2, step 5, step 6], the number of identical steps is 2. The total number of steps for the two records is the sum of the number of steps in record C and the number of steps in record D, i.e., 4 + 4 = 8. The step overlap is the ratio of 2 to 8, i.e., 0.25. If the number of steps for the two records is different, calculate using the same method to ensure that the step overlap reflects the similarity of the operation sequences.

[0060] Step S124: Perform type classification processing on the resource call records of each operation and maintenance service record, and divide the resource call types into hardware resource calls, software resource calls, and network resource calls. Count the number of resource types that are called in common between any two operation and maintenance service records, and determine the type correlation degree of the resource call records between the two operation and maintenance service records by the ratio of the number of common resource types to the total number of resource types in the two operation and maintenance service records.

[0061] Resource call records are categorized by type: hardware resource calls include calls to device debugging tools and hardware testing equipment; software resource calls include calls to firmware upgrade packages, operation and maintenance management software, and cloud platform interfaces; and network resource calls include calls to remote network diagnostic services and bandwidth resources. For example, if a record calls both the "Device Log Query Interface" (software resource) and the "Remote Network Diagnostic Service" (network resource), then its resource call type is software resource call and network resource call.

[0062] For any two records, count the number of resource types they commonly use. For example, record E uses [software resource, network resource], and record F uses [hardware resource, software resource], so the number of resource types they commonly use is 1. The total number of resource types for the two records is 2 + 2 = 4, and the type correlation is the ratio of 1 to 4, which is 0.25. If one record uses three resource types and the other uses two, and there are two common types, then the number of common types is 2, the total number is 3 + 2 = 5, and the type correlation is 2 / 5.

[0063] Step S125: Perform sentiment analysis on the service effect feedback text of each operation and maintenance service record to determine whether the evaluation sentiment of the service effect feedback text is positive, neutral or negative, and map each evaluation sentiment to a preset continuous numerical score. For any two operation and maintenance service records, calculate the similarity of the numerical scores of the evaluation sentiments of the two records, and determine the similarity as the convergence of the evaluation of the service effect feedback texts of the two operation and maintenance service records.

[0064] A sentiment analysis model is used to process service feedback texts. This model is trained to identify sentiment words and semantic tendencies in the text to determine the evaluation bias. Positive evaluations include "The fault has been resolved and the system is working normally," neutral evaluations include "The fault has been partially resolved, but further observation is needed," and negative evaluations include "The fault has not improved after maintenance."

[0065] The three evaluation tendencies are mapped to preset continuous numerical scores. For example, positive evaluations are mapped to a higher numerical range, neutral evaluations to a middle numerical range, and negative evaluations to a lower numerical range. To calculate the convergence of evaluations between two records, the numerical scores of both records are first obtained. Then, the absolute value of the difference between the two scores is calculated. The ratio of this absolute value to the score range is subtracted from 1 to obtain the convergence value. This convergence value also ranges from 0 to 1; the closer the value is to 1, the more consistent the service effectiveness feedback evaluation tendencies of the two records.

[0066] For example, record G has a positive evaluation tendency and a high mapped numerical score; record H also has a positive evaluation tendency and a similarly high mapped numerical score. The absolute value of the difference between their scores is small, and the calculated evaluation convergence value is close to 1, indicating that the user evaluation tendencies of the two records are highly consistent. If record I has a negative evaluation tendency (mapped to a lower numerical score) and record J has a positive evaluation tendency (mapped to a higher numerical score), the absolute value of the difference between their scores is large, and the evaluation convergence value is close to 0, indicating a significant difference in evaluation tendencies.

[0067] Step S126: When the problem similarity, step overlap, type correlation, and evaluation convergence of any two operation and maintenance service records all exceed the corresponding preset thresholds, an association edge is established between the two operation and maintenance service records, and the standardized weighted average of the problem similarity, step overlap, type correlation, and evaluation convergence is determined as the association strength value of the association edge.

[0068] Preset thresholds are set for problem similarity, step overlap, type correlation, and evaluation convergence. These thresholds are determined based on historical data statistics and business needs of IoT smart home operation and maintenance services. For example, the problem similarity threshold is set to a relatively high value, the step overlap threshold is set to a medium value, the type correlation threshold is set to a basic value, and the evaluation convergence threshold is set to a medium value.

[0069] For any two operation and maintenance service records, if their problem similarity exceeds the corresponding threshold, and their step overlap, type correlation, and evaluation convergence all exceed their respective preset thresholds, then the two records are determined to be strongly correlated, and a correlation edge is established between them. After establishing the correlation edge, the correlation strength value needs to be calculated. First, the four indicators are standardized, and each indicator value is uniformly converted to the standard range of 0 to 1 (if the indicator value is already in this range, no processing is required).

[0070] Subsequently, different weights were assigned to the four standardized indicators. The weights were set according to the degree of influence of each indicator on the relevance of the operation and maintenance service. For example, the issue similarity had the highest weight, followed by the step overlap and type relevance, while the evaluation convergence had a relatively low weight. The product of the four indicators and their respective weights was calculated, and the sum of the four products was the association strength value of the associated edge. This association strength value reflects the tightness of the association between two records.

[0071] Step S127: Combine all established associated edges and corresponding operation and maintenance service records as nodes to form a target associated network structure that includes node attributes, edge attributes, and association strength values.

[0072] Each operation and maintenance service record is treated as a node in the target associated network structure. The node attributes include the service request text, execution operation sequence, resource call record, service effect feedback text, and the operation and maintenance scenario type to which the record belongs. All associated edges established in step S126 are included in the network. The edge attributes include the identifiers of the two node records corresponding to the associated edge, the original values ​​and standardized values ​​of the four indicators for establishing the association, and other information.

[0073] Simultaneously, the association strength value of each associated edge is bound to the corresponding associated edge to form a complete target association network structure. This target association network structure can be stored and visualized through a graph database. Each node in the graph database corresponds to an operation and maintenance service record, and each edge corresponds to the association relationship and association strength between records, which facilitates subsequent analysis of the association between nodes in the network and the identification of core record clusters.

[0074] Step S130: Based on the target association network structure, identify the core record clusters with correlation in the target association network structure, extract complementary operation and maintenance information from each operation and maintenance service record in the core record cluster, and fuse them to form an operation and maintenance knowledge module with scenario adaptability, thereby obtaining a set of operation and maintenance knowledge modules.

[0075] Based on the target-related network structure, by analyzing the correlation strength between nodes and the network topology, tightly related core record clusters are identified. For each core record cluster, complementary information from different records is mined, integrated, and fused to form knowledge modules adapted to specific operation and maintenance scenarios. Finally, all knowledge modules are aggregated to form a set.

[0076] Step S131: Calculate the number of associated edges for each node in the target associated network structure, and mark nodes with more than a preset edge count threshold as core nodes.

[0077] Iterate through each node in the target network structure and count the number of edges connected to each node. This number of edges reflects the frequency of association between the operation and maintenance service record corresponding to that node and other records. The preset edge count threshold is set according to the overall distribution of the number of edges connected to nodes in the network. For example, the threshold can be the sum of the average and standard deviation of the number of edges connected to all nodes.

[0078] Nodes with more than a preset threshold of associated edges are marked as core nodes. The operation and maintenance service records corresponding to these nodes usually involve high-frequency or typical operation and maintenance scenarios, and are closely related to multiple other records, making them the central nodes that constitute the core record cluster. For example, a node corresponding to the operation and maintenance record of "intelligent lighting network connection failure" has a large number of associated edges, exceeding the preset threshold, and is therefore marked as a core node.

[0079] Step S132: Taking each core node as the center, traverse all nodes connected by the associated edges of the core node to form an initial node set centered on the core node. Calculate the ratio of the total number of associated edges between all nodes in the initial node set to the theoretical maximum number of associated edges between all nodes in the initial node set, and determine the association density of the initial node set as the ratio.

[0080] Starting with each core node, use either depth-first search or breadth-first search to obtain all nodes connected by edges to that core node. Combine these nodes with the core node to form the initial node set. For example, if core node A connects to nodes B, C, and D, the initial node set would be {A, B, C, D}.

[0081] Calculate the total number of associated edges within the initial node set, i.e., the number of established edges between any two nodes in the set. Simultaneously, calculate the theoretical maximum number of associated edges for this set, calculated as the number of nodes multiplied by (number of nodes - 1) and then divided by 2. This formula is based on the theoretical assumption that an associated edge can be established between any two nodes. The association density is the ratio of the actual total number of associated edges to the theoretical maximum number of associated edges, reflecting the degree of close association between nodes within the initial node set.

[0082] Step S133: The initial set of nodes with an association density exceeding a preset density threshold is determined as the core record cluster, and each core record cluster corresponds to a type of operation and maintenance scenario.

[0083] The preset density threshold is set based on the characteristics of the operation and maintenance service scenario and the overall correlation level of the associated network. For example, it can be set to a medium-high value to ensure that the nodes within the core record cluster have strong internal correlation. The initial set of nodes with a correlation density exceeding the threshold is determined as the core record cluster, while the initial set of nodes with a correlation density below the threshold is split or merged into other clusters.

[0084] The operation and maintenance service records corresponding to the nodes in each core record cluster belong to the same type of operation and maintenance scenario. For example, the core record cluster consisting of the core node "intelligent lighting network connection failure" and its associated nodes corresponds to the "intelligent lighting control failure operation and maintenance" scenario; the cluster consisting of the core node "intelligent thermostat temperature display abnormality" and its associated nodes corresponds to the "intelligent temperature control equipment failure operation and maintenance" scenario.

[0085] Step S134: Perform information complementarity analysis on each operation and maintenance service record in each core record cluster to identify the differentiated fault descriptions of service request texts in different operation and maintenance service records, the complementary operation steps of the execution operation sequence in different operation and maintenance service records, and the alternative resource types of resource call records in different operation and maintenance service records.

[0086] Step S1341: Cluster the problem feature vectors of the service request texts of all operation and maintenance service records in the core record cluster to obtain multiple problem feature clusters, each of which corresponds to a type of core fault problem.

[0087] Clustering algorithms are used to cluster the request feature vectors of all records within the core record cluster. The clustering algorithm calculates the distance between vectors and groups vectors that are close to each other into the same cluster. For example, request feature vectors such as "Living room smart light cannot be turned on by APP", "Bedroom smart light APP control failure", and "Study room smart light remote control unresponsive" are clustered into one cluster, corresponding to the core fault problem of "smart light APP remote control failure"; vectors such as "Smart light local button unresponsive" and "Smart light does not turn on after power-on" are clustered into another cluster, corresponding to the core fault problem of "smart light local control failure".

[0088] The records within each problem feature cluster all revolve around the same core fault problem, and different clusters correspond to different core fault problems.

[0089] Step S1342: Decompose the service request text of the operation and maintenance service record in each problem feature cluster into a fault description, extract the fault occurrence environment, fault manifestation form and fault impact range in each service request text, identify the differentiated description content of the same core fault problem in different service request texts, and form a differentiated fault description list.

[0090] For each problem feature cluster, the service request text of each record within the cluster is broken down. For example, in the cluster "Smart Lighting App Remote Control Failure", the request text of a certain record, "Living room smart lights cannot be turned on via the app when the WiFi signal is weak", is broken down to the fault environment "weak WiFi signal", the fault manifestation is "cannot be turned on via the app", and the fault impact range is "living room smart lights"; the request text of another record, "Bedroom smart lights cannot be remotely controlled after the app version update", is broken down to the fault environment "after the app version update", the fault manifestation is "cannot be remotely controlled", and the fault impact range is "bedroom smart lights".

[0091] By comparing the breakdown results of different records within a cluster, differentiated descriptions are identified, such as the fault occurring in environments like "weak WiFi signal," "after an app update," and "after a router restart," with the fault affecting smart lights in different rooms. These differentiated descriptions are then compiled into a differentiated fault description list, which comprehensively covers different manifestations of the same core fault problem.

[0092] Step S1343: Perform sequence alignment processing on the operation step units of the execution operation sequence of all operation and maintenance service records in the core record cluster, and construct a standard operation step framework based on the logical relationship of the operation steps.

[0093] The core record cluster collects the step units of the execution operation sequence of all records, and processes these step units using a sequence alignment algorithm. The sequence alignment algorithm aligns similar steps in different sequences to the same position based on the semantic similarity and logical relationship between the operation steps. For example, for the execution operation sequence of "Smart Lighting APP Control Failure," "Check WiFi Connection" and "Check Network Status" are aligned to the same position, and "Restart Router" and "Reset Network" are aligned to the same position.

[0094] Based on the aligned step units, a standard operating procedure framework is constructed according to the logical sequence of "troubleshooting - fault location - fault repair - functional testing". For example, the standard operating procedure framework is "check device network connection - check APP version and permissions - restart network device - reset smart lighting device - reconfigure network - test APP control function". This standard operating procedure framework covers the general steps for handling such faults.

[0095] Step S1344: Identify additional operation steps in the execution operation sequence of each operation and maintenance service record that are not included in the standard operation step framework, determine whether the additional operation steps can solve special cases not covered by the standard operation step framework, and identify the additional operation steps that can solve special cases as complementary operation steps.

[0096] The system iterates through the execution sequence of each record in the core record cluster, compares it with the standard operation procedure framework, and identifies additional operation steps not included in the framework. For example, a record's operation sequence may contain steps such as "uninstall and reinstall the app" or "clear app cache data," which are not included in the standard framework.

[0097] Determine whether these additional steps address special cases, such as "app cache anomalies causing control failure" or "app installation file corruption causing functional abnormalities," scenarios not covered by the standard framework. If the additional steps effectively resolve these special cases, they are identified as complementary operation steps. For example, "uninstalling and reinstalling the app" resolves app file corruption issues and is identified as a complementary operation step; "clearing app cache data" resolves cache anomaly issues and is also identified as a complementary operation step.

[0098] Step S1345: Classify and statistically analyze the resource types of all operation and maintenance service records in the core record cluster to obtain the call frequency of each resource type, and determine the resource types whose call frequency exceeds the preset frequency threshold as core resource types.

[0099] The resource call types of all records within the core record cluster are statistically analyzed, and the call frequency of each resource type is calculated, i.e., the number of times that type of resource is called by different records. For example, the "Device Log Query Interface" is called multiple times, the "Remote Command Issuance Interface" is called multiple times, the "Firmware Upgrade Package" is called multiple times, and the "Hardware Detection Tool" is called less frequently.

[0100] The preset frequency threshold is set based on the overall distribution of resource calls, and resource types whose call frequency exceeds the threshold are identified as core resource types. For example, if the call frequency of "Device Log Query Interface", "Remote Command Issuance Interface", and "Firmware Upgrade Package" exceeds the threshold, they are identified as core resource types. These resources are critical for handling faults in the corresponding operation and maintenance scenarios of this cluster.

[0101] Step S1346: Identify other resource types that are called simultaneously in the operation and maintenance service records of the core resource type, determine whether the other resource types can complete the same function when the core resource type is unavailable, and determine the other resource types that can complete the same function as alternative resource types.

[0102] Find all records that call core resource types and extract other non-core resource types that are also called in these records. For example, some records that call the "Device Log Query Interface" (core resource) also call the "Local Device Log Reading Tool"; some records that call the "Remote Command Issuance Interface" (core resource) also call the "Device Local Command Input Tool".

[0103] Determine whether these other resource types can perform the same function in place of the core resource when it is unavailable. For example, when the "Device Log Query Interface" cannot be called due to network failure, the "Local Device Log Reading Tool" can read device logs through a local connection and perform the same log query function, thus being identified as a substitute resource type; when the "Remote Command Issuance Interface" is unavailable, the "Device Local Command Input Tool" can send commands to the device through local operation, thus being identified as a substitute resource type.

[0104] Step S1347: Compile the list of differentiated fault descriptions, complementary operation steps, and alternative resource types to form the information complementarity analysis results.

[0105] The differentiated fault description list generated in step S1342, the complementary operation steps determined in step S1344, and the alternative resource types identified in step S1346 are integrated and organized according to the structure of "core fault problem - differentiated description - standard operation framework - complementary steps - core resource - alternative resource" to form the information complementarity analysis results.

[0106] Step S135: Extract differentiated fault descriptions from each operation and maintenance service record to form a scenario fault feature set; extract complementary operation steps from each operation and maintenance service record to form a complete operation process sequence; and extract alternative resource types from each operation and maintenance service record to form a resource candidate list.

[0107] Extract all contents of the differentiated fault description list from the information complementarity analysis results, classify them according to core fault issues, and form a set of scenario fault features. For example, the fault feature set for the "smart lighting APP control failure" scenario includes features such as "weak WiFi signal causing control failure", "APP version problem causing control failure", and "network equipment failure causing control failure".

[0108] Extract complementary operation steps and add them to the standard operation step framework to form a complete operation process sequence. For example, based on the standard framework of "check network - restart device - reconfigure network - test function", add complementary steps such as "uninstall and reinstall APP" and "clear cache" to form a complete operation process covering both general and special cases.

[0109] Extract alternative resource types and categorize them according to their corresponding core resource types to form a resource candidate list. For example, the candidate resource for "Device Log Query Interface" is "Local Device Log Reading Tool", and the candidate resource for "Remote Command Issuance Interface" is "Local Command Input Tool". The list clearly defines the alternative for each core resource.

[0110] Step S136: The scenario fault feature set, complete operation process sequence and resource alternative list are associated and integrated, and the resource calling rules corresponding to each step in the complete operation process sequence and the fault response plan corresponding to each step in the complete operation process sequence are supplemented to form an operation and maintenance knowledge module containing scenario features, operation process, resource configuration and fault plan.

[0111] The system integrates and correlates scenario fault feature sets, complete operation process sequences, and resource alternative lists to match corresponding resource invocation rules and fault response plans for each step in the complete operation process sequence. The resource invocation rules specify the core resources that should be prioritized for this step, the conditions for resource invocation, and the logic for selecting alternative resources when invocation fails. For example, the invocation rule for the "check device logs" step is "prioritize calling the device log query interface; if the interface call fails, use the local device log reading tool."

[0112] The fault response plan provides solutions for possible abnormal situations in each step. For example, in the "Restart Router" step, if the network still does not recover after restarting, the plan is to "Check the router hardware status - Replace the router - Reconfigure the network"; in the "Reconfigure Network" step, if network configuration fails, the plan is to "Check the device network configuration mode - Reset the device network configuration status - Re-initiate network configuration".

[0113] The integrated content forms a complete operation and maintenance knowledge module, which includes four core parts: scenario fault feature set (clarifying the fault types in the scenario), complete operation process sequence (clarifying the handling process), resource configuration (clarifying resource calling rules and alternative resources), and fault contingency plan (clarifying the abnormal handling plan), and has scenario adaptability.

[0114] Step S137: Repeat the above process for each core record cluster to obtain multiple operation and maintenance knowledge modules, and summarize the operation and maintenance knowledge modules to form an operation and maintenance knowledge module set.

[0115] For each core record cluster identified in the target associated network structure, repeat the processing steps S134 to S136, that is, sequentially perform information complementarity analysis, extract scenario fault feature set, complete operation process sequence and resource alternative list, associate and integrate and supplement resource call rules and fault response plans to form an operation and maintenance knowledge module corresponding to each cluster.

[0116] For example, for the core record cluster of "intelligent curtain control fault maintenance," a knowledge module is formed that includes curtain control fault characteristics, operation procedures, resource configuration, and contingency plans; for the "intelligent security equipment fault maintenance" cluster, a corresponding security equipment maintenance knowledge module is formed. All these knowledge modules are aggregated, classified and stored according to maintenance scenario types, forming a maintenance knowledge module set.

[0117] Step S140: Perform dynamic knowledge system construction processing on the set of operation and maintenance knowledge modules to form a target operation and maintenance knowledge system with self-adjustment capability.

[0118] Based on the set of operation and maintenance knowledge modules, an initial multi-dimensional knowledge system is constructed. By recording the actual application data and user feedback of the knowledge modules, the classification framework, module classification, and module content of the knowledge system are adjusted regularly to enable the knowledge system to have self-adjustment capabilities, and finally form the target operation and maintenance knowledge system.

[0119] Step S141: Initially set the classification framework of the operation and maintenance knowledge system. The classification framework of the operation and maintenance knowledge system includes three levels: scenario category, scenario subcategory, and scenario sub-category. Each level is divided into multiple classification tags according to the business attributes of the operation and maintenance service.

[0120] The initial classification framework comprises three levels. The scenario categories are divided according to the types of IoT smart home control devices, including five major category tags: "Smart Lighting Equipment Maintenance," "Smart Curtain Equipment Maintenance," "Smart Temperature Control Equipment Maintenance," "Smart Security Equipment Maintenance," and "Multi-Device Collaboration Maintenance."

[0121] Scene subcategories are divided under scene categories according to fault type. For example, the "Smart Lighting Equipment Maintenance" category includes four subcategories: "Control Function Fault", "Power Supply Fault", "Network Connection Fault", and "Firmware Fault"; the "Smart Temperature Control Equipment Maintenance" category includes three subcategories: "Temperature Display Fault", "Adjustment Function Fault", and "Network Fault".

[0122] The scenario subcategories are further divided based on specific fault manifestations. For example, the subcategory "Smart Lighting Equipment Maintenance - Control Function Faults" includes three subcategories: "APP Remote Control Faults," "Local Button Control Faults," and "Voice Control Faults." Similarly, the subcategory "Smart Lighting Equipment Maintenance - Network Connection Faults" includes three subcategories: "WiFi Connection Failure," "Unstable Network Signal," and "IP Address Conflict." Each level of the classification framework has clearly defined business attributes, ensuring accurate categorization for subsequent knowledge modules.

[0123] Step S142: Each operation and maintenance knowledge module in the operation and maintenance knowledge module set is assigned to the corresponding scenario sub-category in the classification framework of the operation and maintenance knowledge system according to the matching degree between the scenario fault feature set of the operation and maintenance knowledge module and the classification labels of each level in the classification framework of the operation and maintenance knowledge system, thus forming an initial multi-dimensional knowledge system.

[0124] For each module in the operation and maintenance knowledge module set, key information such as core fault types and specific fault manifestations are extracted from its scenario fault feature set. The matching degree of this key information with the scenario category, scenario subcategory, and scenario fine category labels in the classification framework is calculated. The matching degree is determined based on the degree of overlap of feature keywords and semantic similarity.

[0125] For example, the scenario fault feature set of a certain operation and maintenance knowledge module is "smart lighting APP remote control failure, frequent faults when WiFi signal is weak", and its core fault type is "control function failure", specifically manifested as "APP remote control failure". Calculations show that this module has the highest matching degree with "smart lighting equipment operation and maintenance" (scenario category), the highest matching degree with "control function failure" (scenario subcategory), and the highest matching degree with "APP remote control failure" (scenario subcategory). Therefore, this module is assigned to the subcategory "smart lighting equipment operation and maintenance - control function failure - APP remote control failure".

[0126] All operation and maintenance knowledge modules are assigned to the corresponding scenario subcategories according to the above method. Each scenario subcategory contains at least one operation and maintenance knowledge module, thereby forming an initial multi-dimensional knowledge system. This initial multi-dimensional knowledge system clearly organizes the operation and maintenance knowledge of different scenarios in a hierarchical structure.

[0127] Step S143: Record the frequency of use scenarios for each operation and maintenance knowledge module in actual applications and the cross-scenario reuse rate of each operation and maintenance knowledge module. The frequency of use scenarios is the number of operation and maintenance scenarios corresponding to when the operation and maintenance knowledge module is called. The cross-scenario reuse rate is the ratio of the number of times the operation and maintenance knowledge module is called in non-initial allocation scenarios to the total number of times the operation and maintenance knowledge module is called.

[0128] After the initial multi-dimensional knowledge system is put into practical use, a usage log recording function is set up for each operation and maintenance knowledge module. The frequency of usage scenarios is determined by counting the number of different operation and maintenance scenarios corresponding to the module when it is called. For example, if a module is initially assigned to the "smart lighting APP remote control failure" scenario, it will be called not only in this scenario, but also in the "smart curtain APP remote control failure" and "smart temperature control APP remote control failure" scenarios in actual application, and its usage scenario frequency is 3.

[0129] Calculating cross-scenario reuse rate requires first counting the total number of times a module is called, and then counting the number of times it is called in non-initial allocation scenarios. The ratio of these two counts is the cross-scenario reuse rate. For example, if a module is called a certain number of times in total, and a certain number of times it is called in non-initial allocation scenarios, the cross-scenario reuse rate is the ratio of these two counts. If a module is only called in the initial allocation scenario, the cross-scenario reuse rate is 0.

[0130] Step S144: Collect adaptation feedback for each operation and maintenance knowledge module after its application in the new scenario. The adaptation feedback includes the applicability score of the operation and maintenance knowledge module's operation process, the matching score of the operation and maintenance knowledge module's resource configuration, and the effectiveness score of the operation and maintenance knowledge module's fault contingency plan.

[0131] When the operations and maintenance (O&M) knowledge module is applied to a new O&M scenario, an adaptation feedback questionnaire is pushed to O&M personnel and users through the O&M service platform. The adaptation feedback questionnaire includes three core dimensions of scoring items: the applicability score of the operation process, which evaluates whether the operation steps in the module are suitable for fault handling in the new scenario; the matching score of the resource configuration, which evaluates whether the resource calling scheme in the module matches the resource requirements of the new scenario; and the effectiveness score of the fault contingency plan, which evaluates whether the exception handling contingency plan in the module is effective in the new scenario.

[0132] The scoring uses a fixed scoring standard, and operations and maintenance personnel and users complete the scoring based on their actual application experience. After collecting all feedback scores, the system calculates the average score for each dimension, which serves as the adaptation feedback result for that module in the new scenario. The adaptation feedback for each module is associated with the corresponding application scenario information.

[0133] Step S145: When the cross-scenario reuse rate of any operation and maintenance knowledge module exceeds the preset reuse threshold, analyze the common features of multiple scenarios adapted to the operation and maintenance knowledge module, add a scenario subclass or scenario sub-class corresponding to the common features in the classification framework of the operation and maintenance knowledge system, and simultaneously assign the operation and maintenance knowledge module to the newly added classification and the original classification of the operation and maintenance knowledge module.

[0134] The preset reuse threshold is set based on the application requirements of the knowledge system and the general situation of module reuse. When the cross-scenario reuse rate of a certain operation and maintenance knowledge module exceeds the threshold, it indicates that the module has strong cross-scenario applicability, and it is necessary to analyze the common characteristics of all the scenarios it adapts to.

[0135] For example, a module initially assigned to "smart lighting APP remote control failure" has a cross-scenario reuse rate exceeding the threshold. The scenarios it is adapted to include "smart lighting APP remote control failure", "smart curtain APP remote control failure", and "smart temperature control APP remote control failure". These scenarios share the common feature of "smart device APP remote control failure" and all belong to different device type categories.

[0136] Based on this common characteristic, a new scenario subclass, "APP Remote Control Fault," is added to the knowledge system classification framework. This subclass does not belong to any specific scenario category but exists as a shared subclass across categories. This module is simultaneously assigned to both the newly added "APP Remote Control Fault" subclass and the original "Intelligent Lighting Equipment Operation and Maintenance - Control Function Fault - APP Remote Control Fault" subclass, achieving multi-category classification of the module and improving knowledge reuse efficiency.

[0137] Step S146: When the adaptation feedback score of any operation and maintenance knowledge module is lower than the preset score threshold, analyze the reason for the lower score threshold. If the operation and maintenance knowledge module is missing operation procedures, supplement the operation and maintenance knowledge module in the new scenario. If the operation and maintenance knowledge module is mismatched in resource configuration, update the resource candidate list of the operation and maintenance knowledge module to form an adjusted operation and maintenance knowledge module.

[0138] A preset scoring threshold is used to determine the adaptability of the operations and maintenance knowledge module in new scenarios. When the module's adaptation feedback score falls below this threshold, the module adjustment process is initiated. First, the specific reasons for the low score are analyzed by reviewing the operations and maintenance personnel's operation records, detailed descriptions of user feedback, and the module's application logs to pinpoint the root cause of the problem.

[0139] If the cause is a missing operation procedure, meaning that the operation steps in the module cannot cover the fault handling requirements of the new scenario, for example, when applying a module in the scenario of "smart curtain APP remote control failure", it is found that the operation step of "checking the drive status of the curtain motor" is missing, resulting in incomplete fault diagnosis, then this step should be added to the complete operation procedure sequence of the module, and the execution conditions and operation specifications of this step should be clearly defined.

[0140] If the cause is a resource configuration mismatch—that is, the resource calling scheme in the module cannot meet the resource requirements of the new scenario, for example, when applying a module in the scenario of "remote control failure of smart temperature control APP," the module's recommended "remote log query interface" cannot adapt to the log format of this brand of temperature controller—then the module's resource alternative list will be updated, a "dedicated log query interface" adapted to this brand of temperature controller will be added, and the resource calling rules will be adjusted to prioritize calling the dedicated interface. After the adjustments, a new operation and maintenance knowledge module will be formed and replaced with the original module for use.

[0141] Step S147: Based on the frequency of use scenarios of all operation and maintenance knowledge modules, the cross-scenario reuse rate of all operation and maintenance knowledge modules, and the adaptation feedback of all operation and maintenance knowledge modules, regularly adjust the hierarchical structure of the classification framework of the operation and maintenance knowledge system, the classification tags of the classification framework of the operation and maintenance knowledge system, and the classification affiliation of all operation and maintenance knowledge modules to form a target operation and maintenance knowledge system with self-adjustment capabilities.

[0142] Step S1471: Set an adjustment period. Within each adjustment period, count the number of operation and maintenance knowledge modules under each scenario sub-category in the classification framework of the operation and maintenance knowledge system. If the number of operation and maintenance knowledge modules under any scenario sub-category exceeds the preset module number threshold, then split the scenario sub-category into multiple new scenario sub-categories. Each new scenario sub-category corresponds to different sub-scenario features of the operation and maintenance knowledge modules.

[0143] Set a fixed adjustment cycle, such as adjusting the knowledge system monthly. Within each adjustment cycle, iterate through all scenario subcategories in the classification framework and count the number of operation and maintenance knowledge modules under each subcategory. A preset module count threshold is set based on the business coverage and knowledge management needs of the subcategory. When the number of modules under a subcategory exceeds this threshold, it indicates that the business scope of that subcategory is too broad and needs to be split.

[0144] For example, if the number of modules under the subcategory "Intelligent Security Equipment Operation and Maintenance - Camera Failure - Recording Function Failure" exceeds the threshold, and the sub-scenario characteristics corresponding to these modules include "Insufficient storage space leading to recording failure", "Incompatible recording format leading to inability to store", and "Camera hardware failure leading to recording interruption", then this subcategory will be split into three new scenario subcategories: "Insufficient storage space leading to recording failure", "Incompatible recording format leading to inability to store", and "Camera hardware failure leading to recording interruption", and each new subcategory will be assigned a corresponding operation and maintenance knowledge module.

[0145] Step S1472: If the number of operation and maintenance knowledge modules under any scenario subclass is lower than the preset module number threshold, and the similarity of the scenario features of the operation and maintenance knowledge modules of the scenario subclass with those of the adjacent scenario subclass exceeds the preset similarity threshold, then the scenario subclass is merged into the adjacent scenario subclass.

[0146] For scenario subcategories with fewer than a preset threshold number of modules, calculate the scenario feature similarity between them and the operation and maintenance knowledge modules in adjacent scenario subcategories (subcategories with similar business attributes). The scenario feature similarity is calculated based on the degree of overlap of multi-dimensional information such as the module's fault feature set, operation process, and resource configuration.

[0147] If the similarity exceeds a preset similarity threshold, it indicates that the business attributes of the two subcategories are highly similar and can be merged. For example, if the number of modules in the subcategories "Smart Lighting Equipment Maintenance - Power Failure - Poor Socket Contact" and "Smart Lighting Equipment Maintenance - Power Failure - Aging Power Cord" are both below the threshold, and the similarity of their scene features exceeds the threshold, the two subcategories will be merged into the subcategory "Smart Lighting Equipment Maintenance - Power Failure - Abnormal Power Supply Line". After the merger, the modules under the original two subcategories will be uniformly classified into the new subcategory.

[0148] Step S1473: Calculate the average usage frequency of operation and maintenance knowledge modules under each category tag in the classification framework of the operation and maintenance knowledge system. If the average usage frequency of operation and maintenance knowledge modules under any category tag is lower than the preset frequency threshold, delete the category tag and reassign the operation and maintenance knowledge modules under the category tag to other relevant category tags in the classification framework of the operation and maintenance knowledge system.

[0149] Calculate the average frequency of usage scenarios for all operation and maintenance knowledge modules under each category tag (including major, sub, and detailed categories) in the classification framework. If the average frequency of usage scenarios under a certain category tag is lower than the preset frequency threshold, it indicates that the business scenario corresponding to that tag is used infrequently and does not need to be retained separately; it should be deleted.

[0150] For example, if the average usage frequency of modules under the tag "Smart Lighting Equipment Maintenance - Firmware Failure - Old Version Compatibility Failure" is lower than the threshold, delete the tag, re-analyze the scenario characteristics of the modules under it, and assign them to relevant tags such as "Smart Lighting Equipment Maintenance - Firmware Failure - Firmware Version Failure" to ensure that the modules can still be effectively retrieved and called.

[0151] Step S1474: For each operation and maintenance knowledge module, recalculate the matching degree between the scenario fault feature set of the operation and maintenance knowledge module and the classification labels of each level in the current operation and maintenance knowledge system classification framework. Adjust the classification of the operation and maintenance knowledge module according to the new matching degree so that the operation and maintenance knowledge module is assigned to the category with the highest matching degree.

[0152] Since the labels in the classification framework may be added, merged, or deleted, it is necessary to recalculate the matching degree between each operation and maintenance knowledge module and the labels at each level of the current classification framework. The matching degree calculation method is the same as in step S142, and is determined based on the keyword overlap and semantic similarity between the scenario fault feature set and the labels.

[0153] Based on the new matching results, the module's classification is adjusted. For example, a module was originally assigned to the subcategory "Smart Curtain Device Maintenance - Network Failure - WiFi Connection Failure". After the classification framework is adjusted, a new subcategory "Smart Device Network Failure - WiFi Connection Failure" is added across the major category. After recalculating the matching degree, it is found that the module's matching degree with the new subcategory is higher than that with the original subcategory. Therefore, its classification is adjusted to the new subcategory while retaining its original subcategory classification, thus achieving multi-category management.

[0154] Step S1475: Record the classification framework of the operation and maintenance knowledge system for each adjustment, the changes in the classification of operation and maintenance knowledge modules for each adjustment, and the basis for each adjustment, and form an adjustment log.

[0155] All operations during the knowledge system adjustment process are recorded in detail, including changes in the classification framework structure (addition, merging, deletion of tags and hierarchical adjustments), adjustments to the classification of each operation and maintenance knowledge module (original classification, new classification), and the specific basis for the adjustments (such as module usage frequency, cross-scenario reuse rate, adaptation feedback score, etc.).

[0156] The adjustment log is stored using timestamps as indexes, supporting the tracing of historical adjustment records. By analyzing the adjustment log, the evolutionary patterns of the knowledge system can be summarized, ultimately forming a target operation and maintenance knowledge system with self-adjusting capabilities.

[0157] Step S150: Based on the target operation and maintenance knowledge system, generate operation and maintenance service response content containing resource optimization suggestions for newly received operation and maintenance service requests.

[0158] When a new IoT smart home control operation and maintenance service request is received, the system retrieves the matching operation and maintenance knowledge module from the target operation and maintenance knowledge system, optimizes the resource configuration scheme based on the resource constraints of the request, generates service response content including operation procedures, resource suggestions, and fault contingency plans, and pushes it to operation and maintenance personnel and user terminals to guide the operation and maintenance service.

[0159] Step S151: Receive a new operation and maintenance service request, perform scenario feature extraction processing on the new operation and maintenance service request, extract the fault description text, available resource types, and service target requirements in the new operation and maintenance service request, and form the request scenario feature vector of the new operation and maintenance service request.

[0160] The system receives new service requests through its maintenance service request handling system. These requests may originate from a smart home app, voice assistant, or customer service hotline. The system extracts scenario features from the request content. First, it extracts the fault description text, such as "The bedroom smart curtains cannot be controlled via the app, but the WiFi signal is normal." Then, it extracts the types of available resources provided by the user, such as "Local debugging tools and router management backend can be accessed." Finally, it extracts the service objective requirements, such as "Restore the curtain app control function within 1 hour."

[0161] The extracted fault description text, available resource types, and service target requirements are vectorized. Using the same word embedding technique as in step S121, each feature is mapped to a fixed-dimensional numerical vector. These vectors are then concatenated to form a request scenario feature vector, which comprehensively reflects the scenario attributes of the new request.

[0162] Step S152: Calculate the similarity between the request scenario feature vector of the new operation and maintenance service request and the scenario fault feature set of each operation and maintenance knowledge module in the target operation and maintenance knowledge system, and determine the operation and maintenance knowledge modules whose similarity exceeds the preset scenario similarity threshold as candidate knowledge modules.

[0163] Step S1521: Convert the scenario fault feature set of each operation and maintenance knowledge module into feature vector form to obtain the knowledge module feature vector of each operation and maintenance knowledge module. The dimension of the knowledge module feature vector of each operation and maintenance knowledge module is consistent with the dimension of the request scenario feature vector of the new operation and maintenance service request.

[0164] For each operation and maintenance knowledge module in the target operation and maintenance knowledge system, extract its scenario fault feature set, and use the same word embedding technology and vector concatenation method as the request scenario feature vector to convert it into a knowledge module feature vector.

[0165] For example, the feature vector of the request scenario has several dimensions, and the feature vector of each knowledge module is adjusted to the same dimensions. The dimensions of the vector parts corresponding to the fault description, the vector parts corresponding to the resource type, and the vector parts corresponding to the service target are consistent with the request vector to ensure feature alignment.

[0166] Step S1522: Calculate the Euclidean distance between the request scenario feature vector of the new operation and maintenance service request and the knowledge module feature vector of each operation and maintenance knowledge module, and at the same time calculate the cosine similarity between the request scenario feature vector of the new operation and maintenance service request and the knowledge module feature vector of each operation and maintenance knowledge module.

[0167] When calculating the Euclidean distance, first calculate the square of the difference between the corresponding dimension values ​​of the feature vector of the request scenario and the feature vector of the knowledge module, then sum all the squared values, and finally take the square root of the summation result to obtain the Euclidean distance value. The smaller the Euclidean distance value, the more similar the two vectors are.

[0168] The method for calculating cosine similarity is the same as in step S122, obtained by dividing the vector dot product by the product of the magnitudes of the two vectors. The closer the value is to 1, the higher the similarity. Calculating both similarity indices simultaneously allows for measuring the degree of matching between the request and the module from different perspectives, improving matching accuracy.

[0169] Step S1523: Multiply the normalized result of the Euclidean distance between the request scenario feature vector of the new operation and maintenance service request and the knowledge module feature vector of each operation and maintenance knowledge module by the Euclidean distance weight, multiply the cosine similarity between the request scenario feature vector of the new operation and maintenance service request and the knowledge module feature vector of each operation and maintenance knowledge module by the cosine similarity weight, and add the two to obtain the comprehensive similarity value.

[0170] First, the Euclidean distance is normalized to a value between 0 and 1. The conversion method is to subtract the current Euclidean distance from the maximum value of the Euclidean distance, and then divide by the difference between the maximum and minimum values ​​of the Euclidean distance. The larger the normalized Euclidean distance value, the higher the vector similarity.

[0171] Weights are assigned to the normalized Euclidean distance and cosine similarity, respectively. These weights are set based on historical matching results; for example, the weight of cosine similarity is higher than that of Euclidean distance. The normalized Euclidean distance is multiplied by its weight, and the cosine similarity is multiplied by its weight. The sum of these two values ​​is the comprehensive similarity value, which comprehensively reflects the degree of matching between the request and the module.

[0172] Step S1524: Mark the operation and maintenance knowledge modules whose comprehensive similarity value exceeds the scene similarity threshold as candidate knowledge modules.

[0173] The preset scenario similarity threshold is set based on the matching accuracy of historical operation and maintenance services. Operation and maintenance knowledge modules with a comprehensive similarity value exceeding this threshold are marked as candidate knowledge modules. For example, in the comprehensive similarity calculation results of a new request, if the comprehensive similarity value of 3 modules exceeds the threshold, these 3 modules are all marked as candidate knowledge modules and proceed to the next step of screening.

[0174] Step S1525: For all candidate knowledge modules, calculate the average adaptation feedback score of each candidate knowledge module in historical applications, determine the candidate knowledge modules whose average score exceeds the preset score threshold as candidate knowledge modules, and sort the candidate knowledge modules in order of comprehensive similarity value from high to low to form a candidate knowledge module sequence.

[0175] Extract the historical adaptation feedback scores for each candidate knowledge module and calculate the average of all scores. A preset scoring threshold is used to filter modules with good adaptation performance; candidate knowledge modules with an average score exceeding this threshold are identified as candidate knowledge modules.

[0176] Candidate knowledge modules are sorted in descending order of their overall similarity scores to form a sequence of candidate knowledge modules. Modules ranked higher in the sequence have a higher matching degree and better adaptation effect to new requests, and are given priority as the knowledge basis for service responses.

[0177] Step S153: Extract the resource constraints in the new operation and maintenance service request. The resource constraints in the new operation and maintenance service request include restrictions on available resource types, resource quantity, and resource access permissions.

[0178] Extract resource constraints from new operation and maintenance service requests. Available resource type restrictions refer to the range of resource types that users or operation and maintenance environments can call, such as "only local resources can be called, cloud platform interfaces cannot be accessed"; resource quantity restrictions refer to the upper limit of the number of available resources, such as "only one debugging device is available"; resource call permission restrictions refer to the range of access permissions that operation and maintenance personnel have for calling resources, such as "no device firmware upgrade permission".

[0179] Step S154: Analyze the resource candidate list of each candidate knowledge module, determine whether the resource types in the resource candidate list of the candidate knowledge module meet the available resource type restrictions in the new operation and maintenance service request, determine whether the resource quantity requirements in the resource candidate list of the candidate knowledge module are within the available quantity range in the new operation and maintenance service request, and determine whether the resource calls in the resource candidate list of the candidate knowledge module meet the permission restrictions in the new operation and maintenance service request.

[0180] The resource candidate list for each candidate knowledge module is analyzed one by one. First, the resource types in the list are compared with the available resource type restrictions for the new request. For example, if the available resource type restriction for the new request is "local resources only", and the resource candidate list for a certain candidate knowledge module includes "cloud platform log query interface" (not a local resource), then the resource type is determined to be ineligible for the restriction; if the list includes "local device debugging tool" and "local router management interface" (both local resources), then the type restriction is determined to be compliant.

[0181] Next, check if the resource quantity requirement is within the available range. If the resource quantity limit of the new request is "only one debugging device is available", and a certain operation step of a candidate knowledge module requires "two debugging devices to run simultaneously", then the resource quantity requirement is determined to be out of range; if the step requires "a single debugging device can complete", then the quantity limit is determined to be met.

[0182] Finally, verify whether the resource call complies with the permission restrictions. If the permission restriction for the newly requested resource call is "no firmware upgrade permission", and the resource candidate list of a certain candidate knowledge module contains the "firmware upgrade package call" operation, then the resource call is determined to be inconsistent with the permission restrictions; if the list only contains operations that do not require upgrade permissions, such as "device status query" and "parameter adjustment", then the permission restrictions are determined to be consistent.

[0183] Step S155: For resource types that meet the resource constraints in the new operation and maintenance service request, retain the priority of the resource type in the resource candidate list of the candidate knowledge module. For resource types that do not meet the resource constraints in the new operation and maintenance service request, remove them from the resource candidate list of the candidate knowledge module, and supplement them with alternative resource types that meet the resource constraints in the new operation and maintenance service request and the calling rules of the alternative resource types.

[0184] For each candidate knowledge module, the original calling priority order of resource types in the resource candidate list that meet the constraints is maintained. For example, if the "local device log reading tool" has a higher priority than the "local parameter detection tool" in the original resource candidate list of a certain module, and both meet the constraints, then that priority is retained.

[0185] Resource types that do not meet the constraints will be removed from the list. For example, resource types that do not meet the "local resource restrictions" or "no upgrade permission" criteria, such as "cloud platform command delivery interface" and "firmware upgrade package resources," will be removed.

[0186] Then, supplement alternative resource types that meet the constraints. If the "cloud platform log query interface" is removed, a local resource that can achieve the same log query function needs to be added, such as the "device local serial port log export tool", and the calling rules of this alternative resource should be specified: "In the operation step 'obtain device operation log', the local serial port log export tool should be started first, the device and the debugging terminal are connected via USB, the log export command is sent, and the log file is saved to the local directory."

[0187] Step S156: Based on the adjusted resource candidate list of candidate knowledge modules, optimize the complete operation process sequence of the candidate knowledge modules, and adjust the resource calling scheme corresponding to each operation step in the complete operation process sequence of the candidate knowledge modules so that the complete operation process sequence of the candidate knowledge modules matches the resource constraints in the new operation and maintenance service request.

[0188] Based on the revised resource candidate list, the complete operation flow sequence of the candidate knowledge modules was optimized. If a resource corresponding to a step in the original sequence has been removed, it was replaced with a supplementary alternative resource, and the operation description of the step was adjusted. For example, the original step "call the cloud platform log query interface to obtain device logs" was optimized to "use the local serial port log export tool to obtain device logs," while supplementing specific operation details such as tool connection and command sending.

[0189] If the original sequence contains related steps that depend on resources that do not meet the constraints, the step logic needs to be redesigned. For example, the original sequence "test function after firmware upgrade" cannot be executed due to "lack of upgrade permission," and it is optimized to "test function after adjusting existing device parameters," and the calling scheme of the "local parameter adjustment tool" is matched.

[0190] After optimization, it is necessary to ensure the logical coherence of the operation process sequence, that the resource calls of each step meet the constraints of the new request, and that the operation order conforms to the operation and maintenance specifications of IoT smart home devices, such as "first check basic faults, then perform in-depth debugging" and "first hardware testing, then software configuration".

[0191] Step S157: Extract the complete operation process sequence, the resource alternative list, and the fault contingency plan from the adjusted candidate knowledge module. Combine the service objective requirements of the new operation and maintenance service request, supplement the execution priority suggestions of the complete operation process sequence of the candidate knowledge module and the resource allocation optimization scheme of the candidate knowledge module to form the operation and maintenance service response content.

[0192] Extract the core content from the adjusted candidate knowledge modules: complete operation process sequence (such as "check device power - connect local debugging tool - export device log - analyze log to locate fault - adjust device parameters - test control function"), adjusted resource alternative list (such as "local debugging tool, serial port log export tool, parameter adjustment software") and fault contingency plan (such as "if log export fails, restart the device and reconnect the debugging tool").

[0193] Based on the service objectives of the new request (such as "restore the smart curtain APP control function in the bedroom within 1 hour"), the following priority suggestions are provided: Set "Connect to local debugging tool - export device logs" as high priority, requiring completion within 10 minutes; set "Analyze logs - adjust parameters" as medium priority, requiring completion within 30 minutes; and set "Test control function" as low priority, requiring completion within the remaining time.

[0194] Additionally, a resource allocation optimization plan is proposed: it is recommended to prioritize allocating the only available local debugging tool to the "Export Device Logs" step, and then use it for the "Parameter Adjustment" step after completion; if the debugging tool takes too long, the built-in debugging function of the smart terminal can be used temporarily as an auxiliary tool. The above content is integrated into a structured operation and maintenance service response, presented with a clear hierarchical structure, facilitating quick understanding and execution by operation and maintenance personnel.

[0195] Step S158: Send the operation and maintenance service response content to the terminal device that initiated the new operation and maintenance service request, and record the current call scenario of the candidate knowledge module and the current adaptation and adjustment content of the candidate knowledge module.

[0196] The operation and maintenance service response is sent to the terminal device that initiated the new request via the message push interface of the operation and maintenance service platform, such as the user's smart home APP or the display terminal of the voice assistant. The sending format is adapted according to the terminal type: the APP uses a combination of text and images, while the voice assistant uses a combination of voice broadcast and text summary.

[0197] Meanwhile, the module call log of the target operation and maintenance knowledge system records the candidate knowledge module identifier, the operation and maintenance scenario of the new request (such as "bedroom smart curtain APP control failure - local resource constraints - no upgrade permission"), and the adaptation and adjustment content (such as "removing cloud platform resources, supplementing serial port log export tools and calling rules, and optimizing operation sequence priority"). The above records will serve as an important basis for subsequent knowledge system adjustments and module optimizations, ensuring that the target operation and maintenance knowledge system can continuously adapt to diverse operation and maintenance scenario requirements.

[0198] Figure 2The illustration shows exemplary hardware and software components of a multi-dimensional knowledge extraction and construction system 100 for operation and maintenance technical services, which can implement the ideas of this application, according to some embodiments of this application. For example, processor 120 can be used in the multi-dimensional knowledge extraction and construction system 100 for operation and maintenance technical services and to perform the functions in this application.

[0199] For example, a multi-dimensional knowledge extraction and construction system 100 applied to operation and maintenance technical services may include a network port 110 connected to a network, one or more processors 120 for executing program instructions, a communication bus 130, and various forms of storage media 140, such as a disk, ROM, or RAM, or any combination thereof. Exemplarily, the multi-dimensional knowledge extraction and construction system 100 applied to operation and maintenance technical services may also include program instructions stored in ROM, RAM, or other types of non-transitory storage media, or any combination thereof. The methods of this application can be implemented according to the program instructions. The multi-dimensional knowledge extraction and construction system 100 applied to operation and maintenance technical services also includes an I / O interface 150 between the computer and other input / output devices.

[0200] Furthermore, this embodiment of the invention also provides a readable storage medium, wherein computer-executable instructions are preset in the readable storage medium, and when the processor executes the computer-executable instructions, the above-mentioned multi-dimensional knowledge extraction and construction method applied to operation and maintenance technical services is implemented.

[0201] It should be noted that, in order to simplify the description of the present invention and thus help to understand one or more embodiments of the invention, multiple features may sometimes be grouped into one embodiment, drawing or description thereof in the foregoing description of the embodiments of the present invention.

Claims

1. A method for multi-dimensional knowledge extraction and construction applied to operation and maintenance technical services, characterized in that, The method includes: The system acquires a full record of operations and maintenance services generated during the operation and maintenance technical service process. The full record of operations and maintenance services includes service request text, execution operation sequence, resource call record and service effect feedback text under multiple operation and maintenance scenarios, and each operation and maintenance scenario corresponds to at least two sets of service execution process records with differences. The entire record of the operation and maintenance service is processed to construct an association network, and the association edges between each operation and maintenance service record are established to obtain the target association network structure. Based on the target association network structure, identify the core record clusters with correlation in the target association network structure, extract complementary operation and maintenance information from each operation and maintenance service record in the core record cluster, and fuse them to form an operation and maintenance knowledge module with scenario adaptability, thus obtaining a set of operation and maintenance knowledge modules. The set of operation and maintenance knowledge modules is dynamically constructed to form a target operation and maintenance knowledge system with self-adjustment capabilities. Based on the target operation and maintenance knowledge system, for newly received operation and maintenance service requests, an operation and maintenance service response content containing resource optimization suggestions is generated; Based on the target association network structure, the process involves identifying core record clusters with correlation within the target association network structure, extracting complementary operation and maintenance information from each operation and maintenance service record within the core record clusters, and fusing them to form an operation and maintenance knowledge module with scenario adaptability, resulting in a set of operation and maintenance knowledge modules, including: Calculate the number of associated edges for each node in the target associated network structure, and mark nodes with more than a preset edge count threshold as core nodes; Taking each core node as the center, traverse all nodes connected by the associated edges of the core node to form an initial node set centered on the core node. Calculate the ratio of the total number of associated edges between all nodes in the initial node set to the theoretical maximum number of associated edges between all nodes in the initial node set, and determine this ratio as the association density of the initial node set. The initial set of nodes whose association density exceeds the preset density threshold is determined as the core record cluster, and each core record cluster corresponds to a type of operation and maintenance scenario. For each core record cluster, perform information complementarity analysis on each operation and maintenance service record to identify differentiated fault descriptions in service request texts, complementary operation steps in execution sequences, and alternative resource types in resource call records. Extract differentiated fault descriptions from each operation and maintenance service record to form a scenario fault feature set; extract complementary operation steps from each operation and maintenance service record to form a complete operation process sequence; and extract alternative resource types from each operation and maintenance service record to form a resource candidate list. The scenario fault feature set, complete operation process sequence and resource alternative list are associated and integrated, and the resource calling rules corresponding to each step in the complete operation process sequence and the fault response plan corresponding to each step in the complete operation process sequence are supplemented to form an operation and maintenance knowledge module that includes scenario features, operation process, resource configuration and fault plan. Repeat the above process for each core record cluster to obtain multiple operation and maintenance knowledge modules, and then summarize the operation and maintenance knowledge modules to form an operation and maintenance knowledge module set.

2. The multi-dimensional knowledge extraction and construction method for operation and maintenance technical services according to claim 1, characterized in that, The process of constructing an association network for the full record of the operation and maintenance services, establishing association edges between each operation and maintenance service record, and obtaining the target association network structure includes: For each operation and maintenance service record, the service request text is processed to extract problem features, including problem type keywords, fault phenomenon description phrases, and service target statements, forming a request feature vector for each operation and maintenance service record. Calculate the cosine similarity between the request feature vectors of any two operation and maintenance service records, and determine the cosine similarity as the question similarity of the service request text of the two operation and maintenance service records; The execution operation sequence of each operation and maintenance service record is decomposed into steps, and the execution operation sequence is divided into multiple consecutive operation step units. The number of completely identical steps in the operation step units of any two operation and maintenance service records is counted. The ratio of the number of steps to the total number of steps in the two operation and maintenance service records is determined as the step overlap of the execution operation sequence of the two operation and maintenance service records. For each operation and maintenance service record, the resource call records are classified into hardware resource calls, software resource calls, and network resource calls. The number of resource types called by any two operation and maintenance service records is counted. The ratio of the number of common resource types to the total number of resource types in the two operation and maintenance service records is determined as the type correlation degree of the resource call records between the two operation and maintenance service records. Sentiment analysis is performed on the service effect feedback text of each operation and maintenance service record to determine whether the evaluation tendency of the service effect feedback text is positive, neutral or negative. Each evaluation tendency is mapped to a preset continuous numerical score. For any two operation and maintenance service records, the similarity of the numerical scores of the evaluation tendencies of the two records is calculated. The similarity is determined as the convergence of the evaluation of the service effect feedback text of the two operation and maintenance service records. When the problem similarity, step overlap, type correlation, and evaluation convergence of any two operation and maintenance service records all exceed the corresponding preset thresholds, an association edge is established between the two operation and maintenance service records, and the standardized weighted average of the problem similarity, step overlap, type correlation, and evaluation convergence is determined as the association strength value of the association edge. All established edges and their corresponding operation and maintenance service records are used as nodes to form a target relational network structure that includes node attributes, edge attributes, and relation strength values.

3. The multi-dimensional knowledge extraction and construction method for operation and maintenance technical services according to claim 1, characterized in that, The process of performing information complementarity analysis on each maintenance service record within each core record cluster identifies differentiated fault descriptions in service request texts across different maintenance service records, complementary operation steps in execution sequences across different maintenance service records, and alternative resource types in resource call records across different maintenance service records, including: The problem feature vectors of service request texts of all operation and maintenance service records in the core record cluster are clustered to obtain multiple problem feature clusters, and each problem feature cluster corresponds to a type of core fault problem. For each problem feature cluster, the service request text of the operation and maintenance service record is decomposed into a fault description. The fault occurrence environment, fault manifestation form and fault impact range of each service request text are extracted. The differentiated description content of the same core fault problem in different service request texts is identified to form a differentiated fault description list. The operation steps of all operation and maintenance service records in the core record cluster are sequence aligned, and a standard operation step framework is constructed based on the logical relationship between the operation steps. Identify additional operation steps in the execution operation sequence of each operation and maintenance service record that are not included in the standard operation step framework, determine whether the additional operation steps can solve special cases not covered by the standard operation step framework, and identify the additional operation steps that can solve special cases as complementary operation steps. The resource types of all operation and maintenance service records in the core record cluster are classified and statistically analyzed to obtain the call frequency of each resource type. The resource types whose call frequency exceeds the preset frequency threshold are identified as core resource types. Identify other resource types that are called simultaneously in the operation and maintenance service records of calling the core resource type, determine whether the other resource types can complete the same function when the core resource type is unavailable, and identify the other resource types that can complete the same function as alternative resource types; The differentiated fault description list, complementary operation steps, and alternative resource types are compiled into information complementarity analysis results.

4. The multi-dimensional knowledge extraction and construction method for operation and maintenance technical services according to claim 1, characterized in that, The dynamic knowledge system construction process for the set of operation and maintenance knowledge modules, forming a target operation and maintenance knowledge system with self-adjustment capabilities, includes: The initial classification framework of the operation and maintenance knowledge system is set. The classification framework of the operation and maintenance knowledge system includes three levels: scenario category, scenario subcategory, and scenario detail category. Each level is divided into multiple classification tags according to the business attributes of the operation and maintenance service. Each operation and maintenance knowledge module in the set of operation and maintenance knowledge modules is assigned to the corresponding scenario sub-category in the classification framework of the operation and maintenance knowledge system based on the matching degree between the scenario fault feature set of the operation and maintenance knowledge module and the classification labels of each level in the classification framework of the operation and maintenance knowledge system, thus forming an initial multi-dimensional knowledge system. Record the frequency of use scenarios for each operation and maintenance knowledge module in actual applications and the cross-scenario reuse rate of each operation and maintenance knowledge module. The frequency of use scenarios is the number of operation and maintenance scenarios corresponding to when the operation and maintenance knowledge module is called. The cross-scenario reuse rate is the ratio of the number of times the operation and maintenance knowledge module is called in non-initial allocation scenarios to the total number of times the operation and maintenance knowledge module is called. Collect adaptation feedback for each operation and maintenance knowledge module after its application in new scenarios. The adaptation feedback includes the applicability score of the operation and maintenance knowledge module's operation process, the matching score of the operation and maintenance knowledge module's resource configuration, and the effectiveness score of the operation and maintenance knowledge module's fault contingency plan. When the cross-scenario reuse rate of any operation and maintenance knowledge module exceeds the preset reuse threshold, analyze the common features of multiple scenarios that the operation and maintenance knowledge module is adapted to, add a scenario subclass or scenario sub-class corresponding to the common features in the classification framework of the operation and maintenance knowledge system, and assign the operation and maintenance knowledge module to both the newly added classification and the original classification of the operation and maintenance knowledge module. When the adaptation feedback score of any operation and maintenance knowledge module is lower than the preset score threshold, analyze the reason for the lower score threshold. If the operation and maintenance knowledge module is missing operation procedures, supplement the operation and maintenance knowledge module in the new scenario. If the operation and maintenance knowledge module is mismatched in resource configuration, update the resource candidate list of the operation and maintenance knowledge module to form an adjusted operation and maintenance knowledge module. Based on the frequency of use scenarios of all operation and maintenance knowledge modules, the cross-scenario reuse rate of all operation and maintenance knowledge modules, and the adaptation feedback of all operation and maintenance knowledge modules, the hierarchical structure of the classification framework of the operation and maintenance knowledge system, the classification tags of the classification framework of the operation and maintenance knowledge system, and the classification affiliation of all operation and maintenance knowledge modules are adjusted regularly to form a target operation and maintenance knowledge system with self-adjustment capabilities.

5. The multi-dimensional knowledge extraction and construction method for operation and maintenance technical services according to claim 4, characterized in that, The process involves periodically adjusting the hierarchical structure of the operations and maintenance (O&M) knowledge system's classification framework, the classification tags of the O&M knowledge system's classification framework, and the classification affiliation of all O&M knowledge modules based on the frequency of use scenarios for all O&M knowledge modules, the cross-scenario reuse rate of all O&M knowledge modules, and the adaptation feedback of all O&M knowledge modules. This includes: Set an adjustment cycle. Within each adjustment cycle, count the number of operation and maintenance knowledge modules under each scenario sub-category in the classification framework of the operation and maintenance knowledge system. If the number of operation and maintenance knowledge modules under any scenario sub-category exceeds the preset module number threshold, then split the scenario sub-category into multiple new scenario sub-categories. Each new scenario sub-category corresponds to different sub-scenario features of the operation and maintenance knowledge modules. If the number of operation and maintenance knowledge modules under any scenario subclass is less than the preset module number threshold, and the similarity of the scenario features of the operation and maintenance knowledge modules of the scenario subclass with those of the adjacent scenario subclass exceeds the preset similarity threshold, then the scenario subclass will be merged into the adjacent scenario subclass. The average usage frequency of operation and maintenance knowledge modules under each category tag in the classification framework of the operation and maintenance knowledge system is calculated. If the average usage frequency of operation and maintenance knowledge modules under any category tag is lower than the preset frequency threshold, the category tag is deleted and the operation and maintenance knowledge modules under the category tag are reassigned to other relevant category tags in the classification framework of the operation and maintenance knowledge system. For each operation and maintenance knowledge module, recalculate the matching degree between the scenario fault feature set of the operation and maintenance knowledge module and the classification labels of each level in the classification framework of the current operation and maintenance knowledge system. Adjust the classification of the operation and maintenance knowledge module according to the new matching degree so that the operation and maintenance knowledge module is assigned to the category with the highest matching degree. Record the classification framework of the operation and maintenance knowledge system for each adjustment, the changes in the classification and affiliation of the operation and maintenance knowledge modules for each adjustment, and the basis for each adjustment, and form an adjustment log.

6. The multi-dimensional knowledge extraction and construction method for operation and maintenance technical services according to claim 1, characterized in that, Based on the target operation and maintenance knowledge system, the process of generating an operation and maintenance service response containing resource optimization suggestions for newly received operation and maintenance service requests includes: Upon receiving a new operation and maintenance service request, the system performs scenario feature extraction processing on the new operation and maintenance service request, extracting the fault description text, available resource types, and service target requirements from the new operation and maintenance service request to form a request scenario feature vector for the new operation and maintenance service request. Calculate the similarity between the request scenario feature vector of the new operation and maintenance service request and the scenario fault feature set of each operation and maintenance knowledge module in the target operation and maintenance knowledge system, and determine the operation and maintenance knowledge modules whose similarity exceeds the preset scenario similarity threshold as candidate knowledge modules; Extract the resource constraints from the new operation and maintenance service request. The resource constraints in the new operation and maintenance service request include restrictions on available resource types, resource quantity, and resource access permissions. Analyze the resource candidate list for each candidate knowledge module, determine whether the resource types in the resource candidate list of the candidate knowledge module meet the available resource type restrictions in the new operation and maintenance service request, determine whether the resource quantity requirements in the resource candidate list of the candidate knowledge module are within the available quantity range in the new operation and maintenance service request, and determine whether the resource calls in the resource candidate list of the candidate knowledge module meet the permission restrictions in the new operation and maintenance service request. For resource types that meet the resource constraints in the new operation and maintenance service request, retain the priority of the resource type in the resource candidate list of the candidate knowledge module. For resource types that do not meet the resource constraints in the new operation and maintenance service request, remove them from the resource candidate list of the candidate knowledge module and supplement them with alternative resource types that meet the resource constraints in the new operation and maintenance service request and the calling rules of the alternative resource types. Based on the adjusted resource candidate list of candidate knowledge modules, optimize the complete operation process sequence of the candidate knowledge modules, and adjust the resource calling scheme corresponding to each operation step in the complete operation process sequence of the candidate knowledge modules so that the complete operation process sequence of the candidate knowledge modules matches the resource constraints in the new operation and maintenance service request. Extract the complete operation process sequence, resource alternative list, and fault contingency plan from the adjusted candidate knowledge modules. Combine these with the service objective requirements of the new operation and maintenance service request to supplement the execution priority suggestions for the complete operation process sequence of the candidate knowledge modules and the resource allocation optimization scheme of the candidate knowledge modules, thus forming the operation and maintenance service response content. The operation and maintenance service response content is sent to the terminal device that initiated the new operation and maintenance service request, and the invocation scenario of the candidate knowledge module and the adaptation and adjustment content of the candidate knowledge module are recorded.

7. The multi-dimensional knowledge extraction and construction method for operation and maintenance technical services according to claim 6, characterized in that, The calculation of the similarity between the request scenario feature vector of the new operation and maintenance service request and the scenario fault feature set of each operation and maintenance knowledge module in the target operation and maintenance knowledge system, and the determination of operation and maintenance knowledge modules whose similarity exceeds a preset scenario similarity threshold as candidate knowledge modules, includes: The scenario fault feature set of each operation and maintenance knowledge module is converted into feature vector form to obtain the knowledge module feature vector of each operation and maintenance knowledge module. The dimension of the knowledge module feature vector of each operation and maintenance knowledge module is consistent with the dimension of the request scenario feature vector of the new operation and maintenance service request. Calculate the Euclidean distance between the request scenario feature vector of the new operation and maintenance service request and the knowledge module feature vector of each operation and maintenance knowledge module, and at the same time calculate the cosine similarity between the request scenario feature vector of the new operation and maintenance service request and the knowledge module feature vector of each operation and maintenance knowledge module. Multiply the normalized result of the Euclidean distance between the request scenario feature vector of the new operation and maintenance service request and the knowledge module feature vector of each operation and maintenance knowledge module by the Euclidean distance weight, and multiply the cosine similarity between the request scenario feature vector of the new operation and maintenance service request and the knowledge module feature vector of each operation and maintenance knowledge module by the cosine similarity weight. Add the two to obtain the comprehensive similarity value. Operation and maintenance knowledge modules whose comprehensive similarity value exceeds the scene similarity threshold are marked as candidate knowledge modules; For all candidate knowledge modules, the average score of the adaptation feedback of each candidate knowledge module in historical applications is calculated. Candidate knowledge modules with an average score exceeding a preset score threshold are identified as candidate knowledge modules. The candidate knowledge modules are then sorted in descending order of comprehensive similarity value to form a candidate knowledge module sequence.

8. The multi-dimensional knowledge extraction and construction method for operation and maintenance technical services according to claim 1, characterized in that, The full record of operation and maintenance services generated during the process of obtaining operation and maintenance technical services includes: Deploy operation and maintenance service record collection nodes, which are respectively connected to the operation and maintenance service request acceptance system, the operation and maintenance operation execution system, the resource scheduling system and the service evaluation feedback system; The system collects the submission time of all service requests, the terminal identifier that initiated all service requests, and the service request text of all service requests from the operation and maintenance service request acceptance system to form a subset of request records. The operation and maintenance operation execution system collects the operation execution account corresponding to each service request, the operation sequence corresponding to each service request, the operation start time corresponding to each service request, the operation end time corresponding to each service request, and the operation process log corresponding to each service request to form an operation record subset; The resource scheduling system collects the resource type, resource identifier, start time, end time, and usage status of each service request during execution, forming a subset of resource records. The evaluation submission time, evaluation initiation terminal identifier, service effect feedback text, and rating information of each service request are collected from the service evaluation feedback system to form a subset of feedback records. Based on the unique identifier of the service request, the corresponding records in the request record subset, operation record subset, resource record subset, and feedback record subset are associated and integrated to form each operation and maintenance service record containing complete information. All associated and integrated operation and maintenance service records are summarized to obtain the full operation and maintenance service record.

9. A multi-dimensional knowledge extraction and construction system applied to operation and maintenance technical services, characterized in that, The method includes a processor and a memory, the memory and the processor being connected. The memory is used to store programs, instructions or code, and the processor is used to execute the programs, instructions or code in the memory to implement the multi-dimensional knowledge extraction and construction method for operation and maintenance technical services as described in any one of claims 1-8.

Images