Risk assessment methods, apparatus, electronic devices and computer-readable storage media

Abstract

This disclosure relates to a risk assessment method, apparatus, electronic device, and computer-readable storage medium. The method includes: upon triggering a risk assessment operation for target software, collecting multivariate data for the target software, including business characteristic data and domain knowledge data of the target software; extracting feature data corresponding to each risk factor from the multivariate data, and constructing a target prompt based on the feature data corresponding to each risk factor and a prompt template; inputting the target prompt into a large-scale risk assessment model, and outputting a risk assessment result for the target software. This method can improve the accuracy of risk assessment results.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a risk assessment method, apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] In an enterprise's internal software development and requirements management system, risk assessment of product requirements is a core element in ensuring delivery quality and controlling project costs. With the diversification of business scenarios, the number of requirements from various business lines continues to grow, involving high-risk scenarios such as financial security, system performance, and data consistency. This places higher demands on the comprehensiveness, accuracy, and timeliness of risk assessments, directly impacting the agility of the delivery process and the effectiveness of quality control.

[0003] Currently, the industry generally adopts a demand risk assessment method dominated by human experience. The assessment process relies on the subjective judgment of personnel from different roles such as R&D, product, and operations. Due to significant differences in the judgment rules of different teams or personnel, the standards are vague and lack consistency, resulting in potential quality defects in the final risk assessment results, that is, poor accuracy of the risk assessment results. Summary of the Invention

[0004] This disclosure provides a risk assessment method, apparatus, electronic device, and computer-readable storage medium to at least address the problem of potential quality defects in risk assessment results in related technologies. The technical solution of this disclosure is as follows:

[0005] According to a first aspect of the present disclosure, a risk assessment method is provided, comprising:

[0006] When a risk assessment operation is triggered for the target software, multi-dimensional data is collected for the target software, including business characteristic data of the target software and domain knowledge data of the target software;

[0007] Extract feature data corresponding to each risk factor from the multivariate data;

[0008] Based on the feature data corresponding to each risk factor and the prompt template, a target prompt is constructed.

[0009] The target prompt is input into the risk assessment model, and the risk assessment results for the target software are output.

[0010] In one embodiment, the business characteristic data includes at least one of business data, user behavior data, historical fault data, code change data, requirement document data, and personnel characteristic data; the domain knowledge data includes data from various professional fields, and the professional fields include at least one of security, quality, finance, and data.

[0011] In one embodiment, the method further includes:

[0012] The domain intelligence agents corresponding to each of the aforementioned professional fields are invoked to perform risk identification on the business feature data, and risk identification results corresponding to each of the aforementioned professional fields are obtained respectively;

[0013] The risk identification results corresponding to each of the aforementioned professional fields are used as the domain knowledge data of the target software.

[0014] In one embodiment, the method further includes:

[0015] In response to a configuration operation for a risk assessment strategy, at least one of the risk factors, risk factor weights, risk determination thresholds, and risk assessment strategies is determined.

[0016] In one embodiment, the step of constructing the target prompt based on the feature data corresponding to each of the risk factors and the prompt template includes:

[0017] The initial prompt template is adjusted based on at least one of the risk factors, the risk factor weights, the risk assessment threshold, and the risk assessment strategy to obtain the prompt template.

[0018] The feature data corresponding to each of the risk factors are filled into the prompt template to construct the target prompt.

[0019] In one embodiment, the method further includes:

[0020] Real-time monitoring of changes in the target software's basic data, including team status data, code data, and requirement data corresponding to the target software;

[0021] When the changes in the basic data are detected to meet the risk assessment criteria, a risk assessment operation for the target software is triggered.

[0022] In one embodiment, the risk assessment result includes at least one of the following: risk assessment content, risk score, risk level, project modification points, optimization suggestions, and scope of impact.

[0023] According to a second aspect of the present disclosure, a risk assessment apparatus is provided, comprising:

[0024] The data acquisition unit is configured to collect multi-dimensional data for the target software when a risk assessment operation for the target software is triggered. The multi-dimensional data includes business characteristic data of the target software and domain knowledge data of the target software.

[0025] The extraction unit is configured to extract feature data corresponding to each risk factor from the multivariate data;

[0026] The construction unit is configured to execute the construction of a target prompt based on the feature data corresponding to each of the risk factors and the prompt template;

[0027] The evaluation unit is configured to take the target prompt as input to a risk assessment model and output a risk assessment result for the target software.

[0028] In one embodiment, the business characteristic data includes at least one of business data, user behavior data, historical fault data, code change data, requirement document data, and personnel characteristic data; the domain knowledge data includes data from various professional fields, and the professional fields include at least one of security, quality, finance, and data.

[0029] In one embodiment, the device further includes:

[0030] The identification unit is configured to execute the call to the domain intelligence agent corresponding to each of the professional fields to perform risk identification on the business feature data, and obtain the risk identification results corresponding to each of the professional fields respectively;

[0031] The determining unit is configured to use the risk identification results corresponding to each of the professional fields as domain knowledge data for the target software.

[0032] In one embodiment, the device further includes:

[0033] The response unit is configured to perform a configuration operation in response to a risk assessment strategy, determining at least one of the risk factors, risk factor weights, risk determination thresholds, and risk assessment strategies.

[0034] In one embodiment, the step of constructing the target prompt based on the feature data corresponding to each of the risk factors and the prompt template includes:

[0035] The initial prompt template is adjusted based on at least one of the risk factors, the risk factor weights, the risk assessment threshold, and the risk assessment strategy to obtain the prompt template.

[0036] The feature data corresponding to each of the risk factors are filled into the prompt template to construct the target prompt.

[0037] In one embodiment, the device further includes:

[0038] The monitoring unit is configured to perform real-time monitoring of changes in the basic data of the target software, including team status data, code data, and requirement data corresponding to the target software.

[0039] The assessment unit is configured to trigger a risk assessment operation for the target software when it detects that the changes in the basic data meet the risk assessment conditions.

[0040] In one embodiment, the risk assessment result includes at least one of the following: risk assessment content, risk score, risk level, project modification points, optimization suggestions, and scope of impact.

[0041] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement any of the risk assessment methods provided in the first aspect.

[0042] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided, wherein when instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform any of the risk assessment methods provided in the first aspect.

[0043] According to a fifth aspect of the present disclosure, a computer program product is provided, the computer program product including instructions that, when executed by a processor of an electronic device, enable the electronic device to perform any of the risk assessment methods provided in the first aspect.

[0044] The technical solutions provided by the embodiments of this disclosure have at least the following beneficial effects:

[0045] The risk assessment method, apparatus, electronic device, and computer-readable storage medium provided in this disclosure, upon triggering a risk assessment operation for target software, collects multi-source data for the target software. This multi-source data includes business characteristic data and domain knowledge data of the target software. Further, feature data corresponding to each risk factor is extracted from the multi-source data, and a target prompt is constructed based on the feature data corresponding to each risk factor and a prompt template. Finally, the target prompt is input into a large-scale risk assessment model, outputting a risk assessment result for the target software. The risk assessment method, apparatus, electronic device, and computer-readable storage medium provided in this disclosure, by introducing the semantic understanding and multi-source data fusion capabilities of a large-scale model, perform deep analysis and correlation analysis of the multi-source data of the target software. This can accurately capture the implicit relationships between risk factors, thus significantly improving the accuracy of risk assessment results, reducing cross-role communication costs, and increasing the efficiency of risk assessment.

