Decision logic analysis methods and related equipment

Abstract

This specification discloses a decision logic analysis method and related equipment. The method includes: concurrently collecting real-time rule trigger event streams and decision logic source code from the server during server-side decision engine runtime; constructing a dynamic call graph based on the real-time rule trigger event stream, the dynamic call graph containing rule nodes and dynamic attributes of rule triggers; constructing a static dependency graph based on the decision logic source code, the static dependency graph containing variable nodes and code-level dependencies; parsing the association between the dynamic call graph and the static dependency graph to generate a dynamic-static fusion strategy graph; and rendering a heatmap based on the dynamic-static fusion strategy graph for display on a visualization interface.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a decision logic analysis method and related equipment. Background Technology

[0002] In existing decision engines, rule triggering behavior is dynamic, while code-level dependencies are static. These two aspects are often treated separately in traditional technologies, making it difficult to observe the runtime triggering chain as a whole, accurately identify the relationships between rules, and promptly detect policy bottlenecks, redundant logic, and abnormal paths. Furthermore, existing systems generally lack visualization tools that can uniformly present runtime triggering relationships and static code structure, failing to intuitively demonstrate the triggering frequency of rules and their impact on the overall policy. This results in high costs and low efficiency in policy analysis, auditing, and optimization. Summary of the Invention

[0003] This specification provides a decision logic analysis method and related equipment, the technical solution of which is as follows:

[0004] Firstly, this specification provides a decision logic analysis method, which includes: concurrently collecting real-time rule trigger event streams and decision logic source code from the server during server-side decision engine runtime; constructing a dynamic call graph based on the real-time rule trigger event stream, the dynamic call graph containing rule nodes and dynamic attributes of rule triggers; constructing a static dependency graph based on the decision logic source code, the static dependency graph containing variable nodes and code-level dependencies; parsing the association between the dynamic call graph and the static dependency graph to generate a dynamic-static fusion strategy graph; and rendering a heatmap based on the dynamic-static fusion strategy graph for display on a visualization interface.

[0005] Secondly, this specification provides a decision logic analysis device, comprising: a characterization data acquisition module for parallel acquisition of real-time rule trigger event streams and decision logic source code of the server during server-side decision engine runtime; a dynamic call construction module for constructing a dynamic call graph based on the real-time rule trigger event stream, the dynamic call graph including rule nodes and dynamic attributes of rule triggers; a static dependency construction module for constructing a static dependency graph based on the decision logic source code, the static dependency graph including variable nodes and code-level dependencies; a dynamic-static fusion strategy module for parsing the association between the dynamic call graph and the static dependency graph and generating a dynamic-static fusion strategy graph; and a heatmap visualization module for rendering a heatmap based on the dynamic-static fusion strategy graph for display on a visualization interface.

[0006] Thirdly, this specification provides a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the above-described method steps.

[0007] Fourthly, this specification provides an electronic device that may include: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the above-described method steps.

[0008] Fifthly, this specification provides a computer program product that stores at least one instruction, which is loaded by a processor and executes the above-described method steps.

[0009] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following:

[0010] In one or more embodiments of this specification, by collecting runtime behavioral data and static logical data in parallel and representing them in the form of a graph, the unobservability of decision-making logic can be eliminated at the overall level, and the traceability and quantifiability of the decision execution chain can be achieved, thereby providing a unified and reliable data foundation for subsequent rule analysis, coverage evaluation and strategy optimization. Attached Figure Description

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

[0012] Figure 1 This is a scenario diagram of a decision logic analysis system provided in this manual.

[0013] Figure 2 This is a flowchart illustrating a decision logic analysis method provided in this manual.

[0014] Figure 3 It is based on Figure 2 The flowchart shows the specific implementation of step S300 in the decision logic analysis method shown in the corresponding embodiment.

[0015] Figure 4 It is based on Figure 2 The flowchart shows the specific implementation of step S400 in the decision logic analysis method shown in the corresponding embodiment.

[0016] Figure 5 It is based on Figure 4The flowchart shows the specific implementation of step S410 in the decision logic analysis method shown in the corresponding embodiment.

[0017] Figure 6 This is a flowchart illustrating another decision logic analysis method provided in this manual.

[0018] Figure 7 This is a schematic diagram of a decision logic analysis device provided in this specification.

[0019] Figure 8 This is a schematic diagram of the structure of an electronic device provided in this specification.

[0020] Figure 9 This is a schematic diagram of the operating system and user space provided in this manual.

[0021] Figure 10 yes Figure 9 Architecture diagram of the Android operating system in China.

[0022] Figure 11 yes Figure 9 Architecture diagram of the iOS operating system. Detailed Implementation

[0023] The technical solutions in 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 are within the scope of protection of this specification.

[0024] In the description of this specification, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. In the description of this specification, it should be noted that, unless otherwise expressly specified and limited, "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. Those skilled in the art can understand the specific meaning of the above terms in this specification based on the specific circumstances. Furthermore, in the description of this specification, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0025] The present specification will now be described in detail with reference to specific embodiments.

[0026] Please see Figure 1 This is a schematic diagram of a decision logic analysis system provided in this specification. Figure 1 As shown, the decision logic analysis system may include at least a client cluster and a service platform 100.

[0027] The client cluster may include at least one client, such as Figure 1 As shown, it specifically includes client 1 corresponding to user 1, client 2 corresponding to user 2, ..., client n corresponding to user n, where n is an integer greater than 0.

[0028] Each client in a client cluster can be an electronic device with communication capabilities, including but not limited to: wearable devices, handheld devices, personal computers, tablets, in-vehicle devices, smartphones, computing devices, or other processing devices connected to a wireless modem. Electronic devices may have different names in different networks, such as: user equipment, access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent or user device, cellular phone, cordless phone, personal digital assistant (PDA), and electronic devices in 5G networks or future evolved networks.

[0029] The service platform 100 can be a standalone server device, such as a rack-mount, blade, tower, or cabinet-type server device, or a workstation, mainframe, or other hardware device with strong computing power; or it can be a server cluster composed of multiple servers. The servers in the service cluster can be composed in a symmetrical manner, wherein each server is functionally and hierarchically equivalent in the transaction chain, and each server can provide services independently. The independent provision of services can be understood as not requiring the assistance of other servers.

[0030] In one or more embodiments of this specification, the service platform 100 can establish a communication connection with at least one client in the client cluster, and complete the data interaction during the decision logic analysis process based on the communication connection, such as online transaction data interaction. For example, the service platform 100 can display the dynamic and static fusion strategy map and heat map obtained by the decision logic analysis method of this specification on the visualization interface.

[0031] It should be noted that the service platform 100 establishes a communication connection with at least one client in the client cluster via a network for interactive communication. This network can be a wireless network or a wired network. Wireless networks include, but are not limited to, cellular networks, wireless LANs, infrared networks, or Bluetooth networks. Wired networks include, but are not limited to, Ethernet, universal serial bus (USB), or controller area networks. In one or more embodiments of the specification, technologies and / or formats including Hyper Text Markup Language (HTML), Extensible Markup Language (XML), etc., are used to represent data exchanged over the network (such as target compressed packets). Furthermore, conventional encryption technologies such as Secure Socket Layer (SSL), Transport Layer Security (TLS), Virtual Private Network (VPN), and Internet Protocol Security (IPsec) can be used to encrypt all or some links. In other embodiments, customized and / or dedicated data communication technologies can be used to replace or supplement the aforementioned data communication technologies.

[0032] The decision logic analysis system embodiments provided in this specification and the decision logic analysis methods described in one or more embodiments belong to the same concept. The execution entity corresponding to the decision logic analysis method involved in one or more embodiments of this specification can be the aforementioned service platform 100; the execution entity corresponding to the decision logic analysis method involved in one or more embodiments of this specification can also be the electronic device corresponding to the client, specifically determined based on the actual application environment. The implementation process of the decision logic analysis system embodiments can be detailed in the following method embodiments, and will not be repeated here.

[0033] based on Figure 1 The following is a detailed description of the decision logic analysis method provided by one or more embodiments of this specification, illustrated in the scenario diagram.

[0034] Please see Figure 2This document provides a flowchart illustrating a decision logic analysis method for one or more embodiments of this specification. This method can be implemented using a computer program and can run on a decision logic analysis device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone tool application. The decision logic analysis device can be a service platform. Specifically, the decision logic analysis method includes: S100, concurrently collecting real-time rule trigger event streams and decision logic source code from the server during server-side decision engine operation; S210, constructing a dynamic call graph based on the real-time rule trigger event stream, the dynamic call graph containing rule nodes and dynamic attributes of rule triggers; S220, constructing a static dependency graph based on the decision logic source code, the static dependency graph containing variable nodes and code-level dependencies; S300, parsing the relationship between the dynamic call graph and the static dependency graph to generate a dynamic-static fusion strategy graph; and S400, rendering a heatmap based on the dynamic-static fusion strategy graph for display on a visualization interface. In this specification, by simultaneously collecting runtime dynamic data and static source code dependencies, and using graph structure modeling to integrate the two types of heterogeneous data, the decision-making logic can be visualized and the rule execution behavior can be quantitatively presented.

[0035] Specifically, in some embodiments, this method is applied to a distributed network device configuration system, which contains multiple configuration decision rules. During device online or parameter refresh, the platform collects the trigger events for each rule at runtime, including the rule number, trigger time, input parameters, and execution result. This constructs a dynamic call graph, recording the actual execution sequence and trigger frequency of the rules. Simultaneously, the distributed network device configuration system parses static variable dependencies based on the configuration script, constructing a static dependency graph. Subsequently, dynamic rule nodes are aligned with static variable nodes through identifier matching, forming a dynamic-static fusion strategy graph. The distributed network device configuration system uses color rendering based on the execution load and trigger frequency of different nodes in the fusion graph, forming a heatmap displayed in the management interface to assist administrators in analyzing the execution status of configuration strategies.

