A large model-based multi-feature recognition evaluation method

Abstract

The application relates to a multi-feature recognition evaluation method based on a large model and belongs to the technical field of artificial intelligence. According to the scheme, a distributed task scheduling framework is used to trigger task execution, a plurality of AI large models are called in parallel to obtain reply texts and aggregate results, features of entities are extracted from the reply texts and are analyzed, sentiment tendency judgment and media attribution recognition are performed on the entities, multi-dimensional indexes are calculated and are fused to generate a comprehensive score, and optimization suggestions are generated. The application solves the problems of single evaluation dimension, difficulty in heterogeneous feature fusion and insufficient deep information extraction in the prior art, realizes automatic, standardized and comprehensive evaluation of entity performance in an AI dialogue scene, and provides reliable data support for decision-making.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to a multi-feature recognition and evaluation method based on a large model. Background Technology

[0002] In the era of generative artificial intelligence, the digital performance of entities (such as brands, products, and organizations) in dialogues between users and large language models (LLMs) has become a key factor influencing user cognition and decision-making. Current technologies for evaluating online entity performance mainly develop along two paths: search engine optimization (SEO) and online public opinion monitoring technologies, and general natural language processing (NLP) services. The closest existing technology is a method that combines multiple NLP APIs to perform simple analysis of AI responses and generate separate reports. However, existing technologies have significant drawbacks: First, features are isolated, with no mathematical model correlation between the multiple output feature indicators, failing to reflect the overall performance and internal structure of the entity; second, there is a lack of fusion methods, lacking an algorithmic model to standardize and scientifically fuse heterogeneous features; third, the evaluation depth is insufficient, feature extraction remains superficial, failing to design deep feature parsing rules tailored to the semantic characteristics of AI dialogues, and thus failing to accurately extract implicit information; fourth, the output results cannot be directly used for decision-making, requiring secondary human interpretation, and cannot automatically generate standardized comprehensive scores. Therefore, there is an urgent need for a technical solution that can automatically extract various heterogeneous entity representation features from unstructured text in generative AI dialogues and integrate them into a single, quantitative evaluation index through a fusion model, in order to overcome the shortcomings of existing technologies. Summary of the Invention

[0003] To address the aforementioned technical problems, this invention provides a multi-feature recognition and evaluation method based on a large model. It constructs an end-to-end multi-feature fusion evaluation model, achieving automated and intelligent mapping from raw AI dialogue text to a comprehensive entity evaluation score. This solves the problems of existing technologies such as one-sided, isolated evaluation, difficulty in fusion, and insufficient extraction of deep information. The invention adopts the following technical solution: A multi-feature recognition and evaluation method based on a large model, the method comprising: Receive the GEO assessment task configuration information input by the user through the web front-end interface, construct the GeoTask data object and assign configuration parameters, call the data access layer interface to store the configuration information in the database, and generate and return a unique GEO assessment task identifier. The evaluation task is triggered on a timed basis through a distributed task scheduling framework, the execution of multi-node tasks is controlled by a distributed lock mechanism, and multi-node coordination and failure task compensation are achieved through task status management. The large model client is managed and a unified calling interface is set up through the factory pattern. A retry mechanism and exception handling configuration are set for each large model. Multiple large models are called through the unified calling interface and the response results of each large model are aggregated. The system constructs brand extraction prompts, encapsulates structured analysis parameters, calls AI tool interfaces and inputs the prompts and structured analysis parameters to obtain structured analysis results containing each identified brand; it extracts brand-related information from the structured analysis results and performs quantitative transformation, and generates default value records for unidentified bound brands; Conduct in-depth verification and detailed analysis of brand sentiment, improve sentiment-related characteristics; determine the media source attribution of brand-related content, and complete media classification identification; output standardized data containing detailed sentiment information and media attribution classification. Calculate and integrate the results of various indices to pinpoint brand performance weaknesses and generate optimization suggestions.

[0004] In some embodiments of the present invention, the GEO assessment task configuration information includes basic task information, large model configuration information, assessment cycle configuration information, prompt word configuration information, and competitor binding information.

[0005] In some embodiments of the present invention, the XXL-JOB distributed task scheduling framework is used to construct a timed triggering mechanism for evaluation tasks, which is suitable for multi-node cluster deployment scenarios.

[0006] In some embodiments of the present invention, a Redis distributed lock mechanism is used to achieve unique control over task execution.

[0007] In some embodiments of the present invention, large model client management and a unified calling interface are implemented through a factory pattern, specifically including: First, define an abstract client class AiWebSearchAbstractClient, which encapsulates the common calling methods and core properties of all large model clients; Create the AiWebSearchFactory class; when the factory class is initialized, it receives an array of all concrete clients, iterates through the array and registers each client to CLIENT_MAP according to its AiModelTypeEnum type, thus completing the centralized storage of clients; The factory class exposes the getClient(AiModelTypeEnummodelType) method as a unified calling interface, through which the caller obtains the client. When adding a large model client, it is only necessary to implement the AiWebSearchAbstractClient abstract class, define the corresponding AiModelTypeEnum enumeration value, and add the new client to the registration array during factory initialization.

[0008] In some embodiments of the present invention, constructing brand extraction prompts specifically includes: based on the requirements of brand recognition and ranking analysis, solidifying preset brand extraction prompts, the prompts clearly instructing AI to identify the self-owned brand and competitor brands from the specified text, and returning standardized JSON format results containing visibility, ranking, and sentiment dimensions, ensuring that the AI ​​output meets the requirements of subsequent parsing.

[0009] In some embodiments of the present invention, encapsulating structured analysis parameters specifically includes: creating a JSONObject structured parameter object, filling in three types of parameters according to the interface specification: input text, custom name, and competitor list, to ensure that the parameters cover all the information required for AI analysis and that the format adapts to the requirements of AI tool interfaces.

[0010] In some embodiments of the present invention, an independent data record is created for each unidentified bound brand, all feature fields are filled with preset default values, and the task ID is associated with the record and added to the brand analysis result set. Finally, the total number of the result set is verified to be consistent with the total number of bound brands.

[0011] In some embodiments of the present invention, a multi-layered data security and privacy protection mechanism is constructed throughout the entire process of data transmission, storage and processing, including data transmission security assurance, sensitive data de-identification storage, AI model call data isolation, evaluation result access control and data lifecycle management.

[0012] In some embodiments of the present invention, the construction of an exception handling and fault tolerance mechanism includes downgrade processing for abnormal format of AI model return results, conflict resolution strategy when multiple model results are aggregated, processing flow for distributed lock acquisition timeout, cache fallback scheme when database connection is abnormal, and end-to-end abnormal monitoring and alarm for task execution.

[0013] This invention provides a multi-feature recognition and evaluation method based on a large model. The technical solution provided by the embodiments of this invention brings at least the following beneficial effects: (1) A multi-feature fusion evaluation model for AI dialogue scenarios was established, and a five-dimensional evaluation system including visibility index, ranking index, first place index, sentiment index and citation index was designed. A unified mathematical fusion framework was proposed, and the standardized fusion of multi-dimensional features was realized. The technical problem of heterogeneous feature fusion was solved. Through feature normalization processing (such as mapping ranking to score and converting sentiment probability to 0-100 score) and weight allocation mechanism, heterogeneous data such as frequency, order and sentiment probability were effectively integrated.

[0014] (2) Deep semantic feature extraction was achieved. Based on the characteristics of AI dialogue text, rules for brand recognition, ranking analysis, and media affiliation judgment based on prompt word engineering were designed to accurately extract implicit ranking lists, comparison relationships, authoritative citations and other information. The output is structured and computable evaluation results. The generated comprehensive score and sub-feature scores can be directly used for horizontal comparison, trend tracking and anomaly detection, providing standardized input for upper-level data analysis and decision support systems.

[0015] (3) The multi-model parallel calling and distributed task scheduling architecture is adopted to improve the evaluation efficiency and system reliability, and supports multiple modes such as continuous evaluation and single evaluation to meet the needs of different scenarios.

[0016] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating the multi-feature recognition evaluation method. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0020] Before describing the technical solution of the present invention in detail, the technical background and technical terms involved in the technical solution will be explained first: AIGC (Generative Artificial Intelligence): An important branch of artificial intelligence, its core characteristic is that it autonomously generates entirely new content with a certain degree of logic and completeness based on training data and algorithmic models, rather than simply extracting and organizing existing data. Essentially, it learns from the patterns in massive amounts of data (such as language logic, knowledge connections, and content structure) to simulate human creative / expressive abilities, outputting content in various forms such as text, images, audio, and video.

[0021] SEO (Search Engine Optimization): Technical optimization techniques for traditional search engines (such as Baidu, Google, Bing, etc.). The core goal is to improve the ranking of target web pages / websites in the organic search results of search engines, so that users can see the web page / website more prominently when searching for specific keywords, thereby increasing exposure, traffic, and conversion opportunities.

[0022] GEO (Generative Engine Optimization): GEO focuses on optimizing the digital performance of entities (such as brands, products, organizations, etc.) in the output results of generative engines (mainly referring to large language models, LLM), including key indicators such as the entity's visibility in AI dialogue responses, AI-generated content, ranking competitiveness, sentiment tendency, and authoritative citations. Ultimately, through systematic evaluation and optimization, it enhances the entity's awareness, favorability, and influence in the process of user interaction with AI.

[0023] The Factory Pattern: This pattern uses a dedicated "factory class" to uniformly manage the creation logic of different types of objects. Users don't need to worry about the specific creation details of objects (such as initialization parameters, dependency configurations, instantiation rules, etc.); they only need to submit their requirements to the factory to obtain object instances that meet those requirements. For example, in this invention, during factory initialization, clients (objects) of different large models such as Doubao, DeepSeek, and Tencent Yuanbao are registered in a HashMap according to AiModelTypeEnum (model type enumeration). When the system needs to call a certain type of large model, it only needs to pass the model type (such as "Doubao") to the factory, and the factory will return the corresponding client instance through the getClient method. Users don't need to worry about the initialization of different model clients, interface adaptation, or other details; they can obtain usable clients uniformly through the factory, achieving "separation of creation logic and usage logic."

[0024] Figure 1 This is a flowchart illustrating a multi-feature recognition evaluation method. The method includes the following steps: Step S101: Receive the GEO assessment task configuration information input by the user through the Web front-end interface, construct the GeoTask data object and assign configuration parameters, call the data access layer interface to store the configuration information in the database, and generate and return a unique GEO assessment task identifier.

[0025] The above steps are used for task creation and configuration. This step is the starting point of the entity multi-feature recognition evaluation process based on generative AI dialogue. The core purpose is to receive the user's personalized configuration requirements through the web front-end interface, generate a structured GEO (Generative Engine Optimization) evaluation task, and provide basic parameter support for subsequent multi-model calls, feature extraction and fusion evaluation.

[0026] In this step, the user initiates a GEO assessment task creation request through the web front-end interactive interface provided by the multi-feature recognition assessment device. The multi-feature recognition assessment device displays a complete configuration option menu on the front end. After the user completes each configuration according to their own assessment needs, they submit the request. The multi-feature recognition assessment device receives the configuration parameters in the background and performs a validity check. After the check is passed, the configuration information is encapsulated into a standardized task object, stored in the database, and a unique task ID is returned for identification in subsequent task scheduling, execution, and query.