[0046] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0047] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0048] Figure 1 This is a flowchart illustrating a risk assessment method according to an exemplary embodiment.

[0049] Figure 2 This is a flowchart illustrating a process for generating domain knowledge data according to an exemplary embodiment.

[0050] Figure 3 This is a detailed flowchart illustrating step 106 according to an exemplary embodiment.

[0051] Figure 4 This is a flowchart illustrating a risk assessment process triggered by real-time monitoring, according to an exemplary embodiment.

[0052] Figure 5 This is a demand risk assessment architecture diagram illustrated according to an exemplary embodiment.

[0053] Figure 5 This is a structural block diagram of a demand risk intelligent assessment architecture illustrated according to an exemplary embodiment.

[0054] Figure 6 This is a schematic diagram of the interface of a data dashboard according to an exemplary embodiment.

[0055] Figure 7 This is a structural block diagram illustrating a demand risk intelligent assessment process according to an exemplary embodiment.

[0056] Figure 8 This is a structural block diagram illustrating large-scale model risk analysis according to an exemplary embodiment.

[0057] Figure 9 This is a block diagram illustrating a risk assessment apparatus according to an exemplary embodiment.

[0058] Figure 10 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation

[0059] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0060] It should also be noted that 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 display, data used for analysis, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties.

[0061] Figure 1 This is a flowchart illustrating a risk assessment method according to an exemplary embodiment. This embodiment uses the application of the method to a terminal as an example for illustration. It is understood that the method can also be applied to a server, or to a system including a terminal and a server, and implemented through interaction between the terminal and the server. In this embodiment, the method includes steps 102 to 108, wherein:

[0062] Step 102: When a risk assessment operation for the target software is triggered, collect multi-dimensional data for the target software. The multi-dimensional data includes business characteristic data of the target software and domain knowledge data of the target software.

[0063] In this embodiment of the disclosure, after triggering a risk assessment for the target software, it is necessary to collect multi-dimensional data covering technology, business, professional fields, etc., to ensure the comprehensiveness of the assessment. In one example, business characteristic data is the basic data material supporting the risk assessment, including at least one of the following: business data, user behavior data, historical fault data, code change data, requirement document data, and personnel characteristic data, such as requirement documents, collaboration records, code commit logs, historical fault databases, past requirement risk assessment records, code bug fix logs, developer technology stack matching degree, similar requirement handling experience, historical code quality scores, etc.

[0064] Domain knowledge data is specialized domain data generated by specialized agents (domain intelligent agents). In one example, the specialized domain includes at least one of the following: security, quality, finance, and data. Specialized domain data can be R&D cost estimates and failure loss calculations output by a finance agent, code vulnerability scan results and data compliance risk points output by a security agent, and data transmission security and storage compliance verification results output by a data agent. This disclosure does not limit the specific tools used for data collection; any tool capable of acquiring the corresponding data, such as Git repository interfaces, team collaboration platform APIs (Application Programming Interfaces), and domain intelligent agent scanning tools, is applicable to this embodiment.

[0065] For example, business data can include product form, business architecture, and technical architecture, which can be obtained through API interfaces from internal document systems, product white papers, technical architecture reviews, business sharing sessions, and business knowledge bases. User behavior data can include clicks, page dwell time, function usage frequency, and interaction records, which can be obtained using internal tracking and analytics platforms. Historical fault data can include historical issue records, including complaints, suggestions, feedback, and work orders, which can be obtained from internal systems through API interfaces, such as fault review reports, customer service work order logs, monitoring logs, and historical fault databases. Code change data can include requirement code changes, number of submissions, and modified modules, which can be obtained through the internal code submission platform. Requirement-related data can include design prototypes, requirement documents, and review meeting minutes, which can be extracted and integrated from the internal project management platform. Personnel characteristic data can include task completion efficiency, defect introduction rate, and historical online issues, which can be obtained from departmental project management tools.

[0066] Step 104: Extract the feature data corresponding to each risk factor from the multivariate data.

[0067] In this embodiment of the disclosure, risk factors refer to specific quantifiable indicators or dimensions that affect the level of risk of the target software. They are the core components of risk assessment, and their sources are related to multi-dimensional data, covering multiple dimensions such as technology, business, personnel, and professional fields. For example, before extracting feature data, the collected multi-dimensional data needs to be preprocessed. This may include data cleaning and noise reduction, removing duplicate data, correcting outliers, and completing missing data. Based on the preprocessed data, the format is standardized, converting unstructured data such as requirement document text and code snippets into a format that the model can process. For example, text can be converted into semantic vectors using NLP (Natural Language Processing) tools, and code quantification features can be extracted through abstract syntax trees. This unifies the field format of structured data from different sources.

[0068] Furthermore, feature data corresponding to each risk factor can be extracted based on the preprocessed multivariate data. For example, technical risk factor features such as code change volume (number of modified files, lines of code, etc.) and the proportion of core module modifications can be extracted from Git code commit logs. Business risk factor features such as historical failure rate and failure impact scope can be extracted from historical failure databases. Security risk factor features such as the number of high-risk vulnerabilities and vulnerability remediation priority can be extracted from security agent scanning results. Personnel risk factor features such as developer experience value and historical code bug rate can be extracted from personnel-related data. After extraction, feature importance analysis can be used to filter highly relevant features and remove redundant information, ultimately obtaining the feature dataset corresponding to each risk factor.

[0069] Step 106: Based on the feature data corresponding to each risk factor and the prompt template, construct the target prompt.

[0070] In this embodiment, the prompt template serves as a carrier connecting risk assessment rules and feature data. It transforms manually defined risk factor weights, judgment criteria, and other assessment logic into reasoning instructions understandable by the risk assessment model, preventing the model from deviating from business needs. The prompt template includes a fixed part and a dynamic part. The fixed part clarifies the assessment objective and output format. The assessment objective can be set as the risk score, risk level, core risk points, explanatory text, and optimization suggestions for the target software, based on provided feature data and rules. The output format can be specified as Markdown (a lightweight markup language) structured format, etc. The dynamic part embeds risk factor rules and real-time feature data, including a preset dynamic weight matrix, such as a security factor weight of 0.4, a funding factor weight of 0.3, a code factor weight of 0.3 and a personnel factor weight of 0.2 for new feature iteration software, and judgment criteria for each risk factor, such as a code modification volume ≥ 10 files as high risk, a historical failure rate ≥ 0.3 as high risk, and the number of high-risk vulnerabilities ≥ 1 as high risk, etc. When constructing a target prompt, the characteristic data corresponding to each risk factor needs to be embedded into the dynamic part of the prompt template in a preset format, and integrated with the evaluation rules in the fixed part to form a complete reasoning instruction.

