Online feature and model version binding method and system applied to model service

Abstract

The application provides an online feature and model version binding method and system applied to a model service, relates to the technical field of model service management, performs a feature solidification operation on a risk feature gathering container, generates a risk feature solidification copy bound with a risk control request identifier and synchronizes to an offline feature warehouse; constructs a risk control model label directory, writes a risk control model identifier and a corresponding model version label chain; extracts a target risk feature solidification copy corresponding to a target risk control request identifier from the offline feature warehouse, extracts a target model version label from the risk control model label directory, encapsulates the two as a version binding snapshot, and writes into a version binding registry, so that a corresponding risk control service session only schedules a corresponding model version entity through the target model version label to perform online risk reasoning. The application realizes accurate binding and session-level scheduling control of online features and model versions.

Description

Technical Field

[0001] This application relates to the field of model service management technology, and more specifically, to a method and system for binding online features and model versions to model services. Background Technology

[0002] In internet finance, e-commerce, and digital payment scenarios, risk control models, as core components of online services, play a crucial role in real-time risk identification and transaction interception. With the continuous expansion of business scale and the constant evolution of fraud methods, risk control models need frequent iterations to maintain the timeliness of their judgment capabilities; model version updates have become a routine operation in the daily maintenance of risk control systems. Meanwhile, the risk features upon which online risk control inference relies are typically dynamically generated by real-time computing engines. These features are strongly correlated with specific risk control requests and are time-sensitive.

[0003] In existing technologies, the association management between online features and model versions typically adopts the following methods: One method is to statically bind specific model versions to feature computation pipelines at the model service deployment level. That is, when the model goes online, the feature sources and computation logic it depends on are fixed, and the feature pipeline configuration needs to be adjusted synchronously when the model version is updated. Another method is to distribute mapping rules between model versions and feature types through a configuration center at the request processing level, and the service runtime dynamically selects features and models according to the rules. However, the static binding method cannot cope with the differences in feature dependencies between different versions of the same model. When model iteration leads to changes in feature requirements, the entire feature pipeline needs to be redeployed, causing service interruption risks. Although the dynamic rule method has a certain degree of flexibility, it lacks the ability to solidify and record the precise correspondence between the specific feature instance used in a single risk control request and the specific model version. In scenarios such as post-event auditing, model effect backtracking, and feature drift investigation, it cannot provide traceable binding evidence, and the risk of rule conflicts and version scheduling chaos is high in high-concurrency request scenarios. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide an online feature and model version binding method and system for model services.

[0005] According to a first aspect of this application, an online feature-model version binding method for model services is provided, the method comprising: Construct a risk feature aggregation container, write a risk control request identifier into the risk feature aggregation container, and write an online risk feature set corresponding to the risk control request identifier into the risk feature aggregation container; Perform a feature solidification operation on the risk feature aggregation container to generate a solidified copy of the risk feature bound to the risk control request identifier, and synchronize the solidified copy of the risk feature to the offline feature repository; Construct a risk control model tag directory, write a risk control model identifier into the risk control model tag directory, and write a model version tag chain corresponding to the risk control model identifier into the risk control model tag directory. Each model version tag in the model version tag chain points to a model version entity. Extract a solidified copy of the target risk feature corresponding to the target risk control request identifier from the offline feature repository, and extract the target model version tag corresponding to the target risk control model identifier from the risk control model tag directory. Encapsulate the solidified copy of the target risk feature and the target model version tag into a version-bound snapshot. Write the version binding snapshot to the version binding registry so that the risk control service session corresponding to the version binding snapshot can only schedule the model version entity corresponding to the target risk control model identifier to perform online risk inference through the target model version tag.

[0006] According to a second aspect of this application, an online feature and model version binding system for a model service is provided. The online feature and model version binding system for a model service includes a machine-readable storage medium and a processor. The machine-readable storage medium stores machine-executable instructions. When the processor executes the machine-executable instructions, the online feature and model version binding system for a model service implements the aforementioned online feature and model version binding method for a model service.

[0007] Based on any of the above aspects, the technical effect of this application is as follows: By constructing a risk feature aggregation container and associating risk control request identifiers with corresponding online risk feature sets, a one-to-one mapping anchor between feature data and specific risk control requests is established at the initial stage of request processing. This ensures that the feature instances used by each risk control request in a high-concurrency online service environment have a clear request-level identifier. Subsequently, by performing feature solidification operations on the risk feature aggregation container, a solidified copy of the risk feature bound to the risk control request identifier is generated and synchronized to the offline feature repository. This transforms transient online feature data into persistent and traceable offline solidified records. On the model side, by constructing a risk control model tag directory and writing model identifiers and corresponding model version tag chains, a structured hierarchical index is established between model entities and their historical versions. This allows any model version to be accurately located and referenced through the tag chain. Furthermore, data is retrieved from the offline feature repository. The target risk feature fixed copy and target model version tag corresponding to the target risk control request identifier are extracted from the risk control model tag directory and encapsulated into a version binding snapshot. This immutably couples the online feature instance and the model version entity at the request granularity, forming binding evidence that combines feature traceability and version location. Finally, the version binding snapshot is written to the version binding registry and the risk control service session is constrained to schedule the corresponding model version entity for online inference only through the target model version tag. At the runtime level, session-level strong consistency constraint of feature version is achieved, eliminating the problem of feature and model mismatch caused by chaotic version scheduling. In the high-frequency iteration risk control model service scenario, it can achieve accurate binding of feature instance and model version for each risk control request, full lifecycle traceability, and strong runtime consistency scheduling, which significantly improves the reliability, auditability, and version control granularity of online risk control services. Attached Figure Description

[0008] Figure 1 The diagram illustrates a flowchart of the online feature-model version binding method for model services provided in an embodiment of this application.

[0009] Figure 2 This is a schematic diagram of the online feature aggregation and solidification and model version tag directory construction scenario provided in the embodiments of this application.

[0010] Figure 3 This is a schematic diagram of the version binding snapshot registration and model version entity scheduling inference scenario provided in the embodiments of this application. Detailed Implementation

[0011] Figure 1 This paper illustrates a flowchart of an online feature-model version binding method for model services provided in an embodiment of this application. The detailed steps include: Step S110: Construct a risk feature aggregation container, write a risk control request identifier into the risk feature aggregation container, and write the online risk feature set corresponding to the risk control request identifier into the risk feature aggregation container.

[0012] Step S111: Receive the risk control service request, parse the request header of the risk control service request, extract the risk control request identifier corresponding to the risk control service request, and extract the risk control scenario type tag corresponding to the risk control service request.

[0013] A risk control service request message is retrieved from the message queue and serialized in protocol buffer format. The message is then deserialized to obtain the request message body. The request header of the message body contains a risk control request identifier field and a risk control scenario type tag field. The risk control request identifier is a universally unique identifier string generated by the payment gateway using the UUID version 4 algorithm when generating the risk control service request. The risk control scenario type tag is an enumerated tag, with values ​​including payment transfer scenario tag, account login scenario tag, and credit application scenario tag. The value of the risk control request identifier field in the request header is denoted as Rid, and the value of the risk control scenario type tag field is denoted as Stype.

[0014] like Figure 2 As shown, in the process of acquiring and parsing the risk control service request, the request message is logically broken down into two parts: a request header and a request body. The request header carries a risk control request identifier used to uniquely identify the current transaction and a risk control scenario type label used for classification; the request body, as the source of the original risk characteristics, contains account behavior attribute fields and transaction environment attribute fields. Figure 2 The text clearly indicates, through explicit arrows, that the aforementioned fields will be further processed by the risk feature aggregation container to generate subsequent online risk feature sets.

[0015] Step S112: Create an aggregation storage unit within the risk feature aggregation container, with the risk control request identifier as the primary key and the risk control scenario type label as the partition key. The aggregation storage unit has a graph-like storage structure that carries multi-dimensional risk feature fields.

[0016] The risk feature aggregation container is an in-memory key-value store engine, internally organizing storage space by partition key. Using `Stype` as a parameter, the corresponding partition is located within the risk feature aggregation container, and an aggregation storage unit with `Rid` as the key is created within that partition. The aggregation storage unit's data structure is a graph-like storage structure with adjacency lists and attribute tables stored separately. The adjacency list stores directed edge connections between nodes, and each node corresponds to a row index in the adjacency list, which stores a list of indexes of all target nodes originating from that node. The attribute table stores the set of attribute fields for each node, and each node corresponds to a column family in the attribute table. A column family can hold multiple mapping pairs of column names and column values. The adjacency list and attribute table are linked by a unique node identifier, which is `Rid` concatenated with the node type prefix and an auto-incrementing sequence number.

[0017] Step S113: Parse the request body of the risk control service request and extract the original risk feature set carried by the risk control service request. The original risk feature set includes account behavior attribute fields and transaction environment attribute fields.

[0018] Continuing to parse the request body portion of the request message, this portion contains the original risk feature set, organized as a nested list of key-value pairs. Traversing this list, key-value pairs are categorized by their key prefixes: those prefixed with account behavior attributes are assigned to the account behavior attribute field, and those prefixed with transaction environment attributes are assigned to the transaction environment attribute field. The account behavior attribute field includes a sequence of transaction amounts over the past 24 hours, a sequence of counterparty types over the past 24 hours, and a sequence of transaction time intervals over the past 24 hours. The transaction environment attribute field includes device fingerprint, network IP address location, and geographic location coordinates.

[0019] Step S114: Perform behavior trajectory restoration processing on the account behavior attribute fields to generate a directed graph of account behavior trajectory. The directed graph of account behavior trajectory uses behavior events as nodes and the temporal jump relationship between behavior events as edges.

[0020] The system extracts the transaction amount sequence, counterparty type sequence, and transaction time interval sequence for the past 24 hours from the account behavior attribute fields, aligning these three sequences by timestamp. Each transaction is abstracted as a behavior event node, with attributes including the transaction amount, counterparty type, and time interval between the transaction and the previous transaction. The node identifier for a behavior event node is formatted as Rid concatenated with the behavior event prefix and the transaction's sequence number. A directed edge is formed by connecting the earlier-occurring behavior event nodes to the later-occurring ones, according to the chronological order of the transactions. The directed edge's attribute includes a jump type, determined by the combination of the counterparty types of the preceding and following transactions. All behavior event nodes and directed edges constitute a directed graph of account behavior trajectory.

[0021] Step S115: Perform environmental profile reconstruction processing on the transaction environment attribute fields to generate a transaction environment profile topology graph. The transaction environment profile topology graph uses environmental entities as nodes and the relationships between environmental entities as edges.

[0022] Device fingerprints, network IP address geolocation, and geographic coordinates are extracted from the transaction environment attribute fields. Device fingerprints are abstracted into device entity nodes, network IP address geolocation into network entity nodes, and geographic coordinates into location entity nodes. Each environment entity node's attributes include its type label and entity value. The node identifier format for environment entity nodes is Rid concatenated with the environment entity prefix and an auto-incrementing entity type number. Directed edges are established between device entity nodes and network entity nodes, indicating that the device accesses the network through that network; directed edges are established between network entity nodes and location entity nodes, indicating that the network serves that geographic location area. All environment entity nodes and directed edges constitute the transaction environment profile topology.

[0023] Step S116: Write the directed graph of account behavior trajectory to the account behavior attribute sub-partition of the aggregation storage unit, and write the transaction environment profile topology graph to the transaction environment attribute sub-partition of the aggregation storage unit.

[0024] Allocate account behavior attribute sub-partitions and transaction environment attribute sub-partitions in the adjacency list of the aggregated storage unit. Add a new row to the adjacency list for each behavior event node in the directed graph of the account behavior trajectory, and write the attributes of the behavior event node into the account behavior attribute sub-partition column family of the attribute table. Write the directed edges between behavior event nodes into the target node index list of the corresponding row in the adjacency list. Add a new row to the adjacency list for each environment entity node in the transaction environment profile topology graph, and write the attributes of the environment entity node into the transaction environment attribute sub-partition column family of the attribute table. Write the directed edges between environment entity nodes into the target node index list of the corresponding row in the adjacency list.

[0025] Step S117: Extract the out-degree and in-degree sequences of each behavioral event node in the directed graph of account behavior trajectory into behavioral flow feature vectors. Extract the adjacency matrix of each environmental entity node in the transaction environment profile topology graph into an environment association feature vector. Use the behavioral flow feature vector and the environment association feature vector as topological attribute annotations for the directed graph of account behavior trajectory and the transaction environment profile topology graph, respectively, and attach them to the corresponding graph nodes or edge attributes. Encapsulate the directed graph of account behavior trajectory, the transaction environment profile topology graph, and their associated topological attribute annotations into a graph structure feature package. This graph structure feature package constitutes the online risk feature set corresponding to the risk control request identifier.

