A low-voltage fee collection whole-process intelligent management and control system and method

Abstract

This invention discloses an intelligent management and control system and method for the entire low-voltage payment collection process, relating to the field of power marketing service management and control technology. The system includes a multi-domain state profile acquisition module, a conflict degree token pool delineation module, a token performance time-domain deduction module, and an execution feedback self-correction module. The multi-domain state profile acquisition module collects multi-source state data and generates logical intent vectors and physical load vectors. The conflict degree token pool delineation module calculates the data conflict degree coefficient and activates either a soft token candidate pool or a hard token candidate pool, obtaining an executable action set through rigid constraint pruning. The token performance time-domain deduction module differentially modulates the initial performance base and basic attenuation constant of the target token to generate the next round trigger time and transition direction. The execution feedback self-correction module performs user-specific correction of the basic attenuation constant based on the time deviation between the actual payment collection time and the next round trigger time.

Description

Technical Field

[0001] This invention relates to the field of power marketing service management technology, and more specifically, to an intelligent management system and method for the entire process of low-voltage payment collection. Background Technology

[0002] With the widespread adoption of electricity information collection systems, marketing business systems, SMS platforms, outbound calling platforms, and mobile work terminals in the power supply service sector, the collection of overdue payments from low-voltage electricity customers is gradually shifting from a single manual notification method to a multi-channel collaborative processing approach. Current low-voltage payment collection typically relies on marketing accounting systems to obtain accounting information such as the amount owed, duration of the overdue payment, and user category, and combines this with SMS reminders, outbound calls, electronic bill push notifications, and on-site service work orders to send payment reminders to users. Simultaneously, some power supply units also impose certain restrictions on the timing and method of payment collection actions based on business rules such as daily contact frequency, quiet periods, user classification, and service resource availability, in order to meet power supply service standards and user service management requirements. These methods can, to a certain extent, achieve batch contact with overdue customers, record-keeping of payment collection, and scheduling of manual service resources, and are currently common technical implementation paths in low-voltage payment collection operations. However, current low-voltage payment collection processes still rely heavily on fixed rules, fixed frequencies, or human experience to select collection actions. Data such as account status, user historical responses, actual electricity consumption behavior, compliance restrictions, execution resources, and external environment are often scattered across different systems, making it difficult to form a unified basis for status judgment at the same decision-making moment. For the same user with outstanding payments, existing methods often struggle to accurately identify the degree of matching between their feedback information and actual electricity consumption behavior. It is also difficult to determine the timing and escalation direction of the next round of outreach based on the expected changes in the effect of different collection actions within subsequent time windows. This leads to problems such as collection actions not matching the user's current status, insufficient basis for switching outreach methods, duplicate outreach, or uneven resource allocation. In addition, the existing process does not adequately utilize the linkage between user payment feedback, outreach receipts, and subsequent strategy parameters, making it difficult to continuously revise subsequent collection strategies based on actual execution results. This affects the precision and closed-loop adaptive capability of the entire low-voltage payment collection process. To address the above problems, this invention proposes a solution. Summary of the Invention

[0003] In order to overcome the above-mentioned defects of the prior art, embodiments of the present invention provide a low-pressure payment collection process intelligent management and control system and method to solve the problems mentioned in the background art.

[0004] To achieve the above objectives, the present invention provides the following technical solution: A low-voltage bill collection intelligent management and control system includes the following modules: a multi-domain state section acquisition module, which is used to collect multi-source state data at the time of bill collection decision, and after preprocessing and normalization, obtains a logical intent vector representing the user's active expression characteristics and a physical load vector representing the user's actual electricity consumption behavior characteristics. The conflict degree token pool delineation module is used to calculate the data conflict degree coefficient based on the logical intent vector and the physical load vector to quantify the deviation between the user's proactive expression characteristics and the actual electricity consumption behavior characteristics. Based on the comparison result of the data conflict degree coefficient and the preset conflict degree threshold, the soft token candidate pool or hard token candidate pool is activated, and the executable action set is obtained through rigid constraint pruning. The token performance time-domain deduction module is used to select target tokens from the set of executable actions. Based on the type of the token candidate pool to which the target token belongs, it uses the data conflict coefficient to differentially modulate the initial performance base and basic attenuation constant of the target token to obtain the modulated initial penetration performance and modulated attenuation constant. Based on the initial penetration performance, attenuation constant and preset minimum charging pressure red line, it obtains the critical time difference required for the token penetration performance to decay to the minimum charging pressure red line, and generates the absolute timestamp and transition direction label for the next round of token triggering accordingly. The execution feedback self-correction module is used to perform user-specific correction on the basic attenuation constant after the target token is sent to the corresponding execution channel, based on the time deviation between the actual time of the user's cancellation and the absolute timestamp of the next round of token triggering.

[0005] In a preferred embodiment, the multi-domain state profile acquisition module collects multi-source state data including at least six types of state domain data: billing state domain, historical contact state domain, user response state domain, compliance constraint state domain, resource availability state domain, and external environment state domain. The multi-domain state profile acquisition module performs preprocessing and normalization on the six types of state domain data. Preprocessing includes at least filling missing values ​​and removing outliers for continuous numerical fields and encoding conversion for discrete label fields. Normalization is used to map each field to a unified value range. The multi-domain state profile acquisition module also extracts user profile feature groups from the historical contact state domain. The user profile feature groups include at least channel reachability, which represents the success rate of user connection or response on each soft channel; latency sensitivity, which represents the degree of time compression from receiving a payment reminder signal to generating an effective response; commitment fulfillment, which represents the proportion of users' historical commitment payments actually fulfilled; and complaint sensitivity, which represents the probability of users triggering complaint events under payment reminder pressure.

[0006] In a preferred embodiment, the logical intent vector includes at least an emotion polarity component mapped from the emotion classification results of the user's reply text, a response rate component calculated from the ratio of the number of valid responses to the number of touches within a preset historical window, a commitment payment duration component normalized from the time difference between the user's commitment payment time and the current time, a historical commitment fulfillment rate component calculated from the ratio of the number of historical commitments fulfilled to the number of historical commitments, and a soft channel proactive communication frequency component normalized from the number of times the user proactively replies or proactively inquires within a preset historical window. The physical load vector includes at least the daily average electricity consumption component obtained by normalizing the daily average electricity consumption within a preset statistical window, the peak electricity consumption ratio component calculated by the ratio of peak electricity consumption to total electricity consumption, the load continuity component calculated by combining the number of consecutive electricity consumption days, the number of zero electricity consumption days and the load fluctuation rate, the nighttime electricity consumption component calculated by the ratio of nighttime electricity consumption to total electricity consumption, and the electricity consumption growth rate component obtained by normalizing the growth rate of the current cycle electricity consumption relative to the previous cycle electricity consumption. The logical intent vector and the physical load vector are configured to have the same dimension.

[0007] In a preferred embodiment, the conflict level token pool delineation module normalizes the logical intent vector and the physical payload vector respectively to obtain normalized logical intent vector and normalized physical payload vector, and uses the cosine distance between the normalized logical intent vector and the normalized physical payload vector as the data conflict level coefficient; when the data conflict level coefficient is not higher than the preset conflict level threshold, the soft token candidate pool is activated; when the data conflict level coefficient is higher than the preset conflict level threshold, the soft token channel is closed and the hard token candidate pool is activated; the soft token candidate pool and the hard token candidate pool are not activated simultaneously in the same decision round; the tokens in the hard token candidate pool are pre-sorted according to their reach strength from low to high to form a strength ladder.

