Risk control index generation method, device, storage medium and program product

Abstract

The specification provides a risk control index generation method, device, storage medium and program product. An index requirement in natural language form input by a user is acquired, semantic analysis is performed on the index requirement to extract a plurality of key fields representing a business intent of a risk control index, and structured data is generated; a code generation model injected with risk control domain knowledge is called to generate index code based on the structured data, a preset test sample is input into the index code and run, and whether the index code passes a running dimension verification is determined based on a running result; a code review model is called to check a business logic of the index code to determine whether the index code passes a logic dimension verification; in a case where the index code passes the running dimension verification and passes the logic dimension verification, business data associated with the risk control index is input into the index code and run to generate the risk control index.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of artificial intelligence technology, and in particular to a method, device, storage medium and program product for generating risk control indicators. Background Technology

[0002] Risk control indicators are the core basis for risk assessment, credit approval, and abnormal transaction monitoring in fields such as financial lending and corporate risk control. Their calculation accuracy and generation timeliness directly determine the reliability of risk control decisions. With the continuous expansion of business scenarios, the types and calculation logic of risk control indicators are becoming increasingly complex, and the personalized and dynamic characteristics of indicator requirements are becoming more and more significant. How to efficiently and accurately generate risk control indicators that conform to business rules has become the key to the construction and iteration of risk control systems.

[0003] The rapid development of language modeling technologies, such as Large Language Models (MLMs), has driven the automation of code generation. Related technologies have attempted to automatically generate risk control indicator calculation code based on natural language-based indicator requirements using language models, which has shortened the manual development cycle and lowered the technical threshold to some extent. However, general-purpose language models, lacking understanding of business rules and enterprise data structures in the risk control field, often generate code with numerous errors and poor quality. Furthermore, in these technologies, code verification mainly relies on manual verification or simple checks based on whether the code can run. The verification results are not comprehensive or reliable enough, leading to potential errors in the final code used to calculate risk control indicators. Risk control indicators generated from flawed code may deviate from the actual business situation, resulting in inaccurate subsequent risk assessments. Therefore, a more efficient and accurate solution for generating risk control indicators is needed. Summary of the Invention

[0004] In view of the above, one or more embodiments of this specification provide the following technical solutions: According to a first aspect of one or more embodiments of this specification, a method for generating risk control indicators is proposed, the method comprising: Obtain the indicator requirements in natural language form input by the user, which describe the risk control indicators to be generated; Semantic parsing is performed on the required indicators to extract multiple key fields that represent the business intent of the risk control indicators and generate structured data. The code generation model generates indicator codes based on the structured data, wherein the code generation model incorporates risk control domain knowledge through supervised fine-tuning and / or enhanced retrieval. Input the preset test sample into the indicator code and run it. Based on the running result, determine whether the indicator code passes the verification of the running dimension. The code review model is invoked to verify the business logic of the indicator code in order to determine whether the indicator code passes the verification at the logical dimension. If the indicator code passes the verification of the operational dimension and the logical dimension, the business data associated with the risk control indicator is input into the indicator code and run to generate the risk control indicator.

[0005] According to a second aspect of the embodiments of this specification, an electronic device is provided, comprising: processor; Memory used to store processor-executable instructions; Wherein, when the processor executes the executable instructions, it is used to implement the method described in the first aspect.

[0006] According to a third aspect of the embodiments of this specification, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps of the method described in the first aspect.

[0007] According to a fourth aspect of the embodiments of this specification, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described in the first aspect.

[0008] As can be seen from the above embodiments, after obtaining the risk control indicator requirements in natural language input by the user, the embodiments of this specification can perform semantic parsing on the indicator requirements to extract key fields representing the business intent of the risk control indicator and generate structured data. Then, using supervised fine-tuning and / or enhanced retrieval, a code generation model incorporating risk control domain knowledge is used to generate indicator code based on the structured data. The indicator code is then validated in terms of its operational dimensions using preset test samples as input. Simultaneously, a code review model can be invoked to validate the indicator code in terms of its logical dimensions. If the indicator code passes the validation in both dimensions, then business data related to the risk control indicator is input and the indicator code is run to generate the final risk control indicator.

[0009] By transforming natural language-based indicator requirements into structured data representing the business intent of risk control indicators, user business intent can be accurately reproduced, significantly reducing the transmission deviation and usage threshold of indicator requirements. By incorporating risk control domain knowledge into the code generation model through supervised fine-tuning and / or enhanced retrieval, the generated indicator code can better align with risk control business specifications and data calculation logic, effectively improving the professionalism and accuracy of code generation. By setting up a dual verification mechanism across both operational and logical dimensions, the executableness and operational stability of the indicator code are ensured, while the compliance and correctness of the code's business logic are verified, avoiding the problem of code that runs but has incorrect calculation logic. The overall solution automates the entire process from requirement analysis and code generation to dual verification and indicator output, significantly reducing manual intervention and development cycle. While improving the efficiency of risk control indicator generation, it effectively ensures the accuracy, reliability, and business compliance of the final risk control indicators, better adapting to diverse and personalized risk control indicator generation needs. Attached Figure Description

[0010] Figure 1 This is an exemplary embodiment of an application scenario diagram.

[0011] Figure 2 This is a flowchart of a risk control indicator generation method provided in an exemplary embodiment.

[0012] Figure 3 This is a schematic diagram of a risk control indicator generation method provided in an exemplary embodiment.

[0013] Figure 4 This is an exemplary embodiment of a diagram illustrating the injection of risk control domain knowledge into a code generation model through retrieval enhancement.

[0014] Figure 5 This is an exemplary embodiment illustrating the injection of risk control domain knowledge into a code generation model through supervised fine-tuning.

[0015] Figure 6 This is a schematic diagram illustrating the iterative correction of indicator codes provided in an exemplary embodiment.

[0016] Figure 7 This is a schematic diagram of the architecture of a risk control indicator generation system provided in an exemplary embodiment.

[0017] Figure 8 This is a flowchart of a risk control indicator generation method provided in an exemplary embodiment.

[0018] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an exemplary embodiment. Detailed Implementation

[0019] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0020] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with relevant laws, regulations and standards, and corresponding operation entry points shall be provided for users to choose to authorize or refuse.

[0021] Risk control indicators (RCIs) are structured feature variables used to quantify and assess the level of risk faced by enterprises or users in their business operations (such as credit approval, transaction monitoring, anti-fraud, and compliance review). These indicators are typically generated from raw business data (such as transaction records, user behavior logs, and enterprise registration information) through specific logical rules or mathematical operations, and can serve as input features for risk assessment models (such as scorecards, decision trees, and machine learning models). The accuracy, coverage, and timeliness of RCIs directly affect the effectiveness of the risk control system.

