Instruction repairing method and device, equipment and medium

Abstract

The invention belongs to the field of artificial intelligence, and relates to an instruction repairing method and device, equipment and a medium, and the method comprises the steps: obtaining corresponding error information when it is detected that a tool calling instruction outputted by a large model in response to query information fails to be executed; and constructing a multi-dimensional retrieval query vector set based on the tool calling instruction, the query information and the error information. And retrieving the matching repair information in the mixed knowledge base. Determining an adaptive field constraint condition by combining an application scene corresponding to the query information, integrating the query information, the instruction, the error information, the repair information and the field constraint condition, generating a structured repair context, repairing a large model through a preset instruction, generating a corrected tool calling instruction, and executing the corrected tool calling instruction. The method can be applied to the business fields of financial science and technology, insurance, medical treatment and the like, and the instruction repairing efficiency can be improved.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology and is applied to online processing business scenarios such as fintech, insurance, and healthcare. In particular, it relates to an instruction repair method, device, equipment, and medium. Background Technology

[0002] In the current era of deep integration between artificial intelligence technology and various business systems, Large Language Models (LLMs), with their powerful natural language understanding and generation capabilities, have been widely applied in tool call command generation scenarios. They can accurately respond to various business query needs in key areas such as financial transaction processing and medical data interaction, becoming a core technical support connecting business needs and system execution. Regarding the issue of tool call command execution failures, the mainstream solution in the industry is a self-reflective retry mechanism based on LLMs. Its core implementation logic is as follows: after detecting a tool call command execution failure, the original query, the failed tool call command, and the corresponding error feedback information are simply concatenated to form a new prompt word, which is then re-entered into the same LLM. The model then generates a corrected tool call command based on its self-reflective capabilities to complete the fault repair.

[0003] However, this mainstream remediation mechanism has revealed many significant technical flaws in practical applications, especially in critical sectors such as finance and healthcare where compliance requirements are extremely high. Its limitations are even more pronounced, making it difficult to meet the needs of actual business scenarios. On the one hand, the general-purpose LLM does not fully integrate domain-specific compliance strategies, leading to generated remediation commands that easily violate industry technical specifications or relevant laws and regulations, resulting in insufficient compliance adaptability. On the other hand, for complex types of tool call errors such as context semantic mismatches, missing permission configurations, and parameter logic conflicts, relying solely on repeated retries is insufficient for accurately locating the root cause of the fault and efficiently remediating it. This not only results in a low success rate but may also trigger a chain reaction of problems such as business interruptions and data anomalies due to multiple retries exceeding the scope of the service level agreement. Summary of the Invention

[0004] The purpose of this application is to provide an instruction repair method, apparatus, computer device, and storage medium to solve the problems of poor compliance and adaptability, low success rate of complex error repair, and insufficient repair efficiency in existing tool error repair mechanisms.

[0005] Firstly, a method for repairing instructions is provided, which employs the following technical solution: When a tool invocation command corresponding to the query information fails to execute, the error information corresponding to the tool invocation command is obtained. The tool invocation command is the execution command output by the large language model in response to the query information. Based on the tool invocation command, query information, and error information, a multi-dimensional retrieval query vector set is constructed. Based on the multi-dimensional retrieval query vector set, a retrieval operation is performed in the hybrid knowledge base to obtain matching repair information. The hybrid knowledge base pre-stores multi-dimensional document vectorized data of tool invocation failures. Based on the application scenario corresponding to the query information, compliance strategies adapted to the application scenario are determined as domain constraints. The query information, tool invocation command, error information, repair information, and domain constraints are integrated to generate a structured repair context. Based on the repair context, the large model is repaired using preset commands to generate corrected tool invocation commands, which are then executed.

[0006] Secondly, a command repair device is provided, which adopts the following technical solution: The acquisition module is used to acquire the error information corresponding to the tool invocation command when the execution of the tool invocation command corresponding to the query information is detected to have failed. The tool invocation command is the execution command output by the large language model in response to the query information. The building module is used to construct a multi-dimensional retrieval query vector set based on tool call commands, query information, and error information; The retrieval module is used to retrieve query vector sets based on multi-dimensional retrieval, perform retrieval operations in the hybrid knowledge base, obtain matching repair information, and call the multi-dimensional document vectorized data of the fault in the hybrid knowledge base pre-stored tool. The determination module is used to determine the compliance strategies that are appropriate for the application scenario as domain constraints based on the application scenario corresponding to the query information. The integration module is used to integrate query information, tool call commands, error messages, repair information, and domain constraints to generate a structured repair context; The generation module is used to integrate based on the repair context, repair the large model using preset instructions, generate corrected tool call instructions, and execute the corrected tool call instructions.

[0007] Thirdly, a computer device is provided, which adopts the following technical solution: When a tool invocation command corresponding to the query information fails to execute, the error information corresponding to the tool invocation command is obtained. The tool invocation command is the execution command output by the large language model in response to the query information. Based on the tool invocation command, query information, and error information, a multi-dimensional retrieval query vector set is constructed. Based on the multi-dimensional retrieval query vector set, a retrieval operation is performed in the hybrid knowledge base to obtain matching repair information. The hybrid knowledge base pre-stores multi-dimensional document vectorized data of tool invocation failures. Based on the application scenario corresponding to the query information, compliance strategies adapted to the application scenario are determined as domain constraints. The query information, tool invocation command, error information, repair information, and domain constraints are integrated to generate a structured repair context. Based on the repair context, the large model is repaired using preset commands to generate corrected tool invocation commands, which are then executed.

[0008] Fourthly, a computer-readable storage medium is provided, which adopts the following technical solution: When a tool invocation command corresponding to the query information fails to execute, the error information corresponding to the tool invocation command is obtained. The tool invocation command is the execution command output by the large language model in response to the query information. Based on the tool invocation command, query information, and error information, a multi-dimensional retrieval query vector set is constructed. Based on the multi-dimensional retrieval query vector set, a retrieval operation is performed in the hybrid knowledge base to obtain matching repair information. The hybrid knowledge base pre-stores multi-dimensional document vectorized data of tool invocation failures. Based on the application scenario corresponding to the query information, compliance strategies adapted to the application scenario are determined as domain constraints. The query information, tool invocation command, error information, repair information, and domain constraints are integrated to generate a structured repair context. Based on the repair context, the large model is repaired using preset commands to generate corrected tool invocation commands, which are then executed.

[0009] Compared with existing technologies, the embodiments of this application have the following main advantages: By constructing a multi-dimensional query vector set and using a hybrid knowledge base retrieval, it fully integrates diverse and heterogeneous fault repair knowledge, accurately locates the root cause of complex errors, significantly improves the success rate and efficiency of repairing complex tool call errors, and avoids business risks caused by repeated retries. By combining application scenarios to determine domain constraints and integrating and generating structured repair contexts, the correction instructions generated by the instruction repair model strictly adapt to domain compliance requirements, solving the problem of insufficient compliance adaptability of existing mechanisms. The overall process achieves knowledge-based, compliant, and efficient fault repair. Attached Figure Description

[0010] To more clearly illustrate the solutions in this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is an exemplary system architecture diagram to which this application can be applied; Figure 2 A flowchart of an embodiment of the repair method according to the instructions of this application; Figure 3 This is a schematic diagram of one embodiment of the instruction repair device according to this application; Figure 4 This is a schematic diagram of the structure of one embodiment of the computer device according to this application. Detailed Implementation

[0012] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0013] like Figure 1 As shown, system architecture 100 may include terminal device 101, network 102, and server 103. Terminal device 101 may be a laptop 1011, tablet 1012, or mobile phone 1013. Network 102 is used as a medium to provide a communication link between terminal device 101 and server 103. Network 102 may include various connection types, such as wired, wireless communication links, or fiber optic cables.

[0014] Users can use terminal device 101 to interact with server 103 via network 102 to receive or send messages, etc. Various communication client applications can be installed on terminal device 101, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0015] Terminal device 101 can be various electronic devices with a display screen and support web browsing. In addition to laptops 1011, tablets 1012, or mobile phones 1013, terminal device 101 can also be e-book readers, MP3 players (Moving Picture Experts Group Audio Layer III), MP4 players (Moving Picture Experts Group Audio Layer IV), laptops, and desktop computers.

[0016] Server 103 can be a server that provides various services, such as a backend server that provides support for the pages displayed on terminal device 101.

