Method for modifying configuration options of a bios

Abstract

The application relates to the field of computer software configuration management, in particular to a modification method of a BIOS configuration option. The method comprises the following steps: acquiring a rule file and a heterogeneous file; performing analysis and processing on the heterogeneous file according to the rule file to determine a global knowledge graph; wherein the global knowledge graph represents semantic correlation of the BIOS configuration option; when it is determined that a modification instruction of a second user is received, determining modification information of a target configuration option according to the modification instruction and the global knowledge graph; wherein the modification instruction represents a natural language text, the target configuration option represents a configuration option matched with the modification instruction in the global knowledge graph, and the modification information represents modification parameters for realizing modification of the target configuration option; and performing modification processing on the target configuration option according to the modification information to obtain a processing result. The method is used to improve the modification efficiency and reliability of the BIOS configuration option.

Description

Technical Field

[0001] This application relates to the field of computer software configuration management, and more particularly to a method for modifying BIOS configuration options. Background Technology

[0002] During hardware development, testing, and deployment, modifications to the configuration options of the Basic Input Output System (BIOS) typically rely on specialized tools, configuration file parsing, and manual retrieval by relevant professionals to locate and adjust the options.

[0003] However, existing solutions mostly rely on fixed parsing logic and preset operation methods, combined with the cooperation of professionals. For non-professionals, when faced with configuration relationships scattered in multiple heterogeneous files, it is difficult to fully associate options with underlying definitions, resulting in decreased positioning efficiency and recognition accuracy. When there are large differences in naming on different hardware platforms, it will further increase the adaptation and maintenance costs.

[0004] Therefore, improving the efficiency and reliability of modifying BIOS configuration options to achieve intelligent management of BIOS configuration options for users with different technical backgrounds has become a technical problem that needs to be solved. Summary of the Invention

[0005] The method for modifying BIOS configuration options provided in this application embodiment can improve the efficiency and reliability of modifying BIOS configuration options.

[0006] In a first aspect, embodiments of this application provide a method for modifying BIOS configuration options, including:

[0007] Obtain the rule file and the heterogeneous file; the rule file is maintained by the first user, and the heterogeneous file represents the BIOS configuration definition data;

[0008] Based on the rule file, heterogeneous files are parsed to determine the global knowledge graph; the global knowledge graph represents the semantic relationships of BIOS configuration options.

[0009] Upon receiving a modification instruction from a second user, the modification information for the target configuration option is determined based on the modification instruction and the global knowledge graph. Here, the modification instruction represents natural language text, the target configuration option represents the configuration option in the global knowledge graph that matches the modification instruction, and the modification information represents the modification parameters that achieve the modification of the target configuration option.

[0010] Based on the modification information, the target configuration options are modified to obtain the processing result; where the processing result represents the completion status of the modification of the target configuration options.

[0011] Optionally, as described above, the heterogeneous files include configuration definition files, interface description files, string resource files, platform description files, and source code files; wherein, the configuration definition file represents the attributes and definition descriptions of the BIOS configuration options, the interface description file represents the interface layout and navigation structure descriptions of the BIOS configuration options, the string resource file represents the display text descriptions of the BIOS configuration options, the platform description file represents the platform-related configuration descriptions of the BIOS configuration options, and the source code file represents the register operation logic descriptions of the BIOS configuration options.

[0012] Optionally, as described above, the heterogeneous files are parsed and processed according to the rule file to determine the global knowledge graph, including:

[0013] According to the rule file, a preset parser is used to parse the heterogeneous file to determine the node set and the attribute information of each node in the node set. The parsing logic of the preset parser satisfies the rules in the rule file. The node set includes option nodes, interface nodes, variable nodes, platform configuration nodes, callback nodes, and register nodes. Option nodes represent BIOS configuration options, interface nodes represent the interface of BIOS configuration options, variable nodes represent the storage variables of BIOS configuration options, platform configuration nodes represent the platform configuration parameters of BIOS configuration options, callback nodes represent the callback functions of BIOS configuration options, and register nodes represent the register operation items of BIOS configuration options.

[0014] The global knowledge graph is determined based on the set of nodes and the attribute information corresponding to at least one node in the set of nodes.

[0015] Optionally, as described above, the global knowledge graph is determined based on the node set and the attribute information corresponding to at least one node in the node set, including:

[0016] Based on the attribute information of the option nodes in the node set, the first type of edge is determined; where the first type of edge represents the belonging relationship of the option node to the interface node;

[0017] Based on the attribute information of the interface nodes in the node set, the second type of edge is determined; whereby the second type of edge represents the interface jump relationship between interface nodes.

[0018] Based on the configuration definition file and the interface description file, the third type of edge is determined; whereby the third type of edge represents the reverse chain parent-child relationship between interface nodes;

[0019] Based on the attribute information of the option nodes and the platform configuration nodes in the node set, the fourth type of edge is determined; whereby the fourth type of edge represents the association relationship between the option nodes and the platform configuration nodes.

[0020] Based on the source code file, identify the fifth type of edge and the sixth type of edge; whereby the fifth type of edge represents the association between the platform configuration node and the callback node, and the sixth type of edge represents the association between the callback node and the register node;

[0021] Based on the fourth, fifth, and sixth types of edges, a seventh type of edge is determined; among them, the seventh type of edge represents the association relationship between option nodes and register nodes;

[0022] Based on the attribute information of the option nodes in the node set and the seventh type of edges, the eighth type of edges is determined; whereby the eighth type of edges represents the cross-platform equivalence relationship between option nodes;

[0023] Determine the first type of edge, the second type of edge, the third type of edge, the fourth type of edge, the fifth type of edge, the sixth type of edge, the seventh type of edge, and the eighth type of edge, and form an edge set;

[0024] The global knowledge graph is determined based on the set of nodes and the set of edges.

[0025] Optionally, as described above, the attribute information of the option node includes the option identifier, and the attribute information of the platform configuration node includes the platform configuration name; based on the attribute information of the option nodes and the platform configuration nodes in the node set, a fourth type of edge is determined, including:

[0026] For each option node and each platform configuration node in the node set, based on the preset word segmentation algorithm, the option identifier and the platform configuration name are split and processed respectively to obtain the initial option word segmentation set corresponding to the option identifier and the initial platform configuration word segmentation set corresponding to the platform configuration name.

[0027] Obtain a preset stop word set, and perform stop word filtering on the initial option word segmentation set and the initial platform configuration word segmentation set respectively to obtain the target option word segmentation set corresponding to the initial option word segmentation set and the target platform configuration word segmentation set corresponding to the initial platform configuration word segmentation set;

[0028] If it is determined that there is an intersection between the target option segmentation set and the target platform configuration segmentation set, then it is determined that there is an association between the option node corresponding to the option identifier and the platform configuration node corresponding to the platform configuration name, which is a fourth type of edge.

[0029] Optionally, as described above, based on the attribute information of the option nodes in the node set and the seventh type of edges, the eighth type of edges is determined, including:

[0030] Obtain a cross-platform equivalent knowledge base; whereby the cross-platform equivalent knowledge base represents the functional semantic correspondence of configuration options between different hardware platforms;

[0031] Based on a cross-platform equivalent knowledge base, the semantic fingerprint of each option node is determined; whereby the semantic fingerprint represents the functional semantic category identifier of the option node.

[0032] Two distinct option nodes in the node set are identified as the first option node and the second option node. If the semantic fingerprint of the first option node and the semantic fingerprint of the second option node are consistent, then the first option node and the second option node satisfy the first condition.

[0033] Based on the seventh type of edge, determine the register node corresponding to the first option node as the first register node, and determine the register node corresponding to the second option node as the second register node;

[0034] Determine the operation set for the first register, which is the first operation set, and determine the operation set for the second register, which is the second operation set; wherein, the operation set represents the type of the register and the context keyword;

[0035] If the first set of operations and the second set of operations intersect, then the first option node and the second option node satisfy the second condition.

[0036] If the first option node and the second option node satisfy the first condition and the second condition, then it is determined that there is a cross-platform equivalence relationship between the first option node and the second option node, which is the eighth type of edge.

[0037] Optionally, as described above, upon determining that a modification instruction from a second user has been received, the modification information for the target configuration option is determined based on the modification instruction and the global knowledge graph, including:

[0038] The system receives input information from a second user and uses a large language model to determine the intent type corresponding to the input information; where the input information represents natural language text.

[0039] If the intent type includes a modification type, then the input information is determined to be a modification instruction;

[0040] Based on the modification instructions, determine the intent keywords; where the intent keywords represent the core operation objects in the modification instructions;

[0041] Based on the intent keywords and the global knowledge graph, a set of candidate options is determined; wherein, the set of candidate options represents at least one configuration option in the global knowledge graph that matches the intent keywords;

[0042] Based on the candidate option set, a decision request is generated using a large language model and sent to the second user; wherein, the decision request represents a confirmation selection request for each configuration option in the candidate option set;

[0043] Receive user decision instructions; wherein, the decision instructions include modification preference data for target configuration options;

[0044] Based on the decision instructions, determine the modification information for the target configuration options.

[0045] Optionally, as described above, a set of candidate options is determined based on intent keywords and a global knowledge graph, including:

[0046] Based on the intent keywords, semantic retrieval processing is performed on each configuration option in the global knowledge graph to determine the first option set; wherein, the configuration options in the first option set are semantically matched with the intent keywords;

[0047] Based on the intent keywords, symbolic retrieval processing is performed on each configuration option in the global knowledge graph to determine the second option set; wherein, the configuration options in the second option set are fuzzy matched with the intent keywords on a symbolic basis.

[0048] Based on the intent keywords, graph query processing is performed on the global knowledge graph to determine the third option set; among them, the configuration options in the third option set have a structural relationship with the intent keywords in the global knowledge graph.

[0049] Based on the first set of options, the second set of options, and the third set of options, determine the set of candidate options.

[0050] Optionally, as described above, a candidate option set is determined based on the first option set, the second option set, and the third option set, including:

[0051] Based on a preset sorting algorithm, the first option set, the second option set, and the third option set are sorted and filtered to obtain the fourth option set;

[0052] Based on a cross-platform equivalent knowledge base and preset prompts, a large language model is used to perform reasoning on the fourth option set to obtain a candidate option set. The preset prompts are used to guide the large language model to perform cross-platform equivalent expansion and platform filtering on the fourth option set.

[0053] Optionally, as described above, the target configuration options are modified based on the modification information to obtain the processing result, including:

[0054] Based on the modification information, a confirmation request is generated and sent to the second user; wherein, the confirmation request is used to prompt the second user to return the corresponding modification path information when the target configuration option is determined to be modified. The modification path information includes a first modification path and / or a second modification path. The first modification path indicates that the modification of the target configuration option is effective on multiple machines, and the second modification path indicates that the modification of the target configuration option is effective on the current machine, and the machine has a BIOS deployed.

[0055] Receive the user's confirmation command, determine the path modification information from the confirmation command, and modify the path for the target.

