Commodity screening method and device associated with vehicle, electronic equipment and storage medium

Abstract

This application relates to a method, apparatus, electronic device, and storage medium for selecting goods associated with vehicles. The method includes: receiving heterogeneous product data from multiple data sources via an asynchronous message mechanism and storing the heterogeneous product data in a database; extracting vehicle model compatibility information from the heterogeneous product data, determining the vehicle model code corresponding to the vehicle model compatibility information, and constructing a minimum inventory unit based on the vehicle model code; receiving the vehicle model code of the bound vehicle and the dynamic status parameter set of the vehicle model terminal reported by the vehicle terminal; selecting goods corresponding to the minimum inventory unit associated with the associated vehicle model code set based on the reported vehicle model code, verifying whether the operating environment conditions corresponding to the goods match the dynamic status parameter set, and sending the verified goods data to the vehicle terminal. This application solves the problem in the prior art where car manufacturer dealership platforms easily match unsuitable goods to users, leading to accidental purchases.

Description

Technical Field

[0001] This application relates to the field of automotive parts technology, specifically to a method and apparatus for screening vehicle-related products, electronic equipment, and storage medium. Background Technology

[0002] With the development of intelligent automotive technology, cars are no longer just providing basic transportation; they are also equipped with a range of additional functions and services, such as autonomous driving, entertainment systems, and intelligent voice assistants, offering users a better driving experience. At the same time, the automotive industry's operating model is gradually shifting towards an internet-based model, with car companies interacting with users anytime, anywhere, before and after the purchase. Against this backdrop, car companies are seeking profit opportunities through multiple channels, with one core focus being the sale of car-related products and services, including software rights and hardware devices.

[0003] Although there are already several general e-commerce platforms, the existence of a large number of different car series and models under the same car brand means that the software rights and hardware products available for different models may be completely different. Furthermore, the data formats of car manufacturers' self-operated products and a large number of third-party suppliers are very different, which makes it difficult to maintain store categories and users are very likely to mistakenly purchase incompatible products. Summary of the Invention

[0004] This application provides a product filtering method, device, electronic device, and storage medium associated with vehicles to solve the problem in the prior art where car manufacturer e-commerce platforms easily match unsuitable products to users, leading to users making incorrect purchases.

[0005] In a first aspect, this application provides a method for filtering goods associated with a vehicle, comprising: receiving heterogeneous goods data from multiple data sources through an asynchronous message mechanism, and storing the heterogeneous goods data in a database; extracting vehicle model adaptation information from the heterogeneous goods data, determining the vehicle model code corresponding to the vehicle model adaptation information, and constructing a minimum inventory unit based on the vehicle model code, wherein each minimum inventory unit is associated with a set of vehicle model codes; the set of vehicle model codes consists of all vehicle model codes corresponding to the minimum inventory unit; receiving the vehicle model code of the bound vehicle and the dynamic status parameter set of the vehicle terminal reported by the vehicle terminal; filtering out the goods corresponding to the minimum inventory unit associated with the associated set of vehicle model codes according to the reported vehicle model codes, verifying whether the operating environment conditions corresponding to the goods match the dynamic status parameter set, and sending the verified goods data to the vehicle terminal.

[0006] Optionally, constructing the minimum inventory unit based on the vehicle model code includes: for structured product data provided by the vehicle manufacturer's internal resource system, directly obtaining the bound vehicle model code, and constructing the minimum inventory unit based on the vehicle model code; for unstructured product data provided by third-party suppliers, using a parsing agent based on natural language understanding to extract vehicle model adaptation information and operating environment conditions from the natural language text fields of the unstructured product data, mapping the vehicle model adaptation information to the vehicle model code, and constructing the minimum inventory unit based on the vehicle model code.

[0007] Optionally, extracting vehicle model compatibility information and operating environment conditions from the natural language text field of the unstructured product data using a parsing agent based on natural language understanding includes: extracting vehicle model name, vehicle series name, system version requirements, and hardware configuration requirements from the natural language text field using a pre-set prompt word template in the agent; using the extracted vehicle model name and vehicle series name as the vehicle model compatibility information, and using the extracted system version requirements and hardware configuration requirements as the operating environment conditions.

[0008] Optionally, mapping vehicle model adaptation information to predefined vehicle model codes includes: when the extracted information is a vehicle series name, mapping the vehicle series name to a vehicle series code, and obtaining all vehicle model codes corresponding to the vehicle series code; matching the extracted vehicle model name with a pre-stored vehicle model code mapping table, and outputting the corresponding vehicle model code.

[0009] Optionally, the method further includes: when the extracted vehicle model name cannot match any entry in the vehicle model code mapping table, determining the semantic similarity between the vehicle model name and each vehicle model name in the mapping table, selecting the vehicle model code corresponding to the vehicle model name with a similarity higher than a preset threshold as a candidate output, and marking the output as a fuzzy matching result.

[0010] Optionally, after constructing the minimum inventory unit based on the vehicle model code, the method further includes: when combining multiple minimum inventory units into one product, calculating the intersection of the vehicle model code sets associated with all the combined minimum inventory units, and using the intersection as the associated vehicle model code set of the combined product.

[0011] Optionally, filtering out the products corresponding to the smallest inventory unit associated with the reported vehicle model code set, verifying whether the operating environment conditions corresponding to the product match the status, and sending the verified product data to the vehicle terminal includes: retrieving the vehicle model code set associated with each smallest inventory unit based on the reported vehicle model code, retaining the smallest inventory unit corresponding to the vehicle model code set, and obtaining the product corresponding to the smallest inventory unit; obtaining the operating environment conditions corresponding to the product, and comparing the operating environment conditions with the dynamic status parameter set one by one, and sending the product data to the vehicle terminal when all operating environment conditions are met, wherein the dynamic status parameter set includes at least one of the system version, remaining storage space, and hardware health status of the vehicle terminal.

[0012] Secondly, this application provides a vehicle-associated product filtering device, comprising: a first processing module, configured to receive heterogeneous product data from multiple data sources via an asynchronous message mechanism and store the heterogeneous product data in a database; a second processing module, configured to extract vehicle model adaptation information from the heterogeneous product data, determine the vehicle model code corresponding to the vehicle model adaptation information, and construct a minimum inventory unit based on the vehicle model code, wherein each minimum inventory unit is associated with a set of vehicle model codes; the set of vehicle model codes consists of all vehicle model codes corresponding to the minimum inventory unit; a third processing module, configured to receive the vehicle model code of the bound vehicle and the dynamic status parameter set of the vehicle terminal reported by the vehicle terminal; and a fourth processing module, configured to filter out the products corresponding to the minimum inventory unit associated with the associated set of vehicle model codes according to the reported vehicle model codes, verify whether the operating environment conditions corresponding to the product match the dynamic status parameter set, and send the verified product data to the vehicle terminal.

[0013] Thirdly, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; the memory is used to store a computer program; and the processor is used to implement the vehicle-related commodity screening method described in the first aspect when executing the computer program.

[0014] Fourthly, this application provides a storage medium storing a computer program thereon, characterized in that, when the computer program is executed by a processor, it implements the vehicle-related commodity screening method described in the first aspect.