[0022] The development process of traditional risk control metrics heavily relies on manual collaboration. First, risk control experts propose metric requirements based on business experience (e.g., "calculate the number of cross-platform loan applications a customer has made in the past 90 days"). Then, developers translate these requirements into executable data processing logic (such as writing SQL queries, ETL scripts, or Python functions). Raw data is then extracted from the enterprise database or data warehouse for processing, ultimately generating structured metrics that can be used for risk assessment model training or real-time decision-making. This process typically involves multiple stages, including iterative communication of requirements, code development, testing and verification, and deployment, taking weeks or even months.

[0023] To improve the efficiency of risk control indicator development, the industry has explored various automated or semi-automated solutions. For example, there are rule-template-based risk control indicator configuration platforms. These platforms offer an interactive interface where risk control experts select predefined data fields (such as "transaction amount" and "overdue days") and combine simple logic (such as "summation," "count," and "sliding window average") via drag-and-drop or drop-down menus. The system automatically generates corresponding SQL or calculation logic. However, this solution only supports preset aggregate functions and logic combinations, and cannot handle complex business semantics (such as "the number of times the maximum daily transaction amount exceeds three times the monthly average in the past 30 days"). Furthermore, all optional fields and operators must be registered and mapped by developers in advance, and new data sources or new logic still require several weeks of development time. Risk control experts must learn the platform's operating rules and cannot directly describe requirements in business language, leading to high communication costs and a high risk of errors.

[0024] Another approach is the use of AutoFeatureEngineering tools. These tools can automatically generate a large number of candidate features based on the original data table using algorithms (such as Cartesian product, time window statistics, cross-combination, etc.). Then, they use model evaluation to filter out effective features, ultimately obtaining risk control indicators. However, the risk control indicators generated by this approach are mostly mathematical combinations, difficult to interpret, and may contain a large number of "noise features" with no business significance. Furthermore, it cannot generate risk control indicators based on "specific risk scenarios" proposed by risk control experts (such as "equipment sharing rate for identifying group fraud"), but rather relies on blind exploration.

[0025] With the development of language modeling technology, related technologies have attempted to automatically generate risk control indicator calculation code based on indicator requirements in natural language. Users can input indicator requirements described in natural language (e.g., "Write an SQL query to retrieve the total order amount for the last 30 days"), and the language model can generate code based on these requirements. Running this code will then yield the risk control indicator. However, general-purpose language models lack understanding of business rules and internal data table structures in the risk control field. This often results in code that references non-existent fields, uses incorrect time partitioning, or ignores null values, leading to incorrect indicator calculation results. Language models generate code based solely on surface text matching, making it difficult to understand crucial business details such as whether "active users in the last 30 days" include canceled accounts or whether refunds have been excluded from "transaction amount," causing semantic drift in the indicators. Furthermore, code verification relies primarily on manual verification or simple checks based on code execution. The verification results are not comprehensive or reliable enough, potentially leading to errors in the final code used to calculate risk control indicators. This results in risk control indicators that deviate from actual business needs, impacting risk assessment results. Therefore, it is necessary to provide a more efficient and accurate solution for generating risk control indicators.

[0026] Based on this, this specification provides a method for generating risk control indicators. After obtaining the indicator requirements in natural language input by the user, the method performs semantic parsing on the indicator requirements to extract key fields representing the business intent of the risk control indicator and generate structured data. Then, using supervised fine-tuning and / or enhanced retrieval, a code generation model incorporating risk control domain knowledge generates indicator code based on the structured data. Pre-set test samples are used as input to verify the indicator code in its operational dimensions. Simultaneously, a code review model can be invoked to verify the indicator code in its logical dimensions. If the indicator code passes the verification in both dimensions, relevant business data for the risk control indicator is input and the indicator code is run to generate the final risk control indicator.

[0027] By transforming natural language-based indicator requirements into structured data representing the business intent of risk control indicators, user business intent can be accurately reproduced, significantly reducing the transmission deviation and usage threshold of indicator requirements. By incorporating risk control domain knowledge into the code generation model through supervised fine-tuning and / or enhanced retrieval, the generated indicator code can better align with risk control business specifications and data calculation logic, effectively improving the professionalism and accuracy of code generation. By setting up a dual verification mechanism across both operational and logical dimensions, the executableness and operational stability of the indicator code are ensured, while the compliance and correctness of the code's business logic are verified, avoiding the problem of code that runs but has incorrect calculation logic. The overall solution automates the entire process from requirement analysis and code generation to dual verification and indicator output, significantly reducing manual intervention and development cycle. While improving the efficiency of risk control indicator generation, it effectively ensures the accuracy, reliability, and business compliance of the final risk control indicators, better adapting to diverse and personalized risk control indicator generation needs.

[0028] The risk control indicator generation method provided in the embodiments of this specification can be executed by various electronic devices, such as mobile phones, tablets, laptops, physical servers, cloud servers, server clusters, etc. The embodiments of this specification do not impose any limitations.

[0029] The risk control indicators in the embodiments of this specification can be various structured characteristic variables that quantify the risk level faced by enterprises or users in their business activities (such as credit approval, transaction monitoring, anti-fraud, compliance review, etc.). Typical examples include, but are not limited to, the following: number of customer overdue payments in the past 30 days, the proportion of the enterprise's external guarantees to its net assets, and the frequency of user equipment replacement.

[0030] Figure 1 This is a schematic diagram of the architecture of a risk control indicator generation system provided in an exemplary embodiment. For example... Figure 1As shown, the system may include a server 11, a network 12, and several electronic devices, such as a PC (Personal Computer) 13, a mobile phone 14, etc.

[0031] Server 11 can be a physical server containing an independent host, or it can be a virtual server hosted in a host cluster. During operation, server 11 can run server-side programs for a certain application to implement the relevant functions of that application. For example, when server 11 runs a program for generating risk control indicators, it can function as a corresponding risk control indicator generation service platform.

[0032] PC13 and mobile phone14 are just some of the types of electronic devices that users can use. In reality, users can obviously also use electronic devices such as tablets, laptops, PDAs (Personal Digital Assistants), wearable devices (such as smart glasses, smartwatches, etc.), etc., and one or more embodiments in this specification do not limit this. During operation, the electronic device can run a client-side program of an application to achieve the relevant functions of that application. For example, when the electronic device runs a risk control indicator generation service program, it can act as a client for that risk control indicator generation service. The client application of the aforementioned risk control indicator generation service can be launched and run on the electronic device. This client-side program can be a native application installed on the electronic device, or it can be a mini-program, quick app, or other similar form. Of course, when using web technologies such as HTML5 or similar, the relevant functions can be achieved through a page displayed by a browser. This browser can be a standalone browser application or a browser module embedded in some applications.