[0036] In other embodiments, this method is applied to a financial services risk control system whose audit engine contains multiple risk control rules. During the actual audit process, the financial services risk control system collects rule trigger event streams in parallel, including rule codes, customer characteristic information, rule judgment results, and execution times. Based on this data, the financial services risk control system constructs a dynamic call graph to describe the rule triggering path and trigger intensity. Simultaneously, the financial services risk control system constructs a static dependency graph based on the variable dependencies obtained from parsing the risk control strategy code. Through unified processing of node identifiers, the two types of graphs are merged into a dynamic-static fused strategy graph. Based on the fused graph, the financial services risk control system uses color gradients to generate a heatmap, displaying rule popularity, critical paths, and low-frequency branches, for risk control personnel to use for auditing, optimization, and strategy iteration.

[0037] In S100, a data acquisition component is deployed in the server-side decision engine to collect data characterizing the execution behavior of decision logic in parallel without affecting decision execution performance. The collected data includes rule identifiers, trigger times, input variables, output results, context information, and execution path identifiers. The acquisition process employs a parallel mechanism, decoupled from the main thread of the server-side decision engine, and does not interfere with the normal decision processing flow. In specific implementations, event acquisition logic can be injected at the rule execution entry point using runtime probes or bytecode enhancement. This probe records metadata such as policy identifiers, rule identifiers, timestamps, session identifiers, variable summaries, execution results, and execution time, and writes them asynchronously to a message queue. This formalized metadata can be directly used for constructing dynamic call graphs and subsequent path analysis. The server-side decision engine can be understood as a computer system component used for the automated execution of platform service rules, platform service policy judgments, and service policy configuration management for corresponding computer platform services. In this specification, the application of the server-side decision engine may include, but is not limited to, network device configuration management systems, user service recommendation engines, network security risk control systems, and financial risk control systems. The processing logic representation data on the server side can be understood as a data set reflecting the internal operating mechanism of the decision engine on the decision server side. In some embodiments, it may include dynamic data generated during service decision processing and static data of the decision logic. Among them, dynamic data includes trajectories, logs, context, and performance indicators, while static data includes source code, script files, configuration files, or rule definition languages ​​that define the decision logic.

[0038] In S210 and S220, events are triggered based on collected runtime rules. Rule nodes generate directed graphs according to the triggering order and relationships, with dynamic attributes such as trigger count and execution result. Simultaneously, by performing syntax parsing or dependency analysis on the decision logic source code, the dependency relationships between variable nodes and the code layer are identified, generating a graph reflecting the static logical structure. The dynamic call graph can be understood as a directed graph-based data structure used to represent the actual triggering order, jump relationships, and execution frequency of each rule node or functional unit in the decision logic within a specific time window. The static dependency graph can be understood as a data structure generated based on code analysis, used to represent the definition reference relationships and data flow of variables, parameters, functions, or rule objects at the code level. Illustratively, the construction of the dynamic call graph is initiated, traffic logs are aggregated based on the time window, and each processing module is used as a graph node. Directed edges are established according to the actual flow of platform service traffic. For example, if platform service traffic is dropped at a blacklist filtering node, the edge pointing to subsequent nodes will become thinner or disappear; if traffic passes through, the edge becomes thicker. The edge attributes record the traffic throughput. It should be noted that the time window can be set as needed, such as half a minute, one minute, two minutes, etc., and this manual does not limit it. The aforementioned processing modules can be protocol parsing processing modules, blacklist filtering processing modules, feature matching processing modules, etc. Illustratively, the static dependency graph is built upon startup, the parser reads the security policy file, and identifies rule objects (nodes) and their logical dependencies (edges).

[0039] In S210 and S220, the processing logic representation data is refined into two types of data input: runtime trigger event streams and decision logic source code. Two graph structures are constructed, one based on dynamic runtime behavior and the other on static logic structure, providing a dual-perspective data foundation for the decision-making process. Specifically, the probe module reads the rule trigger event streams collected during runtime. Based on the rule identifier, trigger order, trigger time, execution result, context parameters, and execution count recorded in the event stream, a dynamic call graph is constructed. Specifically, the dynamic call graph is constructed by treating each triggered rule as a rule node in the graph, establishing directed edges based on the trigger order between runtime rules, and attaching runtime attributes to the nodes or edges as dynamic attributes. If nested calls or conditional branches exist, a tree-like or graph-like call structure is further formed. It should be noted that runtime attributes include the number of triggers, execution time, and trigger result. In high-concurrency scenarios, the probe module can submit event data in batches through a local buffer queue to ensure that the rule execution thread is not blocked. Probe failures are handled uniformly through a degradation strategy, without affecting the execution of the main server's service process. Static syntax parsing or dependency analysis is performed on the source code of the decision logic to identify data variables, computational relationships between variables, variables used in conditional statements, and data flow relationships between rules. This information is then modeled as a static dependency graph, whose elements include variable nodes and dependency edges. Variable nodes represent input variables, intermediate variables, derived variables, etc., appearing in the decision logic, while dependency edges represent assignment, reference, or dependency relationships between variables, used to depict the logical structure of the code layer. It should be noted that the construction of the static dependency graph supports an incremental update mechanism; when the code version changes, re-parsing is automatically triggered and the graph structure is merged with the existing graph. Version control and snapshot mechanisms ensure the consistency and traceability of the graph structure.

[0040] Specifically, in some embodiments, the distributed configuration management system executes a series of parameter validation and configuration rules upon device access. During execution, the distributed configuration management system records a real-time rule trigger event stream, including rule number, execution result, input parameters, and timestamp. Based on these events, the distributed configuration management system constructs a dynamic call graph, where nodes represent configuration rules, edges reflect the rule triggering order, and include dynamic attributes such as the number of triggers. On the other hand, the distributed configuration management system parses the device configuration script, analyzes the definition and reference relationships of variables in the script, and generates a static dependency graph, where variable nodes represent configuration parameters, intermediate variables, and derived parameters, and dependency edges represent the logical relationships between parameters. These two graph structures will be used for fusion in subsequent steps.

[0041] In other embodiments, for the financial services review process, the risk control engine executes risk control rules when processing each loan application, generating a rule trigger event stream in real time. The event stream includes information such as rule ID, customer characteristics, judgment result, and trigger time. Based on the event stream, the risk control engine constructs a dynamic call graph to record the risk control rule trigger path and dynamic attributes. Simultaneously, the risk control engine performs static parsing based on the risk control strategy code to identify risk scoring rules, variable calculation rules, and their dependencies, establishing a static dependency graph. This graph contains variable nodes such as credit limit variables, time variables, and derived scoring variables, and uses dependency edges to represent calculation relationships. This static graph is used to subsequently combine with the dynamic graph to generate a fusion graph.

[0042] In the embodiments corresponding to S210 and S220, the real-time rule-triggered event flow is constructed into a dynamic call graph and the decision logic source code is parsed into a static dependency graph, so that runtime behavior and code-level dependencies are expressed in a structured graphical form, which solves the problem of inconsistency between runtime information and static code information in terms of representation and semantics, and lays a precise structural basis for subsequent semantic mapping and data fusion between graphs.

[0043] In S300, fusion is achieved through node identifier matching, attribute migration, and other methods. Alignment relationships are established between rule nodes in the dynamic call graph and variable nodes in the static dependency graph. Dynamic attributes (such as trigger count and execution time) are mapped to relevant nodes or edges in the static dependency graph, forming a unified strategy graph containing both static structure and dynamic behavior. The dynamic-static fusion strategy graph can be understood as the composite graph structure involved in this specification. It can be achieved by mapping the time / frequency attributes of the dynamic call graph to the topology of the static dependency graph through node alignment, thereby simultaneously containing logical dependencies and runtime load information. Specifically, in some embodiments, the specific implementation of step S300 can be found in [the relevant documentation / reference]. Figure 3 . Figure 3 It is based on Figure 2 The detailed description of step S300 in the decision logic analysis method shown in the corresponding embodiment includes the following steps: S310, establishing a mapping relationship between rule nodes in the dynamic call graph and variable nodes in the static dependency graph through a node alignment mechanism; S320, mapping the dynamic attributes to the corresponding edges of the static dependency graph according to the mapping relationship, generating a dynamic-static fusion strategy graph. In this embodiment, a mapping relationship between the dynamic graph and the static graph is established through a node alignment mechanism, and runtime dynamic attributes are mapped to the structure of the static dependency graph, thereby generating a fusion strategy graph that simultaneously possesses static logical structure and dynamic behavioral information.

[0044] Specifically, in some embodiments, the distributed network device configuration system records the triggering events of configuration rules at runtime, forming a dynamic call graph. The dynamic call graph contains rule nodes, such as parameter validation rule nodes and version consistency check rule nodes, each with dynamic attributes such as the number of triggers and execution time. Simultaneously, the distributed network device configuration system performs static parsing of the device configuration script, constructing a static dependency graph. This static graph contains variable nodes, such as configuration parameters, state variables, and intermediate computational quantities. Dependency edges represent computational or referential relationships between variables. To achieve dynamic-static fusion, the distributed network device configuration system identifies the variables used by rule nodes through a node alignment mechanism. For example, if a validation rule uses parameter A, the rule node is aligned to variable node A. Subsequently, the system maps the number of triggers and execution time of this rule to the dependency edges representing A's participation, making the edges reflect the actual runtime situation. The final generated dynamic-static fusion graph simultaneously displays the static code logic and runtime execution performance.