[0008] In a preferred embodiment, the rigid constraint trimming performed by the conflict degree token pool delineation module on the activated token candidate pool includes at least compliance boundary constraints, resource capacity constraints, action interval constraints, and evidence prerequisite constraints. The compliance boundary constraint is used to remove candidate tokens that do not meet the compliance conditions at the current decision time from the candidate pool based on the daily reach limit corresponding to the user's category tag and the preset silent period interval. Resource capacity constraints are used to remove candidate tokens from the candidate pool that currently lack sufficient execution resources, based on the number of available outbound call seats, the grid worker's shift status, and the online status of smart terminal communication. Action interval constraints are used to remove candidate tokens that do not meet the cooling-off requirements from the candidate pool based on the comparison between the last execution time of the same type of token by the same user and the shortest recurrence period of that type of token. The pre-evidence constraint is used to remove candidate tokens from the candidate pool that do not meet the pre-evidence conditions based on the matching results between the pre-notification requirements required for the candidate token and the existing payment reminder delivery evidence in the system.

[0009] In a preferred embodiment, the token performance time-domain deduction module selects target tokens from the set of executable actions in order of execution cost from low to high. When the target token belongs to the soft token candidate pool, the initial performance base of the target token is reduced by using the data conflict degree coefficient, so that the initial penetration performance after modulation is lower than the initial performance base of the target token. The basic attenuation constant of the target token is also reduced by using the data conflict degree coefficient, so that the attenuation constant after modulation is lower than the basic attenuation constant of the target token. When the target token belongs to the hard token candidate pool, the initial performance base of the target token is enhanced by using the data conflict degree coefficient, so that the initial penetration performance after modulation is higher than the initial performance base of the target token. The basic attenuation constant of the target token is also enhanced by using the data conflict degree coefficient, so that the attenuation constant after modulation is higher than the basic attenuation constant of the target token. Based on the initial penetration efficiency after modulation and the attenuation constant after modulation, an attenuation function is constructed to show how the token penetration efficiency of the target token decreases over time. The critical time difference is obtained by inverse solving with the preset minimum collection pressure red line as the boundary condition. The sum of the target token issuance time and the critical time difference is used as the absolute timestamp for the next round of token triggering.

[0010] In a preferred embodiment, the token performance time-domain extrapolation module generates a transition direction label based on the comparison result between the critical time difference and the preset short-term threshold; the preset short-term threshold includes the soft token short-term threshold corresponding to the soft token candidate pool and the hard token short-term threshold corresponding to the hard token candidate pool, and the hard token short-term threshold is greater than the soft token short-term threshold. When the target token belongs to the soft token candidate pool and the critical time difference is lower than the short-lived threshold of the soft token, the transition direction label is set to cross-pool transition, and the next round of tokens is selected from the hard token candidate pool; when the target token belongs to the hard token candidate pool and the critical time difference is lower than the short-lived threshold of the hard token, the transition direction label is set to in-pool upgrade, and the next round of tokens is selected from the hard token candidate pool by moving up one level according to the strength ladder; when the critical time difference is not lower than the corresponding short-lived threshold, the transition direction label is set to same-level reissue, and the next round of tokens maintains the current strength or selects a substitute token of the same level from the same pool.

[0011] In a preferred embodiment, the execution feedback self-correction module establishes an expiration status verification task with the next round of token trigger absolute timestamp as the expiration time. The expiration status verification task is used to obtain business status data related to the execution result of the target token from the accounting system and the execution channel corresponding to the target token when a cancellation receipt is generated for the user's overdue account or when the expiration time is reached. The business status data includes the target token issuance time, expiration time, cancellation status, actual cancellation time, token execution receipt, and event type label. The event type label includes an early cancellation event where the user completes the cancellation of overdue payments before the expiration time, and an overdue non-cancellation event where the user has not completed the cancellation by the expiration time. The execution feedback self-correction module encapsulates the business status data into response event records.

[0012] In a preferred embodiment, the execution feedback self-correction module calculates the normalized time deviation based on the response event record, and performs a multiplicative update on the user-specific weight factor of the target token according to the positive or negative direction of the normalized time deviation. The adjustment range of a single multiplicative update is determined by the product of the normalized time deviation and the preset self-correction learning rate. The updated user-specific weight factor is restricted to a preset weight constraint range. The product of the user-specific weight factor and the basic decay constant is used as the user-specific basic decay constant, which replaces the basic decay constant in the next round of token performance time-domain extrapolation.

[0013] A method for intelligent management and control of the entire process of low-voltage bill collection includes the following steps: collecting multi-source status data at the time of bill collection decision, and obtaining a logical intent vector representing the user's active expression characteristics and a physical load vector representing the user's actual electricity consumption behavior characteristics after preprocessing and normalization. The data conflict coefficient is calculated based on the logical intent vector and the physical load vector to quantify the deviation between the user's active expression and the actual electricity consumption behavior. The soft token candidate pool or hard token candidate pool is activated based on the comparison result of the data conflict coefficient and the preset conflict threshold. Rigid constraint pruning is performed on the activated token candidate pool to obtain the set of executable actions. Select a target token from the set of executable actions. Based on the type of the token candidate pool to which the target token belongs, use the data conflict coefficient to differentially modulate the initial performance base and basic attenuation constant of the target token to obtain the modulated initial penetration performance and modulated attenuation constant. Based on the modulated initial penetration performance, modulated attenuation constant and preset minimum charging pressure red line, the critical time difference required for the token penetration performance to decay to the minimum charging pressure red line is obtained. Based on this, the absolute timestamp and jump direction label of the next round of token triggering are generated. After the target token is sent to the corresponding execution channel, when the user's overdue account generates a cancellation receipt or when the absolute timestamp of the next round of token triggering is reached, business status data related to the execution result of the target token is obtained from the accounting system and the execution channel corresponding to the target token. Based on the business status data, the time deviation between the actual cancellation time and the absolute timestamp of the next round of token triggering is determined, and the basic attenuation constant is modified for user specificity according to the time deviation.

[0014] The technical effects and advantages of the low-pressure payment collection intelligent management and control system and method of the present invention are as follows: By uniformly collecting multi-source state data at the time of collection decision-making and generating logical intent vectors and physical payload vectors, the integrity and consistency of the input data for collection decisions are improved. By calculating the data conflict coefficient and activating the soft token candidate pool or hard token candidate pool accordingly, the range of collection action candidates can adaptively switch according to the user's current state. Through rigid constraint pruning, compliance boundaries, resource capacity, action intervals, and pre-existing evidence requirements can be considered simultaneously during the action generation stage, reducing the probability of tokens that do not meet the execution conditions entering subsequent processes. By using token performance time-domain extrapolation to generate the next round of token triggering time and transition direction, quantitative basis is provided for reissue, upgrade, or cross-pool switching. By correcting the basic attenuation constant based on the time deviation between the actual debt settlement time and the next round triggering time, the actual execution feedback can have a reverse effect on subsequent strategy generation, improving the refinement and closed-loop adaptive capability of the entire low-pressure collection process. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of a low-pressure payment collection process intelligent management and control method according to the present invention; Figure 2 This is a schematic diagram of the multi-domain state section construction of the present invention; Figure 3 This is a schematic diagram illustrating the conflict level token pool definition and rigid constraint pruning of the present invention. Figure 4 This is a schematic diagram illustrating the time-domain derivation of the token performance of the present invention; Figure 5 This is a schematic diagram illustrating the self-correction feedback mechanism of the present invention; Figure 6 This is a schematic diagram of the structure of a low-pressure payment collection intelligent management and control system for the entire process, as described in this invention. Detailed Implementation

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

