Service verification method and device, storage medium and electronic equipment

Abstract

The embodiment of the invention discloses a service verification method and device, a storage medium and electronic device.The method comprises the steps that a verification control instruction input by a user side to a service simulation console is received, and the verification control instruction comprises a target decision service model of verification decision service and a target data source configuration simulation mode; in response to the target data source, configuring a simulation mode, automatically constructing a standard feature input set through a feature data channel, determining a target simulation execution engine, and calling the target simulation execution engine with the same architecture as an online platform service environment, according to the standard feature input set, loading the standard feature input set into the target decision service model for operation to obtain a simulation execution result, calling a service index calculation engine to perform index operation on the simulation execution result, and generating quantitative verification analysis data for the verification decision service. By adopting the embodiment of the invention, the verification efficiency and accuracy of the decision service model can be improved.

Description

TECHNICAL FIELD

[0001] The present specification relates to the technical field of computer technology, and in particular, to a service verification method and device, a storage medium, and an electronic device. BACKGROUND

[0002] In mass service platform data processing and online service platform systems, in order to respond to dynamically changing platform business service needs and provide better services for platform users, the decision service model of the core bearing platform decision service logic (such as a service rule engine, a service recommendation algorithm, or a service logic judgment model) needs to be frequently iterated and upgraded. In order to ensure the stability of the platform service, before deploying a new decision service model to the online production environment of the service platform, it is usually necessary to simulate and verify its processing effect in an offline environment.

[0003] However, the verification technology for the decision service model to be simulated and verified in the related art usually adopts a heterogeneous simulation method, that is, a script language (such as SQL, Python, etc.) is used to re-write the logic in the offline analysis environment to simulate the running process of the online production environment. The heterogeneity of the underlying architecture between the offline script and the online engine can easily cause precision deviation or logic inconsistency between the offline simulation result and the online real execution result, and cannot accurately reflect the real system performance after the model goes online. In addition, the simulation verification process in the related art often adopts an artificial feature data construction mechanism, and the preparation of simulation verification test data mainly depends on manual extraction and splicing, which not only has low data processing efficiency, but also is difficult to cover complex dynamic state boundaries, and cannot meet the system verification needs under high-frequency iteration. SUMMARY

[0004] The embodiments of the present specification provide a service verification method, device, storage medium, and electronic device, which can improve the verification efficiency and accuracy of the decision service model. The technical solutions are as follows: In a first aspect, the embodiments of the present specification provide a service verification method applied to a service platform, and the method comprises: receiving a verification control instruction input by a user end to a service simulation console, the verification control instruction comprising a target decision service model of a verification decision service and a target data source configuration simulation mode; in response to the target data source configuration simulation mode, automatically constructing a standard feature input set through a feature data channel and determining a target simulation execution engine; calling the target simulation execution engine with the same architecture as the online platform service environment to load the standard feature input set into the target decision service model for running to obtain a simulation execution result; The service index calculation engine is invoked to perform index operation on the simulation execution result, to generate quantified verification analysis data for the verification decision service.

[0005] In a second aspect, the embodiments of the present specification provide a service verification device, applied to a service platform, the device comprising: An instruction receiving module is configured to receive a verification control instruction input by a user terminal to a service simulation console, the verification control instruction comprising a target decision service model of a verification decision service and a target data source configuration simulation mode; An instruction processing module is configured to automatically construct a standard feature input set and determine a target simulation execution engine through a feature data channel in response to the target data source configuration simulation mode; A service verification module is configured to invoke the target simulation execution engine with the same architecture as an online platform service environment, to load the standard feature input set into the target decision service model for running to obtain a simulation execution result; The service verification module is configured to invoke a service index calculation engine to perform index operation on the simulation execution result, to generate quantified verification analysis data for the verification decision service.

[0006] In a third aspect, the embodiments of the present specification provide a computer storage medium, which stores a plurality of instructions, the instructions being adapted to be loaded and executed by a processor to perform the method steps described above.

[0007] In a fourth aspect, the present specification provides a computer program product, which stores at least one instruction, the instruction being adapted to be loaded and executed by a processor to perform the method steps of one or more embodiments of the present specification.

[0008] In a fifth aspect, the present specification provides a computer program product, which stores at least one instruction, the instruction being adapted to be loaded and executed by a processor to perform the method steps of one or more embodiments of the present specification.

[0009] In a fifth aspect, the embodiments of the present specification provide an electronic device, which can include a processor and a memory; wherein the memory stores a computer program, the computer program being adapted to be loaded and executed by the processor to perform the method steps described above.

[0010] The technical solutions provided by some embodiments of the present specification have at least the following beneficial effects: In one or more embodiments of the present specification, by responding to the user terminal inputted verification control instruction containing a specific simulation mode, the standardized feature construction of multi-source heterogeneous data is automatically completed through the feature data channel, and the target simulation execution engine loading strategy model is called for simulation running, which is completely isomorphic with the online platform service environment in code architecture and running dependence, and then the quantitative verification analysis data is generated by using the index engine. The limitations of logical deviation between simulation results and real performance caused by the heterogeneity of offline verification environment and online production environment (such as the difference between script language and compiled language) are solved, and the problems of low verification efficiency and inability to cover real-time traffic scenarios caused by the high dependence of data preparation on manual operation and the lack of automatic closed-loop support in traditional verification process are overcome, realizing high-fidelity simulation verification of platform strategy service before online release, ensuring the consistency of simulation execution results and online real execution, eliminating the system error caused by environmental difference; at the same time, through the automatic data flow and index calculation, the verification period of strategy iteration is greatly shortened, providing reliable data support and safety guarantee for the stability of platform service under high-frequency change. BRIEF DESCRIPTION OF DRAWINGS

[0011] In order to more clearly illustrate the technical solutions in the embodiments of the present specification or the prior art, the drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present specification, and other drawings can be obtained by those skilled in the art without creative labor.

[0012] Figure 1 is a flow diagram of a service verification method provided by an embodiment of the present specification; Figure 2 is a flow diagram of a historical simulation model processing provided by an embodiment of the present specification; Figure 3 is a flow diagram of an online traffic mirroring mode processing provided by an embodiment of the present specification; Figure 4 is a flow diagram of a discrete data verification mode processing provided by an embodiment of the present specification; Figure 5 is a flow diagram of a simulation execution processing provided by an embodiment of the present specification; Figure 6 is a structural diagram of a service verification device provided by an embodiment of the present specification; Figure 7 is a structural diagram of an electronic device provided by an embodiment of the present specification. DETAILED DESCRIPTION

[0013] With reference to the drawings of the embodiments in the specification, the technical solutions in the embodiments of the specification will be clearly and completely described. Obviously, the described embodiments are only a part of the embodiments of the specification, rather than all the embodiments of the specification. Based on the embodiments in the specification, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the specification.

[0014] In the description of the specification, it should be understood that the terms "first", "second" and the like are used only for the purpose of description, and cannot be understood as indicating or implying relative importance. In the description of the specification, it should be noted that, unless otherwise explicitly specified and limited, "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but can optionally include steps or units not listed, or can optionally include other steps or units inherent to the process, method, product or device. The specific meaning of the above terms in the specification can be understood by the person of ordinary skill in the art. In addition, in the description of the specification, "a plurality of" means two or more, unless otherwise specified. "And / or" describes the relationship between the associated objects, which means that there can be three relationships, for example, A and / or B can represent the following three cases: A exists alone, A and B exist together, and B exists alone. The character " / " generally represents an "or" relationship between the associated objects.

[0015] The specification will be described in detail below with reference to specific embodiments.

[0016] In one embodiment, as shown in Figure 1 A service verification method is proposed, which can be implemented by relying on a computer program and can run on a service verification device based on the von Neumann system. The computer program can be integrated in an application or run as a separate tool application. The service verification device can be a service platform.