[0045] In other embodiments, the dynamic call graph is generated by the risk control engine. Rule nodes include identity verification rules, credit limit verification rules, scoring rules, etc., and their node attributes include trigger count, judgment result, and execution time. The static dependency graph is obtained based on the parsing of the risk control strategy code and includes variable nodes, such as credit limit fields, time fields, and credit score fields, with dependency edges representing the transitive relationships between variables. The risk control system aligns the dynamic rule nodes with the static variable nodes based on the variable information referenced by the rules in the strategy configuration. For example, if a credit limit verification rule references a credit limit variable, the risk control system establishes a mapping relationship between the rule node and the credit limit variable node. Subsequently, the risk control system maps the trigger count in the dynamic attributes to the static edge representing the dependency relationship of the credit limit variable, so that this edge in the fused graph can reflect the triggering situation during the actual server-side service operation. The final generated dynamic and static fused strategy graph can be used to display the trigger popularity of risk control rules, the frequency of variable usage, and the execution path, providing risk control personnel with a visual basis for decision-making.

[0046] In S310, a mapping relationship is established based on a preset matching strategy by parsing the rule node identifiers in the dynamic call graph and the variable node identifiers in the static dependency graph. The node alignment mechanism includes identifying the variable information used by the rule node; determining the correspondence between the rule node and the variable node based on the variable name, field identifier, strategy configuration binding relationship, or variable reference relationship contained in the rule definition file; the correspondence can be achieved by directly merging nodes or establishing mapping connections pointing to variable nodes, and if a rule uses multiple variables, multiple mapping relationships can be established.

[0047] Specifically, in some embodiments, the specific implementation of step S310 can be found below. This embodiment is based on... Figure 2The detailed description of step S310 in the decision logic analysis method shown in the corresponding embodiment includes the following steps: parsing the unique identifiers of variable nodes in the static dependency graph; parsing the identifiers of dynamic rule nodes in the dynamic call graph; and merging or establishing associations between matching dynamic rule node identifiers and unique identifiers of variable nodes. In this embodiment, by parsing unique identifiers and rule node identifiers in the static dependency graph and the dynamic call graph respectively, and establishing a merging or association mechanism based on identifier matching, the heterogeneous graph structure can achieve node-level consistency, thereby constructing the basic association framework of the dynamic-static fusion graph.

[0048] Specifically, a static analysis tool or syntax parsing module is first used to uniquely identify all variable nodes in the static dependency graph. The unique identifier can be generated based on the variable name, its policy number, scope, file path, code location, or other semantically relevant information. Specifically, the name field of the variable node can be extracted first to identify the scope or policy to which the variable belongs. If a variable has multiple definitions, disambiguation is performed using location or scope identifiers, ultimately generating a unique identifier string or structured identifier object that can be used for matching. Then, the rule nodes in the dynamic call graph are identified. Specifically, this resolution includes the rule ID, the policy to which the rule belongs, the rule triggering context, the rule type or category identifier, and the rule-variable reference relationship recorded in the system. The aforementioned rule triggering context includes, for example, the input variables or intermediate variables used by the rule. This resolution process enables the rule nodes in the dynamic call graph to provide sufficient information to participate in the subsequent matching process. Finally, node matching and alignment are performed based on two sets of identifiers: dynamic rule node identifiers and variable node unique identifiers. Specifically, the unique identifier of a static variable node can be matched with the variable name or variable reference information used by the rule node. If they match, an association is established, or the two are merged in the fusion graph. If a rule node references multiple variables, a many-to-one mapping is established. If a variable is used by multiple rules, a one-to-many mapping can be formed, creating a structured and integrated relationship between rule nodes and variable nodes, which serves as the basis for the fusion graph.

[0049] Specifically, in some embodiments, the static dependency graph is generated by a configuration script parser, where the unique identifier of variable nodes is in the form of ConfigFile / Section / VariableName. The rule node identifiers of the dynamic call graph are generated by runtime logs, and the rule node identifier is RuleID:VariableName. The network configuration management system first parses the VariableName and scope identifier of all variable nodes in the static graph, and then parses the input parameters used by the rule nodes in the dynamic graph, establishing a mapping relationship by matching parameter names with variable names. If rule R1 uses the variable IP_Address, and the unique identifier of the static variable node contains this variable name, then the network configuration management system establishes an association connection between rule node R1 and variable node IP_Address. After matching is completed, the network configuration management system generates node alignment relationships that can support subsequent fusion calculations.

[0050] In other embodiments, the static dependency graph is generated by the risk control strategy code parser, with variable nodes uniquely identified as `policyId.variableName`. The dynamic call graph is generated by the risk control engine at runtime, with rule nodes identified as `ruleId:referencedVariableName`. The risk control system parses the static graph to obtain the unique identifiers of all variable nodes, such as `IncomeCheck.incomeValue`, and then parses the dynamic graph to obtain the variable names used by the rule nodes, such as `incomeValue`. Based on name matching and strategy number matching, the system determines the variable nodes referenced by the rule nodes. Upon successful matching, the risk control system establishes associations between rule nodes and variable nodes in the graph, enabling runtime behavior to be projected onto the static dependency structure. This mapping relationship is used to subsequently construct a dynamic-static integrated strategy graph, allowing rule nodes to be associated with static variable relationships and dynamic trigger attributes, achieving visualized analysis of risk control logic.

[0051] In the embodiment corresponding to S310, the unique identifier of static variable node and the identifier of dynamic rule node are parsed and merged or associated, which ensures that nodes between heterogeneous data sources can achieve reliable line-by-line mapping and disambiguation. This mechanism avoids node matching errors and semantic confusion, thereby ensuring the semantic consistency of the fused graph and the accuracy of subsequent dynamic attribute injection.

[0052] In S320, based on the node alignment relationship established in S310, dynamic attributes in the dynamic call graph are mapped to corresponding edges in the static dependency graph. It should be noted that the aforementioned dynamic attributes include trigger count, execution time, and trigger result. The mapping method includes: finding the variable node corresponding to the rule node; appending information such as the trigger count and execution time during rule execution to the edges representing variable dependencies; recording dynamic attributes in the graph structure so that variable dependencies simultaneously include runtime triggering conditions; and combining node alignment and attribute mapping to form a fusion strategy graph containing static logic and dynamic data. It should be noted that in some implementations, the fused graph can serve as the input structure for a graph neural network. The graph neural network performs message passing and aggregation operations on nodes and edges to generate node representation vectors, which are used for subsequent feature contribution calculations, improving the accuracy of rule contribution evaluation.

[0053] In the embodiment corresponding to S300, the dynamic call graph and the static dependency graph are merged into a dynamic-static fusion strategy graph through node alignment mechanism and dynamic attribute mapping. This can simultaneously reflect logical dependencies and runtime behavior within a single graph, eliminating the analysis blind spots caused by their separation, and enabling runtime attributes to be used intuitively on the static structure, significantly improving the accuracy of rule impact analysis and path coverage evaluation.

[0054] In S400, each node is assigned a color gradient based on its node attributes (including trigger count, weight influence, etc.), so that the color intensity corresponds to the influence or trigger frequency. The rendering process transforms the fused graph into a visually interactive graphical interface.

[0055] Specifically, in some embodiments, the specific implementation of step S400 can be found in [reference needed]. Figure 4 . Figure 4 It is based on Figure 2 The detailed description of step S400 in the decision logic analysis method shown in the corresponding embodiment includes the following steps: S410, calculating the rule influence index based on the historical decision data and the trigger frequency in the dynamic attributes; S420, performing color gradient rendering on each node of the dynamic-static fusion strategy graph based on the rule influence index and the trigger frequency to obtain a heatmap for display on a visualization interface. In this embodiment, by combining historical decision data with the dynamic attributes in the dynamic graph, especially the trigger frequency, a rule influence index is constructed, and gradient rendering of the fusion graph is performed based on this index and the trigger frequency, so that the heatmap can reflect the comprehensive strength of the decision logic.

[0056] Specifically, in some embodiments, historical decision data refers to the impact of each configuration rule on the successful configuration rate during past batch device access processes. The distributed network device configuration system calculates the marginal contribution of each rule to the final configuration success rate based on historical logs and constructs a rule influence index by combining this with the number of triggers recorded during runtime. For example, if a certain verification rule has historically frequently caused configuration failures, and this rule is triggered a high number of times in the current run, the influence index increases accordingly. Subsequently, the distributed network device configuration system performs color gradient rendering on each node in the fused strategy graph based on the influence index and trigger frequency of each rule node. Nodes with high influence are highlighted, while nodes with lower influence are highlighted. The final heatmap is displayed on the interface, enabling system administrators to quickly identify key stages and potential risk paths in the configuration process.

[0057] In other embodiments, historical decision data includes the impact of each risk control rule in historical loan approvals, such as the rule's contribution to approval rates, default rates, or risk scores. The risk control system combines this historical impact data with the number of times the risk control engine is triggered during runtime to calculate an impact index for each risk control rule. Subsequently, the risk control system performs gradient rendering of the dynamic and static integrated strategy map based on this impact index and trigger frequency. For example, a credit limit stability verification rule with high historical impact and frequent triggering is rendered as a red area, while rules with lower impact or very few triggers are presented in blue or gray. The rendered heatmap is used to present hotspots in the risk control logic, enabling strategy personnel to identify risk sensitivities, review bottlenecks, and inefficient rules.

