Intelligent processing and visualization method for heterogeneous task data of multiple research groups

Abstract

The invention provides an intelligent processing and visualization method for heterogeneous task data of multiple research groups. The method comprises the following steps: firstly, constructing a plug-in rule storage module containing field mapping and task splitting rules; receiving a natural language query request of a user and the research group range information, and analyzing and determining a query demand; aligning the heterogeneous data based on a field mapping rule to obtain standardized data, and splitting a task name according to a task splitting rule to obtain a structured field; generating and executing an SQL (Structured Query Language) to obtain target data, and selecting an output format for adaptation according to the data And finally, the visual template is matched to generate the chart and the natural language abstract to be output, newly added research groups can be supported only by supplementing rules and dynamically loading the system, the maintenance cost can be reduced, and the data query and analysis efficiency can be improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to an intelligent processing and visualization method for heterogeneous task data from multiple research groups. Background Technology

[0002] In scenarios where multiple research groups collaborate on scientific research or projects (such as research groups in artificial intelligence, advanced materials, and solid-state batteries sharing a task management system), existing task data management generally adopts the traditional model of "static reports + manual SQL". Due to differences in research directions and data recording habits among research groups, task data exhibits significant heterogeneity: field names, data granularity, and formats are inconsistent (for example, the "task completion time" field is recorded as "finish_dt" in some research groups and "complete_time" in others). This requires manual alignment of data using ETL tools, which is not only time-consuming and labor-intensive but also prone to errors due to human operation. At the same time, business personnel need to master SQL or professional BI tools to query data and generate charts, making it difficult for ordinary users to quickly obtain analysis results through conversational requests, resulting in a high query threshold.

[0003] Furthermore, the existing system's chart display relies on fixed templates, making it impossible to adjust the visualization format according to users' dynamic query needs (e.g., a line chart is needed for users asking "the task completion trend of each research group in the past 3 months," and a pie chart is needed for users asking "the percentage of incomplete tasks in each research group," requiring manual template reconfiguration). This makes it difficult to meet the data analysis needs of "changing as asked." Moreover, when adding a research group, the core system code needs to be modified to adapt to its data format, resulting in a long expansion cycle and high maintenance costs. This leads to low overall task data management efficiency and makes it impossible to support rapid collaboration among multiple research groups and data-driven decision-making. Summary of the Invention

[0004] In view of this, embodiments of this application provide an intelligent processing and visualization method for heterogeneous task data from multiple research groups, which can **.

[0005] The technical solution of this application embodiment is implemented as follows: In a first aspect, embodiments of this application provide an intelligent processing and visualization method for heterogeneous task data from multiple research groups, comprising the following steps: An external rule storage module is constructed, which includes field mapping rules and task splitting rules corresponding to each research group; Receive a natural language query request input by the user and associated research group scope information, analyze the query intent in combination with the research group scope information, and determine the query requirements; Based on the field mapping rules, the heterogeneous task data of the corresponding research group is aligned to obtain standardized task data. Based on the task splitting rules, the task names of the standardized task data are structurally split to obtain structured task fields; Based on the query requirements and the field information of the standardized task data, generate and execute an SQL query statement to obtain the target task data; Select the appropriate data output format based on the data volume of the target task, and perform adaptation processing on the target task data; Based on feature matching visualization templates of target task data, visualization charts and natural language summaries are generated, and query results are output to users. When a new research group is added, the corresponding rules are only added to the rule storage module so that the system can dynamically load the new rules to support the data processing of the research group.

[0006] Secondly, embodiments of this application also provide an intelligent processing and visualization device for heterogeneous task data from multiple research groups, the device comprising: A building module is used to build an external rule storage module, which includes field mapping rules and task splitting rules corresponding to each research group. The determination module is used to receive the user's natural language query request and associated research group scope information, and to analyze the query intent in combination with the research group scope information to determine the query requirements. The alignment module is used to perform field alignment processing on the heterogeneous task data of the corresponding research group based on the field mapping rules to obtain standardized task data. The splitting module is used to perform structured splitting of the task names in the standardized task data based on the task splitting rules to obtain structured task fields. The acquisition module is used to generate and execute SQL query statements based on query requirements and field information of standardized task data to obtain target task data; The adaptation module is used to select the corresponding data output format based on the data volume of the target task data and to adapt the target task data. The output module is used to match the feature of the target task data with the visualization template, generate visualization charts and natural language summaries, and output the query results to the user. When a new research group is added, the corresponding rules are added only in the rule storage module so that the system can dynamically load the new rules to support the data processing of the research group.

[0007] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the intelligent processing and visualization method for heterogeneous task data from multiple research groups as described in any of the first aspects.

[0008] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, performs the intelligent processing and visualization method for heterogeneous task data from multiple research groups as described in any one of the first aspects.

[0009] The embodiments of this application have the following beneficial effects: By constructing an external rule storage module, a unified mapping of heterogeneous fields across research groups and structured splitting of task names are achieved. This eliminates the need to develop independent data processing logic for different research groups, significantly reducing system maintenance costs. Furthermore, adding new research groups only requires supplementing rules for dynamic adaptation, significantly improving system scalability. Simultaneously, by combining research group scope information with natural language query intent parsing, query compliance is ensured while allowing non-technical personnel to initiate queries without SQL expertise, lowering the data acquisition threshold. Through automatic SQL generation, data volume-adaptive output, and the linked generation of visualization charts and natural language summaries, the entire process of "query-processing-display-interpretation" is automated. This not only overcomes platform character limitations to adapt to different data volume scenarios but also helps users quickly understand the value of data. Ultimately, it efficiently solves the core pain points of existing technologies, such as heterogeneous fields, high query thresholds, rigid displays, and difficulty in expansion, providing an integrated, low-cost, and highly usable solution for collaborative data analysis tasks across multiple research groups. Attached Figure Description

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

[0011] Figure 1 This is a flowchart illustrating steps S101-S107 provided in the embodiments of this application; Figure 2 This is a flowchart illustrating steps S201-S203 provided in the embodiments of this application; Figure 3 This is a flowchart illustrating steps S301-S302 provided in the embodiments of this application; Figure 4 This is a flowchart illustrating steps S401-S403 provided in the embodiments of this application; Figure 5 This is a flowchart illustrating steps S501-S504 provided in the embodiments of this application; Figure 6 This is a flowchart illustrating steps S601-S604 provided in the embodiments of this application; Figure 7 This is a flowchart illustrating steps S701-S704 provided in the embodiments of this application; Figure 8 This is a schematic diagram of the structure of the intelligent processing and visualization device for heterogeneous task data from multiple research groups provided in the embodiments of this application; Figure 9 This is a schematic diagram of the composition structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0013] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0014] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0015] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0016] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0017] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application and is not intended to limit this application.

