A method for intelligent identification and correction of a model and manufacturer of a nanotube device and related equipment

Abstract

The application provides a method for intelligently identifying and correcting and completing device model and manufacturer in a management list and related equipment, and belongs to the technical field of artificial intelligence network equipment intelligent management. The method comprises the following steps: storing device description information and device side information as a device record to be inferred; combining the device description information, the device side information in the device record, and each identification rule and priority processing rule in a knowledge module to form a structured prompt word; outputting an identification result; backfilling the manufacturer name and the model name in the identification result to a manufacturer field and a model field of the management list respectively, and storing the inference basis in the identification result in the device record; obtaining collection success / failure information obtained by performing a collection task according to the corrected manufacturer field and the model field, and feeding back the collection success / failure information to the knowledge module for updating. The application can realize intelligent identification, automatic correction and completion, and closed-loop self-optimization of the device model and manufacturer information in the management list.

Description

Technical Field

[0001] This application relates to the field of intelligent management technology for artificial intelligence network devices, and in particular to a method and related equipment for intelligent identification, correction and completion of device model and manufacturer in a management list. Background Technology

[0002] In related technologies, maintenance personnel check the list item by item before or after data collection is interrupted. This method is costly and extremely inefficient, and cannot handle scenarios involving the management of large-scale devices.

[0003] In summary, the technical problems existing in the relevant technologies need to be improved. Summary of the Invention

[0004] The main objective of this application is to propose a method and related equipment for intelligent identification and correction of equipment model and manufacturer information in a management application form, which can realize intelligent identification, automatic correction and completion, and closed-loop self-optimization of equipment model and manufacturer information in the management application form.

[0005] To achieve the above objectives, one aspect of this application proposes a method for intelligent identification and correction of equipment model and manufacturer in a registration form, the method comprising the following steps: Obtain device description information from the management list, detect the target device to obtain device-side information, and associate the device description information with the device-side information to store as a device record to be inferred; Based on the device records, load the device identification knowledge module; The device description information, device-side information, and various identification rules and priority processing rules in the knowledge module are combined into structured prompt words; The structured prompts are sent to the large model, which then integrates the device description information and the device-side information under constraints to output a recognition result. Based on the confidence level in the identification results, the manufacturer name and model name in the identification results are respectively filled into the manufacturer field and model field of the management form, and the reasoning basis in the identification results is associated and stored in the device record; Obtain the success or failure information of the data collection task based on the corrected manufacturer and model fields, and feed the success or failure information back to the knowledge module for updating.

[0006] In some embodiments, obtaining device description information from the management list, detecting the target device to obtain device-side information, and associating the device description information with the device-side information and storing it as a device record to be inferred includes: Parse the electronic form file submitted by the user to obtain a list of device records. Each device record contains the IP address of the target device, the name of the manufacturer who submitted the form, and the name of the model that was submitted. Use the IP address, the name of the manufacturer who submitted the form, and the name of the model that was submitted as the device description information. Based on the IP address in the device record list, concurrently execute the probe task for the target device; the probe task includes an SNMP probe subtask and a CLI probe subtask; the SNMP probe subtask is to obtain the system OID or private OID of the target device through the SNMP protocol; the CLI probe subtask is to log in to the target device through the Telnet or SSH protocol, execute a preset command list, and capture the returned CLI echo text; When the SNMP probe subtask or the CLI probe subtask successfully obtains device-side information, the obtained OID or CLI echo text is used as the device-side information; when both the SNMP probe subtask and the CLI probe subtask fail, the device-side information is marked as missing. The device description information is associated with the obtained OID or CLI echo text and stored as a device record to be inferred.

[0007] In some embodiments, loading the device-identified knowledge module based on the device record includes: Obtain the IP address from the device record, and match and load the corresponding device identification knowledge module from the device identification knowledge base according to the network segment or enterprise to which the IP address belongs; If the knowledge module cannot be matched based on the IP address, then the preset global default knowledge module is loaded; the knowledge module is stored in JSON format and includes an OID recognition rule set, a CLI recognition rule set, and an experience rule set. The OID identification rule set includes several OID mapping records. Each OID mapping record contains an OID prefix field, a manufacturer field, an equipment series field, or a specific model field. The OID mapping record is used to match the corresponding manufacturer name and model name based on the obtained OID. The CLI identification rule set includes several CLI feature matching records. Each CLI feature matching record contains a feature string field, a manufacturer field, or a model field. The CLI feature matching records are used to match the corresponding manufacturer name and model name based on whether the CLI echo text contains the feature string. The set of empirical rules includes several conflict handling rule records. Each conflict handling rule record contains a conflict condition field and a priority strategy field. The conflict handling rule records are used to indicate which source of information should be prioritized for identification when the device description information is inconsistent with the device-side information.

[0008] In some embodiments, combining the device description information, the device-side information, and the identification rules and priority processing rules in the knowledge module into structured prompt words includes: According to the preset prompt word template, the device description information, the device side information, and the various identification rules and priority processing rules in the knowledge module are combined into structured prompt words; The preset prompt word template includes a task description field, an input data field, an available knowledge field, a constraint field, and an output format requirement field; The task description field is used to explain the target task, which identifies the device model and manufacturer, to the large model. The input data field is used to fill in the device description information and the device-side information; The available knowledge fields are used to fill in the OID recognition rule set, CLI recognition rule set, and experience rule set; The constraint field is used to limit the large model to reason according to the rules provided in the available knowledge field; The output format requirement field is used to specify that the large model outputs the recognition results in the specified JSON format.

[0009] In some embodiments, sending the structured prompt words to a large model, so that the large model, under constraints, integrates the device description information and the device-side information to output a recognition result, includes: The structured prompts are sent to the large model via an API call interface or a local model loading interface; after receiving the structured prompts, the large model parses the device description information and device-side information in the input data field under the constraints of the condition field; the large model selects the corresponding recognition path for inference based on the data type of the device-side information: When the device-side information is an OID, the large model compares the OID with the OID identification rule set in the available knowledge fields, matches the corresponding manufacturer name and model name according to the longest OID prefix matching principle, and uses the matching result as the first identification conclusion. When the device-side information is the CLI echo text, the large model traverses each CLI feature matching record in the CLI recognition rule set, detects whether the CLI echo text contains the feature strings in each record, and takes the manufacturer name and model name corresponding to the matched feature record as the second recognition conclusion. When the device-side information contains both the OID and the CLI echo text, the large model performs reasoning according to the OID recognition path and the CLI recognition path respectively to obtain the first recognition conclusion and the second recognition conclusion. When the first identification conclusion is inconsistent with the second identification conclusion, the big model selects the final identification conclusion from the first identification conclusion and the second identification conclusion according to the priority adoption strategy indicated in the preset conflict priority rules in the knowledge module. When the device-side information is missing, the large model matches the manufacturer name and model name filled in the device description information according to the identification rules in the available knowledge fields, and uses the matching result as the final identification conclusion. After obtaining the final identification conclusion, the large model generates confidence information based on the reliability of the data source on which the final identification conclusion is based and the degree of consistency between the device description information and the device-side information. The large model generates reasoning information based on the recognition path and matched rules used in the recognition process; the reasoning information includes the data source and the rules matched in this recognition. The large model outputs the recognition results in JSON format according to the output format requirements; the recognition results include the manufacturer name field, model name field, confidence level field, and reasoning basis field.

[0010] In some embodiments, the step of backfilling the manufacturer name and model name from the identification result into the manufacturer field and model field of the management form, respectively, based on the confidence level in the identification result, and storing the reasoning basis from the identification result in the device record, includes: Extract the manufacturer name field, model name field, confidence level field, and reasoning basis field from the identification results; Read the confidence level from the confidence field; the confidence level includes high confidence, medium confidence, and low confidence. When the confidence level is high confidence, the manufacturer name in the manufacturer name field will overwrite the manufacturer name in the corresponding device record in the management form, and the model name in the model name field will overwrite the model name in the corresponding device record in the management form. When the confidence level is medium or low, retain the manufacturer name and model name of the corresponding device in the management form, and add a "to be reviewed" mark to the device record. The reasoning basis information in the reasoning basis field is associated and stored in the device record. The reasoning basis information is associated with the IP address, the name of the manufacturer to be filled in, the name of the model to be filled in, the OID or the CLI echo text and stored in the device record.