[0017] Specifically, the service verification method comprises: S102: receiving a verification control instruction input by a user terminal to a service simulation console, the verification control instruction comprising a target decision service model of a verification decision service and a target data source configuration simulation mode; The service simulation console is a human-computer interaction front end or a programming interface gateway for managing verification tasks, configuring simulation parameters and displaying verification results. In actual application, it can be a Web front end interface based on a browser, or an API interface or an RPC service node for calling by a third-party system.

[0018] The verification control instruction refers to a data message input by a user terminal at a service simulation console for triggering a complete verification task. Optionally, the instruction includes at least two core fields in a data structure: an identifier for uniquely indexing the logic to be verified (i.e., target decision service model information), and a value for defining the source and processing method of input data (i.e., target data source configuration simulation mode).

[0019] Target decision service model: refers to a specific business logic object targeted by the current simulation verification task. The data type of the target decision service model includes but is not limited to decision tree files, scorecard model files, rule engine script packages, and compiled binary policy packages.

[0020] Target data source configuration simulation mode refers to the feature data supply method during the running of the simulation verification task. In some embodiments, the target data source configuration simulation mode includes at least discrete data verification mode, historical simulation model, and online traffic mirroring mode.

[0021] In a feasible implementation, the service platform uses the service simulation console as the scheduling entrance and management center of the entire verification task, and is in a state of continuously listening to service requests or waiting for user interaction. Specifically, in the implementation scenario of the graphical interaction interface provided by the service simulation console, when a user terminal (such as an operation terminal of a business personnel) initiates an access request to the service simulation console, the service simulation console of the service platform renders a visual page including a configuration form to the user terminal. The page integrates model selection controls, version management controls, and simulation mode selection components. The user specifies the target decision service model to be verified and its specific version number from the model repository through the above controls, and selects the corresponding target data source configuration simulation mode (such as historical simulation model, online traffic mirroring mode) according to the current actual verification requirement (for example, it is necessary to backtrack historical data to evaluate the stability of the strategy, it is necessary to introduce real-time traffic to verify the pressure resistance of the strategy). The user terminal responds to the user's submission triggering operation, captures and encapsulates the above discrete configuration parameters into a verification control instruction data packet conforming to a preset communication protocol (such as JSON format, XML format), and sends it to the service simulation console through an encrypted transmission channel. The service simulation console of the service platform further receives and processes the verification control instruction.

[0022] S104: automatically building a standard feature input set and determining a target simulation execution engine through a feature data channel in response to the target data source configuration simulation mode; The feature data channel refers to a data transmission and processing pipeline connecting a data source (such as a data lake, a real-time message queue, a feature center) and a simulation execution environment. The feature data channel has ETL (extraction, transformation, loading) capability through software programming, and can convert raw business logs or real-time traffic messages into feature vectors recognizable by the decision service model to be verified according to predefined metadata mapping rules.

[0023] The standard feature input set refers to a data set that meets the input interface specification of the target simulation execution engine after standardization processes such as cleaning, formatting, and feature engineering. The standard feature input set usually eliminates format differences of heterogeneous data sources and usually includes business primary keys, timestamps, and serialized feature fields.

[0024] The target simulation execution engine can be understood as a computing instance used to run the target decision service model. The engine is isomorphic to the online platform service environment in terms of code architecture, dependency library version, and logic implementation, and its running mode (such as batch processing mode, stream processing mode) depends on the current policy model simulation running configuration.

[0025] Illustratively, the service platform configures the simulation mode according to the target data source specified in the instruction, parses the data feature attributes and computing resource requirements required for this verification task. By calling the corresponding feature data channel in response to the parsing result, the data access adapter adapted to the mode is dynamically activated, and the communication connection with the underlying data source is established. The data source can be a distributed file system storing historical business logs, a message middleware or gateway interface transmitting real-time business traffic, etc. After the connection is established, the feature data channel executes an automated data extraction and conversion process, which includes protocol decoding, field cleaning, missing value filling, and feature vector mapping of the original data, thereby uniformly converting the original data with different sources and formats into a standard feature input set that meets the preset interface specification.

[0026] At the same time, the service platform determines and instantiates the target simulation execution engine through the resource scheduler according to the flow characteristics of the data source (such as static batch data, dynamic streaming data) and the performance index requirements of the verification task. This process may involve pulling a runtime environment image consistent with the online platform service environment version from the image repository, and dynamically allocating CPU and memory resources according to the required computing throughput. The system initializes the engine to a specific running state, such as a one-time running batch job state or a continuous listening background service state, and mounts the corresponding network configuration and dependency library for it, finally ensuring that the target simulation execution engine is highly consistent with the production environment in terms of architecture, and is ready to receive the above built standard feature input set in terms of I / O interface, thereby completing all environment preparation work before simulation.

[0027] S106: invoke the target simulation execution engine co-architected with the online platform service environment to load the standard feature input set into the target decision service model for running to obtain a simulation execution result; The target simulation execution engine co-architected with the online platform service environment refers to that the target simulation execution engine and the production engine in the online platform service environment adopt completely consistent technology stack and running logic. Specifically, both load the same decision service model binary file (such as the same JAR package, So library, PMML file), depend on the same version of underlying base library (such as JDK version, C++ runtime library), and perform the same logical operation rules, so as to ensure that the processing results of the same input data are consistent in service processing logic.

[0028] The simulation execution result refers to the full data record output by the target simulation execution engine after running the decision service model. The simulation execution result includes but is not limited to the final decision conclusion (such as pass / reject, credit score), intermediate variable in the decision process, rule hit path, and exception stack information.

[0029] Illustratively, the service platform enters the simulation operation phase, at which time the instantiated target simulation execution engine is in a ready state, and its underlying running environment, including virtual machine configuration, dependent third-party component version, and dynamic link library, is initialized to be strictly consistent with the online platform service environment, to ensure the isomorphism of the computing basis. The service platform first loads the target decision service model to be verified (such as the compiled policy rule package or the serialized algorithm model file) into the memory execution space of the engine through the standardized loading interface, and the engine internally reuses the same class loading mechanism and configuration parsing logic as the production environment to complete the initialization and warm-up of the model, ensuring that the model is in a serviceable active state.

[0030] The service platform controls the engine to continuously read the standard feature input set through the input interface. For each feature record in the input set, the engine encapsulates it as a business object consistent with the online real request context, and injects it into the execution entrance of the target decision service model. For the business logic inside the target decision service model, whether it is a complex score card calculation, a multi-layer nested rule judgment, or a business running logic based on a graph, etc. is accurately executed under the support of the isomorphic engine. Since the production code is completely reused, the floating point operation precision, logical branch judgment condition, and exception handling mechanism in the simulation verification process are consistent with the online real environment, thereby eliminating the logical drift phenomenon caused by language feature differences or implementation details in heterogeneous simulation.

[0031] While the service platform is operating the target decision service model, the control engine starts the full-link execution tracking function, and uses the preset probes or log components to capture detailed metadata in the model execution process. The metadata includes the final business decision conclusion (such as credit scoring or approval result), rule hit path, calculation value of key intermediate variables, and time consumption information of each logical node. The engine encapsulates all the full-quantity metadata including the final conclusion and process information as a simulation execution result, and according to the preset output strategy, synchronously writes it to the memory buffer or asynchronously persists it to the storage system of the service platform.

[0032] S108: calling a service index calculation engine to perform index operation on the simulation execution result, and generating quantified verification analysis data for the verification decision service.

[0033] The service index calculation engine refers to a built-in data index analysis component, which internally encapsulates a variety of standardized unified algorithms (i.e. operators) of different business service evaluation indexes. The service index calculation engine supports operations such as cleaning, aggregation, association and difference comparison on structured data, can take the simulation execution result as a statistical index with business guidance significance, and generate quantified verification analysis data for the verification decision service including indexes.