[0015] In this application, heterogeneous product data from multiple data sources is first received via an asynchronous messaging mechanism and stored in a database. Then, vehicle model compatibility information is extracted from the heterogeneous product data, and the corresponding vehicle model code is determined. A minimum inventory unit is constructed based on the vehicle model code. Next, the vehicle model code of the bound vehicle and the dynamic status parameter set of the vehicle model terminal are received from the vehicle terminal. Finally, based on the reported vehicle model code, the products corresponding to the minimum inventory unit associated with the associated vehicle model code set are selected, and the operating environment conditions corresponding to the product are verified to match the dynamic status parameter set. Finally, the verified product data is sent to the vehicle terminal. As can be seen, in this embodiment, asynchronous messaging and flexible storage support differentiated data formats from various suppliers. Furthermore, natural language understanding technology is used to convert unstructured text into standardized vehicle model codes. In addition, this embodiment combines static vehicle model matching and dynamic status verification to ensure that recommended products are truly usable on the user's vehicle, reducing manual configuration errors, lowering after-sales disputes, and improving system concurrency and response speed. Attached Figure Description

[0016] Figure 1 A flowchart illustrating a vehicle-related product filtering method provided in this application embodiment; Figure 2 A flowchart illustrating a multi-source heterogeneous product aggregation method based on a distributed architecture, provided in this application embodiment; Figure 3 A schematic diagram of a multi-source heterogeneous commodity aggregation device based on a distributed architecture is provided in this application embodiment; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be understood that the preferred embodiments are only for illustrating this application and are not intended to limit the scope of protection of this application.

[0018] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0019] For ease of description, spatial relative terms may be used in the text to describe the relative position or movement of one element or feature relative to another element or feature, as shown in the figure. These relative terms include, for example, "inside," "outside," "middle," "outer," "below," "below," "above," "front," "back," etc. Such spatial relative terms are intended to include different orientations of the device in use or operation, other than those depicted in the figure. For example, if the device in the figure undergoes a positional flip, orientation change, or change of motion, these directional indications will change accordingly. For instance, an element described as "below other elements or features" or "below other elements or features" will subsequently be oriented "above other elements or features" or "above other elements or features." Therefore, the example term "below" can include both upper and lower orientations. The device may be otherwise oriented (rotated 90 degrees or in other directions), and the spatial relative descriptors used in the text will be interpreted accordingly.

[0020] To address the problem in existing automotive retail platforms that easily match users with unsuitable products, leading to accidental purchases, this application provides a product filtering method associated with vehicles, such as... Figure 1 As shown, the steps of this method include: Step 101: Receive heterogeneous product data from multiple data sources through an asynchronous message mechanism and store the heterogeneous product data in the database; In this embodiment, the asynchronous messaging mechanism refers to data exchange between the data sender (such as a third-party supplier system) and the receiver (product platform) via a message queue (such as Kafka or RabbitMQ). The sender delivers data to the queue and returns immediately without waiting for the receiver to finish processing. The receiver retrieves data from the queue according to its own processing capacity. Furthermore, the multiple data sources in this embodiment include internal resource systems of the vehicle manufacturer (such as software stores and hardware inventory systems) and external third-party suppliers (such as parts manufacturers and service providers). In addition, heterogeneous product data refers to product data from different sources that differ in format, fields, and structure. For example, some data is structured JSON / XML, some is semi-structured Excel spreadsheets, and some contains unstructured text descriptions.

[0021] For example, a third-party seat heater supplier pushes product information daily via API, and the system places this push message into a message queue. Even if 100 suppliers update prices simultaneously, the queue can buffer peak traffic, allowing backend services to consume data at their own pace and preventing the database from being overwhelmed. This demonstrates that asynchronous messaging mechanisms can decouple data access and smooth out traffic spikes, improving system stability and scalability, and preventing high-concurrency writes from blocking core services.

[0022] Step 102: Extract vehicle model compatibility information from heterogeneous product data, determine the vehicle model code corresponding to the vehicle model compatibility information, and construct a minimum inventory unit based on the vehicle model code. Each minimum inventory unit is associated with a set of vehicle model codes. The set of vehicle model codes consists of all vehicle model codes corresponding to the minimum inventory unit. In this embodiment, vehicle model compatibility information refers to text or structured data describing which specific vehicle models or series the product can be used with, such as "suitable for Zhixing B and Zhixing C models" or "compatible with ZX series." Extraction can be done through rule matching, but preferably using an agent based on a large language model to perform semantic parsing on unstructured natural language text to identify key entities such as vehicle model names and series names. For example, the parsing agent reads a third-party product description, "Winter heating pack, perfectly compatible with Zhixing B and Zhixing C," and extracts the vehicle model names "Zhixing B" and "Zhixing C." Therefore, in this embodiment, non-standardized, unstructured product compatibility descriptions can be automatically converted into machine-readable standardized information, avoiding manual input errors and inefficiency.

[0023] Furthermore, the vehicle model code is a unique identifier pre-assigned by the automaker for each specific configuration of the vehicle (e.g., ZXB represents the Smart Mobility B model, and ZXC represents the Smart Mobility C model). The system converts the extracted vehicle model name or series name into the corresponding vehicle model code by looking up a pre-established vehicle model code mapping table. If the extracted model name is a series name (such as the Smart Mobility series), then the codes of all models under that series are taken into consideration. For example, in the mapping table, Smart Mobility B corresponds to code ZXB, and Smart Mobility C corresponds to code ZXC. The parsed Smart Mobility B and Smart Mobility C are then converted into ZXB and ZXC, respectively. Therefore, in this embodiment, a precise correspondence is established between external products and the internal vehicle configuration system, laying the foundation for subsequent precise matching.

[0024] Furthermore, in this embodiment, the smallest stock keeping unit (SKU) is the most granular salable unit in product management, possessing independent price, inventory, and specification attributes. Each SKU corresponds to a specific product entity (e.g., a seat heater specifically for the Zhixing B vehicle). When constructing an SKU, one or more vehicle model codes determined earlier are used as the vehicle model code set for that SKU, indicating which vehicle models the SKU is applicable to. For example, an SKU for a seat heater is created, with its vehicle model code set being {ZXB, ZXC}. Another SKU, steering wheel heating software, has a vehicle model code set of {ZXA, ZXB}. In other words, in this embodiment, external products are atomized into manageable and composable smallest units and bound to precise vehicle model applicability, providing a data foundation for subsequent product combination and user matching.

