Commodity auditing method and system, electronic equipment, storage medium and program product

Abstract

The invention provides a commodity auditing method and system, electronic equipment, a storage medium and a program product, and relates to the technical field of computers. According to the method, the to-be-audited commodity information is obtained, the corresponding audit capability configuration and the corresponding audit rule configuration are matched, and then conversion from the commodity information to the request parameters is automatically completed by relying on the audit capability configuration, so that manual coding adaptation is not needed; and then, a request is initiated to the auditing algorithm service, the initial result is analyzed based on the auditing rule configuration to obtain the target auditing result, the whole process can take effect quickly without application release, the development manpower input and the iteration period of new auditing rule access and old rule adjustment are greatly reduced, and the business requirement of continuous expansion of commodity categories is efficiently met.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a product review method, system, electronic device, storage medium, and program product. Background Technology

[0002] Against the backdrop of the rapid development of the internet e-commerce industry, product categories are constantly expanding, transaction volumes are continuously increasing, and consumers are demanding higher speeds and quality in product updates. Some e-commerce platforms focusing on core categories such as footwear, apparel, and cosmetics need to achieve rapid product updates and high-quality review processes to consolidate their core business advantages and expand their high-quality supply chains, thus meeting users' needs for a wider range of product choices.

[0003] However, in the early stages of platform development, product listings and reviews primarily relied on manual processes. As the platform expanded, product categories broadened from core categories to more niche areas, resulting in an exponential increase in product volume. The manual review process proved inefficient and unable to handle the massive influx of new products. To overcome this bottleneck, the industry began exploring the introduction of AI capabilities and large-scale modeling technology to build automated AI review processes. By combining algorithmic capabilities with industry-standard review criteria, the review process was upgraded to be intelligent, gradually replacing manual review.

[0004] However, the current AI review process uses traditional hard-coding to implement the core rules. Specifically, whenever a new machine review rule needs to be added or an existing rule needs to be modified, developers must complete a series of fixed and repetitive technical implementation tasks.

[0005] This hard-coded solution could meet basic review needs in the initial stages when the number of rules was small and category coverage was limited. However, as the platform's business continued to expand, its limitations gradually became apparent. On the one hand, the continuous addition of new product categories required the simultaneous addition of a large number of adapted review rules. However, the integration of each new rule and the adjustment of the logic of each old rule required developers to invest in complete coding work, and it could only take effect online after the project schedule was completed and the application was packaged and released. This resulted in a long rule iteration cycle, making it impossible to quickly respond to the urgent needs of the business for review rules, restricting the expansion efficiency of the AI ​​review process, and making it difficult to adapt to the platform's rapidly developing business pace. Summary of the Invention

[0006] The purpose of this application is to provide a product review method, system, electronic device, storage medium, and program product to improve the low response efficiency of existing hard-coded methods to review requirements.

[0007] In a first aspect, embodiments of this application provide a product verification method, the method comprising: Obtain product information for products awaiting review; Based on the product information, obtain the corresponding review capability configuration and review rule configuration; Based on the aforementioned review capability configuration, the product information is converted into corresponding request parameters; A review request is sent to the review algorithm service based on the request parameters; According to the configured review rules, the initial review result returned by the review algorithm service is parsed into the target review result corresponding to the product to be reviewed.

[0008] In the above implementation process, by obtaining the product information to be reviewed and matching the corresponding review capability configuration and review rule configuration, and then relying on the review capability configuration, the conversion of product information into request parameters is automatically completed without manual coding adaptation. Then, a request is sent to the review algorithm service and the initial result is parsed based on the review rule configuration to obtain the target review result. The entire process can take effect quickly without application release, which greatly reduces the development manpower input and iteration cycle of new review rule access and old rule adjustment, and efficiently adapts to the business needs of continuous expansion of product categories.

[0009] Optionally, the review capability configuration includes a request parameter mapping relationship, and the step of converting the product information into corresponding request parameters according to the review capability configuration includes: Based on the request parameter mapping relationship, the product information is converted into request parameters for the review algorithm service through Java reflection and function mapping mechanisms.

[0010] In the above implementation process, the request parameter mapping relationship in the review capability configuration is combined with Java reflection and function mapping mechanisms to achieve automatic conversion of product information into review algorithm service request parameters. Unlike the traditional hard-coding method, it does not require manually writing field extraction and parameter assembly code. Instead, it defines the mapping relationship between source fields and target fields through configuration. With the help of Java reflection mechanism, the corresponding field values ​​can be accurately obtained directly from the product information object to complete simple mapping. Through the function mapping mechanism, it can flexibly handle complex data conversion requirements such as brand information extraction and product first image filtering. It not only adapts to the parameter format requirements of different review algorithm interfaces, but also avoids code redundancy and maintenance problems caused by developers' style differences, which greatly reduces the parameter adaptation development cost when integrating new review rules.

[0011] Optionally, the request parameter mapping relationship includes a simple field mapping relationship and a complex field mapping relationship. The simple field mapping relationship is used to indicate that the value of a specified field in the product information is obtained through Java reflection and assigned to the corresponding field of the request parameter. The complex field mapping relationship is used to indicate that the product information is converted into an intermediate object by calling a preset function, and then the fields of the intermediate object are mapped to the corresponding fields of the request parameter.

[0012] In the above implementation process, simple field mapping directly obtains the values ​​of specified fields of the product using Java reflection and assigns them to the corresponding fields of the request parameters without additional coding development. This quickly meets the mapping requirements of basic fields and significantly reduces the manpower and time costs of simple rule access. Complex field mapping converts product information into an intermediate object by calling a pre-defined function before completing the field mapping. This can flexibly handle complex data processing scenarios such as brand information extraction and specific image filtering, avoiding repeated development of conversion logic while maintaining the simplicity of configuration. The two mapping methods work together to comprehensively cover parameter construction requirements of different complexities and are deeply integrated with the dynamic configuration system, further supporting the rapid access and iteration of new review rules and reducing application release dependencies.

[0013] Optionally, the review capability configuration also includes the call address of the review algorithm service, and sending a review request to the review algorithm service based on the request parameters includes: An HTTP audit request is sent to the audit algorithm service based on the call address and the request parameters.

[0014] In the above implementation process, the call address of the review algorithm service is incorporated into the review capability configuration, and an HTTP review request is sent based on this address and the constructed request parameters. This eliminates the need to develop a separate FeignClient client bound to a fixed URL for each review algorithm service. By combining configurable addresses with HTTP generic calling capabilities, flexible adaptation to different algorithm interfaces is achieved, significantly reducing the development workload when integrating new algorithm services. Furthermore, the configurable management of call addresses means that scenarios such as changes in algorithm service addresses and the addition of new algorithm interface calls do not require code modifications or application deployments; only configuration adjustments are needed for real-time effects, effectively improving the response speed of the review process to algorithm service iterations.

[0015] Optionally, the review rule configuration includes result parsing conditions and review action rules. The step of parsing the initial review result returned by the review algorithm service into the target review result corresponding to the product to be reviewed, based on the review rule configuration, includes: Based on the result parsing conditions, the initial review result returned by the review algorithm service is parsed; For the initial audit results that meet the result parsing conditions, execute the corresponding audit action rules to obtain the target audit result for the product to be audited.

