An intelligent collection processing method and system based on an AI rule generation engine and an event-driven nodal workflow

Abstract

The application relates to the technical field of intelligent collection, and particularly discloses an intelligent collection processing method and system based on an AI rule generation engine and an event-driven nodal workflow, which comprises the following steps: generating classification rules, collection business rules and transfer rules based on AI and verifying; acquiring high, medium and low priority collection events and constructing context information; selecting a to-be-processed collection event from the priority collection events based on a weighted round robin method, calling a current collection processing node to execute the to-be-processed collection event based on the collection business rules; after all program executions on the current collection processing node are completed, if any transfer rule is hit, a task message of a next collection processing node is sent to a corresponding priority topic; if all the transfer rules are not hit, a case closing / out-of-collection terminal state is entered. The method shortens the configuration period from 3 man-days to 1 hour based on AI natural language generation rules; and verification ensures that the rule accuracy rate reaches more than 95%.

Description

Technical Field

[0001] This invention relates to the field of intelligent debt collection technology, specifically to an intelligent debt collection processing method and system based on an AI rule generation engine and an event-driven node-based workflow. Background Technology

[0002] Currently, there are methods for generating collection strategies based on rule engines, but these methods use a daily batch processing scheduling mode, which cannot meet the requirements for millisecond-level real-time response. Rule engines only support static condition matching and lack AI-assisted rule generation and automatic verification mechanisms. Furthermore, current methods that convert natural language into structured rules using large models and perform semantic conflict and rule overlap detection between new and deployed rules also suffer from limitations. The generated rules are in a custom JSON format, lacking compatibility with standard rule languages ​​(such as DRL). Rule verification is limited to semantic conflict and overlap detection, lacking a multi-stage test case verification mechanism. Visual rule editing and user-interactive fine-tuning are not supported. Rule data sources are limited to sensor device data, making it impossible to correlate with multiple business data sources for comprehensive judgment.

[0003] Therefore, the existing collection management system generally has the following technical problems: (1) It adopts a batch processing scheduling mode and lacks the ability to process cases in real time based on event-driven methods; (2) The rule configuration depends on the technical personnel to write DRL rule scripts, which has a long configuration cycle and is prone to errors, and lacks AI-assisted generation and automatic verification methods; (3) The workflow orchestration is fixed in the code and lacks a node-based, configurable, and flexible workflow engine; (4) The rule configuration and execution are separated and lack an end-to-end automated closed loop from configuration to execution; (5) The existing rule verification scheme only stays at the semantic level of text analysis (such as detecting whether natural language descriptions are conflicting) and lacks verification methods based on actual execution results, making it difficult to guarantee the quality of rules. Summary of the Invention

[0004] To address the aforementioned technical issues, the first objective of this invention is to provide an intelligent debt collection processing method based on an AI rule generation engine and an event-driven nodeized workflow. This method uses AI natural language to generate rules, reducing the configuration cycle from 3 person-days to 1 hour, which can be completed independently by business personnel. Multi-stage AI verification ensures that the rule accuracy rate reaches over 95%, effectively avoiding case processing anomalies caused by erroneous rules. Furthermore, through Kafka event-driven + weighted round-robin scheduling, the response time for high-urgent cases is reduced from 24 hours for batch processing to minutes.

[0005] The second objective of this invention is to provide an intelligent debt collection system based on an AI rule generation engine and an event-driven node-based workflow.

[0006] The first technical solution adopted in this invention is: an intelligent debt collection processing method based on an AI rule generation engine and an event-driven node-based workflow, comprising the following steps: S100: Generate and verify classification rules, collection business rules, and transfer rules based on AI; and synchronize the verified collection business rules and transfer rules to the rule engine. S200: Based on the classification rules after verification, the task messages are pre-divided into high, medium and low priority topics, and high, medium and low priority collection events are obtained from them; and context information is constructed for each collection event; S300: Select a collection event to be processed from the high, medium and low priority collection events based on the weighted round-robin method, and determine the current collection processing node based on the context information of the collection event to be processed; and call the current collection processing node to execute the collection event to be processed based on the collection business rules; S400: After all programs on the current collection processing node have been executed, determine whether the collection event to be processed matches any of the flow rules associated with the current collection processing node; if it matches any flow rule, output the code of the next collection processing node according to the flow rule, and send the task message of the next collection processing node to the corresponding priority topic. Repeat steps S300-S400; if all flow rules are not matched, enter the case closure / termination state.

[0007] Preferably, step S100 includes: receiving a natural language rule description, and converting the natural language rule description into a classification rule, a collection business rule in DRL format, or a flow rule in DRL format through a large language model.

[0008] Preferably, step S100 includes: verifying the classification rules, the collection business rules in DRL format, and the transfer rules. The verification includes a thinking and analysis stage, a knowledge supplementation stage, a rule analysis stage, a logic verification stage, a test case comparison stage, and a summary report stage.

[0009] Preferably, the verification includes: Analysis and interpretation phase: AI performs a semantic-level structured interpretation of the classification rules, DRL-formatted collection business rules, and transfer rules, and outputs the analysis results; Knowledge Supplementation Phase: Based on the analysis results, the AI ​​automatically supplements the relevant domain knowledge and compliance constraints for the rule, and outputs a list of compliance constraints; Rule analysis phase: Based on the analysis results and the compliance constraint list, the AI ​​breaks down the rules into one or more condition-action pairs and outputs a set of several condition-action pairs; Logical verification phase: The AI ​​performs a logical review of the rules and outputs a list of questions; Test case comparison phase: AI automatically generates a test case set based on the set of several condition-action pairs, and drives the underlying rule engine to execute them one by one to obtain test results; Summary Report Stage: AI summarizes the conclusions of the previous stages and generates an archiveable verification report.