[0011] In some embodiments, obtaining the success or failure information of the data collection task based on the corrected manufacturer and model fields, and feeding the success or failure information back to the knowledge module for updating, includes: After the manufacturer and model fields in the management form are corrected, the corresponding acquisition adapter is matched according to the corrected manufacturer name and model name, and the acquisition task for the target device is executed to obtain acquisition success or failure information; the acquisition success or failure information includes acquisition success status or acquisition failure status and failure reason. Obtain the review results submitted by the user; the review results include confirmation information or correction information for the identification results; the correction information includes the corrected manufacturer name and model name, as well as supplementary rule descriptions; When the review result includes the correction information, the corrected manufacturer name and model name are used as the correct labels, associated with the equipment description information and equipment-side information in the equipment record, and formatted as a new mapping record; When the data acquisition success or failure information includes the data acquisition failure status, the data acquisition failure status is associated with the device record and marked as a negative sample; Format the new mapping record or the negative sample into a knowledge update request; Based on the knowledge update request, the following update operation is performed on the knowledge module: The new mapping record is added to the OID recognition rule set or CLI recognition rule set as a new OID mapping record or CLI feature matching record; Based on the corrected manufacturer name and model name, correct the corresponding manufacturer field or model field in the existing OID mapping record or CLI feature matching record in the knowledge module; Based on the data acquisition failure status and the failure reason, adjust the priority adoption strategy or confidence judgment threshold of the conflict priority rule in the knowledge module; Based on the supplementary rule description, generate new conflict resolution rule records and add them to the empirical rule set; Save the updated knowledge module to the device identification knowledge base.

[0012] To achieve the above objectives, another aspect of this application proposes an intelligent identification and correction system for equipment model and manufacturer information in a management application, used to implement the method described above. The system includes: The information acquisition module is used to acquire device description information from the management form, detect the target device to obtain device-side information, and associate the device description information with the device-side information to store as a device record to be inferred. The knowledge base interface module is used to load the knowledge module identified by the device based on the device records; The prompt word construction module is used to combine the device description information, the device-side information, and the various identification rules and priority processing rules in the knowledge module into structured prompt words; The large model inference module is used to send the structured prompt words to the large model, so that the large model can integrate the device description information and the device-side information under the constraints and output the recognition result; The list correction module is used to fill the manufacturer name and model name in the identification result back into the manufacturer field and model field of the management form respectively, based on the confidence level in the identification result, and to associate and store the reasoning basis in the identification result into the device record; The closed-loop feedback module is used to obtain the success or failure information of the data collection task obtained based on the corrected manufacturer and model fields, and to feed the success or failure information back to the knowledge module for updating.

[0013] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0014] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods described above.

[0015] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer program product, including a computer program that, when executed by a processor, implements the aforementioned method.

[0016] The embodiments of this application include at least the following beneficial effects: This application provides a method, system, electronic device, storage medium, and program product for intelligent identification and correction of equipment models and manufacturers in management forms. The solution includes: storing equipment description information and equipment-side information together as a device record to be reasoned; combining the equipment description information, equipment-side information, and various identification rules and priority processing rules in the knowledge module into structured prompt words; outputting the identification result; backfilling the manufacturer name and model name from the identification result into the manufacturer field and model field of the management form, respectively, and storing the reasoning basis from the identification result together in the device record; obtaining the success or failure information of the data collection task obtained based on the corrected manufacturer field and model field, and feeding the success or failure information back to the knowledge module for updating. This application can achieve intelligent identification, automatic correction and completion, and closed-loop self-optimization of equipment model and manufacturer information in management forms. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating a method for intelligent identification and correction of device model and manufacturer in a management form, as provided in an embodiment of this application. Figure 2 This is a flowchart of step S101 provided in the embodiments of this application; Figure 3 This is a flowchart of step S102 provided in the embodiments of this application; Figure 4 This is a flowchart of step S103 provided in the embodiments of this application; Figure 5 This is a flowchart of step S104 provided in the embodiments of this application; Figure 6 This is a flowchart of step S105 provided in the embodiments of this application; Figure 7 This is a flowchart of step S106 provided in the embodiments of this application; Figure 8 This is a schematic diagram of the intelligent identification and correction system for device models and manufacturers in the management form provided in this application embodiment; Figure 9 This is a schematic diagram of the system structure provided in the embodiments of this application; Figure 10 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0019] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0020] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0021] 1. Large Model: Refers to a deep learning model with a large number of parameters and a complex structure, trained on large-scale data, possessing powerful natural language understanding, generation, reasoning, and context learning capabilities. In this solution, the large model serves as the core reasoning engine, used to understand device descriptions, analyze CLI responses, and make comprehensive judgments based on knowledge modules.

[0022] 2. Equipment Identification Knowledge Module: One of the core technical components of this solution. It is a standardized, reusable module that encapsulates the identification rules, historical experience knowledge, and invocation methods required to complete the task of identifying equipment models and manufacturers. Its contents include: 1) OID-based identification rules: For example, “Enterprise private OID .1.3.6.1.4.1.2011.5.25.188.1.4 Manufacturer Huawei, query device model code”.

[0023] 2) Identification knowledge based on CLI echo and historical interfacing experience: For example, "If the CLI echo contains sysname and the banner information contains HUAWEI, the manufacturer may be HUAWEI; if the echo contains the display version output mode and contains HUAWEI CE12808S, the model may be CE12808S."

[0024] 3. OID: Object Identifier, used to uniquely identify a managed object in SNMP (Simple Network Management Protocol) management. A device's private OID or system-level OID typically uniquely identifies its manufacturer and model.

[0025] 4. CLI Echo: Command-line interface echo. This refers to the text information returned after executing specific commands (such as display version, show version) after logging into a network device via protocols such as Telnet or SSH. It contains key information such as the device's software version, hardware model, and runtime.

[0026] 5. Management Form / Equipment List: This is an electronic form submitted to the management platform by the superior unit (such as the provincial company) during the telecommunications network equipment resource data collection and management process. This list includes the IP address, equipment name, account passwords for different protocols, and information such as the equipment model and manufacturer. This solution processes the model and manufacturer information from this list.

[0027] 6. Device Identification Knowledge Base: This is an operations and maintenance domain knowledge management platform that encapsulates scattered OID rules, CLI feature rules, and historical operation and maintenance experience into standardized, structured knowledge modules. These modules can be dynamically loaded and continuously updated during large-scale model inference. It can be implemented by extending CMDB, AIOps platforms, or by building a self-built rule base + vector database.

[0028] This application takes into account that, in the scenario of telecom network cloud network operation, operators need to incorporate a massive number of network devices (such as routers, switches, firewalls, etc.) from different manufacturers into a unified resource data collection and management platform for management. A typical management process is as follows: lower-level units such as provincial companies submit a list of devices to be managed to the platform, the platform matches the pre-set collection adaptation rules based on the device models and other information in the list, and then issues tasks to collect resource data.

[0029] However, a long-standing pain point in actual production is the discrepancy between the equipment models and manufacturers listed by provincial companies and the actual equipment on-site. This manifests in several ways: the reported model number does not match the actual model (e.g., A is entered but B is actually entered), fields are missing, there are typos (e.g., Cisco is mistakenly entered as Cisco0), and the naming is not standardized (e.g., HW-CE12800 is different from Huawei CE12800). Because there is no effective automatic verification mechanism before the list is submitted, the platform matches the adaptation rules based on incorrect information, directly leading to failed data collection tasks, abnormal equipment data collection, and missing core resource data. Subsequently, maintenance personnel have to invest significant effort in manual troubleshooting, logging into the equipment to verify information, correcting configurations, and re-collecting data, severely impacting the success rate of data collection and overall maintenance efficiency.

[0030] To address this issue, relevant technologies mainly rely on the following methods, but all of them have significant shortcomings: Manual verification: Before or after data collection is interrupted, maintenance personnel check the list item by item. This method is costly and extremely inefficient, and cannot handle scenarios involving the large-scale integration of devices into the system.

[0031] Single-rule matching: Some schemes identify devices by detecting their OID or CLI signatures. However, their identification rules are often scattered scripts or hard-coded, making them difficult to maintain and reuse. Identification will fail when encountering new devices or description variations not found in the rule base.

