An e-commerce after-sales dispute autonomous processing method and system based on large model task disintegration

Abstract

The application relates to the field of electronic commerce after-sales dispute processing and machine learning, and particularly relates to an e-commerce after-sales dispute autonomous processing method and system based on large model task decomposition. The method comprises the following steps: receiving an after-sales request and platform dispute record, extracting dispute information according to order numbers to generate initial processing information; dynamically matching a voucher list according to a dispute reason, calling an audit rule to verify the validity of the voucher, and generating a structured task description; performing large language model analysis on the structured task description, combining task template matching and historical case retrieval, and obtaining a sub-task sequence and an execution priority through compliance and rationality auditing; performing information pre-judgment according to the sub-task sequence, generating a pre-judgment result, and executing a corresponding dispute processing scheme, closing the dispute after checking the refund status, and generating a standardized report for storage and iteration. Through structured conversion and large model task decomposition, the application realizes the automation, standardization and closed-loop iteration of after-sales dispute processing.

Description

Technical Field

[0001] This invention relates to the fields of e-commerce after-sales dispute resolution and machine learning, and in particular to an autonomous method and system for resolving e-commerce after-sales disputes based on large model task decomposition. Background Technology

[0002] In the field of e-commerce after-sales dispute resolution and machine learning, existing solutions for handling after-sales request information and platform dispute records typically rely on the platform dispute page, evidence submission status, review status, adjudication execution status, and dispute closure status to complete the process. This approach suffers from limitations such as a fixed process for determining the evidence list, delayed access to review rule information, and a lack of execution priority for subtask sequences. Existing methods often trigger evidence uploading, review, and dispute resolution generation based on the dispute status, or generate preliminary results based on after-sales request information and proposed responses. However, these methods suffer from insufficient structured task descriptions, difficulty in incorporating the validity of evidence information into the task decomposition process, and the absence of historical case library modules in the current processing.

[0003] In scenarios where platform dispute records and after-sales request information coexist, issues such as inconsistencies between dispute causes and solutions, fragmented sources of evidence, and unclear connections between refund record status and adjudication execution status can easily arise, making it difficult to meet the requirement of stable generation of sub-task sequences and execution priorities. Existing intelligent customer service methods mostly revolve around generating target answers, existing task decomposition methods mostly revolve around general task requirements, and existing after-sales processing methods mostly revolve around status transitions or predictive results. There is a lack of a continuous processing link for platform dispute records among these three types of solutions.

[0004] For the joint processing of initial processing information, voucher list, audit rule information, structured task description and large language model parsing, existing technologies generally lack a connection mechanism from determining the validity of voucher information to generating sub-task sequences. This makes it difficult to form a consistent process of acquisition, organization, determination, parsing, verification, auditing, prediction, execution and recording in e-commerce after-sales dispute handling scenarios, resulting in a lack of stable input for the generation process of sub-task sequences and execution priorities in platform dispute records. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a method for autonomously handling e-commerce after-sales disputes based on large-scale model task decomposition, including:

[0006] S100: Receive after-sales requests and platform dispute records, associate them by order number and extract dispute status, dispute cause, product data, refund status and voucher information, and generate initial processing information;

[0007] S200. Based on the initial processing information, match the vouchers according to the cause of the dispute and the solution, call the audit rules to verify the validity of the vouchers, and generate a structured task description;

[0008] S300. Perform large language model parsing, template matching, and case retrieval on the structured task description, and obtain the sub-task sequence and execution priority after compliance and rationality review;

[0009] S400. Based on the subtask sequence and execution priority, perform information prediction and proposed response association to generate prediction results;

[0010] S500: Generate and execute the corresponding dispute resolution plan based on the prediction result, and obtain the execution status of the adjudication plan;

[0011] S600. Based on the execution status of the aforementioned adjudication scheme, perform a refund record status check and platform dispute record update processing to obtain a dispute closure status;

[0012] S700 generates standardized reports and iterates through the database, forming a closed-loop processing mechanism.

[0013] Furthermore, the process of receiving after-sales requests and platform dispute records, and associating them by order number, includes:

[0014] Read after-sales request information from the request content submitted by consumer users in the chat interface, after-sales page or platform dispute page;

[0015] Read the platform dispute records, which include the dispute initiation status, evidence submission status, DHgate review status, adjudication plan execution status, and dispute closure status.

[0016] If the after-sales request information contains an order number that matches the order number in the platform's dispute record, then the after-sales request information will be classified into the corresponding platform dispute record.

[0017] If the after-sales request information does not include an order number, the order number corresponding to the product purchase data will be retrieved from the dispute overview and description information in the platform's dispute record.

[0018] If there are multiple order numbers in the platform's dispute records, they will be matched according to the product parameters, refund record status, and uploaded evidence in the after-sales request information, and the matched order number will be recorded as the order number field in the initial processing information;

[0019] Retrieves the dispute initiation status, evidence submission status, DHgate review status, adjudication execution status, and dispute closure status from the platform's dispute records, and records the current valid status as the dispute status field.

[0020] Furthermore, the process of extracting dispute status, dispute cause, product data, refund status, and voucher information to generate initial processing information includes:

[0021] Retrieves the dispute initiation status, evidence submission status, DHgate review status, adjudication plan execution status, and dispute closure status from the platform's dispute records, and records the current valid status as the dispute status field;

[0022] The description information in the after-sales request information submitted by the consumer user is compared with the dispute cause field in the dispute record of the platform. If they match, the dispute cause is written into the initial processing information. If they do not match, both are written into the initial processing information.

[0023] A read request is sent to the business information database based on the order number to read the product purchase data and product parameters. The product purchase data includes consumer user, merchant user, product object, purchase time, transaction amount, order status and service data node. The product parameters include product name, product specifications, product quantity, product parameter verification information and description information corresponding to the product object.

[0024] First, read the refund record status from the business information database, then read the refund record status associated with the execution status of the adjudication plan from the platform dispute records. If they match, write the initial processing information; if they do not match, write both and the corresponding reading time into the initial processing information.

[0025] Read the uploaded evidence in the evidence upload area, associate the uploaded evidence with the order number, cause of dispute and dispute solution, and mark the source of the voucher information as business information database voucher information, platform dispute record voucher information or description information voucher information.

[0026] Furthermore, the process of matching evidence with the cause of the dispute and the proposed solution, and then applying audit rules to verify the validity of the evidence, includes:

[0027] The matching of dispute causes and solutions includes: a list of credentials determined according to the dispute causes and dispute solutions;

[0028] When the dispute is caused by the buyer not receiving the goods, the logistics voucher, product purchase data, and refund record status will be written into the voucher list;

[0029] When the cause of the dispute does not match the description, the product parameters, uploaded evidence, and description information will be written into the voucher list;

[0030] When the dispute resolution is a partial refund, a full refund, or a return and refund, the refund record status, product purchase data, and uploaded evidence will be written into the voucher list;

[0031] The process of verifying the validity of vouchers by invoking audit rules includes: invoking audit rule information based on the voucher list, wherein the audit rule information includes the matching relationship between voucher information name, voucher information source, voucher information fields, dispute cause, dispute solution, and refund record status;

[0032] The validity determination process for the voucher information includes matching the order number, product parameters, dispute reasons, dispute solutions, and refund record status.

[0033] When the voucher information corresponding to the voucher list exists in the business information database, the voucher information is retrieved from the business information database and matched with the audit rule information to obtain the voucher information validity result. The voucher information validity result includes valid, invalid, and not uploaded status.

[0034] When the validity result of the credential information is "not uploaded", the credential list is sent to the consumer user or merchant user, and a guiding question is output to obtain the supplementary credential information.

[0035] Further, the process of performing large language model parsing, template matching, and case retrieval, and obtaining the sub-task sequence and execution priority after compliance and reasonableness review includes:

[0036] First, read the validity result of the voucher information; only start parsing the large language model if the validity result of the voucher information is valid.

[0037] Input the after-sales request information, dispute cause, dispute solution, voucher list, audit rule information, and voucher validity result into the big language model. The big language model outputs the task type, task object, execution conditions, completion conditions, and task description. The task type includes after-sales request information prediction task, voucher list determination task, voucher information capture task, voucher information submission task, voucher information validity determination task, product purchase data query task, product parameter verification task, platform dispute record status confirmation task, dispute solution generation task, adjudication solution execution status update task, and dispute closure status update task.

[0038] The template matching and case retrieval process includes: matching the task type, task object, execution conditions, and completion conditions with the task template; if the match is successful, a first sub-task sequence is generated; if the match is unsuccessful, historical cases are retrieved, and the historical cases and structured task descriptions are input into the large language model to generate a second sub-task sequence.

[0039] The compliance and reasonableness review includes: calling the review rule information to perform compliance verification on the tasks of determining the validity of voucher information, querying product purchase data, verifying product parameters, and generating dispute solutions in the sub-task sequence; if the match passes, it is marked as a compliant task; if the match fails, it is marked as an abnormal task and the reason for the abnormality is recorded.

[0040] Check the order of the subtask sequence. If there is a conflict, generate optimization suggestions. Re-input the optimization suggestions and the structured task description into the large language model to regenerate the subtask sequence.

[0041] Furthermore, the process of predicting information and associating it with proposed responses to generate prediction results includes:

[0042] The information prediction includes: initiating after-sales request information prediction processing according to execution priority, putting the request content, dispute cause, dispute solution, voucher information and audit rule information in the after-sales request information into the same prediction record, and performing field matching;

[0043] The proposed response association includes: reading the response method information and reason information from the proposed response information, associating the response method information with the dispute resolution solution, and associating the reason information with the cause of the dispute;

[0044] If the response information indicates agreement to a partial refund, agreement to a full refund, or agreement to return the goods and receive a refund, then the corresponding refund record status will be retrieved.

[0045] If the response information is to reject the after-sales request, the reason information, evidence information, and audit rule information will be written into the same pre-judgment record;

[0046] The generation of the prediction result includes: generating prediction results based on the validity results of the voucher information, the proposed response information, and the dispute resolution, including three types of records: those supporting consumer users, those supporting merchant users, and those unknown;

[0047] The predicted results are then matched with the dispute resolution solutions to obtain a matching degree, which includes a matching degree higher than the preset confidence level and a matching degree lower than the preset confidence level.

[0048] Furthermore, the process of generating and executing a corresponding dispute resolution plan based on the predicted results, and obtaining the execution status of the adjudication plan, includes:

[0049] First, read the matching score. When the matching score is higher than the preset confidence score, generate the corresponding processing record based on partial refund, full refund, or return and refund.

[0050] When the matching degree is lower than the preset confidence level, an optimization prompt is generated and the subtask sequence generation is retried;

[0051] The execution of the corresponding dispute resolution plan includes: when the dispute resolution plan is a partial refund and the voucher information matches the review rule information, the partial refund is written into the platform dispute record and the refund record status is updated to "processing";

[0052] When the dispute resolution is a full refund and the refund record status is "not initiated", a full refund processing record is generated, and the platform dispute record is updated to the adjudication execution status;

[0053] When the dispute resolution is a return and refund and the product parameters match the voucher information, the return and refund will be written into the platform's dispute record, and the platform's dispute record will be updated to the status of the adjudication.

[0054] Furthermore, the process of checking the status of refund records and updating platform dispute records includes:

[0055] The refund record status is retrieved from the business information database based on the order number, and then matched with the refund record status in the adjudication plan execution status.

[0056] If the statuses of the two refund records are identical, then the status of the refund record will be written into the platform's dispute record.

[0057] If the refund records in the two places are inconsistent, the refund record status in the business information database, the refund record status in the adjudication plan execution status, the order number and the reading time will be written into the platform dispute record and marked as an abnormal record;

[0058] When the dispute resolution is a partial or full refund and the refund record status is "completed", the execution status of the adjudication in the platform dispute record will be updated to "dispute closed".