[0010] Preferably, the context information in step S200 includes: case number, case processing number, task number, overdue days, amount owed, customer level, customer level identifier, current node code, previous node code, executed node chain, collection history summary, agency number, and intermediate results of program execution.

[0011] Preferably, step S300 includes: selecting events sequentially from the high, medium, and low priority collection event queues according to a preset weight ratio of high, medium, and low priorities for processing.

[0012] Preferably, step S300 includes: determining the current collection processing node based on the process node identified by the current node code in the context information.

[0013] Preferably, step S300 includes: Read all valid programs under the current collection processing node and arrange them in ascending order of program execution; the process engine obtains the corresponding programs in sequence according to the program codes based on the collection business rules and executes them; after the current collection processing node has executed all programs, proceed to step S400.

[0014] Preferably, step S400 includes: After all programs on the current collection processing node have been executed, the rule engine parses the flow rules associated with the current collection processing node to determine whether the collection event to be processed matches any flow rule. If any flow rule is matched, the code of the next collection processing node is output according to the flow rule, and the task message of the next collection processing node is sent to the corresponding high, medium or low priority topic according to the case attribute. After the consumer retrieves the task message, steps S300 to S400 are re-executed. If none of the flow rules are matched, the case enters the case closure / collection termination state.

[0015] The second technical solution adopted in this invention is: an intelligent collection processing system based on an AI rule generation engine and an event-driven nodeized workflow, including an AI rule generation and verification layer, an event access layer, and a collection engine core layer; The AI ​​rule generation and verification layer is used to generate and verify classification rules, collection business rules and transfer rules based on AI; and to synchronize the verified collection business rules and transfer rules to the rule engine. The event access layer is used to pre-classify task messages into high, medium, and low priority topics based on classification rules after verification, and to obtain high, medium, and low priority collection events from them; and to construct context information for each collection event. The core layer of the collection engine is used to select collection events to be processed from the high, medium and low priority collection events based on a weighted round-robin method, and to determine the current collection processing node based on the context information of the collection event to be processed; and to call the current collection processing node to execute the collection event to be processed based on the collection business rules. The system also includes a judgment module, which, after all programs on the current collection processing node have been executed, determines whether the collection event to be processed matches any of the flow rules associated with the current collection processing node. If any flow rule is matched, the system outputs the code of the next collection processing node according to the flow rule, sends the task message of the next collection processing node to the corresponding priority topic, and calls the collection engine core layer again to select and execute the collection event to be processed, iterating the above operations. If none of the flow rules are matched, the system enters the case closure / collection termination state.

[0016] The beneficial effects of the above technical solution are as follows: (1) This invention provides an intelligent collection processing method based on an AI rule generation engine and an event-driven nodeized workflow. The method generates rules based on AI natural language, which shortens the configuration cycle from an average of 3 person-days in the traditional way to within 1 hour, and business personnel can complete it independently. Multi-stage AI verification ensures that the rule accuracy rate reaches more than 95%, effectively avoiding case processing anomalies caused by erroneous rules. Moreover, business personnel do not need to master DRL syntax to complete the rule configuration independently. Furthermore, through Kafka event-driven + weighted polling scheduling, the response time for high-urgent cases is reduced from 24 hours for batch processing to minutes. The nodeized workflow supports flexible orchestration, and no code development is required to add collection nodes. It forms an end-to-end automated closed loop from AI rule generation and verification to engine execution.

[0017] (2) This invention uses Kafka event-driven + weighted round-robin scheduling to reduce the time from the time of urging to the first processing of high-priority cases from an average of 24 hours in batch processing mode to an average of 3.5 minutes; the system can support the real-time processing of 100,000 cases per day under a single-node configuration.

[0018] (3) Compared with existing technologies that only perform semantic conflict detection on rule text based on large models (such as detecting the intent conflict between 'no one turns on the lights in the meeting room' and 'no one turns off the lights in the meeting room'), which lack end-to-end verification methods based on actual execution, the AI ​​of this invention can automatically generate multiple sets of test data (covering boundary hit cases, typical hit cases, and typical miss cases) according to rule conditions and drive the rule engine to simulate execution one by one. By comparing the input / expected output / actual output, entity verification is performed, achieving end-to-end verification based on actual execution results, which is more reliable. At the same time, the verification results can be exported to Excel for audit retention, meeting financial compliance requirements.

[0019] (4) This invention organically integrates the AI ​​rule generation engine (natural language interaction → DRL generation → multi-stage verification) with the event-driven node-based workflow engine (Kafka + weighted polling → node multi-program orchestration → rule engine dynamic flow) to form a complete closed loop; the entire process is event-driven as the main line, and the case context is asynchronously transmitted between processing nodes through Kafka messages.

[0020] (5) The method disclosed in this invention can be applied to credit overdue collection management scenarios. By organically combining AI natural language interaction to generate collection rules, visual rule engine orchestration and event-driven real-time scheduling processing, the collection strategy can be quickly configured, automatically verified and intelligently executed. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating an intelligent debt collection method based on an AI rule generation engine and an event-driven nodeized workflow, as provided in one embodiment of the present invention. Figure 2 This is a schematic diagram illustrating the AI ​​rule generation and multi-stage verification process provided in one embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an intelligent debt collection system based on an AI rule generation engine and an event-driven node-based workflow, provided as an embodiment of the present invention. Detailed Implementation

