Transaction processing method for goods, electronic device, and storage medium

Abstract

The application discloses a transaction processing method of a commodity, an electronic device and a storage medium, and relates to the technical field of artificial intelligence. The method comprises the following steps: in response to an abnormal event existing in a transaction behavior of a target commodity, obtaining interaction text data of the target commodity, wherein the interaction text data is used to represent text data associated with the target commodity generated in an interaction process of different users; determining abnormal description information of the abnormal event based on transaction behavior data of the transaction behavior and the interaction text data; interacting with a target client associated with the target commodity based on the abnormal description information, obtaining an event interaction result of the abnormal event; determining an abnormal processing strategy based on the event interaction result and the transaction behavior data, and processing the abnormal event based on the abnormal processing strategy. The application solves the technical problem that the abnormal event processing effect is poor in the related art.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and more specifically, to a method for processing commodity transactions, an electronic device, and a storage medium. Background Technology

[0002] In large-scale transaction scenarios, existing mechanisms rely on manual monitoring, leading to delays in the detection of anomalies and difficulties in attribution. Handling strategies operate in isolation based on static rules, lacking coordination and dynamic adjustment, and there is no follow-up on performance after execution, failing to support secondary decision-making. This disconnect between perception, execution, and feedback makes it difficult to achieve an adaptive closed loop, resulting in poor anomaly handling.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a method for processing commodity transactions, an electronic device, and a storage medium to at least solve the technical problem of poor handling of abnormal events in related technologies.

[0005] According to one aspect of the embodiments of this application, a transaction processing method for goods is provided, comprising: responding to an abnormal event in the transaction behavior of a target goods; acquiring interactive text data of the target goods, wherein the interactive text data is used to represent text data associated with the target goods generated by the interaction process of different users; determining abnormal description information of the abnormal event based on the transaction behavior data and the interactive text data; interacting with a target client associated with the target goods based on the abnormal description information to obtain an event interaction result of the abnormal event; determining an abnormal handling strategy based on the event interaction result and the transaction behavior data, and processing the abnormal event based on the abnormal handling strategy.

[0006] According to another aspect of the embodiments of this application, a transaction processing method for goods is also provided, including: responding to an input instruction applied to an operation interface, displaying interactive text data of a target product on the operation interface, wherein the interactive text data is used to represent text data associated with the target product generated by the interaction process of different users; responding to a processing instruction applied to the operation interface, displaying an exception handling strategy on the operation interface, wherein the exception handling strategy is determined based on event interaction results and transaction behavior data, the event interaction results are determined based on the interaction between the exception description information of the exception event and the target client associated with the target product, and the exception description information is determined based on transaction behavior data and interactive text data of the transaction behavior.

[0007] According to another aspect of the embodiments of this application, a computing device is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

[0008] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory storing an executable program; and a processor connected to the memory via a bus for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

[0009] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0010] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0011] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the methods in various embodiments of this application.

[0012] According to another aspect of the embodiments of this application, a computer program is also provided, which, when executed by a processor, implements the methods of the various embodiments of this application.

[0013] In this embodiment, in response to an abnormal event in the transaction behavior of a target product, interactive text data of the target product is obtained. This interactive text data represents text data associated with the target product generated during the interaction process of different users. Based on the transaction behavior data and interactive text data, abnormal description information of the abnormal event is determined. Based on the abnormal description information, the target client associated with the target product interacts to obtain the event interaction result of abnormal event 8. Based on the event interaction result and transaction behavior data, an abnormality handling strategy is determined, and the abnormal event is processed according to the abnormality handling strategy. By parsing the transaction behavior data and interactive text data, the abnormal description information of the abnormal event is determined, achieving accurate identification and classification of abnormal situations. The abnormal description information drives the target client to interact, obtaining event interaction results reflecting the current state and intent of the interactive object, overcoming the information lag and one-sidedness caused by current reliance on manual or static rules. Combining real-time dynamic interaction results with multi-dimensional transaction behavior data serves as a decision-making basis, enabling adaptive generation and execution of the abnormality handling strategy, completing a fully automated process from problem perception to closed-loop handling, improving the efficiency and accuracy of abnormal event processing, and thus solving the technical problem of poor abnormal event processing in related technologies.

[0014] It is worth noting that the general description above and the detailed description that follow are merely for illustrative purposes and do not constitute a limitation on this application. Attached Figure Description

[0015] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0016] Figure 1 This is a schematic diagram illustrating an application scenario of an abnormal event handling process according to an embodiment of this application;

[0017] Figure 2 This is a flowchart of a product transaction processing method according to an embodiment of this application;

[0018] Figure 3 This is a schematic diagram of an order processing flow according to an embodiment of this application;

[0019] Figure 4 This is a schematic diagram of a negotiated solution according to an embodiment of this application;

[0020] Figure 5 This is a flowchart of a commodity transaction processing method according to an embodiment of this application;

[0021] Figure 6This is a schematic diagram of an abnormal event handling device according to an embodiment of this application;

[0022] Figure 7 This is a schematic diagram of an abnormal event handling device according to an embodiment of this application;

[0023] Figure 8 This is a structural block diagram of a computing device according to an embodiment of this application;

[0024] Figure 9 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0025] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0027] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0028] The technical solution provided in this application is mainly implemented using a deep learning model. Deep learning models can be widely applied in fields such as Natural Language Processing (NLP), computer vision, and speech processing. Specifically, they can be applied to computer vision tasks such as Visual Question Answering (VQA), Image Captioning (IC), and Image Generation, as well as to NLP tasks such as text-based sentiment classification, text summarization, and machine translation. Therefore, the main application scenarios of this application include, but are not limited to, digital assistants, intelligent robots, search, online education, office software, e-commerce, and intelligent design.

[0029] First, some nouns or terms that appear in the description of the embodiments of this application shall be interpreted as follows:

[0030] "Order surge" refers to a scenario where the number of orders for a target product surges within a short period of time, exceeding the normal delivery and fulfillment capacity. Order surge defines the core characteristics of this abnormal event and is used to trigger subsequent anomaly monitoring and handling processes.

[0031] The inspection expert intelligent agent refers to an intelligent agent built on a large model, possessing autonomous perception, planning, decision-making, and execution capabilities. It automates anomaly handling by autonomously deciding and executing negotiation or disposal actions based on service strategies after identifying inspection issues.

[0032] Platform identity intelligent negotiation refers to a mechanism where agents negotiate and communicate with target clients using their platform identities to reach a conclusion. This process aims to obtain event interaction results that reflect the true intent and status of the target product, providing real-time data support for subsequent risk decisions.

[0033] According to an embodiment of this application, a method for processing commodity transactions is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0034] The technical solutions provided in this application can employ deep learning models with relatively large parameter scales, such as large models containing billions or even more model parameters. Here, "large model" is merely an example; this application does not limit the number of model parameters supported by the deep learning model used, aiming to meet actual needs. The deep learning models involved in this application can be artificial intelligence-based language models (LM) or multimodal models (MM).

[0035] Considering the limited computing resources of mobile terminals, the methods described above in this application embodiment can be applied to, for example... Figure 1 The application scenarios shown are not limited to these. Figure 1 This is a schematic diagram illustrating an application scenario of an abnormal event handling process according to an embodiment of this application. Figure 1 In the application scenario shown, the deep learning model is deployed on server 10. Server 10 can connect to one or more client devices 20 via a local area network (LAN), wide area network (WAN), internet connection, or other types of data network. These client devices 20 may include, but are not limited to, smartphones, tablets, laptops, PDAs, personal computers, smart home devices, and in-vehicle devices. Client devices 20 can interact with users through a graphical user interface to invoke the deep learning model, thereby implementing the method provided in this embodiment.

[0036] In this embodiment, the system consisting of a client device and a server can perform the following steps: The client device detects an abnormal event in the transaction behavior of the target product. The server acquires the interactive text data of the target product; based on the transaction behavior data and interactive text data, it determines the abnormal description information of the abnormal event; based on the abnormal description information, it interacts with the target client associated with the target product to obtain the event interaction result of the abnormal event; based on the event interaction result and transaction behavior data, it determines the abnormal handling strategy and processes the abnormal event based on the abnormal handling strategy.

[0037] It should be noted that with the rapid development of high-performance computing units, the methods provided in this application embodiment can also be applied to model-in-the-loop machines in other application scenarios. In one optional embodiment, the model-in-the-loop machine has multiple built-in models. Users can select one model to adjust as needed to obtain their own model. The high-performance computing unit built into the model-in-the-loop machine can then directly call the adjusted model to execute the methods provided in this application embodiment. In another optional embodiment, the deep learning model-in-the-loop machine has a pre-trained model built-in. Therefore, the high-performance computing unit built into the model-in-the-loop machine can directly call this model to execute the methods provided in this application embodiment.

[0038] Furthermore, when users need to train their own models, they can upload their own datasets via the client. These datasets are then sent to the server, allowing the server to adjust the pre-trained model using the dataset to obtain the user's customized model, which can then be deployed to the production environment. To facilitate users' model adjustment needs, the server provides complete adjustment tools, development frameworks, and processes, supporting multiple adjustment strategies. This allows the adjusted model to better adapt to different application domains and achieve a high degree of customization.

[0039] Under the aforementioned operating environment, this application provides the following: Figure 2 The transaction processing method for the goods shown. Figure 2 This is a flowchart of a product transaction processing method according to an embodiment of this application. Figure 2 As shown, the method may include the following steps:

[0040] Step S202: In response to an abnormal event in the transaction behavior of the target product, obtain the interactive text data of the target product.

[0041] Interactive text data is used to represent text data associated with the target product generated during the interaction process of different users.

[0042] The aforementioned target goods refer to commodities, products, services, or resource units that serve as core interactive entities within a digital transaction or service ecosystem. Target goods can be target products.

[0043] In this embodiment, the target product can be a specific Stock Keeping Unit (SKU), store, or service link. This entity is the carrier of order generation, user inquiries, and fulfillment activities. Abnormal states can be identified and data processed for this specific entity to ensure the accuracy of control granularity.

[0044] The aforementioned transaction behavior refers to all quantifiable and recordable data exchange activities and state transitions between users and target products. For example, transaction behavior can encompass sequences of actions such as browsing, clicking, placing orders, making payments, adding to favorites, and adding to cart. Transaction behavior, through numerical indicators such as order quantity, access frequency, and conversion efficiency, reflects the market popularity and user engagement of the target product, serving as the basis for determining abnormal events.

[0045] The aforementioned abnormal events refer to specific states where the transaction behavior indicators of a target product deviate from the normal statistical distribution or preset rule thresholds. Abnormal events can also refer to specific states where the transaction behavior indicators of a target product deviate from the normal statistical distribution or preset rule thresholds, including data mutations, fulfillment delays, or a surge in user feedback. An abnormal event can refer to an "order surge" scenario, where the number of orders for a target product surges within a short period, causing fulfillment pressure to exceed normal processing capacity. This event is triggered by detecting mutations in dimensions such as order growth rate, slope, and absolute quantity, and serves as the starting signal for subsequent automated collaborative processes. In addition, abnormal events also include delivery delays caused by logistics node congestion, warehouse backlogs, or sudden public events, as well as secondary abnormal states such as increased consumer complaint rates and a surge in inquiries resulting from these events. These states can be identified through multi-dimensional feature analysis, ensuring that the model can intervene in a timely manner, achieving a shift from passive response to proactive perception and handling.

[0046] The aforementioned interactive text data refers to unstructured data records containing natural language information generated by different users during their interactions with the target product. Interactive text data includes user discussions and reviews across platforms (such as social media, forums, and e-commerce platforms), as well as chat logs, Q&A sessions, and complaint messages with merchants (sellers). Interactive text data carries users' emotional tendencies, specific problem descriptions, and potential risk signals, helping the system understand the semantic reasons behind abnormal events.