[0027] The GEO assessment task configuration information mentioned above includes basic task information, large model configuration information, assessment cycle configuration information, prompt word configuration information, and competitor binding information. These will be described in detail below: 1. Basic Task Information The basic information for this task is used to clarify the core object and scenario of the assessment, providing contextual information for subsequent AI prompt generation and model analysis. The specific configuration items are as follows: (1) Evaluation subject type selection: The multi-feature recognition evaluation device supports three types of evaluation subjects. Users need to select one of “brand”, “series” and “product” as the core object type of evaluation. This selection will determine the focus dimension of subsequent feature extraction and evaluation (e.g., the brand level focuses on overall awareness, and the product level focuses on the specific functional performance correlation).

[0028] (2) Input of self-owned brand name: Users need to manually input the accurate name of the self-owned brand or product to be evaluated. The input of a single core entity name is supported (if multiple products belonging to the same self-owned brand need to be evaluated, they can be supplemented through subsequent prompt words configuration). This name will be used as the core keyword for feature recognition and used to accurately locate the target entity from the AI ​​dialogue text.

[0029] (3) Category name selection: The user selects the category to which the subject of the evaluation belongs from the category list preset by the multi-feature recognition evaluation device (such as "smartphone", "home appliance", "beauty and skin care" etc.). The multi-feature recognition evaluation device will match industry-specific AI prompt word templates based on the selected category to improve the scenario adaptability and accuracy of subsequent brand recognition and feature extraction.

[0030] 2. Large model configuration information This large model configuration information is used to specify the AI ​​large models participating in the evaluation and their running parameters. By collaborating with multiple models, the comprehensiveness and reliability of the evaluation results are improved. The specific configuration items are as follows: (1) Model selection: The multi-feature recognition evaluation device integrates a variety of mainstream AI models, such as Doubao, DeepSeek, Tencent Yuanbao, Tongyi Qianwen, and Wenxin Yiyan, and supports multiple selections by users (one or more models can be selected to participate in the evaluation at the same time). Users can combine models independently according to the accuracy requirements and response speed requirements of the evaluation scenario.

[0031] (2) Network search switch: Provides a Boolean configuration option (on / off) to control whether the selected large model enables the real-time network search function when generating responses; when on, the model can obtain the latest network data for analysis, which is suitable for evaluation scenarios that need to combine real-time market dynamics and industry information (such as the performance evaluation of a new product after its launch); when off, the model generates responses only based on its own training data, which is suitable for historical performance backtesting evaluation with higher stability requirements.

[0032] (3) Deep Thinking Switch: Provides a Boolean configuration option (on / off) to control whether the selected large model enables the reasoning enhancement mode; when on, the model will perform multiple rounds of deep reasoning on the user's question to enhance the richness of implicit information (such as implicit ranking, potential competitive relationship) in the response, thereby enhancing the depth of subsequent feature extraction; when off, the model prioritizes fast response and generates concise and direct responses, which is suitable for scenarios with high requirements for evaluation efficiency.

[0033] 3. Evaluation cycle configuration information This evaluation cycle configuration information is used to specify the execution frequency and time range of the evaluation, adapting to the monitoring needs in different scenarios. The specific configuration items are as follows: (1) Evaluation type selection: Users need to choose between "continuous evaluation" and "single evaluation"; "continuous evaluation" is a timed automatic execution mode, in which the multi-feature recognition evaluation device will repeatedly execute the evaluation task according to the preset cycle, which is suitable for long-term monitoring of entity performance trends (such as brand monthly awareness tracking); "single evaluation" is a manual trigger mode, which only executes the evaluation once after the user submits the configuration, which is suitable for temporary needs (such as rapid performance comparison after a competitor's sudden marketing campaign); (2) Monitoring cycle setting: If “Continuous evaluation” is selected, the user needs to set the monitoring cycle. The multi-feature recognition evaluation device provides two preset cycles: “one week” and “one month”. It also supports custom time range (the user can manually enter the start time and execution interval, such as “execute once every 3 days for 2 months”). If “single evaluation” is selected, this configuration item will be automatically hidden. The multi-feature recognition evaluation device defaults to the time of submission of configuration as the evaluation execution time.

[0034] 4. Prompt word configuration information This prompt word configuration information is used to define the dialogue commands of the AI ​​large model, guiding the model to generate response text that meets the evaluation requirements. The specific configuration items are as follows: (1) AI intelligent recommendation prompt word function: The multi-feature recognition evaluation device automatically recommends suitable prompt word templates based on the user's configured evaluation subject type and category name (e.g., for brand evaluation of the "smartphone" category, the recommended prompt word is "Please analyze the user awareness of XX brand smartphones in the current market, the ranking comparison with competitors, user sentiment and related media citations"). Users can directly select or modify it based on this.

[0035] (2) Custom prompts support: Users can manually input custom prompts according to their personalized evaluation needs. Multiple prompts can be input simultaneously (such as "Analyze the core advantages and market ranking of XX product" and "Explain the user reviews and authoritative media reports of XX brand").

[0036] (3) Prompt word enable / disable control: Each prompt word (including prompt words recommended by the multi-feature recognition evaluation device and user-defined prompt words) has an independent enable switch. Users can flexibly control the prompt words that are effective in this task according to the evaluation focus. Prompt words that are not enabled will not be sent to the AI ​​big model.

[0037] 5. Competitor product binding configuration information This competitor binding configuration information is used to specify the competitor objects that need to be compared and analyzed with the domestic brand. It supports multi-dimensional horizontal comparison. The specific configuration items are as follows: (1) Adding competitor brands: Users can manually enter multiple competitor brand names (no upper limit, but must meet the input format requirements of the multi-feature recognition evaluation device). The multi-feature recognition evaluation device supports real-time verification of the uniqueness of brand names to avoid duplicate additions. (2) Brand type identifier: The multi-feature recognition and evaluation device automatically distinguishes between the self-owned brand and the competitor through the "belong" field. The "belong" value of the self-owned brand is 0, and the "belong" value of all added competitor brands is 1. This identifier will be used for group statistics during subsequent feature extraction and index calculation (such as calculating the visibility index and ranking index of the self-owned brand and each competitor separately and comparing them).

[0038] The above steps involve storing configuration information in a database and generating and returning a unique GEO assessment task identifier, specifically including: (1) Parameter encapsulation: The multi-feature recognition device encapsulates all user-configured parameters (including basic task information, large model configuration information, evaluation cycle configuration information, prompt word configuration information, and competitor binding configuration information) into a GeoTask data object. The key attribute assignment rules are as follows: OwnName: This value is assigned to the owner's brand name entered by the user. Model type list (modelType): Encodes the user-selected model (by processing modelCodeList using the dealModelTypeList method, mapping the model name to a unified model code within the multi-feature recognition device). Web Search Switch Status (webSearch): Assigns a value to the user-configured switch status (1 for on, 0 for off). Deep Thinking Switch Status: Assigns a value to the user-configured switch status (1 for on, 0 for off). Assessment Type: Assign the code corresponding to the user's choice of "continuous assessment" or "single assessment".

[0039] (2) Data persistence: Through the geoTaskMapper data access interface, the GeoTask object is inserted into the database, and the database returns the unique GEO evaluation task identifier of the task.

[0040] (3) Result return: The multi-feature recognition device returns the generated GEO evaluation task identifier ID to the Web front end and displays it to the user. The user can use this ID to query the task execution status, evaluation results and optimization suggestions.

[0041] In the above steps, a multi-layered data security and privacy protection mechanism is constructed throughout the entire process of data transmission, storage, and processing, specifically including: (1) Data transmission security The system employs HTTPS protocol and TLS 1.3 encryption standard to encrypt all data transmission between the web front-end and back-end services end-to-end. User-submitted GEO assessment task configuration information (including brand name, competitor list, prompts, etc.) is encrypted throughout the transmission process to prevent data leakage caused by man-in-the-middle attacks. At the same time, the system uses an API key signature mechanism for calling the AI ​​large model interface, with each request carrying a timestamp and signature hash value to ensure the legitimacy and tamper-proof nature of the interface call.

[0042] (2) Sensitive data de-identification storage Sensitive fields in user configuration information (such as the name of the own brand and the name of the competitor brand) are encrypted and stored using the AES-256 symmetric encryption algorithm. The encryption key is uniformly managed by the Key Management Service (KMS) to achieve the separation of key and data storage. The database only stores the encrypted ciphertext, and it is dynamically decrypted through the authorization service when it is read, ensuring that even if the database is illegally accessed, sensitive information cannot be directly obtained.

[0043] (3) Data isolation when calling AI models When calling multiple large AI models, an independent session identifier (sessionId) is assigned to each assessment task to ensure that the dialogue context of different tasks is isolated from each other. At the same time, the prompts and analysis parameters input to the AI ​​model are cleaned to filter out user privacy information (such as contact information, address, etc.) that may be included, and only the core content related to brand assessment is retained. After feature extraction is completed, the original response text returned by the AI ​​model is automatically cleaned up according to the preset retention period (30 days by default) to avoid the risk of data leakage caused by long-term storage.

[0044] (4) Access control of assessment results Based on the RBAC (Role-Based Access Control) model, hierarchical permission management is implemented for the assessment results: the task creator has full permissions to view, export, and delete the results; collaborating members under the same account only have viewing permissions; cross-account access requires temporary authorization through an authorization code mechanism, with the authorization code having an expiration period (default 24 hours) and a limit on the number of accesses (default 3 times); all result access operations are recorded in audit logs, including visitor ID, access time, operation type, IP address, and other information, supporting post-event traceability and security auditing.

[0045] (5) Data lifecycle management Establish a complete data lifecycle management mechanism: Evaluation task configuration information is retained for 7 days after task deletion (supporting recovery from accidental deletion), and automatically physically deleted after the expiration period; evaluation result data is archived or deleted periodically according to the user-configured retention policy (default 90 days); AI model call logs are automatically cleaned up after 180 days; all deletion operations adopt a secure erasure method to ensure that the data is unrecoverable.

[0046] Step S102: Implement timed triggering of evaluation tasks through a distributed task scheduling framework, control the execution of multi-node tasks using a distributed lock mechanism, and achieve multi-node coordination and compensation for failed tasks through task status management.

[0047] The above steps are used for scheduled tasks and distributed lock control. The parameters and unique task ID output by step S101 provide a precise scheduling basis for this step. This step is the core scheduling link of the multi-feature recognition and evaluation process. Its core purpose is to realize the scheduled triggering of evaluation tasks through a distributed task scheduling framework, while using a distributed lock mechanism to avoid repeated execution of tasks in multi-node deployment scenarios. Combined with task status management, it realizes automatic compensation and retry of failed tasks, ensuring the stability, uniqueness and integrity of the entire evaluation process.

[0048] In the above steps, the XXL-JOB distributed task scheduling framework is used to construct a precise and reliable timed triggering mechanism for evaluation tasks, adaptable to multi-node cluster deployment scenarios, and ensuring that tasks are executed in an orderly manner according to preset rules. The timed triggering of evaluation tasks through the distributed task scheduling framework specifically includes: (1) Selection and basic configuration of distributed scheduling framework Determine the core scheduling component: Select the XXL-JOB distributed task scheduling framework, based on its core capabilities such as distributed deployment adaptation, task visualization management, failure retry, and execution log tracking, to meet the high availability and scalability requirements of task scheduling in a multi-node cluster environment.

[0049] Configuration file parameter settings: Specify the communication parameters such as the address, port number, application name, and registration key of the XXL-JOB scheduling center in the device configuration file to complete the basic connection configuration with the scheduling center and ensure network communication between the execution node and the scheduling center.

[0050] Executor node deployment: Deploy XXL-JOB executors on each deployment node of the device, and configure parameters such as executor port, log storage path, and thread pool size to enable each node to receive scheduling instructions and execute tasks.

[0051] (2) Task registration and communication link binding Task annotation registration: The @XxlJob annotation is used to add identifiers (such as "startGeoExecuteLog" and "startGeoAnalysisEngine") to the core timed tasks of the device, clarifying the association between the task name and the executor.

[0052] Task configuration in the scheduling center: Manually enter task information in the XXL-JOB scheduling center or import it through the configuration synchronization tool, including task name, executor name, trigger method (timed trigger), trigger expression (e.g., 0:00 every day, every 24 hours), number of retries on failure, etc.

[0053] Communication link verification: When the actuator starts, it automatically registers with the dispatch center. The dispatch center confirms the online status of the actuator through a heartbeat detection mechanism and establishes a two-way communication link of "dispatch center issues instructions - actuator receives and responds" to ensure accurate transmission of dispatch instructions.

[0054] (3) Scheduled task design and execution 1) Task record generation task (startGeoExecuteLog) execution Trigger timing verification: The dispatch center triggers the task according to the preset expression (0:00 every day). After receiving the instruction, the executor first verifies whether the current time meets the triggering conditions to avoid abnormal triggering.