[0026] For each behavior event node in the directed graph of account behavior trajectory, count the number of directed edges originating from that node as the out-degree and the number of directed edges ending at that node as the in-degree. Arrange the out-degree values ​​of all behavior event nodes by node index to form the out-degree dimension component of the behavior flow feature vector, and arrange the in-degree values ​​of all behavior event nodes by node index to form the in-degree dimension component of the behavior flow feature vector. For all environment entity nodes in the transaction environment profile topology graph, construct a Nenv×Nenv adjacency matrix, where Nenv is the total number of environment entity nodes. If there is a directed edge between the p-th and q-th environment entity nodes, the element at the corresponding position in the adjacency matrix is ​​1; otherwise, it is 0. Expand the adjacency matrix row-wise into a one-dimensional vector, which is the environment association feature vector. Add the out-degree and in-degree dimension components as topological attribute labels to the edge attributes of the directed graph of account behavior trajectory, and add the one-dimensional expanded vector of the adjacency matrix as topological attribute labels to the edge attributes of the transaction environment profile topology graph. The directed graph of account behavior trajectory and the topology graph of the trading environment profile, along with their associated topology attribute annotations, are serialized into a graph structure feature package. The serialization format of the graph structure feature package is as follows: adjacency list first, attribute table in the middle, and topology attribute annotations last. This graph structure feature package constitutes the online risk feature set corresponding to Ridgment ID (RID).

[0027] like Figure 2 As shown, within the internal structure of the risk feature aggregation container, online risk features are organized using a graph-like storage structure. The aggregation storage unit of this container simultaneously carries a directed graph of account behavior trajectories and a topological graph of the transaction environment profile. The directed graph of account behavior trajectories consists of behavioral event nodes and directed edges that connect behavioral events in a temporal sequence, with out-degree and in-degree attributes marked next to each node. The topological graph of the transaction environment profile uses environmental entity nodes as units and records the relationships between entities through an adjacency matrix. Figure 2 The data format shows the coexistence of the above graph structure and graph attributes in the risk feature aggregation container, which together constitute the online risk feature set corresponding to the current risk control request identifier.

[0028] Step S120: Perform feature solidification operation on the risk feature aggregation container to generate a risk feature solidification copy bound to the risk control request identifier, and synchronize the risk feature solidification copy to the offline feature repository.

[0029] Step S121: Capture the termination status signal of the risk control service session corresponding to the risk control request identifier, and apply a write lock to the aggregation storage unit corresponding to the risk control request identifier based on the termination status signal.

[0030] After the risk control service session completes risk inference and returns the risk inference result, the risk control service session management component sends a session termination status signal to the risk feature aggregation container, which carries the Rid. Upon receiving the session termination status signal carrying the Rid, the risk feature aggregation container acquires a mutex lock on the write operation of the aggregation storage unit corresponding to the Rid. The mutex lock is in exclusive locking mode, and during the locking period, no thread is allowed to perform write or modification operations on the aggregation storage unit. Existing read operations are allowed to continue until completion.

[0031] Step S122: After the write lock takes effect, perform topological sorting on the directed graph of account behavior trajectory stored in the aggregation storage unit to generate a linearized sequence of account behavior trajectory; perform topological sorting on the topological graph of transaction environment profile stored in the aggregation storage unit to generate a linearized sequence of transaction environment profile; perform dimensional compression on the behavior flow feature vector stored in the aggregation storage unit to generate a behavior flow compressed feature vector; and perform dimensional compression on the environment association feature vector stored in the aggregation storage unit to generate an environment association compressed feature vector.

[0032] After the exclusive lock takes effect, all behavior event nodes and directed edges of the directed graph of account behavior trajectories are read from the adjacency list of the pooled storage unit. The Kahn topological sorting algorithm is then used to perform a topological sort on the directed graph of account behavior trajectories. First, all behavior event nodes with an in-degree of zero are added to a first-in-first-out (FIFO) queue. A behavior event node is retrieved from the head of the queue and appended to the end of the linearized sequence of account behavior trajectories. Then, all outgoing edges of that behavior event node are traversed, and the in-degree of the target behavior event node pointed to by each outgoing edge is decremented by 1. If the in-degree of the target behavior event node becomes zero after decrementing by 1, the target behavior event node is added to the end of the queue. This retrieval and traversal operation is repeated until the queue is empty. The order of behavior event nodes in the generated linearized sequence of account behavior trajectories conforms to the partial order constraint of the directed graph of account behavior trajectories.

[0033] The Kahn topological sort is also performed on the transaction environment profile topology graph to generate a linearized sequence of transaction environment profiles.

[0034] Dimensionality compression is performed on the behavior flow feature vector using principal component analysis (PCA). This involves calculating the covariance matrix of the behavior flow feature vector and performing eigenvalue decomposition. The eigenvectors corresponding to the top Kbeh largest eigenvalues ​​are used to construct a projection matrix. Multiplying the behavior flow feature vectors by the projection matrix yields the dimensionality-reduced compressed behavior flow feature vectors. Similarly, PCA is used to reduce the dimensionality of the environment association feature vectors. The eigenvectors corresponding to the top Kenv largest eigenvalues ​​are used to construct a projection matrix. Multiplying the environment association feature vectors by the projection matrix yields the dimensionality-reduced compressed environment association feature vectors.

[0035] Step S123: Construct a structured container containing a metadata area and a payload area. Store the linearized sequence of account behavior trajectories and the compressed feature vector of behavior flow as the first set of structured data blocks in the payload area. Store the linearized sequence of the transaction environment profile and the compressed feature vector of environment association as the second set of structured data blocks in the payload area. Store the adjacency index of the directed graph of account behavior trajectories and the topology graph of the transaction environment profile as a topology recovery guide in the metadata area. Serialize and encode the entire content of the structured container to generate a risk feature encoding string, and attach a digest verification value of the risk control request identifier to this encoding string to generate a fixed copy of the risk features. Synchronize the fixed copy of the risk features from the risk feature aggregation container to the offline feature repository, and release the write lock on the aggregation storage unit after synchronization is complete.

[0036] Construct a structured container containing two contiguous memory blocks: a metadata area and a payload area. The metadata area is located at the starting address, and the payload area immediately follows it. The linearized sequence of account behavior trajectories is written into the first segment of the payload area in fixed-length format, ordered by the behavior event node numbers. The compressed feature vector of behavior flow is then written immediately afterward in floating-point array format. These two elements constitute the first set of structured data blocks. The linearized sequence of the transaction environment profile is written into the second segment of the payload area in fixed-length format, ordered by the environment entity node numbers. The compressed feature vector of environment association is then written immediately afterward in floating-point array format. These two elements constitute the second set of structured data blocks.

[0037] Extract the row and column index offsets of each behavior event node in the directed graph of account behavior trajectories from the original adjacency table, and record them as the account behavior adjacency index. Extract the row and column index offsets of each environment entity node in the transaction environment profile topology graph from the original adjacency table, and record them as the transaction environment adjacency index. Write the account behavior adjacency index and the transaction environment adjacency index into the metadata area in sequence to form the topology recovery guide.

[0038] The entire content of the structured container is serialized using Base64 encoding to generate a risk feature encoded string. The SHA-256 hash algorithm is used to hash the risk feature encoded string, and the first few bits of the hash value are used as a digest checksum. This digest checksum is concatenated with the risk feature encoded string using a delimiter to generate a fixed copy of the risk features. This fixed copy of the risk features is synchronized from the memory area where the risk feature aggregation container resides to the persistent storage of the offline feature repository via a data transmission channel. The persistent storage of the offline feature repository is a distributed file system. After synchronization is complete, the exclusive lock on the aggregation storage unit is released, and the write lock is released.

[0039] like Figure 2 As shown, when the feature solidification operation is triggered, the graph structure data in the risk feature aggregation container is converted into a serialized encoded form. Figure 2The document illustrates the topology sorting and dimensionality compression processes involved in the feature solidification operation. After these processes are completed, the data is organized into a structured container, which is functionally divided into a metadata area and a payload area. The payload area stores the first and second sets of structured data blocks, while the metadata area records the topology recovery guidelines used to reconstruct the relationships. Figure 2 The thick solid arrow in the image clearly indicates that after being encapsulated in this structured container, the final solidified copy of the risk characteristics is synchronized to... Figure 2 The offline feature repository on the right (represented by a database cylinder in the figure).

[0040] Step S130: Construct a risk control model tag directory, write risk control model identifiers into the risk control model tag directory, and write a model version tag chain corresponding to the risk control model identifiers into the risk control model tag directory. Each model version tag in the model version tag chain points to a model version entity.

[0041] Step S131: Generate a unique risk control model identifier for each deployed risk control model instance, and extract the risk control scenario type tag corresponding to the risk control model instance.

[0042] Whenever a risk control model instance is deployed to the online risk control model service platform, a unique risk control model identifier is generated for that instance. This identifier is generated by concatenating the instance's name, version number, and deployment timestamp using a hyphen. The risk control scenario type tag for that instance is extracted from the model configuration file.

[0043] Step S132: In the risk control model tag directory, establish a multi-level master index node for the risk control model identifier, with the risk control scenario type tag as the index dimension.

[0044] The risk control model tag directory is a tree-structured storage system. The root node corresponds to the risk control scenario type tag, and the child nodes of the root node correspond to the risk control model identifiers. Using the risk control scenario type tag Stype as the first-level index, the system searches the risk control model tag directory for a corresponding root node. If it doesn't exist, the root node is created. Under the root node corresponding to Stype, child nodes are created using the risk control model identifier as the second-level index. The data area of ​​each child node stores the head pointer address of the model version tag chain corresponding to that risk control model identifier.

[0045] Step S133: Subscribe to the risk control model version release message stream. When the risk control model version release message stream generates a new version release event, extract the risk control model identifier, new version number, and version compatibility description information from the new version release event.

[0046] The message topic for publishing message streams to risk control model versions is implemented using a publish-subscribe message queue. When a new version of the risk control model is deployed, the deployment pipeline publishes a new version release event message to this message topic. The message body contains the risk control model identifier, the new version number, and version compatibility description information. The version compatibility description information is an enumeration value, which can be one of forward compatibility, bidirectional compatibility, or incompatibility.

[0047] Step S134: Perform tag encoding on the new version number to generate a model version tag, and embed the version compatibility description information into the extended attribute field of the model version tag.

[0048] The new version number is tagged and encoded. The tag encoding method is to multiply the three segments of the semantic version number of the new version number by a preset weight coefficient and then sum them to obtain an integer value as the main code of the model version tag. An extended attribute field is allocated in the structure of the model version tag, and the version compatibility description information is written into the extended attribute field in the format of key-value pair strings.

[0049] Step S135: Associate the model version tag with the storage path of the model version entity corresponding to the new version number to obtain the version association record, and write the version association record to the end of the model version tag chain corresponding to the risk control model identifier in the risk control model tag directory.

[0050] The model version entity is a serialized file of the risk control model instance, stored in the model repository's file system. The storage path is a directory hierarchy consisting of the model repository root path concatenated with the risk control model identifier and version number. The model version tag is associated with this storage path by writing a storage path pointer into the model version tag structure. The version association record, containing the model version tag and storage path pointer, is appended to the end of the model version tag chain corresponding to the risk control model identifier. The model version tag chain is a singly linked list, where each node stores a version association record, and the successor pointer of the tail node is null.

[0051] Step S136: Establish an address pointer to the corresponding model version entity for each model version tag in the model version tag chain, and establish version compatibility association edges between adjacent model version tags based on the version compatibility description information.

[0052] For each model version tag in the model version tag chain, its storage path pointer is copied and used as an address pointer, which is stored in the address field of the model version tag structure. Traversing adjacent model version tags in the chain, if the version compatibility description information in the extended attribute field of the preceding model version tag indicates forward compatibility or bidirectional compatibility, a version compatibility association edge is established between the preceding and following model version tags. This edge is unidirectional, following the release time order. If the extended attribute field of the following model version tag indicates backward compatibility or bidirectional compatibility, a reverse version compatibility association edge is established between the two model version tags. The structure of the version compatibility association edge includes the source model version tag address, the target model version tag address, and a compatibility strength attribute.

[0053] like Figure 2 As shown, the risk control model tag directory serves as the model version organization function in the system architecture. This directory uses a tree structure to organize multi-level indexes, containing risk control scenario type tags, risk control model identifiers, and a model version tag chain. The model version tag chain arranges multiple model version tags sequentially in a linked list, with each tag node carrying an address pointer and version compatibility description information. Figure 2 The dashed arrows indicate the specific flow of the new version release event. That is, after the event is parsed, a new model version tag will be generated and appended to the end of the corresponding model version tag chain.

[0054] Step S140: Extract the solidified copy of the target risk feature corresponding to the target risk control request identifier from the offline feature repository, and extract the target model version tag corresponding to the target risk control model identifier from the risk control model tag directory. Encapsulate the solidified copy of the target risk feature and the target model version tag into a version-bound snapshot.