[0032] Traditional text matching relies solely on fuzzy matching of text descriptions in the list, but it cannot handle complex semantic differences, typos, and missing information, and it cannot incorporate real information from the device side (such as OID) for cross-validation.

[0033] In view of this, this application provides a method and related equipment for intelligent identification, correction and completion of equipment model and manufacturer in the management form. This solution can automatically and intelligently identify, correct and complete the equipment model and manufacturer at the management entry point, thereby reducing collection anomalies caused by information errors from the source and reducing reliance on human experience.

[0034] Figure 1 This is an optional flowchart of a method for intelligent identification and correction of equipment model and manufacturer in a management form provided in an embodiment of this application. Figure 1 The method may include, but is not limited to, steps S101 to S106.

[0035] Step S101: Obtain device description information from the management form, detect the target device to obtain device-side information, and associate the device description information with the device-side information to store as a device record to be inferred; Step S102: Load the device identification knowledge module based on the device records; Step S103: Combine the device description information, device-side information, and various identification rules and priority processing rules in the knowledge module from the device record into structured prompt words; Step S104: The structured prompts are sent to the large model so that the large model can integrate the device description information and the device-side information under the constraints and output the recognition result. Step S105: Based on the confidence level in the identification results, fill the manufacturer name and model name in the identification results back into the manufacturer field and model field of the management form, respectively, and store the reasoning basis in the identification results in the device record. Step S106: Obtain the success or failure information of the data collection task obtained based on the corrected manufacturer and model fields, and feed the success or failure information back to the knowledge module for updating.

[0036] Steps S101 to S106, as illustrated in this embodiment, provide a multi-source cross-validation data foundation for subsequent inference by integrating the information filled in the inventory list with the actual information from the device side (OID / CLI). By encapsulating scattered expert experience into standardized, reusable knowledge modules, the inflexibility of traditional hard-coded rules is addressed. By combining multi-source information with knowledge modules into structured prompts containing constraints, the large model ensures controllable inference within the professional domain. By leveraging the language understanding capabilities of the large model for comprehensive judgment, interpretable and confident recognition results are output, replacing manual verification and single-rule matching. Automatic correction of the inventory list or manual review based on confidence levels achieves source error correction and risk control. Feedback of collection success / failure and manual review results to the knowledge module drives continuous knowledge iteration, enabling system self-evolution. Ultimately, the system automatically identifies, corrects, and completes device model and manufacturer information at the management entry point, ensuring that subsequent collection tasks are executed based on accurate information, improving the first-time success rate of management and reducing maintenance costs.

[0037] refer to Figure 2 In some embodiments, step S101 may include, but is not limited to, steps S111 to S114: Step S111: Parse the electronic form file submitted by the user to obtain a list of device records. Each device record contains the IP address of the target device, the name of the manufacturer, and the name of the model. Use the IP address, the name of the manufacturer, and the name of the model as device description information. Step S112: Based on the IP address in the device record list, concurrently execute the probe task for the target device; the probe task includes an SNMP probe subtask and a CLI probe subtask; the SNMP probe subtask is to obtain the system OID or private OID of the target device through the SNMP protocol; the CLI probe subtask is to log in to the target device through the Telnet or SSH protocol, execute a preset command list, and capture the returned CLI echo text; Step S113: When the SNMP probe subtask or CLI probe subtask successfully obtains device-side information, the obtained OID or CLI echo text is used as device-side information; when both the SNMP probe subtask and CLI probe subtask fail, the device-side information is marked as missing. Step S114: Associate the device description information with the obtained OID or CLI echo text and store it as a device record to be inferred.

[0038] In steps S111 to S114 of some embodiments, by obtaining device description information from the management form and actively probing the target device to obtain SNMP OID or CLI echo as device-side information, and storing the two together as a device record to be inferred, the fusion of list-filled information and real device-side information is achieved, transforming the traditional post-event remediation into pre-event cross-validation from a process perspective. This application embodiment further defines the implementation method of parsing the electronic form file to obtain the device record list and concurrently executing SNMP probing subtasks and CLI probing subtasks based on IP addresses. By concurrently executing two different protocol probing tasks in the device probing module, device-side information can be obtained if either subtask succeeds; if both fail, it is marked as missing and handled compatibly, ensuring the robustness of the solution in real-world complex network environments. The OID or CLI echo actively obtained from the device side in this application embodiment is an inherent attribute of the device itself, possessing unforgeable authenticity, and can serve as an objective basis for subsequent verification of the accuracy of the list-filled information, avoiding the unreliability issues caused by relying solely on manually filled information, and providing a data foundation for multi-source cross-validation for subsequent inference steps.

[0039] refer to Figure 3 In some embodiments, step S102 may include, but is not limited to, steps S201 to S202: Step S201: Obtain the IP address in the device record, and match and load the corresponding device identification knowledge module from the device identification knowledge base according to the network segment or enterprise to which the IP address belongs; Step S202: If a knowledge module cannot be matched based on the IP address, a preset global default knowledge module is loaded; the knowledge module is stored in JSON format, including OID recognition rule set, CLI recognition rule set and experience rule set; The OID identification rule set includes several OID mapping records. Each OID mapping record contains an OID prefix field, a manufacturer field, an equipment series field, or a specific model field. The OID mapping record is used to match the corresponding manufacturer name and model name based on the obtained OID. The CLI identification rule set includes several CLI feature matching records. Each CLI feature matching record contains a feature string field, a manufacturer field, or a model field. The CLI feature matching record is used to match the corresponding manufacturer name and model name based on whether the CLI echo text contains the feature string. The set of empirical rules includes several conflict handling rule records. Each conflict handling rule record contains a conflict condition field and a priority strategy field. The conflict handling rule records are used to indicate which source of information should be prioritized for identification when there is a discrepancy between the device description information and the device-side information.

[0040] In steps S201 to S202 of some embodiments, a knowledge module for device identification is loaded based on the device record. The identification rules, historical experience knowledge, and calling methods required to complete the task of identifying the device model and manufacturer are encapsulated into a standardized and reusable module. This application further defines the implementation method of loading the corresponding knowledge module based on the network segment or enterprise source of the IP address, and loading the global default knowledge module when no match can be found. The knowledge module is defined in JSON format as a structured storage format containing an OID identification rule set (including OID prefix field, manufacturer field, device series field, or specific model field), a CLI identification rule set (including feature string field, manufacturer field, or model field), and an experience rule set (including conflict condition field and priority adoption strategy field). This application's embodiments abstract the identification rules, which were originally scattered in collection scripts, configuration files, or personal documents of maintenance personnel, into standardized knowledge modules. This decouples the identification logic from the collection execution logic, supports version management, dynamic loading, and continuous updates, and greatly reduces knowledge maintenance costs. When it is necessary to support new devices or correct old rules, only the knowledge module needs to be updated without modifying the core code. At the same time, the same knowledge module can be quickly reused in different provincial companies and different projects, realizing the accumulation and sedimentation of enterprise-level knowledge assets.

[0041] refer to Figure 4 In some embodiments, step S103 may include, but is not limited to, step S301: Step S301: According to the preset prompt word template, combine the device description information, device side information and the recognition rules and priority processing rules in the knowledge module into structured prompt words; The preset prompt template includes fields for task description, input data, available knowledge, constraints, and output format requirements. The task description field is used to explain the target task, which identifies the device model and manufacturer, to the large model. The input data field is used to fill in device description information and device-side information; The available knowledge fields can be used to fill in the OID recognition rule set, CLI recognition rule set, and experience rule set; The constraint field is used to limit the large model to reason according to the rules provided in the available knowledge fields; The output format requirement field is used to specify that the large model should output the recognition results in the specified JSON format.

[0042] In step S301 of some embodiments, the device description information, device-side information, and various identification rules and priority processing rules in the knowledge module are combined into structured prompt words. This application embodiment further specifies that the combination is performed according to a preset prompt word template. This template includes a task description field (explaining the target task to the large model), an input data field (filling in the device description information and device-side information), an available knowledge field (filling in the OID recognition rule set, CLI recognition rule set, and empirical rule set), a constraint field (limiting the large model to reason only based on available knowledge), and an output format requirement field (limiting output to JSON format). This application embodiment, by structuring multi-source heterogeneous information and domain knowledge into prompt words according to a fixed template, injects expert domain knowledge into the reasoning process of the large model in a standardized manner. In particular, the introduction of the constraint field limits the large model to reason only based on the rules provided in the available knowledge field and prohibits the introduction of external knowledge. This effectively solves the uncontrollable problem that may result from the large model "freely playing" in the professional domain. At the same time, the clear output format requirements provide a unified parsing standard for the large model to subsequently return structured recognition results, ensuring the parsability and stability of the reasoning results.