[0033] As for the network 12 that enables interaction between electronic devices such as PC13 and mobile phone 14 and server 11, communication can be achieved using either wired or wireless networks, depending on the communication methods supported by the respective electronic devices. This specification does not impose any restrictions on this. For example, PC13 can support both wired and wireless communication, so it can use either wired or wireless networks as needed. Mobile phone 14 typically only supports wireless communication, so it can use a wireless network for communication.

[0034] For example, a risk control indicator intelligent agent can be deployed on server 11. Users can input indicator requirements in natural language through clients on electronic devices such as PC 13 and mobile phones 14 and send them to server 11. The risk control indicator intelligent agent on server 11 can call the code generation model to automatically generate indicator code based on the indicator requirements. Then, it can call the code review model to verify the business logic of the generated indicator code and use test samples from the test sample set as input to run the indicator code to verify the operation dimension of the indicator code. After the indicator code passes the above two dimensions of verification, it will automatically run the code and generate the corresponding risk control indicator. Then, the risk control indicator can be stored in the preset risk control indicator library 15.

[0035] The following combination Figure 2 and Figure 3 The method for generating risk control indicators in the embodiments of this specification is described, such as... Figure 2 As shown, the method for generating this risk control indicator may include the following steps: S202. Obtain the indicator requirements of the risk control indicators in natural language form input by the user, wherein the indicator requirements are used to describe the risk control indicators to be generated. In step S202, the user's input of risk control indicator requirements described in natural language can be obtained. These requirements describe the risk control indicators to be generated, such as the definition of the indicator, its constraints, etc. For example, an indicator requirement could be "the number of overdue payments by a customer in the past 30 days." By supporting input in natural language, the barrier to entry for users is significantly reduced, allowing them to initiate indicator generation requests without relying on professional developers, thus improving the usability and accessibility of the entire risk control indicator generation process.

[0036] S204. Perform semantic parsing on the indicator requirements to extract multiple key fields that represent the business intent of the risk control indicators and generate structured data. In step S204, considering that the indicator requirements are unstructured data in natural language form, in order to transform them into structured data that is easy for machines to understand, such as... Figure 3 As shown, semantic parsing of indicator requirements can be performed, and the natural language form of indicator requirements can be structurally decomposed to identify and extract key fields that represent the business intent of risk control indicators. These fields include, for example, business entities, time windows, statistical conditions, aggregation methods, and filtering rules. These key fields are then organized into structured data that machines can directly recognize and process, achieving the conversion from unstructured natural language to standardized machine input. For instance, indicator requirements can be transformed into logical description objects in JSON format.

[0037] By transforming natural language-based metrics into structured data, we can accurately reproduce the user's true business intent, eliminate the ambiguity and vagueness of natural language expressions, provide a reliable input basis for subsequent code generation, and effectively avoid code logic errors caused by misunderstandings of requirements.

[0038] S206. The code generation model is invoked to generate indicator codes based on the structured data, wherein the code generation model incorporates risk control domain knowledge through supervised fine-tuning and / or enhanced retrieval. In step S206, a code generation model incorporating risk control domain knowledge can be invoked to automatically generate indicator codes for calculating risk control metrics based on the structured data. This code generation model can be a general-purpose language model or a proprietary language model that has been supervised and fine-tuned using risk control domain knowledge. For example, risk control domain knowledge can be integrated into the code generation model through one or more methods such as supervised fine-tuning and retrieval enhancement, enabling the model to possess prior knowledge in areas such as risk control business rules, data dictionaries, field mappings, and calculation paradigms.

[0039] Compared to general code generation models, injecting risk control domain knowledge into the model can improve the business matching degree of indicator code, reduce problems such as field errors, non-standard logic, and non-compliance with risk control constraints, and at the same time save the tedious process of manual coding and debugging, thus greatly improving the efficiency of indicator code generation.

[0040] S208. Input the preset test sample into the indicator code and run it. Based on the running result, determine whether the indicator code passes the verification of the running dimension. In step S208, as Figure 3 As shown, pre-built test samples covering various typical scenarios can be used as input to load and run the generated indicator code. By monitoring whether the indicator code compiles and executes normally, whether the running results are within a reasonable range, and whether there are timeouts or abnormal crashes, the system comprehensively determines whether the indicator code passes the verification of the running dimension. Through this step, problems such as code syntax errors, running anomalies, unreasonable results, and performance bottlenecks can be exposed in advance before integrating real business data, avoiding business data distortion or system anomalies caused by code execution failures and ensuring the reliability of the indicator code.

[0041] S210. Call the code review model to verify the business logic of the indicator code to determine whether the indicator code has passed the logic dimension verification; In step S210, a code review model can be invoked to verify the business logic of the indicator code. The focus is on identifying indicators that function correctly but have flawed business logic (e.g., violate business rules, pose compliance risks), and based on this, determining whether the generated indicator code passes the logical dimension verification. The code review model can also be a language model. For example, the code review model and the code generation model can be different instances of the same model, or the code review model can be a custom model obtained by supervised fine-tuning a general language model. For instance, in some embodiments, the code review model can be a general language model. When invoking the code review model to verify the business logic of the indicator code, pre-set business logic rules and the indicator code can be used to construct prompts to guide the language model in verifying the indicator code.

[0042] By adding an independent logic verification step, the core problem of "code can run but business results are incorrect" in related technologies is effectively solved, ensuring that the indicator code is not only executable, but also complies with the risk control business definition and compliance requirements, thereby improving the business effectiveness of the final risk control indicators.

[0043] S212. If the indicator code passes the verification of the running dimension and the logical dimension, the business data associated with the risk control indicator is input into the indicator code and run to generate the risk control indicator.

[0044] In step S212, provided the indicator code passes verification in both the operational and logical dimensions, real business data related to the current risk control indicator can be loaded into the indicator code as input and the code executed, ultimately outputting usable risk control indicator results. The generated risk control indicators can be stored in a risk control indicator library and used as input for risk prediction models during the prediction or training phase. While ensuring automation and high efficiency, a security mechanism of verification before deployment is implemented, preventing erroneous or non-compliant code from directly affecting real business data. This ensures that the final generated risk control indicators are accurate, reliable, and compliant, and can be directly used in actual business scenarios such as risk assessment and review decisions.

[0045] In related technologies, indicator code is typically generated directly from user-input natural language indicator requirements using a generic language model. However, since this generic language model lacks understanding of the enterprise's internal data table structure, field business meanings, data permission boundaries, and quality constraints, generating indicator code directly from natural language indicator requirements is prone to problems such as mismatches between business fields and actual fields stored in the database, incorrect table or field names, and inconsistent data types. This results in generated code that cannot be directly integrated with real business data, requiring developers to manually correct and debug fields, significantly reducing the efficiency of automated generation and the usability of the code. Therefore, in some embodiments, the risk control domain knowledge incorporated into the code generation model can include an enterprise data dictionary. The enterprise data dictionary is a mapping table between business fields and enterprise database fields, recording the database location (database name, table name), specific field name, data type, calculation rules, etc., for each business field.

