Large model reasoning optimization method and system for operation and maintenance technology service

Abstract

The invention provides a large model reasoning optimization method and system for operation and maintenance technical services, and the method comprises the steps: firstly obtaining a set comprising a plurality of to-be-processed operation and maintenance service requests, each to-be-processed operation and maintenance service request carrying operation and maintenance demand description information and an equipment operation scene identifier; performing priority dynamic calibration on operation and maintenance reasoning tasks based on the information, generating a priority list, deploying computing resources and operation and maintenance knowledge resources of large model reasoning according to the priority list and reasoning link requirements, forming a collaborative scheduling scheme, configuring a reasoning process according to the collaborative scheduling scheme, and executing large model reasoning; and finally, converting the result into an operation and maintenance response instruction in combination with the equipment operation scene identifier, and sending the operation and maintenance response instruction to the execution terminal, so that accurate processing of the operation and maintenance task, reasonable allocation of resources and efficient response of the operation and maintenance service are realized.

Description

Technical Field

[0001] The present application relates to the field of operation and maintenance technology, and specifically, to a large-scale model reasoning optimization method and system for operation and maintenance technology services. Background Art

[0002] In today's O&M technology services landscape, the number and types of O&M service requests are increasingly diverse as the variety and complexity of equipment continues to increase. Traditional O&M service processing methods often employ a fixed process to address various requests, lacking the flexibility to adapt to diverse O&M scenarios and requirements.

[0003] When processing maintenance service requests, existing maintenance systems often fail to fully consider the device operating scenario identifiers and specific maintenance requirement descriptions associated with each request. This results in an inability to prioritize requests based on their importance and urgency when faced with a large number of concurrent requests. This can lead to critical and urgent maintenance tasks being delayed while less important tasks consume significant resources.

[0004] Furthermore, when applying large-scale model reasoning to operations and maintenance services, there's a lack of scientific and rational methods for allocating the computing resources and operational knowledge resources required for reasoning. This often follows a fixed resource allocation model, without dynamic adjustments based on the characteristics and requirements of different operational and maintenance reasoning tasks. This results in low resource utilization, an inability to fully leverage the advantages of large models in operational and maintenance technical services, and compromises the quality and efficiency of these services. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide a large-scale model reasoning optimization method and system for operation and maintenance technical services.

[0006] According to a first aspect of the present application, a large model reasoning optimization method for operation and maintenance technical services is provided, the method comprising: Obtain an operation and maintenance service request set under an operation and maintenance technical service scenario, wherein the operation and maintenance service request set includes multiple operation and maintenance service requests to be processed, each operation and maintenance service request carrying operation and maintenance requirement description information and an associated equipment operation scenario identifier; Based on the operation and maintenance requirement description information and the equipment operation scenario identifier of each operation and maintenance service request in the operation and maintenance service request set, dynamically calibrate the priority of the operation and maintenance reasoning task corresponding to each operation and maintenance service request to generate an operation and maintenance reasoning task priority list; According to the operation and maintenance reasoning task priority list and the reasoning link requirements corresponding to each operation and maintenance reasoning task, the computing resources and operation and maintenance knowledge resources required for large model reasoning are deployed to generate a collaborative scheduling plan for reasoning resources and knowledge; According to the reasoning resource and knowledge collaborative scheduling scheme, an adaptive reasoning process is configured for each operation and maintenance reasoning task, and large-scale model reasoning processing is performed through the deployed computing resources to generate an operation and maintenance reasoning result corresponding to the operation and maintenance service request; Combined with the equipment operation scenario identifier associated with the operation and maintenance service request, the operation and maintenance reasoning result is converted into an operation and maintenance response instruction that complies with the equipment operation scenario operation specification, and the operation and maintenance response instruction is sent to the corresponding operation and maintenance execution terminal.

[0007] According to the second aspect of the present application, a large model reasoning optimization system for operation and maintenance technical services is provided. The large model reasoning optimization system for operation and maintenance technical services includes a machine-readable storage medium and a processor. The machine-readable storage medium stores machine-executable instructions. When the processor executes the machine-executable instructions, the large model reasoning optimization system for operation and maintenance technical services implements the aforementioned large model reasoning optimization method for operation and maintenance technical services.

[0008] According to the third aspect of the present application, a computer-readable storage medium is provided, in which computer-executable instructions are stored. When the computer-executable instructions are executed, the aforementioned large-model reasoning optimization method for operation and maintenance technical services is implemented.

[0009] According to any of the above aspects, the technical effects of this application are: By obtaining a set of operation and maintenance service requests under the operation and maintenance technical service scenario, and dynamically calibrating the priority based on the operation and maintenance requirement description information and equipment operation scenario identification of each request, an operation and maintenance reasoning task priority list is generated. This can accurately identify the importance and urgency of different operation and maintenance tasks, ensure that key tasks are processed first, optimize the processing order of operation and maintenance tasks from the source, and improve the response speed and pertinence of operation and maintenance services. According to the priority list and reasoning link requirements, the computing resources and operation and maintenance knowledge resources required for large-scale model reasoning are allocated, and a collaborative scheduling plan for reasoning resources and knowledge is generated, which realizes dynamic and reasonable allocation of resources, avoids waste and idleness of resources, gives full play to the reasoning ability of large models, and improves resource utilization efficiency. According to the scheduling plan, an adaptive reasoning process is configured and large-scale model reasoning processing is executed to generate accurate operation and maintenance reasoning results. Combined with the equipment operation scenario identification, it is converted into operation and maintenance response instructions that comply with operating specifications and sent to the execution terminal, significantly improving the quality and efficiency of operation and maintenance technical services. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a basic introduction to the drawings required for use in the embodiments. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without paying any creative work.

[0011] Figure 1 A flow chart of a large model reasoning optimization method for operation and maintenance technical services provided by an embodiment of the present application is shown; Figure 2 A schematic diagram of the component structure of a large model reasoning optimization system for operation and maintenance technical services provided in an embodiment of the present application for implementing the above-mentioned large model reasoning optimization method for operation and maintenance technical services is shown. DETAILED DESCRIPTION

[0012] The following describes the embodiments of the present application in conjunction with the accompanying drawings. It should be understood that the embodiments described below in conjunction with the accompanying drawings are exemplary descriptions for explaining the technical solutions of the embodiments of the present application and do not constitute a limitation on the technical solutions of the embodiments of the present application.

[0013] Figure 1 The flowchart of the large-scale model reasoning optimization method and system for operation and maintenance technical services provided by the embodiment of the present application is shown. It should be understood that in other embodiments, the order of some steps in the large-scale model reasoning optimization method for operation and maintenance technical services of this embodiment can be shared with each other according to actual needs, or some steps can be omitted or maintained. The detailed steps of the large-scale model reasoning optimization method for operation and maintenance technical services include: Step S110: obtaining an operation and maintenance service request set in an operation and maintenance technical service scenario, wherein the operation and maintenance service request set includes multiple operation and maintenance service requests to be processed, and each operation and maintenance service request carries operation and maintenance requirement description information and an associated equipment operation scenario identifier.

[0014] This example uses the operation and maintenance of smart devices in chain stores as its application context. The devices involved include smart air conditioners, store information display screens, and IoT control systems. The collection of operation and maintenance service requests comes from technical support requests initiated by on-site engineers at each chain store via mobile terminals, as well as automatic repair requests generated by the system after detecting device anomalies. Each operation and maintenance service request includes a complete description of the operation and maintenance requirements and the corresponding device operation scenario identifier.

[0015] The operation and maintenance requirement description information presents different content depending on the request type. In the request initiated by the on-site engineer, the operation and maintenance requirement description information includes the time when the problem occurred, the equipment abnormality, the preliminary troubleshooting operations performed and the troubleshooting results; in the request automatically generated by the system, the operation and maintenance requirement description information includes data such as the abnormal parameter monitoring value, the duration of the parameter abnormality, and the frequency of the abnormality. The equipment operation scenario identifier is a string composed of letters and numbers, including the store code to which the equipment belongs, the equipment type code, the installation area code and the current operation mode code. For example, "STXYZ-KT-XX-C" means that the air-conditioning equipment installed in a specific area of ​​a store is in cooling operation mode.

[0016] These maintenance service requests are aggregated via an encrypted transmission protocol to the technology center's request processing server. The server performs format verification on each request to ensure the integrity of the maintenance requirement description and the validity of the device operation scenario identifier. Once verified, all requests are temporarily stored in a request queue in chronological order, forming a pending maintenance service request set for subsequent priority determination.

[0017] Step S120: Based on the operation and maintenance requirement description information and equipment operation scenario identifier of each operation and maintenance service request in the operation and maintenance service request set, dynamically calibrate the priority of the operation and maintenance reasoning task corresponding to each operation and maintenance service request to generate an operation and maintenance reasoning task priority list.

[0018] For each request in the O&M service request set, the Technical Center's Task Calibration Module extracts the O&M requirement description and the device operating scenario identifier, and determines the corresponding O&M reasoning task priority through multi-dimensional analysis. First, the core issue type in the O&M requirement description is analyzed to determine whether it is an emergency failure, parameter anomaly, or a routine inspection request. Simultaneously, the device operating scenario identifier is decoded to obtain scenario information such as the importance of the store where the device is located and the device's function type.

[0019] Each O&M reasoning task is evaluated using a pre-set priority evaluation logic, taking into account the urgency of the problem type and the importance of the equipment in the scenario information. For example, the evaluation result for the reasoning task corresponding to an air conditioning and refrigeration failure in a core store is higher than the task of fine-tuning the display parameters of the information display screen in a regular store. All O&M reasoning tasks are sorted from high to low based on the evaluation results to form an O&M reasoning task priority list. The list includes the task ID, the corresponding requested equipment operation scenario ID, and the priority evaluation details.

[0020] Step S121: extracting the operation and maintenance task type from the operation and maintenance requirement description information of each operation and maintenance service request, wherein the operation and maintenance task type includes equipment fault handling task, equipment parameter configuration task, and equipment operation status monitoring task.

[0021] The task type extraction module performs semantic analysis on the O&M requirement description information and determines the O&M task type through keyword matching and intent recognition. Equipment fault handling task descriptions typically include keywords such as "fault," "abnormal," and "failure to operate," for example, "the air conditioner suddenly shuts down during operation, and the display screen is blank." Equipment parameter configuration task descriptions include keywords such as "adjust," "set," and "calibrate," for example, "the brightness parameter of the information display needs to be adjusted to the standard value." Equipment operating status monitoring tasks include keywords such as "inspect," "monitor," and "patrol," for example, "regularly monitor the communication status of the IoT controller."