[0017] It should be noted that the instruction repair method provided in this application embodiment is generally executed by a server / terminal device, and correspondingly, the instruction repair device is generally set in the server / terminal device.

[0018] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0019] Continue to refer to Figure 2 The diagram shows a flowchart of an embodiment of the instruction repair method according to this application. The instruction repair method includes the following steps: Step S201: When it is detected that the execution of the tool call instruction corresponding to the query information fails, obtain the error information corresponding to the tool call instruction. The tool call instruction is the execution instruction output by the large language model in response to the query information.

[0020] Among them, query information is the input content initiated by users to the large language model based on specific business needs. It is the core source driving the generation of tool call instructions, which not only includes the expected business goals, but also covers key limiting information such as the operation object, time range, and data dimensions. For example, a user in the financial field might initiate a query to "query the details of the fund flow of Company A's cross-border transactions in Q2 2024, including the counterparty and settlement currency".

[0021] Among them, tool invocation instructions are structured execution instructions that conform to the interface specifications of the business system, generated by the large language model after semantic parsing and requirement decomposition of query information. They can include core elements such as interface identifier, invocation parameters, execution logic, and return data format.

[0022] Error messages are feedback data returned when a tool's invocation command fails to execute due to various exceptions after being submitted to the business system or target tool. They are crucial for locating the root cause of the fault. Error messages may include error codes, exception types, triggering conditions, a description of the fault location, and possible cause suggestions.

[0023] Among them, the big language model is an artificial intelligence model that is pre-trained on massive general text data and domain data and has powerful natural language understanding, semantic parsing and structured text generation capabilities. Its core advantage lies in its ability to capture the deep business intent of query information and transform it into operational logic that the system can recognize.

[0024] Step S202: Based on the tool call instructions, query information, and error information, construct a multi-dimensional retrieval query vector set.

[0025] Among them, the multi-dimensional retrieval query vector set is a vector set formed by transforming three types of core data—tool call instructions, query information, and error information—through a domain-adapted text vector model in order to achieve accurate retrieval of hybrid knowledge bases. The core of it consists of error pattern query vectors and intent-preserving query vectors.

[0026] Step S203: Based on the multi-dimensional retrieval query vector set, perform a retrieval operation in the hybrid knowledge base to obtain matching repair information. The hybrid knowledge base pre-storage tool calls the multi-dimensional document vectorized data of the fault.

[0027] The hybrid knowledge base is a data storage system used by storage tools to access fault repair-related knowledge. Its core feature is the integration of diverse and heterogeneous knowledge sources, rather than a single type of document collection. Specifically, it can include internal historical fault handling reports, business system technical manuals, domain compliance documents, and publicly available solutions from external technical communities. By uniformly vectorizing and indexing this knowledge, it provides comprehensive and accurate knowledge support for fault repair.

[0028] Among them, the repair information is the solution-type data that is directly related to the current tool call failure, obtained by performing a retrieval operation on a hybrid knowledge base based on a multi-dimensional retrieval query vector set. It is the core knowledge basis for solving the failure.

[0029] Among them, multi-dimensional document vectorized data consists of dense semantic vector data formed by preprocessing various original documents from the hybrid knowledge base and transforming them through the domain-adapted text vector model in this solution. This type of data can accurately represent the core semantic features of the original documents, transforming the repair knowledge in text form into a computer-computable vector form, thereby enabling rapid semantic matching and relevance ranking during retrieval.

[0030] Step S204: Based on the application scenario corresponding to the query information, determine the compliance strategy that adapts to the application scenario as the domain constraint condition.

[0031] Among them, the application scenario refers to the specific business domain and scenario type to which the query information belongs. Its core feature is that it includes key attributes such as business rules, data processing requirements, and compliance constraint standards under that scenario, which directly determine the direction of domain constraint selection.

[0032] Among them, compliance strategy is a rule system formulated for specific application scenarios based on industry norms, laws and regulations, and internal management systems of enterprises. It is used to constrain the operation behavior of tool calling. Its core purpose is to ensure that the tool calling process complies with compliance requirements and avoid illegal operations or data security risks.

[0033] Among them, the domain constraint condition is a set of specific constraint rules that are selected, extracted and optimized from compliance strategies based on the application scenario corresponding to the query information. It is the core basis for guiding the large model of instruction repair to generate compliance correction instructions.

[0034] Step S205: Integrate query information, tool call instructions, error information, repair information, and domain constraints to generate a structured repair context.

[0035] Integration refers to the process of associating, reorganizing, deduplicating, and semantically aligning multi-source heterogeneous data, such as query information, tool call instructions, error messages, repair information, and domain constraints, according to a preset structured logic.

[0036] Among them, the repair context is a set of structured intermediate data obtained by integrating multi-source data. It is the core input for the tool to call instructions after the instruction repair big model generates correction instructions. Its feature is that it comprehensively covers all kinds of key information required for fault repair, including user business needs, fault characteristics, repair solutions, compliance constraints, etc. It can provide a complete semantic background for the big model and avoid omissions or violations in the generated correction instructions.

[0037] Step S206: Integrate based on the repair context, repair the large model using preset instructions, generate corrected tool call instructions, and execute the corrected tool call instructions.

[0038] Among them, the instruction repair big model is a dedicated big language model that is specially optimized and trained for tool call instruction repair scenarios. Unlike general big language models, it has the core capabilities of parsing repair context, integrating compliance constraints, and correcting faulty instructions after being fine-tuned by domain fault repair data.

[0039] Among them, the corrected tool call instruction is a structured execution instruction generated by the instruction repair model based on the repair context, which corrects the original instruction's faults and meets the domain constraints. Its core feature is that it solves the problem of the original instruction's execution failure, such as supplementing missing parameters, correcting insufficient permissions, and adjusting parameter formats.

[0040] In one embodiment, after the modified tool invocation instruction is executed by the executor, the execution result fed back by the executor is captured. If the execution result is successful, the execution result is returned to the user, and the complete repair chain information is recorded to the audit system. The complete repair chain information includes at least query information, the original tool invocation instruction, error information, repair information, domain constraints, structured repair context, modified tool invocation instruction, and execution result. If the execution result is a failure, the following steps are iteratively executed until the preset maximum number of retries is reached: obtaining new error information corresponding to the modified tool invocation instruction; constructing a new multi-dimensional retrieval query vector set based on the new error information, query information, and modified tool invocation instruction; retrieving new repair information from the hybrid knowledge base based on the new multi-dimensional retrieval query vector set; determining new domain constraints based on the application scenario; integrating and generating a new structured repair context; and using the instruction repair big model to generate a new modified tool invocation instruction, which is then executed by the executor, and the new execution result is captured. This embodiment captures the result after executing the modified instruction, realizing closed-loop verification of fault repair. Upon successful execution, the complete repair process is recorded in the audit system to meet the audit traceability requirements of fields such as finance and healthcare, ensuring operational traceability and compliance. Upon failure, iterative retrying is performed. By dynamically updating multi-dimensional retrieval vectors and repair information, the success rate of repairing complex faults is improved. A maximum number of retries is preset to avoid business interruptions caused by unlimited retries, balancing repair effectiveness and system stability.

[0041] This application embodiment constructs a multi-dimensional query vector set and uses a hybrid knowledge base for retrieval, fully integrating diverse and heterogeneous fault repair knowledge to accurately locate the root cause of complex errors. This significantly improves the success rate and efficiency of repairing errors caused by complex tool calls, avoiding business risks caused by repeated retries. By combining application scenarios to determine domain constraints and integrating and generating structured repair contexts, the correction instructions generated by the instruction repair model strictly adapt to domain compliance requirements, solving the problem of insufficient compliance adaptability in existing mechanisms. The overall process achieves knowledge-based, compliant, and efficient fault repair.

[0042] In some optional implementations of this embodiment, step 202, constructing a multi-dimensional retrieval query vector set based on tool call instructions, query information, and error information, specifically includes the following steps: The system performs semantic parsing on the query information to obtain a user intent description. Based on tool invocation commands, it performs parameter consistency verification and correction on the user intent description to obtain a target user intent description. Resource constraint parameters are extracted from the target user intent description, and their semantics are expanded to obtain an equivalent parameter semantic set. This equivalent parameter semantic set is then matched with resource constraint configuration specifications in a pre-defined configuration specification knowledge base to generate an intent-preserving query vector. Error pattern features are extracted from error information, and these features are supplemented by command association based on tool invocation commands to obtain a command-associated error feature set. Based on this command-associated error feature set, an error pattern query vector is generated. Finally, a multi-dimensional retrieval query vector set is constructed based on the error pattern query vector and the intent-preserving query vector.

