This article mainly focuses on the construction of decision tree orchestration capability in risk control decision engine. Decision engine is the brain of risk control, and the decision tree orchestration ability and experience is the means to build the brain, how to build efficient, silky, stable and reliable decision tree orchestration ability, is a major challenge to the risk control decision engine, this article and everyone to share the past construction experience.

Any system is certainly not built in the direction of “one step” in the early stage, but the architect tries to build in the direction of expandable and maintainable in the later stage. Good underlying design, not afraid of crazy iteration in the later stage of the product, and easy to change and adjust. Bad “cramming” code, probably in order to achieve functionality as soon as possible, will eventually develop into a “mountain”, and the maintenance cost is getting higher and higher, either to run away, or to start over.

The goal of this phase: to minimize the viable product (MVP); Small cloth iteration, fast online; One person plays multiple roles.

In the early days of the establishment of the risk control department, there were few personnel, lack of UED and front-end, after all, risk control itself is not just needed for visual design and front-end, mainly back-end research and development and strategic operation against black production. At this time, in order to be able to launch the decision tree function as soon as possible, the R&D personnel directly place the decision tree static configuration file (the specific implementation is decomposed below) under the resource directory of the code layer in the idea of small steps and fast running, and each change needs to be released. The construction of the engine itself is also imperfect, there are many functions that need to be added, and it is common to send several versions a week, and everyone can accept it at this stage.

The goal of this stage: no need to issue a release, production changes quickly; Stability-related considerations.

With the gradual growth of the department team, as well as the specification of the R & D process, risk control strategy operators for the response to the timeliness and visualization of decision-making needs are more and more urgent, for the R & D needs to be issued to deploy new decision-making capabilities are dissatisfied, black production is efficient, but R & D release is the need for orchestration and time, everyone has to issue the release, and concentrated in a release cycle, the strategy proposed on Monday, stay until Wednesday and everyone’s needs together, at this time the black production has finished running early. At the same time, there is a certain risk of publishing the version, and if it goes wrong, it needs to be rolled back immediately, which delays the time of the strategy to go online.

Based on the above, we consider that it is time to open up the production environment to directly visualize the ability to orchestrate decision trees, but we do not have front-end students, find other departments to borrow and may not be familiar with the decision engine This set of process specifications, communication costs are still high. The compromise is a solution: the static configuration file is moved to the DB store, and the configuration is displayed in the form of text characters on the front end, which does not require a complex front-end design, and only needs simple form text box filling to meet the requirements of the R&D modification decision flow. In this way, the original static configuration is “moved” and can be configured directly in production, which greatly improves the efficiency of production deployment.

The goal of this stage: efficient, stable, and intelligent visual decision tree orchestration capability product construction

There are more and more business lines that access risk control, and R&D personnel are busy with the development and iteration of variables corresponding to risk scenarios, and they still need to allocate part of their energy to modify the decision tree. Version 2.0 of the decision tree is a string for the operation, not a tree, the policy operation can not be modified, do not dare to modify, the risk of error is too great. Considering that the volume and mode of the entire risk control has been very stable, there is also a certain amount of time to consider the decision arrangement into a visual product delivery strategy personnel use, after all, the adjustment of the decision tree itself is also one of the responsibilities of the strategy, and it is necessary to precipitate this as a highly available product.

We refer to the front-end style design specifications of the BPMN workflow in the industry, extract the elements needed in the risk control decision tree, and build our own decision engine intelligent orchestration capability, visual drag and drop nodes, which can be fully delivered to the strategists for their own configuration and use.

A decision tree is actually a variant DAG (directed acyclic graph) in which the nodes have different properties and functions at the business level.

So how do you store this DAG structure? With two-dimensional array storage, it is impossible to meet the requirements of node attributes and edge attributes, one is that the boundary cannot be defined, perhaps the tree is very large, and the other is that the attributes are implemented by the association table, which will be very fragmented and cannot be intuitively seen.

In fact, the diagram can be represented by a linked list, and the first reaction of the stored structure of the linked list is JSON or XML. It is conceivable that if it is represented by JSON, the hierarchical nesting relationship will be very cumbersome, after all, JSON is used to serialize data, and it is more convenient and intuitive to add properties in terms of display or XML addition.

For example, a simple decision tree is as follows

The decision tree above is represented by an XML data structure as follows:

The above data structure very intuitively represents the current decision tree data structure that needs to be drawn, compared to the data representation of JSON, XML is more flexible, more convenient to expand, and can have a better balance between horizontal and deep.

XML is a very mature technical implementation, there are many open source implementations of parsing XML on the market, such as the above data structure I use common-digester parsing, POM introduced the following dependencies can be:

The entity relationships are as follows:

The XML data is parsed as follows:

where the addNode logic is to store all nodes within a nodeMap structure and assign a value to the startNode node if the current node is the start node.

When the XML is parsed, the association relationship has not yet been established, after polling each node, the node is connected to the node, and the node is verified to exist enough to ensure that it can be associated into a tree.

The execution of the decision only needs to start from the startNode execution and execute recursively until a unique exit pops up. Note that the policy interface has an output decision result, if it is rejected, you can directly interrupt the process execution and return the result.

Among them, the SplitNode node execution needs to evaluate the conditional expression, as long as one condition is met, the node that goes down can be determined, and the subclass override implementation is as follows:

Note: Conditional expressions I previously posted a separate article, if you are interested, please pay attention to it, you can find it in my historical article archive, I will not expand it here.

The execution principle of StrategyNode node is consistent with that of SplitNode, and only subclass overrides the implementation method to execute the corresponding rule engine and obtain the decision result to determine the trend, which is not listed here.

As above, the storage structure of the decision tree is designed, and with the style of the BPMN flow chart built by the front-end students, the node information and expression required for customized risk control can be built at any time (a sentence has been taken here, but in the silky orchestration and auxiliary verification, the front-end students have paid a lot, of course, this is not the focus of this article).

This article shares the thinking and construction process of decision flow graphs in the decision engine, from the minimum available product launch to support business development to the workspace that precipitates the visualization orchestration ability. Of course, this article only shows the thinking and construction process of the general decision flow, showing that there will still be various challenges in the business, such as performance requirements, cost control, etc., there are many challenges, I will share them one by one in the follow-up, welcome to pay attention.

•From 0 to 1 Intelligent risk control decision engine construction • Performance optimization essentials – flame map • How did I get into the business of risk control

Welcome to the public number: Gollum chicken technical column

Personal Technical Blog: https://jifuwei.github.io/