[0022] After each maintenance service request is accurately categorized into its corresponding task type, the system adds a task type tag. This tag is stored as a numeric code, such as "01" for a device troubleshooting task, "02" for a device parameter configuration task, or "03" for a device operating status monitoring task. These tags serve as a basis for subsequent priority evaluation, ensuring differentiated priority evaluation logic for different task types.

[0023] Step S122: parse the device operation scenario identifier associated with each operation and maintenance service request to determine the system level to which the device corresponds, the service link associated with the device, and the current operation stage of the device.

[0024] The device operation scenario identifier resolution module decodes the identifier string segment by segment according to preset encoding rules. For example, for the identifier "STXYZ-KT-XX-C," the module first extracts "STXYZ" as the store code. A query in the store information database reveals that the store is a regional core store, and the corresponding device belongs to the first-level core layer. The module then extracts "KT" as the device type code, confirming that it is air conditioning equipment. The associated business link is the environmental control link, which directly affects the store customer experience. "XX" is then extracted as the installation area code, corresponding to the store lobby area. Finally, "C" is extracted as the operating mode code, representing the cooling operation phase.

[0025] After analysis is complete, structured scenario information is generated, including the device's system layer (level 1 core layer / level 2 standard layer / level 3 auxiliary layer), the device's associated service links (environmental control / information display / security monitoring, etc.), and the device's current operating stage (startup / stable operation / standby, etc.). This information is combined with the operation and maintenance task type to determine the priority level.

[0026] Step S123: Determine the basic priority level based on the association between the operation and maintenance task type and the system level to which the equipment belongs, wherein the basic priority level corresponding to the equipment fault handling task takes precedence over the equipment parameter configuration task, and the basic priority level corresponding to the equipment parameter configuration task takes precedence over the equipment operation status monitoring task.

[0027] Basic priority levels are divided according to both task type and system level. According to the pre-set association rules, the basic priority of the device fault handling task is higher than that of the other two types of tasks at any system level. The basic priority of the device parameter configuration task is higher than that of the device operating status monitoring task, but lower than that of the device fault handling task. The device operating status monitoring task has the lowest basic priority.

[0028] At the same time, the system fine-tunes the basic priority levels. The basic priority of similar tasks for first-tier core devices is higher than for second-tier standard devices, which in turn are higher than for third-tier auxiliary devices. For example, first-tier core device parameter configuration tasks have a higher basic priority than second-tier standard devices, and first-tier core device status monitoring tasks have a higher basic priority than second-tier standard devices. Through this dual-dimensional evaluation, an initial basic priority level is determined for each operation and maintenance reasoning task.

[0029] Step S124: The basic priority level is adjusted in combination with the service link attribute associated with the device, and the priority level of the operation and maintenance reasoning task corresponding to the operation and maintenance service request whose service link is the core service link is adjusted upward.

[0030] The business link attribute assessment module determines whether a device is a core business link based on the type of business link associated with it. In chain store scenarios, environmental control links (air conditioning equipment) and main information display links (main display screens) are core business links. Interruptions or anomalies in these links will directly impact normal store operations. Auxiliary lighting control and backend data backup links, on the other hand, are non-core business links.

[0031] For O&M reasoning tasks with the same basic priority level, if their associated service links are core service links, their priority level will be adjusted upward by one level. For example, if both are device parameter configuration tasks and are at the same system level, the air conditioning parameter adjustment task for the core service link will have a higher priority than the background device parameter adjustment task for the non-core service link. A record of the adjusted priority level will be retained, noting that the adjustment was based on the service link attributes.

[0032] Step S125: Based on the timeliness requirement of the operation and maintenance response in the current operation stage of the device, the priority level is further adjusted, and the priority level of the operation and maintenance reasoning task corresponding to the operation and maintenance service request whose operation and maintenance response meets the immediate response requirement is adjusted upward again.

[0033] The equipment's current operating stage determines the timeliness of O&M responses. Equipment in peak operation (such as air conditioners in stores during peak business hours) has the highest O&M response timeliness requirements, requiring immediate responses. Equipment in stable operation has the next highest timeliness requirements, while equipment in standby or low-load mode has the lowest.

[0034] The timeliness assessment module determines whether an immediate response is required based on the current operational stage of the equipment. For maintenance service requests requiring an immediate response, their priority level is adjusted upward based on the adjusted priority level. For example, an air conditioning troubleshooting task in a core store during peak business hours will have its priority level raised again after system-level and business-link adjustments, as it requires an immediate response during peak operation, ensuring top resource allocation.

[0035] Step S126: Integrate the final priority level corresponding to each operation and maintenance service request, arrange the operation and maintenance reasoning tasks corresponding to all operation and maintenance service requests in order of priority level from highest to second highest, and generate an operation and maintenance reasoning task priority list.

[0036] The priority level integration module collects the final priority level of each operational reasoning task after multi-dimensional adjustments. The levels are divided into four levels: "P0 (highest)", "P1", "P2", and "P3 (lowest)". All tasks are sorted from high to low by their final priority level. Tasks of the same level are arranged in the order of receipt time.

[0037] The generated operational reasoning task priority list includes the task's unique identifier, the corresponding device operating scenario identifier, the final priority level, priority adjustment details, and the estimated processing time. This list is stored in a structured data format and synchronized in real time to the resource scheduling module, serving as the core basis for allocating computing and knowledge resources, ensuring that high-priority tasks receive the required resources first.

[0038] Step S130: According to the operation and maintenance reasoning task priority list and the reasoning link requirements corresponding to each operation and maintenance reasoning task, the computing resources and operation and maintenance knowledge resources required for large model reasoning are deployed to generate a reasoning resource and knowledge collaborative scheduling plan.

[0039] After receiving the priority list of operational reasoning tasks, the resource scheduling module first analyzes the inference link requirements for each operational reasoning task, determining the type of computing resources (e.g., GPU nodes, CPU nodes), the quantity of computing resources, and the scope of operational knowledge resources required to complete the task. Resources are allocated preferentially to high-priority tasks based on the order of the priority list.

[0040] When allocating computing resources, the load on available compute nodes must be considered to avoid resource overload. When allocating knowledge resources, it's necessary to establish associations between reasoning tasks and related knowledge sub-repositories to ensure rapid access to required knowledge data during reasoning. Ultimately, the resource allocation results are integrated into a collaborative scheduling plan for reasoning resources and knowledge, which specifies the compute node allocation, knowledge sub-repository associations, and resource usage periods for each task.

[0041] Step S131: Analyze the reasoning link requirements corresponding to each operation and maintenance reasoning task, and determine the type of reasoning computing nodes, the number of reasoning nodes, and the associated operation and maintenance knowledge domain required for each reasoning link requirement.

[0042] The inference link requirements analysis module breaks down each operation and maintenance inference task and determines the inference link requirements based on the task's complexity and processing logic. For complex equipment fault diagnosis tasks, the inference link is long, requiring compute nodes with deep inference capabilities. For simple parameter query tasks, the inference link is short, and basic inference nodes can meet the requirements.

[0043] By analyzing the technical areas and processing steps involved in the task, we determine the required inference computing node type (deep inference node or basic inference node), the number of inference nodes required to complete the task (single node or multi-node parallel), and the associated operation and maintenance knowledge areas (such as air conditioning fault handling and information release equipment parameters). These analysis results will serve as a direct basis for resource allocation, ensuring accurate resource allocation.

[0044] Step S1311: Decompose each operation and maintenance reasoning task into multiple reasoning subtasks, each reasoning subtask corresponds to a link in the reasoning chain, and determine the processing logic and data interaction requirements of each reasoning subtask.

[0045] The task decomposition module breaks down maintenance reasoning tasks into multiple, interconnected reasoning subtasks based on the reasoning process. For example, the air conditioning and refrigeration fault diagnosis task can be broken down into the "fault phenomenon identification subtask," "fault cause analysis subtask," "maintenance plan generation subtask," and "plan verification subtask."

[0046] Each reasoning subtask has a clearly defined processing logic. For example, the fault phenomenon identification subtask's processing logic is to "extract key phenomenon features from the O&M requirement description and match them with the fault feature library." Data interaction requirements are also defined, including input data types (such as phenomenon description text and device parameters), output data types (such as phenomenon feature vectors and matching scores), and data transfer relationships with other subtasks. This breakdown ensures that resource requirements for each link can be accurately assessed.

[0047] Step S1312: According to the processing logic of each reasoning subtask, determine the reasoning computing node type required for the reasoning subtask, where the reasoning subtask involving deep fault causal analysis corresponds to the deep reasoning requirement node type, and the reasoning subtask involving basic parameter query corresponds to the basic reasoning requirement node type.

[0048] The computational node type determination module categorizes the reasoning subtasks based on their processing logic complexity. Subtasks involving deep fault causal analysis, multi-factor correlation reasoning, and complex solution generation are classified as requiring deep reasoning nodes, as they require multi-level feature extraction and logical reasoning. Subtasks involving basic parameter query, simple rule matching, and standardized result output are classified as requiring basic reasoning nodes.

[0049] For example, the air conditioner failure cause analysis subtask requires analyzing the correlation between multiple parameters such as refrigerant pressure, compressor current, and ambient temperature, which requires deep reasoning. The standard operating procedure query subtask for maintenance plans requires basic reasoning. Different types of nodes are equipped with different hardware resources and reasoning models to ensure processing efficiency and accuracy.

[0050] Step S1313: Count the number of reasoning subtasks included in each operation and maintenance reasoning task and the parallel processing possibility of each reasoning subtask, and determine the number of reasoning nodes required for the operation and maintenance reasoning task. The more reasoning subtasks that can be processed in parallel, the more reasoning nodes are required.

[0051] The inference node count module counts the total number of inference subtasks within each operational inference task and analyzes the dependencies between them. Subtasks with no or weak dependencies are considered suitable for parallel processing; subtasks with strong dependencies (e.g., requiring the completion of a preceding subtask) are considered serial.

[0052] The number of inference nodes required is determined by the number of subtasks that can be processed in parallel, adhering to the principle of "matching the number of parallel subtasks with the number of nodes." For example, if a task contains multiple inference subtasks, some of which can be processed in parallel, a corresponding number of inference nodes should be allocated to achieve parallel processing and shorten the overall inference time. Node redundancy should also be considered, with a certain number of backup nodes reserved for emergencies.

[0053] Step S1314: Extract the operation and maintenance knowledge content that needs to be referenced during the processing of each reasoning subtask, and determine the associated operation and maintenance knowledge field based on the category of the operation and maintenance knowledge content. Among them, the fault diagnosis reasoning subtask is associated with the fault processing knowledge field, and the parameter configuration reasoning subtask is associated with the parameter standard knowledge field.