[0043] Among them, the user intent description is a structured expression formed by deep semantic analysis, core requirement extraction and business logic sorting of user query information. It is a precise interpretation of the deep business goals behind the user's original query, which not only includes the operation object and expected result, but also covers potential demand scenarios and constraints.

[0044] Among them, parameter consistency verification and correction is a process of comprehensively verifying and specifically correcting various parameters involved in the user intent description based on the business system interface specifications and parameter configuration requirements corresponding to the tool call command.

[0045] The target user intent description is a standardized expression of user intent that has been finalized after parameter consistency verification and correction. It is an organic unity of the user's core needs and the system's execution requirements. It not only fully preserves the core business objectives of the user's original query, but also ensures through parameter correction that all related parameters conform to the interface specifications and business logic of the tool's call instructions, and there are no issues such as formatting errors, logical contradictions, or missing information.

[0046] Among them, resource restriction parameters are key parameters that are precisely extracted from the target user's intent description and used to define the scope and constraints of resource access during tool invocation. They are the core elements for limiting the boundaries of business operations and avoiding resource abuse or invalid retrieval.

[0047] The equivalent parameter semantic set is a semantic set formed by multi-dimensional semantic expansion of resource restriction parameters to improve the comprehensiveness and accuracy of retrieval. It covers synonyms, near-synonyms, standardized expressions, business scenario-based expressions, and common abbreviations of parameters, ensuring that effective matching can still be achieved even if the parameter expressions of the repair information in the knowledge base differ from the expressions in the user's intent.

[0048] Among them, the configuration specification knowledge base is a professional knowledge storage system that pre-stores tools to call various configuration standards and specifications. Its stored content covers configuration specifications for business system interface parameters, resource access restriction rules, data format standards, and configurations related to industry compliance requirements, and is classified and managed according to business domain, interface type, and parameter category.

[0049] Among them, the resource restriction configuration specification is a standardized rule entry stored in the configuration specification knowledge base that restricts the use of resources by tools. It is the core basis for defining the legal boundaries and configuration requirements of resource restriction parameters. Each specification clearly defines the parameter name, data type, legal value range, format requirements, associated constraints, and violation handling instructions.

[0050] Among them, the core feature of intent-preserving query vectors lies in accurately capturing the user's core business intent and resource constraints. In the process of hybrid knowledge base retrieval, it can prioritize matching repair information that meets both the user's intent and the resource configuration specifications, effectively avoiding the search results from deviating from the user's real needs or violating the configuration specifications. It is one of the core vectors for achieving accurate retrieval.

[0051] Among them, error pattern features are key feature information representing the core attributes of the fault extracted from the error information returned by the tool call failure through feature extraction algorithms, such as keyword extraction, semantic annotation, and structured parsing. They are the core basis for locating the fault type and root cause. The instruction association error feature set is a complete feature set formed by supplementing, improving and associating the error pattern features with information such as the interface specification, parameter configuration, and execution logic of the tool call instruction.

[0052] In one example, taking the scenario of querying patient electronic medical record data as an example, the user's query information is "Retrieve outpatient medical records and examination reports for the past six months for patient ID: H202406XX". The tool call instruction output by the large language model is "Call the electronic medical record query interface (parameters: patient ID=H202406XX, query type=outpatient medical records + examination reports)". The instruction execution fails and returns the error message "Parameter missing: Time range not specified (error code: 400)". First, the query information is semantically parsed to obtain the user intent description "Retrieve outpatient medical records and examination reports for the past six months for patient ID H202406XX". Based on the interface specification of the tool call instruction, the parameter consistency of this intent description is checked, and it is found that the "time range" parameter is missing. After correction, the target user intent description is obtained as "Retrieve outpatient medical records and examination reports for patient ID H202406XX, with a time range of 20240101-20240630". Resource constraint parameters such as "Patient ID=H202406XX" and "Time range 20240101-20240630" are extracted from the target user intent description and semantically expanded to obtain an equivalent parameter semantic set. This set is then matched with the medical data query resource constraint configuration specification in the configuration specification knowledge base to generate an intent-preserving query vector. Error pattern features such as "Error type = missing parameter," "Abnormal parameter = time range," and "Error code = 400" are extracted from error messages and supplemented by the interface requirement that "time range is a required parameter" in the tool call command to obtain a command-related error feature set and generate an error pattern query vector. Finally, a multi-dimensional retrieval query vector set is constructed from these two types of vectors.

[0053] This application's embodiments extract user intent descriptions through semantic parsing, combine this with tool invocation commands to complete parameter consistency verification and correction, extract resource limitation parameters and perform semantic expansion, and generate intent-preserving query vectors by associating them with a configuration specification knowledge base. Simultaneously, error pattern features are extracted from error information, supplemented by tool invocation commands, and an error pattern query vector is generated, ultimately constructing a multi-dimensional retrieval query vector set. This process accurately captures the user's core business intent, comprehensively characterizes fault features, and improves retrieval adaptability through semantic expansion and specification matching. It ensures efficient retrieval of repair information that meets both user needs and fault scenarios from a hybrid knowledge base, providing strong support for accurate repair of complex errors and effectively solving the problems of low repair success rate and insufficient efficiency in existing mechanisms.

[0054] In some optional implementations, before step 203, which involves performing a retrieval operation in the hybrid knowledge base based on a multi-dimensional retrieval query vector set to obtain matching repair information, the following steps are also included: The process involves: acquiring a document set for the hybrid knowledge base to be built, including historical fault documents, technical specification documents, strategy configuration documents, and community solution documents; collecting domain text data matching the target domain's preset service scenarios to construct a corpus; obtaining a pre-trained general text vector model and fine-tuning it using the corpus to achieve domain-specific adaptation; using the text vector model to vectorize the historical fault documents, technical specification documents, strategy configuration documents, and community solution documents to obtain corresponding text vectors; associating and storing the text vectors with the historical fault documents, technical specification documents, strategy configuration documents, and community solution documents, and constructing a retrieval index based on the similarity between the text vectors to obtain the hybrid knowledge base.

[0055] Among them, the document set is the basic raw data set for building the hybrid knowledge base. It is the core carrier for integrating diverse and heterogeneous knowledge, covering various structured, semi-structured and unstructured text materials related to tool call fault repair.

[0056] Among them, historical fault documents are specialized documents that record actual faults and complete handling chains that occurred during past tool calls within the target domain. They are a core component of the document collection with significant practical value. The document content includes not only query information at the time of fault triggering, original tool call commands, and error feedback details (error codes, exception descriptions, triggering scenarios), but also technical analysis of the fault root cause, step-by-step repair steps, parameter adjustment details, verification results of repair effects, and subsequent preventative measures. Technical specification documents are standardized documents developed by industry standards organizations, technical R&D teams, or enterprise technical departments to standardize the technical implementation, interface design, parameter configuration, data transmission, and system interaction related to tool calls. Policy configuration documents are configuration documents developed for tool call scenarios in the target domain, focusing on core requirements such as compliance requirements, access control, resource allocation, and risk control. They are crucial for ensuring the legality, compliance, security, and controllability of tool calls. Community solution documents are tool call fault solutions shared by technical developers and industry practitioners based on practical experience from external publicly available technical communities.

[0057] The target domain is the specific business area or industry category of the hybrid knowledge base's preset services. It has clear business attributes, scenario characteristics, and technical requirements, and serves as the core benchmark for knowledge base construction and model adaptation. Domain text data is a collection of professional text information highly relevant to the target domain. It is the core training data used for domain adaptation fine-tuning of text vector models, characterized by strong domain relevance, high professionalism, and semantic integrity.

[0058] Domain-specific fine-tuning is a process of secondary training and optimization of a pre-trained general text vector model using target domain text data. Its core objective is to improve the model's semantic understanding and vector conversion accuracy in the target domain. By organizing the domain text data according to specific task formats, such as text classification or semantic matching, and adjusting the model's network parameters, the model can fully learn the target domain's terminology, business logic, semantic expressions, and text structure features, thus overcoming the semantic bias problem of general models in specialized domains. Text vector models are artificial intelligence models capable of converting natural language text into dense semantic vectors that can be computed by computers; they are a core technological tool for document vectorization.

