Data processing method

Abstract

The invention provides a data processing method, and relates to the technical field of data processing, and the method comprises the steps: continuously obtaining a real-time state data stream related to a service instance and a real-time parameter data stream related to an environment, the service instance being bound with at least one physical resource; monitoring the real-time state data stream and the real-time parameter data stream based on a predefined rule set, and generating an adjustment trigger instruction when the monitored data meets at least one trigger condition; in response to the adjustment trigger instruction, calling a dynamic adjustment model, and calculating to obtain a price adjustment amount for the service instance based on system state data at the current moment; the system state data is at least formed by fusing the real-time state data flow and the real-time parameter data flow; according to the price adjustment amount, updating price data corresponding to the service instance; and pushing the updated price comparison data to an associated information display system.

Description

Technical Field

[0001] This application belongs to the field of data processing technology, and specifically relates to a data processing method. Background Technology

[0002] In resource service platforms such as the sharing economy, equipment leasing, and computing power services, determining and managing the transaction price (such as rent and usage fees) for the services or resource instances (hereinafter collectively referred to as "service instances") provided on the platform is a core aspect affecting the platform's operational efficiency, resource utilization, and the revenue of all parties. Traditional pricing methods mainly include cost-plus pricing, static pricing based on historical averages, or periodic price adjustments relying on human experience.

[0003] With technological advancements, dynamic pricing schemes have emerged, such as revenue management systems used in the aviation and hotel industries, which dynamically adjust prices based on advance booking times and remaining inventory. However, applying these schemes directly to service platforms that connect physical resources with demanders presents significant challenges. Service instances in such platforms are typically deeply tied to specific, constantly changing physical resources (such as construction machinery, medical equipment, and server clusters). Their value is influenced by intrinsic factors such as the equipment's real-time operating conditions, health status, and usage intensity, as well as external factors such as market supply and demand fluctuations, environmental conditions, and policies and regulations, exhibiting high complexity and dynamism.

[0004] Existing solutions suffer from the following main shortcomings: First, most systems lack the ability to continuously perceive and integrate the real-time operational status of physical resources (such as fault warnings and performance degradation data obtained through IoT sensors). The historical data relied upon by pricing models is outdated and cannot respond to sudden changes in equipment status. Second, the monitoring of external parameters such as the market environment is often isolated and discontinuous, making it difficult to accurately align with and jointly analyze resource status data on a timeline. This results in inaccurate timing or biased basis for pricing adjustments. Third, the pricing decision-making process has a low degree of automation, often requiring manual intervention or adhering to simple threshold rules. This fails to handle complex, multi-dimensional, and non-linear relationships, leading to rigid adjustment strategies that may miss optimization opportunities or result in suboptimal decisions. Finally, the execution of pricing adjustments is usually decoupled from other systems on the platform (such as information display and recommendation matching systems). The adjusted price cannot quickly and accurately reach the most likely potential users, the feedback loop for adjustment effects is slow, and the system cannot achieve autonomous optimization. Summary of the Invention

[0005] This application provides a data processing method to solve one of the aforementioned technical problems.

[0006] The technical solution adopted in this application is as follows: This application provides a data processing method, including: Continuously acquire real-time status data streams related to service instances and real-time parameter data streams related to the environment, wherein the service instance is bound to at least one physical resource; The real-time status data stream and the real-time parameter data stream are monitored based on a predefined set of rules. When the monitored data meets at least one triggering condition, an adjustment triggering instruction is generated. In response to the adjustment trigger command, a dynamic adjustment model is invoked to calculate the price adjustment amount for the service instance based on the system status data at the current moment; the system status data is formed by fusing the real-time status data stream and the real-time parameter data stream. Update the price data corresponding to the service instance according to the price adjustment amount; The updated pricing data will be pushed to the associated information display system.

[0007] According to one embodiment of this application, the triggering condition includes at least one of the following: The event triggering conditions are based on specific event signals identified from the real-time status data stream; The threshold trigger condition is based on one or more indicator values ​​in the real-time status data stream or the real-time parameter data stream exceeding a preset threshold range; The periodic triggering condition is automatically generated based on a preset time period signal.

[0008] According to one embodiment of this application, the invocation of the dynamic adjustment model, which calculates the price adjustment amount for the service instance based on the current system state data, includes: The system state data is input into a trained deep reinforcement learning model; The deep reinforcement learning model aims to maximize a preset long-term return metric and outputs action instructions corresponding to the current system state. These action instructions include the price adjustment amount.

[0009] According to one embodiment of this application, before updating the price data corresponding to the service instance, the method further includes: The aforementioned price adjustment and the updated price data are input into the effect prediction model; Obtain the prediction results output by the effect prediction model, wherein the prediction results include at least the probability prediction value or expected revenue change value of the service instance being successfully used within a preset future time period. Based on the prediction results, determine whether to perform the update.

[0010] According to one embodiment of this application, pushing the updated consideration data to the associated information display system includes: Based on the updated pricing data, the matching degree between the service instance and multiple candidate user terminals is recalculated. The candidate user terminals are sorted according to the recalculated matching degree; The notification information containing the updated pricing data is pushed to the candidate user terminals that are ranked first.

[0011] According to one embodiment of this application, the method further includes: After the price data is updated, feedback data streams related to the service instance are continuously collected; the feedback data streams include at least subsequent user interaction behavior data. The records containing the adjustment trigger command, the price adjustment amount, and the feedback data stream are used as training samples for incremental training of the dynamic adjustment model.