[0058] In S410, a rule influence index is constructed by combining historical decision data with the trigger counts recorded in the dynamic call graph. Specifically, the influence of each rule node on the decision outcome under different samples is extracted from the historical decision data; the rule influence values ​​obtained from each sample are aggregated to obtain the overall influence performance of the rule node in the historical data; combined with the trigger counts in the runtime dynamic attributes, the influence value can reflect the frequency of the rule in the actual server-side service execution; and a rule influence index is constructed based on the above two dimensions to measure the importance of the rule. The aforementioned influence level can be, for example, weighted influence, marginal contribution value, or decision offset.

[0059] Specifically, in some embodiments, the specific implementation of step S410 can be found in [reference needed]. Figure 5 . Figure 5 It is based on Figure 4The detailed description of step S410 in the decision logic analysis method shown in the corresponding embodiment includes the following steps: S412, calculating the weight influence of each rule node based on historical decision data; S414, calculating the rule influence index based on the weight influence combined with the trigger count in the dynamic attribute. In this embodiment, the rule influence index is constructed by fusing historical weight influence and trigger count as two factors, so that the importance of the rule reflects both its influence on historical results and its activity level in the current network operation.

[0060] Specifically, in some embodiments, historical decision data includes configuration results from different batches of devices. The distributed network device configuration system calculates the marginal contribution of a certain verification rule to the configuration success rate based on historical data; for example, the rule's influence on successful configuration in historical data is weighted by a certain value. Simultaneously, the distributed network device configuration system obtains the number of times the rule has been triggered in recent batches from the dynamic call graph. For example, a certain parameter verification rule may have a high number of triggers in the latest deployment cycle. The distributed network device configuration system combines the weighted influence with the number of triggers to calculate the rule's influence index, reflecting both its historical impact on the configuration process and the current server service pressure. This index is used to render the color intensity of rule nodes in the heatmap, enabling administrators to identify configuration rules with high server service pressure and significant impact.

[0061] In other embodiments, historical decision data includes loan application approval results and the marginal contribution of each rule to the risk score or approval result. For example, the credit limit stability check rule has a high contribution to the decision result in historical data, and the risk control system calculates its weighted impact accordingly. The dynamic call graph provides the number of times the rule is triggered during the real-time review process. If the rule is triggered frequently during the current server service period, it indicates that it has high activity under the current server service load. The risk control system combines the historical weighted impact with the trigger frequency to calculate the final rule influence index. High-influence rules are highlighted in the heatmap, enabling risk control personnel to identify important rules and high-frequency risk points, thereby optimizing strategies or investigating risks.

[0062] In S412, the weighted influence of each rule node is calculated by analyzing the contribution of rule nodes to the decision outcome in historical decision data. Specifically, the weighted influence can be calculated by first determining the triggering status of each rule in each sample of historical data and its impact on the final decision output. Based on changes in model output, decision path, risk score, or rule hierarchy logic, the marginal contribution value or influence weight of the rule is obtained. The marginal contributions of all samples are aggregated, for example, by calculating the mean, weighted average, or normalizing based on sample influence, to obtain the historical weighted influence of that rule node. The weighted influence, as a static indicator, is used to reflect the importance of the rule in the historical data. It should be noted that in some implementations, an adjustable weight coefficient interface can be provided, allowing users to adjust the proportion of quality and quantity items to support different strategic objectives or phased server-side service requirements, ensuring the adaptability of the influence indicator in different scenarios.

[0063] Specifically, in some embodiments, the specific implementation of step S412 can be found in the following embodiments. This embodiment is based on... Figure 5 The detailed description of step S412 in the decision logic analysis method shown in the corresponding embodiment includes the following steps: calculating the marginal contribution of each feature subset to the model prediction based on historical decision data; performing a weighted average of the marginal contributions to obtain the weighted influence of each sample; and determining the weighted influence of the rule node based on the weighted influence of each sample. In this embodiment, a hierarchical contribution analysis method is adopted, using the marginal contribution of feature subsets as a basis, obtaining the sample-level influence through weighted aggregation, and then deriving the weighted influence of the rule node level from the sample-level influence, realizing a quantifiable calculation process for the importance of the rule. The weighted influence can be measured using the SHAP value. In other embodiments, it can also be measured using LIME contribution, feature importance, mutual information, decision path sensitivity, etc.

[0064] Specifically, a marginal contribution analysis is first performed on feature subsets from historical decision data to measure their influence on the model's prediction results. Specifically, input features and corresponding model prediction results are extracted from historical samples. Based on feature grouping rules or model structure, feature subsets are determined, and marginal contribution calculations are performed on each feature subset. For example, through feature perturbation, feature removal, replacement value simulation, or contribution decomposition methods, the gain or change in the prediction results of that feature subset is obtained, ultimately yielding the marginal contribution value of each feature subset in each sample for subsequent aggregation. This marginal contribution value expresses the direct impact of the feature subset on model prediction in historical data. The aforementioned feature subsets include univariate subsets, variable combination subsets, or rule-referenced feature subsets. When the rule structure is complex, rule triggering conditions can be used as model features in the interpreter calculation. The interpreter model can use the SHAP mechanism to interpret the contribution of each sample and rule, obtaining the average contribution of the rule, providing a quality term for the influence index. Then, the marginal contributions of multiple feature subsets corresponding to each sample are weighted to obtain the sample-level weighted influence. Specifically, weight coefficients for each feature subset can be set based on its importance, model structure, or contribution stability. The marginal contributions of all feature subsets in a sample are then weighted and summed to obtain the weighted influence value for that sample. If some feature subsets belong to the same rule, their marginal contributions can be combined during the weighting process to form the overall weighted influence for each sample, reflecting the model's overall sensitivity to that sample. Finally, the sample-level weighted influence is mapped to the rule node-level weighted influence. Specifically, the target features or feature subsets referenced by the rule node can be determined first. The weighted influence values ​​related to this rule in all samples can be statistically analyzed, such as by calculating the average, weighted average, or aggregation according to probability distribution. If the rule involves multiple feature subsets, contributions are fused according to the rule definition, and the aggregation result is used as the weighted influence of the rule node in historical data.

[0065] In some embodiments of this specification, the weighting effect is measured using the SHAP value, the formula of which is:

[0066]

[0067] in, is the SHAP value of feature i, used to measure the average contribution of feature i to the final prediction result; i is the feature or rule number whose contribution is calculated; v is the value function of the model, which is the prediction result returned after inputting the feature set; S is the feature subset that does not contain feature i; N is the set of all features in the model; M is the total number of features, i.e. the number of elements in set N; Let i be the marginal contribution of feature i to subset S; The predicted value of the model after adding feature i to the feature set S; This represents the model's predictions when using only the feature set S. The reciprocal of the weight term is the mathematical definition of Shapley weight.

[0068] Specifically, in some embodiments, historical decision data includes configuration characteristics of multiple devices and predictions of configuration success. These configuration characteristics may include device model, protocol preferences, configuration parameters, etc. The distributed network device configuration system first calculates the marginal contribution of each feature subset to the prediction of configuration success; for example, IP configuration-related features have a high influence on some devices. It should be noted that in this embodiment, feature subsets may include IP-related features, protocol feature groups, version feature groups, etc. Subsequently, the distributed network device configuration system performs weighted aggregation of the feature subset contributions for each device sample to obtain the weighted influence of that sample. For example, feature subsets with higher feature contributions in a device sample have higher weights. Finally, the distributed network device configuration system collects the weighted influence values ​​of all relevant samples based on the feature subsets referenced by each configuration rule, and aggregates them to obtain the historical weighted influence of the corresponding rule node.

[0069] Specifically, in some embodiments, historical decision data includes customer characteristics and model-predicted risk outcomes, with customer characteristics including credit limit, time, credit score, etc. First, the risk control system calculates the marginal contribution of each feature subset to risk prediction. For example, credit score-related features have a high contribution in most samples. It should be noted that in this embodiment, feature subsets include credit limit-related feature groups, credit score-related feature groups, etc. Subsequently, the risk control system weights the marginal contributions of each application sample's feature subsets according to preset weights to synthesize the sample weight influence. Finally, based on the feature subset used by each rule, the weight influence of all samples is summarized to form the historical weight influence of that rule node, used for subsequent influence index calculation. It should be noted that in this embodiment, the aforementioned rules include credit limit check rules, credit score rules, etc.

[0070] In the embodiment corresponding to S412, the process of calculating the marginal contribution from the feature subset level, obtaining the sample-level weight influence through weighted averaging, and then summarizing it to the rule level establishes a traceable derivation link from feature contribution to rule importance. This link ensures the interpretability and statistical robustness of rule weights, making rule evaluation have strict data support and verifiability.

[0071] In S414, dynamic attributes in the dynamic call graph are further utilized to incorporate dynamic behavior into the calculation process of the influence index. These dynamic attributes include, for example, the number of triggers and recent periodic activity.

[0072] Specifically, the number of times a rule is triggered during runtime or the frequency of triggering within a given time window can be obtained first. The number of triggers can be normalized, smoothed, or standardized to avoid deviations caused by scale differences. The normalized number of triggers and the historical weight influence can be combined according to a preset calculation method, such as weighted summation, product form, or other weight fusion methods, to obtain a rule influence index that includes static contribution and dynamic activity.

[0073] In some specific embodiments, the aforementioned rule influence index is obtained using the following formula:

[0074]