[0017] Example: Please refer to Figure 1 As shown in the figure, this embodiment discloses a low-voltage electricity debt collection intelligent management and control system. This system is used for debt collection scenarios of low-voltage electricity customers. It generates a multi-source status profile by uniformly collecting the account status, historical contact status, user response status, compliance constraint status, resource availability status, and external environment status. Then, it defines soft and hard token candidate pools based on the degree of deviation between the user's proactive expression and actual electricity consumption behavior. Subsequently, it performs compliance, resource, interval, and evidence constraint pruning on the candidate tokens, and generates the current execution token and the next transition time according to the law of token effectiveness decay over time. Finally, it corrects the token effectiveness parameters and user profile characteristics based on actual debt settlement feedback, thereby forming a closed-loop management and control process from data collection, action generation, execution monitoring to feedback calibration. In this embodiment, the token refers to a collection action unit that the system can schedule and execute. Each token includes at least a token identifier, execution channel, execution cost, initial performance base, basic attenuation constant, shortest recurrence cycle, and pre-execution evidence requirements. The soft token refers to a collection action that reaches the user mainly through non-on-site, non-physical constraint methods such as SMS, AI outbound calls, WeChat for Work, and electronic bill reminders. The hard token refers to a collection action with strong reach and confirmation strength or physical perception strength, such as smart meter sound and light prompts, smart meter screen character prompts, or on-site verification by grid workers. The collection decision time refers to the time point at which the system calculates a collection strategy based on a preset cycle or triggering event. It can be a fixed time every day, or it can be the time when the arrears status changes, a user response event occurs, the resource status changes, or the time when the previous round of tokens expires. Please see Figure 2 As shown, the multi-domain state section acquisition module is used to acquire multi-source state data at the time of payment reminder decision. After preprocessing and normalization, it obtains a logical intent vector that represents the user's active expression characteristics and a physical load vector that represents the user's actual electricity consumption behavior characteristics. The purpose of this module is to transform heterogeneous data scattered across the marketing accounting system, collection event logs, soft channel receipt library, compliance rule library, scheduling center, metering system and external environment interfaces into a unified data structure at each collection decision moment, so as to provide standard input for subsequent conflict degree calculation, token pool allocation and time domain extrapolation. Specifically, this module is used at the time of payment reminder decision. Trigger multi-domain data acquisition; the multi-domain data includes at least the following six state domains: The first category is the billing status field, which reads the current user's outstanding balance from the marketing billing system. Overdue period and the payment rhythm of the past twelve months Among them, the base amount of arrears Indicates user as of Outstanding amount and duration of outstanding payment. It means from the date of the overdue payment to... Duration between; historical payment rhythm This is used to characterize how long it typically takes for users to complete payment after the bill is generated; the past twelve months is used as the default statistical period, and its initial value is based on the fact that the payment behavior of low-voltage residential and micro-enterprise customers usually has the characteristics of a monthly billing cycle. Twelve months can cover seasonal differences in electricity consumption and payment fluctuations during holidays, while avoiding diluting recent behavioral changes with too long historical data. The second category is the historical contact status domain, which reads the sequence of recent collection actions from the collection event log. and its delivery success identifier, answer identifier, reply identifier, and account cancellation result; the recent collection action sequence This refers to a record of several payment reminder actions arranged chronologically before the current decision-making moment; the system has a limit on the number of historical tracing actions. , used to limit the scope of sequence analysis; The initial value is set to 12 times. The calibration basis is as follows: In low-voltage collection scenarios, too few historical contact records are difficult to reflect the user's habitual response to different channels, while too many historical records are easy to introduce outdated behavioral characteristics. Using 12 times as the initial value can cover typical collection behaviors in multiple billing periods and control the computing load. Those skilled in the art can adjust it to 8 to 20 times according to the actual collection frequency of the power supply unit. The third category is the user response status domain, which reads the user's most recent soft channel interaction reply text, answering delay, response rate, and whether a payment commitment has been made from the soft channel receipt library; the response rate refers to the proportion of users who provide effective feedback to SMS, AI outbound calls, WeChat Work, or electronic bill reminders within a preset historical window; the answering delay refers to the time difference between the soft channel action being delivered and the user generating an effective response such as answering, clicking, replying, or confirming; natural language processing is performed on the reply text to extract semantic features such as emotional polarity, commitment to payment time, and intention to refuse payment; The fourth category is the compliance constraint status domain, which reads user category tags and daily reach limits from the compliance rule base. Quiet period interval Required prior notification regarding permitted channels and specific actions; user classification tags must include at least resident users, non-resident users, sensitive users, key protected users, and users who have been complained about; daily contact frequency limit. The initial value is set at 3 times / day for residential users and 6 times / day for non-residential users; quiet period intervals. The initial values ​​are set from 22:00 to 08:00 the next day. The basis for setting the above initial values ​​is: residential users are more sensitive to nighttime and high-frequency contact, while non-residential users usually have a higher tolerance for business contacts during working hours, so differentiated frequency boundaries are set; the quiet period covers the usual rest period to reduce the risk of contact disturbing residents; the above initial values ​​can be adjusted according to local regulatory requirements, power supply service specifications or user authorization agreements. The fifth category is the resource availability status domain, which reads the number of available outbound call agents from the dispatch center. Grid worker shift status Smart terminal communication online status Among them, the number of outbound call seats available is [number missing]. Used to determine whether AI-powered outbound calls or manual review have the necessary resources to execute; grid worker scheduling status. Used to determine whether the door-to-door collection token meets the execution conditions; online status of smart terminal communication. Used to determine whether actions such as sound and light prompts and scrolling of characters on the screen of a smart meter can be transmitted through the data collection terminal; The sixth category is the external environment state domain; the system reads real-time temperature, extreme weather indicators, and holiday indicators for the station area from the meteorological interface and calendar service. And special supply guarantee identifiers; this type of information is used to help determine whether to restrict hard token triggering; for example, in special environments such as high temperature, low temperature, typhoon, and rainstorm, stricter compliance thresholds can be set for grid workers to verify tokens on-site or the process can be suspended directly; After the six status domains are collected, preprocessing and normalization are performed. For continuous numerical fields, missing values ​​and obvious outliers are removed first. If a single field is missing, the average value of the user over the past three months is used to fill it in. If the user's historical data is insufficient, the average value of users of the same type in the same area is used to fill it in. Subsequently, the data is processed according to the historical average value of the field. and standard deviation Perform Z-Score normalization and map the normalization result to Intervals; for example, a truncated linear mapping method can be used; For discrete label fields, one-hot encoding or hierarchical encoding is preferred to convert them into numerical components; for time series data, statistical features such as mean, variance, peak value, recent value and rate of change are extracted within a preset window; the initial value of the preset window is the past 30 days, and its calibration is based on the fact that the past 30 days can cover a regular payment cycle and is suitable for characterizing users' recent reach performance and response habits. After preprocessing, the data is mapped to logical intent vectors. and physical load vector Logical Intent Vector Dimensions used to characterize behavioral features at the level of user active expression The initial value is set to 5, and the components are, in order, the emotion polarity component, the response rate component, the promised payment duration component, the historical promise fulfillment rate component, and the frequency of proactive communication via soft channels component; among them, the emotion polarity component is obtained by the user's reply text through an emotion classification model or keyword rules, with negative, neutral, and positive being mapped to 0, 0.5, and 1, respectively. The response rate component is calculated as the ratio of the number of valid responses to the number of contacts within a preset historical window; The promised payment duration component is obtained by normalizing the time difference between the promised payment time and the current time; the shorter the time difference, the higher the value. The historical commitment fulfillment rate component is calculated as the ratio of the number of historical commitments fulfilled to the total number of historical commitments. The frequency component of active communication in the soft channel is obtained by normalizing the number of user active replies or inquiries within a preset historical window. Physical load vector Features used to characterize users' actual electricity consumption behavior, their dimensions The initial value is set to 5, and the components are, in order, the average daily electricity consumption, the peak-hour electricity consumption ratio, the load continuity component, the nighttime electricity consumption component, and the electricity consumption growth rate component; among them, The daily average electricity consumption component is obtained by normalizing the daily average electricity consumption over the past 30 days. The peak-hour electricity consumption percentage is calculated as the ratio of peak-hour electricity consumption to total electricity consumption. The load continuity component is calculated by combining the number of days with continuous electricity consumption, days with zero electricity consumption, and load fluctuation rate. The nighttime electricity consumption component is calculated as the ratio of nighttime electricity consumption to total electricity consumption; The electricity consumption growth rate component is obtained by normalizing the current cycle's electricity consumption growth rate relative to the previous cycle's electricity consumption growth rate. Both vector dimensions are set to 5 to ensure a one-to-one geometric comparison between proactively expressed features and actual electricity consumption behavior features in subsequent cosine distance calculations. When new features are added in actual business operations, the consistency of the two vector dimensions can be maintained through feature selection or principal component compression. It should be noted that when the L2 norm of the logical intent vector L or the physical load vector P is 0, the system does not directly perform cosine distance calculations but processes it according to the preset default strategy. Specifically, if only the logical intent vector is missing, the system uses the average logical intent vector of the same type of user in the same area as a substitute; if only the physical load vector is missing, the system uses the average historical electricity consumption of the user over the past three months to construct a substitute vector; if both types of vectors are missing, the system marks the user as having insufficient data and transfers the request to manual review or uses the lowest strength soft token for initial contact. In addition to the two vectors mentioned above, at least the following four user profile features are extracted from the historical reach sequence: channel reachability. Defined as the average connection or response success rate of users on each soft channel, with a value range of [value missing]. The initial value is the statistical average of the past 30 days; delay sensitivity Defined as the average time compression from when a user receives a payment reminder signal to when they generate a valid response, with a value range of [value missing]. The faster the response, the larger the value; the initial value is the average time compression of valid response events over the past 30 days; commitment fulfillment rate. Defined as the actual fulfillment rate of a user's historical promised payments, with a value range of [value range missing]. The initial value is the fulfillment rate of commitments made in the past 12 months; complaint sensitivity. Defined as the probability that a user triggers a complaint under pressure from payment collection, with a value range of [value missing]. The initial value is the ratio of the number of complaints to the number of contacts in the past 12 months; the above profile features are used for subsequent self-correction of feedback, so that the same token can produce differentiated effects for different users; This module ultimately outputs a structured multi-source state cross-section. The multi-source state cross section includes at least cross-domain vector pairs. User profile feature group Compliance and Constraint Group Resource Capacity Group Arrears base and the time of cross-section generation This structured multi-source state section serves as the input to the conflict degree token pool delineation module.

