Bank branch marketing system access configuration method, device and equipment and storage medium

Abstract

The application discloses a marketing system access configuration method, device and equipment of a branch bank and a storage medium, relates to the technical field of parameter configuration, and discloses a marketing system access configuration method of a branch bank, which comprises the following steps: performing multi-intention recognition and demand splitting according to branch marketing demand data, obtaining target intention data and demand context data; performing execution strategy matching according to the target intention data and the demand context data, performing low-code component configuration generation on the branch marketing demand data according to a target execution strategy, obtaining standardized component configuration data and marketing activity rule data; performing element recognition according to branch interface description data and upstream and downstream connection parameters, and constructing branch marketing configuration data according to the element recognition result; and performing branch marketing system access configuration according to the standardized component configuration data, the marketing activity rule data and the branch marketing configuration data. The automation degree and the reuse capability of the branch bank marketing system access configuration are improved.

Description

Technical Field

[0001] This application relates to the field of parameter configuration technology, and in particular to the method, apparatus, equipment and storage medium for accessing and configuring the marketing system of a bank branch. Background Technology

[0002] As the digitalization of retail banking operations continues to increase, branch marketing activities have evolved from manual outreach through single channels to a collaborative end-to-end process relying on the head office's marketing platform, branch local systems, data warehouses, channel interfaces, and marketing feedback systems. In this business scenario, branches typically need to conduct differentiated operations based on local customer characteristics, list selection rules, marketing outreach channels, customer tag combinations, and campaign execution feedback. Significant differences exist between branches in terms of data sources, channel interfaces, business rules, display styles, and control requirements. Therefore, the branch marketing system needs to support both the head office's batch marketing, real-time marketing, and feedback capabilities, while also adapting to the branch's local data structure, interface specifications, and business requirements. This inherently makes the system construction technically characterized by multi-system collaboration, multi-source data integration, and frequent changes in personalized rules.

[0003] Given the aforementioned technological background, traditional technical solutions typically employ a combination of a unified central platform at the head office and customized development at the branch level. This means the head office provides a unified operational application, a batch marketing platform, a real-time marketing platform, and a marketing feedback system. Branch IT personnel then write adaptation code based on their specific business needs and the head office's interface documentation, developing personalized functions such as list categorization, local control rules, special display formats, and channel content. After development, these functions are integrated with the head office's central platform and the branch's local system for joint testing before deployment. When a new branch needs to integrate, the process of clarifying requirements, developing code, adapting interfaces, conducting upstream and downstream integration testing, and deploying must be repeated. Therefore, the main drawback of traditional technical solutions is that each new branch integration requires repeated customized development and integration testing, resulting in long delivery cycles, poor reusability, and difficulty in supporting rapid expansion and agile iteration of branch business. Summary of the Invention

[0004] The main purpose of this application is to provide a method, device, equipment and storage medium for configuring and accessing a marketing system for a bank branch, aiming to solve the technical problems of low efficiency and long delivery cycle of existing branch marketing systems when accessing different branches.

[0005] To achieve the above objectives, this application proposes a method for configuring access to a bank branch's marketing system, the method comprising: Based on the branch marketing demand data, multi-intent identification and demand decomposition are performed to obtain target intent data and demand context data; The execution strategy is obtained by matching the target intent data and the requirement context data. Based on the target execution strategy, the branch marketing demand data is configured and generated using low-code components to obtain standardized component configuration data and marketing activity rule data. Based on the branch interface description data and upstream and downstream docking parameters, element identification is performed to obtain element identification results, and branch marketing configuration data is constructed based on the element identification results. Configure the bank branch's marketing system access based on the standardized component configuration data, the marketing activity rule data, and the branch marketing configuration data.

[0006] In one embodiment, the step of generating standardized component configuration data and marketing activity rule data by low-code component configuration of the branch marketing demand data according to the target execution strategy includes: Based on the target execution strategy, determine the target demand extraction process corresponding to the branch marketing demand data; Based on the target demand extraction process, configuration parameters are extracted from the branch marketing demand data to obtain marketing configuration parameters. Based on the marketing configuration parameters, low-code component code is generated and component encapsulation is performed to obtain candidate component configuration data; The candidate component configuration data is subjected to field standardization processing to obtain standardized component configuration data. Based on the marketing configuration parameters and the standardized component configuration data, activity registration parameters, list filtering parameters, and channel content parameters are generated, and marketing activity rule data is generated based on the activity registration parameters, the list filtering parameters, and the channel content parameters.

[0007] In one embodiment, the step of determining the target demand extraction process corresponding to the branch marketing demand data based on the target execution strategy includes: The input text length, task complexity, and information content are determined based on the branch marketing needs data. The model routing decision is made based on the input text length, the task complexity data, and the information content data to obtain the model routing result; The candidate requirement extraction process is determined based on the model routing results; The candidate demand extraction process and the target execution strategy are combined to obtain the target demand extraction process corresponding to the branch marketing demand data.

[0008] In one embodiment, the step of matching the execution strategy based on the target intent data and the demand context data to obtain the target execution strategy includes: The number of parameters, structural levels, and number of components to be rendered are determined based on the target intent data. Determine the contextual dependencies and semantic completeness of the intent task based on the required context data; The task complexity is determined based on the number of parameters, the structural hierarchy, the number of components rendered, the context dependencies, and the semantic completeness, and a task complexity label is obtained. The target execution strategy is determined based on the task complexity label among the prompt instruction execution strategy, question execution strategy, and agent collaborative execution strategy.

[0009] In one embodiment, the step of identifying elements based on branch interface description data and upstream / downstream connection parameters to obtain element identification results, and constructing branch marketing configuration data based on the element identification results, includes: Based on the branch interface description data and the upstream and downstream docking parameters, the interface field is scanned to obtain the interface field set; Based on the interface field set, identify the first data element that needs to be transmitted in different branches and has the same field structure; Identify second data elements with non-fixed field structures based on the interface field set; Generate feature recognition results based on the first data element and the second data element; Based on the element identification results, we construct element data format, dynamic slot configuration data, and channel content parameter slots, and generate branch marketing configuration data based on the element data format, the dynamic slot configuration data, and the channel content parameter slots.

[0010] In one embodiment, the steps of constructing the element data format, dynamic slot configuration data, and channel content parameter slots based on the element identification results include: Generate fixed field configuration data based on the first data element in the feature recognition result; Dynamic slot configuration data is generated based on the second data element in the element identification result; Generate feature data format based on the fixed field configuration data and the dynamic slot configuration data; Based on the element data format, channel content parameter slots are created to configure corresponding parameter content for channel content.

[0011] In one embodiment, the step of performing multi-intent identification and demand segmentation based on branch marketing demand data to obtain target intent data and demand context data includes: Natural language semantic analysis is performed on the branch marketing demand data to obtain demand semantic data; The initial intent data is obtained by performing intent matching on the required semantic data according to the pre-set intent library; Based on the initial intent data, the branch marketing demand data is segmented to obtain the basic information subtask, the database configuration subtask, the tag combination subtask, and the channel content configuration subtask. Context extraction is performed on the basic information subtask, the database configuration subtask, the tag combination subtask, and the channel content configuration subtask respectively to obtain subtask context data; The initial intent data corresponding to the same intent are merged to obtain a merged result, and the merged result is associated with the subtask context data to obtain target intent data and requirement context data.

[0012] In addition, to achieve the above objectives, this application also proposes a marketing system access configuration device for a bank branch, which includes: an intent recognition module, used to perform multi-intent recognition and demand splitting based on the branch's marketing demand data to obtain target intent data and demand context data; The strategy matching module is used to perform execution strategy matching based on the target intent data and the demand context data to obtain the target execution strategy; The component generation module is used to generate low-code component configurations for the branch marketing demand data according to the target execution strategy, so as to obtain standardized component configuration data and marketing activity rule data. The element identification module is used to identify elements based on the branch interface description data and upstream and downstream docking parameters, obtain element identification results, and construct branch marketing configuration data based on the element identification results. The access configuration module is used to configure the bank branch's marketing system access based on the standardized component configuration data, the marketing activity rule data, and the branch marketing configuration data.

[0013] In addition, to achieve the above objectives, this application also proposes a marketing system access configuration device for a bank branch, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the marketing system access configuration method for a bank branch as described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the marketing system access configuration method for bank branches as described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the marketing system access configuration method for bank branches as described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: By employing a technical approach that first performs multi-intent identification and demand decomposition on branch marketing demand data, then matches target execution strategies based on target intent data and demand context data, and generates standardized component configuration data and marketing activity rule data according to the target execution strategies, while simultaneously identifying elements in branch interface description data and upstream and downstream connection parameters to construct branch marketing configuration data, and finally combining component configuration, activity rules, and branch marketing configuration data to complete the bank branch marketing system access configuration, personalized marketing demands from branches can be decomposed into processable intent information and context information. This allows different demands to generate reusable data according to matched execution strategies. The system configures the data and transforms the parameters required for branch interfaces and upstream / downstream connections into marketing configuration data needed for access configuration. This transforms the traditional access process, which relies on manual understanding of requirements, writing adaptation code, organizing interface parameters, and repeated debugging, into a configuration-based process centered on requirement identification, strategy matching, component configuration generation, and interface element configuration. This solves the problems of low efficiency in requirement adaptation and long delivery cycles when accessing different branches in existing branch marketing systems. Compared with existing technologies, it improves the automation level and configuration reuse capability of bank branch marketing system access configuration, and shortens the configuration and delivery cycle required for different branches to access the marketing system. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating the first embodiment of the marketing system access configuration method for the bank branch in this application. Figure 2 This is a schematic diagram of the marketing system access configuration method for a bank branch, provided in Embodiment 1 of the method for accessing and configuring the marketing system of this application. Figure 3This is a schematic diagram of the execution strategy design based on task complexity, provided in Embodiment 1 of the method for configuring the marketing system of the bank branch in this application. Figure 4 This is a schematic diagram of a database configuration issue list provided for Example 1 of the method for configuring the marketing system of a bank branch in this application. Figure 5 This is a schematic diagram of the channel content extraction Agent provided in Example 1 of the method for configuring the marketing system of the bank branch in this application. Figure 6 This is a schematic diagram of the collaborative task orchestration process for the marketing system access configuration method of the bank branch in this application; Figure 7 A schematic diagram of the large and small model routing mechanism provided in Embodiment 1 of the marketing system access configuration method for the bank branch of this application; Figure 8 A comparative schematic diagram of the connection schemes provided in Implementation Example 1 of the Marketing System Access Configuration Method for the Bank Branch of this Application; Figure 9 This is a data element classification diagram provided in Embodiment 1 of the method for configuring the marketing system of a bank branch in this application. Figure 10 This is a schematic diagram illustrating the global connection of channel configuration data provided in Embodiment 1 of the marketing system access configuration method for the bank branch of this application; Figure 11 This is a flowchart illustrating the second embodiment of the method for configuring the marketing system of a bank branch in this application. Figure 12 This is a schematic diagram of intent recognition and segmentation provided in Embodiment 2 of the method for configuring the marketing system of a bank branch in this application. Figure 13 A simplified flowchart illustrating the bank branch marketing system access configuration method provided in Embodiment 2 of this application; Figure 14 This is a schematic diagram of the module structure of the marketing system access configuration device for a bank branch, as described in an embodiment of this application. Figure 15 This is a schematic diagram of the hardware operating environment involved in the marketing system access configuration method of a bank branch in this application embodiment.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] The main solution of this application embodiment is as follows: Based on branch marketing demand data, perform multi-intent identification and demand decomposition to obtain target intent data and demand context data; perform execution strategy matching based on the target intent data and demand context data to obtain a target execution strategy; generate low-code component configurations for the branch marketing demand data based on the target execution strategy to obtain standardized component configuration data and marketing activity rule data; perform element identification based on branch interface description data and upstream / downstream connection parameters to obtain element identification results, and construct branch marketing configuration data based on the element identification results; and configure the bank branch's marketing system access based on the standardized component configuration data, the marketing activity rule data, and the branch marketing configuration data.