[0034] The quantified verification analysis data refers to the structured evaluation result generated after index operation. Optionally, the data includes but is not limited to two parts: absolute performance index (such as approval pass rate of new model) and relative difference index (such as score deviation value of new and old models for the same batch of users), which are used to intuitively show the effectiveness and safety of the verification decision service.

[0035] Illustratively, after the target simulation execution engine completes the simulation running of full-quantity data and outputs the simulation execution result, the service platform triggers the service index calculation engine to intervene to perform deep data post-processing tasks. Specifically, the service index calculation engine first establishes a data connection with the result storage area, reads the simulation execution result including the decision conclusion, rule path and intermediate variable, and according to the preset verification evaluation template, dynamically loads the required standardized index calculation operator to perform multi-dimensional aggregation operation on the simulation execution result. For basic performance evaluation, the service index calculation engine calculates the distribution characteristics of the simulation execution result in a specific business dimension using the unified operator, such as statistics of decision pass proportion under different user stratification, calculation of probability density distribution of risk score, and statistics of trigger frequency of specific high-risk rules, so as to generate an absolute index set reflecting the independent running performance of the target decision service model.

[0036] Meanwhile, in order to evaluate the specific impact of policy upgrade, the service index calculation engine performs a differential analysis process based on benchmarking: through the feature data channel or the log center, the online platform service environment obtains the reference execution log (i.e., the output of the benchmark model) in the same period or for the same traffic. The service index calculation engine takes the unique identifier of the business request as an anchor point, matches the simulation execution result with the reference execution log at the row level, constructs a wide table data set containing new-old result pairs, and then performs a difference comparison operation on the matched data pairs to calculate the deviation (such as the root mean square error of the score difference) of the decision results, analyze the transition of the decision path, and count the flip rate of the abnormal label. The service index calculation engine encapsulates the above absolute indicators and relative difference indicators into standardized quantitative verification analysis data, and renders them into visual report feedback to the user end as the basis for determining whether the policy service model meets the online conditions.

[0037] In one or more embodiments of the present specification, by responding to the verification control instruction input by the user end containing a specific simulation mode, the standardized feature construction of multi-source heterogeneous data is automatically completed through the feature data channel, and the target simulation execution engine that is completely isomorphic to the online platform service environment in terms of code architecture and running dependencies is called to load the policy model for simulation running, and then the index engine generates quantitative verification analysis data. It solves the problem that the simulation results and real performance have logical deviations due to the heterogeneity of the underlying architecture (such as the difference between scripting languages and compiled languages) between the offline verification environment and the online production environment, and also overcomes the problem that the traditional verification process highly depends on manual operation and lacks automated closed-loop support, resulting in low verification efficiency and the inability to cover real-time traffic scenarios. It realizes high-fidelity simulation verification of platform policy services before online release, ensures the consistency of simulation execution results and real online execution, eliminates system errors caused by environmental differences; at the same time, through fully automated data flow and index calculation, the verification period of policy iteration is greatly shortened, providing reliable data support and safety protection for platform service stability under high-frequency changes.

[0038] In a feasible implementation, the service index calculation engine is called to perform index operation on the simulation execution result to generate quantitative verification analysis data for the verification decision service, which can refer to the following method: Step A2: Obtain the historical execution log of the benchmark decision service model corresponding to the online platform service environment; The benchmark decision service model refers to the policy model object used as a reference for comparison in the verification process. Generally, it refers to the main version model running in the online platform service environment, or the last stable version model specified by the user, which is used to establish a reference baseline for evaluating the performance improvement or logical deviation of the new model.

[0039] Historical execution logs refer to the full-link record data generated by the online platform service environment when processing real business requests. It includes but is not limited to the input feature snapshot of the business request, the decision result of the benchmark decision service model, the rule hit details, the execution time consumption, and the system state metadata.

[0040] Step A4: The simulation execution result is associated and matched with the historical execution log to obtain an associated execution comparison result set. The service index calculation engine calculates a preset business index difference value of the associated execution comparison result set, and generates quantitative verification analysis data for the verification decision service based on the preset business index difference value.

[0041] The associated execution comparison result set refers to the composite data set generated after the simulation execution result and the historical execution log are aligned at the row level based on the same business request. Each record in the data set usually contains a unique request identifier, the decision result of the benchmark model, the simulation result of the target model, and the input feature snapshot of the two, which constitutes the data basis for difference analysis.

[0042] The preset business index difference value refers to a quantitative value reflecting the performance gap between the new and old models calculated based on statistical operators. Its types include but are not limited to: decision consistency index, numerical distribution difference index, and business loss and gain difference index.

[0043] Illustratively, the service index calculation engine first performs a data alignment operation to establish a logical mapping between the simulation environment and the real production environment. Specifically, for large-scale historical backtracking scenarios, the engine uses a distributed parallel computing framework to load the simulation execution result and the historical execution log, and specifies the unique identifier of the business request as the association primary key. The engine combines the two data streams scattered in different time stamps or different storage partitions, and builds an associated execution comparison result set containing full-quantity matching samples. Optionally, if real-time data streams in the "online traffic mirroring mode" are detected, the engine will maintain a sliding window based on event time in memory, and use the watermark mechanism to solve the data out-of-order problem caused by network delay, to ensure that the benchmark log and the shadow simulation result generated by the same real-time request are dynamically paired and combined within the time window.

[0044] After the data correlation is completed, the service index calculation engine performs deep calculation on the comparison result set based on the preset algorithm library. Each record in the result set is traversed, and the key fields of the benchmark result and the simulation result are extracted for comparison. For numerical decision results (such as risk scores), a statistical distribution operator is called to calculate the distribution difference of the two in different quantile intervals, and statistical quantities such as population stability index (PSI) or root mean square error (RMSE) are generated to quantify the degree of shift of the model output distribution; for categorical decision results (such as pass / reject labels), the engine calls a consistency checking operator to identify the flipping of the decision logic. The proportion of samples that are statistically benchmarked to pass and targeted to reject or benchmarked to reject and targeted to pass. In addition, the expected change value of the business loss and gain index can be calculated based on the input features, for example, the estimated bad debt rate fluctuation or interception rate gain that the new strategy may bring based on the historical labels.

[0045] Finally, the various preset business index difference values calculated above are structured and packaged to generate quantitative verification analysis data. The engine aggregates the micro-sample-level differences into macro-tables according to the user-configured focus dimensions, and highlights or generates alert metadata for indices that exceed the preset safety threshold (such as a 10% decrease in pass rate). The quantitative verification analysis data is persisted to the analysis database and simultaneously pushed to the front-end rendering module of the service simulation console.

[0046] In the embodiments of the present specification, by obtaining the historical execution log of the online platform service environment as a control benchmark, and associating and matching it with the simulation execution result at the request granularity, the evaluation bias caused by the distribution difference of the test samples is effectively eliminated, ensuring that the new and old models are strictly compared under the same input conditions. Further, by calculating the difference values of the preset business indicators, abstract code logic changes can be directly converted into visual business loss and gain quantitative data, helping verification personnel accurately identify the online user service risks that may be caused by strategy model iteration, reducing the cost of manual statistics, and ensuring the stability and security of the service model after it goes online.

[0047] Optionally, in one or more embodiments of the present specification, the response to the target data source configuration simulation mode is to automatically construct a standard feature input set through a feature data channel. The following methods can be referred to: In response to the target data source configuration simulation mode, a target feature extraction interface corresponding to the target data source configuration simulation mode is called for automatic data construction processing to generate a standard feature input set adapted to the target decision service model. The target data source configuration simulation mode includes a discrete data verification mode, a historical simulation model, and an online traffic mirroring mode.

[0048] Target feature extraction interface refers to a set of abstract invocation standards or APIs predefined in the feature data channel for a specific data source type.