[0047] This application implements a response triggering mechanism. When it is determined that the transaction behavior data for a specific target product meets the abnormal event judgment conditions, the data acquisition interface is automatically invoked to retrieve and capture interactive text data associated with the target product generated by different users on various interaction channels. This step decouples event triggering from multi-source data aggregation, ensuring that semantic data acquisition is completed synchronously at the moment of anomaly identification.

[0048] The above steps establish the data entry point for the anomaly handling process. This embodiment proactively acquires interactive text data in response to anomaly events, establishing a data link from behavioral anomalies to semantic attribution. Instead of passively waiting for manual reporting, it instantly retrieves relevant text feedback based on real-time monitored behavioral mutations, providing rich contextual information for subsequent intelligent analysis and enabling multi-dimensional data support for anomaly cause localization.

[0049] For example, in a specific application scenario, when order trend analysis (using three-dimensional features: standard deviation, slope, and absolute value) reveals a surge in orders for a product shortly after a live stream, classifying it as an "order explosion" anomaly, a large amount of recent user inquiries and complaints about the product can be retrieved from multiple data sources, such as buyer and seller voice chats, order reviews, user voice messages, and user comments on the platform. For instance, this could identify numerous text records of users asking "when will it ship?" or expressing "anxiety about waiting." This interactive text data is then fed into a natural language processing module for cluster analysis to qualitatively determine the specific cause of the anomaly, such as distinguishing between "live stream surge," "event surge," or "logistics backlog," thereby generating more accurate anomaly descriptions.

[0050] This application embodiment obtains the interactive text data of the target product in response to an abnormal event in the transaction behavior of the target product, realizing the synchronous linkage of abnormal event perception and multi-dimensional data collection. This step automatically associates and obtains text information reflecting the user's true needs and emotional state the moment the abnormal behavior is identified, breaking the traditional separation between behavioral and semantic data in anomaly detection and improving the timeliness and accuracy of anomaly handling.

[0051] Step S204: Based on the transaction behavior data and interaction text data, determine the abnormal description information of the abnormal event.

[0052] The transaction behavior data mentioned above refers to a set of numerical indicators generated by the interactions between users and target products, recorded through quantitative statistical methods. This data may include information on dimensions such as order volume, visit frequency, conversion rate, order growth rate, time series slope, and absolute values. This transaction behavior reflects the changing trends in the market popularity of the target product and is used to identify abnormal fluctuations such as order surges through algorithms such as standard deviation analysis, providing quantitative evidence for the triggering of abnormal events.

[0053] The aforementioned interactive text data refers to unstructured text records containing natural language information generated by different users during their interactions with the target product. Interactive text data can include cross-platform user discussions and reviews, as well as chat logs, Q&A sessions, and complaint messages with merchants. Interactive text data carries users' emotional tendencies, specific problem descriptions, and potential risk signals, helping the system understand the semantic reasons behind abnormal events and compensating for the shortcomings of numerical behavioral data.

[0054] The aforementioned anomaly description information refers to a comprehensive description that has undergone structured processing and includes the anomaly type, severity, scope, and preliminary attribution. This anomaly description information is an intermediate product generated after fusing and analyzing raw transaction behavior data and interactive text data. It includes qualitative results of the problem, causal classification, and relevant contextual data. The anomaly description information transforms unstructured raw data into machine-readable structured semantics, providing accurate input for subsequent intelligent negotiation and decision-making.

[0055] This application embodiment performs a multi-source data fusion analysis process, which can receive transaction behavior data and interactive text data. First, a statistical model is used to perform trend analysis on the transaction behavior data to identify abnormal fluctuation patterns. Simultaneously, natural language processing technology is used to perform cluster analysis on the interactive text data to extract key semantic features. Subsequently, quantitative features and semantic features are mapped and associated to generate anomaly description information that includes the problem type, cause attribution, and detailed description.

[0056] For example, when a surge in orders for a product is detected, the order growth rate and absolute volume can be analyzed to confirm the presence of order surge characteristics. Simultaneously, user inquiries and complaints related to the product can be obtained from different data sources. Through cluster analysis, frequently occurring keywords in the text can be identified. This semantic information can be correlated with behavioral data to determine the cause of the anomaly as "warehouse backlog" due to "livestream surge," generating structured anomaly description information, such as: {Problem: Order surge, Cause: Livestream surge, Status: Warehouse backlog, Number of orders involved: 300,000+}. This description information is then passed to the inspection expert agent to guide the formulation of subsequent negotiation strategies.

[0057] This application's embodiments determine the anomaly description information of abnormal events by using transaction behavior data and interactive text data based on transaction behavior, achieving deep fusion and semantic transformation of multimodal data. This step can accurately locate the cause and nature of abnormal events, providing a high-confidence decision-making basis for subsequent automated negotiation and handling, and improving the intelligence level and response efficiency of anomaly handling.

[0058] Step S206: Based on the abnormal description information, interact with the target client associated with the target product to obtain the event interaction result of the abnormal event.

[0059] The aforementioned anomaly description information refers to a comprehensive description that has undergone structured processing and includes anomaly type, severity, scope, and preliminary attribution.

[0060] This anomaly description information is an intermediate product generated after fusing and analyzing raw transaction behavior data and interactive text data. It may include qualitative results of the problem (such as identifying keywords like "order surge," "order spike," and "warehouse backlog"), causal classifications (such as livestream surge, event surge, express warehouse backlog, and others), and relevant contextual data. The anomaly description information transforms unstructured raw data into machine-readable structured semantics, providing accurate input for subsequent intelligent negotiation and decision-making.

[0061] The aforementioned target client refers to a user terminal device or software application interface associated with the target product, used to receive instructions or feedback information. In this embodiment, the target client mainly refers to the merchant's operating interface, mobile application, or management backend. A two-way communication channel can be established with the merchant (the operator of the target product) by sending structured data or interactive cards to the target client, enabling real-time information transmission and the acquisition of negotiation results.

[0062] The aforementioned event interaction results refer to feedback data obtained through interaction with the target client, reflecting the current status, fulfillment capability, or willingness to handle the issue of the target product. Event interaction results include the merchant's confirmation response to the anomaly, negotiated solutions (such as estimated delivery time and subsequent available quantities), fulfillment commitments, or reasons for refusal. Event interaction results not only contain natural language responses in text format but also structured fields extracted after parsing (such as fields like "available for subsequent delivery," "unable to ship," and "no response after timeout"), serving as a crucial basis for subsequent risk decision-making.

[0063] This application embodiment can execute an automated negotiation process. First, it parses the anomaly description information to extract key negotiation elements (such as anomaly type, order volume involved, and potential risks). Then, based on a preset negotiation strategy, it generates structured interaction instructions or interaction cards and sends them to the target client associated with the target product. It can continuously monitor the target client's feedback channel, receiving natural language text or structured selections returned by the merchant. Next, it can use natural language processing technology to parse the merchant's response, extract key intents and commitments, and finally generate standardized event interaction results, storing them in the system state pool.

[0064] This application embodiment achieves real-time dynamic information acquisition and two-way communication during the exception handling process by interacting with the target client associated with the target product based on the exception description information. This step can accurately grasp the true performance status of the target product and the merchant's intentions before the final disposal, providing highly timely and accurate data support for subsequent risk decisions based on multi-dimensional features, thereby improving the accuracy of exception handling and merchant satisfaction.

[0065] For example, suppose the system has determined that a product has experienced a surge in orders due to a "live stream surge" (abnormal description information). During step S206, a negotiation card can be pushed to the merchant management backend (target client), displaying: "We have detected a surge in orders for your product [Product ID] within [time period], and the current abnormal type is 'surge in orders.' When do you expect to complete the shipment? Do you support delayed shipment?" The merchant replies on the client: "The warehouse is working hard to pack the goods, and it is expected to be shipped within 48 hours. Delay is supported." This reply can be received and parsed through a large model to extract the structured result: {Negotiation Conclusion: Shipment is possible, estimated shipping time: 48 hours, Delay supported: Yes}. This result is the event interaction result, which will then be combined with the current pickup rate data to proceed to the next step of the risk decision-making process.

[0066] Step S208: Based on the event interaction results and transaction behavior data, determine the anomaly handling strategy, and handle the abnormal events based on the anomaly handling strategy.

[0067] The aforementioned exception handling strategy refers to an operational plan formulated for specific abnormal events, including specific handling actions and execution parameters. This strategy is autonomously planned and generated by the large model based on service strategies (rules and logic injected into the context) and event interaction results and transaction behavior data. The exception handling strategy includes a risk level determination (high, medium, low) and a corresponding set of actions (such as proactive compensation, product removal, conversion to pre-sale, sending notifications, and closing work orders). The exception handling strategy transforms abstract decision-making logic into a sequence of executable instructions, ensuring the targeted nature of the handling actions.

[0068] This application's embodiment implements an intelligent decision-making and automated execution process. First, it can receive event interaction results and transaction behavior data, and integrate them with the state memory maintained by a large model. Then, it can invoke the large model, inputting instructions containing service strategies, event interaction results, transaction behavior data, and risk assessment logic, allowing the large model to autonomously plan and generate anomaly handling strategies, and output structured data including problem type, recommended actions, and risk level. Finally, it can parse the anomaly handling strategy, invoke the underlying capability framework to execute corresponding actions, such as initiating compensation, modifying product status, or sending notifications, and update the anomaly event's status record, completing the closed loop.

[0069] This application's embodiments introduce a large model as the decision-making brain, dynamically generating anomaly handling strategies based on multi-dimensional real-time data (merchant's negotiated commitments and actual performance progress). This application does not rely solely on a single threshold trigger, but comprehensively assesses risk levels and autonomously plans a combined set of handling solutions. This process achieves dynamic adaptability and intelligence in the handling logic, ensuring a high degree of matching between the handling actions and the current anomaly scenario, thus improving the accuracy and efficiency of the handling process.

[0070] This application embodiment determines anomaly handling strategies based on event interaction results and transaction behavior data, and processes abnormal events based on these strategies, achieving intelligent and automated anomaly handling decision-making. This step comprehensively considers the merchant's negotiation feedback and actual performance progress, dynamically generating risk management solutions adapted to the current scenario. It achieves end-to-end automation from problem discovery to closed-loop handling, effectively reducing the cost of manual intervention and improving the timeliness and accuracy of anomaly handling.

[0071] For example, suppose the negotiation results for a product experiencing a surge in orders have been obtained: the merchant replied "expected delivery within 48 hours," and the current pickup rate is monitored at 0.6 (below the 0.8 threshold), but the resolution rate is only 0.4. During step S208, the large model analysis concludes that although the merchant has made a commitment, the actual fulfillment progress is severely lagging, posing a high risk of default. The model generates an exception handling strategy based on the established policy. It then calls the interface to proactively compensate the orders related to the product and sends a notification to operations personnel, informing them of the current risk and the compensation measures already taken. Simultaneously, it establishes a monitoring task for the subsequent delivery time of the Service Level Agreement (SLA). If the merchant fails to fulfill the contract on time, the process will be triggered again, executing more forceful actions such as removing the product from the platform.

[0072] The transaction processing method for goods proposed in this application is applicable to logistics fulfillment anomaly management scenarios in high-concurrency, high-time-sensitivity digital transaction service platforms. This scenario primarily addresses situations where order volume surges beyond a merchant's normal delivery and fulfillment capacity within a short period. In related technologies, anomaly detection heavily relies on manual inventory checks or proactive reporting by merchants, resulting in a 24-48 hour lag in anomaly identification. Furthermore, the various handling strategies are isolated, failing to form an effective management loop. This application's embodiment deeply integrates the core steps of the independent claims with this specific application scenario, constructing a fully automated closed-loop system for perception, attribution, negotiation, and handling, thereby solving the problems of delayed response and rigid strategies in existing technologies.