[0059] When the dispute resolution solution is a return and refund and the processing conditions are met, the execution status of the resolution solution will be updated to the dispute closed status. The processing conditions include matching of product parameters, validity results of voucher information, refund record status, and uploaded evidence.

[0060] Furthermore, the process of generating standardized reports and iterating them into the database to form a closed loop includes:

[0061] Create a report record based on the order number, write the dispute status, dispute cause, dispute solution and description information from the platform dispute record into the report record, write the voucher list, voucher information and audit rule information into the report record, and write the voucher information validity result with the voucher information;

[0062] Write the prediction results, matching degree, and prediction information database records into the report record. When the matching degree is lower than the preset reliability, write the optimization prompts and re-triggering large language model processing records into the report record. When the matching degree is higher than the preset reliability, write the processing records in the execution status of the adjudication scheme into the report record.

[0063] The after-sales request information, dispute causes, dispute solutions, voucher list, voucher validity results, prediction results, sub-task sequence, execution priority, adjudication status, and dispute closure status from the standardized report are assembled into a new deconstructed case.

[0064] The new case study is compared with existing historical cases. If there are historical cases with the same cause of dispute and the same solution, the new case study is added to the historical case record of the same type. Otherwise, a new historical case record is created.

[0065] Furthermore, an e-commerce after-sales dispute autonomous handling system based on large model task decomposition includes: an information receiving module, a voucher processing module, a task decomposition module, an information prediction system module, a dispute solution generation module, a platform dispute handling module, a standardized report generation module, and a historical decomposition case library module; the system is used to implement the method described in any of the above-mentioned modules.

[0066] The key innovations of this invention include:

[0067] (1) The initial processing information is first processed by determining the voucher list, calling the audit rule information and determining the validity of the voucher information to obtain a structured task description, so that the after-sales request information, platform dispute records, dispute causes, dispute solutions, product purchase data, product parameters, refund record status and voucher information form a unified input before entering the large language model for parsing.

[0068] (2) Based on the structured task description, perform large language model parsing, task template matching, historical decomposition case library module retrieval, compliance verification and reasonableness review processing to obtain the sub-task sequence and execution priority, so that the sub-task sequence no longer comes from the fixed dispute status flow, but comes from the structured task description and review rule information.

[0069] (3) The subtask sequence and execution priority are sequentially passed to the after-sales request information prediction, dispute solution generation, adjudication solution execution status update, dispute closure status processing and online iterative optimization processing, and the standardized report is written into the historical dismantling case library module to form a new dismantling case.

[0070] The following are its main beneficial effects:

[0071] (1) In response to the problems of the existing solution that the determination of the voucher list depends on a fixed process and the lag in the call of audit rule information, the voucher information is associated with the cause of the dispute, the solution to the dispute and the status of the refund record by the voucher list determination, the call of audit rule information and the determination of the validity of voucher information, so that the structured task description contains the stable input required for subsequent large language model parsing.

[0072] (2) In response to the problem that the parsing of large language models in the existing solution is prone to getting stuck on after-sales request information or ordinary customer service answers, the output content is transformed into a sub-task sequence and execution priority through structured task description, task template matching, historical decomposition case library module retrieval, compliance verification and reasonableness review, and is connected with the subsequent prediction result generation and the execution status of the adjudication solution.

[0073] (3) In response to the problem that the platform dispute records in the existing solution rely heavily on the flow of dispute status, the prediction of after-sales request information, the association of proposed response information and the generation of prediction results are driven by sub-task sequence and execution priority, so that the prediction results enter the dispute solution generation process and serve as the input for partial refund, full refund and return refund processing.

[0074] (4) To address the issue of unclear connection between the refund record status and the execution status of the adjudication plan, the processing records corresponding to partial refunds, full refunds, and return refunds are put into the dispute closure status by checking the refund record status under the execution status of the adjudication plan and updating the platform dispute records.

[0075] (5) To address the issue that the historical dismantling case library module is not involved in the current processing, after-sales request information, platform dispute records, voucher list, voucher information, audit rule information, prediction results, sub-task sequence, execution priority, dispute resolution solution, adjudication scheme execution status and dispute closure status are written into the new dismantling case through standardized report generation and online iterative optimization. Attached Figure Description

[0076] Figure 1 A flowchart illustrating an autonomous handling method for e-commerce after-sales disputes based on large model task decomposition, provided for an embodiment of this application;

[0077] Figure 2 This is a structural block diagram of an e-commerce after-sales dispute autonomous handling system based on large model task decomposition, provided as an embodiment of this application. Detailed Implementation

[0078] Example 1: Refer to Figure 1 This is a flowchart illustrating an autonomous handling method for e-commerce after-sales disputes based on large model task decomposition provided by an embodiment of the present invention. The process may include at least steps S100-S700:

[0079] S100: Receive after-sales requests and platform dispute records, associate them by order number and extract dispute status, dispute cause, product data, refund status and voucher information, and generate initial processing information;

[0080] S200. Based on the initial processing information, match the vouchers according to the cause of the dispute and the solution, call the audit rules to verify the validity of the vouchers, and generate a structured task description;

[0081] S300. Perform large language model parsing, template matching, and case retrieval on the structured task description, and obtain the sub-task sequence and execution priority after compliance and rationality review;

[0082] S400. Based on the subtask sequence and execution priority, perform information prediction and proposed response association to generate prediction results;

[0083] S500: Generate and execute the corresponding dispute resolution plan based on the prediction result, and obtain the execution status of the adjudication plan;

[0084] S600. Based on the execution status of the aforementioned adjudication scheme, perform a refund record status check and platform dispute record update processing to obtain a dispute closure status;

[0085] S700 generates standardized reports and iterates through the database, forming a closed-loop processing mechanism.

[0086] S100: Receive after-sales requests and platform dispute records, associate them by order number and extract dispute status, dispute cause, product data, refund status and voucher information, and generate initial processing information;

[0087] Specifically, this step is executed by the information receiving unit in the e-commerce customer service system. The after-sales request information comes from requests submitted by consumer users on the chat interface, after-sales page, or platform dispute page. The platform dispute record comes from the platform dispute handling module. The platform dispute record includes dispute initiation status, evidence submission status, DHgate review status, adjudication plan execution status, dispute closure status, dispute overview area, evidence upload area, uploaded evidence, and description information. When the information receiving unit receives the after-sales request information, it reads the platform dispute record and associates the after-sales request information with the platform dispute record. This association is completed using the order number. The order number is a common field among the after-sales request information, platform dispute record, product purchase data, refund record status, and voucher information.

[0088] Specifically, the order number is read by the information receiving unit from the after-sales request information and the platform dispute record, respectively. If the two order numbers match, the information receiving unit categorizes the after-sales request information into the corresponding platform dispute record. If the after-sales request information does not contain an order number, the information receiving unit reads the order number corresponding to the product purchase data from the dispute overview area and description information of the platform dispute record. If multiple order numbers exist in the platform dispute record, the information receiving unit matches them according to the product parameters, refund record status, and uploaded evidence in the after-sales request information, and records the matched order number as the order number field in the initial processing information. Thus, subsequent credential list determination processing is carried out under the same order number.

[0089] Specifically, the dispute status refers to the current state of the dispute record on the platform. The information receiving unit reads the dispute initiation status, evidence submission status, DHgate review status, adjudication plan execution status, and dispute closure status from the platform dispute record, and records the current valid status as the dispute status field. If the platform dispute record is already in the dispute closure status, the information receiving unit reads the refund record status and uploaded evidence, and marks the record as a closed record. If the platform dispute record is in the dispute initiation status or evidence submission status, the information receiving unit continues to read the dispute cause, dispute solution, and supporting documentation, and proceeds to processing. If the platform dispute record is in the adjudication plan execution status, the information receiving unit reads the refund record status and writes the refund record status into the initial processing information.

[0090] Specifically, the dispute causes originate from the after-sales request information submitted by the consumer user and the dispute cause field in the platform's dispute records. The dispute causes include buyer not receiving goods, discrepancy with description, refund request, return and refund request, partial refund request, and full refund request. The information receiving unit reads the description information from the after-sales request information and compares the reading result with the dispute cause in the platform's dispute records. If they match, the information receiving unit writes the dispute cause into the initial processing information. If they do not match, the information receiving unit writes the description information from the after-sales request information, the dispute cause from the platform's dispute records, and uploaded evidence together into the initial processing information, and retains the original record for S200 to use for credential list determination processing.

[0091] Specifically, the dispute resolution solution is a solution already filled in in the platform's dispute record or requested by the consumer user. The dispute resolution solutions include partial refund, full refund, and return / refund. The information receiving unit reads the request content from the after-sales request information and reads the dispute resolution solution from the platform's dispute record. If the consumer user submits a partial refund request, the information receiving unit writes the partial refund into the dispute resolution solution field. If the consumer user submits a full refund request, the information receiving unit writes the full refund into the dispute resolution solution field. If the consumer user submits a return / refund request, the information receiving unit writes the return / refund into the dispute resolution solution field and simultaneously reads the refund record status and uploaded evidence. The dispute resolution solution field serves as input for determining the processing of the credential list in S200.

[0092] Specifically, the product purchase data comes from a business information database. This database stores product purchase data, product parameters, refund record status, and voucher information. The information receiving unit sends a read request to the business information database based on the order number and reads the product purchase data. The product purchase data includes the consumer user, merchant user, product object, purchase time, transaction amount, order status, and service data node. The product parameters include the product name, product specifications, product quantity, product parameter verification information, and description information corresponding to the product object. The information receiving unit binds the product purchase data and product parameters to the order number and writes the bound data into the initial processing information. If the business information database does not return product purchase data, the information receiving unit writes the product parameters and description information from the platform dispute record into the initial processing information and records the status of the business information database not returning the data.

[0093] Specifically, the refund record status comes from the business information database and the platform dispute record. The refund record status includes not initiated, processing, completed, and abnormal records. The information receiving unit first reads the refund record status from the business information database, and then reads the refund record status associated with the adjudication scheme execution status from the platform dispute record. If the two refund record statuses are consistent, the information receiving unit writes the refund record status into the initial processing information. If the two refund record statuses are inconsistent, the information receiving unit writes the refund record status returned from the business information database, the refund record status in the platform dispute record, and the corresponding read time into the initial processing information, and makes this field available for the S600's refund record status check. This process is automatically triggered when the platform dispute record is in the adjudication scheme execution status.

[0094] Specifically, the credential information comes from the evidence upload area, uploaded evidence, description information, and the business information database. The credential information includes image information uploaded by consumer users, image information uploaded by merchant users, logistics vouchers, transaction vouchers, refund vouchers, and reason information corresponding to the proposed response. The information receiving unit reads the uploaded evidence from the evidence upload area and associates the uploaded evidence with the order number, dispute cause, and dispute solution. If the credential information comes from the business information database, the information receiving unit marks it as business information database credential information. If the credential information comes from platform dispute records, the information receiving unit marks it as platform dispute record credential information. If the credential information comes from the description information in the after-sales request information, the information receiving unit marks it as description information credential information. These markings are written into the initial processing information, which S200 uses to call the audit rules information to determine the validity of the credential information.

[0095] In one implementation, a consumer submits a "not received goods and requesting a full refund" after-sales request on the after-sales page. The information receiving unit reads the platform's dispute records to obtain the order number, dispute initiation status, dispute reason, and full refund. Subsequently, the information receiving unit accesses the business information database based on the order number to read the product purchase data, product parameters, and refund record status. If the evidence upload area contains logistics vouchers and description information, the information receiving unit synchronously writes the logistics vouchers, description information, and refund record status into the initial processing information. If the evidence upload area does not contain uploaded evidence, the information receiving unit still generates initial processing information and records the "not uploaded" status in the voucher information field. This "not uploaded" status serves as the trigger condition for determining the voucher list processing in S200.