[0016] In the above implementation process, by incorporating the result parsing conditions and audit action rules into the audit rule configuration, on the one hand, there is no need to hardcode and develop dedicated result parsing implementation classes for different audit rules. The parsing logic and corresponding processing actions can be flexibly defined simply by configuration. On the other hand, the binding of parsing conditions and audit actions can adapt to the differences in return formats of different algorithm services and the business audit requirements of various categories and violation scenarios, ensuring the consistency and accuracy of audit results.

[0017] Optionally, the result parsing condition is a conditional expression based on the rule engine syntax, and the conditional expression is used to access and judge the values ​​of each field of the initial review result; And / or, the review action rules include at least one of review approval, review rejection, transfer to manual review, and no result, and each review action rule includes the type of action to be performed and user prompt information.

[0018] In the above implementation process, by using conditional expressions of the rule engine syntax as the result parsing conditions, the values ​​of each field in the initial review result can be flexibly accessed and accurately judged. There is no need to hardcode the parsing logic for the return structure of different algorithms, which can easily adapt to the field validation requirements of multiple review scenarios and greatly improve the adaptability and scalability of the parsing logic. At the same time, the review action rules cover core scenarios such as review approval, rejection, and transfer to manual review. Each action includes a clear execution type and user prompt information, which not only ensures the standardized output of review results, but also provides clear guidance for subsequent links such as merchant rectification and manual review, improving the practicality of the review process and user experience.

[0019] Optionally, obtaining the corresponding review capability configuration and review rule configuration based on the product information includes: Based on the category information of the product information, obtain the corresponding review rule configuration; Based on the configured review rules, obtain the associated review capability configuration.

[0020] In the above implementation process, with the category as the core anchor point, exclusive review rules for different categories (such as footwear and clothing) can be matched in a targeted manner to ensure that the review standards are in line with the characteristics of the category and improve the accuracy of the review. On the other hand, the design of the association between the review rules and the configuration of review capabilities realizes the decoupling and reuse of the two.

[0021] Optionally, after parsing the initial review result returned by the review algorithm service into the target review result corresponding to the product to be reviewed according to the review rule configuration, the method further includes: Record and save the audit execution log, which includes the request parameters, the initial audit result, the rule execution process, and the target audit result.

[0022] In the above implementation process, by recording the audit execution log, the audit results can be traced back to the end. When audit disputes, abnormal results or merchant appeals occur, the parameter construction logic, rule matching details and result derivation process can be quickly traced back, effectively reducing the difficulty of problem location and investigation.

[0023] Secondly, embodiments of this application provide a product verification system, the system comprising: The review capability module is used to convert product information into request parameters for the review algorithm service based on the review capability configuration. The HTTP generic invocation module is used to send HTTP audit requests to the audit algorithm service based on the request parameters. The rules engine parsing module is used to parse the initial review result returned by the review algorithm service into the target review result for the product to be reviewed, based on the review rules configuration. The dynamic configuration management module is used to manage the audit capability configuration and the audit rule configuration, as well as to perform operation management on the configuration.

[0024] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, the steps of the method provided in the first aspect above are performed.

[0025] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the steps of the method provided in the first aspect above.

[0026] Fifthly, embodiments of this application provide a computer program product, including computer program instructions, which, when read and executed by a processor, perform the steps of the method provided in the first aspect above.

[0027] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing embodiments of this application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0028] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1 This is a schematic diagram of the structure of a product verification system provided in an embodiment of this application; Figure 2 A flowchart of a product review method provided in this application embodiment; Figure 3 A schematic diagram illustrating the entire process of a product review method provided in this application embodiment; Figure 4 This is a schematic diagram of the structure of an electronic device for performing a product review method, provided as an embodiment of this application. Detailed Implementation

[0030] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0031] It should be noted that the terms "system" and "network" in the embodiments of this invention can be used interchangeably. "Multiple" refers to two or more; therefore, in the embodiments of this invention, "multiple" can also be understood as "at least two". "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / ", unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0032] It should also be noted that all actions involving the acquisition of signals, information, or data in this application are carried out in compliance with the relevant data protection laws and policies of the country where the application is located, and with the authorization granted by the owner of the relevant device.

[0033] This application provides a product review method. The method obtains the product information to be reviewed and matches the corresponding review capability configuration and review rule configuration. Then, it automatically completes the conversion of product information into request parameters based on the review capability configuration, without the need for manual coding adaptation. Next, it sends a request to the review algorithm service and parses the initial result based on the review rule configuration to obtain the target review result. The entire process can take effect quickly without application deployment, which greatly reduces the development manpower input and iteration cycle of new review rule access and old rule adjustment, and efficiently adapts to the business needs of continuous expansion of product categories.

[0034] To facilitate understanding of the product review methods in this solution, the product review system provided in this solution will be introduced below, such as... Figure 1 As shown, the product review system 100 includes a review capability module 110, an HTTP generic call module 120, a rule engine parsing module 130, and a dynamic configuration management module 140.

[0035] The audit capability module 110 can achieve dynamic configuration capability by combining the HTTP generic call module 120 and the rule engine parsing module 130. The dynamic configuration management module 140 mainly manages dynamic configuration. When an audit rule is executed, the dynamic configuration management module 140 will load the corresponding dynamic configuration rule based on the audit rule identifier.

[0036] Specifically, the audit capability module 110 is used to convert product information into request parameters for the audit algorithm service based on the audit capability configuration. The core of this module is a configuration-based, dynamic field mapping engine. Specifically, it uses Java reflection and Function capabilities, combined with the audit capability configuration, to map information in the product information (source fields in the JSON configuration) to request parameters (target fields in the JSON configuration).

[0037] The HTTP generic invocation module 120 is used to initiate HTTP review requests to the review algorithm service based on request parameters. This module is mainly used to initiate HTTP requests and can be implemented based on FeignClient (which is a declarative HTTP client component in the Spring Cloud ecosystem). It reads the request parameters and invocation address in the review capability configuration to initiate HTTP requests.

[0038] The rule engine parsing module 130 is used to parse the initial review result returned by the review algorithm service into the target review result for the product to be reviewed, based on the review rule configuration. This module can combine the parsing capabilities of the rule engine to parse the initial review result.

[0039] The dynamic configuration management module 140 is used to manage the configuration of audit capabilities and audit rules, as well as to perform operation management on the configuration, such as CRUD operations.

[0040] When adding a new configuration, it is possible to enter the audit capability configuration that includes the request URL and field mapping rules, as well as the rule configuration that includes a unique ruleCode, conditional expression, and audit action. The system automatically assigns a unique identifier to each rule and establishes a "rule-capability" association relationship. The configuration data is synchronized and persisted to the database and Redis version storage.

[0041] When deleting a configuration, you can remove redundant or invalid configurations by specifying a ruleCode, simultaneously unbind the associated audit capabilities, and clean up the corresponding data in the database and cache to avoid invalid configurations consuming resources.

[0042] When modifying the configuration, core elements such as field mapping logic, URL, conditional expressions, and action rules can be adjusted. After modification, the database records are updated in real time, and the Redis version number is triggered to iterate, driving the rule engine to rebuild the local cache, ensuring that the new configuration takes effect without application deployment.

[0043] When querying configurations, on the one hand, after a product triggers an audit, the corresponding two types of configurations are accurately queried based on the ruleCode associated with the category and distributed to modules such as audit capabilities and HTTP generic calls, providing support for the audit process. On the other hand, it supports querying configuration details, relationships, and version history, making it convenient for operations and development personnel to trace the configuration change trajectory and ensuring the standardization and traceability of configuration management.