[0055] Valid task filtering: Traverse the GEO evaluation tasks created in the device database, filter out tasks that are in a valid state (including "continuous evaluation" tasks and "single evaluation" tasks that have not been executed), and exclude invalid tasks that have expired or been deleted.

[0056] Pending execution record generation: For each selected valid task, generate a pending execution task record containing task ID, account ID, evaluation configuration parameter reference (large model list, prompt words, evaluation cycle, etc.), record generation time, and initial status (0-pending execution).

[0057] Persistent storage of records: The generated records of tasks to be executed are stored in batches into the task execution log table to ensure that the records are traceable and to provide a data index for the execution of subsequent evaluation tasks.

[0058] 2) Execution of the assessment task (startGeoAnalysisEngine) Scheduling instruction reception: The scheduling center triggers tasks according to a preset period (such as every 24 hours). After receiving the instruction, the executor calls the entry method of the geoAnalysisService service.

[0059] Pending task processing: Pass in status parameter 0, and geoAnalysisService queries the task execution log table for a list of tasks with a status of "pending execution" (status parameter 0), sorts them by task creation time or priority, and allocates execution resources accordingly.

[0060] Failed task compensation processing: Pass in status parameter 2, geoAnalysisService queries the list of tasks with the status "execution failed" (status parameter 2), filters out tasks that have exceeded the maximum number of retries, and only keeps the failed tasks that can be retried.

[0061] Task execution feedback: After the two types of tasks (pending execution and failure compensation) are processed, the executor returns the ReturnT.SUCCESS flag to the scheduling center to indicate that the task execution is complete, and the scheduling center records the task execution status.

[0062] (4) Scheduling reliability assurance Heartbeat communication maintenance: The actuator sends a heartbeat packet to the scheduling center at preset intervals (e.g., 30 seconds) to report the node's running status and task execution progress. The scheduling center updates the node's online status in real time.

[0063] Fault node task transfer: If the scheduling center does not receive a heartbeat packet from an executor for several consecutive heartbeat cycles, it determines that the node is faulty and automatically reassigns the unfinished tasks of the node to other healthy execution nodes.

[0064] Task timeout control: Configure task timeout time (e.g., 30 minutes) in the scheduling center. If the execution time of a task exceeds the threshold, the scheduling center will automatically mark the task as "execution failed" (2) and trigger subsequent compensation retry.

[0065] Persistent execution logs: During task execution, execution logs (including task ID, execution node, start time, end time, execution result, exception information, etc.) are recorded in real time and stored in the log database for easy troubleshooting and status tracing.

[0066] In the above steps, to address the issue of duplicate execution of the same evaluation task caused by multiple execution nodes simultaneously triggering tasks in a multi-node deployment scenario, a Redis distributed lock mechanism is employed to achieve uniqueness control of task execution. The specific steps of using the distributed lock mechanism to control multi-node task execution include: (1) Definition and initialization of core parameters of distributed lock Lock identifier (KEY) definition: Declare a global constant TASK_LOCK_KEY and assign it the value "_GEO_BEGIN_ANALYSIS" as the unique identifier of the distributed lock, ensuring that all nodes compete for the same lock.

[0067] Lock validity period configuration: Set the default validity period of the lock to 10 seconds, which is fixed through Redis configuration items to avoid lock resource leakage due to execution node failure (downtime, network interruption) and ensure the fault tolerance of the lock mechanism.

[0068] Request Identifier (requestId) Generation: Before each node initiates lock contention, it generates a unique requestId string using UUID to identify the current lock holder and ensure the accuracy of lock release operations.

[0069] Redis lock client initialization: Initialize the Redis distributed lock client (redisDistributedLock), configure parameters such as Redis server address, port, password, connection pool size, etc., and establish a stable connection with the Redis server.

[0070] (2) Lock contention and task execution logic Lock acquisition attempt: After the node triggers the startGeoAnalysisEngine task, it first calls the redisDistributedLock.tryLock(TASK_LOCK_KEY,requestId,10) method to attempt to acquire the distributed lock. This method uses Redis's SETNX command (sets the key if it does not exist, and returns failure if it does) to achieve atomic lock contention.

[0071] Lock acquisition failure handling: If the tryLock method returns false, it means that the lock has been held by another node. The current node records the log information "GEO task is being executed on another node, skip this execution" through the logging component, directly terminates the current task execution process, and does not perform any business logic processing.

[0072] Successful lock acquisition business execution: If the tryLock method returns true, the current node enters the try code block, calls geoAnalysisService.beginAnalysisGeoTask(0) to process the task to be executed, and then calls geoAnalysisService.beginAnalysisGeoTask(2) to process the failure compensation task, and executes the core business logic of the task in sequence (multi-model call, feature extraction, etc.).

[0073] Forced release of lock resources: Regardless of whether the task execution succeeds (completes normally) or fails (throws an exception), the finally block will be entered, calling redisDistributedLock.releaseLock(TASK_LOCK). The `_KEY, requestId)` method ensures that only the holder releases the lock by matching the requestId, thus preventing the accidental release of lock resources for other nodes.

[0074] (3) Lock mechanism adaptation and fault-tolerant design Multi-node cluster adaptation: The locking mechanism is based on the distributed nature of Redis. No matter how many execution nodes are deployed in the system, only one node can acquire the lock and execute the task at the same time. It is naturally adapted to multi-node cluster deployment scenarios and avoids resource waste and data conflicts caused by repeated execution.

[0075] Lock timeout fault tolerance: If a node cannot actively release the lock after acquiring it due to a fault, Redis will automatically delete the lock key after 10 seconds, and the lock will become invalid. Other nodes can then compete for the lock again, ensuring that task scheduling will not be blocked for a long time due to node failure.

[0076] Lock contention concurrency control: Redis's single-threaded nature ensures the atomicity of lock contention, avoiding "overselling" lock contention issues and ensuring the reliability and consistency of the locking mechanism.

[0077] In the above steps, the task status management mechanism achieves execution coordination among multiple nodes through the definition and transition of four task states, while supporting automatic compensation and retry for failed tasks, ensuring the integrity of the evaluation process. The process of achieving multi-node coordination and failed task compensation through task status management specifically includes: (1) Task state definition and initialization Status Enumeration Definition: Define a task status enumeration in the system, and clarify the meaning and encoding of the four statuses: 0-Pending execution (task record generated but not yet started), 1-Execution successful (task fully executed and generated valid results), 2-Execution failed (task execution encountered an exception and was not completed), 3-Executing (task started but not yet finished).

[0078] Status field initialization: When the task record is generated (startGeoExecuteLog task execution), the task status is automatically initialized to "pending execution" (0); during task execution, the status is updated synchronously through database transactions to ensure the atomicity of status changes.

[0079] (2) Multi-node coordination Secondary verification of the status before execution: After a node acquires the distributed lock, before executing a specific evaluation task, it queries the current status of the task in the database by the task ID; if the status is "in execution" (3) or "execution successful" (1), it is determined that the task has been executed by other nodes and the current node skips the task; if the status is "pending execution" (0) or "execution failed" (2), the subsequent process continues.

[0080] Status update during execution: After a node starts executing a task, it immediately performs a database update operation to update the task status from "pending execution" (0) or "execution failed" (2) to "in execution" (3). The atomicity of status update and task execution is guaranteed through database transactions to prevent other nodes from reading the old status at the same time.

[0081] Post-execution status synchronization: After the task is completed, the status is updated according to the execution result: If the execution is successful (no exception and a valid evaluation result is generated), the status is updated to "execution successful" (1), and the evaluation result ID is associated and stored; if the execution fails (an exception is thrown or a valid result is not generated), the status is updated to "execution failed" (2), and the reason for failure (exception stack information, failure link) is recorded.

[0082] (3) Failure task compensation mechanism Compensation task triggering: Each time the startGeoAnalysisEngine task is triggered, the failure task compensation process is automatically triggered, calling the geoAnalysisService.beginAnalysisGeoTask(2) method to query the list of tasks in the database with the status "execution failed"(2).

[0083] Retry eligibility screening: The list of failed tasks is filtered to exclude tasks that have exceeded the maximum number of retries (linked to the number of retries called by the AI ​​model, with a default maximum of 3 times), and only tasks that have not reached the maximum number of retries are retained in the retry queue.

[0084] Retry execution and status update: The retry queue is arranged in reverse order of the task failure time, and the retry tasks are executed in sequence; during the retry process, the process of "state verification before execution → status update during execution → status synchronization after execution" is repeated; if the retry is successful, the status is updated to "execution successful" (1); if the retry still fails, the status remains "execution failed" (2), and the number of failures and the latest failure reason are updated.

[0085] Compensation guarantee and traceability: Compensation retries for failed tasks require no manual intervention and are executed fully automatically; all retry records (trigger time, execution node, result) are stored in the task log table, supporting subsequent manual investigation and traceability, ensuring that task failures caused by temporary anomalies (network fluctuations, temporary unavailability of model services) can be quickly recovered.

[0086] Step S103: Implement large model client management and set up a unified calling interface through the factory pattern, build an exception handling and fault tolerance mechanism, configure retry mechanism and exception handling for each large model, call multiple large models through the unified calling interface and aggregate the response results of each large model.

[0087] The above steps are used to achieve efficient multi-model invocation and result aggregation. First, the five major AI models are managed through the factory pattern (AiWebSearchFactory), providing a unified invocation interface. Then, CountDownLatch is used to implement parallel invocation control and improve execution efficiency. Subsequently, invocation parameters are configured, covering task ID, account ID, prompt words, deep thinking / network search switch status, and 0.8f temperature parameter. A retry mechanism and exception handling (maximum of 3 retries, 3-second delay) are configured for each model invocation to ensure stable invocation. Finally, all model response results are aggregated.

