A method and system for realizing brand customization based on intelligent analysis

Abstract

This invention relates to the field of software development and discloses a method and system for brand customization based on intelligent analysis. The method includes: preprocessing user requirement documents to output structured and unstructured data containing configuration information; querying a relational database for corresponding brand specifications to determine if the configuration information in the structured data meets the brand specifications; if so, outputting the configuration data; otherwise, correcting and outputting the corrected configuration parameters; querying a vector database for several historical cases most similar to the unstructured data; fusing the above data, inputting the generated prompts into a large model, and outputting JSON configuration data; performing syntax and semantic validation on the JSON configuration data, and transmitting the validated or corrected JSON configuration data to a low-code engine for rendering. This invention can improve the accuracy of brand customization configuration while ensuring that the customization system can respond promptly to changes in brand strategy.

Description

Technical Field

[0001] This invention relates to the field of software development, and more specifically, to a method and system for achieving brand customization based on intelligent analysis. Background Technology

[0002] Digital brand applications primarily target scenarios such as brand marketing, user interface design, and implementation of corporate identity standards. They provide users with services including website generation, H5 activity pages, and brand management backends, and require ensuring consistency in interface elements such as brand colors, fonts, and layouts.

[0003] Currently, intelligent configuration systems based on low-code platforms face numerous technical bottlenecks in brand digital application development, primarily manifested in the following three aspects: First, there are structural transformation defects at the semantic parsing level of requirements. Traditional brand customization systems lack effective parsing capabilities for unstructured brand requirement documents input by users, specifically in the following ways: (1) there are semantic ambiguities in natural language descriptions, such as subjective expressions like "tech blue" in color descriptions that cannot be accurately mapped to HEX standard color coding; (2) cross-modal information extraction is difficult, lacking automated recognition methods for non-text elements such as color card images and font styles embedded in the document; (3) general large models cannot adapt to enterprise private specifications, resulting in low accuracy of the model in configuration scenarios for core parameters such as brand color values ​​and font sizes. Second, there are data collaboration barriers at the knowledge fusion level. Existing technical solutions have failed to effectively solve the collaboration problem between public large models and enterprise private knowledge bases: (1) enterprise private brand specifications are not included in the model training data; (2) the static knowledge base update mechanism is missing, failing to reflect changes in brand strategy in real time; (3) traditional keyword retrieval technology is difficult to achieve cross-modal feature matching, resulting in a lower reuse rate of historical cases than industry requirements. Third, there are defects in the dynamic environment adaptation of the system reliability. The existing configuration engine exhibits the following technical deficiencies in the operating environment: (1) Silent changes to the API interface cause historical configuration instructions to become invalid, and there is a lack of compatibility guarantee mechanism for version changes; (2) In the environment of multiple API versions running in parallel, the system cannot automatically identify and adapt to different version parameter specifications; (3) The error diagnosis module only provides basic error information and lacks the ability to generate correction suggestions for configuration items, resulting in the average fault repair time exceeding the acceptable threshold. The above technical defects restrict the large-scale application of low-code platforms in brand digital construction. Therefore, it is urgent to propose innovative solutions. Summary of the Invention

[0004] The purpose of this invention is to address at least one deficiency in the existing technology and provide a method and system for brand customization based on intelligent analysis. This invention can improve the accuracy of brand customization configuration and ensure that the customization system can respond promptly to changes in brand strategy.

[0005] To address the aforementioned technical problems, in a first aspect, the present invention provides a method for achieving brand customization based on intelligent analysis, the method comprising the following steps:

[0006] Obtain the user's requirements document, preprocess the requirements document, and output structured and unstructured data containing configuration information;

[0007] Query the brand specifications corresponding to the structured data in the relational database, and determine whether the configuration information contained in the structured data meets the brand specifications. If it does, output the configuration data; otherwise, output the corrected configuration parameters.

[0008] Search the vector database for several historical cases that are most similar to the unstructured data;

[0009] The system integrates several historical cases, configuration data or corrected configuration parameters, and unstructured data, and inputs the resulting prompts into the large model, outputting JSON configuration data.

[0010] The JSON configuration data is sequentially subjected to syntax and semantic validation. Semantic validation is triggered only if syntax validation passes. If syntax validation fails, the processing flow is terminated and an error is reported. If both syntax and semantic validation pass, the JSON configuration data is transmitted to the low-code engine for rendering. If syntax validation passes but semantic validation fails, error analysis is performed and automatic correction is implemented. Finally, the corrected JSON configuration data is transmitted to the low-code engine for rendering.

[0011] Secondly, the present invention also provides a system for brand customization based on intelligent analysis, the system being based on the method proposed in the first aspect, comprising:

[0012] Preprocessing module: used to obtain the user's requirement document, preprocess the requirement document, and output structured and unstructured data containing configuration information;

[0013] The first query module is used to query the brand specifications corresponding to the structured data in the relational database, and determine whether the configuration information contained in the structured data meets the brand specifications. If it does, the configuration data is output; otherwise, the corrected configuration parameters are output.

[0014] The second query module is used to query the vector database for several historical cases that are most similar to the unstructured data.

[0015] Fusion module: used to merge the aforementioned historical cases, the configuration data or the corrected configuration parameters, and the unstructured data, and input the fused prompts into the large model and output JSON configuration data;

[0016] The validation and rendering module is used to perform syntax and semantic validation on the JSON configuration data in sequence. Semantic validation is triggered only if the syntax validation passes. If the syntax validation fails, the processing flow is terminated and an error is reported. If both the syntax validation and semantic validation pass, the JSON configuration data is transmitted to the low-code engine for rendering. If the syntax validation passes but the semantic validation fails, error analysis is performed and automatic correction is performed. Finally, the corrected JSON configuration data is transmitted to the low-code engine for rendering.