[0025] Step 103: Receive the vehicle model code of the bound vehicle and the dynamic status parameter set of the vehicle terminal reported by the vehicle terminal. In this embodiment, the vehicle terminal refers to the in-vehicle infotainment system (or the user's mobile app). After a user purchases a vehicle and completes real-name authentication, the vehicle cloud platform maps the vehicle's unique identification number (VIN) to a specific vehicle model code. When initiating a product browsing request, the vehicle terminal proactively reports the current vehicle model code (e.g., ZXB) and a set of dynamic status parameters. The set of dynamic status parameters consists of variable status information of the vehicle currently in operation, such as the vehicle system version number (e.g., v2.8), remaining storage space (e.g., 4.2GB), and hardware health status (e.g., whether the seat heating wires are working properly, whether the steering wheel heating module is available), etc. These parameters are encapsulated in key-value pairs in the request header or request body and transmitted in real time. Based on this, the cloud can obtain the user's vehicle's static identity (model) and real-time dynamic capabilities, providing a data foundation for dual filtering and avoiding the recommendation of unusable products.

[0026] Step 104: Based on the reported vehicle model codes, filter out the products corresponding to the smallest inventory unit associated with the associated vehicle model code set, verify whether the operating environment conditions corresponding to the product match the dynamic status parameter set, and send the verified product data to the vehicle terminal.

[0027] In this embodiment, the cloud first performs static filtering: based on the reported vehicle model code (e.g., ZXB), it retrieves the vehicle model code set of all SKUs and retains SKUs whose sets contain ZXB. Then, it identifies the products to which these SKUs belong (a product may consist of one or more SKUs). For example, if the reported code is ZXB, the system filters out SKUs whose vehicle model code set contains ZXB: SKU-A (set {ZXB, ZXC}) and SKU-B (set {ZXA, ZXB}) are retained, while SKU-C (set {ZXD}) is excluded. The products corresponding to these SKUs proceed to the next round of verification. This method quickly narrows down the candidate product range, retaining only products that match the user's static vehicle identity, reducing the computational load of subsequent dynamic verification.

[0028] Furthermore, the operating environment conditions in this application embodiment refer to the prerequisites that the product must meet to function properly. These are typically derived from the product description, such as requiring a system version ≥ 3.0 or seat heating hardware support. During verification, each operating environment condition is compared with the corresponding actual value in the dynamic state parameter set. For example, if the product requires a system version ≥ 3.0, but the reported version is 2.8, then there is a mismatch; if the product requires the seat heating wire to be functioning properly, and the actual state is seat_heater_ok:true, then there is a match. Only when the operating environment conditions of all SKUs associated with the product match the current dynamic state will the product pass the verification. For example, the product "Winter Comfort Package" contains two SKUs: SKU-A (seat heater, no system requirement) and SKU-B (steering wheel heating software, requires system version ≥ 3.0). The user reports a system version of 2.8, which does not meet the requirements of SKU-B. Therefore, the entire product fails the verification and will not be sent to the user. Therefore, dynamic filtering ensures that users can only see products that are fully supported by the current vehicle's hardware and software, completely avoiding the terrible experience of buying something that cannot be used, while reducing invalid traffic and after-sales disputes.

[0029] For steps 101 to 104 above, in this specific example, the vehicle is: Smart Mobility B model (code ZXB), vehicle system version 2.8, seat heating hardware is normal, steering wheel heating hardware is faulty. Product data: Supplier A: Description "Seat heater, suitable for Smart Mobility B and C", after parsing, SKU-A is generated, vehicle model set {ZXB, ZXC}, no system requirements. Supplier B: Description "Steering wheel heating software, requires system ≥ 3.0, compatible with Smart Mobility A and B", after parsing, SKU-B is generated, vehicle model set {ZXA, ZXB}, system version ≥ 3.0 is required. The operations team creates a bundled product "Winter Package", containing SKU-A and SKU-B.

[0030] Based on this, the aforementioned product data is received asynchronously and stored in the database. Then, the LLM agent parses the text, maps it to vehicle model codes, constructs SKU-A and SKU-B, and associates them with the vehicle model set and operating environment conditions, respectively. Upon receiving Zhang San's request from the vehicle's infotainment system, the system obtains the reported vehicle model ZXB and dynamic status {system_version:"2.8", steering_heater_ok:false}. The system finds SKU-A and SKU-B in the vehicle model set that contain ZXB, and the corresponding product, the winter package, becomes a candidate. The winter package is associated with SKU-A (no requirements, satisfied) and SKU-B (requirement ≥3.0, actual 2.8 does not meet the requirement). Because SKU-B does not meet the condition, this product is filtered out. Ultimately, Zhang San only sees the seat heater (which has passed verification) and not the entire winter package. This demonstrates that users will not mistakenly purchase a package that is unusable due to an outdated system version, improving user experience and platform trust.

[0031] Through steps 101 to 104 above, heterogeneous product data from multiple data sources is first received via an asynchronous message mechanism and stored in a database. Then, vehicle model compatibility information is extracted from the heterogeneous product data, and the corresponding vehicle model code is determined. A minimum inventory unit is constructed based on the vehicle model code. Next, the vehicle model code of the bound vehicle and the dynamic status parameter set of the vehicle model terminal are received from the vehicle terminal. Finally, based on the reported vehicle model code, the products corresponding to the minimum inventory unit associated with the associated vehicle model code set are selected, and it is verified whether the operating environment conditions corresponding to the product match the dynamic status parameter set. Finally, the verified product data is sent to the vehicle terminal. It can be seen that in this embodiment, asynchronous messaging and flexible storage support differentiated data formats from various suppliers. Furthermore, natural language understanding technology is used to convert unstructured text into standardized vehicle model codes. In addition, this embodiment combines static vehicle model matching and dynamic status verification to ensure that recommended products are truly usable on the user's vehicle, reducing manual configuration errors, lowering after-sales disputes, and improving system concurrency and response speed.

[0032] In an optional embodiment of this application, the method of constructing the minimum inventory unit based on vehicle model code involved in step 102 above may further include: Step 11: For the structured product data provided by the car manufacturer's internal resource system, directly obtain the bound vehicle model code, and construct the smallest inventory unit based on the vehicle model code; In this embodiment, the internal resource system of an automaker refers to the internal business system owned by the automaker for managing software rights, hardware accessories, service packages, and other goods (e.g., the backend of an in-vehicle application store, a hardware procurement system). Based on this, structured product data refers to product information output by these systems according to the company's unified internal data specifications. It typically has a fixed field format, such as XML or JSON structure, and explicitly includes fields such as product name, resource unique identifier ID, compatible vehicle model code (ConfCode), and series code (SeriesCode). This type of data can be used directly without additional parsing. Furthermore, the bound vehicle model code refers to one or more vehicle model codes (e.g., ZXA, ZXB) that are directly read from the data records of the internal resource system and are already explicitly associated. These codes are used as the set of vehicle model codes for the smallest stock inventory unit (SKU). Moreover, when constructing an SKU, information such as the product's price, inventory, and expiration date are also obtained to form a complete salable unit. For example, conf_codes: ["ZXA","ZXB"] can be directly extracted from the aforementioned internal data to create a SKU for "steering wheel heating software," with a vehicle model code set of {ZXA, ZXB}. It is evident that in this embodiment, reliable internal data is processed using the shortest path to ensure both efficiency and accuracy.

[0033] Step 12: For unstructured product data provided by third-party suppliers, use a parsing agent based on natural language understanding to extract vehicle model compatibility information and operating environment conditions from the natural language text fields of the unstructured product data, map the vehicle model compatibility information to vehicle model codes, and construct the minimum inventory unit based on the vehicle model codes.

[0034] In this embodiment, third-party suppliers refer to external parts manufacturers, software developers, service providers, etc., that provide product information to the product platform through open APIs or file uploads. Based on this, unstructured product data refers to data that lacks unified field definitions and is often primarily natural language text, such as product titles, detailed descriptions, and specification paragraphs. This text often includes vehicle model compatibility information, system requirements, hardware requirements, etc., and lacks predefined machine-readable fields. For example, data provided by a third-party seat heater supplier might be: Product Name: Winter Seat Heating Pad; Applicable Models: Smart B, Smart C; Requires vehicle seats with ventilation interfaces; Recommended for use in areas with temperatures below 10℃. This text lacks a separate vehicle model code field and only contains a natural language description.

[0035] In this embodiment, the parsing agent based on natural language understanding refers to one or more software modules deployed in the cloud and built using a large language model (LLM, such as the GPT series or BERT fine-tuning model). This agent can understand the semantics of natural language and extract specific information from it. Therefore, the agent can be configured to work according to a preset prompt template, such as: "You are a vehicle model adaptation information extractor. Extract from the following product descriptions: vehicle model name, vehicle series name, system version requirements, and hardware configuration requirements. The output format is JSON." As can be seen, in this embodiment, by utilizing the semantic understanding capabilities of the large language model, it is possible to handle various flexible, colloquial, and even product descriptions containing typos or ambiguous expressions, significantly improving parsing coverage and accuracy, without needing to write separate parsing rules for each supplier.

[0036] Specifically, the extracted vehicle model compatibility information can include the vehicle model name (e.g., Zhixing B) and vehicle series name (e.g., Zhixing series), used for subsequent mapping to internal vehicle model codes. The extracted operating environment conditions refer to the vehicle's hardware and software requirements for the normal operation of the product, such as the minimum system version number (system ≥ 3.0 required), specific hardware modules (steering wheel heating wire required), and storage space requirements (500MB of free space required). For example, from the description "Applicable to Zhixing B and Zhixing C, requires system version 2.5 or higher," the extracted vehicle model compatibility information is [Zhixing B, Zhixing C], and the operating environment conditions are {system_version_min: "2.5"}. In other words, this application can convert natural language, which is originally impossible for machines to process directly, into structured data in key-value pair form, laying the foundation for subsequent mapping and verification.

[0037] In addition, in this embodiment, the system maintains a vehicle model code mapping table, where each row records the correspondence between common external vehicle model / series names and internal standard vehicle model codes. For example, the vehicle model code corresponding to the Zhixing series is ZXB, the vehicle model code corresponding to the Zhixing C series is ZXC, and the vehicle model codes corresponding to the Zhixing series are ZXA, ZXB, and ZXC. The mapping process involves looking up the table based on the extracted vehicle model name or series name and outputting the corresponding vehicle model code (one or more). If a series name is extracted, it can be expanded to the codes of all models under that series (depending on business needs). For example, if the vehicle model name Zhixing B is extracted, the code ZXB is obtained; if the series name Zhixing series is extracted, the code list [ZXA, ZXB, ZXC] is obtained.

[0038] Furthermore, in this embodiment, whether the product data is structured from the automaker's internal resource system or unstructured from a third-party supplier, constructing the minimum inventory unit based on vehicle model codes means using one or more mapped vehicle model codes as the set of vehicle model codes for the SKU. Simultaneously, the operating environment conditions extracted from the agent are also associated with the SKU (for subsequent dynamic verification), ultimately generating a complete and manageable minimum inventory unit record, which is stored in the database. For example, creating an SKU for a seat heater, its vehicle model code set is {ZXB, ZXC}, and its operating environment condition is {need_ventilation_port: true}. Thus, based on the above method, the data models for internal and external products are unified, ensuring that regardless of the data source, all data ultimately participates in subsequent combination and matching with the same structure (SKU + vehicle model code set + operating environment conditions), achieving standardized access to heterogeneous data.

[0039] As can be seen from steps 11 and 12 above, the optimal processing strategy is adopted for different sources, taking into account both efficiency and accuracy. Moreover, regardless of the source, the final output is a consistent data model, which facilitates the reuse of general logic for subsequent combination, filtering, and matching.

[0040] In an optional embodiment of this application, the method of extracting vehicle model compatibility information and operating environment conditions from the natural language text field of unstructured product data using a parsing agent based on natural language understanding in step 12 above can further include: Step 21: Use the pre-set prompt word templates in the intelligent agent to extract the vehicle model name, vehicle series name, system version requirements, and hardware configuration requirements from the natural language text field; The prompt template is a pre-designed natural language instruction used to guide the large language model to output results according to a specified format and content. The prompt template typically includes a task description, input data examples, output format examples, and precautions. For example, for extracting vehicle model compatibility information, the following prompt template could be designed: You are a product compatibility information extractor. Extract the following from the product description: vehicle model name (e.g., Zhixing B), vehicle series name (e.g., Zhixing series), system version requirement (e.g., system ≥ 3.0 required), and hardware configuration requirements (e.g., seat heating interface required). Output in JSON format, with keys: model_names, series_names, system_version_req, hardware_req. If no relevant information is available, the corresponding value will be an empty list or null.

[0041] Further, the vehicle model name refers to the specific vehicle configuration name explicitly mentioned in the product description, for example, Zhixing B, Zhixing C, etc. The vehicle series name refers to the name of a certain vehicle series mentioned in the product description, for example, Zhixing Series, which usually represents a collection of multiple vehicle models under one vehicle series. The system version requirement refers to the vehicle-mounted operating system version condition required for the normal operation of the product. Common expressions include: system version ≥ 3.0 required, compatible with TOS 2.5 or above, system version not lower than 2.8 required, etc. The hardware configuration requirement refers to the vehicle hardware conditions required for the normal operation of the product, for example, seat heating interface required, steering wheel heating wire required, panoramic camera equipped, etc. For example, input text: special floor mat for Zhixing Series, applicable to Zhixing A / B / C, no system requirement. Extraction result: vehicle model name [] (no specific model), vehicle series name ["Zhixing Series"], system version requirement null, hardware configuration requirement null.

[0042] Step 22, taking the extracted vehicle model names and vehicle series names as vehicle model adaptation information, and taking the extracted system version requirements and hardware configuration requirements as operating environment conditions.

[0043] For the above step 21 and step 22, in a specific example, the example product description (from a third-party supplier): special seat heating pad for Zhixing B / C, requires vehicle-mounted system version ≥ 2.8, and the vehicle must be equipped with seat ventilation holes. The system calls a pre-set prompt template, which requires the LLM to output in JSON format, including four fields: model_names, series_names, system_version_req, and hardware_req, and sends the above product description text and the prompt template to a large language model (such as GPT-4). The model returns: { "model_names": ["智行B", "智行C"], "series_names": [], "system_version_req": "≥2.8", "hardware_req": "座椅通风孔" } Based on this, the vehicle model adaptation information = vehicle model name ["Smart B", "Smart C"] + vehicle series name []. Operating environment conditions = system version requirement "≥2.8" + hardware configuration requirement "seat ventilation holes". The vehicle model adaptation information is sent to the mapping module, mapping "Smart B" to code ZXB and "Smart C" to ZXC, forming the vehicle model code set {ZXB, ZXC}. The operating environment conditions are stored as an additional attribute of this SKU, used for subsequent comparison with the system version (e.g., 2.8) and hardware status (e.g., whether there are seat ventilation holes) reported by the vehicle's infotainment system. Through a single LLM call, the structured extraction of static adaptation information and dynamic environment conditions is completed simultaneously, avoiding the additional overhead and consistency risks caused by multiple parsings. Furthermore, because the prompt word template is fixed, the parsing result format is uniform, facilitating subsequent automated processing.

[0044] As can be seen, by extracting four types of information (vehicle model name, vehicle series name, system version requirements, and hardware configuration requirements) simultaneously through steps 21 and 22, static adaptation and dynamic conditions are obtained in one go, improving information completeness. Furthermore, classifying the vehicle model name / vehicle series name as vehicle adaptation information retains fine-grained information, supporting subsequent flexible mapping (exact matching or fuzzy expansion), and classifying system / hardware requirements as runtime environment conditions separates concerns, decoupling static matching from dynamic verification logic and facilitating independent optimization.

[0045] In an optional embodiment of this application, the method of mapping vehicle model adaptation information to a predefined vehicle model code in step 12 above may further include: Step 31: When the extracted information is a vehicle series name, map the vehicle series name to a vehicle series code, and obtain all vehicle model codes corresponding to the vehicle series code; Step 32: Match the extracted vehicle model name with the pre-stored vehicle model code mapping table and output the corresponding vehicle model code.

[0046] As can be seen in this embodiment, if the parsing agent only extracts the series name (e.g., "Smart Series") from the product description, without specific model names, the system first maps the series name to an internal series code (e.g., ZX). Then, based on a preset configuration (e.g., "Smart Series includes three models: ZXA, ZXB, and ZXC"), it extracts all the codes for all models under that series, forming a model code list. It should be noted that this processing means the product is considered applicable to all models within the entire series. If the product is actually only compatible with some models within the series, this automatic expansion may lead to over-recommendation (i.e., pushing to users of models that are not supported). Therefore, it is usually agreed in business terms that this rule is only used for products explicitly marked "applicable to all series" or "universal," or manual review is required in the implementation. If the parsing agent extracts specific model names (e.g., Smart B, Smart C), the system searches for these names one by one in the model code mapping table to find the corresponding model code. Each model name typically uniquely corresponds to one model code, and the matching result may be one or more codes (corresponding to multiple model names).

[0047] As can be seen, in this embodiment, a product description may contain both a vehicle series name and a model name. When both exist, one of the following strategies is typically used: Strategy 1 (Union): Merge all model codes from the vehicle series expansion with the codes matching the model name to remove duplicates. For example, if the vehicle series expansion yields [ZXA, ZXB, ZXC] and the model name matching yields [ZXB], then the final output is [ZXA, ZXB, ZXC]. Strategy 2 (Model Name Priority): Consider the model name more specific and use it as the primary reference, with the vehicle series name only used as an auxiliary (e.g., when the model name matching fails). In a specific example, if both the vehicle series name and model name are extracted, the result of the model name matching is usually prioritized. In this case, the vehicle series name is only used as auxiliary information, and the vehicle series name expansion is only used when no model name is extracted; or, if both the vehicle series name and model name are extracted, the merging method can be selected according to the business configuration.

[0048] As can be seen, in this embodiment, rapid batch configuration of general-purpose products (applicable to all models) is supported, reducing repetitive manual data entry, and taking into account both universality and accuracy. When a specific vehicle model exists, the specific model name takes precedence, avoiding over-generalization.

[0049] Based on steps 31 and 32 above, in this embodiment of the application, when the extracted vehicle model name cannot match any entry in the vehicle model code mapping table, the semantic similarity between the vehicle model name and each vehicle model name in the mapping table is determined, and the vehicle model code corresponding to the vehicle model name with a similarity higher than a preset threshold is selected as a candidate output, and the output is marked as a fuzzy matching result.

[0050] It can be seen that, in the embodiments of the present application, the system performs string comparison between the extracted vehicle model name (e.g., Zhixing B) and the external name column in the pre-stored vehicle model code mapping table. If no completely identical name can be found (for example, due to spelling errors, use of aliases, inclusion of redundant modifiers, or the vehicle model name being a colloquial abbreviation), this situation is defined as matching failure, which is a common problem in actual business, because the product descriptions from third-party suppliers may be non-standard and inconsistent. For example, the extracted vehicle model name is Zhixing Type B, ZXB, or Zhixing Model, while the standard name in the mapping table is Zhixing B, thus the exact matching fails.

[0051] In addition, semantic similarity refers to the proximity of the meanings of two texts, not just literal identity. The calculation methods can adopt: cosine similarity based on word vectors (for example, using pre-trained models such as BERT and Word2Vec to convert texts into vectors); character similarity based on edit distance (Levenshtein distance); matching based on a thesaurus (such as WordNet) or a custom vehicle model alias dictionary. Based on this, the similarity between the extracted vehicle model name and each standard vehicle model name in the mapping table is calculated respectively, to obtain a score between 0 and 1 (1 indicates completely identical or synonymous, 0 indicates completely irrelevant). The preset threshold is a configurable empirical value, for example 0.8. The system only selects those standard vehicle model names whose similarity is greater than or equal to the threshold, considers that they are sufficiently close in semantics and can be used as candidates, then extracts the vehicle model codes corresponding to these standard vehicle model names to form a candidate code list. If multiple standard names all exceed the threshold (for example, both Zhixing B and Zhixing B Sports Edition are matched), multiple candidate codes may be output, which in practice may indicate that the product is suitable for multiple similar vehicle models, or requires further manual confirmation.

[0052] Further, while generating the candidate codes, a tag will be attached to the mapping result (for example, match_type: "fuzzy"), and this tag will always be transmitted to the finally constructed minimum stock keeping unit record. Subsequent processing (such as manual review, operation background display, statistical reports) can distinguish between exact matching and fuzzy matching according to the tag, give extra attention to products with fuzzy matching or require manual review, so as to reduce the risk of incorrect configuration. That is, in the present application and the embodiments, the trace of uncertainty in the mapping process is retained, so that the system has traceability and manual intervention capability, which not only gives full play to the advantages of automation, but also maintains business security.

[0053] In an optional embodiment of this application, after constructing the minimum inventory unit based on the vehicle model code, the following steps may be included: Step 41, when multiple minimum inventory units are combined into one product, calculate the intersection of the vehicle model code sets associated with all the combined minimum inventory units, and use the intersection as the associated vehicle model code set of the combined product.

[0054] A Stock Keeping Unit (SKU) is a salable unit with independent pricing and inventory. In some business scenarios, it's desirable to package two or more SKUs into a bundled product (also known as a set or bundle) for sale together. For example, a "Winter Heating Package" includes a seat heater (SKU-A) and steering wheel heating software (SKU-B). Bundling into a single product means creating a new product record that links (associates) multiple SKUs. When a user purchases this product, they simultaneously receive all associated SKUs. Each SKU is associated with a set of vehicle model codes (e.g., SKU-A's set is {ZXA, ZXB}, and SKU-B's set is {ZXB, ZXC}). A mathematical intersection operation is performed on all these sets to find the vehicle model codes that appear in all sets simultaneously. Only vehicle models supported by all associated SKUs can use all sub-products in the bundle.

[0055] A bundled product is not a SKU in itself, but rather a virtual product hierarchy. The system generates a set of associated vehicle model codes for it, which is the result of the intersection operation. In the subsequent user matching process, the cloud treats the bundled product as a regular product. Only when the vehicle model code reported by the user belongs to this intersection will the bundled product pass the static filtering. For example, the associated vehicle model code set for the bundled product "Winter Comfort Package" is {ZXB}. When a user with a ZXB vehicle requests a product list, this bundled product is included as a candidate; if the vehicle is ZXA or ZXC, the bundled package will not be seen.

[0056] In this specific example, the smallest inventory unit is: SKU-A (seat heater): Vehicle model code set {ZXA, ZXB}, operating environment conditions: none.

[0057] SKU-B (Steering wheel heating software): Vehicle model code set {ZXB, ZXC}, Operating environment conditions: System version ≥ 3.0.

[0058] SKU-C (All-Season Floor Mats): Vehicle model code set {ZXA,ZXB,ZXC}, Operating environment conditions: None.

[0059] Currently, a combined product, the Winter Comfort Package, is created, attaching SKU-A and SKU-B. Then, the list of SKUs to be combined is obtained: [SKU-A, SKU-B]. The respective vehicle model codes are read: {ZXA, ZXB} and {ZXB, ZXC}. The intersection is calculated: {ZXA, ZXB} ∩ {ZXB, ZXC} = {ZXB}. The intersection result, {ZXB}, is used as the associated vehicle model code set for the Winter Comfort Package. If the intersection is empty, the system prompts the operations staff that the package cannot be listed.

[0060] User Zhang San drives a ZXB vehicle with a vehicle infotainment system version 2.8 and requests a product list. Static filtering: The set {ZXB} of combined products containing the reported code ZXB is included in the candidate list. Dynamic verification: The SKU-B associated with the product Winter Comfort Package requires a system version ≥ 3.0, but it is actually 2.8, so it fails verification and is ultimately not distributed.

[0061] User Li Si drives a ZXC vehicle. System version 3.2 requests a list of products. Static filtering: ZXC is not in the combined product set {ZXB}, so this combination will not be seen.

[0062] User Wang Wu, driving a ZXB model, system version 3.2, requested a product list. Static filtering passed, dynamic validation passed (system version satisfied), and the winter comfort package was issued.

[0063] As can be seen, taking the intersection of the vehicle model codes of multiple SKUs can accurately calculate the range of vehicle models that the combined products are truly applicable to, ensuring that all sub-products are usable and eliminating the risk of buying products that cannot be used. In addition, using the intersection as the associated vehicle model code set for the combined products unifies the matching data model for individual products and combinations, allowing subsequent filtering logic to be reused.

[0064] In an optional embodiment of this application, step 104, which involves filtering out the goods corresponding to the smallest inventory unit associated with the reported vehicle model code set based on the reported vehicle model code, verifying whether the operating environment conditions corresponding to the goods match the dynamic state parameter set, and sending the verified goods data to the vehicle terminal, may further include: Step 51: Retrieve the set of vehicle codes associated with each minimum inventory unit based on the reported vehicle code, retain the minimum inventory unit corresponding to the set of vehicle codes, and obtain the product corresponding to the minimum inventory unit. Step 52: Obtain the operating environment conditions corresponding to the product, and compare the operating environment conditions with the dynamic status parameter set one by one. When all operating environment conditions are met, send the product data to the vehicle terminal. The dynamic status parameter set includes at least one of the following: the system version of the vehicle terminal, the remaining storage space, and the hardware health status.

[0065] In this specific example, steps 51 and 52 above involve the following vehicle type: Smart Mobility B (code ZXB), system version 2.8, remaining storage 4.2GB, and hardware status: steering_heater_ok: false (steering wheel heating module malfunction). The database already contains the following SKUs and products: SKU-A (Seat Heater): Vehicle model set {ZXB, ZXC}, no operating environment conditions specified. This is a single product: a seat heater.

[0066] SKU-B (Steering Wheel Heating Software): Vehicle model set {ZXA, ZXB}, operating environment conditions {system_version≥3.0, steering_heater_ok:true}. It belongs to the product category Steering Wheel Heating Software (single item) and Winter Comfort Package (combined product, containing both SKU-A and SKU-B).

[0067] First, static filtering is performed, which involves reporting code ZXB and retrieving the vehicle model set for all SKUs: SKU-A: {ZXB, ZXC} Contains ZXB → Reserved SKU-B: {ZXA, ZXB} Contains ZXB → Reserved Candidate SKU: [SKU-A, SKU-B].

[0068] Then, retrieve the products, that is, retrieve the associated products based on the candidate SKUs, and after deduplication, we get: Product: Seat heater (from SKU-A); Product: Steering wheel heating software (from SKU-B); Product: Winter comfort package (from SKU-A and SKU-B).

[0069] Finally, dynamic verification is performed. For each product, its operating environment conditions are obtained and compared with the reported dynamic status parameter set {system_version:"2.8", steering_heater_ok:false}: Product "Seat Heater": No operating environment conditions → Pass. Product "Steering Wheel Heating Software": Condition system_version ≥ 3.0 (2.8 < 3.0 not met) → Fail. Product "Winter Comfort Package": Includes SKU-A (no requirements) and SKU-B (requires ≥ 3.0 and normal hardware); failure of either results in overall failure → Fail. Therefore, only the seat heater passes verification and is sent to the vehicle's infotainment system. The system displays the product, and users can purchase and use it normally.

[0070] As can be seen, in this embodiment, retrieving the SKU model set based on the reported vehicle model code can quickly complete static identity matching, and the use of set member judgment results in low time complexity. Furthermore, retaining the matched SKUs and obtaining the corresponding products can transform the technical SKU matching results into a product list that is understandable to the user. Obtaining the operating environment conditions corresponding to the products indicates support for dynamic condition verification of complex products (combined products must meet the conditions of all sub-SKUs), and comparing the operating environment conditions with the dynamic state parameter set one by one can accurately determine whether the current hardware and software status of the vehicle meets the product usage requirements.

[0071] The present application will now be explained in detail with reference to specific embodiments of the present application. These specific embodiments provide a method for aggregating multi-source heterogeneous goods based on a distributed architecture. This method achieves highly available and highly accurate goods aggregation and distribution through standardized interface adaptation, document-oriented underlying storage, multi-agent semantic mapping, and dynamic state matching algorithms between the edge and cloud. Specifically, it includes the following processes: 1) Distributed microservices and document-oriented heterogeneous data access layer This system adopts a microservice architecture to decouple business functions, physically isolating the third-party product synchronization service from the core transaction aggregation service.