[0024] In this embodiment, for ease of description, the following description will focus on the marketing system access configuration device of a bank branch.

[0025] Due to the low efficiency and long delivery cycle of existing branch marketing systems when accessing different branches, this application provides a solution. This solution employs a technical approach that first performs multi-intent identification and demand decomposition on branch marketing demand data; then matches target execution strategies based on target intent data and demand context data; and generates standardized component configuration data and marketing activity rule data according to the target execution strategies. Simultaneously, it identifies elements in branch interface description data and upstream / downstream connection parameters to construct branch marketing configuration data. Finally, it combines component configuration, activity rules, and branch marketing configuration data to complete the access configuration of the bank branch marketing system. This approach enables personalized marketing demands from branches to be decomposed into processable intent information and context. This information enables reusable configuration content to be generated according to matching execution strategies for different needs, and transforms the parameters required for branch interfaces and upstream and downstream connections into marketing configuration data required for access configuration. This transforms the traditional access process, which relies on manual understanding of requirements, writing adaptation code, organizing interface parameters, and repeated joint debugging, into a configuration-based processing process centered around requirement identification, strategy matching, component configuration generation, and interface element configuration. This solves the problems of low requirement adaptation efficiency and long delivery cycle of existing branch marketing systems when accessing different branches. Compared with existing technologies, it improves the automation level and configuration reuse capability of bank branch marketing system access configuration, and shortens the configuration and delivery cycle required for different branches to access the marketing system.

[0026] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions, such as a marketing system access configuration device for a bank branch. The following description uses a marketing system access configuration device for a bank branch as an example to illustrate this embodiment and the subsequent embodiments.

[0027] Based on this, this application provides a method for configuring access to a bank branch's marketing system, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the marketing system access configuration method for a bank branch in this application.

[0028] In this embodiment, the method for configuring the marketing system of the bank branch includes steps S10 to S50: Step S10: Perform multi-intent identification and demand decomposition based on the branch marketing demand data to obtain target intent data and demand context data.

[0029] It should be noted that the branch marketing demand data refers to the original business requirements proposed by the branch regarding the setup of marketing campaigns, channel integration, and rule configuration. This typically includes channel access requirements, control rule parameters, customer segmentation criteria, and channel display formats. The branch marketing demand data is input in natural language and serves as the primary basis for subsequent intent recognition and component configuration, stemming from the branch's actual business operation needs.

[0030] Additionally, multi-intent recognition involves semantically parsing natural language input request text to identify multiple independent business configuration intents contained within the text. Multi-intent recognition can break down an input containing multiple configuration requirements into independent content corresponding to different configuration dimensions, avoiding interference between configuration information from different dimensions and improving the accuracy of subsequent parameter extraction.

[0031] Furthermore, requirement breakdown involves dividing the original requirement text into paragraphs and merging content according to the corresponding intents, based on the identification of multiple intents. Requirement breakdown can organize the mixed original requirements into structured input fragments that correspond one-to-one with the pre-configured dimensions, providing clear processing objects for the subsequent extraction of independent parameters for each dimension.

[0032] Additionally, target intent data consists of a combination of intent tags and corresponding requirement fragments, categorized into pre-configured dimensions after intent identification and segmentation. Target intent data corresponds to four preset configuration categories: basic information configuration, database configuration, tag combination configuration, and channel content configuration, which guide the matching direction of subsequent execution strategies.

[0033] Furthermore, requirement context data consists of globally related information and background descriptions retained in the original requirement, and does not belong to any single independent intent. Requirement context data includes the overall business background of the requirement, branch identifiers, and general constraints across intents. It is used to supplement missing related information for single intent fragments during subsequent parameter extraction, avoiding parameter extraction bias caused by context loss.

[0034] Understandably, after receiving the branch marketing demand data, the system calls a large language model to perform full semantic analysis on the data; based on four pre-defined configuration intents, the semantically analyzed text is segmented into paragraphs, and the corresponding configuration intent is matched for each paragraph; text segments that match the same configuration intent are merged to generate target intent data corresponding to each intent; at the same time, global background and constraint information that does not belong to a single intent in the original requirements are extracted and organized into requirement context data.

[0035] In this embodiment, the input branch marketing demand data is the new Wuhan branch's Huiyantong channel, with an over-harassment prevention period of 15 days, a customer manager contact validity period of 30 days, and a default reference group ratio of 15. Users with unavailable phone numbers and those under 14 years old need to be filtered out. The channel content supports inputting strategy descriptions and options for issuing customer tags. After multi-intent recognition and demand decomposition, four types of target intent data can be extracted: basic configuration information, configuration database, configuration tag combinations, and configuration channel content. Simultaneously, the overall access background of the corresponding branch is retained as demand context data.

[0036] Reference Figure 2 , Figure 2 This is a schematic diagram of the marketing system access configuration system for a bank branch, which is the first embodiment of the marketing system access configuration method for a bank branch in this application.

[0037] like Figure 2As shown, the branch component low-opening design platform serves as the component configuration entry point. Internally, it includes low-opening configuration, model-driven design, component design, branch management, independent development, model accumulation, content validation, and unified output. It generates component configuration content based on branch marketing needs and validates and outputs it. The activity planning platform receives configuration content output from the branch component low-opening design platform, including regular activities, multi-wave activities, canvas design, and workflow orchestration, used to form the planning rules and execution flow for marketing activities. The execution platform receives activity planning results, including batch engine, real-time engine, list distribution, and activity execution. It completes batch or real-time marketing tasks according to the activity rules and distributes the marketing list and activity content to branches. On the branch side: The existing self-built systems of each branch refer to their existing local business systems, including Hangzhou Branch Qihang, Wuhan Huiyantong, Nanjing Zhihu, and other systems, used to receive data from the execution platform and perform local marketing processing; End-to-end connectivity connects the branch's component design platform, event planning, execution platform, and existing self-built systems, including system integration and data standardization, used to unify data transmission rules and interface connection methods between various stages; Marketing feedback includes a response marketplace and feedback analysis, used to receive the results data after the branch's marketing execution and perform feedback analysis, thus forming a bank branch marketing system access configuration process from component configuration, event planning, task execution, branch system processing to marketing feedback.

[0038] Step S20: Perform execution strategy matching based on the target intent data and the demand context data to obtain the target execution strategy.

[0039] It should be noted that execution strategy matching is a decision-making process that selects the optimal processing solution from multiple preset processing modes based on the task complexity corresponding to the target intent data. Execution strategy matching uses task complexity as the core criterion, enabling it to match corresponding processing resources and processes for configuration tasks of varying difficulty, balancing processing efficiency and accuracy.

[0040] Additionally, the target execution strategy is selected after matching and is used to handle the specific execution mode of parameter extraction and component generation tasks under the corresponding intent. The target execution strategy includes three different modes, which are applicable to simple tasks, complex parameter extraction tasks, and multi-component rendering tasks, respectively. Different modes correspond to different model invocation methods and task processing flows.

[0041] Understandably, the process involves reading the requirement fragments corresponding to each intent in the target intent data, combining them with the global constraint information in the requirement context data, evaluating the number of parameters and logical complexity of the task corresponding to each intent, determining the complexity level of the task based on the evaluation results, matching the corresponding processing scheme from three preset execution modes, and marking the matched processing scheme as the target execution strategy for the corresponding intent to guide subsequent parameter extraction and component generation.

[0042] Reference Figure 3 , Figure 3 This is a schematic diagram of the execution strategy design based on task complexity for the first embodiment of the marketing system access configuration method for a bank branch in this application.

[0043] like Figure 3 As shown, in the configuration method for the marketing system of a bank branch, the system performs complexity assessment on the target intent data and requirement context data. The complexity assessment is mainly based on the number of parameters, structural hierarchy, and semantic understanding difficulty to determine whether the task is simple, moderate, or complex. For simple tasks, the Prompt command method is used, which includes Json Mode, Zero Shot, and Few Shot, to directly extract configuration content with relatively fixed formats and clear semantics from the branch's marketing requirement data. For moderate tasks, the COT question method is used, which includes COT thinking chain, problem decomposition, and summary, to break down more complex configuration requirements into multiple questions and extract parameters step by step. For complex tasks, the Agent collaboration method is used, which includes task orchestration, Agent collaboration, and ToolCall, to divide the processing of branch marketing requirements with multiple components and configuration items and integrate the results. Through the above processing, corresponding target execution strategies can be matched to branch marketing requirements according to different task complexities, providing a processing basis for subsequent low-code component configuration generation and marketing activity rule data generation.

[0044] In one feasible implementation, step S20 may include steps S21 to S24: Step S21: Determine the number of parameters, structural levels, and number of components to be rendered for the intent task based on the target intent data.