[0055] Step S141: Receive the version binding instruction, parse the target risk control request identifier and target risk control model identifier carried in the version binding instruction, use the target risk control request identifier as the query key, search in the offline feature warehouse, and extract the solidified copy of the target risk feature corresponding to the target risk control request identifier.

[0056] The system receives a version binding instruction, which is a remote procedure call request. The request parameters include the target risk control request identifier Rid_target and the target risk control model identifier Mid_target. Using Rid_target as the query key, a key-value query request is initiated to the offline feature repository. Upon receiving the query request, the offline feature repository searches its index for a fixed copy of the risk feature with the key Rid_target. If a match is found, the storage path of that fixed copy is returned. The serialized data of the fixed copy is read from the storage path and deserialized to obtain the fixed copy of the target risk feature.

[0057] Step S142: Parse the serialized structured container from the solidified copy of the target risk features. Based on the boundaries and indexes defined in the metadata area, separate the first set of structured data blocks and the second set of structured data blocks. Extract the linearized sequence of account behavior trajectories and the corresponding compressed feature vectors of behavior flow from the first set of structured data blocks. Extract the linearized sequence of transaction environment profiles and the corresponding compressed feature vectors of environment association from the second set of structured data blocks. Reconstruct the hierarchical relationship between features based on the topology recovery guide.

[0058] The risk feature encoding string is extracted from the solidified copy of the target risk features. This string is then Base64 decoded to reconstruct the binary representation of the structured container. The account behavior adjacency index and the trading environment adjacency index are read from the metadata area of ​​the structured container. Based on the starting offset and length of each data block in the payload area recorded in the metadata area, the first and second sets of structured data blocks are separated from the payload area. From the first set of structured data blocks, a linearized sequence of account behavior trajectories is parsed in a fixed-length format, and a compressed feature vector of behavior flow is parsed from the following floating-point array. From the second set of structured data blocks, a linearized sequence of the trading environment profile is parsed in a fixed-length format, and an compressed feature vector of environment association is parsed from the following floating-point array.

[0059] Based on the row and column index offsets of the original adjacency table for each behavior event node recorded in the account behavior adjacency index, the behavior event nodes in the linearized sequence of account behavior trajectories are associated with the adjacency relationships in the original directed graph of account behavior trajectories, thus reconstructing the hierarchical relationships between behavior event nodes. Similarly, based on the row and column index offsets of the original adjacency table for each environment entity node recorded in the transaction environment adjacency index, the environment entity nodes in the linearized sequence of transaction environment profiles are associated with the adjacency relationships in the original transaction environment profile topology graph, thus reconstructing the hierarchical relationships between environment entity nodes.

[0060] Step S143: Using the target risk control model identifier as the query key, search the risk control model tag directory, extract the model version tag chain corresponding to the target risk control model identifier, and extract the model version tag with the latest release time from the model version tag chain as the target model version tag.

[0061] Using Mid_target as the query key, traverse the second-level index nodes in the risk control model tag directory to find the risk control model identifier child node that matches Mid_target. After finding the matching child node, read the head pointer of the model version tag chain stored in its data area, and traverse each model version tag one by one along the successor pointers starting from the head node of the chain. Compare the version release time corresponding to each model version tag, and extract the model version tag with the latest release time as the target model version tag.

[0062] Step S144: Obtain the storage path of the model version entity pointed to by the target model version tag through the address pointer of the target model version tag, and read the version compatibility description information of the target model version tag.

[0063] Read the address pointer from the address field of the target model version tag. The address pointer points to a storage address that stores the complete storage path string of the target model version entity. Read the extended attribute field of the target model version tag and parse the version compatibility description information from it.

[0064] Step S145: Create a binding snapshot instance, write the solidified copy of the target risk feature and the target model version tag into the binding snapshot instance, and attach a binding triplet identifier composed of the target risk control request identifier, the target risk control model identifier and the target model version tag to the binding snapshot instance to obtain the version binding snapshot.

[0065] A binding snapshot instance is created in memory. This instance is a structure containing three fields: a target risk feature solidified copy storage area, a target model version tag storage area, and a binding triplet identifier storage area. The serialized byte stream of the target risk feature solidified copy is copied to the target risk feature solidified copy storage area, and the target model version tag structure is copied to the target model version tag storage area. The Rid_target, Mid_target, and target model version tag are concatenated using a delimiter to form a binding triplet identifier string, which is then written to the binding triplet identifier storage area. The completed binding snapshot instance is the version binding snapshot.

[0066] like Figure 2As shown, the generation of version-bound snapshots relies on two data sources. The first is a fixed copy of the target risk feature corresponding to the target risk control request identifier extracted from the offline feature repository; the second is the target model version tag corresponding to the target risk control model identifier extracted from the risk control model tag directory. Figure 2 The dashed arrows clearly indicate that the two data components are encapsulated within a version-binding snapshot, and are appended with a binding triplet identifier consisting of the target risk control request identifier, the target risk control model identifier, and the target model version tag. Subsequently, this version-binding snapshot is written... Figure 2 The version at the bottom is bound to the registry (represented as a registry table graphic).

[0067] Step S150: Write the version binding snapshot to the version binding registry, so that the risk control service session corresponding to the version binding snapshot can only schedule the model version entity corresponding to the target risk control model identifier to perform online risk inference through the target model version tag.

[0068] Step S151: Create a registry record in the version binding registry with the binding triple identifier as the primary key.

[0069] The version binding registry is a hash table structure. The keys of the hash table are the binding triplet identifier strings, and the values ​​are registry record entry structures. The hash value of the binding triplet identifier string is calculated, the corresponding hash bucket is located in the version binding registry, and a new registry record entry is created on the collision chain of that hash bucket. The primary key field of the registry record entry is written with the binding triplet identifier string.

[0070] Step S152: Serialize the version binding snapshot into a data payload for a registry record and write it to the registry record.

[0071] The three storage areas of the version-bound snapshot are serialized sequentially into a continuous byte stream. The serialization format is as follows: the first two bytes store the byte length of the target risk feature solidified copy, followed by the byte stream storing the target risk feature solidified copy; the next two bytes store the byte length of the target model version tag, followed by the byte stream storing the target model version tag; the last two bytes store the byte length of the binding triplet identifier, followed by the byte stream storing the binding triplet identifier string. The serialized continuous byte stream is then written to the data payload field of the registry record.

[0072] Step S153: Set the binding lifecycle status flag to active binding state for the registry record, and synchronize the binding lifecycle status flag with the version compatibility association edge in the model version tag chain corresponding to the target risk control model identifier.

[0073] Write an active binding status flag to the lifecycle field of the registry entry. Check if there is a backward version compatibility association edge in the model version tag chain for the target model version tag. If so, append a reference record to the attribute of the version compatibility association edge. The reference record contains the primary key and binding lifecycle status flag of the registry entry, so that the registry entry can be notified when the version compatibility association edge changes.

[0074] Step S154: When the risk control service session initiates an online risk inference request, extract the current risk control request identifier from the online risk inference request, and use the current risk control request identifier as the query key to retrieve the corresponding current registry record in the version binding registry.

[0075] When a risk control service session needs to perform online risk inference, it constructs an online risk inference request, which includes the current risk control request identifier Rid_current. Using Rid_current as the query key, it concatenates possible risk control model identifiers to form a fuzzy matching pattern of binding triple identifiers. It then performs a prefix scan query in the version binding registry to find the registry record with Rid_current as the first prefix in the binding triple identifier, which is then used as the current registry record.

[0076] Step S155: Parse the version binding snapshot from the current registry record, extract the target model version tag from the version binding snapshot, and locate the storage path of the model version entity corresponding to the target risk control model identifier through the address pointer of the target model version tag.

[0077] The serialized byte stream is read from the data payload field of the current registry record, and deserialized field by field according to the serialization format to reconstruct the contents of the three storage areas of the version-bound snapshot. The target model version tag structure is read from the target model version tag storage area, the address pointer is extracted from the address field, and the storage path string of the target model version entity is read through the address pointer.

[0078] Step S156: Load the model version entity from the storage path of the model version entity, input the solidified copy of the target risk feature in the version binding snapshot into the model version entity for online risk reasoning, and obtain the risk reasoning result.

[0079] Based on the storage path string, the serialized file of the model version entity is located in the file system. The model loader is then invoked to deserialize the model version entity into an executable risk control model instance. Risk feature encoding strings are extracted from the solidified copy of the target risk features and decoded into a structured container. Linearized sequences of account behavior trajectories and transaction environment profiles are extracted from the payload area of ​​the structured container. These two sequences are used as input features and fed into the forward propagation path of the risk control model instance. The risk control model instance outputs a risk inference result, which is a probability distribution vector representing the probability of normal and abnormal transaction categories.

[0080] like Figure 3 As shown, the version binding registry stores binding records in a structured table format. The table explicitly includes the binding triplet identifier, the version binding snapshot data payload, and the binding lifecycle status flag. Figure 3 The active binding status of the record item is highlighted, and the version compatibility association edge synchronization identifier indicates that the record is consistent with the version edge in the directory. During online risk reasoning in the risk control service session, Figure 3 The complete data flow, from receiving the current risk control request identifier to retrieving the registry and parsing the version binding snapshot, is described. Subsequently, Figure 3 The forked arrows indicate the process of extracting the model version entity storage path (i.e., the path located by the target model version label through the addressing pointer) and the solidified copy of the target risk feature from the snapshot. Both serve as input to the model version entity and ultimately output the risk inference result.

[0081] Step S210: Monitor the binding lifecycle status flags of each registry record in the version binding registry. When the binding lifecycle status flag of the target registry record changes from active binding status to expired binding status, parse the corresponding expired version binding snapshot from the target registry record.

[0082] The background maintenance process of the version binding registry traverses all registry entries at a preset polling cycle (Tscan), reading the binding lifecycle status flag stored in the lifecycle field of each registry entry. When the status flag value of a registry entry changes from active binding to expired binding, that registry entry is marked as the target registry entry. The trigger condition for the expired binding state is that the risk control service session corresponding to the registry entry has ended and exceeded the preset liveness time (Tlive). The serialized byte stream is read from the data payload field of the target registry entry, and deserialized field by field according to the serialization format agreed in step S152 to reconstruct the contents of the three storage areas of the expired version binding snapshot: the expired target risk feature solidified copy, the expired target model version tag, and the expired binding triplet identifier.

[0083] Step S220: Extract the expired target model version tag from the expired version binding snapshot, and obtain the storage path of the expired model version entity through the address pointer of the expired target model version tag.

[0084] Read the expired target model version tag structure from the target model version tag storage area of ​​the expired version bound snapshot, extract the address pointer from the address field of the expired target model version tag structure, and read the storage path string of the expired model version entity through the address pointer.

[0085] Step S230: Extract the solidified copy of the expired target risk feature from the expired version binding snapshot, input the solidified copy of the expired target risk feature into the expired model version entity for offline risk backtracking reasoning, and generate risk backtracking reasoning results.

[0086] Read the serialized byte stream of the expired target risk feature solidified copy from the target risk feature solidified copy storage area of ​​the expired version bound snapshot. Load the expired model version entity according to the storage path string obtained in step S220. After decoding the expired target risk feature solidified copy, extract the linearized sequence of account behavior trajectory and the linearized sequence of transaction environment profile, input them into the expired model version entity for offline risk backtracking inference, and output the risk backtracking inference result from the expired model version entity.

[0087] Step S240: Associate the risk backtracking reasoning result with the original registry record in the version binding registry of the expired version binding snapshot to obtain the backtracking binding record. Delete the target registry record in the version binding registry and migrate the backtracking binding record to the binding history archive storage partition.

[0088] A risk backtracking reasoning result field is appended to the structure of the expired version binding snapshot. The risk backtracking reasoning result generated in step S230 is written to this field to form a backtracking binding record. After serializing the backtracking binding record, it is written to the next available storage page of the binding history archive storage partition. The binding history archive storage partition is an independent logical partition partitioned in the storage engine where the version binding registry resides, and it is stored using an append-only write method. After writing is completed, the logical deletion flag of the target registry record is set to true in the version binding registry, releasing the hash bucket collision chain node occupied by the registry record. At the same time, the storage page address and page offset of the backtracking binding record in the binding history archive storage partition are recorded to the archive pointer field of the registry record, establishing a pointer relationship from the original registry record to the backtracking binding record.

[0089] Step S250: Create a timeline index for the backtracking binding records in the binding history archive storage partition. The timeline index organizes the retrieval path of the backtracking binding records with the binding triplet identifier in the expired version binding snapshot as the dimension.