[0075] in, For rules The influence index, known as the SHAP value, is used to measure the combined effect of rule quality and activity. The rule number whose influence is being calculated; n is the total number of historical samples; In the sample The following rules The SHAP value represents its contribution to the sample; This is the j-th historical sample data; For rules The number of times a rule is triggered in historical data is used to measure its activity level. The logarithmic transformation of the trigger count is used to compress the order-of-magnitude differences, preventing high-frequency rules from excessively amplifying their contributions. The formula above provides an operable normalization calculation framework. The average feature contribution value measures the quality and directionality of the rule, while the logarithmic transformation compresses the order-of-magnitude differences in the trigger count. The combination of these two aspects allows the indicator to distinguish between high-impact low-frequency rules and low-impact high-frequency rules, thereby ensuring the numerical stability of the indicator and the adaptability of the server-side service.

[0076] In the embodiment corresponding to S410, the influence of historical rule weights is first calculated and then combined with the number of triggers to construct an influence index. By simultaneously incorporating historical contribution and operational activity, the bias problem of a single indicator is overcome, forming a comprehensive evaluation index that takes into account both rule quality and actual server-side service load, thereby providing a quantitative basis for rule ranking and resource allocation.

[0077] In S420, heatmap rendering first normalizes the influence index and trigger frequency of each rule node and variable node to determine color ranges. High-influence or high-trigger nodes are assigned bright colors, while low-influence or low-frequency nodes are assigned lower-brightness or cool-toned colors. Color gradient rendering is then performed on all nodes of the fused graph, creating hot, cold, and transitional zones. The rendering results are displayed in a visualization interface, allowing users to intuitively identify important nodes and hotspot areas through color differences. It should be noted that in some embodiments, key attributes of nodes and edges in the fused graph can be persistently saved before rendering, including node type, statistical values, trigger frequency time series, and SHAP value mean, to ensure the stability and consistency of the graph rendering and retrieval process.

[0078] In the embodiment corresponding to S400, the step of calculating the rule influence index based on the fusion graph and rendering the nodes with color gradients realizes the direct mapping from numerical values ​​to visual representation, enabling the hot spots, sparse areas and critical paths of the decision-making system to be intuitively identified on the visualization interface, which significantly improves the efficiency of strategy auditing, anomaly detection and optimization decision-making.

[0079] In some embodiments of this specification, after S400, the decision logic analysis method further includes: adjusting the decision logic in response to a user's adjustment instruction on the visualized interface; performing random sampling prediction on the adjusted decision logic using a Monte Carlo simulation method to obtain performance indicators and generate a comparison view.

[0080] In this embodiment, an interactive strategy adjustment and Monte Carlo quantization simulation mechanism are introduced on the basis of heat map display, enabling users to directly adjust the decision logic in the visual interface and obtain quantitative feedback on the performance changes after adjustment in real time.

[0081] Specifically, a visual interface is first provided to allow users to modify rules, adjust thresholds, and adjust logical paths. Upon detecting a user-inputted adjustment command, the system identifies the user's adjustment target, including rule parameters, variable thresholds, rule activation status, path priority, or combined conditions. Based on the adjustment, the internal structure of the decision logic is updated, including rule node attributes, variable dependencies, and the decision path structure. Without altering the historical data structure, an adjusted version of the decision logic is generated, and an internal validation mechanism ensures that the adjusted logic satisfies the integrity of the syntax structure and dependencies.

[0082] Random sampling prediction is performed on the adjusted decision logic. Specifically, a number of samples can be randomly selected from historical or simulated data. The sample size can be greater than, equal to, or less than the original data volume. The input variables are randomly perturbed for each sample to form multiple sets of simulated inputs. Simulated samples can be generated by sampling the historical input distribution and combining it with the perturbation strategy. Statistical indicators include success rate, failure rate, critical path trigger changes, etc. In risk control scenarios, indicators such as pass rate, bad debt rate, and expected loss are also included. Prediction is performed under the adjusted decision logic, simulation results are recorded, and the performance indicators of each simulation result are statistically analyzed. The performance indicators before and after adjustment are compared in a structured manner, and a comparison view is finally generated. The comparison view includes visualization content such as difference matrix, trend chart, and indicator comparison table. In some embodiments, warning thresholds can be configured, such as triggering a warning when the pass rate drops by more than two percentage points or the bad debt rate rises by more than three percentage points, and the warning is displayed on the interface.

[0083] Specifically, in some embodiments, administrators observe hotspot rules in the configuration process using heatmaps and submit adjustment commands in the interface, such as adjusting the trigger threshold of a validation rule or changing the rule execution order. The distributed network device configuration system parses these adjustment commands in real time, updates the decision logic structure, and forms a new configuration strategy. Subsequently, the distributed network device configuration system uses Monte Carlo simulation to randomly sample from historical device configuration inputs and randomly perturb device parameters to simulate a large number of configuration scenarios. Configuration prediction is then performed on the adjusted strategy to obtain changes in success rate, failure reason distribution, and rule trigger frequency. It should be noted that the perturbed device parameters may include version number, IP range, configuration template parameters, etc. The distributed network device configuration system displays the indicators before and after the adjustment in a comparative view, including success rate change curves and rule hit change tables, enabling administrators to clearly determine whether the adjustment has optimized the process.

[0084] In other embodiments, risk control personnel identify high-impact rules using heatmaps and attempt to adjust the threshold of a rule from 20% to 25% or temporarily disable a sub-rule within the interface. The risk control system parses the adjustment request and generates a new version of the risk control logic. Subsequently, the system uses the Monte Carlo method to simulate the adjusted strategy, generating a large number of simulated application samples by randomly sampling from historical loan application data and perturbing variables such as loan amount, time, and credit score. The system performs risk control prediction, obtaining performance indicators such as risk score distribution, changes in approval rate, and changes in bad debt rate. Finally, a comparison view before and after the adjustment is generated, including an approval rate comparison table, a risk score distribution comparison chart, and a rule trigger change matrix, supporting risk control personnel in determining whether the adjustment is reasonable.

[0085] In the above embodiments, by responding to user adjustments to the decision logic through a visual interface and using Monte Carlo simulation to perform random sampling prediction on the adjusted logic, a closed loop of interactive modification and quantitative verification is established. This enables the strategy adjustment to obtain performance evaluation and risk prediction at the probability distribution level in a non-production environment, thereby significantly reducing the trial and error cost of strategy deployment and improving the security of decision-making.

[0086] In some embodiments of this specification, such as Figure 6 As shown, after S400, the decision logic analysis method further includes: S500, detecting the dynamic-static fusion strategy graph and identifying low-frequency execution paths. In this embodiment, low-frequency execution paths are identified by performing a full path scan and frequency analysis on the graph, which is used for strategy optimization, logic compression, anomaly detection, and other purposes. Specifically, this detection process is based on the dynamic-static fusion strategy graph generated by the system in the aforementioned steps. This graph contains both static dependency edges and variable structures and dynamic calling nodes and their dynamic attributes. Specifically, the overall structure of the fusion graph, including all nodes, dependency edges, rule reference relationships, and reachable paths, can be obtained first. All valid paths in the graph are traversed. These paths may include rule links, variable dependency links, and rule-variable combination paths. Dynamic attributes such as minimum trigger count, path coverage count, and path execution probability are read for each path. Then, the path activity is judged according to a preset threshold or statistical interval. If the path trigger count is zero or lower than the system-set threshold, it is identified as a low-frequency execution path. The detection results are marked in the internal structure and can be recorded as low-frequency path labels, weakly active path labels, or potential abnormal path labels. Low-frequency paths can be marked in the visualization interface, for example, by using dashed boxes, light-colored rendering, or information prompts.

[0087] Specifically, in some embodiments, after the distributed network device configuration system initially constructs a dynamic and static integrated policy graph and renders a heatmap, it further performs low-frequency path detection on the graph. The distributed network device configuration system traverses all configuration task paths in the graph, including IP allocation paths, protocol check paths, version verification paths, etc. During the detection process, the system reads the trigger count corresponding to each path. For example, if the protocol compatibility check rules corresponding to certain paths have never been triggered in the past hundreds of thousands of device configurations, the distributed network device configuration system marks the path as a low-frequency execution path. The detection results are presented in a faded color in the visualization interface, allowing administrators to see the unused logical links in the actual execution process, thereby enabling rule cleanup or policy compression and avoiding redundant logic from affecting system maintenance costs.

[0088] In other embodiments, after the risk control engine generates a fusion strategy graph and displays a heatmap, the risk control system further analyzes all risk control paths, including risk node paths, credit scoring paths, and approval rejection decision paths. The risk control system traverses all paths and checks the trigger count on each path. For example, if a rule for checking large loans during a specific time period is triggered zero times within a year, but this path actually exists in the graph, it indicates that this rule has no use case in the current server-side service. The risk control system marks this path as a low-frequency execution path and prompts risk control personnel in the interface that this logic may need to be adjusted or taken offline. This function helps to discover redundant strategies, reduce the complexity of risk control rules, and improve review performance.

[0089] Specifically, in some embodiments, the specific implementation of step S500 can be found in the following embodiments. This embodiment is based on... Figure 6 The detailed description of step S500 in the decision logic analysis method shown in the corresponding embodiment includes the following steps: setting a time window threshold; traversing the branch paths in the dynamic-static fusion strategy graph; if a branch path has zero trigger counts within the time window, then the branch path is marked as a low-frequency execution path and a warning is issued in the visualization interface. In this embodiment, by introducing a time window mechanism, path triggering is bound to the time dimension, making low-frequency path identification more accurate and timely, and prompting users to pay attention to potential path problems through a visual warning method.