[0045] It should be noted that an intent task refers to all the parameter extraction and component generation work that needs to be completed under a single configuration intent. Intent tasks revolve around a single configuration dimension and are the basic processing unit for execution strategy matching. The processing difficulty of different intent tasks varies significantly.

[0046] Additionally, the number of parameters refers to the total number of independent parameter items that need to be extracted and configured under a single intent task. The number of parameters directly reflects the processing volume of the intent task; the more parameters there are, the greater the processing workload of the intent task, and the higher the probability of errors.

[0047] Furthermore, the structural hierarchy refers to the depth of the logical nesting and subordination relationships between parameters within a single intent task. The structural hierarchy reflects the logical complexity of parameter configuration; a deeper structural hierarchy indicates more constraints and relationships between parameters, making processing more difficult.

[0048] Additionally, the component rendering count refers to the total number of independent low-code components that need to be generated and rendered under a single intent task. The component rendering count corresponds to the number of final visualization configuration items. A higher component rendering count means more component generation modules need to be called, resulting in a longer intent task processing chain.

[0049] Understandably, this involves reading the requirement fragment content corresponding to the target intent data, counting the total number of independent parameter items that need to be configured under the configuration intent corresponding to the target intent data, sorting out the logical subordinate relationship between each parameter, counting the maximum nesting depth of parameters, and counting the total number of independent visualization components that need to be generated under the configuration intent corresponding to the target intent data; and completing the statistics and confirmation of the three indicators.

[0050] Step S22: Determine the contextual dependencies and semantic completeness corresponding to the intent task based on the demand context data.

[0051] It's important to note that context dependency refers to the degree to which the parameter extraction process for an intent task relies on global information within the requirement context data. A stronger context dependency indicates that relying solely on fragmented information within the intent is insufficient to extract all parameters, necessitating the inclusion of global background information to fill in any missing content.

[0052] Additionally, semantic completeness refers to the completeness of the semantic representation of the requirement fragment corresponding to the intent task, i.e., whether the fragment contains all the key information required to complete parameter extraction. The lower the semantic completeness, the more information is missing from the requirement fragment, requiring supplementary reasoning or multiple rounds of interaction to complete the information.

[0053] Understandably, the requirement fragments corresponding to the intent task are compared with the requirement context data to determine whether the missing parameter information in the requirement fragments can be obtained from the requirement context data, thereby determining the degree of context dependency; at the same time, the completeness of the requirement fragments themselves is analyzed, and the proportion of missing key configuration items is counted to quantify semantic completeness; finally, the judgment results of the two indicators are output.

[0054] Step S23: Determine the task complexity based on the number of parameters, the structural hierarchy, the number of component renderings, the context dependencies, and the semantic completeness to obtain a task complexity marker.

[0055] It should be noted that task complexity assessment is a process of comprehensively evaluating the overall processing difficulty of an intent task by integrating multiple task characteristic indicators. Task complexity assessment quantifies the processing difficulty of an intent task from multiple dimensions, avoiding the one-sidedness of judging by a single indicator and ensuring the accuracy and rationality of the difficulty classification.

[0056] Additionally, the task complexity flag is output after complexity determination, representing the task's difficulty level. Different difficulty levels correspond to different execution strategies, and the task complexity flag is the direct basis for subsequent execution strategy selection.

[0057] Understandably, the following steps are taken: assign corresponding weights and tiered thresholds to the five metrics: parameter quantity, structural hierarchy, component rendering quantity, context dependency, and semantic completeness; compare the actual values ​​of each metric with their corresponding thresholds to obtain the difficulty score for each dimension; sum the scores of each dimension according to their corresponding weights to obtain the comprehensive difficulty score; and generate the corresponding task complexity label based on the difficulty range of the comprehensive score.

[0058] Step S24: Determine the target execution strategy from the prompt instruction execution strategy, question execution strategy, and agent collaborative execution strategy based on the task complexity label.

[0059] It should be noted that the prompt instruction execution strategy is a processing mode that allows the model to complete parameter extraction in one go by directly providing guiding instructions that require structured output. This strategy is suitable for simple tasks, has a short processing flow, fast response speed, and can quickly output structured configuration parameters.

[0060] Another approach is the question-and-execution strategy, which involves breaking down the parameter extraction process into multiple targeted questions, guiding the model to answer each question sequentially, and then summarizing the output parameters. This strategy is suitable for parameter extraction tasks of moderate complexity, reducing the difficulty of each individual process and improving the accuracy of parameter extraction through step-by-step decomposition.

[0061] Furthermore, the agent collaborative execution strategy is a processing mode in which multiple specialized processing modules work together to complete different sub-tasks and then integrate the results. This strategy is suitable for complex tasks involving multi-component rendering, can flexibly adapt to diverse component generation needs, and ensures effective processing in complex scenarios.

[0062] Understandably, different execution strategies are pre-assigned to different task complexity markers; the task complexity markers are read and matched with the corresponding preset execution strategies; the matched execution strategies are determined as the target execution strategies for the corresponding intent tasks, which guide the subsequent component configuration generation work.

[0063] In this embodiment, low complexity markers correspond to prompt instruction execution strategies, medium complexity markers correspond to question execution strategies, and high complexity markers correspond to agent collaborative execution strategies. Different levels of tasks are matched with the most suitable processing mode.

[0064] It should be understood that the instruction execution strategy is geared towards simple task execution. During execution, the original requirement text under the corresponding intent is first organized, and the structured parameter output format corresponding to this type of task is preset. The original requirement text and output format requirements are then input into the language model. If necessary, a small number of reference examples of similar tasks can be added, i.e., few-shot learning, to help the model accurately identify parameter extraction rules. After receiving all inputs, the model directly extracts all corresponding configuration parameters from the original requirement text according to the format constraints, and outputs a structured parameter result that conforms to the standard specifications in one go, completing the parameter extraction work under a single intent.

[0065] The question-and-answer execution strategy is geared towards complex parameter extraction tasks. During execution, the complete parameter extraction task is first broken down into multiple highly targeted sub-questions, each corresponding to a specific configuration parameter verification or value extraction requirement. A thought-chain-guided approach guides the model to sequentially answer all sub-questions, gradually clarifying the specific content and values ​​of each configuration. After all sub-questions are answered, the results are summarized and organized to generate a complete structured parameter set. In this embodiment, the database configuration extraction task is broken down into sub-questions such as whether to enable list control, whether to configure a reference group and its corresponding default ratio, the type of target to be reached, whether to set baseline conditions, whether to enable anti-excessive interference and the corresponding number of days, etc. This step-by-step breakdown reduces the complexity of each processing step and minimizes information extraction errors.

[0066] The agent-based collaborative execution strategy is designed for complex tasks involving multi-component rendering. During execution, the complete component configuration task is first broken down into multiple independent subtasks, each corresponding to the parameter extraction and generation of a specific type of component. A dedicated processing module, or agent, is assigned to each subtask, with each agent focusing on a single type of processing task. An orchestration and scheduling mechanism controls the execution order and data transmission logic of each agent, ensuring seamless collaboration. After all agents complete their respective subtasks, the outputs of all subtasks are integrated to generate a complete component configuration data set. In this embodiment, the channel content extraction task will configure multiple dedicated agents, each responsible for extracting and generating parameters for different types of components such as input boxes, dropdown lists, text boxes, recommended products, and customer tags, collaboratively completing the configuration of all channel content.

[0067] Reference Figure 4 , Figure 4 This is a schematic diagram of the database configuration problem list for the first embodiment of the marketing system access configuration method for a bank branch in this application.

[0068] like Figure 4 As shown, the left side uses data configuration extraction tasks as a unified task scope, grouping multiple data configuration issues into the same parameter extraction process. The right side lists the configuration items that need to be extracted or confirmed from the branch's marketing needs data, including whether to enable list control, whether to configure a reference group and what the default ratio is, what the contact purpose is and whether it belongs to marketing or notification / reminder, whether to set a baseline condition and what the batch and real-time conditions are, whether to enable excessive disturbance and how many days to set it. In the configuration method of the bank branch's marketing system access, this diagram corresponds to the question-based processing method in a more complex parameter extraction scenario. By breaking down the data configuration requirements into specific questions such as list control, reference group configuration, contact purpose, baseline condition, and excessive disturbance, the system can obtain the data configuration parameters required for the branch's marketing activities item by item, and provide clear parameter basis for the subsequent generation of marketing activity rule data and branch marketing configuration data.

[0069] Reference Figure 5 , Figure 5 This is a schematic diagram of the channel content extraction Agent for the first embodiment of the marketing system access configuration method for the bank branch of this application.

[0070] like Figure 5As shown, in the configuration method for the marketing system of a bank branch, the channel content extraction agent is used to process the channel content configuration tasks in the branch's marketing demand data, and calls the corresponding processing tools according to the type of different configuration items in the channel content. Tool binding means that the channel content extraction agent is associated with multiple dedicated agents, specifically including input box agent, drop-down box agent, text box agent, recommended product agent, and customer tag distribution agent. Among them, the input box agent is used to extract the input-type configuration content that needs to be filled in by the user, the drop-down box agent is used to extract the configuration content that needs to be selected from preset options, the text box agent is used to extract the marketing copy or explanatory text-type configuration content, the recommended product agent is used to extract the recommended product configuration content involved in the marketing activity, and the customer tag distribution agent is used to extract the customer tag configuration content that needs to be distributed with the channel content. By splitting the channel content extraction task to different dedicated agents, the complex channel content configuration can be transformed into multiple well-structured configuration parameters, providing a basis for the subsequent generation of standardized component configuration data and marketing activity rule data.

[0071] Step S30: Generate low-code component configuration data and marketing activity rule data by performing low-code component configuration on the branch marketing demand data according to the target execution strategy.

[0072] It's important to note that low-code component configuration generation follows the processing flow corresponding to the target execution strategy. It extracts key configuration parameters from the requirement data and generates directly reusable visual configuration components. Low-code component configuration generation eliminates the need for manual coding, transforming natural language requirements into standardized configuration items and automatically converting business requirements into executable configurations.

[0073] Additionally, standardized component configuration data is a set of component configuration parameters that conforms to a unified data format specification and is output through the generation process. Standardized component configuration data includes component type, parameter values, validation rules, and rendering logic, and can be directly referenced and called by downstream modules without additional format adaptation processing.