[0018] Please see Figure 3 As shown, the conflict degree token pool delineation module is used to calculate the data conflict degree coefficient based on the logical intent vector and the physical load vector to quantify the deviation between the user's proactive expression characteristics and the actual electricity consumption behavior characteristics. Based on the comparison result of the data conflict degree coefficient and the preset conflict degree threshold, the soft token candidate pool or hard token candidate pool is activated, and the executable action set is obtained by rigid constraint pruning. The purpose of this module is to leverage the logical intent vector output by the multi-domain state section acquisition module. and physical load vector The deviation between the active expression and actual behavior of the same user at the same decision moment is calculated, and a soft token candidate pool or a hard token candidate pool is selected accordingly. Then, the set of executable actions is obtained by pruning through rigid constraints. First, calculate the data conflict coefficient. The data conflict coefficient Used to quantify the degree of inconsistency between users' proactive statements and actual electricity consumption behavior, with a value range of [value range missing]. ; The closer it is to 0, the higher the consistency between the user's actively expressed characteristics and the actual electricity consumption behavior characteristics, and the higher the expected response efficiency of conventional soft-touch actions; The closer it is to 1, the greater the deviation between the user's actively expressed characteristics and the actual electricity consumption behavior characteristics, and the lower the expected response efficiency of conventional soft-touch actions; In this embodiment, the data conflict coefficient is calculated using the cosine distance form. Specifically, for the logical intent vector... and physical load vector Normalization is performed separately, and in this embodiment, L2 norm normalization is preferred to obtain the normalized vector. and Then, the cosine distance is used to calculate the data conflict coefficient. Right now In the formula, This represents the dot product of two normalized vectors. The reason for using cosine distance is that this distance focuses more on the directional difference between the two feature vectors, rather than the absolute scale difference such as the amount owed or the amount of electricity used, and can more stably represent the consistency between the active expression trend and the real behavior trend. Calculate the data conflict coefficient Then, based on the preset conflict threshold Define the token pool; This is the soft token response performance switching threshold, used to determine whether to continue using the soft token candidate pool as the priority action set in the current user state. Its initial value is set to 0.5; the initial value is set based on the fact that the cosine distance is located at... When the range is defined, 0.5 can be used as the dividing point between low and medium deviation of active expression and real behavior and medium to high deviation. In actual deployment, ROC curves or precision-recall balance analysis can be performed using two types of data from historical samples: on-time cancellation after soft reach and non-cancellation after soft reach. This threshold can then be recalibrated. when If the consistency between the user's actively expressed characteristics and actual electricity consumption behavior is within a preset acceptable range, it indicates that there is no significant deviation between the user's current feedback information and actual electricity consumption behavior. Therefore, the conventional soft-reach method still has value and is activated in the soft token candidate pool. ; when If the deviation between the user's actively expressed characteristics and the actual electricity consumption behavior characteristics reaches or exceeds a preset conflict threshold, it indicates that the expected response efficiency of the conventional soft-reach method in the current round is reduced. Therefore, the soft token channel is closed and the hard token candidate pool is activated. ; It should be noted that the soft token candidate pool and the hard token candidate pool are not activated at the same time to avoid conflicting collection actions in the same decision round. In this embodiment, the soft token candidate pool The system must pre-configure at least the following four types of tokens: payment reminder SMS token, AI outbound call token, WeChat push token, and electronic billing reminder token. Hard token candidate pool The system should pre-configure at least four types of tokens: smart meter audio-visual reminder token, smart meter screen scrolling payment reminder token, and grid worker on-site verification token; each token should have its execution cost bound in the system configuration table. Initial performance base Basic attenuation constant Shortest recurrence cycle and prerequisite evidence requirements Where i represents the token identifier, i=1,2,…,n, and n represents the total number of tokens in the currently activated token candidate pool; This represents the execution cost of the i-th token. This represents the initial performance base of the i-th token before user conflict modulation. This represents the basic attenuation constant of the i-th token before user conflict degree modulation. This represents the shortest time interval during which the i-th token is allowed to be executed repeatedly. This represents the evidentiary preconditions that must be satisfied before the i-th token is executed; The hard token pool is sorted from low to high strength as follows: smart meter audio and visual prompts, smart meter screen scrolling reminder characters, and grid member on-site verification. This sorting is used for the pool upgrade determination of the token effectiveness time domain inference module. Once the token pool is defined, rigid constraints are applied to all candidate tokens in the activation pool. These rigid constraints include compliance boundary constraints, resource capacity constraints, action interval constraints, and evidence prerequisite constraints. Compliance boundary constraints are used to determine the current decision-making moment. Does it fall into a silent period? And whether the user has reached the daily reach limit on the number of times they have been reached that day. If any condition is triggered, the corresponding token is removed from the candidate set. Resource capacity constraints are used to determine whether the external resources on which token execution depends are available; AI outbound call tokens require a certain number of available outbound call agents. The AI ​​outbound call channel is either available or its status is not specified; the grid worker's on-site visit token requires the grid worker's scheduling status. The user must be on duty and the current work order capacity must not exceed the limit; smart terminal tokens require the smart terminal to be in an online communication state. The resource is online; if the resource is unavailable, the corresponding token is removed. Action interval constraints are used to prevent the same type of reminder action from being repeatedly delivered within a short period of time; read the last execution time of the same type of token for the same user. ,calculate Is it below the shortest recurrence cycle of the token? Among them, the shortest recurrence cycle for soft tokens. The initial value is set to 24 hours, which is the shortest recurrence period for hard tokens. The initial value is set at 72 hours. The basis for this initial value is that: too frequent soft outreach can easily lead to a decrease in the response rate or an increase in the risk of complaints, while hard outreach has a stronger sense of pressure and intensity of contact confirmation, so a longer cooling-off period needs to be set to ensure the proportionality principle and service compliance. The evidence requirement constraint is used to determine whether the necessary notification has been completed before the execution of a specific hard token; the grid worker's on-site verification of the token requires the system to have at least two evidences of payment reminder SMS delivery or equivalent electronic notification evidence; the grid worker's on-site verification of the token requires at least one AI outbound call answering evidence, SMS delivery evidence or manual record confirmation; if the evidence is insufficient, the token will not be included in the set of executable actions. After the above trimming, we obtain the set of executable actions for the current collection round. The final output of this module is the data conflict coefficient. Executable action set and the activated token pool identifier It is then passed to the token performance time-domain deduction module.