[0059] Among them, associative storage is a data management method that establishes a unique mapping relationship between the text vectors transformed from the document set through a text vector model and the corresponding original documents (historical fault documents, technical specification documents, strategy configuration documents, and community solution documents, etc.), and stores them in the knowledge base according to a preset data structure. This storage method not only preserves the high-dimensional semantic features of the text vectors, facilitating rapid similarity calculation, but also enables rapid retrieval of detailed content from the original documents after a matching vector is found, ensuring rapid acquisition and accurate application of repair information. The retrieval index is an index structure built based on the semantic similarity relationship between the text vectors after document vectorization, using specific indexing algorithms such as inverted indexes and vector indexes. It is a core component for improving the retrieval efficiency of the hybrid knowledge base. Its core function is to avoid traversing and calculating all document vectors during retrieval by pre-calculating and storing the semantic association information of the text vectors, thereby significantly shortening the retrieval response time.

[0060] In one example, focusing on the repair of policy underwriting tool call failures, the construction process of the hybrid knowledge base is explained in detail. First, a document set is acquired, including historical failure documents from the insurance industry such as "policy underwriting interface parameter errors" and "underwriting permission verification failures," technical specification documents such as the "Insurance Underwriting Tool Call Technical Specification V3.0," underwriting strategy configuration documents that comply with policy requirements, and publicly available solution documents for underwriting tool call failures from communities (such as GitHub). Text data from the insurance field, including underwriting business process texts, underwriting terminology dictionaries, and regulatory compliance provisions, are collected to build a dedicated corpus. A pre-trained general BERT model is obtained, and this corpus is used to fine-tune the model for domain adaptation, optimizing the model's semantic understanding of professional terms such as "underwriting factors" and "underwriting thresholds," resulting in an insurance-domain-adapted text vector model. This model is used to vectorize various documents in the document set, generating corresponding text vectors. These text vectors are then linked and stored after establishing a unique mapping relationship with the original documents. A vector retrieval index is built based on the cosine similarity between text vectors to achieve rapid location of similar fault repair knowledge, ultimately forming a hybrid knowledge base that supports insurance underwriting tools in calling fault repair methods. This knowledge base integrates diverse knowledge and can accurately match various fault repair needs in underwriting scenarios.

[0061] This application's embodiments integrate diverse and heterogeneous documents, such as historical fault documents and technical specification documents, to form a document set. A corpus is constructed by collecting text data from the target domain. A general text vector model is fine-tuned for domain adaptation to ensure the model accurately captures domain semantic features. The adapted model is then used to vectorize various documents, and a hybrid knowledge base is built through associative storage and similarity retrieval indexes. This achieves systematic integration and efficient retrieval adaptation of diverse knowledge. This process enriches the knowledge dimensions of the knowledge base, avoiding the limitations of a single knowledge source. Furthermore, through domain adaptation and vector retrieval design, it improves the accuracy of knowledge matching and retrieval efficiency, providing comprehensive and efficient knowledge support for complex error repair. This addresses the problems of insufficient utilization of heterogeneous knowledge and inadequate retrieval accuracy in existing mechanisms.

[0062] In some optional implementations, the multi-dimensional retrieval query vector set includes error pattern query vectors and intent preservation query vectors. Step S203 involves performing a retrieval operation in a hybrid knowledge base based on the multi-dimensional retrieval query vector set to obtain matching repair information. This specifically includes the following steps: Parallel retrieval operations are performed on the hybrid knowledge base using error pattern query vectors and intent-preserving query vectors to obtain a preliminary set of matching document fragments. It is then determined whether the number of preliminarily matched document fragments exceeds a preset threshold. If so, a preset cross-encoder is used to perform deep interactive calculations between the document fragments in the set and the error pattern query vectors and intent-preserving query vectors, respectively, to obtain a relevance score for each document fragment. Based on the relevance scores, the document fragment set is sorted to obtain a sorted set of candidate document fragments. If not, the document fragment set is determined as the sorted set of candidate document fragments. Finally, repair information matching the error pattern query vectors and intent-preserving query vectors is extracted from the sorted set of candidate document fragments.

[0063] The document fragment set is a collection of document fragments related to tool call failure scenarios and core user intents, initially selected after parallel retrieval of the hybrid knowledge base using error pattern query vectors and intent-preserving query vectors. These document fragments are not complete documents, but rather partial fragments containing key information for fault repair extracted from original documents such as historical fault documents and technical specification documents. The threshold is a preset quantitative criterion for balancing the comprehensiveness and accuracy of search results. It is a key parameter for selecting the initially matching document fragment set, and its value can be dynamically adjusted according to the fault complexity of the target domain, the size of the knowledge base, and the required search response efficiency.

[0064] The cross-encoder is a neural network model with deep semantic interaction computing capabilities. It is the core tool for achieving accurate matching between document fragments and query vectors. Its key feature is its ability to perform bidirectional semantic encoding and interaction between document fragments and query vectors (error pattern query vectors, intent-preserving query vectors), rather than single-dimensional feature comparison. By capturing the deep semantic relationship between the two, such as the adaptation logic between error types and repair solutions, and the fit between user intent and knowledge fragments, it outputs quantitative results that accurately reflect the correlation between the two, effectively solving the matching bias problem caused by relying solely on surface features in traditional retrieval.

[0065] The relevance score, a quantitative score obtained through deep interaction calculations between the document fragment and the error pattern query vector and intent-preserving query vector using a cross-encoder, is the core indicator for measuring the degree to which the document fragment matches the current fault repair needs. A high score directly reflects the effectiveness of the repair information in the document fragment in resolving the fault and its alignment with the user's intent.

[0066] The candidate document fragment set is a final set of document fragments with high matching degree determined after preliminary retrieval and deep relevance ranking. It is the direct data source for extracting repair information. If the number of initially matched document fragments exceeds the threshold, the set consists of the top N highly relevant fragments (N is the preset screening number) after relevance score ranking; if it does not exceed the threshold, it is directly composed of the initially matched fragments.

[0067] In one example, taking the fault repair of the car insurance claim amount calculation tool as an example, in the known multi-dimensional retrieval query vector set, the error pattern query vector represents the fault feature of "parameter logic conflict (mismatch between calculation factor and vehicle model)," while the intent-preserving query vector represents the core requirement of "accurate calculation of car insurance claim amount." Parallel retrieval is performed on the hybrid knowledge base of the insurance domain using dual vectors, quickly matching 120 document fragments related to "calculation factor adaptation rules" and "vehicle model parameter verification scheme," forming a preliminary matching document fragment set. A preset threshold of 80 is set; if 120 exceeds the threshold, a cross-encoder is initiated for deep interactive calculation. The cross-encoder performs semantic association analysis on each document fragment with both the error pattern query vector and the intent-preserving query vector, outputting a relevance score for each fragment. For example, a fragment that simultaneously matches the requirements for calculation factor conflict repair and accurate claim amount calculation receives a score of 0.91. Based on the relevance scores, the top 80 highly relevant segments are selected to form a candidate document segment set. From this set, the repair information "adjust the accounting factor to a vehicle model-specific adaptation version and supplement the vehicle model parameter verification logic" is extracted. This information not only matches the fault characteristics but also meets the user's core business intent, providing accurate knowledge basis for the generation of subsequent correction instructions.

[0068] This application embodiment performs parallel retrieval on a hybrid knowledge base using error pattern query vectors and intent-maintaining query vectors, simultaneously capturing fault characteristics and core user intents to quickly obtain a preliminary set of matching document fragments. A preset threshold is used to dynamically determine whether to initiate deep filtering. When the number of fragments exceeds the threshold, a cross-encoder enables deep semantic interaction between the document fragments and the dual query vectors, sorting high-quality fragments by relevance score. Fragments within the threshold are directly retained, and finally, precisely matched repair information is extracted from the candidate fragment set. This process balances retrieval efficiency and matching accuracy, improving response speed through parallel retrieval while strengthening the fit between repair information and fault / intent through deep interactive computation, providing accurate knowledge support for complex error repair and addressing the low success rate and insufficient efficiency of existing mechanisms.