[0049] Discrete data verification mode: refers to a debugging mode for a single or small number of specified real online request data, which can be called single case test in some scenarios, and can be used for rapid testing.

[0050] Historical simulation model refers to a backtracking mode for massive data in a historical period, which can be used for regression testing.

[0051] Online traffic mirroring mode refers to a mirroring mode for real-time production environment traffic, which can be used for production test.

[0052] In a feasible implementation, when the target data source configuration simulation mode is the historical simulation model, refer to Figure 2 , Figure 2 is a flowchart of a historical simulation model processing process, which specifically executes the generation of a standard feature input set adapted to the target decision service model, including: S202: Extracting historical original service request data from a distributed storage system based on the time window index corresponding to the target feature extraction interface, parsing the business fields in the historical original service request data, and mapping the business fields to a feature vector sequence; Time window index refers to time sequence metadata used for quickly locating data partitions in a distributed storage system.

[0053] Feature vector sequence refers to a mathematical expression form required by the verified model input after the heterogeneous original business fields are numerically encoded.

[0054] Illustratively, the target feature extraction interface of the feature data channel starts the automated extraction process, reads the time window parameters specified in the verification control instruction and converts them into time window indexes that adapt to the query syntax of the underlying distributed storage system, then uses the indexes to build distributed query jobs, performs partition pruning or range scanning operations on the physical cluster storing massive historical data, to accurately locate the data block position in the target time period, then schedules multiple computing nodes to read these data blocks concurrently, loads the binary or compressed format files stored on the disk into the memory buffer, and calls the pre-set parser to decode the data stream, to identify and extract the key business fields from the unstructured or semi-structured original logs according to the Schema definition of the business log, such as user geographic location code, device model and merchant category code, etc.

[0055] After the business field extraction is completed, the business fields are subjected to feature engineering processing. For continuous numerical fields (such as the amount), the engine performs normalization, standardization or logarithmic conversion operations to map them to floating-point numbers in a specific interval; for discrete category fields (such as city or occupation), the engine performs one-hot encoding, hash encoding and Embedding embedding lookup to convert them into high-dimensional sparse vectors or low-dimensional dense vector features. Finally, all the processed dimensional features are spliced and assembled according to the input order preset by the model to generate a structured feature vector sequence.

[0056] S204: detecting whether the target feature field required by the target decision service model is present in the feature vector sequence; The target feature field refers to the input variable identifier that the target decision service model must rely on when executing the operation logic. The target feature field defines the specific needs of the model for external data. If any target feature field is missing, the model will output an exception or cause the calculation result to be unreliable due to the inability to instantiate the input object.

[0057] S204 performs strict input data compliance checks to ensure that subsequent simulation operations will not be interrupted due to data missing. Considering different architecture scenarios such as static model files and dynamic feature maps, this embodiment provides two optional processing methods: a matching process based on static data structure configuration and an analysis process based on dynamic dependency map.

[0058] Optionally, in the matching process based on the static data structure configuration, the metadata description file corresponding to the target decision service model version is loaded, and the metadata description file defines the input signature required by the model operation. The feature data channel reads the metadata description file to parse the standard list containing all target feature fields, traverses the feature vector sequence to extract all business field key names contained therein, and constructs a candidate feature set currently available. It is judged whether each element in the target feature field standard list exists in the candidate feature set. In the comparison process, the complete matching of the field name is checked and the compatibility of the data type is checked. If all fields in the standard list can be found in the candidate set, a complete check status code is generated; otherwise, all unmatched fields are marked as missing features and a missing field list is generated, and the processing flow is directed to the subsequent feature backtracking or completion step.

[0059] Optionally, in the analysis process based on the dynamic dependency graph, the input requirements of the target decision service model and the dependency graph of the feature engineering platform are loaded. When it is detected that a specific target feature field (such as risk level) is missing in the feature vector sequence, instead of immediately determining that it is missing, the dependency graph is further queried to determine whether there is a basic atomic feature in the feature vector sequence that can calculate the target feature field. If there are enough basic atomic features, the target feature field is marked as a derivable type and the temporary calculation logic is triggered in the subsequent steps; when the target feature field does not exist in the sequence and the atomic features required by the target feature field are also incomplete, it is determined that the field is of the missing type and S208 is triggered, which can make the most use of existing historical data and reduce unnecessary external data requests.

[0060] S206: If the target feature field exists in the feature vector sequence, a standard feature input set is obtained based on the feature vector sequence; Illustratively, if the target feature field exists in the feature vector sequence, the elements in the feature vector sequence are sorted and aligned according to the input feature order table defined in the target decision service model metadata. It is considered that many high-performance decision models rely on the index position of the input vector rather than the field name in the underlying operation, so it is necessary to ensure that each feature value accurately falls into the dimension slot expected by the model. After the alignment is completed, type coercion logic is executed to ensure that the data precision of all numerical values strictly matches the type definition of the model input tensor, avoiding calculation overflow or truncation error caused by inconsistent precision. Then the aligned and converted feature data and the metadata of the historical request (including the unique business serial number, user identification and business occurrence timestamp) are merged, and a preset serialization component is called to encapsulate them into a data object conforming to the interface specification of the target simulation execution engine to obtain the standard feature input set.

[0061] S208: If the target feature field is missing in the feature vector sequence, a feature backtracking calculation sub-process is triggered to determine a supplementary feature value or receive an externally input supplementary feature value, so as to obtain the standard feature input set based on the supplementary feature value and the feature vector sequence.

[0062] Feature backtracking calculation can be a process of re-accessing the original business log at the historical time and re-executing the feature engineering calculation on the past time slice according to the calculation logic definition of the missing specific field in the historical feature snapshot.

[0063] Supplementary feature value refers to a feature value obtained by backtracking calculation or specified by external configuration. The value is used to fill in the missing items of historical data, so that the incomplete feature vector becomes a complete standard input.

[0064] Illustratively, the feature backtracking calculation triggered to attempt to perform automation: extract the unique identifier of the missing target feature field, and retrieve the calculation logic script associated with the field in the metadata warehouse of the feature engineering management platform. If the calculation logic is obtained, the exact timestamp of the occurrence of the historical business request is used as the reference time point, and a backtracking query request is initiated to the underlying distributed system that stores the original log. The data range associated with the reference time point is circled in the original business log (for example, all records in the past 30 days of the time point), and the calculation logic retrieved is used to perform on-demand aggregation operation on the original data (for example, calculate the total data transfer amount in the past 30 days), thereby dynamically generating the true value of the feature at the historical time as a supplementary feature value.

[0065] If the automation backtracking fails due to missing original logs or undefined calculation logic, or is configured in manual intervention mode, the process of receiving external input is performed, which can specifically read the pre-loaded feature default value configuration table to extract the corresponding default value; or output an interactive prompt to the user on the service simulation console, and request the user to upload a supplementary data file containing the missing feature (such as a CSV wide table with an associated primary key). If the supplementary feature value is successfully obtained through any of the above paths, the vector merging operation is performed, and the supplementary feature value is inserted or spliced into the original feature vector sequence according to the index position defined by the target decision service model. The completed sequence is re-encapsulated as a standard feature input set with complete structure.

[0066] In this specification, by extracting the original business log from the distributed storage bottom layer based on the time window index, and intelligently triggering the feature backtracking calculation sub-process or external supplement process based on the original data when the automation detects that the historical feature vector sequence is missing the target feature field required by the new model. The common feature cold start limitation in policy iteration process is solved, that is, the technical obstacle that the historical data cannot be directly reused due to the inconsistency of the feature system of the new and old models is effectively overcome, the simulation bias caused by filling with static default values is avoided, and it is ensured that the complete input context required by the new model can be accurately restored using the existing historical original data. In the case where new data accumulation is not required, the complex strategy containing new features can be accurately backtested, the coverage of the verification is improved, and the utilization rate of the historical data assets is improved.