[0056] The tool corresponding to the target modification path is determined from the preset tool library and is called the target tool; the preset tool library is used to store the execution tools corresponding to different modification paths;

[0057] Based on the modification information and the target tool, the target configuration options are modified to obtain the processing result.

[0058] Secondly, embodiments of this application provide a device for modifying BIOS configuration options, comprising:

[0059] The file acquisition module is used to acquire rule files and heterogeneous files; the rule files are maintained by the first user, and the heterogeneous files represent BIOS configuration definition data;

[0060] The knowledge graph determination module is used to parse heterogeneous files according to the rule file to determine the global knowledge graph; the global knowledge graph represents the semantic relationships of BIOS configuration options.

[0061] The information determination module is used to determine the modification information of the target configuration option based on the modification instruction and the global knowledge graph when it is determined that a modification instruction from the second user has been received. The modification instruction represents natural language text, the target configuration option represents the configuration option in the global knowledge graph that matches the modification instruction, and the modification information represents the modification parameters that achieve the modification of the target configuration option.

[0062] The option modification module is used to modify the target configuration options according to the modification information and obtain the processing result; the processing result represents the completion status of the modification of the target configuration options.

[0063] Thirdly, embodiments of this application provide a system for modifying BIOS configuration options, including: a memory and a processor;

[0064] The memory stores the instructions that the computer executes;

[0065] The processor executes computer execution instructions stored in memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0066] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0067] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0068] The BIOS configuration option modification method provided in this application obtains a rule file and a heterogeneous file. Based on the rule file, the heterogeneous file is parsed to determine a global knowledge graph. When a modification command from a second user is received, the modification information of the target configuration option is determined based on the modification command and the global knowledge graph. Furthermore, the target configuration option is modified based on the modification information to obtain a processing result. The rule file is maintained by a first user, the heterogeneous file represents BIOS configuration definition data, the global knowledge graph represents the semantic relationships of BIOS configuration options, the modification command represents natural language text, the target configuration option represents the configuration option in the global knowledge graph that matches the modification command, the modification information represents the modification parameters for modifying the target configuration option, and the processing result represents the completion status of the target configuration option modification. Compared to existing methods that rely on fixed parsing logic and preset operation methods combined with professional assistance, this BIOS configuration option modification method achieves semantic association integration of scattered configuration data through rule file-driven heterogeneous file parsing. It achieves accurate matching and positioning of natural language commands to configuration options through the global knowledge graph, and achieves efficient modification execution of configuration options through automated processing of modification information. The method described in this application improves the efficiency and reliability of modifying BIOS configuration options, enabling intelligent management of BIOS configuration options for users with different technical backgrounds. Attached Figure Description

[0069] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0070] Figure 1 A flowchart illustrating a method for modifying BIOS configuration options provided in this application. Figure 1 ;

[0071] Figure 2 A flowchart illustrating a method for modifying BIOS configuration options provided in this application. Figure 2 ;

[0072] Figure 3 A flowchart illustrating an interaction method driven by a large language model, provided in this application;

[0073] Figure 4 A flowchart illustrating a method for modifying BIOS configuration options provided in this application. Figure 3 ;

[0074] Figure 5 A schematic diagram of a BIOS configuration option modification device provided in this application;

[0075] Figure 6 This is a schematic diagram of the structure of a BIOS configuration option modification system provided in this application.

[0076] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0077] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0078] During hardware development, testing, and deployment, modifications to BIOS configuration options typically rely on specialized tools, configuration file parsing, and manual retrieval by relevant professionals to locate and adjust options.

[0079] However, existing solutions mostly rely on fixed parsing logic and preset operation methods, combined with the cooperation of professionals. For non-professionals, when faced with configuration relationships scattered in multiple heterogeneous files, it is difficult to fully associate options with underlying definitions, resulting in decreased positioning efficiency and recognition accuracy. When there are large differences in naming on different hardware platforms, it will further increase the adaptation and maintenance costs.

[0080] Therefore, improving the efficiency and reliability of modifying BIOS configuration options to achieve intelligent management of BIOS configuration options for users with different technical backgrounds has become a technical problem that needs to be solved.

[0081] The BIOS configuration option modification method presented in this application, compared to existing methods that rely on fixed parsing logic and preset operation modes combined with professional assistance, achieves semantic association and integration of scattered configuration data through rule-based file-driven heterogeneous file parsing. It also achieves precise matching and location of natural language commands to configuration options through a global knowledge graph, and realizes efficient modification execution of configuration options through automated processing of modification information. This method improves the efficiency and reliability of BIOS configuration option modification, enabling intelligent management of BIOS configuration options for users with different technical backgrounds.

[0082] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0083] Figure 1 A flowchart illustrating a method for modifying BIOS configuration options provided in this application. Figure 1 ,like Figure 1 As shown, the method includes:

[0084] S101. Obtain the rule file and heterogeneous file; wherein, the rule file is maintained by the first user, and the heterogeneous file represents the BIOS configuration definition data;

[0085] S102. Based on the rule file, parse the heterogeneous files to determine the global knowledge graph; wherein, the global knowledge graph represents the semantic relationships of the BIOS configuration options;

[0086] S103. Upon determining that a modification instruction from the second user has been received, the modification information of the target configuration option is determined based on the modification instruction and the global knowledge graph. The modification instruction represents natural language text, the target configuration option represents the configuration option in the global knowledge graph that matches the modification instruction, and the modification information represents the modification parameters for implementing the modification of the target configuration option.

[0087] S104. Based on the modification information, modify the target configuration options to obtain the processing result; wherein, the processing result represents the completion status of the modification of the target configuration options.

[0088] The executing entity of this application can be a configuration processing program deployed on a local workstation, a configuration management system deployed on a server, or other devices capable of implementing the method of this application.

[0089] In step S101, the rule file can be written and maintained by the first user according to the BIOS architecture specifications and parsing requirements. Its content may include heterogeneous file parsing rules, architecture knowledge, etc., to provide a rule basis for subsequent parsing of heterogeneous files, ensuring that the parsing logic executes according to preset rules. Specifically, the first user can refer to developers, firmware engineers, or platform configuration maintenance personnel involved in BIOS configuration system maintenance. Their maintenance activities specifically involve adding, deleting, or revising parsing rules or related rules in the rule file.

[0090] Heterogeneous files can refer to a collection of files in the BIOS source code that store configuration definition data in different formats. As input data for the method of this application, their contents can be distributed across multiple directories, multiple project folders, or multiple version packages.

[0091] In practice, the executing entity first responds to a preset task (such as a scheduled synchronization task) or a manually triggered instruction (such as an interface operation instruction used to initiate a parsing process), loads a rule file from a preset storage location, and the rule file can be saved in a structured text format and includes information such as file type identifier (used to distinguish heterogeneous files of different formats), field extraction expressions (such as regular expression patterns), naming mapping relationships (such as camelCase naming splitting rules or abbreviation lookup tables), association key definitions (such as association rules between variable identifiers and platform configuration database names), and exception handling conditions (such as rollback strategies or log recording rules when parsing fails).

[0092] In one possible implementation, the rules file may include, but is not limited to, the following rules:

[0093] Rule 1: Define the responsibilities and association mechanisms of the data layer, control layer, string layer, and form layer; for example, the data layer is responsible for storing the default values ​​and attribute definitions of the options, the control layer is responsible for describing the interface presentation and interactive behavior of the options, the string layer is responsible for managing the display text and localized resources of the options, and the form layer is responsible for organizing the page layout and navigation structure of the options. The layers are referenced and bound across layers through preset association keys (such as variable identifiers).

[0094] Rule 2: Configurable regular expression styles for parsing heterogeneous files; for example, configurable regular expression styles for heterogeneous files are represented as multiple register styles. Each register style drives the regular expression matching logic of the corresponding parser to extract register operation information from the source code file. Specifically, each register style supports the extraction of operation elements such as register type and context keywords.

[0095] Rule 3: Clarify the rule modification methods for scenarios of architectural changes; for example, when the BIOS architecture changes (e.g., adding a new type of heterogeneous file format or adjusting the option naming convention), the rule modification methods may include: adding parsing rule entries for the corresponding file type in the rule file, updating the naming mapping relationship to adapt to the new naming convention, revising the association key definition to match the new cross-layer reference mechanism, and marking the old rules as obsolete to retain historical compatibility, so that the parsing capability can be dynamically expanded without modifying the main program code of the parser.

[0096] At the same time, the executing entity can read heterogeneous files from the file set corresponding to the BIOS according to the current BIOS version to be processed, the target platform identifier, or the project path.

[0097] It should be understood that the rule file serves as a guide for the parsing process. Its configurability decouples the parsing logic from the program code. First, users can adapt to different BIOS architecture versions or platform differences by maintaining the rule file without recompiling or modifying the parser program, thereby reducing maintenance costs and improving system scalability.

[0098] In step S102, the global knowledge graph can refer to a data structure that organizes BIOS configuration options (which can be simply referred to as options) and their relationships in the form of a graph structure. It contains multiple types of nodes and the edges between nodes, and is used to uniformly represent the scattered definitions of BIOS configuration options in multiple heterogeneous files and their semantic relationships.

[0099] In practice, heterogeneous files are parsed according to the rule file to determine the global knowledge graph. This can be done by first determining the parser corresponding to each heterogeneous file based on the file type identifier in the rule file, and then using the preset parser to parse each type of heterogeneous file, extracting various nodes and their attribute information to form a node set; secondly, based on the association key definition in the rule file, analyzing the semantic relationships between nodes in the node set to determine the associated edges between nodes, forming an edge set; then, constructing graph structure data based on the node set and edge set; and finally, optimizing the storage and establishing an index for the graph structure data to determine the global knowledge graph.

[0100] It should be understood that the default parser can extract structured data from heterogeneous files of the corresponding format based on the regular expression styles and field extraction expressions configured in the rule file. Its parsing logic is driven by the rule file rather than being embedded in the program code, so that the first user can adapt to new file formats or revise parsing rules by maintaining the rule file.

[0101] It is understandable that the construction of a global knowledge graph realizes the transition from scattered file-level storage to unified semantic-level association, so that the retrieval and location of BIOS configuration options no longer depends on understanding and manually associating various heterogeneous file formats one by one, but can be carried out through efficient semantic traversal and association reasoning based on the graph structure.

[0102] In step S103, the second user can refer to a user who interacts with the system through natural language to request modifications to BIOS configuration options. Their technical background can range from professional developers to non-professional system administrators, and they do not need professional knowledge of BIOS source code structure or register operations to initiate configuration modification requests. It is understood that the first user can be the second user, but the second user is not necessarily the first user.

[0103] Modification commands can refer to configuration option modification requests entered by a second user in natural language text form, such as "configure cppc to 0 and deploy to 10.55.27.11", etc. Their content can include operation intent (such as enabling, disabling, setting values, etc.), target parameter values ​​(such as 0, 1, etc.).