[0096] In another implementation, the merchant user has submitted a proposed response, which includes reasons for rejecting the after-sales request. The information receiving unit reads the after-sales request, the proposed response, the reasons, and the platform dispute record, and associates the reasons with the cause of the dispute. If the reasons are inconsistent with the dispute resolution, the information receiving unit does not change the dispute status in the platform dispute record, but only writes the proposed response and the reasons into the initial processing information. This initial processing information is used in S400 for after-sales request information prediction and proposed response information association processing.

[0097] After completing the above processing, the initial processing information includes after-sales request information, platform dispute records, order number, dispute status, dispute cause, dispute solution, product purchase data, product parameters, refund record status, voucher information, proposed response information, and reason information. This initial processing information is sent from the information receiving unit to S200. S200 uses this initial processing information to determine the voucher list, retrieve audit rule information, and determine the validity of the voucher information, thus obtaining a structured task description. Therefore, the initial processing information output by S100 directly becomes the input to S200.

[0098] Summary of the technical effects of this step: This step integrates after-sales request information, platform dispute records, business information database, and voucher information into the same initial processing information. Order numbers are integrated across product purchase data, product parameters, refund record status, and voucher information. This organization method provides a stable input for determining the voucher list and retrieving audit rule information in S200.

[0099] S200. Based on the initial processing information, match the vouchers according to the cause of the dispute and the solution, call the audit rules to verify the validity of the vouchers, and generate a structured task description;

[0100] Specifically, this step is jointly executed by the voucher list determination unit, the audit rule information acquisition unit, and the voucher information validity determination unit. The voucher list determination unit receives the initial processing information obtained in S100 and reads the after-sales request information, platform dispute records, order number, dispute status, dispute cause, dispute solution, product purchase data, product parameters, refund record status, voucher information, proposed response information, and reason information from the initial processing information. When the initial processing information enters this step, the voucher list determination unit first performs a consistent reading of the order number, and then associates the order number with the dispute cause, dispute solution, and product purchase data. After the association is completed, the voucher list determination unit determines the voucher list according to the dispute cause and dispute solution. The voucher list is a collection of records corresponding to the voucher information name, voucher information source, and voucher information status of the current after-sales request information. The voucher information source includes the business information database, evidence upload area, uploaded evidence, and description information.

[0101] Specifically, when the dispute is caused by the buyer not receiving the goods, the document list determination unit writes the logistics documents, product purchase data, and refund record status into the document list. When the dispute is caused by discrepancies with the description, the document list determination unit writes the product parameters, uploaded evidence, and description information into the document list. When the dispute resolution is a partial refund, a full refund, or a return and refund, the document list determination unit writes the refund record status, product purchase data, and uploaded evidence into the document list. If the initial processing information includes proposed response information and reason information, the document list determination unit matches the proposed response information and reason information with the dispute cause and writes the matching result into the document list. This process is automatically triggered when the platform dispute record is in the dispute initiation state or evidence submission state. When the platform dispute record is in the adjudication scheme execution state, the document list determination unit adds the refund record status to the document list.

[0102] Furthermore, the audit rule information acquisition unit retrieves audit rule information based on the voucher list. The audit rule information is a set of rule records shared by the platform dispute resolution module and the information prediction system module. The audit rule information includes the matching relationship between voucher information name, voucher information source, voucher information fields, dispute cause, dispute solution, and refund record status. The audit rule information acquisition unit reads the voucher information name from the voucher list and searches for the corresponding audit rule information in the business information database and the platform dispute records. If the voucher information in the voucher list comes from the business information database, the audit rule information acquisition unit reads the corresponding audit rule information from the business information database. If the voucher information in the voucher list comes from the evidence upload area, the audit rule information acquisition unit reads the audit rule information corresponding to the uploaded evidence. If the voucher information in the voucher list comes from the description information, the audit rule information acquisition unit reads the audit rule information corresponding to the description information.

[0103] Specifically, the voucher information validity determination unit receives the voucher list, the audit rule information, and the initial processing information, and performs validity determination processing on the voucher information. The voucher information validity determination processing includes order number matching, product parameter matching, dispute cause matching, dispute solution matching, and refund record status matching. Order number matching checks whether the order number associated with the voucher information matches the order number in the initial processing information. Product parameter matching checks whether the product name, product specifications, product quantity, and product parameters corresponding to the voucher information are consistent. Dispute cause matching checks whether the voucher information corresponds to the dispute cause. Dispute solution matching checks whether the voucher information corresponds to a partial refund, a full refund, or a return and refund. Refund record status matching checks whether the refund record status corresponds to the dispute solution.

[0104] Further, when the voucher information corresponding to the voucher list exists in the business information database, the voucher information validity determination unit retrieves the voucher information from the business information database and matches the retrieved voucher information with the audit rule information to obtain a voucher information validity result. The voucher information validity result includes valid, invalid, and not uploaded status. When the voucher information validity result is valid, the voucher information validity determination unit writes the result into the structured task description. When the voucher information validity result is invalid, the voucher information validity determination unit writes the invalidity reason, voucher information name, and audit rule information into the structured task description, and records that the platform dispute record does not enter the adjudication scheme execution status. When the voucher information validity result is not uploaded status, the voucher list determination unit sends the voucher list to the consumer user or merchant user and outputs guiding rhetorical questions to obtain supplementary voucher information. After the supplementary voucher information is returned, the voucher information validity determination unit performs the validity determination process again.

[0105] In one implementation, the initial processing information shows the dispute cause as "buyer did not receive goods," the dispute resolution as "full refund," and the refund record status as "not initiated." The voucher list determination unit reads the business information database based on the order number and writes the logistics voucher, product purchase data, and refund record status into the voucher list. The audit rule information acquisition unit calls the audit rule information corresponding to the buyer not receiving goods. The voucher information validity determination unit matches the order number in the logistics voucher, the product object in the product purchase data, and the dispute cause in the platform dispute record. If the match is successful, a valid voucher information validity result is obtained. If the match fails, an invalid voucher information validity result is obtained, and the voucher information name and audit rule information are written into the structured task description.

[0106] In another implementation, the initial processing information indicates that the cause of the dispute does not match the description, the dispute resolution is a return and refund, and no evidence is uploaded in the evidence upload area. The voucher list determination unit determines a voucher list based on the product parameters and description information, and sends the voucher list to the consumer user. The guiding question is generated based on the voucher information names in the voucher list and points to the product parameters, uploaded evidence, and description information. After the consumer user submits supplementary voucher information, the voucher information validity determination unit calls the audit rules information to complete the voucher information validity determination process and writes the voucher information validity result into the structured task description.

[0107] The structured task description is jointly generated by the voucher list determination unit, the audit rule information acquisition unit, and the voucher information validity determination unit. The structured task description includes after-sales request information, platform dispute records, order number, dispute status, dispute cause, dispute solution, product purchase data, product parameters, refund record status, voucher list, voucher information, audit rule information, voucher information validity result, proposed response information, and reason information. This structured task description is output from this step and sent to S300. S300 performs large language model parsing, task template matching, historical case library module retrieval, compliance verification, and reasonableness review based on the structured task description to obtain a sub-task sequence and execution priority.

[0108] In summary, this step integrates the voucher list, audit rule information, and voucher validity results into a single structured task description. This structured task description inherits the initial processing information from S100 and provides a unified input for the large language model parsing in S300. The three states of voucher information—not uploaded, invalid, and valid—are entered into different processing records, forming a processing chain distinct from fixed evidence submission states.

[0109] S300. Perform large language model parsing, template matching, and case retrieval on the structured task description, and obtain the sub-task sequence and execution priority after compliance and rationality review;

[0110] Specifically, this step is executed by the task decomposition module. The task decomposition module receives the structured task description obtained from S200 and reads after-sales request information, platform dispute records, order number, dispute status, dispute cause, dispute solution, product purchase data, product parameters, refund record status, voucher list, voucher information, audit rule information, voucher information validity result, proposed response information, and reason information from the structured task description. The large language model is a model that receives the structured task description and outputs a sequence of subtasks. The task template is a template that records the task type, task object, execution conditions, completion conditions, and execution priority. The historical decomposition case library module is a case library that stores historical cases, standardized reports, subtask sequences, and execution results. After receiving the structured task description, the task decomposition module first reads the voucher information validity result. If the voucher information validity result is valid, the task decomposition module starts parsing using the large language model. If the voucher information validity result is invalid or not uploaded, the task decomposition module still reads the structured task description and uses the voucher information validity result as a constraint condition for task template matching.

[0111] Specifically, the large language model parsing process includes semantic category reading, dispute cause reading, dispute solution reading, and credential information status reading. The task decomposition module inputs the after-sales request information, the dispute cause, the dispute solution, the credential list, the audit rule information, and the credential information validity result into the large language model. The large language model parses the structured task description and outputs the task type, task object, execution conditions, completion conditions, and task description. The task type corresponds to the after-sales request information prediction task, credential list determination task, credential information retrieval task, credential information submission task, credential information validity determination task, product purchase data query task, product parameter verification task, platform dispute record status confirmation task, dispute solution generation task, adjudication solution execution status update task, and dispute closure status update task. The task object corresponds to the order number, platform dispute record, credential information, product purchase data, product parameters, refund record status, and proposed response information.

[0112] Specifically, the task template matching process involves the task decomposition module matching the task type, task object, execution conditions, and completion conditions with task templates. If the dispute cause in the structured task description is that the buyer has not received the goods, and the dispute solution is a full refund, the task decomposition module matches a task template that includes tasks such as querying product purchase data, determining the validity of voucher information, predicting after-sales request information, generating a dispute solution, and updating the execution status of the adjudication plan. If the dispute cause in the structured task description does not match the description, and the dispute solution is a return and refund, the task decomposition module matches a task template that includes tasks such as verifying product parameters, submitting voucher information, determining the validity of voucher information, confirming the status of platform dispute records, and generating a dispute solution. If the task template is successfully matched, the task decomposition module generates a first sub-task sequence based on the successfully matched task template and writes an execution priority to the first sub-task sequence.

[0113] Specifically, the historical case library module initiates its retrieval process when task template matching fails. The task decomposition module reads historical cases from the historical case library module and compares the dispute causes, dispute solutions, evidence lists, evidence validity results, prediction results, adjudication status, and dispute closure status of these historical cases with the structured task description. When the comparison results meet the similarity criteria, the task decomposition module inputs the historical cases and the structured task description into the large language model. The large language model generates a second sub-task sequence and assigns an execution priority to the second sub-task sequence. The similarity criteria consist of consistent dispute causes, consistent dispute solutions, consistent evidence lists, and consistent evidence validity results. If the historical case library module does not find any historical cases, the task decomposition module generates a second sub-task sequence based on the task type, task object, execution conditions, and completion conditions in the structured task description.

[0114] Specifically, the compliance verification process is completed by the task decomposition module calling the audit rule information. The task decomposition module matches the tasks for determining the validity of voucher information, querying product purchase data, verifying product parameters, and generating dispute solutions in the first or second sub-task sequence with the audit rule information. When the audit rule information matches successfully, the task decomposition module marks the corresponding task as a compliant task. When the audit rule information does not match successfully, the task decomposition module marks the corresponding task as an abnormal task and records the reason for the abnormality. If the voucher information validity result is invalid, the task decomposition module retains the voucher information submission task in the sub-task sequence and sets the voucher information submission task before the dispute solution generation task. If the refund record status is completed, the task decomposition module retains the platform dispute record status confirmation task and the dispute closure status update task in the sub-task sequence.

