A service processing method and apparatus, a storage medium, and an electronic device

Abstract

The embodiment of the specification discloses a service processing method and device, a storage medium and an electronic equipment, wherein the method comprises the following steps: firstly, responding to a service state update event of a target user object, updating a user service state feature vector of the target user object in a platform application service, inputting the feature vector into a preset service logic decision topology model for path matching, determining a target service task scheduling branch, then extracting a user service execution operator associated with the branch, determining a user service task scheduling instruction carrying a service resource item and a task configuration parameter according to the user service execution operator, further calling a template engine to fill the configuration parameter field into a preset data message template to generate target service guide information data packets, and finally distributing the data packets to a terminal device of the target object through a preset service message pushing channel to realize accurate recommendation of service resource information.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a service processing method, apparatus, storage medium, and electronic device. Background Technology

[0002] In current internet service interaction scenarios, users have extremely high expectations for the response speed of service platforms and the accuracy of recommended service content. However, existing technologies often fail to achieve deep semantic perception when faced with dynamic changes in user status (such as user authentication through the platform or activation of platform services). This results in a certain lag and bias in the service guidance information pushed to users, which carries platform service resources. When an individual user's service needs change instantaneously, the service platform struggles to capture and match complex user service logic in real time. Users often receive redundant information that does not match their current service status, interfering with their decision-making efficiency and interaction experience.

[0003] Furthermore, due to the relatively simple mechanism for generating service guidance information and the lack of refined adaptation to user service scenarios, the platform service recommendations received by users on the terminal often lack specificity and fail to meet users' personalized needs in complex service chains. This results in service gaps, limits the smoothness of user operations in platform applications, and makes it difficult to build a high-quality service ecosystem such as personalized goals for each user. Summary of the Invention

[0004] This specification provides a service processing method, apparatus, storage medium, and electronic device, the technical solutions of which are as follows: Firstly, embodiments of this specification provide a service processing method, the method comprising: In response to a service status update event of a target user object, update the user service status feature vector of the target user object in the platform application service; The user service status feature vector is input into a preset service logic decision topology model, and path matching is performed in the service logic decision topology model to obtain the target service task scheduling branch. Extract the user service execution operator associated with the target service task scheduling branch, and determine the user service task scheduling instruction corresponding to each target user object based on the user service execution operator. The user service task scheduling instruction carries service resource items and user service task configuration parameters. Based on the service resource items and user service task configuration parameters, a target service guidance information data packet is generated. The target service guidance information data packet is then distributed downlink to the terminal device of each target object through a preset service message push channel, so as to perform service resource information recommendation processing to the target object based on the service resource items.

[0005] Secondly, embodiments of this specification provide a service processing apparatus, the apparatus comprising: The service monitoring module is used to update the user service status feature vector of the target user object in the platform application service in response to the service status update event of the target user object; The service processing module is used to input the user service status feature vector into a preset service logic decision topology model, and perform path matching in the service logic decision topology model to obtain the target service task scheduling branch. The service processing module is used to extract the user service execution operator associated with the target service task scheduling branch, and determine the user service task scheduling instruction corresponding to each target user object based on the user service execution operator. The user service task scheduling instruction carries service resource items and user service task configuration parameters. The service processing module is used to generate a target service guidance information data packet based on the service resource item and the user service task configuration parameters, and to distribute the target service guidance information data packet downlink to the terminal device of each target object through a preset service message push channel, so as to perform service resource information recommendation processing to the target object based on the service resource item.

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

[0007] Fourthly, this specification provides a computer program product storing at least one instruction adapted to be loaded by a processor and to execute the method steps of one or more embodiments of this specification.

[0008] Fifthly, this specification provides a computer program product storing at least one instruction adapted to be loaded by a processor and to execute the method steps of one or more embodiments of this specification.

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

[0010] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following: In one or more embodiments of this specification, a path matching method is adopted, which uses a preset service logic decision topology model driven by a real-time updated user service state feature vector for path matching. User service execution operators associated with topology branches are used to dynamically generate task scheduling instructions carrying configuration parameters, and finally, a template engine is called to fill a preset data message template to generate target service guidance information. This solves the technical problems in existing service processing technologies, such as poor flexibility in adjusting business strategies due to the use of linear hard-coded logic, difficulty in accurately capturing and responding to instantaneous changes in multi-dimensional user states, and the inability of static guidance information generation mechanisms to adapt to complex and ever-changing business contexts, leading to a misalignment between recommended resources and user needs. By leveraging user service state feature vectors and topology models, deep decoupling of complex business service decision-making logic from underlying code implementation is achieved. This enables flexible handling of non-linear business flows and conflicts through a visualized directed acyclic graph structure, improving the system's accuracy in perceiving user dynamic intentions and the efficiency of strategy iteration. Furthermore, through operator-based task execution and templated message rendering mechanisms, abstract decision results are transformed into standardized instructions and data packets, reducing the complexity of development and maintenance in multi-service scenarios and ensuring the real-time and accuracy of service guidance information generation in high-concurrency scenarios. Finally, it ensures that the service resource recommendation information delivered to the terminal highly matches the user's current state and preferences, thereby optimizing the user's interactive experience and service resource conversion rate while ensuring the stability of the service platform. Attached Figure Description

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

[0012] Figure 1 This is a flowchart illustrating a service processing method provided in an embodiment of this specification; Figure 2 This is a schematic diagram of a vector update process provided in an embodiment of this specification; Figure 3 This is a schematic diagram of a path matching process provided in an embodiment of this specification; Figure 4 This is a schematic diagram of the structure of a service processing device provided in the embodiments of this specification; Figure 5 This is a schematic diagram of the structure of an electronic device provided in the embodiments of this specification. Detailed Implementation

[0013] The technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

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

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

[0016] In one embodiment, such as Figure 1 As shown, a service processing method is proposed, which can be implemented using a computer program and can run on a service processing device based on the von Neumann architecture. This computer program can be integrated into an application or run as a standalone utility application. The service processing device can be a service platform.

[0017] In the actual business ecosystem, the service platform, as the core hub, essentially constructs a high-frequency interaction field connecting users with diverse platform services. The service platform provides users with comprehensive, multi-level platform services, such as online service consultation, personalized e-commerce resource allocation, smart government service processing, and real-time streaming content distribution. Within this field, whenever a user performs actions on a mobile terminal or web page, such as submitting risk assessments, browsing specific product categories, initiating service requests, or changing service subscriptions, these actions immediately trigger service status updates and are sent back to the service platform.

[0018] Specifically, the service processing method includes: S102: In response to the service status update event of the target user object, update the user service status feature vector of the target user object in the platform application service; Service status update events refer to trigger signals that change user business attributes during the operation of platform application services, caused by proactive interaction of the target user, automatic logical changes triggered by the platform service, or external third-party data synchronization. Examples include user completion of real-name authentication, change of user service level, expiration of user service subscription, and successful user service authentication.

[0019] The user service status feature vector refers to a digital representation model used to characterize a user in a specific business time and space. This user service status feature vector consists of multi-dimensional feature components, each of which represents a specific business service attribute (such as activity level, risk tolerance level, service risk level, historical preference weight, etc.). Through numerical encoding, it forms a high-dimensional mathematical vector that can be directly processed by computer algorithm models.