[0044] The following section, using the aforementioned product review system, details the implementation process of the product review method. For example... Figure 2 As shown, the product review method includes the following steps: Step S210: Obtain product information for the product to be reviewed.

[0045] When a merchant completes the product information and submits it for review on an e-commerce platform, or when the product review system initiates a periodic review of listed products, the product review process is triggered. At this time, the product review system can obtain product information from the e-commerce platform or from its internal service interface.

[0046] Product information can be a structured product information object that encapsulates all relevant data for the product to be reviewed, such as basic attributes, category information, sales attributes, multimedia information, brand information, and other business attributes. Basic attributes may include product ID, product title, and product description text. Category information may include the first-level category ID and name (e.g., "Clothing"), second-level category ID and name (e.g., "Men's Wear"), and third-level category ID and name (e.g., "Sports T-shirts"). Sales attributes may include sales price, original price, and inventory quantity. Brand information may include brand ID, Chinese brand name, English brand name, and a link to the brand logo. Other business attributes may include shipping location, material, and size.

[0047] Step S220: Based on the product information, obtain the corresponding audit capability configuration and audit rule configuration.

[0048] The review capability configuration can be a declarative document in JSON format that describes "how to communicate with a specific review algorithm service", including the interface address, protocol, and how to convert product information into the input parameters required by the algorithm.

[0049] The audit rule configuration can also be a declarative document in SON format, which describes "under what conditions what audit conclusion is produced". It does not include the specific audit code logic, but only the conditional expressions and result mappings.

[0050] Understandably, the configuration of review capabilities and review rules can be pre-written configuration information by developers for products to be reviewed and stored in the database. The database can store multiple review capability configurations and review rule configurations. Different business scenarios may correspond to different review rule configurations; for example, the review rules for new product launches are different from the review rules for product modifications.

[0051] If it is necessary to develop corresponding review rules for the specific characteristics of the products to be reviewed, then the review rule configuration and review capability configuration need to be rewritten and stored in the database. Of course, if it is not necessary to rewrite them, you can directly look up the existing review rule configuration and review capability configuration in the database.

[0052] In some implementations, developers can use the dynamic configuration management module to write audit rule configurations and audit capability configurations. These two configurations can be managed through CRUD operations using application robot callbacks. Furthermore, for ease of searching, the dynamic configuration management module can define a unique rule identifier (ruleCode) for each audit rule configuration. Each audit rule configuration can be associated with one audit capability configuration, and one audit capability configuration can be bound to multiple audit rule configurations.

[0053] The review rule configuration is generally associated with the product category. Therefore, when obtaining the two configurations, you can obtain the corresponding review rule configuration based on the category information of the product information, and then obtain the review capability configuration associated with it based on the review rule configuration.

[0054] For example, the system can first parse the category identifier in the product information, which is usually the category ID. Then, by querying the rule-category binding relationship table, it can determine one or more review rule configurations applicable to the product to be reviewed. Next, the system retrieves the associated review capability configuration from the cache of the dynamic configuration management module according to the ruleCode of each review rule configuration.

[0055] The rule-category binding relationship table is a pre-configured mapping table that ensures different review rules are applied to products in different categories. For example, the "Clothing" category may be bound to the "Trademark Recognition" and "Not for Sale" rules; while the "Books" category may be bound to the "Prohibited Text Recognition" and "Piracy Detection" rules.

[0056] Step S230: Based on the audit capability configuration, convert the product information into the corresponding request parameters.

[0057] This step, performed by the aforementioned review capability module, is a data transformation or assembly process. The module parses the `requestMappingConfig` section of the review capability configuration, which defines the mapping rules from complex product information objects to standard algorithm interface request parameters. Through these mapping rules, product information can be mapped to the request parameters of the review algorithm service interface.

[0058] Step S240: Send an audit request to the audit algorithm service based on the request parameters.

[0059] This step is performed by the HTTP generic invocation module to standardize communication. The audit capability configuration can include the invocation address of the audit algorithm service, so an HTTP audit request can be sent to the audit algorithm service based on the invocation address and request parameters.

[0060] The HTTP generic invocation module reads the httpConfig section of the audit capability configuration (which contains configuration information related to HTTP communication, such as the call address URL, HTTP method, request headers, timeout settings, etc.), and, in conjunction with the request parameters generated in the previous step, initiates a standard HTTP request.

[0061] HTTP generic calls can be understood as using the same HTTP client instance to call any backend service that conforms to the HTTP protocol through dynamically passed configurations (URL, request parameters, etc.), thus realizing the decentralization and configurability of interface calls.

[0062] The system uses a unified, configurable HTTP client, rather than pre-writing specific client code for each algorithm interface. This client is responsible for handling all the low-level details of network communication, such as connection pool management, serialization / deserialization (JSON format), retry mechanisms, circuit breaking and degradation, and load balancing.

[0063] This approach incorporates the call address of the review algorithm service into the review capability configuration and sends HTTP review requests based on this address and the constructed request parameters. This eliminates the need to develop a separate FeignClient client bound to a fixed URL for each review algorithm service. By combining configurable addresses with HTTP generic calling capabilities, flexible adaptation to different algorithm interfaces is achieved, significantly reducing the development workload when integrating new algorithm services. Furthermore, the configurable management of call addresses means that changes to algorithm service addresses or the addition of new algorithm interface calls do not require code modifications or application deployment; only configuration adjustments are needed for real-time effectiveness, effectively improving the review process's responsiveness to algorithm service iterations.

[0064] After the HTTP generic invocation module sends the HTTP review request to the review algorithm service, the review algorithm service reviews the product to be reviewed according to its own review algorithm. Then the module will receive the original response returned by the review algorithm service and initially parse it into a general structured object (such as a Map or a specific POJO), which can be called the initial review result.

[0065] Step S250: Based on the audit rule configuration, parse the initial audit result returned by the audit algorithm service into the target audit result corresponding to the product to be audited.

[0066] The initial review result returned by the review algorithm service reflects the algorithm's technical judgment of the input data, but it has not yet been interpreted in conjunction with specific business rules. For example, the initial review result might be {"containsSensitiveWord":true,"confidence":0.95,"word":"xx"}, but it does not specify the action that should be taken based on this review result, such as rejection or referral to manual processing. Therefore, the rule engine parsing module is still needed to parse the initial review result into the target review result.

[0067] The rules engine parsing module loads the acquired review rule configuration. At its core is a list of conditions, each containing an expression written in a specific syntax (such as QLExpress) and an action. The system injects the initial review result object into the rules engine's context and then executes these expressions sequentially. Expressions can directly access nested fields in the initial review result (such as `data.has_not_sale_item`). When an expression evaluates to true, the engine immediately stops further evaluation and executes its associated action. The action defines the final target review result type (such as "Approved," "Rejected," or "Transferred to Human Assistant") and metadata such as prompts and suggestions to be returned to the front end.

[0068] In the above implementation process, by obtaining the product information to be reviewed and matching the corresponding review capability configuration and review rule configuration, and then relying on the review capability configuration, the conversion of product information into request parameters is automatically completed without manual coding adaptation. Then, a request is sent to the review algorithm service and the initial result is parsed based on the review rule configuration to obtain the target review result. The entire process can take effect quickly without application release, which greatly reduces the development manpower input and iteration cycle of new review rule access and old rule adjustment, and efficiently adapts to the business needs of continuous expansion of product categories.