[0019] Please see Figure 4 As shown, the token performance time-domain deduction module is used to select target tokens from the set of executable actions. Based on the type of the token candidate pool to which the target token belongs, it uses the data conflict coefficient to differentially modulate the initial performance base and basic attenuation constant of the target token to obtain the modulated initial penetration performance and modulated attenuation constant. Based on the initial penetration performance, attenuation constant and preset minimum charging pressure red line, it obtains the critical time difference required for the token penetration performance to decay to the minimum charging pressure red line, and generates the absolute timestamp and transition direction label for the next round of token triggering accordingly. The purpose of this module is to select the current execution token from the set of executable actions output by the conflict token pool delineation module, and to combine this with the data conflict coefficient (see [link to relevant documentation]). Figure 4As shown, the token performance time-domain deduction module is used to select target tokens from the set of executable actions. Based on the type of the token candidate pool to which the target token belongs, it uses the data conflict coefficient to differentially modulate the initial performance base and basic attenuation constant of the target token to obtain the modulated initial penetration performance and modulated attenuation constant. Based on the initial penetration performance, attenuation constant and preset minimum charging pressure red line, it obtains the critical time difference required for the token penetration performance to decay to the minimum charging pressure red line, and generates the absolute timestamp and transition direction label for the next round of token triggering accordingly. The purpose of this module is to select the current execution token from the set of executable actions output by the conflict token pool delineation module, and to combine this with the data conflict coefficient. Differentiated modulation is applied to the initial penetration effectiveness and decay rate of the token, thereby calculating the time required for the token effectiveness to decay to the minimum collection pressure threshold, and generating the next round of token trigger timestamp and transition direction; Differentiated modulation is applied to the initial penetration effectiveness and decay rate of the token, thereby calculating the time required for the token effectiveness to decay to the minimum collection pressure threshold, and generating the next round of token trigger timestamp and transition direction. First, from the set of executable actions Select target token In a preferred embodiment, according to the execution cost The token with the lowest cost is selected as the current target token, from low to high. If multiple tokens have the same execution cost, the token with higher user channel reachability is selected first. If they are still the same, the token with lower historical complaint risk is selected. This selection rule is used to reduce resource consumption and user disturbance while ensuring the effectiveness of collection. Furthermore, the initial performance base of the target token is read from the configuration table. and fundamental attenuation constant In this embodiment, the initial performance base of the soft token class is... The initial value is set to 100 dimensionless performance units, and the basic decay constant for soft tokens is... The initial value is set to 0.05 per hour; the initial performance base for hard tokens. The initial value is also set to 100 dimensionless efficiency units, and the basic decay constant for hard tokens is also set. The initial value is set to 0.04 per hour; the initial performance base is uniformly set to 100 to facilitate comparison of different tokens on the same scale; the basic decay constant of hard tokens is smaller than that of soft tokens because hard tokens usually have higher reach and more explicit execution confirmation results, so their expected effect intensity decays at a relatively low rate. Subsequently, the data conflict coefficient is used for execution. Initial penetration performance reconstruction driven by the target token; the initial penetration performance is used to characterize the expected strength of the target token's effective response to the user at the initial moment of issuance; For soft tokens, the larger the data conflict coefficient K, the greater the deviation between the user's actively expressed characteristics and the actual electricity consumption behavior characteristics. Historically, the probability of such users responding effectively to soft-touch actions is lower. Therefore, the initial penetration effectiveness of soft tokens decreases as K increases. For hard tokens, the larger the data conflict coefficient K, the lower the expected response efficiency of conventional soft outreach actions in the current user state, and the more necessary it is to use actions with higher outreach strength or higher confirmation strength to supplement them; therefore, the initial penetration efficiency of hard tokens increases with the increase of K. Then, based on the data conflict coefficient The initial penetration performance reconstruction of the driver can be represented by the following equation: In the formula, The soft token conflict sensitivity index is used to characterize the superlinear decrease in the initial penetration effectiveness of a soft token as the data conflict coefficient K increases. Its value ranges from 1.0 to 2.0, and in this embodiment, it is set to 1.5. This is the hard token conflict gain factor, initially set to 0.3; The value greater than 1 is chosen to reflect that the effectiveness of the soft token decreases superlinearly as the conflict level increases; The value of 0.3 is set to keep the hard token gain within a controllable range and prevent high-conflict users from directly triggering overly strong actions. Next, the execution is carried out by The attenuation constant mapping is driven by the following formula: For soft tokens, users can easily perform immediate desensitization for similar channels such as SMS, outbound calls, and WeChat Work. Therefore, the attenuation constant of soft tokens adopts an exponential acceleration mapping, as shown in the following formula: In the formula, The soft token desensitization acceleration factor is set to an initial value of 1.0; For hard tokens, since they rely on reach confirmation strength, physical sensing, or human contact, the expected response performance decays relatively slowly. Therefore, the hard token decay constant adopts a linear mild mapping, as shown in the following equation: In the formula, The hard token attenuation modulation factor is initially set to 0.3. This factor can be calibrated using historical collection samples: the time it takes for the user to complete the cancellation after the token is issued is used as the observed value of the effectiveness duration, and the least squares method is used to fit different... The decay rate within the interval is calculated, and the initial parameters are obtained by smoothing the fitting results. After mapping the initial penetration performance to the attenuation constant, we further construct an attenuation function for the token penetration performance over time, as follows: In the formula, This is the current time when the token was issued. For any time after the document is issued, Indicates the target token is in The remaining penetration effectiveness at a given time; this function describes the process by which the expected strength of the token's effective response to the user gradually decreases over time after the token is issued. The system sets a minimum collection pressure threshold. Its initial value is set to 30 dimensionless efficiency units; The calibration criteria are as follows: when the token's effectiveness falls below approximately 30% of its initial value, the probability of users continuing to actively pay for the token decreases significantly, necessitating consideration of reissuance, upgrade, or cross-pool migration; Substitute the decay function and solve for the critical time difference in reverse. : ; If the calculation yields This indicates that the current token was insufficient to create effective collection pressure when it was issued, and the system will... Set to 0 and proceed directly to the upgrade or manual review process; if The system is based on Generating the next round of tokens triggers an absolute timestamp. ; Subsequently, the system according to The relationship with the short-term threshold determines the transition direction; soft token short-term threshold The initial value is set to 6 hours, which is the short-lived threshold for hard tokens. The initial value is set to 36 hours; If the current token is a soft token, and This indicates that the soft token decays to the pressure threshold within a short period, which is considered a cross-pool transition, and it will be prioritized for entry into the hard token pool in the next round; for example, if the current token is a payment reminder SMS token, the system calculates its critical time difference. Hours, while the short-lived threshold of soft tokens The initial value is 6 hours; since 3.5 < 6, it indicates that the expected effective time of the SMS token in the current user state is short, and the gain of continuing to reissue the same soft touch action is limited; therefore, the jump direction label JumpFlag is recorded as a cross-pool jump, and in the next round, tokens that meet the compliance constraints, resource constraints and evidence-based constraints, such as smart meter sound and light prompt tokens or smart meter screen reminder character scrolling tokens, are selected from the hard token candidate pool first. If the current token is a hard token, and This indicates that the current hard token strength is insufficient, and it is determined to be an upgrade within the pool. In the next round, it will move up one level in the hard token pool according to the strength ladder. For example, the current token is a smart meter audio-visual prompt token, and the system calculates its critical time difference. Hours, while the short-lived threshold of hard tokens The initial value is 36 hours; since 24 < 36, it indicates that the expected effective time of the current hard token in this user state is insufficient to support a longer reminder window, and the system records the jump direction label JumpFlag as an upgrade within the pool; if the smart meter screen reminder character scrolling token meets the requirements of silent period, daily contact frequency, terminal online and advance notification, then the smart meter screen reminder character scrolling token will be selected first in the next round; if the token does not meet the constraints, then the next executable token will be selected from the hard token pool according to the strength ladder and constraint pruning results; like If the value is not lower than the corresponding short-term threshold, it will be judged as a replacement of the same level, and the current token strength will be maintained in the next round or a low-cost token of the same level will be selected in the same pool. For example, the current token is an AI outbound call token, and the system calculates its critical time difference. Hours, while the short-lived threshold of soft tokens The initial value is 6 hours; since 9 > 6, it indicates that the token still has an expected effective time of no less than the preset short-term threshold under the current user status, and the system does not trigger cross-pool transition; if the user has not cleared the account when the next trigger time arrives, the system can continue to select the AI ​​outbound call token for same-level reissue; if the current outbound call resources are insufficient or the user has reached the outbound call action interval limit, the system can select the same level and lower execution cost of the Enterprise WeChat push token or electronic bill posting reminder token as the alternative token from the soft token pool; This module ultimately outputs the currently executing token instruction. Token issuance time Next round trigger absolute timestamp and jump direction labels The above information is then passed to the execution feedback self-correction module.