[0071] For example, the target prompt can be expressed as: "Please assess the risk of the target software based on the following rules and feature data: 1. Risk factors and weights: security factor (weight 0.4, ≥1 high-risk vulnerability is considered high risk), funding factor (weight 0.3, cost overrun probability ≥0.5 is considered high risk), code factor (weight 0.2, modification amount ≥5 files is considered high risk), personnel factor (weight 0.1, experience value <0.3 is considered high risk); 2. Feature data: number of high-risk vulnerabilities = 2, cost overrun probability = 0.4, code modification amount = 8 files, personnel experience value = 0.2; 3. Output requirements: output the risk score, level, core risk points, explanatory text and optimization suggestions in Markdown format."

[0072] Step 108: Input the target prompt into the risk assessment model and output the risk assessment results for the target software.

[0073] In this embodiment of the disclosure, the risk assessment big model is a big language model that is finely tuned based on business scenarios. It is trained and optimized through historical data such as feature data of past requirements and risk tags, and has multi-dimensional reasoning and semantic understanding capabilities, and can accurately execute the assessment logic in the prompt instruction.

[0074] For example, after inputting the target prompt into the risk assessment model, the model first performs single-factor risk assessment, matching feature data with the judgment criteria of each risk factor one by one, and determining the risk level of each factor based on its weights. For instance, two high-risk vulnerabilities with a weight of 0.4 indicate high risk, as does eight code modifications with a weight of 0.2. Next, cross-factor correlation analysis is performed to identify the interaction relationships between risk factors. For example, a high code modification volume coupled with a high historical failure rate indicates overlapping risks. Finally, a comprehensive score is calculated, integrating the risk scores of each factor using algorithms such as weighted summation. For example, the security score is 90 × 0.4 + the funding score is 70 × 0.3 + the code score is 80 × 0.2 + the personnel score is 60 × 0.1 = 81 points. Finally, the risk level is determined by comparing it to preset thresholds: 0-50 points for low risk, 51-80 points for medium risk, and 81-100 points for high risk. The final level is output, along with an explanatory text. For example, the core risk points include: two high-risk vulnerabilities (weight 0.4) and code modifications exceeding the threshold (weight 0.2), resulting in a high overall risk. The output risk assessment is structured, including the core risk score, level, and explanatory text, as well as targeted optimization suggestions, such as prioritizing the remediation of high-risk vulnerabilities and assigning experienced developers to code reviews. Interactive feedback is also supported, with embedded instructions for buttons like "Confirm Risk" and "Request Review," facilitating subsequent user operations and model iteration optimization.

[0075] It should be noted that the embodiments disclosed herein do not limit the specific type of risk assessment model. Any large model that has semantic understanding and multi-dimensional reasoning capabilities and can perform risk assessment through the prompt command is applicable to the embodiments disclosed herein.

[0076] The risk assessment method provided in this disclosure, upon triggering a risk assessment operation for target software, collects multi-dimensional data for the target software. This multi-dimensional data includes business characteristic data and domain knowledge data of the target software. Further, feature data corresponding to each risk factor is extracted from the multi-dimensional data, and a target prompt is constructed based on the feature data corresponding to each risk factor and a prompt template. Finally, the target prompt is input into a large-scale risk assessment model, outputting a risk assessment result for the target software. The risk assessment method provided in this disclosure, by introducing the semantic understanding and multi-source data fusion capabilities of a large-scale model, performs in-depth analysis and correlation analysis of the multi-dimensional data of the target software. This allows for accurate capture of implicit relationships between risk factors, thus significantly improving the accuracy of risk assessment results, reducing cross-role communication costs, and increasing the efficiency of risk assessment.

[0077] In one exemplary embodiment, reference is made to Figure 2As shown, the method further includes steps 202 to 204, wherein:

[0078] Step 202: Call the domain intelligence agent corresponding to each professional field to perform risk identification on the business feature data, and obtain the risk identification results corresponding to each professional field respectively;

[0079] Step 204: Use the risk identification results corresponding to each professional field as the domain knowledge data of the target software.

[0080] In this embodiment of the disclosure, during the collection of multi-dimensional data, after the business feature data collection is completed, the domain intelligence agent corresponding to each professional field can be invoked to perform risk identification on the collected business feature data, perform in-depth risk scanning and analysis within its professional field, obtain the risk identification results corresponding to each professional field, realize the professional in-depth analysis of the business feature data, and finally integrate the outputs of each domain intelligence agent to obtain the domain knowledge data in the multi-dimensional data.

[0081] Domain knowledge data and business characteristic data together constitute multi-dimensional data, which provides a professional and in-depth supplement to the business characteristic data. In other words, it provides professional dimension indicators for the extraction of risk factor characteristic data, such as extracting the risk factor characteristic of the number of high-risk vulnerabilities from the identification results of security agents. At the same time, it provides domain-level risk rules for the construction of target prompts, so that risk assessment can cover all scenarios of risks in both general and professional dimensions.

[0082] Among them, the domain-specific intelligent agents are automated analysis modules that focus on specific risk dimensions. They have the core characteristics of domain division of labor and autonomous execution, and can include financial agents, security agents, data agents, quality agents, performance agents, etc. Each intelligent agent has built-in professional analysis rules, tool calling capabilities, and risk judgment logic for the corresponding domain.

[0083] Among them, the Funds Agent can integrate payment clearing and settlement rules, transaction compliance requirements, historical loss cases, as well as the decision-making strategies, cost calculation models, and historical cost databases of the risk control rule engine. It is used to analyze information such as the complexity of required functions, the estimated R&D manpower input, and the failure losses of similar historical requirements in business characteristic data, and output risk identification results such as the estimated amount of R&D costs, the probability of cost overruns, the calculation of potential failure losses, and the level of fund risk.

[0084] The security agent can integrate security scanning rules, historical security vulnerability data, compliance verification rule base, etc., to scan code snippets, interface configurations, permission settings, etc. in business characteristic data, identify security vulnerabilities and compliance risks, and output risk identification results such as the number of high-risk vulnerabilities, the number of medium-risk vulnerabilities, vulnerability remediation priority, and compliance violation details.

[0085] The data agent analyzes data storage schemes, transmission link configurations, and data synchronization rules in business characteristic data by introducing data dictionaries, data lineage graphs, data quality detection rules (such as integrity and accuracy verification), data consistency verification tools, and data transmission encryption detection modules. It outputs risk identification results such as data consistency risk scores, transmission security verification results, storage compliance conclusions, and data anomaly trigger probability.

[0086] Quality Agent can integrate historical defect databases, performance baseline data, industry quality standards, etc., and perform in-depth analysis on information such as historical defect records, code quality data, performance test results, and requirement quality requirements in business characteristic data. It outputs risk identification results such as comprehensive quality risk score, defect recurrence probability, performance deviation from baseline, quality compliance rate, core quality issues details, and test focus suggestions.

[0087] The performance agent can call system performance simulation tools and code complexity analysis modules. Based on information such as the scope of code changes, frequency of core interface calls, and concurrency estimates in business characteristic data, it can output risk identification results such as the impact value on system response speed, risk of concurrency carrying capacity, probability of resource consumption exceeding threshold, and level of performance optimization requirements.

[0088] This disclosure does not limit the specific type, capabilities, or number of domain intelligence agents. Domain intelligence agents can be added according to business scenarios, such as operation and maintenance agents and compliance agents. Moreover, the analysis process of each intelligence agent does not require manual intervention and is executed automatically throughout the process, ensuring the efficiency and professionalism of risk identification.