[0018] See Figure 1 , Figure 1 This is a flowchart illustrating steps S101-S107 of the intelligent processing and visualization method for heterogeneous task data from multiple research groups provided in this application embodiment. It will be combined with... Figure 1 Steps S101-S107 are explained below.

[0019] In step S101, an external rule storage module is constructed, which includes field mapping rules and task splitting rules corresponding to each research group. In existing technologies, task data from different research groups (such as artificial intelligence, advanced materials, and solid-state batteries) exhibit differences in field names, granularity, and format (for example, the "task completion time" field is denoted as "finish_dt" by the artificial intelligence group and "complete_time" by the solid-state battery group). Developing separate data processing rules for each research group would result in high system maintenance costs and poor scalability. Therefore, this step employs an "external" design to decouple the rules from the core system logic, laying the foundation for rapid expansion to new research groups in the future.

[0020] Field mapping rules are used to define the correspondence between the "original fields" and "preset standard fields" of each research group. For example, the Artificial Intelligence research group is configured with "finish_dt → standard field_task completion time" and "task_type → standard field_task type", while the Solid State Battery research group is configured with "complete_time → standard field_task completion time" and "task_category → standard field_task type", ensuring that the heterogeneous fields of different research groups can be unified to the same standard dimension.

[0021] The task splitting rules address the issue of inconsistent task names across different research groups (e.g., the task name for the Artificial Intelligence research group is "Model Training - Image Recognition - Accuracy Optimization", and the task name for the Basic Software research group is "Code Development - Interface Debugging"). The rules define splitting logic (e.g., splitting by the separator "-") to ensure that structured task hierarchy fields (level 1, level 2, and level 3 tasks) can be generated subsequently to meet the needs of chart aggregation analysis.

[0022] In step S102, the system receives a natural language query request input by the user and associated research group scope information, analyzes the query intent in conjunction with the research group scope information, and determines the query requirements. Here, users (such as researchers in research groups and project managers) do not need to switch to a separate system. They can initiate queries in the existing task management platform (such as task dashboard) and enter natural language questions (such as "show the task completion rate of the Vehicle-Road-Cloud-Star research group in the past 3 months" or "statistically analyze the distribution of uncompleted tasks in the Foresight Materials research group"). At the same time, the system automatically associates the "research group scope information" corresponding to the user's identity (if the user belongs to the solid-state battery research group, the default query scope is the data of that group), avoiding unauthorized queries.

[0023] The core of intent parsing is to transform "conversational questions" into "structured query requirements." For example, if a user inputs "task completion status of various research groups in national key laboratories in the past 3 months," the system needs to parse out: data dimensions (time dimension: the past 3 months, subject dimension: each research group, indicator dimension: task completion status); filtering conditions (time range: the past 3 months, subject range: research groups under national key laboratories); and visualization requirements (the need to compare data from various research groups, implicitly requiring chart types such as "bar charts / line charts"), providing a clear basis for subsequent SQL generation.

[0024] In step S103, the heterogeneous task data of the corresponding research group is aligned based on the field mapping rules to obtain standardized task data. Here, based on the research group's field mapping rules, the original heterogeneous data is "cleaned and aligned": If the original data of the research group contains fields that are not defined in the standard fields (such as the "model version number" of the artificial intelligence research group, which is not universal to all research groups), they will be discarded directly to avoid redundant data affecting subsequent processing; If there are fields in the standard fields that are not included in the original data of the research group (such as the solid-state battery research group not recording "task priority"), then empty values ​​(such as "NULL" or "unmarked") will be automatically filled to ensure that the processed data structure of all research groups is consistent.

[0025] This step allows heterogeneous data from multiple research groups to be uniformly converted into a "standard field table" (containing standard fields such as "task ID, task name, task type, task completion time, task completion status, and research group to which it belongs"), eliminating the need to develop separate cleaning logic for each group and significantly reducing operation and maintenance costs.

[0026] In step S104, the task names of the standardized task data are structurally split based on the task splitting rules to obtain structured task fields; Here, the task names of different research groups vary greatly in hierarchy (e.g., the task name "Roadside Equipment Deployment - Regional Testing - Data Feedback" of the Vehicle-Road-Cloud-Star research group is a three-level structure, while the task name "Operating System Adaptation" of the Basic Software research group is a first-level structure). Without structuring, it is impossible to achieve the chart requirement of "aggregating by task level" (e.g., "statistics on the completion rate of each first-level task"). Therefore, this step processes the task names based on task splitting rules (e.g., splitting by "-", with a maximum of three levels): The three-level task name structure (e.g., "Model Training - Image Recognition - Accuracy Optimization") is broken down into "Level 1 Task: Model Training, Level 2 Task: Image Recognition, Level 3 Task: Accuracy Optimization"; Second-level task names (e.g., "Code Development - Interface Debugging") are broken down into "First-level task: Code Development, Second-level task: Interface Debugging, Third-level task: Empty string"; The first-level task name (e.g., "operating system adaptation") is broken down into "first-level task: operating system adaptation, second-level task: empty string, third-level task: empty string".

[0027] The split "Level 1-Level 2-Level 3 Tasks" fields can be directly used for subsequent visualization aggregation (such as generating "bar charts of the number of Level 1 tasks completed" and "line charts of the completion rate of Level 2 tasks under a certain Level 1 task"), meeting users' needs for charts that can be changed "as needed".

[0028] In step S105, an SQL query statement is generated and executed based on the query requirements and the field information of the standardized task data to obtain the target task data; In existing technologies, business personnel need to manually write SQL queries to retrieve data, which is a high barrier to entry. This step drives the automatic generation of SQL based on "query requirements + standard field information".

[0029] The input parameters are the parsed query requirements (e.g., "task completion rate of the Cheluyunxing research group in the past 3 months") and defined standard fields (e.g., "research group, task completion time, task completion status"). A large language model (e.g., Qwen-Max) is invoked, combined with a standard field dictionary (to avoid model "illusion" generating non-existent fields), to transform the query requirements into standardized SQL (e.g., "SELECT Task Completion Status, COUNT (Task ID) AS Task Quantity FROM Standard Field Table WHERE Research Group = 'Cheluyunxing Research Group' AND Task Completion Time BETWEEN DATE_SUB (CURDATE (),INTERVAL 3 MONTH) AND CURDATE () GROUP BY Task Completion Status"). The system connects to the data lake through a pre-set project account (requiring prior application for data authorization from the data analysis center and group digital authorization), executes the SQL statement, and obtains the raw target data (e.g., "Completed: 28 records, Incomplete: 12 records").

[0030] In step S106, the corresponding data output format is selected according to the data volume of the target task data, and the target task data is adapted. Existing platforms (such as Dify) have character length limits (e.g., 80,000 characters). If the target data volume is too large (e.g., "Export all task details of the solid-state battery research group in the past year, a total of 100,000 rows of data"), directly outputting in string format will exceed the limit, resulting in data transmission failure. If the data volume is small (e.g., "Statistics on task completion rate in the past month, a total of 2 rows of data"), outputting in file format will increase the complexity of user operations (requiring downloading and opening the file). Therefore, this step achieves adaptation through "Data Volume Assessment - Format Selection".