[0073] During the anomaly detection phase, the system can respond to abnormal events in transaction behavior related to a specific product link and obtain the interactive text data of that product. This step not only identifies surges in order volume but also performs semantic analysis on the interactive text data in conjunction with specific triggering scenarios such as large-scale live-streaming promotions or logistics backlogs. This feature solves the technical problems of lagging anomaly detection and low accuracy in cause localization in related technologies, achieving a leap from simple numerical monitoring to semantic-based accurate attribution, enabling the platform to identify the anomaly type and cause at an early stage of anomaly occurrence.

[0074] During the intelligent negotiation phase, interaction can be conducted between the target client and the target product based on the anomaly description information to obtain the event interaction results of the anomaly event. This step sends structured negotiation instructions to the merchant through the platform's agent intelligent negotiation mechanism and triggers industry collaboration processes for high-level merchants. Through multi-channel, hierarchical, real-time interaction, the true willingness and time commitment of merchants to fulfill their obligations are obtained.

[0075] During the risk decision-making and handling phase, anomaly handling strategies can be determined by a large model based on event interaction results and transaction behavior data, and these strategies are then used to process abnormal events. Anomaly handling strategies are dynamically generated and include a combination of actions such as proactive compensation, product status restrictions, or conversion to pre-sale. This step is linked to the platform's goal of reducing complaint rates and ensuring a smooth fulfillment experience, achieving a shift from passive response to proactive intervention. Through proactive compensation for order fulfillment and service level agreement timeout monitoring mechanisms, a surge in consumer complaints due to delivery delays is effectively avoided.

[0076] This application's embodiments automate and close the entire anomaly handling process in the anomaly management scenario of a digital transaction platform, significantly improving the timeliness of handling. Through a large-model-driven inspection expert agent, the previously fragmented processes of anomaly discovery, manual verification, strategy execution, and after-sales compensation can be linked into an automated workflow. The problem of insufficient secondary decision-making due to the lack of merchant fulfillment tracking in related technologies is resolved. This application achieves a complete closed loop from order surge detection to fulfillment tracking through service level agreement timeout monitoring and dynamic fulfillment assessment, shortening the anomaly handling cycle from hours to minutes, effectively preventing large-scale consumer complaints.

[0077] This application improves the accuracy of anomaly attribution and the dynamic adaptability of handling strategies, reducing the false positive rate. By integrating transaction behavior data (order trends) with interactive text data (user feedback and merchant responses), this application utilizes a large model for multi-dimensional feature analysis to accurately identify the causes of anomalies. Simultaneously, based on negotiation results and real-time fulfillment data such as pickup and resolution rates, the risk level and handling strategies are dynamically adjusted, ensuring that handling actions are highly matched to the current scenario, thus achieving precision and dynamism in anomaly handling strategies.

[0078] This application's embodiments reduce platform operating costs and enhance the intelligence level of merchant fulfillment management. Through intelligent negotiation between platform agents and industry collaboration mechanisms, routine, zero-manual automated inspections are achieved. Platform operators no longer need to manually check and communicate with each merchant; agents can autonomously handle massive concurrent anomalies. This automation mechanism not only reduces the platform's human resource operating costs but also significantly reduces the cost of integrating new scenarios through standardized service program interface expansion mechanisms. Furthermore, proactive compensation and fulfillment tracking enhance merchants' awareness of fulfilling platform rules.

[0079] Through the above steps, in response to an abnormal event in the transaction behavior of the target product, the system acquires the interactive text data of the target product, which represents the text data associated with the target product generated by the interaction process of different users. Based on the transaction behavior data and interactive text data, the abnormal event's description information is determined. The system then interacts with the target client associated with the target product based on the abnormal description information to obtain the event interaction result of the abnormal event. Based on the event interaction result and transaction behavior data, an anomaly handling strategy is determined, and the abnormal event is processed according to the strategy. By parsing the transaction behavior data and interactive text data to determine the abnormal event's description information, accurate identification and classification of abnormal situations are achieved. The abnormal description information drives the target client to interact, obtaining event interaction results reflecting the current state and intent of the interacting object, overcoming the information lag and one-sidedness caused by current reliance on manual or static rules. Combining real-time dynamic interaction results with multi-dimensional transaction behavior data serves as a decision-making basis, enabling adaptive generation and execution of the anomaly handling strategy. This completes a fully automated process from problem perception to closed-loop handling, improving the efficiency and accuracy of abnormal event processing, and thus solving the technical problem of poor abnormal event handling in related technologies.

[0080] In the above embodiments of this application, the interaction between the target client associated with the target product and the abnormal description information to obtain the event interaction result of the abnormal event includes: sending the abnormal description information to the target client; responding to receiving feedback information from the target client regarding the abnormal description information within a preset time period, determining the event interaction result based on the abnormal description information and the feedback information; and responding to not receiving feedback information from the target client regarding the abnormal description information within the preset time period, determining the event interaction result as an interaction failure.

[0081] The aforementioned preset time period refers to a fixed time interval used to wait for the target client's response and set a timeout threshold after executing the interaction command. For example, the preset time period can be set to two hours or three hours, and can be set according to the actual situation. By setting a preset time period, the negotiation efficiency and the likelihood of the merchant's response can be balanced.

[0082] When sending an exception description to the target client, a timer can be started. If no valid feedback signal is received from the target client within a preset time period, it is considered a timeout. This time threshold is set based on the standard requirements of the platform's Service Level Agreement (SLA) to ensure that the exception handling process is time-constrained.