[0012] According to one embodiment of this application, after generating the adjustment trigger instruction and before invoking the dynamic adjustment model, the method further includes: Perform a risk constraint check, which includes: determining whether the current adjustment meets the preset adjustment boundary rules, and / or assessing the current adjustment risk level based on the latest risk monitoring data; The step of invoking the dynamically adjusted model is performed only after the risk constraint check has passed.

[0013] A second aspect of this application provides a data processing apparatus for a dynamic price adjustment system of a resource service platform, comprising: The data stream acquisition module is used to continuously acquire real-time status data streams related to service instances and real-time parameter data streams related to the environment; The monitoring and triggering module is used to monitor the data stream based on a predefined set of rules and generate an adjustment triggering command when the triggering conditions are met. The adjustment calculation module is used to respond to the trigger command by calling the dynamic adjustment model to calculate the price adjustment amount; The price update module is used to update the price data of the service instance according to the adjustment amount; The information synchronization module is used to push the updated consideration data to the associated information display system.

[0014] A third aspect of this application provides a computer-readable storage medium having a program stored thereon that, when executed by a processor, implements the steps described in the method.

[0015] A fourth aspect of this application provides an electronic device including a memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method as described.

[0016] Due to the adoption of the above technical solution, the beneficial effects achieved by this application are as follows: This application continuously acquires real-time status data streams (such as IoT sensor data and interaction logs) of physical resources bound to service instances, enabling the system to monitor the resource's health status, usage load, and popularity in real time. Simultaneously, by continuously acquiring real-time parameter data streams related to the environment (such as market conditions and macroeconomic indicators), the system can synchronously perceive the external macroeconomic environment affecting resource value. Merging these two data streams into system status data constructs a comprehensive, time-scaled status view that simultaneously encompasses both the "resource itself" and its "environment." This provides a comprehensive, real-time, and context-rich data foundation for all subsequent analysis and decision-making, overcoming the shortcomings of traditional methods such as incomplete data dimensions and poor timeliness.

[0017] By concurrently monitoring two types of real-time data streams using predefined rule sets, the system can flexibly set composite conditions, including event triggers (such as competitor price changes), threshold triggers (such as exceeding idle time limits), and periodic triggers. When multi-dimensional data meets at least one trigger condition, the system automatically generates adjustment trigger instructions. This mechanism frees personnel from tedious continuous monitoring work and enables more accurate trigger decisions based on fused system status data than single signal judgments, significantly improving the timeliness and accuracy of response and avoiding decision-making delays caused by human error or incomplete rules.

[0018] In response to a trigger command, a dynamic adjustment model is invoked for calculation. This model (e.g., trained using reinforcement learning) can learn the nonlinear relationship between states and optimal actions (adjustments) in complex environments. The model infers based on fused current-moment system state data, and the output price adjustment is a result that comprehensively considers multiple factors such as real-time resource status, market environment, and historical patterns. This replaces subjective decision-making relying on fixed formulas or human experience, ensuring that each price adjustment is supported by data and models, making it more scientific and adaptable, and helping to capture profit opportunities and mitigate risks in dynamic markets.

[0019] The system automatically updates the pricing data corresponding to the service instance based on the price adjustment amount, ensuring the atomicity and immediacy of price changes. More importantly, after the update is complete, the system proactively pushes the updated pricing data to the associated information display system. This "push" action establishes an active communication link between the pricing module and the front-end display and user interaction modules, ensuring that price changes take effect instantly on the user interface and providing timely and accurate data input for subsequent intelligent recommendations and user outreach based on the new price. This transforms a price adjustment from an isolated event into a trigger driving collaborative work within the platform, forming a rapid closed loop of "perception-decision-execution-display". Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating a data processing method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0021] Figure label: 810, Processor; 820, Communication interface; 830, Memory; 840, Communication bus. Detailed Implementation

[0022] To more clearly illustrate the overall concept of this application, a detailed explanation is provided below with reference to the accompanying drawings.

[0023] Many specific details are set forth in the following description to provide a thorough understanding of this application. However, this application may also be implemented in other ways different from those described herein. Therefore, the scope of protection of this application is not limited to the specific embodiments disclosed below. It should be noted that, unless otherwise specified, the embodiments of this application and the features thereof can be combined with each other.

[0024] In this application, unless otherwise expressly specified and limited, the "above" or "below" of the second feature can mean that the first and second features are in direct contact, or that the first and second features are in indirect contact through an intermediate medium. In the description of this specification, references to terms such as "an embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples.

[0025] Example 1 like Figure 1 As shown, a data processing method includes: S100, continuously acquire real-time status data streams related to the service instance and real-time parameter data streams related to the environment, wherein the service instance is bound to at least one physical resource.

[0026] Specifically, the system continuously collects data streams through multiple channels. These "real-time status data streams" include, but are not limited to: Equipment operation data stream: Through IoT sensors installed on leased equipment (such as construction machinery and medical equipment), real-time sequential data such as equipment operating time, current load, energy consumption, vibration frequency of key components, temperature, and fault diagnosis codes are collected.

[0027] Platform interaction data stream: Records the sequence of user behavior of this device on the platform, including the number of unique visitors (UV), page views (PV), number of times it is added to favorites, number of inquiries received and their content, historical bidding records, etc.