[0090] The metadata area of ​​the binding history archive storage partition maintains a timeline index structure, which is a multi-level skip list. The key of the skip list is the timestamp component contained in the binding triplet identifier in the expired version binding snapshot. The generation timestamp of the target risk control request identifier is parsed from the binding triplet identifier. The values ​​of the skip list are the storage addresses of the retrospective binding records in the binding history archive storage partition. Each time a retrospective binding record is written, a key-value pair node is inserted into the skip list. Multiple retrospective binding records under the same binding triplet identifier dimension form a time-sorted retrieval path in the skip list according to their write timestamps.

[0091] like Figure 3 As shown, the evolution of the version binding lifecycle is clearly illustrated through a state transition diagram. A state transition event is triggered when a record transitions from an active binding state to an expired binding state. This event causes the corresponding data to be migrated out of the version binding registry, and the generated backtracking binding record is stored. Figure 3 The system binds historical archive storage partitions (represented by cylindrical graphics) and creates timeline indexes within these partitions to support the retrieval of expired binding records.

[0092] Step S310: Receive the binding relationship query request, parse the query risk control request identifier carried in the binding relationship query request, and use the query risk control request identifier as the query key to retrieve the corresponding query registry record in the version binding registry.

[0093] The system receives a binding relationship query request, which is a remote procedure call request. The request parameters include the query risk control request identifier Rid_query. Using Rid_query as the query key, a prefix scan query is performed in the version binding registry to find registry entries whose first prefix is ​​Rid_query in the binding triple identifier. If multiple matches are found, the registry entry containing the latest target model version tag in the binding triple identifier is returned.

[0094] Step S320: Parse the version binding snapshot from the query registry record and extract the query model version tag from the version binding snapshot.

[0095] Read the serialized byte stream from the data payload field of the query registry record, deserialize it field by field according to the serialization format, and extract the query model version tag from the reconstructed version binding snapshot.

[0096] Step S330: By querying the version compatibility association edges of the model version tags, trace upstream to obtain the set of upstream model version tags that are compatible with the queried model version tags; by querying the version compatibility association edges of the model version tags, trace downstream to obtain the set of downstream model version tags that are compatible with the queried model version tags.

[0097] Starting from the list of version compatibility association edges for the query model version label, trace upstream along the reverse version compatibility association edges pointing to the query model version label. For each reverse version compatibility association edge reached, an upstream model version label is added to the upstream model version label set. This process continues recursively upstream from the reverse version compatibility association edges of that upstream model version label until no more reverse version compatibility association edges are found. Similarly, trace downstream along the forward version compatibility association edges starting from the query model version label. For each forward version compatibility association edge reached, a downstream model version label is added to the downstream model version label set. This process continues recursively downstream from the forward version compatibility association edges of that downstream model version label until no more forward version compatibility association edges are found.

[0098] Step S340: Combine the query model version tag, the upstream model version tag set, and the downstream model version tag set into a version compatibility tracing link, associate the version compatibility tracing link with the version binding snapshot corresponding to the query risk control request identifier, and generate the binding relationship tracing result.

[0099] The query model version tag is placed in the center, the upstream model version tag set is arranged in ascending order of tracing distance on the left, and the downstream model version tag set is arranged in ascending order of tracing distance on the right. Together, these three constitute the version compatibility tracing link. The version compatibility tracing link is associated with the binding triplet identifier of the version binding snapshot parsed from the query registry record. The association method is to encapsulate the binding triplet identifier and the version compatibility tracing link into a binding relationship tracing result structure.

[0100] Step S350: Return the binding relationship tracing result so that the risk control service session corresponding to the query risk control request identifier can compare the risk inference results among multiple compatible model version entities along the version compatibility tracing link.

[0101] The structure of the binding relationship tracing result is serialized and returned as the response to the binding relationship query request. Upon receiving the response, the corresponding model version entity can be loaded one by one along the addressing pointers of each model version tag in the version compatibility tracing chain. The fixed copies of risk features in the version binding snapshot are then input into these model version entities for risk inference, and the risk inference results of multiple versions are obtained for comparative analysis.

[0102] Step S410: Receive the model version rollback instruction and parse the rollback risk control model identifier and target rollback version number carried in the model version rollback instruction.

[0103] Receive a model version rollback instruction. The model version rollback instruction is a remote procedure call request. The request parameters include the rollback risk control model identifier Mid_rollback and the target rollback version number Vtarget. The target rollback version number is in the format of a three-part semantic version number.

[0104] Step S420: Using the rollback risk control model identifier as the query key, retrieve the corresponding current model version tag chain in the risk control model tag directory, traverse each model version tag in the current model version tag chain, extract the version number corresponding to each model version tag, compare the extracted version number with the target rollback version number, and locate the target rollback model version tag.

[0105] Using `Mid_rollback` as the query key, retrieve the corresponding current model version tag chain in the risk control model tag directory. Starting from the head node of the current model version tag chain, traverse each model version tag, reading its version number field. Compare the version number field with `Vtarget` segment by segment. The comparison method is to compare the major version number, minor version number, and revision number separately. If all three are completely identical, the comparison is successful, and the currently traversed model version tag is identified as the target rollback model version tag.

[0106] Step S430: Obtain the storage path of the target rollback model version entity through the address pointer of the target rollback model version tag, and load the target rollback model version entity from the storage path of the target rollback model version entity.

[0107] Extract the address pointer from the address field of the target rollback model version tag, and read the storage path string of the target rollback model version entity through the address pointer. Locate the serialized file of the target rollback model version entity in the file system based on the storage path string, and call the model loader to deserialize the target rollback model version entity into an executable risk control model instance.

[0108] Step S440: In the version binding registry, retrieve all registry entries that reference the model version tag in the model version tag chain corresponding to the rollback risk control model identifier and whose release time is later than the target rollback version number. Perform a version tag replacement operation on the retrieved registry entries, replace the model version tag in the registry entries with the target rollback model version tag, and update the version compatibility association edge pointing to the registry entries.

[0109] Perform a full table scan in the version binding registry to filter registry entries whose binding triple identifiers contain "Mid_rollback". For each filtered registry entry, parse the version binding snapshot from its data payload, read the version release time of the model version tag, and mark the registry entry as a record to be replaced if the version release time is later than the version release time of the target rollback version number. Perform a version tag replacement operation on the record to be replaced: replace the entire model version tag structure in the data payload with the target rollback model version tag structure, and replace the model version tag portion in the binding triple identifier with the target rollback model version tag. Traverse the version compatibility association edge list of the target rollback model version tag, and point the version compatibility association edges referenced in the record to be replaced to the version compatibility association edge list updated to the target rollback model version tag.

[0110] Step S450: Rewrite the replaced registry entries into the version binding registry so that subsequent risk control service sessions can schedule the target rollback model version entity for online risk reasoning through the target rollback model version tag.

[0111] After performing the version tag replacement operation, the registry record is reserialized into a byte stream and written back to the data payload field at the original hash bucket position of the registry record in the version-bound registry, overwriting the original data. In subsequent risk control service sessions, during the processing flow of steps S154 to S156, the replaced target rollback model version tag will be read, thereby loading the target rollback model version entity for online risk inference.

[0112] like Figure 3 As shown, in a model version rollback scenario, after receiving the model version rollback command, in Figure 3 The system searches the current model version tag chain within the risk control model tag directory in the upper right corner, and locates the target rollback model version tag within the chain. After loading the target rollback model version entity, Figure 3 The registry table area below uses arrows to indicate version label replacement operations: that is, the model version label in the relevant record is replaced with the target rollback model version label. After the replacement is complete, the updated registry record is rewritten to the version binding registry, thereby achieving smooth rollback and scheduling switching of model versions.

[0113] For example, step S510: Extract the target risk feature solidified copy from the version binding snapshot, recalculate the digest verification value attached to the target risk feature solidified copy to obtain the recalculated digest verification value, and compare the recalculated digest verification value with the digest verification value already attached to the target risk feature solidified copy to obtain the digest consistency comparison result.

[0114] Extract the risk feature encoded string and the attached digest checksum from the target risk feature solidified copy storage area of ​​the version-bound snapshot, concatenating them with a delimiter. Recalculate the SHA-256 hash on the risk feature encoded string, using the first few bits of the hash value as the recalculated digest checksum. Compare the recalculated digest checksum with the attached digest checksum bit by bit. If they match completely, the digest consistency comparison result is consistent; otherwise, it is inconsistent.

[0115] Step S520: Extract the target model version tag from the version binding snapshot, obtain the storage path of the model version entity pointed to by the address pointer of the target model version tag, load the model version entity from the storage path of the model version entity, and extract the model structure description information and model weight parameter set of the model version entity.

[0116] Extract the target model version tag structure from the target model version tag storage area of ​​the version-bound snapshot, read the storage path string from the address field, and load the model version entity. The serialized file of the model version entity contains two independent data segments: model structure description information and model weight parameter set. The model structure description information is stored in JSON format, recording the model's layer type, layer name, layer parameter dimensions, and inter-layer connection relationships. The model weight parameter set is stored as a contiguous 32-bit floating-point array, with the expanded values ​​of the weight tensor for each layer arranged sequentially.

[0117] Step S530: Perform structural hash calculation on the model structure description information to generate a model structure hash value; perform weight hash calculation on the model weight parameter set to generate a model weight hash value; and combine the model structure hash value and the model weight hash value into a model version fingerprint.

[0118] Perform a SHA-256 hash calculation on the JSON string describing the model structure information to generate a model structure hash value. Perform a SHA-256 hash calculation on the byte representation of the floating-point array of the model weight parameter set to generate a model weight hash value. Concatenate the model structure hash value and the model weight hash value with a hyphen to form the model version fingerprint string.

[0119] Step S540: Write the model version fingerprint into the extended attribute field of the target model version tag, and jointly store the digest consistency comparison result and the model version fingerprint as a version binding integrity record. Associate the version binding integrity record with the registry record entry of the version binding snapshot in the version binding registry, so that the risk control service session corresponding to the version binding snapshot reads the version binding integrity record before scheduling the model version entity.

[0120] Add a key-value pair to the extended attribute field of the target model version tag structure, where the key is the model version fingerprint and the value is the model version fingerprint string generated in step S530. Create a version binding integrity record structure, containing a digest consistency comparison result field and a model version fingerprint field. After serializing the version binding integrity record, write it to the extended data area of ​​the corresponding registry record in the version binding registry. Before loading the model version entity in step S156, the risk control service session first reads the version binding integrity record from the extended data area of ​​the registry record to verify whether the digest consistency comparison result is consistent and whether the model version fingerprint matches the recalculated fingerprint of the model version entity to be loaded.

[0121] Step S610: Capture the state transition event of the binding lifecycle status flag of each registry record in the version binding registry changing from active binding state to expired binding state, parse the expired version binding snapshot from the expired registry record corresponding to the state transition event, and extract the expired risk feature solidified copy and expired model version tag from the expired version binding snapshot.

[0122] The event listener for the version-binding registry captures state transition events when the binding lifecycle state flag of a registry entry changes. When the state transition event indicates an active binding state before the change and an expired binding state after the change, the primary key of the expired registry entry is extracted from the event data of the state transition event. Using this primary key, the expired registry entry is retrieved from the version-binding registry. An expired version binding snapshot is parsed from the data payload, and a solidified copy of the expiration risk feature and an expired model version tag are extracted.

[0123] Step S620: Recalculate the summary verification value attached to the solidified copy of the expired risk feature to obtain the expired recalculated summary verification value. Compare the expired recalculated summary verification value with the summary verification value already attached to the solidified copy of the expired risk feature to obtain the expired summary consistency comparison result.

[0124] Perform the same digest verification value recalculation and comparison process as step S510 on the expired risk characteristic solidified copy to obtain the expired digest consistency comparison result.

[0125] Step S630: Deserialize the solidified copy of the expired risk characteristics to extract a structured container containing a metadata area and a payload area. Based on the topology recovery guidelines in the metadata area, extract the linearized sequence of expired account behavior trajectory and its associated topology attribute annotations, as well as the linearized sequence of expired transaction environment profile and its associated topology attribute annotations, from the payload area.

[0126] Perform the same parsing process as step S142 on the solidified copy of the expired risk characteristics to obtain the linearized sequence of the expired account behavior trajectory and its associated compressed feature vector of behavior flow, as well as the linearized sequence of the expired transaction environment profile and its associated compressed feature vector of environment association. The compressed feature vector of behavior flow and the compressed feature vector of environment association are the topological attribute annotations.

[0127] Step S640: Retrieve adjacent risk feature solidified copies within the adjacent time window corresponding to the expired risk feature solidified copies in the offline feature warehouse, and extract the linearized sequence of adjacent account behavior trajectory and the linearized sequence of adjacent transaction environment profile from the adjacent risk feature solidified copies.