[0020] In a specific implementation scenario, those skilled in the art should understand that the fundamental step of "updating the user service status feature vector of the target user object in the platform application service in response to a service status update event of the target user object" involves relevant technical means in the field of computer data processing. Specifically, when the service platform receives a service status update event of the target user object, it obtains the original feature vector by calling a conventional database read / write interface, and updates the feature vector according to a preset dimension mapping table using conventional computer instructions such as basic direct numerical overlay, fixed-length vector dimension concatenation, and simple linear weighted merging. The service processing method based on the topology decision mechanism in this specification does not rely on an extremely complex single update algorithm; the aforementioned conventional update methods can also provide a structured input foundation for the subsequent service logic decision topology model.

[0021] In illustrative terms, while basic user service state feature vector updates can be achieved through conventional methods, some embodiments in this specification, in order to achieve deeper semantic awareness and more accurate dynamic characterization in complex and high-concurrency business ecosystems and solve the problem of lag in traditional update mechanisms, provide an optional service state feature vector evolution logic as a core advanced improvement to the aforementioned basic update methods. Specifically, the further improved implementation of updating the user service state feature vector of the target user object in the platform application service in response to the service state update event of the target user object is as follows: extracting service state metadata from multi-source heterogeneous service data streams, determining the historical user profile behavior features of the target user object, and performing feature fusion processing based on the service state metadata and the historical user profile behavior features to obtain the updated user service state feature vector. Through this dynamic and static dual-source feature fusion mechanism, the lag of historical data can be effectively eliminated, generating feature vectors with deep context awareness capabilities. Optionally, when the service platform detects a change in the service status of a target user (e.g., a user submitting a new service request online), the service platform system first intercepts the original data stream generated by this event (i.e., the multi-source heterogeneous service data stream). It extracts a snapshot of the target user's current feature vector from the distributed cache database (which can be considered the target user's historical user profile behavior features), and calls a preset feature extraction model to parse the original data stream, extracting the incremental feature components related to this service status update event. An incremental fusion algorithm is then used to overwrite or weight and merge the incremental feature components into the original feature vector snapshot (which also undergoes incremental feature fusion with historical user profile behavior features), generating an updated user service status feature vector. This approach reduces the real-time read / write pressure on the database and ensures low latency in response.

[0022] Optionally, when the service platform detects a change in the service status of a target user (e.g., a user submitting a new service request online), it triggers a full-dimensional scan of the target user, simultaneously accessing multi-source heterogeneous data sources (such as user behavior databases, interaction detail databases, and social attribute databases). It extracts all the latest original metadata associated with the user (i.e., service status metadata) and extracts a snapshot of the target user's current feature vector from a distributed cache database (which can be viewed as the target user's historical user profile behavioral features). Using feature engineering techniques such as deep learning encoders (e.g., feature extractors with autoencoder structures), these heterogeneous data (i.e., service status metadata and historical user profile behavioral features normalized to a unified feature space) are mapped to a unified feature space and re-encoded and normalized to generate a feature vector that comprehensively reflects the user's current overall status.

[0023] S104: Input the user service status feature vector into a preset service logic decision topology model, and perform path matching in the service logic decision topology model to obtain the target service task scheduling branch; A service logic decision topology model refers to a pre-constructed logical network consisting of nodes and edges connecting them, typically employing a directed acyclic graph (DAG) structure at its underlying logic level. This model defines the flow path of the service platform's business service processing logic through topological connections, enabling automatic selection of service tasks through hierarchical logical decisions upon receiving input features (user service status feature vectors).

[0024] Optionally, in this specification, the service logic decision topology model can exist in the form of a strategy canvas, a logic configuration tool based on a graphical interface. Administrators (such as operations or maintenance personnel) can drag and drop component icons representing specific logical functions (such as conditional traffic splitting, feature filtering, and timed waiting) onto the canvas and connect them using directed lines to construct a business decision flow diagram. In backend processing, the strategy canvas is compiled into structured configuration information in a directed acyclic graph format for the service logic decision topology model.

[0025] Path matching: refers to the technical process of comparing the input user service status feature vector with the judgment rules at each level in the topology model, thereby determining one or more execution paths from multiple candidate paths.

[0026] In a schematic manner, the structured configuration information of the logical decision-making topology model is first analyzed to construct a logical link topology diagram. When a user service state feature vector is input, the control logical decision-making topology model, starting from the root node, uses Boolean operators at each level to perform gating checks on specific components in the feature vector. For example, when the feature vector reaches the age-based branching node, the operator determines whether the user belongs to the target age group based on a preset threshold. Based on the logical truth value (True / False) determined by the gating check comparison result, the vector is driven to perform deterministic topology jumps between attribute branching nodes until it reaches the leaf node, i.e., the target service task scheduling branch.

[0027] S106: Extract the user service execution operator associated with the target service task scheduling branch, and determine the user service task scheduling instruction corresponding to each target user object based on the user service execution operator. The user service task scheduling instruction carries service resource items and user service task configuration parameters. User service execution operators refer to highly encapsulated business service logic functional units, which serve as the underlying technical implementation of task execution nodes in the strategy canvas. Each operator has pre-built processing logic for specific business service objectives (such as user rights calculation logic, interface call protocols, service risk verification rules, and information push logic), and can receive external parameters for dynamic instantiation and configuration.

[0028] User service task scheduling instructions refer to a structured set of instructions generated by the service platform to drive downstream business service systems to execute specific business service tasks. This instruction set is typically presented as a standardized data sequence to ensure semantic equivalence across systems.

[0029] Service resource items refer to specific rights and interests or content entities to be allocated to users, such as platform vouchers, platform service product codes, platform discount codes, platform points packages, multimedia content links, etc.

[0030] User service task configuration parameters refer to dynamic variables that control the details of task execution, such as resource validity period, trigger threshold, display style ID, and priority weight.

[0031] Intuitively, a user service execution operator can be defined as a set of declarative rule templates. Once the target service task scheduling branch is determined, the business rules associated with that branch are instantiated. At this point, a real-time conflict detection layer can be introduced to compare the currently generated instruction with the service resources already held by the user (e.g., checking if the user already holds the same type of coupon). After eliminating conflicts, the service resource items carried by the instruction are finally determined. Combined with preset business scenario parameters (e.g., activity ID), a task scheduling instruction containing resource attributes and configuration logic is generated.

[0032] S108: Generate a target service guidance information data packet based on the service resource item and user service task configuration parameters, and distribute the target service guidance information data packet downlink to the terminal device of each target object through a preset service message push channel, so as to perform service resource information recommendation processing to the target object based on the service resource item.

[0033] The target service guidance information data packet refers to a structured data entity generated by the service platform for transmission across the network. It not only encapsulates core business data (i.e., service resource items), but also contains metadata (i.e., configuration parameters) that controls the terminal display logic and interactive behavior.

[0034] A service message push channel refers to a logical or physical communication link established between a service platform and a terminal device, used to carry downlink transmission of data packets. This channel may include, but is not limited to, long-connection channels based on the TCP / IP protocol (such as WebSocket), system-level push channels provided by mobile operating system vendors (such as APNs, FCM), or API interfaces of third-party instant messaging services.