[0069] Based on the above embodiments, the review capability configuration includes a request parameter mapping relationship. According to the request parameter mapping relationship, product information and function mapping mechanism can be converted into corresponding request parameters through Java reflection mechanism.

[0070] The request parameter mapping can be understood as a data transformation manual. It defines, in structured JSON format, how to accurately convert raw product information from diverse sources and with complex structures into strictly formatted request parameters expected by the review algorithm service. This configuration avoids writing hard-coded parameter assembly logic for each algorithm, achieving a declarative description of the integration process.

[0071] When the system performs an audit task, the audit capability module will drive the entire conversion process. Its input is a product information object and an audit capability configuration, and its output is a request parameter object.

[0072] The Java reflection mechanism is responsible for mapping from the source object to the target parameter. This mechanism is a capability provided by the Java language to inspect or modify information such as classes, objects, methods, and properties at runtime (rather than compile time). Here, it allows the program to retrieve the value of a field based solely on the string of the field name (sourceFieldName) without knowing the specific type of the product information object. For example, the approval module uses a reflection API, such as getDeclaredField(sourceFieldName), to obtain the field object, and then calls field.get(productInfoObj) to retrieve the actual value of the field. This process is completely dynamic and does not require hard-coding like product.getLevel1CategoryId() as in traditional code. After retrieving the value, the engine places it into the request parameter Map using targetKey (e.g., "categoryL1").

[0073] The function mapping mechanism is used to handle scenarios requiring complex logic transformations. The system maintains a global function registry where all available mapping functions are registered. When processing complex mappings, the auditing module can retrieve the corresponding function instance from the function registry, call the function's execute method, and obtain the returned intermediate result object. Then, a secondary mapping is performed on the intermediate result to complete the transformation of request parameters for complex fields.

[0074] In the above implementation process, the request parameter mapping relationship in the review capability configuration is combined with Java reflection and function mapping mechanisms to achieve automatic conversion of product information into review algorithm service request parameters. Unlike the traditional hard-coding method, it does not require manually writing field extraction and parameter assembly code. Instead, it defines the mapping relationship between source fields and target fields through configuration. With the help of Java reflection mechanism, the corresponding field values ​​can be accurately obtained directly from the product information object to complete simple mapping. Through the function mapping mechanism, it can flexibly handle complex data conversion requirements such as brand information extraction and product first image filtering. It not only adapts to the parameter format requirements of different review algorithm interfaces, but also avoids code redundancy and maintenance problems caused by developers' style differences, which greatly reduces the parameter adaptation development cost when integrating new review rules.

[0075] Based on the above embodiments, the above request parameter mapping relationship includes a simple field mapping relationship and a complex field mapping relationship. The simple field mapping relationship is used to indicate that the value of a specified field in the product information is obtained through the Java reflection mechanism and assigned to the corresponding field of the request parameter. The complex field mapping relationship is used to indicate that the product information is converted into an intermediate object by calling a preset function, and then the fields of the intermediate object are mapped to the corresponding fields of the request parameter.

[0076] One example of a JSON format for configuring audit capabilities is shown below: JSON / / 1. Simple field mapping, mapping specific fields in the original product information to request parameters defined in the protocol. "fieldMappingList": [ { / / sourceFieldName is the field name in the product information. "sourceFieldName": "level1CategoryId", / / targetKey is the field name required by the protocol. "targetKey": "level1CategoryId" }, { "sourceFieldName": "level2CategoryId", "targetKey": "level2CategoryId" }, { "sourceFieldName": "categoryId", "targetKey": "level3CategoryId" } ] / / 2. Complex field mapping: Using Function capabilities, the original product information is converted into a temporary object, and then specific field information is mapped based on the temporary object. "complexFieldMappingList": [ { / / Referencing methods with FunctionCode set to BrandInfo, converting them to intermediate objects. "mappingFunctionCode": "brandInfo", "fieldMappingList": [ { / / Fields of the converted object "sourceFieldName": "name", / / Fields required by the algorithm "targetKey": "item_logo_name }, { "sourceFieldName": "chineseName", "targetKey": "item_cn_name }, { "sourceFieldName": "englishName", "targetKey": "item_en_name }, { "sourceFieldName": "nickName", "targetKey": "item_alias_name" }, { "sourceFieldName": "logoUrl", "targetKey": "item_logo_url } ] } ] The simple field mapping relationship is suitable for scenarios where the source data (product information) and target data (algorithm parameters) structures directly correspond without conversion. It is usually an array, where each element declares a pair of "source-target" correspondences.

[0077] Complex field mapping relationships are used to handle scenarios requiring data processing, such as filtering specific images from a list of product images, expanding nested brand objects into multiple fields, or performing numerical calculations. It implements complex logic by referencing predefined mapping functions.

[0078] When loading the audit capability configuration, the system first parses the JSON-formatted configuration content and converts it into an internally executable data structure. For example, it uses a JSON processing library such as Jackson or Gson to convert the JSON string into a Java object. For the example configuration above, the system creates a corresponding FieldMappingConfig object, which contains two core collections: List <simplemappingrule>simpleMappings: Stores all simple field mappings.

[0079] List <complexmappingrule>complexMappings: Stores all complex field mappings.

[0080] The core of simple field mapping is to use Java reflection to extract the value of a specific field from the product information object according to the configuration instructions, and assign it to the corresponding field of the request parameter object.

[0081] Assume the structure of the product information object is as follows: public class ProductInfo { private String level1CategoryId; / / First-level category ID private String level2CategoryId; / / Second-level category ID private String categoryId; / / Third-level category ID private BrandInfo brand; / / Brand information (nested object) private List <imageinfo>images; / / Image list / / ... other fields } The system can maintain a reflection executor, specifically responsible for retrieving object property values ​​via reflection. The reflection executor first retrieves the field value, then processes nested paths. When sourceFieldName is a simple path (such as "level1CategoryId"), the above method is called directly. When it is a nested path, recursive processing is required.

[0082] For the three simple mapping rules in the example configuration above, the reflection executor will execute them in sequence: Rule 1: Obtain productInfo.level1CategoryId → assign it to the level1CategoryId parameter in the request; Rule 2: Obtain productInfo.level2CategoryId and assign it to the level2CategoryId parameter in the request. Rule 3: Get productInfo.categoryId and assign it to the level3CategoryId parameter in the request.

[0083] Complex field mapping processes product information using a threshold function to generate intermediate objects, which are then used for field mapping. This is a two-level mapping mechanism.

[0084] The module locates the corresponding function implementation from the system's pre-built function registry based on the mappingFunctionCode (e.g., "extractPrimaryImage"). These functions are pre-developed Java classes that implement a unified interface, such as MappingFunction, whose core method is execute(Object sourceData, Map<String, Object> context).

[0085] The system calls the `execute` method of this function, passing the product information object as a parameter. The function internally encapsulates specific business logic.

[0086] For example, after the extractPrimaryImage function receives the product information object, its internal logic may be: 1. Access the product's imageList field; 2. Traverse this image list and find the image marked as "main image" or the first image in the sorted list; 3. Return an intermediate result object containing imageId and URL.

[0087] The function returns an intermediate object. The module then uses the nested fieldMappingList within the complex map to perform another reflection mapping on this intermediate object, mapping the intermediate object's properties to the final request parameter map.

[0088] Take the complex mapping in the example configuration above as an example: Based on mappingFunctionCode:"brandInfo", obtain a BrandInfoFunction instance from the function registry, execute brandInfo.execute(productInfo, context), and obtain a BrandInfoDTO intermediate object.