[0128] Based on the generation timestamp of the risk control request identifier corresponding to the expired risk feature solidified copy, a time window Twindow is taken both forward and backward. Adjacent risk feature solidified copies whose generation timestamps fall within this time window are retrieved from the offline feature warehouse. From the retrieved adjacent risk feature solidified copies, the linearized sequence of adjacent account behavior trajectories and the linearized sequence of adjacent transaction environment profiles are parsed according to the process in step S142.

[0129] Step S650: Perform trajectory evolution comparison processing on the linearized sequence of expired account behavior trajectory and the linearized sequence of adjacent account behavior trajectory to generate an account behavior trajectory evolution offset record; perform environmental evolution comparison processing on the linearized sequence of expired transaction environment profile and the linearized sequence of adjacent transaction environment profile to generate a transaction environment trajectory evolution offset record; combine the account behavior trajectory evolution offset record and the transaction environment trajectory evolution offset record into a feature evolution offset record set.

[0130] The linearized sequence of expired account behavior trajectories is compared node-by-node with the linearized sequences of adjacent account behavior trajectories. The attribute value difference vector for each corresponding behavioral event node is calculated, containing three components: transaction amount difference, counterparty type change marker, and time interval difference. The difference vectors of all behavioral event nodes are arranged by node number to form an account behavior trajectory evolution offset record. Similarly, the linearized sequence of expired transaction environment profiles is compared node-by-node with the linearized sequences of adjacent transaction environment profiles. The attribute value difference vector for each corresponding environment entity node is calculated, containing two components: entity type change marker and entity value change amount. The difference vectors of all environment entity nodes are arranged by node number to form a transaction environment trajectory evolution offset record. The account behavior trajectory evolution offset record and the transaction environment trajectory evolution offset record are merged to form a feature evolution offset record set.

[0131] Step S660: Append the feature evolution offset record set and the consistency comparison result of the expired summary to the expired version binding snapshot, generate the expired binding evolution snapshot, write the expired binding evolution snapshot to the binding history archive storage partition, and establish a bidirectional traceability index with the expired registry record.

[0132] An expired binding evolution snapshot is constructed by appending a feature evolution offset record set field and an expired summary consistency comparison result field to the expired version binding snapshot structure. The expired binding evolution snapshot is then serialized and written to the next available storage page of the binding history archive storage partition. The address of this storage page is recorded in the archive pointer field of the expired registry record. Simultaneously, a reverse index is created for this expired binding evolution snapshot in the metadata area of ​​the binding history archive storage partition. The reverse index records the primary key of the expired registry record corresponding to this expired binding evolution snapshot, achieving bidirectional traceability indexing.

[0133] Step S710: In the version binding registry, filter the set of active registry entries whose binding lifecycle status is marked as active binding status, extract the active model version tag corresponding to each active registry entry in the active registry entry set, and obtain the storage path of the active model version entity through the address pointer of the active model version tag.

[0134] Iterate through all registry entries in the version binding registry, and filter out registry entries whose binding lifecycle status is marked as active in the lifecycle field, forming a set of active registry entries. For each active registry entry in the active registry entry set, parse the version binding snapshot from the data payload, extract the active model version tag, and read the storage path string of the active model version entity from the address field.

[0135] Step S720: Extract the solidified copy of the active risk feature corresponding to each active registry record in the active registry record set, and parse the linearized sequence of account behavior trajectory and the linearized sequence of transaction environment profile from the solidified copy of the active risk feature.

[0136] For each active registry record in the active registry record set, extract the solidified copy of the active risk characteristics from the version binding snapshot, and execute the parsing process of step S142 to obtain the linearized sequence of account behavior trajectory and the linearized sequence of transaction environment profile.

[0137] Step S730: Group the set of active registry records according to the storage path of the active model version entity to obtain a set of model version groups, with each model version group corresponding to an active model version entity.

[0138] Using the storage path string of the active model version entity as the grouping key, active registry entries with the same storage path in the active registry record set are grouped into the same model version group. After grouping, each model version group corresponds to a unique active model version entity.

[0139] Step S740: Extract distribution features from the linearized sequences of all account behavior trajectories within each model version group to generate account behavior distribution feature records. These records reflect the central tendency of the account behavior features carried by the active model version entity. Extract distribution features from the linearized sequences of all trading environment profiles within each model version group to generate trading environment distribution feature records. These records reflect the central tendency of the trading environment features carried by the active model version entity.

[0140] For the linearized sequences of all account behavior trajectories within the model version group, extract the mean and standard deviation of the transaction amount attribute for each behavior event node, the mode of the counterparty type attribute, and the mean and standard deviation of the time interval attribute. Summarize these statistics to form a record of account behavior distribution characteristics. For the linearized sequences of all transaction environment profiles within the model version group, extract the distribution frequency vector of the entity type attribute for each environment entity node, and extract the mean and standard deviation of the entity value attribute. Summarize these statistics to form a record of transaction environment distribution characteristics.

[0141] Step S750: Combine the account behavior distribution feature record and the transaction environment distribution feature record into a version carrying feature distribution record, and write the version carrying feature distribution record into the extended attribute field of the active model version tag. When the active model version entity triggers a version update operation, the version carrying feature distribution record is used as the decision reference input for the version update operation.

[0142] Account behavior distribution feature records and transaction environment distribution feature records are concatenated using a delimiter to form a version-carrying feature distribution record string. A new key-value pair is added to the extended attribute field of the active model version label, where the key is the version-carrying feature distribution and the value is the version-carrying feature distribution record string. When an active model version entity triggers a version update operation, the version update pipeline reads the version-carrying feature distribution record and uses it as a decision reference input for training or adjusting the configuration of the new version model.

[0143] Step S810: In the risk control model tag directory, extract adjacent model version tag pairs that have version compatibility related edges. The adjacent model version tag pairs contain the first model version tag and the second model version tag.

[0144] Traverse all model version tag chains in the risk control model tag directory. For adjacent model version tags in each chain, check if there is a version compatibility association edge between them. If a version compatibility association edge exists, extract the adjacent model version tags into an adjacent model version tag pair, denoted as the first model version tag and the second model version tag.

[0145] Step S820: Obtain the storage path of the first model version entity through the address pointer of the first model version tag, and obtain the storage path of the second model version entity through the address pointer of the second model version tag.

[0146] Extract the address pointer from the address field of the first model version tag and read the storage path of the first model version entity. Extract the address pointer from the address field of the second model version tag and read the storage path of the second model version entity.

[0147] Step S830: Retrieve the first set of registry entries that reference the first model version tag in the version binding registry, and retrieve the second set of registry entries that reference the second model version tag.

[0148] Perform a full table scan in the version-bound registry, filtering out registry records whose data load contains the first model version tag, forming the first set of registry records. Then, filter out registry records whose data load contains the second model version tag, forming the second set of registry records.

[0149] Step S840: Extract the first set of fixed copies of risk features from the first set of registry records, and extract the second set of fixed copies of risk features from the second set of registry records. Parse the first set of fixed copies of risk features into a set of linearized sequences of account behavior trajectories and a set of linearized sequences of the first transaction environment profile. Parse the second set of fixed copies of risk features into a set of linearized sequences of account behavior trajectories and a set of linearized sequences of the second transaction environment profile.

[0150] For each registry entry in the first registry record set, a version-bound snapshot is parsed from the data load, and a risk feature solidified copy is extracted to form a first risk feature solidified copy set. The same operation is performed on each registry entry in the second registry record set to form a second risk feature solidified copy set. The parsing process of step S142 is then executed on both risk feature solidified copy sets to obtain a first account behavior trajectory linearized sequence set, a first transaction environment profile linearized sequence set, a second account behavior trajectory linearized sequence set, and a second transaction environment profile linearized sequence set.

[0151] Step S850: Compare the distribution differences of the first set of linearized account behavior trajectories and the second set of linearized account behavior trajectories to generate account behavior distribution difference records. Compare the distribution differences of the first set of linearized transaction environment profiles and the second set of linearized transaction environment profiles to generate transaction environment distribution difference records. Combine the account behavior distribution difference records and the transaction environment distribution difference records into inter-version feature distribution difference records.

[0152] The distribution characteristics of the first and second linearized sequence sets of account behavior trajectories are calculated according to step S740. The differences between the corresponding statistics of the two distribution characteristics are calculated one by one to form an account behavior distribution difference record. Similarly, the distribution characteristics of the first and second linearized sequence sets of trading environment profiles are calculated according to step S740. The differences between the corresponding statistics of the two distribution characteristics are calculated one by one to form a trading environment distribution difference record. The account behavior distribution difference record and the trading environment distribution difference record are concatenated using a separator to form an inter-version feature distribution difference record.

[0153] Step S860: Record the difference in feature distribution between versions and write it into the version compatibility association edge between adjacent model version label pairs as the compatibility strength attribute of the version compatibility association edge.

[0154] Add a key-value pair to the attribute field of the version compatibility association edge structure. The key is the feature distribution difference, and the value is a string recording the feature distribution difference between versions. This string quantifies the degree of difference in the risk feature distribution carried by two adjacent model versions, serving as a reference attribute for measuring the strength of version compatibility.

[0155] Step S910: Receive the feature playback instruction and parse the playback risk control request identifier and playback risk control model identifier carried in the feature playback instruction.

[0156] Receive a feature replay instruction, which is a remote procedure call request. The request parameters include the replay risk control request identifier Rid_replay and the replay risk control model identifier Mid_replay.

[0157] Step S920: Using the playback risk control request identifier as the query key, retrieve the corresponding expired binding evolution snapshot in the binding history archive storage partition, and extract the expired risk feature solidified copy and expired model version tag from the expired binding evolution snapshot.

[0158] Using Rid_replay as the query key, a search is performed in the timeline index of the binding history archive storage partition to find expired binding evolution snapshots whose first prefix is ​​Rid_replay, and the snapshot with the latest timestamp is selected. From the retrieved expired binding evolution snapshots, a fixed copy of the expiration risk feature and an expired model version tag are extracted.

[0159] Step S930: Deinterleave the expired risk feature solidified copy to restore the linearized sequence of the replay account behavior trajectory and the linearized sequence of the replay transaction environment profile.

[0160] The analysis process of step S142 is performed on the solidified copy of the expired risk characteristics to restore the linearized sequence of the replay account behavior trajectory and the linearized sequence of the replay transaction environment profile.

[0161] Step S940: Using the replay risk control model identifier as the query key, retrieve the corresponding replay model version tag chain in the risk control model tag directory, extract the subsequent model version tag from the replay model version tag chain that is closest to the release time of the expired model version tag and whose release time is later than the expired model version tag, and obtain the storage path of the subsequent model version entity through the address pointer of the subsequent model version tag.

[0162] Using `Mid_replay` as the query key, retrieve the corresponding replay model version tag chain in the risk control model tag directory. Traverse the replay model version tag chain from the beginning, comparing the release time of each model version tag with the release time of expired model version tags. Filter out model version tags whose release time is later than the expired model version tag, and select the one with the smallest difference between its release time and the expired model version tag as the subsequent model version tag. Extract the address pointer from the address field of the subsequent model version tag and read the storage path of the subsequent model version entity.

[0163] Step S950: Load the subsequent model version entity from the storage path of the subsequent model version entity, input the linearized sequence of the replay account behavior trajectory and the linearized sequence of the replay transaction environment profile into the subsequent model version entity for risk inference, and obtain the feature replay risk inference result.

[0164] The subsequent model version entity is loaded according to the storage path. The linearized sequence of the replay account behavior trajectory and the linearized sequence of the replay transaction environment profile are input into the subsequent model version entity. The subsequent model version entity outputs the feature replay risk inference result.

[0165] Step S960: Associate the feature replay risk inference results with the expired binding evolution snapshot to obtain the feature replay binding record. Write the feature replay binding record to the binding history archive storage partition and update the bidirectional traceability index corresponding to the expired binding evolution snapshot.

[0166] Append a feature replay risk inference result field to the expired binding evolution snapshot structure to form a feature replay binding record. Serialize the feature replay binding record and write it to the binding history archive storage partition. Update the bidirectional traceability index corresponding to the expired binding evolution snapshot, and add a storage address entry for the feature replay binding record to the inverted index.

[0167] Step S1010: Write a timed polling signal for the binding lifecycle status flag to the version binding registry, receive the polling response triggered by the timed polling signal, and traverse all active registry entries in the version binding registry whose binding lifecycle status flag is active binding status.

[0168] During the initialization of the version binding registry, a timed polling timer is created with a period of Tscan. Upon expiration of the timer, a timed polling signal is sent to the management thread of the version binding registry. Upon receiving the polling signal, the management thread executes the polling response, iterating through all hash buckets in the version binding registry. For each registry entry in the collision chain of each hash bucket, its lifecycle field is read, and registry entries marked as having an active binding status are added to the list of active registry entries. After the iteration is complete, all active registry entries are obtained.