[0088] In the above steps, managing large model clients and setting up a unified calling interface through the factory pattern encapsulates the creation and management logic of different large model clients, eliminating the coupling between the caller and the specific client, and achieving unified access and calling of multiple models. Specifically, this includes: (1) Abstract client definition First, define an abstract client class AiWebSearchAbstractClient, which encapsulates the common calling methods (such as chatWithWebSearch) and core attributes (such as model type and interface address) for all large model clients, providing a unified behavior specification for all specific clients and ensuring that different model clients have a consistent calling standard.

[0089] (2) Factory class construction and initialization Create an AiWebSearchFactory class with a built-in static HashMap (CLIENT_MAP) as the client mapping table. The key is AiModelTypeEnum (model type enumeration, including DouBao, DeepSeek, Tencent Yuanbao, etc.), and the value is AiWebSearchAbstractClient (abstract client). When the factory class is initialized, it receives an array of all concrete clients (such as AWebSearchDouBaoClient, AWebSearchDeepSeekClient), iterates through the array, and registers each client to CLIENT_MAP according to its AiModelTypeEnum type, thus completing the centralized storage of clients.

[0090] (3) Unified API Design The factory class exposes the getClient(AiModelTypeEnummodelType) method as a unified calling interface. The caller only needs to pass in the enumeration type of the target model, and the factory can match and return the corresponding specific client instance from CLIENT_MAP. Regardless of which model is called, the caller obtains the client through this interface without needing to be aware of the implementation differences of the client of different underlying models, thus achieving "one interface call, adapting to multiple models".

[0091] (4) Client Management Extension When adding a new large model client, you only need to implement the AiWebSearchAbstractClient abstract class, define the corresponding AiModelTypeEnum enumeration value, and add the new client to the registration array during factory initialization. You can complete the access of the new model without modifying the caller code, thus ensuring the scalability of client management.

[0092] The above steps involve constructing an exception handling and fault tolerance mechanism to address potential issues such as result parsing errors, aggregation conflicts, lock contention timeouts, and database connection errors that may occur during parallel multi-model calls. This ensures the continuity of task execution and data integrity, reduces the impact of single-scenario exceptions on the overall process, and forms a dual fault tolerance guarantee with the subsequent retry mechanism and exception handling configuration for each large model. Specifically, this covers five sub-scenarios, each with clearly defined triggering conditions, processing flows, subsequent connections, and logging standards to ensure feasibility and traceability, and to guarantee the system's stability and data integrity under abnormal scenarios. Specifically, this includes: (1) Downgraded handling of abnormal format of AI model returned results This scenario addresses the formatting issues that arise when parsing the JSON-formatted structured analysis results returned by AI models after calling multiple large models through a unified API. It is closely integrated with the subsequent result aggregation stage, and the processing flow balances maximizing data extraction with workflow continuity, as detailed below: When parsing the structured analysis results in JSON format returned by the AI ​​model, a three-layer format validity check is first performed using a pre-set JSON parsing and validation tool to ensure that the results meet the parsing requirements for subsequent brand identification and ranking extraction. The three layers of validation are as follows: ① JSON syntax validation: Validating whether the returned text conforms to the standard JSON syntax to avoid problems such as syntax errors and mismatched brackets; ② Required field existence validation: Validating whether the returned results contain core fields necessary for subsequent steps, such as brandName, visible, and rank. If any required field is missing, the validation is deemed to have failed; ③ Field type validation: Validating whether the types of each core field conform to the pre-set specifications (e.g., visible is boolean or 0 / 1 numeric, rankNum is integer, and tendency is -1 / 0 / 1 / 2 numeric). If the types do not match, the validation is deemed to have failed.

[0093] If any of the three layers of verification fails, a tiered degradation process is immediately triggered to ensure that as much valid data as possible is extracted, avoiding the interruption of the entire process due to a single model parsing anomaly. The tiered degradation logic is as follows: Level 1 Degradation: Attempt to extract key information from the original response text of the model using preset regular expressions. The regular expression rules are specifically matched to the core content required for subsequent steps, including: brand name (matching Chinese and English brand keywords and company abbreviations), ranking number (matching integers between 1 and 100 and corresponding textual expressions such as "first place" and "first" and converting them into numbers), and sentiment keywords (matching sentiment descriptions such as "positive," "negative," and "neutral" and words with positive or negative connotations). Based on the extracted key information, a simplified structured result is constructed, and default values ​​for required fields are added (if visibility is not extracted, it is set to 0 by default) to ensure that the result can be successfully integrated into subsequent brand identification and ranking analysis steps.

[0094] Second-level degradation: If regular expression extraction still fails (no key information is extracted), the current call status of the model is marked as "parsing error". Detailed error information is recorded in the error log table (the log includes fields such as task ID, model type, call time, error type, original response text, and verification failure details). At the same time, the analysis results of this model are removed from the aggregation result set. This does not affect the valid results of other models. Subsequent aggregation processes will continue to execute only based on the valid results of the remaining models, ensuring that the overall process is not interrupted.

[0095] Special scenario handling: If all called AI models experience parsing anomalies (i.e. all models trigger the second-level degradation), it is determined that this multi-model call has no valid result. The current task status is updated to "execution failed", and the failure compensation mechanism is triggered (notifying the operation and maintenance personnel to investigate the model interface and return format issues, while recording the task failure details and supporting manual triggering of task retry), ensuring that the anomaly is traceable and remediable.

[0096] (2) Conflict resolution strategies when aggregating results from multiple models This scenario addresses the issue of conflicting judgments by multiple AI models regarding the core features of the same brand during the aggregation of responses from various large models. It supplements and improves the conflict determination criteria, resolution logic, and traceability mechanism to ensure the accuracy and consistency of the aggregated results, providing reliable data for subsequent brand identification, sentiment analysis, and other stages. Specifically: When multiple AI models make conflicting judgments about the same brand's features (with clearly defined conflict criteria: for the same core feature of the same brand, different models return inconsistent results, such as model A classifying brand X as having a positive sentiment while model B classifies it as negative; model C classifying brand Y as ranking 3rd while model D classifies it as ranking 5th; some models identify brand Z while others do not), a "confidence-weighted voting" strategy is used to resolve the conflict, balancing model accuracy with the reasonableness of the results. The specific process is as follows: The first step is to configure the model confidence weights: a basic confidence weight is preset for each AI model (the initial value is 1.0 for all models). The weights are dynamically adjusted based on the model's historical call accuracy (the adjustment period is every day at midnight, and the adjustment logic is: the model's daily accuracy = the number of valid judgments of the model on that day ÷ the total number of calls of the model on that day, and the weight = the model's daily accuracy ÷ the average daily accuracy of all models, ensuring that models with higher accuracy have higher weights and affect the final aggregation result). The weight adjustment records are synchronously stored in the model management table, which supports manual viewing and intervention.

[0097] The second step is to resolve conflicts by type: Different resolution logics are used for conflicts based on different core characteristics to ensure the results align with business needs. ① Emotional Tendency Conflict: Calculate the weighted votes for each emotional category (weighted votes = sum of model weights supporting that emotional category, e.g., positive votes = model A weight × 1 + model C weight × 1, negative votes = model B weight × 1, neutral votes = model E weight × 1), and take the emotional category with the highest weighted votes as the brand's final emotional tendency; if there are ties in weighted votes, "neutral" is taken as the final result by default, balancing conservatism and rationality.

[0098] ② Ranking position conflict: Extract the brand ranking position returned by all models (remove model results of "no ranking" or "parsing error"), calculate the weighted average of each ranking (weighted average = Σ(model ranking × model weight) ÷ Σ model weights supporting the ranking), and round the weighted average to the nearest integer as the brand's final ranking; if all models return "no ranking", the final ranking is set to -1 (invalid ranking), consistent with the ranking extraction logic above.