[0069] In some optional implementations, step S204, which involves determining the compliance strategy that adapts to the application scenario as a domain constraint based on the application scenario corresponding to the query information, specifically includes the following steps: Based on the application scenarios corresponding to the query information, scenario feature dimensions are analyzed for tool call instructions and query information to generate scenario tags. The scenario tags are then matched with a pre-set scenario policy mapping library in multiple dimensions to obtain candidate compliance policies. The scenario policy mapping library stores the mapping relationship between each application scenario and the corresponding compliance policy. The compliance policies are pre-configured with constraint priority rules and descriptions of violation consequences. Based on the operation type of the tool call instructions, the candidate compliance policies are filtered to determine the appropriate policy set. Constraint clauses related to the operation type are extracted from the policy set. Based on the constraint clauses, constraint priority rules, and descriptions of violation consequences, domain constraint conditions are generated.

[0070] Among them, scenario feature dimension analysis is an analysis process that extracts key features of application scenarios from multiple core dimensions based on query information and tool call instructions. Its purpose is to accurately define the scenario type and core attributes of the current business, and provide a basis for matching subsequent compliance strategies.

[0071] Scenario tags are structured identifiers obtained after parsing scenario feature dimensions, used to represent the core attributes of application scenarios. They concisely and intuitively reflect the key characteristics of a scenario, facilitating rapid matching with the scenario policy mapping library. The scenario policy mapping library is a data storage system that pre-stores the mapping relationships between various application scenario tags and corresponding compliance policies. Its core function is to achieve rapid matching between scenarios and compliance policies, avoiding the inefficiency caused by filtering one by one.

[0072] Among them, the candidate compliance strategy is a set of compliance strategies related to the current application scenario obtained by multi-dimensional matching of scenario tags and scenario strategy mapping library. Its feature is that it covers all compliance rules that may be involved in the scenario, but it has not yet been precisely filtered for specific tool call operation types.

[0073] The strategy set is a subset of precise compliance strategies obtained by further filtering candidate compliance strategies for specific operation types of tool invocation commands, such as query, write, delete, and modify. Its core principle is to eliminate compliance strategies irrelevant to the current operation type and retain rules that directly constrain that operation. Constraint clauses are specific rule entries extracted from the strategy set and directly used to constrain the generation of tool invocation commands. They are a core component of domain constraints, characterized by being clear, executable, and unambiguous, explicitly defining the allowed scope, prohibited behaviors, required parameters, and format requirements of tool invocation operations.

[0074] In one example, taking the scenario of querying large insurance policy claim application data as an example, the user's query information is "query the original materials and review records of the claim application corresponding to policy number P202405XXX". The big language model outputs the tool call instruction as "call the claim data query interface (parameter: policy number P202405XXX, query scope: original materials + review records)". First, based on this application scenario, the tool call instruction and query information are analyzed from the perspective of scenario features. Features are extracted from business domain (financial insurance), business type (claim data query), data sensitivity (high sensitivity), and operation permission level (level 2) to generate the scenario label "financial insurance - claim query - high sensitivity - level 2 permission". This label is matched with a preset scenario strategy mapping library. This mapping library stores the mapping relationship between the "financial insurance - claim query - high sensitivity" scenario and the adaptation strategy of the Personal Information Protection Law and the data access security specifications of insurance companies. The compliance strategy is pre-configured with constraint priority rules and explanations of the consequences of violations, and a set of candidate compliance strategies is obtained through matching. After filtering by "query" operation type and removing irrelevant strategies, a set of adaptive strategies including data access permission verification and sensitive data anonymization is obtained. The corresponding constraint clauses are extracted, and combined with the corresponding constraint priority rules and explanations of the consequences of violations, domain constraint conditions are generated.

[0075] This application's embodiments generate scenario tags by parsing tool invocation commands and query information from a scenario feature dimension. Relying on a scenario policy mapping library, it achieves precise matching between scenarios and compliance policies, initially screening candidate compliance policies. Further filtering is then performed based on the operation type of the tool invocation commands to form a suitable policy set. Targeted constraint clauses are extracted, and constraint priority rules and violation consequence descriptions are integrated to generate domain constraint conditions. This process achieves layered and precise screening of compliance policies from scenario adaptation to operation adaptation, ensuring that domain constraint conditions not only conform to the compliance requirements of specific application scenarios but also focus on the core constraint needs of tool invocation operations. This avoids the blind application of general compliance rules and provides precise and clear constraint basis for subsequently generating compliant and effective correction commands.

[0076] In some optional implementations, step S205 integrates query information, tool invocation instructions, error messages, repair information, and domain constraints to generate a structured repair context, specifically including the following steps: The process involves: acquiring a pre-defined structured repair context template, comprising a factual information area, a knowledge evidence area, and a constraint area; filling the corresponding fields in the factual information area with query information, tool call instructions, and error information to obtain the filled factual information area; calculating the confidence score of the repair information using a pre-defined cross-encoder, and sorting the repair information according to the confidence score to obtain the sorted repair information; obtaining the source annotations of the repair information from a hybrid knowledge base, and filling the sorted repair information, confidence scores, and source annotations into the corresponding fields in the knowledge evidence area to obtain the filled knowledge evidence area; extracting scenario compliance requirements from domain constraints based on the application scenario, and filling the scenario compliance requirements into the corresponding fields in the constraint area to obtain the filled constraint area; performing a causal correlation test on the filled factual information area and the filled knowledge evidence area, removing the first target data to obtain the factual information area data and the knowledge evidence area data; performing a matching test on the filled constraint area and the application scenario, filtering the second target data to obtain the constraint area data; and integrating the factual information area data, the knowledge evidence area data, and the constraint area data to generate a structured repair context.

[0077] Among them, the structured repair context template is a predefined core data integration framework with clear partitioning logic and standardized field specifications. This template achieves data classification and storage through three preset core areas (fact information area, knowledge evidence area, and constraint condition area). Each area is designed with exclusive fields and format requirements for specific data types, and can be flexibly adapted according to the business characteristics of the target field (such as insurance and medical care), providing a unified execution standard for subsequent data filling, validation and integration.

[0078] The Fact Information Area is a core module in the structured repair context template, specifically designed to carry various objective factual data related to the tool's invocation of the fault occurrence process. It serves as the fundamental data carrier for reconstructing the fault scenario and clarifying the repair target. The Knowledge Evidence Area is a key region in the structured repair context template used to integrate and store the knowledge support data required for fault repair. Its core function is to provide authoritative and credible knowledge basis for repair decisions, while ensuring the traceability of the repair process. The Constraints Area is a module in the structured repair context template specifically designed to carry the compliance constraints specific to the application scenario. It is the core guarantee to ensure that post-repair instructions comply with industry standards, laws and regulations, and corporate systems.

[0079] The populated fact information area is a structured data set formed by entering and standardizing the original fact data such as query information, tool call instructions, and error information one by one according to the field definitions and format requirements of the fact information area in the structured repair context template.

[0080] Source labeling is a traceable identifier used to accurately identify the origin of repair information. It is a core attribute that ensures the authority and reliability of repair information and provides a basis for auditing and verifying the repair process. The populated knowledge evidence area is a data set formed by entering and structuring the repair information, corresponding confidence scores, and source labels according to the preset field requirements of the knowledge evidence area, after sorting by confidence level.

[0081] Among them, scenario compliance requirements are a subset of targeted compliance rules extracted from domain constraints that are highly adapted to the application scenario corresponding to the current query information, and constitute the core content of the constraint condition area. The populated constraint condition area is a data set formed by entering and structuring the extracted scenario compliance requirements according to the preset field specifications of the constraint condition area. During the population process, the scenario compliance requirements need to be broken down in detail to ensure that each constraint rule can accurately match the corresponding field.

[0082] The causal correlation test is a process of deeply verifying the logical correlation between the filled factual information area and the knowledge evidence area. Its core purpose is to eliminate invalid data without causal correlation, ensuring that the repair information in the knowledge evidence area accurately matches the fault facts in the factual information area, thus providing effective support for the generation of subsequent repair instructions. The first target data is the set of invalid data determined by the causal correlation test to have no direct causal correlation with the fault facts in the factual information area. The factual information area data is the core data set that, after the filled factual information area undergoes the causal correlation test (simultaneously verifying the logical consistency of the factual data itself and eliminating redundant factual data that is duplicated or contradictory), is ultimately retained and can accurately reconstruct the core fault facts and has a causal correlation with the effective repair information in the knowledge evidence area. The knowledge evidence area data is the set of high-quality repair information and related auxiliary data that, after the filled knowledge evidence area undergoes the causal correlation test and the first target data is removed, is retained and has a direct causal correlation with the fault facts in the factual information area.