[0017] Compared with the prior art, the beneficial effects of the technical solution of the present invention are:

[0018] This invention avoids the problems of semantic ambiguity in natural language descriptions and difficulties in cross-modal information extraction found in existing customization systems through preprocessing such as document analysis and data cleaning. Furthermore, it improves the accuracy of brand customization configuration by retrieving enterprise brand specifications from a relational database and several historical cases most similar to user needs from a vector database, and then generating JSON configuration data using the fused input model. This avoids the problem of existing general-purpose models being unable to adapt to enterprise-specific specifications, resulting in low accuracy in configuring core parameters such as brand color values ​​and font sizes. Moreover, through syntax and semantic validation of the JSON configuration data, as well as error analysis and correction, it avoids the problems of existing customization systems failing to reflect brand strategy changes in real time and failing to provide suggestions for correcting configuration items, further improving the accuracy of brand customization configuration while ensuring the system can respond promptly to brand strategy changes. Attached Figure Description

[0019] Figure 1 This is a flowchart of a method for brand customization based on intelligent analysis, which is an embodiment of the present invention.

[0020] Figure 2 This is a flowchart of a method for brand customization based on intelligent analysis according to Embodiment 1 of the present invention.

[0021] Figure 3 This is a system block diagram of a brand customization system based on intelligent analysis, as described in Embodiment 3 of the present invention.

[0022] Figure 4 This is a flowchart of the API monitoring service in Embodiment 1 of the present invention.

[0023] Figure 5 This is a flowchart illustrating the generation of the vector database in Embodiment 1 of the present invention. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0025] Example 1

[0026] Please see Figure 1-2 A preferred embodiment of the present invention provides a method for brand customization based on intelligent analysis, comprising:

[0027] Step S1: Obtain the user's requirement document, preprocess the requirement document, and output structured and unstructured data containing configuration information;

[0028] Step S2: Query the brand specifications corresponding to the structured data in the relational database, and determine whether the configuration information contained in the structured data meets the brand specifications. If it does, output the configuration data; otherwise, output the corrected configuration parameters.

[0029] Step S3: Query the vector database for several historical cases that are most similar to the unstructured data;

[0030] Step S4: Integrate the several historical cases, the configuration data or the corrected configuration parameters, and the unstructured data, and input the generated prompts into the large model and output JSON configuration data;

[0031] Step S5: Perform syntax and semantic validation on the JSON configuration data sequentially. Semantic validation is triggered only if the syntax validation passes. If the syntax validation fails, the processing flow is terminated and an error is reported. If both the syntax and semantic validations pass, the JSON configuration data is transmitted to the low-code engine for rendering. If the syntax validation passes but the semantic validation fails, error analysis is performed and automatic correction is implemented. Finally, the corrected JSON configuration data is transmitted to the low-code engine for rendering.

[0032] This embodiment avoids the problems of semantic ambiguity in natural language descriptions and difficulties in cross-modal information extraction found in existing customization systems through preprocessing such as document analysis and data cleaning. It also improves the accuracy of brand customization configuration by retrieving enterprise brand specifications from a relational database and several historical cases most similar to user needs from a vector database, and then generating JSON configuration data using the fused large-scale input model. This avoids the problem of existing general-purpose models being unable to adapt to enterprise-specific specifications, resulting in low accuracy in configuring core parameters such as brand color values ​​and font sizes. Furthermore, through syntax and semantic validation of the JSON configuration data, as well as error analysis and correction, it avoids the problems of existing customization systems failing to reflect brand strategy changes in real time and failing to provide suggestions for correcting configuration items, further improving the accuracy of brand customization configuration while ensuring the system can respond promptly to brand strategy changes.

[0033] In a feasible embodiment, step S1, the preprocessing includes document analysis and / or data cleaning. The document analysis, based on a deep learning model (Mask R-CNN), sequentially performs region detection and region classification on the requirement document. Region detection is used to locate text regions in the requirement document. Optionally, it also includes image regions and table regions. Region detection divides the requirement document into multiple parts with different characteristics, allowing for targeted processing of each region later. In implementing region detection, document layout information, such as line spacing, column spacing, margins, font size, and style variations, is used to determine the boundaries of different regions. For example, larger line spacing may indicate separation between paragraphs, thus dividing different text block regions; significant changes in font size and style may distinguish between headings and body text. For image regions, image recognition algorithms based on pixel features, color distribution, and edge detection are used to detect and locate image content in the document, identifying regions with image features. For table regions, the position and extent of the table are determined by analyzing line patterns, cell arrangement rules, and text alignment within specific areas. For example, it can identify grid structures formed by combinations of horizontal and vertical lines, as well as the regular arrangement of text within a table, thereby accurately detecting table regions. In terms of region classification implementation,

[0034] Region classification, building upon region detection, further subdivides the identified regions, clarifying the specific type of each region. For example, text regions are classified as titles, subtitles, and / or body text; image regions as brand color charts and / or product images; and table regions as structured data tables. In implementing region classification, content features within each region are matched and analyzed according to predefined rules and patterns. For text regions, font size, bolding, underlining, and other formatting features, as well as the text's position in the document structure (e.g., at the top of the page, at the beginning of a chapter), determine whether it is a title, subtitle, or body text. For image regions, content features such as the presence of chart elements or specific graphic symbols distinguish between ordinary images and charts. Optionally, semantic information of the region content can also be considered for classification. For example, analyzing the semantics of words, sentence structure, and context in text regions further confirms their text type. For chart regions, understanding the type of information expressed by the chart (e.g., data comparison, process display) allows for more accurate chart classification. Text, images, and tables are all used to assist the large model in generating configuration prompts.