[0054] The knowledge domain association module scans the processing logic of each reasoning subtask and extracts keywords related to the operational knowledge content, such as "air conditioning compressor fault code," "refrigerant charging standard pressure," and "display brightness adjustment parameter range." The knowledge domain classification system matches these keywords to determine the operational knowledge domain associated with each subtask.

[0055] Fault diagnosis subtasks primarily involve the fault handling knowledge domain, which includes a fault code library, fault causal relationship diagrams, and a collection of typical fault cases. Parameter configuration subtasks primarily involve the parameter standard knowledge domain, which includes equipment parameter specification tables, parameter adjustment manuals, and parameter exception handling guides. Each subtask can be associated with multiple knowledge domains to ensure comprehensive knowledge coverage during the reasoning process.

[0056] Step S1315: Integrate the inference computing node type, the number of inference nodes, and the associated operation and maintenance knowledge domain corresponding to each operation and maintenance reasoning task to form a description of the inference link requirements for each operation and maintenance reasoning task.

[0057] The inference link requirement integration module aggregates the required parameters for each operational reasoning task to form a structured inference link requirement description. This description includes the task identifier, a list of inference computing node types (arranged by subtask order), the total number of required inference nodes, a list of associated operational knowledge domains, and the priority of knowledge invocation for each domain.

[0058] For example, the reasoning link requirements description for an air conditioning fault diagnosis task specifies a deep reasoning requirement node for the fault cause analysis subtask and a basic reasoning requirement node for the fault code query subtask. A corresponding number of reasoning nodes must be allocated, linking the fault handling knowledge domain (priority 1) and the parameter standard knowledge domain (priority 2). This reasoning link requirements description serves as the input document for resource allocation, ensuring that resource allocation accurately matches task requirements.

[0059] Step S132: sorting out the available computing resource pool in the operation and maintenance technical service scenario, wherein the available computing resource pool includes multiple inference computing nodes, and each inference computing node is marked with the node service capability and the number of inference tasks currently carried.

[0060] The computing resource sorting module regularly scans the technology center's computing resource clusters and collects status information for all available inference computing nodes. Each inference computing node is labeled with information including its unique identifier, hardware configuration parameters (such as processor type, memory capacity, and number of computing cores), supported inference model types, node service capability level (high / medium / low), and the number of inference tasks currently being carried.

[0061] The available computing resource pool is categorized and stored by node service capability level, forming a resource index table. This resource index table is updated in real time, and information is promptly refreshed when the number of tasks a node carries changes or when a node's status changes (e.g., offline or undergoing maintenance). This allows the resource scheduling module to clearly understand the current resource supply situation.

[0062] Step S133: arranging the operation and maintenance knowledge resource base in the operation and maintenance technical service scenario, wherein the operation and maintenance knowledge resource base is divided into multiple knowledge sub-bases according to the operation and maintenance knowledge field, and each knowledge sub-base stores operation and maintenance cases, operation and maintenance operation specifications and equipment characteristic data in the corresponding field.

[0063] The knowledge resource organization module structures and categorizes the O&M knowledge resource library, dividing it into specialized sub-libraries, such as the air conditioning equipment knowledge sub-library, the information publishing equipment knowledge sub-library, and the IoT control knowledge sub-library, based on O&M knowledge domains. Each sub-library is further subdivided by knowledge type, including an O&M case library (storing historical troubleshooting records), an O&M operation specification library (storing standardized operating procedures), and an equipment feature database (storing equipment technical parameters and model difference data).

[0064] Each knowledge sub-repository is equipped with a knowledge indexing system and update mechanism to ensure the accuracy and timeliness of the knowledge content. The knowledge indexing system supports multi-dimensional searches by keyword, equipment model, fault type, and more. The update mechanism regularly extracts knowledge from new operation and maintenance cases and technical manuals and adds it to the corresponding sub-repository.

[0065] Step S134: According to the operation and maintenance reasoning task priority list, the core operation and maintenance reasoning tasks are preferentially assigned reasoning computing nodes whose service capabilities match their reasoning link requirements, so that the number of reasoning tasks currently carried by the reasoning computing nodes corresponding to the core operation and maintenance reasoning tasks does not exceed the preset proportion of the node's maximum carrying capacity.

[0066] The core task resource allocation module identifies core operational reasoning tasks (typically P0 and P1 tasks) from the operational reasoning task priority list and allocates resources in descending order of priority. For each core task, matching inference computing nodes are selected from the available computing resource pool based on the node type and service capability requirements of its inference link requirements.

[0067] During the screening process, we focus on checking the number of inference tasks currently carried by the node, ensuring that the node's load after allocation does not exceed a preset proportion of its maximum capacity, and reserving resources to cope with peak workloads. For example, a deep inference node may have a certain maximum load capacity and is currently carrying some tasks. We must ensure that newly assigned tasks do not exceed the preset proportion. If the current load approaches or exceeds this proportion, we will re-screen other nodes. This strict load control ensures the inference efficiency of core tasks.

[0068] Step S1341: extract core operation and maintenance reasoning tasks from the operation and maintenance reasoning task priority list, and process each core operation and maintenance reasoning task in order of priority from the highest priority to the second highest priority.

[0069] The core task extraction module scans the priority list of operational reasoning tasks and selects tasks with priority levels P0 and P1 as core operational reasoning tasks. P0 tasks are prioritized over P1 tasks, and core tasks of the same level are sorted according to their original order in the list.

[0070] A core task processing queue is established. Each task item in the queue contains a task identifier, a summary of the inference link requirements, and a label for the required resource type. The processing module calls the resource allocation interface sequentially in the queue order to match computing resources to each core task, ensuring that high-priority tasks receive priority resource support. During this sequential processing, the system generates a dedicated resource allocation session for each core task, recording task processing progress and resource matching status to avoid resource allocation conflicts between tasks.

[0071] Step S1342: For the core operation and maintenance reasoning task currently being processed, select the reasoning computing nodes whose service capabilities match the reasoning link requirements of the operation and maintenance reasoning task from the available computing resource pool to form a set of candidate reasoning computing nodes.

[0072] The resource screening module analyzes the inference link requirements of the current core operation and maintenance inference tasks, extracting the inference computing node type, service capability level, and hardware configuration requirements. Based on these parameters, it traverses all nodes in the available computing resource pool and selects inference computing nodes that meet the requirements using a node attribute matching algorithm.

[0073] During the screening process, the node type (deep inference-required or basic inference-required) is first matched to ensure that the node type aligns with the task requirements. Next, the node's service capability level is verified to ensure it meets the processing performance requirements of the task. Finally, the node's hardware configuration is checked to ensure it supports the inference model involved in the task. All qualified nodes are included in the candidate inference computing node set, which includes information such as node identification, current load status, and resource response speed for subsequent selection.

[0074] Step S1343: query the number of inference tasks currently carried by each candidate inference computing node in the candidate inference computing node set, and calculate the ratio of the number of inference tasks currently carried by each candidate inference computing node to the maximum carrying capacity of the node.

[0075] The load query module uses the resource monitoring interface to obtain real-time load data for each candidate inference computing node set, focusing on the number of inference tasks currently being carried. It also retrieves each node's maximum load capacity parameter, which is pre-set based on the node's hardware configuration and historical performance test results. It represents the maximum number of tasks a node can handle under stable operating conditions.

[0076] The calculation module calculates the ratio of each node's current number of tasks to its maximum capacity to determine the node's load factor. The load factor reflects the node's resource utilization; a lower ratio indicates more abundant remaining resources. The calculated result is associated with the node's ID and stored to form a candidate node load list.

[0077] Step S1344: Filter out candidate inference computing nodes whose ratio of the number of currently carried inference tasks to the maximum carrying capacity does not exceed a preset ratio threshold and use them as target inference computing nodes.

[0078] The threshold filtering module calls the preset load control strategy and extracts the load ratio threshold parameter. This load ratio threshold varies by node type. The threshold for nodes requiring deep reasoning is lower than that for nodes requiring basic reasoning, ensuring that complex tasks receive more sufficient resource support.

[0079] The load ratios in the candidate node load list are compared with the threshold, and nodes with load ratios below the threshold are selected as target inference computing nodes. If multiple nodes meet the criteria, they are sorted from fastest to slowest based on their resource response speed, with the fastest nodes being prioritized. Once the target node is determined, the system locks some of its resources to prevent them from being occupied by other tasks.

[0080] Step S1345: Allocate the core operation and maintenance reasoning task currently being processed to the target reasoning computing node, and update the number of reasoning tasks currently carried by the target reasoning computing node.

[0081] The task allocation module generates a task allocation instruction, which contains the core operation and maintenance inference task identifier, inference link parameters, and data transmission address. The instruction is sent to the target inference computing node through the resource scheduling interface. The node receives the instruction and returns a confirmation message, completing the task allocation process.

[0082] After task allocation is complete, the resource status update module immediately updates the number of tasks currently being carried by the target inference computing node, recalculates the node's load rate, and synchronizes it with the available computing resource pool. It also marks the task's allocation status as "allocated" in the core task processing queue and records the node ID and allocation time.

[0083] Step S1346: Repeat the above steps to complete the allocation of inference computing nodes for all core operation and maintenance inference tasks, and then allocate inference computing nodes for common operation and maintenance inference tasks according to the same process.

[0084] The loop processing module monitors the completion status of the core task processing queue. Once all P0 and P1-level tasks have completed node allocation, it initiates the resource allocation process for common operation and maintenance reasoning tasks (P2 and P3 levels). The allocation process for common tasks is the same as for core tasks, but they have lower load thresholds and resource selection priorities than core tasks.

[0085] During normal task allocation, the system prioritizes available resources remaining after core tasks are allocated, avoiding the use of spare resources that may be needed by core tasks. After all tasks are allocated, a resource allocation summary report is generated. The resource allocation summary report includes the node allocation status, resource utilization, and load balancing status of tasks at each level.

[0086] Step S135: Match the knowledge sub-base of the corresponding operation and maintenance knowledge domain to each operation and maintenance reasoning task, and establish an association mapping between the reasoning computing node and the knowledge sub-base, so that the reasoning computing node can directly call the associated knowledge sub-base when performing reasoning processing.

[0087] The knowledge sub-base matching module searches for the corresponding knowledge sub-base in the operation and maintenance knowledge resource library based on the list of operation and maintenance knowledge domains associated with each operation and maintenance reasoning task. Using a domain label matching algorithm, this ensures that each task is accurately matched to the relevant knowledge sub-base. For cross-domain tasks, multiple relevant sub-bases are matched.