[0083] The aforementioned feedback information refers to the digital data proactively returned by the target client to the system in response to interactive instructions sent by the system, containing merchant intent or status updates. Feedback information can be structured card selection data (such as clicking "Confirm delivery available later") or unstructured natural language text (such as the merchant's entered reply). This information can be parsed to extract key semantic entities and transformed into standardized event interaction results. If such information is not received, the default status determination logic is triggered.

[0084] The aforementioned anomaly description information refers to a comprehensive structured data unit generated after multi-source data fusion analysis, describing the abnormal state, cause, and scope of impact of the target product. This anomaly description information includes problem characterization (e.g., order surge), cause attribution (e.g., livestream surge, logistics backlog), scope of impact (e.g., order volume), and preliminary risk assessment. As the core content of the interaction command, the anomaly description information is sent to the target client, aiming to clearly convey the abnormal situation and matters requiring confirmation to the merchant, and is the prerequisite for triggering merchant feedback.

[0085] This application embodiment executes an asynchronous interaction and timeout determination process. First, the generated exception description information is parsed to construct a structured interaction instruction containing exception details and negotiation queries, and this instruction is sent to the target client associated with the target product. Then, a preset time period timer is started to continuously monitor the feedback channel. If feedback information returned by the target client is successfully received and parsed within the preset time period, an event interaction result containing a negotiation conclusion or performance commitment can be generated based on the content of the feedback information and the context of the exception description information. If no valid feedback information is received by the end of the preset time period, the interaction status is automatically determined, an event interaction result indicating interaction failure is generated, and this result is recorded in the system state pool for subsequent decision-making modules to call.

[0086] The above steps implement an asynchronous synchronization mechanism and fault tolerance handling between platform autonomous perception and human feedback. This embodiment of the application achieves non-blocking intelligent negotiation by introducing a preset time period and timeout judgment logic. The system no longer passively waits but sets clear time boundaries. When feedback information is received, it can accurately extract the merchant's intention; when no feedback information is received, it can automatically mark the scenario as "interaction failed," thereby triggering a preset risk mitigation strategy. This mechanism ensures the continuity and automation of the exception handling process, avoiding interruptions to the entire process due to a single unresponsive link.

[0087] For example, in a specific application scenario, once it is determined that a product has experienced a surge in orders due to "livestream traffic" and an anomaly description is generated, the initialization process is executed. A structured card containing a query for "estimated shipping time" can be sent to the merchant's management backend (target client), and a two-hour Service Level Agreement (SLA) timer is started simultaneously. If the merchant replies "estimated to ship in 48 hours" within 1.5 hours, the feedback information is parsed, and the event interaction result is generated as "shippable later, time 48 hours". If the merchant does not take any action within two hours, the timer expires, automatically determining that no feedback was received, and the event interaction result is directly generated as "interaction failed". Subsequently, the system inputs this "interaction failed" result as a high-risk factor into the large model, triggering the corresponding risk decision-making process (such as directly executing proactive compensation or removing the product from the platform), ensuring that the anomaly is handled in a timely manner.

[0088] This application embodiment achieves automated closed-loop and fault-tolerant handling of the abnormal negotiation process by interacting with the target client based on abnormal description information and determining the event interaction result according to the feedback received within a preset time period. This step enables the system to automatically obtain the merchant's willingness to fulfill the contract within a set time, or automatically mark the interaction failure status in case of timeout, avoiding manual intervention and process stagnation, and ensuring the continuous operation of the abnormal handling process. Through the automated timeout judgment mechanism, scenarios where merchants are unreachable or refuse to negotiate can be quickly identified, and subsequent risk handling strategies can be triggered in a timely manner, improving the overall efficiency and response speed of abnormal handling and ensuring the stability of the platform's fulfillment service.

[0089] For example, assuming a product has been identified as having an anomaly due to "warehouse backlog," an anomaly description is generated and sent to the merchant's client. A two-hour timer can be started simultaneously. If the merchant replies via the client within one hour that "shipping needs to be delayed by 3 days," the system receives this feedback, parses it, and determines the event interaction result as "delayed by 3 days." If the merchant does not take any action within two hours, after the timer expires, it can be determined that no feedback was received, and the event interaction result is determined as "interaction failed." Subsequently, this "interaction failed" status can be passed to the risk decision module. Based on this high-risk status, the large model automatically generates an anomaly handling strategy including "proactive compensation" and "product removal," and executes the corresponding actions, thereby completing a fully automated process from anomaly detection to handling.

[0090] In the above embodiments of this application, the target client includes multiple sub-clients. Determining the event interaction result based on the exception description information and feedback information includes: in response to receiving feedback information from any of the multiple sub-clients, determining the event interaction result based on the exception description information and the feedback information from any of the sub-clients; and in response to receiving feedback information from multiple sub-clients, determining the event interaction result based on the exception description information, the data access permissions of the multiple sub-clients, and the feedback information from the multiple sub-clients.

[0091] The aforementioned sub-clients refer to independent client access nodes that belong to the same target product management authority but have different functional modules, role identities, or data access scopes.

[0092] In a multi-tiered management architecture, sub-clients represent different operating entities or system modules, such as daily operation clients for merchants, dedicated management clients for higher-level merchants, or industry collaborative operation clients for the platform. Each sub-client has an independent identity and interaction interface, capable of receiving and responding to exception descriptions sent by the system, and providing feedback on processing results according to its respective permission level.

[0093] The aforementioned data access permissions refer to a set of authorization permissions that are pre-configured or dynamically granted based on the sub-client's identity attributes or role level, for accessing data of a specific scope, specific security level, or specific type.

[0094] Data access permissions determine the dimensions of data that a sub-client can acquire or contribute during interaction. For example, a regular merchant client has the permission to view and reply to its own product data, while a high-level merchant's dedicated client or industry collaboration client has the permission to issue cross-store data, end-to-end logistics data, or emergency response instructions. This differentiated permission configuration ensures the targeted nature and security of information interaction, enabling the system to automatically adjust decision-making weights based on the feedback source.

[0095] This application implements a multi-source feedback aggregation and hierarchical decision-making process. It can send anomaly description information to multiple sub-clients associated with the target product and simultaneously monitor the feedback channels of each sub-client. When feedback information is received from any of the multiple sub-clients, a preliminary event interaction result can be quickly determined based on this single feedback information combined with the anomaly description information, thereby shortening processing latency in typical scenarios. When feedback information is received from multiple sub-clients, a multi-source fusion mechanism can be activated to retrieve data retrieval permissions from each feedback source sub-client. Based on permission levels, multi-source feedback information is weighted or logically validated. By comprehensively considering the anomaly description information and the permission-weighted multi-source feedback information, the final event interaction result is determined, ensuring the accuracy of decision-making in complex scenarios.

[0096] The above steps implement an adaptive interaction strategy based on the diversity of feedback sources. By distinguishing between "single sub-client feedback" and "multiple sub-client feedback," this embodiment constructs a hierarchical response mechanism. In the case of single feedback, an efficiency-first strategy can be adopted, directly utilizing available information to generate results, thus improving response speed. In the case of multiple feedback, data retrieval permissions are introduced as a key reference dimension to fuse multi-source information. Feedback from sub-clients with higher permissions (such as industry collaboration terminals) carries higher weight in decision-making, or the system verifies the consistency of feedback from different sub-clients through permission checks. This mechanism solves the problems of information conflict or unclear weights in scenarios involving multiple roles, achieving accurate determination of interaction results.

[0097] For example, in a specific application scenario, for a high-level merchant experiencing a surge in orders, an anomaly description can be sent simultaneously to both the merchant's daily operations client (first sub-client) and the industry collaboration operations client (second sub-client). If only the merchant's daily operations client replies with "estimated delivery within 48 hours," the event interaction result is directly determined as "delivery is possible later, within 48 hours." If both the merchant's daily operations client and the industry collaboration operations client are received simultaneously ("delivery is expected within 48 hours"), it is determined that the industry collaboration operations client has higher data access permissions (such as access to real-time warehouse capacity data). By combining these two feedbacks with supplementary information from the higher-permission client, a more detailed event interaction result is determined, including the estimated delivery time and resource coordination status, thus providing richer decision-making basis for the large model.

[0098] This application's embodiments differentiate between receiving feedback from a single sub-client and feedback from multiple sub-clients, and introduce data retrieval permissions as the basis for multi-source feedback fusion, achieving adaptive determination of abnormal interaction results. This step enables rapid response in normal scenarios, and in complex multi-role scenarios, it improves the accuracy of event interaction results and the comprehensiveness of decision-making basis through permission-weighted fusion of multi-source information, effectively supporting the subsequent risk decision-making module's accurate judgment in different scenarios.

[0099] For example, suppose a product promoted by a livestreamer experiences a surge in orders, generating an anomaly description message and sending it to the merchant. The merchant's daily operations staff then responds via the regular management backend (first sub-client): "Warehouse full, 3 days required." Simultaneously, because this merchant is a senior-level merchant, a notification is also sent to the industry operations staff (second sub-client, with higher privileges). If the industry operations staff does not respond, the event interaction result can be determined as "Available for delivery later, 3 days." If the industry operations staff responds with "Warehouse coordinated, can be compressed to 48 hours," feedback from both sub-clients can be received. Given that the industry operations client has higher data access privileges, the industry operations feedback can be used as the primary basis, combined with the merchant's original feedback, to determine the final event interaction result as "Available for delivery later, 48 hours, source: industry coordination." This result is directly transmitted to the risk decision module, influencing the subsequent compensation strategy determination.

[0100] In the above embodiments of this application, determining the event interaction result based on the anomaly description information, the data access permissions of multiple sub-clients, and the feedback information of multiple sub-clients includes: responding to different feedback information from multiple sub-clients, determining a target sub-client among the multiple sub-clients based on the data access permissions of the multiple sub-clients, and determining the event interaction result based on the feedback information and anomaly description information of the target sub-client, wherein the data access permissions of the target sub-client are greater than the data access permissions of other sub-clients among the multiple sub-clients excluding the target sub-client; responding to the same feedback information from multiple sub-clients, determining the event interaction result based on the feedback information and anomaly description information of the multiple sub-clients.

[0101] The aforementioned target sub-client refers to a specific client node selected from among multiple participating sub-clients based on preset rules as having higher decision-making weight or a higher data access level.

[0102] The aforementioned target sub-clients are typically access terminals with higher management levels or broader data perspectives, such as industry collaboration operation clients on the platform side or advanced management clients on the merchant side. When there are discrepancies in the feedback from multiple sub-clients, the feedback from the target sub-client is given priority or serves as the primary basis for the final decision, and its data access permissions occupy a higher position in the hierarchical structure.

[0103] This application implements a multi-source decision-making and traffic diversion process based on feedback consistency. First, the consistency of feedback information received from multiple sub-clients is compared. If discrepancies are found in the feedback information from multiple sub-clients, the data retrieval permission level of each sub-client can be retrieved. Based on permission hierarchy rules, a target sub-client with higher data retrieval permissions than all other participating feedback sub-clients is selected, and its feedback information is extracted. This feedback information is then combined with anomaly description information to generate an event interaction result. If the feedback information from multiple sub-clients is found to be consistent, the feedback information from all sub-clients can be integrated and combined with anomaly description information to jointly generate an event interaction result, thereby enhancing decision confidence.

[0104] The above describes an intelligent arbitration and information fusion mechanism for multi-role collaborative scenarios. By distinguishing between "different" and "same" feedback information, this embodiment constructs a dynamic decision weight allocation strategy. In cases of different feedback information, data retrieval permissions can be introduced as an arbitration standard to automatically identify and adopt the opinions of high-permission sub-clients, solving the decision-making problem when multiple sources of information conflict and ensuring that actions comply with higher-level management requirements. In cases of identical feedback information, a consensus mechanism can be adopted to integrate feedback from multiple parties to confirm the reliability of the information, avoiding the risk of false alarms from a single node. This dual judgment logic based on permissions and consistency improves the logical rigor and scenario adaptability of determining event interaction results.

[0105] This application's embodiments dynamically select between decision-making based on a high-privilege sub-client (i.e., the aforementioned target sub-client) or decision-making based on multi-source consensus, based on the differences in feedback information from multiple sub-clients, thus achieving intelligent arbitration and information fusion in complex interaction scenarios. This application can automatically adopt the opinions of the high-privilege subject when information conflicts occur, ensuring that the handling strategy complies with the platform's overall management specifications; when information is consistent, multi-source verification enhances the confidence of the decision, effectively reducing handling deviations caused by false alarms from a single node or insufficient permissions, and improving the accuracy and logical rigor of event interaction result determination.

[0106] In the above embodiments of this application, sending the abnormal description information to the target client includes: obtaining a preset interaction template, wherein the preset interaction template includes at least one placeholder for interaction content to be filled; filling the placeholder for at least one interaction content to be filled in the preset interaction template based on the object information of the target product and the abnormal description information to obtain the target interaction information; and sending the target interaction information to the target client.

[0107] The aforementioned preset interaction template refers to a predefined message or instruction format definition file that contains a fixed structure, text frames, and variable data placeholders.

[0108] Pre-defined interaction templates are used to standardize the format and elements of interactive information between the system and the target client. They define the logical structure of the interactive content, such as titles, body text, queries, and action buttons, and set placeholders for dynamically generated data. Through template-based design, the system can unify the presentation of interactive information, ensuring standardization and readability, while also supporting the rapid generation of personalized interactive content based on different scenarios.

[0109] The placeholders for the interactive content to be filled mentioned above refer to specific markers or variable slots embedded in the preset interactive template, which are used to receive and display dynamically generated specific data values ​​at runtime.

[0110] Placeholders are variable parts of a template, typically identified by specific symbols. During the interaction information generation process, real-time acquired object information or exception description information can be mapped to corresponding placeholders, replacing the placeholder markers and thus generating complete interaction information containing specific project data. The number and type of placeholders are pre-defined according to the needs of the interaction scenario, for example, including fields such as product ID, exception type, and estimated processing time.

[0111] The aforementioned object information refers to a static or semi-static data set describing the basic attributes, status, and historical data of the target product (such as goods, stores, or services). Object information focuses on the inherent characteristics of the target product itself, such as product name, store rating, historical sales volume, and current inventory status. Object information provides context for interactive information, enabling the target client to clearly identify the specific object to which the interaction is directed, thus enhancing the targeting and accuracy of the interactive information.

[0112] The aforementioned target interaction information refers to the final interaction message entity generated after template filling, containing complete dynamic data and a fixed structure, and ready to be sent to the target client.

[0113] The target interaction information is the product of combining a preset interaction template with specific data. It includes a detailed description of the specific abnormal event, the query content, and possible operational guidance. The target interaction information has been formatted and validated to conform to the target client's parsing specifications, and can be directly sent to the target client for display or processing via communication protocols.

[0114] This application embodiment executes a standardized process for generating and sending interactive information. First, a preset interactive template matching the current abnormal scenario can be retrieved. This preset interactive template contains placeholders for at least one piece of interactive content to be filled in, carrying dynamic data. Next, object information of the target product and generated abnormal description information can be extracted. Based on the mapping rules defined in the template, relevant fields from the object information and abnormal description information are filled into the corresponding placeholders in the preset interactive template, thereby generating target interactive information containing a specific context. Finally, the target interactive information can be sent to the target client associated with the target product through a communication interface to trigger subsequent feedback interactions.

[0115] The above steps automate and template the construction of abnormal interaction information. By introducing preset interaction templates and placeholder mechanisms, this application decouples the generation process of interaction information from hard-coded logic, achieving separation of content and structure. This application eliminates the need to write independent message generation code for each abnormal situation; instead, it dynamically fills templates to adapt to different data combinations. This mechanism ensures the uniformity and standardization of the interaction information format, improving the efficiency and maintainability of information generation. Simultaneously, by integrating object information and abnormal description information, the target interaction information can provide rich and accurate context, helping the target client quickly understand the abnormal situation, thereby promoting more effective feedback.

[0116] For example, in a specific application scenario, when a product is determined to have experienced an "order surge" anomaly, a preset "order surge negotiation template" can be retrieved. This template contains the fixed text "An anomaly has been detected in your product [Product Name], the anomaly type is [Anomaly Type], and the estimated order volume affected is [Affected Order Volume]. When do you expect to complete the shipment?" Here, "[Product Name]", "[Anomaly Type]", and "[Affected Order Volume]" are placeholders for the interactive content to be filled in. The product name can be obtained from the target product information as "Outdoor Windbreaker", and the anomaly description information can be obtained as "Livestream Order Surge" and "3000 Orders Affected". These specific data can be filled into the corresponding placeholders to generate the target interactive information: "An anomaly has been detected in your product 'Outdoor Windbreaker', the anomaly type is 'Livestream Order Surge,' and the estimated order volume affected is 3000 orders. When do you expect to complete the shipment?" Subsequently, the generated target interactive information can be sent to the merchant's management backend (target client) in the form of a structured card.

[0117] The embodiments of the present application generate target interaction information by acquiring a preset interaction template and filling placeholders based on the object information and abnormality description information of a target product, thereby realizing automatic generation and standardized presentation of abnormal interaction content. This step enables the system to quickly construct interaction messages containing rich context information, ensures the uniformity of interaction formats and the accuracy of content, reduces the cost of manually compiling interaction information, and improves the understanding efficiency and feedback quality after the target client receives the information.

[0118] In the above embodiments of the present application, determining an abnormality handling strategy based on an event interaction result and transaction behavior data includes: acquiring target service data of the transaction behavior, where the target service data is used to represent service data for the transaction behavior; and determining the abnormality handling strategy based on the event interaction result, the transaction behavior data and the target service data.

[0119] The above-mentioned transaction behavior refers to a recordable and analyzable operation sequence or data stream generated by a user or a system client during the interaction process with the target product. The transaction behavior covers all digital interaction traces in the whole process from abnormality discovery to negotiation and disposal, including but not limited to changes in order transaction trends, emotional tendencies of user comments, content of merchant replies, and click behaviors. These data are the basic materials for evaluating the abnormal state and the merchant's response situation, and provide dynamic time series data support for subsequent strategy formulation.

[0120] The above-mentioned target service data refers to a set of quantitative indicators or state information related to the target product that reflects the service performance status and capability. The target service data specifically characterizes the service performance of the target product within a specific time window, such as the collection rate (the ratio of the number of collected orders to the total number of orders), the resolution rate (the ratio of the number of resolved abnormal orders to the total number of abnormal orders), and the logistics timeliness compliance rate. These data directly reflect the actual performance capability of the merchant or the logistics link, and are a key objective basis for judging the risk level and selecting disposal actions.

[0121] The above-mentioned event interaction result refers to structured data generated after negotiation and interaction with the target client, which is used to describe negotiation conclusions, performance commitments or interaction states. The event interaction result includes the estimated delivery time confirmed by the merchant, the negotiation conclusion (such as available for subsequent delivery, unable to deliver) or the interaction failure state. It is a bridge connecting front-end negotiation and back-end decision-making, and provides information on the merchant's subjective will and commitment.

[0122] The aforementioned anomaly handling strategy refers to a set of action instructions determined based on comprehensive analysis of multi-dimensional data, used for automated or semi-automated handling of abnormal events. An anomaly handling strategy can be a rule package or decision tree containing specific operational logic, defining the measures to be taken under different input conditions, such as proactive compensation, adjusting product status (removing from shelves, switching to pre-sale), completing work orders, or notifying manual intervention. This strategy is autonomously planned and generated by a large model based on input data, aiming to achieve closed-loop handling.

[0123] This application embodiment implements a multi-source data fusion and strategy generation process. First, target service data associated with transaction behavior can be collected and acquired to quantitatively characterize the service fulfillment status of the target product. Subsequently, event interaction results, transaction behavior data, and target service data can be used as input variables and input into the decision model. The decision model performs joint analysis and weight evaluation on these three types of data, comprehensively considering merchant commitments, historical behavior trends, and real-time fulfillment capabilities, thereby determining and outputting corresponding anomaly handling strategies.

[0124] The above steps represent a leap from a single information source to multi-source fusion decision-making. This application's embodiment introduces target service data, combining the merchant's subjective commitment (event interaction results), historical behavioral patterns (transaction behavior data), and objective fulfillment capabilities (target service data). This multi-dimensional weighted decision-making mechanism makes the generation of anomaly handling strategies more comprehensive and objective, enabling more accurate identification of high-risk scenarios and avoiding over- or under-handling.

[0125] For example, in a specific application scenario, regarding an anomaly in order volume for a certain product, the event interaction result might be "the merchant promises delivery within 48 hours," and transaction behavior data shows a recent surge in orders for this product along with an increase in user complaints. Further analysis of the target service data reveals that the product's current pickup rate is 0.5 (low) and resolution rate is 0.7. These three factors can be input into a larger model: the merchant promises delivery, but the pickup rate is low (questionable fulfillment capability), and transaction behavior indicates user anxiety. After comprehensive evaluation, the larger model determines this as high-risk, generating an anomaly handling strategy including: "Implement proactive compensation, with a compensation limit of 50,000 orders, and temporarily remove the product from the platform to control the delivery pace." This strategy directly utilizes the key indicator of low pickup rate in the target service data, correcting a potentially erroneous low-risk judgment based solely on the merchant's promise.

[0126] This application embodiment achieves precise decision-making driven by multi-dimensional data by acquiring target service data and determining anomaly handling strategies based on event interaction results, transaction behavior data, and target service data. This step enables the system to comprehensively consider merchant commitments, behavioral trends, and real-time fulfillment capabilities, effectively improving the accuracy of anomaly risk identification and ensuring a high degree of matching between the anomaly handling strategy and the current scenario, thereby enhancing the pertinence and effectiveness of the handling.

[0127] In the above embodiments of this application, determining anomaly handling strategies based on event interaction results, transaction behavior data, and target service data includes: conducting risk assessments on abnormal events based on event interaction results, transaction behavior data, and target service data to obtain the target risk level of the abnormal event; and determining the anomaly handling strategy corresponding to the target risk level from multiple risk levels, wherein different risk levels correspond to different anomaly handling strategies.

[0128] The aforementioned target risk level refers to a discrete risk status identifier derived from the quantitative classification of the potential harm, probability of failure, or scope of negative impact of an abnormal event based on multidimensional assessment data. The target risk level is typically divided into several levels, such as low risk, medium risk, and high risk. This level is not a fixed value but is dynamically generated, reflecting the severity of the current abnormal event in a specific context. It is a key intermediate variable connecting data assessment and specific handling actions, determining the granularity of the subsequent anomaly handling strategy to be invoked.

[0129] The aforementioned anomaly handling strategies refer to a set of predefined or dynamically generated operational instructions configured for different risk levels to execute closed-loop handling of anomaly events. Anomaly handling strategies may include specific actions and their parameters, such as the maximum amount of proactive compensation, product status change instructions (removal from shelves, conversion to pre-sale), notification recipients and methods, and work order completion conditions. Different risk levels correspond to different strategy combinations; high risk corresponds to strong intervention measures, while low risk corresponds to weak intervention or automatic case closure measures, thereby achieving a match between the intensity of handling and the degree of risk.

[0130] The aforementioned risk assessment refers to the calculation process of using specific algorithms or models to comprehensively analyze multi-source input data to quantify the severity of the potential consequences of abnormal events. In the embodiments of this application, risk assessment is a multi-factor fusion process that can simultaneously consider event interaction results (subjective commitment), transaction behavior data (behavioral trends), and target service data (objective performance capability). Through weighted calculation or logical judgment, the system maps multi-dimensional inputs to a single risk level output, ensuring that the assessment results can comprehensively reflect the true risk situation of the current scenario.

[0131] This application embodiment executes a risk grading and strategy matching process based on multi-dimensional data. First, it receives event interaction results, transaction behavior data, and target service data, and inputs them into the risk assessment module. The risk assessment module performs joint analysis on these three types of data based on preset assessment rules or large-scale model reasoning capabilities, generating a target risk level representing the severity of the abnormal event. Subsequently, it retrieves a pre-configured anomaly handling strategy library, and based on the determined target risk level, performs mapping and matching from multiple risk levels and their corresponding anomaly handling strategies, selecting the anomaly handling strategy consistent with the target risk level as the subsequent handling plan.

[0132] The above steps achieve logical decoupling and precise mapping from data analysis to decision execution. By introducing explicit risk assessment steps, this embodiment transforms complex unstructured data (such as text feedback and behavioral sequences) into structured risk level identifiers. This hierarchical mechanism eliminates the need for the system to write independent processing logic for every subtle data combination, instead simplifying the decision-making path through a "level-strategy" mapping relationship. Simultaneously, the design of different strategies corresponding to different risk levels ensures the gradient and rationality of the response actions, avoiding excessive or insufficient intervention and enhancing the scientific nature of automated decision-making.

[0133] For example, in a specific application scenario, the event interaction result for a certain product might be "the merchant promises subsequent delivery but no specific time," transaction behavior data shows a surge in orders and an increase in user complaints, and target service data shows a pickup rate of 0.5 (below the threshold of 0.8) and a resolution rate of 0.5 (below the threshold of 0.6). The system inputs this data into the risk assessment module and, based on the rule "pickup rate > 0.8 and resolution rate < 0.6 and the negotiated solution is subsequent delivery," determines it as high risk, generating a target risk level of "high risk." Subsequently, the system queries the strategy library to find the exception handling strategy corresponding to "high risk," which includes two actions: "proactive compensation (up to 50,000 orders)" and "product removal." The system ultimately determines this strategy as the handling solution for this exception. If the target service data shows a pickup rate of 0.9, it might be judged as "low risk," and the corresponding strategy might be "complete the work order."

[0134] This application embodiment achieves a target risk level by conducting risk assessment based on event interaction results, transaction behavior data, and target service data, and then determines the corresponding anomaly handling strategy from multiple risk levels, realizing hierarchical management and precise matching of anomaly handling. This step enables the automatic selection of matching handling intensity based on the severity of the anomaly, avoiding resource waste or user experience damage caused by extensive handling, and improving the automation level and decision-making rationality of the anomaly handling process.

[0135] In the above embodiments of this application, obtaining target service data for transaction behavior includes: obtaining current service indicators, historical service indicators, and historical service indicator completion rates for transaction behavior, wherein the current service indicators represent the service indicators for transaction behavior in the current time period, the historical service indicators represent the service indicators for transaction behavior in a historical time period, and the historical service indicator completion rates represent the completion rates of historical service indicators in a historical time period; and determining target service data based on the current service indicators, historical service indicators, and historical service indicator completion rates.

[0136] The aforementioned current service metric refers to a quantitative value reflecting the current fulfillment status or processing progress of a target product, obtained through real-time data collection within a specific time window when an abnormal event occurs. The current service metric is dynamically changing and typically represents real-time service performance data from the moment the abnormality was triggered to the current assessment time. For example, in a scenario of a surge in orders, it could be represented as "the number of orders collected since the surge" or "the real-time collection rate at the current time." This current service metric reflects the target product's immediate responsiveness and actual output in the face of sudden pressure.

[0137] The aforementioned historical service indicators refer to a set of quantitative data accumulated over a historical period to characterize the regular fulfillment capability or service baseline of the target commodity. Historical service indicators are benchmark values ​​derived from long-term or specific historical periods (such as the past 30 days or the past few months), representing the service capability level of the target commodity under normal or past high-load conditions.

[0138] The aforementioned historical service indicator completion rate refers to the proportion or percentage of actual service results achieved within a historical period relative to the preset target or expected service indicator. Historical service indicator completion rate is a ratio or percentage value used to measure the fulfillment of established service commitments or KPIs (Key Performance Indicators) by a target product within a historical period. For example, if the historical target is "98% of orders must be shipped within 24 hours," and the actual completion rate is 95%, then the completion rate is 95%. This indicator reflects the stability and reliability of the target product's fulfillment and is an important dimension for assessing its creditworthiness and potential risks.

[0139] The aforementioned target service data refers to a structured data entity representing the overall fulfillment capability of a target commodity, generated through comprehensive analysis and fusion of current service indicators, historical service indicators, and the completion rate of historical service indicators. Target service data is not single-dimensional raw data, but rather a multi-dimensional feature vector integrating current status, benchmark capability, and historical reputation. By comparing current performance with historical benchmarks and considering the stability of historical fulfillment, a comprehensive assessment of the target commodity's current risk status and service potential is generated. This target service data will serve as the core input for the subsequent risk assessment module, used to determine whether intervention measures are necessary.

[0140] This application embodiment executes a multi-dimensional service data collection and fusion generation process. First, it can acquire current service metrics within the current time window in real time to capture immediate performance dynamics after anomalies occur. Simultaneously, it can retrieve and obtain historical service metrics within historical time periods to establish a baseline for service capabilities and calculate the completion rate of historical service metrics within that historical period to quantify the reliability of historical performance. Subsequently, the current service metrics, historical service metrics, and historical service metric completion rates can be used as input variables and processed through a preset data fusion algorithm or model. This comprehensively considers the difference between real-time performance and historical benchmarks, as well as the stability of historical performance, ultimately generating and outputting the target service data.

[0141] The above steps represent an upgrade from single real-time data to a comprehensive performance profile. This application's embodiment constructs a three-dimensional evaluation system of "current-historical-reputation" by introducing historical service indicators and their completion rates. By comparing current indicators with historical benchmarks, it is possible to identify whether abnormal fluctuations are occasional or trend-based; by incorporating historical completion rates, the performance inertia and credibility of the target product can be assessed. This fusion mechanism makes the generated target service data more comprehensive and robust, providing a more solid data foundation for subsequent risk assessment.

[0142] For example, in a specific application scenario, to address a merchant's abnormal order surge, it's necessary to determine the target service data. First, obtain the current service metrics. Within one hour of the self-inflicted order surge, the merchant has collected 1000 orders, resulting in a current collection rate of 0.5 (1000 / 2000). Second, obtain historical service metrics. The merchant's average daily collection volume over the past 30 days is 5000 orders / day, and the average delivery time during historical promotional periods is 24 hours. Third, obtain historical service metric completion rates. The merchant's target for the "24-hour delivery rate" over the past 90 days is 99%, and the actual completion rate is 95%, meaning the historical service metric completion rate is 95%. Finally, determine the target service data by inputting the current collection rate of 0.5, the historical daily average of 5000 orders, the historical delivery time of 24 hours, and the historical completion rate of 95% into the fusion module. Since the current collection rate (0.5) is far lower than the expected immediate capacity based on historical daily averages, and the historical completion rate (95%) is slightly lower than the target (99%), the generated target service data can be marked as "performance capacity under pressure, with slight deviations in historical performance". This data will be passed to the risk assessment module, affecting the final risk level determination.

[0143] This application's embodiments achieve a multi-dimensional and dynamic assessment of performance capability by acquiring current service metrics, historical service metrics, and historical service metric completion rates, and determining target service data based on these three metrics. This step combines real-time performance, benchmark capabilities, and historical reputation for a comprehensive evaluation, effectively avoiding misjudgments caused by fluctuations in single real-time data, improving the accuracy and representativeness of target service data, and thus providing more reliable data support for subsequent risk assessment and anomaly handling strategy formulation.

[0144] In the above embodiments of this application, the method further includes: obtaining the number of executions of the transaction behavior in the target time period; splitting the number of executions in the target time period to obtain the number of executions in multiple sub-time periods in the target time period; and determining whether there are any abnormal events in the transaction behavior based on the number of executions in the multiple sub-time periods.

[0145] The target time period mentioned above refers to a specific time interval used for statistical analysis of the frequency or quantity of trading activities. The target time period can be a fixed time window (such as the past 1 hour or the past 24 hours) or a dynamically set time range. The selection of this time period aims to capture the concentration of trading activities within a specific period, providing a time benchmark for subsequent judgment of behavioral trends.

[0146] The execution count mentioned above refers to the total number or cumulative value of the target transaction behavior occurring within a specified time frame. The execution count reflects the overall scale of the transaction behavior. In scenarios with a surge in orders, this typically manifests as the total number of orders completed, the total number of customer service inquiries, or the total number of logistics pickups. This value is a fundamental metric for measuring project load, and its absolute value is directly related to the utilization of system resources.

[0147] The aforementioned sub-time periods refer to multiple consecutive or discrete time units with shorter time spans, obtained by further subdividing the target time period. Sub-time periods are used to provide a higher time resolution view of the data. For example, if the target time period is 1 hour, the sub-time periods can be set to 10 minutes or 5 minutes. By analyzing the number of executions within the sub-time periods, local characteristics of data changes can be identified, such as sudden increases, sharp decreases, or fluctuation patterns.

[0148] The aforementioned abnormal events refer to situations where the execution volume or trend of trading behavior deviates from the normal benchmark, potentially indicating potential risks or requiring intervention. Abnormal events are not single data points, but rather conclusions drawn from time series analysis. An abnormal event is identified when the execution volume in a sub-period exhibits a non-linear surge, abnormal volatility, or a significant deviation from the historical baseline. In this application, abnormal events specifically refer to the "order surge" phenomenon that leads to a surge in fulfillment pressure.

[0149] This application implements an anomaly detection process based on time series segmentation. First, the total number of transactions executed within a target time period can be counted and obtained. Then, the target time period can be divided into multiple sub-time periods, and the number of transactions executed in each sub-time period can be calculated, forming a time-segmented data sequence. Finally, this time-segmented data sequence can be analyzed, and by examining statistical indicators such as the distribution characteristics, growth slope, or standard deviation of the number of transactions executed in each sub-time period, it can be determined whether there are any abnormal events deviating from the normal pattern in the transaction behavior.

[0150] This application's embodiments, by introducing a sub-time period segmentation mechanism, can capture the dynamic changes in transaction behavior over time. For example, even if the total number of executions has not reached the historical peak, if there is an exponential increase in the recent sub-time periods, the potential risk of order surges can still be identified. This method based on fine-grained time series analysis improves the sensitivity and timeliness of anomaly detection, enabling earlier intervention in potential risks.

[0151] This application embodiment captures the dynamic trends of transaction behavior by obtaining the execution count of the target time period and breaking it down into multiple sub-time periods for analysis. This step can identify sudden surges or abnormal fluctuations in a short period of time, avoiding missed detections caused by averaging the total volume, thereby improving the timeliness and accuracy of abnormal event detection and gaining valuable time for subsequent automated processing.

[0152] In the above embodiments of this application, determining whether there are abnormal events in a transaction based on the execution quantity of multiple sub-time periods includes: determining the execution quantity growth rate between adjacent sub-time periods and the average execution quantity of multiple sub-time periods based on the execution quantity of multiple sub-time periods; determining the execution quantity deviation of the target product based on the average execution quantity of multiple sub-time periods and the execution quantity of multiple sub-time periods; and determining whether there are abnormal events in the transaction based on the execution quantity growth rate and the execution quantity deviation.

[0153] The aforementioned execution volume growth rate refers to the relative change rate of the number of transactions executed between two adjacent sub-time periods. It is used to characterize the time dynamic trend and instantaneous burst intensity of the data sequence. The execution volume growth rate is calculated by dividing the difference between the execution volume of the subsequent sub-time period and the execution volume of the previous sub-time period by the execution volume of the previous sub-time period. The execution volume growth rate reflects the acceleration or deceleration of trading behavior within a very short time window, and can keenly capture sudden surges or drops in traffic, making it a key parameter for identifying early signals of abnormal fluctuations.

[0154] The aforementioned average execution volume refers to the arithmetic mean of the execution volumes across all sub-time periods within the target time period. It serves as a baseline or normal scale for transaction activity within the statistical period. The average execution volume is obtained by summing the execution volumes across all sub-time periods within the target time period and dividing by the total number of sub-time periods. It eliminates the impact of short-term random fluctuations, providing a stable reference baseline that represents the average fulfillment or interaction capability of the target commodity under normal circumstances. It is the fundamental benchmark for determining whether current data deviates from the norm.

[0155] The aforementioned execution quantity deviation refers to the degree of difference between the execution quantity of a single sub-time period and its mean, used to quantify data fluctuations at a specific point in time relative to the normal level. Execution quantity deviation can be determined by calculating the difference between the execution quantity of a sub-time period and the mean, or the ratio of the difference to the mean (such as the coefficient of variation). This indicator reflects the dispersion and anomalous clustering of data distribution. When the execution quantity of a certain sub-time period is significantly higher than the mean, it indicates a non-random, concentrated clustering of behavior at that moment, which is an important signal of anomalies.

[0156] This application implements a two-dimensional anomaly detection process based on statistical characteristics. First, the execution quantity growth rate between adjacent sub-time periods is calculated to capture the instantaneous trend of transaction behavior. Simultaneously, the average execution quantity for each sub-time period is calculated to establish a behavioral baseline. Next, the deviation of the execution quantity for each sub-time period from the average execution quantity can be calculated to quantify the fluctuation range of local data. Finally, the execution quantity growth rate and execution quantity deviation can be used as input variables, combined with preset judgment logic or models, to comprehensively assess whether abnormal events exist in the transaction behavior. If the growth rate exceeds a threshold or the deviation exceeds a threshold, or if the combination of both meets specific conditions, an anomaly is determined to exist.

[0157] The above steps represent an upgrade in anomaly detection from single-dimensional to multi-dimensional statistical features. This application's embodiments construct a more robust detection mechanism by introducing two complementary indicators: "growth rate" and "deviation." The growth rate focuses on "trend" and "speed," enabling early detection of ongoing surges; the deviation focuses on "amplitude" and "dispersion," identifying anomalies relative to the norm. The combination of these two indicators can capture both sudden outbreaks and persistent high-level anomalies, improving the accuracy and recall of anomaly identification.

[0158] For example, in a specific application scenario, we analyze data for a certain product over the past hour (6 sub-time periods, each 10 minutes). The number of orders in each sub-time period is [10, 12, 11, 100, 200, 300]. The calculated mean is (10+12+11+100+200+300) / 6≈100.5. From the 4th to the 5th period: (200-100) / 100=100% (growth rate 100%). From the 5th to the 6th period: (300-200) / 200=50% (growth rate 50%). The growth rate for the first few periods is close to 0%. Deviation for the 4th period: |100-100.5| / 100.5≈0.5%. Deviation for the 5th period: |200-100.5| / 100.5≈99%. The deviation of segment 6 is approximately 198% (|300-100.5| / 100.5). The growth rates of segments 5 and 6 (100% and 50%) are detected to far exceed the normal fluctuation range (e.g., 20%), and the deviation of segment 6 (198%) is extremely high. Based on these two indicators, it can be determined that the product has experienced an abnormal "order surge" event, triggering the inspection process.

[0159] This application's embodiments determine whether abnormal events exist in transaction behavior based on the execution quantity growth rate and execution quantity deviation, achieving accurate capture of dynamic changes in project traffic. This step can simultaneously focus on the instantaneous burst speed of traffic (growth rate) and the fluctuation range relative to the normal (deviation), effectively reducing the false alarm rate and false negative rate, improving the sensitivity and reliability of abnormal event identification, thereby ensuring that the abnormal handling process can be initiated in a timely and accurate manner.

[0160] This application is built on a pre-defined platform and adopts a three-layer architecture consisting of event-driven, agent workflow, and service provider interface (SPI).

[0161] In the event layer, the event center can register four types of core events: product order surge event, negotiation completion message, expected delivery timeout, and subsequent delivery timeout. Among them, the product order surge event can be detected by the order surge signal captured by the message queue topic. The negotiation completion message can be transmitted to the merchant for feedback or verification conclusion through global message. The expected delivery timeout can be a breach of contract event where the merchant fails to fully fulfill the contract within the initial latest delivery time stipulated by the platform or initially promised. The subsequent delivery timeout can be a secondary breach of contract event where the merchant fails to fulfill the contract within the delayed delivery time that has been re-promised without negotiation or system adjustment.

[0162] The Agent layer orchestrates the entire lifecycle of the intelligent agent based on a general workflow framework. This agent can autonomously plan and make decisions using a large model based on service strategies and multi-dimensional state factors, and manage process execution through standardized interfaces. At the same time, it uses a memory model to uniformly manage state data covering more than 20 dimensions, including product information, merchant information, order details, and negotiation results.

[0163] The capability layer adopts an integrated service operation capability framework, which carries seven major tool functions through the service provider interface. These include a verification tool for performing negotiation and verification of order surges across the entire domain, a timeliness monitoring function for creating tasks in the task center for when orders should be shipped and subsequent available shipping times, an order proactive compensation function that covers the preset order limit, an order removal operation, sending commitment messages, and completing work orders, thereby achieving standardized support for various handling actions.

[0164] Figure 3 This is a schematic diagram of an order processing flow according to an embodiment of this application, such as... Figure 3 As shown, in the offline data warehouse, the source table contains product identifiers, order surge start time, order surge end time, and expected delivery time. The expected delivery time is the later time of the order. Solutions can be provided for order surge events in the source table. Order surge events can be used as an admission condition to create agency work orders. It can determine whether the product has committed to delivery. If so, a message can be sent to enter the negotiation stage. If not, it can directly enter the negotiation stage. During the negotiation process, it can determine whether it is a high-level merchant. If it is a high-level merchant, Platform-Business Negotiation (PB Negotiation) can be conducted to determine whether the timeout is due to inability to deliver or other reasons. If so, industry-wide negotiation is conducted and the negotiation ends. If not, the negotiation ends directly. If it is not a high-level merchant, the negotiation ends directly after the platform-merchant negotiation.

[0165] Figure 4 This is a schematic diagram of a negotiated solution according to an embodiment of this application, such as... Figure 4 As shown, it can listen to negotiation result messages, update the negotiation result work order memory, and also includes logic for locking documents for proactive compensation for delayed delivery. This logic is mainly for identifying products with high order volume, and the related impact range is not included in the admission criteria. Then, it enters the negotiation result judgment stage.

[0166] If the negotiation result indicates that subsequent shipment is possible, the due date for shipment will be increased by one time period (TOC). Then, a timeout assessment will be conducted. If the due date for shipment is less than the subsequent shipment time, the merchant's agreement rate will be assessed to see if it is greater than 60%. If it is, the subsequent shipment time will be increased by one time period (TOC), and the process will proceed to risk decision-making. If it is less than or equal to the subsequent shipment time, the process will proceed directly to risk decision-making. If the due date for shipment is greater than or equal to the subsequent shipment time, the due date for shipment will be increased by one time period (TOC), and after the timeout assessment, the process will proceed directly to risk decision-making. If the negotiation result indicates that subsequent shipment is possible but there is no time, no shipment, or other timeout situations, the due date for shipment will also be increased by one time period (TOC), and after the timeout assessment, the process will proceed directly to risk decision-making.

[0167] Upon entering the risk decision-making stage, if the risk is determined to be high, the process ends after proactively offering compensation, removing the product from the platform, and completing the work order. If the risk is determined to be low, the process ends after completing the work order. The input to this process is the platform's processing result, which is received and used to formulate a decision. Project rules can be divided into three categories: First, the high-risk determination criteria are that there is a valid time available for subsequent delivery and the consensus rate is less than 60% and the fulfillment rate is less than 80%. Second, the second high-risk determination criteria are that there is no valid time available for subsequent delivery and the fulfillment rate is less than 80%. All other situations are determined to be risk-free. The final output of the process is the risk level.

[0168] This application begins with problem identification. Analysis is performed based on three dimensions of order transaction trends: standard deviation, slope, and absolute volume. On average, over forty products with more than 300,000 orders are selected daily. Cluster analysis is then used to qualitatively identify problems by combining chat data from buyer inquiries, merchant feedback, and customer reviews. Keywords such as "order surge," "order spike," and "warehouse backlog" are identified, and the problem is attributed to factors such as livestream surge, promotional surge, warehouse backlog, or other reasons. Next, problem verification is conducted. The intelligent agent automatically triggers the platform's negotiation mechanism and industry collaboration process with the merchant, sending a structured negotiation card to the merchant with a two-hour time limit. For high-level merchants, industry collaboration is triggered simultaneously. Subsequently, a large model is used to analyze the merchant's natural language responses, extracting negotiation conclusions such as whether delivery is possible, impossible, or no response within the time limit, as well as the estimated delivery time. Furthermore, the industry collaboration results take precedence over the platform-merchant negotiation results.

[0169] When making risk decisions, the model can autonomously plan based on multi-dimensional features such as service strategy, negotiation results, acceptance rate and resolution rate. The criteria for high risk are acceptance rate greater than 0.8, resolution rate less than 0.6 and negotiation solution that can be issued later. In this case, proactive compensation and removal of the product are executed. The criteria for low risk are acceptance rate less than 0.8. In this case, the work order is directly closed. The final output is structured data containing problem, action and risk level.

[0170] During the execution of actions, the intelligent agent invokes the integrated service operation capability framework to perform specific actions, including proactive compensation for delayed shipments (covering up to 50,000 orders), delisting of products (with corresponding penalty codes), monitoring service level agreement timeouts for corresponding shipment times and subsequent available shipment times, and notifying specific operations personnel via messages. The service strategy is centered on large-scale model prompts, defining the system role as an inspection expert responsible for planning the next steps for abnormal issues. The task flow is divided into two modules: issue verification and risk decision-making. Issue verification plans actions based on the input status and service strategy verification module; once any verification action is executed, the process terminates and does not proceed to risk decision-making. Risk decision-making is only executed when issue verification logic is not triggered. Based on status information and the service strategy risk decision-making module, it identifies high, medium, and low risks and executes corresponding actions. Process constraints require adherence to the service strategy's planned actions without deviation; executed actions must not be fabricated and must be within the provided capability list. The final output format is structured data containing the issue, action, and risk level.

[0171] This application leverages a large-model-driven intelligent planning agent. Large-model technology can be applied to shipping logistics inspection scenarios to build an intelligent agent with autonomous planning capabilities. By employing a dynamic recall mechanism that injects service strategies into the large-model context using markup language text, operations personnel can directly modify strategies without developer intervention. This technology achieves a shift from traditional rule configuration to intelligent planning, shortening the strategy iteration cycle and improving response efficiency.

[0172] This application enables the integration of general workflows, large-scale model decision-making, and event-driven architecture for a specific platform. This architecture builds a general agent workflow framework on the platform and utilizes an event-driven mechanism to achieve automated orchestration of the entire process. The event center supports the integration of various event types, including product order surge events, negotiation completion messages, and service level agreement timeouts. Through a standardized service provider interface extension mechanism, new scenarios can be quickly integrated simply by implementing the corresponding interface and registering the event. Simultaneously, the underlying capability execution framework is selected as the infrastructure, achieving unified online and offline capabilities and convenient operational configuration.

[0173] This application enables a multi-channel negotiation and closed-loop handling mechanism. This mechanism achieves a closed-loop intelligent negotiation between intelligent agents and merchants. In the platform-merchant negotiation phase, structured negotiation cards are sent, and a large model parses the merchant's natural language responses. In the industry collaboration phase, interactive cards are triggered synchronously for high-level merchants to notify industry operations, forming a tiered negotiation strategy. In the monitoring phase, tasks are automatically created in the task center after negotiation, and service level agreement monitoring points are set for the corresponding delivery time and subsequent available delivery time. In the handling phase, based on the negotiation results and actual performance data, the intelligent agent autonomously decides and executes operations including order retention, proactive compensation, and product removal, achieving closed-loop management of project processing.

[0174] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0175] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, they can also be implemented by hardware. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0176] According to an embodiment of this application, a method for processing commodity transactions is provided. Figure 5 This is a flowchart of a commodity transaction processing method according to an embodiment of this application, such as... Figure 5 As shown, the method may include the following steps:

[0177] Step S502: In response to the input command applied to the operation interface, display the interactive text data of the target product on the operation interface.

[0178] Interactive text data is used to represent text data associated with the target product generated during the interaction process of different users.

[0179] This application embodiment executes a data visualization process in human-computer interaction. It can monitor user actions on the interface in real time, and when an input command for the data display function is detected, the data retrieval module is triggered. Based on the target product identifier associated with the command, the acquired interactive text data is retrieved from the database and formatted and loaded into a preset display area on the interface. Finally, this text content is rendered and displayed for user viewing.

[0180] Step S504: In response to the processing instructions applied to the operation interface, display the exception handling strategy on the operation interface.

[0181] Among them, the exception handling strategy is determined based on the event interaction results and transaction behavior data. The event interaction results are determined by interacting with the target client associated with the target product based on the exception description information of the exception event. The exception description information is determined based on the transaction behavior data and interaction text data of the transaction behavior.

[0182] It can monitor processing commands on the user interface. When a user confirmation or execution command is detected, the strategy generation module is invoked. This module integrates exception description information and event interaction results to construct a complete exception handling strategy. Subsequently, the specific content of the strategy, including suggested actions and their basis, can be rendered and displayed on the user interface for final confirmation or execution by the user.

[0183] Through the above steps, in response to input commands applied to the operation interface, interactive text data of the target product is displayed on the operation interface. This interactive text data represents text data associated with the target product generated during the interaction process of different users. In response to processing commands applied to the operation interface, an exception handling strategy is displayed on the operation interface. This exception handling strategy is determined based on event interaction results and transaction behavior data. The event interaction results are determined based on the interaction between the exception description information from the exception event and the target client associated with the target product. The exception description information is determined based on transaction behavior data and interactive text data. By analyzing transaction behavior data and interactive text data, abnormal event description information is determined, enabling accurate identification and classification of abnormal situations. Based on the abnormal description information, the target client is driven to interact, obtaining event interaction results that reflect the current state and intent of the interactive object, overcoming the information lag and one-sidedness caused by current reliance on manual or static rules. Real-time dynamic interaction results are combined with multi-dimensional transaction behavior data as a basis for decision-making, enabling the adaptive generation and execution of abnormal handling strategies, completing a fully automated process from problem perception to closed-loop handling, improving the efficiency and accuracy of abnormal event handling, and thus solving the technical problem of poor abnormal event handling effect in related technologies.