[0035] Service resource information recommendation processing refers to the process by which a terminal device, after receiving a data packet, parses and executes the instructions within it, displays service resources to the user in a specific visual form (such as pop-ups, notification messages, in-application floating windows, etc.) on the human-computer interaction interface (UI), and guides the user to respond to the interaction of the resource.

[0036] In a schematic manner, the service platform encapsulates the determined service resource items and user service task configuration parameters through a serialization component, adding data verification bits, service version numbers, and timestamps during the encapsulation process to construct a target service guidance information data packet conforming to a preset transmission protocol standard. Then, a channel detection mechanism is activated to query and identify the current network connection status and application activity status of the target terminal device in real time. If the terminal is determined to be online and active, a high-efficiency long-connection channel at the application layer is established or reused first. If the terminal is determined to be running in the background or offline, it is automatically routed to the system-level offline push channel provided by the mobile operating system vendor. The service platform then distributes the generated data packet to the selected service message push channel and simultaneously activates the distribution receipt listening logic. If no delivery confirmation signal is received from the terminal device within a preset time window threshold, an automatic retry strategy is triggered or the system switches to a backup SMS notification channel for compensation distribution. Finally, when the terminal device successfully receives the data packet, it will invoke the local notification management module according to the configuration parameters, generating corresponding service resource recommendation information in the system notification bar or application interface, thus completing the reach to the target device.

[0037] This specification employs a path matching technique that uses a pre-defined service logic decision topology model driven by real-time updated user service state feature vectors. It dynamically generates task scheduling instructions carrying configuration parameters using user service execution operators associated with topology branches, and finally calls a template engine to populate a pre-defined data message template to generate target service guidance information. This addresses the technical problems in existing service processing technologies, such as poor flexibility in adjusting business strategies due to linear hard-coded logic, difficulty in accurately capturing and responding to instantaneous changes in multi-dimensional user states, and the inability of static guidance information generation mechanisms to adapt to complex and ever-changing business contexts, leading to a misalignment between recommended resources and user needs. By leveraging user service state feature vectors and topology models, deep decoupling of complex business service decision-making logic from underlying code implementation is achieved. This enables flexible handling of non-linear business flows and conflicts through a visualized directed acyclic graph structure, improving the system's accuracy in perceiving user dynamic intentions and the efficiency of strategy iteration. Furthermore, through operator-based task execution and templated message rendering mechanisms, abstract decision results are transformed into standardized instructions and data packets, reducing the complexity of development and maintenance in multi-service scenarios and ensuring the real-time and accuracy of service guidance information generation in high-concurrency scenarios. Finally, it ensures that the service resource recommendation information delivered to the terminal highly matches the user's current state and preferences, thereby optimizing the user's interactive experience and service resource conversion rate while ensuring the stability of the service platform.

[0038] In one feasible implementation, the specific execution of distributing the target service guidance information data packet downlink through a preset service message push channel can be carried out in the following manner: Step A2: Match the target physical link from multiple preset heterogeneous message push channels according to the online status and access protocol type of the terminal device; Heterogeneous message push channels refer to multiple message transmission paths integrated by a service platform that have different transmission protocols, different vendor standards, and different applicable scenarios. For example, these include platform-built long connection channels based on TCP / UDP protocols, vendor system-level push channels based on HTTP / 2 protocols (such as cloud push services from various mobile phone manufacturers), and SMS / MMS channels based on telecom operator networks.

[0039] Target physical link: refers to the specific communication connection link that is selected to actually carry the downlink transmission of this data packet.

[0040] Step A4: Distribute the target service guidance information data packet using the target physical link and monitor the distribution receipt signal; A delivery acknowledgment signal refers to an acknowledgment message (ACK) sent by a terminal device to the server after successfully receiving and parsing a data packet. It is used to indicate the atomic completion of the transmission process.

[0041] Step A6: If the distribution receipt signal is not received within the preset time period, a retry strategy is triggered or the target service guidance information data packet is stored in the offline cache queue.

[0042] In illustrative terms, in step A2, the service platform obtains the real-time online status of the terminal device through a heartbeat detection mechanism and identifies the protocol type of the network it accesses (such as WiFi, 4G / 5G). The system has a built-in priority routing table. If the terminal is detected to be in an "active foreground application" and "healthy long connection" state, it prioritizes matching the platform's self-built WebSocket long connection as the target physical link to ensure millisecond-level latency. If the terminal is detected to be in a "background running" or "long connection disconnected" state, it automatically adapts and switches to the corresponding vendor system-level push channel as the target physical link based on the device fingerprint recognition result. Subsequently, in step A4, the system encapsulates the data packet and pushes it into the selected physical link, while simultaneously starting a countdown listener. Finally, in step A6, if the listener does not capture the distribution receipt signal within a preset short timeout threshold (e.g., 500 milliseconds), it is determined to be network jitter and triggers an immediate retry strategy, attempting to resend within a limited number of times (e.g., 3 times). If the retry still fails, it downgrades to calling the SMS gateway channel for final fallback delivery.

[0043] In the embodiments described in this specification, intelligent routing matching of heterogeneous channels through the above-described method achieves dynamic optimization of downlink physical links. This ensures low-latency interaction using self-built channels when the terminal is online, and basic reach is guaranteed using vendor channels when offline, thereby improving the success rate of service information delivery across all scenarios. Combined with a dual guarantee mechanism of receipt monitoring and retry caching, a highly robust message distribution closed loop is constructed, ensuring that even in extreme abnormal situations such as network jitter or momentary interruption, high-value service guidance information data packets can still be reliably delivered to the terminal device through immediate retry or subsequent caching consumption mechanisms, avoiding service interruptions and enhancing the system's fault tolerance and user experience consistency.

[0044] Optional, please see Figure 2 , Figure 2 This is a flowchart illustrating a vector update process proposed in this specification. Specifically, the execution of updating the user service status feature vector of the target user object in the platform application service can be referenced as follows: S202: Listen to the service status update event in real time through an asynchronous message queue in the multi-source heterogeneous service data stream, and extract the service status metadata in the multi-source heterogeneous service data stream; Asynchronous message queues refer to middleware systems (such as Kafka, RocketMQ, or RabbitMQ) deployed in a service architecture. They employ a producer-consumer model for non-blocking message passing between different service components. They allow decoupling between data producers (such as user terminals or business gateways) and data processors (such as feature calculation engines), thus enabling data buffering and peak smoothing under high concurrency traffic.

[0045] Multi-source heterogeneous service data flow refers to a data set that originates from different business domains and system levels within the service ecosystem and has a differentiated data structure.

[0046] Service status metadata refers to the standardized key information fields with clear business semantics extracted from the aforementioned raw, redundant, and poorly formatted heterogeneous data streams after cleaning, parsing, and mapping. For example, the user ID, operation timestamp, request interface name, and return status code extracted from a complex HTTP request log are examples of service status metadata.

[0047] As an illustration, the service platform deploys log collection agents on various business application server nodes. These agents capture raw log streams generated by service status update events in real time through instant polling or file system listening. The collection agents encapsulate the captured multi-source heterogeneous data into message objects and asynchronously deliver them to a pre-defined message queue Topic partition. The streaming computing engine, acting as the consumer, subscribes to and pulls these message objects in real time. The streaming computing engine uses a pre-defined regular expression library to perform pattern matching and field segmentation on the heterogeneous text data, removing invalid debugging information and garbled characters. Finally, based on a predefined metadata dictionary, the cleaned key fields are mapped to a standardized key-value pair structure, thus completing the extraction of service status metadata.