[0083] The second target data consists of invalid compliance constraints deemed incompatible with the current application scenario through a matching check between the constraint area and the application scenario. This type of data typically represents general domain compliance rules that are not applicable to the specific business scenario and are therefore identified as second target data. These data must be filtered out to prevent irrelevant compliance requirements from interfering with the generation of remediation instructions and to ensure the accuracy of the constraints. The constraint area data is the set of core compliance constraints that are fully adapted to the current application scenario, retained after the constraint area has been filled and a matching check has been performed, and second target data has been removed.

[0084] In one example, taking the failure scenario of the car insurance claim calculation tool as an example, a preset structured repair context template is obtained, which includes a factual information area, a knowledge evidence area, and a constraint condition area. The user query information "calculate the car insurance claim amount for policy number P202407XXX", the failed tool call instruction "call the car insurance claim calculation interface (parameter: policy number P202407XXX)", and the error message "parameter missing: vehicle model code (error code 400)" are filled into the corresponding fields of the factual information area to obtain the filled factual information area. The confidence scores of the three retrieved repair information are calculated using a cross-encoder, and the repair information is sorted by score to obtain the sorted repair information (e.g., the score of 0.94 for "supplementing vehicle model code parameters" is the best). The source annotations of each repair information are obtained from the hybrid knowledge base (e.g., historical failure document ID: IN202406) and filled into the knowledge evidence area to obtain the filled knowledge evidence area. Based on the auto insurance claims scenario, compliance requirements such as "the need to verify the matching relationship between vehicle model and insured amount in claims calculation" are extracted from the domain constraints and filled into the constraint area. A causal relationship test is then performed on the filled factual information area and knowledge evidence area to remove irrelevant primary target data such as "adjusting interface timeout time". A matching test is then performed on the constraint area to filter secondary target data such as "personal insurance underwriting requirements". Finally, the remaining data is integrated to generate a structured repair context, ensuring that the information input to the model accurately matches fault repair and compliance requirements.

[0085] This application embodiment relies on a pre-defined structured template. It fills in factual data such as query information and tool call instructions by partitioning, combines cross-encoder scoring and sorting of repair information with supplementary source annotations, extracts scenario compliance requirements to complete the constraint condition area filling, and achieves orderly classification of multi-source data. Then, causal correlation checks are performed to eliminate irrelevant data, and matching checks are used to filter out data that does not meet compliance requirements, ultimately integrating to form a structured repair context. This process ensures the logical and standardized organization of data through template specifications, improves data accuracy through dual checks, and incorporates confidence scoring and source annotations to ensure the reliability of repair information. It provides comprehensive, accurate, and compliant input support for the instruction repair model, avoids interference from invalid data, and improves the accuracy and compliance of the generated correction instructions.

[0086] In some optional implementations, step 206 involves integrating based on the repair context, using preset instructions to repair the large model, and generating corrected tool call instructions, specifically including the following steps: Error messages are parsed to extract error features and obtain business level labels. Based on the business level labels, the generation parameters of the preset instruction repair model are dynamically adjusted. Based on the application scenario and domain constraints, domain-specific system prompts are generated. The domain-specific system prompts and repair context are integrated to obtain instruction repair guidance information. Based on the instruction repair guidance information, the corrected tool call instructions are generated using the parameter-adjusted instruction repair model.

[0087] Among them, error features are a set of key information representing the core attributes and scope of impact of tool call failures, extracted after structured parsing of the error information. This includes core elements such as error type, error code, abnormal parameters, fault triggering scenario, and scope of business impact. Business level labels are classification labels based on the degree of impact, urgency, and processing priority of the fault in the error features. These labels are the core basis for dynamically adjusting the parameters generated by the instruction repair model.

[0088] Among them, the generation parameters are the core parameters that can be dynamically adjusted during the process of the tool calling instructions after the instruction repair model is generated and corrected. They determine the generation logic, output format and optimization direction of the model, including temperature coefficient (to control generation diversity), maximum generation length, Top-K sampling threshold, compliance constraint weights, etc.

[0089] Among them, domain-specific system prompts are targeted prompts generated by combining the business characteristics and domain constraints of the current application scenario. They are used to guide the instruction repair model to focus on domain compliance requirements and business rules to generate correction instructions.

[0090] Among them, the instruction repair guidance information is a complete guidance data formed by semantically integrating domain-specific system prompts with structured repair context. It is the core input for the instruction repair model to generate correction instructions. It includes both the clear repair direction and compliance constraints of domain-specific system prompts, and complete data support such as the original fault facts, high-quality repair information, and precise compliance requirements in the repair context. This enables the model to generate correction instructions that both resolve the fault and meet domain requirements under clear guidance, combined with comprehensive fault and compliance information, avoiding the generation of instructions that deviate from the business scenario or violate regulations.

[0091] In one example, taking a failure scenario of calling a large-amount auto insurance claims calculation tool as an example, the error message "Parameter logic conflict (calculation factor and vehicle model mismatch, error code 500)" is parsed, and the error characteristics "Error type: parameter logic conflict, affected business: large-amount auto insurance claims calculation, scope of failure impact: core business process" are extracted, and the business level label is determined to be "core business interruption". Based on this label, the temperature coefficient of the instruction repair model is adjusted from 0.7 to 0.3 (to improve generation stability), and the compliance constraint weight is increased from 0.5 to 0.8 (to strengthen compliance). Combining the auto insurance claims scenario and domain constraints, a domain-specific system prompt is generated: "Please generate a correction instruction adapted to the auto insurance claims calculation interface V3.0, which needs to solve the problem of mismatch between the calculation factor and the vehicle model, and ensure compliance with the claims data encryption requirements and calculation accuracy specifications". This prompt is integrated with the structured repair context to obtain instruction repair guidance information. The instruction to repair the large model after adjusting the input parameters of the guidance information was generated as follows: "Call the vehicle insurance claims calculation interface (parameters: policy number P202408XX, vehicle code C202, calculation factor F-C202, data transmission encryption method: AES-256)". This instruction accurately repairs the fault and meets the compliance requirements of the field.

[0092] This application's embodiments extract error features from error information to obtain business level labels, and dynamically adjust the parameters of the instruction repair model generation based on these labels, ensuring the model generation strategy adapts to the business impact level of the fault. Domain-specific system prompts are generated by combining application scenarios and domain constraints, and integrated with the repair context to form instruction repair guidance information, clarifying the domain compliance and business orientation of model generation. Based on this guidance information, correction instructions are generated using the parameter-adjusted model. This process ensures adaptability to different fault levels through dynamic parameter adjustment, and strengthens compliance and scenario adaptation through domain-specific prompts, ensuring that the generated correction instructions accurately resolve the fault and comply with domain standards, thereby improving repair reliability and compliance.

[0093] It should be emphasized that, in order to further ensure the privacy and security of the above query information, error information, multi-dimensional retrieval query vector set, repair information, and repair context, the above query information, error information, multi-dimensional retrieval query vector set, repair information, and repair context can also be stored in a blockchain node.

[0094] The blockchain referred to in this application is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include an underlying blockchain platform, a platform product service layer, and an application service layer.

[0095] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) refers to the theories, methods, technologies, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0096] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware through computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0097] Further reference Figure 3 As a response to the above Figure 2 To implement the method shown, this application provides an embodiment of an instruction repair device, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0098] like Figure 3 As shown, the instruction repair device 400 of this embodiment includes: an acquisition module 401, a construction module 402, a retrieval module 403, a determination module 404, an integration module 405, and a generation module 406. Wherein: The acquisition module 401 is used to acquire the error information corresponding to the tool invocation instruction when it is detected that the execution of the tool invocation instruction corresponding to the query information fails. The tool invocation instruction is the execution instruction output by the large language model in response to the query information. Module 402 is used to construct a multi-dimensional retrieval query vector set based on tool call instructions, query information, and error information; The retrieval module 403 is used to perform retrieval operations in the hybrid knowledge base based on a multi-dimensional retrieval query vector set, obtain matching repair information, and call the multi-dimensional document vectorized data of the fault in the hybrid knowledge base pre-storage tool. The determination module 404 is used to determine the compliance strategy that matches the application scenario as a domain constraint condition based on the application scenario corresponding to the query information. The integration module 405 is used to integrate query information, tool call instructions, error messages, repair information and domain constraints to generate a structured repair context; The generation module 406 is used to integrate based on the repair context, repair the large model using preset instructions, generate corrected tool call instructions, and execute the corrected tool call instructions.