[0184] According to an embodiment of this application, an abnormal event handling device for implementing the above-described transaction processing method for goods is also provided. Figure 6 This is a schematic diagram of an abnormal event handling device according to an embodiment of this application, such as... Figure 6 As shown, the device 600 includes: an acquisition module 602, a determination module 604, an interaction module 606, and a processing module 608.

[0185] The system comprises the following modules: an acquisition module, which responds to an abnormal event in a transaction involving a target product by acquiring the interactive text data of the target product, wherein the interactive text data represents text data associated with the target product generated during the interaction process of different users; a determination module, which determines the abnormal description information of the abnormal event based on the transaction behavior data and the interactive text data; an interaction module, which interacts with the target client associated with the target product based on the abnormal description information to obtain the event interaction result of the abnormal event; and a processing module, which determines the abnormal handling strategy based on the event interaction result and the transaction behavior data, and processes the abnormal event based on the abnormal handling strategy.

[0186] It should be noted that the acquisition module 602, determination module 604, interaction module 606, and processing module 608 correspond to steps S202 to S208 in the above embodiments. The four modules and their corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in the above embodiments. It should be noted that the above modules or units can be hardware or software components stored in memory and processed by one or more processors. The above modules can also run as part of the device in the server 10 provided in the above embodiments.