[0090] Specifically, a time window parameter is set according to the server-side service requirements. This time window parameter can be any of a fixed window, a sliding window, or a custom window. A fixed window can be, for example, the most recent 1 day, 7 days, or 30 days; a sliding window can move dynamically with the current time; and a custom window can be set by the user based on the server-side service cycle. The time window is used to limit the statistical range, giving the calculation of trigger counts a clear time interval. Then, all reachable paths in the fusion graph are systematically traversed, mainly decision paths, rule link paths, variable dependency paths, and different path combinations at branch nodes, as well as path sets composed of static structures and dynamic attributes, to read the execution record of each path within the time window and extract the trigger count or coverage count. Paths are judged for low frequency and visually marked. If the trigger count of a path is 0, it is identified as a low-frequency execution path, and a special mark, such as a low-frequency label, is added to the path, triggering a visual warning prompt, including a path highlight box, light-colored annotation, warning icon, or prompt floating window. The low-frequency path detection results are recorded and can be used for rule adjustment, strategy compression, or anomaly detection.

[0091] Specifically, in some embodiments, the administrator sets the time window to the most recent 14 days. The distributed network device configuration system traverses various branch paths in the converged graph, such as IP verification paths, version verification paths, and protocol negotiation paths, and counts the number of times each path is triggered within 14 days. If the system detects that an old version compatibility check path has been triggered zero times in the entire time window, it marks it as a low-frequency execution path and displays it as a gray dashed line in the visualization interface. A pop-up message also appears indicating that this path has not been triggered in the recent period and should be considered for decommissioning or merging. This mechanism helps administrators identify expired paths and reduce redundant rules.

[0092] In other embodiments, risk control personnel set the time window to the most recent 30 days. The risk control system traverses all risk control paths, including credit limit approval paths, credit inquiry paths, and multiple borrowing detection paths. If the system detects that a specific industry practitioner's special review path has been triggered zero times in the past 30 days, it marks this path as a low-frequency path and displays a warning icon in the risk control strategy visualization interface, indicating to risk control personnel that the path may no longer be suitable for the current server-side service scenario. This mechanism helps the risk control team to maintain and optimize strategies in a timely manner.

[0093] In the S500 implementation, a systematic scan of path-level trigger statistics in the fusion graph automatically reveals logical branches that have been unused or rarely triggered, providing direct evidence for rule cleanup, logic compression, and anomaly analysis, thus improving policy maintenance efficiency and reducing redundancy and complexity. Specifically, based on a mechanism that traverses paths within a set time window and marks paths with zero triggers within the window as alerts, a time dimension is introduced to make low-frequency identification timely and configurable. Through clear time window definitions, path traversal, and zero-trigger judgment, recent invalid paths and occasional events can be accurately distinguished, and alerts are provided in the visualization interface, supporting targeted adjustments and governance by the operations and policy teams.

[0094] In a specific implementation scenario, the following example illustrates how a Web Application Firewall (WAF) can handle a large-scale HTTP attack. An online game company's login interface experiences a sudden CC attack with 100,000 requests per second, causing the WAF's CPU load to spike to 95%, preventing legitimate players from logging in. Operations personnel urgently need to pinpoint the protection rules consuming excessive computing resources. At this point, the service processing logic representation data of the network security platform can be collected in parallel during the runtime of the network security platform service's server-side decision engine. This can involve collecting real-time access logs and protection policy packages from the Web Application Firewall in parallel. The log stream shows that a large number of requests are marked as suspected bot attacks, and the processing time for a single request exceeds the processing threshold. It should be noted that in this embodiment, the real-time access logs are equivalent to the aforementioned dynamic data, and the protection policy packages are equivalent to the aforementioned static data. Based on the server-side processing logic representation data, a dynamic call graph representing runtime trigger relationships and a static dependency graph representing code-level logical relationships are constructed. The dynamic call graph shows that when traffic passes through a certain regular expression matching node, the processing latency increases significantly, causing congestion. The static dependency graph shows a custom regular expression rule in the policy file. This rule contains a complex regular expression and depends on preceding protocol decoding rules. The node mapping relationship between the dynamic call graph and the static dependency graph is parsed to generate a dynamic-static fusion policy graph. For example, the system uses rule ID matching to precisely map runtime attributes such as average latency and 99% hit rate recorded in the dynamic graph to a specific node in the static graph, thus fusion to generate the dynamic-static fusion policy graph. A heatmap is rendered based on this dynamic-static fusion policy graph for display on a visualization interface. The operations and maintenance personnel can then view the generated dynamic-static fusion policy heatmap on interfaces such as the console. For example, if a node in the dynamic-static fusion policy graph is dark red and flashing continuously, and its size is significantly larger than other rule nodes, it indicates that the node consumes a lot of resources. The graph also shows the dependency relationship between this rule and other scoring rules through connections. Using this method, operations and maintenance personnel can directly determine that the regular expression rule is a performance bottleneck without logging into the device and checking logs line by line. The operations and maintenance personnel then downgraded or paused the rule on the interface. After execution, the load on the Web Application Firewall decreased, and the server service returned to normal, realizing visualization and rapid response of network security risk control based on dynamic and static fusion policy heatmaps. In the above embodiments of this specification, by collecting runtime behavioral data and static logical data in parallel and expressing them in the form of graphs, the unobservability of decision-making logic can be eliminated at the overall level, and the traceability and quantification of the decision execution chain can be achieved, thereby providing a unified and reliable data foundation for subsequent rule analysis, coverage assessment, and policy optimization.

[0095] The following will combine Figure 7This manual provides a detailed description of the decision logic analysis device provided. It should be noted that... Figure 7 The decision logic analysis device shown is used to execute the instructions in this manual. Figures 1-6 The methods of the embodiments shown are illustrated only in connection with this specification for ease of explanation. For specific technical details not disclosed, please refer to this specification. Figures 1-6 The example shown.

[0096] Please see Figure 7 This diagram illustrates the structure of the decision logic analysis device described in this specification. The decision logic analysis device 700 can be implemented as all or part of a user terminal through software, hardware, or a combination of both. According to some embodiments, the decision logic analysis device 700 includes a characterization data acquisition module 710, a dynamic call construction module 721, a static dependency construction module 722, a dynamic-static fusion strategy module 730, and a heatmap visualization module 740. The system includes the following components: a data acquisition module 710, which collects real-time rule-triggered event streams and decision logic source code from the server in parallel during the execution of the server-side decision engine; a dynamic call construction module 721, which constructs a dynamic call graph based on the real-time rule-triggered event stream, the dynamic call graph containing rule nodes and dynamic attributes of rule triggers; a static dependency construction module 722, which constructs a static dependency graph based on the decision logic source code, the static dependency graph containing variable nodes and code-level dependencies; a dynamic-static fusion strategy module 730, which parses the relationship between the dynamic call graph and the static dependency graph to generate a dynamic-static fusion strategy graph; and a heatmap visualization module 740, which renders a heatmap based on the dynamic-static fusion strategy graph for display on a visualization interface.

[0097] Optionally, the dynamic-static fusion strategy module 730 specifically includes: a mapping relationship establishment submodule, used to establish a mapping relationship between the rule nodes in the dynamic call graph and the variable nodes in the static dependency graph through a node alignment mechanism; and a fusion graph generation submodule, used to map the dynamic attributes to the corresponding edges of the static dependency graph according to the mapping relationship, thereby generating a dynamic-static fusion strategy graph.

[0098] Optionally, the mapping relationship establishment submodule specifically includes: a variable node parsing unit, used to parse the unique identifier of the variable node in the static dependency graph; a dynamic rule parsing unit, used to parse the dynamic rule node identifier in the dynamic call graph; and a node identifier merging unit, used to merge or establish an association connection between the matching dynamic rule node identifier and the unique identifier of the variable node.

[0099] Optionally, the heatmap visualization module 740 specifically includes: a rule index calculation submodule, used to calculate the rule influence index based on the historical decision data and the number of triggers in the dynamic attributes; and a color gradient rendering submodule, used to perform color gradient rendering on each node of the dynamic-static fusion strategy map based on the rule influence index and the trigger frequency to obtain a heatmap for display on the visualization interface.

[0100] Optionally, the rule index calculation submodule specifically includes: a weight influence calculation unit, used to calculate the weight influence of each rule node based on historical decision data; and a rule index calculation unit, used to calculate the rule influence index based on the weight influence combined with the trigger count in the dynamic attribute.

[0101] Optionally, the weight influence calculation unit specifically includes: a marginal contribution determination subunit, used to calculate the marginal contribution of each feature subset to the model prediction based on historical decision data; a sample weight influence subunit, used to perform a weighted average of the marginal contributions to obtain the weight influence of each sample; and a weight influence calculation subunit, used to determine the weight influence of the rule node based on the weight influence of each sample.

[0102] Optionally, the rule index calculation unit is specifically used to perform the following calculations:

[0103]

[0104] in, For rules The influence index, known as the SHAP value, is used to measure the combined effect of rule quality and activity. The rule number whose influence is being calculated; n is the total number of historical samples; In the sample The following rules The SHAP value represents its contribution to the sample; This is the j-th historical sample data; For rules The number of times a rule is triggered in historical data is used to measure its activity level. The logarithmic transformation of the trigger number is used to compress the order-of-magnitude difference, so that the high-frequency rules do not over-amplify the contribution.

[0105] Optionally, the decision logic analysis device 700 further includes: a decision logic adjustment module, used to adjust the decision logic in response to the user's adjustment instruction on the visualization interface; and a comparison view generation module, used to perform random sampling prediction on the adjusted decision logic using the Monte Carlo simulation method to obtain performance indicators and generate a comparison view.

[0106] Optionally, the decision logic analysis device 700 further includes a low-frequency path identification module, used to detect the dynamic-static fusion strategy graph and identify low-frequency execution paths.