[0089] The risk assessment method provided in this disclosure introduces specialized domain intelligent agents such as funding agents, security agents, and data agents to perform in-depth risk scanning and analysis within their respective domains. It also collects and integrates the output results of multiple agents through intelligent scheduling algorithms. This architecture, which combines domain-specific governance with collaboration, can provide deeper and more professional risk insights compared to a single model or rule set, and can cope with the assessment and judgment of complex business scenarios.

[0090] In an exemplary embodiment, the method may further include: in response to a configuration operation for a risk assessment strategy, determining at least one of a risk factor, a risk factor weight, a risk determination threshold, and a risk assessment strategy.

[0091] In this embodiment, the system supports users in flexibly adjusting assessment rules according to differences in business scenarios and changes in demand types. The triggering timing of the configuration can run through the entire risk assessment process, such as pre-setting strategies before assessment and adjusting strategies based on feedback after assessment. The configuration operation can be completed through a visual configuration panel. Among them, the configuration operation for risk assessment strategy refers to the rule adjustment behavior initiated by the user through the visual configuration panel, and one or more configuration objects can be selected according to actual needs.

[0092] In one example, the system supports adding, deleting, modifying, and querying risk factors. For instance, adding a data compliance factor to adapt to privacy protection business requirements, deleting hardware resource consumption factors that are irrelevant to the current business, modifying the calculation method of code change factors (e.g., changing it from the number of files involved to the number of lines of core code involved), or selecting the set of risk factors that need to be enabled in the current assessment (e.g., enabling only security factors, funding factors, and code factors for payment-related requirements).

[0093] In another example, it supports assigning weight values ​​to each enabled risk factor, with the total weight typically being 1 or 100%. Configuration can be done manually or visually, such as by dragging and dropping sliders to assign percentages. It also supports quickly loading preset weight templates based on business scenarios, such as a payment business template with security factor 0.4, funding factor 0.3, code factor 0.2, and personnel factor 0.1; and a new feature iteration template with code factor 0.3, personnel factor 0.25, quality factor 0.25, and performance factor 0.2.

[0094] In another example, the system supports setting thresholds for the correspondence between risk scores and risk levels, clearly defining the criteria for classifying low, medium, and high risk. For instance, users can configure risk scores of 0-50 as low risk, 51-80 as medium risk, and 81-100 as high risk. Thresholds can also be adjusted for specific highly sensitive scenarios; for example, in core financial businesses, the high-risk threshold can be lowered to 75 points, meaning a score ≥75 is considered high risk. Furthermore, the system supports setting independent thresholds for individual risk factors; for example, if the number of high-risk vulnerabilities is ≥1, it is directly classified as high risk.

[0095] In another example, the system supports defining logical rules for risk assessment, including single-factor judgment logic and multi-factor comprehensive judgment logic. For instance, a single-factor veto strategy can be configured, such as classifying a fund agent output with a probability of financial loss ≥ 0.3 as high-risk, regardless of other factor scores; a multi-factor overlay logic can be configured, such as increasing the overall risk level by one level when both code modification volume and historical failure rate are high-risk; or a domain priority strategy can be configured, such as automatically increasing the weight of security domain risk factors by 20% for comprehensive calculation when the score is ≥ 80.

[0096] After configuration is complete, the system automatically converts the configuration results into the corresponding parameter format, such as JSON, stores it in the configuration center, and synchronizes it to subsequent processes in real time. Risk factors and weight parameters are used to build the target prompt. The risk assessment threshold is used to determine the risk level. The risk assessment strategy embeds inference instructions from the target prompt, guiding the large model to perform risk assessment according to preset logic. Simultaneously, all configuration operation records are stored in the operation log table of the storage layer, supporting the tracing of historical configuration versions and facilitating rollback adjustments after business changes.

[0097] The risk assessment method provided in this disclosure provides a configuration entry point for risk assessment strategies, realizes dynamic adaptation between risk assessment strategies and business operations, improves the accuracy of risk assessment, and reduces the operational threshold without the need for code development.

[0098] In one exemplary embodiment, such as Figure 3 As shown, in step 106, based on the feature data corresponding to each risk factor and the prompt template, a target prompt is constructed, including the following steps 302 to 304, wherein:

[0099] Step 302: Adjust the initial prompt template based on at least one of the risk factors, risk factor weights, risk judgment thresholds, and risk judgment strategies to obtain the prompt template;

[0100] Step 304: Fill the feature data corresponding to each risk factor into the prompt template to construct the target prompt.

[0101] In this embodiment of the disclosure, the initial prompt template is a preset basic framework that includes fixed core structures such as assessment objectives and output formats, but does not embed specific assessment rules. By integrating the rules after the user-configured risk assessment strategy is dynamically adjusted into the template, the template has reasoning logic that fits the current business scenario.

[0102] For example, after a user adjusts risk factors, the initial prompt template can be adjusted based on those risk factors. For instance, if a data compliance factor is added to the configuration, the factor and its corresponding description are added to the risk factor list in the initial prompt template; if a hardware resource consumption factor is deleted, the relevant description of that factor is removed from the initial prompt template; if some factors are enabled, only the enabled factor entries in the initial prompt template are retained.

[0103] If a user adjusts the risk factor weights, the adjustment can be made based on those weights. For example, the configured weight values ​​can be synchronously updated in the risk factor rules of the initial prompt template to clarify the importance percentage of each factor. For instance, if the safety factor weight is configured to be 0.4 and the funding factor weight to be 0.3, then the corresponding annotations can be made in the initial prompt template to guide the large model to prioritize the analysis of high-weight factors.

[0104] If the user adjusts the risk assessment threshold, adjustments can be made based on that threshold. For example, risk level classification standards and independent thresholds for single factors can be added to the initial prompt template. For instance, threshold rules for low risk (0-50 points), medium risk (51-80 points), and high risk (81-100 points) can be embedded into the initial prompt template. At the same time, independent thresholds can be added, such as stating that having ≥1 high-risk vulnerability directly classifies a vulnerability as high-risk, to unify the judgment criteria of the initial prompt template.

[0105] If the user adjusts the risk assessment strategy, adjustments can be made based on that strategy. For example, the configured logical rules can be transformed into inference instructions in the initial prompt template. For instance, a single-factor veto strategy would directly classify a risk as high if the probability of financial loss is ≥0.3, without needing to add other factors for calculation. A multi-factor overlay logic would increase the overall risk level by one level if the code modification volume is high and the historical failure rate is high, ensuring that the initial prompt template performs the assessment according to the preset logic.

[0106] The adjusted prompt template retains its fixed and dynamic components. The fixed components remain unchanged, while the dynamic components are fully integrated into the configured evaluation rules, ensuring both relevance and adaptability. Finally, combining the adjusted prompt template with the feature data yields the target prompt.