[0104] The target configuration option can refer to a BIOS configuration option in the global knowledge graph that matches the semantic content of the modification command. There can be one or more target configuration options, and when multiple candidates exist, confirmation can be obtained by sending a decision request to a second user.

[0105] Modification information can refer to the complete set of information required to drive parameter changes of the target configuration options. It may include, but is not limited to, the target parameter value (i.e., the changed configuration value), the execution strategy (e.g., directly modifying the default value of the source code or modifying firmware variables through remote connection), and the verification rules (e.g., comparing the values ​​before and after the modification, confirming the effective scope, etc.).

[0106] Modifying parameters can refer to modifying the data in the information used to specifically execute parameter changes, such as target parameter values, source code file paths, etc. It should be understood that different modification instructions correspond to different modification parameters.

[0107] In practice, the process of using a large language model to determine the modification information of the target configuration option can include the following sub-steps: First, input the modification command into the large language model for intent recognition to determine the user's operation intent type (e.g., query, modification, etc.); if the intent type is modification, extract keywords from the modification command (e.g., function description, parameter value, etc.); second, search the global knowledge graph based on the keywords to obtain multiple candidate option sets; then, use the large language model to perform reasoning processing on the candidate option sets to determine the target configuration option, and generate modification information containing the modification parameters based on the association information of the target configuration option in the global knowledge graph (e.g., current parameter value, associated register, platform constraints, etc.).

[0108] A large language model can refer to an artificial intelligence model with natural language understanding and generation capabilities. For example, the large language model in this application can be pre-trained based on BIOS configuration domain corpus, and its functions can include intent recognition, semantic matching, reasoning and ranking, and text generation. The large language model can be deployed on a local server or call remote services via a network interface. Its input can include modification command text, relevant subgraphs or node attribute information from the global knowledge graph, and its output can include intent type, a candidate set of target configuration options, and modification information.

[0109] In step S104, the modification process can refer to the operation of changing the parameters of the target configuration option based on the modification information.

[0110] The processing result can refer to the status information reached after the target configuration option has been modified. For example, the processing result may include parameter change status (e.g., change successful, change failed, etc.), modification timestamp, modification record identifier, and verification result.

[0111] In practice, the target configuration option is modified based on the modification information to obtain the processing result. This can be done as follows: First, the modification information is parsed to extract the target parameter value and the location information of the target configuration option. Second, based on the location information, the configuration data storage location corresponding to the target configuration option is accessed. Then, the current parameter value is updated to the target parameter value. Third, a verification operation is performed, such as reading back the updated parameter value or comparing the state differences before and after the update. Finally, the processing result is generated, and the parameter change status and verification result are recorded.

[0112] It should be understood that the specific implementation method of the modification process can be configured according to the actual application scenario. For example, it can be globally effective by modifying the default value field in the BIOS source code, or it can be single-machine effective by modifying the firmware variables of the target machine. The specific execution strategy is determined by the modification path type in the modification information, and this embodiment does not make specific limitations on this.

[0113] This embodiment provides a method for modifying BIOS configuration options. Through the parsing and processing of heterogeneous files driven by rule files, it achieves semantic association and integration of scattered configuration data. Through a global knowledge graph, it achieves precise matching and location of natural language commands to configuration options. Through automated processing of modification information, it achieves efficient execution of configuration option modifications. This method improves the efficiency and reliability of BIOS configuration option modification, enabling intelligent management of BIOS configuration options for users with different technical backgrounds.

[0114] Figure 2 A flowchart illustrating a method for modifying BIOS configuration options provided in this application. Figure 2 , Figure 2 Implementation examples in Figure 1 Based on the examples, the method for modifying BIOS configuration options is described in detail, such as... Figure 2 As shown, the method includes:

[0115] S201. Obtain the rule file and heterogeneous file; wherein, the rule file is maintained by the first user, and the heterogeneous file represents the BIOS configuration definition data.

[0116] The heterogeneous files include configuration definition files, interface description files, string resource files, platform description files, and source code files. The configuration definition file represents the attributes and definition descriptions of the BIOS configuration options; the interface description file represents the interface layout and navigation structure description of the BIOS configuration options; the string resource file represents the display text description of the BIOS configuration options; the platform description file represents the platform-related configuration descriptions of the BIOS configuration options; and the source code file represents the register operation logic descriptions of the BIOS configuration options.

[0117] Specifically, the configuration definition file can be in the ".sd" format. For example, the configuration definition file can be located and obtained by recognizing the file extension ".sd".

[0118] The interface description file can be in the format of ".vfr". For example, the interface description file can be located and obtained by recognizing the file extension ".vfr".

[0119] The string resource file can be in the ".uni" format. For example, the string resource file can be located and obtained by recognizing the file extension "uni".

[0120] The platform description file can be in the ".sdl" format. For example, the platform description file can be located and obtained by recognizing the file extension ".sdl".

[0121] The source code file can be in ".c" format. For example, the source code file can be located and obtained by recognizing the file extension ".c".

[0122] It is understandable that identifying files by their file extensions can accurately extract various heterogeneous files from a collection of files scattered across multiple directories, project folders, or version packages, providing a foundation of input data for subsequent parsing and processing.

[0123] S202. According to the rule file, the heterogeneous file is parsed using a preset parser to determine the node set and the attribute information of each node in the node set. The parsing logic of the preset parser satisfies the rules in the rule file. The node set includes option nodes, interface nodes, variable nodes, platform configuration nodes, callback nodes, and register nodes. Option nodes represent BIOS configuration options, interface nodes represent the interface of BIOS configuration options, variable nodes represent the storage variables of BIOS configuration options, platform configuration nodes represent the platform configuration parameters of BIOS configuration options, callback nodes represent the callback functions of BIOS configuration options, and register nodes represent the register operation items of BIOS configuration options.

[0124] In one possible implementation, the pre-defined parsers may include a configuration definition parser (which can be represented as SdParser), an interface description parser (which can be represented as VfrParser), a string resource parser (which can be represented as UniParser), a platform description parser (which can be represented as SdlParser), and a source code parser (which can be represented as CSourceParser). Each parser performs parallel parsing of heterogeneous files of the corresponding format based on the regular expression styles and field extraction expressions configured in the rule file.

[0125] For example, the configuration definition parser can parse the configuration definition file to extract attribute information such as option names, default values, and variable identifiers. Specifically, the configuration definition parser can extract relevant information such as option definitions (e.g., non-volatile random access memory (NVRAM) fields, control macros, control types, forms, and stored variables (varstore)).

[0126] The interface description parser can parse the interface description file to extract attribute information such as form definitions, question references, and navigation relationships. Specifically, the interface description parser can extract information such as stored variables (varstore), forms (form), and controls (controls, which support cross-line matching).

[0127] The string resource parser can parse string resource files to extract attribute information such as string identifiers, language codes, and display text. Specifically, the string resource parser can extract related information such as multilingual string tokens.

[0128] The platform description parser can parse the platform description file to extract attribute information such as platform conditions and platform configuration database (PCD) definitions. Specifically, the platform description parser can extract information such as multilingual string tokens and linkers (ELINK).

[0129] The source code parser can parse source code files to extract attribute information such as register read / write function calls and callback function definitions. Specifically, the source code parser can extract the platform configuration database (PCD) read (Get) items / set items, callback functions, and register operations (which can include 8 types of registers: memory-mapped I / O (MMIO) registers, input / output (IO) registers, model specific registers (MSR), system management network (SMN) registers, peripheral component interconnect (PCI) registers, hardware read-only (PCIE_STRAP) registers, graphics north bridge registers (GNB_REG), and system management unit (SMU) registers).

[0130] For example, for ease of understanding, Table 1 below gives the attribute information of each node obtained by each parser.

[0131] Table 1:

[0132]

[0133] It should be understood that the specific type and implementation of the preset parser can be configured according to the actual application scenario, as long as it can extract nodes and their attribute information from heterogeneous files of the corresponding format based on the parsing rules in the rule file. There are no restrictions on the specific name, number, or internal implementation logic of the preset parser.

[0134] S203. Determine the global knowledge graph based on the node set and the attribute information corresponding to at least one node in the node set.

[0135] Specifically, based on the association key definition in the rule file, the semantic association relationships between nodes in the node set can be analyzed. Based on the analysis results, the association edges between nodes can be determined to form an edge set. Furthermore, based on the node set and the edge set, graph structure data can be constructed to obtain a global knowledge graph.

[0136] It is understandable that by constructing a global knowledge graph that includes option nodes, interface nodes, variable nodes, platform configuration nodes, callback nodes, and register nodes, BIOS configuration definition data scattered across multiple heterogeneous files can be integrated into a unified semantic association network. This enables retrieval and reasoning based on semantic relationships, thereby improving the efficiency and reliability of modifying BIOS configuration options.

[0137] In an optional implementation, step S203 may include:

[0138] S2031. Determine the first type of edge based on the attribute information of the option nodes in the node set; wherein, the first type of edge represents the belonging relationship of the option node to the interface node.

[0139] In one possible implementation, the attribute information of the option node may include the form identifier (e.g., form_id). Based on the form identifier, the affiliation between the option node and the interface node containing the option can be determined, resulting in a first type of edge (which can be represented as option_in_form).

[0140] S2032. Determine the second type of edge based on the attribute information of the interface nodes in the node set; wherein, the second type of edge represents the interface jump relationship between interface nodes.

[0141] In one possible implementation, the attribute information of the interface node may include a jump target identifier (e.g., goto_targets[]). Based on the jump target identifier, the jump relationship between the current interface node and the target interface node can be determined, and the second type of edge (which can be represented as form_goto) can be obtained.

[0142] S2033. Based on the configuration definition file and the interface description file, determine the third type of edge; wherein, the third type of edge represents the reverse chain parent-child relationship between interface nodes.

[0143] In one possible implementation, the determination of the third type of edge can be based on the reverse chain algorithm, and step S2033 may include:

[0144] S2033a. Using a preset interface description parser, parse all form identifiers and corresponding jump target identifiers in the interface description file.

[0145] S2033b, Determine the boundaries of the form body.

[0146] The boundaries of the form body (which can be represented as form body) can refer to the start and end positions of a single form definition in the interface description file. The boundaries of the form body can be determined by identifying keywords related to the form definition (such as "form").

[0147] S2033c: Extract the jump target identifier inside the form body, determine the reference relationship between the referenced form and the referencing form, and establish the parent-child relationship between the forms.

[0148] The reference relationship can represent the hierarchical association formed when one form references another form through a jump operation (such as the goto statement). The referenced form is the child form, and the form that initiates the reference is the parent form.

[0149] S2033d: Traverse each option node, find the form node to which the option node belongs based on the form identifier of the option node, and establish the affiliation relationship between the option node and the form node.

[0150] S2033e: Using a preset configuration definition parser, parse the relationship between form sets and forms in the configuration definition file.