[0169] Step S1020: Extract the active model version tag from the currently polled active registry record, and obtain the storage path of the active model version entity through the address pointer of the active model version tag.

[0170] For each active registry entry in the active registry record list, parse the version binding snapshot from the data payload and extract the active model version tag structure from the target model version tag storage area. Extract the address pointer from the address field of the active model version tag structure, and read the storage path string of the active model version entity through the address pointer.

[0171] Step S1030: Search the risk control model tag directory for model version tag chains that belong to the same risk control model identifier as the active model version tag.

[0172] The risk control model identifier Mid_active is parsed from the binding triplet identifier of the active registry record. Using Mid_active as the lookup key, the corresponding model version tag chain is retrieved in the risk control model tag directory, and the head pointer of that model version tag chain is read.

[0173] Step S1040: Extract the latest model version tag from the model version tag chain whose release time is later than that of the active model version tag, and obtain the storage path of the latest model version entity through the address pointer of the latest model version tag.

[0174] Starting from the head node of the model version tag chain, traverse each model version tag, comparing the release time of each model version tag with the release time of the active model version tag. Filter out all model version tags whose release time is later than that of the active model version tag, and select the model version tag with the latest release time as the latest model version tag. Extract the address pointer from the address field of the latest model version tag, and read the storage path string of the latest model version entity.

[0175] Step S1050: Load the latest model version entity from the storage path of the latest model version entity, input the solidified copy of the active risk characteristics corresponding to the active registry record into the latest model version entity for risk inference, and obtain the migration pre-inference result.

[0176] Based on the storage path string of the latest model version entity, locate the serialized file of the model version entity in the file system, and call the model loader to deserialize the latest model version entity into an executable risk control model instance. Extract the solidified copy of active risk features from the version binding snapshot of active registry records, and parse the linearized sequence of account behavior trajectory and the linearized sequence of transaction environment profile according to the process in step S142. Input the linearized sequence of account behavior trajectory and the linearized sequence of transaction environment profile into the latest model version entity for risk inference, and the latest model version entity outputs the migration pre-inference result.

[0177] Step S1060: Compare the migration pre-inference results with the existing risk inference results in the active registry record, generate a version migration compatibility assessment record, write the version migration compatibility assessment record into the extended attribute field of the active registry record, and synchronize the version migration compatibility assessment record to the version compatibility association edge between the active model version tag and the latest model version tag in the model version tag chain.

[0178] Extract the risk inference result generated during the initial binding of the active registry entry from its version binding snapshot. This risk inference result is stored in the inference result field of the active registry entry. Compare the migration pre-inference result with the initial risk inference result by calculating the KL divergence value between the two probability distribution vectors; a smaller KL divergence value indicates better migration compatibility. Combine the KL divergence value and the migration pre-inference result to form a version migration compatibility assessment record. Write this version migration compatibility assessment record into the extended attribute field of the active registry entry. Simultaneously, locate the version compatibility association edge between the active model version label and the latest model version label in the model version label chain, and append the version migration compatibility assessment record to the attribute field of this version compatibility association edge.

[0179] Step S1110: Extract the binding triplet identifiers corresponding to all registry records in the version binding registry. Aggregate the binding triplet identifiers according to the risk control model identifier dimension they contain to obtain a model-dimensional binding snapshot aggregation set. Extract the risk feature solidified copy corresponding to each binding snapshot in the model-dimensional binding snapshot aggregation set. Parse the risk feature interleaved encoding string from the risk feature solidified copy. Deinterleave the risk feature interleaved encoding string to restore the linearized sequence of account behavior trajectory and the linearized sequence of transaction environment profile.

[0180] Traverse all registry entries in the version binding registry and parse the binding triplet identifier from the data payload of each registry entry. Extract the risk control model identifier field from the binding triplet identifier, and group binding triplet identifiers with the same risk control model identifier into the same model-dimensional binding snapshot aggregation set, using the risk control model identifier as the aggregation key. For each binding snapshot in the binding snapshot aggregation set, extract the version binding snapshot from the corresponding registry entry, and then extract the risk feature solidified copy from the version binding snapshot. Parse each risk feature solidified copy according to the process in step S142, and reconstruct the linearized sequence of account behavior trajectory and the linearized sequence of transaction environment profile from the risk feature encoding string.

[0181] Step S1120: Perform time-series splicing on all linearized sequences of account behavior trajectories within the same model-dimensional bound snapshot aggregation set to generate a long-range time-series sequence of account behavior in the model dimension. Perform time-series splicing on all linearized sequences of transaction environment profiles within the same model-dimensional bound snapshot aggregation set to generate a long-range time-series sequence of transaction environment in the model dimension.

[0182] The fixed copies of each risk feature within the bound snapshot aggregation set are arranged in ascending order according to the generation timestamp of their corresponding risk control request identifier. The linearized sequence of account behavior trajectory for each fixed copy of the risk feature is extracted sequentially according to the arrangement order. The timestamp attribute of the first behavioral event node of the subsequent sequence is compared with the timestamp attribute of the last behavioral event node of the previous sequence, and the time difference is calculated as the splicing interval. The subsequent sequence is spliced ​​to the end of the previous sequence, and the spliced ​​sequence is the long-term time-series sequence of account behavior. The linearized sequence of the trading environment profile is processed in the same arrangement order and splicing method to generate the long-term time-series sequence of the trading environment.

[0183] Step S1130: Extract the model version tag corresponding to each bound snapshot in the bound snapshot aggregation set of the model dimension, sort the model version tags by release time to obtain the model version evolution sequence, and establish a mapping relationship between each model version tag in the model version evolution sequence and the corresponding time period subsequence of account behavior in the long-term time series sequence of account behavior.

[0184] Extract model version tags from the registry entries corresponding to each bound snapshot in the bound snapshot aggregation set. Sort the model version tags in ascending order of their release time to obtain the model version evolution sequence. For two adjacent model version tags in the model version evolution sequence, take the release time of the previous model version tag as the start time and the release time of the next model version tag as the end time. Extract a continuous subsequence from the long-term time sequence of account behavior events whose timestamp attributes fall within this time interval. This subsequence is taken as the account behavior subsequence corresponding to the previous model version tag among the two adjacent model version tags. Establish a key-value mapping relationship between each model version tag and its corresponding account behavior subsequence.

[0185] Step S1140: Establish a mapping relationship between each model version label in the model version evolution sequence and the corresponding time period subsequence of the trading environment in the long-term time series sequence of the trading environment.

[0186] Using the same time interval extraction method as step S1130, extract continuous subsequences of environmental entity nodes whose timestamp attributes fall within the corresponding time interval from the long-term time series of the transaction environment, and establish a key-value mapping relationship with the corresponding model version label.

[0187] Step S1150: Associate the mapping relationship with the corresponding risk reasoning result, generate an association mapping record between version evolution and feature time series, and write the association mapping record between version evolution and feature time series into the extended storage partition of the version binding registry.

[0188] Risk inference results are extracted from the registry entries corresponding to each bound snapshot. The model version evolution sequence, account behavior sub-sequence mapping relationship, transaction environment sub-sequence mapping relationship, and risk inference results are combined into a correlation mapping record between version evolution and feature time series. This record is then serialized and written to the extended storage partition of the version-bound registry. The extended storage partition is an independent physical storage area within the version-bound registry, stored in append-only mode.

[0189] Step S1160: When the new version model is deployed online, the long-term time series of account behavior and the long-term time series of the transaction environment are recorded and replayed according to the correlation mapping between version evolution and feature time series, as the backtracking verification input of the new version model.

[0190] When a new version model is deployed and goes live, triggering a new version release event, the association mapping record between version evolution and feature time series is read from the extended storage partition of the version-bound registry. Long-term time series sequences of account behavior and trading environment are extracted from these sequences. These two long-term time series sequences are used as backtesting inputs for the new version model. Batch risk inference is performed on the new version model, and the batch inference results output by the new version model are compared with the historical risk inference results recorded in the association mapping record to generate a backtesting verification report for the new version model.

[0191] Step S1210: Receive the binding relationship splitting instruction and parse the risk control request identifier to be split and the splitting strategy parameters carried in the binding relationship splitting instruction.

[0192] The system receives a binding relationship splitting instruction, which is a remote procedure call request. The request parameters include the risk control request identifier "Rid_split" to be split and the splitting strategy parameter. The splitting strategy parameter is an enumeration value, which can be either splitting by behavior event node or splitting by time window.

[0193] Step S1220: Using the risk control request identifier to be split as the query key, retrieve the corresponding registry record to be split in the version binding registry.

[0194] Using Rid_split as the query key, perform a prefix scan query in the version binding registry to find registry entries in the binding triplet identifier that have Rid_split as the first prefix as the registry entries to be split.

[0195] Step S1230: Parse the version binding snapshot to be split from the registry record to be split, and extract the original risk feature solidified copy and the original model version tag from the version binding snapshot.

[0196] Parse the version binding snapshot from the data load of the registry record to be split, extract the original risk feature solidified copy from the target risk feature solidified copy storage area, and extract the original model version tag from the target model version tag storage area.

[0197] Step S1240: Parse the risk feature interleaved encoding string from the original risk feature solidified copy, deinterleave the risk feature interleaved encoding string, and restore the linearized sequence of account behavior trajectory and the linearized sequence of transaction environment profile.

[0198] The original risk characteristics are fixed copies are analyzed according to the process in step S142 to restore the linearized sequence of account behavior trajectory and the linearized sequence of transaction environment profile.

[0199] Step S1250: Segment the linearized sequence of account behavior trajectories, dividing it into multiple sub-sequences based on the inflection points of the out-degree sequence changes of the behavior event nodes. Segment the linearized sequence of the transaction environment profile, dividing it into multiple sub-sequences based on the inflection points of the adjacency matrix changes of the environment entity nodes.

[0200] Extract the out-degree value of each behavioral event node from the linearized sequence of account behavior trajectories, and arrange them into an out-degree sequence in sequence order. Calculate the first-order difference between two adjacent out-degree values ​​in the out-degree sequence. If the absolute value of the first-order difference exceeds a preset inflection point threshold, mark that position as an out-degree change inflection point. Segment the linearized sequence of account behavior trajectories at the out-degree change inflection points to obtain multiple account behavior trajectory sub-sequence segments. Extract the adjacency density value of each environment entity node from the linearized sequence of trading environment profiles. The adjacency density value is the number of non-zero elements in the corresponding row of the adjacency matrix for that environment entity node. Arrange them into an adjacency density sequence in sequence order, and calculate the first-order difference between two adjacent values ​​in the adjacency density sequence. If the absolute value of the first-order difference exceeds a preset inflection point threshold, mark that position as an adjacency matrix change inflection point. Segment the linearized sequence of trading environment profiles at the adjacency matrix change inflection points to obtain multiple trading environment profile sub-sequence segments.

[0201] Step S1260: Recombine the multiple account behavior trajectory sub-sequence segments and multiple transaction environment profile sub-sequence segments obtained by segmentation according to the time sequence correspondence to obtain multiple sub-feature combination pairs, generate a sub-binding identifier for each sub-feature combination pair, and encapsulate each sub-feature combination pair with the original model version label to form a sub-version binding snapshot.

[0202] The account behavior trajectory sub-segments and the transaction environment profile sub-segments are arranged in ascending order of their start timestamps. Account behavior trajectory sub-segments with overlapping timestamps are paired with transaction environment profile sub-segments to form sub-feature combination pairs. A sub-binding identifier is generated for each sub-feature combination pair; the sub-binding identifier is the concatenation of the Rid_split sub-feature combination pair number. The account behavior trajectory sub-segments and transaction environment profile sub-segments in the sub-feature combination pair are encapsulated into a sub-graph structure feature package as described in step S117. The sub-graph structure feature package and the original model version label are then encapsulated into a sub-version binding snapshot.

[0203] Step S1270: Write the sub-version binding snapshots into the version binding registry respectively, and mark the registry record to be split in the version binding registry as split, and establish the split tracing association between the registry record to be split and each sub-version binding snapshot.

[0204] For each sub-version bound snapshot, write it to the version binding registry according to the process in step S150, generating a corresponding sub-registry record. Set the split status flag bit in the lifecycle field of the registry record to be split from 0 to 1, indicating that it has been split. Write the primary key list of the sub-registry record to the extended attribute field of the registry record to be split, forming a forward pointer to the split tracing association. Write the primary key of the registry record to be split to the extended attribute field of each sub-registry record, forming a reverse pointer to the split tracing association.

[0205] Step S1310: Extract all active registry records marked as active binding status in the version binding registry, construct an active binding snapshot set, parse the risk feature solidified copy corresponding to each active binding snapshot in the active binding snapshot set, and extract the linearized sequence of account behavior trajectory and the linearized sequence of transaction environment profile.