[0031] Here, the system calculates the character length of the target data (e.g., approximately 50 characters per data entry, approximately 5 million characters for 100,000 rows) or the number of data rows (e.g., 100,000 rows). If the data exceeds a preset threshold (e.g., character length > 80,000 or number of rows > 1,000), it is converted into a temporary CSV file (for easy download and analysis with Excel). If the data does not exceed the threshold, it is converted into a JSON string (e.g., "[{"Task Completion Status":"Completed","Task Quantity":28},{"Task Completion Status":"Not Completed","Task Quantity":12}]"), which can be directly displayed on the front end. The system outputs a "format identifier" (e.g., "file_type=csv" or "file_type=json") to downstream processing nodes (e.g., visualization module, summary generation module). The downstream nodes automatically select the parsing method (reading the CSV file or parsing the JSON string) based on the identifier, achieving seamless processing.

[0032] In step S107, based on the feature matching visualization template of the target task data, a visualization chart and natural language summary are generated, and the query results are output to the user; wherein, when a new research group is added, only the corresponding rules are added in the rule storage module so that the system can dynamically load the new rules to support the data processing of the research group.

[0033] Here, templates are automatically matched based on the characteristics (dimension, type, distribution) of the target data: If the data is "time series data" (such as "the number of tasks completed by each research group in the past 3 months"), match the line chart template (to facilitate the display of trend changes); If the data is "categorical comparison data" (such as "percentage of tasks not completed by each research group"), match the pie chart / bar chart template (to facilitate the display of percentage / quantity comparison); If the data is "detailed data" (such as "list of unfinished tasks"), match the table template (to facilitate the display of specific information).

[0034] To help users quickly understand the meaning behind the data (avoiding the inability to identify trends / anomalies by simply looking at charts), a large language model is invoked to interpret the target data: For the data on "task completion rate of the Vehicle-Road-Cloud-Star research group in the past 3 months" (e.g., 80% in January, 75% in February, and 90% in March), the following summary is generated: "The task completion rate of the Vehicle-Road-Cloud-Star research group in the past 3 months has shown a fluctuating upward trend. The completion rate in January and February decreased slightly (from 80% to 75%), while the completion rate in March increased significantly to 90%, which is presumably related to the additional resource input in March." For the data on "distribution of unfinished tasks among research groups" (e.g., the unfinished rate of the Foresight Materials research group is 40%, while the unfinished rate of other groups is <20%), the following summary is generated: "The unfinished rate of the Foresight Materials research group (40%) is significantly higher than that of other research groups (all <20%), and the bottleneck in the progress of tasks in this group needs to be focused on."

[0035] Finally, the system integrates "visual charts + natural language summaries" and displays them interactively on the front end. Users can click on the charts to view data details (e.g., clicking on a bar in a bar chart displays a list of specific tasks for that research group), and can download charts or data files (CSV / JSON). The entire process of "query-understand-export" can be completed without any additional operations.

[0036] If a new "Intelligent Cockpit Research Group" is added, only the "field mapping rules" (such as "task_end_time → standard field_task completion time") and "task splitting rules" (such as splitting by "-" up to three levels) of the group need to be added to the external rule storage module. No modification to the core system code is required. The system will periodically scan the rule storage module during runtime, identify the new rules and load them automatically (without restarting the system). The adaptation of the new research group can usually be completed within 10 minutes, which greatly improves the system's scalability.

[0037] In some embodiments, see Figure 2 , Figure 2 This is a flowchart illustrating steps S201-S203 provided in the embodiments of this application. The construction of the plug-in rule storage module can be achieved through steps S201-S203, which will be explained in conjunction with each step.

[0038] In step S201, the rule storage module is set to an editable file format, making it independent of the system's core processing logic; In step S202, the field mapping rules define a one-to-one correspondence between the original fields of each research group and the preset standard fields; In step S203, the task splitting rules define the splitting logic of task names according to preset delimiters and the number constraints of the number of field segments after splitting.