[0151] In this context, a form set (which can be represented as a formset) can refer to a collection structure containing multiple related forms, while a form (which can be represented as a form) can refer to a single independent configuration interface unit. The relationship between a form set and a form can characterize the organization and reference relationship of the form set to the individual forms it contains.

[0152] S2033f: Identify form-level fields using a preset depth counting recognition algorithm.

[0153] The preset depth counting recognition algorithm can refer to a traversal algorithm that starts from the top-level form set, recursively traverses each form and its sub-form references, and records the traversal depth count. The depth count represents the nesting level of the current form in the hierarchical structure; for example, the depth count of the top-level form is 0, the depth count of its directly referenced sub-forms is 1, and so on. Form hierarchy fields can be, for example, an Advanced field, a Main field, or a Server Management field.

[0154] S2033g: Reverse the parent-child relationship between forms to obtain the mapping relationship representing the child form to the parent form.

[0155] The reversal operation refers to converting the original reference relationship from parent form to child form into a traceback relationship from child form to parent form. Specifically, it involves iterating through the established set of parent-child relationships, generating corresponding key-value pairs from child form to parent form for each parent-child relationship, and storing them in a mapping relationship. The mapping relationship (which can be represented as `parent_map`) can be a dictionary or hash table structure, with the key being the child form identifier and the value being the parent form identifier, used to support fast backtracking queries from lower-level forms to upper-level forms.

[0156] S2033h, trace back along the mapping relationship from the form containing the options to the top-level form to obtain the third type of edge.

[0157] Among them, the third type of edge (which can be represented as form_parent) can represent the reverse chain parent-child relationship formed by starting from the option node, tracing upwards through its own form node along the parent_map to the top-level form node. This is used to support quickly locating the complete hierarchical path of any option in the BIOS settings interface.

[0158] For example, assuming the option node represents a CPC configuration item and its parent form node is SMU CommonOptions, tracing back along the parent_map reveals: the parent form of SMU Common Options is NBIO CommonOptions, the parent form of NBIO Common Options is AMD CBS, the parent form of AMD CBS is Advanced, and Advanced is the top-level form. Thus, the complete navigation path for this option node is determined to be Advanced, AMD CBS, NBIO Common Options, SMU Common Options, and CPC. The hierarchical relationships along this path constitute the third type of edge. For instance, when a second user queries "Where is CPC?" using natural language, the system can quickly return the aforementioned complete hierarchical path based on this third type of edge, assisting the second user in locating the target configuration option.

[0159] S2034. Based on the attribute information of the option nodes and the platform configuration nodes in the node set, determine the fourth type of edge; wherein, the fourth type of edge represents the association relationship between the option nodes and the platform configuration nodes.

[0160] In an optional implementation, the attribute information of the option node includes an option identifier (e.g., varid), and the attribute information of the platform configuration node includes a platform configuration name (e.g., PCD name); step S2034 may include:

[0161] S2034a. For each option node and each platform configuration node in the node set, based on the preset word segmentation algorithm, the option identifier and the platform configuration name are split and processed respectively to obtain the initial option word segmentation set corresponding to the option identifier and the initial platform configuration word segmentation set corresponding to the platform configuration name.

[0162] The preset word segmentation algorithm can be a splitting rule based on naming conventions (such as camelCase or underscore separation) to split continuous identifier strings into independent semantic units.

[0163] For example, the attribute value of varid is CbsCmnGnbSmuCppc, and the initial option segmentation set obtained after splitting includes Cbs, Cmn, Gnb, Smu, and Cppc; the attribute value of PCD name is PcdCfgCPPCMode, and the initial platform configuration segmentation set obtained after splitting includes Pcd, Cfg, CPPC, and Mode.

[0164] S2034b: Obtain a preset stop word set, and perform stop word filtering on the initial option word segmentation set and the initial platform configuration word segmentation set respectively to obtain the target option word segmentation set corresponding to the initial option word segmentation set and the target platform configuration word segmentation set corresponding to the initial platform configuration word segmentation set.

[0165] The preset stop word set can refer to a set of general words that do not contribute to semantic matching or have a low contribution. In one possible implementation, the preset stop word set is configured in a rules file. The first user can dynamically adjust the stop word set according to the actual application scenario or the naming convention differences of different BIOS architecture versions.

[0166] Stop word filtering can refer to removing words that belong to a stop word set. For example, the preset stop word set includes Cbs, Cmn, Gnb, Smu, Pcd, Cfg, and Mode; the initial option word segmentation set includes Cbs, Cmn, Gnb, Smu, and Cppc; after stop word filtering (filtering Cbs, Cmn, Gnb, and Smu), the target option word segmentation set includes Cppc; the initial platform configuration word segmentation set includes Pcd, Cfg, CPCC, and Mode; after stop word filtering (filtering Pcd, Cfg, and Mode), the target platform configuration word segmentation set CPCC is obtained.

[0167] S2034c. If it is determined that there is an intersection between the target option segmentation set and the target platform configuration segmentation set, then it is determined that there is an association between the option node corresponding to the option identifier and the platform configuration node corresponding to the platform configuration name, which is a fourth type of edge.

[0168] Intersection can refer to two sets containing the same elements.

[0169] In one possible implementation, determining the intersection between the target option word segmentation set and the target platform configuration word segmentation set can be achieved by performing a case-insensitive comparison between the two sets. If at least one element appears in both sets, then an intersection is determined to exist. For example, the target option word segmentation set includes `Cppc`, and the target platform configuration word segmentation set includes `CPPC`. After a case-insensitive comparison, `Cppc` and `CPPC` match successfully, indicating an intersection. This means there is a common element `CPPC`, and thus, a fourth type of edge (which can be represented as `option_pcd`) is determined to exist between the corresponding option node and the platform configuration node.

[0170] It is understandable that by determining the fourth type of edge based on word segmentation and stop word filtering, key semantic information can be extracted and matched when the naming conventions of the option identifier and the platform configuration name are inconsistent or different, thereby realizing the association between the option node and the platform configuration node and improving the recognition accuracy of the fourth type of edge.

[0171] S2035. Based on the source code file, determine the fifth type of edge and the sixth type of edge; wherein, the fifth type of edge represents the association between the platform configuration node and the callback node, and the sixth type of edge represents the association between the callback node and the register node.

[0172] In one possible implementation, a pre-defined source code parser can be used to parse the source code file and extract the callback function definitions and register operation information.

[0173] For the fifth type of edge, the callback function name referenced in the attribute information of the platform configuration node can be identified. If the callback function name matches the identifier of a callback node defined in the source code file (specifically, the value of the callback function reference field of the platform configuration node is completely consistent with the value of the function name field of the callback node, or consistent after normalization processing such as removing prefixes or suffixes), then it is determined that there is a fifth type edge (which can be represented as pcd_callback) between the platform configuration node and the callback node.

[0174] For the sixth type of edge, the register operation contained in the attribute information of the callback node can be identified. If the type identifier of the register operation matches the type identifier of a register node (specifically, the register operation function name extracted from the attribute information of the callback node corresponds to the register type field value of the register node (for example, the function name containing "Mmio" and the type field value "MMIO" are consistent after normalization to remove case differences)), then it is determined that there is a sixth type edge (which can be represented as callback_regop) between the callback node and the register node.

[0175] S2036. Based on the fourth, fifth, and sixth types of edges, determine the seventh type of edge; whereby the seventh type of edge represents the association between the option node and the register node.

[0176] Specifically, the seventh type of edge can be determined through graph traversal reasoning: if there exists a path from an option node via a fourth type edge (option_pcd) to the platform configuration node, then via a fifth type edge (pcd_callback) to the callback node, and finally via a sixth type edge (callback_regop) to the register node, then it is determined that a seventh type edge (which can be represented as option_regop) exists between the option node and the register node. It can be understood that this seventh type of edge represents the operation of the register that ultimately maps the configuration change of the option, realizing a full-link association from configuration options to underlying hardware operations.

[0177] S2037. Based on the attribute information of the option nodes in the node set and the seventh type of edge, determine the eighth type of edge; wherein, the eighth type of edge represents the cross-platform equivalence relationship between option nodes.

[0178] In an optional implementation, step S2037 may include:

[0179] S2037a, Obtain a cross-platform equivalent knowledge base; wherein, the cross-platform equivalent knowledge base represents the functional semantic correspondence of configuration options between different hardware platforms.

[0180] Specifically, the cross-platform equivalence knowledge base can be configured in a rules file and maintained and updated by the first user based on BIOS domain knowledge. The cross-platform equivalence knowledge base can contain mappings between function categories and function semantic keywords. For example, the function category "CPU performance enhancement function" can be mapped to the keyword set [Intel Turbo Boost, AMD CPB], the function category "multi-threaded synchronization function" can be mapped to the keyword set [Intel Hyper-Threading, AMD SMT], and the function category "CPU frequency management function" can be mapped to the keyword set [Intel Speed ​​Shift, AMD CPPC]. Each function category represents a type of cross-platform common hardware function, and the function semantic keywords are used to identify the configuration option names for implementing this function on different platforms.

[0181] S2037b. Based on the cross-platform equivalent knowledge base, determine the semantic fingerprint corresponding to each option node; wherein, the semantic fingerprint represents the functional semantic category identifier of the option node.

[0182] Specifically, for each option node in the node set, the option name and / or display text in its attribute information can be extracted and matched with functional semantic keywords in the cross-platform equivalent knowledge base. If the option name or display text matches at least one keyword of a certain functional category (specifically, the option name or display text, after normalization by removing case differences and delimiters, is the same as at least one keyword), then the semantic fingerprint of the option node is determined as the identifier of that functional category.

[0183] For example, if the name of the option node is “Turbo”, which matches the keyword “Intel Turbo Boost”, then its semantic fingerprint is determined to be “CPU performance enhancement function”; if the name of the option node is “CPB”, which matches the keyword “AMD CPB”, then its semantic fingerprint is also determined to be “CPU performance enhancement function”.

[0184] S2037c. Determine two different option nodes in the node set as the first option node and the second option node. If the semantic fingerprint of the first option node and the semantic fingerprint of the second option node are consistent, then determine that the first option node and the second option node satisfy the first condition.

[0185] Specifically, if the semantic fingerprint of the first option node is consistent with the semantic fingerprint of the second option node (specifically, the functional semantic category identifiers of the two option nodes are the same), then it is determined that the first option node and the second option node satisfy the first condition. The first condition indicates that the two option nodes belong to the same category at the functional semantic level, that is, they may implement the same or similar hardware functions.

[0186] However, the first condition only completes the initial screening. There may be options with the same functional category but different implementations on different platforms. Therefore, it is necessary to further verify through the second condition.

[0187] S2037d. Based on the seventh type of edge, determine the register node corresponding to the first option node as the first register node, and determine the register node corresponding to the second option node as the second register node.

[0188] S2037e, determine the operation set of the first register as the first operation set, and determine the operation set of the second register as the second operation set; wherein, the operation set represents the type of the register and the context keyword.