[0088] The association mapping module establishes an association between the inference computing node and the matching knowledge sub-repository, generating an association mapping table. This mapping table records the node ID, knowledge sub-repository ID, knowledge call permissions, and data transmission path. When executing inference, the inference computing node can directly access the corresponding knowledge sub-repository through this mapping table to obtain the required operation and maintenance cases, operating specifications, and equipment characteristic data, without the need for additional knowledge retrieval processes.

[0089] Step S136: Record the inference computing node allocation results and knowledge sub-base matching results corresponding to each operation and maintenance inference task, and integrate them to form an inference resource and knowledge collaborative scheduling plan.

[0090] The scheduling plan generation module collects resource allocation data for all operational reasoning tasks, including the inference computing node identifiers, node configuration parameters, knowledge sub-base identifiers, and associated mapping relationships assigned to each task. This data is categorized and organized by task priority and resource type to form a structured scheduling plan document.

[0091] The plan document includes a resource allocation list, a knowledge association list, a resource usage schedule, and a conflict resolution mechanism. The resource usage schedule clearly defines the resource usage periods for each task to avoid resource conflicts; the conflict resolution mechanism specifies the rules for adjusting task priorities when resources are insufficient. After the plan is generated, it undergoes validity verification to ensure that the resource requirements of all tasks are met. Once verified, it is sent to the inference execution module to serve as the basis for inference process configuration.

[0092] Step S140: Based on the reasoning resource and knowledge collaborative scheduling scheme, an adaptive reasoning process is configured for each operation and maintenance reasoning task, and large-model reasoning processing is performed through the allocated computing resources to generate an operation and maintenance reasoning result corresponding to the operation and maintenance service request.

[0093] The inference process configuration module designs a unique inference process for each operational inference task based on the inference resource and knowledge collaborative scheduling scheme. This process design determines the inference phase division, processing logic for each phase, and knowledge call timing based on the task's inference link requirements, assigned compute node types, and matching knowledge sub-repositories.

[0094] After configuration is complete, the inference process parameters are sent to the corresponding inference computing node. The node loads the large model inference engine and initializes according to the process parameters. Inference processing is performed using the allocated computing resources. During the inference process, data from the associated knowledge sub-repository is called upon at preset times to assist in the execution of the inference logic. After the inference process is complete, an operational inference result is generated, containing operational action suggestions, their rationale, and associated data. The result is then stored in association with the corresponding operational service request.

[0095] Step S141: extracting the inference computing node allocation result and the knowledge sub-base matching result corresponding to each operation and maintenance inference task from the inference resource and knowledge collaborative scheduling solution.

[0096] The solution analysis module connects the reasoning resources and knowledge collaborative scheduling plan, splits the solution content according to the task ID, and extracts the reasoning computing node allocation results of each operation and maintenance reasoning task, including node ID, node type and resource configuration parameters; at the same time, it extracts the knowledge sub-base matching results, including knowledge sub-base ID, knowledge domain and call priority.

[0097] The extracted results are organized into structured data by task, with each task corresponding to a record containing node information and knowledge sub-base information. These records are then transferred to the inference process configuration module and serve as the basis for process design, ensuring that the configured inference process is compatible with the allocated resources and knowledge.

[0098] Step S142: According to the knowledge sub-base matching result, determine the type of operation and maintenance knowledge data and the calling timing to be called during the reasoning process of each operation and maintenance reasoning task, and generate a knowledge calling timing plan.

[0099] The knowledge call planning module analyzes the knowledge sub-base content in the knowledge sub-base matching results and determines the type of operation and maintenance knowledge data required for each operation and maintenance reasoning task at each stage of reasoning. For example, the fault diagnosis stage requires fault case data and causal relationship data, and the solution generation stage requires operation specification data and equipment parameter data.

[0100] Based on the phases of the inference process, call timings are set for each knowledge data type to ensure timely access to knowledge support when needed. Call timings are set based on the inference phase, such as calling basic device parameter data at inference startup, calling case reference data during the intermediate inference phase, and calling specification verification data during the result verification phase. Knowledge data types and call timings are integrated to generate a knowledge call sequence plan, which includes the call sequence number, knowledge type, sub-library identifier, and trigger conditions.

[0101] Step S143: Based on the inference computing node type corresponding to the inference computing node allocation result, configure the inference module combination of each operation and maintenance reasoning task. The deep reasoning requirement node corresponds to the inference module combination including a multi-stage reasoning layer, and the basic reasoning requirement node corresponds to the inference module combination including a single-stage reasoning layer.

[0102] The inference module configuration module selects the appropriate inference module combination based on the inference computing node type (deep inference-required or basic inference-required). For deep inference-required nodes, a multi-stage inference layer combination is configured to handle complex inference logic; for basic inference-required nodes, a single-stage inference layer combination is configured to improve processing efficiency.

[0103] During module configuration, the functional responsibilities, input and output data formats, and inter-layer connections of each inference layer are clearly defined. A multi-stage inference layer configuration includes requirements analysis, knowledge association, multi-path inference, and result integration; a single-stage inference layer configuration includes requirements mapping and direct inference. The configuration results are bound to the inference computation node to ensure that the node loads the correct inference module.

[0104] Step S1431: Identify the inference computing node type in the inference computing node allocation result corresponding to each operation and maintenance inference task, and determine whether the inference computing node type is a deep inference requirement node or a basic inference requirement node.

[0105] The node type identification module parses the node attribute information in the inference calculation node allocation results and determines the node type based on the type identification field. Nodes requiring deep inference have the "deep inference" keyword in their identification field, and their hardware configuration parameters include information about high-performance components that support complex model operations. Nodes requiring basic inference have the "basic inference" keyword in their identification field, and their hardware configuration is primarily designed to meet the needs of lightweight model operations.

[0106] Recognition results are stored in association with operational reasoning tasks, serving as a direct basis for configuring the reasoning module. For nodes with questionable recognition results, the system automatically initiates configuration verification, verifying the node's actual reasoning capabilities through test tasks to ensure accurate type judgment.

[0107] Step S1432: If the inference computing node type is a deep reasoning requirement node, a multi-stage reasoning layer combination including a requirement analysis layer, a knowledge association layer, a multi-path reasoning layer, and a result integration layer is configured for the corresponding operation and maintenance reasoning task.

[0108] The multi-stage reasoning layer configuration module loads a multi-stage reasoning layer combination for deep reasoning requirement nodes. The requirement parsing layer is responsible for structuring the operation and maintenance requirement description information, converting unstructured text into structured requirement feature vectors. The knowledge association layer establishes the relationship between structured requirements and knowledge sub-base data and extracts relevant knowledge features. The multi-path reasoning layer generates multiple sets of intermediate reasoning results through different reasoning paths, each using different reasoning logic. The result integration layer integrates multiple sets of intermediate reasoning results, eliminating logical conflicts and forming a unified reasoning conclusion.

[0109] Each inference layer is connected sequentially, with the output of the previous layer serving as the input to the next. Data between layers is transmitted using a standardized feature vector format. During configuration, operating parameters for each layer are set, such as the feature extraction dimension for the demand parsing layer and the number of paths for the multi-path inference layer, to ensure efficient and accurate inference.

[0110] Step S1433: The demand analysis layer is used to structure the operation and maintenance demand description information, the knowledge association layer is used to establish the association relationship between structured requirements and knowledge sub-base data, the multi-path reasoning layer is used to generate multiple groups of intermediate reasoning results through different reasoning paths, and the result integration layer is used to fuse multiple groups of intermediate reasoning results.

[0111] The requirements analysis layer uses natural language processing technology to perform word segmentation, entity recognition, and intent classification on operation and maintenance requirement descriptions, extracting key information and converting it into a structured requirement feature vector. This feature vector encompasses multiple dimensions, including requirement type, equipment characteristics, and problem characteristics. The knowledge association layer uses a feature matching algorithm to compare the requirement feature vector with knowledge features in the knowledge sub-base, establish associations, and select highly relevant knowledge data.

[0112] The multi-path reasoning layer establishes multiple parallel reasoning paths, each employing a different reasoning strategy, such as rule-based reasoning, case-based reasoning, and model-based reasoning. Each path independently generates intermediate reasoning results. The result integration layer uses a voting mechanism and logical verification methods to evaluate and integrate multiple sets of intermediate reasoning results, retaining conclusions with high consistency and correcting any conflicts to form the final reasoning output.

[0113] Step S1434: If the inference computing node type is a basic inference demand node, a single-stage inference layer combination including a demand mapping layer and a direct inference layer is configured for the corresponding operation and maintenance inference task.

[0114] The single-stage inference layer configuration module loads a single-stage inference layer combination for the basic inference requirement node. The requirement mapping layer maps the operation and maintenance requirement description information into standardized inference input and directly associates it with the preset inference template through keyword matching. The direct inference layer executes the inference logic according to the inference template based on the standardized inference input and knowledge sub-base data, generating a single inference result.

[0115] The two-layer structure uses a simple linear connection, with the output of the requirements mapping layer directly fed into the direct inference layer. During the configuration process, the matching accuracy of the inference templates is optimized to ensure that different types of basic requirements are accurately mapped to the corresponding inference templates, improving inference efficiency and accuracy.

[0116] Step S1435: The requirement mapping layer is used to map the operation and maintenance requirement description information into standardized reasoning input, and the direct reasoning layer is used to generate a single reasoning result based on the standardized reasoning input and the knowledge sub-base data.

[0117] The requirements mapping layer uses preset mapping rules to convert keywords and core requirements in the O&M requirements description into a standardized inference input format. This format, with a maximum capacity, aligns with the input requirements of the inference template. Mapping rules include the correspondence between keywords and inference templates, parameter extraction rules, and format conversion logic to ensure the accuracy and completeness of the mapped input data.

[0118] The direct inference layer loads an inference template that matches the standardized input. The template contains fixed inference logic and knowledge reference paths. Following the inference template's guidance, it calls relevant data from the knowledge sub-repository, performs inference calculations according to logical steps, and generates a single inference result. This result includes clear conclusions and supporting evidence, meeting the response requirements for basic operation and maintenance needs.

[0119] Step S1436: Record the configuration result of the inference module combination corresponding to each operation and maintenance inference task, so that the configuration result is compatible with the inference computing node type.

[0120] The configuration result recording module stores the configuration details of the inference module combination for each operation and maintenance inference task in the configuration database. These details include the task identifier, node type, inference layer combination list, operating parameters for each layer, and configuration time. An index is established to associate tasks with configuration results for easy subsequent query and tracing.