[0107] Optionally, the low-frequency path identification module specifically includes: a time threshold setting submodule, used to set a time window threshold; a branch path traversal submodule, used to traverse the branch paths in the dynamic-static fusion strategy graph; and an early warning prompting submodule, used to mark a branch path as a low-frequency execution path and issue an early warning prompt in the visualization interface if there is a branch path whose trigger count is zero within the time window.

[0108] It should be noted that the decision logic analysis device provided in the above embodiments is only illustrated by the division of the above functional modules when executing the decision logic analysis method. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the decision logic analysis device and the decision logic analysis method embodiments provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be repeated here.

[0109] The serial numbers in this specification are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0110] In this specification, by collecting runtime behavioral data and static logical data in parallel and representing them in the form of a graph, the unobservability of decision-making logic can be eliminated at the overall level, and the traceability and quantifiability of the decision execution chain can be achieved, thereby providing a unified and reliable data foundation for subsequent rule analysis, coverage evaluation and strategy optimization.

[0111] This specification also provides a computer storage medium capable of storing multiple instructions adapted to be loaded and executed by a processor as described above. Figures 1-6 The decision logic analysis method described in the illustrated embodiment can be found in the following document for its specific execution process. Figures 1-6 The specific details of the illustrated embodiments will not be elaborated here.

[0112] This specification also provides a computer program product that stores at least one instruction, said at least one instruction being loaded and executed by the processor as described above. Figures 1-6 The decision logic analysis method described in the illustrated embodiment can be found in the following document for its specific execution process. Figures 1-6 The specific details of the illustrated embodiments will not be elaborated here.

[0113] Please refer to Figure 8This diagram illustrates a structural block diagram of an electronic device provided in an exemplary embodiment of this specification. The electronic device in this specification may include one or more components such as a processor 110, a memory 120, an input device 130, an output device 140, and a bus 150. The processor 110, memory 120, input device 130, and output device 140 may be connected via the bus 150.

[0114] Processor 110 may include one or more processing cores. Processor 110 connects to various parts of the electronic device via various interfaces and lines, and performs various functions and processes data of electronic device 100 by running or executing instructions, programs, code sets, or instruction sets stored in memory 120, and by calling data stored in memory 120. Optionally, processor 110 may be implemented using at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). Processor 110 may integrate one or more of the following: central processing unit (CPU), graphics processing unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into processor 110 and may be implemented separately through a communication chip.

[0115] The memory 120 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 120 may include a non-transitory computer-readable storage medium. The memory 120 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 120 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), instructions for implementing the various method embodiments described below, etc. The operating system may be the Android system, including systems deeply developed based on the Android system, the iOS system developed by Apple Inc., including systems deeply developed based on the iOS system, or other systems. The data storage area may also store data created by the electronic device during use, such as phonebook data, audio and video data, chat log data, etc.

[0116] See Figure 9 As shown, the memory 120 can be divided into operating system space and user space. The operating system runs in the operating system space, while native and third-party applications run in the user space. To ensure that different third-party applications can achieve good running performance, the operating system allocates corresponding system resources for each application. However, different application scenarios within the same third-party application have different requirements for system resources. For example, in local resource loading scenarios, third-party applications have high requirements for disk read speed; in animation rendering scenarios, third-party applications have high requirements for GPU performance. Since the operating system and third-party applications are independent of each other, the operating system often cannot promptly perceive the current application scenario of a third-party application, resulting in the operating system's inability to adapt system resources accordingly to the specific application scenario of the third-party application.

[0117] In order for the operating system to distinguish the specific application scenarios of third-party applications, it is necessary to establish data communication between the third-party applications and the operating system. This would allow the operating system to obtain the current scenario information of the third-party applications at any time, and then perform targeted system resource adaptation based on the current scenario.

[0118] Taking the Android operating system as an example, the programs and data stored in memory 120 are as follows: Figure 10As shown, the memory 120 can store the Linux kernel layer 320, the system runtime library layer 340, the application framework layer 360, and the application layer 380. The Linux kernel layer 320, system runtime library layer 340, and application framework layer 360 belong to the operating system space, while the application layer 380 belongs to the user space. The Linux kernel layer 320 provides low-level drivers for various hardware components of the electronic device, such as display drivers, audio drivers, camera drivers, Bluetooth drivers, Wi-Fi drivers, and power management. The system runtime library layer 340 provides support for key features of the Android system through several C / C++ libraries. For example, the SQLite library provides database support, the OpenGL / ES library provides 3D graphics support, and the Webkit library provides browser kernel support. The system runtime library layer 340 also provides the Android runtime library, which mainly provides core libraries that allow developers to write Android applications using the Java language. The Application Framework Layer 360 provides various APIs that may be used when building applications. Developers can also use these APIs to build their own applications, such as activity management, window management, view management, notification management, content provider, package management, call management, resource management, and location management. At least one application runs in the Application Layer 380. These applications can be native applications that come with the operating system, such as contacts, SMS, clock, and camera apps; or third-party applications developed by third-party developers, such as games, instant messaging, and photo editing apps.

[0119] Taking the operating system as an example (iOS), the programs and data stored in memory 120 are as follows: Figure 11As shown, the iOS system includes: Core OS layer 420, Core Services layer 440, Media layer 460, and Cocoa Touch layer 480. Core OS layer 420 includes the operating system kernel, drivers, and low-level program frameworks. These low-level program frameworks provide hardware-level functionality for use by the program frameworks located in Core Services layer 440. Core Services layer 440 provides system services and / or program frameworks required by applications, such as Foundation framework, account framework, advertising framework, data storage framework, network connectivity framework, geolocation framework, motion framework, etc. Media layer 460 provides applications with audiovisual interfaces, such as interfaces related to graphics and images, audio technology, video technology, and wireless playback (AirPlay) interfaces. Cocoa Touch layer 480 provides various commonly used interface-related frameworks for application development and is responsible for user touch interaction on electronic devices. Examples include local notification services, remote push services, advertising frameworks, game tool frameworks, message user interface (UI) frameworks, UIKit user interface frameworks, map frameworks, and so on.

[0120] exist Figure 11 The framework shown includes, but is not limited to, the base framework in the core service layer 440 and the UIKit framework in the touchable layer 480. The base framework provides many basic object classes and data types, offering the most basic system services to all applications, and is independent of the UI. The UIKit framework, on the other hand, provides a basic UI class library for creating touch-based user interfaces. iOS applications can use the UIKit framework to provide their UI, thus providing the application's infrastructure for building user interfaces, drawing, handling user interaction events, responding to gestures, and so on.

[0121] The methods and principles for implementing data communication between third-party applications and the operating system in the iOS system can be found in the Android system, and will not be repeated here.

[0122] The input device 130 is used to receive input instructions or data, and includes, but is not limited to, a keyboard, mouse, camera, microphone, or touch device. The output device 140 is used to output instructions or data, and includes, but is not limited to, a display device and a speaker. In one example, the input device 130 and the output device 140 can be combined into a touch screen, which is used to receive touch operations from the user using a finger, stylus, or any suitable object on or near it, and to display the user interface of various applications. The touch screen is usually located on the front panel of the electronic device. The touch screen can be designed as a full-screen, curved screen, or irregularly shaped screen. The touch screen can also be designed as a combination of a full-screen and a curved screen, or a combination of an irregularly shaped screen and a curved screen; this specification does not limit this.

[0123] In addition, those skilled in the art will understand that the structure of the electronic device shown in the above figures does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements. For example, the electronic device may also include radio frequency circuits, input units, sensors, audio circuits, wireless fidelity (WiFi) modules, power supplies, Bluetooth modules, etc., which will not be described in detail here.

[0124] In this specification, the entity executing each step can be the electronic device described above. Optionally, the entity executing each step can be the operating system of the electronic device. The operating system can be Android, iOS, or other operating systems; this specification does not limit this.

[0125] The electronic device described in this manual may also be equipped with a display device. This display device can be any device capable of displaying information, such as a cathode ray tube display (CR), a light-emitting diode display (LED), an e-ink screen, a liquid crystal display (LCD), or a plasma display panel (PDP). Users can use the display device on electronic device 101 to view displayed text, images, videos, and other information. The electronic device may be a smartphone, tablet, gaming device, AR (Augmented Reality) device, automobile, data storage device, audio playback device, video playback device, laptop, desktop computing device, or wearable device such as an electronic watch, electronic glasses, electronic helmet, electronic bracelet, electronic necklace, or electronic clothing.

[0126] exist Figure 8 In the illustrated electronic device, which can be a terminal, the processor 110 can be used to call the network optimization application stored in the memory 120 and specifically perform the following operations: During the runtime of the server-side decision engine, parallel collection of real-time rule-triggered event streams and decision logic source code from the server; construction of a dynamic call graph based on the real-time rule-triggered event stream, the dynamic call graph containing rule nodes and dynamic attributes of rule triggers; construction of a static dependency graph based on the decision logic source code, the static dependency graph containing variable nodes and code-level dependencies; parsing the association between the dynamic call graph and the static dependency graph to generate a dynamic-static fusion strategy graph; and rendering a heatmap based on the dynamic-static fusion strategy graph for display on a visualization interface.

[0127] In one embodiment, when the processor 110 performs the parsing of the association between the dynamic call graph and the static dependency graph to generate a dynamic-static fusion strategy graph, it specifically performs the following operations: establishing a mapping relationship between the rule nodes in the dynamic call graph and the variable nodes in the static dependency graph through a node alignment mechanism; and mapping the dynamic attributes to the corresponding edges of the static dependency graph according to the mapping relationship to generate a dynamic-static fusion strategy graph.