[0043] refer to Figure 5 In some embodiments, step S104 may include, but is not limited to, steps S401 to S409: Step S401: The structured prompts are sent to the large model via an API call interface or a local model loading interface; after receiving the structured prompts, the large model parses the device description information and device-side information in the input data fields under the constraints of the condition fields; the large model selects the corresponding recognition path for inference based on the data type of the device-side information. Step S402: When the device-side information is OID, the large model compares the OID with the OID identification rule set in the available knowledge fields, matches the corresponding manufacturer name and model name according to the longest OID prefix matching principle, and uses the matching result as the first identification conclusion. Step S403: When the device-side information is CLI echo text, the large model traverses each CLI feature matching record in the CLI recognition rule set, detects whether the CLI echo text contains the feature strings in each record, and takes the manufacturer name and model name corresponding to the matched feature record as the second recognition conclusion. Step S404: When the device-side information contains both OID and CLI echo text, the large model performs reasoning according to the OID recognition path and the CLI recognition path respectively to obtain the first recognition conclusion and the second recognition conclusion. Step S405: When the first identification conclusion and the second identification conclusion are inconsistent, the large model selects the final identification conclusion from the first identification conclusion and the second identification conclusion according to the priority adoption strategy indicated in the preset conflict priority rules in the knowledge module. Step S406: When equipment-side information is missing, the large model matches the manufacturer name and model name filled in the equipment description information in each of the identification rules in the available knowledge fields, and uses the matching result as the final identification conclusion. Step S407: After obtaining the final identification conclusion, the large model generates confidence information based on the reliability of the data source on which the final identification conclusion is based and the degree of consistency between the device description information and the device-side information. Step S408: Based on the recognition path and matched rules used in the recognition process, the large model generates reasoning basis information; the reasoning basis information includes the data source and the matched rules used in this recognition. Step S409: Output the recognition results using the large model in JSON format as required by the output format requirements; the recognition results include the manufacturer name field, model name field, confidence level field, and reasoning basis field.

[0044] In steps S401 to S409 of some embodiments, structured prompts are sent to the large model, enabling the large model to output recognition results by integrating device description information and device-side information under constraints. This application further defines the implementation method for selecting the corresponding recognition path for reasoning based on the data type of the device-side information: when the device-side information is an OID, matching is performed according to the longest matching principle of the OID prefix; when it is a CLI echo, string matching is performed by traversing CLI feature matching records; when both are present, first and second recognition conclusions are obtained respectively, and when they are inconsistent, the final conclusion is selected according to the conflict priority rule; when device-side information is missing, fuzzy matching is performed based on the filled-in information; finally, confidence information is generated based on the reliability of the data source and the consistency of the information, and reasoning basis information is generated based on the recognition path and matching rules. This application's embodiments utilize the language understanding and reasoning capabilities of a large model to comprehensively judge dispersed OID rules, CLI features, and list descriptions, replacing traditional hard-coded rule matching. This allows for flexible handling of complex situations such as filling errors, typos, inconsistent naming, and diverse descriptions. Simultaneously, it forces the large model to output confidence levels and reasoning bases, achieving transparent identification that "knows not only what" but also "why." The confidence levels and reasoning bases not only enhance maintenance personnel's trust in the system and provide accurate decision-making assistance for manual review but also provide traceable evidence for subsequent fault investigation and knowledge auditing.

[0045] refer to Figure 6In some embodiments, step S105 may include, but is not limited to, steps S501 to S505: Step S501: Extract the manufacturer name field, model name field, confidence level field, and reasoning basis field from the identification results; Step S502: Read the confidence level from the confidence level field; the confidence level includes high confidence, medium confidence and low confidence. Step S503: When the confidence level is high confidence, overwrite the manufacturer name in the manufacturer name field with the manufacturer name in the corresponding equipment record in the management form, and overwrite the model name in the model name field with the model name in the corresponding equipment record in the management form. Step S504: When the confidence level is medium or low, retain the manufacturer name and model name of the corresponding equipment record in the management form, and add a "to be reviewed" mark to the equipment record. Step S505: The reasoning basis information in the reasoning basis field is associated and stored in the device record. The reasoning basis information is associated with the IP address, the name of the manufacturer, the name of the model, and the OID or CLI echo text and stored in the device record.

[0046] In steps S501 to S505 of some embodiments, based on the confidence level in the identification result, the manufacturer name and model name in the identification result are respectively filled back into the manufacturer field and model field of the registration form, and the reasoning basis is associated and stored in the device record. This application embodiment further defines the implementation method of extracting each field from the identification result, reading the confidence level, and processing it according to the level: at high confidence, the corresponding reported manufacturer name and model name in the registration form are directly overwritten; at medium or low confidence, the original content is retained and a "to be reviewed" mark is added; regardless of the confidence level, the reasoning basis is associated and stored with the IP address, reported manufacturer name, reported model name, OID, or CLI echo text for review and reference. This application's embodiments employ a differentiated processing mechanism that achieves fully automatic correction of high-confidence results and introduces manual review for medium- and low-confidence results. This maximizes the efficiency advantages of automation while providing a risk mitigation mechanism through manual supervision to prevent the spread of automated errors in uncertain identification results. Simultaneously, by associating and storing the reasoning basis with multi-source information in the device records, manual reviewers can make accurate judgments based on complete contextual information (original data entry, actual information from the device, and reasoning basis), achieving efficient human-machine collaborative closed-loop processing.

[0047] refer to Figure 7 In some embodiments, step S106 may include, but is not limited to, steps S601 to S60B: Step S601: After the manufacturer and model fields in the management form are corrected, the corresponding acquisition adapter is matched according to the corrected manufacturer name and model name, and the acquisition task for the target device is executed to obtain acquisition success or failure information; the acquisition success or failure information includes acquisition success status or acquisition failure status and failure reason. Step S602: Obtain the review result submitted by the user; the review result includes confirmation information or correction information of the identification result; the correction information includes the corrected manufacturer name and model name, as well as supplementary rule description; Step S603: When the review result includes correction information, the corrected manufacturer name and model name are used as the correct labels, associated with the equipment description information and equipment-side information in the equipment record, and formatted as a new mapping record. Step S604: When the success or failure information includes a failure status, associate the failure status with the device record and mark it as a negative sample. Step S605: Format the new mapping record or negative sample into a knowledge update request; Step S606: Based on the knowledge update request, perform the following update operations on the knowledge module: Step S607: Add the new mapping record to the OID recognition rule set or CLI recognition rule set as a newly added OID mapping record or CLI feature matching record; Step S608: Based on the corrected manufacturer name and model name, correct the corresponding manufacturer field or model field in the existing OID mapping record or CLI feature matching record in the knowledge module. Step S609: Based on the failure status and cause of the data collection failure, adjust the priority adoption strategy or confidence threshold of the conflict priority rules in the knowledge module. Step S60A: Based on the supplementary rule description, generate a new conflict resolution rule record and add it to the empirical rule set; Step S60B: Save the updated knowledge module to the device identification knowledge base.

[0048] In steps S601 to S60B of some embodiments, the success or failure information of the data collection task obtained by performing the data collection task based on the corrected manufacturer field and model field is obtained, and the data collection success or failure information is fed back to the knowledge module for updating. This application embodiment further defines the implementation method of obtaining data collection success or failure information by matching the data collection adapter with the corrected manufacturer name and model name, obtaining the user-submitted review results (including confirmation information or correction information and supplementary rule descriptions), formatting manually corrected labels into new mapping records or marking them as negative samples, generating a knowledge update request, and then performing various update operations on the knowledge module (adding mapping records, correcting existing mapping records, adjusting conflict priority rules or confidence thresholds, generating new conflict handling rules). This application embodiment enables the system to continuously learn and optimize, adaptively respond to dynamic environments such as new equipment entering the network and changes in manufacturer naming habits, and continuously improve the recognition accuracy as the running time increases; at the same time, it uses the success or failure status of the data collection task as a feedback signal to achieve intelligent operation and maintenance.