[0074] Furthermore, marketing campaign rule data is a set of rule parameters extracted and organized from the requirements to constrain the execution logic of marketing campaigns. This data includes customer segmentation rules, outreach control rules, campaign wave rules, and channel distribution rules, serving as the core basis for subsequent campaign planning and execution.

[0075] Understandably, for each intent, the target execution strategy calls the corresponding model processing flow; simple tasks directly guide the model to extract the corresponding configuration parameters and output structured results through instructions; complex parameter extraction tasks guide the model to extract all configuration parameters item by item through multiple rounds of progressive questioning; multi-component rendering tasks extract parameters separately through multiple specialized processing modules and then integrate and summarize them; finally, standardized component configuration data and marketing activity rule data are generated.

[0076] In one feasible implementation, step S30 may include steps S31 to S35: Step S31: Determine the target demand extraction process corresponding to the branch marketing demand data based on the target execution strategy.

[0077] It should be noted that the target requirement extraction process corresponds one-to-one with the target execution strategy, and is used to extract the specific processing steps and calling logic for configuration parameters from the original requirements. Different execution strategies correspond to different extraction processes, which include model calling methods, processing rounds, information integration rules, etc., and serve as the execution basis for carrying out parameter extraction work.

[0078] Understandably, each type of execution strategy is pre-bound with a corresponding requirement extraction process, and the process clearly defines the order of calling the corresponding processing modules and the data flow rules; the type identifier of the target execution strategy is read and matched with the corresponding preset extraction process; the matched extraction process is determined as the target requirement extraction process, which is used to guide the subsequent configuration parameter extraction process.

[0079] Reference Figure 6 , Figure 6 This is a schematic diagram of the large and small model collaborative task orchestration process in the first embodiment of the marketing system access configuration method for the bank branch of this application.

[0080] like Figure 6As shown, in the configuration method for accessing the marketing system of a bank branch, rule management is used to pre-control the processing of branch marketing needs. This includes rate limiting rules, task grading, and scheduling strategies. Rate limiting rules control the model call volume and task processing frequency; task grading differentiates the processing difficulty of different branch marketing needs; and scheduling strategies determine how tasks enter subsequent processing flows. Orchestration and scheduling organize the task processing process according to the results of rule management. This includes parallel orchestration, traffic control, and task scheduling. Parallel orchestration processes configuration tasks that can be processed simultaneously in parallel; traffic control controls the call resources of large and small models; and task scheduling assigns different types of tasks to corresponding models. Large models handle complex tasks and in-depth analysis, suitable for branch marketing needs with complex semantic relationships, numerous configuration items, or requiring in-depth understanding. Small models handle simple tasks and provide rapid responses, suitable for configuration tasks with clear rules, simple parameter structures, or high response time requirements. Through the coordination of rule management, orchestration and scheduling, and large and small models, the corresponding processing method can be selected based on the task characteristics of the branch marketing needs, providing a processing foundation for subsequent execution strategy matching and low-code component configuration generation.

[0081] In one feasible implementation, step S31 may include steps S311 to S314: Step S311: Determine the input text length, task complexity data, and information content data based on the branch marketing demand data.

[0082] It should be noted that the input text length refers to the total character length of the natural language text corresponding to the marketing demand data, used to measure the overall size of the input content. Input text length is one of the basic indicators for model routing decisions; the longer the text length, the higher the computational load on the model, and the higher the requirements for the model's processing capabilities.

[0083] Additionally, task complexity data is a quantitative measure of the difficulty in processing the corresponding requirement extraction task, encompassing multi-dimensional difficulty characteristics such as the number of parameters, their structure, and hierarchy. Task complexity data directly reflects the task's requirements on the model's reasoning capabilities and serves as a core reference for the model's routing decisions.

[0084] Furthermore, information content data refers to the richness of effective business configuration information contained in the input text, used to measure the actual information density of the input content. Information content data can distinguish between different scenarios where long texts contain low information and short texts contain high information, avoiding routing decision biases caused by judging solely based on text length.

[0085] Understandably, the total number of characters in the natural language text corresponding to the branch marketing demand data is used to obtain the input text length; combined with the previously determined task complexity features, task complexity data is compiled; and the proportion and richness of effective configuration information in the input text are analyzed to quantify the information content data.

[0086] Step S312: Based on the input text length, the task complexity data, and the information content data, perform model routing judgment to obtain the model routing result.

[0087] It should be noted that model routing decision-making is a decision-making process that comprehensively considers multiple input indicators to assess the task's demand on model capabilities, and then selects the appropriate model specifications. Model routing decision-making can dynamically match models with different capabilities according to the actual needs of the task, achieving a reasonable allocation of computing resources and balancing processing efficiency and processing effect.

[0088] Additionally, the model routing result is the model selection result output after routing judgment, used to specify the model specification to be used to process the current task. The model routing result corresponds to language models with different parameter sizes. Models of different sizes differ in inference speed and comprehension ability, and are adapted to processing tasks of varying difficulty.

[0089] Understandably, the following steps are taken: set corresponding judgment thresholds and weights for the three indicators of input text length, task complexity, data information content, etc.; compare the actual values ​​of the three indicators with the corresponding thresholds, and calculate the comprehensive adaptation score based on the weights; determine the model specification adapted to the current task based on the comprehensive adaptation score, and generate the corresponding model routing results.

[0090] In this embodiment, the model routing results correspond to two selectable language models: a low-parameter model with 1.4 billion parameters and a high-parameter model with 7.2 billion parameters, which are adapted to task scenarios of different difficulty.

[0091] Step S313: Determine the candidate requirement extraction process based on the model routing results.

[0092] It should be noted that the candidate requirement extraction process is tied to the corresponding model specifications and is adapted to the requirements extraction and processing flow of the corresponding model's operating characteristics. Different model specifications correspond to different candidate extraction processes, and the processing steps and calling logic within the process will be adjusted according to the model's capabilities to fully leverage the performance advantages of the corresponding model.

[0093] Understandably, a corresponding requirement extraction process is pre-matched for each model specification; the model specification corresponding to the model routing result is read, and a requirement extraction process suitable for the corresponding model is obtained, and the corresponding process is marked as a candidate requirement extraction process.

[0094] Reference Figure 7 , Figure 7 This is a schematic diagram of the size model routing mechanism in the first embodiment of the marketing system access configuration method for a bank branch in this application.

[0095] like Figure 7 As shown, in the configuration method for accessing the marketing system of a bank branch, the system first receives the branch marketing demand data input by the user, and then determines whether to use a large model. The judgment criteria include input length, task complexity, and information content. When the user input is short, the task complexity is low, and the information content is small, the system can choose the SmallLLM Qwen1.5-14b language model for processing to complete simple configuration item recognition, fast parameter extraction, and basic requirement parsing. When the user input is long, the task complexity is high, and the information content is rich, the system chooses the LargeLLMQwen1.5-72b language model for processing to complete complex semantic understanding, multi-configuration item extraction, and in-depth requirement analysis. Through this routing mechanism, the corresponding model can be selected according to the actual complexity of the branch marketing demand data, providing a model processing foundation for subsequent generation of target intent data and requirement context data, execution strategy matching, and low-code component configuration generation.

[0096] Step S314: Combine the candidate demand extraction process and the target execution strategy to obtain the target demand extraction process corresponding to the branch marketing demand data.

[0097] It should be noted that process combination is the process of integrating and matching the candidate extraction process at the model level with the target execution strategy at the task complexity level. Process combination can take into account differences in model capabilities and task complexity, forming a complete execution path that adapts to both model specifications and task types.

[0098] Understandably, the process involves reading the task processing steps framework corresponding to the target execution strategy, embedding the model call logic in the candidate requirement extraction process into the corresponding processing stage, adjusting the execution order and data transmission rules within the process to ensure seamless connection between the two parts of the logic, and integrating them to form a target requirement extraction process that adapts to both model specifications and task complexity.

[0099] Step S32: Based on the target demand extraction process, the branch marketing demand data is processed to extract configuration parameters and obtain marketing configuration parameters.

[0100] It should be noted that configuration parameter extraction is the process of identifying and extracting specific configuration values ​​and rule settings from branch marketing demand data in natural language format. Configuration parameter extraction is the core step in transforming requirements into executable configurations, and the accuracy of the extraction results directly affects the effectiveness of subsequent component generation and campaign execution.

[0101] Additionally, marketing configuration parameters are extracted from the original requirements and consist of a set of values ​​and rules for each specific configuration item. These parameters cover various aspects, including basic campaign information, control rules, customer segmentation criteria, and channel display formats, serving as the foundational data for subsequent component generation and rule formulation.

[0102] Understandably, following the processing steps specified in the target requirement extraction process, the corresponding language model processing capabilities are invoked; the corresponding content in the branch marketing requirement data is identified and extracted one by one, and the configuration requirements described in natural language are transformed into structured parameter values; after the extraction of all configuration items is completed, the complete marketing configuration parameters are compiled and summarized.

[0103] In this embodiment, based on the needs of the Wuhan branch's Huiyantong channel, the extracted marketing configuration parameters include specific rule values ​​such as 15 days of protection against excessive disturbances, 30 days of validity period for customer manager contact, a reference group ratio of 15, filtering of unavailable calls and users under the age of 14.

[0104] Step S33: Generate low-code component code and encapsulate the components according to the marketing configuration parameters to obtain candidate component configuration data.

[0105] It should be noted that the low-code component code generation is a process that automatically generates the rendering and interaction logic code for the corresponding low-code components based on marketing configuration parameters. The generated code conforms to the low-code platform's component specifications and can be directly loaded and run on the low-code platform without requiring manual coding.

[0106] Additionally, component encapsulation is the process of integrating generated component code, parameter configurations, validation rules, and other elements into independent, reusable component units. Component encapsulation can integrate scattered code and configurations into standardized component modules, facilitating subsequent calling and management.

[0107] Furthermore, the candidate component configuration data is a preliminary set of component configuration data obtained after code generation and encapsulation. The candidate component configuration data contains all the functional logic and configuration parameters of the component, but the full-link field standardization validation has not yet been completed. It is an intermediate product for generating the final standardized component.

[0108] Understandably, the process involves reading the values ​​and rules in the marketing configuration parameters and matching them with the corresponding low-code component templates; generating the rendering code, interaction logic, and data validation rules for the corresponding components based on the component templates and marketing configuration parameters; and packaging and integrating all the generated content according to the component specifications to form independent candidate component configuration data.