[0115] Specifically, the reasonableness review process is completed by the task decomposition module based on the dispute status, dispute cause, dispute solution, and refund record status. The task decomposition module checks the order of the sub-task sequences. The credential information submission task precedes the credential information validity determination task. The credential information validity determination task precedes the after-sales request information prediction task. The after-sales request information prediction task precedes the dispute solution generation task. The dispute solution generation task precedes the adjudication scheme execution status update task. The adjudication scheme execution status update task precedes the dispute closure status update task. If a sequence conflict occurs in the sub-task sequence, the task decomposition module generates an optimization suggestion and re-inputs the optimization suggestion and the structured task description into the large language model. The large language model regenerates the sub-task sequence and re-enters the compliance verification and reasonableness review process.

[0116] In one implementation, the dispute cause in the structured task description is that the buyer has not received the goods, the dispute resolution is a full refund, the validity result of the voucher information is valid, and the refund record status is "not initiated". The task decomposition module matches the corresponding task template and generates a first sub-task sequence. The first sub-task sequence sequentially includes a product purchase data query task, a voucher information validity determination task, a after-sales request information prediction task, a dispute resolution generation task, and a resolution execution status update task. The task decomposition module calls the audit rule information to complete the compliance verification, then completes the reasonableness review based on the refund record status, and writes the execution priority.

[0117] In another implementation, the cause of the dispute in the structured task description does not match the description, the dispute solution is a return and refund, and the validity result of the voucher information is "not uploaded". When the task decomposition module does not match the task template, it reads historical cases from the historical decomposition case library module. When the historical cases match the cause of the dispute and the dispute solution in the structured task description, the large language model generates a second sub-task sequence. The second sub-task sequence includes, in sequence, a voucher information submission task, a product parameter verification task, a voucher information validity determination task, a after-sales request information prediction task, a dispute solution generation task, and a ruling solution execution status update task. The task decomposition module sets the voucher information submission task as a higher execution priority and writes the execution priority into the sub-task sequence.

[0118] After completing the above processing, the task decomposition module outputs a subtask sequence and execution priority. The subtask sequence includes task type, task object, execution conditions, completion conditions, and task description. The execution priority records the execution order and triggering conditions of each subtask. The subtask sequence and execution priority are sent to S400. Based on the subtask sequence and execution priority, S400 performs after-sales request information prediction, correlates proposed response information, and generates prediction results to obtain the prediction results.

[0119] In summary, this step converts structured task descriptions into a sequence of subtasks and execution priorities. Task template matching and historical decomposition case library retrieval modules handle recorded and unrecorded scenarios respectively. Compliance verification and rationality review incorporate review rules into the task decomposition process, providing clear input for subsequent prediction result generation.

[0120] In one specific embodiment:

[0121] In S300, the structured task description is parsed using a large language model, template matching is performed, and case retrieval is conducted. After compliance and rationality review, a sequence of subtasks and their execution priorities are obtained.

[0122] Part 1: The task decomposition module receives a structured task description from S200, from which it reads after-sales request information, platform dispute records, order number, dispute status, dispute cause, dispute solution, product purchase data, product parameters, refund record status, voucher list, voucher information, audit rule information, voucher information validity result, proposed response information, and reason information. The module first reads the voucher information validity result. If the result is "valid," it initiates large language model parsing; otherwise, the result is used as a constraint for task template matching, skipping model calls and directly entering the template matching path. Large language model parsing processing includes semantic category reading, dispute cause reading, dispute solution reading, and voucher information status reading. To quantify the matching degree between the structured task description and the task template, an attention-weighted matching score is defined. Formula ① calculates the feature vector extracted from the structured task description and the... The cosine similarity between the feature vectors of each task template is used, and dispute state weights are introduced.

[0123] Formula①

[0124]

[0125] in: Structured task description and the first The matching score for each task template, with a value range of... ;

[0126] : Index of task templates ,in The total number of task templates (derived from the number of templates in the historical deconstruction case library module);

[0127] Feature dimension index ;

[0128] The total dimension of the feature is determined by the number of voucher information names, the number of enumerated causes of disputes, and the number of enumerated solutions to disputes in the voucher list. ;

[0129] : No. The template in the first The attention weight on the dimension is derived from the frequency of association between each voucher information name and the cause of dispute recorded in the review rules information, and its value range is... and ;

[0130] Structured task description in the first The normalized eigenvalues ​​on the dimension are linearly combined from the validity results of the voucher information, the dispute cause matching indicator, and the dispute solution matching indicator, with a value range of [value range missing]. ;

[0131] : No. The task template is in the first... The baseline feature value on the dimension is generated by enumerating the execution conditions and completion conditions in the task template, and takes the value 0 or 1.

[0132] :right From 1 to Sum.

[0133] Data source mapping: Extracting the voucher list, cause of dispute, and dispute resolution from the structured task description to obtain feature vectors. The task type, task object, execution conditions, and completion conditions are extracted from the task template. The matching relationship between the voucher information name and the cause of the dispute is obtained by extracting the information from the audit rules. .

[0134] Simple numerical example: Suppose the cause of the dispute in the structured task description is "buyer did not receive goods", the solution is "full refund", and the validity result of the voucher information is valid, then the corresponding... ;template The baseline feature is set as Weight The numerator is calculated as 0.4 × 1 × 1 + 0.3 × 1 × 1 + 0.3 × 1 × 1 = 1.0. The left-hand side of the denominator is calculated as √[(0.4 × 1)² + (0.3 × 1)² + (0.3 × 1)²] = √(0.16 + 0.09 + 0.09) = √0.34 ≈ 0.5831. The right-hand side of the denominator is calculated as √(1 + 1 + 1) = √3 ≈ 1.732. The denominator is calculated as 0.5831 × 1.732 ≈ 1.010. Therefore... High matching degree.

[0135] Output of Formula ① As a criterion for determining whether subsequent steps result in a successful template match, when Match successful.

[0136] Formula ② integrates the matching score with the validity result of the voucher information to form the conditional trigger probability of task decomposition, which is used to determine whether to call the large language model to generate a sequence of subtasks.

[0137] Formula②

[0138]

[0139] in: : The probability of triggering the generation of subtask sequences by the large language model, with a value range of ;

[0140] Sigmoid function, definition Mapping real values ​​to interval;

[0141] The preset coefficients are derived from the regression parameters of matching scores and success rates statistically analyzed in the historical case library module. ;

[0142] The highest matching score output by formula ① is... ;

[0143] : Preset coefficient, take ;

[0144] : Voucher information validity flag, set to 1 if the voucher information validity result in the structured task description is "valid", otherwise set to 0;

[0145] : Preset coefficient, take ;

[0146] : Voucher upload status flag. The value is 0 when the voucher information validity result is "not uploaded" and 1 when it has been uploaded;

[0147] :when The value is 1 if it is not uploaded, otherwise it is 0.

[0148] Data source mapping: Obtained from the validity results of the extracted voucher information based on the structured task description. and The output of formula ① is obtained .

[0149] Simple numerical example: Continuing from the previous example , , The linear combination is calculated as 1.2 × 0.990 + 1.0 × 1 - 0.8 × (1 - 1) = 1.188 + 1 - 0 = 2.188, and Sigmoid(2.188) = 0.899. The trigger probability is 89.9%, which exceeds the threshold of 0.5, so the large language model is activated.

[0150] Output of Formula ② The data is then sent to the subsequent template matching and historical case retrieval module to determine whether to generate the first or second subtask sequence. If the template matches successfully, the first subtask sequence is generated; otherwise, the historical decomposition case library module is retrieved. The first subtask sequence output in this section includes the task type, task object, execution conditions, completion conditions, and task description, and the execution priority is written in. This subtask sequence is used as input to the "Information Prediction" module of S400.

[0151] Part Two: Matching scores that follow from the output of Part One With trigger probability When a task template match fails, the historical case library module is activated for retrieval and processing. The task decomposition module reads historical cases from the historical case library module and compares the dispute causes, dispute solutions, evidence lists, evidence validity results, preliminary judgments, execution status of the adjudication plan, and dispute closure status of the historical cases with the structured task description. To quantify the similarity between historical cases and the current structured task description, a weighted similarity function is defined. Formula ③ calculates the historical cases. The similarity to the current description is calculated using the cosine similarity of the binary encoded vectors of the dispute cause, solution, and voucher list, and a consistency penalty is introduced for the validity of the voucher information.

[0152] Formula③

[0153]

[0154] in: : No. The similarity between each historical case and the current structured task description, with a value range of... ;

[0155] Historical Case Index ,in This represents the total number of cases in the historical case library module.

[0156] Binary encoded dimensional index ;

[0157] Total coding dimension, consisting of the number of enumerated causes of disputes. Number of dispute resolution solutions The voucher information name and quantity in the voucher list The sum of them constitutes, that is , ;

[0158] : No. The first historical case in The encoding on the dimension comes from the case records in the historical disassembly case library module, and the value is 0 or 1;

[0159] Structured task description in the first The code on the dimension is generated by enumerating the cause of the dispute, the solution to the dispute, and the list of credentials in the current description, and takes the value of 0 or 1;

[0160] The penalty coefficient is derived from the importance of validity and consistency as specified in the audit rules information. ;

[0161] : The validity flag of the credential information described in the current structured task (meaning the same as formula ②);

[0162] : No. The validity flag for the voucher information in each historical case takes a value of 0 (invalid or not uploaded) or 1 (valid).

[0163] :right From 1 to Summation;

[0164] brackets : Indicates a penalty factor.

[0165] Data source mapping: Extracting the cause of the dispute, the solution to the dispute, and the list of evidence from the structured task description to obtain the encoding vector. The historical case analysis module extracts the causes of disputes, dispute solutions, a list of vouchers, and the validity results of voucher information. and .