[0089] Assume the brand information in the product information is as follows: brand.getName() = "Nike" brand.getChineseName() = "Nike" brand.getEnglishName() = "Nike" brand.getNickName() = "Hook Brand" brand.getLogoUrl() = "https: / / nike.com / logo.png" The intermediate object BrandInfoDTO contains: { name: "Nike" chineseName: "Nike", English Name: "Nike", nickName: "Hook Card", logoUrl: "https: / / nike.com / logo.png" } When mapping to request parameters, the module executes the following sequentially: Rule 1: intermediateObject.name → "Nike" → put it into item_logo_name; Rule 2: intermediateObject.chineseName → "Nike" → put into item_cn_name; Rule 3: intermediateObject.englishName → "Nike" → put it into item_en_name; Rule 4: intermediateObject.nickName → "Hook Card" → put it into item_alias_name; Rule 5: intermediateObject.logoUrl → "https: / / nike.com / logo.png" → put it into item_logo_url.

[0090] Once all simple and complex mappings have been processed, the request parameter Map will contain all the key-value pairs generated according to the configuration. The audit capability module returns this structured Map to the next higher-level process (usually the HTTP generic call module), which serializes it into a format such as JSON and then initiates a network request.

[0091] Here is an example of an HTTP audit request initiated by the HTTP generic invocation module: JSON { / / URL for making the request "url": " / ai-check / not-sale / check", / / headers "headers":[], / / Request parameters, used in the dynamic configuration module for auditing "requestMappingConfig": { "fieldMappingList": [ {"sourceFieldName": "level1CategoryId", "targetKey": "level1CategoryId" }, { "sourceFieldName": "level2CategoryId", "targetKey": "level2CategoryId" }, { "sourceFieldName": "categoryId", "targetKey": "level3CategoryId" } ] } } In the above implementation process, simple field mapping directly obtains the values ​​of specified fields of the product using Java reflection and assigns them to the corresponding fields of the request parameters without additional coding development. This quickly meets the mapping requirements of basic fields and significantly reduces the manpower and time costs of simple rule access. Complex field mapping converts product information into an intermediate object by calling a pre-defined function before completing the field mapping. This can flexibly handle complex data processing scenarios such as brand information extraction and specific image filtering, avoiding repeated development of conversion logic while maintaining the simplicity of configuration. The two mapping methods work together to comprehensively cover parameter construction requirements of different complexities and are deeply integrated with the dynamic configuration system, further supporting the rapid access and iteration of new review rules and reducing application release dependencies.

[0092] In some implementations, the aforementioned preset functions include at least one of the following: a function for extracting specific product image information, a function for processing product brand information, and a function for calculating product price information.

[0093] The function for extracting specific product image information aims to extract one or more specific images from a product's image list to meet the diverse image input requirements of different review algorithms. This function receives two main input parameters: a complete product information object and optional function configuration parameters. The product information object contains an image list field, which typically contains multiple image objects, each with information such as image ID, URL, type, size, and sorting.

[0094] The function can implement multiple extraction strategies, selecting the best strategy based on the passed configuration parameters: Strategy A: Extract the first main image: Traverse the image list and find the image marked as "main image" and sorted first.

[0095] Strategy B: Extract the first background image: Specifically extract the background image used to showcase the product's usage scenario.

[0096] Strategy C: Extract images within a specified size range: Filter images that meet the criteria based on the image size requirements of the review algorithm.

[0097] Strategy D: Multi-image combination extraction: Extract the main image and background image simultaneously to form a single image set.

[0098] During the extraction process, the function can also perform a series of quality checks, such as URL validity checks, size validation, and format compatibility checks. For any anomalies detected, the function can also be configured with error handling mechanisms.

[0099] The purpose of the function used to process product brand information is to standardize the complex and nested brand information structure in products into a flat format that is easy for the auditing algorithm to process, and to support the output of brand information in multiple languages ​​and formats.

[0100] The function first locates the brand information from the product information object. Brand information may exist in multiple locations: the main brand field (the direct brand attribute of the product), nested brand objects (brand information is nested as an independent object within the product), SKU-level brand information (for multi-SKU products, each SKU may have different brand information), and historical brand information (the product may have records of brand changes).

[0101] The function can perform standardized processing on the extracted brand information, including brand name normalization, multilingual brand name extraction, brand alias processing, and brand logo processing. The function supports multiple output formats to meet the different needs of the review algorithm, such as flat format, structured format, and algorithm-specific formats.

[0102] The purpose of the function used to calculate commodity price information is to perform in-depth analysis and calculation of commodity price information, generate price characteristics, trends and anomaly indicators, and provide rich input features for price auditing algorithms.

[0103] The function can collect all relevant price data from product information, including current selling price, original price, historical price data, category average price, competitor prices, cost price, etc. Based on the collected data, the function calculates multiple price-related indicators, such as discount rate calculation, historical price fluctuation, price competitiveness, gross profit margin estimation, and price trend.

[0104] Understandably, in practical applications, the behavior of each preset function can be adjusted through configuration, and the corresponding preset functions can be configured according to actual audit requirements, not limited to the preset functions listed above.

[0105] Based on the above embodiments, the above-mentioned review rule configuration may include result parsing conditions and review action rules. When parsing the initial review result according to the review rule configuration, the initial review result returned by the review algorithm can be parsed according to the result parsing conditions. Then, the corresponding review action rules are executed on the initial review result that meets the result parsing conditions to obtain the target review result corresponding to the product to be reviewed.

[0106] The rules engine parsing module is responsible for converting the initial review results returned by the review algorithm service into review decisions with clear business implications. It adopts a condition-driven decision-making design pattern, externalizing complex business judgment logic into configurable rule expressions, thus achieving separation between business logic and technical implementation.

[0107] After receiving the initial review result from the review algorithm service, the HTTP generic invocation module sends it to the rule engine parsing module for processing. Upon receiving the initial review result, the rule engine parsing module first loads the corresponding review rule configuration and parses each part of the configuration, including the result parsing conditions and review action rules. It may also include a default action configuration, which is the default action to be executed when all conditions are not met.

[0108] The result parsing condition is an array containing multiple condition items. Each condition item may include a condition name (for identification and logging), a condition expression string, and a condition description (explaining the business meaning of the condition).

[0109] The review action rules and result parsing conditions correspond one-to-one, which may include action type (such as PASS, REJECT, MANUAL_REVIEW, NO_RESULT), message template (dynamic text containing placeholders), and additional parameters (such as suggested actions, risk level, notification channels, etc.).

[0110] The rule engine executes each result parsing condition in the configured order. When a condition expression is met, the corresponding review action rule is executed. The action rule defines the specific business response, such as pass, rejection, or transfer to manual review. The final target review result may include the review conclusion (e.g., pass, rejection, transfer to manual review), explanation of the review reason, suggested actions, risk level, timestamp information, etc.

[0111] In the above implementation process, by incorporating the result parsing conditions and audit action rules into the audit rule configuration, on the one hand, there is no need to hardcode and develop dedicated result parsing implementation classes for different audit rules. The parsing logic and corresponding processing actions can be flexibly defined simply by configuration. On the other hand, the binding of parsing conditions and audit actions can adapt to the differences in return formats of different algorithm services and the business audit requirements of various categories and violation scenarios, ensuring the consistency and accuracy of audit results.