[0067] In a feasible implementation, when the target data source configuration simulation mode is the online traffic mirroring mode, please refer to Figure 3 , Figure 3 is a flowchart of the online traffic mirroring mode processing, and the generation of the standard feature input set adapted to the target decision service model includes: S302: Real-time replication of the inbound traffic of the online platform service environment by the traffic mirroring component, and redirection of the inbound traffic to the isolated verification environment corresponding to the target data source configuration simulation mode as a standard feature input set; The traffic mirroring component refers to a network function module deployed in the network access layer in an online environment. The component has out-of-band replication capability and can generate a complete and consistent traffic data copy without interfering with the original traffic data packet forwarding path.

[0068] Inbound traffic refers to the original service request data stream sent from the user end or external system to the online platform service environment.

[0069] Illustratively, when running in the online traffic mirroring mode, the traffic mirroring component located at the entrance of the online platform service environment is activated through the feature data channel, continuously monitoring the inbound traffic passing through the production gateway or service grid proxy node. Whenever a service request that meets the verification range (such as a specific URL path or a specific user group) is detected, the component starts a parallel asynchronous thread to perform full replication of the request data packet while executing the normal production forwarding logic.

[0070] After completing the replication of the data packet, the traffic mirroring component performs routing rewriting and marking operations on the mirrored copy. The traffic mirroring component modifies the target address of the mirrored traffic from the production service cluster to the entrance address of the isolated verification environment, and injects specific metadata labels into the request header as needed to clearly distinguish the test attributes of the traffic and prevent confusion in subsequent processing. Subsequently, the redirected traffic is pushed in real time through the internal high-speed network to the data receiving end of the feature data channel. The feature data channel unpacks and cleans these original protocol packets, removes redundant fields related to network transmission, and retains core business parameters, finally converting them into a standard feature input set in a streaming format, which is continuously injected into the isolated verification environment, allowing the target decision service model to perceive real business pressure and data distribution that are completely synchronized with the online environment.

[0071] S304: Instantiating the target simulation execution engine in the isolated verification environment, and configuring the result output port of the target simulation execution engine to be in a blocked state, which is used to control the simulation execution results not to be returned to the business front end corresponding to the online platform service environment.

[0072] The isolated verification environment refers to an independent running space that can share resources with the production environment on the physical infrastructure, but is strictly divided logically through virtualization technology.

[0073] The blocking state refers to a special I / O configuration mode. In this state, the business logic inside the engine is normally executed, but the action of sending responses outside is intercepted and terminated by the interceptor. The simulation engine only goes in but not out (for the business front end), preventing real users from receiving duplicate or incorrect responses.

[0074] Illustratively, in the pre-set isolated verification environment, the instantiation process of the target simulation execution engine is started, the running image of the target decision service model is pulled from the image repository and deployed as an independent container or process, and independent computing resources and non-public network addresses are allocated for the instance to ensure logical isolation with the online platform service environment in network topology. In the initialization stage or dynamic configuration stage of the target simulation execution engine, the output port of the engine is configured in a forced blocking state. Specifically, the output interception middleware is loaded or the egress traffic rules of the service grid are configured, which are set to monitor and take over all response packets generated by the engine.

[0075] When the target simulation execution engine completes the decision calculation on the input traffic and attempts to return the simulation execution result to the business front end through the result output port according to the standard protocol, the interception mechanism will capture the response action and prevent the data packet from entering the real network backhaul link, thereby avoiding the business front end from receiving double responses from the production service and the simulation service. At the same time, in order to preserve the verification basis, the output port in the blocking state will redirect the intercepted simulation execution result to the asynchronous message queue, log file or analysis database inside the system for subsequent use by the index calculation engine, thereby completing the full-link simulation verification of the new strategy model on the premise of ensuring the absolute safety and non-interference of the online business.

[0076] In a feasible implementation, when the target data source is configured in the discrete data verification mode, please refer to Figure 4 , Figure 4 is a flowchart of a discrete data verification mode processing, which specifically executes the generation of a standard feature input set adapted to the target decision service model, including: S402: an interactive configuration interface is displayed; S404: a numerical definition instruction for a target feature dimension is received, the feature numerical value input by the instruction is parsed to construct a standard feature input set; or, a feature association sampling instruction for a target object identifier is received, a feature center service is called to retrieve historical user feature data associated with the target object identifier, and a standard feature input set is constructed based on the historical user feature data.

[0077] When the user's authentication requirement is identified as a discrete data verification mode, the interface definition file of the target decision service model is read to parse the list of input fields and data type constraints required for the model to run, and an interactive configuration interface is dynamically rendered in the front-end browser or client based on the parsed information. For example, the interface is divided into two functional modules: a custom numerical value input area and an ID association retrieval area, allowing users to freely select according to the test purpose.

[0078] For scenarios where the user wants to perform boundary value testing or hypothesis verification, the service platform receives user-defined numerical value instructions for the target feature dimensions through the interface. The service platform performs format checking and type conversion on these input feature values, assembles them into a JSON object or key-value pair mapping table that conforms to the model interface specification, and directly constructs a standard feature input set.

[0079] In an optional operation path, for scenarios where the user wants to reproduce a specific online user behavior scenario, the system receives user input of feature association sampling instructions for the target object identifier on the interface. The system responds to the instruction by calling the feature center service through an internal API to initiate a real-time retrieval request using the target object identifier as the index key. The feature center service returns the full profile data of the object at the current time or a specified historical time, including static attributes and dynamic behavior labels. The system receives these historical user feature data and performs field filtering and alignment on the historical user feature data according to the requirements of the target decision service model, excluding irrelevant fields. Finally, the cleaned profile data is packaged into a standard feature input set.

[0080] In this specification, in the discrete data verification mode, an interactive configuration interface is dynamically rendered to provide numerical value definition instruction input entry for target feature dimensions and feature association sampling function for target object identifiers. This realizes the automatic construction of a standard feature input set from a single numerical value setting or a single identity index, reduces the operation threshold of strategy verification, and enables business personnel or developers to quickly conduct hypothesis verification and production problem reproduction, thereby improving the debugging efficiency of strategy models in the agile iteration process and the accuracy of case problem positioning.

[0081] Optionally, please refer to Figure 5 , Figure 5 is a flowchart of a simulation execution process. The target simulation execution engine is called to load the standard feature input set into the target decision service model for running to obtain simulation execution results, including: S502: Call the target simulation execution engine with the same architecture as the online platform service environment to build a virtual execution context. The virtual execution context refers to a closed environment built inside the simulation execution engine for carrying out the running of the target decision service model. The virtual execution context simulates the thread local variables, request scope, security authentication token and system environment variables (such as server time zone, IP address) in the online production environment, ensuring that the model cannot perceive that it is in an offline simulation state when running in a sandbox.

[0082] Illustratively, the service platform starts the target simulation execution engine with the same architecture as the online platform service environment to build a virtual execution context. Through deep cloning of the runtime state of the production environment, the target simulation execution engine allocates an independent memory stack in the initialization stage, and loads the dependent library, class loader structure and global singleton object according to the preset configuration template, which is completely consistent with the online environment. Further, the target simulation execution engine initializes an isolated context container for each simulation task to be executed, which preloads the simulation stub object of the key infrastructure in the production environment, such as the log context, full link tracking ID and user session object, thereby building a virtual running base that is consistent with the real production environment in the code view.

[0083] S504: Based on the loading of the target decision service model in the virtual execution context, logical synchronization processing is performed on the standard feature input set, and the standard feature input set is loaded into the target decision service model for running to obtain a simulation execution result.

[0084] Logical synchronization processing refers to the process of adjusting the system state (such as time dimension and global configuration state) of the simulation environment to be consistent with the time when the business corresponding to the standard feature input set occurs.