[0020] Please see Figure 5 As shown, the execution feedback self-correction module is used to perform user-specific correction on the basic attenuation constant after the target token is sent to the corresponding execution channel, based on the time deviation between the actual cancellation time of the user and the absolute timestamp of the next round of token triggering. The purpose of this module is to transform the token execution results generated by the token performance time-domain extrapolation module into computable feedback events. By comparing the deviation between the actual debt settlement time and the system extrapolation time, the token decay parameters and user profile characteristics are corrected, so that the next round of debt collection strategy is more in line with the actual user behavior. Execute token instructions based on the time-domain inference module output by the token performance model. The target token is sent to the corresponding execution channel; For example, for SMS tokens, the system calls the SMS platform to send payment reminders and records the delivery status; for AI outbound call tokens, the system calls the outbound call platform to initiate calls and records answering, rejecting, call duration, and voice recognition results; for WeChat push tokens, the system records message reach, reading, and reply status; for smart meter audio-visual prompts or screen character scrolling tokens, the system issues control commands through the data collection terminal and records terminal receipts; for grid worker on-site verification tokens, the system generates an on-site verification work order and pushes it to the grid worker's terminal, whereby the grid worker verifies the user's overdue payment status, contact information, and payment feedback and sends back the verification results. After the target token is issued, the next round of token triggers the absolute timestamp. An expiration status verification task is established for each expiration date. This task does not continuously monitor user activities; instead, it reads business status data directly related to the target token's execution result from the billing system and the execution channel corresponding to the target token when a cancellation receipt is generated for a user's overdue account, or when the expiration date arrives. This business status data includes account identifier, token identifier, token type, target token issuance time, expiration date, cancellation status, and actual cancellation time. The system includes token execution receipts and event type tags; event type tags include early cancellation events and overdue non-cancellation events. Early cancellation events indicate that a user's overdue account generates a cancellation receipt before the due date, while overdue non-cancellation events indicate that the overdue account has not generated a cancellation receipt by the due date. The execution feedback self-correction module encapsulates business status data into response event records. This is used to calculate the time deviation and correct the fundamental attenuation constant; Calculate the normalized time deviation based on the response event log. When the event type is an early write-off event, Calculate as follows: ;at this time, The larger the absolute value of a negative value, the earlier the user's actual cancellation time is compared to the system's estimated time, indicating that the estimate of token effectiveness is too conservative or the estimate of decay rate is too high. When the event type is an overdue unresolved event, the time deviation will be... A value of +1 indicates that the token failed to achieve the expected write-off result within the preset performance window, suggesting either an overly optimistic estimate of token performance or an underestimation of the decay rate; the system will... Constraints Within the range, to prevent drastic fluctuations in parameters caused by abnormal accounting times or system delays; Subsequently, the user-specific weighting factor of the basic decay constant was applied. Fine-tuning is performed; the user-specific weighting factor Used to characterize the degree of deviation of the i-th token relative to the general basic decay constant under the current user profile. The initial value is set to 1.0, indicating that the system uses the general basic decay constant in the configuration table before obtaining the user feedback sample; and a self-correcting learning rate is introduced. The initial value is set to 0.05 as the adjustment step size for the weighting factor in a single feedback. Based on normalized time deviation The positive and negative directions of the user-specific weighting factor Perform directional correction: when When the value is negative, it indicates that the user's actual cancellation time is earlier than the system's predicted trigger time for the next round. The system determines that the actual duration of the token's effect in this user scenario is not less than the predicted result, and therefore adjusts the token in the direction of reducing the decay rate. ;when When the value is positive, it indicates that the user has not completed the cancellation within the simulation window or the actual response is later than the system's simulation result. The system determines that the actual duration of the token's effect in this user scenario is shorter than the simulation result, and therefore adjusts it in the direction of increasing the decay rate. ; In this embodiment, the directional correction can be implemented using a multiplicative update method, that is, according to... With self-correcting learning rate The product of these factors determines the magnitude of a single adjustment, and the adjusted weighting factor is constrained within a preset weight constraint interval; the initial value of the preset weight constraint interval is set to... This is used to prevent excessive weight factor shift caused by a single abnormal feedback event; the updated weight factor is multiplied by the general basic attenuation constant in the configuration table to obtain the user-specific basic attenuation constant, and replaces the original general basic attenuation constant in the next round of token performance time domain deduction. As a specific implementation, the update of the weight factor can be expressed as: In the formula, This represents a truncation function, used to restrict the update result to a preset weight constraint interval. Let represent the user-specific base decay constant for the i-th token facing the current user. The updated user-specific base decay constant can be expressed as: In the formula, Represents the user-specific fundamental decay constant for the i-th token oriented towards the current user; This represents the general fundamental decay constant of the i-th token in the system configuration table; This user-specific basic decay constant will replace the general basic decay constant in the next round of token performance time-domain extrapolation module, in order to generate performance extrapolation results that are more in line with the user's response habits; The system also updates four user profile features simultaneously; regarding channel reachability If this round uses a soft token and the transaction is successfully completed with early cancellation, the adjustment will be increased using an exponentially weighted moving average. If the transaction fails to be completed or the transaction is not cancelled by the due date, the adjustment will be decreased in the same way. The exponentially weighted moving average coefficient... The initial value was set to 0.2, based on the following: 0.2 allows recent behavior to have a perceptible impact on the profile while preserving historical stability; and it also addresses latency sensitivity. The system according to Compared to The degree of compression is updated accordingly; the earlier the settlement, the higher the sensitivity to delays; regarding the fulfillment of commitments... If the user makes a specific payment commitment during this round of soft channel interaction, the system will determine the actual time of account cancellation. Whether the contract falls within the promised time window is considered a successful fulfillment if it does, and a failed fulfillment otherwise. The data is updated using an exponentially weighted moving average. (Regarding complaint sensitivity...) If a complaint event is triggered in this round of tokens, the tokens will be increased in a weighted manner; if no complaint is triggered in several consecutive rounds, the tokens will be gradually decreased in a uniform step size, the initial value of which can be set to 0.02. After updating parameters and user profile, the system determines whether the user has completed the debt cancellation process. If the user has cancelled the debt, the system closes the current collection loop, generates a collection loop record, and archives it. If the user has not cancelled the debt, the system... The multi-domain state profile acquisition module is constantly retried to acquire new multi-source state profiles and enter the next round of collection decision based on the updated user profile and token parameters; Through the above implementation methods, the present invention can transform the low-pressure collection process from a single, experience-based, fixed-frequency reminder method into an intelligent closed-loop management method based on user behavior conflict degree, token effectiveness decay, and execution feedback self-correction. This not only improves the matching degree between collection actions and user status, but also reduces the risk of excessive collection and illegal contact through compliance constraints, resource constraints, action interval constraints, and evidence pre-requisite constraints.