[0028] Performance-related data flow: If the equipment is within the lease period, the publicly available operating data of the lessee company will be accessed or crawled in real time, such as the operating rate index of the company's location, industry public opinion information, and legal risk information.

[0029] The "real-time parameter data stream" includes, but is not limited to: Market data stream: Information such as the recent average transaction price index of similar used equipment, the release price of new equipment, and changes in the price of related raw materials are crawled from third-party data services or public markets.

[0030] Macroeconomic environment data stream: Acquire industry policy changes, seasonal demand indices (such as the peak season index for construction), and holiday calendars in the region where the equipment is located.

[0031] All these data streams are accessed through message queues (such as Kafka) and stored and time-aligned using time-series databases (such as InfluxDB) to form a comprehensive data view describing the current state of the system.

[0032] Physical resources refer to actual, existing physical equipment or assets that can be leased or used. Examples include: a CAT 320 excavator, a Siemens MRI medical imaging system, and a 50kW industrial transformer.

[0033] Service instance: Refers to a tradable and manageable virtual object created on a digital platform (such as a financial leasing platform) corresponding to a physical resource. It contains all digital twin information of the resource, including its description, status, pricing, lease terms, etc.

[0034] Binding relationship: Each service instance must be uniquely associated with at least one physical resource. This is the foundation for mapping data from the physical world to the digital world. Binding relationships are typically established through unique device identifiers (such as serial numbers or IoT device IDs).

[0035] This binding ensures the accuracy and relevance of data collection, enabling any operation on the "service instance" (such as price adjustment) to be accurately reflected on the corresponding physical resources, thus achieving virtual-physical linkage.

[0036] S200: Monitor the real-time status data stream and real-time parameter data stream based on a predefined set of rules. When the monitored data meets at least one triggering condition, generate an adjustment triggering command.

[0037] The system has a pre-defined configurable rule engine that defines various trigger conditions, such as: Event triggering conditions: For example, identifying "engine fault code P0300" from the equipment operation data stream and subsequently receiving a work order event indicating "repair completed"; or identifying an event from the market data stream indicating that "the listed price of the same model of equipment from a major competitor has decreased by 10%".

[0038] Threshold trigger conditions: For example, "the number of days without any user access to the device is >7 days"; or "the inquiry conversion rate (inquiry volume / visit volume) of the device in the past 24 hours is <2%"; or "the market supply-demand ratio (demand / supply) of similar devices has increased by more than 15% in the past week".

[0039] Periodic triggering conditions: For example, the system automatically starts a global assessment every Monday at 9:00 AM.

[0040] When the rules engine detects that any condition is met, it will generate a structured "adjustment trigger instruction", which includes the trigger type, trigger time, associated device ID, and key snapshot data at the time of triggering.

[0041] S300, in response to the adjustment trigger command, invoke the dynamic adjustment model to calculate the price adjustment amount for the service instance based on the system status data at the current moment.

[0042] This step is the core decision-making process. The system maintains a trained Deep Reinforcement Learning (DRL) model as a dynamically adjusted model. The decision-making process is as follows: State Construction: At the trigger moment, all real-time data streams acquired from S100 that are related to the target device are subjected to feature extraction and fusion to construct a high-dimensional state vector (State_t). This vector contains hundreds of features such as device state, market popularity, user interests, and time context.

[0043] Model Inference: Input State_t into the DRL model. The optimization objective (reward function) of this model (e.g., trained based on the DDPG or PPO algorithm) is to maximize the platform's long-term revenue, which comprehensively considers factors such as rental costs per transaction, equipment idle costs, platform commissions, and user satisfaction. Based on the current state, the model outputs an action, which in this embodiment is a continuous value representing the suggested price adjustment percentage (ΔP), such as "reduce by 5.2%" or "increase by 1.8%".

[0044] Adjustment amount calculation: Apply the adjustment ratio output by the model to the current benchmark price P_current of the equipment to calculate the specific adjustment amount: Adjustment amount = P_current * ΔP.

[0045] S400, Update the price data corresponding to the service instance according to the price adjustment amount.

[0046] Before the final adjustments are implemented, the system can optionally perform effect prediction and risk assessment: Performance Prediction: The adjusted new price P_new = P_current * (1 + ΔP) is input into an offline-trained performance prediction model (such as a gradient boosting tree model). Based on historical data, this model predicts the probability of renting out the device at this new price within the next 3 or 7 days, as well as the expected change in revenue. If the prediction does not meet the preset requirements (e.g., the increase in rental probability is less than 5%), the system can refuse to execute the adjustment or return to recalculation.

[0047] Risk constraint check: This check verifies whether the adjustment violates preset hard rules, such as "a single adjustment cannot exceed ±20%" and "the adjusted price cannot be lower than the equipment maintenance cost floor price." Simultaneously, it quickly verifies whether the lessee's credit has suddenly deteriorated recently. Only after all checks pass will the system automatically update the equipment's price in the database via internal API and synchronize it to the front-end webpage and mobile application.

[0048] S500 pushes the updated pricing data to the associated information matching system.

[0049] After the price is updated, the system immediately links with the platform's intelligent matching system: The information matching system recalculates the matching score between the device and all currently active potential tenant profiles based on the new P_new.