[0035] The data cleaning process involves using natural language processing (NLP) technology to sequentially clean, perform semantic analysis, and extract entities from the categorized text. The resulting data is then combined with dynamic knowledge base queries to generate unstructured data and structured data containing configuration information. Specifically, data cleaning includes: (1) Text cleaning: using SpaCy's text preprocessing function to clean information unrelated to brand customization, such as punctuation marks, special characters, HTML tags, etc.; (2) Word segmentation: using SpaCy's word segmentation function to split Chinese text into individual words or phrases; (3) Part-of-speech tagging and named entity recognition: using SpaCy's part-of-speech tagging function to identify nouns, verbs, adjectives, etc. in the text, and using named entity recognition function to identify entities such as brand name (TCL), brand theme color, font, etc. in the text; (5) Information extraction: after finding the named entities, SpaCy is used to determine the specific text and entity of each entity, and this information is organized into a list, where each element is a small dictionary containing entity text and type label; (6) Outputting structured data: combining the dynamic knowledge base, querying the mapping relationship, converting "Tech Blue" into the standard color value #005A9C. Finally, this list is converted into a JSON format string, where the dynamic knowledge base includes a relational database and a vector database. It should be noted that during the data standardization (structuring) process, fields containing explicit fields or fields that can be mapped to predefined rules can be standardized. For explicit fields, fields that can be mapped to predefined rules, such as prohibiting gradient colors, or requirements that are subjective descriptions (such as reflecting a sense of technology) or lack predefined rules (such as complex layout requirements), the original text should be retained, and the output should be unstructured data.

[0036] For example, the code for data cleaning and information extraction using SpaCy is as follows:

[0037] doc = nlp("TCL's brand theme color is tech blue, and the title font size is no smaller than 14px")