[0166] Simple numerical example: The cause of the dispute in historical case c is "buyer did not receive the goods" (1st dimension of the code = 1), the solution is "full refund" (6th dimension = 1), the voucher list includes "logistics voucher" (11th dimension = 1), and the other dimensions are 0; the current description is the same, so the dot product = 1×1 + 1×1 + 1×1 = 3, the modulus is √3≈1.732, and the cosine similarity = 3 / 3 = 1. , The penalty term = 1 - 0.3 × 0 = 1, therefore The output of formula ③ Used to determine whether the similarity meets the conditions ( (When a match is considered successful), and the historical case with the highest similarity is selected.

[0167] Formula ④ uses the predicted results and sub-task sequences from matched historical cases to generate the initial priority weights for the second sub-task sequence. A priority scoring function is defined to integrate the execution priority of historical cases with the time urgency of the current dispute state.

[0168] Formula④

[0169]

[0170] in: : No. The execution priority score of each subtask, with a value range of... The higher the score, the higher the priority.

[0171] Subtask index ;

[0172] Natural exponential function ;

[0173] The first case in history The original priority of each subtask is read from the execution priority field in the historical decomposition case library module, and is usually an integer from 1 to 10;

[0174] The time urgency factor of the current dispute status is derived from the duration of the dispute initiation status in the platform's dispute records. (Unit: hour), Calculation formula ;

[0175] :right From 1 to Summation is used to normalize the denominator;

[0176] : Subtask temporary index, and Synonyms, used to iterate through all subtasks;

[0177] The total number of subtasks in the second subtask sequence. ;

[0178] : No. The original priority of each subtask (and) (same meaning)

[0179] The penalty gain coefficient for supplementary vouchers is derived from the urgency of missing vouchers specified in the audit rules information. ;

[0180] : Indicator function, when the first The value is 1 if the subtask involves submitting credential information and the credential information validity result is "not uploaded", otherwise it is 0.

[0181] parentheses Gain factor;

[0182] Data source mapping: Obtained by extracting subtask sequences and execution priorities from the historical decomposition case library module. The duration of the dispute initiation status is extracted from the platform's dispute records. The validity results of the extracted voucher information from the structured task description are used for calculation. .

[0183] Simple numerical example: Let's define the priority of the task for submitting credential information in historical cases. The dispute lasted for 12 hours. ,molecular Other tasks, such as product parameter verification tasks. ,molecular The summation denominator is approximately 12.18 + 4.48 + ... . If the summation of the 6 tasks is approximately 30, then the maximum soft score is 0.406. Multiplying this by (1 + 0.5 × 1) = 1.5 gives 0.609. (Output of Formula ④) The execution priority of each subtask in the second subtask sequence is written into the subtask sequence and sent to S400. The second subtask sequence and its priority output in this section are directly used as input to "information prediction and proposed response association" in S400.

[0184] Part Three: Continuing from the sub-task sequence (first or second sub-task sequence) and its initial priority obtained in Part Two, the task decomposition module performs compliance verification and reasonableness review. Compliance verification invokes review rule information, matching the tasks for determining the validity of voucher information, querying product purchase data, verifying product parameters, and generating dispute solutions within the sub-task sequence against the review rule information. Tasks that match are marked as compliant; otherwise, they are marked as abnormal and the reason is recorded. Reasonableness review checks the order of the sub-task sequence based on the dispute status, cause of the dispute, dispute solution, and refund record status. To quantify the degree of order conflict and generate optimization suggestions, a conflict degree function based on topological sorting is defined. Formula ⑤ calculates the topological order conflict coefficient of the current sub-task sequence.

[0185] Formula⑤

[0186]

[0187] in: : The order conflict coefficient of the subtask sequence, with a range of values. A larger value indicates a more severe conflict.

[0188] The total number of task pairs that need to be checked for sequence constraints is determined by the predefined sequence rules in the compliance check (e.g., the task of submitting credential information must precede the task of verifying the validity of credential information, a total of 5 rules). ;

[0189] The index of the preceding task in the sequence constraint. This is the task number within the subtask sequence;

[0190] The index of the subsequent task in the sequence constraint requires... Must Previously executed, recorded as ;

[0191] : Indicator function, takes the value 1 if the condition inside the parentheses is true, otherwise takes the value 0;

[0192] :Task The position number in the subtask sequence starts from 1 and increments.

[0193] :Task The position number in the subtask sequence;

[0194] The symbol : represents "task" Must be in the task "Previously executed" comes from the predefined sequence constraint rules in the audit rule information;

[0195] : Regarding item 1 to item 2 Summation is performed using the sequence constraint rules;

[0196] : Average factor, which normalizes the conflict count to .

[0197] Simple numerical example: The subtask sequence is as follows: ① Voucher information validity determination task (position 1), ② Voucher information submission task (position 2). The constraint requires that the voucher information submission task must precede the voucher information validity determination task, i.e. , actual location , ,condition If true, the indicator function = 1. If there are 5 constraints in total, and 2 of them conflict, then... If the conflict coefficient This will trigger the generation of optimization suggestions.

[0198] Formula ⑥ is based on the conflict coefficient Based on the proportion of abnormal tasks in compliance verification, an optimized rescheduling vector is generated to correct the order of subtasks and dynamically adjust their execution priorities.

[0199] Formula⑥

[0200]

[0201] in: : No. The order-corrected weights of each subtask, with a range of values. This is used to reallocate execution priorities (the higher the weight, the earlier the task should be placed).

[0202] Subtask index ( Same as formula ④);

[0203] : Natural exponential function;

[0204] The conflict penalty coefficient is derived from the success rate statistics of conflict resolution in the historical deconstruction case library module. ;

[0205] Formula ⑤ outputs the order conflict coefficient, which has the same meaning as above;

[0206] : No. The task type dependency depth of each subtask is determined by the level that the task should have in the execution chain. For example, the task dependency depth of submitting credential information is 1, the task dependency depth of determining the validity of credential information is 2, the task dependency depth of predicting after-sales request information is 3, and the task dependency depth of generating dispute resolution solutions is 4. Dimensionless integer.

[0207] :right From 1 to Summation is used to normalize the denominator;

[0208] : Subtask temporary index, and Synonyms;

[0209] : No. Depth of dependencies for each subtask;

[0210] The penalty coefficient for abnormal tasks is derived from the abnormal tolerance level in the audit rules information. ;

[0211] : Indicator function, when the first The value is 1 if a subtask is marked as an abnormal task during compliance verification, and 0 otherwise.

[0212] parentheses Factors that reduce the weight of abnormal tasks;

[0213] minus sign Negative numbers within the exponent result in a smaller exponential function value as the conflict increases and the dependency depth increases.

[0214] Data source mapping: obtained from formula ⑤ Input; Dependency depth is extracted from the task types in the subtask sequence. ; obtained from compliance verification results .

[0215] Simple numerical example: Take , Then the exponent term Set up a task to submit voucher information. , ; Task of determining the validity of voucher information , Other tasks are similar. The denominator is the sum of the exponents of each task. If there are 4 tasks, the sum ≈ 0.449 + 0.202 + ... ≈ 1.0. Then the numerator is 0.449. Multiplying this by (1 - 0.8 × 0) = 0.449, we get... If the task is abnormal, multiply by (1-0.8)=0.2, resulting in 0.0898. The output of formula ⑥. The order used to regenerate the subtask sequence is determined by moving tasks with higher correction weights forward and writing them into the new execution priority sequence. If the conflict coefficient... The task decomposition module generates optimization suggestions and re-inputs these suggestions along with the structured task description into the large language model. The large language model then regenerates the subtask sequence, which is then re-entered for compliance verification and rationality review. After completing the above processing, the task decomposition module outputs the final subtask sequence and execution priority, including task type, task object, execution conditions, completion conditions, and task description. The execution priority records the execution order and triggering conditions of each subtask. This subtask sequence and execution priority are sent to S400 as the scheduling source for "after-sales request information prediction, proposed response information association, and prediction result generation and processing" in S400.

[0216] This section summarizes the technical effects: By constructing an attention matching, similarity retrieval, conflict detection, and priority reordering chain using formulas ① to ⑥, the structured task description is transformed into an executable, verifiable, and self-correcting sequence of sub-tasks. This chain achieves dual-path fusion of task templates and historical cases, and embeds review rule information into the task generation process in the form of mathematical constraints, significantly improving the standardization and automation of task decomposition. Compared with general large-scale model task decomposition, this technology, through closed-loop feedback of conflict coefficients and order correction weights, enables the sub-task sequence to be self-consistent in terms of compliance and rationality, avoiding the disordered or illegal task flow generated by pure models.

[0217] S400. Based on the subtask sequence and execution priority, perform information prediction and proposed response association to generate prediction results;

[0218] Specifically, this step is executed by the information prediction system module. The information prediction system module receives the sub-task sequence and execution priority obtained from S300, and reads the after-sales request information, platform dispute records, dispute causes, dispute solutions, credential information, audit rule information, proposed response information, and reason information from the structured task description. When the sub-task sequence includes an after-sales request information prediction task, the information prediction system module initiates after-sales request information prediction processing according to the execution priority. The after-sales request information prediction processing refers to placing the request content, dispute causes, dispute solutions, credential information, and audit rule information from the after-sales request information into the same prediction record, and performing field matching on the prediction record. The field matching includes matching the dispute causes with the after-sales request information, matching the dispute solutions with the credential information, and matching the audit rule information with the credential information.

[0219] Specifically, the proposed response information association is initiated by the information prediction system module when performing the after-sales request information prediction task. The proposed response information originates from the initial processing information and enters the subtask sequence through a structured task description. The proposed response information includes response method information and reason information. After reading the proposed response information, the information prediction system module associates the response method information with the dispute resolution method and the reason information with the dispute cause. If the response method information is agreement to a partial refund, agreement to a full refund, or agreement to a return and refund, the information prediction system module reads the corresponding refund record status. If the response method information is rejection of the after-sales request, the information prediction system module reads the reason information, voucher information, and review rule information, and writes all three into the same prediction record. The prediction record is used for subsequent prediction result generation processing.

[0220] Furthermore, the prediction result generation process is completed by the information prediction system module based on the prediction record. The information prediction system module first reads the validity result of the credential information. If the validity result is valid, the information prediction system module continues to read the proposed response information and the dispute resolution solution. If the validity result is invalid, the information prediction system module writes the review rule information, the reason for invalidity, and the credential information name into the prediction record and generates the corresponding prediction result. If the validity result is not uploaded, the information prediction system module reads the credential information submission task from the subtask sequence and marks the prediction record as credential information to be supplemented. This mark, along with the execution priority, is written into the prediction result.

[0221] Specifically, the predicted results include three types of records: supporting consumer users, supporting merchant users, and unknown. The information prediction system module matches after-sales request information, proposed response information, voucher information, and review rule information. If the after-sales request information, voucher information, and review rule information all correspond to the dispute resolution, the information prediction system module generates a predicted result supporting consumer users. If the proposed response information, reason information, voucher information, and review rule information all correspond to rejecting the after-sales request, the information prediction system module generates a predicted result supporting merchant users. If the validity result of the voucher information is "not uploaded," or if the proposed response information conflicts with the dispute reason, the information prediction system module generates an unknown predicted result. After the predicted result is generated, it is written into the prediction information database and associated with the order number in the platform's dispute records.

[0222] Specifically, the information prediction system module also matches the prediction result with the dispute resolution solution to obtain a matching degree. The matching degree is a record of consistency between the prediction result and the dispute resolution solution. If the prediction result supports the consumer user, and the dispute resolution solution is a partial refund, a full refund, or a return and refund, the information prediction system module records the matching degree as higher than a preset reliability. If the prediction result supports the merchant user, and the dispute resolution solution is a record of refusing the after-sales request, the information prediction system module records the matching degree as higher than a preset reliability. If the prediction result is unknown, or the prediction result is inconsistent with the dispute resolution solution, the information prediction system module records the matching degree as lower than a preset reliability. The matching degree and the prediction result are written together into the prediction information database.

[0223] In one implementation, the subtask sequence sequentially includes a task to determine the validity of credential information, a task to predict after-sales request information, and a task to generate a dispute resolution solution. The execution priority indicates that the task to predict after-sales request information precedes the task to generate a dispute resolution solution. The information prediction system module reads after-sales request information, proposed response information, credential information, and review rule information. If a consumer submits after-sales request information indicating that the buyer has not received the goods, and the credential information validity result is valid, and the merchant's proposed response information is agreement to a full refund, the information prediction system module generates a prediction result supporting the consumer's request and records the matching degree as higher than a preset confidence level. The prediction result is used as input for the dispute resolution solution generation process in step S500.

[0224] In another implementation, the subtask sequence displays that the task of submitting credential information has a higher execution priority than the task of predicting after-sales request information. When the information prediction system module reads that the credential information validity result is "not uploaded," it does not proceed to the prediction record corresponding to the dispute resolution generation task. Instead, it writes the after-sales request information, credential list, proposed response information, and review rule information into the prediction information database and generates an unknown prediction result. The unknown prediction result and the matching degree being lower than the preset confidence level are output together for the S500 to call when generating optimization prompts.

[0225] After the above processing is completed, the prediction result includes the order number, after-sales request information, proposed response information, voucher information, review rule information, dispute resolution method, matching degree, and prediction information database record. The prediction result is sent to S500 by the information prediction system module. Based on the prediction result, S500 generates a dispute resolution method, processes partial refunds, full refunds, and returns / refunds, and obtains the execution status of the adjudication plan. Thus, the prediction result output by S400 becomes the input location of S500.

[0226] Summary of the technical effects of this step: This step converts the subtask sequence and execution priority into a predicted result. After-sales request information, proposed response information, voucher information, and audit rule information are combined into a single predicted record in the information predicted system module. The predicted result and matching degree provide direct input for the S500's dispute resolution generation and processing.

[0227] S500: Generate and execute the corresponding dispute resolution plan based on the prediction result, and obtain the execution status of the adjudication plan;

[0228] Specifically, this step is jointly executed by the dispute resolution generation module and the execution control module. The dispute resolution generation module receives the prediction result obtained from S400 and reads the order number, after-sales request information, proposed response information, voucher information, audit rule information, dispute resolution, matching degree, and prediction information database records from the prediction result. After the prediction result enters this step, the dispute resolution generation module first reads the matching degree. When the matching degree is higher than the preset confidence level, the dispute resolution generation module reads the dispute resolution and generates corresponding processing records based on partial refund, full refund, or return and refund. When the matching degree is lower than the preset confidence level, the dispute resolution generation module reads the prediction result, the voucher information, and the audit rule information, generates an optimization prompt, and sends the optimization prompt to S300 to re-trigger the large language model to generate a new sub-task sequence and execution priority.

[0229] Specifically, the dispute resolution generation process includes resolution reading, resolution matching, and resolution recording. Resolution reading refers to retrieving the dispute resolution corresponding to the order number from the pre-judgment result. Resolution matching refers to matching the dispute resolution with the pre-judgment result. Resolution recording refers to writing the matched dispute resolution into the platform's dispute record. If the pre-judgment result supports the consumer user, and the dispute resolution is a partial refund, full refund, or return refund, the dispute resolution generation module records the dispute resolution as a pending execution resolution. If the pre-judgment result supports the merchant user, and the dispute resolution is consistent with the reason information in the proposed response information, the dispute resolution generation module records the dispute resolution as a pending confirmation resolution. If the pre-judgment result is unknown, the dispute resolution generation module does not execute the partial refund, full refund, or return refund process, and writes the unknown pre-judgment result into the pre-judgment information database record.

[0230] Specifically, the partial refund processing is executed by the execution control module based on the order number, product purchase data, refund record status, and voucher information. The execution control module reads the dispute status from the platform dispute record and the matching degree from the pre-judgment result. When the matching degree is higher than the preset confidence level, and the voucher information matches the review rule information, the execution control module writes the partial refund into the platform dispute record and updates the refund record status to "processing." When the refund record status is already "processing," the execution control module does not generate a duplicate partial refund record and writes the current refund record status into the adjudication scheme execution status. When the validity result of the voucher information is invalid, the execution control module does not execute the partial refund processing and writes the reason for invalidity into the platform dispute record.

[0231] Specifically, the full refund processing is executed by the execution control module based on the order number, after-sales request information, dispute cause, and refund record status. The execution control module reads the supporting consumer user record from the pre-judgment result and the full refund from the dispute resolution solution. If the refund record status is "not initiated," the execution control module generates a full refund processing record and updates the platform dispute record to the adjudication solution execution status. If the refund record status is "processing," the execution control module reads the original refund record status and writes the refund record status into the adjudication solution execution status. If the refund record status is an abnormal record, the execution control module writes the abnormal record into the platform dispute record and sends it to S600 for refund record status check.

[0232] Specifically, the return and refund processing is executed by the execution control module based on the order number, product parameters, voucher information, and review rules. The execution control module reads the product name, specifications, and quantity from the product parameters, and the uploaded evidence and description information from the voucher information. When the product parameters match the voucher information, and the predicted result is consistent with the return and refund, the execution control module writes the return and refund to the platform dispute record and updates the platform dispute record to the adjudication scheme execution status. When the product parameters do not match the voucher information, the execution control module generates an optimization prompt and returns the optimization prompt to S300. After the return and refund processing is completed, the execution control module writes the processing conditions corresponding to the return and refund to the adjudication scheme execution status for S600 to read.

[0233] In one implementation, a consumer submits a after-sales request indicating that the buyer has not received the goods. The S400 outputs a preliminary judgment supporting the consumer, with a full refund as the dispute resolution solution, and a matching degree higher than the preset confidence level. The dispute resolution generation module reads the order number, voucher information, and review rule information. The execution control module reads the refund record status. If the refund record status is "not initiated," the execution control module generates a full refund processing record and updates the platform dispute record to the adjudication solution execution status. Subsequently, the adjudication solution execution status is sent to the S600, which checks the refund record status and updates the platform dispute record.

[0234] In another implementation, a consumer submits after-sales request information that does not match the description, and the dispute resolution is a return and refund. The predicted result output by S400 is unknown, with a matching degree lower than the preset confidence level. The dispute resolution generation module reads the credential information and review rule information to generate optimization suggestions. The optimization suggestions and the predicted result are returned to S300. S300 re-triggers the large language model to generate a new sub-task sequence and execution priority. At this time, the execution control module does not update the platform dispute record to the adjudication solution execution status, but writes the current processing record into the predicted information database.

[0235] After the above processing is completed, the execution status of the adjudication scheme includes the order number, dispute resolution method, partial refund processing record, full refund processing record, return and refund processing record, refund record status, voucher information, audit rule information, and preliminary judgment result. The execution status of the adjudication scheme is sent to S600 by the execution control module. Based on the execution status of the adjudication scheme, S600 performs a refund record status check and updates the platform dispute record to obtain the dispute closure status.

[0236] Summary of the technical effects of this step: This step converts the predicted result into the execution status of the adjudication plan. When the matching degree is higher than the preset confidence level, partial refund, full refund, or return refund enters the execution control module. When the matching degree is lower than the preset confidence level, the optimization prompt returns to S300, causing the subtask sequence and execution priority to be regenerated.

[0237] S600. Based on the execution status of the aforementioned adjudication scheme, perform a refund record status check and platform dispute record update processing to obtain a dispute closure status;

[0238] Specifically, this step is jointly executed by the platform dispute resolution module and the execution control module. The platform dispute resolution module receives the adjudication plan execution status obtained from S500, and reads the order number, dispute resolution solution, partial refund processing record, full refund processing record, return and refund processing record, refund record status, voucher information, audit rule information, and preliminary judgment result from the adjudication plan execution status. After the adjudication plan execution status enters this step, the platform dispute resolution module first reads the current dispute status in the platform dispute record. When the current dispute status is the adjudication plan execution status, the execution control module initiates a refund record status check. When the current dispute status is the dispute closed status, the platform dispute resolution module reads the original dispute closed status and writes the current adjudication plan execution status into the processing record.

[0239] Specifically, the refund record status check refers to the execution control module reading the refund record status from the business information database based on the order number and matching the refund record status with the refund record status in the adjudication scheme execution status. The refund record status includes not initiated, processing, completed, and abnormal records. If the two refund record statuses match, the execution control module writes the refund record status to the platform dispute record. If the two refund record statuses do not match, the execution control module writes the refund record status from the business information database, the refund record status in the adjudication scheme execution status, the order number, and the read time to the platform dispute record and marks the record as an abnormal record. The abnormal record is retained in the platform dispute record and does not enter the dispute closure state.

[0240] Furthermore, when the dispute resolution method is a partial refund, the execution control module reads the partial refund processing record and the refund record status. When the refund record status is "completed," the platform dispute resolution module updates the adjudication status in the platform dispute record to "dispute closed." When the refund record status is "processing," the platform dispute resolution module maintains the adjudication status and records the partial refund processing record. When the refund record status is "not initiated," the execution control module rereads the partial refund processing record and writes "not initiated" into the platform dispute record. When the refund record status is an abnormal record, the platform dispute resolution module retains the adjudication status and writes the abnormal record into the description information of the platform dispute record.

[0241] Specifically, when the dispute resolution method is a full refund, the execution control module reads the full refund processing record and the refund record status. When the refund record status is "completed," the platform dispute resolution module writes the order number, full refund processing record, refund record status, and preliminary judgment result into the platform dispute record and updates the platform dispute record to a "dispute closed" status. When the refund record status is "processing," the execution control module continues to read the refund record status from the business information database and writes the reading result into the adjudication scheme execution status. When the refund record status is an "abnormal record," the platform dispute resolution module does not update it to a "dispute closed" status but writes the abnormal record, voucher information, and audit rule information into the platform dispute record.

[0242] Furthermore, when the dispute resolution method is a return and refund, the execution control module reads the return and refund processing record and the corresponding processing conditions. These processing conditions include product parameter matching, voucher information validity results, refund record status, and uploaded evidence. The execution control module matches the product parameters with the return and refund processing record, matches the voucher information with the review rule information, and reads the refund record status. When the processing conditions are met, the platform dispute resolution module updates the adjudication solution execution status to dispute closed. When the processing conditions are not met, the platform dispute resolution module maintains the adjudication solution execution status and writes the unmet processing conditions into the platform dispute record.

[0243] Specifically, the platform dispute record update process includes status reading, status comparison, status writing, and status lookup. Status reading involves the platform dispute processing module retrieving the dispute initiation status, evidence submission status, DHgate review status, adjudication plan execution status, and dispute closure status from the platform dispute records. Status comparison involves the platform dispute processing module comparing the current dispute status with the adjudication plan execution status. Status writing involves the platform dispute processing module writing the corresponding records of completed partial refunds, full refunds, or return refunds into the platform dispute records. Status lookup involves the execution control module rereading the refund record status from the business information database and writing the lookup results into the platform dispute records. After the status lookup is completed, the platform dispute processing module generates a dispute closure status.

[0244] In one implementation, the dispute resolution status shows a full refund, a predicted result supporting the consumer, a matching degree higher than a preset confidence level, and a refund record status of "processing." The execution control module reads the business information database based on the order number. If the business information database returns a completed refund record status, the platform dispute handling module writes the full refund processing record to the platform dispute record and updates the platform dispute record from the dispute resolution execution status to the dispute closed status. If the business information database returns an abnormal refund record status, the platform dispute handling module writes the abnormal record into the description information and retains the dispute resolution execution status.

[0245] In another implementation, the adjudication scheme execution status displays a dispute resolution of "return and refund." The execution control module reads product parameters, uploaded evidence, voucher information, and review rule information. If the product parameters match the return and refund processing record, the voucher information is valid, the refund record status is completed, and the platform dispute resolution module writes the return and refund processing record into the platform dispute record and generates a dispute closed status. If the uploaded evidence does not match the review rule information, the platform dispute resolution module records the unmet processing conditions and maintains the adjudication scheme execution status.

[0246] After the above processing is completed, the dispute closure status includes the order number, platform dispute record, dispute solution, refund record status, partial refund processing record, full refund processing record, return and refund processing record, voucher information, audit rule information, prediction result, and status review result. The dispute closure status is sent to the S700 by the platform dispute processing module. Based on the dispute closure status, the S700 performs standardized report generation and online iterative optimization processing to obtain new breakdown cases.

[0247] In summary, this step converts the adjudication status to a dispute closed status. Refund record status checks are implemented throughout the partial refund, full refund, and return refund processes. The platform's dispute record update process retains status review results and anomaly records, providing input for generating standardized reports for the S700.

[0248] S700 generates standardized reports and iterates through the database, forming a closed-loop processing mechanism.

[0249] Specifically, this step is jointly executed by the standardized report generation module and the historical case analysis library module. The standardized report generation module receives the dispute closure status obtained in S600 and reads the order number, platform dispute record, dispute solution, refund record status, partial refund processing record, full refund processing record, return and refund processing record, voucher information, audit rule information, preliminary judgment result, and status review result from the dispute closure status. The standardized report generation module also reads the subtask sequence and execution priority output in S300, and reads the matching degree written into the preliminary judgment information library in S400. All of the above data enters the standardized report generation process.

[0250] Specifically, the standardized report records after-sales request information, platform dispute records, a list of credentials, credential information, audit rules information, preliminary judgment results, sub-task sequences, execution priorities, dispute resolution methods, the execution status of adjudication schemes, and the dispute closure status. The standardized report generation module first creates a report record according to the order number, then writes the dispute status, cause of the dispute, dispute resolution method, and description information from the platform dispute record into the report record. Subsequently, the standardized report generation module writes the list of credentials, credential information, and audit rules information into the report record, and associates the validity result of the credential information with the credential information. If the validity result of the credential information is invalid or not uploaded, the standardized report generation module writes the corresponding invalid reason or not uploaded status into the report record.

[0251] Specifically, the standardized report generation module processes the prediction results. The prediction results include three types of records: those supporting consumer users, those supporting merchant users, and unknown. The standardized report generation module writes the prediction results, matching degree, and prediction information database records into the report record. If the matching degree is lower than a preset confidence level, the standardized report generation module reads the optimization hints generated by S500 and writes the optimization hints and the re-triggered large language model processing record into the report record. If the matching degree is higher than the preset confidence level, the standardized report generation module reads the execution status of the adjudication scheme and writes the partial refund processing record, full refund processing record, or return and refund processing record into the report record.

[0252] Specifically, the online iterative optimization process is executed by the historical dismantling case library module. This module receives the standardized report and reads after-sales request information, dispute causes, dispute solutions, a list of vouchers, voucher validity results, preliminary judgment results, sub-task sequences, execution priorities, adjudication plan execution status, and dispute closure status from the report. The historical dismantling case library module assembles the above content into a new dismantling case. The new dismantling case includes historical cases, the standardized report, the sub-task sequence, and execution results. The execution results include the adjudication plan execution status, dispute closure status, refund record status, and status review results.

[0253] Understandably, the online iterative optimization process is automatically triggered after the platform dispute record is updated to a dispute closed state. The historical case analysis module compares the new case analysis with existing historical cases. The comparison includes the cause of the dispute, the solution to the dispute, the list of evidence, the validity result of the evidence information, the prediction result, and the dispute closed status. If the historical case analysis module contains historical cases with the same cause and the same solution to the dispute, the module adds the new case analysis to the same historical case record. If the historical case analysis module does not contain the same record, it creates a new historical case record. This record is available for retrieval and processing by the S300's historical case analysis module.

[0254] Specifically, the online iterative optimization process of the large language model includes reading decomposition records, updating task templates, and writing historical cases. The historical decomposition case library module reads the subtask sequence and execution priority from a new decomposition case and associates them with the dispute closure status in the standardization report. If the subtask sequence in the new decomposition case has passed compliance verification and reasonableness review, and the corresponding platform dispute record has been updated to a dispute closure status, the historical decomposition case library module writes the subtask sequence into the task template update record. If the new decomposition case contains optimization hints, the historical decomposition case library module writes the optimization hints, the validity result of the voucher information, and the prediction result into the historical case. These historical cases are then input into the large language model along with the structured task description in subsequent S300 steps.

[0255] In one implementation, the dispute resolution method corresponding to the dispute closure status is a full refund. The standardized report generation module reads the full refund processing record, the refund record status, the preliminary judgment result, and the status review result. If the refund record status is "completed," the standardized report generation module writes the full refund processing record, voucher information, audit rule information, sub-task sequence, and execution priority into the standardized report. The historical case library module then writes the standardized report into a new case, and writes the buyer not receiving goods, full refund, valid voucher information result, preliminary judgment result supporting consumer users, and dispute closure status into the historical cases.

[0256] In another implementation, the dispute resolution method corresponding to the dispute closure status is a return and refund. The standardized report generation module reads the return and refund processing record, product parameters, uploaded evidence, review rule information, and status lookup results. If the processing conditions corresponding to the return and refund are met, the standardized report generation module writes the return and refund processing record, the validity result of the voucher information, the sub-task sequence, and the execution priority into the standardized report. The historical dismantling case library module writes the standardized report into a new dismantling case. When the same dispute cause and the same dispute resolution method occur subsequently, S300 retrieves the historical case from the historical dismantling case library module and inputs the historical case and the structured task description into the large language model.

[0257] After the above processing is completed, the new dismantling case includes after-sales request information, platform dispute records, a list of vouchers, voucher information, audit rule information, preliminary judgment results, sub-task sequence, execution priority, dispute resolution solution, adjudication plan execution status, dispute closure status, and a standardized report. The new dismantling case is written into the historical dismantling case library module and used as a historical case in the subsequent retrieval process of the historical dismantling case library module in S300. Thus, the output of S700 returns to the input source of S300, forming a closed loop in the platform dispute record processing.

[0258] In summary, this step converts the dispute closure status into a standardized report and a new decomposition case. The standardized report retains the subtask sequence, execution priority, predicted results, and status lookup results. The new decomposition case is written to the historical decomposition case library module for subsequent large language model parsing and retrieval.

[0259] Example 2: Figure 2 This diagram illustrates a structural block diagram of an e-commerce after-sales dispute autonomous handling system based on large-model task decomposition according to an embodiment of the present invention. Figure 2 As shown, the structure may include:

[0260] The information receiving module 01 is used to receive after-sales request information and platform dispute records, read order number, dispute status, dispute cause, dispute solution, product purchase data, product parameters, refund record status, and voucher information, generate initial processing information, and connect to the voucher processing module. Specifically, the information receiving module receives after-sales request information from consumer users and platform dispute records from the platform dispute processing module. The information receiving module associates the after-sales request information and the platform dispute records according to the order number and reads the dispute status, dispute cause, and dispute solution. The information receiving module calls the business information database to read product purchase data, product parameters, refund record status, and voucher information. The voucher information comes from the business information database, the evidence upload area, uploaded evidence, and description information. The information receiving module performs source marking, field comparison, and status registration on the read data to form initial processing information. The initial processing information includes after-sales request information, platform dispute records, order number, dispute status, dispute cause, dispute solution, product purchase data, product parameters, refund record status, and voucher information. The information receiving module provides the initial processing information to the voucher processing module as input for determining the voucher list, calling the audit rule information, and determining the validity of the voucher information.

[0261] The credential processing module 02 is used to receive the initial processing information, perform credential list determination, audit rule information invocation, and credential information validity determination, generate a structured task description, and connect to the task decomposition module. Specifically, the credential processing module receives the initial processing information from the information receiving module and reads after-sales request information, proposed response information, dispute cause, dispute solution, and credential information from the initial processing information. The credential processing module determines the credential list based on the after-sales request information, the proposed response information, the dispute cause, and the dispute solution, and retrieves the credential information corresponding to the credential list from the business information database. If the business information database does not retrieve the credential information, the credential processing module sends the credential list to the consumer user or merchant user and outputs guiding questions to receive supplementary credential information. The credential processing module invokes the audit rule information, matches the credential information with the audit rule information, and generates a credential information validity result. The credential processing module writes the initial processing information, the credential list, the audit rule information, and the credential information validity result into the structured task description. The voucher processing module provides the structured task description to the task decomposition module as input for the large language model parsing, task template matching, and historical decomposition case library retrieval modules.

[0262] The task decomposition module 03 receives the structured task description, performs large language model parsing, task template matching, historical decomposition case library retrieval, compliance verification, and rationality review, generates a sub-task sequence and execution priority, and connects to the information prediction system module. Specifically, the task decomposition module receives the structured task description from the voucher processing module and reads after-sales request information, platform dispute records, voucher list, voucher information, review rule information, voucher information validity results, dispute causes, and dispute solutions. The task decomposition module inputs the structured task description into the large language model to parse it and obtain the task type, task object, execution conditions, and completion conditions. The task decomposition module matches the parsing results with the task template. If the match is successful, it generates a first sub-task sequence. If the match is unsuccessful, the task decomposition module retrieves historical cases from the historical decomposition case library module and inputs the historical cases and the structured task description into the large language model to generate a second sub-task sequence. The task decomposition module calls the review rule information to perform compliance verification and rationality review on the first or second sub-task sequence. The task decomposition module generates a sequence of subtasks and their execution priorities. The subtask sequence includes tasks for predicting after-sales request information, determining a list of vouchers, retrieving voucher information, submitting voucher information, verifying the validity of voucher information, querying product purchase data, verifying product parameters, confirming the status of platform dispute records, generating dispute solutions, updating the execution status of adjudication schemes, and updating the closure status of disputes. The task decomposition module provides the subtask sequence and execution priorities to the information prediction system module as input for predicting after-sales request information, associating proposed response information, and generating prediction results.

[0263] The information prediction system module 04 is used to receive the sub-task sequence and the execution priority, perform after-sales request information prediction, associate proposed response information, and generate prediction results, and connect with the dispute resolution generation module. Specifically, the information prediction system module receives the sub-task sequence and execution priority from the task decomposition module, and reads the after-sales request information prediction task from the sub-task sequence. The information prediction system module retrieves after-sales request information, proposed response information, voucher information, and audit rule information, and associates the response method information and reason information in the proposed response information with the dispute resolution solution and the cause of the dispute, respectively. The information prediction system module reads the validity result of the voucher information according to the execution priority. When the validity result of the voucher information is valid, the information prediction system module generates the prediction result. When the validity result of the voucher information is invalid or not uploaded, the information prediction system module writes the voucher information name, audit rule information, and corresponding status into the prediction information database. The information prediction system module generates the prediction result and matches the prediction result with the dispute resolution solution to obtain the matching degree. The information prediction system module provides the prediction results and the matching degree to the dispute resolution generation module as input objects for dispute resolution generation, partial refund, full refund and return refund processing.

[0264] The dispute resolution generation module 05 receives the predicted results, performs dispute resolution generation, partial refund, full refund, and return refund processing, generates an execution status for the adjudication plan, and connects to the platform's dispute handling module. Specifically, the dispute resolution generation module receives the predicted results from the information prediction system module and reads the order number, voucher information, audit rule information, dispute resolution, matching degree, and prediction information database records. When the matching degree is lower than a preset confidence level, the dispute resolution generation module reads the predicted results, voucher information, and audit rule information, generates an optimization prompt, and returns the optimization prompt to the task decomposition module. When the matching degree is higher than a preset confidence level, the dispute resolution generation module reads the dispute resolution and records partial refund, full refund, or return refund as a pending execution plan. The dispute resolution generation module calls the execution control module to write the partial refund processing record, full refund processing record, or return refund processing record. The dispute resolution generation module generates an execution status for the adjudication plan. The execution status of the adjudication plan includes the order number, dispute resolution method, partial refund processing record, full refund processing record, return and refund processing record, refund record status, voucher information, audit rule information, and preliminary judgment result. The dispute resolution method generation module provides the execution status of the adjudication plan to the platform dispute resolution module as input for refund record status checking and platform dispute record update processing.

[0265] The platform dispute handling module 06 is used to receive the execution status of the adjudication scheme, perform refund record status checks and platform dispute record update processing, generate a dispute closure status, and connect with the standardized report generation module. Specifically, the platform dispute handling module receives the execution status of the adjudication scheme from the dispute solution generation module and reads the order number, dispute solution, partial refund processing record, full refund processing record, return and refund processing record, refund record status, voucher information, audit rule information, and preliminary judgment result. The platform dispute handling module reads the current dispute status in the platform dispute records. When the current dispute status is the adjudication scheme execution status, the platform dispute handling module calls the business information database to read the refund record status and compares it with the refund record status in the adjudication scheme execution status. When the dispute solution is a partial refund or full refund, the platform dispute handling module updates the platform dispute record according to the completed refund record status. When the dispute solution is a return and refund, the platform dispute handling module reads the processing conditions corresponding to the return and refund and matches the product parameters, voucher information, audit rule information, and refund record status. When the processing conditions are met, the platform dispute handling module generates a dispute closure status. The platform dispute resolution module provides the dispute closure status to the standardized report generation module as input for the standardized report generation process.

[0266] The standardized report generation module 07 receives the dispute closure status, performs standardized report generation processing, generates a standardized report, and connects to the historical case library module. Specifically, the standardized report generation module receives the dispute closure status from the platform dispute handling module and reads the order number, platform dispute record, dispute solution, refund record status, partial refund processing record, full refund processing record, return and refund processing record, voucher information, audit rule information, prediction result, and status review result. The standardized report generation module also reads the sub-task sequence and execution priority generated by the task decomposition module and the matching degree written into the prediction information library by the information prediction system module. The standardized report generation module establishes a report record according to the order number and writes after-sales request information, platform dispute record, voucher list, voucher information, audit rule information, prediction result, sub-task sequence, execution priority, dispute solution, adjudication scheme execution status, and dispute closure status into the standardized report. The standardized report generation module provides the standardized report to the historical case library module as input for online iterative optimization processing.

[0267] The historical dismantling case library module 08 receives the standardized report, performs online iterative optimization processing, generates new dismantling cases, and connects to the task dismantling module. Specifically, the historical dismantling case library module receives the standardized report from the standardized report generation module and reads after-sales request information, platform dispute records, voucher list, voucher information, audit rule information, prediction results, sub-task sequence, execution priority, dispute resolution solution, adjudication scheme execution status, and dispute closure status. The historical dismantling case library module assembles the standardized report, the sub-task sequence, the execution priority, and the execution results into a new dismantling case. The execution results include the adjudication scheme execution status, dispute closure status, refund record status, and status review results. The historical dismantling case library module compares the new dismantling case with existing historical cases and establishes historical case records according to the dispute cause, dispute resolution solution, voucher list, voucher information validity results, prediction results, and dispute closure status. The historical dismantling case library module provides the new dismantling case to the task dismantling module. The task decomposition module calls the new decomposition case in the subsequent historical decomposition case library module retrieval, and enters the large language model parsing together with the structured task description.

Claims

1. A method for autonomous handling of e-commerce after-sales disputes based on large-scale model task decomposition, characterized in that, include: S100: Receive after-sales requests and platform dispute records, associate them by order number and extract dispute status, dispute cause, product data, refund status and voucher information, and generate initial processing information; S200. Based on the initial processing information, match the vouchers according to the cause of the dispute and the solution, call the audit rules to verify the validity of the vouchers, and generate a structured task description; S300. Perform large language model parsing, template matching, and case retrieval on the structured task description, and obtain the sub-task sequence and execution priority after compliance and rationality review; S400. Based on the subtask sequence and execution priority, perform information prediction and proposed response association to generate prediction results; S500: Generate and execute the corresponding dispute resolution plan based on the prediction result, and obtain the execution status of the adjudication plan; S600. Based on the execution status of the aforementioned adjudication scheme, perform a refund record status check and platform dispute record update processing to obtain a dispute closure status; S700 generates standardized reports and iterates through the database, forming a closed-loop processing mechanism.

2. The method according to claim 1, characterized in that, The process of receiving after-sales requests and platform dispute records and associating them by order number includes: Read after-sales request information from the request content submitted by consumer users in the chat interface, after-sales page or platform dispute page; Read the platform dispute records, which include the dispute initiation status, evidence submission status, DHgate review status, adjudication execution status, and dispute closure status. If the after-sales request information contains an order number that matches the order number in the platform's dispute record, then the after-sales request information will be classified into the corresponding platform dispute record. If the after-sales request information does not include an order number, the order number corresponding to the product purchase data will be retrieved from the dispute overview and description information in the platform's dispute record. If there are multiple order numbers in the platform's dispute records, they will be matched according to the product parameters, refund record status, and uploaded evidence in the after-sales request information, and the matched order number will be recorded as the order number field in the initial processing information; Retrieves the dispute initiation status, evidence submission status, DHgate review status, adjudication execution status, and dispute closure status from the platform's dispute records, and records the current valid status as the dispute status field.

3. The method according to claim 2, characterized in that, The process of extracting dispute status, dispute cause, product data, refund status, and supporting documentation to generate initial processing information includes: Retrieves the dispute initiation status, evidence submission status, DHgate review status, adjudication plan execution status, and dispute closure status from the platform's dispute records, and records the current valid status as the dispute status field; The description information in the after-sales request information submitted by the consumer user is compared with the dispute cause field in the dispute record of the platform. If they match, the dispute cause is written into the initial processing information. If they do not match, both are written into the initial processing information. A read request is sent to the business information database based on the order number to read the product purchase data and product parameters. The product purchase data includes consumer user, merchant user, product object, purchase time, transaction amount, order status and service data node. The product parameters include product name, product specifications, product quantity, product parameter verification information and description information corresponding to the product object. First, read the refund record status from the business information database, then read the refund record status associated with the execution status of the adjudication plan from the platform dispute records. If they match, write the initial processing information; if they do not match, write both and the corresponding reading time into the initial processing information. Read the uploaded evidence in the evidence upload area, associate the uploaded evidence with the order number, cause of dispute and dispute solution, and mark the source of the voucher information as business information database voucher information, platform dispute record voucher information or description information voucher information.

4. The method according to claim 1, characterized in that, The process of matching vouchers with the cause of the dispute and the proposed solution, and then applying audit rules to verify the validity of the vouchers, includes: The matching of dispute causes and solutions includes: a list of credentials determined according to the dispute causes and dispute solutions; When the dispute is caused by the buyer not receiving the goods, the logistics voucher, product purchase data, and refund record status will be written into the voucher list; When the cause of the dispute does not match the description, the product parameters, uploaded evidence, and description information will be written into the voucher list; When the dispute resolution is a partial refund, a full refund, or a return and refund, the refund record status, product purchase data, and uploaded evidence will be written into the voucher list; The process of verifying the validity of vouchers by invoking audit rules includes: invoking audit rule information based on the voucher list, wherein the audit rule information includes the matching relationship between voucher information name, voucher information source, voucher information fields, dispute cause, dispute solution, and refund record status; The validity determination process for the voucher information includes matching the order number, product parameters, dispute reasons, dispute solutions, and refund record status. When the voucher information corresponding to the voucher list exists in the business information database, the voucher information is retrieved from the business information database and matched with the audit rule information to obtain the voucher information validity result. The voucher information validity result includes valid, invalid, and not uploaded status. When the validity result of the credential information is "not uploaded", the credential list is sent to the consumer user or merchant user, and a guiding question is output to obtain the supplementary credential information.

5. The method according to claim 4, characterized in that, The process of performing large language model parsing, template matching, and case retrieval, and obtaining the sub-task sequence and execution priority after compliance and reasonableness review, includes: First, read the validity result of the voucher information; only start parsing the large language model if the validity result of the voucher information is valid. Input the after-sales request information, dispute cause, dispute solution, voucher list, audit rule information, and voucher validity result into the big language model. The big language model outputs the task type, task object, execution conditions, completion conditions, and task description. The task type includes after-sales request information prediction task, voucher list determination task, voucher information capture task, voucher information submission task, voucher information validity determination task, product purchase data query task, product parameter verification task, platform dispute record status confirmation task, dispute solution generation task, adjudication solution execution status update task, and dispute closure status update task. The template matching and case retrieval process includes: matching the task type, task object, execution conditions, and completion conditions with the task template; if the match is successful, a first sub-task sequence is generated; if the match is unsuccessful, historical cases are retrieved, and the historical cases and structured task descriptions are input into the large language model to generate a second sub-task sequence. The compliance and reasonableness review includes: calling the review rule information to perform compliance verification on the tasks of determining the validity of voucher information, querying product purchase data, verifying product parameters, and generating dispute solutions in the sub-task sequence; if the match passes, it is marked as a compliant task; if the match fails, it is marked as an abnormal task and the reason for the abnormality is recorded. Check the order of the subtask sequence. If there is a conflict, generate optimization suggestions. Re-input the optimization suggestions and the structured task description into the large language model to regenerate the subtask sequence.

6. The method according to claim 5, characterized in that, The process of predicting information and associating it with proposed responses to generate prediction results includes: The information prediction includes: initiating after-sales request information prediction processing according to execution priority, putting the request content, dispute cause, dispute solution, voucher information and audit rule information in the after-sales request information into the same prediction record, and performing field matching; The proposed response association includes: reading the response method information and reason information from the proposed response information, associating the response method information with the dispute resolution solution, and associating the reason information with the cause of the dispute; If the response information indicates agreement to a partial refund, agreement to a full refund, or agreement to return the goods and receive a refund, then the corresponding refund record status will be retrieved. If the response information is to reject the after-sales request, the reason information, evidence information, and audit rule information will be written into the same pre-judgment record; The generation of the prediction result includes: generating prediction results based on the validity results of the voucher information, the proposed response information, and the dispute resolution, including three types of records: those supporting consumer users, those supporting merchant users, and those unknown; The predicted results are then matched with the dispute resolution solutions to obtain a matching degree, which includes a matching degree higher than the preset confidence level and a matching degree lower than the preset confidence level.

7. The method according to claim 6, characterized in that, The process of generating and executing a corresponding dispute resolution plan based on the predicted results, and obtaining the execution status of the adjudication plan, includes: First, read the matching score. When the matching score is higher than the preset confidence level, generate the corresponding processing record based on partial refund, full refund, or return and refund. When the matching degree is lower than the preset confidence level, an optimization prompt is generated and the subtask sequence generation is retried; The execution of the corresponding dispute resolution plan includes: when the dispute resolution plan is a partial refund and the voucher information matches the review rule information, the partial refund is written into the platform dispute record and the refund record status is updated to "processing"; When the dispute resolution is a full refund and the refund record status is "not initiated", a full refund processing record is generated, and the platform dispute record is updated to the adjudication execution status; When the dispute resolution is a return and refund and the product parameters match the voucher information, the return and refund will be written into the platform's dispute record, and the platform's dispute record will be updated to the status of the adjudication.

8. The method according to claim 7, characterized in that, The process of checking refund record status and updating platform dispute records includes: The refund record status is retrieved from the business information database based on the order number, and then matched with the refund record status in the adjudication plan execution status. If the status of two refund records is the same, then the status of the refund record will be written into the platform's dispute record. If the refund records in the two places are inconsistent, the refund record status in the business information database, the refund record status in the adjudication plan execution status, the order number and the reading time will be written into the platform dispute record and marked as an abnormal record; When the dispute resolution is a partial or full refund and the refund record status is "completed", the execution status of the adjudication in the platform dispute record will be updated to "dispute closed". When the dispute resolution solution is a return and refund and the processing conditions are met, the execution status of the resolution solution will be updated to the dispute closed status. The processing conditions include matching of product parameters, validity results of voucher information, refund record status, and uploaded evidence.

9. The method according to claim 1, characterized in that, The process of generating standardized reports and iterating them into the database to form a closed loop includes: Create a report record based on the order number, write the dispute status, dispute cause, dispute solution and description information from the platform dispute record into the report record, write the voucher list, voucher information and audit rule information into the report record, and write the voucher information validity result with the voucher information; Write the prediction results, matching degree, and prediction information database records into the report record. When the matching degree is lower than the preset reliability, write the optimization prompts and re-triggering large language model processing records into the report record. When the matching degree is higher than the preset reliability, write the processing records in the execution status of the adjudication scheme into the report record. The after-sales request information, dispute causes, dispute solutions, voucher list, voucher validity results, prediction results, sub-task sequence, execution priority, adjudication status, and dispute closure status from the standardized report are assembled into a new deconstructed case. The new case study is compared with existing historical cases. If there are historical cases with the same cause of dispute and the same solution, the new case study is added to the historical case record of the same type. Otherwise, a new historical case record is created.

10. An e-commerce after-sales dispute autonomous handling system based on large model task decomposition, characterized in that, include: The system comprises an information receiving module, a voucher processing module, a task breakdown module, an information prediction system module, a dispute resolution generation module, a platform dispute resolution module, a standardized report generation module, and a historical breakdown case library module; the system is used to implement the method described in any one of the preceding claims.

Images