[0022] The embodiments of the present invention will be further described in detail below with reference to the accompanying drawings and examples. The following detailed description of the embodiments and the accompanying drawings are used to illustrate the principles of the present invention by way of example, but should not be used to limit the scope of the present invention. That is, the present invention is not limited to the described preferred embodiments, and the scope of the present invention is defined by the claims.

[0023] In the description of this invention, it should be noted that, unless otherwise stated, "a plurality of" means two or more; the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance; those skilled in the art can understand the specific meaning of the above terms in this invention as appropriate.

[0024] Example 1 like Figure 1 As shown, one embodiment of the present invention provides an intelligent debt collection processing method based on an AI rule generation engine and an event-driven node-based workflow, including the following steps: S100: Generate and verify classification rules, collection business rules, and transfer rules based on AI; and synchronize the verified collection business rules and transfer rules to the rule engine. like Figure 2 As shown, the AI-generated classification rules, debt collection rules, and workflow rules include: The system receives natural language rule descriptions from business personnel and converts these descriptions into classification rules, collection business rules in DRL format, and flow rules in DRL format using a large language model. The large language model is, for example, the Hermes large language model.

[0025] For example, the specific process is as follows: (1) Rule generation: Business personnel input natural language descriptions on the rule management page, and the front end calls the rule generation streaming ( / base / ai / chatStream SSE) interface; the back end rule dialogue service module assembles the organization number, real-time data table metadata and offline data table metadata, and forwards them to the large language model in a streaming manner; the front end presents the thinking process and classification rules, collection business rules in DRL format and the main text of the transfer rules in a streaming display manner.

[0026] (2) Rule visualization: After the collection business rules and flow rules in DRL format are generated, the rule expression conversion interface ( / base / ruleSet / drlToFrontExpression) is called to map the collection business rules and flow rules in DRL format to a front-end editable rule configuration structure (including rule condition set, rule result, priority, etc.), which is presented as a tree-like condition diagram in the G6 visualization editor, supporting logical AND / OR combination and various comparison operations such as equal to, greater than, less than, contain, and interval.

[0027] DRL stands for Drools Rule Language; streaming is suitable for scenarios where large language models are output segment by segment.

[0028] AI (Artificial Intelligence) generated classification rules, DRL-formatted collection business rules, and transfer rules must undergo multi-stage testing and verification before they can take effect. Verification is triggered by the rule testing interface and returned in segments according to stage identifiers via the rule testing streaming interface. Each stage is executed serially, and the process is terminated if any blocking problem is found in any stage.

[0029] The classification rules, collection business rules in DRL format, and flow rules are validated, including the following stages: analysis, knowledge supplementation, rule analysis, logic verification, test case comparison, and summary report. ① The analysis phase; AI performs a semantic-level structured interpretation of the classification rules, DRL-formatted collection business rules, and transfer rules, and outputs analysis results. The analysis results include the goal of the rule, the scope of applicable cases, key condition factors, triggering actions, and potential impact assessment.

[0030] The specific output analysis results include: (a) The goal of this rule: the business problems this rule aims to solve (such as "identifying mild debt collection targets" and "screening high-risk cases requiring human intervention"). (b) Scope of application of this rule: types of clients / cases covered by the rule and exclusion conditions; (c) Key condition factors of the rule: a list of fields extracted from the rule condition clause (such as overdue days, amount owed, and number of historical overdue payments). (d) The triggering action of the rule: the output defined in the rule result clause (such as setting the collection method, writing a tag, or returning the current node code); (e) Assessment of the potential impact of the rule: expected hit rate and impact on dispatch / text / outbound call volume.

[0031] The analysis results in this Analyze phase serve two purposes: first, they provide contextual hints to supplement the knowledge and rule analysis phases, reducing misinterpretations of the rule intent in subsequent phases; second, they are displayed in real-time on the front end as analysis process segments, allowing business personnel to confirm whether the AI's understanding is consistent with the natural language description.

[0032] ② Knowledge Supplementation Stage; Based on the analysis results output during the thinking and analysis phase, AI automatically supplements the rule with relevant domain knowledge and compliance constraints, and outputs a list of compliance constraints; the domain knowledge and compliance constraints include, but are not limited to, collection industry standards, key points of laws and regulations, internal control rules of institutions, and explanations of business terms.

[0033] Specifically, domain knowledge and compliance constraints include: (a) Industry standards for debt collection: such as the requirements for contact frequency, contact methods, and communication time periods in the "Self-Discipline Convention on Overdue Debt Collection in Internet Finance"; (b) Key legal and regulatory points: Personal Information Protection Law, restrictions related to consumer rights protection; (c) Internal control rules of the organization: such as "collection shall not be carried out more than twice a week", "outbound calls are prohibited from 22:00 to 8:00", "debt details shall not be disclosed to third parties", etc.; (d) Explanation of business terminology: Provide operational definitions for vague expressions such as "good historical repayment record" and "gentle collection" that appear in the rules.

[0034] The knowledge supplementation phase does not directly modify the classification rules, DRL-formatted collection business rules, and flow rules. Instead, it writes them into the checklist (i.e., compliance constraint list) of the logic verification phase. The logic verification phase will check each rule action to see if it violates the above constraints. For example, if the rule result clause implicitly contains "3 outbound calls per day", the logic verification phase will mark it as a compliance conflict and provide modification suggestions.