[0189] Specifically, for each register node, the register type and context keywords in its attribute information can be extracted to form the operational characteristics of that register node. The first set of operations can be the union of the operational characteristics of all register nodes in the first set of register nodes, and the second set of operations can be the union of the operational characteristics of all register nodes in the second set of register nodes.

[0190] S2037f: If the first operation set and the second operation set have an intersection, then the first option node and the second option node are determined to satisfy the second condition.

[0191] Specifically, intersection can refer to two sets of operations having the same register type or the same context keyword.

[0192] For example, the registers in the first operation set are of type {MSR} and the context keywords are {turbo,boost,performance}, while the registers in the second operation set are of type {SMU} and the context keywords are {cpb,performance,boost}. The elements of their intersection include {performance,boost}, indicating that the first operation set and the second operation set have an intersection, and it can be determined that the first option node and the second option node satisfy the second condition.

[0193] S2037g. If the first option node and the second option node satisfy the first condition and the second condition, then it is determined that there is a cross-platform equivalence relationship between the first option node and the second option node, which is the eighth type of edge.

[0194] Specifically, an eighth type edge can be determined to exist between the first option node and the second option node if both the first option node and the second option node satisfy the first condition and the second condition.

[0195] It is understandable that by unifying the semantic association of configuration options that are scattered and have different names on different hardware platforms, and obtaining the eighth type of edge, the portability and consistency of BIOS configuration options across different platforms can be improved.

[0196] S2038. Determine the first type of edge, the second type of edge, the third type of edge, the fourth type of edge, the fifth type of edge, the sixth type of edge, the seventh type of edge, and the eighth type of edge, and form an edge set.

[0197] S2039. Determine the global knowledge graph based on the set of nodes and the set of edges.

[0198] In one possible implementation, the various types of nodes in the node set and the various types of edges in the edge set can be organized into graph structure data, and the connection relationships between nodes can be stored using adjacency lists or adjacency matrices. Indexes can be created on the graph structure data (such as node identifier indexes, edge type indexes, attribute value indexes, etc.) to obtain a global knowledge graph to support efficient graph query operations.

[0199] For example, for ease of reading, Table 2 below provides a summary of the above eight types of edges.

[0200] Table 2:

[0201]

[0202] It is understandable that by constructing a global knowledge graph containing eight types of edges, the semantic relationships of BIOS configuration options in multiple dimensions such as interface affiliation, interface navigation, hierarchical structure, platform association, callback mapping, register operation, and cross-platform equivalence can be comprehensively represented, thereby supporting queries and reasoning based on multi-dimensional associations.

[0203] S204. Receive input information from the second user and use a large language model to determine the intent type corresponding to the input information; wherein, the input information represents natural language text.

[0204] Specifically, the second user can input natural language text through an interactive interface (such as a graphical interface or voice input interface), such as "disable Turbo Mode" or "configure cppc to 0 and deploy to 10.55.27.11". After receiving this input information, the executing entity inputs it into a preset large language model for intent recognition. The large language model identifies the operational intent in the input information through context analysis and determines the corresponding intent type.

[0205] For example, intent types may include, but are not limited to, query types (e.g., viewing details, including but not limited to option types, default values, optional values, menu paths, etc.), explanation types (e.g., explaining technical meaning), modification types (e.g., performing specific modification operations), re-filtering types (e.g., re-filtering options to switch query topics), navigation types (e.g., viewing navigation paths, displaying menu locations), and chat types (e.g., freely conversing with users about questions).

[0206] S205. If the intent type includes a modification type, then the input information is determined to be a modification instruction.

[0207] Specifically, when the large language model identifies the intent type as modification, the executing entity marks the received input information as a modification instruction and proceeds to the subsequent configuration option modification processing flow. Modification type indicates the user's intent to change BIOS configuration options, such as enabling, disabling, or setting parameter values.

[0208] For example, if the intent type is not a modification type (such as a query type), the executing entity can call the corresponding query processing module to return the query result without entering the modification process. The same applies to other intent types that are not modification types, which will not be elaborated here.

[0209] S206. Based on the modification instruction, determine the intent keywords; where the intent keywords represent the core operation object in the modification instruction.

[0210] In one possible implementation, a large language model can be used to segment and extract entities from the modification instructions, extracting the core operation objects (such as the name or function description of the target configuration option) and operation intentions (such as turning on, turning off, setting values, etc.).

[0211] For example, for the modification command "configure cppc to 0 and deploy to 10.55.27.11", the intent keyword can be determined to include the core operation object "cppc".

[0212] S207. Determine a set of candidate options based on the intent keywords and the global knowledge graph; wherein the set of candidate options represents at least one configuration option in the global knowledge graph that matches the intent keywords.

[0213] In an optional implementation, step S207 may include:

[0214] S2071. Based on the intent keywords, perform semantic retrieval processing on each configuration option in the global knowledge graph to determine the first option set; wherein, the configuration options in the first option set are semantically matched with the intent keywords.

[0215] Specifically, semantic retrieval processing can be based on a semantic similarity calculation model (such as a word embedding model or a semantic encoding model) to map the intent keywords and the attribute information of each option node in the global knowledge graph (such as option name, display text, function description, etc.) into semantic vectors, and calculate the similarity between the vectors.

[0216] For example, if the similarity exceeds a preset threshold (e.g., 0.75), the option node is determined to be semantically matched with the intent keyword and can be incorporated into the first option set. Alternatively, the top M (e.g., the top 10) option nodes are selected according to the similarity from high to low and determined as the first option set.

[0217] S2072. Based on the intent keywords, perform symbol retrieval processing on each configuration option in the global knowledge graph to determine the second option set; wherein, the configuration options in the second option set are fuzzy matched with the intent keywords on the symbol.

[0218] Specifically, symbol retrieval processing can be based on character-level matching algorithms to compare intent keywords with the identifiers of each option node.

[0219] For example, symbol retrieval processing can support fuzzy matching methods such as exact matching, prefix matching, suffix matching, and substring matching. For instance, if the intent keyword is "CPPC", symbol retrieval processing may match option nodes such as "CPPC" and "CPPCConfig".

[0220] For example, all the option nodes that are fuzzy matched are determined as the second option set.

[0221] S2073. Based on the intent keywords, perform graph query processing on the global knowledge graph to determine the third option set; wherein, the configuration options in the third option set have a structural relationship with the intent keywords in the global knowledge graph.

[0222] Specifically, graph query processing can be based on graph traversal algorithms to determine the node corresponding to the intent keyword (specifically, the option node, register node, or platform configuration node matching the intent keyword can be determined through symbol retrieval or semantic retrieval), and starting from the node, search for option nodes within a preset number of hops (e.g., within 10 hops) along the associated edges in the global knowledge graph to obtain the third option set.

[0223] S2074. Determine the candidate option set based on the first option set, the second option set, and the third option set.

[0224] In an optional implementation, step S2074 may include:

[0225] S2074a. Based on a preset sorting algorithm, sort and filter the first option set, the second option set, and the third option set to obtain the fourth option set.

[0226] The preset sorting algorithm can refer to an algorithm used to fuse multi-way retrieval results and generate a unified sorted option. For example, the preset sorting algorithm can be the Reciprocal Rank Fusion (RRF) algorithm.

[0227] For example, the ranking of each option in the first option set represents the position of the option in the semantic retrieval path after sorting by semantic similarity from high to low. The ranking of each option in the second option set represents the position of the option in the symbol retrieval path after sorting by symbol matching degree from high to low (symbol matching degree can be a preset relationship between matching type priority and character overlap, such as exact matching is preferred over prefix matching, prefix matching is preferred over substring matching, and the higher the character overlap under the same matching type, the higher the matching degree). The ranking of each option in the third option set represents the position of the option in the graph query path after sorting by structural association tightness (specifically, it can refer to the number of associated edges required to reach the option node from the node corresponding to the intent keyword, i.e., the number of hops; the fewer the hops, the higher the structural association tightness) from high to low.

[0228] For each option node that appears in at least one set of options, its RRF score is calculated. The RRF score can refer to the weighted sum of the inverse rankings in each retrieval path. For example, the RRF score can be:

[0229] ;

[0230] in, Indicates the RRF score. This indicates the rank of the option node in the semantic retrieval path. This indicates the rank of the option node in the symbol search path. This indicates the rank of the option node in the graph query path.

[0231] For example, the option nodes are sorted from high to low according to their RRF scores, and the top N (e.g., the top 60) option nodes are selected to obtain the fourth option set.

[0232] S2074b: Based on the cross-platform equivalent knowledge base and preset prompt words, the large language model is used to perform reasoning processing on the fourth option set to obtain a candidate option set; wherein, the preset prompt words are used to guide the large language model to perform cross-platform equivalent expansion and platform filtering processing on the fourth option set.

[0233] Specifically, the fourth option set, the cross-platform equivalent knowledge base, the current target platform identifier, and the preset prompt words can be assembled into an input context and submitted to the large language model for reasoning.

[0234] The preset prompts can include role definition (e.g., "You are a BIOS configuration expert"), task description (e.g., "Please perform cross-platform equivalence expansion on the following candidate options and filter out the options that match the target platform"), input format instructions (e.g., "The candidate option list is as follows, each line contains the option name, platform identifier, and current parameter value"), constraints (e.g., "Only retain platform configuration nodes that match the target platform identifier. If a candidate option belongs to another platform, please find its equivalent option through the cross-platform equivalence knowledge base and replace it"), and output format requirements (e.g., "Return the option name, platform identifier, and recommendation reason"), etc.

[0235] In one possible implementation, the large language model can also call the query interface of the global knowledge graph to obtain the associated context information of the candidate options (such as associated registers, the form path to which they belong, cross-platform equivalence relations, etc.) as an auxiliary basis for reasoning, so as to improve the accuracy of cross-platform equivalence expansion and platform filtering.

[0236] In one possible implementation, the large language model can also preprocess the fourth option set based on an intelligent pre-screening mechanism to improve inference efficiency and accuracy. Specifically, when the number of option nodes in the fourth option set exceeds a preset threshold (e.g., 1000), intelligent pre-screening can be performed: based on intent keywords and a cross-platform equivalent knowledge base, the relevance of each option node in the fourth option set is scored, and the nodes are sorted from high to low scores. The top K (e.g., the top 200) option nodes are then injected into the large language model for inference, avoiding the large language model from missing options or inference bias due to an excessive number of options.

[0237] The relevance scoring of each option node in the fourth option set can be achieved as follows: if the intent keyword matches the variable identifier (varid) of the option node, a first preset score (e.g., 10 points) is added; if the intent keyword matches the option name (name) of the option node, a second preset score (e.g., 5 points) is added; if the intent keyword matches a functional semantic keyword in a cross-platform equivalent knowledge base, and the option node also matches the same functional category, a third preset score (e.g., 8 points) is added. The pre-screening score of each option node is the sum of the scores of each condition met. The higher the score, the stronger the relevance between the option node and the intent keyword, and the higher it is injected into the large language model for inference.