[0039] To ensure that non-technical personnel (such as the research group's data administrator) can also modify the rules (without writing code), a universal and easily editable file format (such as JSON) is chosen for the following reasons: JSON format is highly readable, has a clear structure, and is easy to modify manually (e.g., it can be edited with Notepad or Notepad++). JSON format is highly compatible with existing systems (such as backend Java / Python services and frontend JavaScript), requiring no additional format conversion tools; The JSON format supports nested structures, allowing for flexible definition of the hierarchical relationship between "research group" and "rule" (e.g., "{"Intelligent Cockpit Research Group":{"Field Mapping Rule":{"task_end_time":"Task Completion Time"},"Task Splitting Rule":{"Separator":"-","Maximum Splitting Levels":3}}}").

[0040] The rule storage module is set as an independent file (e.g., named "group_rule.json") and stored in a specified system directory (e.g., " / data / rules / "). The core system processing logic (e.g., field alignment module, task splitting module) retrieves rules by reading this file, instead of hardcoding the rules into the code. In this way, when modifying rules, only the JSON file needs to be edited, without recompiling and re-deploying the system, reducing maintenance costs. Version management of the rule file can be performed (e.g., using Git to record each modification), which makes it easy to trace historical versions and roll back erroneous modifications.

[0041] To avoid ambiguity in field mapping (such as the same original field corresponding to multiple standard fields, or the same standard field corresponding to multiple original fields), a "one-to-one correspondence" definition method is adopted, specifically including: Field Identifiers: Clearly define the "physical name" (e.g., "task_end_time" in a database table) and "meaning description" (e.g., "timestamp of actual task completion") of the original field to avoid mapping errors caused by similar field names (e.g., distinguish between "task_end_time" and "task_plan_end_time"). Data type adaptation: If the data types of the original field and the standard field are inconsistent (e.g., the original field "task_completion" is the string "complete / not completed", and the standard field "task completion status" is the integer "1 / 0"), add type conversion logic to the mapping rules (e.g., "task_completion='complete'→1, task_completion='not completed'→0") to ensure that the data types are consistent after alignment; Default value setting: If the original field contains null values ​​(such as some tasks not recording "task leader"), define a default fill value (such as "not specified") in the mapping rules to avoid statistical errors caused by null values ​​in subsequent SQL queries.

[0042] Based on the actual format of each research group's task names, select the most commonly used separators (such as "-", "_", " / "), and specify them in the rules: If the task name of the research group does not have a fixed separator (such as "Smart Cockpit UI Design 2024"), then define the "no separator" rule, and after splitting, only the first-level task field is retained (such as "first-level task: Smart Cockpit UI Design 2024, second-level / third-level task: empty string"); if the task name of the research group has multiple separators (such as "model development_algorithm optimization-performance testing"), then define the "priority separator" (such as splitting by "-" first, then by "_") to ensure that the splitting logic is consistent.

[0043] Based on actual business needs (task levels typically do not exceed three), the "maximum number of splitting levels" is defined as 3 levels for the following reasons: If there are too many levels of splitting (such as 5 levels), it will lead to field redundancy and overly complex chart aggregation dimensions (such as "five-level task completion rate" having no actual business meaning). If the number of levels is too small (e.g., level 1), it cannot meet the requirement of "analysis by task sub-level" (e.g., the completion status of the second-level task under "Level 1 Task: Model Development").

[0044] In some embodiments, see Figure 3 , Figure 3 This is a flowchart illustrating steps S301-S302 provided in the embodiments of this application. Receiving the user's input natural language query request and the associated research group scope information can be achieved through steps S301-S302, which will be explained in conjunction with each step.

[0045] In step S301, a floating interactive entry component is set on the task dashboard interface of the existing task management system.

[0046] In step S302, a natural language query request is received from the user after clicking the interactive entry component and being redirected to the question and answer interface.

[0047] In step S303, a communication connection is established between the interactive entry component and the backend processing service through the API gateway to synchronize the research group scope information associated with the user.

[0048] In existing technologies, users need to switch to a separate data analysis system (such as a BI tool) to initiate queries, which is cumbersome and requires re-login (as permissions are not shared). This step sets the interactive entry component to a "floating" design, embedding it into the task dashboard interface of the existing task management system. The floating button is usually fixed in the lower right corner of the interface (or other position that does not obscure the core content), allowing users to find it without scrolling the page, making operation convenient. The button is designed with an "AI assistant" icon (such as a robot icon) + text label ("AI Data Query"), clearly defining its function and reducing the user's cognitive cost. The component is bound to the user permissions of the existing system (e.g., only the research group administrator can view the data of the entire group, while ordinary members can only view their personal data), eliminating the need for users to log in or apply for additional permissions.

[0049] This application's embodiments use front-end development technologies (such as HTML, CSS, and JavaScript) to implement the floating button: The button defaults to "collapsed" (showing only the icon) and "expanded" (showing both icon and text) when the mouse hovers over it, avoiding taking up too much screen space; the button's layer is set to the highest using the CSS "z-index" property (e.g., z-index:9999), ensuring it is displayed above tables, charts, and other elements in the task dashboard and is not obscured; it supports different screen sizes (e.g., desktop and tablet), and the button size and position are automatically adjusted (e.g., the button size is enlarged by 1.2 times on tablets to avoid touch operation errors).

[0050] After a user clicks on the floating interactive entry component, the front end pops up a Q&A interface in the form of a "modal" (instead of jumping to a new page). The user does not need to leave the current task dashboard interface, and can close the modal at any time during the query process to return to the dashboard, avoiding operation interruption. The Q&A interface automatically synchronizes the current dashboard's filter conditions (e.g., if the dashboard has been filtered as "incomplete tasks", the Q&A interface's default query scope is "incomplete tasks"), reducing the user's repetitive input. The Q&A interface includes an "input box" (supporting multi-line input, with the prompt text: "Please enter your query requirements, such as 'show task completion status in the last 3 months'"), "history" (displaying the user's last 10 query results, which can be reviewed again), and "help documentation" (click to view frequently asked questions, such as "how to query specific types of tasks").

[0051] To improve user input efficiency (especially for complex queries), the input box provides the following auxiliary functions: Tip: When a user enters keywords (such as "completion rate"), a drop-down menu will display common query templates (such as "show the task completion rate of [research group] in the recent [time]" and "compare the task completion rates of [research group 1] and [research group 2]"). Users can quickly generate query statements by clicking on the templates. Error message: If the user enters content without a clear query intent (such as "data query"), a prompt will be displayed below the input box: "Please specify the dimensions of the query, such as time range, research group, indicators (completion rate / quantity, etc.)" to guide the user to improve their requirements.

[0052] In existing systems, direct communication between the front-end and back-end services poses security risks (such as exposed interfaces and unencrypted data transmission), and it is difficult to manage interface calls uniformly (such as rate limiting and logging). This step establishes communication between the interaction entry component and the back-end processing service through an API gateway. Its core functions include: Security protection: The API gateway performs authentication (verifies whether the user token is valid), permission verification (verifies whether the user has permission to query the research group's data), and request encryption (uses HTTPS protocol to transmit data to prevent data leakage). Traffic control: Set limits on the frequency of API calls (e.g., a maximum of 10 queries per minute for a single user) to prevent high-frequency requests from overloading the backend service; Log recording: Records the user ID, query content, call time, and response result for each request, which facilitates subsequent troubleshooting (e.g., if the user reports a query failure, the log can be used to locate the cause).

[0053] In some embodiments, see Figure 4 , Figure 4 This is a flowchart illustrating steps S401-S403 provided in the embodiments of this application. The parsing query intent can be achieved through steps S401-S403, which will be explained in conjunction with each step.

[0054] In step S401, the large language model is invoked, and the natural language query request and the research group scope information are passed into the model as input parameters; In step S402, the data dimensions, filtering conditions, and visualization requirements involved in the query are identified through the model; In step S403, permission constraints are set based on the research group scope information to filter query dimensions that exceed user permissions and reduce semantic ambiguity.

[0055] This application selects the Qwen-Max model as the core of intent parsing. The Qwen-Max model has high accuracy in understanding Chinese natural language, and is particularly good at handling "domain-specific problems" (such as research group task data queries). It can accurately identify domain terms such as "last 3 months" and "task completion rate". The first packet latency of the Qwen-Max model (the time from initiating a request to receiving the first part of the response) is usually <500ms, which meets the user's "real-time query" needs (avoiding excessively long waiting times). It supports the injection of domain knowledge (such as standard field dictionaries and research group information) through Prompt, reducing model "illusions" (such as generating non-existent fields or research group names).

[0056] To ensure the accuracy and stability of the analysis results, the following model parameters are set: Temperature: Set to 0.1 (range 0-1). The lower the temperature, the more certain the model output (avoiding the generation of multiple different analytical results), which is suitable for scenarios that require precise analysis. Maximum tokens (max_tokens): Set to 512 to ensure that complex query requirements can be fully parsed (such as "comparing the completion rates of the first-level tasks of the three research groups of Artificial Intelligence, Solid-State Battery and Basic Software in the past 6 months, and sorting them by completion rate from high to low"), while avoiding outputting redundant content. Stop Words: Set the stop word to "parse end" to ensure that the model automatically stops outputting after parsing is complete, avoiding unnecessary text from interfering with subsequent processing.

[0057] The model extracts core data dimensions from query requests through semantic analysis: Time dimension: Identify time expressions such as "the last 3 months", "January-March 2024", and "last week" and convert them into standard time ranges (e.g., "the last 3 months" → "March 1, 2024 to May 31, 2024"). Research Group Dimension: Identify entities such as "Vehicle-Road-Cloud-Star Research Group" and "Artificial Intelligence Research Group". If the user does not explicitly mention it (e.g., "Show task completion rate in the past 3 months"), the user's research group will be filled in by default. Task hierarchy dimension: Recognizes hierarchical descriptions such as "Level 1 Task" and "Level 2 Task". If not mentioned, it will be parsed according to the "Overall Task" dimension by default. Metrics dimensions: Identify metrics such as “completion rate”, “quantity”, and “incomplete percentage”, and convert them into standard metric names (e.g., “completion rate” → “task completion rate”, “quantity” → “task quantity”).

[0058] Identify hidden filter conditions in the query: Task status filtering: such as "incomplete task" and "delayed task", can be converted into standard filtering conditions (such as "task completion status = incomplete" and "task completion time > planned completion time"). Task type filtering: such as "model training task" and "interface debugging task", can be converted to "task type = model training" and "task type = interface debugging"; Priority filtering: such as "high priority task" is converted to "task priority = high".

[0059] Inferring the user's visualization needs based on the query description: If the query includes "comparison" or "ranking", the expected requirement is a bar chart / column chart (to facilitate comparison of data from different subjects). If the query contains "trend" or "change", the requirement is inferred to be a line chart (to easily display time series changes). If the query contains "percentage", it is inferred that the requirement is a pie chart / dot chart (to easily show the percentage of each part). If the query contains "details" or "list", it is inferred that the requirement is a table (to facilitate the display of specific data).

[0060] This application's embodiments ensure query compliance through "permission constraints": The user's research group scope information comes from the existing system's permission management module (such as the group's digital permission platform) to ensure the accuracy of permission information; if the user's parsed query intent contains "research groups beyond their permissions" (such as the user only having permission to query "vehicle-road-cloud-star research group" but querying "solid-state battery research group" data), the model will automatically filter out the research group and add "permission prompts" to the parsing results (such as "You do not have permission to query solid-state battery research group data, this part of the request has been automatically filtered out").