[0035] ③ Rule Analysis Phase; The AI ​​takes the structured analysis results output from the thinking and analysis phase as input and refers to the compliance constraint list output from the supplementary knowledge phase to break down the rules into one or more "condition-action pairs" and output a set of several condition-action pairs; each condition-action pair includes a condition expression, logical relationship, action list and rule priority.

[0036] Each condition-action pair specifically includes: (a) Conditional expression: The structured list of fields, operators, and thresholds (e.g., overdue days > 60 and the amount owed is between 10,000 and 50,000). (b) Logical relationships: AND, OR, NOT and parenthesis hierarchy between conditions; (c) Action list: Key-value pairs written to the result object after a rule is hit (e.g., collection method = SMS plus outbound call, frequency limit = twice a week); (d) Rule priority: the order in which multiple rules are triggered.

[0037] The above set of condition-action pairs is used to: (1) determine which input fields and their legal value ranges need to be constructed when automatically generating test cases during the test case comparison phase; (2) map natural language conditions to specific column names in the rule factor table (such as the collection case information table) to ensure that the test input is consistent with the production environment fields; (3) generate at least one positive hit test case and one negative miss test case for each condition-action pair.

[0038] ④ Logical verification (Verify) phase; Without accessing production case data, AI performs static and semi-dynamic logical reviews of rules and outputs a problem list. Each problem in the problem list includes severity level, problem location, problem description, and modification suggestions. When an error-level problem exists, the test case comparison phase is blocked. The logical review items include mutually exclusive / contradictory conditions, conflicting actions, boundary integrity, null / default values, type matching, and compliance verification.

[0039] The logical review items specifically include: (a) Mutually exclusive / contradictory conditions: For example, the same field requires both overdue days > 90 and overdue days < 30; (b) Action conflict: The rule result sets mutually exclusive actions at the same time (such as both "suspend collection" and "make outbound calls immediately"); (c) Boundary integrity: Check whether the endpoints of the open and closed intervals of numerical conditions are covered. For example, does "overdue for more than 60 days" include the principal value of 60 days? Does "owe money of 10,000 to 50,000 yuan" behave as expected at the boundaries of 9,999.99, 10,000, 50,000, 50,000.01? (d) Null / Default: Whether the rule safely degrades when the key field is empty or missing (default is no hit or default branch is used); (e) Type matching: Whether the amount field is compared with the amount type, and whether the date field is compared with the date type; (f) Compliance verification: Check whether the collection frequency, time period and method are in violation of the items in the supplementary knowledge stage.

[0040] ⑤ Test case comparison (TestCompare) phase; AI automatically generates a test case set based on the set of several condition-action pairs, and drives the underlying rule engine to execute each pair to obtain test results; the test case set includes a unique test case number, scenario label, input data, expected output, actual output, and whether it passes or fails.

[0041] For example, each record in the test case set includes: (a) Unique use case number: such as TC001-TC010; (b) Scene tags, including: boundary hit, boundary miss, typical hit, typical miss, null value, etc.; (c) Input data: A snapshot of simulated cases organized by "Rule Factor Table·Field=Value", such as "Collection Case Information Table·Overdue Days=60, Amount Defaulted=15000, Historical Overdue Counts=1, Customer Level=M"; The table names / field names in the input data are consistent with the production rule factors, real-time data stream table, and offline data table; (d) Expected output: The engine return expected when a rule is hit, including a list of triggered rule names, output result set (such as the current node code, collection method), and whether the execution was successful; (e) Actual output: The actual return obtained after the system injects the input data into the rule session of the rule execution engine for execution; (f) Pass: The result of a structured comparison between the actual output and the expected output on the agreed fields.

[0042] The front-end comparison result display module shows the total number of test cases, whether all passed, and the number of failed test cases in summary form; the details can be generated into a spreadsheet through the export function (including a summary page and a details page, with columns including test case number, scenario, input data, expected output, actual output, and whether passed).

[0043] A typical configuration consists of 10 test cases: 5 boundary hits and 5 boundary misses, covering the endpoint values ​​of each condition factor.

[0044] ⑥ Summary stage; AI summarizes the conclusions of the preceding stages and generates an archiveable verification report. The verification report includes basic rule information, conclusions of each stage, test statistics, details of failed test cases, risk warnings, and effective suggestions.

[0045] The verification report includes the following specific contents: (a) Basic rule information: rule set code, version number, rule summary, generation time, operator; (b) Conclusions of each stage: Whether the thinking and analysis stage, knowledge supplementation stage, rule analysis stage, and logic verification stage were passed, and a summary description; (c) Test statistics: total number of test cases, number of passes, number of failures; (d) Details of failed test cases: The unique ID, inconsistency fields, and differences between expected and actual output for each test case in the failure list; (e) Risk warning: warning-level issues remaining from the logic verification phase, insufficient boundary coverage, and suggestions for compliance margins; (f) Activation recommendation: Allow activation if all test cases pass; otherwise, prohibit activation and list the items that must be fixed.

[0046] The verification report text can be archived along with the rule version for future regulatory inspections or internal audits.

[0047] Synchronization to the rules engine includes: After all six phases of validation pass (zero failed test cases) and the user confirms the rule's effectiveness on the front end, the system persists the DRL-formatted collection business rules and workflow rules to a relational database (e.g., MySQL) and synchronizes them to the anytxn-rule rule engine cache. This ensures that the node program can load the latest DRL-formatted collection business rules or workflow rules upon its next execution. Collection business rules or workflow rules that fail validation must not be written to the production rule cache. Passing the test is a necessary threshold condition for the rule to take effect and cannot be skipped.