[0072] For third-party supplier integration, the system introduces a Virtual Standard Product Unit (Virtual SPU) mechanism. The underlying system abandons the traditional relational table structure, instead adopting a document-oriented non-relational database, storing data in a dynamic document format (such as BSON). This allows the system to be extremely flexible in supporting unstructured product attributes (such as different specifications and dynamic configuration items) from different suppliers with varying nesting levels, without frequent modifications to the underlying database table structure. Simultaneously, the system defines data contracts through specific standardized interface specifications. Data changes from external suppliers are verified by the gateway and then delivered to a distributed message queue. The core system processes the data through an asynchronous consumption mechanism, achieving traffic smoothing.

[0073] 2) Semantic mapping and SKU standardization based on multi-agent collaboration The Cheyun platform abstracts product information into three levels from bottom to top: Standard Product Unit (SPU), Minimum Stock Unit (SKU), and Product.

[0074] The internal system provides hardware and software resources to directly generate SPUs and hard binds them with vehicle matching attributes, including resource unique identifier ID, usable vehicle model code (ConfCode) and vehicle series code (SeriesCode).

[0075] In processing the retrieval of third-party supplier products and their conversion into internal SKUs, the system innovatively introduces a multi-agent collaborative architecture. The system deploys a dedicated cluster of parsing agents, utilizing a Large Language Model (LLM) to extract features from unstructured third-party product description text. This automatically aligns and maps the semantics of external non-standard natural language descriptions with the automaker's internal standard SeriesCode and ConfCode, thereby accurately converting heterogeneous supplier products into standardized internal SKUs.