[0050] For the top-N potential lessees whose matching scores have improved most significantly, the system will send targeted notifications via in-site messages, application push notifications, or SMS, such as: "The price of the XX model excavator you are interested in has been updated, and its cost performance has improved. Click to view." At the same time, the device is temporarily given a higher weight in the platform's recommendation list and search result ranking, giving it more exposure.

[0051] In some embodiments of this application, the triggering condition includes at least one of the following: The event triggering conditions are based on specific event signals identified from the real-time status data stream; The threshold trigger condition is based on one or more indicator values ​​in the real-time status data stream or the real-time parameter data stream exceeding a preset threshold range; The periodic triggering condition is automatically generated based on a preset time period signal.

[0052] As mentioned above, an event trigger condition refers to a condition that the system uses pattern recognition or signal detection techniques to capture specific, discrete symptom signals from a continuously flowing real-time status data stream and makes a judgment accordingly. Essentially, it monitors whether a business or technical event conforming to a predefined pattern appears in the data stream. For example, identifying a specific Diagnostic Troubleshooting Code (DTC) representing a critical fault from a device sensor data stream, or parsing an announcement of a competitor releasing a new price from a market data stream. The system needs to predefine the characteristic patterns of these events; when the incoming data matches the pattern, the event is determined to have occurred, thus satisfying the trigger condition. This definition transforms discrete business events into technical signals that can be automatically recognized by a computer.

[0053] Threshold trigger conditions refer to conditions under which the system continuously monitors and calculates one or more continuous indicators in a real-time status data stream or real-time parameter data stream, and compares the calculation results with a preset numerical range. The core technology lies in windowed aggregation operations on the data stream (such as calculating moving averages, cumulative values, and rates of change) and threshold comparisons. For example, continuously calculating the average load rate of devices over the past 72 hours, the condition is met when this value is lower than a preset "idle threshold" (e.g., 20%). Another example is calculating the instantaneous value of the market supply-demand ratio (quantity demanded / quantity supplied), and the condition is met when it exceeds a preset "tightness threshold." Both the threshold and the comparison range are configurable technical parameters, enabling the system to quantitatively respond to continuous changes in indicators.

[0054] A periodic trigger condition refers to a condition under which the system automatically initiates evaluation and generates a judgment based on a preset, regular time period signal. Its technological basis is a time scheduler. The system automatically generates a trigger evaluation signal based on time rules such as Cron expressions or at specific absolute time points, independent of changes in external data streams. For example, the system can be configured to automatically generate an evaluation signal at 10:00 AM every workday, at which point the periodic condition is met regardless of equipment or market data. This definition enables the system to perform fixed-period inspections or execute calendar-based strategies, ensuring the planning and coverage of the price adjustment mechanism in the time dimension.

[0055] The above three triggering conditions together constitute a multi-dimensional, automated monitoring system that can cover different scenarios such as sudden events, continuous quantitative changes in indicators, and fixed cycles, providing a clear, reliable, and efficient technical basis for initiating subsequent complex price adjustment decision models.

[0056] In some embodiments of this application, the invocation of the dynamic adjustment model, which calculates the price adjustment amount for the service instance based on the system state data at the current moment, includes: The system state data is input into a trained deep reinforcement learning model; The deep reinforcement learning model aims to maximize a preset long-term return metric and outputs action instructions corresponding to the current system state. These action instructions include the price adjustment amount.

[0057] As described above, the system uses the fused system state data at the current moment as an input feature vector, which is then fed into a pre-trained deep reinforcement learning model. This model typically consists of a deep neural network, representing the optimal decision-making strategy learned by the agent in a specific environment (i.e., the service platform).

[0058] The core optimization objective of the deep reinforcement learning model is set during its training phase to maximize a pre-defined long-term return metric. This metric is typically formalized as the cumulative discounted value of all expected revenues the platform will obtain from the service instance over a future period. The model is trained through repeated trial and error with the environment (composed of historical data simulations or online interactions), learning how to act according to different system states to ultimately maximize this long-term return.

[0059] During the inference and decision-making phase, after receiving the system state data at the current moment, the model calculates based on its internally learned policy network and outputs an optimal action instruction corresponding to the current system state. In the specific application scenario described in the claims, this action instruction is concretized into a numerical value, which directly represents the proposed price adjustment for the service instance, such as an increase of 5% or a decrease of 3%. This output result is a quantitative decision made by the model based on a comprehensive consideration of long-term benefits, tailored to the current specific state.

[0060] In some embodiments of this application, before updating the consideration data corresponding to the service instance, the method further includes: The aforementioned price adjustment and the updated price data are input into the effect prediction model; Obtain the prediction results output by the effect prediction model, wherein the prediction results include at least the probability prediction value or expected revenue change value of the service instance being successfully used within a preset future time period. Based on the prediction results, determine whether to perform the update.

[0061] As described above, after obtaining the consideration adjustment amount and calculating the corresponding updated consideration data, the system does not immediately perform the update. Instead, it submits these two pieces of data—the consideration adjustment amount and the calculated updated consideration data—along with the necessary context information, as input to an independent effect prediction model.

[0062] The system obtains the prediction results output from the effect prediction model. The core function of the model is to perform counterfactual inference, and its output includes at least one or more of the following quantitative prediction values: the probability prediction that the service instance will be successfully rented or used at the adjusted new price within a certain preset future time period (e.g., the next 24 hours or 7 days); or the expected change in revenue that the adjustment can bring compared to maintaining the original price.