[0061] In addition to permission constraints, the model also reduces semantic ambiguity in the following ways: If a user uses non-standard terminology (such as "task completion time"), the model automatically maps it to the standard field ("task completion time") to avoid parsing errors caused by inconsistent terminology. For ambiguous queries (such as "recent months" or "certain research groups"), the model guides the user to clarify their needs through follow-up questions (e.g., displaying prompts on the front end such as "Please specify the exact duration of 'recent months' (e.g., 3 months / 6 months)" or "Please specify the exact name of 'certain research groups'"). If a user query contains multiple intents (such as "display task completion rates for the past 3 months and export data"), the model breaks it down into "visualization needs (displaying completion rates)" and "export needs (exporting data)" to ensure that subsequent steps can be handled separately.

[0062] In some embodiments, see Figure 5 , Figure 5 This is a flowchart illustrating steps S501-S504 provided in the embodiments of this application. The step of performing field alignment processing on the heterogeneous task data of the corresponding research group based on the field mapping rules to obtain standardized task data can be achieved through steps S501-S504, which will be explained in conjunction with each step.

[0063] In step S501, based on the field mapping rules, the original fields in the heterogeneous task data of the corresponding research group are traversed. In step S502, the original fields that do not match the standard fields are discarded; In step S503, for missing fields in the standard fields where no corresponding original field is found, empty values ​​are automatically filled in; In step S504, the processed task data is uniformly converted into standardized task data that conforms to the preset standard field format, and adapted to the same set of downstream processing logic.

[0064] Here, the object being traversed is the "original task data table of the corresponding research group" (such as the original table "ai_task_data" for the artificial intelligence research group, and the original table "solid_battery_task_data" for the solid-state battery research group). The traversal scope includes all fields in the table (such as "task_id", "finish_dt", "task_type", "model_version", etc.). The traversal process is implemented through a backend program (such as Python's Pandas library or Java's MyBatis framework). When iterating through each original field, the backend service retrieves the research group's "field mapping rules" from the external rule storage module and establishes a matching index (such as a hash table) for "original field - standard field": Index structure: The key is the original field name (e.g., "finish_dt"), and the value is the corresponding standard field information (e.g., {"standard_field":"task completion time","data_type":"date","default_value":"not completed"}). Matching efficiency: Field matching with O(1) time complexity is achieved through a hash table, ensuring that even if the original table has a large number of fields (such as 20 fields), the matching can be completed quickly without affecting the processing efficiency.

[0065] "Redundant fields" refer to fields in the original field that are not defined in the "Field Mapping Rules" (i.e., fields without corresponding standard fields). The determination logic is as follows: Traverse the original field list. If a field (such as "model_version" from the AI ​​research group) has no corresponding value in the matching index (i.e., the mapping relationship between "model_version" and "standard field" is not defined in the rule), it is determined to be a redundant field. If the original field is a "primary key field" (such as "task_id"), it is not determined to be a redundant field even if it is not defined in the rule (it needs to be retained as a unique identifier for the task) to avoid subsequent data association errors.

[0066] At the data level, when generating standardized task data, redundant fields are directly excluded (e.g., if the original table has a "model_version" field, this field is not retained in the standardized table) to avoid redundant data consuming storage resources; information on discarded fields is recorded (e.g., "The original field 'model_version' of the Artificial Intelligence Research Group did not match the standard field and has been discarded") and stored in the system log for easy subsequent investigation (e.g., if a user reports that a field is missing, the log can be used to confirm whether it is a redundant field); if the number of discarded fields is large (e.g., exceeding 30% of the total number of original fields), a prompt is added to the natural language summary of the query results (e.g., "There are 3 fields in the original data of the Artificial Intelligence Research Group that did not match the standard field and have been discarded, which does not affect the core indicator analysis") to avoid user confusion.

[0067] "Missing field" refers to a field that exists in the standard field list but not in the original field list (i.e., the standard field has no corresponding original field). The determination logic is as follows: First, determine the "standard field list" for the research group (summarized from field mapping rules, such as ["task ID", "task name", "task completion time", "task completion status", "task type"]). Iterate through the standard field list. If a standard field (such as "task type") does not have a corresponding field in the original field list (i.e., there is no "task_type" or similar field in the original table), it is determined to be a missing field.

[0068] Different null value filling strategies are adopted based on the data type and business meaning of the standard field: Date type fields (such as "task completion time"): Fill with the default value "not completed" (if the task is not completed) or "1970-01-01" (if a uniform date format is required); String type fields (such as "task type"): Fill with the default value "unmarked"; Numeric type fields (such as "task hours"): Fill with the default value "0"; Boolean type fields (such as "whether to postpone"): filled with the default value "false" (not postponed); Default values ​​can be defined in the field mapping rules (e.g., the default value for "Task Type" is "Unlabeled"), which can be flexibly adjusted to meet the business needs of different research groups.