[0021] Please see Figure 6 As shown, this invention discloses a method for intelligent control of the entire low-voltage bill collection process, including the following steps: collecting multi-source state data at the bill collection decision moment, and obtaining a logical intent vector representing the user's active expression characteristics and a physical load vector representing the user's actual electricity consumption behavior characteristics after preprocessing and normalization; The data conflict coefficient is calculated based on the logical intent vector and the physical load vector to quantify the deviation between the user's active expression and the actual electricity consumption behavior. The soft token candidate pool or hard token candidate pool is activated based on the comparison result of the data conflict coefficient and the preset conflict threshold. Rigid constraint pruning is performed on the activated token candidate pool to obtain the set of executable actions. Select a target token from the set of executable actions. Based on the type of the token candidate pool to which the target token belongs, use the data conflict coefficient to differentially modulate the initial performance base and basic attenuation constant of the target token to obtain the modulated initial penetration performance and modulated attenuation constant. Based on the modulated initial penetration performance, modulated attenuation constant and preset minimum charging pressure red line, the critical time difference required for the token penetration performance to decay to the minimum charging pressure red line is obtained. Based on this, the absolute timestamp and jump direction label of the next round of token triggering are generated. After the target token is sent to the corresponding execution channel, when the user's overdue account generates a cancellation receipt or when the absolute timestamp of the next round of token triggering is reached, business status data related to the execution result of the target token is obtained from the accounting system and the execution channel corresponding to the target token. Based on the business status data, the time deviation between the actual cancellation time and the absolute timestamp of the next round of token triggering is determined, and the basic attenuation constant is modified for user specificity according to the time deviation.

[0022] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0023] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product.

[0024] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and inventive constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0025] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0026] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0027] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A low-voltage fee collection full-process intelligent management and control system, characterized in that, It includes the following modules: a multi-domain state section acquisition module, which is used to acquire multi-source state data at the time of payment reminder decision, and after preprocessing and normalization, obtains a logical intent vector representing the user's active expression characteristics and a physical load vector representing the user's actual electricity consumption behavior characteristics; The conflict degree token pool delineation module is used to calculate the data conflict degree coefficient based on the logical intent vector and the physical load vector to quantify the deviation between the user's proactive expression characteristics and the actual electricity consumption behavior characteristics. Based on the comparison result of the data conflict degree coefficient and the preset conflict degree threshold, the soft token candidate pool or hard token candidate pool is activated, and the executable action set is obtained through rigid constraint pruning. The token performance time-domain deduction module is used to select target tokens from the set of executable actions. Based on the type of the token candidate pool to which the target token belongs, it uses the data conflict coefficient to differentially modulate the initial performance base and basic attenuation constant of the target token to obtain the modulated initial penetration performance and modulated attenuation constant. Based on the initial penetration performance, attenuation constant and preset minimum charging pressure red line, it obtains the critical time difference required for the token penetration performance to decay to the minimum charging pressure red line, and generates the absolute timestamp and transition direction label for the next round of token triggering accordingly. The execution feedback self-correction module is used to perform user-specific correction on the basic attenuation constant after the target token is sent to the corresponding execution channel, based on the time deviation between the actual time of the user's cancellation and the absolute timestamp of the next round of token triggering.

2. The low-voltage intelligent management and control system according to claim 1, characterized in that, The multi-domain state profile acquisition module collects multi-source state data that includes at least six types of state domain data: accounting state domain, historical contact state domain, user response state domain, compliance constraint state domain, resource availability state domain, and external environment state domain. The multi-domain state section acquisition module performs preprocessing and normalization on six types of state domain data. The preprocessing includes at least filling missing values ​​and removing outliers in continuous numerical fields, as well as encoding conversion of discrete label fields. Normalization is used to map each field to a uniform value range. The multi-domain state section acquisition module also extracts user profile feature groups from the historical reach state domain. The user profile feature groups include at least the channel reachability, which represents the success rate of the user's connection or response on each soft channel; the delay sensitivity, which represents the degree of time compression from the user receiving the payment reminder signal to generating an effective response; the commitment fulfillment rate, which represents the proportion of the user's historical commitment to pay that has actually been fulfilled; and the complaint sensitivity, which represents the probability of the user triggering a complaint event under the pressure of payment reminders.

3. The low-pressure fee-charging full-process intelligent management and control system according to claim 2, characterized in that, The logical intent vector includes at least the emotion polarity component obtained by mapping the emotion classification results of the user's reply text, the response rate component calculated by the ratio of the number of valid responses to the number of contacts within a preset historical window, the promised payment duration component obtained by normalizing the time difference between the user's promised payment time and the current time, the historical promise fulfillment rate component calculated by the ratio of the number of historical promises fulfilled to the number of historical promises fulfilled, and the soft channel proactive communication frequency component obtained by normalizing the number of user proactive replies or proactive inquiries within a preset historical window. The physical load vector includes at least the daily average electricity consumption component obtained by normalizing the daily average electricity consumption within a preset statistical window, the peak electricity consumption ratio component calculated by the ratio of peak electricity consumption to total electricity consumption, the load continuity component calculated by combining the number of consecutive electricity consumption days, the number of zero electricity consumption days and the load fluctuation rate, the nighttime electricity consumption component calculated by the ratio of nighttime electricity consumption to total electricity consumption, and the electricity consumption growth rate component obtained by normalizing the growth rate of the current cycle electricity consumption relative to the previous cycle electricity consumption. The logical intent vector and the physical load vector are configured to have the same dimension.