[0076] 3) Hierarchical product construction and attribute intersection calculation engine The product is the final layer displayed to the user and can be associated with one or more SKUs. The most significant technical feature of this layer lies in the automated derivation of its visibility range: the product's vehicle model code and series code information are not manually configured, but rather the system's underlying aggregation calculation engine extracts the vehicle model and series attribute sets of all associated SKUs and performs a strict intersection operation. This intersection result dynamically generates the final visibility range limit for the product, ensuring absolute compatibility of composite products across multiple vehicle model configurations.

[0077] 4) Dual filtering mechanism based on edge-cloud collaboration: static identity + dynamic state After a user purchases a vehicle and completes real-name authentication, the CarCloud platform generates a unique user identifier (UserId) and establishes a strong database mapping with the vehicle unique identification code (VIN), vehicle series code, model code, and vehicle system unique code (TUID).

[0078] When a terminal (vehicle infotainment system or mobile app) initiates a product browsing request, the cloud gateway not only compares the static vehicle model / series code corresponding to the VIN code with the product's overlapping range, but also receives the "dynamic device status tree" (such as the current vehicle infotainment system version, remaining storage space, and hardware health) reported in real time by the vehicle infotainment system. Only when the static identity is completely matched and the dynamic status meets the prerequisites will the system send the product data package to the terminal.