[0109] Reference Figure 8 , Figure 8This is a comparative schematic diagram of the docking scheme for the first embodiment of the marketing system access configuration method for the bank branch of this application.

[0110] like Figure 8 As shown, the left side represents the new solution. After clarifying the business requirements, the access process is mainly completed through component configuration and branch system integration. Component configuration is used to generate reusable configuration content based on the branch's marketing needs, and branch system integration is used to complete the integration with the branch system according to the configuration results. This concentrates the new branch system integration process into the configuration and integration stages. The right side represents the old solution. After the business requirements are proposed, they need to be processed through the component platform, planning module, execution platform, and branch system. Each stage requires repeated clarification of requirements and coordination with development processes such as scheduling, analysis and design, development and testing. At the same time, solution integration and joint debugging verification are also required to complete the integration of the branch system. In light of this solution, this diagram illustrates that traditional branch marketing system integration requires repeated communication, development, and verification between multiple systems. In contrast, this solution simplifies the integration process through component configuration and branch system integration, enabling branch marketing requirements to be transformed into access configuration content, reducing redundant development and joint debugging.

[0111] Step S34: Perform field standardization processing on the candidate component configuration data to obtain standardized component configuration data.

[0112] It should be noted that field standardization is a process of uniformly adjusting the field names, data formats, and value ranges in the configuration data of candidate components according to a pre-defined unified data specification across the entire chain. Field standardization can eliminate format differences between component data and downstream modules, ensuring smooth data flow throughout the entire chain.

[0113] Furthermore, standardized component configuration data is obtained after field standardization processing, conforming to the unified data specification across the entire supply chain. This standardized component configuration data can be directly referenced and called by downstream modules without additional format adaptation work, and represents the final output of component configuration.

[0114] Understandably, the process involves reading the pre-defined unified data standard specifications across the entire process chain, comparing each field in the candidate component configuration data item by item, adjusting field names and data formats that do not conform to the specifications, verifying and correcting parameters that exceed the value range, and generating standardized component configuration data that meets the requirements after completing the standardization verification and adjustment of all fields.

[0115] Step S35: Generate activity registration parameters, list filtering parameters, and channel content parameters based on the marketing configuration parameters and the standardized component configuration data, and generate marketing activity rule data based on the activity registration parameters, the list filtering parameters, and the channel content parameters.

[0116] It should be noted that the event registration parameters are the basic information parameters used to complete the registration of marketing events in the planning module. These parameters include basic information such as event name, event duration, branch, and event type, and are essential for the formal creation of the event.

[0117] Additionally, the list filtering parameters are rule parameters used to constrain the marketing customer segmentation logic. These parameters include customer tag combinations, filtering conditions, reference group settings, and baseline conditions, and are the core basis for the execution platform to generate marketing lists.

[0118] Furthermore, channel content parameters are configuration parameters used to define the display format and content delivered to marketing outreach channels. Channel content parameters include component configurations for the channel interface, content templates, customer tag display rules, etc., and serve as the basis for content delivery to branch-level channels.

[0119] In addition, marketing campaign rule data is a complete set of parameters that integrates the rules of the entire campaign process, supporting the entire operation of the campaign from creation and execution to outreach. Marketing campaign rule data is the core basis for campaign planning and execution, directly determining the operational logic and execution effect of the marketing campaign.

[0120] Understandably, basic activity information is extracted from marketing configuration parameters and standardized component configuration data and organized into activity registration parameters; customer group screening and control rules are extracted and organized into list screening parameters; and channel display and content configuration are extracted and organized into channel content parameters. These three types of parameters are then integrated according to the logical order of activity execution to form complete marketing activity rule data.

[0121] In this embodiment, for the needs of the branch's Smart Eye Channel, the generated list filtering parameters include rules such as 15 days to prevent excessive disturbance, 30 days validity period for customer manager contact, 15 reference group ratio, filtering of unavailable calls and users under 14 years old, and channel content parameters including policy description input and customer tag selection configuration.

[0122] Step S40: Based on the branch interface description data and upstream and downstream docking parameters, perform element identification to obtain element identification results, and construct branch marketing configuration data based on the element identification results.

[0123] It should be noted that the branch interface description data is descriptive information that describes the data format, transmission method, field definitions, and interaction logic of the branch's local interface. The branch interface description data reflects the data interaction specifications on the branch's local side and is the basic input for identifying interface elements, used to clarify the data interaction boundaries and format requirements on the branch side.

[0124] Additionally, the upstream and downstream interface parameters are the complete set of parameters required for data interaction between the event planning, execution platform, and feedback modules and the branch office. These parameters cover various categories, including channel configuration, event metadata, execution settings, and customer information, and are the core content transmitted in the entire data interaction process.

[0125] Furthermore, element identification involves comparing and analyzing the branch interface description data with upstream and downstream connection parameters to distinguish between common and unique content. Element identification can identify the common fixed parameters and differentiated variable parameters used in different branch connections, providing a basis for subsequent standardized and customized connection solutions.

[0126] Furthermore, the element identification results are obtained through comparative analysis, and include a list of docking parameters categorized into common and unique parameters. The element identification results mark parameters common to different rows as common data, and row-specific parameters as dynamic slot data, clearly defining the boundaries between the two types of data and their respective processing methods.

[0127] Furthermore, the branch marketing configuration data is constructed based on the element identification results and is adapted to the full configuration data required for branch integration. The branch marketing configuration data includes standardized common parameters and customizable parameters configured on demand, which can simultaneously meet the needs of unified data standards across the entire chain and the localized and differentiated integration requirements of branches.

[0128] Understandably, the process involves collecting all interaction fields and format requirements defined in the branch interface description data, while simultaneously summarizing the upstream and downstream connection parameters of each module across the entire chain. These two types of parameters are then compared item by item, selecting parameters that must be transmitted across all branch connections and have the same format as common data, and selecting parameters with format or content differences depending on the branch as individual data, i.e., dynamic slots. The classification results of the two types of data, along with their respective field definitions, are then compiled into element identification results. Based on the element identification results, a fixed standard transmission format is set for the common parameters, and configurable dynamic parameter slots are reserved for the individual parameters, integrating these to form the branch marketing configuration data.

[0129] In one feasible implementation, step S40 may include steps S41 to S45: Step S41: Scan the interface fields according to the branch interface description data and the upstream and downstream docking parameters to obtain the interface field set.

[0130] It should be noted that interface field scanning is a process of systematically collecting all field items of the parameters between the branch-side interface and the upstream and downstream modules. Interface field scanning can comprehensively cover all interaction fields across the entire chain, avoiding the omission of key data items and providing a complete field foundation for subsequent element classification.

[0131] Additionally, the interface field set, obtained through scanning and collection, is a complete list of all interactive fields across the entire process. The interface field set encompasses the fields defined by the branch-side interfaces and the parameter fields passed by upstream and downstream modules, serving as the foundational processing object for subsequent data element identification.

[0132] Understandably, this involves extracting all interaction fields defined in the branch interface description data, as well as all transmission fields included in the upstream and downstream connection parameters. These two types of fields are then aggregated and deduplicated to form a complete set of interface fields. This ensures that all fields involved in data interaction are included in the set.

[0133] Step S42: Identify the first data element that needs to be transmitted in different branches and has the same field structure based on the interface field set.

[0134] It should be noted that the first data element is a data item that needs to be transmitted across different branches, and whose field names, data formats, and value rules are completely consistent. The first data element has cross-branch universality and will not change due to different branches, making it a core component of the unified data standard across the entire chain.

[0135] Understandably, the process involves iterating through each field in the interface field set, comparing the definition and format of each field in different branch interfaces, and filtering out field items that exist in all branches and have completely consistent field structure, data type, and transmission rules. These filtered field items are then categorized as the first data element.

[0136] In this embodiment, the first data element includes parameters common to different branches, such as basic channel information, customer group event information, and activity metadata. The transmission rules for the first data element parameters are uniform when connecting with each branch, and no individual customization is required.

[0137] Step S43: Identify second data elements with non-fixed field structures based on the interface field set.

[0138] It should be noted that the second data element is a data item whose field structure and content vary from branch to branch. The second data element corresponds to the localized and personalized configuration requirements of each branch, and is the core content that needs to be differentiated each time a new branch is connected.

[0139] Understandably, the identified first data elements are excluded from the interface field set, and the remaining field items are analyzed. Field items with different definitions, data formats, or content rules due to different row divisions are filtered out. The filtered field items are then classified as second data elements.

[0140] In this embodiment, the second data element includes line-specific parameter content such as special display formats for localized management rules. The parameter structure of the second data element is complex and highly personalized, making it impossible to transmit it directly using a uniform, fixed format.

[0141] Reference Figure 9 , Figure 9 This is a schematic diagram of data element classification for the first embodiment of the marketing system access configuration method for a bank branch in this application.

[0142] like Figure 9 As shown, the component platform corresponds to component metadata, channel basic information, and channel configuration data. Component metadata describes the basic attributes and usage rules of the component; channel basic information records the basic parameters of the marketing channel; and channel configuration data accommodates the configuration differences in channel access and displayed content across different branches. The planning module corresponds to canvas metadata, customer event information, other configuration data, and channel setting data. Canvas metadata describes the basic information of the event planning page or process arrangement; customer event information describes the target customer group and triggering events of the marketing activity; other configuration data supplements the extended configurations that need to be transmitted in event planning; and channel setting data determines the activity... The system configures the placement and reach across different channels; the execution platform includes corresponding activity metadata, execution settings, and branch channel information. Activity metadata describes the basic activity information required for activity execution; execution settings determine execution parameters such as batch execution, real-time execution, and list distribution; and branch channel information describes the interface or channel information required for the branch's local channel system to receive and process marketing tasks. In conjunction with this solution, this diagram illustrates how the system identifies common data and branch-specific data within the component platform, planning module, and execution platform to form a unified data classification foundation. This provides a basis for subsequently building branch marketing configuration data and completing the integration configuration of the bank branch's marketing system.

[0143] Step S44: Generate feature recognition results based on the first data element and the second data element.

[0144] It should be noted that the feature identification result is a comprehensive list of connected features, formed after identifying both types of data features. The feature identification result clearly indicates the feature type to which each field belongs, as well as the processing rules for each feature type.