[0063] The system makes logical judgments based on the prediction results to determine whether to execute the update. This judgment process is based on preset decision rules. For example, it may be set so that the update operation of the pricing data is only approved when the predicted "probability of successful use" increases by more than a certain percentage threshold, or the "expected change in revenue" is positive and reaches a certain amount; if the prediction results fail to meet the preset conditions for effectiveness, the price adjustment order will be suspended or rejected, and no actual update will be executed. This step introduces a decision gating mechanism based on forward-looking prediction.

[0064] In some embodiments of this application, pushing the updated consideration data to the associated information display system includes: Based on the updated pricing data, the matching degree between the service instance and multiple candidate user terminals is recalculated. The candidate user terminals are sorted according to the recalculated matching degree; The notification information containing the updated pricing data is pushed to the candidate user terminals that are ranked first.

[0065] As mentioned above, after obtaining the updated pricing data, the system immediately invokes the matching degree calculation algorithm within the platform to recalculate the degree of association between the service instance and multiple currently active candidate user terminals (i.e., device or account profiles representing potential users) on the platform, i.e., the matching degree. This calculation process typically considers multi-dimensional information such as the user's historical preferences, budget range, real-time demand status, and the latest pricing data.

[0066] After recalculating the matching degree for all relevant candidate user terminals, the system will perform a sorting operation on all candidate user terminals based on the calculated new matching degree values. The sorting is usually performed in descending order of matching degree, thus forming an ordered list.

[0067] Based on resource allocation strategies or push rules, the system prioritizes sending notifications to candidate user terminals ranked high on the list. This notification explicitly includes the updated pricing data, as well as other relevant service change information. Through this mechanism of re-evaluating and ranking based on the new pricing, the system ensures that price change information reaches the potential user group most likely to accept the new price, thereby improving the effectiveness of the pricing strategy and the user experience.

[0068] In some embodiments of this application, the method further includes: After the price data is updated, feedback data streams related to the service instance are continuously collected; the feedback data streams include at least subsequent user interaction behavior data. The records containing the adjustment trigger command, the price adjustment amount, and the feedback data stream are used as training samples for incremental training of the dynamic adjustment model.

[0069] As described above, after performing the price data update operation, the system will initiate a data collection process to continuously collect feedback data streams related to the service instance. The feedback data streams mainly record the actual impact of the price change, and its core data includes at least subsequent user interaction data, such as: whether the user clicked to browse again after seeing the new price, whether they initiated a new inquiry, and whether the rental transaction was successfully completed, along with their timestamps.

[0070] These feedback data are systematically organized. The system encapsulates the key elements of this price adjustment event and constructs a complete record. This record serves as a training sample and contains at least three parts: the initial adjustment trigger instruction that led to the price adjustment (including a snapshot of the state at the time of triggering), the price adjustment amount output by the decision model, and the feedback data stream collected after the update (especially the final result data that can reflect changes in revenue or conversion rate).

[0071] The system incrementally trains the dynamically adjusted model using newly generated training samples. Specifically, these training samples are stored in the model's experience replay buffer and then, in the next training cycle, are mixed with historical samples to update the parameters of the deep reinforcement learning model (e.g., its Actor or Critic network). Through this process, the model can adjust its strategy based on the actual effects (reward signals) of its decisions in the real environment, thereby continuously learning from online interactions and optimizing its future price adjustment decision-making capabilities. This forms a complete closed loop of "decision-execution-feedback-learning".

[0072] In some embodiments of this application, after generating the adjustment trigger instruction and before invoking the dynamic adjustment model, the method further includes: Perform a risk constraint check, which includes: determining whether the current adjustment meets the preset adjustment boundary rules, and / or assessing the current adjustment risk level based on the latest risk monitoring data; The step of invoking the dynamically adjusted model is performed only after the risk constraint check has passed.

[0073] As mentioned above, specifically, the system will perform an automated risk constraint check. This check mainly includes two aspects: determining whether the proposed adjustment complies with preset adjustment boundary rules. These rules are pre-defined hard technical constraints, such as: the absolute value of a single price adjustment must not exceed a certain percentage limit (e.g., 10%); the adjusted price must be within a preset allowed price range (e.g., not lower than the cost floor price); and the time interval since the last price adjustment for this service instance must be greater than the specified minimum quiet period.

[0074] Risk constraint checks assess the risk level of the current adjustment based on the latest risk monitoring data. The system queries or calculates risk indicators related to this adjustment in real time, such as: whether the latest health status of the physical resources bound to the service instance shows any warnings, whether the credit scores of the target lessee (or potential lessee group) have deteriorated significantly, and whether the overall liquidity risk of the current market is too high. Based on this real-time data, the system comprehensively calculates the potential risk level of this adjustment through a risk scoring model or rule set.

[0075] This check serves as a decision gating mechanism. The system is configured to only consider the risk constraint check "passed" if the current adjustment simultaneously meets all relevant boundary rules and the assessed risk level is below a preset acceptable threshold. Only under these conditions will the system proceed to the next step of calling the dynamic adjustment model. If the check fails, the price adjustment process will be terminated or transferred to a manual review queue, thus preventing the initiation of complex model decisions under conditions of excessively high risk or non-compliance with basic rules, ensuring the compliance and robustness of system operations.