[0206] The version binding registry is traversed in the manner described in step S1010, and all active registry records are filtered out. For each active registry record, a version binding snapshot is parsed from its data payload. A fixed copy of the risk characteristics is extracted from the version binding snapshot, and the linearized sequence of account behavior trajectory and the linearized sequence of transaction environment profile are parsed according to the process in step S142. All parsing results, together with the primary key of the corresponding active registry record, constitute the active binding snapshot set.

[0207] Step S1320: Extract the model version tag corresponding to each active binding snapshot in the active binding snapshot set, and obtain the storage path of the model version entity through the address pointer of the model version tag.

[0208] Extract the model version tag from the version binding snapshot corresponding to each active binding snapshot, extract the address pointer from the address field, and read the storage path string of the model version entity.

[0209] Step S1330: Load the model version entity from the storage path of the model version entity, input the corresponding linearized sequence of account behavior trajectory and the linearized sequence of transaction environment profile into the model version entity for risk reasoning, and obtain the risk reasoning result of the current period.

[0210] For each active bound snapshot, load the corresponding model version entity according to the storage path, input the linearized sequence of account behavior trajectory and the linearized sequence of transaction environment profile into the model version entity, and the model version entity outputs the risk inference result of the current period.

[0211] Step S1340: Extract the historical risk reasoning results of each active binding snapshot in the active binding snapshot set within the previous lifecycle period.

[0212] The risk inference result stored during step S1330 of the previous timed polling cycle is read from the inference result field of the active registry record corresponding to each active binding snapshot, and used as the historical risk inference result. If the active registry record is being polled for the first time, the historical risk inference result is null.

[0213] Step S1350: Compare the current period risk inference result with the historical risk inference result to generate a risk inference result offset record. Aggregate all risk inference result offset records corresponding to the same model version label to generate a version risk offset aggregate record corresponding to the model version label.

[0214] For each active binding snapshot where historical risk inference results are not empty, calculate the JS divergence value between the probability distribution vector of the current period's risk inference results and the probability distribution vector of the historical risk inference results. The JS divergence value quantifies the degree of offset between the two probability distributions. Combine the JS divergence value with the primary key of the active registry record to form a risk inference result offset record. Using the model version tag as the aggregation key, group all risk inference result offset records with the same model version tag into the same group. Calculate the mean and standard deviation of all JS divergence values ​​within the group to form a version risk offset aggregate record.

[0215] Step S1360: Perform a horizontal comparison of the version risk offset aggregation records corresponding to different model version tags to generate inter-version risk offset difference records, and write the inter-version risk offset difference records into the extended attribute fields of the corresponding model version tags in the risk control model tag directory.

[0216] For any two distinct model version labels, subtract the absolute values ​​of their version risk offset aggregation records to obtain the inter-version risk offset difference value. Arrange the inter-version risk offset difference values ​​of all pairwise model version label pairs into a difference matrix, and take the average of the rows in this matrix to obtain the average offset difference value of each model version label relative to all other model version labels. Write the average offset difference value into the extended attribute field of the corresponding model version label, with the key being the inter-version risk offset difference.

[0217] Step S1370: When the risk offset difference record between versions triggers the preset offset condition, a version switch warning signal is sent to the risk control service session through the corresponding active registry record in the version binding registry.

[0218] When the average offset difference value in the risk offset difference record between versions of a certain model version tag exceeds a preset offset threshold, a preset offset condition is triggered. The system searches the version binding registry for all active registry entries referencing that model version tag and sends a version switch warning signal to the risk control service session corresponding to these active registry entries. The version switch warning signal contains the risk control model identifier, version number, and average offset difference value of that model version tag.

[0219] Step S1410: In the risk control model tag directory, establish a version evolution branch for the model version tag chain corresponding to each risk control model identifier. The version evolution branch takes the first model version tag in the model version tag chain as the root node.

[0220] For each risk control model identifier in the risk control model tag directory, a version evolution branch tree is constructed starting from its head node, with the first model version tag as the root node. Each node in the version evolution branch tree stores the address of a model version tag. The root node of the tree is the first model version tag in the model version tag chain. Initially, there is only one main branch under the root node of the tree, and the nodes on the main branch are arranged in the order of the model version tag chain.

[0221] Step S1420: Capture the branch version release event generated by the risk control model version release message stream, and extract the parent version number and the new branch version number from the branch version release event.

[0222] Subscribe to event messages of type "Branch Version Release" in the risk control model version release message stream. When a branch version release event is captured, parse the event message body and extract the parent version number Vparent and the new branch version number Vbranch. The parent version number is the direct upstream version number of the branch version, and the new branch version number is the branch version number of this release.

[0223] Step S1430: Locate the parent model version label corresponding to the parent version number in the model version label chain, create a branch association edge on the version compatibility association edge of the parent model version label, generate a branch model version label for the new branch version number, and attach the branch model version label to the end of the branch association edge.

[0224] Traverse the model version tag chain to find the model version tag with a version number equal to Vparent, and use it as the parent model version tag. Add a new branch association edge to the version compatibility association edge list of the parent model version tag. Mark the type of the branch association edge as a branch edge to distinguish it from the regular version compatibility association edge. Generate a branch model version tag for the new branch version number Vbranch as in step S134, and attach the branch model version tag to the end of the branch association edge.

[0225] Step S1440: Establish an address pointer for the corresponding branch model version entity for the branch model version tag, and retrieve the set of all parent registry records that reference the parent model version tag in the version binding registry.

[0226] Extract the address pointer from the address field of the branch model version tag, and read the storage path string of the branch model version entity through the address pointer. Perform a full table scan in the version binding registry, and filter out registry records whose data payload contains the parent model version tag to form the parent registry record set.

[0227] Step S1450: Perform branch copying on each parent registry entry in the parent registry record set to generate a branch registry entry, and replace the model version label in the branch registry entry with the branch model version label.

[0228] For each parent registry entry in the parent registry record set, make a complete copy of the byte stream of its data payload field. Locate the model version tag storage area within the copied byte stream and replace the parent model version tag structure with the branch model version tag structure. Simultaneously, modify the model version tag portion of the binding triplet identifier, replacing the parent model version tag with the branch model version tag. The modified byte stream constitutes the data payload of the branch registry entry.

[0229] Step S1460: Write the branch registry entry to the version binding registry and set the binding lifecycle status flag of the branch registry entry to active binding status.

[0230] Following the process from steps S151 to S153, the branch registry record is written to the version binding registry, and the binding lifecycle status flag is set to active binding status.

[0231] Step S1470: Establish a branch tracing association edge between the branch registry entry and the parent registry entry.

[0232] The primary key list of the branch registry entry is appended to the extended attribute field of the parent registry entry, and the primary key of the parent registry entry is written to the extended attribute field of the branch registry entry. The two form a branch tracing association edge.

[0233] Step S1480: When the risk control service session initiates an online risk inference request, the online risk inference request is simultaneously distributed to the parent model version entity corresponding to the parent registry record and the branch model version entity corresponding to the branch registry record based on the branch tracing association edge, so as to obtain a dual-path risk inference result.

[0234] In the processing flow of steps S154 to S156, after parsing the version binding snapshot from the parent registry record, the risk control service session additionally checks whether the extended attribute field of the parent registry record contains the primary key list of the branch registry record. If it exists, the primary key of each branch registry record is read one by one along the branch tracing association edge, each branch registry record is retrieved in the version binding registry, the version binding snapshot is parsed from each branch registry record, and the branch model version entity is loaded. The same risk feature solidified copies are input into the parent model version entity and each branch model version entity respectively to obtain the dual-path risk inference result.

[0235] Step S1510: Extract a solidified copy of the target risk feature from the offline feature warehouse, parse the risk feature interleaved encoding string from the solidified copy of the target risk feature, perform deinterleaving processing on the risk feature interleaved encoding string, and restore the linearized sequence of account behavior trajectory and the linearized sequence of transaction environment profile.

[0236] The solidified copy of the target risk characteristics is analyzed according to the process in step S142 to restore the linearized sequence of account behavior trajectory and the linearized sequence of transaction environment profile.

[0237] Step S1520: Parse the topological attribute annotations of the directed graph of account behavior trajectory from the structured container of the target risk feature solidified copy, and extract the behavior flow feature vectors corresponding to each behavior event node to calculate their in-degree ratio. Parse the topological attribute annotations of the topological graph of the trading environment profile, and extract the environment association feature vectors corresponding to each environment entity node to calculate their adjacency density value. Use the in-degree ratio and adjacency density value as independent numerical features, and map them back to the corresponding node positions in the linearized sequence of account behavior trajectory and the linearized sequence of trading environment profile, respectively.

[0238] Extracting the behavior flow compressed feature vector from the structured container of the target risk feature solidified copy according to the parsing process in step S142, and restoring it to the behavior flow feature vector through inverse principal component analysis. Extracting the out-degree and in-degree values ​​of each behavior event node from the behavior flow feature vector, calculating the out-degree / in-degree ratio (out-degree divided by in-degree), with the ratio set to a preset maximum if the in-degree is zero. Restoring the environment association compressed feature vector to the environment association feature vector through inverse principal component analysis, calculating the adjacency density value of each environment entity node from the adjacency matrix expansion of the environment association feature vector (the sum of the element values ​​in the row of the environment entity node divided by the total number of columns). Adding the out-degree / in-degree ratio of each behavior event node as a numerical attribute to the corresponding behavior event node's attribute list in the account behavior trajectory linearization sequence. Adding the adjacency density value of each environment entity node as a numerical attribute to the corresponding environment entity node's attribute list in the transaction environment profile linearization sequence.

[0239] Step S1530: Compare the in-degree ratio of each behavior event node with a preset in-degree ratio threshold, and mark the behavior event nodes whose in-degree ratio exceeds the preset in-degree ratio threshold as behavior mutation nodes.

[0240] Iterate through each behavior event node in the linearized sequence of account behavior trajectories, read its in-degree ratio, and calculate the absolute value of the difference between the in-degree ratio and a preset in-degree ratio threshold. If the absolute value is greater than zero, mark the behavior event node as a behavior mutation node and record its deviation direction exceeding the threshold. If the in-degree ratio is greater than the preset in-degree ratio threshold, the deviation direction is positive; otherwise, it is negative.

[0241] Step S1540: Compare the adjacency density value of each environmental entity node with the preset adjacency density threshold, mark the environmental entity nodes whose adjacency density value exceeds the preset adjacency density threshold as environmental mutation nodes, extract the temporal position information of the behavioral mutation nodes in the linearized sequence of account behavior trajectory as behavioral mutation temporal points, and extract the temporal position information of the environmental mutation nodes in the linearized sequence of transaction environment profile as environmental mutation temporal points.

[0242] For each environmental entity node in the linearized sequence of the trading environment profile, traverse it and read its adjacency density value. Calculate the absolute value of the difference between the adjacency density value and a preset adjacency density threshold. If the absolute value is greater than zero, mark the environmental entity node as an environmental mutation node. For each behavioral mutation node, extract its sorting sequence number in the linearized sequence of account behavior trajectory as the behavioral mutation time-series point. For each environmental mutation node, extract its sorting sequence number in the linearized sequence of the trading environment profile as the environmental mutation time-series point.

[0243] Step S1550: Align the behavioral mutation time series points and the environmental mutation time series points according to the time series to generate a feature mutation time series point sequence. Write the feature mutation time series point sequence into the extended attribute field of the version-bound snapshot as the feature mutation anchor point of the risk control service session corresponding to the version-bound snapshot when the model version is switched.

[0244] All behavioral mutation time-series points and all environmental mutation time-series points are sorted in ascending order according to their respective sorting numbers and merged into a single feature mutation time-series point sequence. Each element contains a mutation type marker and a sorting number. This feature mutation time-series point sequence is serialized and written to an extended attribute field of the version-bound snapshot, with the key being the feature mutation anchor point. When the risk control service session corresponding to the version-bound snapshot needs to switch models, the feature mutation anchor point is read, and the model version switch is performed near the time point marked in the feature mutation time-series point sequence, ensuring that the model version switch occurs at a node where the risk feature distribution changes significantly.

[0245] Furthermore, an online feature-model version binding system for model services provided in this application embodiment includes a processor and a memory. The processor and memory are connected, for example, via a bus. Optionally, the online feature-model version binding system for model services may further include a transceiver, which can be used for data interaction between this online feature-model version binding system and other online feature-model version binding systems for model services, such as sending and / or receiving data. It should be noted that in actual scheduling, the transceiver is not limited to one, and the structure of this online feature-model version binding system for model services does not constitute a limitation on the embodiments of this application.

[0246] The memory stores program code for executing the embodiments of this application, and its execution is controlled by a processor. The processor executes the program code stored in the memory to implement the steps shown in the foregoing method embodiments.