[0079] Specifically, the method steps of this specific implementation are as follows: Figure 2 As shown, it includes the following steps: Step 201: Heterogeneous system integration and underlying data initialization; The product platform first connects with the enterprise's internal resource provision system and external third-party suppliers. Utilizing an API gateway within a distributed architecture, and adhering to interface standards and specifications, it uniformly connects to the product catalog interfaces of external suppliers. Frequently changing product data streams from third parties (such as price and inventory fluctuations) are not directly written to the main database but are instead pushed to the system's message queue for asynchronous queuing.

[0080] Step 202: Construction of SPU and virtual SPU and intelligent agent analysis; Internal resources: Internal business systems create entity SPUs on the product platform through interfaces, clearly identifying the supported vehicle models and series codes. This process can be controlled by the internal business process engine to streamline the approval process and ensure compliance during product listing.

[0081] External Resources: For third-party suppliers, the system creates a virtual SPU set in a document-oriented database. When instantiation is required, the system schedules the semantic parsing agent in the background to read the full description information of the third-party products, extract the implicit vehicle model adaptation rules, and map them into internal SeriesCode and ConfCode, completing the standardization and cleaning of heterogeneous data.

[0082] Step 203: SKU inheritance and intersection operation of composite products; The product platform operators create SKUs based on the aforementioned SPUs, configuring prices and expiration dates. At this point, the SKUs automatically inherit the vehicle model and series restrictions resolved by the underlying SPU or intelligent agent.