[0048] Furthermore, in one embodiment, step S200 also includes bidirectional conversion between DRL and JSON; Business users can fine-tune the condition tree in a visual rule editor (such as G6) and then reverse-generate DRL format rules for submission and verification, thus achieving a closed loop of "natural language generation → visual fine-tuning → execution-level verification".

[0049] The process of generating and validating collection business rules in DRL format based on AI is as follows: The administrator entered: "If the overdue period exceeds 60 days, the customer has a good repayment history (no more than 2 overdue payments in the past 12 months), and the amount owed is between 10,000 and 50,000 yuan, a gentle collection method of SMS reminders + manual outbound calls will be used, with a collection frequency of no more than 2 times per week."

[0050] Example of the thought process for SSE streaming response: "Analysis conditions: overdue days greater than 60; number of historical overdue payments not greater than 2; amount owed between 10,000 and 50,000; actions: collection methods are SMS collection and outbound calls..."

[0051] After the rules are converted into a visual condition tree, the rule test streaming interface is submitted to complete the six-stage verification in sequence. During the test case comparison stage, 10 test cases are generated, including TC001 (overdue days = 59, expected non-hit) and TC002 (overdue days = 60, expected boundary hit). After the rule execution engine executes each test case, all 10 test cases pass. The summary report concludes that the rules are effective. After administrator confirmation, the rules are put into the production environment.

[0052] The core of this invention's verification method lies in its approach: instead of performing pure text semantic detection on classification rules, debt collection rules, and transfer rules, artificial intelligence automatically generates batch test data (covering boundary values, typical hit and miss scenarios) based on rule conditions. This data drives the underlying rule execution engine to simulate execution line by line, structurally comparing the actual output with the expected output, and archiving it as an exportable verification report. This method can uncover hidden defects such as "grammatically correct but with incorrect boundary behavior," upgrading verification from text analysis to actual execution verification, and providing a complete chain of evidence for financial compliance audits.

[0053] The present invention generates DRL standard format collection rules and circulation rules, thereby ensuring cross-system compatibility and long-term maintainability of collection rules (DRL JSON two-way conversion balances standardization and visualization); the six-stage AI test verification comprehensively guarantees rule quality from business rationality, logical consistency, and execution correctness, with an accuracy rate of over 95%, and the verification report can be exported to Excel for compliance audit; the parallel reference of three types of data sources (rule factors, real-time data stream fields, and offline data fields) enables rule judgment to make decisions by integrating multi-dimensional business data, with essential improvements in accuracy and coverage.

[0054] S200: Pre-divide task messages into high, medium and low priority topics based on the verified classification rules, and obtain high, medium and low priority collection events therefrom; and construct context information for each collection event; External systems (such as bank core, batch processing jobs) or the internal node circulation module of the present system encapsulate overdue cases into standardized messages and write them into the message queue; when or before an event enters the message queue, the priority topic to which the event should be written is determined according to the verified classification rules, including: Preset high (event-high), medium (event-medium) and low priority (event-low) topics in the Nacos configuration center based on the verified classification rules; receive collection events through Kafka, RocketMQ or Pulsar message queues; the classification rules are for example: let the number of overdue days be d and the amount of arrears be a, then when d>90 and a>50000 yuan, the event is written to the high priority topic (event-high); when 30<d≤90 or 10000<a≤50000 yuan, the event is written to the medium priority topic (event-medium); events in other cases are written to the low priority topic (event-low); among them, Nacos is a dynamic service discovery and configuration management platform; Kafka / RocketMQ / Pulsar are distributed message middleware, which implement classified consumption and horizontal scaling through message topics and consumer groups.

[0055] After consumers retrieve data in batches (e.g., 200 items per batch), they immediately mark the collection events as high / medium / low priority based on the topic to which the task message belongs, thus obtaining high-priority, medium-priority, and low-priority collection events. Before entering the scheduler, the event's context information (EventContext) is constructed. In the backend implementation, this context information is jointly carried by the message transmission object and the node execution context: the message transmission object includes case information, task information, message topic, and message identifier; the node execution context includes case number, current node code, and intermediate program execution results. This context information serves as the unified input carrier for subsequent weighted scheduling, node program chain execution, and rule engine judgment.

[0056] Consumers adopt a manual commit offset commit strategy: the consumption position is committed only after a batch of messages has been successfully processed and persisted, avoiding message loss or business inconsistency caused by abnormal process exit, thus ensuring that messages are not lost in the event of abnormal downtime.

[0057] The event context information (EventContext) includes, but is not limited to, case number (caseId), case handling number (caseHandleId), task number (taskId), overdue days, amount owed, customer level, customer level identifier, current node code (nodeCode), previous node code, executed node chain, collection history summary, organization number (orgNo), and intermediate program execution results (programResult).

[0058] S300: Select a collection event to be processed from the high, medium and low priority collection events based on the weighted round-robin method, and determine the current collection processing node based on the context information of the collection event to be processed; and call the current collection processing node to execute the collection event to be processed based on the collection business rules; The weighted round-robin method selects collection events to be processed from high, medium, and low priority collection events, including: Events are selected sequentially from the high, medium, and low priority non-empty priority collection event queues for processing according to a preset weight ratio of high, medium, and low priorities. For example, the preset weight ratio of high, medium, and low priorities is: high priority collection event : medium priority collection event : low priority collection event = 6 : 3 : 1.