[0046] For example, assuming the requirement is "calculate a company's debt-to-asset ratio", the business field "debt-to-asset ratio" can be extracted. Then, by querying the enterprise data dictionary, the database information corresponding to "debt-to-asset ratio" can be found. For example, the database is enterprise_risk_db, the table name is t_financial_data, the field name is asset_liability_ratio, and it may even include the calculation rule, namely, debt-to-asset ratio = total liabilities / total assets.

[0047] In the process of calling the code generation model to generate indicator code, at least some of the business fields in the structured data can be mapped one by one to the actual fields corresponding to the target database that stores the risk control indicator-related business data based on the enterprise's data dictionary. This completes the standardized conversion from business layer fields to database layer fields. Then, the code generation model is called based on the mapped structured data to generate indicator code that is adapted to the target database structure.

[0048] The above methods can effectively eliminate the field differences between business descriptions and actual database storage, ensuring that the generated indicator code can be directly connected to the target database for execution without the need for manual secondary correction of field mapping relationships. This reduces the workload of code debugging and adaptation, and improves the automation, executability, and business adaptability of code generation.

[0049] In some embodiments, to ensure that the generated indicator code aligns with actual business needs, risk control domain knowledge can be incorporated into the code generation process by enhancing the retrieval method. For example, ... Figure 4As shown, when calling the code generation model to generate indicator code based on structured data, the system can first retrieve target knowledge highly relevant to the aforementioned structured data from a pre-built risk control domain knowledge base. For example, multiple key fields representing the business intent of risk control indicators extracted from indicator requirements can be used as search terms to retrieve target knowledge from the risk control domain knowledge base that has a higher relevance than a preset relevance. Then, the retrieved target knowledge can be combined with the structured data to construct prompts that fit the current risk control indicator requirements. These prompts can then guide the code generation model, allowing it to generate indicator code that adapts to the enterprise's database structure and complies with business rules and compliance requirements, based on a thorough understanding of the target knowledge. The target knowledge may include one or more of the following key knowledge: general and enterprise-specific business rules in the risk control field (such as "M1 overdue = overdue for 1-30 days", "gang fraud often manifests as shared devices / IPs", etc.), historical risk control indicator templates covering historical risk control indicator definitions and standard execution codes, enterprise data dictionary used to map business fields in indicator requirements to fields in the target database (which stores business data related to risk control indicators), and data compliance constraints specific to risk control scenarios (such as prohibited sensitive fields).

[0050] By pre-building a risk control knowledge base, when generating indicator codes, the model retrieves highly relevant risk control knowledge of various types from the knowledge base. This ensures that the generated code fully complies with risk control business specifications, reuses mature historical experience, and adapts to the enterprise's data architecture. The generated indicator codes are not only significantly improved in terms of professionalism, compliance, and business adaptability, but also reduce the workload of manual debugging and correction. This further improves the automation, accuracy, and efficiency of indicator code generation, ensuring that the risk control indicators generated based on this code can accurately match the actual business and compliance requirements.

[0051] In some embodiments, the code generation model can also incorporate risk control domain knowledge through supervised fine-tuning. For example, ... Figure 5As shown, we can first collect and obtain the indicator definitions (i.e., indicator definitions in natural language form) corresponding to historical risk control indicators, as well as the standard executable code that matches each indicator definition and can be practically implemented, to construct a training sample set. Then, we use the indicator definitions as input data for the basic language model and the corresponding standard executable code as supervision labels for model training. We can perform domain-adaptive training on the basic language model through supervised fine-tuning. For example, based on the difference between the predicted code output by the language model and the standard executable code, we can adjust the model parameters of the language model so that it can fully learn the mapping rules, business logic, and code specifications of risk control indicators from definition to executable code, ultimately obtaining a code generation model adapted to risk control scenarios. Through the above method, the code generation model can learn the indicator logic and code paradigm of the risk control domain, overcome the problem of insufficient adaptability of general models in risk control scenarios, and improve the automation level and reliability of risk control indicator code generation.

[0052] In some embodiments, multiple key fields extracted after semantic parsing of the indicator requirements in natural language form can cover the core elements representing the business intent of risk control indicators. Specifically, they may include one or more of the following: (1) the business entities involved in the risk control indicators, i.e., the core business objects around which the indicator calculation revolves (such as customers, transactions, loan applications, merchants, etc.), used to clarify the calculation subject and data source of the indicators. (2) the time window corresponding to the business data used to calculate the risk control indicators, i.e., the time range of indicator statistics (such as the last 30 days, the last 90 days, etc.), used to define the filtering boundary of business data and ensure the accuracy of the time dimension of indicator calculation. (3) the calculation logic of the risk control indicators, i.e. the specific statistical methods and operation rules of the indicators (such as counting, summation, percentage calculation, average calculation, etc.), used to clarify the core calculation paradigm of the indicators. (4) the constraints of the risk control indicators, i.e. the business norms, numerical restrictions, and compliance requirements that must be followed in the indicator calculation process (such as numerical range constraints, field non-empty constraints, compliance verification rules, etc.), used to ensure the compliance and rationality of indicator calculation.

[0053] By extracting the aforementioned core key fields, the business logic of risk control indicator requirements can be comprehensively and accurately decomposed, transforming vague natural language requirements into clear, specific, and quantifiable structured elements. This provides an accurate and reliable input foundation for subsequent field mapping based on the enterprise data dictionary and the generation of indicator codes by calling the code generation model, effectively avoiding problems such as code generation errors and indicator calculation deviations caused by incomplete requirement analysis and omission of key information.

[0054] In related technologies, when the generated indicator code fails verification in the operational or logical dimensions, it typically requires manual investigation of the failure reasons, manual code modification, and re-verification. This not only results in extremely low automation and long code correction cycles but also heavily relies on the business and technical experience of developers, easily leading to inaccurate corrections and ineffective repeated debugging, thus failing to form an automated code correction loop. To address these issues, in some embodiments, such as... Figure 6 As shown, an automated iterative correction and verification mechanism has also been added. For example, if the indicator code fails verification in either the operational or logical dimension, the indicator code can be used as the current code to be corrected and a code correction operation can be performed. By using the code to be corrected and the verification feedback information indicating the reason for the failure to pass verification to construct prompt words, the code generation model is guided to make targeted corrections to the code to be corrected to obtain the corrected code. Then, the corrected code is re-verified in both the operational and logical dimensions. If it is determined that the code to be corrected still fails verification in either dimension, and / or the number of corrections has not reached the preset number, the code correction operation is returned to continue, realizing iterative correction and verification until the code passes dual verification or reaches the preset number of corrections.