[0187] In the above embodiments of this application, the interaction module is used to send the abnormal description information to the target client; in response to receiving feedback information from the target client regarding the abnormal description information within a preset time period, the interaction module determines the event interaction result based on the abnormal description information and the feedback information; in response to not receiving feedback information from the target client regarding the abnormal description information within the preset time period, the interaction module determines the event interaction result as an interaction failure.

[0188] In the above embodiments of this application, the target client includes multiple sub-clients. The determining module is used to determine the event interaction result based on the exception description information and the feedback information of any sub-client in response to receiving feedback information from any of the multiple sub-clients; and to determine the event interaction result based on the exception description information, the data access permissions of the multiple sub-clients, and the feedback information of the multiple sub-clients in response to receiving feedback information from the multiple sub-clients.

[0189] In the above embodiments of this application, the determining module is used to determine the target sub-client among the multiple sub-clients based on the data access permissions of the multiple sub-clients in response to different feedback information from multiple sub-clients, and to determine the event interaction result based on the feedback information and abnormal description information of the target sub-client, wherein the data access permissions of the target sub-client are greater than the data access permissions of the other sub-clients among the multiple sub-clients excluding the target sub-client; and to determine the event interaction result based on the feedback information and abnormal description information of the multiple sub-clients in response to the same feedback information from multiple sub-clients.

[0190] In the above embodiments of this application, the interaction module is used to obtain a preset interaction template, wherein the preset interaction template includes at least one placeholder for interaction content to be filled; based on the object information and abnormal description information of the target product, the at least one placeholder for interaction content to be filled in the preset interaction template is filled to obtain the target interaction information; and the target interaction information is sent to the target client.

[0191] In the above embodiments of this application, the determining module is used to obtain target service data of the transaction behavior, wherein the target service data is used to represent service data for the transaction behavior; and an exception handling strategy is determined based on the event interaction result, the transaction behavior data and the target service data.