[0048] S204: Based on the historical user profile behavior characteristics of the target user object and the service status metadata, perform user profile tag update processing to obtain target user profile behavior tags that represent the user object profile. Historical user profile behavioral characteristics refer to the set of business service attributes accumulated by the target user object in the service platform database up to the time this update event was triggered.

[0049] The user profile tag update process uses the latest real-time data (i.e., service status metadata) to correct, enhance, or reset existing historical data. This process aims to eliminate the lag in historical data, enabling profile tags to accurately reflect the user's business service intent at the current moment.

[0050] Target user profile behavior tags refer to the tagged data output after update processing, which is used to represent the latest state of the user object.

[0051] This process illustratively involves retrieving historical user profile behavior features from the user profile database, extracting the corresponding last update timestamp, calculating the time difference between the current time and the last update time, and using a preset time decay function to calculate the time decay factor of the historical features. The extracted service status metadata is then incorporated, and a weighted moving average algorithm is employed to fuse the decayed historical features with the current metadata values. In this calculation, service status metadata is typically given a higher immediate weight to reflect the influence of the latest behavior. Finally, the calculated numerical results are mapped to a preset label range to determine the updated target user profile behavior labels.

[0052] S206: Based on the target user profile behavior tags and service resource recommendation items, perform service resource recommendation risk assessment processing to obtain service resource recommendation risk features, and then perform vector fusion of the service resource recommendation risk features and the service status metadata to obtain the user service status feature vector of the target user object in the platform application service.

[0053] Service resource recommendation risk assessment refers to the quantitative calculation process that uses algorithmic models to determine the potential service risks (such as compliance risks and user aversion risks) that may arise when recommending specific service resources to users with specific profile tags.

[0054] Service resource recommendation risk characteristics refer to the output results of risk assessment and processing, which are usually represented as a set of probability value distributions or high-dimensional hidden layer vectors to characterize the strength of various risk factors.

[0055] In one feasible implementation, the service platform loads a preset risk rule matrix. This matrix defines the admission threshold between user profile tags and service resource recommendations (e.g., if the user tag is R2 conservative, then the recommended item R5 high-risk fund corresponds to a high risk level). The target user profile behavior tags are substituted into the matrix for retrieval and matching, outputting a set of discrete risk scores, which are then normalized to generate service resource recommendation risk features.

[0056] Next, a vector fusion operation is performed, employing a feature concatenation strategy. The aforementioned service resource recommendation risk features are used as the header, and the vector generated from the extracted service status metadata (such as current time and device ID) after one-hot encoding is used as the tail. The two are directly concatenated along the feature dimension, and the dimensionality reduction process (such as using PCA principal component analysis) is applied to the concatenated long vector to obtain the final user service status feature vector. This method has low computational overhead, and the risk features retain their original physical meaning in the vector, facilitating subsequent interpretability analysis.

[0057] In the embodiments described in this specification, the above-mentioned method utilizes asynchronous message queues and heterogeneous data extraction mechanisms to achieve physical decoupling between service status update event capture and downstream processing logic. This ensures high-throughput concurrent data intake while eliminating interference from data source format differences. Through the dynamic update mechanism of user profile tags, it is ensured that user characteristics can evolve in real time with changes in user behavior, eliminating the lag in historical profiles and generating deep semantic feature vectors with context awareness. This makes the feature vectors input into the final decision model not only include static business attributes but also represent dynamic risk coupling relationships in the current environment, thereby improving the security and accuracy of the platform in scheduling service tasks and recommending resources in complex and ever-changing scenarios.

[0058] In one feasible implementation, the process of performing service resource recommendation risk assessment based on the target user profile behavior tags and service resource recommendation items to obtain service resource recommendation risk features is specifically executed. Then, the service resource recommendation risk features are vector-fused with the service status metadata to obtain the user service status feature vector of the target user object in the platform application service. This can be achieved by referring to the following method: Step B2: Based on the target user profile behavior tags and the service attribute characteristics of the service resource recommendation items, a deep risk assessment model is used to determine the service resource recommendation risk characteristics of the target user object under the multi-dimensional service risk evaluation system; The deep risk assessment big model refers to a large model adapted to specific scenarios for deep risk assessment based on the Large Language Model (LLM). While this model can reuse the underlying self-attention mechanism and sequence modeling capabilities of the LLM, its input layer has undergone multimodal adaptation, enabling it to simultaneously handle unstructured text data (such as logs and comments) and structured business service data. Furthermore, based on general pre-training, the model has undergone domain-adaptive fine-tuning using a large number of labeled business risk samples, thus possessing the ability to accurately identify implicit risk features in complex business contexts.

[0059] A multi-dimensional service risk assessment system refers to a set of indicators built by a service platform to comprehensively quantify business risks. This system deconstructs service risks into multiple orthogonal dimensions, such as: compliance dimension (whether it meets legal regulations and platform access red lines), fraud probability dimension (whether there is suspicion of machine-generated traffic or identity forgery), and user experience dimension (whether recommended content will cause user aversion or complaints).

[0060] Service attribute features refer to the inherent business attributes of service resource recommendation items.

[0061] The service resource recommendation risk feature is used to characterize the results of the above multidimensional risk assessment system as a high-dimensional numerical vector. The direction and magnitude of this vector in mathematical space accurately describe the intensity of the recommendation behavior in each risk dimension.

[0062] In one feasible implementation, the service platform invokes a deep risk assessment model that has been pre-tuned specifically for risk control. This model employs a multi-tower deep neural network structure adapted to structured business data at its underlying architecture. Target user profile behavioral tags (including user ID, discrete preference tags, and continuous activity values) are input into the user feature processing tower of the deep risk assessment model. Simultaneously, service attribute features of recommended service resources (including product ID, risk level, and category attributes) are input into the resource feature processing tower of the deep risk assessment model. Within each feature tower, shared or independent embedding layers are used to map high-dimensional sparse categorical features into low-dimensional dense real-valued vectors. Numerical features are normalized and concatenated to perform deep nonlinear interactive operations on user representation vectors and resource representation vectors using a multilayer perceptron, capturing the implicit matching logic between user attributes and resource attributes. Finally, the top layer of the model employs a multi-task learning architecture, calculating probability values ​​under different risk dimensions through multiple independent task output heads, thereby outputting service resource recommendation risk features covering multiple task risk dimensions such as compliance, user experience, and fraud probability.

[0063] Step B4: Use a deep risk assessment model to determine the attention weight distribution of the service resource recommendation risk features and the service status metadata. The attention weight distribution is used to quantify the degree of correlation and promotion of different service risk assessment dimensions on the current service status update event under the multi-dimensional service risk assessment system. Attention weight distribution refers to a set of probability values ​​output in the attention layer of a deep risk assessment model. This set is generated by calculating the similarity between the query vector and the key vector, and then processing it through a normalization function. Each value in this set typically ranges from 0 to 1, and the sum is 1. The magnitude of these values ​​directly reflects the degree to which the model focuses on a specific feature dimension.

[0064] The degree of correlation promotion refers to the quantitative indicator of the activation, amplification, and inhibition effects of external environmental factors (i.e., service status metadata) on internal risk factors (i.e., service risk assessment dimensions) in a specific business service scenario.