[0247] The above description is only an optional implementation method for some implementation scenarios of this application. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this application, without departing from the technical concept of this application, also fall within the protection scope of the embodiments of this application.

Claims

1. A method for binding online features to model versions in model services, characterized in that, The method includes: Construct a risk feature aggregation container, write a risk control request identifier into the risk feature aggregation container, and write an online risk feature set corresponding to the risk control request identifier into the risk feature aggregation container; Perform a feature solidification operation on the risk feature aggregation container to generate a solidified copy of the risk feature bound to the risk control request identifier, and synchronize the solidified copy of the risk feature to the offline feature repository; Construct a risk control model tag directory, write a risk control model identifier into the risk control model tag directory, and write a model version tag chain corresponding to the risk control model identifier into the risk control model tag directory. Each model version tag in the model version tag chain points to a model version entity. Extract a solidified copy of the target risk feature corresponding to the target risk control request identifier from the offline feature repository, and extract the target model version tag corresponding to the target risk control model identifier from the risk control model tag directory. Encapsulate the solidified copy of the target risk feature and the target model version tag into a version-bound snapshot. Write the version binding snapshot to the version binding registry so that the risk control service session corresponding to the version binding snapshot can only schedule the model version entity corresponding to the target risk control model identifier to perform online risk inference through the target model version tag.

2. The online feature and model version binding method applied to model services according to claim 1, characterized in that, The process of constructing a risk feature aggregation container, writing a risk control request identifier into the risk feature aggregation container, and writing an online risk feature set corresponding to the risk control request identifier into the risk feature aggregation container includes: Receive a risk control service request, parse the request header of the risk control service request, extract the risk control request identifier corresponding to the risk control service request, and extract the risk control scenario type tag corresponding to the risk control service request; Within the risk feature aggregation container, an aggregation storage unit is created with the risk control request identifier as the primary key and the risk control scenario type label as the partition key. The aggregation storage unit has a graph storage structure that carries multi-dimensional risk feature fields. Parse the request body of the risk control service request and extract the original risk feature set carried by the risk control service request. The original risk feature set includes account behavior attribute fields and transaction environment attribute fields. The account behavior attribute fields are processed to restore the behavior trajectory, and a directed graph of account behavior trajectory is generated. The directed graph of account behavior trajectory has behavior events as nodes and the temporal jump relationship between behavior events as edges. The transaction environment attribute fields are reconstructed to generate a transaction environment profile topology graph, which uses environmental entities as nodes and the relationships between environmental entities as edges. Write the directed graph of the account behavior trajectory into the account behavior attribute sub-partition of the aggregation storage unit, and write the transaction environment profile topology graph into the transaction environment attribute sub-partition of the aggregation storage unit; The out-degree and in-degree sequences of each behavioral event node in the directed graph of account behavior trajectory are extracted as behavioral flow feature vectors. The adjacency matrix of each environmental entity node in the topological graph of transaction environment profile is extracted as an environmental association feature vector. The behavioral flow feature vector and the environmental association feature vector are used as topological attribute labels for the directed graph of account behavior trajectory and the topological graph of transaction environment profile, and are respectively attached to the corresponding graph node or edge attribute. The directed graph of account behavior trajectory, the topological graph of transaction environment profile, and their associated attribute labels are encapsulated into a graph structure feature package. This graph structure feature package constitutes an online risk feature set corresponding to the risk control request identifier.

3. The online feature and model version binding method applied to model services according to claim 1, characterized in that, The step of performing a feature solidification operation on the risk feature aggregation container to generate a solidified copy of the risk feature bound to the risk control request identifier, and synchronizing the solidified copy of the risk feature to the offline feature repository, includes: Capture the termination status signal of the risk control service session corresponding to the risk control request identifier, and apply a write lock to the aggregation storage unit corresponding to the risk control request identifier based on the termination status signal; After the write lock takes effect, topological sorting is performed on the directed graph of account behavior trajectories stored in the aggregation storage unit to generate a linearized sequence of account behavior trajectories. Topological sorting is performed on the topological graph of transaction environment profiles stored in the aggregation storage unit to generate a linearized sequence of transaction environment profiles. Dimensional compression is performed on the behavior flow feature vectors stored in the aggregation storage unit to generate behavior flow compressed feature vectors. Dimensional compression is performed on the environment association feature vectors stored in the aggregation storage unit to generate environment association compressed feature vectors. A structured container containing a metadata area and a payload area is constructed. The linearized sequence of the account behavior trajectory and the compressed feature vector of the behavior flow are stored as the first set of structured data blocks in the payload area. The linearized sequence of the transaction environment profile and the compressed feature vector of the environment association are stored as the second set of structured data blocks in the payload area. The adjacency index of the directed graph of the account behavior trajectory and the topology graph of the transaction environment profile are stored as topology recovery guidance in the metadata area. The entire content of the structured container is serialized and encoded to generate a risk feature encoding string. The digest verification value of the risk control request identifier is appended to the encoding string to generate a fixed copy of the risk feature. The fixed copy of the risk feature is synchronized from the risk feature aggregation container to the offline feature warehouse. After the synchronization is completed, the write lock of the aggregation storage unit is released.

4. The online feature and model version binding method applied to model services according to claim 1, characterized in that, The process of constructing a risk control model tag directory, writing risk control model identifiers into the risk control model tag directory, and writing a model version tag chain corresponding to the risk control model identifiers into the risk control model tag directory includes: A unique risk control model identifier is generated for each deployed risk control model instance, and the risk control scenario type tag corresponding to the risk control model instance is extracted; In the risk control model tag directory, establish a multi-level master index node for the risk control model identifier, with the risk control scenario type tag as the index dimension; Subscribe to the risk control model version release message stream. When the risk control model version release message stream generates a new version release event, extract the risk control model identifier, new version number, and version compatibility description information from the new version release event. The new version number is tagged and encoded to generate a model version tag, and the version compatibility description information is embedded into the extended attribute field of the model version tag; Associate the model version tag with the storage path of the model version entity corresponding to the new version number to obtain a version association record, and write the version association record to the end of the model version tag chain corresponding to the risk control model identifier in the risk control model tag directory; For each model version tag in the model version tag chain, an address pointer is established pointing to the corresponding model version entity, and version compatibility association edges are established between adjacent model version tags based on the version compatibility description information.

5. The online feature and model version binding method applied to model services according to claim 3, characterized in that, The step of extracting a fixed copy of the target risk feature corresponding to the target risk control request identifier from the offline feature repository, and extracting the target model version tag corresponding to the target risk control model identifier from the risk control model tag directory, and encapsulating the fixed copy of the target risk feature and the target model version tag into a version-bound snapshot includes: Receive a version binding instruction, parse the target risk control request identifier and target risk control model identifier carried in the version binding instruction, use the target risk control request identifier as the query key to search in the offline feature warehouse, and extract a solidified copy of the target risk feature corresponding to the target risk control request identifier; The serialized structured container is parsed from the solidified copy of the target risk features. Based on the boundaries and indexes defined in the metadata area, a first set of structured data blocks and a second set of structured data blocks are separated. From the first set of structured data blocks, the linearized sequence of account behavior trajectory and the corresponding behavior flow compressed feature vector are extracted. From the second set of structured data blocks, the linearized sequence of transaction environment profile and the corresponding environment association compressed feature vector are extracted. The hierarchical relationship between features is reconstructed based on the topology recovery guide. Using the target risk control model identifier as the query key, a search is performed in the risk control model tag directory to extract the model version tag chain corresponding to the target risk control model identifier, and the model version tag with the latest release time is extracted from the model version tag chain as the target model version tag. The storage path of the model version entity pointed to by the target model version tag is obtained through the address pointer of the target model version tag, and the version compatibility description information of the target model version tag is read. Create a binding snapshot instance, write the solidified copy of the target risk feature and the target model version tag into the binding snapshot instance, and attach a binding triplet identifier composed of the target risk control request identifier, the target risk control model identifier and the target model version tag to the binding snapshot instance to obtain the version binding snapshot.

6. The online feature and model version binding method applied to model services according to claim 1, characterized in that, The step of writing the version binding snapshot to the version binding registry, so that the risk control service session corresponding to the version binding snapshot only schedules the model version entity corresponding to the target risk control model identifier for online risk inference through the target model version tag, includes: Create a registry record in the version binding registry with the binding triple identifier as the primary key; The data payload of the version-bound snapshot is serialized into a registry record and written to the registry record; Set the binding lifecycle status flag to active binding state for the registry record, and synchronize the binding lifecycle status flag with the version compatibility association edge in the model version tag chain corresponding to the target risk control model identifier; When the risk control service session initiates an online risk reasoning request, the current risk control request identifier is extracted from the online risk reasoning request, and the current risk control request identifier is used as the query key to retrieve the corresponding current registry record in the version binding registry. Parse the version binding snapshot from the current registry record, extract the target model version tag from the version binding snapshot, and locate the storage path of the model version entity corresponding to the target risk control model identifier through the address pointer of the target model version tag; The model version entity is loaded from the storage path of the model version entity, and a solidified copy of the target risk feature in the version-bound snapshot is input into the model version entity for online risk reasoning to obtain the risk reasoning result.

7. The online feature-model version binding method applied to model services according to claim 1, characterized in that, After writing the version binding snapshot to the version binding registry, the method further includes: Monitor the binding lifecycle status flag of each registry record in the version binding registry. When the binding lifecycle status flag of the target registry record changes from active binding status to expired binding status, parse the corresponding expired version binding snapshot from the target registry record. Extract the expired target model version tag from the expired version binding snapshot, and obtain the storage path of the expired model version entity through the address pointer of the expired target model version tag; Extract a solidified copy of the expired target risk feature from the expired version binding snapshot, input the solidified copy of the expired target risk feature into the expired model version entity for offline risk backtracking reasoning, and generate risk backtracking reasoning results; The risk backtracking reasoning result is associated with the original registry record entry in the version binding registry of the expired version binding snapshot and stored to obtain the backtracking binding record. The target registry record entry is deleted in the version binding registry and the backtracking binding record is migrated to the binding history archive storage partition. A timeline index is created for the backtracking binding records in the historical archive storage partition. The timeline index organizes the retrieval path of the backtracking binding records with the binding triplet identifier in the expired version binding snapshot as the dimension.

8. The online feature-model version binding method applied to model services according to claim 1, characterized in that, After writing the version binding snapshot to the version binding registry, the method further includes: Receive a binding relationship query request, parse the query risk control request identifier carried in the binding relationship query request, and use the query risk control request identifier as the query key to retrieve the corresponding query registry record in the version binding registry; Parse the version binding snapshot from the query registry record, and extract the query model version tag from the version binding snapshot; By using the version compatibility association edge of the query model version tag, we can trace upstream to obtain a set of upstream model version tags that are compatible with the query model version tag, and by using the version compatibility association edge of the query model version tag, we can trace downstream to obtain a set of downstream model version tags that are compatible with the query model version tag. The query model version tag, the upstream model version tag set, and the downstream model version tag set are combined into a version compatibility tracing link. The version compatibility tracing link is associated with the version binding snapshot corresponding to the query risk control request identifier to generate a binding relationship tracing result. The binding relationship tracing result is returned, enabling the risk control service session corresponding to the query risk control request identifier to compare risk inference results among multiple compatible model version entities along the version compatibility tracing link.

9. The online feature and model version binding method applied to model services according to claim 1, characterized in that, After constructing the risk control model tag directory, writing risk control model identifiers to the risk control model tag directory, and writing the model version tag chain corresponding to the risk control model identifiers to the risk control model tag directory, the process further includes: Receive the model version rollback instruction and parse the rollback risk control model identifier and target rollback version number carried in the model version rollback instruction; Using the rollback risk control model identifier as the query key, the corresponding current model version tag chain is retrieved in the risk control model tag directory. Each model version tag in the current model version tag chain is traversed, and the version number corresponding to each model version tag is extracted. The extracted version number is compared with the target rollback version number to locate the target rollback model version tag. The storage path of the target rollback model version entity is obtained through the address pointer of the target rollback model version tag, and the target rollback model version entity is loaded from the storage path of the target rollback model version entity. In the version binding registry, retrieve all registry entries that reference the model version tag chain corresponding to the rollback risk control model identifier and whose release time is later than the target rollback version number. Perform a version tag replacement operation on the retrieved registry entries, replace the model version tag in the registry entries with the target rollback model version tag, and update the version compatibility association edge pointing to the registry entries. After the registry entries are replaced, they are rewritten into the version-bound registry, so that subsequent risk control service sessions can schedule the target rollback model version entity to perform online risk reasoning through the target rollback model version tag.

10. An online feature-model version binding system for model services, characterized in that, The method includes a processor and a computer-readable storage medium storing machine-executable instructions that, when executed by the processor, implement the online feature-model version binding method for a model service as described in any one of claims 1-9.

Images