[0059] The rules for selecting events are as follows: In the formula, The selected priority index (high, medium, low); Priority iThe cumulative number of times an event has been scheduled and executed since the scheduler started; each time an event is retrieved from and executed from this queue, Add 1; Priority i The preset weight coefficients correspond one-to-one with high, medium, and low priorities. In this embodiment, we take... =6、 =3、 =1; Priority i The queue of events to be processed; Indicates priority i The percentage of service performed relative to its weight; the smaller this ratio, the less service is provided relative to the weight, and the higher the degree of under-scheduling. Select the non-empty queue with the highest relative weight underscheduling degree to make the long-term scheduling ratio approach 6:3:1 and avoid low-priority queues from being underscheduled for a long time.

[0060] If and only if Only queues with this priority level can participate in the selection process if they are not empty. If multiple non-empty queues... If they are equal, the first non-empty queue is selected in the order of high, medium, and low to ensure that the behavior during the startup phase is determined.

[0061] For example, initially = = =0, each queue If all values ​​are 0, the first non-empty queue is selected in high, medium, and low priority order. Typically, the highest priority queue is selected first. After execution... Add 1; when =6、 =3、 When =1, = = =1.0, the degree of underscheduling of each queue is the same, and the scheduling ratio reaches a balance of 6:3:1.

[0062] Based on the context information of the pending collection event, the current collection processing nodes are determined to include: Based on the process node identified by the current node code in the context information, the current collection processing node is determined. The current collection processing node is not a fixed collection entry node. It is the collection entry node when the collection is first initiated, and can be any node such as manual collection or smart SMS after the process is transferred.

[0063] The current collection processing node is invoked to execute the pending collection event based on the verified collection business rules, including: The process engine reads all valid programs under the current collection processing node from the node program mapping configuration and arranges them in ascending order of program execution. Based on the collection business rules, the process engine retrieves the corresponding programs (such as data loading programs, rule calling programs, etc.) from the program registration container according to the program code and executes them. The collection processing node must execute all programs (or terminate abnormally) before entering the S400 flow judgment. If a single program fails, the task details status can be written as abnormal and subsequent flow can be blocked.

[0064] The programs include, but are not limited to: data loading program, rule calling program associated with collection business rule set, node flow program, auto dispatch program, SMS sending program, query credit report program, outcall list generation program, etc.

[0065] The invocation of collection business rules is as follows: Configure a rule calling program (ruleCallingProgram) at a certain collection node and associate it with a collection business rule set (RuleSet). The rule conditions are "overdue days > 60 and historical overdue times ≤ 2 and the amount owed is between 10,000 and 50,000 yuan". If the rule is hit, the business results such as collection method (e.g., SMS collection and outbound call) will be output for subsequent programs at the same node (e.g., SMS sending, outbound call list generation). The collection business rules are executed by the anytxn-rule rule engine, which supports execution types such as JUDGE, OPERATOR, and RESULT. They are used to make intra-node judgments, calculations, or result matching on case attributes. Typical outputs include collection methods, business tags, and calculated field values, rather than the next node code.

[0066] S400: After all programs on the current collection processing node have been executed, determine whether the collection event to be processed matches any of the flow rules associated with the current collection processing node; if any flow rule is matched, output the code of the next collection processing node according to the flow rule, and send the task message of the next collection processing node to the corresponding priority topic; repeat steps S300-S400; if none of the flow rules are matched, enter the case closure / collection termination state.

[0067] After all programs on the current collection processing node have been executed, the rule engine parses the flow rules associated with the current collection processing node. The flow rules are in DRL format and are configured in the node flow strategy (including the front-end flow strategy list and front-end node parameter configuration). It is determined whether the collection event to be processed matches any flow rule. If any flow rule is matched, the code of the next collection processing node is output according to the flow rule, and the task message of the next collection processing node (including complete event context information) is sent to the corresponding high, medium or low priority topic according to the case attribute. After the consumer retrieves the task message, steps S300 to S400 are re-executed. If none of the flow rules are matched, the case enters the case closure / collection termination state.

[0068] The internal workflow of the strategy transfer service is as follows: the rule invocation program executes the transfer rule set to obtain the next node code; the node transfer program generates the next node task message and writes it to the message queue. The input for judgment is the case runtime fields in the event context information (number of overdue days, amount owed, customer level, most recent collection result, commitment to repayment flag, etc.).

[0069] After a successful hit, the consumer is again dispatched via S300, and all procedures are executed at the target node according to priority (e.g., manual collection node: outbound call list generation → waiting for manual collection → S400 judgment again).

[0070] If the case is not hit, it is marked as closed / issued for further action; cases in a closed state can also be retried via data feedback to trigger S200.

[0071] For example, the transfer rule is configured at the collection node: "If the number of overdue days > 90 and the amount owed > 50,000, then transfer to the manual collection node"; when the case is overdue for 95 days and the amount owed is 62,000 yuan, the rule is hit, the system sends the next node task message to the corresponding priority topic, and the consumer is scheduled again through step S300 to execute the corresponding program chain at the target node; after the manual collection is completed, step S400 can be executed again, and the case can be transferred to the repayment tracking node or the lost contact repair node according to conditions such as "promised repayment" and "lost contact".

[0072] The rule engine is based on the rule execution framework (anytxn-rule), which uses rule session compilation to compile collection business rules (DRL format) and Rete algorithm for pattern matching. It supports three types of rule execution: judgment, operation, and result.

[0073] AI rule generation engine: Composed of rule management interaction module, rule dialogue service, rule set management service and streaming transmission control module, responsible for the generation, multi-stage verification and release of collection business rules (DRL format).