[0065] In a schematic manner, a deep risk assessment model inputs service status metadata and service resource recommendation risk features into multiple parallel attention heads. Each attention head has an independent projection parameter matrix, aiming to observe the relationship between risk and environment from different semantic subspaces. Within each attention head, the large model infers the cross-attention of service status metadata to different service risk assessment dimensions, identifying explicit correlation features (such as the correlation between time and fraud) and implicit correlation features (such as the correlation between device model and compliance). Then, the outputs of all attention heads are concatenated and linearly fused, and a comprehensive attention weight distribution is generated through a global gating network. In this way, the degree of promotion of multiple different types of correlations can be quantified simultaneously. For example, in the same scenario, it can identify both the high promotion of remote login to user security and the high promotion of older devices to user experience, thereby achieving a holistic perception of complex risk situations.

[0066] Step B6: Based on the attention weight distribution, perform non-linear weighted aggregation on the service resource recommendation risk features and the service state metadata to generate a user service state feature vector that represents the coupling relationship between service resource recommendation risk and service context.

[0067] Nonlinear weighted aggregation refers to a complex mathematical operation that linearly weights and sums (or performs a Hadamard product) the feature components according to their weight values, and then inputs the result into a nonlinear activation function. The aim of nonlinear weighted aggregation is to generate vectors that fit the complex, non-planar logical boundaries of the data, rather than simply superimposing linear values.

[0068] Service context refers to the spatiotemporal environment and device state of a user, constructed from service state metadata.

[0069] Coupling refers to the dynamic relationship of mutual dependence and influence between two or more variables. In this step, it specifically refers to the fact that business risks are not static, but can change qualitatively with changes in the service context (for example, the same user service behavior may be low risk in a commonly used location, but high risk in a remote location).

[0070] The user service status feature vector refers to the numerical vector that is ultimately output as input to the decision model.

[0071] In a schematic representation, a deep risk assessment model uses attention weight distribution as weighting coefficients to perform a dimension-wise weighted summation of service resource recommendation risk features, which are represented as value vectors. This generates a reconstructed risk context vector. In this vector, the values ​​of risk dimensions activated by high weights in the attention mechanism (such as fraud risk) are significantly amplified, while the values ​​of irrelevant dimensions are suppressed. This risk context vector is then concatenated with the original service state metadata vector to form a joint feature vector. This joint feature vector is input into the fully connected layer at the end of the deep risk assessment model. In this fully connected layer, a pre-defined nonlinear activation function (such as ReLU) is used to perform nonlinear mapping and dimensionality compression on the joint feature vector, outputting the final user service state feature vector. This vector, through nonlinear transformation, successfully fuses discrete risk signals and environmental features into a unified semantic entity, accurately representing the complex coupling state between the two.

[0072] This specification utilizes the powerful semantic reasoning and feature representation capabilities of a deep risk assessment model to accurately extract hidden high-order risk patterns between users and resources from massive sparse business data. This breaks through the expression bottleneck of traditional statistical models. Through a dynamic weight allocation network constructed using an attention mechanism, the correlation and promotion degree of the current service context on different risk dimensions are quantified. This is equivalent to giving the system the ability to automatically focus on key risk points in specific environments (e.g., automatically focusing on the fraud dimension in abnormal environments). Then, the service state feature vector generated by nonlinear weighted aggregation abstracts the deep semantic entities of the environment-risk coupling relationship. This enables the subsequent service logic decision topology model to make accurate task scheduling decisions based on this high-confidence feature vector, improving the risk control robustness and service recommendation effectiveness of the service platform in complex dynamic environments.

[0073] Optionally, the following example illustrates the model training process for a large-scale deep risk assessment model: In some embodiments, a pre-trained basic large language model can be obtained and adapted to a deep risk assessment scenario to obtain a deep risk assessment large model. However, directly applying the basic large language model to a deep risk assessment scenario is often difficult to adapt to new deep risk assessment scenarios. Therefore, the basic large language model is first obtained to create an initial deep risk assessment large model, and sample data for the new deep risk assessment scenario is obtained. This sample data includes sample user profile behavior tags and sample service attribute features of sample service resource recommendation items. Since the basic large language model is usually a pre-trained open-source AIGC model with content generation capabilities, this specification only needs to adapt it to the deep risk assessment scenario. Specifically, the sample data can be used to fine-tune the initial deep risk assessment large model. After the model fine-tuning training is completed, a deep risk assessment large model adapted to the deep risk assessment scenario is obtained.

[0074] Model creation: Obtain the basic large language model, create an initial deep risk assessment scenario plugin model for deep risk assessment scenarios, and form an initial deep risk assessment large model based on the basic large language model and the initial deep risk assessment scenario plugin model; the basic large language model (MLLM) includes, but is not limited to, the DeepSeek large model, the GPT series large models, etc.

[0075] Sample data acquisition: Acquire sample data for new in-depth risk assessment scenarios. This sample data includes sample user profiles, behavioral tags, and sample service attribute features of sample service resource recommendations in the in-depth risk assessment scenario.

[0076] Sample data annotation: User service status feature vector labels representing the coupling relationship between service resource recommendation risk and service context, based on the annotation of deep risk assessment requirements in deep risk assessment scenarios.

[0077] Model training process: Input the sample data into the initial deep risk assessment model for at least one round of model training. During the forward training of the model: Based on the sample data, the initial deep risk assessment model is used to process and obtain the predicted user service status feature vector. During the reverse training of the model, the model loss value is determined by the model loss function based on the predicted user service status feature vector and the user service status feature vector label. Based on the model loss value, the model parameters are adjusted in the initial deep risk assessment model to obtain the trained deep risk assessment model.

[0078] An illustrative example of an initial deep risk assessment scenario plugin model can be created based on a machine learning model.

[0079] Optionally, the model's training termination conditions may include, for example, the loss function value being less than or equal to a preset loss function threshold, or the number of iterations reaching a preset threshold. Specific training termination conditions can be determined based on actual circumstances and are not specifically limited here.

[0080] It should be noted that the machine learning models involved in one or more embodiments of this specification include, but are not limited to, fitting of one or more of the following machine learning models: Convolutional Neural Network (CNN) model, Deep Neural Network (DNN) model, Recurrent Neural Networks (RNN) model, embedding model, Gradient Boosting Decision Tree (GBDT) model, Logistic Regression (LR) model, etc.

[0081] Optional: Based on the model loss value, adjust the model parameters of the initial deep risk assessment scenario plugin model in the initial deep risk assessment large model. This can keep the model structure of the basic large language model unchanged until the model training termination condition is met, thus obtaining the basic large language model and the deep risk assessment scenario plugin model. This completes the model fusion of the basic large language model and the deep risk assessment scenario plugin model, resulting in a trained deep risk assessment large model.

[0082] An illustrative example of an initial deep risk assessment scenario plugin model can be created based on a machine learning model.

[0083] Optional, please refer to Figure 3 , Figure 3 This is a flowchart illustrating a path matching process. Specifically, the path matching process in the service logic decision topology model to obtain the target service task scheduling branch can be performed as follows: S302: Parse the structured configuration information of the logical decision topology model and extract the directed acyclic graph logical links composed of multiple logical judgment nodes, attribute diversion nodes and task execution operator nodes; A directed acyclic graph (DAG) logical link refers to a specific topological structure composed of nodes and directed edges in a service logic decision-making topology model. The data flow in this structure is directional, ensuring that the decision-making process can necessarily flow from the starting node to the ending node.