[0069] Next, the "processed fields (retained original fields + filled missing fields)" will be uniformly converted according to the standard field format: If the original field "finish_dt" is a string ("20240510"), and the standard field "task completion time" is a date ("2024-05-10"), the string will be converted to a standard date format by a backend program (such as Python's datetime library); all field names of the standardized task data will use standard field names (such as "task ID" and "task completion time"), and the original field names will no longer be retained to ensure that the field names are consistent when generating SQL and charts in the future.

[0070] The generated standardized task data (such as DataFrame format or database temporary table) can be directly adapted to the same set of downstream processing logic (such as SQL generation, task splitting, and visualization): For the SQL generation module: there is no need to modify the SQL template for different research groups (e.g., the SQL template for querying "task completion rate" is uniformly "SELECT task completion status, COUNT (task ID) FROM standardized table GROUP BY task completion status"). For the task splitting module: all standardized data from research groups include a "task name" field, and a unified splitting rule (such as splitting by "-") can be directly applied. For the visualization module: all standardized data from all research groups include standard fields such as "task completion time" and "task completion status", and a unified chart template (such as a line chart grouped by "task completion time") can be directly applied to achieve "one set of logic to adapt to multiple sets of data".

[0071] In some embodiments, see Figure 6 , Figure 6 This is a flowchart illustrating steps S601-S604 provided in the embodiments of this application. The step of selecting the corresponding data output format according to the data volume of the target task data and performing adaptation processing on the target task data can be achieved through steps S601-S604, which will be explained in conjunction with each step.

[0072] In step S601, the character length or number of data lines of the target task data is counted to complete the data volume assessment; In step S602, if the evaluation result shows that the amount of data exceeds a preset threshold, the target task data is converted into a temporary file format and stored. In step S603, if the evaluation result shows that the amount of data does not exceed the preset threshold, the target task data is converted into string format; In step S604, a format identifier is output to the downstream processing node, enabling the downstream node to adaptively identify and parse the data in the corresponding format based on the identifier.

[0073] Here, the character length or number of lines of the target task data is first counted to complete the evaluation. If it exceeds the preset threshold (referencing the platform's 80,000 character limit, it is set to 75,000 characters and 1,000 lines), it is converted into a CSV temporary file for storage and a dedicated download link is generated. If it does not exceed the threshold, it is directly converted into a JSON string for quick display by the front end. At the same time, the format identifier is passed to downstream nodes to ensure that they can automatically recognize and parse it. This avoids the tediousness of downloading small data files and breaks through the bottleneck of outputting large data strings.

[0074] The value of this embodiment lies in its ability to adapt to different data scenarios without modifying the underlying platform limitations, through lightweight format switching: CSV files support the export of millions of rows of data to meet users' batch analysis needs; JSON strings enable data rendering in seconds to adapt to real-time query scenarios, and file storage is set with a 24-hour expiration and cleanup mechanism to balance data availability and system storage resource optimization.

[0075] In some embodiments, see Figure 7 , Figure 7 This is a flowchart illustrating steps S701-S704 provided in the embodiments of this application. The step of generating a visualization chart and natural language summary based on the feature matching visualization template of the target task data and outputting the query results to the user can be achieved through steps S701-S704, which will be explained in conjunction with each step.

[0076] In step S701, the type of the target task data is analyzed to determine whether it is time series data, categorical data, or numerical comparison data; In step S702, the corresponding chart type, such as line chart, bar chart or pie chart, is matched from the preset ECharts chart template library based on the data type. In step S703, the large language model is invoked, and the target task data is input into the model to generate a natural language summary of data trends and anomaly interpretations; In step S704, the generated visualization charts and natural language summaries are integrated, and the query results are output in an interactive format.

[0077] Here, the target data type (time series / categorical comparison / detailed data) is first analyzed, and the corresponding chart is automatically matched from the ECharts template library (e.g., line chart for time series, bar chart for categorical comparison, and interactive table for detailed data). Then, a large language model is called to generate a natural language summary with trend judgment and anomaly recognition based on data features. Finally, the "chart + summary" is integrated and output with a responsive interface, supporting chart scaling and downloading, table filtering and sorting, and adapting to multiple terminals such as computers, tablets, and mobile phones.

[0078] The above approach upgrades "data display" to "data interpretation": charts dynamically adapt to data characteristics, avoiding errors caused by manual selection of chart types; natural language summaries extract the business significance behind the data (such as "a certain research group's incomplete rate is significantly higher than other groups"), helping non-technical users quickly grasp core information; and interactive functions improve the efficiency of data exploration, allowing users to complete operations such as filtering and exporting without relying on professional tools.

[0079] In summary, the embodiments of this application have the following beneficial effects: By using an external rule storage module, heterogeneous fields across research groups can be unified and rapidly expanded without developing independent logic for each group, significantly reducing system maintenance costs and adaptation time for new research groups. Natural language parsing and NL2SQL conversion break down the barriers to using SQL and BI tools, allowing business personnel to initiate queries verbally, while permission constraints ensure query compliance, significantly improving data acquisition efficiency. Dynamically adapting output (CSV files / JSON strings) overcomes platform character limitations, accommodating both large-scale batch analysis and small-scale real-time display needs. Leveraging ECharts dynamic chart matching and large language model summarization, "automatic data visualization + intelligent interpretation" is achieved, helping users quickly capture data trends and anomalies. It also supports lightweight integration into existing systems without reconstruction, ultimately addressing existing technical pain points from multiple dimensions—cost reduction, efficiency improvement, ease of use, and adaptability—providing an efficient, flexible, and low-barrier solution for collaborative data analysis across multiple research groups.

[0080] Based on the same inventive concept, this application also provides an intelligent processing and visualization device for heterogeneous task data of multiple research groups, which corresponds to the intelligent processing and visualization method for heterogeneous task data of multiple research groups in the first embodiment. Since the principle of the device in this application is similar to the intelligent processing and visualization method for heterogeneous task data of multiple research groups, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0081] like Figure 8 As shown, Figure 8 This is a schematic diagram of the intelligent processing and visualization device 800 for heterogeneous task data from multiple research groups provided in this application embodiment. The intelligent processing and visualization device 800 for heterogeneous task data from multiple research groups includes: Module 801 is used to build an external rule storage module, which includes field mapping rules and task splitting rules corresponding to each research group. The determination module 802 is used to receive the natural language query request input by the user and the associated research group scope information, and to analyze the query intent in combination with the research group scope information to determine the query requirements. Alignment module 803 is used to perform field alignment processing on heterogeneous task data of the corresponding research group based on the field mapping rules to obtain standardized task data. The splitting module 804 is used to perform structured splitting of the task names of standardized task data based on the task splitting rules to obtain structured task fields; The acquisition module 805 is used to generate and execute SQL query statements based on the query requirements and field information of standardized task data to obtain the target task data; The adaptation module 806 is used to select the corresponding data output format according to the data volume of the target task data and to adapt the target task data. The output module 807 is used to generate visual charts and natural language summaries based on feature matching visualization templates of target task data, and output query results to users; when a new research group is added, the corresponding rules are only added to the rule storage module so that the system can dynamically load the new rules to support the data processing of the research group.

[0082] Those skilled in the art should understand that Figure 8 The functions of each unit in the intelligent processing and visualization device 800 for heterogeneous task data from multiple research groups can be understood by referring to the relevant description of the intelligent processing and visualization method for heterogeneous task data from multiple research groups mentioned above. Figure 8 The functions of each unit in the intelligent processing and visualization device 800 for heterogeneous task data from multiple research groups shown can be realized through a program running on a processor or through specific logic circuits.

[0083] In one possible implementation, the construction of the external rule storage module includes: The rule storage module is configured as an editable file format, making it independent of the system's core processing logic; The field mapping rules define a one-to-one correspondence between the original fields of each research group and the preset standard fields; The task splitting rules define the splitting logic of task names according to preset delimiters and the constraints on the number of field segments after splitting.

[0084] In one possible implementation, receiving the user's input natural language query request and associated research group scope information includes: Add a floating interactive entry component to the task dashboard interface of the existing task management system; Receive natural language query requests from users who are redirected to the question-and-answer interface after clicking the interactive entry component; The API gateway establishes a communication connection between the interactive entry component and the backend processing service, synchronizing the research group scope information associated with the user.

[0085] In one possible implementation, the parsing of the query intent includes: The large language model is invoked, and the natural language query request and the research group's scope information are passed into the model as input parameters; The model identifies the data dimensions, filtering conditions, and visualization requirements involved in the query. By setting permission constraints based on the research group's scope information, query dimensions that exceed user permissions are filtered out, reducing semantic ambiguity.

[0086] In one possible implementation, the step of performing field alignment processing on the heterogeneous task data of the corresponding research group based on the field mapping rules to obtain standardized task data includes: Based on field mapping rules, the original fields in the heterogeneous task data of the corresponding research group are traversed; Discard any original fields that do not match the standard fields; For missing fields where no corresponding original field is found in the standard fields, automatically fill in empty values; The processed task data is uniformly converted into standardized task data that conforms to the preset standard field format, and adapted to the same set of downstream processing logic.

[0087] In one possible implementation, the step of selecting the corresponding data output format based on the data volume of the target task data and performing adaptation processing on the target task data includes: Calculate the character length or number of rows of data for the target task to complete the data volume assessment; If the evaluation results show that the data volume exceeds the preset threshold, the target task data will be converted into a temporary file format and stored. If the evaluation results show that the amount of data does not exceed the preset threshold, the target task data will be converted into string format; Output a format identifier to downstream processing nodes so that downstream nodes can adaptively identify and parse data of the corresponding format based on the identifier.

[0088] In one possible implementation, the feature matching visualization template based on the target task data generates visualization charts and natural language summaries, and outputs query results to the user, including: Analyze the type of data for the target task to determine whether it is time series data, categorical data, or numerical comparison data. Based on the data type, it matches the corresponding chart type from the preset ECharts chart template library, such as line chart, bar chart, or pie chart; Call the large language model, input the target task data into the model to generate a natural language summary of data trends and anomaly interpretation; The generated visualizations and natural language summaries are integrated to output query results in an interactive format.

[0089] The aforementioned intelligent processing and visualization device for heterogeneous task data from multiple research groups achieves unified and rapid expansion of heterogeneous fields across research groups through an external rule storage module, eliminating the need to develop independent logic for each group, significantly reducing system maintenance costs and adaptation time for new research groups. Leveraging natural language parsing and NL2SQL conversion, it breaks down the barriers to using SQL and BI tools, allowing business personnel to initiate queries verbally, while ensuring query compliance through permission constraints, significantly improving data acquisition efficiency. By dynamically adapting the output to the data volume (CSV file / JSON string), it overcomes platform character limitations, accommodating both large-scale batch analysis and small-scale real-time display needs. Based on ECharts dynamic chart matching and large language model summarization, it achieves "automatic data visualization + intelligent interpretation of meaning," helping users quickly capture data trends and anomalies. It also supports lightweight integration into existing systems without reconstruction, ultimately addressing existing technical pain points from multiple dimensions of "cost reduction, efficiency improvement, ease of use, and adaptability," providing an efficient, flexible, and low-barrier solution for collaborative task data analysis across multiple research groups.

[0090] like Figure 9 As shown, Figure 9 This is a schematic diagram of the composition structure of the electronic device 900 provided in the embodiments of this application. The electronic device 900 includes: The device 900 includes a processor 901, a storage medium 902, and a bus 903. The storage medium 902 stores machine-readable instructions executable by the processor 901. When the electronic device 900 is running, the processor 901 communicates with the storage medium 902 via the bus 903. The processor 901 executes the machine-readable instructions to perform the steps of the intelligent processing and visualization method for heterogeneous task data from multiple research groups as described in the embodiments of this application.

[0091] In practical applications, the various components in the electronic device 900 are coupled together via a bus 903. It is understood that the bus 903 is used to achieve communication between these components. In addition to a data bus, the bus 903 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 9 The general designated all buses as Bus 903.

[0092] The aforementioned electronic devices achieve unified and rapid expansion of heterogeneous fields across research groups through an external rule storage module, eliminating the need to develop independent logic for each group, significantly reducing system maintenance costs and adaptation time for new research groups. Leveraging natural language parsing and NL2SQL conversion, they break down the barriers to using SQL and BI tools, allowing business personnel to initiate queries verbally, while ensuring query compliance through permission constraints, significantly improving data acquisition efficiency. Dynamically adapting output (CSV files / JSON strings) overcomes platform character limitations, accommodating both large-scale batch analysis and small-scale real-time display needs. Utilizing ECharts dynamic chart matching and large language model summarization, they achieve "automatic data visualization + intelligent interpretation of meaning," helping users quickly capture data trends and anomalies. They also support lightweight integration into existing systems without reconstruction, ultimately addressing existing technical pain points from multiple dimensions—cost reduction, efficiency improvement, ease of use, and adaptability—providing an efficient, flexible, and low-barrier solution for collaborative data analysis across multiple research groups.

[0093] This application also provides a computer-readable storage medium storing executable instructions. When the executable instructions are executed by at least one processor 901, the intelligent processing and visualization method for heterogeneous task data from multiple research groups described in this application is realized.

[0094] In some embodiments, the storage medium may be a magnetic random access memory (FRAM), a read-only memory (ROM), or a programmable read-only memory (PROM). Erasable Programmable Read-Only Memory (EPROM) Electrically Erasable Programmable Read-Only Memory (EEPROM) Read-only memory, flash memory, magnetic surface storage, optical disc, or CD-ROM ROM, Compact Disc Read It can be a memory such as a memory only; or it can be a device that includes one or any combination of the above-mentioned memories.

[0095] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0096] As an example, executable instructions may, but do not necessarily, correspond to files in the file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0097] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0098] The aforementioned computer-readable storage medium achieves unified and rapid expansion of heterogeneous fields across research groups through an external rule storage module, eliminating the need to develop independent logic for each group, significantly reducing system maintenance costs and adaptation time for new research groups. Leveraging natural language parsing and NL2SQL conversion, it breaks down the barriers to using SQL and BI tools, allowing business personnel to initiate queries verbally, while ensuring query compliance through permission constraints, significantly improving data acquisition efficiency. Dynamically adapting output (CSV files / JSON strings) overcomes platform character limitations, accommodating both large-scale batch analysis and small-scale real-time display needs. Based on ECharts dynamic chart matching and large language model summarization, it achieves "automatic data visualization + intelligent interpretation of meaning," helping users quickly capture data trends and anomalies. It also supports lightweight integration into existing systems without reconstruction, ultimately addressing existing technical pain points from multiple dimensions of "cost reduction, efficiency improvement, ease of use, and adaptability," providing an efficient, flexible, and low-barrier solution for collaborative data analysis across multiple research groups.