[0107] For example, each risk factor in the adjusted prompt template has reserved data entry slots. The corresponding feature data is entered in the format of "factor name = specific value". For instance, "code modification amount (weight 0.2)" in the template corresponds to "code modification amount = 8 files", "historical failure rate (weight 0.3)" corresponds to "historical failure rate = 0.4", and "number of high-risk vulnerabilities (weight 0.4)" corresponds to "number of high-risk vulnerabilities = 2", ensuring that the rules and data for each factor are accurately matched. If there is professional feature data output by the domain agent, such as "defect recurrence probability = 0.3" for the quality agent, it is entered according to the corresponding domain factor entry in the prompt template, forming a complete input data set together with the general feature data. After the data is entered, the target prompt forms a complete inference instruction of rules plus data, which clarifies the evaluation logic of the large model and provides specific analytical materials, ensuring that the risk assessment results output by the large model conform to both business rules and the actual situation of the target software.

[0108] The risk assessment method provided in this disclosure constructs a target prompt through a two-step process of adjusting the template and filling in data. The prompt is designed around controllable rules, data adaptation, and accurate reasoning, closely aligning with the core requirements of risk assessment. This ensures that the assessment rules are deeply adapted to the business scenario, avoiding problems such as logical omissions and formatting issues that occur when manually writing prompts, thereby improving the accuracy and consistency of risk assessment results.

[0109] In one exemplary embodiment, such as Figure 4 As shown, the method further includes steps 402 to 404, wherein:

[0110] Step 402: Monitor changes in the target software's basic data in real time. The basic data includes the team status data, code data, and requirement data corresponding to the target software.

[0111] Step 404: When the basic data change is detected to meet the risk assessment conditions, a risk assessment operation for the target software is triggered.

[0112] In this embodiment, the risk assessment operation for the target software can be triggered manually or automatically in real time. In one example, changes to the target software's basic data can be monitored in real time. When the changes meet the risk assessment criteria, the risk assessment operation is triggered. Real-time monitoring of basic data changes includes monitoring changes to key data throughout the entire lifecycle of the target software, such as team status data, code data, and requirement data, ensuring that the risk assessment can respond promptly to business and technical changes. The monitoring mechanism combines active retrieval with passive push, achieving continuous monitoring through interfaces to various data sources, such as team collaboration platform APIs, Git repository WebHooks, and requirement management system interfaces, without manual intervention, ensuring the real-time and accurate perception of data changes. This embodiment does not limit the specific technical implementation of the monitoring; any technical solution that can achieve real-time capture of basic data changes (such as message queue monitoring, scheduled task retrieval, and event-driven monitoring) is applicable to this embodiment.

[0113] For example, the specific monitoring content and change scenarios for team status data, code data, and requirement data are as follows:

[0114] Monitoring team status data includes monitoring changes in project team collaboration information related to the target software, such as adjustments to member assignments (key developers and testers added or removed from the project), changes in task progress (core module development delays exceeding preset thresholds, task status changing from in progress to blocked), and changes in collaboration processes (adjustments to code review processes, addition of test case review nodes), etc.

[0115] Monitoring code data includes monitoring changes to the target software's code repository, focusing on core changes at the code level, such as Git repository code commits (adding code commits, modifying code snippets, deleting code), branch operations (branch merging, creating new feature branches, deleting branches), code review results (approval or rejection, marking high-risk issues in review comments), and changes to code scan results (adding code vulnerabilities, updating the status of existing vulnerability fixes), etc.

[0116] Monitoring requirement data includes monitoring changes in the entire process of the target software's requirements, such as requirement submission (new requirement creation and project association), requirement content changes (modification of requirement documents, addition or deletion of function lists, adjustment of business logic), requirement status changes (relocation of requirements from design to development, entry into the pre-launch review stage), and requirement priority adjustments (upgrade from ordinary to urgent).

[0117] When changes to the target software's basic data are detected and meet the preset risk assessment conditions, a corresponding risk assessment operation is triggered. These risk assessment conditions are a set of rules preset based on business scenarios and risk management needs. Users can set or adjust these conditions through a visual configuration panel to suit the assessment frequency and sensitivity requirements of different business lines.

[0118] For example, risk assessment conditions can be trigger rules preset for core and critical change scenarios, such as merging core branch code, major changes to requirements, resubmitting code after fixing high-risk vulnerabilities, and adjustments to the division of labor among key project members. They can also be trigger rules with thresholds set for high-frequency change scenarios, such as ≥5 code submissions per hour, ≥3 changes to requirements per day, and ≥2 changes to core team members per week. Furthermore, they can be trigger rules set based on the scope of the change's business or technical impact, such as code modifications involving ≥3 core business modules, requirement changes affecting ≥100,000 users, and code modifications affecting the core interface call frequency of ≥1000 times / second.

[0119] The risk assessment method provided in this disclosure monitors changes to the basic data of the target software in real time and automatically triggers a risk assessment operation when the changes meet preset assessment conditions. This achieves immediate response to business and technical dynamics in risk assessment, avoiding the omission of key change risks due to delays in manual reporting. Furthermore, by replacing the traditional manual initiation mode with automated triggering, it significantly shortens the assessment initiation cycle and improves the agility of the delivery process. At the same time, it covers the core data dimensions of the entire software lifecycle, ensuring that risk assessment can accurately capture potential risk points in team collaboration, code modification, and requirement iteration. Moreover, it selects effective trigger scenarios based on assessment conditions, avoiding the waste of resources caused by ineffective assessments. Ultimately, it achieves early detection and early control of risks, providing a strong guarantee for the quality and efficiency of software requirement delivery.

[0120] In one exemplary embodiment, the risk assessment result includes at least one of the following: risk assessment content, risk score, risk level, project modification points, optimization suggestions, and scope of impact.

[0121] In this embodiment of the disclosure, the risk assessment results adopt a multi-dimensional structured output format, covering core dimensions such as risk assessment content, risk score, risk level, project modification points, optimization suggestions, and scope of impact. The output items can be flexibly selected according to the business scenario. The core objective is to provide different roles with a quantitative, comparable, concrete, and clearly defined risk decision-making basis, solving the problems of vague and impractical traditional assessment results.

[0122] The risk assessment content provides a structured description of the nature of the risk, clarifying what the risk is and what causes it. The risk score, using a quantitative indicator from 0 to 100, intuitively reflects the level of risk; the score is calculated based on a weighted sum of characteristic data and dynamic weights of various risk factors. The risk level is a qualitative conclusion based on the risk score and a preset threshold, categorized into low, medium, and high risk, serving as a core indicator for quickly conveying the severity of the risk. Project modification points precisely pinpoint the specific changes associated with the risk, linking them to the monitored basic data and collected multi-dimensional data to ensure the feasibility of risk tracing. Optimization suggestions are actionable guidelines based on professional analysis of domain intelligence agents and historical fault repair experience, possessing specificity and practicality. The scope of impact clarifies the business, technology, and user boundaries that the risk may affect, derived from a comprehensive assessment of multi-dimensional data. The output format of the multi-dimensional results can follow a preset Markdown template to ensure a consistent structure and high readability.

[0123] For example, the risk assessment results may include the following:

[0124] Risk assessment content: Currently, there is no code implementation, so the technical implementation risks cannot be identified; the requirement involves fund-related logic, and subsequent code needs to pay attention to the security of the fund flow; the requirement involves tag filtering and data invalidation, and the accuracy of subsequent implementation needs to be monitored.

[0125] Risk score: 13 points.

[0126] Risk level: Low risk.

[0127] Project changes: This requirement is for the planning of the funding-related module, involving the organization of tag data, without any actual code changes.