[0055] The above solution enables fully automated closed-loop correction after code verification failure, eliminating the need for manual error investigation and code modification. This significantly reduces reliance on manual intervention and debugging costs, effectively shortening the code correction cycle. Furthermore, the prompt words built based on verification feedback information allow the model to accurately locate and fix code runtime anomalies and business logic issues. Combined with a preset number of iteration correction mechanisms, the solution significantly improves the success rate of the code ultimately passing dual verification while maintaining correction efficiency. This further improves the fully automated system from code generation and multi-dimensional verification to intelligent correction, effectively enhancing the overall efficiency, stability, and reliability of risk control indicator generation.

[0056] In some embodiments, verification feedback information can be specifically generated based on the verification dimensions where the indicator code failed, ensuring that the feedback content accurately matches the error type and provides a clear basis for code correction. For example, when the indicator code fails the runtime dimension verification, the verification feedback information can be an error log automatically generated by the system during the execution of the code to be corrected. This error log can record in detail the specific anomalies at the code execution level, such as missing fields, syntax errors, runtime crashes, timeout exceptions, data type mismatches, and other key information that can directly pinpoint runtime failures. When the code to be corrected fails the logic dimension verification, the verification feedback information can be review opinions output by the code review model and presented in natural language. These review opinions can be combined with risk control business rules to clearly and intuitively point out the specific problems existing in the code to be corrected at the business logic level, such as statistical deviations, calculation logic that does not meet risk control requirements, violations of data compliance constraints, omissions of business rules, and other core logical errors.

[0057] In some embodiments, if the number of automated iterations for correction reaches a preset number and the indicator code still fails verification, a structured error report can be generated based on the verification feedback information (e.g., error logs or review comments) and fed back to the developers. This allows the developers to quickly locate code errors and perform error debugging based on the verification feedback information.

[0058] In related technologies, the verification of the operation dimension of indicator code often simply judges whether the code can start execution. The verification dimension is single and the coverage of the scenario is one-sided. It cannot effectively identify hidden operation problems such as abnormal results, uncovered logical branches, timeouts, and memory overflows. It is very easy for the code to have operation failures such as calculation distortion, program crashes, and performance bottlenecks after connecting to real business data, which seriously affects the stability and reliability of risk control indicator generation. In view of the above problems, in some embodiments, when determining whether the indicator code has passed the verification of the operation dimension based on the operation result, a multi-dimensional and full-coverage judgment rule can be adopted. That is, when the operation result indicates that the indicator code has any of the following problems, it is determined that the indicator code has not passed the verification of the operation dimension. The above problems include any of the following: (1) The indicator code has not run successfully; The indicator code has not run successfully, usually because the indicator code has basic problems such as syntax errors and field reference errors, which prevent it from executing normally. For example, the indicator code for counting the number of customers overdue in the past 30 days cannot start execution because the database field overdue_days is mistakenly written as overdue_day. (2) The result is not within the preset range; the result is not within the preset range, which means that the calculation result exceeds the reasonable value range agreed upon by the risk control business. For example, the preset reasonable range for calculating the proportion of overdue transactions of customers is [0,1], but the code execution result is 1.3 or -0.2, which obviously violates the business value rules. (3) The result is inconsistent with the preset standard result; the result is inconsistent with the preset standard result, which means that the output of the code under the standard test sample does not match the known correct result. For example, in the test sample, the customer has a total of 5 transactions in the past 30 days and 2 overdue transactions. The standard proportion result is 0.4, while the code execution result is 0.2, which is a calculation logic error. (4) The result does not cover the key branches of the indicator code; the result does not cover the key branches of the indicator code, which means that the core logic branches in the code have not been tested and executed. For example, the indicator code contains the branch logic of "calculate the proportion if there is a valid transaction and set the result to 0 if there is no valid transaction", but the test only uses the sample with transactions, and the key branches without transactions are not triggered and covered. (5) The indicator code runs for longer than the preset time. The indicator code runs for longer than the preset time, which means that the code execution efficiency is not up to standard. For example, the preset calculation time for a single customer indicator is no more than 5 seconds. However, the code takes 8 seconds to run because it does not configure a database index and uses a full table scan to query data, which cannot meet the performance requirements of batch calculation. (6) Memory overflow occurs during operation. Memory overflow during operation means that the code exceeds the memory usage limit due to unreasonable data loading method or loop logic defects. For example, when batch calculating the risk control indicators of all customers, the code loads a large amount of transaction data at once without pagination, which causes memory overflow and leads to abnormal program termination.

[0059] By constructing multi-dimensional verification rules that include execution status, result accuracy, branch coverage, runtime performance, and resource consumption, it is possible to comprehensively and meticulously investigate various explicit and implicit problems in the indicator code at the runtime level before accessing real business data. This effectively avoids later business failures caused by incomplete verification, significantly improves the runtime stability, execution reliability, and calculation accuracy of the indicator code, and also provides clear and specific judgment criteria for subsequent code corrections, further improving the verification system of risk control indicator code.

[0060] In some embodiments, to more comprehensively and meticulously verify the generated indicator code, a test sample set can be pre-constructed. This test sample set includes multiple test samples for verifying the code, each associated with a standard execution result calculated based on the risk control indicator's calculation logic. The test samples in this set cover various key types, such as regular test samples, critical test samples, data missing test samples, and abnormal data samples. Regular test samples refer to those where the code's input data or final calculation result falls within the normal range of the risk control indicator's calculation logic. Critical test samples are those containing boundary values ​​of the risk control indicator's calculation rules. Data missing test samples contain null values ​​or no business records. Abnormal data samples contain numerical, type, or logical anomalies.

[0061] By constructing a standardized test sample set covering multiple scenarios including normal, critical, missing data, and abnormal data, and providing precise standard operation results, the indicator code can be verified in all scenarios. This comprehensively examines the execution stability and accuracy of the code under various normal and edge scenarios, effectively making up for the shortcomings of traditional test samples being incomplete and verification criteria being not rigorous. It can identify and avoid potential operational risks of the code in the complex data environment of real business in advance, significantly improve the robustness of the indicator code and the credibility of the verification results, and provide a solid guarantee for the stable and reliable generation of risk control indicators.

[0062] In some embodiments, after generating risk control indicators, the generated risk control indicators can be directly input into a pre-trained risk assessment model to predict the risk of target users, such as predicting the user's risk level, thereby supporting actual risk control decisions such as credit approval, risk warning, and credit limit management.

[0063] In some embodiments, the generated risk control indicators can also be used as training samples as input variables for the risk assessment model and added to the training process of the risk assessment model to enrich the model's feature dimensions and optimize the model's learning effect on risk patterns.