[0145] Understandably, this involves compiling a complete list of fields and a unified format definition for the first set of data elements, while simultaneously compiling the field ranges and distinguishing features for the second set of data elements. The classification information field definitions for both types of elements, along with the processing rules for each type, are then integrated to form a complete element identification result.

[0146] Step S45: Construct element data format, dynamic slot configuration data, and channel content parameter slots based on the element identification results, and generate branch marketing configuration data based on the element data format, the dynamic slot configuration data, and the channel content parameter slots.

[0147] It should be noted that the feature data format is a unified data transmission standard defined for the first data feature, including field names, data types, value constraints, and transmission order. The feature data format is applicable to all line-based integration scenarios and is a core standard for ensuring end-to-end data interoperability.

[0148] Additionally, dynamic slot configuration data refers to variable parameter configuration rules designed for the second data element, used to carry differentiated parameter content for different rows. Dynamic slot configuration data does not restrict the specific field structure, only defining the slot calling rules and parsing methods.

[0149] Furthermore, the channel content parameter slot is a dynamic parameter carrier specifically designed for differentiated parameters related to channel content. This slot receives channel configuration content generated upstream, and downstream modules do not need to concern themselves with the specific parameter details within the slot.

[0150] Understandably, a unified data format is established based on the first data element, clarifying the transmission specifications for all common parameters. Dynamic slot configuration data is designed based on the second data element, defining the rules for carrying and parsing variable parameters. Simultaneously, dedicated channel content parameter slots are set up for channel content parameters to adapt to the differentiated configuration needs of multiple components within channel content. The unified format dynamic slots and dedicated parameter slots are then integrated to form complete branch marketing configuration data.

[0151] In one feasible implementation, step S45 may include steps S451 to S454: Step S451: Generate fixed field configuration data based on the first data element in the element identification result.

[0152] It should be noted that the fixed field configuration data is generated based on the first data element, and the field names and formats are fixed. The fixed field configuration data corresponds to common parameters that are universal across all branches, and does not need to be adjusted in different branch connection scenarios. It is a fixed standard part of the end-to-end data transmission.

[0153] Understandably, the field definitions of all first data elements in the feature recognition results are extracted, and a uniform data type and value rule are set for each field. All fields are then arranged and integrated in a fixed transmission order to generate fixed field configuration data applicable to all rows.

[0154] In this embodiment, the fixed field configuration data includes common field content such as channel basic information, activity metadata, and execution settings, and all branch connections use the same transmission format.

[0155] Step S452: Generate dynamic slot configuration data based on the second data element in the element identification result.

[0156] It should be noted that dynamic slot configuration data is generated based on the second data element and is variable configuration data used to carry differentiated content. Dynamic slot configuration data does not restrict the specific field structure inside the slot, but only specifies the way the slot is called and the parsing rules, which can adapt to the personalized parameter requirements of different branches.

[0157] Understandably, this involves analyzing the differences in characteristics among all second-level data elements in the element recognition results, and establishing a framework and parsing rules for variable parameters. Within this framework, expandable parameter filling positions are reserved to generate dynamic slot configuration data that supports the input of differentiated content.

[0158] In this embodiment, dynamic slot configuration data is used to carry differentiated content for each line, such as localized management rules and special display formats. Different lines can fill their own exclusive configurations into the slots.

[0159] Step S453: Generate feature data format based on the fixed field configuration data and the dynamic slot configuration data.

[0160] It should be noted that the feature data format is a complete data transmission specification that integrates fixed fields and dynamic slots, serving as a unified standard for data interaction between all modules across the entire data chain. The feature data format clearly defines the overall structure of data transmission, field order, and parsing rules, ensuring smooth data interaction between upstream and downstream modules.

[0161] It is understandable that fixed-field configuration data serves as the main framework of the data format, while dynamic slot configuration data is embedded in the corresponding extended positions within the framework. The overall data transmission order and parsing logic are clearly defined, integrating them to form a complete feature data format.

[0162] Step S454: Establish channel content parameter slots by configuring corresponding parameter content for channel content according to the element data format.

[0163] It should be noted that the channel content parameter slot is a dedicated dynamic parameter carrier specifically set up for channel content configuration, used to transmit the channel component configuration content generated upstream. The channel content parameter slot is independent of the general dynamic slot, specifically adapted to the multi-component and highly differentiated characteristics of channel content, ensuring smooth transmission of channel content.

[0164] Understandably, a dedicated parameter slot is reserved for channel content in the element data format, and corresponding data input and parsing rules are set. The slot content is explicitly generated by the upstream component platform, and downstream modules parse it directly according to the rules, without needing to concern themselves with internal details, thus completing the establishment of the channel content parameter slot.

[0165] Reference Figure 10 , Figure 10 This is a schematic diagram of the global connection of channel configuration data in the first embodiment of the marketing system access configuration method for the bank branch of this application.

[0166] like Figure 10 As shown, the left side represents the business processing chain. After the component platform generates component-related configurations, they are passed to the planning system. The planning system then passes the activity-related configurations to the batch and real-time middleware platforms. The batch and real-time middleware platforms then distribute the processed data to the branch system to complete the branch-side marketing task assignment. The right side shows the data structure definitions for each stage. The component output definition includes the component output fields channelCd, channelNm, and configData. ChannelCd and channelNm correspond to basic information, while configData corresponds to channel configuration, describing the basic channel information and configuration content output by the component platform. The activity registration parameters include svsId, svsNm, and channelData, where svsId and svsNm correspond to... The canvas metadata includes `channelData`, which corresponds to channel configuration and describes the basic activity parameters and channel parameters required when the planning system registers an activity. The data sent from the middle platform includes `uid`, `bk`, and `channelInfo`, where `uid` and `bk` correspond to activity metadata, and `channelInfo` corresponds to channel configuration, describing the activity information and channel configuration information required when the execution middle platform sends marketing tasks to the branch system. The data standardization and transparent transmission on the right indicate that each link processes channel configuration data through unified data fields and transmission rules, enabling the component platform, planning system, batch middle platform, real-time middle platform, and branch system to connect according to a consistent data format. This provides a data foundation for building branch marketing configuration data and configuring the bank branch's marketing system access.

[0167] Step S50: Configure the marketing system access for the bank branch based on the standardized component configuration data, the marketing activity rule data, and the branch marketing configuration data.

[0168] It should be noted that the marketing access configuration integrates the generated component configurations, activity rules, and branch connection configurations to complete the configuration operation for connecting the branch and head office marketing capabilities. After the marketing access configuration is completed, the branch can use the head office's marketing planning, execution, and feedback capabilities through a standardized process, without the need for additional customized development work.

[0169] Understandably, the process involves: distributing standardized component configuration data to the component design platform to complete component rendering and publishing; synchronizing marketing activity rule data to the activity planning module to complete the configuration and verification of activity logic; synchronizing branch marketing configuration data to the execution platform and the branch's local side to complete parameter matching and joint debugging verification of the data transmission channel; and finally, after verifying all configuration items, the corresponding branch's marketing capabilities can be integrated.

[0170] This embodiment provides a method for configuring a marketing system for a bank branch. By performing multi-intent identification and decomposition of the branch's marketing needs and determining the complexity of the tasks, it matches differentiated execution strategies and combines large and small models for collaborative routing to complete the configuration of low-code components and the automatic generation of marketing activity rules. At the same time, it performs common and individual classification of all-link connection elements, constructs a unified data transmission format with fixed standards and dynamic slots, and integrates all configuration data to complete the configuration of the branch's marketing capabilities. This achieves rapid deployment of branch marketing access with zero repetitive development, shortens the new branch access cycle from months to days or even hours, and improves the data compatibility and business requirement iteration response speed of the entire link.

[0171] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 11 Step S10 of the method for configuring the marketing system of a bank branch includes steps S11 to S15: Step S11: Perform natural language semantic parsing on the branch marketing demand data to obtain demand semantic data.

[0172] It should be noted that Natural Language Semantic Parsing (NLP) is a process of deep semantic understanding and structured transformation of requirement text in natural language form. NLP can identify business entities, configuration rules, and logical relationships in text, transforming unstructured natural language into semantic information that can be processed by machines, which is a fundamental prerequisite for subsequent intent matching.

[0173] Additionally, demand semantic data is intermediate demand processing data obtained after semantic parsing, carrying semantic tags and structured information. Demand semantic data retains all the business meaning of the original demand while possessing machine-recognizable structured features, enabling it to be directly used for subsequent intent matching and classification.

[0174] Understandably, after receiving the branch's marketing requirements data, the system calls a language model to perform sentence-by-sentence semantic analysis on all the requirements text; identifies the business configuration items, parameter values, and logical constraints in the text, transforms the natural language description into structured semantic units; and integrates all semantic units to generate complete requirements semantic data.

[0175] Step S12: Perform intent matching on the required semantic data according to the preset intent library to obtain initial intent data.

[0176] It should be noted that the pre-defined intent library is a reference library containing all business configuration intent categories and corresponding semantic features. The pre-defined intent library covers all core dimensions of branch marketing configurations, with each type of intent corresponding to a clear configuration scope and semantic features, providing a unified classification benchmark for intent matching.

[0177] Additionally, the initial intent data consists of semantic fragments with temporary intent tags, obtained after preliminary intent matching. This initial intent data only performs preliminary intent classification of single fragments and has not yet undergone merging, organization, or contextual association; it is an intermediate product of subsequent splitting and merging processes.

[0178] Understandably, the semantic features of various intents in the pre-built intent library are read, and each semantic unit in the required semantic data is compared with each type of intent feature; the intent category with the highest probability is matched for each semantic unit, and initial intent data with the corresponding intent tag is generated.

[0179] In this embodiment, the preset intent library contains four types of preset intents: basic configuration information, configuration database, configuration tag combination, and configuration channel content. All semantic fragments are matched to the corresponding categories.

[0180] Step S13: Based on the initial intent data, the branch marketing demand data is segmented to obtain the basic information subtask, the database configuration subtask, the tag combination subtask, and the channel content configuration subtask.

[0181] It's important to note that paragraph splitting is a process that divides the original requirement text into multiple independent text segments corresponding to different intents, based on the intent classification results. Paragraph splitting can break down a complete text containing multiple types of configuration requirements into independent task units, ensuring that each text segment corresponds to only one type of configuration intent and preventing content from different intents from interfering with each other.