[0112] Based on the above embodiments, the result parsing conditions are conditional expressions based on the rule engine syntax. These conditional expressions are used to access and judge the values ​​of each field in the initial review result.

[0113] The review action rules include at least one of the following: review approved, review rejected, transferred to manual review, and no result. Each review action rule includes the type of action to be performed and the user prompt information.

[0114] Here, the result parsing conditions can be conditional expressions written based on the QLExpress rule engine syntax. The core purpose is to accurately access various fields (such as status code, business judgment result data, description information message, etc.) in the initial review result returned by the review algorithm, and perform logical judgment on the field values ​​to determine whether the initial review result meets the preset review standards.

[0115] The review action rules are a set of execution instructions bound to the result parsing conditions. They include at least four types: review passed, review rejected, transferred to manual review, and no result. Each type specifies the "execution action type" (i.e. the specific review conclusion) and "user prompt information" (feedback text for merchants or reviewers), which are used to output a clear response when the initial review result meets the corresponding parsing conditions.

[0116] The review rules configuration is entered in JSON format through the dynamic configuration management module. Each rule corresponds to a unique ruleCode (rule identifier). The core configuration includes two parts: result parsing conditions and review action rules. At the same time, defaultAction (the default action when all conditions are not met) must be specified.

[0117] The following is an example of the review rule configuration for a review requirement that "the main image contains blind box-related content": JSON { "ruleCode": "PIC_CONTAINS_BIND_BOX", "name": "The cover image contains content related to blind boxes", / / conditions are used to determine the possibility of multiple outcomes. Each condition is equivalent to an if statement. "conditions": [ { / / If the returned result does not meet expectations, then indicate that there is no result. "expression": "result.code == null || result.code != 0 ||result.data.blindBox == null", "action": { "type": "NO_RESULT", "messageExpression": "'Algorithm yielded no results'" } }, / / When the returned result meets expectations and the bindBox field is 0, the review is approved. { "expression": "result.data.blindBox == 0", "action": { "type": "PASS", "messageExpression": "'Approved'" } }, / / If the returned result matches expectations and bindBox=1, it indicates the presence of the word "blind box," and the review will fail. { "expression": "result.data.blindBox == 1", "action": { "type": "REJECT", "messageExpression": "'The image contains blind box text, please re-upload'", "suggestType": 2, "suggestKey": "imgId", "preAuditSuggestKey": "imgUrl" } } ], If none of the above conditions are met, then the default is pass. "defaultAction": { "type": "PASS" } } In this configuration, the `conditions` array contains multiple result parsing conditions, each corresponding to a different detection scenario. Each condition defines its judgment logic using the `expression` field in QLExpress syntax, and the `action` field binds to the corresponding review action rule. `defaultAction` defines the default handling method when all conditions are not met. After configuration, the dynamic configuration management module saves it to the database and synchronously updates the rule version corresponding to that `ruleCode` in the database to ensure that the latest configuration is obtained upon subsequent loading.