[0128] Optimization suggestions: 1. It is recommended to conduct a code review again when submitting code in the future, with a focus on the fund flow and data security; 2. It is recommended to add self-testing instructions to ensure that the requirement logic is fully verified before actual implementation.

[0129] Scope of impact: The impact is small, does not involve core links, the change type is configuration change, the number of lines of code changed is 0, and the self-testing situation is not described.

[0130] The risk assessment method provided in this disclosure, by clearly defining the core dimensions of the risk assessment results, including risk assessment content, risk score, risk level, project modification points, optimization suggestions, and scope of impact, achieves both quantification and visualization of risk assessment. This solves the problems of vagueness and lack of unified standards in traditional manual assessments. The risk score and level provide intuitive and comparable quantitative indicators, ensuring consensus among different roles on the degree of risk. Project modification points accurately pinpoint the source of risk, while the risk assessment content and scope of impact clearly define the nature of the risk and the affected business or technical boundaries, avoiding the predicament of knowing there is risk but not knowing where it is located. Optimization suggestions directly provide actionable rectification directions, transforming the assessment results into practical action guidelines and significantly reducing the execution cost of risk management. Simultaneously, the multi-dimensional results can adapt to the decision-making needs of different roles, improving cross-role collaboration efficiency. Furthermore, the structured result format provides standardized data support for subsequent result traceability, bad case collection, and model optimization, further strengthening the closed-loop iterative capability of the risk assessment system.

[0131] To enable those skilled in the art to better understand the embodiments of this disclosure, the embodiments of this disclosure are described below through specific examples.

[0132] This disclosure discloses an automated, standardized, and dynamically adaptable risk assessment scheme. By combining multi-dimensional data collection, intelligent analysis algorithms, and dynamic configuration technologies, and leveraging the understanding and analysis capabilities of large-scale models, along with business characteristics and risk models, it systematically improves the accuracy and efficiency of requirements assessment, reduces quality risks caused by inconsistent rules and differences in human experience, and ultimately improves project delivery time and product quality. The overall architecture of the risk assessment scheme is as follows: Figure 5 As shown, the main modules include a presentation layer, a service layer, a data layer, and a storage layer. The main responsibilities of each layer are as follows:

[0133] Presentation Layer: Through a visual interface, the assessment results of demand risks are displayed in the form of charts and figures, such as... Figure 6 As shown, this helps users intuitively understand the data. It also automatically pushes risk assessment reports, supports a visual configuration panel, and the reports can display changes in requirements, risk levels (low / medium / high), assessment reasons, and optimization suggestions to assist users in making decisions. Dynamic configuration allows business, product, and technical personnel to adjust parameters such as risk factor weights, judgment thresholds, and judgment strategies in real time, making the strategies more suitable for business needs.

[0134] Service Layer: By monitoring team status in real time and pulling code change information, and combining risk model calculations and threshold settings to quantify risks, the system dynamically optimizes the model through fine-tuning and creativity adjustments, and automatically pushes reports. Data Layer: The underlying data system is built using basic data (Team / Git / PRD documents), business characteristics (historical fault database / code characteristics / personnel characteristics), and domain-specific intelligent agents (funding agent / security agent / data agentd, etc.). This comprehensively supports risk quantification and dependency analysis, enabling accurate risk assessment based on requirements.

[0135] Data Layer: The underlying data system is built through basic data (Team / Git / PRD documents), business characteristics (historical fault database / code characteristics / personnel characteristics) and domain intelligent agents (funding agent / security agent / data agent / quality agent, etc.) to fully support risk quantification and chain dependency analysis, and achieve accurate demand risk assessment.

[0136] Storage layer: The original information of the requirements, intelligent analysis results, operation logs and other information are stored through a MySQL database, and strict access control is implemented to ensure that only authorized users can access and operate the data.

[0137] Based on the above architecture, such as Figure 7 As shown, the entire process of demand risk assessment, from data collection, professional analysis, model reasoning, to result output, is fully presented from three dimensions: data layer, service layer, and workflow layer, combined with a dual-trigger mechanism of active and passive links. The main process of demand risk assessment is as follows:

[0138] Data Acquisition and Triggering: The system actively listens for key events in real time, capturing both status-related and data-related events. This automatically triggers the evaluation process and simultaneously retrieves four types of data: code characteristics, historical faults, business scenarios, and personnel characteristics. Status-related events include changes in the requirement lifecycle (e.g., requirement submission, modification, deployment application) and team collaboration status (adjustments to member roles, progress delays). Data-related events include Git code changes (commit, merge, branch creation), business configuration updates, and fault alarm triggers. The system simultaneously retrieves four types of data: code characteristics, historical faults, business scenarios, and personnel characteristics.

[0139] Data processing: Distribute the data to the corresponding domain agents according to their professional fields, analyze the data, and obtain the professional feature datasets of each domain.

[0140] Dynamic weight configuration: The system can adjust the risk factor weights in real time according to business scenarios, and users can also adjust the risk factor weights and risk thresholds through a visual interface.

[0141] Agent Deep Analysis: Each domain-specific agent calculates domain-specific risks based on its own professional feature dataset and assigned weights. An intelligent scheduling algorithm then standardizes the format of the domain risk results output by each agent, verifies conflicts (e.g., conflicting risk assessments of the same code modification by different agents), and completes information to generate a multi-domain risk summary dataset. A large-scale model then leverages semantic understanding and multi-dimensional reasoning capabilities to perform three layers of calculations on the summary data: factor correlation analysis, global risk quantification, and risk level determination. Factor correlation analysis identifies cross-domain risk associations, such as code vulnerabilities, security risks, user financial losses, and financial risks. Global risk quantification calculates a comprehensive risk score using a dynamic weight matrix, such as a weighted summation: security score × 0.4 + financial score × 0.3 + ... . Risk level determination compares the risk to preset thresholds and outputs the final risk level (high / medium / low), core risk chain, and scope of impact (technology / business / personnel).

[0142] Automated output and visualized collaboration: The system automatically pushes assessment results to relevant roles. Assessment results can be structured reports or real-time alerts. Structured reports include risk level, risk point details, impact scope, remedial suggestions, and supporting data (such as related code snippets and historical failure cases). Real-time alerts include pop-ups / SMS / email alerts triggered by high-risk requirements, ensuring timely response. A visual dashboard intuitively displays risk distribution, assessment dimension breakdown, and risk trends. Users can also adjust strategies based on assessment results through a visual interface, such as increasing the security weight of a business line or reducing the assessment frequency of low-risk requirements.

[0143] Regarding the above risk assessment process, such as Figure 7 As shown, the specific responsibilities of the data layer, service layer, and workflow layer are as follows:

[0144] The data layer is the data foundation for risk assessment. It uses a MySQL database as the core storage medium and integrates multi-source data to form a raw material pool for risk assessment, including domain knowledge base, business knowledge base, historical risk database, requirement data storage, team information, and requirement conclusion acquisition.