[0049] refer to Figure 8 This application also provides an intelligent identification and correction system for equipment models and manufacturers in management lists, used to implement the method described above. The system includes: The information acquisition module is used to acquire the device description information in the management form, detect the target device to obtain device-side information, and associate the device description information with the device-side information to store the device record to be inferred. The knowledge base interface module is used to load the knowledge modules identified by the device based on device records; The prompt word construction module is used to combine the device description information, device-side information, and various recognition rules and priority processing rules in the knowledge module from the device record into structured prompt words; The large model inference module is used to send structured prompts to the large model, so that the large model can integrate device description information and device-side information under constraints and output recognition results. The list correction module is used to fill the manufacturer name and model name in the identification results back into the manufacturer field and model field of the management form respectively, based on the confidence level in the identification results, and to associate and store the reasoning basis in the identification results into the equipment record; The closed-loop feedback module is used to obtain the success or failure information of the data collection task based on the corrected manufacturer and model fields, and to feed the success or failure information back to the knowledge module for updating.

[0050] As an optional implementation, the main method of this application includes: 1. During the management process, obtain the equipment list and equipment description information provided by the provincial company, and optionally obtain equipment-side information (such as SNMP OID, CLI echo text, etc.).

[0051] 2. Load and apply the device identification knowledge module (which encapsulates identification rules based on OID, identification knowledge and instructions based on CLI echo and historical docking experience), combine it with the large model for reasoning, and output the device model, manufacturer, and optional confidence level and explanation.

[0052] 3. Fill in or correct the model and manufacturer fields in the management list with the identification results to drive subsequent data collection and configuration; mark low-confidence results or transfer them to manual review, and feed the results back to the iterative optimization of the equipment identification knowledge module.

[0053] The main innovations are: 1. The ability to identify equipment models / manufacturers is encapsulated into a reusable "equipment identification knowledge module". This module contains identification rules based on OID and identification knowledge based on CLI echo and historical docking experience. The large model performs reasoning under the constraints of this module to achieve standardized and iterative intelligent identification.

[0054] 2. At the entry point of the management system, the system integrates the information reported by the provincial company with the information obtainable from the equipment side (OID, CLI display), and performs comprehensive identification of multi-source information through the "equipment identification knowledge module + large model", and outputs the confidence level and interpretable basis, supporting manual review and knowledge accumulation.

[0055] The system approach is described in the following process: 1. The management entry point receives text information such as equipment list and equipment description provided by the provincial company, and supports obtaining equipment-side information (such as OID obtained by SNMP query, CLI echo fragment obtained from first login or detection) when feasible.

[0056] 2. Load the device identification knowledge module related to the current task from the device identification knowledge base. This module encapsulates the rules for identifying device models and manufacturers based on OID, as well as the instructions and knowledge for identifying models and manufacturers based on CLI echo text and historical docking experience.

[0057] 3. Organize the provincial company description information and equipment-side information (if any) into a large model input according to a predetermined format, and inject the instructions and knowledge in the equipment identification knowledge module as constraints or context into the large model to trigger reasoning.

[0058] 4. The large model outputs the device model, manufacturer, optional confidence level, and the rules / knowledge fragments on which it is based based on the device recognition knowledge module, forming an interpretable recognition result.

[0059] 5. Link the identification results with the management list, automatically fill in or correct the model and manufacturer fields in the list; mark or transfer records with confidence levels below the threshold to manual review, and record the review results for optimization of the equipment identification knowledge module.

[0060] 6. Configure subsequent data collection tasks based on the revised management information; optionally, incorporate manual review results and data collection success / failure feedback into the experience base to update or expand the device identification knowledge module.

[0061] As an optional implementation method, embodiments of this application include: 1. Main process steps and inventive points of the technical solution: This invention provides a method for intelligent identification, automatic correction, and completion of equipment model and manufacturer information in a registration form (a method for intelligent identification, correction, and completion of equipment model and manufacturer information in a registration form), the main steps of which are as follows: 1) Information Acquisition: When the management process is initiated, the equipment list and equipment description information submitted by the provincial company are obtained, and equipment-side information (such as SNMP OID, CLI echo text, etc.) can be obtained optionally.

[0062] 2) Knowledge Loading: Load the "Device Identification Knowledge Module" related to the current task from the device identification knowledge base. This module encapsulates identification rules based on OID as well as identification knowledge and instructions based on CLI echo and historical docking experience.

[0063] 3) Large-scale model inference: Taking the equipment list description information, equipment-side information, and the loaded equipment identification knowledge module as input, the large-scale model is triggered to perform inference. In this step, under the constraints of the knowledge module, the large-scale model integrates multi-source information and outputs the equipment model, manufacturer, and optional confidence levels and supporting explanations.

[0064] —This step is the main inventive point of this invention, and its innovation lies in: encapsulating the scattered, empirical device identification knowledge into a standardized and reusable "device identification knowledge module" and using it as the context and constraint for large model reasoning, enabling the large model to perform interpretable and high-confidence intelligent identification, effectively solving the problems of poor flexibility and difficulty in dealing with the diversity of descriptions in traditional rule matching.

[0065] 4) Result processing: Automatically backfill or correct the model and manufacturer fields in the management list with the identification results; mark low confidence results or transfer them to manual review.

[0066] 5) Closed-loop feedback: The results of manual review and the success or failure information of data collection are fed back to the equipment identification knowledge base for optimization and iteration of the equipment identification knowledge module.

[0067] Specific embodiments have been described in detail with respect to the above steps, especially step 3, as shown in the "Specific Embodiments" section below.

[0068] 2. The technical problem solved and the technical effects achieved by this invention: 1) Technical problems to be solved: This invention aims to address the technical problem in the telecommunications network equipment management process: inconsistencies between the model and manufacturer information in the equipment list submitted by provincial companies and the actual equipment (such as errors, omissions, typos, inconsistent naming, etc.) lead to the platform matching collection rules based on erroneous information, resulting in collection failures, missing resource data, and high manual investigation costs. Existing technologies rely on manual verification or single-rule matching, which suffers from low efficiency, high cost, and difficulty in reusing and iterating rules.

[0069] 2) Achieved technical effects: This invention achieves the following significant technical effects by introducing an intelligent recognition architecture of "device identification knowledge module + large model" at the inlet of the management system: A. Source correction to improve the accuracy of data collection: Automatic identification, correction and completion of equipment model / manufacturer are completed during the data collection process to ensure that subsequent data collection tasks are executed based on correct information. This reduces data collection anomalies caused by information errors from the root cause and significantly improves the success rate of data collection on the first attempt.

[0070] B. Knowledge encapsulation to enhance recognition capabilities: The scattered OID rules and CLI experience knowledge are encapsulated into standardized and reusable "device recognition knowledge modules", which makes the recognition logic maintainable and scalable, and can be combined with the language understanding capabilities of large models. This effectively addresses complex situations such as diverse descriptions and non-standard naming, and improves the coverage and accuracy of recognition.

[0071] C. Interpretable output, supporting controllable risks: The recognition results are accompanied by confidence level and reasoning basis, enabling maintenance personnel to understand the recognition process. Low-confidence results can be manually intervened in a timely manner, realizing closed-loop processing of human-machine collaboration and reducing the risks brought about by automation.

[0072] D. Closed-loop feedback for continuous evolution: By feeding back the results of manual review and the success or failure information of the collected data to the knowledge base, the device's knowledge recognition module can continuously learn and optimize, forming a self-evolving intelligent recognition system with significant long-term value.

[0073] E. Reduced operation and maintenance costs: Significantly reduced workload for manual verification and post-event investigation, improving the intelligence level and overall efficiency of cloud network operation.

[0074] The technical solution and specific embodiments of the invention in this application are as follows: This invention is applicable to automated operation and maintenance scenarios involving large-scale equipment management and resource data collection in telecommunications networks.

[0075] 1. Overview of the technical solution: The core of this invention lies in constructing a dual-engine intelligent recognition architecture of "device identification knowledge module + large model" and embedding it into the management process. The system structure of the entire technical solution is referenced... Figure 9 . 2. Specific Implementation Examples: This preferred embodiment starts with a list of two devices to be included in the management system submitted by a provincial branch of a certain operator, and fully demonstrates the entire process from information acquisition to closed-loop feedback.