[0074] The present invention takes the credit card overdue collection scenario as an example to further illustrate the specific process of the intelligent collection processing method based on the AI rule generation engine and event-driven node-based workflow of the present invention: Application scenario: Automated collection processing of credit card overdue cases of a financial institution. Cases are divided into three priorities according to the number of overdue days (d) and the amount of owed money (a): high priority (d>90 days and a>50000 yuan), medium priority (30<d≤90 days or 10000<a≤50000 yuan), low priority (d≤30 days and a≤10000 yuan).

[0075] System configuration: Three Kafka priority topics (event-high, event-medium, event-low) are preset in the Nacos configuration center, the batch pull count for a single consumer is set to 200 items per time, and the offset is manually committed; the scheduling weight is configured as high:medium:low=6:3:1.

[0076] Process example: (1) The bank pushes overdue cases in real time to the corresponding priority topics of Kafka every day; taking a credit card case with 95 overdue days and an owed amount of 62000 yuan as an example, this case enters the event-high topic.

[0077] (2) The weighted round-robin scheduler consumes the event-high topic at a weight of 6:3:1, retrieves the case and constructs an EventContext, which includes context information such as case ID, number of overdue days, owed amount, customer level, and collection history.

[0078] (3) The node processor executes the entry collection node. The node is configured with CaseHandelImpl (case processing module) to judge the case status: for cases of first-time overdue with a positive owed amount, a case number (format: CS{yyyyMMdd}_{6-digit random number}) is generated and written into the case status table; settled cases are updated to the exit collection status.

[0079] (4) After the execution of the entry collection node is completed, the policy flow service parses the flow rules on the entry collection node; examples of the rules: "overdue days>90 and owed amount>50000 → flow to manual collection node"; "overdue days≤90 and owed amount≤10000 → flow to intelligent SMS collection node"; this example hits the first rule, and sends the "manual collection node" event message via Kafka.

[0080] (5) The manual collection node is equipped with a telephone collection program and an outbound call list generation program. The manual collection node executes the outbound call list generation program and other programs. The collector makes telephone collection based on the outbound call list and records the collection content. After the collection is completed, it enters the transfer judgment again: if the customer promises to repay within 7 days, it will be transferred to the "repayment tracking node"; if the customer is out of contact, it will be transferred to the "out of contact repair node".

[0081] Example 2 like Figure 3 As shown, one embodiment of the present invention provides an intelligent debt collection processing system based on an AI rule generation engine and an event-driven nodeized workflow, including an AI rule generation and verification layer, an event access layer, and a debt collection engine core layer; The AI ​​rule generation and verification layer is used to generate and verify classification rules, collection business rules, and transfer rules based on AI; and to synchronize the verified collection business rules and transfer rules to the rule engine; the AI ​​rule generation and verification layer outputs rules through SSE streaming call to the large model; performs six-stage automated verification (thinking and analysis → knowledge supplementation → rule analysis → logic verification → test case comparison → summary report stage), and can only take effect and be synchronized to the rule engine after verification.

[0082] The event access layer is used to pre-classify task messages into high, medium, and low priority topics based on the classification rules after verification, and to obtain high, medium, and low priority collection events from them; and to build context information for each collection event; the event access layer pulls collection event messages in batches from the three preset priority topics (event-high, event-medium, event-low) through the Kafka event listener, and the Nacos configuration center uniformly manages the Kafka cluster parameters, supporting dynamic adjustment of the number of consumer threads and the number of batch pulls.

[0083] The core layer of the collection engine is used to select collection events to be processed from the high, medium and low priority collection events based on a weighted round-robin method, and to determine the current collection processing node based on the context information of the collection event to be processed; and to call the current collection processing node to execute the collection event to be processed based on the collection business rules. The system also includes a judgment module, which, after all programs on the current collection processing node have been executed, determines whether the collection event to be processed matches any of the flow rules associated with the current collection processing node. If any flow rule is matched, the system outputs the code of the next collection processing node according to the flow rule, sends the task message of the next collection processing node to the corresponding priority topic, and calls the collection engine core layer again to select and execute the collection event to be processed, iterating the above operations. If none of the flow rules are matched, the system enters the case closure / collection termination state.

[0084] The core layer of the collection engine consists of a weighted polling scheduler, a node-based workflow engine, a rule engine, and a judgment module (i.e., a strategy transfer service) connected in series. The scheduler selects events with context from high, medium, and low priority queues in a 6:3:1 ratio. The workflow engine supports multiple programs to be arranged in execution order. The rule engine provides judgment-based, computational, and result-based judgments. The strategy transfer service parses the node transfer strategy, and if a match is found, the next node task message is written to the corresponding priority message topic. When executing a program, the business function module layer (case dispatch, SMS, outbound calls, and credit investigation) is called through the interface gateway.

[0085] Furthermore, the intelligent debt collection processing system based on an AI rule generation engine and an event-driven node-based workflow also includes: a business function module layer and a data storage layer; The business function module layer includes case management, strategy management, process management, operation management, and data management. Case management, strategy management, process management, operation management, and data management are connected to the collection engine core layer through a unified menu permission system and API gateway.

[0086] The data storage layer consists of: MySQL for storing core business data; Redis and Caffeine for two-level caching to accelerate queries; Elasticsearch for full-text search of collection records; and Kafka, RocketMQ, or Pulsar as message brokers to achieve asynchronous decoupling. In addition to the local Caffeine cache, this invention can utilize a Redis distributed cache, supporting multiple instances sharing cached data. Combined with cache expiration and proactive refresh mechanisms, it enables efficient reading of node information and rule configurations. Caffeine is a high-performance Java local caching library that supports time- and capacity-based expiration policies and scheduled refresh mechanisms.