[0076] Example 2 This embodiment provides supplementary explanations regarding the training and use of the dynamic adjustment model involved in Embodiment 1.

[0077] Model training is an offline process: Environment Simulation: Based on the platform's accumulated historical transaction data, device status logs, and user behavior logs, a simulation environment is constructed. This environment can simulate processes such as device status changes, user inquiries and decisions, and market competition.

[0078] Model Training: Using the simulated environment described above, the model is trained using deep reinforcement learning algorithms such as DDPG. The agent (i.e., the model) observes a state s_t in the environment, executes a price adjustment action a_t (i.e., ΔP), and the environment provides a reward r_t (calculated based on the profit from the simulated transaction) before transitioning to the next state s_{t+1}. Through millions of such simulated interactions, the model learns a policy π, enabling it to select the price adjustment action with the highest expected long-term cumulative reward for any given state s.

[0079] Online Deployment and Updates: The trained model is deployed to the online service, providing real-time inference in the form of microservices. Simultaneously, the system continuously collects real-world adjustment decisions and subsequent user behavior and transaction data as new training samples, periodically performing incremental learning or retraining to enable the model to adapt to market changes and achieve self-evolution.

[0080] Example 3 This embodiment provides a dynamic pricing adjustment method applied to a resource service platform. This method achieves real-time, intelligent adjustment of service instance pricing by constructing a data-driven closed-loop system. The following explanation uses specific formulas and models: Step 1: Multi-dimensional real-time data acquisition and feature quantization The system continuously collects data streams from multiple sources and performs feature engineering to transform them into quantitative indicators usable by the model.

[0081] Equipment status feature extraction: Equipment health score calculation: Taking into account equipment runtime, fault status, and performance degradation, the calculation formula is as follows:

[0082] in, This represents the cumulative operating hours. For design life, This represents the current number of valid fault codes. This is the threshold for the number of fault codes. This is the performance degradation rate calculated based on sensor data (such as vibration amplitude and temperature shift). These are preset weighting coefficients based on the device type.

[0083] Market environment characteristics extraction: Market popularity index calculation: reflects the relative supply and demand situation and price level of similar resources in the market.

[0084]

[0085] in, Let t be the average price of similar services offered by competitors as monitored at time t. The historical average price over the past T days. The total search volume for similar services across the entire network at time t. It is its historical average.

[0086] User behavior feature extraction: User interest intensity calculation: quantifies the degree of attention potential users pay to a specific service instance.

[0087]

[0088] in, This refers to the number of inquiries in the past 24 hours. For the number of visits, This represents the average time spent on a page. For platform reference, the duration of the stay This is the smoothing constant.

[0089] Step 2: Dynamic Adjustment of Decision Generation Based on Reinforcement Learning When the monitoring data meets the preset trigger conditions, the system calls the trained deep reinforcement learning model to generate adjustment decisions.

[0090] State construction: Combine the above features with time context features (such as day of the week) Are there holidays? Combining these elements forms a state vector. :

[0091] Model Inference and Action Output: Actor Network Trained Using Proximal Policy Optimization (PPO) Algorithm As a decision-making model, the network receives the state. Through forward propagation of the neural network, an action representing the adjustment ratio is output. :

[0092] in, For network parameters, actions Limited to the range of [-0.15, 0.15], indicating a maximum adjustment range of ±15%.

[0093] Model Training and Reward Function: The goal of model training is to maximize the long-term cumulative reward. Reward Function The design is as follows:

[0094] Specifically:

[0095] in, and Indicator functions for trading and idle periods. For the cost of a single transaction, The last item represents the daily idle cost and is designed to encourage smooth adjustments and avoid drastic fluctuations.

[0096] Step 3: Adjustment effect simulation and risk verification Before implementing the adjustment, the system uses a causal inference model to predict the effect of the adjustment and performs a compliance check.

[0097] Effect prediction (counterfactual prediction): A dual robust estimation method is used to predict the adjustment actions to be taken. Incremental effect after .

[0098] First, train two regression models: Predict the outcome under "adjusted" conditions (such as the probability of renting out the property in the next 3 days). Predict the outcome under the "no adjustment" condition.

[0099] At the same time, train a propensity score model. Predicting in state The probability of an adjustment occurring.

[0100] For the current state and the action to be performed (Considered "adjustment"), the expected incremental effect is:

[0101] (This is a simplified illustration; the actual calculation will be based on a weighted average of historical samples.)

[0102] Risk and boundary verification: Amplitude verification: Ensure (e.g., 15%).

[0103] Absolute boundary verification: ensures ,in As the cost price, This is the maximum price limit in the market.

[0104] Frequency verification: Checks the time interval since the last adjustment. (e.g., minimum interval of 6 hours).

[0105] Step 4: Adjusting Execution and System Coordination After verification, the system performs adjustments and works in conjunction with other modules on the platform.

[0106] Consideration Update: New Consideration The system updates the database and cache atomically through internal interfaces.

[0107] Match Recalculation and Targeted Push: The information matching system immediately recalculates the match rate of all potential users using the new offer.

[0108]

[0109] in, For user budget characteristics, For service instance E and user requirements Technical similarity, Assess user risk rating. This is a Sigmoid function. The system selects the Top K users with the greatest improvement in matching accuracy for priority push notifications.