[0064] In some embodiments, to improve the readability, maintainability, and business traceability of indicator codes, a code generation model can be used simultaneously during the indicator code generation process to automatically generate accompanying annotation information. This annotation information can include one or more elements from the risk control indicator's business meaning, the data sources upon which the risk control indicator is calculated, and the specific calculation logic of the risk control indicator. This achieves integrated and automated generation of indicator code and business annotations. By automatically generating annotation information, subsequent developers can quickly understand the business background, data sources, and calculation rules corresponding to the code, significantly reducing the understanding and communication costs of code handover, problem troubleshooting, and system iteration, and improving code traceability.

[0065] The code generation method provided in this specification is described below with reference to a specific embodiment. To generate risk control indicators efficiently and accurately, a risk control indicator generation system is provided below. Figure 7 The architecture of the risk control indicator generation system is demonstrated, comprising the following core modules: a user interaction layer, a large-scale model agent core layer, an enterprise data and execution layer, and a feedback and governance layer. The user interaction layer primarily receives indicator requests from users in natural language. The large-scale model agent core layer parses the business semantics of these requests, combines business rules and historical indicator templates from the risk control knowledge base, generates indicator code, and performs dual-channel verification. The enterprise data and execution layer uses an enterprise data dictionary to map business fields from the indicator requests to actual table structures, runs the code in a secure environment (e.g., a secure sandbox), and stores the results in the indicator result storage. The feedback and governance layer monitors the effectiveness of the indicators, supports manual review and feedback, and dynamically updates the knowledge in the risk control knowledge base.

[0066] The core of this embodiment lies in constructing a dedicated "Large Model Agent Core Layer" for generating enterprise risk control indicators. This layer does not simply call a general large model for code generation; instead, it achieves end-to-end automated generation of risk control indicator code—from natural language requirements to high-quality, directly deployable code—through deep integration of risk control business knowledge, enterprise data context, and a dual code quality assurance mechanism. Its specific composition and working mechanism are as follows: 1. Natural Language Understanding (NLU) Module This module is a precise parser of business semantics. It is responsible for receiving indicator requirements (e.g., "Calculate the proportion of overdue transactions in the past 30 days to the total number of transactions") input by risk control experts in natural language form, and performing deep semantic analysis on them.

[0067] First, pre-trained language models can be used to identify key business entities (such as "customer," "overdue transaction," and "30 days"), time windows (sliding / fixed), aggregation logic (counting, percentage, maximum value, etc.), and conditional constraints (such as "credit products only"). Second, the parsed results can be structured into an intermediate representation (IR), such as a logical description object in JSON format, containing elements such as field mappings, time ranges, and calculation formulas. Furthermore, this module supports a clarification mechanism for ambiguous semantics. When the input is ambiguous (e.g., does "recently" refer to 7 days or 30 days?), it can proactively initiate an interactive confirmation with the user to ensure the intent is correct.

[0068] This module can transform unstructured business language into structured logical instructions that are understandable and executable by machines, which is an accurate prerequisite for subsequent code generation.

[0069] 2. Risk control knowledge base The risk control knowledge base serves as the intelligent hub for business rules and experience. To address the lack of risk control expertise in general-purpose models, this solution constructs a dynamically updated risk control knowledge base, acting as the "business brain" of the Agent. This knowledge base contains the following knowledge: (1) Historical indicator template library: stores the indicator definitions, code implementations and business explanations that have been verified and effective in the company's history; (2) Risk control business rule set: such as "M1 overdue = overdue for 1-30 days" and "gang fraud often manifests as shared equipment / IP" and other risk control rules; (3) Enterprise Data Dictionary: Automatically maps business terms (such as "customer ID") to the actual table names and field names (such as user_info.user_id) in the enterprise database. (4) Compliance constraint list: clearly prohibits the use of sensitive fields and operations that must be de-identified.

[0070] This risk control knowledge base can be injected into the indicator code generation process in two ways to ensure that the generated code is not only syntactically correct, but also conforms to the company's actual business logic, data structure and compliance requirements, fundamentally improving business alignment.

[0071] (1) Retrieval Enhanced Generation (RAG): Before each generation, the most relevant templates or rules are retrieved in real time based on the semantic keywords output by NLU and used as context input to the language model.

[0072] (2) Supervised fine-tuning: Supervised fine-tuning of the basic language model on the risk control indicator code corpus to internalize common patterns and norms.

[0073] 3. Code generation engine This engine can automatically generate executable indicator code (e.g., Python code) based on a large language model fine-tuned for risk control (such as Llama, Qwen, or a self-developed model), receiving structured logical descriptions and knowledge base retrieval results from NLU. The generation process not only focuses on syntactic correctness but also emphasizes readability, maintainability, and performance optimization (e.g., avoiding full table scans and using window functions appropriately). It supports multi-language output and is compatible with existing enterprise technology stacks (such as SparkSQL, Pandas, FlinkUDF, etc.). The generated results include complete comments explaining the business meaning of the indicators, data sources, and calculation logic, facilitating subsequent auditing. This code generation engine can replace the manual coding work of traditional IT developers, achieving "what you think is what you get" automated development. Figure 8 The diagram illustrates the specific code generation process. After risk control experts input their indicator requirements in natural language, the code generation engine combines knowledge from the risk control knowledge base to generate indicator code. 4. Code Inspection Component To address potential "illusions" or logical oversights in language models, this solution innovatively employs a dual-channel code inspection mechanism, verifying code quality from both the execution and logical levels: (1) Positive verification module (execution verification dimension) like Figure 8 As shown, the generated code can be deployed to a secure sandbox environment, automatically injecting a preset test dataset (covering normal values, boundary values, null values, and outlier values, etc., CornerCase); the code is executed and the following monitoring is performed: whether compilation / running is successful, whether the output results are within a reasonable range (e.g., percentage ∈ [0,1]), whether key branch logic is covered, and whether there are performance bottlenecks (e.g., timeout, memory overflow). If verification fails, a specific error log is returned (e.g., "field overdue_days does not exist").

[0074] (2) Reverse review module (logical review dimension) like Figure 8 As shown, static analysis of the code can be performed by another dedicated code review model (which can be a different instance of the same model or a specially tuned review model). This agent has built-in risk control logic verification rules, such as: "When calculating the delinquency rate, the denominator should not include settled orders," "The time window should use business time rather than system time," "Avoid executing database queries in loops," and "Division operations must prevent division by zero errors." This model can output review comments in natural language, pointing out potential business logic errors or risks.

[0075] Among them, positive verification ensures that the code "can run", while reverse review ensures that the code "runs correctly". The combination of the two can significantly improve the reliability, security and business correctness of the indicator code, far exceeding the effect of single testing or manual spot checks.

[0076] 5. Closed-loop feedback and iterative mechanism like Figure 8 As shown, if the dual-channel check fails, the system can automatically report the error to the code generation engine, triggering iterative optimization (such as correcting field names or adjusting time logic). If multiple failures occur or the problem is complex, a structured error report (including execution logs and review comments) will be returned to risk control experts or debuggers for them to quickly locate the problem and correct the original requirements. While ensuring quality, the system maximizes automation, introducing manual intervention only when necessary to achieve efficient human-machine collaboration.