[0099] This application embodiment constructs a multi-dimensional query vector set and uses a hybrid knowledge base for retrieval, fully integrating diverse and heterogeneous fault repair knowledge to accurately locate the root cause of complex errors. This significantly improves the success rate and efficiency of repairing errors caused by complex tool calls, avoiding business risks caused by repeated retries. By combining application scenarios to determine domain constraints and integrating and generating structured repair contexts, the correction instructions generated by the instruction repair model strictly adapt to domain compliance requirements, solving the problem of insufficient compliance adaptability in existing mechanisms. The overall process achieves knowledge-based, compliant, and efficient fault repair.

[0100] In one embodiment, the construction module 402 includes: The first parsing submodule is used to perform semantic parsing on the query information to obtain a description of the user's intent; The correction submodule is used to perform parameter consistency verification and correction on the user intent description based on the tool call command, so as to obtain the target user intent description. The extended submodule is used to extract resource constraint parameters from the target user intent description, and to semantically extend the resource constraint parameters to obtain an equivalent parameter semantic set. The matching submodule is used to associate and match the equivalent parameter semantic set with the resource restriction configuration specifications in the preset configuration specification knowledge base to generate an intent-preserving query vector. The association submodule is used to extract error mode features from error information, and supplement the error mode features with instruction association based on tool call instructions to obtain an instruction-associated error feature set. The first generation submodule is used to generate error pattern query vectors based on the instruction-associated error feature set; The construction submodule is used to build a multi-dimensional retrieval query vector set by maintaining the query vector based on the error pattern query vector and the intent.

[0101] In one embodiment, the retrieval module 403 includes: The retrieval submodule is used to perform parallel retrieval operations on the hybrid knowledge base by using the error pattern query vector and intent-based query vector to obtain a preliminary set of matching document fragments; The judgment submodule is used to determine whether the number of initially matched document fragments exceeds a preset threshold; The interaction submodule is used to perform deep interactive calculations on the document fragments in the document fragment set with the error mode query vector and the intent preservation query vector respectively through the preset cross encoder to obtain the relevance score of each document fragment. The first sorting submodule is used to sort the document fragment set according to the relevance score to obtain the sorted candidate document fragment set; The `determine` submodule is used to determine the set of document fragments as the sorted candidate set of document fragments if no such determination is made. The extraction submodule is used to extract repair information that matches the error pattern query vector and the intent-maintaining query vector based on the sorted set of candidate document fragments.

[0102] In one embodiment, the determining module 404 includes: The dimension parsing submodule is used to perform scene feature dimension parsing on tool call commands and query information based on the application scenario corresponding to the query information, and generate scene tags. The dimension matching submodule is used to perform multi-dimensional matching between scene tags and the preset scene policy mapping library to obtain candidate compliance policies. The scene policy mapping library stores the mapping relationship between each application scenario and the corresponding compliance policy. The compliance policy is pre-configured with constraint priority rules and descriptions of the consequences of violations. The filtering submodule is used to filter candidate compliance policies based on the operation type of the tool call command, determine the appropriate policy set, and extract the constraint clauses related to the operation type from the policy set. The second generation submodule is used to generate domain constraints based on constraint clauses, constraint priority rules, and descriptions of consequences of violations.

[0103] In one embodiment, the integration module 405 includes: The template acquisition submodule is used to acquire a preset structured repair context template, which includes a fact information area, a knowledge evidence area, and a constraint condition area. The first input submodule is used to fill query information, tool call commands and error information into the corresponding fields of the fact information area to obtain the filled fact information area; The second sorting submodule is used to calculate the confidence score of the repair information using a preset cross encoder, sort the repair information according to the confidence score, and obtain the sorted repair information. The second filling submodule is used to obtain the source annotations of the repair information from the hybrid knowledge base, and fill the sorted repair information, confidence score and source annotations into the corresponding fields of the knowledge evidence area to obtain the filled knowledge evidence area; The third filling submodule is used to extract scenario compliance requirements from domain constraints based on application scenarios, fill the scenario compliance requirements into the corresponding fields of the constraint area, and obtain the filled constraint area. The verification submodule is used to perform causal relationship verification on the filled fact information area and the filled knowledge evidence area, remove the first target data, and obtain the fact information area data and the knowledge evidence area data. The filtering submodule is used to perform a matching check between the filled constraint condition area and the application scenario, filter the second target data, and obtain the constraint condition area data. The first integration submodule is used to integrate the data in the fact information area, the knowledge evidence area, and the constraint condition area to generate a structured repair context.

[0104] In one embodiment, the generation module 406 includes: The second parsing submodule is used to parse error information, extract error features to obtain business level labels, and dynamically adjust the generation parameters of the preset instruction repair large model based on the business level labels. The second integration submodule is used to generate domain-specific system prompts based on application scenarios and domain constraints, and integrate the domain-specific system prompts with the repair context to obtain instruction repair guidance information; The third generation submodule is used to repair the boot information based on the instructions, repair the large model using the instructions with adjusted parameters, and generate the corrected tool call instructions.

[0105] In one embodiment, the instruction repair device 400 further includes: The document acquisition module is used to acquire the document set of the hybrid knowledge base to be built. The document set includes historical fault documents, technical specification documents, strategy configuration documents, and community solution documents. The collection module is used to collect domain text data of the target domain that matches the preset service scenarios of the hybrid knowledge base, and to build a corpus; The fine-tuning module is used to obtain a pre-trained general text vector model. It uses a corpus to fine-tune the pre-trained general text vector model for domain adaptation, resulting in a text vector model adapted to the target domain. The vectorization module is used to vectorize historical fault documents, technical specification documents, strategy configuration documents, and community solution documents using a text vector model to obtain corresponding text vectors. The storage module is used to associate and store text vectors with historical fault documents, technical specification documents, strategy configuration documents, and community solution documents, and to build a retrieval index based on the similarity between text vectors to obtain a hybrid knowledge base.

[0106] To address the aforementioned technical problems, embodiments of this application also provide a computer device. Please refer to [link / reference needed]. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.

[0107] Computer device 6 includes a memory 61, a processor 62, and a network interface 63 that are interconnected via a system bus. It should be noted that only computer device 6 with memory 61, processor 62, and network interface 63 is shown in the figure; however, it should be understood that it is not required to implement all the components shown, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described herein is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0108] Computer devices can include desktop computers, laptops, handheld computers, and cloud servers. These devices allow for human-computer interaction with users through keyboards, mice, remote controls, touchpads, or voice-activated devices.

[0109] The memory 61 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 61 may be an internal storage unit of the computer device 6, such as the hard disk or memory of the computer device 6. In other embodiments, the memory 61 may also be an external storage device of the computer device 6, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 6. Of course, the memory 61 may include both the internal storage unit and its external storage device of the computer device 6. In this embodiment, the memory 61 is typically used to store the operating system and various application software installed on the computer device 6, such as computer-readable instructions for instruction repair methods. In addition, the memory 61 may also be used to temporarily store various types of data that have been output or will be output.

[0110] In some embodiments, processor 62 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. This processor 62 is typically used to control the overall operation of the computer device 6. In this embodiment, processor 62 is used to execute computer-readable instructions stored in memory 61 or to process data, such as computer-readable instructions for executing instruction repair methods.

[0111] The network interface 63 may include a wireless network interface or a wired network interface, which is typically used to establish a communication connection between the computer device 6 and other electronic devices.

[0112] This application embodiment constructs a multi-dimensional query vector set and uses a hybrid knowledge base for retrieval, fully integrating diverse and heterogeneous fault repair knowledge to accurately locate the root cause of complex errors. This significantly improves the success rate and efficiency of repairing errors caused by complex tool calls, avoiding business risks caused by repeated retries. By combining application scenarios to determine domain constraints and integrating and generating structured repair contexts, the correction instructions generated by the instruction repair model strictly adapt to domain compliance requirements, solving the problem of insufficient compliance adaptability in existing mechanisms. The overall process achieves knowledge-based, compliant, and efficient fault repair.

[0113] This application also provides another embodiment, namely, providing a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the instruction repair method described above.