[0077] Step 1: Obtain the list of entities subject to management and equipment information: Execution entities: the list receiving module and the device detection module of the management platform.

[0078] Triggering condition: Provincial units upload equipment list files via web interface or push list data via API.

[0079] Processing Actions: The manifest receiving module parses the manifest file to obtain a list of device records. For each record, the device detection module concurrently executes detection tasks based on the IP address: First, try using SNMP v2c / v3 to obtain the device's sysObjectID (corresponding to OID .1.3.6.1.2.1.1.2.0) and any possible private OIDs.

[0080] If SNMP is unreachable or OID acquisition fails, attempt SSH login (using a pre-configured generic username / password or key) and execute a pre-defined list of commands, such as display version (Huawei / H3C), show version (Cisco / other vendors), show system (Juniper), etc., and capture the returned CLI text snippets. If login fails or there is no CLI response, mark the device-side information as missing.

[0081] The results show that each device record is associated with the following fields: IP address, manufacturer of the device information, model number of the device information, obtained OID (if any), obtained CLI echo (if any), and device reachability status. In this embodiment: Device A (10.10.1.1): Enter the manufacturer "Huawei", model is empty, OID obtained successfully: .1.3.6.1.4.1.2011.2.23.4.10, CLI not detected.

[0082] Device B (10.10.2.2): The manufacturer is "Cisco", the model is "Catalyst 9200", SNMP is unreachable, SSH is successful, and the CLI output includes "Cisco IOS XE Software, Version 17.3.3" and "Cisco Catalyst9300".

[0083] The purpose of this step is to provide as much raw data as possible for subsequent reasoning, including unreliable reported information and reliable real information from the device side.

[0084] Step 2: Load the device identification knowledge module: Execution entity: The large model inference engine calls the knowledge base interface.

[0085] Trigger condition: The inference engine is preparing to process a batch of device records.

[0086] Processing Action: The inference engine uses the device's recorded IP address network segment, historical experience, or directly loads the globally default "Device Identification Knowledge Module." The knowledge module is stored in JSON or a specific format; an example of its content is shown below: { "module_id": "core_router_switch_v1", "oid_rules": [ {"oid_prefix": ".1.3.6.1.4.1.2011.2.23.4", "vendor": "Huawei", "family": "NetEngine 8000", "specific": {".1.3.6.1.4.1.2011.2.23.4.10": "NetEngine 8000 M14"}}, {"oid_prefix": ".1.3.6.1.4.1.9.1.", "vendor": "Cisco", "family": "Catalyst"} ], "cli_rules": [ {"pattern": "Cisco IOS XE Software", "vendor": "Cisco"}, {"pattern": "Catalyst 9300", "model": "Catalyst 9300"} ], "experience": [ {"condition": "The list model name conflicts with the model feature in the CLI echo", "action": "Prefer the CLI feature"} ] } The result obtained: The inference engine has acquired the rules and experience knowledge used for this inference.

[0087] The purpose of this step is to inject expert domain knowledge into the reasoning process in a standardized and reusable manner, avoiding the complete free play of large models and improving recognition accuracy and interpretability.

[0088] Step 3: Construct cue words and call the large model for inference: Execution entity: Large model inference engine.

[0089] Triggering condition: After the knowledge module is loaded, construct prompt words for each device record one by one.

[0090] Processing Action: The inference engine combines device information with knowledge module content to form prompts. The design of these prompts is crucial, as they must clearly inform the large model of the task objective, input data, and constraints. Taking device B as an example, the prompt structure is as follows:

Task

[0091] [Enter Information] Equipment list description: Manufacturer to be filled in: Cisco Model number to be filled in: Catalyst 9200 Equipment-side information: CLI echo snippet: Cisco IOS XE Software, Version 17.3.3 Cisco Catalyst 9300 Available knowledge modules { "cli_rules": [ {"pattern": "Cisco IOS XE Software", "vendor": "Cisco"}, {"pattern": "Catalyst 9300", "model": "Catalyst 9300"} ], "experience": {"condition": "The model in the list conflicts with the model feature in the CLI echo", "action": "Prioritize the CLI feature"} } [Output Format] Please strictly output in the following JSON format: { "vendor": "Manufacturer Name", "model": "Model Name", "confidence": "High / Medium / Low", "reason": "Briefly describe the reasoning process and basis" } The inference engine sends the prompt to the large model (which can be a model loaded via API or locally) and obtains the response.

[0092] The obtained result: the large model returns a structured recognition result. For device B, it returns: { "vendor": "Cisco", "model": "Catalyst 9300", "confidence": "High", "reason": "The manufacturer described in the list is Cisco, which matches the CLI rule. The model in the list is Catalyst 9200, but the CLI echo clearly contains 'Catalyst 9300'. According to the empirical rule in the knowledge module (prioritize the CLI feature), it is determined that the actual model should be Catalyst 9300." } For device A, a similar result is returned, based on the exact OID match.

[0093] Function of the step: Combine multi-source heterogeneous information (text list, OID, CLI) with the domain knowledge module, and utilize the language understanding and reasoning capabilities of the large model to generate accurate and interpretable recognition conclusions. This step is the core inventive point of the present invention, which replaces the traditional hard-coded rule matching and can flexibly handle various description deviations and missing situations.

[0094] ​Alternative solutions: If the enterprise has high data security requirements, the large model can be replaced with a lightweight NLP model (such as a BERT variant) deployed locally and privately. However, the knowledge modules need to be vectorized or structured, sacrificing some generalization ability in exchange for compliance. Alternatively, a multi-model voting mechanism can be adopted to combine the results of multiple large models to improve robustness.

[0095] Step 4: Result Processing and List Correction: Execution Module: List Correction Module.

[0096] Triggering condition: Receiving the recognition results returned by the large model.

[0097] Processing Actions: Update the manufacturer and model information from the identification results to the internal equipment record table. For records with a "high" confidence level, directly overwrite the original list fields; for records with a "medium" or "low" confidence level, retain the original fields while adding a label (such as "pending verification"), and store the reasoning basis for subsequent manual review. Simultaneously, pass the corrected equipment information to the task scheduling module for matching with the acquisition adapter.

[0098] The results were: an updated list of devices and a queue of devices requiring manual review.

[0099] The purpose of this step is to ensure that accurate equipment information is used in subsequent data collection processes, and to introduce manual supervision for uncertain identifications to prevent the spread of automated errors.

[0100] Alternative solutions include setting dynamic confidence thresholds, such as dynamically adjusting the "high" standard based on historical accuracy; or automatically including devices with "medium" confidence in grayscale data collection and verification, and then deciding whether to adopt them based on the success rate of data collection.

[0101] Step 5: Manual review and closed-loop feedback: Execution entities: Operation and maintenance personnel (through the manual review interface), and closed-loop feedback module.

[0102] Triggering conditions: A device record with a confidence level lower than the threshold is found, or the data collection task fails to execute.

[0103] Processing Actions: Maintenance personnel log in to the review interface to view device details, original information, inference results, and supporting evidence. If they approve the inference results, they click "Confirm," and the device proceeds to normal data collection. If they believe the inference is incorrect, they manually correct it to the correct manufacturer and model number and provide a brief explanation. The closed-loop feedback module formats the manual review results (including the correct manufacturer and model number and any rules the user may add) into a knowledge update request and sends it to the knowledge base management terminal. For example, if a manual reviewer discovers that the actual model number of a device is "Catalyst 9300L," but the large model output is "Catalyst 9300," the feedback information can indicate that "when 'Catalyst 9300' appears in the CLI echo, it should be further subdivided into 9300 or 9300L, and other features should be considered," thereby driving the refinement of the knowledge module.

[0104] Results: The knowledge module has been continuously optimized, which will improve the recognition accuracy of similar devices in the future; the data collection task was successfully executed based on correct information.

[0105] Function of the steps: To form a closed loop of human-machine collaboration, enabling the system to have self-learning capabilities and continuously adapt to new equipment and new situations.

[0106] Alternative solution: An automated feedback verification mechanism can be added. For example, for the same type of equipment that has been manually corrected multiple times, new rule candidates can be automatically generated and automatically merged into the knowledge module after testing and verification.