[0121] The system regularly verifies the configuration results and compares whether the inference calculation node type matches the configured inference module combination. If a mismatch is found, the reconfiguration process is automatically triggered to ensure that the configuration results are always compatible with the node type and to ensure the stability of the inference process.

[0122] Step S144: embed the knowledge call timing plan into the configured reasoning module combination to form an adaptive reasoning process for each operation and maintenance reasoning task.

[0123] The timing embedding module integrates the knowledge call timing plan with the reasoning module combination, inserting the knowledge call interface into the corresponding reasoning layer of the reasoning module combination according to the planned call timing. After the demand analysis layer is completed, the initial knowledge call interface is inserted to obtain basic device knowledge; a continuous knowledge call interface is set up in the knowledge association layer to dynamically obtain related knowledge; and an on-demand knowledge call interface is set up in the multi-path reasoning layer and the direct reasoning layer to call specific knowledge according to the reasoning progress.

[0124] The embedded adaptive reasoning process includes the complete sequence of reasoning logic and knowledge invocation. Each knowledge invocation interface is associated with a corresponding knowledge sub-repository and data type. After the process configuration is complete, simulation testing is performed to verify the alignment of knowledge invocation timing with the inference progress, ensuring that knowledge is accurately acquired when needed.

[0125] Step S145: Input the operation and maintenance requirement description information and equipment operation scenario identifier of each operation and maintenance service request into the corresponding adaptation reasoning process, perform large model reasoning processing through the deployed reasoning computing node, and call the matching knowledge sub-library data according to the knowledge call sequence plan during the reasoning process.

[0126] The inference execution module converts the key information of the operation and maintenance service request (operation and maintenance requirement description and device operation scenario identifier) ​​into inference input data and formats it according to the input requirements of the adaptive inference process. This input data is sent to the deployed inference computing node via a data transmission protocol. Upon receipt, the node initiates the adaptive inference process.

[0127] The inference computing node executes large-model inference processing according to the process steps. When the trigger conditions set by the knowledge call timing plan are met, it accesses the matching knowledge sub-repository through the association mapping table to obtain the required data. The knowledge data is integrated with the inference input data, driving the inference logic layer by layer until all inference stages are completed. Intermediate data during the inference process is stored in real time in the node's temporary storage area for result verification and traceability.

[0128] Step S1451: Perform structured conversion processing on the operation and maintenance requirement description information of each operation and maintenance service request, and decompose the unstructured operation and maintenance requirement description content into structured requirement data containing requirement type identification, core demand points, and related equipment parameters. At the same time, parse the equipment operation scenario identification associated with the operation and maintenance service request, extract the equipment model information, operating environment parameters, and historical operation and maintenance record index contained in the equipment operation scenario identification, and form a standardized input package.

[0129] The structured conversion module uses natural language understanding technology to process unstructured O&M requirement descriptions. It extracts key information such as device names and fault symptoms through entity recognition and identifies the requirement type (e.g., fault handling, parameter configuration) through intent classification. Core requirements are broken down into quantifiable requirement indicators, and associated device parameters are extracted from the description or supplemented through device identification queries to form structured requirement data.