[0099] ③ Visibility conflict (some models recognize the brand, some models do not): A "lenient strategy" is adopted with clear judgment criteria: as long as one model successfully recognizes the brand (i.e., the model returns the brand's visible=1 or a valid brand name), the brand is judged to be visible (bindVisible=1); only when all models fail to recognize the brand and there are no valid parsing results is it judged to be invisible (bindVisible=0), to avoid brand omissions due to recognition bias of some models.

[0100] The third step is conflict resolution traceability: The conflict resolution process and the basis for the final decision are recorded in detail in the results details table (the record includes: brand name, conflict feature type, results and weights returned by each model, calculation process of weighted votes / weighted average, and final decision result), which supports subsequent manual review. If any abnormality is found in the aggregated results, it can be traced back to the specific model and calculation process, which is convenient for problem investigation and strategy optimization.

[0101] (3) Distributed lock acquisition timeout handling process This scenario connects the concurrency control logic for parallel calls of multiple models. Addressing potential lock acquisition timeout issues in the Redis distributed lock contention phase, it supplements and improves timeout judgment, processing flow, retry rules, and logging standards to avoid task blocking and duplicate execution caused by lock contention, ensuring the orderly execution of parallel calls of multiple models. Specifically: Before starting multi-model parallel calls, a Redis distributed lock needs to be acquired (the core function of the lock is to prevent the same task from being executed by multiple nodes at the same time, avoiding duplicate model calls and result chaos). The system presets the lock acquisition timeout (default 5 seconds, which can be flexibly configured according to task complexity and model call time). The lock key format is "task:lock:{task ID}", and the value is the current node ID. The default validity period of the lock is 300 seconds (to avoid deadlock caused by the lock not being released).

[0102] If the current node fails to acquire the distributed lock within the preset timeout period (5 seconds), the following processing flow will be triggered immediately to balance task execution efficiency and concurrency safety: The first step is logging: Immediately log a "lock acquisition timeout" message. The log should include details such as node ID, task ID, lock acquisition timeout duration, current lock holder information (obtained by querying the lock's value in Redis), and remaining lock validity period (obtained by querying the lock's TTL value in Redis) to ensure that the anomaly is traceable.

[0103] The second step is timeout reason determination and tiered handling: Based on the queried remaining lock validity period, the timeout reason is determined, and differentiated handling logic is used to avoid invalid retries. ① If the current lock holder's lock has a remaining validity period of more than 3 seconds, it means that the task is being executed normally on other nodes (no deadlock has occurred). The current node directly exits the lock contention process without retrying, thus avoiding multiple nodes repeatedly competing for the lock and wasting system resources. At the same time, a "lock contention exit" log is recorded, indicating the reason for exit.

[0104] ② If the remaining validity period of the lock held by the current lock holder is less than 3 seconds, it means that the lock is about to be released (there may be a situation where the lock holder has finished executing but has not released the lock in time). The current node enters a short waiting state, and the waiting time is equal to the remaining validity period of the lock plus 1 second (to ensure that the lock is completely released before retrying). After the waiting period ends, the node will try to acquire the distributed lock again, and can retry a maximum of 2 times.

[0105] The third step is retry failure handling: If the current node still fails to acquire the distributed lock after two retries, it immediately records a "lock contention failure" log, indicating the number of retries and the duration of each retrieval. The current node then officially exits the task execution process, and the task is continued by the node currently holding the lock, ensuring that the task is not interrupted or repeated.

[0106] As a fallback: If the remaining validity period of the lock is found to be -1 (the lock has expired and has not been released normally), the current node will directly force the release of the lock (delete the lock key in Redis) and then try to acquire the lock again to avoid the task being unable to execute due to deadlock.

[0107] (4) Cache fallback solution for database connection failure This scenario addresses potential database connection anomalies during database operations such as task configuration reading, model client information querying, and aggregation result storage. It improves caching design, fallback processes, data consistency guarantees, and alerting mechanisms to ensure normal task execution and no data loss, as detailed below: In the entire process of multi-model parallel invocation and result aggregation, multiple database operations are involved (including: reading task configuration information from the database, reading large model client configuration information, storing model invocation logs, and storing aggregation results). To cope with database connection anomalies (such as database connection timeout, connection pool exhaustion, database service crashes, etc.), Redis caching is introduced as a fallback solution to implement the logic of "caching first, database fallback, and anomaly switching," as detailed below: The first step is cache preheating and priority reading: Task configuration information (including the list of evaluated brands, model call parameters, weight thresholds, etc.) and large model client configuration information (including model interface address, call key, basic weights, etc.) are synchronously written to the Redis cache after the first read from the database. The cache key adopts the format "config:task:{task ID}" and "config:model:{model type}". The cache validity period is consistent with the task validity period (the cache automatically expires after the task is completed). When reading this type of information later, it is retrieved from the Redis cache first. The database is only queried when the cache is not hit (cache expired or cache does not exist), which reduces the database access pressure and improves the reading efficiency.

[0108] The second step is a fallback switch for database connection anomalies: When the system detects a database connection anomaly (based on connection status detection in the database connection pool, the criteria being: three consecutive failed attempts to acquire a database connection, or a connection timeout exceeding 3 seconds), it immediately and automatically switches to "cached read-only mode" to ensure that the task continues to execute without interruption. The specific switching logic is as follows: ① Task configuration read: Reads task configuration information only from the Redis cache. If the cache is not hit (e.g., the task is a new task and the cache has not been warmed up), the task is marked as "configuration read failed", triggers an alarm and terminates the task execution.

[0109] ② Result Storage: Model call logs, aggregation results, and other data generated during the evaluation process are temporarily stored in a Redis temporary queue (the queue key format is "cache:task:result:{taskID}", and the queue capacity is set to a maximum of 1000 records to avoid queue overflow). The data in the temporary queue is sorted by timestamp to ensure data order. At the same time, a data temporary storage log is recorded, indicating the reason for temporary storage (database connection error).

[0110] ③ Database health check: After switching to "cache read-only mode", the system automatically triggers a database health check task. The check cycle is once every 30 seconds. The check content includes database connection status and service running status. The check results are synchronously recorded to the operation and maintenance log.

[0111] The third step is data consistency assurance and recovery: Once the database recovers to normal (passes two consecutive health checks), the system automatically exits the "cache read-only mode" and switches back to normal mode. At the same time, it triggers the data synchronization process of the Redis temporary queue, synchronizing all data temporarily stored in the temporary queue to the database in batches. After synchronization is complete, the Redis temporary queue is cleared, and a data synchronization log is recorded (including the amount of synchronized data, synchronization duration, and whether synchronization was successful). If a failure occurs during the synchronization process, a retry mechanism is triggered (up to 3 retries). If a retry fails, the operations and maintenance personnel are notified for manual handling to ensure eventual data consistency and prevent the loss of any valid data.

[0112] The fourth step is handling extreme scenarios: If the database continues to be abnormal for more than the preset threshold (30 minutes by default), the system will immediately send an alarm notification to the administrator (via email or WeChat). The alarm content includes the type of abnormality, the duration of the abnormality, and the amount of temporarily stored data. At the same time, the creation of new tasks will be suspended, and only tasks that have completed cache preheating will be allowed to continue to execute, so as to avoid Redis overflow caused by a large amount of temporarily stored data and reduce system risks.

[0113] (5) Monitoring and alarming of anomalies in the entire task execution chain This scenario serves as a fallback in the entire exception handling and fault tolerance mechanism, covering the entire process of parallel multi-model calls and result aggregation. It supplements and improves monitoring indicators, exception thresholds, alarm mechanisms, and handling suggestions to achieve real-time exception detection, rapid response, and timely processing, ensuring the stable operation of the entire process. Details are as follows: Establish a full-chain anomaly monitoring system for task execution. Relying on monitoring tools, collect multi-dimensional monitoring metrics in real time, set reasonable anomaly thresholds, and automatically trigger alarms for anomaly scenarios. Simultaneously, provide clear handling suggestions to facilitate quick problem location and resolution for operations and maintenance personnel. The monitoring scope covers all aspects including factory mode client management, model invocation, result parsing, aggregation conflicts, lock contention, and database operations. Specific additions and improvements are as follows: The first step is to define core monitoring metrics and anomaly thresholds: Clearly define the following core monitoring metrics and their corresponding anomaly thresholds to ensure that anomalies are quantifiable and triggerable: ① AI model call anomaly rate: In a single batch of tasks, the number of model call failures (including interface call failures and timeouts) ÷ the total number of model calls. The anomaly threshold is set to 30% (exceeding this threshold indicates that multiple models have interface problems). ② Number of consecutive failed calls to the AI ​​model: The number of consecutive failed calls to the same model. The abnormal threshold is set to 3 times (if the number of times exceeds this threshold, it indicates that the model interface is abnormal and needs to be investigated). ③ Task execution time: The total time taken for a single task from startup to completion of the aggregated result. The abnormal threshold is set to 60 minutes (exceeding this threshold indicates abnormal task execution, which may be due to model call timeout, lock blocking, or other issues). ④ Result parsing anomaly rate: In a single batch of tasks, the number of times the model returns result parsing anomalies (triggering degradation processing) ÷ the total number of model calls, with the anomaly threshold set at 30%; ⑤ Distributed lock holding time: The duration for which a single node holds a distributed lock. The exception threshold is set to 300 seconds (exceeding this threshold indicates that there may be a deadlock or abnormal task execution). ⑥ Duration of Database Connection Anomalies: The duration during which the database remains in a connection anomaly state. The anomaly threshold is set to 30 minutes. ⑦ Redis cache hit rate: number of successful cache reads ÷ total number of cache reads, with an exception threshold set to 50% (if it is lower than this threshold, it indicates that the cache design is unreasonable and needs to be optimized).

[0114] The second step is the alarm mechanism: when any monitored indicator reaches an abnormal threshold, the system immediately triggers an alarm. The alarm mechanism has been supplemented and improved as follows: ① Alarm channels: Supports three alarm channels: email, WeChat Work, and SMS (priority can be configured, core anomalies trigger dual alarms via SMS and WeChat Work), ensuring that maintenance personnel receive notifications in a timely manner; ② Alarm content: Alarm information includes the type of exception, trigger time, task ID, exception details (e.g., model call exception should specify the model type and reason for the exception; lock holding time exception should specify the node ID and remaining lock validity period), current monitoring indicator value, exception threshold, and suggested handling measures (e.g., continuous model failures suggest checking the interface key; database exceptions suggest checking the database service). ③ Alarm classification: Classified into three levels according to the severity of the anomaly: Level 1 (urgent): Task execution failure, database continuous anomaly for more than 30 minutes, all model calls fail, requiring immediate handling; Level 2 (general): Single model fails 3 times in a row, parsing anomaly rate exceeds 30%, requiring handling within 1 hour; Level 3 (hint): Cache hit rate is less than 50%, lock acquisition timeout and retry failed, requiring optimization within 24 hours. ④ Alarm Retry: If the alarm notification fails to be sent (such as email delivery failure or SMS delivery failure), it will be retried once every 5 minutes, with a maximum of 3 retries, to avoid unhandled exceptions due to alarms not being delivered.

[0115] The third step is the anomaly closure loop: After handling the anomaly, the maintenance personnel can mark the anomaly handling status (unhandled, in process, handled) on the monitoring platform. After the handling is completed, a handling record (including handling method, handling result, and cause of the problem) must be filled in to form an anomaly handling closure loop. At the same time, the system automatically counts the anomaly handling time and handling success rate to provide data support for subsequent fault tolerance mechanism optimization.

[0116] In the above steps, retry mechanisms and exception handling are configured for each large model. To address the instability of individual large model calls, standardized retry and exception handling logic is configured for each model call process to ensure the reliability of each model call. Specifically, this includes: (1) Retry parameter preset In the core method chatWithWebSearch for model invocation, the preset retry parameters are: a maximum of 3 retries and a retry delay of 3 seconds (implemented by Thread.sleep(3000)). The parameters can be flexibly adjusted through the configuration file to adapt to the interface stability of different models.

[0117] (2) Design of retry loop logic The core call logic, doChatWithWebSearch (the method that actually initiates the model dialogue request), is encapsulated in a loop. The retry counter, retryCount, is initialized to 0. Before each call to doChatWithWebSearch, it is first checked whether retryCount is less than the maximum number of retries. If it is, the call is executed. If the call throws an exception (such as network timeout or interface error), retryCount is incremented, and the loop is re-executed after 3 seconds.

[0118] (3) Anomaly detection and classification In the retry loop, different types of exceptions such as IOException (network exception) and ApiException (interface exception) are caught, and exception details (such as exception type, model type, and call parameters) are recorded to the log. If a call does not have an exception, the model response result is returned directly and the loop is terminated. If the loop reaches the maximum number of retries and still throws an exception, the loop is terminated and an empty result is returned, marking the model call as failed.

[0119] (4) Independent configuration guarantee Each large model's invocation task executes the retry and exception handling logic independently. The failure or retry of one model's invocation will not affect the execution flow of other models, ensuring the isolation of exceptions when multiple models are invoked in parallel.

[0120] In the above steps, multiple large models are invoked through a unified API, and the response results from each large model are aggregated. Based on the factory pattern, a unified API, combined with a multi-threaded parallel mechanism, is used to implement multi-model invocation and synchronously aggregate all response results. Specifically, this includes: (1) Preparations before parallel invocation Read the list of model types selected by the user (such as Doubao, Tongyi Qianwen) from the task configuration, count the number of models and initialize CountDownLatch (the counter value is equal to the number of models), which is used by the main thread to wait for all models to call the task to complete; Based on the selected model type, the corresponding client instance is obtained sequentially through the getClient interface of the factory class, and the standardized calling parameter ChatReqVo (including task ID, account ID, prompt word, deep thinking / network search on / off status, and 0.8f temperature parameter) is constructed.

[0121] (2) Multi-threaded parallel calls Initialize the aiExector multi-threaded executor to create an independent thread task for each selected model; Within the thread task, the client instance obtained through the factory's unified interface calls the chatWithWebSearchByType method, passing in ChatReqVo and the corresponding model enumeration, to execute the model dialogue request; After each thread task is completed (regardless of whether it returns a result on success or returns null on failure), the CountDownLatch.countDown() method is called to decrement the counter value by 1, marking the completion of the task for that model.

[0122] (3) Main thread blocking and result aggregation The main thread calls the CountDownLatch.await() method and blocks until all thread tasks are completed (the counter value is zero), ensuring that all model call results have been returned; Iterate through the execution results of all thread tasks, collect non-empty model response texts, and store them according to model type (such as Doubao response, Tongyi Qianwen response) to form a structured aggregated result set; for models that return empty due to failure, record the failure identifier and reason, and include them in the exception information module of the aggregated result.

[0123] (4) Validation of aggregation results The aggregation result set is validated to ensure that the number of selected models matches the number of records in the result set (including success / failure records), thus avoiding result loss due to thread exceptions and ensuring the integrity of the aggregation results.

[0124] Step S104: Construct brand extraction prompts, encapsulate structured analysis parameters, call the AI ​​tool interface and pass in the prompts and structured analysis parameters to obtain structured analysis results containing each identified brand; extract brand-related information from the structured analysis results and perform quantitative transformation, and generate default value records for unidentified bound brands.

[0125] The above steps perform brand identification and ranking analysis, building upon the large model response text output from the preceding multi-model parallel invocation and result aggregation steps. AI is driven by specialized prompts to identify the target brand and competing brands, extract and standardize brand ranking-related information, determine brand visibility status, and automatically complete default attribute records for unidentified bound brands to ensure data integrity. The output is structured feature data containing brand information, visibility, ranking, and sentiment, providing foundational identification results for subsequent sentiment analysis and media attribution judgment, and offering core feature support for subsequent evaluation index calculations. This achieves a seamless transition from the model's original response to standardized evaluation features.

[0126] The above steps involve constructing brand-extracted prompts, encapsulating structured analysis parameters, and calling AI tool interfaces by passing in the prompts and structured analysis parameters. Specifically, this includes: (1) Construction of brand extraction prompts Based on the core requirements of brand recognition and ranking analysis, a pre-defined brand extraction prompt (PromptConstant.EXTRACT_BRAND_PROMPT) is established. The prompt clearly instructs the AI ​​to identify the self-owned brand and competitor brands from the specified text and return standardized JSON format results containing dimensions such as visibility, ranking, and sentiment, ensuring that the AI ​​output meets the requirements of subsequent parsing.

[0127] (2) Encapsulation of structured analysis parameters Create a JSONObject structured parameter object and populate it with three types of core parameters according to the interface specification: input text (the multi-model response content aggregated from the previous steps), own name (an array of self-owned brands bound in the task configuration), and competitor list (an array of competitor brand lists bound in the task configuration). Ensure that the parameters cover all the core information required for AI analysis and that the format is adapted to the requirements of the AI ​​tool interface.

[0128] (3) AI tool interface call Initialize the aiUtils utility class, call its chatWithAI core method, and pass in the constructed brand extraction prompts, parameter JSON strings, and a unique identifier for this analysis task according to the interface requirements. Trigger the brand analysis process of the AI ​​tool, and synchronously wait for and receive the structured analysis results in JSON array format returned by the AI.

[0129] The above steps involve extracting brand-related information from the structured analysis results and performing quantitative transformation, specifically including: (1) Structured result parsing The system iterates through the JSON array returned by the AI, parsing each brand's full range of fields line by line, covering core dimensions such as brand name, visibility, presence of a ranking, specific ranking position, sentiment, and negative descriptions, ensuring that no key information is missed.

[0130] (2) Standardized Quantification Conversion A unified quantization rule is applied to non-textual features, converting qualitative information such as "visibility" and "whether there is a ranking" into binary quantization values ​​of 0 (no / no) or 1 (yes / no); the rationality of numerical information such as "ranking position" is verified (non-numeric values ​​are marked as -1) and the original values ​​are retained; "sentiment tendency" is quantized and encoded according to preset rules (positive = 1, neutral = 0, negative = -1), so that all features are adapted to the subsequent index calculation requirements.

[0131] (4) Storage of extraction results The parsed and quantified brand information is categorized by brand name, encapsulated into structured data entity classes, and persistently stored by associating it with a unique task ID, forming a standardized brand feature dataset.

[0132] The above steps involve generating default value records for unrecognized bound brands, specifically including: (1) Unidentified Brand Screening The list of brands identified by AI is compared with the list of self-owned brands and competitor brands bound in the task configuration to accurately filter out the bound brands that do not appear in the AI ​​analysis results (i.e., the target brands that are not identified).

[0133] (2) Default value rule configuration The default value system for unidentified brands is preset, with visibility and whether there is a ranking set to 0 (none), ranking position set to -1 (invalid value), sentiment set to 0 (neutral), and negative description set to an empty string, to ensure that the default values ​​conform to the subsequent index calculation logic.

[0134] (3) Default record generation and supplementation Create an independent data record for each unidentified bound brand, fill in all feature fields with preset default values, and supplement it to the brand analysis result set after associating it with the task ID. Finally, verify that the total number of the result set is consistent with the total number of bound brands to ensure data integrity and avoid missing subsequent analysis steps due to unidentified brands.

[0135] Step S105: Conduct in-depth verification and detailed analysis of brand sentiment, improve sentiment-related features; determine the media source attribution of brand-related content, complete media classification identification; output standardized data containing detailed sentiment information and media attribution classification.

[0136] The above steps are used for sentiment analysis and media attribution determination. Building upon the structured brand characteristic data output from the preceding brand identification and ranking analysis steps, they primarily achieve two functions: first, to deepen and refine the analysis of brand sentiment orientation, improving sentiment-related characteristics; and second, to determine the media source attribution of brand-related content, completing media classification and labeling. Simultaneously, they standardize the handling of abnormal data to ensure the integrity of the results, ultimately outputting standardized data containing refined sentiment information and media attribution classification. This provides core support for subsequent brand evaluation index calculation and assessment result aggregation, achieving a seamless transition from basic brand identification to comprehensive feature-based in-depth analysis.

[0137] The above steps involve in-depth verification and detailed analysis of brand sentiment, refining sentiment-related features. This step, based on the structured brand data output from the brand identification and ranking analysis steps, combines specific technical methods to further verify and standardize brand sentiment, refining sentiment-related features and ensuring the standardization and accuracy of sentiment data. Specifically, this includes: (1) The system calls the getTendencyId() method of the dataInfoFactory factory class to standardize the sentiment description (positive, neutral, negative) returned by the preceding AI and strictly follow the preset rules: -1 represents negative sentiment, 0 represents neutral sentiment, and 1 represents positive sentiment, realizing the transformation of sentiment from text description to quantitative label, and adapting to the subsequent index calculation requirements.

[0138] (2) Conduct in-depth verification of sentiment orientation, and make logical judgments based on the brand's visibility status (bindVisible attribute) from the previous steps: If bindVisible is 0 (meaning the brand is not visible), it indicates that the brand has no relevant emotional information, and the emotional tendency is set to 2 (marked as "not applicable"). If bindVisible is not 0 (i.e. brand is visible), the numerical identifier converted by the getTendencyId() method will be directly assigned to the tendency attribute of the model analysis result to complete the accurate assignment of sentiment tendency.

[0139] (3) Integrate information such as quantitative indicators of sentiment tendency and visibility association rules into the brand's structured feature data, improve the sentiment-related feature system, correct the sentiment tendency anomalies caused by brand visibility, ensure that the sentiment characteristics are consistent with the actual state of the brand, and provide accurate sentiment data support for subsequent evaluation.

[0140] In the above steps, determining the media source attribution of brand-related content and completing media classification labeling relies on pre-set methods and services. Through multi-step judgment logic, it accurately determines the media source attribution of brand-related content, completes standardized media classification labeling, and lays the foundation for subsequent media quantity statistics. Specifically, this includes: (1) Judgment by own media A dedicated `checkOwnMedia()` method is defined. This method takes two core parameters: the website name and a list of proprietary brands. It uses a two-way inclusion logic to check whether the website name contains the proprietary brand name, or whether the proprietary brand name contains the website name. If either condition is met, it indicates a strong association between the website and the proprietary brand, and the method returns `true` (determined to be proprietary media). If neither condition is met, it returns `false` (not proprietary media), providing a basis for subsequent media classification.

[0141] (2) Mainstream media matching The KeyMediaMatchService is used to accurately identify mainstream media. The determineOwnMedia() method is defined to execute a three-step judgment logic based on priority, ultimately completing the media classification identification: First, it prioritizes matching mainstream media by calling the KeyMediaMatchService to determine if the current website is core media. If it is determined to be core media, the checkMainMediaHitBrandName() method verifies that the content title and body contain the independent brand name. After successful double verification, it is determined to be core media and returns a value of 2. Second, it checks whether it is owned media. If the original website name is not empty and the checkOwnMedia() method returns true, it indicates that the website is owned media and returns a value of 1. Third, if neither of the above two judgments is satisfied, it means that the media ownership cannot be clearly determined, and it is judged as unknown media, returning a value of 0.

[0142] (3) Classification labeling implementation The numerical identifiers returned by the determineOwnMedia() method (0 = unknown media, 1 = owned media, 2 = core media) are assigned to the media type attribute of the corresponding brand-related content. This completes the determination of the media source attribution and standardized classification identifier for each piece of brand-related content, ensuring the uniformity and standardization of media classification.

[0143] The above steps output standardized data containing detailed sentiment information and media affiliation classification. This step integrates the analysis results from the first two parts, combines media quantity statistics methods, completes data standardization processing, and finally outputs a standardized dataset adapted for subsequent steps, achieving seamless integration with the brand evaluation index calculation and evaluation result summary steps. Specifically, this includes: (1) Data integration First, the detailed analysis results of brand sentiment are integrated, including numerical identifiers converted by the getTendencyId() method (-1=negative, 0=neutral, 1=positive, 2=not applicable), as well as the associated brand visibility status, to ensure the refinement and completeness of sentiment information. At the same time, the media attribution classification results are integrated, that is, the media type numerical identifier (0, 1, 2) corresponding to each piece of brand-related content, as well as the corresponding website name and judgment criteria, to achieve the association and binding of sentiment information and media attribution information.

[0144] (2) Statistics on the number of media outlets The system invokes two pre-defined statistical methods to accurately count the number of media outlets: the first is the getMediaCount() method, which iterates through the brand-related citation list to count the number of citations for media type 1 (own media) that are related to the target brand, thus obtaining the number of own media outlets; the second is the getMainMediaCount() method, which similarly iterates through the citation list to count the number of citations for media type 2 (core media) that are related to the target brand, thus obtaining the number of mainstream (core) media outlets, and then adds the statistical results to the dataset.

[0145] (3) Standardized output All integrated data undergoes standardized verification, unifying data formats and quantification rules, and correcting issues such as missing data and abnormal labeling to ensure the consistency and accuracy of sentiment information, media classification labels, and media quantity statistics. The final output is a structured, standardized dataset covering core content such as basic brand information, refined sentiment numerical labels, media affiliation classification labels, and the number of owned / mainstream media outlets. This dataset directly provides comprehensive and accurate standardized data support for subsequent brand evaluation index calculations (such as sentiment index and media influence index), achieving efficient integration between this step and subsequent steps.

[0146] Step S106: Calculate and integrate the results of various indices, identify the brand's performance weaknesses, and generate optimization suggestions.

[0147] The above steps are used for calculating evaluation indices and generating optimization suggestions. They build upon the detailed sentiment information, media classification labels, and media quantity statistics output from the preceding sentiment analysis and media attribution determination steps. The core functions are: first, based on data such as brand visibility, ranking, sentiment orientation, and media citations, and according to preset weights and quantitative logic, to calculate five standardized evaluation indices: visibility index, top-ranking index, ranking index, sentiment index, and citation index; second, combining the results of these five indices with details from previous analyses, to pinpoint brand performance weaknesses, identify their causes, and generate targeted and actionable optimization suggestions. The evaluation indices and optimization suggestions output in this step connect to the subsequent summary of evaluation conclusions and report generation, providing core data support and precise optimization guidance for comprehensive brand evaluation. Specifically, this includes: (1) Visible index calculation The visibility index is primarily used to quantify brand exposure and visibility. Its calculation logic is strictly linked to the preceding brand visibility assessment results. Specifically, it works as follows: Using all self-owned and competitor brands bound in the task configuration as the calculation base, the visibility identifier (bindVisible attribute, 0 = invisible, 1 = visible) for each brand is extracted. Brand data with a sentiment tendency of 2 (not applicable, i.e., the brand is not visible) is excluded, and the number of visible brands (the total number of brands with bindVisible=1) is counted. A standardized quantitative formula is used to calculate the visibility index: Visibility Index = (Number of visible brands ÷ Total number of bound brands) × 100 × Preset weight (the weight can be flexibly configured according to evaluation needs, with a default percentage of 20%). After calculation, the result is rounded to two decimal places to ensure index accuracy and intuitively reflect the overall brand exposure and visibility level. The corresponding Java code is as follows: double vProp = divide(visibilityProp, totalCount, 3,RoundingMode.HALF_UP) * 100; analysisStatistical.setVisibilityProp(vProp).

[0148] (2) Calculation of the first index The First-Place Index focuses on the advantage of a brand's first-place exposure, quantifying its core competitiveness in rankings. The calculation process is closely linked to the extraction results of preceding ranking positions. The technical details are as follows: Using visible brands (bindVisible=1) as the calculation range, the ranking position identifier for each brand is extracted (rankNum attribute, 1 = first place, -1 = no ranking, other values ​​indicate non-first-place ranking); the number of first-place brands is counted (the total number of brands with rankNum=1 and bindVisible=1); the calculation formula is: First-Place Index = (Number of first-place brands ÷ Number of visible brands) × 100 × Preset weight (default percentage 20%); if the number of visible brands is 0, the First-Place Index is directly assigned a value of 0; the result is rounded to two decimal places, accurately reflecting the brand's ability to gain first-place exposure and highlighting the core value of first-place ranking. The corresponding Java program code is as follows: double fProp = divide(firstProp, rankCount, 3, RoundingMode.HALF_UP)* 100; analysisStatistical.setFirstProp(fProp).

[0149] (3) Ranking index calculation The ranking index is used to quantify the overall ranking competitiveness of a brand, integrating two core pieces of information: "whether it has a ranking" and "its specific ranking order." The technical details are as follows: Using visible brands as the calculation scope, the ranking identifier (rank attribute, 0 = no ranking, 1 = ranked) and specific ranking position (rankNum attribute) of each brand are extracted. For ranked brands (rank=1), reverse quantification is performed according to the ranking order (i.e., the highest ranking value is 1, and the quantification value decreases as the ranking decreases; for example, ranking 1 is quantified as 1, ranking 2 as 0.9, and so on. If there is no fixed highest ranking, the actual highest ranking is used as the benchmark). For unranked brands (rank=0 or rankNum=-1), the quantification value is assigned to 0. The calculation formula is: Ranking Index = (Sum of quantification values ​​of all visible brand rankings ÷ Number of visible brands) × 100 × Preset weight (default percentage 20%). If the number of visible brands is 0, the ranking index is assigned to 0. The result is rounded to two decimal places, comprehensively reflecting the overall performance of the brand ranking. The corresponding Java program code is as follows: private int getScoreByRanking(double avgRanking) { if (avgRanking <= 1.0) { return 100; / / Rank 1: 100 points } else if (avgRanking < 5.0) { return 80; / / Rank < 5: 80 points } else if (avgRanking < 10.0) { return 70; / / Rank < 10: 70 points } else { return 50; / / Rank ≥ 10: 50 points } } (4) Calculation of Emotion Index The emotional index quantifies the brand's emotional reputation performance, strictly relying on the refined emotional tendency analysis results from the previous step, and incorporating emotional confidence to optimize accuracy. The technical details are as follows: The calculation range is based on visible brands (bindVisible=1, tendency≠2), and the emotional tendency numerical identifier (tendency attribute, -1=negative, 0=neutral, 1=positive) and emotional confidence of each brand are extracted; the emotional tendency of each brand is weighted and quantified, positive sentiment (1) is weighted by confidence (confidence × 1), neutral sentiment (0) is weighted by 0, and negative sentiment (-1) is weighted by confidence (confidence × (-1)); the calculation formula is: emotional index = (total emotional weight of all visible brands ÷ number of visible brands) × 100 × preset weight (default percentage 20%); if the number of visible brands is 0, the emotional index is assigned a value of 0, and the result is retained to 2 decimal places, taking into account the difference between positive and negative sentiment and the reliability of judgment, and accurately reflecting the brand's reputation. The corresponding Java program code is as follows: double nnProp = divide(nonNegativeProp, visibilityProp, 3,RoundingMode.HALF_UP) * 100; analysisStatistical.setNonNegativeProp(nnProp).

[0150] (5) Calculation of citation index The Citation Index quantifies a brand's citation influence across various media platforms. It integrates prior media quantity statistics, distinguishing the weight differences between owned media and mainstream media. The technical details are as follows: Extracting the number of owned media (obtained via the `getMediaCount()` method, media type = 1 and associated with the target brand's citation count) and the number of mainstream (core) media (obtained via the `getMainMediaCount()` method, media type = 2 and associated with the target brand's citation count); setting weight differences (mainstream media has a higher weight than owned media, default weight 0.6 for mainstream media and 0.4 for owned media), calculating the weighted media total: Weighted Media Total = Own Media Quantity × 0.4 + Mainstream Media Quantity × 0.6; using the total number of brand-related citations as the base, the calculation formula is: Citation Index = (Weighted Media Total ÷ Total Citations) × 100 × Preset Weight (default percentage 20%); if the total number of citations is 0, the Citation Index is assigned 0, and the result is rounded to two decimal places, accurately reflecting the brand's communication influence across different media levels. The corresponding Java code is as follows: double omProp = divide(ownMediaProp, totalCount, 3,RoundingMode.HALF_UP) * 100; double mmProp = divide(mainMediaProp, totalCount, 3,RoundingMode.HALF_UP) * 100; analysisStatistical.setOwnMediaProp(omProp); analysisStatistical.setMainMediaProp(mmProp).

[0151] (6) Generation of optimization suggestions The optimization recommendations are generated based on the calculation results of five evaluation indices, combined with details from previous brand identification, sentiment analysis, and media attribution assessments. The technical details are as follows: First, threshold judgments are performed on the five index results (preset passing thresholds for each index, such as 60 points) to identify brand performance weaknesses (e.g., low visibility index indicates insufficient exposure, low sentiment index is associated with more negative descriptions, low citation index indicates insufficient mainstream media coverage). Second, by linking these weaknesses to previous technical details (e.g., low sentiment index is associated with specific types of negative descriptions, low ranking index is associated with ranking position distribution), the causes of these weaknesses are clarified. Finally, tiered optimization recommendations are generated: for weaknesses in visibility / ranking index, it is recommended to increase brand exposure and optimize ranking strategies; for weaknesses in sentiment index, it is recommended to specifically improve negative word-of-mouth and strengthen positive publicity; for weaknesses in citation index, it is recommended to increase cooperation with mainstream media and enrich content on proprietary media. All recommendations specify actionable steps and are linked to the evaluation index optimization goals. These are then integrated and simultaneously output to the evaluation conclusion, providing precise guidance for brand optimization and supporting the final evaluation report output. The corresponding Java code is as follows: JSONObject jsonParam = new JSONObject(); for (GeoTaskAnalysisStatistical stat : statisticalList) { JSONObject modelJson = new JSONObject(); modelJson.put("Visibility Index", stat.getVisibilityProp()); modelJson.put("Rank Index", stat.getAverageRank()); modelJson.put("First Prop Index", stat.getFirstProp()); modelJson.put("sentiment index", stat.getNonNegativeProp()); modelJson.put("Reference Index", stat.getOwnMediaProp() + stat.getMainMediaProp()); if (stat.getModelCode() == 0) { jsonParam.put("Total score of all models", modelJson); } else { jsonParam.put(AiModelTypeEnum.getName(stat.getModelCode()) + "Model Rating", modelJson); } } String userPrompt = PromptConstant.EXTRACT_USER_GEO_SUGGESTION .replace("Enter assessment dimensions", jsonParam.toJSONString()) .replace("Enter brand or product", geoTask.getOwnName()); ChatReqVo chatReqVo = new ChatReqVo( geoTask.getAccountId(), geoTask.getId(), PromptConstant.EXTRACT_SYSNTEM_GEO_SUGGESTION, userPrompt, 0.8f, true, false ); ChatResSimpleVo result = aiChatService.chatWithWebSearchByType(chatReqVo, AiModelTypeEnum.DOU_BAO); JSONArray suggestions = JSON.parseArray(result.getResult()); for (int i = 0; i < suggestions.size(); i++) { GeoTaskOptimization optimization = new GeoTaskOptimization(); optimization.setSuggestion(suggestions.getString(i)); geoTaskDao.insertGeoTaskOptimization(optimization); } The above solution will be illustrated below through a specific embodiment and in conjunction with a specific application scenario.

[0152] 1. Application Scenarios and Basic Data Settings Application scenario: A new energy vehicle company conducts online brand exposure and reputation evaluation, and entrusts the system to conduct a comprehensive evaluation of "its own brand (Brand A) + 4 competing brands (Brands B, C, D, and E)".

[0153] The preceding sentiment analysis and media attribution determination steps have output the following core foundational data (connecting with the preceding steps and providing a basis for index calculation): (1) Total number of brands bound: 5 (A, B, C, D, E).

[0154] (2) Brand visibility and ranking data (bindVisible=1 visible, 0 invisible; rankNum=1 first place, -1 no ranking): A (visible=1, rankNum=1), B (visible=1, rankNum=2), C (visible=1, rankNum=3), D (visible=1, rankNum=-1), E (visible=0, tendency=2).

[0155] (3) Sentiment and confidence level (tendency = -1 negative, 0 neutral, 1 positive): A (1, 0.9), B (0, 0.8), C (-1, 0.7), D (1, 0.85), E (2, no confidence level).

[0156] (4) Media citation data (getMediaCount() own media = 3 times; getMainMediaCount() mainstream media = 2 times; total number of brand-related citations = 10 times).

[0157] (5) Preset parameters: the weight of each of the five indices is 20%; the passing threshold is 60 points; the weight of mainstream media is 0.6 and the weight of self-owned media is 0.4.

[0158] Based on the above data, the specific implementation process of each step will be explained in detail below.

[0159] (1) Visible index calculation Core objective: To quantify the overall exposure and visibility of 5 linked brands, with the calculation process strictly linked to the results of preceding visibility assessments. Data filtering: Brands with a sentiment index of 2 (not applicable) are excluded (only brand E, bindVisible=0). The remaining visible brands are A, B, C, and D, with a total of 4 visible brands. Substituting into the formula: Visibility Index = (Number of visible brands ÷ Total number of bound brands) × 100 × Preset weight = (4 ÷ 5) × 100 × 20% = 80 × 0.2 = 16.00; Result: Visibility Index = 16.00 (rounded to 2 decimal places), indicating that 80% of the 5 bound brands achieved exposure visibility, and the overall visibility level is good.

[0160] (2) Calculation of the first index Core objective: To quantify the advantage of a brand gaining top-tier exposure and focus on the visible ranking position of the brand. Data filtering: The calculation scope is visible brands (A, B, C, D, a total of 4), extract the rankNum attribute, and count the number of first-rank brands (only brand A has rankNum=1, and the number of first-rank brands is 1). Substituting into the formula: First-place index = (Number of first-place brands ÷ Number of visible brands) × 100 × Preset weight = (1 ÷ 4) × 100 × 20% = 25 × 0.2 = 5.00; Result: First place index = 5.00, indicating that only 25% of brands received first place exposure. Although brand A occupies the first place, its overall competitiveness in the first place is relatively weak.

[0161] (3) Ranking index calculation Core objective: To quantify the overall ranking competitiveness of visible brands, integrating "whether there is a ranking" with "ranking order": Data filtering and reverse quantization: The calculation scope is the visible brands (4), the actual highest ranking is 3 (brand C), and reverse quantization is performed according to the rules: A (rankNum=1): Quantized value = 1; B (rankNum=2): Quantized value = 0.9; C (rankNum=3): Quantized value = 0.8; D (rankNum=-1, no ranking): Quantized value = 0; Calculate the total quantified value: 1 + 0.9 + 0.8 + 0 = 2.7; Substituting into the formula: Ranking Index = (Total Quantitative Values ​​÷ Number of Visible Brands) × 100 × Preset Weight = (2.7 ÷ 4) × 100 × 20% = 67.5 × 0.2 = 13.50; Result: Ranking index = 13.50. It can be seen that only 3 brands have a clear ranking, the overall ranking competitiveness is medium, and brand D has no ranking, which lowers the overall level.

[0162] (4) Calculation of Emotion Index Core objective: To quantify the emotional reputation of visible brands, incorporate confidence levels to optimize accuracy, and correlate with prior sentiment analysis results. Data filtering: The calculation scope includes visible brands (A, B, C, D, tendency ≠ 2), extracting the sentiment tendency and confidence level of each brand, and calculating the weighted value: A (tendency=1, confidence level 0.9): 0.9 × 1 = 0.9; B (tendency=0, confidence level 0.8): 0.8 × 0 = 0; C (tendency = -1, confidence level 0.7): 0.7 × (-1) = -0.7; D (tendency = 1, confidence level 0.85): 0.85 × 1 = 0.85; Calculate the weighted sum: 0.9 + 0 - 0.7 + 0.85 = 1.05; Substituting into the formula: Emotional Index = (Sum of weighted values ​​÷ Number of visible brands) × 100 × Preset weight = (1.05 ÷ 4) × 100 × 20% = 26.25 × 0.2 = 5.25; Results: Emotional Index = 5.25, indicating the presence of negative emotions in the brand (Brand C), a bias in overall emotional reputation, and insufficient utilization of the weight of positive emotions.

[0163] (5) Calculation of citation index Core objective: To quantify a brand's influence in media citations, differentiate between owned and mainstream media weight, and correlate the statistical results of preceding media coverage. Extracting media data: Number of owned media = 3 times (getMediaCount()), Number of mainstream media = 2 times (getMainMediaCount()); Calculate the weighted total media volume: 3 × 0.4 + 2 × 0.6 = 1.2 + 1.2 = 2.4; Substituting into the formula: Citation Index = (Total Weighted Media ÷ Total Number of Citations) × 100 × Preset Weight = (2.4 ÷ 10) × 100 × 20% = 24 × 0.2 = 4.80; Results: Citation index = 4.80. Among the total number of brand-related citations, weighted media accounted for only 24%, indicating that the citation influence of mainstream media and self-owned media was relatively weak.

[0164] (6) Generation of optimization suggestions Core objective: Based on five index results (visibility 16.00, first place 5.00, ranking 13.50, sentiment 5.25, citations 4.80), combined with the passing threshold of 60 points (each index has a maximum score of 20 points, corresponding to the overall passing line), this study identifies weaknesses, analyzes their causes, and generates actionable recommendations. Weaknesses identified: All five indices are below the passing mark (the passing mark for a single index is 12 points, and only the visible index meets the standard). The core weaknesses are the first-place index, the sentiment index, and the citation index, while the secondary weakness is the ranking index. Cause analysis (related to preceding technical details): Low First-Rank Index: It can be seen that only brand A is ranked first among brands, while competitors B and C rank higher, indicating low exposure coverage for the first-rank brand. Low sentiment index: Brand C has clear negative sentiment (confidence level 0.7, negative descriptions are related to product battery life issues), which lowers the overall reputation; Low citation index: mainstream media cited it only 2 times, and its own media cited it 3 times, indicating insufficient media coverage and weak weighted influence; Low ranking index: Brand D has no ranking, and brands B and C rank better than brand A (except for the first place), indicating insufficient ranking competitiveness.

[0165] Targeted optimization suggestions (implementable, related to index optimization goals): Regarding the first-place / ranking index: Optimize online search ranking strategy, increase investment in first-place exposure for Brand A, and promote Brand D to improve its ranking layout, with the goal of raising the first-place index to 12 points and the ranking index to 15 points; Regarding the sentiment index: In response to negative descriptions of Brand C (battery life issues), issue a statement on battery life optimization, strengthen positive publicity (such as user test battery life cases), reduce the impact of negative emotions, and aim to raise the sentiment index to 12 points; Regarding the citation index: Increase cooperation with mainstream media (such as core automotive media), enrich the content of our own media (such as official website and WeChat official account evaluation content), and increase the number of media citations, with the goal of raising the citation index to 12 points; Regarding the visibility index: Maintain the existing exposure level and promote the E brand to improve visibility (bindVisible from 0 to 1), further consolidating the visibility index advantage.

[0166] Output Integration: The optimization suggestions are integrated with the results of the five indices and output synchronously to the subsequent evaluation conclusion summary stage, supporting the generation of the final new energy vehicle brand evaluation report and providing precise guidance for enterprise brand optimization.

[0167] In summary, the above embodiments take the online exposure and reputation evaluation of new energy vehicle enterprise brands as a specific scenario, and five bound brands as evaluation objects. Based on the basic data output from the preceding sentiment analysis and media affiliation judgment steps, the standardized calculation of five indices—visibility, first place, ranking, sentiment, and citation—is completed sequentially according to preset parameters. Combining the index results with the qualified thresholds, shortcomings are identified and their causes are analyzed, generating targeted and implementable optimization suggestions. The entire embodiment clearly connects the preceding and subsequent steps, completely replicating the entire process of evaluation index calculation and optimization suggestion generation, verifying the practicality and accuracy of the solution, and can be adapted to various brand evaluation scenarios by adjusting preset parameters.

[0168] According to embodiments of the present invention, a storage device is also provided. The storage device may include a processor and a memory, wherein the memory stores a computer program. When the computer program is executed by the processor, it can implement the methods provided in any of the above embodiments, and its execution method and beneficial effects are similar, and will not be described again here. In addition, depending on the specific application, the storage device may also include any other suitable components.

[0169] It should be understood that although the steps in the flowcharts of the accompanying drawings are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying drawings may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. The same / similar parts between the various embodiments of the methods described above in this specification can be referred to each other. Each embodiment focuses on describing the differences from other embodiments, and relevant parts can be referred to the descriptions of other method embodiments.

[0170] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0171] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A multi-feature recognition and evaluation method based on a large model, characterized in that, The method includes: Receive the GEO assessment task configuration information input by the user through the web front-end interface, construct the GeoTask data object and assign configuration parameters, call the data access layer interface to store the configuration information in the database, and generate and return a unique GEO assessment task identifier. The evaluation task is triggered on a timed basis through a distributed task scheduling framework, the execution of multi-node tasks is controlled by a distributed lock mechanism, and multi-node coordination and failure task compensation are achieved through task status management. The large model client is managed and a unified calling interface is set up through the factory pattern. A retry mechanism and exception handling configuration are set for each large model. Multiple large models are called through the unified calling interface and the response results of each large model are aggregated. The system constructs brand extraction prompts, encapsulates structured analysis parameters, calls AI tool interfaces and inputs the prompts and structured analysis parameters to obtain structured analysis results containing each identified brand; it extracts brand-related information from the structured analysis results and performs quantitative transformation, and generates default value records for unidentified bound brands; Conduct in-depth verification and detailed analysis of brand sentiment, improve sentiment-related characteristics; determine the media source attribution of brand-related content, and complete media classification identification; output standardized data containing detailed sentiment information and media attribution classification. Calculate and integrate the results of various indices to pinpoint brand performance weaknesses and generate optimization suggestions.