[0083] Then, a user-facing product is created, and one or more SKUs are attached to this product. The system background triggers the intersection calculation engine in real time to perform mathematical intersection calculations on the available vehicle configurations of the selected SKUs. For example, if SKU-A supports vehicle models X and Y, and SKU-B supports vehicle models Y and Z, then the final visibility range of the generated combined product will be automatically locked to vehicle model Y.

[0084] Step 204, Dynamic requests and status reporting for end-to-cloud collaboration; When a user opens the product platform client, the terminal application sends a request to the cloud. If the user is logged in and has bound a vehicle, the terminal will report the device's unique identifier (TUID) and dynamic status information (such as the current system version number, available memory, etc.) as parameters in the request header or request body to the gateway when sending the request.

[0085] Step 205: Dual filtering and precise distribution; After receiving the request, the cloud server performs two-layer verification: Static identity verification: The UserId is used to look up the associated VIN code and vehicle series / model information, and then compared with the visible range of all products in the system.

[0086] Dynamic status verification: For products that have passed the first layer of verification (especially software applications or products that require specific hardware support), further verification is performed to check whether the environmental parameters required for their operation match the dynamic device status tree reported by the terminal.

[0087] Ultimately, the cloud only serializes the precise product data structure that meets the criteria and returns it to the user for rendering. This avoids transmitting massive amounts of invalid product data to the user, greatly reducing downlink network bandwidth consumption and improving the loading speed and user experience of the in-vehicle infotainment system.

[0088] Corresponding to the above Figure 1 This application also provides a product screening device associated with a vehicle, such as... Figure 3 As shown, the device includes: The first processing module 302 is used to receive heterogeneous product data from multiple data sources through an asynchronous message mechanism and store the heterogeneous product data in a database. The second processing module 304 is used to extract vehicle model adaptation information from heterogeneous product data, determine the vehicle model code corresponding to the vehicle model adaptation information, and construct a minimum inventory unit based on the vehicle model code. Each minimum inventory unit is associated with a set of vehicle model codes. The set of vehicle model codes consists of all vehicle model codes corresponding to the minimum inventory unit. The third processing module 306 is used to receive the vehicle model code of the bound vehicle and the dynamic status parameter set of the vehicle terminal reported by the vehicle terminal. The fourth processing module 308 is used to filter out the products corresponding to the smallest inventory unit associated with the reported vehicle model code set, verify whether the operating environment conditions corresponding to the product match the dynamic status parameter set, and send the verified product data to the vehicle terminal.

[0089] In an optional embodiment of this application, the second processing module may further include: The first processing unit is used to directly obtain the bound vehicle model code from the structured product data provided by the car manufacturer's internal resource system, and to build the smallest inventory unit based on the vehicle model code; The second processing unit is used to extract vehicle model compatibility information and operating environment conditions from the natural language text fields of unstructured product data provided by third-party suppliers using a parsing agent based on natural language understanding. The vehicle model compatibility information is mapped to vehicle model codes, and the minimum inventory unit is constructed based on the vehicle model codes.

[0090] In an optional embodiment of this application, the second processing unit in this application includes: The first processing subunit is used to extract vehicle model name, vehicle series name, system version requirements and hardware configuration requirements from natural language text fields using pre-set prompt word templates in the intelligent agent; The second processing subunit is used to take the extracted vehicle model name and vehicle series name as vehicle model adaptation information, and take the extracted system version requirements and hardware configuration requirements as operating environment conditions.