[0128] In one embodiment, when the processor 110 executes the process of establishing the mapping relationship between the rule nodes in the dynamic call graph and the variable nodes in the static dependency graph through the node alignment mechanism, it specifically performs the following operations: parsing the unique identifier of the variable node in the static dependency graph; parsing the identifier of the dynamic rule node in the dynamic call graph; and merging or establishing an association connection between the matching dynamic rule node identifier and the unique identifier of the variable node.

[0129] In one embodiment, when the processor 110 executes the rendering of a heatmap based on the dynamic-static fusion strategy graph for display on a visualization interface, it specifically performs the following operations: calculates the rule influence index based on the historical decision data and the number of triggers in the dynamic attributes; and performs color gradient rendering on each node of the dynamic-static fusion strategy graph based on the rule influence index and the trigger frequency to obtain a heatmap for display on a visualization interface.

[0130] In one embodiment, when the processor 110 performs the calculation of the rule influence index based on historical decision data and the number of triggers in the dynamic attributes, it specifically performs the following operations: calculates the weight influence of each rule node based on historical decision data; and calculates the rule influence index based on the weight influence and the number of triggers in the dynamic attributes.

[0131] In one embodiment, when the processor 110 performs the calculation of the weight influence of each rule node based on historical decision data, it specifically performs the following operations: calculates the marginal contribution of each feature subset to the model prediction based on historical decision data; performs a weighted average of the marginal contributions to obtain the weight influence of each sample; and determines the weight influence of the rule node based on the weight influence of each sample.

[0132] In one embodiment, when the processor 110 performs the calculation of the rule influence index based on the weighted influence combined with the number of triggers in the dynamic attribute, it specifically performs the following operations:

[0133]

[0134] in, For rules The influence index, known as the SHAP value, is used to measure the combined effect of rule quality and activity. The rule number whose influence is being calculated; n is the total number of historical samples; In the sample The following rules The SHAP value represents its contribution to the sample; This is the j-th historical sample data; For rules The number of times a rule is triggered in historical data is used to measure its activity level. The logarithmic transformation of the trigger number is used to compress the order-of-magnitude difference, so that the high-frequency rules do not over-amplify the contribution.

[0135] In one embodiment, after the processor 110 executes the rendering of the heatmap based on the dynamic-static fusion strategy map to display it on the visualization interface, it further performs the following operations: adjusting the decision logic in response to the user's adjustment instruction on the visualization interface; performing random sampling prediction on the adjusted decision logic using the Monte Carlo simulation method to obtain execution performance indicators and generate a comparison view.

[0136] In one embodiment, after the processor 110 executes the rendering of the heatmap based on the dynamic-static fusion strategy map to display it on the visualization interface, it also performs the following operations: detects the dynamic-static fusion strategy map and identifies low-frequency execution paths.

[0137] In one embodiment, when the processor 110 executes the detection of the static-dynamic fusion strategy graph and identifies low-frequency execution paths, it specifically performs the following operations: sets a time window threshold; traverses the branch paths in the static-dynamic fusion strategy graph; if there is a branch path whose trigger count is zero within the time window, then the branch path is marked as a low-frequency execution path and a warning is given in the visualization interface.

[0138] In this specification, by collecting runtime behavioral data and static logical data in parallel and representing them in the form of a graph, the unobservability of decision-making logic can be eliminated at the overall level, and the traceability and quantifiability of the decision execution chain can be achieved, thereby providing a unified and reliable data foundation for subsequent rule analysis, coverage evaluation and strategy optimization.

[0139] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0140] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the object characteristics, interactive behavior characteristics, and user information involved in this specification were all obtained under full authorization.

[0141] The above-disclosed embodiments are merely preferred embodiments of this specification and should not be construed as limiting the scope of this specification. Therefore, any equivalent variations made in accordance with the claims of this specification shall still fall within the scope of this specification.

Claims

1. A decision logic analysis method, the decision logic analysis method comprising: During the runtime of the server-side decision engine, the real-time rule trigger event stream and decision logic source code of the server are collected in parallel. A dynamic call graph is constructed based on the real-time rule-triggered event stream, and the dynamic call graph includes rule nodes and dynamic attributes of rule triggering; A static dependency graph is constructed based on the source code of the decision logic, and the static dependency graph includes variable nodes and code-level dependencies. The relationship between the dynamic call graph and the static dependency graph is analyzed to generate a dynamic-static fusion strategy graph; A heatmap is rendered based on the dynamic-static fusion strategy map to be displayed on a visualization interface; The process of parsing the relationship between the dynamic call graph and the static dependency graph to generate a dynamic-static fusion strategy graph specifically includes: A mapping relationship between rule nodes in the dynamic call graph and variable nodes in the static dependency graph is established through a node alignment mechanism; Based on the mapping relationship, the dynamic attributes are mapped to the corresponding edges of the static dependency graph to generate a dynamic-static fusion strategy graph; The process of establishing a mapping relationship between rule nodes in the dynamic call graph and variable nodes in the static dependency graph through a node alignment mechanism specifically includes: Parse the unique identifiers of the variable nodes in the static dependency graph; Parse the dynamic rule node identifiers in the dynamic call graph; Merge or establish a connection between the matching dynamic rule node identifier and the variable node unique identifier.

2. The decision logic analysis method according to claim 1, wherein rendering a heatmap based on the dynamic-static fusion strategy map for display on a visualization interface specifically includes: The rule influence index is calculated based on historical decision-making data and the number of triggers in the dynamic attributes. Based on the rule influence index and trigger frequency, color gradient rendering is performed on each node of the dynamic and static fusion strategy map to obtain a heat map for display on the visualization interface.

3. The decision logic analysis method according to claim 2, wherein calculating the rule influence index based on historical decision data combined with the trigger count in the dynamic attributes specifically includes: The weight and influence of each rule node are calculated based on historical decision data; The rule influence index is calculated based on the weighted impact and the number of triggers in the dynamic attributes.

4. The decision logic analysis method according to claim 3, wherein calculating the weight influence of each rule node based on historical decision data specifically includes: The marginal contribution of each feature subset to the model prediction is calculated based on historical decision data. The weighted average of the marginal contributions is used to obtain the weighted impact of each sample; The weight influence of the rule node is determined based on the weight influence of each sample.

5. The decision logic analysis method according to claim 3, wherein the rule influence index is obtained by the following formula: in, For rules The influence index, known as the SHAP value, is used to measure the combined effect of rule quality and activity. The rule number for which the influence is being calculated; n is the total number of historical samples; In the sample The following rules The SHAP value represents its contribution to the sample; This is the j-th historical sample data; For rules The number of times a rule is triggered in historical data is used to measure its activity level. The logarithmic transformation of the trigger number is used to compress the order-of-magnitude difference, so that the high-frequency rules do not over-amplify the contribution.

6. The decision logic analysis method according to claim 1, after rendering the heatmap based on the dynamic-static fusion strategy map for display on the visualization interface, the decision logic analysis method further includes: In response to the user's instruction to adjust the decision logic shown on the visualization interface, the decision logic is adjusted; The Monte Carlo simulation method is used to perform random sampling prediction on the adjusted decision logic to obtain performance indicators and generate a comparison view.

7. The decision logic analysis method according to claim 1, after rendering the heatmap based on the dynamic-static fusion strategy map for display on the visualization interface, the decision logic analysis method further includes: The dynamic-static fusion strategy graph is detected to identify low-frequency execution paths.

8. The decision logic analysis method according to claim 7, wherein detecting the dynamic-static fusion strategy graph and identifying low-frequency execution paths specifically includes: Set a time window threshold; Traverse the branch paths in the dynamic-static fusion strategy graph; If a branch path has zero trigger counts within the time window, then that branch path is marked as a low-frequency execution path and a warning is displayed in the visualization interface.

9. A decision logic analysis device, the device comprising: The data acquisition module is used to collect real-time rule-triggered event streams and decision logic source code from the server in parallel during the runtime of the server-side decision engine. A dynamic call construction module is used to construct a dynamic call graph based on the real-time rule-triggered event stream. The dynamic call graph includes rule nodes and dynamic attributes of rule triggering. A static dependency building module is used to build a static dependency graph based on the source code of the decision logic. The static dependency graph includes variable nodes and code-level dependencies. The dynamic-static fusion strategy module is used to parse the relationship between the dynamic call graph and the static dependency graph, and generate a dynamic-static fusion strategy graph. The heatmap visualization module is used to render a heatmap based on the dynamic-static fusion strategy map for display on a visualization interface; The dynamic-static fusion strategy module specifically includes: The mapping relationship establishment submodule is used to establish the mapping relationship between the rule nodes in the dynamic call graph and the variable nodes in the static dependency graph through a node alignment mechanism; The fusion graph generation submodule is used to map the dynamic attributes to the corresponding edges of the static dependency graph according to the mapping relationship, and generate a dynamic-static fusion strategy graph. The mapping relationship establishment submodule specifically includes: The variable node parsing unit is used to parse the unique identifier of the variable node in the static dependency graph; the dynamic rule parsing unit is used to parse the dynamic rule node identifier in the dynamic call graph. The node identifier merging unit is used to merge or establish associations between matching dynamic rule node identifiers and variable node unique identifiers.

10. A computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the method steps of any one of claims 1 to 8.

11. A computer program product storing at least one instruction, said at least one instruction being loaded by a processor and executing the method steps of any one of claims 1 to 8.

12. An electronic device, comprising: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and executed the method steps as claimed in any one of claims 1 to 8.

Images