[0084] Logical judgment nodes refer to the intermediate nodes in a directed acyclic graph (DAG) that are responsible for performing conditional judgments, and usually contain specific comparison logic (such as greater than, less than, or contain).

[0085] Attribute-based traffic splitting nodes refer to branch nodes that direct traffic to different downstream paths based on the upstream judgment results.

[0086] Task execution operator nodes refer to the leaf nodes in a DAG, representing the final determined specific business service actions.

[0087] As an illustration, the service platform reads structured configuration information stored in the configuration center through a pre-built model loader. The loader deserializes and parses the file to construct a directed acyclic graph logical link object in memory. This object clearly defines the parent-child connection relationships and hierarchical depth between various logical judgment nodes (such as regional judgment), attribute diversion nodes (such as high / medium / low risk diversion), and task execution operator nodes (such as pushing Class A coupons).

[0088] S304: Using the user service status feature vector as input parameter, Boolean operation operators of each level of logical discrimination node are triggered sequentially from the root node of the directed acyclic graph logical link to compare the user service status feature vector with the node preset threshold to obtain the comparison result; Boolean operators are atomic functions pre-installed within logical decision nodes to perform logical judgments. They accept numerical or character input, perform operations such as greater than, less than, equal to, contain, and regular expression matching, and output a binary result of either True or False.

[0089] In a schematic manner, the received user service status feature vector is loaded into the runtime memory, and the root node, the sole entry point of the directed acyclic graph logical link, is locked as the currently active node. The decision engine reads the feature index configured in the root node, extracts the corresponding dimension component values ​​from the feature vector, and activates the node's built-in Boolean operator. The extracted dimension component values ​​are then mathematically compared with the node's preset threshold. If the comparison condition is met (e.g., the feature value is greater than the threshold), the operator outputs a logical truth value, and the next level of child nodes is unlocked according to the topological connection relationship. The currently active pointer is then moved to that child node to continue the comparison. If the comparison condition is not met, the operator outputs a logical false value, immediately interrupting the subsequent traversal of that branch, or backtracking to the previous level branch node to find other paths. This process proceeds layer by layer along the logical link until a leaf node is reached or all paths are blocked, thus generating a complete comparison result chain.

[0090] In one feasible implementation, the comparison of the user service status feature vector with a preset threshold of the node to obtain the comparison result can be performed in the following manner: Step C2: Extract the target attribute feature components from the user service status feature vector that correspond to the target attribute dimension of the current logical discrimination node; The target attribute feature component refers to a single-dimensional value or sub-vector extracted from the multi-dimensional user service status feature vector based on the configuration index of the current node, and used for this specific determination. For example, in the region determination node, this component is the specific bit value representing the region in the feature vector.

[0091] In a schematic representation, when the service logic decision topology model traverses the logical links of the directed acyclic graph and reaches the current logical discrimination node, it reads the metadata description file configured for that node. This file defines the names of the business fields that the node needs to verify and the physical storage location information of those fields in the feature vector (such as index or offset). A feature mapping table is established, which maintains the correspondence between business service attributes and vector dimensions. The mapping table is queried according to the target attribute dimension of the node to obtain the corresponding index address. This index address is used to slice or mask the high-dimensional user service state feature vector to accurately extract the data fragments at the corresponding positions.

[0092] Step C4: Call the Boolean operator to perform boundary value verification on the target attribute feature components, so as to verify the confidence score of the target attribute feature components deviating from the preset threshold of the node; Boundary value verification refers to a non-binary numerical evaluation process. It focuses on calculating the distance, deviation, or probability density of the input value relative to a preset threshold or within a specific interval.

[0093] A confidence score is a normalized numerical value used to quantify the degree of certainty that an input feature meets the criteria. A higher score indicates a higher confidence level that the feature value indeed meets the criteria.

[0094] This example illustrates how a predefined tolerance radius parameter in the node configuration is read using Boolean operators (e.g., if the threshold is 100 and the tolerance radius is 5, the buffer is [9, 105]). The position of the target attribute feature component on the number axis is determined. If the feature component is above the buffer (i.e., greater than 105), the highest confidence score (e.g., 1.0) is assigned; if it is below the buffer (i.e., less than 95), the lowest confidence score (e.g., 0.0) is assigned. If the feature component falls inside the buffer, linear interpolation is performed, and the confidence score is calculated based on the feature value's relative position within the buffer. For example, if the feature value is exactly in the center of the buffer (e.g., equal to the threshold), the score is 0.5; if the feature value is in the upper quartile of the buffer, the score is 0.75.

[0095] Step C6: Determine the Boolean truth value of the corresponding logical branch based on the mapping relationship between the confidence score and the preset pass rate, and generate the comparison result based on the Boolean truth value.

[0096] The process involves reading the configuration parameters of the current logical judgment node to obtain a preset pass rate value. This value is typically preset by business experts based on the node's importance in the overall risk control model (e.g., a pass rate of 0.9 for core access nodes and 0.6 for non-core nodes). Next, a mapping comparison operation is performed, comparing the confidence score with the preset pass rate. This mapping follows a threshold truncation principle: if the confidence score is greater than or equal to the preset pass rate, the feature is considered to have a slight deviation but generally meets business expectations, and the Boolean truth value of the corresponding logical branch is set to True; conversely, if the confidence score is less than the preset pass rate, the deviation is deemed too large and unacceptable, and the Boolean truth value is set to False. Finally, a standardized comparison result object is generated based on this determined Boolean truth value and returned to the topology traversal engine. This drives the engine to activate the downstream path connected to the "True" port of the node, or trigger blocking logic when the result is False.

[0097] S306: Based on the logical truth value determined by the comparison result, drive the user service state feature vector to perform topological jumps between the attribute distribution nodes to obtain at least one service task scheduling branch, and determine the target service task scheduling branch with the highest semantic fit with the user service state feature vector in the service task scheduling branch.

[0098] In a schematic manner, based on the logical truth value determined by the comparison results, the feature vector is controlled to perform hierarchical jumps along directed edges between attribute splitting nodes. In complex scenarios, multiple candidate paths that meet the conditions may be triggered simultaneously. At this time, the cosine similarity between the feature vector and the scene semantic vector (aggregated from the semantic labels of all nodes on the branch) carried by each candidate service task scheduling branch is calculated, i.e., semantic fit. Finally, the branch with the highest fit score (e.g., a score of 0.95) is selected as the unique target service task scheduling branch.

[0099] In this specification, the above-described method utilizes a visualized directed acyclic graph structure to completely decouple complex business logic from the underlying code implementation. This allows operations personnel to flexibly configure non-linear decision-making paths, improving the agility of strategy iteration. Secondly, through Boolean operations and topology jump mechanisms, the flow of feature vectors in the logical chain is ensured to have mathematical determinism and traceability, guaranteeing the system's execution stability. Furthermore, by introducing semantic fit as the final decision-making dimension, the system can intelligently identify and lock the optimal strategy branch that best matches the deep semantics of the current user's characteristics among multiple candidate paths that meet hard thresholds. This demonstrates strong robustness and accuracy in handling high-concurrency and high-complexity business conflicts, achieving the ultimate personalization of the service experience.