[0091] In an optional embodiment of this application, the second processing subunit performs the following steps: when the extracted information is a vehicle series name, the vehicle series name is mapped to a vehicle series code, and all vehicle model codes corresponding to the vehicle series code are obtained; the extracted vehicle model name is matched with a pre-stored vehicle model code mapping table, and the corresponding vehicle model code is output.

[0092] In an optional embodiment of this application, the apparatus in this application may further include: a fifth processing module, configured to determine the semantic similarity between the extracted vehicle name and each vehicle name in the mapping table when the extracted vehicle name cannot match any entry in the vehicle code mapping table, select the vehicle code corresponding to the vehicle name with a similarity higher than a preset threshold as a candidate output, and mark the output as a fuzzy matching result.

[0093] In an optional embodiment of this application, the apparatus in this application may further include: a sixth processing module, configured to, after constructing the minimum inventory unit based on vehicle model codes, calculate the intersection of the vehicle model code sets associated with all the combined minimum inventory units when multiple minimum inventory units are combined into a product, and use the intersection as the associated vehicle model code set of the combined product.

[0094] In an optional embodiment of this application, the fourth processing module includes: The third processing unit is used to retrieve the set of vehicle codes associated with each minimum inventory unit based on the reported vehicle code, retain the minimum inventory unit corresponding to the set of vehicle codes, and obtain the product corresponding to the minimum inventory unit. The fourth processing unit is used to obtain the operating environment conditions corresponding to the product, and compare the operating environment conditions with the dynamic status parameter set one by one. When all operating environment conditions are met, the product data is sent to the vehicle terminal. The dynamic status parameter set includes at least one of the following: the system version of the vehicle terminal, the remaining storage space, and the hardware health status.

[0095] like Figure 4 As shown in the figure, this application provides an electronic device, including a processor 411, a communication interface 412, a memory 413, and a communication bus 414, wherein the processor 411, the communication interface 412, and the memory 413 communicate with each other through the communication bus 414. Memory 413 is used to store computer programs; In one embodiment of this application, when the processor 411 executes the program stored in the memory 413, it implements the vehicle-related product filtering method provided in any of the aforementioned method embodiments, and its function is similar, so it will not be described again here.

[0096] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the vehicle-associated goods filtering method provided in any of the foregoing method embodiments.

[0097] The device embodiments described above are merely illustrative. 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 modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0098] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0099] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0100] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for filtering goods associated with vehicles, characterized in that, include: Heterogeneous product data from multiple data sources is received through an asynchronous message mechanism, and the heterogeneous product data is stored in the database; Vehicle model compatibility information is extracted from the heterogeneous product data, and the vehicle model code corresponding to the vehicle model compatibility information is determined. A minimum inventory unit is constructed based on the vehicle model code, wherein each minimum inventory unit is associated with a set of vehicle model codes; the set of vehicle model codes consists of all vehicle model codes corresponding to the minimum inventory unit. Receive the vehicle model code of the bound vehicle and the dynamic status parameter set of the vehicle terminal reported by the vehicle terminal; Based on the reported vehicle model codes, the products corresponding to the smallest inventory unit associated with the set of associated vehicle model codes are selected, and it is verified whether the operating environment conditions corresponding to the product match the set of dynamic status parameters. The product data that passes the verification is then sent to the vehicle terminal.

2. The method according to claim 1, characterized in that, Constructing the minimum inventory unit based on the vehicle model code includes: For structured product data provided by the car manufacturer's internal resource system, the bound vehicle model code is directly obtained, and the minimum inventory unit is constructed based on the vehicle model code; For unstructured product data provided by third-party suppliers, a parsing agent based on natural language understanding is used to extract vehicle model compatibility information and operating environment conditions from the natural language text fields of the unstructured product data. The vehicle model compatibility information is mapped to vehicle model codes, and the minimum inventory unit is constructed based on the vehicle model codes.

3. The method according to claim 2, characterized in that, The extraction of vehicle model compatibility information and operating environment conditions from the natural language text fields of the unstructured product data using a parsing agent based on natural language understanding includes: The vehicle model name, vehicle series name, system version requirements, and hardware configuration requirements are extracted from the natural language text field using the pre-set prompt word templates in the intelligent agent. The extracted vehicle model name and vehicle series name are used as the vehicle model adaptation information, and the extracted system version requirements and hardware configuration requirements are used as the operating environment conditions.

4. The method according to claim 3, characterized in that, Mapping vehicle model adaptation information to predefined vehicle model codes includes: When the extracted information is a vehicle series name, the vehicle series name is mapped to a vehicle series code, and all vehicle model codes corresponding to the vehicle series code are obtained; The extracted vehicle model name is matched with a pre-stored vehicle model code mapping table, and the corresponding vehicle model code is output.

5. The method according to claim 4, characterized in that, The method further includes: When the extracted vehicle model name cannot match any entry in the vehicle model code mapping table, the semantic similarity between the vehicle model name and each vehicle model name in the mapping table is determined, and the vehicle model code corresponding to the vehicle model name with a similarity higher than a preset threshold is selected as a candidate output, and the output is marked as a fuzzy matching result.

6. The method according to claim 1, characterized in that, After constructing the minimum inventory unit based on the vehicle model code, the method further includes: When multiple minimum inventory units are combined into one product, the intersection of the vehicle model code sets associated with all the combined minimum inventory units is calculated, and the intersection is used as the associated vehicle model code set of the combined product.

7. The method according to claim 1, characterized in that, Based on the reported vehicle model codes, the products corresponding to the smallest inventory unit associated with the set of associated vehicle model codes are selected, and the operating environment conditions corresponding to the product are verified to match the dynamic status parameter set. The product data that passes the verification is then sent to the vehicle terminal, including: Based on the reported vehicle model codes, retrieve the set of vehicle model codes associated with each minimum inventory unit, retain the minimum inventory unit corresponding to the set of vehicle model codes, and obtain the product corresponding to the minimum inventory unit; The system obtains the operating environment conditions corresponding to the product and compares the operating environment conditions with the dynamic status parameter set one by one. When all operating environment conditions are met, the product data is sent to the vehicle terminal. The dynamic status parameter set includes at least one of the system version, remaining storage space, and hardware health status of the vehicle terminal.

8. A product sorting device associated with a vehicle, characterized in that, include: The first processing module is used to receive heterogeneous product data from multiple data sources through an asynchronous message mechanism and store the heterogeneous product data in a database. The second processing module is used to extract vehicle model compatibility information from the heterogeneous product data, determine the vehicle model code corresponding to the vehicle model compatibility information, and construct a minimum inventory unit based on the vehicle model code, wherein each minimum inventory unit is associated with a set of vehicle model codes; the set of vehicle model codes consists of all vehicle model codes corresponding to the minimum inventory unit. The third processing module is used to receive the vehicle model code of the bound vehicle and the dynamic status parameter set of the vehicle terminal reported by the vehicle terminal. The fourth processing module is used to filter out the products corresponding to the smallest inventory unit associated with the reported vehicle model code set, verify whether the operating environment conditions corresponding to the product match the dynamic status parameter set, and send the verified product data to the vehicle terminal.

9. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory is used to store a computer program; the processor is used to execute the computer program to implement the vehicle-related product screening method according to any one of claims 1-7.

10. A storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the vehicle-related product screening method as described in any one of claims 1-7.

Images