[0077] Figure 9 This is a schematic structural diagram of a device provided in an exemplary embodiment. For example... Figure 9 As shown, device 400 mainly consists of a communication interface 402, a user interface 404, a processor 406, and a data storage 408. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 410. The communication interface 402 enables device 400 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, the communication interface 402 may include a chipset and antenna for wireless communication with a radio access network or access point. Furthermore, the communication interface 402 can be a wired interface such as Ethernet, Token Ring, or a USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or a wide-area wireless interface (e.g., WiMAX or LTE). Of course, the communication interface 402 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. The communication interface 402 may also include multiple physical communication interfaces, such as Wi-Fi, Bluetooth, and wide-area wireless interfaces.

[0078] User interface 404 includes receiving user input and providing output to the user. Therefore, user interface 404 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 404 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 404 may include software, circuitry, or other forms of logic capable of transmitting and receiving data from external user input / output devices. Additionally or alternatively, device 400 may support remote access from other devices via communication interface 402 or another physical interface (not shown). User interface 404 may be configured to receive user input, the position and movement of which may be indicated by an indicator or cursor described herein. User interface 404 may also be configured as a display device for rendering or displaying text fragments.

[0079] Processor 406 may contain one or more general-purpose processors and / or special-purpose processors.

[0080] Data storage 408 may include one or more volatile and / or non-volatile storage components and may be integrated wholly or partially with processor 406. Data storage 408 may include removable and non-removable components.

[0081] Processor 406 is capable of executing program instructions 418 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 408 to perform the various functions described herein. Data storage 408 may comprise a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 400, enable device 400 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Processor 406 executing program instructions 418 may result in processor 406 using data 412.

[0082] For example, program instructions 418 may include an operating system 422 (e.g., an operating system kernel, device drivers, and / or other modules) installed on device 400 and one or more applications 420 (e.g., a browser, social application, or game application). Similarly, data 412 may include operating system data 416 and application data 414. Operating system data 416 is primarily accessible to the operating system 422, while application data 414 is primarily accessible to one or more applications 420. Application data 414 may reside in a file system visible or hidden from the user of device 400.

[0083] Application 420 can communicate with operating system 422 through one or more application programming interfaces (APIs). These APIs help application 420 read and / or write application data 414, transmit or receive information via communication interface 402, receive or display information on user interface 404, etc.

[0084] In some terminology, application 420 may be simply referred to as "app". Furthermore, application 420 can be downloaded to device 400 through one or more online app stores or app markets. However, applications can also be installed on device 400 in other ways, such as through a web browser or a physical interface on device 400 (e.g., a USB port).

[0085] Risk control indicator generation devices can be applied to, for example Figure 9 The device shown is used to implement the technical solution of this specification. The device may include: The acquisition module is used to acquire the indicator requirements in natural language form input by the user, and the indicator requirements are used to describe the risk control indicators to be generated. The semantic parsing module is used to perform semantic parsing on the indicator requirements to extract multiple key fields that represent the business intent of the risk control indicators and generate structured data. The code generation module is used to call the code generation model to generate indicator code based on the structured data, wherein the code generation model incorporates risk control domain knowledge through supervised fine-tuning and / or enhanced retrieval. The code verification module is used to input the preset test sample into the indicator code and run it, and determine whether the indicator code passes the verification of the running dimension based on the running result; and to call the code review model to verify the business logic of the indicator code to determine whether the indicator code passes the verification of the logic dimension. The risk control indicator generation module is used to input the business data associated with the risk control indicator into the indicator code and run it, so as to generate the risk control indicator, provided that the indicator code passes the verification of the running dimension and the verification of the logical dimension.

[0086] In some embodiments, the risk control domain knowledge includes an enterprise data dictionary, and the code generation module is used to call a code generation model to generate indicator code based on the structured data, specifically for: Based on the enterprise data dictionary, at least some fields in the structured data are mapped to fields in the target database, and the target database stores business data related to the risk control indicators. The code generation model is invoked to generate the indicator code based on the mapped structured data.

[0087] In some embodiments, the code generation model incorporates risk control domain knowledge through enhanced retrieval, and the code generation module is used to call the code generation model to generate indicator code based on the structured data, specifically for: Retrieve target knowledge related to the structured data from a pre-built risk control domain knowledge base, construct prompt words based on the target knowledge and the indicator code, and use the constructed prompt words to guide the code generation model to generate the indicator code; The target knowledge includes one or more of the following: Business rules, historical risk control indicator templates, enterprise data dictionary, and data compliance constraints in the risk control field. The historical risk control indicator template includes at least the definition of historical risk control indicators and the standard execution code of historical risk control indicators. The enterprise data dictionary is used to map the business fields in the indicator requirements to fields in the target database. The target database stores business data related to the risk control indicators.

[0088] In some embodiments, the code generation model incorporates risk control domain knowledge through supervised fine-tuning, and the code generation model is trained based on the following method: Obtain the definition of historical risk control indicators and the standard execution code of the historical risk control indicators; Using the defined metrics as input to the language model and the standard executable code as labels, the language model is subjected to supervised fine-tuning to obtain the code generation model.

[0089] In some embodiments, the plurality of key fields include one or more of the following: The business entities involved in risk control indicators, the time window corresponding to the business data used to calculate risk control indicators, the calculation logic of risk control indicators, and the constraints of risk control indicators.

[0090] In some embodiments, the device is further configured to: If the indicator code fails the verification of either the operational dimension or the logical dimension, the indicator code will be used as the code to be corrected in the current iteration, and the following code correction operation will be performed: Using the code to be corrected and the verification feedback information of the code to be corrected, prompt words are constructed to guide the code generation model to correct the code to be corrected, so as to obtain the corrected code; wherein, the verification feedback information is used to indicate the reason why the code to be corrected failed the verification. Verify the revised code; If the code to be corrected fails the verification in either the runtime dimension or the logical dimension, and / or the number of corrections does not reach the preset number, the code correction operation will be returned to be executed.

[0091] In some embodiments, if the indicator code fails the validation of the running dimension, the validation feedback information includes error logs generated when running the code to be corrected; If the code to be corrected fails the verification of the logical dimension, the verification feedback information includes the review comments output by the code review model in natural language, which are used to point out the business logic errors in the code to be corrected.

[0092] In some embodiments, the code verification module is used to determine whether the indicator code passes the verification of the running dimension based on the running results, specifically for: If the execution result indicates that the indicator code has any of the following problems during the execution process, the indicator code is deemed to have failed the validation of the execution dimension: The indicator code failed to run successfully, the running result was not within the preset range, the running result was inconsistent with the preset standard running result, the running result did not cover the key branches of the indicator code, the running time of the indicator code exceeded the preset time, and memory overflow occurred during the running process.