[0085] Illustratively, the target decision service model is loaded in the built virtual execution context, and logical synchronization processing is performed on the standard feature input set. In this link, the service platform hot loads the compiled policy model file into the context, reads the metadata (such as business occurrence timestamp) in the standard feature input set, and aligns the state of the virtual context. For example, the calling interface of the system clock inside the model is intercepted and rewritten, the "current time" in the context is forcibly set to the historical timestamp in the input set, and the corresponding permission configuration or switch configuration is dynamically injected according to the user attribute in the input set, to complete the logical time and space synchronization. After ensuring that the context environment and the data features are completely consistent in logical time sequence, the service platform injects the standard feature input set into the model entry of the target decision service model to trigger the operation of the decision logic, and the target decision service model processes the input data in the virtual context according to the established rules, and the decision conclusion, intermediate variable and exception stack generated are captured by the target simulation execution engine, to generate a simulation execution result.

[0086] In the present specification, by constructing a virtual execution context with the same architecture as the online platform service environment, and performing business time-based logical synchronization processing during model loading runtime, the problem of spatiotemporal misalignment logical deviation caused by inconsistency between physical runtime or system environment state and historical data time in offline simulation environment is effectively solved, ensuring that the target decision service model can restore the closed sandbox of the historical real scene to run, thereby eliminating the influence of environmental interference on decision logic, and improving the accuracy and reliability of the simulation execution result in time-sensitive and state-dependent business scenarios.

[0087] In a feasible implementation, the logical synchronization processing includes logical time virtual synchronization processing and state virtual synchronization processing. Specifically, the logical synchronization processing performed by the target decision service model loaded in the virtual execution context on the standard feature input set can refer to the following manner: Step B2: based on the virtual execution context in which the target decision service model is loaded, starting time virtual synchronization processing, injecting a time interception probe in the running thread of the target simulation execution engine to parse the business occurrence timestamp of the to-be-processed data in the standard feature input set, when the target simulation execution engine initiates a system time acquisition call, intercepting the system time acquisition call through the time interception probe, and redirecting the return value of the system time acquisition call to the business occurrence timestamp; The time interception probe refers to a software agent embedded in the runtime environment of the simulation execution engine. It can monitor and hijack the application's call request to the underlying operating system time function by using aspect-oriented programming or bytecode instrumentation technology.

[0088] The business occurrence timestamp refers to the metadata carried in the standard feature input set, which records the accurate time when the business actually occurred in history.

[0089] Illustratively, in order to ensure that the target decision service model can accurately reproduce the time logic of the historical time during the simulation execution process, the service platform can perform step B2 to start the time virtual synchronization processing. Specifically, in the initialization phase of the virtual execution context, a time interception probe is injected into the class loader or the underlying runtime library of the target simulation execution engine by using dynamic bytecode enhancement technology. The time interception probe can cover all underlying system APIs related to time acquisition. When the simulation task starts to process a specific data in the standard feature input set, the service platform parses the business occurrence timestamp in the data metadata and binds it to the thread local context of the current execution thread, thereby setting a dedicated virtual clock for the thread.

[0090] When the target decision service model executes specific business logic code and initiates a system time acquisition call, for example, to determine whether the current time belongs to the Double 11 promotion event window, the time interception probe immediately captures this instruction. The time interception probe blocks the instruction from directly accessing the real system clock of the physical server through the hook function, prevents the target decision service model from acquiring the current physical time, reads the pre-bound business occurrence timestamp from the context of the current thread through the time interception probe, encapsulates it into a time object conforming to the API return value specification, and returns it as an alternative return value to the target decision service model. Through this mechanism, all time-sensitive logic (such as day change judgment and validity period verification) in the target decision service model will be directed to a historical moment, thereby achieving logical time rollback.

[0091] Step B4: Based on the loading of the target decision service model start state virtual synchronization processing in the virtual execution context, when the target simulation execution engine triggers a state write instruction in the process of processing the to-be-processed data, the state write instruction is intercepted to prohibit modification of the persistent storage space of the online platform service environment, and state change data is written to the session-level state cache of the virtual execution context. When the target simulation execution engine triggers a state read instruction to obtain a target cumulative indicator, the session-level state cache and the historical feature snapshot system are retrieved according to a preset priority indication.

[0092] The state write instruction is an operation request issued by the target decision service model during running, aiming to update the attribute value of the business entity. For example, updating the user's daily interaction frequency, recording the last login time of the device, or deducting the data volume of the user end.

[0093] The persistent storage space refers to the physical medium relied on in the online platform service environment for long-term storage of real business data.

[0094] The session-level state cache refers to a memory storage area temporarily opened in the virtual execution context, with a life cycle limited to the current simulation task. It acts as a sandbox database for temporarily storing all data changes generated during simulation.

[0095] The target cumulative indicator refers to a feature that needs to be dynamically calculated based on historical data and current behavior, such as the cumulative number of visits in the past 24 hours, the cumulative number of service uses, etc.

[0096] Illustratively, to ensure that the simulation process has both dynamic interaction and absolute security, the service platform performs step B4 to start the state virtual synchronization processing mechanism. When the target simulation execution engine obtains intermediate results and triggers a state write instruction according to the business logic in the process of processing the to-be-processed data, the target address of the instruction is immediately recognized by the underlying IO interceptor. Usually, to prevent test data generated by simulation from polluting the real production environment, the IO interceptor will forcibly intercept the state write instruction and cut off its connection with the persistent storage space of the online platform service environment, thereby ensuring the read-only attribute of the online database. At the same time, the state change data (for example, the daily access count of user A + 1) carried in the state write instruction is redirected and written into the session-level state cache maintained inside the virtual execution context. The session-level state cache is a high-speed memory structure independent of the external environment and is used to record all state increments in this simulation session.

[0097] Further, when subsequent business logic or continuous simulation tasks trigger a state read instruction to obtain a target cumulative indicator (for example, to determine whether the current cumulative service usage times of a user are over the limit), a hierarchical retrieval strategy based on a preset priority indication is performed: first, the session-level state cache is retrieved to check whether there is a latest change record of the indicator in the current simulation context; if the cache hits (that is, the state has just been simulated and modified), the value in the cache is directly returned, thereby realizing state memory and dynamic accumulation in the simulation process; if the cache misses, the historical feature snapshot system is retrieved to obtain the original baseline data at the time of business occurrence. Through this write-time redirection and read-time priority caching mechanism, a virtual closed loop that can simulate continuous business state changes can be successfully constructed, so that complex strategy models that rely on real-time state accumulation can be accurately verified in a completely isolated environment.

[0098] Optionally, based on steps B2-B4, to solve the problem of calculation accuracy of complex time sequence indicators in the simulation environment, the service platform can further perform steps C2 and C4, specifically: Step C2: If the trigger state write instruction is of a time window indicator operation type, determine the virtual time window boundary based on the business occurrence timestamp; The time window indicator operation type refers to a type of business indicator that depends on a specific time period range for statistics. Common examples include 24-hour cumulative amount, 7-day login times, and daily average consumption in a natural month. The calculation result of this type of indicator will dynamically change as the current baseline time moves.

[0099] The virtual time window boundary refers to an effective statistical time interval calculated based on the business occurrence timestamp in the simulation process. Usually, only data falling within this interval is included in the calculation.

[0100] Illustratively, when the target simulation execution engine triggers a state write instruction or a query instruction, the service platform performs type identification on the metric metadata involved in the state write instruction or the query instruction. If the system determines that the instruction belongs to the time window metric operation type (for example, calculating the cumulative number of times in the past 24 hours before the current time), the processing logic of step C2 is immediately activated: in this process, the aggregation calculation engine first accesses the virtual execution context, extracts the business occurrence timestamp representing the real occurrence time of the current to-be-processed data injected by the previous step, and sets it as the time reference point or window cutoff time of this operation.