[0038] entities = [

[0039] {"text": "TCL", "label": "Brand", "entity": "Brand"},

[0040] {"text": "Tech Blue", "label": "Brand Theme Color", "entity": "PrimaryColor"},

[0041] {"text": "14px", "label": "font size", "entity": "FontSize"};

[0042] The code first calls SpaCy's NLP pipeline via NLP to complete basic processing such as word segmentation, part-of-speech tagging, and syntactic analysis. Then, it identifies business-related entities through predefined rules or models. Finally, it combines dynamic knowledge base queries to output structured data containing configuration information. The structured data in this embodiment is as follows:

[0043] {

[0044] "brand": "TCL",

[0045] "primary_color": "#2A5CAA",

[0046] "font_size": {"min_size": 14}

[0047] }

[0048] In this code, "brand": "TCL" indicates that the brand is TCL, "primary_color" indicates that the brand's primary color is 2A5CAA, and "font_size": {"min_size": 14} indicates that the font size is no smaller than 14px.

[0049] In an optional embodiment, step S2 involves querying the brand specifications corresponding to the structured data in a relational database and determining whether the configuration information contained in the structured data meets the brand specifications. Specifically, this includes:

[0050] (1) Determine the brand name based on the structured data;

[0051] (2). Based on the brand name, search the relational database for all versions of the brand specification corresponding to the brand, and sort all brand specifications in descending order according to the effective version number. The search algorithm is SQL, and optionally, it can also be NoSQL query.

[0052] (3) Using the brand specification corresponding to the first ranked version number as the criterion, determine whether the configuration information contained in the structured data meets the brand specification.

[0053] For example, the code for querying brand specifications is as follows:

[0054] SELECT * FROM brand_rules

[0055] WHERE brand='TCL'

[0056] AND rule_type='font_size'

[0057] ORDER BY version DESC

[0058] LIMIT 1

[0059] In this code, WHERE brand='TCL' specifies the exclusive brand TCL; ANDrule_type='font_size'

[0060] The filter rule type is font size; ORDER BY version DESC indicates sorting by version number in descending order, i.e., latest version takes precedence; LIMIT 1 indicates retrieving the latest record. It should be noted that when searching for brand specifications, it is possible to find brand specifications corresponding to version numbers that are not yet valid. Valid brand specifications are not used as criteria to determine whether the configuration information contained in the structured data meets the specifications. Furthermore, the query process for other configuration information such as font color is similar to the above process and will not be elaborated further here.

[0061] In step S2, if the structured data does not meet the corresponding brand specifications, the structured data will give an error message and automatically or manually correct the non-compliant configuration items. Finally, the corrected configuration parameters will be output. For example, if the structured data specifies fontSize: 10, that is, the font size is 10px, but the brand specification is min_size=14, that is, the specification requires the minimum font size to be 14px, then the system will give an error message and automatically or manually adjust it to 14px.

[0062] This embodiment ensures that the system always meets the latest specifications through versioned and structured rule management and querying in the stages of requirement analysis and configuration generation.

[0063] In an optional embodiment, in step S3, several historical cases most similar to the unstructured data are queried in the vector database, specifically including:

[0064] (1). The unstructured data is input into a vector model and encoded to output the corresponding vector, wherein the vector model is an Ada-2 model;

[0065] (2) Calculate the cosine similarity between the vector and each vector in the vector database, and sort all the results from largest to smallest. Select the top-ranked vectors and retrieve the corresponding historical cases from the vector database. The selected vectors can be 2 to 4. For the vector database generation process, please refer to [link to documentation]. Figure 5 .

[0066] For example, suppose a user's unstructured data consists of a tech-themed blue theme and a promotional page design. Then, based on this unstructured data, the following two similar cases can be found in the vector library:

[0067] Historical Case 1:

[0068] json

[0069] {

[0070] "layout": "skewed dynamics",

[0071] "fontSize": 16,

[0072] "color": {

[0073] "primary": "#2A5CAA",

[0074] "secondary": "#F5F5F5"

[0075] },

[0076] "components": ["Dynamic Carousel", "3D Product Showcase"]

[0077] };

[0078] In this context, "layout": "skewed dynamic" indicates that the layout type is skewed dynamic, "fontSize": 16 indicates that the font size is 16px, "primary": "#2A5CAA" indicates that the primary color is #2A5CAA, "secondary": "#F5F5F5" indicates that the secondary color is #F5F5F5, and "components": ["dynamic carousel", "3D product display"] indicates that the core components are dynamic carousel and 3D product display.

[0079] Historical Case 2

[0080] {

[0081] "layout": "Minimalist grid",

[0082] "fontSize": 18,

[0083] "color": {

[0084] "primary": "#2A5CAA",

[0085] "secondary": "#E0E0E0"

[0086] },

[0087] "components": ["Data Dashboard", "Comparison Table"]

[0088] };

[0089] In this context, "layout": "minimalist grid" indicates that the layout type is minimalist, "fontSize": 18 indicates that the font size is 18px, "primary": "#2A5CAA" indicates that the primary color is #2A5CAA, "secondary": "#E0E0E0" indicates that the secondary color is #E0E0E0, and "components": ["data dashboard", "comparison table"] indicates that the core components are: data dashboard and comparison table.

[0090] This embodiment helps ensure the accuracy and flexibility of customized generation by querying historical cases and using them to assist in generating prompts.

[0091] In this embodiment, the differences and collaborations between relational databases and vector databases can be found in Table 1 below:

[0092] Table 1: Differences and Collaboration Tables between Relational Databases and Vector Databases

[0093]

[0094] In an optional embodiment, in step S4, the several historical cases, the configuration data or the corrected configuration parameters, and the unstructured data are merged, and the fused prompt is input into the large model, and JSON configuration data is output. In this embodiment, if the structured data meets the brand specifications, the configuration data is used to assist in generating the prompt; if the structured data does not meet the brand specifications, the corrected configuration parameters are used to assist in generating the prompt. Furthermore, the priority of the reference case in the prompt can be dynamically adjusted based on the cosine similarity between the historical cases and the unstructured data.

[0095] For example, combining the above content, the generated prompt is as follows:

[0096] Brand guidelines (must be followed)

[0097] - Primary color value: Must be #2A5CAA (Tech Blue)

[0098] - Font size: 14-20px (current value detected: 14px)

[0099] - Gradient colors are prohibited.

[0100] ### Reference Case (For Reference)

[0101] - **Case ID**: C001

[0102] - Layout type: Slanted dynamic

[0103] - Font size: 16px

[0104] - Color scheme: Primary color #2A5CAA, Secondary color #F5F5F5

[0105] - Core components: Dynamic carousel, 3D product display

[0106] - **Case ID**: C002

[0107] - Layout type: Minimalist grid

[0108] - Font size: 18px

[0109] - Color scheme: Primary color #2A5CAA, Secondary color #E0E0E0

[0110] - Core components: Data dashboards, comparison tables

[0111] ### Original User Request

[0112] "TCL's brand page needs to reflect a sense of technology and use a blue color scheme."

[0113] The large model can be configured based on the TCL brand JSON generated by the above prompt, which will not be elaborated here.

[0114] This embodiment obtains enterprise brand specifications from a relational database and several historical cases most similar to user needs from a vector database. Then, it generates JSON configuration data using the fused input model. This avoids the problem that existing general-purpose models cannot adapt to enterprise private specifications, resulting in low accuracy of the model in configuration scenarios of core parameters such as brand color values ​​and font size. This improves the accuracy of brand customization configuration.

[0115] In an optional embodiment, step S5 includes checking the validity of the JSON format, the existence of required fields, and the validity of the basic type of the field values.

[0116] For example, if the JSON configuration data contains {"color": {"primary": 123}} → the field value type is incorrect and should be string.

[0117] The semantic verification includes color verification, font verification, and layout verification. The color verification includes color format verification and color value range verification, and the font verification includes font name verification and font size verification.

[0118] For example, color format validation: The code to verify whether it conforms to HEX or HEX+Alpha format is as follows:

[0119] def validate_color_format(color: str) ->bool:

[0120] hex_re = r'^#([A-Fa-f0-9]{6}|[A-Fa-f0-9]{8})$'

[0121] return re.match(hex_re, ​​color) is not None

[0122] In the code above, the regular expression `def validate_color_format(color: str) ->bool:` means that the color value should start with `#` and match 6 hexadecimal characters (standard HEX, such as `#FF0000`) or 8 hexadecimal characters (HEX+Alpha, such as `#FF0000FF`, where the last two digits represent transparency).

[0123] Color value range validation: The code for validating whether the color values ​​match the brand's standard color values ​​is as follows:

[0124] def validate_color_value(color: str, brand: str) ->bool:

[0125] allowed = knowledge_base.get_brand_colors(brand)

[0126] return color.lower() in allowed

[0127] In the code above, `def validate_color_value(color: str, brand: str) ->bool` indicates that the list of allowed colors for the brand is retrieved from the knowledge base. `allowed = knowledge_base.get_brand_colors(brand)` checks if the color value is in the allowed list; it returns `True` if it is, and `False` otherwise. For example, if the input is `{ "color": { "primary": "#2A5CAA"}}`, the validation will fail: the primary color for the TCL brand should be #E31937.

[0128] During the validation process, if syntax validation passes but semantic validation fails, error analysis is performed and automatic corrections are made. Finally, the corrected JSON configuration data is transmitted to the low-code engine for rendering. This includes:

[0129] (1). Specific reasons for failure of location verification: Request the brand specification in the relational database, and perform color, font and layout verification on the JSON configuration data according to the brand specification. When the verification fails, trigger the error root cause analysis / automatic correction strategy and output the error reason. The error reason includes field-level error and value range error.

[0130] (2). Dynamically accommodate unknown extended fields and trigger rule upgrades, while generating interpretable error reports and correction strategies: If the error is caused by a field-level error, the API change record query process is triggered, that is, the differences between historical versions are compared to confirm whether the field has been abandoned, renamed or added, and the type of the field-level error is determined. The types include API version upgrade abandonment or renaming, existence of unknown extended fields and non-sensitive fields. If the type of the field-level error is API version upgrade abandonment or renaming, the automatic correction strategy is triggered to correct the JSON configuration data. If the type of the field-level error is existence of unknown extended fields, the JSON configuration data is not corrected, and the API monitoring service is triggered.

[0131] (3) If the error is due to a value range error, determine whether the value range error violates brand specifications. If it does, trigger an automatic correction strategy to correct it according to brand specifications. For example, if a field value does not conform to brand specifications (e.g., the color field format should support HEX+Alpha format but is configured as #E31937), or the font size exceeds the allowed range (e.g., the maximum font size is 16px but is configured as 18px), then trigger an automatic correction strategy to correct it according to brand specifications. Otherwise, manual investigation is performed. The investigation includes, but is not limited to, data consistency, such as whether the dependencies between different fields are correct. For example, if a component requires a specific color, does it conflict with other configurations? Security issues, such as whether the color value may contain malicious code.

[0132] Furthermore, the API monitoring service specifically includes:

[0133] (1). Obtain the unknown extended field from the JSON configuration data;

[0134] (2). Call the sensitive word library to check whether the unknown extended field involves sensitive information. If it does, the process ends and rendering is not performed. Otherwise, record the metadata of the unknown extended field and allow the request to pass. The metadata includes the name, type, rule standard, and example value of the unknown extended field. In this embodiment, non-sensitive fields refer to fields that are not defined by existing rules in business rule verification but will not pose a direct risk to system security, user privacy, or core business processes. The judgment criteria mainly include the following aspects: 1. Data sensitivity: Non-sensitive: does not involve user privacy (such as name, phone number), security authentication (such as password, token) or sensitive business data (such as transaction amount, account information). Sensitive: involves personal identification information (PII), financial data, permission identifiers, etc. 2. Business impact: Non-sensitive: the absence or error of the field will not cause the core business logic to fail or the data to be inconsistent (such as interface style configuration, additional function switch). Sensitive: the absence or error of the field will directly affect the core function (such as order status, payment method). 3. Compliance requirements: Non-sensitive: the field is not subject to mandatory constraints by laws, regulations, or industry standards (such as theme color, font size). Sensitive: Fields must comply with GDPR, PCI-DSS, and other compliance requirements (such as user authorization identifiers and encryption keys). 4. Contextual Relevance: Non-sensitive: Fields have low relevance to the current business process (such as debug flags and log levels). Sensitive: Fields are strongly related to access control and data ownership (such as role permissions and tenant IDs).

[0135] (3) Establish corresponding verification rule proposals based on the metadata and retain them in the rule base. The verification rule proposals take effect in the next verification request cycle. In this embodiment, the lifecycle management of metadata includes: Temporary storage: Metadata is temporarily stored in a cache (such as Redis) or a temporary database table for quick access by the rule engine. Post-rule upgrade processing: If a field is officially included in the rule base, the metadata is converted into historical archives. If a field has not been used for a long time, a cleanup strategy can be set (such as automatic deletion after 30 days of retention).

[0136] It should be noted that triggering the API monitoring service also includes updates to the API documentation or knowledge base. Specifically: 1. API documentation updates refer to changes in the API interface definitions provided by the low-code engine, including but not limited to: adding / deprecating fields (e.g., adding the `newTheme` field and deprecating the `primaryColor` field); adjusting parameter formats (e.g., expanding the color field from `hex` to `hex_alpha`); and version upgrades (e.g., upgrading from v3.1 to v3.2, with changes to field naming rules). 2. Knowledge base updates refer to changes in enterprise brand specifications or historical case data, including: expanding brand rules (e.g., adding allowed secondary colors #F5F5F5); adding case study templates (e.g., adding a "Technology-themed promotional page" design template); and adjusting thresholds (e.g., expanding the font size range from 12-16px to 14-20px).

[0137] Please see Figure 4 The API monitoring service architecture diagram is shown in Table 2 below. The functions of each module are also shown in Table 2.

[0138] Table 2: Function Table of Each Module of API Monitoring Service

[0139]

[0140] Example 2

[0141] This embodiment is a specific experimental process of the method proposed in Embodiment 1. The user-uploaded PDF document "TCL 2024 Brand Visual Specifications" includes: "The main brand color is 'Tech Blue', the title font is 'Founder TCL HeiTi', and the minimum font size is 14px; the page layout must reflect a sense of technology, gradient colors are prohibited, and dark mode is supported." The specific steps are as follows:

[0142] 1. Multimodal document parsing:

[0143] 1.1 Document Analysis: Using a Mask R-CNN-based visual segmentation model, the title, body text, and color swatch image regions in the document were identified. The title text, "TCL 2024 Brand Visual Specifications," was extracted as metadata.

[0144] 1.2 OCR and Entity Extraction:

[0145] Extracting the main text using Tesseract OCR: "The brand's primary color is tech blue; the title font is Founder TCL Heiti, with a minimum font size of 14px; gradient colors are prohibited." Performing Named Entity Recognition (NER) using SpaCy:

[0146] The recognition results are as follows:

[0147] {

[0148] "color": {"text": "Tech Blue", "label": "COLOR", "params": {"value": "#2A5CAA"}},

[0149] "font_family": {"text": "Founder TCL Bold", "label": "FONT"},

[0150] "font_size": {"text": "14px", "label": "FONT_SIZE", "params": {"min":14}},

[0151] "prohibition": {"text": "Gradient colors are prohibited", "label": "PROHIBITION", "params": {"gradient": false}}

[0152] };

[0153] The final output structured data is as follows:

[0154] "brand": "TCL",

[0155] "primary_color": "#Tech Blue",

[0156] "font_family": "Founder TCL Bold",

[0157] "font_size": {"min": 14},

[0158] "gradient": false, / / Gradient colors are prohibited;

[0159] The output unstructured data: The page layout should reflect a sense of technology and support dark mode.

[0160] 2. Dynamic Knowledge Base Retrieval and Prompt Generation

[0161] 2.1 Interaction with the dynamic knowledge base (including relational databases and vector databases):

[0162] 1). Brand specification query, the query code is as follows:

[0163] SELECT * FROM brand_rules

[0164] WHERE brand='TCL' AND rule_type='color'

[0165] ORDER BY version DESC LIMIT 1

[0166] In the code above, `WHERE brand='TCL' AND rule_type='color'` means filtering for the brand TCL and using color-related rules. `ORDER BY version DESC` sorts by version number in descending order, meaning the latest version comes first. `LIMIT 1` means only the latest record is retrieved. The query results are as follows:

[0167] {

[0168] "primary_color": "#2A5CAA",

[0169] "allowed_formats": ["hex"],

[0170] "version": "v3.2"

[0171] };

[0172] In the code above, "primary_color": "#2A5CAA" indicates that the HEX color value of the brand's primary color is #2A5CAA, "allowed_formats": ["hex"] indicates the specified format for restricting the use of colors in the system, and "version": "v3.2" indicates the version identifier of the current specification, used to track rule change history and manage multiple versions.

[0173] 2) Interact with the vector database to retrieve historical cases. The code is as follows:

[0174] query = embed("Tech Blue Tech Layout")

[0175] top_cases = vector_db.search(query, top_k=2) # Returns cases C001 and C002

[0176] In the code above, `query = embed("Tech Blue Tech Sense Layout")` means that the system calls the `embed` function to convert "Tech Blue Tech Sense Layout" into a numerical form, i.e., a vector, for easier computer processing and analysis. `vector_db` is a vector database that stores a large amount of case data. Each case is converted into a vector form. `top_cases = vector_db.search(query, top_k=2)` returns cases C001 and C002, indicating that the system queries the vector database for the two historical cases most similar to the previously converted unstructured data, and finally outputs the historical cases C001 and C002.

[0177] The interactive search results are as follows:

[0178] Case C001: Slanted dynamic layout, main color #2A5CAA, font size 16px, includes "3D product display" component.

[0179] Case C002: Minimalist grid layout, main color #2A5CAA, font size 18px, includes a "data dashboard" component.

[0180] 2.1 Generate a prompt:

[0181] prompt = f"""

[0182] Please generate a brand configuration JSON that meets the following requirements:

[0183] ### Brand Guidelines (Must be followed)

[0184] - Primary color value: Must be #2A5CAA (Tech Blue)

[0185] - Font: Founder TCL Heiti, font size ≥ 14px

[0186] - Gradient colors are prohibited.

[0187] ### Reference Case

[0188] - Case C001: Slanted Dynamic Layout, Font Size 16px

[0189] - Case C002: Minimalist grid layout, font size 18px

[0190] ### Original User Request

[0191] "The TCL brand page needs to reflect a sense of technology and support dark mode."

[0192] """;

[0193] 3. Input a large model to generate JSON configuration data;

[0194] 4. Business rule validation (i.e., syntax and semantic validation) and intelligent correction:

[0195] 4.1 Multi-level verification:

[0196] 1) Syntax validation: Verify the validity of the JSON format; the result is successful.