4. The low-voltage intelligent management and control system of the whole process of collecting fares from passengers according to claim 1, characterized in that, The conflict level token pool delineation module normalizes the logical intent vector and the physical payload vector respectively to obtain normalized logical intent vector and normalized physical payload vector, and uses the cosine distance between the normalized logical intent vector and the normalized physical payload vector as the data conflict level coefficient; when the data conflict level coefficient is not higher than the preset conflict level threshold, the soft token candidate pool is activated. When the data conflict coefficient is higher than the preset conflict threshold, the soft token channel is closed and the hard token candidate pool is activated. The soft token candidate pool and the hard token candidate pool are not activated at the same time in the same decision round; the tokens in the hard token candidate pool are pre-sorted by reach strength from low to high to form a strength ladder.

5. The low-pressure fee-charging full-process intelligent management and control system according to claim 4, characterized in that, The rigid constraint trimming performed by the conflict-degree token pool delineation module on the activated token candidate pool includes at least compliance boundary constraints, resource capacity constraints, action interval constraints, and evidence precondition constraints. The compliance boundary constraint is used to remove candidate tokens that do not meet the compliance conditions at the current decision time from the candidate pool based on the daily reach limit corresponding to the user's category tag and the preset silent period interval. Resource capacity constraints are used to remove candidate tokens from the candidate pool that currently lack sufficient execution resources, based on the number of available outbound call seats, the grid worker's shift status, and the online status of smart terminal communication. Action interval constraints are used to remove candidate tokens that do not meet the cooling-off requirements from the candidate pool based on the comparison between the last execution time of the same type of token by the same user and the shortest recurrence period of that type of token. The pre-evidence constraint is used to remove candidate tokens from the candidate pool that do not meet the pre-evidence conditions based on the matching results between the pre-notification requirements required for the candidate token and the existing payment reminder delivery evidence in the system.

6. The low-voltage intelligent management and control system of the whole process of collecting fares from passengers according to claim 1, characterized in that, The token performance time-domain extrapolation module selects target tokens from the set of executable actions in order of execution cost from low to high. When the target token belongs to the soft token candidate pool, the initial performance base of the target token is reduced by using the data conflict coefficient, so that the initial penetration performance after modulation is lower than the initial performance base of the target token. The basic attenuation constant of the target token is enhanced by using the data conflict coefficient, so that the attenuation constant after modulation is higher than the basic attenuation constant of the target token. When the target token belongs to the hard token candidate pool, the initial performance base of the target token is enhanced by using the data conflict degree coefficient, so that the initial penetration performance after modulation is higher than the initial performance base of the target token. The basic attenuation constant of the target token is also enhanced by using the data conflict degree coefficient, so that the attenuation constant after modulation is higher than the basic attenuation constant of the target token. Based on the initial penetration efficiency after modulation and the attenuation constant after modulation, an attenuation function is constructed to show how the token penetration efficiency of the target token decreases over time. The critical time difference is obtained by inverse solving with the preset minimum collection pressure red line as the boundary condition. The sum of the target token issuance time and the critical time difference is used as the absolute timestamp for the next round of token triggering.

7. The low-voltage intelligent management and control system of the whole process of collecting fares from passengers according to claim 6, characterized in that, The token performance time-domain extrapolation module generates transition direction labels based on the comparison results between the critical time difference and the preset short-term threshold. The preset short-term thresholds include the short-term threshold for soft tokens corresponding to the soft token candidate pool and the short-term threshold for hard tokens corresponding to the hard token candidate pool. The short-term threshold for hard tokens is greater than the short-term threshold for soft tokens. When the target token belongs to the soft token candidate pool and the critical time difference is lower than the soft token short-lived threshold, the jump direction label is set to cross-pool jump, and the next round of tokens is selected from the hard token candidate pool. When the target token belongs to the hard token candidate pool and the critical time difference is lower than the short-term threshold of the hard token, the transition direction label is set to upgrade within the pool, and the next round of tokens is selected one level up in the hard token candidate pool according to the strength ladder; when the critical time difference is not lower than the corresponding short-term threshold, the transition direction label is set to reissue at the same level, and the next round of tokens maintains the current strength or selects a substitute token of the same level in the same pool.

8. The low-voltage intelligent management and control system of the whole process of collecting fares from passengers according to claim 1, characterized in that, The execution feedback self-correction module establishes an expiration status verification task based on the absolute timestamp of the next round of token triggering. The expiration status verification task is used to obtain business status data related to the execution result of the target token from the accounting system and the execution channel corresponding to the target token when a cancellation receipt is generated for a user's overdue account or when the expiration time is reached. The business status data includes the target token issuance time, expiration time, cancellation status, actual cancellation time, token execution receipt, and event type label. Event type tags include early cancellation events where the user cancels the outstanding amount before the due date, and overdue non-cancellation events where the user fails to cancel the amount by the due date. The execution feedback self-correction module encapsulates business status data into response event records.

9. The low-voltage intelligent management and control system according to claim 8, characterized in that, The execution feedback self-correction module calculates the normalized time deviation based on the response event records. It then multiplicatively updates the user-specific weight factor of the target token according to the positive or negative direction of the normalized time deviation. The adjustment range of each multiplicative update is determined by the product of the normalized time deviation and the preset self-correction learning rate. The updated user-specific weight factor is restricted to a preset weight constraint range. The product of the user-specific weight factor and the basic decay constant is used as the user-specific basic decay constant, which replaces the basic decay constant in the next round of token performance time-domain extrapolation.

10. A method for intelligent control of the entire low-pressure payment collection process, used to implement the intelligent control system for the entire low-pressure payment collection process as described in any one of claims 1-9, characterized in that, Includes the following steps: Multi-source state data is collected at the time of payment reminder decision-making. After preprocessing and normalization, logical intent vector representing the user's proactive expression characteristics and physical load vector representing the user's actual electricity consumption behavior characteristics are obtained. The data conflict coefficient is calculated based on the logical intent vector and the physical load vector to quantify the deviation between the user's active expression and the actual electricity consumption behavior. The soft token candidate pool or hard token candidate pool is activated based on the comparison result of the data conflict coefficient and the preset conflict threshold. Rigid constraint pruning is performed on the activated token candidate pool to obtain the set of executable actions. Select a target token from the set of executable actions. Based on the type of the token candidate pool to which the target token belongs, use the data conflict coefficient to differentially modulate the initial performance base and basic attenuation constant of the target token to obtain the modulated initial penetration performance and modulated attenuation constant. Based on the modulated initial penetration performance, the modulated attenuation constant and the preset minimum charging pressure red line, the critical time difference required for the token penetration performance to decay to the minimum charging pressure red line is obtained by inverse solution, and the absolute timestamp and jump direction label of the next round of token triggering are generated accordingly. After the target token is sent to the corresponding execution channel, when the user's overdue account generates a cancellation receipt or when the absolute timestamp of the next round of token triggering is reached, business status data related to the execution result of the target token is obtained from the accounting system and the execution channel corresponding to the target token. Based on the business status data, the time deviation between the actual cancellation time and the absolute timestamp of the next round of token triggering is determined, and the basic attenuation constant is modified for user specificity according to the time deviation.

Images