[0107] The beneficial effects of this application include: 1. Key Technical Point 1: Dual-engine intelligent recognition architecture based on "device recognition knowledge module + large model": Technical means: This invention encapsulates the OID rules, CLI features, and historical docking experience required for device identification into a standardized and reusable "device identification knowledge module," which serves as the context and constraints for large-scale model reasoning. At the management entry point, guided by the knowledge module, the large-scale model performs reasoning by integrating the device list description and device-side information (OID / CLI), outputting the device model, manufacturer, confidence level, and basis.

[0108] Advantages compared to existing technologies: Existing technologies either rely on manual verification (inefficient) or on hard-coded scripts or single-rule matching (lacking flexibility and unable to handle diverse descriptions, typos, omissions, etc.).

[0109] The advantages of this invention are: by encapsulating domain experience through knowledge modules, it solves the uncontrollable problems that may arise from large models "freely applying" their capabilities in specialized fields; at the same time, by utilizing the language understanding and reasoning capabilities of large models, it overcomes the limitations of traditional rule matching in handling complex scenarios such as semantic ambiguity and inconsistent naming. The combination of these two aspects achieves a unity of "reusability of experience" and "flexibility of intelligence," representing a completely new architecture in the field of device recognition.

[0110] 2. Technical Point Two: Standardized Encapsulation and Iterable Mechanism of Device Identification Knowledge Module: Technical means: This invention abstracts and standardizes the originally scattered device identification rules that rely on personal experience (such as "a certain OID corresponds to a certain model" or "a certain CLI feature code corresponds to a certain manufacturer"), and encapsulates them into an independent "device identification knowledge module". This module can be stored independently in a knowledge base and supports version management, dynamic loading, and continuous updates.

[0111] Advantages compared to existing technologies: Existing technology: Identification rules are usually scattered in data collection scripts, configuration files, or personal documents of operations and maintenance personnel, making them difficult to maintain, reuse, and pass on. Adding or modifying a rule often requires modifying multiple parts of the code.

[0112] Advantages of this invention: The standardized encapsulation of knowledge modules decouples the recognition logic from the data collection and execution logic, significantly reducing the cost of knowledge maintenance. When new devices need to be supported or old rules need to be corrected, only the knowledge modules need to be updated, without modifying the core code. Simultaneously, the reusability of the modules allows the same knowledge to be quickly deployed in different provincial companies and different projects, achieving the accumulation and consolidation of enterprise-level knowledge assets.

[0113] 3. Technical Point Three: Interpretable Reasoning and Confidence Output Mechanism Integrating Multi-Source Information: Technical means: During the inference phase, this invention mandates that the large model output structured results, which must include not only the manufacturer and model number, but also the "confidence level" (high / medium / low) and "reasoning basis" (such as "basis: exact OID match" or "basis: CLI features take precedence over the list"). For records with a confidence level below the threshold, the system automatically forwards them to manual review.

[0114] Advantages compared to existing technologies: Existing technology: Automated identification results are often "black boxes". Operation and maintenance personnel do not know where the identification conclusions come from, and they cannot quickly judge suspicious results, resulting in low trust in automated systems or reluctance to enable fully automated processes.

[0115] The advantages of this invention are: it achieves transparent identification that not only "knows what," but also "knows why." The confidence level and reasoning basis not only enhance maintenance personnel's trust in the system and provide accurate decision-making assistance for manual review, but also provide traceable evidence for subsequent troubleshooting and knowledge auditing. This "human-machine collaboration" mechanism ensures that high-risk decisions remain under control, which is key to the successful implementation of automated systems in telecom-grade maintenance environments.

[0116] 4. Technical Point Four: Closed-loop feedback and knowledge self-optimization mechanism between identification results and the management process: Technical means: This invention transmits the correct results after manual verification, as well as the success or failure information of subsequent data collection tasks, back to the device recognition knowledge base through a closed-loop feedback module to drive the optimization and iteration of the knowledge module. For example, manually corrected model numbers will be used as new training data or rule bases to update the knowledge module.

[0117] Advantages compared to existing technologies: Existing technology: Most recognition systems are static; once deployed, their recognition capabilities are fixed. Adding new devices or discovering errors requires manual revision and updates of the rules.

[0118] The advantages of this invention are: it constructs a flywheel effect from "data" to "knowledge" and then to "intelligence." Every manual review and data collection verification transforms into nourishment for the evolution of knowledge modules. The more the system is used, the smarter it becomes, with recognition accuracy continuously improving over time. It can adaptively respond to dynamic environments such as new devices joining the network and changes in manufacturer naming conventions, achieving true intelligent operation and maintenance.

[0119] 5. Technical Point Five: Strategy for fusing information from the inventory entry point with equipment-side information (OID / CLI): Technical means: At the starting point of the management process, this invention not only passively receives the list information submitted by the provincial company, but also actively initiates the detection of target devices to obtain their OID and / or CLI echo. Even if the acquisition of device-side information fails, the process can still continue based on the list description.

[0120] Advantages compared to existing technologies: Current technology: Most of the time, the problem is only investigated by logging into the device after the data collection fails, which is a "post-event remedy".

[0121] The advantages of this invention are that it transforms "passive reception" into "active verification." Before data collection occurs, real information from the device side is cross-validated with the inventory information, achieving "prevention before the event." This design ensures the accuracy of the basic data used to drive data collection from a process perspective, which is a prerequisite for the effectiveness of all subsequent intelligent identification and error correction. Simultaneously, it provides compatibility handling for situations where device-side information acquisition fails, ensuring the robustness of the solution in real-world complex network environments.

[0122] In summary, this invention constructs a complete, innovative, and practical intelligent identification solution for telecommunications network equipment models through the five progressive and mutually supportive technical points mentioned above. It has achieved significant progress in terms of accuracy, efficiency, interpretability, self-evolution capability, and process robustness, surpassing existing technologies.

[0123] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0124] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0125] Please see Figure 10 , Figure 10 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 1001 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 1002 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 1002 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1002 and is called and executed by the processor 1001 using the methods described in the embodiments of this application. Input / output interface 1003 is used to implement information input and output; The communication interface 1004 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 1005 transmits information between various components of the device (e.g., processor 1001, memory 1002, input / output interface 1003, and communication interface 1004); The processor 1001, memory 1002, input / output interface 1003 and communication interface 1004 are connected to each other within the device via bus 1005.

[0126] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0127] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0128] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0129] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0130] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0131] This application provides a method, system, electronic device, storage medium, and program product for intelligent identification and correction of device models and manufacturers in a registration form. It constructs a dual-engine intelligent identification architecture of "standardized device identification knowledge module + large model." At the entry point of the registration process, it cross-validates the list description information submitted by the enterprise with the actual device information (SNMP OID or CLI echo) actively detected. The large model, under the constraints of the knowledge module, performs comprehensive reasoning to automatically identify, correct, and complete the device model and manufacturer information in the registration form that is incorrectly filled, missing, or inconsistently named. Through confidence level processing, manual review, and closed-loop feedback mechanisms, it drives continuous iterative optimization of the knowledge module, ultimately ensuring the accurate execution of subsequent resource collection tasks from the source, reducing manual maintenance costs, and improving the first-time success rate of registration.

[0132] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0133] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0134] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0135] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0136] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0137] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0138] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0139] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0140] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0141] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for intelligent identification, correction, and completion of equipment model and manufacturer information in a data entry form, characterized in that... The method includes the following steps: Obtain device description information from the management list, detect the target device to obtain device-side information, and associate the device description information with the device-side information to store as a device record to be inferred. Based on the device records, load the device identification knowledge module; The device description information, device-side information, and various identification rules and priority processing rules in the knowledge module are combined into structured prompt words; The structured prompts are sent to the large model, which then integrates the device description information and the device-side information under constraints to output a recognition result. Based on the confidence level in the identification results, the manufacturer name and model name in the identification results are respectively filled into the manufacturer field and model field of the management form, and the reasoning basis in the identification results is associated and stored in the device record; Obtain the success or failure information of the data collection task based on the corrected manufacturer and model fields, and feed the success or failure information back to the knowledge module for updating.