[0100] In one feasible implementation, after obtaining the target service task scheduling branch through path matching in the service logic decision topology model, the following approach can also be referenced: Step D2: Synchronously activate the shadow execution path instruction corresponding to the target service task scheduling branch; A shadow execution path refers to a set of logical links that run in parallel in the background of a service. It typically employs a traditional risk control model based on deterministic rules or a stable model from a previous version. Shadow execution path instructions are machine-executable instructions specific to the shadow execution path.

[0101] Step D4: Calculate the policy entropy deviation between the real path instruction corresponding to the target service task scheduling branch and the shadow execution path instruction. The policy entropy deviation is used to quantify the output uncertainty of the target service logical decision topology model in the current service context. Policy entropy deviation refers to a metric that quantifies the difference in distribution between the output of the master model (real path) and the output of the shadow model (shadow path) using the concept of entropy in information theory (such as KL divergence or cross entropy). This policy entropy deviation reflects the degree to which current AI decisions deviate from traditional safety baselines.

[0102] Step D6: Determine whether the policy entropy deviation exceeds the warning threshold; Step D8: If the limit is exceeded, the circuit breaker mechanism will be executed to reset the target service boot information data packet to be generated to the baseline security template; A baseline security template refers to a set of static service content that has undergone rigorous compliance review, is risk-free, and has broad applicability. Examples include generic service homepages or system busy notifications, rather than personalized sensitive recommendations.

[0103] Step D10: If it does not exceed the limit, then execute the step of extracting the user service execution operator associated with the target service task scheduling branch.

[0104] Schematic illustration: In step D2, when the engine matches the target service task scheduling branch (i.e., the real path) in the complex topology model through the aforementioned step S306, it does not immediately execute the business action under that branch. Instead, it synchronously activates a shadow execution path instruction using asynchronous threads or parallel coroutines. This shadow execution path typically runs a deterministic rule model built based on expert experience (e.g., based on a simple blacklist or whitelist). Although this deterministic rule model has weak generalization ability, it possesses absolute compliance and security. By inputting the same user service state feature vector into this shadow path, a referential shadow decision result is quickly generated.

[0105] Further, in step D4, an information theory algorithm is introduced to quantify the difference between the two. This is achieved by obtaining the probability distribution corresponding to the real path instruction (e.g., a confidence level of 0.9 for recommending product A) and the probability distribution corresponding to the shadow execution path instruction. Specifically, the distance between the two probability distributions, i.e., the policy entropy deviation, is calculated using the relative entropy formula or the mean squared error (MSE) algorithm. This policy entropy deviation objectively reflects the extent to which the main model's decision deviates from the safety baseline; the greater the deviation, the more aggressive or anomalous the main model's decision, and the higher the uncertainty and potential risk (such as model illusion) of its output.

[0106] Further steps D6 and D8 compare the calculated policy entropy deviation with a preset warning threshold. If the policy entropy deviation exceeds the threshold, it is determined that the current main model's decision may have uncontrollable AI risks (such as recommending high-risk content to minors, while the shadow model strongly opposes it). At this point, the instruction circuit breaker mechanism is immediately triggered, physically blocking the issuance of the real path instruction and discarding the personalized content generated by that instruction. Then, a preset configuration center is invoked to read the baseline security template (such as a general service knowledge popularization page or a standard welcome message), and the guide information data packet to be generated is forcibly reset to this security template. This process ensures that even if the AI ​​model experiences logical breakdown in extreme scenarios, the final information delivered to the user always remains above the safety and compliance baseline.

[0107] Further in step D10, if the policy entropy deviation does not exceed the threshold, it means that although the decision of the main model is personalized, it is still within the interpretable range of the safety baseline. At this time, the safety lock is released, and the user service execution operator that extracts the real path association is executed normally to generate high-precision personalized guidance information and send it to the client.

[0108] In this specification, a dual-track checkpoint system combining AI intelligent decision-making with traditional rule verification is constructed using the above method. The policy entropy deviation serves as a safety benchmark, which can capture abnormal deviations of the main model's decision from the safety baseline in real time. Combined with the instruction circuit breaker mechanism, it ensures that while pursuing high personalization and high intelligence, a safety bottom line is always maintained, achieving high robustness and high reliability of the platform's business system in complex environments.

[0109] The following will combine Figure 4 This specification provides a detailed description of the service processing apparatus provided in the embodiments. It should be noted that... Figure 4 The service processing device shown is used to execute this specification. Figures 1-3 The methods shown in the embodiments are illustrated for ease of explanation, showing only the parts related to the embodiments of this specification. For specific technical details not disclosed, please refer to this specification. Figures 1-3 The example shown.

[0110] Please see Figure 4 This diagram illustrates the structure of a service processing device according to an embodiment of this specification. The service processing device 1 can be implemented as all or part of a device through software, hardware, or a combination of both. According to some embodiments, the service processing device 1 includes a service monitoring module 11 and a service processing module 12, specifically used for: The service monitoring module 11 is used to update the user service status feature vector of the target user object in the platform application service in response to the service status update event of the target user object. Service processing module 12 is used to input the user service status feature vector into a preset service logic decision topology model, and perform path matching in the service logic decision topology model to obtain the target service task scheduling branch. The service processing module 12 is used to extract the user service execution operator associated with the target service task scheduling branch, and determine the user service task scheduling instruction corresponding to each target user object based on the user service execution operator. The user service task scheduling instruction carries service resource items and user service task configuration parameters. The service processing module 12 is used to generate a target service guidance information data packet based on the service resource item and the user service task configuration parameters, and to distribute the target service guidance information data packet downlink to the terminal device of each target object through a preset service message push channel, so as to perform service resource information recommendation processing to the target object based on the service resource item.

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

[0112] The example numbers in this specification are for descriptive purposes only and do not represent the superiority or inferiority of the examples.

[0113] This specification also provides a computer storage medium that can store multiple instructions adapted to be loaded and executed by a processor as described above. Figures 1-3 The service processing method described in the illustrated embodiment can be found in the following document for a detailed execution process. Figures 1-3 The specific details of the illustrated embodiments will not be elaborated here.

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

[0115] Please refer to Figure 5 This is a structural block diagram of an electronic device provided in an embodiment of this specification. The electronic device in this specification may 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, memory 1020, input device 1030, and output device 1040 may be connected to each other via the bus 1050.

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

[0117] The memory 1020 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 1020 may include non-transitory computer-readable storage medium. The memory 1020 may be used to store instructions, programs, code, code sets, or instruction sets.

[0118] The input device 1030 is used to receive input instructions or data, and includes, but is not limited to, a keyboard, mouse, camera, microphone, or touch device. The output device 1040 is used to output instructions or data, and includes, but is not limited to, a display device and a speaker. In this embodiment, the input device 1030 can be a temperature sensor for acquiring the operating temperature of the electronic device. The output device 1040 can be a speaker for outputting audio signals.

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

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

[0121] exist Figure 5 In the electronic device, the processor 1010 can be used to call a program stored in the memory 1020 and execute it to implement the service processing method as described in the various method embodiments of this specification.

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

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

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