[0099] In the several embodiments provided in this application, it should be understood that the disclosed methods and electronic devices can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components may be combined, or integrated into another system, or some features may be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0100] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0101] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0102] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a platform server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

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

Claims

1. A method for intelligent processing and visualization of multi-subject group heterogeneous task data, characterized in that, The method comprises the following steps: An external plug-in rule storage module is constructed, which contains field mapping rules and task splitting rules corresponding to each subject group; A natural language query request input by a user and associated subject group range information are received, and a query intention is analyzed in combination with the subject group range information to determine a query requirement; Based on the field mapping rules, field alignment processing is performed on heterogeneous task data corresponding to the subject group to obtain standardized task data; Based on the task splitting rules, the task name of the standardized task data is structurally split to obtain a structured task field; An SQL query statement is generated according to the query requirement and the field information of the standardized task data, and is executed to obtain target task data; According to the data volume of the target task data, a corresponding data output format is selected to adaptively process the target task data; A visual template is matched based on the characteristics of the target task data to generate a visual chart and a natural language abstract, and the query result is output to the user; when a new subject group is added, only the corresponding rules are supplemented in the rule storage module to enable the system to dynamically load the new rules to support data processing of the subject group.

2. The method of claim 1, wherein, The external plug-in rule storage module is constructed, comprising: The rule storage module is set to an editable file format, which is independent of the system core processing logic; In the field mapping rules, a one-to-one correspondence between the original fields of each subject group and the preset standard fields is defined; In the task splitting rules, the splitting logic of the task name according to the preset delimiter and the quantity constraint of the field segment after splitting are defined.