[0130] The device operation scenario identification parsing module splits the identification string according to encoding rules, extracting device model information (such as air conditioner model and display screen size), operating environment parameters (such as operating mode and ambient temperature range), and historical operation and maintenance record indexes (pointing to the device's historical maintenance records). The module integrates the structured demand data with the parsed scenario information to form a standardized input package containing multiple data fields. This input package uses a unified data format to ensure correct parsing by the inference computing nodes.

[0131] Step S1452: The standardized input package is transmitted to the input interface of the corresponding adaptive reasoning process, and according to the type of inference computing node associated with the adaptive reasoning process, the inference module initialization operation of the inference computing node is triggered. The adaptive reasoning process corresponding to the deep reasoning requirement node triggers the module loading of the multi-stage reasoning layer, and the adaptive reasoning process corresponding to the basic reasoning requirement node triggers the module loading of the single-stage reasoning layer.

[0132] The data transmission module sends standardized input packets through an encrypted channel to the input interface of the adaptive inference process. After verifying the integrity and format of the input packets, the interface sends initialization instructions to the inference computing node. The inference computing node initiates the corresponding module loading process based on its own type (deep or basic inference requirement node).

[0133] The deep reasoning requirement node loads all modules of the multi-stage reasoning layer, including the requirement parsing module, knowledge association module, multi-path reasoning engine, and result integration module. Each module is initialized according to preset parameters. The basic reasoning requirement node loads the requirement mapping module and direct reasoning engine. During module initialization, the connection status with the knowledge sub-repository is verified. After initialization is complete, the node returns a ready signal and waits for the inference start instruction.

[0134] Step S1453: Extract the knowledge call node and the associated knowledge sub-base type corresponding to the current reasoning stage from the knowledge call timing plan, send the knowledge call instruction to the reasoning calculation node, and the reasoning calculation node establishes and matches the knowledge layer according to the knowledge call instruction to generate a single reasoning result based on the standardized reasoning input and knowledge sub-base data. The demand mapping layer converts the unstructured operation and maintenance demand description information into a standardized reasoning input vector in a fixed format through a pre-trained semantic mapping model. The vector dimension matches the input dimension of the direct reasoning layer. The standardized reasoning input vector contains feature data of multiple dimensions such as requirement type features, device parameter features, and scenario features. Each dimensional feature is normalized to ensure that the data distribution meets the input requirements of the direct reasoning layer.

[0135] The direct inference layer loads a pre-trained lightweight inference model, generated based on extensive historical O&M case data. It consists of three basic structures: an input layer, a hidden layer, and an output layer. The input layer receives a standardized inference input vector and, through feature transformation and weight calculation in the hidden layer, maps the feature data to the output space. The output layer uses a softmax activation function to generate a probability distribution of different O&M solutions, selecting the solution with the highest probability as the single inference result. During the inference process, the direct inference layer uses the basic parameter data and rule base in the knowledge sub-repository in real time to verify and correct the inference results, ensuring that they comply with equipment operating specifications.

[0136] Step S1436: Record the configuration results of the inference module combination corresponding to each operation and maintenance inference task, ensuring that the configuration results are compatible with the inference computing node type. The configuration result recording module stores detailed information about the inference module combination in the task configuration database, including the task identifier, inference computing node type, inference module list, parameter settings for each module, and knowledge sub-base associations. Each configuration result is generated with a unique configuration version number, which is bound to the inference task identifier to facilitate subsequent traceability and tuning.

[0137] The database regularly performs statistical analysis on configuration results to identify the matching efficiency of different inference computing node types and inference module combinations. When the inference computing node hardware configuration is updated or the inference model version is upgraded, the configuration result recording module automatically triggers a configuration compatibility check to ensure that the new configuration remains compatible with the node type.

[0138] Step S144: Embed the knowledge call sequence plan into the configured reasoning module combination to form an adaptive reasoning process for each operation and maintenance reasoning task. The sequence embedding module parses each call node in the knowledge call sequence plan and determines its insertion position in the reasoning module combination. For a multi-stage reasoning layer combination, the knowledge call node is embedded after the completion of the requirement parsing layer, during the operation of the knowledge association layer, before the start of the multi-path reasoning layer, and at the initial stage of the result integration layer. For a single-stage reasoning layer combination, the knowledge call node is embedded after the completion of the requirement mapping layer and during the operation of the direct reasoning layer.

[0139] Each knowledge call node establishes a trigger association with the corresponding inference module. When the inference process reaches a specific stage in that module, the knowledge call instruction is automatically activated. The embedded adaptive inference process generates a visual flowchart that illustrates the execution order of each inference module, the triggering timing of the knowledge call node, and the data interaction between modules. The flowchart is stored in the process configuration library and serves as an operational guide for the inference computing node to execute inference tasks.

[0140] Step S145: The operation and maintenance requirement description and equipment operation scenario identifier for each operation and maintenance service request are input into the corresponding adaptive reasoning process. The deployed inference computing nodes perform large-scale model inference processing, invoking the matching knowledge sub-repository data according to the knowledge call sequence plan. The data input module packages the operation and maintenance requirement description and equipment operation scenario identifier into an input data set and transmits it to the start node of the adaptive reasoning process via an interface. The inference computing node then activates each inference module in the order specified in the adaptive reasoning process flow chart, gradually advancing the inference process.

[0141] During the inference process, when the process reaches the knowledge call node, a data request is automatically sent to the knowledge sub-repository to obtain the knowledge data required for the current inference stage. After format conversion, the knowledge data is input into the inference module and integrated with the feature data in the input data set. The inference computing node records the intermediate results, knowledge call records, and module operation status in real time during the inference process, ensuring traceability of the inference process.

[0142] Step S1451: The operation and maintenance requirement description information for each operation and maintenance service request is structured and converted. The unstructured operation and maintenance requirement description is broken down into structured requirement data containing the requirement type identifier, core requirements, and associated equipment parameters. The device operation scenario identifier associated with the operation and maintenance service request is analyzed, and the device model information, operating environment parameters, and historical operation and maintenance record index contained in the device operation scenario identifier are extracted to form a standardized input package. The structured conversion module uses natural language processing technology to perform word segmentation and semantic analysis on the unstructured text, identifying the requirement type identifier (e.g., fault reporting, parameter adjustment, status query).

[0143] The core demand point extraction module uses keyword weighting to filter out core demand content from the operation and maintenance demand description, such as "poor air conditioning cooling effect" and "insufficient display brightness." The associated device parameter extraction module identifies the device parameters mentioned in the description, such as "set temperature 26°C" and "operating frequency 50Hz," to form a structured parameter list. The device operation scenario identification parsing module splits the identification string according to encoding rules, extracting device model information (such as "KFR-35GW / BP3"), operating environment parameters (such as "ambient temperature 32°C" and "humidity 60%"), and historical operation and maintenance record indexes (such as "REC-20230615-002"), and integrates them with the structured demand data into a standardized input package. The input package is encapsulated in JSON format to ensure data integrity and parsability.

[0144] Step S1452: The standardized input package is transmitted to the input interface of the corresponding adaptive reasoning process. Based on the type of inference computing node associated with the adaptive reasoning process, the inference module initialization operation of the inference computing node is triggered. The adaptive reasoning process corresponding to the deep reasoning requirement node triggers the module loading of the multi-stage inference layer, and the adaptive reasoning process corresponding to the basic reasoning requirement node triggers the module loading of the single-stage inference layer. The data transmission module sends the standardized input package to the input interface of the adaptive reasoning process via an encrypted channel. After verifying the integrity and format correctness of the input package, the interface sends an initialization instruction to the inference computing node. The inference computing node initiates the corresponding module loading process based on its own type (deep or basic reasoning requirement node).

[0145] The deep reasoning requirement node loads all modules of the multi-stage reasoning layer, including the requirement parsing module, knowledge association module, multi-path reasoning engine, and result integration module. Each module is initialized according to preset parameters. The basic reasoning requirement node loads the requirement mapping module and direct reasoning engine. During module initialization, the connection status with the knowledge sub-repository is verified. After initialization is complete, the node returns a ready signal and waits for the inference start instruction.

[0146] Step S1453: The knowledge call node and associated knowledge sub-base type corresponding to the current reasoning stage are extracted from the knowledge call sequence plan. The knowledge call instruction is sent to the reasoning computation node. The reasoning computation node establishes a data transmission link with the corresponding knowledge sub-base based on the knowledge call instruction. The sequence extraction module parses the knowledge call sequence plan according to the reasoning stages to determine the type of knowledge sub-base to be called in the current stage (e.g., fault handling knowledge sub-base, parameter standard knowledge sub-base) and the specific location of the call node.

[0147] The knowledge call instruction includes the knowledge sub-repository identifier, the required knowledge type, the required data format, and the transmission encryption method. After receiving the instruction, the inference computing node sends a connection request to the knowledge management system through the knowledge resource scheduling interface. After verifying the request's legitimacy, the knowledge management system allocates an access port for the knowledge sub-repository to the inference computing node and establishes a dedicated data transmission link. This link utilizes a bidirectional encryption mechanism to ensure the security and integrity of the knowledge data during transmission. Once the transmission link is established, a successful connection confirmation signal is returned.

[0148] Step S1454: Through the established data transmission link, the operation and maintenance knowledge data required for the current reasoning phase is extracted from the matching knowledge sub-repository. The reasoning phase corresponding to the deep reasoning requirement node prioritizes the extraction of fault causal correlation data and complex operation and maintenance solution templates from the knowledge sub-repository. The reasoning phase corresponding to the basic reasoning requirement node prioritizes the extraction of basic parameter standard data and general operation instructions from the knowledge sub-repository. The data extraction module performs a search operation within the matching knowledge sub-repository based on the knowledge type specified in the knowledge call instruction.

[0149] During the fault diagnosis phase for nodes requiring deep reasoning, causal relationship data (e.g., "Correlation between abnormal compressor noise and insufficient refrigerant," "Influence curve of dirty condenser blockage and heat dissipation efficiency") and complex O&M solution templates (e.g., "Multi-component collaborative replacement process," "Systematic troubleshooting steps framework") are retrieved and extracted. During the parameter query phase for nodes requiring basic reasoning, standard basic parameter data (e.g., "Summer air conditioning temperature setting range," "Display brightness adjustment parameter thresholds") and general operating instructions (e.g., "Standard filter cleaning procedures," "Power restart operation specifications") are retrieved and extracted. The extracted O&M knowledge data is packaged in a unified format and sent to the inference computing node via a data transmission link.

[0150] Step S1455: Utilizing the inference computation node, the structured demand data in the standardized input package and the extracted operation and maintenance knowledge data are input into the initialized inference module, executing the first-stage inference operation and generating the first-stage inference intermediate results. The inference execution module converts the structured demand data and operation and maintenance knowledge data into a feature vector format recognizable by the inference module. The structured demand data vector includes demand type features, equipment parameter features, and scenario features, while the operation and maintenance knowledge data vector includes knowledge association features, historical case features, and specification constraint features.

[0151] The two feature vectors are input into the initialized inference module. The module performs feature fusion and nonlinear transformations through a multi-layer neural network, calculating the correlation and influence weights between features. For the first phase of deep inference requirement nodes (requirement parsing), the module outputs the feature importance ranking and knowledge matching score for the structured requirement. For the first phase of basic inference requirement nodes (requirement mapping), the module outputs the standardized inference input vector and knowledge association index. The intermediate results of the first phase of inference are stored in the node's temporary buffer, along with a timestamp and module identifier.

[0152] Step S1456: Repeat the above steps of extracting knowledge sub-repository data and performing inference calculations based on the next knowledge call node in the knowledge call sequence plan until the inference phases corresponding to all nodes in the knowledge call sequence plan are completed. The intermediate inference results generated during each inference phase are temporarily stored in the temporary data storage area of ​​the inference calculation node. The sequence advancement module monitors the completion status of the current inference phase. When the first phase of inference calculations is completed, the next knowledge call node information is extracted from the knowledge call sequence plan.

[0153] According to the process of steps S1453 to S1455, the knowledge call and reasoning operation of the next reasoning stage are executed in sequence until all the reasoning stages corresponding to the knowledge call nodes are completed. For example, the deep reasoning requirement node needs to complete the four stages of requirement analysis, knowledge association, multi-path reasoning and result integration in sequence, and each stage performs knowledge extraction and reasoning operation operations. The intermediate results of reasoning in each stage include feature data, operation process parameters and stage conclusions, which are stored in the temporary data storage area in the order of the stages. The area adopts a partitioned storage strategy to ensure that data from different stages are not confused.

[0154] Step S1457: During each inference phase, the inference computation node compares the intermediate inference results of the current phase with the corresponding verification data in the knowledge sub-repository to ensure consistency between the core logic of the intermediate inference results and the verification data. For nodes requiring deep inference, multiple sets of intermediate inference results generated by the multi-path inference layer must also be cross-validated to eliminate logical conflicts. The verification and comparison module extracts verification data relevant to the current inference phase from the knowledge sub-repository, such as standard inference results from historical cases and logical constraints for standardized operations.

[0155] The intermediate inference results are compared with the verification data for features and logical consistency, and the deviation between the two is calculated. If the deviation is within the preset threshold, the verification is considered passed. For the multi-path inference layer of the deep reasoning requirement node, different inference paths generate multiple sets of intermediate inference results. The cross-validation module calculates the logical similarity and conclusion consistency of each set of results, identifies and eliminates conflicting content, and performs weighted fusion of divergent conclusions to form a unified intermediate result. Intermediate results that pass verification are marked as valid and allowed to enter the next inference stage; intermediate results that fail verification trigger the re-inference mechanism.

[0156] Step S1458: After all inference phases are complete, the inference computing node integrates all intermediate inference results and organizes them according to the output format requirements of the adaptive inference process to form an intermediate inference dataset containing a complete inference logic chain. This intermediate inference dataset is used to subsequently generate the operation and maintenance inference results corresponding to the operation and maintenance service request. The result integration module reads all valid intermediate inference results from the temporary data storage area in order of the inference phases, extracting the core conclusions, feature parameters, and knowledge reference records for each phase.

[0157] For nodes requiring deep reasoning, a result integration algorithm performs weighted fusion of multi-path reasoning results, constructing a reasoning logic chain based on logical relevance. This chain encompasses the relationships between problem analysis, cause deduction, solution generation, and effect prediction. For nodes requiring basic reasoning, the results of each stage are arranged chronologically to form a linear reasoning logic chain. The intermediate reasoning dataset is organized in a structured table format, containing fields such as the reasoning stage number, core conclusion description, supporting evidence data, knowledge citation source, and credibility score.

[0158] Step S146: The inference processing generates content containing the operation and maintenance action direction, the operation and maintenance action basis, and the operation and maintenance action related data. This content is determined as the operation and maintenance inference result corresponding to the operation and maintenance service request. The result generation module analyzes the inference logic chain and core conclusions of the intermediate inference data set to extract a clear operation and maintenance action direction, such as "replace the air conditioner compressor," "adjust the display brightness parameters," or "clean the condenser heat sink."

[0159] The O&M basis integrates the O&M knowledge, historical case matching results, and logical reasoning conclusions referenced during the reasoning process to demonstrate the rationality and scientific nature of the operation direction. The O&M operation-related data includes the equipment parameters, tool list, safety precautions, and expected performance indicators required to perform the operation. These three components are combined in a standardized format to generate a structured O&M reasoning result, which is accompanied by a reasoning process ID and a generation timestamp to ensure traceability.

[0160] Step S150: Based on the device operation scenario identifier associated with the operation and maintenance service request, the operation and maintenance reasoning result is converted into an operation and maintenance response instruction that conforms to the device operation scenario operation specifications, and the operation and maintenance response instruction is sent to the corresponding operation and maintenance execution terminal. The instruction conversion module receives the operation and maintenance reasoning result and the device operation scenario identifier, performs format conversion and content adaptation on the reasoning result according to the operation specifications corresponding to the scenario identifier, generates an operation and maintenance response instruction that can be directly executed by the operation and maintenance execution terminal, and sends the instruction to the terminal device via the communication module.

[0161] Step S151: Parse the device operation scenario identifier associated with the operation and maintenance service request to obtain the device operation specification version, device operation permission range, and the type of the device's currently connected operation interface. The identifier parsing module breaks down the device operation scenario identifier string according to preset encoding rules, extracting the specification version field (e.g., "V2.3"), permission range field (e.g., "ADMIN-01"), and interface type field (e.g., "RS485-02").

[0162] The Specification Version field queries the device's operating specification library to obtain the corresponding operating specification document, which includes term definitions, standard operating procedures, and instruction format requirements. The Permission Scope field links to the permission management system to determine the functional scope and parameter adjustment permissions allowed for the current operation and maintenance operation, such as whether firmware upgrades are allowed or whether core parameters can be modified. The Interface Type field is used to query the interface technical manual to clarify communication parameters such as data transmission protocol, baud rate, and verification method.

[0163] Step S152: Extract the operation direction, operation basis, and associated data from the operation reasoning results, and create a structured description of the operation direction according to the format requirements of the equipment operation specification version. The result extraction module separates three core components from the operation reasoning results. The structured description module converts the operation direction into standardized operation terms based on the terminology and expression requirements of the equipment operation specification version.

[0164] For example, "improve air conditioning cooling effect" can be converted to "adjust air conditioning cooling system operating parameters to improve cooling efficiency." Structured descriptions include three elements: the operation object, the operation action, and the operation goal. Each element conforms to the definition standards in the specification version, ensuring consistent understanding of the operation direction across different terminal devices and operators.

[0165] Step S153: Based on the device operation permission range, the operation and maintenance operation-related data is screened for content that meets the permission requirements and any content that exceeds the device operation permission range is deleted. The permission screening module compares the operation and maintenance operation-related data with the device operation permission range item by item, retaining content within the permission range, such as general parameter adjustment data, basic operation tool lists, and general safety tips.

[0166] Any content that exceeds the scope of authorization, such as core firmware upgrade packages, encryption parameter modification instructions, and access permissions for advanced diagnostic tools, will be deleted and a filtering log will be recorded. After filtering, permission tags will be added to the associated data, indicating the permission level and operation restrictions for each content, ensuring that the operation and maintenance execution terminal can only access and execute operations within its scope of authorization.

[0167] Step S154: Determine the instruction format of the operation and maintenance response instruction based on the type of operation interface currently connected to the device. The instruction format includes the field structure and data transmission encoding method corresponding to the interface protocol. The interface adapter module queries the interface protocol specification based on the type of operation interface currently connected to the device and determines the instruction field structure, such as the start identifier field, instruction type field, data length field, operation content field, checksum field, and end identifier field.

[0168] The data transmission encoding method is selected based on the interface characteristics, such as ASCII, hexadecimal, or custom binary encoding. The encoding method must ensure unambiguous command content during transmission and optimize transmission efficiency. After the command format is determined, a format template is generated. The template contains the length, data type, and padding rules for each field.

[0169] Step S155: The structured description of the operation and maintenance operation direction, the basis for the operation and maintenance operation, and the filtered operation and maintenance operation-related data are organized according to the determined instruction format to form an operation and maintenance response instruction that conforms to the equipment operation scenario and operation specifications. The instruction assembly module sequentially fills the structured description of the operation and maintenance operation direction (in the operation content field), the basis for the operation and maintenance operation (in the additional description field), and the filtered operation and maintenance operation-related data (in the parameter data field) in the order of the fields in the format template.

[0170] The format of the filled fields is checked to ensure that the data type and length of each field meet the template requirements. After the verification is passed, the value of the check field is calculated and filled. The entire instruction is encoded using a specific data transmission encoding method to generate the final operation and maintenance response instruction. The instruction is stored in the form of a byte stream for easy transmission through the operation interface.

[0171] Step S156: Verify that the field structure and data transmission encoding method in the operation and maintenance response instruction fully match the type of operation interface currently connected to the device, so that the operation and maintenance response instruction can be correctly parsed by the operation and maintenance execution terminal. The instruction verification module compares the field structure of the operation and maintenance response instruction with the protocol specification corresponding to the operation interface type, checking for consistency in field order, length, and definition.

[0172] At the same time, the encoded instructions are decoded and tested to verify that the decoded content is consistent with the original content, ensuring that no data is lost or distorted during the encoding process. If the verification finds a mismatch or decoding anomaly, the command assembly module returns to readjust the format and encoding method. The operation and maintenance response instructions that pass the verification are marked as valid instructions and are ready to be sent to the operation and maintenance execution terminal.

[0173] Step S157: The verified operation and maintenance response command is sent to the corresponding operation and maintenance execution terminal via the device's currently connected operation interface. The data transmission status is monitored during the transmission process to ensure that the command reaches the terminal device intact. The communication module establishes a data transmission link based on the communication parameters corresponding to the operation interface type (such as baud rate and timeout period) and sends the operation and maintenance response command as a byte stream.

[0174] During transmission, the link status and data transmission progress are monitored in real time. If a transmission interruption or error occurs, a retransmission mechanism is automatically initiated until the command is successfully sent or the maximum number of retransmissions is reached. After receiving the command, the operation and maintenance execution terminal returns a confirmation signal. Upon receiving the confirmation signal, the communication module records a successful command transmission log containing the transmission time, terminal identification, and command ID.

[0175] Figure 2 A large model reasoning optimization system 100 for operation and maintenance technical services provided in an embodiment of the present application is shown, including a processor 1001, a memory 1003 and a program code stored on the memory 1003. The processor 1001 executes the above program code to implement the steps of the large model reasoning optimization method for operation and maintenance technical services.

[0176] Figure 2 The large model reasoning optimization system 100 for operation and maintenance technical services shown includes: a processor 1001 and a memory 1003. The processor 1001 and the memory 1003 are connected, such as through a bus 1002. Optionally, the large model reasoning optimization system 100 for operation and maintenance technical services may also include a transceiver 1004, which may be used for data interaction between the large model reasoning optimization system for operation and maintenance technical services and other large model reasoning optimization systems for operation and maintenance technical services, such as data sending and / or data receiving. It should be noted that the transceiver 1004 is not limited to one in actual scheduling, and the structure of the large model reasoning optimization system 100 for operation and maintenance technical services does not constitute a limitation on the embodiments of the present application.

[0177] The memory 1003 is used to store program codes for executing the embodiments of the present application, and the execution is controlled by the processor 1001. The processor 1001 is used to execute the program codes stored in the memory 1003 to implement the steps shown in the above method embodiments.

[0178] An embodiment of the present application provides a computer-readable storage medium having program code stored thereon. When the program code is executed by a processor, the steps and corresponding contents of the aforementioned method embodiment can be implemented.

[0179] The above is only an optional implementation method for some implementation scenarios of this application. It should be pointed out that for ordinary technicians in this technical field, without departing from the technical concept of the solution of this application, other similar implementation methods based on the technical ideas of this application also fall within the protection scope of the embodiments of this application.

Claims

1. A large model reasoning optimization method for operation and maintenance technical services, characterized in that: The method comprises: Obtain an operation and maintenance service request set under an operation and maintenance technical service scenario, wherein the operation and maintenance service request set includes multiple operation and maintenance service requests to be processed, each operation and maintenance service request carrying operation and maintenance requirement description information and an associated equipment operation scenario identifier; Based on the operation and maintenance requirement description information and the equipment operation scenario identifier of each operation and maintenance service request in the operation and maintenance service request set, dynamically calibrate the priority of the operation and maintenance reasoning task corresponding to each operation and maintenance service request to generate an operation and maintenance reasoning task priority list; According to the operation and maintenance reasoning task priority list and the reasoning link requirements corresponding to each operation and maintenance reasoning task, the computing resources and operation and maintenance knowledge resources required for large model reasoning are deployed to generate a collaborative scheduling plan for reasoning resources and knowledge; According to the reasoning resource and knowledge collaborative scheduling scheme, an adaptive reasoning process is configured for each operation and maintenance reasoning task, and large-scale model reasoning processing is performed through the deployed computing resources to generate an operation and maintenance reasoning result corresponding to the operation and maintenance service request; Combined with the equipment operation scenario identifier associated with the operation and maintenance service request, the operation and maintenance reasoning result is converted into an operation and maintenance response instruction that complies with the equipment operation scenario operation specification, and the operation and maintenance response instruction is sent to the corresponding operation and maintenance execution terminal.

2. The large model reasoning optimization method for operation and maintenance technical services according to claim 1 is characterized in that: The method dynamically calibrates the priority of the operation and maintenance reasoning task corresponding to each operation and maintenance service request based on the operation and maintenance requirement description information and the equipment operation scenario identifier of each operation and maintenance service request in the operation and maintenance service request set, and generates an operation and maintenance reasoning task priority list, including: Extracting the operation and maintenance task type from the operation and maintenance requirement description information of each operation and maintenance service request, wherein the operation and maintenance task type includes equipment fault handling task, equipment parameter configuration task, and equipment operation status monitoring task; Parse the device operation scenario identifier associated with each operation and maintenance service request to determine the system level to which the device belongs, the service link associated with the device, and the current operation stage of the device. Determine the basic priority level based on the association between the operation and maintenance task type and the system level to which the equipment belongs, where the equipment fault handling task corresponding to the basic priority level takes precedence over the equipment parameter configuration task, and the equipment parameter configuration task corresponding to the basic priority level takes precedence over the equipment operation status monitoring task; Based on the service link attributes associated with the device, the basic priority level is adjusted. The priority level of the operation and maintenance reasoning task corresponding to the operation and maintenance service request of the core service link is adjusted upward. The priority level is further adjusted based on the timeliness requirements for operation and maintenance responses in the current operation stage of the equipment. The priority level of the operation and maintenance reasoning tasks corresponding to the operation and maintenance service requests that meet the immediate response requirements is adjusted upward again. Integrate the final priority level corresponding to each operation and maintenance service request, arrange the operation and maintenance reasoning tasks corresponding to all operation and maintenance service requests in order of priority level from high to low, and generate an operation and maintenance reasoning task priority list.

3. The large model reasoning optimization method for operation and maintenance technical services according to claim 1 is characterized in that: The method allocates computing resources and operation and maintenance knowledge resources required for large model reasoning based on the operation and maintenance reasoning task priority list and the reasoning link requirements corresponding to each operation and maintenance reasoning task, and generates a collaborative scheduling plan for reasoning resources and knowledge, including: Analyze the reasoning link requirements corresponding to each operation and maintenance reasoning task, and determine the type of reasoning computing nodes, number of reasoning nodes, and related operation and maintenance knowledge areas required for each reasoning link requirement; Sorting out the available computing resource pool in the operation and maintenance technical service scenario, wherein the available computing resource pool includes multiple inference computing nodes, each of which is marked with the node service capacity and the number of inference tasks currently carried; Organize the operation and maintenance knowledge resource library under the operation and maintenance technical service scenario, and divide the operation and maintenance knowledge resource library into multiple knowledge sub-libraries according to the operation and maintenance knowledge field. Each knowledge sub-library stores operation and maintenance cases, operation and maintenance operation specifications, and equipment characteristic data in the corresponding field. According to the operation and maintenance reasoning task priority list, the core operation and maintenance reasoning tasks are preferentially assigned to the reasoning computing nodes whose service capabilities match their reasoning link requirements, so that the number of reasoning tasks currently carried by the reasoning computing nodes corresponding to the core operation and maintenance reasoning tasks does not exceed the preset proportion of the node's maximum carrying capacity; Match each operation and maintenance reasoning task with a knowledge sub-base corresponding to the operation and maintenance knowledge domain, establish an association mapping between the reasoning computing node and the knowledge sub-base, so that the reasoning computing node can directly call the associated knowledge sub-base when performing reasoning processing; Record the inference computing node allocation results and knowledge sub-base matching results corresponding to each operation and maintenance reasoning task, and integrate them to form a collaborative scheduling plan for inference resources and knowledge.

4. The large model reasoning optimization method for operation and maintenance technical services according to claim 3 is characterized in that: The analysis of the reasoning link requirements corresponding to each operation and maintenance reasoning task determines the type of reasoning computing nodes, number of reasoning nodes, and associated operation and maintenance knowledge areas required for each reasoning link requirement, including: Decompose each operation and maintenance reasoning task into multiple reasoning subtasks. Each reasoning subtask corresponds to a link in the reasoning chain. Determine the processing logic and data interaction requirements for each reasoning subtask. Based on the processing logic of each reasoning subtask, determine the type of reasoning computing node required for the reasoning subtask. The reasoning subtask involving deep fault causal analysis corresponds to the deep reasoning requirement node type, and the reasoning subtask involving basic parameter query corresponds to the basic reasoning requirement node type. Count the number of inference subtasks contained in each operation and maintenance inference task and the parallel processing possibility of each inference subtask, and determine the number of inference nodes required for the operation and maintenance inference task. The more inference subtasks that can be processed in parallel, the more inference nodes are required. Extract the operation and maintenance knowledge content that needs to be referenced during the processing of each reasoning subtask, and determine the associated operation and maintenance knowledge domain based on the category of the operation and maintenance knowledge content. Among them, the fault diagnosis reasoning subtask is associated with the fault processing knowledge domain, and the parameter configuration reasoning subtask is associated with the parameter standard knowledge domain. Integrate the inference computing node type, number of inference nodes, and related operation and maintenance knowledge fields corresponding to each operation and maintenance reasoning task to form a description of the inference link requirements for each operation and maintenance reasoning task.

5. The large model reasoning optimization method for operation and maintenance technical services according to claim 3 is characterized in that: The priority list of operation and maintenance reasoning tasks is used to prioritize the allocation of inference computing nodes whose service capabilities match the inference link requirements of the core operation and maintenance reasoning tasks, so that the number of inference tasks currently carried by the inference computing nodes corresponding to the core operation and maintenance reasoning tasks does not exceed a preset ratio of the node's maximum carrying capacity, including: Extracting core operation and maintenance reasoning tasks from the operation and maintenance reasoning task priority list, and processing each core operation and maintenance reasoning task in order of priority from the highest priority to the lowest priority; For the core operation and maintenance reasoning task currently being processed, the inference computing nodes whose service capabilities match the inference link requirements of the operation and maintenance reasoning task are screened from the available computing resource pool to form a set of candidate inference computing nodes; Querying the number of inference tasks currently carried by each candidate inference computing node in the candidate inference computing node set, and calculating the ratio of the number of inference tasks currently carried by each candidate inference computing node to the maximum carrying capacity of the node; Select candidate inference computing nodes whose ratio of the number of currently carried inference tasks to the maximum carrying capacity does not exceed the preset ratio threshold as target inference computing nodes; Assign the currently processed core operation and maintenance reasoning task to the target reasoning computing node and update the number of reasoning tasks currently carried by the target reasoning computing node; Repeat the above steps to complete the allocation of inference computing nodes for all core operation and maintenance inference tasks, and then follow the same process to allocate inference computing nodes for common operation and maintenance inference tasks.

6. The large model reasoning optimization method for operation and maintenance technical services according to claim 1 is characterized in that: The method configures an adaptive reasoning process for each operation and maintenance reasoning task based on the reasoning resource and knowledge collaborative scheduling scheme, executes large model reasoning processing through the deployed computing resources, and generates an operation and maintenance reasoning result corresponding to the operation and maintenance service request, including: Extract the inference computing node allocation result and knowledge sub-base matching result corresponding to each operation and maintenance inference task from the inference resource and knowledge collaborative scheduling scheme; According to the matching results of the knowledge sub-bases, the type of operation and maintenance knowledge data and the calling timing to be called during the reasoning process of each operation and maintenance reasoning task are determined, and a knowledge calling timing plan is generated; Based on the inference computing node type corresponding to the inference computing node allocation result, configure the inference module combination of each operation and maintenance inference task, the deep inference requirement node is correspondingly configured with an inference module combination including a multi-stage inference layer, and the basic inference requirement node is correspondingly configured with an inference module combination including a single-stage inference layer; Embed the knowledge call timing plan into the configured reasoning module combination to form an adaptive reasoning process for each operation and maintenance reasoning task; The operation and maintenance requirement description information and equipment operation scenario identifier of each operation and maintenance service request are input into the corresponding adaptive reasoning process. The large model reasoning processing is performed through the deployed reasoning computing nodes. During the reasoning process, the matching knowledge sub-base data is called according to the knowledge call sequence plan; The content including the operation and maintenance operation direction, the operation and maintenance operation basis and the operation and maintenance operation related data is generated through reasoning processing, and the content is determined as the operation and maintenance reasoning result corresponding to the operation and maintenance service request.

7. The large model reasoning optimization method for operation and maintenance technical services according to claim 6 is characterized in that: The configuring of the inference module combination of each operation and maintenance inference task based on the inference computing node type corresponding to the inference computing node allocation result includes: Identify the inference computing node type in the inference computing node allocation result corresponding to each operation and maintenance inference task, and determine whether the inference computing node type is a deep inference requirement node or a basic inference requirement node; If the inference computing node type is a deep inference requirement node, a multi-stage inference layer combination including a requirement analysis layer, a knowledge association layer, a multi-path inference layer, and a result integration layer is configured for the corresponding operation and maintenance inference task; The demand analysis layer is used to structure the operation and maintenance demand description information, the knowledge association layer is used to establish the association relationship between structured demand and knowledge sub-base data, the multi-path reasoning layer is used to generate multiple sets of intermediate reasoning results through different reasoning paths, and the result integration layer is used to fuse multiple sets of intermediate reasoning results; If the inference computing node type is a basic inference demand node, a single-stage inference layer combination including a demand mapping layer and a direct inference layer is configured for the corresponding operation and maintenance inference task; The requirement mapping layer is used to map the operation and maintenance requirement description information into standardized reasoning input, and the direct reasoning layer is used to generate a single reasoning result based on the standardized reasoning input and knowledge sub-base data; Record the inference module combination configuration results corresponding to each operation and maintenance inference task to make the configuration results compatible with the inference computing node type.

8. The large model reasoning optimization method for operation and maintenance technical services according to claim 6 is characterized in that: The operation and maintenance requirement description information and equipment operation scenario identifier of each operation and maintenance service request are input into the corresponding adaptive reasoning process, and the large model reasoning processing is performed through the deployed reasoning computing node. During the reasoning process, the matching knowledge sub-base data is called according to the knowledge call sequence plan, including: Perform structured conversion on the operation and maintenance requirement description information of each operation and maintenance service request, breaking down the unstructured operation and maintenance requirement description into structured requirement data containing the requirement type identifier, core demand points, and associated equipment parameters. At the same time, parse the equipment operation scenario identifier associated with the operation and maintenance service request, extract the equipment model information, operating environment parameters, and historical operation and maintenance record index contained in the equipment operation scenario identifier, and form a standardized input package; The standardized input package is transmitted to the input interface of the corresponding adaptive reasoning process. According to the type of inference computing node associated with the adaptive reasoning process, the inference module initialization operation of the inference computing node is triggered. The adaptive reasoning process corresponding to the deep reasoning requirement node triggers the module loading of the multi-stage reasoning layer, and the adaptive reasoning process corresponding to the basic reasoning requirement node triggers the module loading of the single-stage reasoning layer; Extract the knowledge call node and the associated knowledge sub-base type corresponding to the current reasoning stage from the knowledge call timing plan, send the knowledge call instruction to the reasoning computing node, and the reasoning computing node establishes a data transmission link with the matching knowledge sub-base according to the knowledge call instruction; Through the established data transmission link, the operation and maintenance knowledge data required for the current reasoning stage is extracted from the matching knowledge sub-base. The reasoning stage corresponding to the deep reasoning requirement node prioritizes the extraction of fault causal correlation data and complex operation and maintenance solution templates in the knowledge sub-base. The reasoning stage corresponding to the basic reasoning requirement node prioritizes the extraction of basic parameter standard data and general operation instructions in the knowledge sub-base. Using the inference computing node, the structured demand data in the standardized input package and the extracted operation and maintenance knowledge data are input into the initialized inference module, and the first stage inference operation is performed to generate the first stage inference intermediate result; According to the next knowledge call node in the knowledge call time sequence plan, the above steps of knowledge sub-base data extraction and reasoning operation are repeated until the reasoning stages corresponding to all nodes in the knowledge call time sequence plan are completed. The intermediate reasoning results generated in each reasoning stage are temporarily stored in the temporary data storage area of ​​the reasoning calculation node. During the execution of each inference phase, the inference computing node compares the intermediate inference results of the current phase with the corresponding verification data in the knowledge sub-base to ensure that the core logic of the intermediate inference results and the verification data are consistent. If it is a deep inference requirement node, it is also necessary to cross-validate the multiple sets of intermediate inference results generated by the multi-path inference layer to eliminate logical conflicts. After completing all reasoning stages, the reasoning computing node integrates all intermediate reasoning results, organizes the data according to the output format requirements of the adapted reasoning process, and forms an intermediate reasoning data set containing a complete reasoning logic chain. The intermediate reasoning data set is used to subsequently generate operation and maintenance reasoning results corresponding to the operation and maintenance service request.

9. The large model reasoning optimization method for operation and maintenance technical services according to claim 1 is characterized in that: The step of converting the operation and maintenance reasoning result into an operation and maintenance response instruction that complies with the operation specification of the device operation scenario in combination with the device operation scenario identifier associated with the operation and maintenance service request includes: Parse the device operation scenario identifier associated with the operation and maintenance service request, and obtain the device operation specification version, device operation permission range, and operation interface type currently connected to the device corresponding to the device operation scenario identifier; Extracting the operation and maintenance operation direction, operation and maintenance operation basis, and operation and maintenance operation related data from the operation and maintenance reasoning result, and providing a structured description of the operation and maintenance operation direction according to the format requirements corresponding to the equipment operation specification version; According to the scope of equipment operation authority, filter the operation and maintenance operation related data to content that meets the authority requirements, and delete the related data that exceeds the scope of equipment operation authority; Determine the instruction format of the operation and maintenance response instruction based on the type of operation interface currently connected to the device, the instruction format including the field structure and data transmission encoding method corresponding to the interface protocol; The structured description of the operation and maintenance operation direction, operation and maintenance operation basis, and the filtered operation and maintenance operation related data are organized according to the determined instruction format to form an operation and maintenance response instruction that meets the equipment operation scenario operation specifications; Confirm whether the field structure and data transmission encoding method in the operation and maintenance response instruction completely match the operation interface type currently connected to the device, so that the operation and maintenance response instruction can be correctly parsed by the operation and maintenance execution terminal.

10. A large model reasoning optimization system for operation and maintenance technical services, characterized by: It includes a processor and a computer-readable storage medium, wherein the computer-readable storage medium stores machine-executable instructions, and when the machine-executable instructions are executed by the processor, the large-model reasoning optimization method for operation and maintenance technical services described in any one of claims 1 to 9 is implemented.

Images