[0118] When adding or editing product information triggers product review, the system retrieves the pre-bound set of review rules (including the corresponding ruleCode) for the product category (e.g., children's shoes, footwear). The dynamic configuration management module loads the corresponding JSON configuration based on the ruleCode. The rule engine parsing module first checks if the rule for that ruleCode in the local cache is the latest version. If not, it rebuilds the QLExpress rule engine and updates the local cache to ensure that the latest result parsing conditions and review action rules are used for subsequent processing.

[0119] The HTTP generic invocation module initiates an HTTP request to the interface of the review algorithm task based on the URL (such as " / ai-check / not-sale / check") and the request parameters generated by the field mapping in the review capability configuration. After the interface returns the raw response, the HTTP generic invocation module converts it into an initial review result object in a unified format.

[0120] After obtaining the initial review result object, the rules engine parsing module reads the `conditions` array from the JSON configuration and processes the expression of each condition in sequence: first, the expression is compiled by the QLExpress rules engine; then, the required field values ​​(such as `code` and `data`) are extracted from the initial review result object and substituted into the expression for logical operations. Taking the first condition in the configuration as an example, the expression "result.code == null || result.code != 0 || result.data.blindBox == null" will extract the `code` and `data` values ​​from the initial review result, and the result after calculation is "true", meaning that the initial review result is determined to meet the parsing condition.

[0121] When a certain result parsing condition is determined to be "satisfied", the system will execute the review action rule bound to that condition: if actionType is "REJECT", the target result of "Rejection" will be output, and a preset user prompt message will be returned simultaneously (e.g., "The product image contains the words 'blind box', which does not comply with platform specifications, and the review is rejected"); if actionType is "MANUAL_REVIEW", the result of "Transfer to manual review" will be output, and the prompt message will be "The product image has detected a suspected blind box pattern, which needs to be further verified manually to see if it is a blind box product"; if actionType is "PASS", the result of "Review passed" will be output, along with the corresponding prompt. If none of the conditions are met, the system will execute defaultAction, such as outputting the prompt message "Review passed", thus completing the transformation from the initial review result to the target review result. The entire process does not require hard-coding modifications or application deployment; it only requires configuration to take effect.

[0122] In the above implementation process, by using conditional expressions of the rule engine syntax as the result parsing conditions, the values ​​of each field in the initial review result can be flexibly accessed and accurately judged. There is no need to hardcode the parsing logic for the return structure of different algorithms, which can easily adapt to the field validation requirements of multiple review scenarios and greatly improve the adaptability and scalability of the parsing logic. At the same time, the review action rules cover core scenarios such as review approval, rejection, and transfer to manual review. Each action includes a clear execution type and user prompt information, which not only ensures the standardized output of review results, but also provides clear guidance for subsequent links such as merchant rectification and manual review, improving the practicality of the review process and user experience.

[0123] Based on the above embodiments, after obtaining the target audit result, an audit execution log can also be recorded and saved. The audit execution log includes request parameters, initial audit result, rule execution process and target audit result.

[0124] The audit execution log is a structured data collection that records key information throughout the audit process. Its core includes request parameters, initial audit results, rule execution process, target audit results, etc. It is used to trace audit logic, troubleshoot problems, monitor audit results, and provide data support for audit rule optimization and process maintenance.

[0125] The request parameters here refer to the set of parameters generated by the aforementioned review capability module after converting product information through mechanisms such as Java reflection and function mapping. These parameters are used to call the review algorithm interface and include various fields and corresponding values ​​required by the interface.

[0126] The initial review result is the original response data returned by the review algorithm service, which is then converted into a unified format by the HTTP generic call module.

[0127] The rule execution process refers to the details of how the rule engine parsing module executes the audit rules. This may include the loaded ruleCode, the parsing conditions of the matching results (conditional expressions and calculation results), the execution of audit action rules and related information, etc., reflecting the flow of audit logic.

[0128] The target review result is the final review conclusion output after the rules are executed, including the type of action (approved, rejected, transferred to manual review, no result) and the corresponding user prompt information. It is the final review feedback received by the merchant or reviewer.

[0129] After the audit process completes the output of the target audit result, the system will automatically trigger the process of recording and saving the audit execution log. This process can be achieved by relying on the data output of each module and a unified log management mechanism.

[0130] First, after completing their respective functions, each core module synchronously pushes key data to the log collection component: After generating request parameters, the review capability module immediately collects the parameter set (including the final parameter values ​​after simple field mapping and complex field transformation); during the rule execution process, the rule engine parsing module collects rule execution details in real time, including the loaded ruleCode, the traversal result parsing conditions, the expression calculation result (true / false), the index of the successfully matched condition, and the corresponding action information; after the target review result is generated, the final action type (such as "rejection") and user prompt information (such as "the product image contains clothing that is not for sale, which does not comply with the platform specifications and is rejected") are collected.

[0131] Secondly, the log data is structured. After receiving data pushed by various modules, the log collection component performs structured processing according to a preset unified format to ensure the standardization and parsability of the log information. The structured logs will contain a unique log ID (used for unique log identification, which can be associated with product spuId, audit timestamp, etc.) and key-value pairs of each core field.

[0132] Next, the processed log data is stored in the database. After storage, the audit execution logs can be linked with the dynamic configuration management module and the monitoring system. For example, the dynamic configuration management module supports querying all audit logs corresponding to a rule by ruleCode, making it easier for staff to analyze the rule execution effect (such as whether there are misjudgments or whether the condition expression needs optimization). The unified monitoring system can generate monitoring metrics (such as audit pass rate, average audit time, and rule matching success rate) based on fields such as the target audit result and rule execution time in the logs. When anomalies occur (such as a sudden increase in the rejection rate of a rule or the audit time exceeding the threshold), an alarm is triggered to remind staff to investigate in a timely manner. For example, if multiple logs show that the expression of a certain rule frequently triggers manual review, but all are compliant after manual review, staff can trace the rule execution process through the logs, adjust the action rule corresponding to the condition, or optimize the expression to improve the automation rate of the audit.

[0133] In the above implementation process, by recording the audit execution log, the audit results can be traced back to the end. When audit disputes, abnormal results or merchant appeals occur, the parameter construction logic, rule matching details and result derivation process can be quickly traced back, effectively reducing the difficulty of problem location and investigation.

[0134] Combination Figure 3 The implementation process of the above method will be explained through a specific case below.

[0135] Suppose we need to add a new review rule: "Non-sale items cannot appear in product images; if they do, the review will fail."

[0136] Developers first need to leverage the capabilities of the review algorithm and model to develop an interface for detecting whether "non-sale items" exist in the image, and clarify the details of the interface protocol to provide a foundation for subsequent configuration and invocation. Interface protocol: http: / / domain / not-sale / check (will be added to the audit capability configuration later); The request parameters are shown in the table below:

[0137] The fields of the returned results are defined as shown in the table below:

[0138] Based on the above interface protocol, the staff wrote two core JSON configuration files: audit capability configuration and audit rule configuration.

[0139] The configuration for review capabilities includes the mapping relationship between URLs and request parameters. An example configuration is as follows: JSON / / Review Capabilities { / / Request URL "url": " / not-sale / check", / / Field mapping "requestMappingConfig": { / / Simple field mapping "fieldMappingList": [ { "sourceFieldName": "level1CategoryId", "targetKey": "level1CategoryId" }, { "sourceFieldName": "level2CategoryId", "targetKey": "level2CategoryId" }, { "sourceFieldName": "categoryId", "targetKey": "level3CategoryId" } ], / / For complex field mapping, convert the data into an intermediate object using a function before performing the mapping. "perItemMapping": { "mappingFunctionCode": "firstAndFirstGroundPic", "fieldMappingList": [ { "sourceFieldName": "productImageId", "targetKey": "imgId" }, { "sourceFieldName": "url", "targetKey": "imgUrl } ] } } } The review rule configuration defines a unique ruleCode (e.g., NOT_SALE_CHECK), and configures the conditions array and defaultAction. Example configuration is as follows: JSON { "ruleCode": "PIC_CONTAINS_NO_SALE_STUFF", "name": "Image shows non-sale item", "conditions": [ { "expression": "result.code == null || result.code != 0", "action": { "type": "NO_RESULT", "messageExpression": "'Algorithm yielded no results'" } }, { "expression": "result.data == null || result.data == 0", "action": { "type": "PASS", "messageExpression": "'Approved'" } }, { "expression": "result.data>0&&result.data != 2", "action": { "type": "REJECT", "messageExpression": "'The image contains information about non-sale items (such as hang tags, anti-counterfeiting tags, hangers, etc.), please re-upload." "suggestType": 2, "suggestKey": "imgId", "preAuditSuggestKey": "imgUrl" } } ], "defaultAction": { "type": "PASS" } } The two configurations mentioned above can be entered into the system through the application robot callback function of the dynamic configuration management module, and the system will automatically save the configurations to the database. At the same time, a binding relationship between "audit rule - audit capability" is established (in this case, the NOT_SALE_CHECK rule is bound to the above audit capability configuration), and this audit capability can be reused by other rules.

[0140] In the review configuration backend, staff bind the review rule with ruleCode=NOT_SALE_CHECK to the product category that needs to take effect (such as "children's shoes" or "footwear" in this example), completing the "category-rule" association mapping. This operation ensures that when products under this category trigger review in the future, the corresponding review rule can be accurately matched.

[0141] When a merchant adds or edits a "children's shoes, footwear" product (such as uploading a new pair of children's shoes and filling in the relevant information), a SPU change message is triggered, which then initiates the review process. Rule matching: Based on the product category, the system queries the bound ruleCode=NOT_SALE_CHECK and sends a configuration loading request to the dynamic configuration management module; Configuration loading: The dynamic configuration management module is based on ruleCode and returns the corresponding audit capability configuration and audit rule configuration.

[0142] Rule engine initialization: The rule engine parsing module checks whether the locally cached rule engine is the latest version recorded in Redis (verified by ULE_VERSION). If not, it rebuilds the rule engine based on the loaded audit rule configuration and updates the local cache to ensure that the latest condition expressions and action rules are used.

[0143] The review capability module receives the original product information (including carousel image address, image ID, category ID, etc.), and combines it with the loaded review capability configuration to automatically assemble the request parameters using Java reflection. Parse the requestMappingConfig in the configuration and identify simple field mapping rules: for example, obtain the carouselImageUrls field value of the product object through reflection (such as "https: / / example.com / carousel1.jpg"), and directly map it to the imgUrl of the request parameter; obtain the imageId field value (such as 123456), and map it to imgId; obtain the firstLevelCategoryCode field value (such as 1001), and map it to level1CategoryId; If there are complex fields (such as needing to extract the first image from a list of product images), then a function mapping mechanism is used: the firstAndFirstGroundPic function in the system function registry is called, the list of product images is input, the URL of the first image is extracted and then mapped to imgUrl (in this case, it is a simple field mapping, and the assembly is completed directly). The final result is a standardized request parameter object, with a format that conforms to the interface protocol requirements.

[0144] The HTTP generic invocation module is a general-purpose HTTP client built on FeignClient, which performs request initiation and response processing. Dynamic request construction: Read the URL (http: / / domain / not-sale / check) and headers in the audit capability configuration, add the system default headers (such as authentication information and request ID), and serialize the request parameters generated by the audit capability module into a JSON format request body; Request execution: The URL and parameters are bound to the generic client through a dynamic proxy mechanism to initiate an HTTP POST request; if a network error occurs, a retry mechanism is triggered, if a timeout occurs, the request fails quickly, and if an interface error occurs, a fallback mechanism is executed. Response processing: Receive the raw HTTP response returned by the algorithm, convert it into an initial audit result object in a unified format (example: {code: 0, data: 1, imgUrl: "https: / / example.com / carousel1.jpg", message: "Algorithm prediction is normal", timeCost: "50ms"}), record the call log (time consumption, status code), and then pass the result to the rule engine parsing module.

[0145] The rules engine parsing module is based on the QLExpress rules engine. Combined with the approved rules configuration, it parses the initial approval results and executes the corresponding actions: Rule configuration parsing: Reads the conditions array and defaultAction from the configuration, and compiles the expression for each condition. Conditional matching: Substitute the field values ​​of the initial review results into the expression for judgment: For example, if the initial review results are code=0 and data=1, substitute them into the first conditional expression "code == 0&&data == 1", the result is true, and the condition is satisfied. Action execution: Triggers the action bound to this condition: actionType=REJECT (approval rejection), and generates the user prompt message "The product image contains clothing that is not for sale, which does not comply with platform regulations and has been rejected." If the initial review result is code=0 and data=2 (shoe-tag, allowed range), then all conditions are not met, execute defaultAction, and output "Review passed" and corresponding prompt.

[0146] The system can use the "rejection" (or other action type) generated by the rule engine parsing module as the target review result and feed it back to the merchant and reviewers to complete the review process for the product.

[0147] In addition, the unified logging system automatically records key information throughout the entire process, including request parameters (complete parameters after assembly), initial review results (data after conversion of the original algorithm response), rule execution process (loaded ruleCode, matched conditional expressions and calculation results, executed actions), and target review results. Logs are synchronously stored in the database (long-term traceability) and Redis (recent fast query), supporting subsequent rule optimization and problem investigation.

[0148] The entire process requires no hard-coded development or application deployment; rule access and activation can be completed simply through configuration. This fully demonstrates the advantages of the dynamic configuration chain: "efficient expansion and rapid response." At the same time, relying on the collaboration of the four modules, it achieves fully automated review from parameter assembly, request initiation, result parsing to final feedback.

[0149] Please refer to Figure 4 , Figure 4 This is a schematic diagram of an electronic device for performing a product review method, provided as an embodiment of this application. The electronic device may include: at least one processor 310, such as a CPU; at least one communication interface 320; at least one memory 330; and at least one communication bus 340. The communication bus 340 is used to establish communication between these components. In this embodiment, the communication interface 320 is used for signaling or data communication with other node devices. The memory 330 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 330 may also be at least one storage device located remotely from the aforementioned processor. The memory 330 stores computer-readable instructions; when these computer-readable instructions are executed by the processor 310, the electronic device performs the aforementioned method process.

[0150] Understandable. Figure 4 The structure shown is for illustrative purposes only; the electronic device may also include components that are more advanced than those shown. Figure 4 The more or fewer components shown, or having the same Figure 4 The different configurations shown. Figure 4 The components shown can be implemented using hardware, software, or a combination thereof.

[0151] This application provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it performs the method process executed by the electronic device in the above method embodiments.

[0152] This embodiment discloses a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions, and when the program instructions are executed by a computer, the computer can perform the methods provided in the above-described method embodiments, such as including: Obtain product information for products awaiting review; Based on the product information, obtain the corresponding review capability configuration and review rule configuration; Based on the aforementioned review capability configuration, the product information is converted into corresponding request parameters; A review request is sent to the review algorithm service based on the request parameters; According to the configured review rules, the initial review result returned by the review algorithm service is parsed into the target review result corresponding to the product to be reviewed.

[0153] In summary, the embodiments of this application provide a product review method, system, electronic device, storage medium, and program product. This method obtains product information to be reviewed and matches it with corresponding review capability configuration and review rule configuration. Then, it automatically completes the conversion of product information into request parameters based on the review capability configuration, without the need for manual coding adaptation. Next, it sends a request to the review algorithm service and parses the initial result based on the review rule configuration to obtain the target review result. The entire process can take effect quickly without application deployment, which greatly reduces the development manpower input and iteration cycle of new review rule access and old rule adjustment, and efficiently adapts to the business needs of continuous expansion of product categories.

[0154] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus 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. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0155] Furthermore, 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.

[0156] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0157] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

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

Claims

1. A product verification method, characterized in that, The method includes: Obtain product information for products awaiting review; Based on the product information, obtain the corresponding review capability configuration and review rule configuration; Based on the aforementioned review capability configuration, the product information is converted into corresponding request parameters; A review request is sent to the review algorithm service based on the request parameters; According to the configured review rules, the initial review result returned by the review algorithm service is parsed into the target review result corresponding to the product to be reviewed.

2. The method according to claim 1, characterized in that, The review capability configuration includes a request parameter mapping relationship. The step of converting the product information into corresponding request parameters according to the review capability configuration includes: Based on the request parameter mapping relationship, the product information is converted into request parameters for the review algorithm service through Java reflection and function mapping mechanisms.

3. The method according to claim 2, characterized in that, The request parameter mapping relationship includes a simple field mapping relationship and a complex field mapping relationship. The simple field mapping relationship is used to indicate that the value of a specified field in the product information is obtained through Java reflection and assigned to the corresponding field of the request parameter. The complex field mapping relationship is used to indicate that the product information is converted into an intermediate object by calling a preset function, and then the fields of the intermediate object are mapped to the corresponding fields of the request parameter.

4. The method according to claim 2, characterized in that, The audit capability configuration also includes the call address of the audit algorithm service, and sending an audit request to the audit algorithm service based on the request parameters includes: An HTTP audit request is sent to the audit algorithm service based on the call address and the request parameters.

5. The method according to claim 1, characterized in that, The review rule configuration includes result parsing conditions and review action rules. The step of parsing the initial review result returned by the review algorithm service into the target review result corresponding to the product to be reviewed, based on the review rule configuration, includes: Based on the result parsing conditions, the initial review result returned by the review algorithm service is parsed; For the initial audit results that meet the result parsing conditions, execute the corresponding audit action rules to obtain the target audit result for the product to be audited.

6. The method according to claim 5, characterized in that, The result parsing conditions are conditional expressions based on rule engine syntax, which are used to access and judge the values ​​of each field in the initial review result; And / or, the review action rules include at least one of review approval, review rejection, transfer to manual review, and no result, and each review action rule includes the type of action to be performed and user prompt information.

7. The method according to claim 1, characterized in that, The step of obtaining the corresponding review capability configuration and review rule configuration based on the product information includes: Based on the category information of the product information, obtain the corresponding review rule configuration; Based on the configured review rules, obtain the associated review capability configuration.

8. The method according to claim 1, characterized in that, After configuring the review rules and parsing the initial review result returned by the review algorithm service into the target review result corresponding to the product to be reviewed, the process further includes: Record and save the audit execution log, which includes the request parameters, the initial audit result, the rule execution process, and the target audit result.

9. A product verification system, characterized in that, The system includes: The review capability module is used to convert product information into request parameters for the review algorithm service based on the review capability configuration. The HTTP generic invocation module is used to send HTTP audit requests to the audit algorithm service based on the request parameters. The rules engine parsing module is used to parse the initial review result returned by the review algorithm service into the target review result for the product to be reviewed, based on the review rules configuration. The dynamic configuration management module is used to manage the audit capability configuration and the audit rule configuration, as well as to perform operation management on the configuration.

10. An electronic device, characterized in that, It includes a processor and a memory, the memory storing computer-readable instructions that, when executed by the processor, perform the method as described in any one of claims 1-8.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it performs the method as described in any one of claims 1-8.

12. A computer program product, characterized in that, It includes computer program instructions, which, when read and executed by a processor, perform the method as described in any one of claims 1-7.

Images