[0110] Feedback-learning loop: Adjusted user behavior data (exposure, clicks, transactions) is collected and used as a new state-action-reward tuple. Stored in the experience pool for periodic online fine-tuning of the PPO model.

[0111] Example 4 The method described operates on the platform's dynamic pricing adjustment system. The system continuously monitors the physical resource status and external environment bound to a service instance (such as a rentable drone). Once conditions are met, it intelligently triggers a pricing adjustment decision, calculates the adjustment amount using a machine learning model, updates the pricing, and synchronizes it to the front end. Finally, it optimizes the model based on feedback data. The following detailed explanation, using a "drone aerial photography service" example, illustrates the process step-by-step.

[0112] Step S110: Continuously acquire data stream (corresponding to the preamble of weight 1) The system continuously acquires two types of real-time data streams: Real-time status data stream related to the service instance: The service instance is "Urban High-Definition Aerial Photography Service," and its bound physical resource is a specific model of drone. The data stream includes: Device status stream: Battery cycle count obtained through the drone's built-in sensors Average calibration error of gimbal Cumulative vibration intensity of the fuselage .

[0113] Service interaction flow: Real-time data of this service instance on the platform, such as the number of page views in the past hour. Number of times it was added to the demand list .

[0114] Real-time parameter data streams related to the environment include: Market flow: Average minute quotes for similar aerial photography services in the same city, obtained via API. and its rate of change over the past 24 hours .

[0115] Spatiotemporal flow: Current date type (weekday / weekend), weather conditions (e.g., visibility) ), regional airspace control status .

[0116] Step S120: Monitoring and Triggering Adjustment The system's preset rule set includes various triggering conditions and monitors the aforementioned data flow in real time.

[0117] Scene trigger: One Saturday morning, the weather was sunny. (No airspace control). The system detected: Market flow data: (Competitors' average price increased by 8%).

[0118] Service interaction flow data: , Calculate instantaneous interest It is 0.1 higher than the usual threshold.

[0119] Rule determination: The rule set predefines "threshold triggering conditions": when and And the date is a weekend and At that time, it was determined to be a "peak demand window".

[0120] Generate instruction: If the current data meets the combined conditions, the system generates an adjustment trigger instruction, marked as "Demand Peak Price Increase Trigger", and attaches a snapshot of all relevant data mentioned above.

[0121] Step S130: Calculate the adjustment amount using the dynamic adjustment model. The system responds to the trigger command and begins the decision-making process.

[0122] Constructing system state data: Fusing various data points at the trigger moment into a state vector. .

[0123]

[0124] All values ​​have been normalized.

[0125] Invoke Dynamically Adjusted Model: The system invokes a deployed Deep Reinforcement Learning (DRL) model. This model employs the DDPG (Deep Deterministic Policy Gradient) algorithm, trained in a simulated environment based on historical data, with the optimization objective of maximizing long-term returns.

[0126] Model reasoning: Input the Actor network of the DRL model. The forward propagation calculation of the network is as follows:

[0127]

[0128]

[0129] in, For the network parameters obtained during training, The output is limited to [-10%, +10%]. The model outputs actions based on the current "peak demand" state. This means that the proposed price increase is 6.5%.

[0130] Risk constraint check: Perform a risk constraint check before the formal calculation.

[0131] Check adjustment boundaries: The preset upper limit of the absolute value of a single adjustment is 10%. ), conform to.

[0132] Risk assessment and adjustment: A review of the drone's most recent maintenance record and credit status revealed no abnormalities. The risk level is assessed as "low".

[0133] The inspection passed; proceed with the execution.

[0134] Step S140: Effect Prediction and Decision Confirmation To avoid undesirable adjustments, the system performs effect simulation and prediction.

[0135] Call the effect prediction model: The system will and the amount of adjustment to be implemented Input a performance prediction model (trained based on the XGBoost algorithm). This model predicts two key metrics: Changes in the probability of a transaction in the next 24 hours .

[0136] Changes in expected returns .

[0137] Obtaining prediction results: The model outputs the prediction results: (Due to the price increase, the probability of a transaction is estimated to decrease by 8 percentage points), but (Unit revenue). The system's built-in strategy trade-offs suggest that, under the current peak demand conditions, the weight of increased revenue outweighs the slight decrease in the probability of a transaction.

[0138] Decision-making: Based on the comprehensive forecast results and business rules, this adjustment is determined to be a "positive revenue adjustment" and is approved for implementation.

[0139] Step S150: Update the consideration data Assuming the current service price Yuan / hour.

[0140] Calculate the new consideration: Yuan.

[0141] The system updates the price field of the "Urban High-Definition Aerial Photography Service" instance in the database to 319 yuan / hour (rounded down).

[0142] Step S160: Push updates and recalculate matching degree Once the price is updated, the system immediately links with the information display and matching system.

[0143] Recalculate the matching degree: The information matching system obtains a new offer. Yuan. For each candidate user terminal (i.e., user profile) within the platform, recalculate its matching degree with the service.

[0144] The matching degree calculation function is:

[0145] in, It is user u's historical budget preference. It is the service skills matching degree (such as whether the user needs high-definition aerial photography). It is the proximity between the user's location and the service area. It is the Sigmoid function.