[0238] For example, based on the above steps, a test was conducted. The test results showed that when a large codebase (including option 1132) was tested with "disable Turbo Mode", the response time of the large language model decreased from 41.4 seconds to 5.6 seconds, and the return result of the large language model changed from an empty list (missed selection) to correctly selecting the CPB option.

[0239] It is understandable that by using a large language model to perform secondary reasoning on the fourth option set after multi-way retrieval fusion, the candidate options can be further refined and expanded based on domain knowledge and cross-platform equivalence rules, making up for the shortcomings of ranking algorithms based solely on statistical scores, thereby improving the accuracy and platform adaptability of the candidate option set.

[0240] It is understandable that by integrating the results of semantic retrieval, symbol retrieval, and graph query to determine the set of candidate options, the user's search intent can be comprehensively covered from multiple dimensions such as semantic similarity, character matching degree, and structural relevance. This reduces the risk of missed detections in a single search method and thus improves the accuracy of configuration option positioning.

[0241] S208. Based on the candidate option set, a decision request is generated using a large language model and sent to the second user; wherein, the decision request represents a confirmation selection request for each configuration option in the candidate option set.

[0242] For example, a set of candidate options and preset decision prompts (such as "You are a BIOS configuration assistant. Please generate a user confirmation request based on the following candidate options, clearly displaying the key information of each option and guiding the user to select") can be input into a large language model, which will then generate a structured decision request.

[0243] The decision request may include, for example, detailed information about the candidate options (such as option name, platform, current parameter value, function description, etc.), selection prompts (such as "Please select the target configuration option you want to modify from the following options") and input format instructions (such as "Enter option number or option name").

[0244] Furthermore, the executing entity sends the generated decision request to the second user via an interactive interface, awaiting the second user's feedback. For example, the decision request could be displayed as: "The following candidate options were detected: 1. CPCC (AMD platform, current value: 1); 2. Speed ​​Shift (Intel platform, current value: 0). Please enter the option number or name you wish to modify."

[0245] S209. Receive the user's decision instruction; wherein the decision instruction includes the modification preference data of the target configuration option.

[0246] Specifically, after receiving the decision request, the second user can select the target configuration option according to their own needs, and input the modification preference data to form a decision instruction that is fed back to the executing entity.

[0247] The modification preference data can include the identification information of the target configuration option (such as option number, option name, or node identifier) ​​and the expected parameter change information (such as target parameter value, effective range preference, etc.). For example, if a second user enters "Select 1, set to 0", the target configuration option in the decision instruction will be "CPPC", and the modification preference data will include the target parameter value "0".

[0248] S210. Based on the decision instruction, determine the modification information for the target configuration options.

[0249] Specifically, the decision instruction is parsed to extract the identification information of the target configuration option and the modification preference data. Based on the identification information of the target configuration option, the corresponding target configuration option node is located in the global knowledge graph, and its current attribute information (such as current parameter values, associated registers, platform constraints, etc.) is obtained. Combined with the target parameter values ​​in the modification preference data, complete modification information is generated.

[0250] The modified information may include, for example, the node identifier of the target configuration option, the current parameter value, the target parameter value, the modification path type (e.g., code-level or machine-level, which can be system default or user-specified), and the associated verification rules. For example, if the decision instruction is "select 1, set to 0", then the determined modified information is: target configuration option "CPPC", current parameter value "1", target parameter value "0".

[0251] It is understandable that by establishing a multi-round interaction mechanism between the executing entity and the second user, the large language model generates decision requests and receives decision instructions from the second user, determines the target configuration options and their modification information, and can transform natural language input into structured configuration change instructions. This enables the transformation from vague intents to precise parameter modifications, improves the accuracy of configuration modifications, and avoids misoperations caused by misunderstandings of intents.

[0252] S211. Based on the modification information, modify the target configuration options to obtain the processing result; wherein, the processing result represents the completion status of the modification of the target configuration options.

[0253] In an optional implementation, step S211 may include:

[0254] S2111. Based on the modification information, generate a confirmation request and send the confirmation request to the second user; wherein, the confirmation request is used to prompt the second user to return the corresponding modification path information when determining to modify the target configuration option, the modification path information includes a first modification path and / or a second modification path, the first modification path indicates that the modification of the target configuration option is effective on multiple machines, the second modification path indicates that the modification of the target configuration option is effective on the current machine, and the machine is equipped with a BIOS.

[0255] For example, the confirmation request may include a comparison of the current and target parameter values ​​of the target configuration option, an explanation of the impact scope of each modification path, and a risk warning. For instance, the confirmation request could be displayed as: "CPPC is about to be modified. Its current value is 1, and the target value is 0. Please select the scope of application: 1. Code-level modification (applies to all machines); 2. Machine-level modification (applies only to the current machine). Please enter the option number."

[0256] S2112. Receive the user's confirmation command, determine the path modification information from the confirmation command, and modify the path for the target.

[0257] Specifically, after receiving the confirmation request, the second user selects the first modification path and / or the second modification path according to their needs, generating a confirmation instruction that is then sent back to the executing entity. The executing entity parses the confirmation instruction and extracts the target modification path information. For example, if the second user inputs "2", the target modification path is determined to be the second modification path (machine-level modification).

[0258] S2113. Determine the tool corresponding to the target modification path from the preset tool library, which is the target tool; wherein, the preset tool library is used to store the execution tools corresponding to different modification paths.

[0259] For example, the preset tool library may include a source code editing tool (e.g., a text editor) corresponding to the first modification path and a remote connection tool (e.g., a system configuration environment tool) corresponding to the second modification path. Based on the type of the target modification path, the corresponding tool is matched and invoked from the tool library. For example, if the target modification path is the first modification path, the target tool is determined to be a source code editing tool; if it is the second modification path, the target tool is determined to be a system configuration environment tool.

[0260] S2114. Based on the modification information and target tool, modify the target configuration options to obtain the processing result.

[0261] Specifically, based on the target parameter values ​​and target tools in the modification information, the actual parameter change operation is performed.

[0262] In one possible implementation, if the target modification path is the first modification path, the default value field corresponding to the target configuration option in the BIOS source code is located using a source code editing tool, the current value is updated to the target parameter value, and the version change information is recorded. If the target modification path is the second modification path, a secure connection is established with the target machine using a remote connection tool, and the corresponding parameter value in the target machine firmware variable is modified by calling the system configuration environment tool. Further, after the modification is completed, a verification operation is performed (e.g., readback confirmation or compilation comparison), the processing result is generated, and the parameter change status and effective scope are recorded.

[0263] It should be understood that the specific type and implementation method of the target tool can be configured according to the actual application scenario, as long as it can support the parameter change operation of the corresponding modified path. There are no restrictions on the specific name, version and internal implementation logic of the target tool.

[0264] It is understandable that by providing two modification paths—code-level and machine-level—for a second user to choose from, and matching the corresponding execution tools to complete the modification process, the configuration change requirements in different scenarios can be met, thereby improving the flexibility and scenario adaptability of BIOS configuration modification.

[0265] In this embodiment, based on the above embodiments, on the one hand, a preset parser is used to parse heterogeneous files and construct a global knowledge graph containing multiple types of nodes and associated edges to solve the problem that BIOS configuration options are scattered in multiple heterogeneous files, making it difficult to completely associate options with underlying definitions; on the other hand, a candidate option set is determined by fusing semantic retrieval, symbol retrieval, and graph query to further solve the problem of insufficient positioning accuracy caused by missed detections or mismatches in a single retrieval method; furthermore, through a multi-round interaction mechanism between the execution subject and the second user (including the generation of decision requests, the receipt of user decision instructions, and the confirmation of modification paths), natural language input is converted into structured configuration change instructions to solve the problem that the threshold for non-professional users to directly operate source code or firmware variables is too high; thereby improving the efficiency of BIOS configuration option positioning and the accuracy of identification or modification.

[0266] Figure 3 A flowchart illustrating an interaction method driven by a large language model, as provided in this application. Figure 3 The example illustrates the interaction between the large language model and the second user in the aforementioned examples, such as... Figure 3 As shown, the method includes:

[0267] S301, Receive user natural language input.

[0268] Here, the user is the second user, and the natural language input is the input information of the aforementioned second user, which represents natural language text.

[0269] S302, an intent understanding engine that injects a global knowledge graph, a cross-platform equivalent knowledge base, and prompt word engineering to guide the large language model.

[0270] Among them, the global knowledge graph and cross-platform equivalent knowledge base are shown in [link to relevant documentation]. Figure 2 The steps of the embodiments will not be repeated here.

[0271] The prompt word engineering guided representation standardizes and constrains the input and output of the large language model through preset prompt word templates. This is used to clarify the task objectives, input format, constraints and output requirements, and guide the large language model to generate the expected response.

[0272] S303. The large language model is used to determine the intent type.

[0273] The intent type can include, but is not limited to, query type (e.g., viewing detailed information, including but not limited to option type, default value, optional value, menu path, etc.), explanation type (e.g., explaining technical meaning), modification type (e.g., performing specific modification operations), re-filter type (e.g., re-filtering options to switch query topics), navigation type (e.g., viewing navigation path, displaying menu location), and chat type (e.g., freely conversing with users about questions).

[0274] S304. Perform the operation corresponding to the intent type and return the corresponding result.

[0275] For example, when the natural language input is "see the details of cppc", the large language model determines that the intent type is query type and displays the complete information in the knowledge graph (type / default value / optional value / menu path).

[0276] For a natural language input of "What does the first option mean?", the big language model determines the intent type as the explanation type, displays details, and provides the big language model's explanation of the option's meaning and system impact.

[0277] If the natural language input is "modify the first option" or "deploy to 10.55.27.11 with cppc set to 0", then after confirming with the user, code-level and / or machine-level modifications will be performed.

[0278] If the natural language input is "switch memory-related options", then step S303 is executed again to allow the large language model to filter options with new intents;

[0279] For natural language input "Which part of the menu", display the menu navigation path of the options;

[0280] For any other question as natural language input, perform free dialogue with a large language model to provide a response.

[0281] S305. Determine whether the user wants to continue inputting.

[0282] S306. If the user continues to input, proceed to step S303.

[0283] S307. If the user does not continue to input, the interaction ends.

[0284] In this case, if the second user actively sends a command to end the session (such as "end"), or if the system detects a session timeout or connection interruption, it indicates that the user has not continued to input.

[0285] The interaction method based on a large language model provided in this embodiment further explains the interaction between the user and the large language model, enabling the second user to engage in multi-turn dialogues with the system using everyday language, gradually clarifying their needs and obtaining precise configuration options. This reduces the professional threshold for BIOS configuration management and improves the flexibility of interaction and user experience.

[0286] Figure 4 A flowchart illustrating a method for modifying BIOS configuration options provided in this application. Figure 3 , Figure 4 Based on the foregoing embodiments, this example provides another way to illustrate the method for modifying BIOS configuration options, such as... Figure 4 As shown, the method includes:

[0287] S401, Load the rule file.

[0288] For example, load the four-layer separation architecture parsing rules from config / hii_architecture_rules.json.

[0289] S402. Based on the rules in the rule file and a preset parser, parse the heterogeneous files and construct a global knowledge graph.

[0290] For example, step S402 includes:

[0291] S4021, Original Node Construction: The output of the preset parser (including configuration definition parser, interface description parser, string resource parser, platform description parser and source code parser) is mapped to 6 types of nodes (Option / Form / VarStore / PCD / Callback / RegisterOp), and a direct edge between option_in_form and form_goto is established;

[0292] S4022, Navigation path derivation: Derivation of the form_parent edge from the form_goto edge (see step S2033) to achieve 100% navigation path coverage;

[0293] S4023, Semantic Association Establishment: PCD core word intersection matching to establish option_pcd edge; trace the transit path from PCD node to Callback node to RegisterOp node, and establish pcd_callback / callback_regop / option_regop edge;

[0294] S4024, Cross-platform equivalence extension: Based on two-layer equivalence mapping, establish cross_platform_equiv edges.

[0295] S4025. Based on the above types of nodes and edges, a global knowledge graph is constructed.

[0296] S403. The large language model performs intent recognition on natural language text, determines the intent type, and returns the corresponding set of options.

[0297] S404, a large language model, enables completely free interaction between the user and the system.

[0298] The input information for fully free interaction can be, for example, "See the detailed information of CPCC", "What does the first option mean", "Modify the first option", "Deploy CPCC to 0 to 10.55.27.11", etc. The large language model returns the corresponding response text based on the input information.

[0299] For example, when a user asks "What does the first option mean?", the large language model recognizes it as an explanatory intent and displays details and explanations; when a user asks "See details", the large language model recognizes it as a query type and displays complete information (e.g., option type: oneof, current default value: 1, possible values: value=0: Disabled or value=1: Enabled, menu path: Advanced to AMD CBS to NBIO to SMU to CPPC); when a user enters "Modify the first option", the large language model recognizes it as a modification type, confirms it, and performs code-level modifications; when a user enters "Deploy to 10.55.27.11", the large language model recognizes it as a modification type, extracts the relevant Internet Protocol (IP) address, and performs remote modifications.

[0300] In one possible implementation, for code-level modifications, the steps could be as follows: move OPTION_DEFAULT (before modification, value=0 was OPTION_DEFAULT; after modification, value=1 was OPTION_DEFAULT); for machine-level modifications, the steps could be as follows: establish a Secure Shell connection to 10.55.27.11, upload SCELNX_64, export mapstring, modify NVRAM, perform a BMC IPMI reboot, and then verify.

[0301] It should be understood that the specific steps for code-level and machine-level modifications described above are merely examples for ease of understanding. The specific implementation methods can be configured according to the actual application scenario, and the specific implementation details of the modification path are not limited here.

[0302] S405, Result Verification.

[0303] For example, the result verification characterizing the recognition of the above intent types can specifically be: cross-platform equivalence recognition verification: the user inputs the Intel term "disable Turbo Mode", and the large language model recognizes it as the AMD CPB option (CbsCmnCpuCpb) based on the cross-platform equivalence knowledge base, with a response time of 5.6 seconds; knowledge graph construction verification (e.g., AMD Venice, option 1132): PCD association rate 85.1% (963 / 1132), register association rate 72.9% (825 / 1132), cross-platform equivalence 305 / 1132.

[0304] It is understood that this embodiment, based on the foregoing embodiments, further illustrates the method for modifying BIOS configuration options, thereby improving the efficiency and reliability of modifying BIOS configuration options.

[0305] Figure 5 A schematic diagram of a BIOS configuration option modification device provided in this application is shown below. Figure 5 As shown, the BIOS configuration option modification device 50 includes: a file acquisition module 501, a graph determination module 502, an information determination module 503, and an option modification module 504.

[0306] The file acquisition module 501 is used to acquire rule files and heterogeneous files; wherein, the rule files are maintained by the first user, and the heterogeneous files represent BIOS configuration definition data;

[0307] The knowledge graph determination module 502 is used to parse and process heterogeneous files according to the rule file to determine the global knowledge graph; wherein, the global knowledge graph represents the semantic relationship of BIOS configuration options;

[0308] The information determination module 503 is used to determine the modification information of the target configuration option based on the modification instruction and the global knowledge graph when it is determined that a modification instruction from the second user has been received; wherein, the modification instruction represents natural language text, the target configuration option represents the configuration option in the global knowledge graph that matches the modification instruction, and the modification information represents the modification parameters for implementing the modification of the target configuration option;

[0309] The option modification module 504 is used to modify the target configuration option according to the modification information and obtain the processing result; wherein, the processing result represents the completion status of the modification of the target configuration option.

[0310] In an optional example, the heterogeneous files include configuration definition files, interface description files, string resource files, platform description files, and source code files; wherein, the configuration definition file represents the attributes and definition descriptions of the BIOS configuration options, the interface description file represents the interface layout and navigation structure description of the BIOS configuration options, the string resource file represents the display text description of the BIOS configuration options, the platform description file represents the platform-related configuration descriptions of the BIOS configuration options, and the source code file represents the register operation logic descriptions of the BIOS configuration options.

[0311] In an optional example, the map determination module 502 is also used for:

[0312] Based on the rule file, a pre-defined parser is used to parse heterogeneous files, determining the node set and the attribute information of each node in the node set. The parsing logic of the pre-defined parser satisfies the rules in the rule file. The node set includes option nodes, interface nodes, variable nodes, platform configuration nodes, callback nodes, and register nodes. Option nodes represent BIOS configuration options, interface nodes represent the interface of BIOS configuration options, variable nodes represent the stored variables of BIOS configuration options, platform configuration nodes represent the platform configuration parameters of BIOS configuration options, callback nodes represent the callback functions of BIOS configuration options, and register nodes represent the register operations of BIOS configuration options. A global knowledge graph is determined based on the node set and the attribute information corresponding to at least one node in the node set.

[0313] In an optional example, the map determination module 502 is also specifically used for:

[0314] Based on the attribute information of the option nodes in the node set, determine the first type of edges; where the first type of edges represents the affiliation relationship of the option nodes to the interface nodes. Based on the attribute information of the interface nodes in the node set, determine the second type of edges; where the second type of edges represents the interface navigation relationship between interface nodes. Based on the configuration definition file and the interface description file, determine the third type of edges; where the third type of edges represents the reverse chain parent-child relationship between interface nodes. Based on the attribute information of the option nodes and the platform configuration nodes in the node set, determine the fourth type of edges; where the fourth type of edges represents the association relationship between option nodes and platform configuration nodes. Based on the source code file, determine the fifth type of edges and... The sixth type of edge is defined; where the fifth type of edge represents the association between platform configuration nodes and callback nodes, and the sixth type of edge represents the association between callback nodes and register nodes; based on the fourth, fifth, and sixth types of edges, the seventh type of edge is determined; where the seventh type of edge represents the association between option nodes and register nodes; based on the attribute information of option nodes in the node set and the seventh type of edge, the eighth type of edge is determined; where the eighth type of edge represents the cross-platform equivalence relationship between option nodes; the first, second, third, fourth, fifth, sixth, seventh, and eighth types of edges are determined as the edge set; based on the node set and the edge set, the global knowledge graph is determined.

[0315] In an optional example, the attribute information of the option node includes the option identifier, and the attribute information of the platform configuration node includes the platform configuration name; the graph determination module 502 is also specifically used for:

[0316] For each option node and each platform configuration node in the node set, based on a preset word segmentation algorithm, the option identifier and the platform configuration name are split into initial option word segments corresponding to the option identifier and initial platform configuration word segments corresponding to the platform configuration name. A preset stop word set is obtained, and the initial option word segments and the initial platform configuration word segments are filtered by stop words to obtain the target option word segments corresponding to the initial option word segments and the target platform configuration word segments corresponding to the initial platform configuration word segments. If it is determined that there is an intersection between the target option word segments and the target platform configuration word segments, then it is determined that there is an association between the option node corresponding to the option identifier and the platform configuration node corresponding to the platform configuration name, which is a fourth type of edge.

[0317] In an optional example, the map determination module 502 is also specifically used for:

[0318] Obtain a cross-platform equivalence knowledge base; where the cross-platform equivalence knowledge base represents the functional semantic correspondence of configuration options across different hardware platforms; based on the cross-platform equivalence knowledge base, determine the semantic fingerprint corresponding to each option node; where the semantic fingerprint represents the functional semantic category identifier of the option node; determine two different option nodes in the node set as the first option node and the second option node. If the semantic fingerprint of the first option node and the semantic fingerprint of the second option node are consistent, then the first option node and the second option node satisfy the first condition; based on the seventh type of edge, determine the register node corresponding to the first option node as the first register node, and determine the register node corresponding to the second option node as the second register node; determine the operation set of the first register as the first operation set, and determine the operation set of the second register as the second operation set; where the operation set represents the type and context keywords of the register; if the first operation set and the second operation set have an intersection, then the first option node and the second option node satisfy the second condition; if the first option node and the second option node satisfy the first condition and the second condition, then a cross-platform equivalence relationship exists between the first option node and the second option node, which is the eighth type of edge.

[0319] In an optional example, the information determination module 503 is also used for:

[0320] The system receives input information from a second user and uses a large language model to determine the intent type corresponding to the input information; where the input information represents natural language text; if the intent type includes a modification type, the input information is determined to be a modification instruction; based on the modification instruction, intent keywords are determined; where the intent keywords represent the core operation object in the modification instruction; based on the intent keywords and the global knowledge graph, a set of candidate options is determined; where the set of candidate options represents at least one configuration option in the global knowledge graph that matches the intent keywords; based on the set of candidate options, a decision request is generated using the large language model and sent to the second user; where the decision request represents a confirmation selection request for each configuration option in the set of candidate options; the system receives the user's decision instruction; where the decision instruction includes modification preference data for the target configuration option; based on the decision instruction, the modification information for the target configuration option is determined.

[0321] In an optional example, the information determination module 503 is also specifically used for:

[0322] Based on the intent keywords, semantic retrieval processing is performed on each configuration option in the global knowledge graph to determine the first option set; wherein the configuration options in the first option set are semantically matched with the intent keywords. Based on the intent keywords, symbolic retrieval processing is performed on each configuration option in the global knowledge graph to determine the second option set; wherein the configuration options in the second option set are symbolically fuzzy matched with the intent keywords. Based on the intent keywords, graph query processing is performed on the global knowledge graph to determine the third option set; wherein the configuration options in the third option set have structural relationships with the intent keywords in the global knowledge graph. Based on the first option set, the second option set, and the third option set, a candidate option set is determined.

[0323] In an optional example, the information determination module 503 is also specifically used for:

[0324] Based on a pre-defined sorting algorithm, the first, second, and third option sets are sorted and filtered to obtain a fourth option set. Then, using a large language model, the fourth option set is reasoned based on a cross-platform equivalence knowledge base and pre-defined prompts to obtain a candidate option set. The pre-defined prompts guide the large language model to perform cross-platform equivalence expansion and platform filtering on the fourth option set.

[0325] In an optional example, option modification module 504 is also used for:

[0326] Based on the modification information, a confirmation request is generated and sent to the second user. This confirmation request prompts the second user to return the corresponding modification path information when confirming the modification of the target configuration option. The modification path information includes a first modification path and / or a second modification path. The first modification path indicates that the modification of the target configuration option applies to multiple machines, and the second modification path indicates that the modification of the target configuration option applies to the current machine, which has a BIOS. The system receives the user's confirmation command and determines the modification path information from the confirmation command, which is the target modification path. It then determines the tool corresponding to the target modification path from a preset tool library, which is the target tool. The preset tool library stores execution tools corresponding to different modification paths. Based on the modification information and the target tool, the target configuration option is modified to obtain the processing result.

[0327] The BIOS configuration option modification device in this embodiment can execute the technical solution in the above method. Its specific implementation process and technical principle are the same, and will not be described again here.

[0328] Figure 6 A schematic diagram of a BIOS configuration option modification system provided in this application is shown below. Figure 6As shown, the BIOS configuration option modification system 60 provided in this embodiment includes at least one processor 601 and a memory 602. Optionally, the BIOS configuration option modification system 60 further includes a communication component 603. The processor 601, memory 602, and communication component 603 are connected via a bus 604.

[0329] In a specific implementation, at least one processor 601 executes computer execution instructions stored in memory 602, causing at least one processor 601 to perform the above-described method.

[0330] The specific implementation process of processor 601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0331] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0332] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0333] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0334] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

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

[0336] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as magnetic disks or optical disks.

[0337] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for modifying BIOS configuration options, characterized in that, include: Obtain rule files and heterogeneous files; wherein the rule files are maintained by the first user, and the heterogeneous files represent BIOS configuration definition data; Based on the rule file, the heterogeneous files are parsed to determine a global knowledge graph; wherein, the global knowledge graph represents the semantic relationships of BIOS configuration options; Upon determining that a modification instruction from a second user has been received, modification information for the target configuration option is determined based on the modification instruction and the global knowledge graph; wherein, the modification instruction represents natural language text, the target configuration option represents a configuration option in the global knowledge graph that matches the modification instruction, and the modification information represents modification parameters for implementing the modification of the target configuration option; Based on the modification information, the target configuration option is modified to obtain a processing result; wherein, the processing result represents the completion status of the modification of the target configuration option.

2. The method according to claim 1, characterized in that, The heterogeneous files include configuration definition files, interface description files, string resource files, platform description files, and source code files; wherein, the configuration definition file represents the attributes and definition descriptions of the BIOS configuration options, the interface description file represents the interface layout and navigation structure description of the BIOS configuration options, the string resource file represents the display text description of the BIOS configuration options, the platform description file represents the platform-related configuration descriptions of the BIOS configuration options, and the source code file represents the register operation logic descriptions of the BIOS configuration options.

3. The method according to claim 2, characterized in that, The step of parsing the heterogeneous files according to the rule file to determine the global knowledge graph includes: According to the rule file, a preset parser is used to parse the heterogeneous file to determine the node set and the attribute information of each node in the node set; wherein, the parsing logic of the preset parser satisfies the rules in the rule file, the node set includes option nodes, interface nodes, variable nodes, platform configuration nodes, callback nodes, and register nodes, the option nodes represent the configuration options of the BIOS, the interface nodes represent the interface of the configuration options of the BIOS, the variable nodes represent the storage variables of the configuration options of the BIOS, the platform configuration nodes represent the platform configuration parameters of the configuration options of the BIOS, the callback nodes represent the callback functions of the configuration options of the BIOS, and the register nodes represent the register operation items of the configuration options of the BIOS. The global knowledge graph is determined based on the set of nodes and the attribute information corresponding to at least one node in the set of nodes.

4. The method according to claim 3, characterized in that, The step of determining the global knowledge graph based on the node set and attribute information corresponding to at least one node in the node set includes: Based on the attribute information of the option nodes in the node set, a first type of edge is determined; wherein, the first type of edge represents the belonging relationship of the option node to the interface node; Based on the attribute information of the interface nodes in the node set, a second type of edge is determined; wherein, the second type of edge represents the interface jump relationship between interface nodes; Based on the configuration definition file and the interface description file, a third type of edge is determined; wherein, the third type of edge represents the reverse chain parent-child relationship between interface nodes; Based on the attribute information of the option nodes in the node set and the attribute information of the platform configuration nodes, a fourth type of edge is determined; wherein, the fourth type of edge represents the association relationship between the option nodes and the platform configuration nodes; Based on the source code file, a fifth type of edge and a sixth type of edge are determined; wherein, the fifth type of edge represents the association between the platform configuration node and the callback node, and the sixth type of edge represents the association between the callback node and the register node; Based on the fourth type of edge, the fifth type of edge, and the sixth type of edge, a seventh type of edge is determined; wherein, the seventh type of edge represents the association relationship between the option node and the register node; Based on the attribute information of the option nodes in the node set and the seventh type of edge, an eighth type of edge is determined; wherein, the eighth type of edge represents the cross-platform equivalence relationship between option nodes; The first type of edge, the second type of edge, the third type of edge, the fourth type of edge, the fifth type of edge, the sixth type of edge, the seventh type of edge, and the eighth type of edge are determined to be the edge set; The global knowledge graph is determined based on the set of nodes and the set of edges.

5. The method according to claim 4, characterized in that, The attribute information of the option node includes an option identifier, and the attribute information of the platform configuration node includes a platform configuration name; determining the fourth type of edge based on the attribute information of the option nodes in the node set and the attribute information of the platform configuration node includes: For each option node and each platform configuration node in the node set, based on a preset word segmentation algorithm, the option identifier and the platform configuration name are split and processed to obtain the initial option word segmentation set corresponding to the option identifier and the initial platform configuration word segmentation set corresponding to the platform configuration name. Obtain a preset stop word set, and perform stop word filtering on the initial option word segmentation set and the initial platform configuration word segmentation set respectively to obtain the target option word segmentation set corresponding to the initial option word segmentation set and the target platform configuration word segmentation set corresponding to the initial platform configuration word segmentation set; If it is determined that there is an intersection between the target option segmentation set and the target platform configuration segmentation set, then it is determined that there is an association between the option node corresponding to the option identifier and the platform configuration node corresponding to the platform configuration name, which is the fourth type of edge.

6. The method according to claim 4, characterized in that, The step of determining the eighth type of edge based on the attribute information of the option nodes in the node set and the seventh type of edge includes: Obtain a cross-platform equivalent knowledge base; wherein, the cross-platform equivalent knowledge base represents the functional semantic correspondence of configuration options between different hardware platforms; Based on the cross-platform equivalent knowledge base, the semantic fingerprint corresponding to each option node is determined; wherein, the semantic fingerprint represents the functional semantic category identifier of the option node; Two distinct option nodes in the node set are identified as a first option node and a second option node. If the semantic fingerprint of the first option node and the semantic fingerprint of the second option node are consistent, then the first option node and the second option node are determined to satisfy the first condition. Based on the seventh type of edge, the register node corresponding to the first option node is determined as the first register node, and the register node corresponding to the second option node is determined as the second register node; The operation set of the first register is determined as a first operation set, and the operation set of the second register is determined as a second operation set; wherein, the operation set represents the type and context keyword of the register; If the first set of operations and the second set of operations intersect, then the first option node and the second option node are determined to satisfy the second condition; If the first option node and the second option node satisfy the first condition and the second condition, then it is determined that there is a cross-platform equivalence relationship between the first option node and the second option node, which is the eighth type of edge.

7. The method according to claim 1, characterized in that, Upon determining that a modification instruction from a second user has been received, the step of determining the modification information of the target configuration option based on the modification instruction and the global knowledge graph includes: The system receives input information from the second user and uses a large language model to determine the intent type corresponding to the input information; wherein the input information represents natural language text. If the intent type includes a modification type, then the input information is determined to be the modification instruction; Based on the modification instruction, determine the intent keywords; wherein, the intent keywords represent the core operation object in the modification instruction; Based on the intent keywords and the global knowledge graph, a set of candidate options is determined; wherein, the set of candidate options represents at least one configuration option in the global knowledge graph that matches the intent keywords; Based on the candidate option set, a decision request is generated using the large language model and sent to the second user; wherein, the decision request represents a confirmation selection request for each configuration option in the candidate option set; Receive user decision instructions; wherein, the decision instructions include modification preference data for the target configuration options; Based on the decision instruction, determine the modification information for the target configuration option.

8. The method according to claim 7, characterized in that, The step of determining the candidate option set based on the intent keywords and the global knowledge graph includes: Based on the intent keywords, semantic retrieval processing is performed on each configuration option in the global knowledge graph to determine a first option set; wherein, the configuration options in the first option set are semantically matched with the intent keywords; Based on the intent keywords, symbol retrieval processing is performed on each configuration option in the global knowledge graph to determine a second option set; wherein, the configuration options in the second option set are fuzzily matched with the intent keywords on a symbolic basis. Based on the intent keywords, a graph query is performed on the global knowledge graph to determine a third option set; wherein, the configuration options in the third option set and the intent keywords have a structural relationship in the global knowledge graph; The candidate option set is determined based on the first option set, the second option set, and the third option set.

9. The method according to claim 8, characterized in that, Determining the candidate option set based on the first option set, the second option set, and the third option set includes: Based on a preset sorting algorithm, the first option set, the second option set, and the third option set are sorted and filtered to obtain a fourth option set; Based on the cross-platform equivalent knowledge base and preset prompt words, the large language model is used to perform reasoning processing on the fourth option set to obtain the candidate option set; wherein, the preset prompt words are used to guide the large language model to perform cross-platform equivalent expansion and platform filtering processing on the fourth option set.

10. The method according to any one of claims 1-9, characterized in that, The step of modifying the target configuration option based on the modified information to obtain the processing result includes: Based on the modification information, a confirmation request is generated and sent to the second user; wherein, the confirmation request is used to prompt the second user to return the corresponding modification path information when it is determined to modify the target configuration option, the modification path information includes a first modification path and / or a second modification path, the first modification path indicates that the modification of the target configuration option is effective on multiple machines, and the second modification path indicates that the modification of the target configuration option is effective on the current machine, the machine having the BIOS deployed; Receive the user's confirmation instruction, determine the path modification information from the confirmation instruction, and modify the path for the target. The tool corresponding to the target modification path is determined from a preset tool library and is designated as the target tool; wherein, the preset tool library is used to store execution tools corresponding to different modification paths; Based on the modified information and the target tool, the target configuration options are modified to obtain the processing result.

11. A system for modifying BIOS configuration options, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-10.

Images