[0182] Additionally, the basic information subtask is an independent processing unit corresponding to the basic information configuration intent, carrying the configuration requirements related to the activity's basic information. The basic information subtask includes basic configuration content such as the branch to which the activity belongs, the channel name, and the activity period, and is the foundational information part of the entire configuration process.

[0183] Furthermore, the database configuration subtask is an independent processing unit corresponding to the database configuration intent, carrying configuration requirements related to data filtering and control rules. The database configuration subtask includes data control configuration content such as anti-excessive interference rules, contact validity periods, reference group settings, and filtering conditions, which directly affect the marketing list generation logic.

[0184] Additionally, the tag combination subtask is an independent processing unit corresponding to the tag combination configuration intent, carrying configuration requirements related to customer group tag selection. The tag combination subtask includes customer group selection tags, basic condition settings, and other customer group selection-related configuration content, used to define the target customer group scope of the marketing campaign.

[0185] Furthermore, the channel content configuration subtask is an independent processing unit corresponding to the channel content configuration intent, carrying configuration requirements related to the channel display format and distributed content. The channel content configuration subtask includes channel interface components, distributed content templates, customer tag display, and other channel-side configuration content, which determines the final display effect of the branch channel.

[0186] Understandably, based on the intent tag corresponding to each semantic fragment in the initial intent data, the position of the corresponding content in the original requirement text is located; the original requirement text is cut into four independent text fragments according to the intent category, with each text fragment corresponding to a type of configuration intent; the four text fragments are then organized into basic information subtasks, database configuration subtasks, tag combination subtasks, and channel content configuration subtasks.

[0187] In this embodiment, based on the needs of the branch's Smart Eye Channel, the basic information subtask includes adding content related to the branch's Smart Eye Channel; the database configuration subtask includes content such as preventing excessive disturbances, contact validity period, and reference group ratio; the tag combination subtask includes content such as phone unavailability and age filtering; and the channel content configuration subtask includes content such as strategy description input and customer tag distribution options.

[0188] Step S14: Context extraction is performed on the basic information subtask, the database configuration subtask, the tag combination subtask, and the channel content configuration subtask respectively to obtain subtask context data.

[0189] It should be noted that context extraction is the process of extracting global background information from the original requirements that does not belong to a single subtask but has a constraining effect on the parameter extraction of the corresponding subtask. Context extraction can preserve the global constraints in the requirements, avoid the loss of related information when subtasks are processed independently, and ensure the accuracy of parameter extraction.

[0190] Additionally, subtask context data is extracted from the original requirements and consists of global background and constraint information related to the corresponding subtask. While not part of the subtask's core configuration, subtask context data influences the parameter value logic and rule boundaries, providing supplementary information for parameter extraction.

[0191] Understandably, this involves analyzing the core configuration content of each subtask one by one, sorting out the global information in the original requirements that has a constraint effect on the corresponding subtask, and extracting the background information that does not belong to the core content of the subtask but has a constraint effect, and organizing it into the subtask context data of the corresponding subtask.

[0192] Step S15: Merge the initial intent data corresponding to the same intent to obtain a merge result, and associate the merge result with the subtask context data to obtain target intent data and requirement context data.

[0193] It should be noted that the merging result is a complete set of intent content obtained by integrating all initial intent data under the same intent. The merging result can integrate multiple scattered semantic fragments of the consensus graph into complete single intent configuration content, eliminating the information fragmentation problem caused by fragmented segments.

[0194] Additionally, the target intent data is a combination of complete configuration content and intent tags for each type of configuration intent, after being merged and organized. The target intent data contains all the core configuration information for the corresponding intent, is structurally complete and clearly defined, and serves as direct input for subsequent execution strategy matching and parameter extraction.

[0195] Furthermore, the requirement context data is a global set of background and constraint information obtained by integrating the context data of all subtasks. The requirement context data covers the general background of the entire requirement and the constraints across subtasks, and is used to supplement the correlation information of each intention task in subsequent processing.

[0196] Understandably, the process involves integrating all initial intent data under the same intent category, eliminating duplicate content, and organizing the logical order to generate a merged result for the corresponding intent. The merged result for each type of intent is then associated and bound with the context data of the corresponding subtask to form the target intent data for that intent. At the same time, the global common background information of all subtasks is summarized and organized to form complete requirement context data.

[0197] Reference Figure 12 , Figure 12 This is a schematic diagram illustrating intent recognition and segmentation in the second embodiment of the marketing system access configuration method for a bank branch in this application.

[0198] like Figure 12As shown, after a user inputs branch marketing needs data, the system performs semantic analysis on the input content through intent recognition and combines it with routing algorithms to determine the intent. The routing algorithms include semantic routing and zero-shot routing, used to identify different configuration intents contained in the user input. After the intent recognition results are processed, they are divided into four types of tasks: basic configuration information, configuration database, configuration tag combination, and configuration channel content. The basic configuration information is used to extract basic configuration content such as adding new channels and branch names. The configuration database is used to extract data configuration content such as anti-excessive disturbance, account manager contact validity period, reference group ratio, and filtering conditions. The configuration tag combination is used to extract customer screening and tag combination related content. The configuration channel content is used to extract content such as channel display, strategy description, and customer tag distribution. The example text on the right is: I want to add the Wuhan branch's Huiyantong channel, with anti-excessive disturbance for 15 days, account manager contact validity period for 30 days, reference group ratio of 15 by default, and need to filter out users whose phone numbers are unavailable and users under the age of 14. The channel content supports input strategy descriptions and customer tag options. This example illustrates that the system can break down a continuous natural language requirement into multiple configuration tasks, which are then mapped to basic information, database, tag combinations, and channel content configurations, respectively. This yields target intent data and requirement context data, providing input for subsequent execution strategy matching and low-code component configuration generation.

[0199] This embodiment provides a method for configuring a marketing system for a bank branch. By performing natural language semantic parsing on the branch's marketing demand data and combining it with a pre-built intent library to complete initial intent matching, the demand is split into four independent configuration sub-tasks according to the matching results, and the associated context of each sub-task is extracted. Finally, the content of the unified graph is merged and the context association binding is completed. This achieves accurate decomposition of mixed natural language demand into structured multi-intent tasks, while fully preserving global constraint information. This provides a clear and independent processing unit and complete information support for subsequent differentiated execution strategy matching and accurate parameter extraction.

[0200] For example, to help understand the implementation process of the bank branch marketing system access configuration method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 13 , Figure 13 A simplified flowchart illustrating the configuration method for accessing a bank branch's marketing system is provided. Specifically: The business flow on the left shows the branch marketing needs going through the following stages from top to bottom: problem planning, task scheduling, access control, and result rendering. In the problem planning stage, the system first identifies the problem, then performs multi-intent decomposition, and generates corresponding tasks to break down the user-inputted branch marketing needs into manageable configurable tasks. In the task scheduling stage, the system organizes the task processing through orchestration, execution strategies, and rule management, combining Prompt commands, FewShot, COT questions, thought chains, Agent orchestration, and Tools. The system uses methods such as Call to extract parameters and process tasks of varying complexity for configuration tasks. The model resources on the right include large and small models, providing corresponding model processing capabilities based on task complexity and processing requirements. The component library on the right includes input boxes, text boxes, dropdown lists, recommended products, and distribution tags, providing optional components for channel content configuration and page component configuration. During the exit control phase, the system checks and supplements the generated configuration results through data verification, result review, and configuration completion to avoid missing or non-compliant configuration content. During the result rendering phase, the system generates component display results and configuration content that can be used for access configuration in the bank branch marketing system through component selection, parameter binding, and dynamic rendering, thereby supporting the subsequent generation of standardized component configuration data and marketing activity rule data.

[0201] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the marketing system access configuration method of the bank branch in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0202] This application also provides a marketing system access configuration device for a bank branch, please refer to... Figure 14 The marketing system access configuration device for the bank branch includes: The intent recognition module 10 is used to perform multi-intent recognition and demand decomposition based on the branch marketing demand data to obtain target intent data and demand context data. The strategy matching module 20 is used to perform execution strategy matching based on the target intent data and the demand context data to obtain the target execution strategy; The component generation module 30 is used to generate low-code component configurations for the branch marketing demand data according to the target execution strategy, so as to obtain standardized component configuration data and marketing activity rule data. The element identification module 40 is used to identify elements based on the branch interface description data and upstream and downstream docking parameters, obtain element identification results, and construct branch marketing configuration data based on the element identification results. Access configuration module 50 is used to configure the marketing system access of the bank branch based on the standardized component configuration data, the marketing activity rule data, and the branch marketing configuration data.

[0203] The bank branch marketing system access configuration device provided in this application adopts the bank branch marketing system access configuration method in the above embodiments, which can solve the technical problems of low demand adaptation efficiency and long delivery cycle when the existing branch marketing system accesses different branches. Compared with the prior art, the beneficial effects of the bank branch marketing system access configuration device provided in this application are the same as the beneficial effects of the bank branch marketing system access configuration method provided in the above embodiments, and other technical features in the bank branch marketing system access configuration device are the same as the features disclosed in the above embodiments, and will not be repeated here.

[0204] In one embodiment, the component generation module 30 is further configured to determine the target demand extraction process corresponding to the branch marketing demand data based on the target execution strategy; Based on the target demand extraction process, configuration parameters are extracted from the branch marketing demand data to obtain marketing configuration parameters. Based on the marketing configuration parameters, low-code component code is generated and component encapsulation is performed to obtain candidate component configuration data; The candidate component configuration data is subjected to field standardization processing to obtain standardized component configuration data. Based on the marketing configuration parameters and the standardized component configuration data, activity registration parameters, list filtering parameters, and channel content parameters are generated, and marketing activity rule data is generated based on the activity registration parameters, the list filtering parameters, and the channel content parameters.

[0205] In one embodiment, the component generation module 30 is further configured to determine the input text length, task complexity data, and information content data based on the branch marketing demand data; The model routing decision is made based on the input text length, the task complexity data, and the information content data to obtain the model routing result; The candidate requirement extraction process is determined based on the model routing results; The candidate demand extraction process and the target execution strategy are combined to obtain the target demand extraction process corresponding to the branch marketing demand data.