[0114] This application embodiment constructs a multi-dimensional query vector set and uses a hybrid knowledge base for retrieval, fully integrating diverse and heterogeneous fault repair knowledge to accurately locate the root cause of complex errors. This significantly improves the success rate and efficiency of repairing errors caused by complex tool calls, avoiding business risks caused by repeated retries. By combining application scenarios to determine domain constraints and integrating and generating structured repair contexts, the correction instructions generated by the instruction repair model strictly adapt to domain compliance requirements, solving the problem of insufficient compliance adaptability in existing mechanisms. The overall process achieves knowledge-based, compliant, and efficient fault repair.

[0115] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of the various embodiments of this application.

[0116] Obviously, the embodiments described above are only some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the patent scope of this application. This application can be implemented in many different forms; rather, the purpose of providing these embodiments is to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of patent protection of this application.

[0117] The software tools or components not belonging to our company that appear in the embodiments of this application are merely examples and do not represent actual use.

Claims

1. A method for repairing instructions, characterized in that, Includes the following steps: When it is detected that the execution of the tool call instruction corresponding to the query information fails, the error information corresponding to the tool call instruction is obtained. The tool call instruction is the execution instruction output by the large language model in response to the query information. Based on the tool invocation instructions, the query information, and the error information, a multi-dimensional retrieval query vector set is constructed. Based on the multi-dimensional retrieval query vector set, a retrieval operation is performed in the hybrid knowledge base to obtain matching repair information. The hybrid knowledge base pre-storage tool calls the multi-dimensional document vectorized data of the fault. Based on the application scenario corresponding to the query information, the compliance strategy adapted to the application scenario is determined as the domain constraint condition; The query information, the tool invocation instructions, the error information, the repair information, and the domain constraints are integrated to generate a structured repair context; Based on the repair context, the large model is repaired using preset instructions, and the corrected tool call instructions are generated and executed.

2. The method according to claim 1, characterized in that, The step of constructing a multi-dimensional retrieval query vector set based on the tool invocation command, the query information, and the error information specifically includes: The query information is semantically parsed to obtain a description of the user's intent; Based on the tool invocation command, the user intent description is checked and corrected for parameter consistency to obtain the target user intent description; Resource restriction parameters are extracted from the target user intent description, and the resource restriction parameters are semantically extended to obtain an equivalent parameter semantic set. The equivalent parameter semantic set is associated and matched with the resource restriction configuration specifications in the preset configuration specification knowledge base to generate an intent-preserving query vector; Error pattern features are extracted from the error information, and instruction association is performed on the error pattern features based on the tool invocation instructions to obtain an instruction-associated error feature set; Based on the error feature set associated with the instruction, an error pattern query vector is generated; A multi-dimensional retrieval query vector set is constructed based on the error pattern query vector and the intent-maintaining query vector.

3. The method according to claim 1, characterized in that, Before the step of performing a retrieval operation in the hybrid knowledge base based on the multi-dimensional retrieval query vector set to obtain matching repair information, the method further includes: Obtain the document set of the hybrid knowledge base to be built, which includes historical fault documents, technical specification documents, strategy configuration documents, and community solution documents; Collect domain text data of the target domain that matches the preset service scenario of the hybrid knowledge base, and construct a corpus; Obtain a pre-trained general text vector model, and use the corpus to perform domain adaptation fine-tuning on the pre-trained general text vector model to obtain a text vector model adapted to the target domain. Using the text vector model, the historical fault documents, the technical specification documents, the strategy configuration documents, and the community solution documents are vectorized to obtain corresponding text vectors. The text vectors are associated and stored with the historical fault documents, the technical specification documents, the strategy configuration documents, and the community solution documents. A retrieval index is constructed based on the similarity between the text vectors to obtain the hybrid knowledge base.

4. The method according to claim 3, characterized in that, The multi-dimensional retrieval query vector set includes error pattern query vectors and intent preservation query vectors; The step of performing a retrieval operation in the hybrid knowledge base based on the multi-dimensional retrieval query vector set to obtain matching repair information specifically includes: By using the error pattern query vector and the intent-preserving query vector, a parallel retrieval operation is performed on the hybrid knowledge base to obtain a preliminary set of matched document fragments; Determine whether the number of the initially matched document fragment set exceeds a preset threshold; If so, then through a preset cross encoder, the document fragments in the document fragment set are respectively subjected to deep interactive calculation with the error pattern query vector and the intent preservation query vector to obtain the relevance score of each document fragment; Based on the relevance score, the document fragment set is sorted to obtain a sorted candidate document fragment set; If not, then the set of document fragments is determined as the sorted set of candidate document fragments; Based on the sorted set of candidate document fragments, repair information that matches the error pattern query vector and the intent to maintain query vector is extracted.

5. The method according to claim 1, characterized in that, The step of determining the compliance strategy adapted to the application scenario based on the query information as the domain constraint condition specifically includes: Based on the application scenario corresponding to the query information, the tool call command and the query information are analyzed according to the scenario feature dimension to generate scenario tags; The scenario tags are matched with a preset scenario policy mapping library in multiple dimensions to obtain candidate compliance policies. The scenario policy mapping library stores the mapping relationship between each application scenario and the corresponding compliance policy. The compliance policy is pre-configured with constraint priority rules and explanations of the consequences of violations. Based on the operation type of the tool invocation command, the candidate compliance strategies are screened to determine the appropriate strategy set, and the constraint clauses related to the operation type are extracted from the strategy set. Based on the aforementioned constraint clauses, constraint priority rules, and descriptions of the consequences of violations, domain constraints are generated.

6. The method according to claim 1, characterized in that, The step of integrating the query information, the tool invocation command, the error information, the repair information, and the domain constraints to generate a structured repair context specifically includes: Obtain a preset structured repair context template, the template including a fact information area, a knowledge evidence area, and a constraint condition area; The query information, the tool call command, and the error information are respectively filled into the corresponding fields of the fact information area to obtain the filled fact information area; A preset cross encoder is used to calculate the confidence score of the repair information, and the repair information is sorted according to the confidence score to obtain the sorted repair information; The source annotations of the repair information are obtained from the hybrid knowledge base, and the sorted repair information, the confidence score and the source annotations are filled into the corresponding fields of the knowledge evidence area to obtain the filled knowledge evidence area. Based on the application scenario, scenario compliance requirements are extracted from the domain constraints, and the scenario compliance requirements are filled into the corresponding fields of the constraint area to obtain the filled constraint area. A causal correlation test is performed on the filled fact information area and the filled knowledge evidence area, and the first target data is removed to obtain the fact information area data and the knowledge evidence area data. The filled constraint area is matched with the application scenario, and the second target data is filtered to obtain the constraint area data. The data in the factual information area, the data in the knowledge evidence area, and the data in the constraint area are integrated to generate a structured repair context.

7. The method according to claim 1, characterized in that, The step of integrating based on the repair context, repairing the large model using preset instructions, and generating corrected tool call instructions specifically includes: The error information is parsed, and error features are extracted to obtain business level labels. Based on the business level labels, the generation parameters of the preset instruction repair large model are dynamically adjusted. Based on the application scenario and the domain constraints, a domain-specific system prompt is generated. The domain-specific system prompt and the repair context are then integrated to obtain instruction repair guidance information. Based on the instruction repair guidance information, the large model is repaired using the instruction with adjusted parameters, and the corrected tool call instruction is generated.

8. A command repair device, characterized in that, include: The acquisition module is used to acquire error information corresponding to the tool invocation instruction when it is detected that the execution of the tool invocation instruction corresponding to the query information fails. The tool invocation instruction is the execution instruction output by the large language model in response to the query information. The construction module is used to construct a multi-dimensional retrieval query vector set based on the tool invocation instructions, the query information, and the error information; The retrieval module is used to perform retrieval operations in the hybrid knowledge base based on the multi-dimensional retrieval query vector set to obtain matching repair information. The hybrid knowledge base pre-storage tool calls the multi-dimensional document vectorized data of the fault. The determination module is used to determine the compliance strategy that adapts to the application scenario as a domain constraint condition based on the application scenario corresponding to the query information. An integration module is used to integrate the query information, the tool call instructions, the error information, the repair information, and the domain constraints to generate a structured repair context; The generation module is used to integrate based on the repair context, repair the large model using preset instructions, generate corrected tool call instructions, and execute the corrected tool call instructions.

9. A computer device, characterized in that, The device includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor, when executing the computer-readable instructions, implements the steps of the instruction repair method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the instruction repair method as described in any one of claims 1 to 7.

Images