3. The method of claim 1, wherein, The natural language query request input by the user and the associated subject group range information are received, comprising: A floating interactive entry component is set on the task board interface of the existing task management system; The natural language query request input by the user after jumping to the question and answer interface by clicking the interactive entry component is received; An API gateway is used to establish a communication connection between the interactive entry component and the backend processing service, and the subject group range information associated with the user is synchronized.

4. The method of claim 1, wherein, The query intention is analyzed, comprising: A large language model is called, and the natural language query request and the subject group range information are input into the model as input parameters; The data dimensions, filtering conditions and visualization requirements involved in the query are identified by the model; Based on the subject group range information, permission constraints are set to filter the query dimensions beyond the user's authority and reduce semantic ambiguity.

5. The method of claim 1, wherein, Based on the field mapping rules, the field alignment processing is performed on the heterogeneous task data corresponding to the subject group to obtain standardized task data, comprising: Based on the field mapping rules, the original fields in the heterogeneous task data corresponding to the subject group are traversed; The original fields that are not matched to the standard fields are discarded; The missing fields in the standard fields that do not find corresponding original fields are automatically filled with null values; The processed task data is uniformly converted into standardized task data in a preset standard field format to adapt to the same set of downstream processing logic.

6. The method of claim 1, wherein, The data volume of the target task data is counted, and the data volume is evaluated; ​ If the evaluation result shows that the data volume exceeds the preset threshold, the target task data is converted into a temporary file format and stored; If the evaluation result shows that the data volume does not exceed the preset threshold, the target task data is converted into a string format; Output the format identifier to the downstream processing node, so that the downstream node can adaptively identify and parse the data in the corresponding format according to the identifier.

7. The method of claim 1, wherein, The feature matching visualization template based on the target task data generates a visualization chart and a natural language summary, and outputs the query result to the user, including: Analyze the type of the target task data to determine whether it is time series data, classification data, or numerical comparison data; Based on the data type, match the corresponding chart type from the preset ECharts chart template library, such as line chart, column chart, or pie chart; Call a large language model and pass the target task data into the model to generate a natural language summary of the data trend and anomaly interpretation; Integrate the generated visualization chart and natural language summary to output the query result in a user-interactive form.

8. An intelligent processing and visualization device for multi-subject group heterogeneous task data, characterized in that, The device comprises: A construction module for constructing an external plug-in rule storage module, which contains field mapping rules and task splitting rules corresponding to each subject group; A determination module for receiving a natural language query request input by a user and associated subject group range information, analyzing the query intent in combination with the subject group range information, and determining the query requirement; An alignment module for performing field alignment processing on the heterogeneous task data of the corresponding subject group based on the field mapping rules to obtain standardized task data; A splitting module for structurally splitting the task name of the standardized task data based on the task splitting rules to obtain structured task fields; An acquisition module for generating and executing a SQL query statement according to the query requirement and the field information of the standardized task data to acquire target task data; An adaptation module for selecting a corresponding data output format according to the data volume of the target task data and performing adaptation processing on the target task data; An output module for generating a visualization chart and a natural language summary based on a feature matching visualization template of the target task data and outputting the query result to the user; when a new subject group is added, only the corresponding rules are supplemented in the rule storage module to enable the system to dynamically load the new rules to support data processing of the subject group.

9. An electronic device, comprising: It comprises: A processor, a storage medium, and a bus, the storage medium stores machine-readable instructions executable by the processor, when the electronic device is running, the processor and the storage medium communicate through the bus, the processor executes the machine-readable instructions to perform the intelligent processing and visualization method of the multi-subject group heterogeneous task data as claimed in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which is executed by the processor when running to perform the intelligent processing and visualization method of the multi-subject group heterogeneous task data as claimed in any one of claims 1 to 7.

Images