[0206] In one embodiment, the strategy matching module 20 is further configured to determine the number of parameters, structural hierarchy, and number of components rendered corresponding to the intent task based on the target intent data; Determine the contextual dependencies and semantic completeness of the intent task based on the required context data; The task complexity is determined based on the number of parameters, the structural hierarchy, the number of components rendered, the context dependencies, and the semantic completeness, and a task complexity label is obtained. The target execution strategy is determined based on the task complexity label among the prompt instruction execution strategy, question execution strategy, and agent collaborative execution strategy.

[0207] In one embodiment, the element identification module 40 is further configured to perform interface field scanning based on the branch interface description data and the upstream and downstream docking parameters to obtain an interface field set; Based on the interface field set, identify the first data element that needs to be transmitted in different branches and has the same field structure; Identify second data elements with non-fixed field structures based on the interface field set; Generate feature recognition results based on the first data element and the second data element; Based on the element identification results, we construct element data format, dynamic slot configuration data, and channel content parameter slots, and generate branch marketing configuration data based on the element data format, the dynamic slot configuration data, and the channel content parameter slots.

[0208] In one embodiment, the feature recognition module 40 is further configured to generate fixed field configuration data based on the first data feature in the feature recognition result; Dynamic slot configuration data is generated based on the second data element in the element identification result; Generate feature data format based on the fixed field configuration data and the dynamic slot configuration data; Based on the element data format, channel content parameter slots are created to configure corresponding parameter content for channel content.

[0209] In one embodiment, the intent recognition module 10 is further configured to perform natural language semantic parsing on the branch marketing demand data to obtain demand semantic data; The initial intent data is obtained by performing intent matching on the required semantic data according to the pre-set intent library; Based on the initial intent data, the branch marketing demand data is segmented to obtain the basic information subtask, the database configuration subtask, the tag combination subtask, and the channel content configuration subtask. Context extraction is performed on the basic information subtask, the database configuration subtask, the tag combination subtask, and the channel content configuration subtask respectively to obtain subtask context data; The initial intent data corresponding to the same intent are merged to obtain a merged result, and the merged result is associated with the subtask context data to obtain target intent data and requirement context data.

[0210] This application provides a marketing system access configuration device for a bank branch. The marketing system access configuration device for a bank branch includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the marketing system access configuration method for a bank branch in the above embodiment 1.

[0211] The following is for reference. Figure 15 This document illustrates a structural diagram of a marketing system access configuration device suitable for implementing embodiments of this application for a bank branch. The marketing system access configuration device for a bank branch in this application embodiment may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 15 The bank branch marketing system access configuration device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0212] like Figure 15As shown, the marketing system access configuration device for a bank branch may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to programs stored in ROM (Read Only Memory) 1002 or programs loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the bank branch's marketing system access configuration device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the bank branch's marketing system access configuration device to exchange data wirelessly or via wired communication with other devices. Although the figure shows a bank branch's marketing system access configuration device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have alternatively.

[0213] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0214] The marketing system access configuration device for bank branches provided in this application adopts the marketing system access configuration method for bank branches in the above embodiments, which can solve the technical problems of low demand adaptation efficiency and long delivery cycle when existing branch marketing systems access different branches. Compared with the prior art, the beneficial effects of the marketing system access configuration device for bank branches provided in this application are the same as the beneficial effects of the marketing system access configuration method for bank branches provided in the above embodiments, and other technical features in the marketing system access configuration device for bank branches are the same as the features disclosed in the method of the previous embodiment, and will not be repeated here.

[0215] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0216] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0217] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the marketing system access configuration method for a bank branch in the above embodiments.

[0218] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, RAM (Random Access Memory), ROM (Read Only Memory), Erasable Programmable Read Only Memory (EPROM), optical fiber, CD-ROM (CD-Read Only Memory), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0219] The aforementioned computer-readable storage medium may be included in the marketing system access configuration equipment of a bank branch; or it may exist independently and not be installed in the marketing system access configuration equipment of a bank branch.

[0220] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the marketing system access configuration device of a bank branch, the marketing system access configuration device of the bank branch performs the following actions: multi-intent identification and demand decomposition based on the branch's marketing demand data to obtain target intent data and demand context data; execution strategy matching is performed based on the target intent data and the demand context data to obtain a target execution strategy; low-code component configuration is generated based on the target execution strategy for the branch's marketing demand data to obtain standardized component configuration data and marketing activity rule data; element identification is performed based on the branch's interface description data and upstream / downstream connection parameters to obtain element identification results, and branch marketing configuration data is constructed based on the element identification results; and the marketing system access configuration of the bank branch is performed based on the standardized component configuration data, the marketing activity rule data, and the branch marketing configuration data.

[0221] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including LAN (Local Area Network) or WAN (Wide Area Network)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0222] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0223] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0224] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described bank branch marketing system access configuration method. This solves the technical problems of low efficiency and long delivery cycles in existing branch marketing systems when accessing different branches. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the bank branch marketing system access configuration method provided in the above embodiments, and will not be elaborated upon here.

[0225] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method for configuring access to a bank branch's marketing system.

[0226] The computer program product provided in this application can solve the technical problems of low efficiency in adapting to different branch needs and long delivery cycles in existing branch marketing systems. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the bank branch marketing system access configuration method provided in the above embodiments, and will not be repeated here.

[0227] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for configuring and accessing a marketing system in a bank branch, characterized in that, The method includes: Based on the branch marketing demand data, multi-intent identification and demand decomposition are performed to obtain target intent data and demand context data; The execution strategy is obtained by matching the target intent data and the requirement context data. Based on the target execution strategy, the branch marketing demand data is configured and generated using low-code components to obtain standardized component configuration data and marketing activity rule data. Based on the branch interface description data and upstream and downstream docking parameters, element identification is performed to obtain element identification results, and branch marketing configuration data is constructed based on the element identification results. Configure the bank branch's marketing system access based on the standardized component configuration data, the marketing activity rule data, and the branch marketing configuration data.

2. The method as described in claim 1, characterized in that, The step of generating standardized component configuration data and marketing activity rule data by low-code component configuration of the branch marketing demand data according to the target execution strategy includes: Based on the target execution strategy, determine the target demand extraction process corresponding to the branch marketing demand data; Based on the target demand extraction process, configuration parameters are extracted from the branch marketing demand data to obtain marketing configuration parameters. Based on the marketing configuration parameters, low-code component code is generated and component encapsulation is performed to obtain candidate component configuration data; The candidate component configuration data is subjected to field standardization processing to obtain standardized component configuration data. Based on the marketing configuration parameters and the standardized component configuration data, activity registration parameters, list filtering parameters, and channel content parameters are generated, and marketing activity rule data is generated based on the activity registration parameters, the list filtering parameters, and the channel content parameters.

3. The method as described in claim 2, characterized in that, The steps of the target demand extraction process for determining the branch marketing demand data according to the target execution strategy include: The input text length, task complexity, and information content are determined based on the branch marketing needs data. The model routing decision is made based on the input text length, the task complexity data, and the information content data to obtain the model routing result; The candidate requirement extraction process is determined based on the model routing results; The candidate demand extraction process and the target execution strategy are combined to obtain the target demand extraction process corresponding to the branch marketing demand data.

4. The method as described in claim 1, characterized in that, The step of matching the execution strategy based on the target intent data and the demand context data to obtain the target execution strategy includes: The number of parameters, structural levels, and number of components to be rendered are determined based on the target intent data. Determine the contextual dependencies and semantic completeness of the intent task based on the required context data; The task complexity is determined based on the number of parameters, the structural hierarchy, the number of components rendered, the context dependencies, and the semantic completeness, and a task complexity label is obtained. The target execution strategy is determined based on the task complexity label among the prompt instruction execution strategy, question execution strategy, and agent collaborative execution strategy.

5. The method as described in claim 1, characterized in that, The steps of identifying elements based on branch interface description data and upstream / downstream connection parameters, obtaining element identification results, and constructing branch marketing configuration data based on the element identification results include: Based on the branch interface description data and the upstream and downstream docking parameters, the interface field is scanned to obtain the interface field set; Based on the interface field set, identify the first data element that needs to be transmitted in different branches and has the same field structure; Identify second data elements with non-fixed field structures based on the interface field set; Generate feature recognition results based on the first data element and the second data element; Based on the element identification results, we construct element data format, dynamic slot configuration data, and channel content parameter slots, and generate branch marketing configuration data based on the element data format, the dynamic slot configuration data, and the channel content parameter slots.

6. The method as described in claim 5, characterized in that, The steps for constructing the element data format, dynamic slot configuration data, and channel content parameter slots based on the element identification results include: Generate fixed field configuration data based on the first data element in the feature recognition result; Dynamic slot configuration data is generated based on the second data element in the element identification result; Generate feature data format based on the fixed field configuration data and the dynamic slot configuration data; Based on the element data format, channel content parameter slots are created to configure corresponding parameter content for channel content.

7. The method as described in claim 1, characterized in that, The steps of performing multi-intent identification and demand segmentation based on branch marketing demand data to obtain target intent data and demand context data include: Natural language semantic analysis is performed on the branch marketing demand data to obtain demand semantic data; The initial intent data is obtained by performing intent matching on the required semantic data according to the pre-set intent library; Based on the initial intent data, the branch marketing demand data is segmented to obtain the basic information subtask, the database configuration subtask, the tag combination subtask, and the channel content configuration subtask. Context extraction is performed on the basic information subtask, the database configuration subtask, the tag combination subtask, and the channel content configuration subtask respectively to obtain subtask context data; The initial intent data corresponding to the same intent are merged to obtain a merged result, and the merged result is associated with the subtask context data to obtain target intent data and requirement context data.

8. A marketing system access configuration device for a bank branch, characterized in that, The device includes: The intent recognition module is used to perform multi-intent recognition and demand decomposition based on branch marketing demand data to obtain target intent data and demand context data. The strategy matching module is used to perform execution strategy matching based on the target intent data and the demand context data to obtain the target execution strategy; The component generation module is used to generate low-code component configurations for the branch marketing demand data according to the target execution strategy, so as to obtain standardized component configuration data and marketing activity rule data. The element identification module is used to identify elements based on the branch interface description data and upstream and downstream docking parameters, obtain element identification results, and construct branch marketing configuration data based on the element identification results. The access configuration module is used to configure the bank branch's marketing system access based on the standardized component configuration data, the marketing activity rule data, and the branch marketing configuration data.

9. A marketing system access configuration device for a bank branch, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the marketing system access configuration method for a bank branch as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the marketing system access configuration method for a bank branch as described in any one of claims 1 to 7.

Images