2. The method according to claim 1, characterized in that, The GEO assessment task configuration information includes basic task information, large model configuration information, assessment cycle configuration information, prompt word configuration information, and competitor binding information.

3. The method according to claim 1, characterized in that, The XXL-JOB distributed task scheduling framework is adopted to build a timed triggering mechanism for evaluation tasks, which is suitable for multi-node cluster deployment scenarios.

4. The method according to claim 1, characterized in that, The Redis distributed lock mechanism is used to ensure unique control over task execution.

5. The method according to claim 1, characterized in that, The factory pattern is used to manage large model clients and set up a unified API, specifically including: First, define an abstract client class AiWebSearchAbstractClient, which encapsulates the common calling methods and core properties of all large model clients; Create the AiWebSearchFactory class; when the factory class is initialized, it receives an array of all concrete clients, iterates through the array and registers each client to CLIENT_MAP according to its AiModelTypeEnum type, thus completing the centralized storage of clients; The factory class exposes the getClient(AiModelTypeEnummodelType) method as a unified calling interface, through which the caller obtains the client. When adding a large model client, it is only necessary to implement the AiWebSearchAbstractClient abstract class, define the corresponding AiModelTypeEnum enumeration value, and add the new client to the registration array during factory initialization.

6. The method according to claim 1, characterized in that, The process of constructing brand extraction prompts includes: based on the needs of brand recognition and ranking analysis, solidifying pre-set brand extraction prompts; the prompts clearly instruct the AI ​​to identify the self-owned brand and competitor brands from the specified text, and return standardized JSON format results containing visibility, ranking, and sentiment dimensions, ensuring that the AI ​​output meets the requirements of subsequent parsing.

7. The method according to claim 6, characterized in that, Encapsulate structured analysis parameters, specifically by creating a JSONObject structured parameter object and filling it with three types of parameters according to the interface specifications: input text, custom name, and competitor list. This ensures that the parameters cover all the information required for AI analysis and that the format is compatible with the AI ​​tool interface requirements.

8. The method according to claim 1, characterized in that, Create an independent data record for each unidentified bound brand, fill in all feature fields with preset default values, and add it to the brand analysis result set after associating it with the task ID. Finally, verify that the total number of the result set is consistent with the total number of bound brands.

9. The method according to claim 1, characterized in that, Throughout the entire process of data transmission, storage, and processing, a multi-layered data security and privacy protection mechanism has been constructed, including data transmission security assurance, sensitive data anonymization and storage, AI model data call isolation, evaluation result access control, and data lifecycle management.

10. The method according to claim 1, characterized in that, The construction of anomaly handling and fault tolerance mechanisms includes degradation handling for abnormal AI model return result formats, conflict resolution strategies when aggregating results from multiple models, handling procedures for distributed lock acquisition timeouts, caching fallback solutions for database connection anomalies, and end-to-end anomaly monitoring and alarms for task execution.

Images