[0197] 2) Semantic validation:

[0198] Color validation: The primary color #2A5CAA conforms to the specification, and gradient: false satisfies the requirement of disabling gradient colors.

[0199] Font validation: Founder TCL Heiti is in the list of allowed fonts, and its font size of 16px conforms to the minimum constraint of 14px.

[0200] 3) Environment compatibility verification:

[0201] The low-code engine API version is detected to be v3.2, and the field name change needs to be adapted (layout.type → layout_template).

[0202] 4.2 Automatic Correction Strategy:

[0203] actions:

[0204] - type: field_rename

[0205] source: layout.type

[0206] target: layout_template

[0207] - type: value_map

[0208] field: layout_template

[0209] mapping: {

[0210] "Minimalist": "grid_minimalist",

[0211] "Tilt Dynamics": "dynamic_tilt"

[0212] };

[0213] In the above code, source: layout.type target: layout_template means renaming layout.type to layout_template, and - type: value_map means performing value conversion on the renamed field.

[0214] The corrected configuration is as follows:

[0215] {

[0216] "brand": "TCL",

[0217] "theme": {

[0218] "color": {"primary": "#2A5CAA", "secondary": "#F5F5F5", "gradient": false},

[0219] "fonts": {"fontFamily": "Fangzheng TCL Boldface", "fontSize": 16},

[0220] "dark_mode": true

[0221] },

[0222] "layout_template": "grid_minimalist",

[0223] "components": ["Data Dashboard", "Comparison Table"], and correct the inconsistent content.

[0224] 5. API Monitoring and Dynamic Compatibility

[0225] 5.1 Handling of Unknown Extended Fields:

[0226] The new field "dark_mode": true is added in the user request.

[0227] Dynamic Compatibility: Temporarily release and record metadata, as follows:

[0228] {

[0229] "field": "dark_mode",

[0230] "type": "boolean",

[0231] "sample_values": [true],

[0232] "source_request": "req_20240320_001"

[0233] }

[0234] Generate rule upgrade proposals as follows:

[0235] {

[0236] "field": "dark_mode",

[0237] "type": "boolean",

[0238] "default": false,

[0239] Description: Dark Mode Toggle

[0240] } ;

[0241] 5.2 Rule Issuance:

[0242] Automatic mode: The validation rule base is updated through the CI / CD pipeline, and the new rules are automatically applied to subsequent requests.

[0243] 5.3 The low-code engine supports newly added extended fields.

[0244] 5.3.1. Dynamic Data Model Support

[0245] schema-less or flexible schema design:

[0246] Low-code engines typically employ schema-less data stores (such as MongoDB) or support dynamic field extensions, allowing the inclusion of undefined fields (such as dark_mode) in the configuration.

[0247] Example:

[0248] {

[0249] "theme": {

[0250] "dark_mode": true / / Dynamically extended field

[0251] }

[0252] }

[0253] Low-code engine behavior: Store or pass the field directly without pre-defining a data model.

[0254] 5.3.2. Rule-Driven Dynamic Adaptation

[0255] Validation rules are separated from rendering logic:

[0256] Validation rules: After updating via CI / CD, only the validity of fields (such as type and format) is controlled, and low-code engines are not required to support it in advance.

[0257] Rendering logic: The low-code engine can parse unknown fields through conditional statements or dynamic templates.

[0258] / / Pseudocode: Switch themes based on dark_mode

[0259] if (config.dark_mode) {

[0260] applyDarkTheme();

[0261] } else {

[0262] applyLightTheme();

[0263] } ;

[0264] 5.3.3. API Monitoring and Automatic Mapping

[0265] API version compatibility:

[0266] If the low-code engine API is upgraded (such as by adding a dark_mode field), the system will automatically adapt the request format through traffic mirroring and version mapping rules.

[0267] Example:

[0268] def adapt_request(config, api_version):

[0269] if api_version>= "3.0":

[0270] config["theme"]["dark_mode"]= config.pop("legacy_dark_mode")

[0271] return config;

[0272] 5.3.4. Dynamic UI Generation

[0273] Component-based extension:

[0274] Low-code engines can support new fields through dynamic component loading:

[0275] If dark_mode requires front-end interaction, the system will automatically match a predefined "switch component" or generate basic UI elements.

[0276] Example location:

[0277] {

[0278] "components": [

[0279] {

[0280] "type": "Switch",

[0281] "field": "dark_mode",

[0282] "label": "Dark Mode"

[0283] } ]

[0285] }

[0286] This embodiment illustrates a method for brand customization based on intelligent analysis proposed in Embodiment 1 of the present invention, which can improve the accuracy of brand customization configuration and ensure that the customization system can respond to brand strategy changes in a timely manner.

[0287] Example 3

[0288] like Figure 3 As shown, an embodiment of the present invention provides a system for brand customization based on intelligent analysis, comprising:

[0289] Preprocessing module: used to obtain the user's requirement document, preprocess the requirement document, and output structured and unstructured data containing configuration information;

[0290] The first query module is used to query the brand specifications corresponding to the structured data in the relational database, and determine whether the configuration information contained in the structured data meets the brand specifications. If it does, the configuration data is output; otherwise, the corrected configuration parameters are output.

[0291] The second query module is used to query the vector database for several historical cases that are most similar to the unstructured data.

[0292] Fusion module: used to merge the aforementioned historical cases, the configuration data or the corrected configuration parameters, and the unstructured data, and input the fused prompts into the large model and output JSON configuration data;

[0293] The validation and rendering module is used to perform syntax and semantic validation on the JSON configuration data in sequence. Semantic validation is triggered only if the syntax validation passes. If the syntax validation fails, the processing flow is terminated and an error is reported. If both the syntax validation and semantic validation pass, the JSON configuration data is transmitted to the low-code engine for rendering. If the syntax validation passes but the semantic validation fails, error analysis is performed and automatic correction is performed. Finally, the corrected JSON configuration data is transmitted to the low-code engine for rendering.

[0294] The system proposed in this embodiment is based on the method proposed in Embodiment 1. Therefore, the options proposed in Embodiment 1 are also applicable to this embodiment, and will not be repeated here.

[0295] Obviously, the above embodiments of the present invention are merely examples for clearly illustrating the present invention, and are not intended to limit the implementation of the present invention. Those skilled in the art can make other variations or modifications based on the above description. It is neither necessary nor possible to exhaustively describe all embodiments here. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the claims of the present invention.

Claims

1. A method for brand customization based on intelligent analysis, characterized in that, The method includes the following steps: Obtain the user's requirements document, preprocess the requirements document, and output structured and unstructured data containing configuration information; Query the brand specifications corresponding to the structured data in the relational database, and determine whether the configuration information contained in the structured data meets the brand specifications. If it does, output the configuration data; otherwise, output the corrected configuration parameters. Search the vector database for several historical cases that are most similar to the unstructured data; The system integrates several historical cases, configuration data or corrected configuration parameters, and unstructured data, and inputs the resulting prompts into the large model, outputting JSON configuration data. The JSON configuration data undergoes syntax and semantic validation sequentially. Semantic validation includes color, font, and layout validation. Color validation includes color format and color value range validation, while font validation includes font name and font size validation. Semantic validation is triggered only if syntax validation passes. If syntax validation fails, the processing terminates and an error is reported. If both syntax and semantic validation pass, the JSON configuration data is transmitted to the low-code engine for rendering. If syntax validation passes but semantic validation fails, error analysis is performed and automatic correction is implemented. Finally, the corrected JSON configuration data is transmitted to the low-code engine for rendering. Specifically, this includes: (1). Request the brand specification in the relational database, and perform color, font and layout validation on the JSON configuration data according to the brand specification. When the validation fails, output the error reason, which includes field-level error and value range error. (2) If the error is caused by a field-level error, the API change record query process is triggered to query and determine the type of the field-level error. The types include API version upgrade being abandoned or renamed, and the existence of an unknown extended field that is not a sensitive field. If the type of the field-level error is API version upgrade being abandoned or renamed, the automatic correction strategy is triggered to correct the JSON configuration data. If the type of the field-level error is the existence of an unknown extended field, the JSON configuration data is not corrected, and the API monitoring service is triggered. (3) If the error is caused by a value range error, determine whether the value range error violates the brand specifications. If it does, trigger the automatic correction strategy to correct it according to the brand specifications; otherwise, conduct a manual investigation.

2. The method for brand customization based on intelligent analysis according to claim 1, characterized in that, The preprocessing includes document analysis and / or data cleaning. The document analysis, based on a deep learning model, sequentially performs region detection and region classification on the requirement document. The region detection is used to locate text regions in the requirement document, and the region classification is used to classify the located regions into titles, subtitles, and / or body text. The data cleaning involves using natural language processing technology to sequentially clean, perform semantic analysis, and extract entities from the classified text to obtain the processing results. These results are then combined with dynamic knowledge base queries to generate unstructured data and structured data containing configuration information.

3. The method for brand customization based on intelligent analysis according to claim 1, characterized in that, The step of querying the brand specifications corresponding to the structured data in a relational database and determining whether the configuration information contained in the structured data meets the brand specifications specifically includes: (1) Determine the brand name based on the structured data; (2). Based on the brand name, search the relational database for all versions of the brand specification corresponding to the brand, and sort all brand specifications in descending order according to the effective version number; (3) Using the brand specification corresponding to the first ranked version number as the criterion, determine whether the configuration information contained in the structured data meets the brand specification.

4. The method for brand customization based on intelligent analysis according to claim 3, characterized in that, If the configuration information contained in the structured data does not meet the brand specifications, an error message will be given, and the non-compliant configuration items will be automatically or manually corrected. Finally, the corrected configuration parameters will be output.

5. The method for brand customization based on intelligent analysis according to claim 1, characterized in that, The step of querying the vector database for several historical cases most similar to the unstructured data specifically includes: (1) Encode the unstructured data input vector model and output the corresponding vector; (2). Calculate the cosine similarity between the vector and each vector in the vector database, sort all the calculation results from largest to smallest, take the top-ranked vectors, and obtain the historical cases corresponding to the vectors in the vector database.

6. The method for brand customization based on intelligent analysis according to claim 1, characterized in that, The syntax validation includes checking the validity of the JSON format, the existence of required fields, and the validity of the basic data type of the field values.

7. The method for brand customization based on intelligent analysis according to claim 1, characterized in that, API monitoring services specifically include: (1). Obtain the unknown extended field from the JSON configuration data; (2). Call the sensitive word library to check whether the unknown extended field involves sensitive information. If it does, the process ends and rendering is not performed. Otherwise, record the metadata of the unknown extended field, including the name, type, rule standard and example value of the unknown extended field. (3) Establish corresponding verification rule proposals based on the metadata and retain them in the rule base. The verification rule proposals shall take effect in the next verification request cycle.

8. A system for brand customization based on intelligent analysis, the system being based on the method for brand customization based on intelligent analysis as described in any one of claims 1 to 7, characterized in that, The system includes: Preprocessing module: used to obtain the user's requirement document, preprocess the requirement document, and output structured and unstructured data containing configuration information; The first query module is used to query the brand specifications corresponding to the structured data in the relational database, and determine whether the configuration information contained in the structured data meets the brand specifications. If it does, the configuration data is output; otherwise, the corrected configuration parameters are output. The second query module is used to query the vector database for several historical cases that are most similar to the unstructured data. Fusion module: used to merge the aforementioned historical cases, the configuration data or the corrected configuration parameters, and the unstructured data, and input the fused prompts into the large model and output JSON configuration data; The validation and rendering module is used to perform syntax and semantic validation on the JSON configuration data in sequence. Semantic validation is triggered only if the syntax validation passes. If the syntax validation fails, the processing flow is terminated and an error is reported. If both the syntax validation and semantic validation pass, the JSON configuration data is transmitted to the low-code engine for rendering. If the syntax validation passes but the semantic validation fails, error analysis is performed and automatic correction is performed. Finally, the corrected JSON configuration data is transmitted to the low-code engine for rendering.

Images