[0087] The layers are interconnected, and the AI ​​rule generation and verification layer feeds back the rules to the core layer of the collection engine, forming a complete closed loop.

[0088] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this invention 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 design 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 implementations should not be considered beyond the scope of this invention.

[0089] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0090] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0091] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0092] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion 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 this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

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

Claims

1. A smart debt collection processing method based on an AI rule generation engine and an event-driven node-based workflow, characterized in that, Includes the following steps: S100: Generate and verify classification rules, collection business rules, and transfer rules based on AI; And synchronize the verified collection business rules and flow rules to the rule engine; S200: Based on the classification rules after verification, the task messages are pre-divided into high, medium and low priority topics, and high, medium and low priority collection events are obtained from them; And to build context information for each collection event; S300: Select a collection event to be processed from the high, medium and low priority collection events based on the weighted round-robin method, and determine the current collection processing node based on the context information of the collection event to be processed; And invoke the current collection processing node to execute the pending collection event based on the collection business rules; S400: After all programs on the current collection processing node have been executed, determine whether the collection event to be processed matches any of the flow rules associated with the current collection processing node; if it matches any flow rule, output the code of the next collection processing node according to the flow rule, and send the task message of the next collection processing node to the corresponding priority topic. Repeat steps S300-S400; if all flow rules are not matched, enter the case closure / termination state.

2. The intelligent debt collection processing method according to claim 1, characterized in that, Step S100 includes: receiving a natural language rule description, and converting the natural language rule description into a classification rule, a collection business rule in DRL format, or a flow rule in DRL format through a large language model.

3. The intelligent debt collection processing method according to claim 1, characterized in that, Step S100 includes: verifying the classification rules, collection business rules in DRL format, and flow rules. The verification includes a thinking and analysis stage, a knowledge supplementation stage, a rule analysis stage, a logic verification stage, a test case comparison stage, and a summary report stage.

4. The intelligent debt collection processing method according to claim 3, characterized in that, The verification includes: Analysis and interpretation phase: AI performs a semantic-level structured interpretation of the classification rules, DRL-formatted collection business rules, and transfer rules, and outputs the analysis results; Knowledge Supplementation Phase: Based on the analysis results, the AI ​​automatically supplements the relevant domain knowledge and compliance constraints for the rule, and outputs a list of compliance constraints; Rule analysis phase: Based on the analysis results and the compliance constraint list, the AI ​​breaks down the rules into one or more condition-action pairs and outputs a set of several condition-action pairs; Logical verification phase: The AI ​​performs a logical review of the rules and outputs a list of questions; Test case comparison phase: AI automatically generates a test case set based on the set of several condition-action pairs, and drives the underlying rule engine to execute them one by one to obtain test results; Summary Report Stage: AI summarizes the conclusions of the previous stages and generates an archiveable verification report.

5. The intelligent debt collection processing method according to claim 1, characterized in that, The context information mentioned in step S200 includes: case number, case processing number, task number, number of overdue days, amount owed, customer level, customer level identifier, current node code, previous node code, executed node chain, collection history summary, agency number, and intermediate results of program execution.

6. The intelligent debt collection processing method according to claim 1, characterized in that, Step S300 includes: selecting events from high, medium, and low priority collection events in sequence for processing according to a preset weight ratio of high, medium, and low priorities.

7. The intelligent debt collection processing method according to claim 1, characterized in that, Step S300 includes: determining the current collection processing node based on the process node identified by the current node code in the context information.

8. The intelligent debt collection processing method according to claim 1, characterized in that, Step S300 includes: Read all valid programs under the current collection processing node and arrange them in ascending order of program execution; the process engine obtains the corresponding programs in sequence according to the program codes based on the collection business rules and executes them; after the current collection processing node has executed all programs, proceed to step S400.

9. The intelligent debt collection processing method according to claim 1, characterized in that, Step S400 includes: After all programs on the current collection processing node have been executed, the rule engine parses the flow rules associated with the current collection processing node to determine whether the collection event to be processed matches any flow rule. If any flow rule is matched, the code of the next collection processing node is output according to the flow rule, and the task message of the next collection processing node is sent to the corresponding high, medium or low priority topic according to the case attribute. After the consumer retrieves the task message, steps S300 to S400 are re-executed. If none of the flow rules are matched, the case enters the case closure / collection termination state.

10. An intelligent debt collection system based on an AI rule generation engine and an event-driven node-based workflow, characterized in that, This includes an AI rule generation and verification layer, an event access layer, and a core collection engine layer. The AI ​​rule generation and verification layer is used to generate and verify classification rules, collection business rules, and transfer rules based on AI. And synchronize the verified collection business rules and flow rules to the rule engine; The event access layer is used to pre-classify task messages into high, medium and low priority topics based on the classification rules after verification, and to obtain high, medium and low priority collection events from them; And to build context information for each collection event; The core layer of the collection engine is used to select collection events to be processed from the high, medium and low priority collection events based on the weighted round-robin method, and determine the current collection processing node based on the context information of the collection event to be processed. And invoke the current collection processing node to execute the pending collection event based on the collection business rules; The system also includes a judgment module, which, after all programs on the current collection processing node have been executed, determines whether the collection event to be processed matches any of the flow rules associated with the current collection processing node. If any flow rule is matched, the system outputs the code of the next collection processing node according to the flow rule, sends the task message of the next collection processing node to the corresponding priority topic, and calls the collection engine core layer again to select and execute the collection event to be processed, iterating the above operations. If none of the flow rules are matched, the system enters the case closure / collection termination state.

Images