[0101] Further, the service platform reads the time window length parameter (such as 24 hours, 7 days) configured in the metric definition, and performs reverse time sequence reasoning with the business occurrence timestamp as the origin, to accurately calculate the window start time corresponding to the metric at the historical time through subtraction operation. Through the foregoing process, the system constructs a virtual time window boundary that is independent of the current physical clock, which dynamically shifts with the business occurrence time of each to-be-verified data, ensuring that no matter when the simulation task is executed, the statistical range defined by the system always strictly reproduces the historical time slice, thereby providing an accurate space-time reference for subsequent data filtering and aggregation.

[0102] Step C4: When retrieving the session-level state cache and the historical feature snapshot system, filter data items outside the virtual time window boundary, and perform real-time aggregation calculation of the target cumulative metric in the virtual execution context.

[0103] Real-time aggregation calculation refers to the immediate statistical operation on a group of data streams in memory, rather than waiting for all data to be written to disk before performing batch processing.

[0104] Target cumulative metric refers to a value reflecting the total sum of the state in a specific business period obtained through aggregation calculation, for example, the cumulative service usage number of a user in the past 7 days.

[0105] Illustratively, after the specific range of the virtual time window is determined in step C2, step C4 is performed to complete the accurate cleaning and core calculation of data. In this process, the aggregation calculation engine starts a parallel retrieval mechanism, while scanning the session-level state cache (storing the incremental state data newly generated in this simulation session) and the historical feature snapshot system (storing the existing stock historical data at the time of business occurrence), and extracting all candidate data details associated with the current target object identifier. The timestamp attribute of each candidate data retrieved is compared with the virtual time window boundary one by one, and the automatic filtering logic is executed: the data items falling outside the window boundary (i.e. expired old data earlier than the window start time or future abnormal data later than the window end time) are determined as invalid data and are excluded; only the valid data items strictly falling within the virtual time window are retained. These valid data cleaned in time are loaded into the high-speed memory calculation unit of the virtual execution context, and real-time aggregation calculation (such as numerical summation, frequency counting, de-duplication statistics or weighted average operation) is performed according to the index definition, so as to obtain the target cumulative index accurately reflecting the business state at the historical moment, and return it as a standard input to the target decision service model to support the subsequent rule judgment logic.

[0106] In the present specification, the virtual sliding window aggregation mechanism based on the business time anchor point is constructed by performing steps C2 to C4, which can dynamically determine the virtual time window boundary according to the business occurrence time of the data to be processed, and perform unified time sequence filtering and real-time aggregation on the incremental data in the session-level state cache and the stock data in the historical feature snapshot. The problem of invalid time window index calculation caused by physical time lag in the offline simulation scenario is effectively solved, and the new state generated in the simulation process can be immediately included in the closed-loop calculation of the subsequent cumulative index, so that the strategy model involving complex sliding window logic (such as 24-hour cumulative transaction amount) can obtain high-fidelity input in time sequence logic completely consistent with the historical real scene in the completely isolated sandbox environment, thereby improving the accuracy and robustness of state-dependent business rule verification.

[0107] The embodiments of the present specification will be described below in conjunction with Figure 6 The service verification device provided by the embodiments of the present specification will be described in detail. It should be noted that Figure 6 The service verification device shown in the figure is used to execute the method of the embodiments of the present specification Figures 1 to 5 The method of the embodiments shown in the figure is only shown with parts related to the embodiments of the present specification, and the specific technical details not disclosed are referred to the method of the embodiments of the present specification Figures 1 to 5 The embodiments shown in the figure.

[0108] Please refer to Figure 6, which shows a structural schematic diagram of a service verification device according to an embodiment of the present specification. The service verification device 1 can be realized by software, hardware or a combination of both to become all or part of the device. According to some embodiments, the service verification device 1 comprises an instruction receiving module 11, an instruction processing module 12 and a service verification module 13, which are specifically used for: The instruction receiving module 11 is configured to receive a verification control instruction input by a user terminal to a service simulation console, wherein the verification control instruction comprises a target decision service model of a verification decision service and a target data source configuration simulation mode; The instruction processing module 12 is configured to automatically construct a standard feature input set through a feature data channel and determine a target simulation execution engine in response to the target data source configuration simulation mode; The service verification module 13 is configured to call the target simulation execution engine with the same architecture as the online platform service environment to load the standard feature input set into the target decision service model for running to obtain a simulation execution result; The service verification module 13 is configured to call a service index calculation engine to perform index operation on the simulation execution result to generate quantitative verification analysis data for the verification decision service.

[0109] It should be noted that the service verification device provided in the above embodiments is only exemplified by the division of the above functional modules when the service verification method is executed. In actual application, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the above described functions. In addition, the service verification device and the service verification method provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiments, which will not be described here.

[0110] The above sequence numbers of the embodiments of the present specification are only for description, not representing the advantages or disadvantages of the embodiments.

[0111] The embodiments of the present specification also provide a computer storage medium, which can store a plurality of instructions, the instructions being suitable for being loaded and executed by a processor to execute the service verification method of the above embodiments. Figures 1 to 5 The specific implementation process can be referred to the specific description of the above embodiments, which will not be described here. Figures 1 to 5 The specific implementation process can be referred to the specific description of the above embodiments, which will not be described here.

[0112] The present specification also provides a computer program product, which stores at least one instruction, the at least one instruction being loaded and executed by the processor to execute the service verification method of the above embodiments. Figures 1 to 5 The specific implementation process can be referred to the specific description of the above embodiments, which will not be described here. Figures 1 to 5 ​

[0113] Referring to Figure 7 A structural block diagram of an electronic device according to an embodiment of the present disclosure is provided. The electronic device according to an embodiment of the present disclosure can include one or more of the following components: a processor 1010, a memory 1020, an input device 1030, an output device 1040, and a bus 1050. The processor 1010, the memory 1020, the input device 1030, and the output device 1040 can be connected to each other through the bus 1050.

[0114] The processor 1010 can include one or more processing cores. The processor 1010 connects various parts within the entire electronic device using various interfaces and lines, and performs various functions of the electronic device and processes data by executing instructions, programs, code sets, or instruction sets stored in the memory 1020, and calling data stored in the memory 1020. Alternatively, the processor 1010 can be implemented in at least one of a hardware form of a digital signal processor (DSP), a field-programmable gate array (FPGA), a programmable logic array (PLA). The processor 1010 can integrate a combination of one or more of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. Among them, the CPU mainly processes an operating system, a user interface, and an application program; the GPU is responsible for rendering and drawing display content; and the modem is used for processing wireless communication. It can be understood that the above-mentioned modem can also not be integrated into the processor 1010, but can be implemented by a separate communication chip.

[0115] The memory 1020 can include a random access memory (RAM) and can also include a read-only memory (ROM). Alternatively, the memory 1020 includes a non-transitory computer-readable storage medium. The memory 1020 can be used to store instructions, programs, codes, code sets, or instruction sets.

[0116] The input device 1030 is configured to receive input instruction or data, and the input device 1030 includes, but is not limited to, a keyboard, a mouse, a camera, a microphone, or a touch device. The output device 1040 is configured to output instruction or data, and the output device 1040 includes, but is not limited to, a display device, a speaker, and the like. In the embodiments of the present specification, the input device 1030 can be a temperature sensor configured to acquire the operating temperature of the electronic device. The output device 1040 can be a speaker configured to output an audio signal.

[0117] In addition, those skilled in the art can understand that the structure of the electronic device shown in the above-described drawings does not constitute a limitation on the electronic device, and the electronic device can include more or fewer components than those shown in the drawings, or combine certain components, or different component arrangements. For example, the electronic device further includes a radio frequency circuit, an input unit, a sensor, an audio circuit, a wireless fidelity (WIFI) module, a power supply, a Bluetooth module, and the like, which are not described herein.