[0093] In some embodiments, the test samples are obtained from a pre-built test sample set, which includes multiple test samples, each of which is associated with a standard operating result. The standard operating result is calculated based on the calculation logic of the risk control indicator. The multiple test samples cover one or more of the following types: regular test samples, critical test samples, data missing test samples, and abnormal data samples. and / or The method further includes: using the code generation model to generate annotation information for the indicator code, wherein the annotation information includes one or more of the following: the business meaning of the risk control indicator, the data source used to calculate the risk control indicator, and the calculation logic of the risk control indicator.

[0094] In some embodiments, after generating the risk control indicators, the device is further configured to: The risk control indicators are input into a pre-trained risk assessment model to predict the risk of target users; or, The aforementioned risk control indicators are used as feature variables for training the risk assessment model. For ease of description, the above apparatus is described by dividing it into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in one or more software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0095] Based on the same concept as the methods described above, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in any of the above embodiments by executing the executable instructions.

[0096] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0097] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0098] What those skilled in the art will understand is: In this specification, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded.

[0099] In this specification, “a,” “an,” and “the” do not specifically refer to the singular, but may also include the plural.

[0100] In this specification, ordinal numbers such as "first," "second," etc., do not necessarily indicate order; they are often used to distinguish between objects. For example, "first server" and "second server" usually refer to two servers. To differentiate between these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0101] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0102] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0103] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0104] Although one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is only one of many possible execution orders and does not represent the only execution order. Therefore, when the claims involve method steps, any changes or adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims.

Claims

1. A method for generating risk control indicators, the method comprising: Obtain the indicator requirements in natural language form input by the user, which describe the risk control indicators to be generated; Semantic parsing is performed on the required indicators to extract multiple key fields that represent the business intent of the risk control indicators and generate structured data. The code generation model generates indicator codes based on the structured data, wherein the code generation model incorporates risk control domain knowledge through supervised fine-tuning and / or enhanced retrieval. Input the preset test sample into the indicator code and run it. Based on the running result, determine whether the indicator code passes the verification of the running dimension. The code review model is invoked to verify the business logic of the indicator code in order to determine whether the indicator code passes the verification at the logical dimension. If the indicator code passes the verification of the operational dimension and the logical dimension, the business data associated with the risk control indicator is input into the indicator code and run to generate the risk control indicator.

2. The method according to claim 1, wherein the risk control domain knowledge includes an enterprise data dictionary, and the calling code generation model generates indicator codes based on the structured data, comprising: Based on the enterprise data dictionary, at least some fields in the structured data are mapped to fields in the target database, and the target database stores business data related to the risk control indicators. The code generation model is invoked to generate the indicator code based on the mapped structured data.

3. The method according to claim 1 or 2, wherein the code generation model incorporates risk control domain knowledge through enhanced retrieval, and the invocation of the code generation model generates indicator codes based on the structured data, comprising: Retrieve target knowledge related to the structured data from a pre-built risk control domain knowledge base, construct prompt words based on the target knowledge and the indicator code, and use the constructed prompt words to guide the code generation model to generate the indicator code; The target knowledge includes one or more of the following: Business rules, historical risk control indicator templates, enterprise data dictionary, and data compliance constraints in the risk control field. The historical risk control indicator template includes at least the definition of historical risk control indicators and the standard execution code of historical risk control indicators. The enterprise data dictionary is used to map the business fields in the indicator requirements to fields in the target database. The target database stores business data related to the risk control indicators.

4. The method according to claim 1 or 2, wherein the code generation model incorporates risk control domain knowledge through supervised fine-tuning, and the code generation model is trained based on the following method: Obtain the definition of historical risk control indicators and the standard execution code of the historical risk control indicators; Using the defined metrics as input to the language model and the standard executable code as labels, the language model is subjected to supervised fine-tuning to obtain the code generation model.

5. The method according to claim 1 or 2, wherein the plurality of key fields includes one or more of the following: The business entities involved in risk control indicators, the time window corresponding to the business data used to calculate risk control indicators, the calculation logic of risk control indicators, and the constraints of risk control indicators.

6. The method according to claim 1, further comprising: If the indicator code fails the verification of either the operational dimension or the logical dimension, the indicator code will be used as the code to be corrected in the current iteration, and the following code correction operation will be performed: Using the code to be corrected and the verification feedback information of the code to be corrected, prompt words are constructed to guide the code generation model to correct the code to be corrected, so as to obtain the corrected code; wherein, the verification feedback information is used to indicate the reason why the code to be corrected failed the verification. Verify the revised code; If the code to be corrected fails the verification in either the runtime dimension or the logical dimension, and / or the number of corrections does not reach the preset number, the code correction operation will be returned to be executed.

7. The method according to claim 6, wherein if the indicator code fails the verification of the running dimension, the verification feedback information includes the error log generated when running the code to be corrected; If the code to be corrected fails the verification of the logical dimension, the verification feedback information includes the review comments output by the code review model in natural language, which are used to point out the business logic errors in the code to be corrected.

8. The method according to claim 1, determining whether the indicator code passes the validation of the running dimension based on the running results, includes: If the execution result indicates that the indicator code has any of the following problems during the execution process, the indicator code is deemed to have failed the validation of the execution dimension: The indicator code failed to run successfully, the running result was not within the preset range, the running result was inconsistent with the preset standard running result, the running result did not cover the key branches of the indicator code, the running time of the indicator code exceeded the preset time, and memory overflow occurred during the running process.

9. The method according to claim 1, wherein the test sample is obtained from a pre-constructed test sample set, the test sample set includes multiple test samples, each test sample is associated with a standard operating result, the standard operating result is calculated based on the calculation logic of the risk control indicator, and the multiple test samples cover one or more of the following types: regular test samples, critical test samples, data missing test samples, and abnormal data samples; and / or The method further includes: The code generation model is used to generate annotation information for the indicator code. The annotation information includes one or more of the following: the business meaning of the risk control indicator, the data source used to calculate the risk control indicator, and the calculation logic of the risk control indicator.

10. The method according to claim 1, further comprising, after generating the risk control indicators: The risk control indicators are input into a pre-trained risk assessment model to predict the risk of target users; or, The aforementioned risk control indicators are used as feature variables of the risk assessment model to be trained.

11. An electronic device, characterized in that, include: processor; A memory for storing processor-executable instructions; wherein the processor implements the steps of the method as described in any one of claims 1-10 by executing the executable instructions.

12. A computer-readable storage medium, characterized in that, It stores computer instructions that, when executed by a processor, implement the steps of the method as described in any one of claims 1-10.

13. A computer program product, characterized in that, Includes a computer program / instructions that, when executed by a processor, implement the steps of the method as described in any one of claims 1-10.

Images