2. The method according to claim 1, characterized in that, The steps of obtaining device description information from the management list, detecting the target device to obtain device-side information, and associating and storing the device description information and the device-side information as a device record to be inferred include: Parse the electronic form file submitted by the user to obtain a list of device records. Each device record contains the IP address of the target device, the name of the manufacturer who submitted the form, and the name of the model that was submitted. Use the IP address, the name of the manufacturer who submitted the form, and the name of the model that was submitted as the device description information. Based on the IP address in the device record list, concurrently execute the probe task for the target device; the probe task includes an SNMP probe subtask and a CLI probe subtask; the SNMP probe subtask is to obtain the system OID or private OID of the target device through the SNMP protocol; the CLI probe subtask is to log in to the target device through the Telnet or SSH protocol, execute a preset command list, and capture the returned CLI echo text; When the SNMP probe subtask or the CLI probe subtask successfully obtains device-side information, the obtained OID or CLI echo text is used as the device-side information; when both the SNMP probe subtask and the CLI probe subtask fail, the device-side information is marked as missing. The device description information is associated with the obtained OID or CLI echo text and stored as a device record to be inferred.

3. The method according to claim 1, characterized in that, The step of loading the device identification knowledge module based on the device records includes: Obtain the IP address from the device record, and match and load the corresponding device identification knowledge module from the device identification knowledge base according to the network segment or enterprise to which the IP address belongs; If the knowledge module cannot be matched based on the IP address, then the preset global default knowledge module is loaded; the knowledge module is stored in JSON format and includes an OID recognition rule set, a CLI recognition rule set, and an experience rule set. The OID identification rule set includes several OID mapping records. Each OID mapping record contains an OID prefix field, a manufacturer field, an equipment series field, or a specific model field. The OID mapping record is used to match the corresponding manufacturer name and model name based on the obtained OID. The CLI identification rule set includes several CLI feature matching records. Each CLI feature matching record contains a feature string field, a manufacturer field, or a model field. The CLI feature matching records are used to match the corresponding manufacturer name and model name based on whether the CLI echo text contains the feature string. The set of empirical rules includes several conflict handling rule records. Each conflict handling rule record contains a conflict condition field and a priority strategy field. The conflict handling rule records are used to indicate which source of information should be prioritized for identification when the device description information is inconsistent with the device-side information.

4. The method according to claim 1, characterized in that, The step of combining the device description information, the device-side information, and the various identification rules and priority processing rules in the knowledge module into structured prompt words includes: According to the preset prompt word template, the device description information, the device side information, and the various identification rules and priority processing rules in the knowledge module are combined into structured prompt words; The preset prompt word template includes a task description field, an input data field, an available knowledge field, a constraint field, and an output format requirement field; The task description field is used to explain the target task, which identifies the device model and manufacturer, to the large model. The input data field is used to fill in the device description information and the device-side information; The available knowledge fields are used to fill in the OID recognition rule set, CLI recognition rule set, and experience rule set; The constraint field is used to limit the large model to reason according to the rules provided in the available knowledge field; The output format requirement field is used to specify that the large model outputs the recognition results in the specified JSON format.

5. The method according to claim 4, characterized in that, The step of sending the structured prompts to the large model, so that the large model, under constraints, integrates the device description information and the device-side information to output a recognition result, includes: The structured prompts are sent to the large model via an API call interface or a local model loading interface; after receiving the structured prompts, the large model parses the device description information and device-side information in the input data field under the constraints of the condition field; the large model selects the corresponding recognition path for inference based on the data type of the device-side information: When the device-side information is an OID, the large model compares the OID with the OID identification rule set in the available knowledge fields, matches the corresponding manufacturer name and model name according to the longest OID prefix matching principle, and uses the matching result as the first identification conclusion. When the device-side information is the CLI echo text, the large model traverses each CLI feature matching record in the CLI recognition rule set, detects whether the CLI echo text contains the feature strings in each record, and takes the manufacturer name and model name corresponding to the matched feature record as the second recognition conclusion. When the device-side information contains both the OID and the CLI echo text, the large model performs reasoning according to the OID recognition path and the CLI recognition path respectively to obtain the first recognition conclusion and the second recognition conclusion. When the first identification conclusion is inconsistent with the second identification conclusion, the big model selects the final identification conclusion from the first identification conclusion and the second identification conclusion according to the priority adoption strategy indicated in the preset conflict priority rules in the knowledge module. When the device-side information is missing, the large model matches the manufacturer name and model name filled in the device description information according to the identification rules in the available knowledge fields, and uses the matching result as the final identification conclusion. After obtaining the final identification conclusion, the large model generates confidence information based on the reliability of the data source on which the final identification conclusion is based and the degree of consistency between the device description information and the device-side information. The large model generates reasoning information based on the recognition path and matched rules used in the recognition process; the reasoning information includes the data source and the matched rules used in this recognition. The large model outputs the recognition results in JSON format according to the output format requirements; the recognition results include the manufacturer name field, model name field, confidence level field, and reasoning basis field.

6. The method according to claim 1, characterized in that, The step involves, based on the confidence level in the identification result, backfilling the manufacturer name and model name from the identification result into the manufacturer field and model field of the management form, respectively, and storing the reasoning basis from the identification result in the device record, including: Extract the manufacturer name field, model name field, confidence level field, and reasoning basis field from the identification results; Read the confidence level from the confidence field; the confidence level includes high confidence, medium confidence, and low confidence. When the confidence level is high confidence, the manufacturer name in the manufacturer name field will overwrite the manufacturer name in the corresponding device record in the management form, and the model name in the model name field will overwrite the model name in the corresponding device record in the management form. When the confidence level is medium or low, retain the manufacturer name and model name of the corresponding device in the management form, and add a "to be reviewed" mark to the device record. The reasoning basis information in the reasoning basis field is associated and stored in the device record. The reasoning basis information is associated with the IP address, the name of the manufacturer to be filled in, the name of the model to be filled in, the OID or the CLI echo text and stored in the device record.

7. The method according to claim 1, characterized in that, The process of obtaining the success or failure information of the data collection task based on the corrected manufacturer and model fields, and then feeding this success or failure information back to the knowledge module for updating, includes: After the manufacturer and model fields in the management form are corrected, the corresponding acquisition adapter is matched according to the corrected manufacturer name and model name, and the acquisition task for the target device is executed to obtain acquisition success or failure information; the acquisition success or failure information includes acquisition success status or acquisition failure status and failure reason. Obtain the review results submitted by the user; the review results include confirmation information or correction information for the identification results; the correction information includes the corrected manufacturer name and model name, as well as supplementary rule descriptions; When the review result includes the correction information, the corrected manufacturer name and model name are used as the correct labels, associated with the equipment description information and equipment-side information in the equipment record, and formatted as a new mapping record; When the data acquisition success or failure information includes the data acquisition failure status, the data acquisition failure status is associated with the device record and marked as a negative sample; Format the new mapping record or the negative sample into a knowledge update request; Based on the knowledge update request, the following update operation is performed on the knowledge module: The new mapping record is added to the OID recognition rule set or CLI recognition rule set as a new OID mapping record or CLI feature matching record; Based on the corrected manufacturer name and model name, correct the corresponding manufacturer field or model field in the existing OID mapping record or CLI feature matching record in the knowledge module; Based on the data acquisition failure status and the failure reason, adjust the priority adoption strategy or confidence judgment threshold of the conflict priority rule in the knowledge module; Based on the supplementary rule description, generate new conflict resolution rule records and add them to the empirical rule set; Save the updated knowledge module to the device identification knowledge base.

8. A system for intelligent identification, correction, and completion of equipment model and manufacturer information in a data entry form, used to implement the method described in any one of claims 1 to 7, characterized in that, The system includes: The information acquisition module is used to acquire device description information from the management form, detect the target device to obtain device-side information, and associate the device description information with the device-side information to store as a device record to be inferred. The knowledge base interface module is used to load the knowledge module identified by the device based on the device records; The prompt word construction module is used to combine the device description information, the device-side information, and the various identification rules and priority processing rules in the knowledge module into structured prompt words; The large model inference module is used to send the structured prompt words to the large model, so that the large model can integrate the device description information and the device-side information under the constraints and output the recognition result; The list correction module is used to fill the manufacturer name and model name in the identification result back into the manufacturer field and model field of the management form respectively, based on the confidence level in the identification result, and to associate and store the reasoning basis in the identification result into the device record; The closed-loop feedback module is used to obtain the success or failure information of the data collection task obtained by performing the data collection task based on the corrected manufacturer field and model field, and to feed the success or failure information of the data collection to the knowledge module for updating.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images