Claims

1. A service processing method, characterized in that, Applied to a service platform, the method includes: In response to a service status update event of a target user object, update the user service status feature vector of the target user object in the platform application service; The user service status feature vector is input into a preset service logic decision topology model, and path matching is performed in the service logic decision topology model to obtain the target service task scheduling branch. Extract the user service execution operator associated with the target service task scheduling branch, and determine the user service task scheduling instruction corresponding to each target user object based on the user service execution operator. The user service task scheduling instruction carries service resource items and user service task configuration parameters. Based on the service resource items and user service task configuration parameters, a target service guidance information data packet is generated. The target service guidance information data packet is then distributed downlink to the terminal device of each target object through a preset service message push channel, so as to perform service resource information recommendation processing to the target object based on the service resource items. The step of obtaining the target service task scheduling branch through path matching in the service logic decision topology model includes: The structured configuration information of the logical decision topology model is analyzed to extract a directed acyclic graph (DAG) logical link consisting of multiple logical judgment nodes, attribute distribution nodes, and task execution operator nodes. Using the user service state feature vector as input parameters, Boolean operators at each level of the DAG logical link are triggered sequentially, starting from the root node, to compare the user service state feature vector with preset thresholds for each node. Based on the logical truth value determined by the comparison result, the user service state feature vector is driven to perform topological jumps between the attribute distribution nodes to obtain at least one service task scheduling branch. Within this service task scheduling branch, the target service task scheduling branch with the highest semantic fit to the user service state feature vector is determined.

2. The method according to claim 1, characterized in that, The step of comparing the user service status feature vector with a preset threshold for the node to obtain the comparison result includes: Extract the target attribute feature components from the user service status feature vector that correspond to the target attribute dimension of the current logical discrimination node; The Boolean operator is invoked to perform boundary value verification on the target attribute feature components, so as to verify the confidence score of the target attribute feature components deviating from the preset threshold of the node; The Boolean truth value of the corresponding logical branch is determined based on the mapping relationship between the confidence score and the preset pass rate, and the comparison result is generated based on the Boolean truth value.

3. The method according to claim 1, characterized in that, The method further includes: Synchronously activate the shadow execution path instruction corresponding to the target service task scheduling branch; Calculate the policy entropy deviation between the actual path instruction corresponding to the target service task scheduling branch and the shadow execution path instruction. The policy entropy deviation is used to quantify the output uncertainty of the target service logical decision topology model in the current service context. Determine whether the policy entropy deviation exceeds the warning threshold; If the limit is exceeded, the circuit breaker mechanism will be executed to reset the target service boot information data packet to be generated to the baseline security template. If the number of cases does not exceed the limit, then the step of extracting the user service execution operator associated with the target service task scheduling branch is executed.

4. The method according to claim 1, characterized in that, The downlink distribution of the target service guidance information data packet through a preset service message push channel includes: Based on the online status and access protocol type of the terminal device, a target physical link is matched from multiple preset heterogeneous message push channels; The target service guidance information data packet is distributed using the target physical link, and the distribution receipt signal is monitored; If the distribution receipt signal is not received within the preset time period, a retry strategy is triggered or the target service guidance information data packet is stored in an offline cache queue.

5. The method according to claim 1, characterized in that, Updating the user service status feature vector of the target user object in the platform application service includes: Extract service status metadata from multi-source heterogeneous service data streams and determine the historical user profile behavior characteristics of the target user object; The user service status feature vector is obtained by performing feature fusion processing based on the service status metadata and the historical user profile behavior features.

6. The method according to claim 5, characterized in that, The process of extracting service status metadata from multi-source heterogeneous service data streams and determining the historical profile features of the target user object, followed by feature fusion processing based on the service status metadata and the historical profile features to obtain a user service status feature vector, includes: By listening to the service status update events in real time through an asynchronous message queue, the service status metadata in the multi-source heterogeneous service data stream is extracted to determine the historical user profile behavior characteristics of the target user object. Based on the historical user profile behavior features of the target user object and the service status metadata, user profile tag update processing is performed to obtain target user profile behavior tags that characterize the user object profile. Based on the target user profile behavior tags and service resource recommendation items, service resource recommendation risk assessment processing is performed to obtain service resource recommendation risk features. The service resource recommendation risk features are then fused with the service status metadata to obtain the user service status feature vector of the target user object in the platform application service. Alternatively, a preset feature extraction model is called to parse and extract incremental feature components related to the service status update event from the multi-source heterogeneous service data stream. Based on the incremental feature components, the historical user profile behavior features are incrementally fused to obtain the user service status feature vector. Alternatively, the service status metadata and the normalized features of the historical user profile behavior are encoded into a unified feature space to obtain the user service status feature vector.

7. The method according to claim 6, characterized in that, The process of performing service resource recommendation risk assessment based on the target user profile behavior tags and service resource recommendation items to obtain service resource recommendation risk features, and then performing vector fusion of the service resource recommendation risk features with the service status metadata to obtain the user service status feature vector of the target user object in the platform application service, including: Based on the target user profile behavior tags and the service attribute characteristics of the service resource recommendation items, a deep risk assessment model is used to determine the service resource recommendation risk characteristics of the target user under the multi-dimensional service risk evaluation system. A deep risk assessment model is used to determine the attention weight distribution between the service resource recommendation risk characteristics and the service status metadata. The attention weight distribution is used to quantify the degree of correlation and promotion of different service risk assessment dimensions on the current service status update event under the multi-dimensional service risk assessment system. Based on the attention weight distribution, the service resource recommendation risk features and the service state metadata are non-linearly weighted and aggregated to generate a user service state feature vector that represents the coupling relationship between service resource recommendation risk and service context.

8. A service processing apparatus, characterized in that, The device, applied to a service platform, includes: The service monitoring module is used to update the user service status feature vector of the target user object in the platform application service in response to the service status update event of the target user object; The service processing module is used to input the user service status feature vector into a preset service logic decision topology model, and perform path matching in the service logic decision topology model to obtain the target service task scheduling branch. The service processing module is used to extract the user service execution operator associated with the target service task scheduling branch, and determine the user service task scheduling instruction corresponding to each target user object based on the user service execution operator. The user service task scheduling instruction carries service resource items and user service task configuration parameters. The service processing module is used to generate a target service guidance information data packet based on the service resource item and the user service task configuration parameters, and to distribute the target service guidance information data packet downlink to the terminal device of each target object through a preset service message push channel, so as to perform service resource information recommendation processing to the target object based on the service resource item; The step of obtaining the target service task scheduling branch through path matching in the service logic decision topology model includes: The structured configuration information of the logical decision topology model is analyzed to extract a directed acyclic graph (DAG) logical link consisting of multiple logical judgment nodes, attribute distribution nodes, and task execution operator nodes. Using the user service state feature vector as input parameters, Boolean operators at each level of the DAG logical link are triggered sequentially, starting from the root node, to compare the user service state feature vector with preset thresholds for each node. Based on the logical truth value determined by the comparison result, the user service state feature vector is driven to perform topological jumps between the attribute distribution nodes to obtain at least one service task scheduling branch. Within this service task scheduling branch, the target service task scheduling branch with the highest semantic fit to the user service state feature vector is determined.

9. 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 7.

10. 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 7.

11. 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 7.

Images