[0118] In the embodiments of the present specification, the execution subject of each step can be the electronic device described above. Alternatively, the execution subject of each step is an operating system of the electronic device. The operating system can be an Android system, an IOS system, or other operating systems, which are not limited in the embodiments of the present specification.

[0119] In the electronic device, Figure 7 In the electronic device, the processor 1010 can be configured to invoke a program stored in the memory 1020 and perform to implement the service verification method as described in the various method embodiments of the present specification.

[0120] Those of ordinary skill in the art can understand that all or part of the processes in the above-described embodiments can be completed by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the above-described embodiments. The storage medium can be a magnetic disc, an optical disc, a read-only memory, a random access memory, or the like.

[0121] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of the present specification are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data need to comply with relevant laws, regulations, and standards in relevant countries and regions. For example, the verification control instruction and user information involved in the present specification are obtained under sufficient authorization.

[0122] The above descriptions are only the preferred embodiments of the present specification, and certainly cannot limit the scope of the rights of the present specification, so the equivalent changes made according to the claims of the present specification still belong to the scope covered by the present specification.

Claims

1. A service verification method, characterized in that, Applied to a service platform, the method includes: Receive verification control instructions input by the user terminal to the service simulation console. The verification control instructions include the target decision service model and the target data source configuration simulation mode of the verification decision service. In response to the target data source configuration simulation mode, a standard feature input set is automatically constructed and the target simulation execution engine is determined through the feature data channel; The target simulation execution engine, which shares the same architecture as the online platform service environment, is invoked to load the standard feature input set into the target decision service model for execution to obtain simulation results. The service metric calculation engine is invoked to perform metric calculations on the simulation execution results, generating quantitative verification analysis data for the verification decision service. The step of calling the target simulation execution engine, which has the same architecture as the online platform service environment, to load the standard feature input set into the target decision service model for execution and obtain simulation results includes: calling the target simulation execution engine, which has the same architecture as the online platform service environment, to construct a virtual execution context; loading the target decision service model based on the virtual execution context to perform synchronous processing of the standard feature input set; and loading the standard feature input set into the target decision service model for execution and obtaining simulation results.

2. The method according to claim 1, characterized in that, The simulation mode is configured in response to the target data source, and a standard feature input set is automatically constructed through the feature data channel, including: In response to the target data source configuration simulation mode, the target feature extraction interface corresponding to the target data source configuration simulation mode is called to perform automated data construction processing to generate a standard feature input set adapted to the target decision service model; The target data source configuration simulation modes include discrete data verification mode, historical simulation model and online traffic mirroring mode.

3. The method according to claim 2, characterized in that, When the target data source is configured with the historical simulation model as the simulation mode, the generation of a standard feature input set adapted to the target decision service model includes: Based on the time window index corresponding to the target feature extraction interface, historical original service request data is extracted from the distributed storage system, the business fields in the historical original service request data are parsed, and the business fields are mapped into a feature vector sequence. Detect whether the feature vector sequence contains the target feature field required for the operation of the target decision service model; If the target feature field exists in the feature vector sequence, then a standard feature input set is obtained based on the feature vector sequence; If the target feature field is missing in the feature vector sequence, the feature backtracking calculation sub-process is triggered to determine the supplementary feature value or receive the supplementary feature value from external input, so as to obtain the standard feature input set based on the supplementary feature value and the feature vector sequence.

4. The method according to claim 2, characterized in that, When the target data source is configured with the simulation mode as the online traffic mirroring mode, the generation of the standard feature input set adapted to the target decision service model includes: The inbound traffic of the online platform service environment is copied in real time by the traffic mirroring component, and the inbound traffic is redirected to the isolation verification environment corresponding to the simulation mode of the target data source as the standard feature input set. In the isolated verification environment, the target simulation execution engine is instantiated, and the result output port of the target simulation execution engine is configured to be in a blocked state. The blocked state is used to control the simulation execution result from not returning to the business front end corresponding to the online platform service environment.

5. The method according to claim 2, characterized in that, When the target data source is configured with the simulation mode as the discrete data verification mode, the generation of a standard feature input set adapted to the target decision service model includes: Displays an interactive configuration interface; Receive a numerical definition instruction for the target feature dimension, parse the feature values ​​input by the instruction to construct a standard feature input set; or, receive a feature association sampling instruction for the target object identifier, call the feature center service to retrieve historical user feature data associated with the target object identifier, and construct a standard feature input set based on the historical user feature data.

6. The method according to claim 1, characterized in that, The logical synchronization processing includes logical time virtual synchronization processing and state virtual synchronization processing. The step of performing logical synchronization processing on the standard feature input set based on the target decision service model loaded in the virtual execution context includes: Based on the virtual execution context, the target decision service model is loaded to start virtual synchronization processing. A time interception probe is injected into the running thread of the target simulation execution engine to parse the business occurrence timestamp of the data to be processed in the standard feature input set. When the target simulation execution engine initiates a system time acquisition call, the system time acquisition call is intercepted by the time interception probe, and the return value of the system time acquisition call is redirected to the business occurrence timestamp. Based on the target decision service model loaded in the virtual execution context, the virtual synchronization processing of the state is initiated. When the target simulation execution engine triggers a state write instruction while processing the data to be processed in the standard feature input set, the state write instruction is intercepted to prevent modification of the persistent storage space of the online platform service environment, and the state change data is written to the session-level state cache of the virtual execution context. When the target simulation execution engine triggers a state read instruction to obtain the target cumulative indicators, the session-level state cache and the historical feature snapshot system are retrieved according to the preset priority indication.

7. The method according to claim 6, characterized in that, The method further includes: If the trigger state write instruction is a time window indicator operation type, the virtual time window boundary is determined based on the service occurrence timestamp; When retrieving the session-level state cache and the historical feature snapshot system, data items located outside the boundaries of the virtual time window are filtered out, and the target cumulative metrics are aggregated and calculated in real time within the virtual execution context.

8. The method according to claim 1, characterized in that, The service indicator calculation engine performs indicator calculations on the simulation execution results to generate quantitative verification analysis data for the verification decision service, including: Obtain the historical execution logs of the benchmark decision service model corresponding to the online platform service environment; The simulated execution results are correlated and matched with the historical execution logs to obtain a correlated execution comparison result set. The service indicator calculation engine is used to calculate the preset business indicator difference value of the correlated execution comparison result set. Based on the preset business indicator difference value, quantitative verification analysis data for the verification decision service is generated.

9. A service verification device, characterized in that, The device, applied to a service platform, includes: The instruction receiving module is used to receive verification control instructions input by the user terminal to the service simulation console. The verification control instructions include the target decision service model and the target data source configuration simulation mode of the verification decision service. The instruction processing module is used to configure the simulation mode in response to the target data source, automatically construct a standard feature input set through the feature data channel, and determine the target simulation execution engine; The service verification module is used to call the target simulation execution engine, which has the same architecture as the online platform service environment, to load the standard feature input set into the target decision service model for running and obtaining simulation execution results; The service verification module is used to call the service indicator calculation engine to perform indicator calculations on the simulation execution results and generate quantitative verification analysis data for the verification decision service. The step of calling the target simulation execution engine, which has the same architecture as the online platform service environment, to load the standard feature input set into the target decision service model for execution and obtain simulation results includes: calling the target simulation execution engine, which has the same architecture as the online platform service environment, to construct a virtual execution context; loading the target decision service model based on the virtual execution context to perform synchronous processing of the standard feature input set; and loading the standard feature input set into the target decision service model for execution and obtaining simulation results.

10. A computer storage medium, characterized in that, The computer storage medium stores a plurality of instructions adapted for loading by a processor and executing the steps of the method as described in any one of claims 1 to 8.

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

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

Images