[0146] Example: For user "Construction Company A" ( , , Matching degree before price adjustment After the price adjustment For user "Wedding Planner B" ( , , ), matching degree from Down to .

[0147] Targeted Push Notifications: The system sorts all potential users based on a recalculated match score. Although some users' match scores decrease, the system's strategy is to target users whose absolute match scores are still above a threshold (e.g., 0.6) and whose decrease is the smallest. Therefore, "Construction Company A" will receive a gentle notification: "The service you are interested in has had its price updated due to increased demand, but it still falls within your budget." For "Wedding Planner B," whose match score has decreased significantly, the system will not proactively push price change notifications to avoid a negative experience.

[0148] Step S170: Feedback Learning Loop After the adjustments are implemented, the system enters an observation period to collect feedback data.

[0149] Data stream collection and feedback: Over the next 24 hours, the system will continuously collect user interaction behavior data streams for this service instance, including: subsequent browsing counts, new inquiry counts, and whether orders have been placed.

[0150] Creating a training sample: This adjustment event is used as a training sample. :

[0151] in, It is an instant reward calculated based on actual earnings and user interaction within 24 hours.

[0152] Incremental training: An experience replay buffer is added to the DRL model. The system periodically uses both new and old samples in the buffer to perform incremental training on the network parameters of the DRL model, enabling the model to adapt to market changes and learn more accurate pricing strategies.

[0153] Example 5 This application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method in any of the embodiments of the first aspect described above.

[0154] Figure 2 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 2 As shown, the electronic device may include a processor 810, a communication interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other via the communication bus 840. The processor 810 may call logical instructions in the memory 830 to execute the method in any of the embodiments of the first aspect described above. Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0155] On the other hand, the present invention also provides a computer program product, the computer program product including a computer program, the computer program being stored on a non-transitory computer-readable storage medium, and when the computer program is executed by a processor, the computer is able to perform the methods provided by the above methods.

[0156] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the methods provided by the above methods.

[0157] For any parts not mentioned in this application, existing technologies may be used or referenced.

[0158] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0159] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A data processing method, characterized in that, A dynamic pricing adjustment system applied to resource service platforms includes: Continuously acquire real-time status data streams related to service instances and real-time parameter data streams related to the environment, wherein the service instance is bound to at least one physical resource; The real-time status data stream and the real-time parameter data stream are monitored based on a predefined set of rules. When the monitored data meets at least one triggering condition, an adjustment triggering instruction is generated. In response to the adjustment trigger command, a dynamic adjustment model is invoked to calculate the price adjustment amount for the service instance based on the system status data at the current moment; the system status data is formed by fusing the real-time status data stream and the real-time parameter data stream. Update the price data corresponding to the service instance according to the price adjustment amount; The updated pricing data will be pushed to the associated information display system.

2. The method according to claim 1, characterized in that, The triggering condition includes at least one of the following: The event triggering conditions are based on specific event signals identified from the real-time status data stream; The threshold trigger condition is based on one or more indicator values ​​in the real-time status data stream or the real-time parameter data stream exceeding a preset threshold range; The periodic triggering condition is automatically generated based on a preset time period signal.

3. The method according to claim 1, characterized in that, The dynamic adjustment model is invoked to calculate the price adjustment amount for the service instance based on the current system state data, including: The system state data is input into a trained deep reinforcement learning model; The deep reinforcement learning model aims to maximize a preset long-term return metric and outputs action instructions corresponding to the current system state. These action instructions include the price adjustment amount.

4. The method according to claim 1, characterized in that, Before updating the price data corresponding to the service instance, the method further includes: The aforementioned price adjustment and the updated price data are input into the effect prediction model; Obtain the prediction results output by the effect prediction model, wherein the prediction results include at least the probability prediction value or expected revenue change value of the service instance being successfully used within a preset future time period. Based on the prediction results, determine whether to perform the update.

5. The method according to claim 1, characterized in that, The step of pushing the updated consideration data to the associated information display system includes: Based on the updated pricing data, the matching degree between the service instance and multiple candidate user terminals is recalculated. The candidate user terminals are sorted according to the recalculated matching degree; The notification information containing the updated pricing data is pushed to the candidate user terminals that are ranked first.

6. The method according to claim 1, characterized in that, The method further includes: After the price data is updated, feedback data streams related to the service instance are continuously collected; the feedback data streams include at least subsequent user interaction behavior data. The records containing the adjustment trigger command, the price adjustment amount, and the feedback data stream are used as training samples for incremental training of the dynamic adjustment model.

7. The method according to claim 1, characterized in that, After generating the adjustment trigger instruction and before invoking the dynamic adjustment model, the following is also included: Perform a risk constraint check, which includes: determining whether the current adjustment meets the preset adjustment boundary rules, and / or assessing the current adjustment risk level based on the latest risk monitoring data; The step of invoking the dynamically adjusted model is performed only after the risk constraint check has passed.

8. A data processing apparatus, characterized in that, A dynamic pricing adjustment system applied to resource service platforms includes: The data stream acquisition module is used to continuously acquire real-time status data streams related to service instances and real-time parameter data streams related to the environment; The monitoring and triggering module is used to monitor the data stream based on a predefined set of rules and generate an adjustment triggering command when the triggering conditions are met. The adjustment calculation module is used to respond to the trigger command by calling the dynamic adjustment model to calculate the price adjustment amount; The price update module is used to update the price data of the service instance according to the adjustment amount; The information synchronization module is used to push the updated consideration data to the associated information display system.

9. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the data processing method as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the data processing method as described in any one of claims 1-7.

Images