[0192] In the above embodiments of this application, the determining module is used to perform risk assessment on abnormal events based on event interaction results, transaction behavior data and target service data, and obtain the target risk level of the abnormal event; and determine the abnormal handling strategy corresponding to the target risk level from multiple risk levels, wherein different risk levels correspond to different abnormal handling strategies.

[0193] In the above embodiments of this application, the determining module is used to obtain the current service indicators, historical service indicators, and historical service indicator completion rate of the transaction behavior. The current service indicators are used to represent the service indicators of the transaction behavior in the current time period, the historical service indicators are used to represent the service indicators of the transaction behavior in the historical time period, and the historical service indicator completion rate is used to represent the completion rate of the historical service indicators in the historical time period. Based on the current service indicators, historical service indicators, and historical service indicator completion rate, the target service data is determined.

[0194] In the above embodiments of this application, the device is further configured to obtain the number of executions of the transaction behavior in a target time period; to break down the number of executions in the target time period to obtain the number of executions in multiple sub-time periods in the target time period; and to determine whether there are any abnormal events in the transaction behavior based on the number of executions in multiple sub-time periods.

[0195] In the above embodiments of this application, the device is further configured to determine the execution quantity growth rate between adjacent sub-time periods and the average execution quantity of multiple sub-time periods based on the execution quantity of multiple sub-time periods; determine the execution quantity deviation of the target product based on the average execution quantity of multiple sub-time periods and the execution quantity of multiple sub-time periods; and determine whether there are abnormal events in the transaction behavior based on the execution quantity growth rate and the execution quantity deviation.

[0196] According to an embodiment of this application, an abnormal event handling device for implementing the above-described transaction processing method for goods is also provided. Figure 7 This is a schematic diagram of an abnormal event handling device according to an embodiment of this application, such as... Figure 7 As shown, the device 700 includes: a first display module 702 and a second display module 704.

[0197] The first display module responds to input commands applied to the operation interface and displays interactive text data of the target product on the operation interface. The interactive text data represents text data associated with the target product generated during the interaction process of different users. The second display module responds to processing commands applied to the operation interface and displays an exception handling strategy on the operation interface. The exception handling strategy is determined based on event interaction results and transaction behavior data. The event interaction results are determined based on the interaction between the exception description information of the exception event and the target client associated with the target product. The exception description information is determined based on transaction behavior data and interactive text data.

[0198] It should be noted that the first display module 702 and the second display module 704 mentioned above correspond to steps S502 to S504 in the above embodiments. The two modules and the corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in the above embodiments. It should be noted that the above modules or units can be hardware components or software components stored in memory and processed by one or more processors. The above modules can also be part of the device and run in the server 10 provided in the above embodiments.

[0199] It should be noted that the preferred embodiments involved in the above embodiments of this application are the same as the solutions, application scenarios and implementation processes provided in the above embodiments, but are not limited to the solutions provided in the above embodiments.

[0200] Embodiments of this application may provide a computing device. Figure 8 This is a structural block diagram of a computing device according to an embodiment of this application. Figure 8 As shown, the computing device 100 may include one or more (only one is shown in the figure) processors 102, memory 104, memory controller, and peripheral interfaces.

[0201] The aforementioned computing device can be understood as an integrated smart terminal, including but not limited to servers, desktop computers, PCs (Personal Computers), all-in-one model machines, etc., and the computing device may have the model described in the above embodiments of this application pre-installed.

[0202] Specifically, this computing device can pre-install various types of models, including but not limited to models in natural language processing, visual processing, speech processing, code processing, and multimodal task processing, thus providing diverse model selection. In different product forms, this computing device can support one or more model usage methods, including but not limited to model training, model invocation, model fine-tuning, model deployment, model inference, and application. In some product forms, this computing device also supports model management, including but not limited to multi-type model management (supporting the management of discriminative, generative, and other model types), model version control (supporting the control of different model versions), and model evaluation (evaluating model performance and effectiveness based on model evaluation tools). In other product forms, this computing device can also create applications based on models, providing API calling capabilities, allowing models to be called into created applications through API interfaces, and providing application management tools to achieve application control.

[0203] Furthermore, the computing device can also include data management (supporting the creation and management of model tuning datasets), a training center (providing abundant training resources to help users learn and master AI technology), and basic control capabilities (providing enterprise-level basic control capabilities to ensure the security and efficient operation of the system). Through the above functions, it provides a comprehensive and integrated device for AI development, training, deployment, and application.

[0204] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the methods in the above embodiments. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to terminal A via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0205] The processor can invoke an executable program stored in memory via a transmission device to execute the method described in any of the above embodiments.

[0206] Embodiments of this application may provide an electronic device. Figure 9 This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 9 As shown, the electronic device may include: an input / output device 112; a memory 114; and a processor 116, wherein the processor 116 is connected to the input / output device 112 and the memory 114 via a bus 118.

[0207] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the methods in the above embodiments. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to terminal A via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0208] The processor can invoke an executable program stored in memory via a transmission device to execute the method described in any of the above embodiments.

[0209] Those skilled in the art will understand that, Figure 9 The structure shown is for illustrative purposes only. The electronic device may also be a smartphone, tablet, PDA, mobile internet device (MID), PAD, or other terminal device. This diagram does not limit the structure of the aforementioned electronic device. For example, the electronic device may include more or fewer components (such as network interfaces, display devices, etc.) than shown in the diagram, or may have a different configuration than shown in the diagram.

[0210] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0211] Embodiments of this application also provide a computer-readable storage medium. Optionally, in this embodiment, the computer-readable storage medium can be used to store program code executed by the method provided in the above embodiments.

[0212] Optionally, in this embodiment, the storage medium may be located in a computing device or an electronic device.

[0213] Optionally, in this embodiment, the computer-readable storage medium is configured to store an executable program, which, when the executable program is running, controls the device where the computer-readable storage medium is located to execute the method described in any of the above embodiments.

[0214] Embodiments of this application also provide a computer program product. Optionally, in this embodiment, the computer program product may include a computer program that, when executed by a processor, implements the methods provided in the embodiments described above.

[0215] Embodiments of this application also provide a computer program product. Optionally, the computer program product may include a non-volatile computer-readable storage medium, which can be used to store a computer program that, when executed by a processor, implements the method provided in the above embodiments.

[0216] Embodiments of this application also provide a computer program. Optionally, in this embodiment, when the computer program is executed by a processor, it implements the method provided in the above embodiments.

[0217] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

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

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

[0220] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0221] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0222] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for processing commodity transactions, characterized in that, include: In response to an abnormal event in the transaction behavior of the target product, the interaction text data of the target product is obtained, wherein the interaction text data is used to represent text data associated with the target product generated by the interaction process of different users; Based on the transaction behavior data and the interaction text data, determine the abnormal description information of the abnormal event; Based on the anomaly description information, the target client associated with the target product interacts with the anomaly event to obtain the event interaction result of the anomaly event; Based on the event interaction results and the transaction behavior data, an anomaly handling strategy is determined, and the abnormal event is handled based on the anomaly handling strategy.

2. The method according to claim 1, characterized in that, Based on the anomaly description information, the target client associated with the target product interacts with the client to obtain the event interaction result of the anomaly event, including: Send the anomaly description information to the target client; In response to receiving feedback information from the target client regarding the anomaly description information within a preset time period, the event interaction result is determined based on the anomaly description information and the feedback information; If no feedback information regarding the abnormal description information is received from the target client within a preset time period, the event interaction result is determined to be an interaction failure.

3. The method according to claim 2, characterized in that, The target client includes multiple sub-clients. Based on the anomaly description information and the feedback information, the event interaction result is determined, including: In response to receiving feedback information from any of the plurality of sub-clients, the event interaction result is determined based on the exception description information and the feedback information from any of the sub-clients; In response to receiving feedback information from the multiple sub-clients, the event interaction result is determined based on the exception description information, the data access permissions of the multiple sub-clients, and the feedback information from the multiple sub-clients.

4. The method according to claim 3, characterized in that, Based on the anomaly description information, the data access permissions of the multiple sub-clients, and the feedback information from the multiple sub-clients, the event interaction result is determined, including: In response to the different feedback information from the multiple sub-clients, a target sub-client is determined among the multiple sub-clients based on the data access permissions of the multiple sub-clients. The event interaction result is determined based on the feedback information of the target sub-client and the abnormal description information, wherein the data access permissions of the target sub-client are greater than the data access permissions of the other sub-clients among the multiple sub-clients excluding the target sub-client. If the feedback information from the multiple sub-clients is the same, the event interaction result is determined based on the feedback information from the multiple sub-clients and the exception description information.

5. The method according to claim 2, characterized in that, Sending the anomaly description information to the target client includes: Obtain a preset interaction template, wherein the preset interaction template includes at least one placeholder for interaction content to be filled in; Based on the object information of the target product and the abnormal description information, the placeholders of at least one interactive content to be filled in the preset interactive template are filled to obtain the target interactive information. The target interaction information is sent to the target client.

6. The method according to any one of claims 1 to 5, characterized in that, Based on the event interaction results and the transaction behavior data, an anomaly handling strategy is determined, including: Obtain the target service data for the transaction behavior, wherein the target service data is used to represent the service data for the transaction behavior; Based on the event interaction results, the transaction behavior data, and the target service data, the exception handling strategy is determined.

7. The method according to claim 6, characterized in that, Based on the event interaction results, the transaction behavior data, and the target service data, the anomaly handling strategy is determined, including: Based on the event interaction results, the transaction behavior data, and the target service data, a risk assessment is performed on the abnormal event to obtain the target risk level of the abnormal event. The anomaly handling strategy corresponding to the target risk level is determined from multiple risk levels, wherein different risk levels correspond to different anomaly handling strategies.

8. The method according to claim 6, characterized in that, Obtaining the target service data for the transaction includes: Obtain the current service metrics, historical service metrics, and historical service metric completion rate of the transaction behavior, wherein the current service metrics are used to represent the service metrics of the transaction behavior in the current time period, the historical service metrics are used to represent the service metrics of the transaction behavior in a historical time period, and the historical service metric completion rate is used to represent the completion rate of the historical service metrics in the historical time period. The target service data is determined based on the current service metrics, the historical service metrics, and the completion rate of the historical service metrics.

9. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Obtain the number of transactions executed within the target time period; The execution count of the target time period is broken down to obtain the execution count of multiple sub-time periods within the target time period; Based on the number of executions in the multiple sub-time periods, it is determined whether the transaction behavior is subject to the abnormal event.

10. The method according to claim 9, characterized in that, Based on the execution count of the multiple sub-time periods, determine whether the transaction behavior exhibits the abnormal event, including: Based on the execution count of the multiple sub-time periods, determine the execution count growth rate between adjacent sub-time periods and the average execution count of the multiple sub-time periods; Based on the average execution quantity of the multiple sub-time periods and the execution quantity of the multiple sub-time periods, the deviation of the execution quantity of the target product is determined; Based on the execution quantity growth rate and the execution quantity deviation, it is determined whether the transaction behavior has the abnormal event.

11. A method for processing commodity transactions, characterized in that, include: In response to input commands applied to the operation interface, interactive text data of the target product is displayed on the operation interface, wherein the interactive text data is used to represent text data associated with the target product generated by the interaction process of different users; In response to processing instructions applied to the operation interface, an exception handling strategy is displayed on the operation interface. The exception handling strategy is determined based on event interaction results and transaction behavior data. The event interaction results are determined based on the interaction between the exception description information of the exception event and the target client associated with the target product. The exception description information is determined based on the transaction behavior data of the transaction behavior and the interaction text data.

12. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor, connected to a memory via a bus, is used to run the program, wherein the program, when running, performs the method according to any one of claims 1 to 11.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the computer-readable storage medium is located to perform the method according to any one of claims 1 to 11.

14. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the method described in any one of claims 1 to 11.

Images