[0145] The service layer is the core engine for professional analysis and data processing, serving as a bridge between the data layer and the workflow layer. It collects and processes data through both active and passive channels, outputting structured features suitable for risk assessment. The passive channel is driven by team status. By capturing real-time changes in team collaboration and identifying lifecycle changes to requirements, it encapsulates these changes into standardized messages and asynchronously pushes them to the workflow layer via Kafka. The active channel is driven by message pushes. External systems initiate assessment requests via message pushes (including manual initiation). After the message body is constructed and encapsulated in Kafka, it triggers the assessment process in the workflow layer.

[0146] The workflow layer is the decision-making center for risk reasoning and result output. Based on the Luigi task scheduling framework, it automates risk assessment reasoning and result optimization, while also maintaining the prompt. Upon receiving a risk assessment message, it parses it into a model-recognizable input format, retrieves relevant requirement information from the service layer via API calls, integrates the prompt and feature data based on the semantic understanding and multi-dimensional reasoning capabilities of the large model, makes a preliminary risk assessment, and outputs a comprehensive risk conclusion by combining dynamic weights and assessment thresholds. For example, Figure 8 As shown, the risk analysis of the large model mainly includes the following three core logics:

[0147] Multimodal data processing. First, the collected multi-source heterogeneous data undergoes cleaning, noise reduction, and formatting to eliminate irrelevant information and standardize the input format, ensuring data accuracy and reliability. For example, unstructured requirement documents are vectorized into text, or code change information is transformed into quantitative features representing complexity and risk. Second, data features are extracted, selected, and fused to construct a multi-dimensional feature vector that characterizes requirement risks. This includes features such as historical failure rates, code modification volume, number of core business modules, and personnel experience.

[0148] Model training and optimization. The model is trained and fine-tuned using historical data (including demand characteristics and final risk outcome labels). The model's predictions are compared with its actual performance after going live, and bad cases (false positives and false negatives) are continuously collected. New case data is collected into the training dataset for periodic model fine-tuning, forming a continuous learning loop. This allows the model to adapt to rapid changes in business and technology, maintaining a high level of model analysis accuracy.

[0149] Risk prediction and quantification. The trained model is encapsulated as an API interface, which is then used to perform risk assessments on requirements. The specific process involves inputting preprocessed feature data (requirement documents, code changes, personnel characteristics, etc.) into the model. The model sequentially assesses information such as the scope of impact, risk pathways, code change scope, and change type. Simultaneously, it combines the results of domain intelligence agent recall (risks in areas such as security, quality, data, and funding), performs comprehensive analysis and calculations according to the weights set by the risk assessment model, and then, based on the previously determined risk level and hard-nothing criteria, outputs a structured report using a fixed Markdown template. This report includes a risk score, risk level, project change points, risk assessment content, recommendations, and provides feedback and confirmation buttons. The model can provide supplementary explanatory text, outputting the core key characteristics of this risk, such as "This change involves a core interface for fund payment" or "This code change has a high historical failure rate," explaining the high-risk determination and helping R&D and testing personnel understand the report content and take targeted measures.

[0150] This disclosed embodiment, by introducing the understanding and analysis capabilities of a large model, enables the solution to deeply integrate and analyze multi-dimensional data such as requirement documents, code changes, business scenarios, and historical failures. The adopted dynamic multi-factor risk model, such as funding, security, and performance agents, can identify potential related risks and complex scenario risks that are difficult to detect using traditional methods. This significantly reduces the false negative rate of issues caused by rule omissions or experience differences, improving the accuracy and comprehensiveness of risk assessment. By real-time monitoring of development status (such as requirement status and Git code changes) and automated data retrieval and analysis processes, the assessment process, which originally relied heavily on manual communication and subjective judgment, is shortened to within minutes. This automated and standardized assessment process greatly frees up manpower and improves the overall agility of R&D delivery. The solution is not a fixed rule set; its embedded model fine-tuning, creativity adjustment, and threshold configuration mechanisms allow it to self-optimize and iteratively update based on historical assessment results, new business data, and constantly changing requirements. This ensures that the risk assessment standards keep pace with business and technological developments, preventing the assessment model from becoming outdated and possessing good dynamic adaptability and continuous evolution capabilities. By using visual dashboards, dynamic configuration panels, and structured reports (including risk classification, rationale, and optimization suggestions), risk assessment results become intuitive and easy to understand. Product, technical, and business personnel can not only clearly understand where the risks lie, but also adjust parameters such as risk factor weights and judgment thresholds to make the assessment strategy more aligned with their actual business needs. By identifying risks in high-risk areas such as financial security, data consistency, and system performance earlier and more accurately, it helps to take preventative measures at the beginning of the development cycle, preventing problems from erupting later or even in the production environment. This significantly reduces remediation costs, protects the company's reputation, and avoids potential compliance issues.

[0151] It should be understood that, although Figures 1-8 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figures 1-8 At least some of the steps in the process may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but may be executed at different times. The execution order of these steps or stages is not necessarily sequential, but may be executed in turn or alternately with other steps or at least some of the steps or stages in other steps.

[0152] It is understood that the same / similar parts between the various embodiments of the methods described above in this specification can be referred to each other. Each embodiment focuses on the differences from other embodiments, and relevant parts can be referred to the description of other method embodiments.

[0153] Figure 9 This is a block diagram 900 illustrating a risk assessment apparatus according to an exemplary embodiment. (Refer to...) Figure 9 The device includes a data acquisition unit 902, an extraction unit 904, a data construction unit 906, and an output unit 908. Wherein:

[0154] The data acquisition unit 902 is configured to collect multi-dimensional data for the target software when a risk assessment operation for the target software is triggered. The multi-dimensional data includes business characteristic data of the target software and domain knowledge data of the target software.

[0155] Extraction unit 904 is configured to extract feature data corresponding to each risk factor from multivariate data;

[0156] Construction unit 906 is configured to execute the construction of the target prompt based on the feature data corresponding to each risk factor and the prompt word template;

[0157] Evaluation unit 908 is configured to take the target prompt as input into the risk assessment model and output the risk assessment results for the target software.

[0158] In one exemplary embodiment, the business characteristic data includes at least one of business data, user behavior data, historical fault data, code change data, requirement document data, and personnel characteristic data; the domain knowledge data includes data from various professional fields, including at least one of security, quality, finance, and data fields.

[0159] In one exemplary embodiment, the apparatus further includes:

[0160] The identification unit is configured to execute the call to the domain intelligence agent corresponding to each of the professional fields to perform risk identification on the business feature data, and obtain the risk identification results corresponding to each of the professional fields respectively;

[0161] The determining unit is configured to use the risk identification results corresponding to each of the professional fields as domain knowledge data for the target software.

[0162] In one exemplary embodiment, the apparatus further includes:

[0163] The response unit is configured to perform a configuration operation in response to a risk assessment strategy, determining at least one of the risk factors, risk factor weights, risk determination thresholds, and risk assessment strategies.

[0164] In an exemplary embodiment, the step of constructing the target prompt based on the feature data corresponding to each of the risk factors and the prompt template includes:

[0165] The initial prompt template is adjusted based on at least one of the risk factors, the risk factor weights, the risk assessment threshold, and the risk assessment strategy to obtain the prompt template.

[0166] The feature data corresponding to each of the risk factors are filled into the prompt template to construct the target prompt.

[0167] In one exemplary embodiment, the apparatus further includes:

[0168] The monitoring unit is configured to perform real-time monitoring of changes in the basic data of the target software, including team status data, code data, and requirement data corresponding to the target software.

[0169] The assessment unit is configured to trigger a risk assessment operation for the target software when it detects that the changes in the basic data meet the risk assessment conditions.

[0170] In one exemplary embodiment, the risk assessment result includes at least one of the following: risk assessment content, risk score, risk level, project modification points, optimization suggestions, and scope of impact.

[0171] The risk assessment device provided in this disclosure, upon triggering a risk assessment operation for target software, collects multi-source data for the target software. This multi-source data includes business characteristic data and domain knowledge data of the target software. Further, it extracts feature data corresponding to each risk factor from the multi-source data and constructs a target prompt based on the feature data corresponding to each risk factor and a prompt template. Finally, the target prompt is input into a large-scale risk assessment model, outputting a risk assessment result for the target software. The risk assessment device provided in this disclosure, by introducing the semantic understanding and multi-source data fusion capabilities of a large-scale model, performs in-depth analysis and correlation analysis of the multi-source data of the target software. This allows for accurate capture of implicit relationships between risk factors, thus significantly improving the accuracy of risk assessment results, reducing cross-role communication costs, and increasing the efficiency of risk assessment.

[0172] Figure 10 This is a block diagram illustrating an electronic device 1000 for a risk assessment method according to an exemplary embodiment. For example, the electronic device 1000 may be a mobile phone, computer, digital broadcasting terminal, messaging device, game console, tablet device, medical device, fitness equipment, personal digital assistant, etc.

[0173] Reference Figure 10 The electronic device 1000 may include one or more of the following components: processing component 1002, memory 1004, power supply component 1006, multimedia component 1008, audio component 1010, input / output (I / O) interface 1012, sensor component 1014, and communication component 1016.

[0174] Processing component 1002 typically controls the overall operation of electronic device 1000, such as operations associated with display, telephone calls, data communication, camera operation, and recording operations. Processing component 1002 may include one or more processors 1020 to execute instructions to perform all or part of the steps of the methods described above. Furthermore, processing component 1002 may include one or more modules to facilitate interaction between processing component 1002 and other components. For example, processing component 1002 may include a multimedia module to facilitate interaction between multimedia component 1008 and processing component 1002.

[0175] Memory 1004 is configured to store various types of data to support the operation of electronic device 1000. Examples of such data include instructions for any application or method operating on electronic device 1000, contact data, phonebook data, messages, pictures, videos, etc. Memory 1004 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, optical disk, or graphene storage.

[0176] Power supply component 1006 provides power to various components of electronic device 1000. Power supply component 1006 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic device 1000.

[0177] Multimedia component 1008 includes a screen that provides an output interface between the electronic device 1000 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of the touch or swipe action but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 1008 includes a front-facing camera and / or a rear-facing camera. When the electronic device 1000 is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0178] Audio component 1010 is configured to output and / or input audio signals. For example, audio component 1010 includes a microphone (MIC) configured to receive external audio signals when electronic device 1000 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 1004 or transmitted via communication component 1016. In some embodiments, audio component 1010 also includes a speaker for outputting audio signals.

[0179] I / O interface 1012 provides an interface between processing component 1002 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0180] Sensor assembly 1014 includes one or more sensors for providing state assessments of various aspects of electronic device 1000. For example, sensor assembly 1014 can detect the on / off state of electronic device 1000, the relative positioning of components such as the display and keypad of electronic device 1000, changes in position of electronic device 1000 or its components, the presence or absence of user contact with electronic device 1000, orientation or acceleration / deceleration of device 1000, and temperature changes of electronic device 1000. Sensor assembly 1014 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 1014 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 1014 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.

[0181] Communication component 1016 is configured to facilitate wired or wireless communication between electronic device 1000 and other devices. Electronic device 1000 can access wireless networks based on communication standards, such as WiFi, carrier networks (such as 2G, 6G, 4G, or 5G), or combinations thereof. In one exemplary embodiment, communication component 1016 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 1016 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0182] In an exemplary embodiment, the electronic device 1000 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the methods described above.

[0183] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 1004 including instructions, which can be executed by a processor 1020 of an electronic device 1000 to perform the above-described method. For example, the computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0184] In an exemplary embodiment, a computer program product is also provided, the computer program product including instructions that can be executed by the processor 1020 of the electronic device 1000 to perform the above method.

[0185] It should be noted that the above-mentioned apparatus, electronic equipment, computer-readable storage medium, computer program product, etc., may also include other implementation methods according to the description of the method embodiments. For specific implementation methods, please refer to the description of the relevant method embodiments, which will not be elaborated here.

[0186] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the claims.

[0187] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A risk assessment method, characterized in that, include: When a risk assessment operation is triggered for the target software, multi-dimensional data is collected for the target software, including business characteristic data of the target software and domain knowledge data of the target software; Extract feature data corresponding to each risk factor from the multivariate data; Based on the feature data corresponding to each risk factor and the prompt template, a target prompt is constructed. The target prompt is input into the risk assessment model, and the risk assessment results for the target software are output.

2. The method according to claim 1, characterized in that, The business characteristic data includes at least one of the following: business data, user behavior data, historical fault data, code change data, requirement document data, and personnel characteristic data; the domain knowledge data includes data from various professional fields, including at least one of the following: security, quality, finance, and data.

3. The method according to claim 2, characterized in that, The method further includes: The domain intelligence agents corresponding to each of the aforementioned professional fields are invoked to perform risk identification on the business feature data, and risk identification results corresponding to each of the aforementioned professional fields are obtained respectively; The risk identification results corresponding to each of the aforementioned professional fields are used as the domain knowledge data of the target software.

4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: In response to a configuration operation for a risk assessment strategy, at least one of the risk factors, risk factor weights, risk determination thresholds, and risk assessment strategies is determined.

5. The method according to claim 4, characterized in that, The target prompt is constructed based on the feature data corresponding to each risk factor and the prompt template, including: The initial prompt template is adjusted based on at least one of the risk factors, the risk factor weights, the risk assessment threshold, and the risk assessment strategy to obtain the prompt template. The feature data corresponding to each of the risk factors are filled into the prompt template to construct the target prompt.

6. The method according to claim 1, characterized in that, The method further includes: Real-time monitoring of changes in the target software's basic data, including team status data, code data, and requirement data corresponding to the target software; When the changes in the basic data are detected to meet the risk assessment criteria, a risk assessment operation for the target software is triggered.

7. The method according to claim 1, characterized in that, The risk assessment results include at least one of the following: risk assessment content, risk score, risk level, project modification points, optimization suggestions, and scope of impact.

8. A risk assessment device, characterized in that, include: The data acquisition unit is configured to collect multi-dimensional data for the target software when a risk assessment operation for the target software is triggered. The multi-dimensional data includes business characteristic data of the target software and domain knowledge data of the target software. The extraction unit is configured to extract feature data corresponding to each risk factor from the multivariate data; The construction unit is configured to execute the construction of a target prompt based on the feature data corresponding to each of the risk factors and the prompt template; The evaluation unit is configured to take the target prompt as input to a risk assessment model and output a risk assessment result for the target software.

9. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the risk assessment method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the risk assessment method as described in any one of claims 1 to 7.

Images