Chart generation method and device, equipment and storage medium

Abstract

The invention provides a chart generation method and device, equipment and a storage medium, and the method comprises the steps: obtaining target query data corresponding to query intention information according to the query intention information in a query instruction in response to the query instruction; based on the target query data, extracting feature information of the target query data by a pre-trained deep learning model; according to a preset rule, a target type matched with the feature information and the query intention information is determined in the multiple chart types, and the preset rule is used for indicating the corresponding relation of the feature information, the query intention information and the chart types; and displaying the data chart of the target type on the target interaction interface based on the target query data. According to the method, the advantages of the deep learning model and the manual compiling rule can be combined, and the accuracy of chart type recommendation is improved.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a chart generation method, apparatus, device, and storage medium. Background Technology

[0002] With the advent of the big data era, data has become a crucial factor of production. The key is to quickly extract critical information from massive amounts of data and present this information clearly and accurately to decision-makers. In this process, data visualization, especially chart generation, plays an indispensable role. It can transform complex and abstract data relationships into intuitive graphical representations, thereby improving the efficiency of information transmission and understanding.

[0003] Currently, automated chart generation methods mainly fall into two categories. One is based on predefined rules, which uses chart selection guidelines summarized by expert experience (e.g., "use line charts to analyze trends, and bar charts to compare categories") to select the chart type by matching the basic data type (such as dimension and measure) and the user's stated simple intent. The other is based on deep learning models, which use a large number of "data-chart" pairing samples for training, enabling the model to directly learn from data features and predict the most suitable chart type.

[0004] However, both of the aforementioned existing technologies suffer from the following drawbacks: On the one hand, while the method using only preset rules is logically transparent, the rule system struggles to cover all complex and implicit features in the data (such as data distribution patterns and potential correlations between multiple dimensions), resulting in the determined chart type potentially failing to optimally reveal the deep-seated patterns in the data, thus limiting accuracy. On the other hand, while the method relying solely on deep learning models can capture complex features, its decision-making process is like a "black box," lacking interpretability; more importantly, the model may produce visualizations that, while consistent with its internal logic, are actually meaningless or even misleading, and it is difficult to trace and adjust the reasons for the decisions. Summary of the Invention

[0005] This application provides a chart generation method, apparatus, device, and storage medium to solve the problems in the prior art where chart types are determined by using only preset rules, which fails to capture complex and implicit data features, resulting in inaccurate chart types; and the prior art where chart types are determined by using only deep learning models, resulting in opaque decision logic and lack of interpretability, while the chart types determined by deep learning models may lead to meaningless visualization effects.

[0006] Firstly, this application provides a chart generation method, the method comprising:

[0007] In response to a query command, the target query data corresponding to the query intent information in the query command is obtained.

[0008] Based on the target query data, the feature information of the target query data is extracted by a pre-trained deep learning model;

[0009] According to preset rules, among several chart types, a target type that matches the feature information and the query intent information is determined. The preset rules are used to indicate the correspondence between the feature information, the query intent information and the chart type.

[0010] Based on the target query data, a data chart of the target type is displayed on the target interactive interface.

[0011] In one possible design, displaying a data chart of the target type on the target interactive interface based on the target query data includes:

[0012] Obtain the chart configuration template corresponding to the target type;

[0013] The target query data is populated into the chart configuration template to generate a chart configuration object;

[0014] Based on the chart configuration object, generate chart rendering code;

[0015] Execute the chart rendering code to display the data chart on the target interactive interface.

[0016] In one possible design, generating chart rendering code based on the chart configuration object includes:

[0017] Obtain the code template corresponding to the chart configuration object;

[0018] Insert the chart configuration object into the code template to generate the chart rendering code.

[0019] In one possible design, obtaining the target query data corresponding to the query intent information based on the query instruction includes:

[0020] Based on the query intent information, multiple corresponding candidate service interfaces are determined;

[0021] Obtain the current status information of each of the candidate service interfaces;

[0022] The current state information is input into a pre-trained reinforcement learning model. The reinforcement learning model determines the target service interface from the candidate service interfaces based on the score value corresponding to each current state information. The target service interface has the highest score value. The score value is positively correlated with the calling performance of the candidate service interface.

[0023] Call the target service interface to obtain the target query data.

[0024] In one possible design, determining multiple corresponding candidate service interfaces based on the query intent information includes:

[0025] Based on the query intent information, multiple corresponding candidate service types are determined;

[0026] Determine the first historical performance score for each of the candidate service types;

[0027] Based on the first historical performance score, a target service type is determined from the candidate service types, wherein the target service type has the highest first historical performance score.

[0028] Identify multiple candidate service instances corresponding to the target service type;

[0029] Determine a second historical performance score for each of the candidate service instances;

[0030] Based on the second historical performance score, a target service instance is determined from the candidate service instances, and the target service instance has the highest second historical performance score.

[0031] Based on the target service instance, multiple candidate service interfaces are determined.

[0032] In one possible design, prior to responding to a query instruction, the method further includes:

[0033] Obtain the user's query text;

[0034] The query instruction is generated based on the query request text.

[0035] In one possible design, generating the query instruction based on the query request text includes:

[0036] Extract multiple semantic units at different semantic levels from the query request text;

[0037] The plurality of semantic units are matched with a preset knowledge graph, and named entities that match the semantic units are determined in the preset knowledge graph;

[0038] Based on the named entities and the relationships between the named entities in the preset knowledge graph, the user's query intent is determined;

[0039] The query instruction is generated based on the named entity and the query intent.

[0040] Secondly, this application provides a chart generation apparatus, the apparatus comprising:

[0041] A response module is used to, in response to a query instruction, obtain the target query data corresponding to the query intent information in the query instruction;

[0042] An extraction module is used to extract feature information of the target query data using a pre-trained deep learning model based on the target query data.

[0043] The matching module is used to determine, according to preset rules, a target type that matches the feature information and the query intent information among several chart types, wherein the preset rules are used to indicate the correspondence between the feature information, the query intent information and the chart type;

[0044] The generation module is used to display a data chart of the target type on the target interactive interface based on the target query data.

[0045] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0046] The memory stores computer-executed instructions;

[0047] The processor executes computer execution instructions stored in the memory to implement the method as described in the first aspect.

[0048] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in the first aspect.

[0049] The chart generation method, apparatus, device, and storage medium provided in this application have the following technical advantages:

[0050] 1. This method automatically extracts complex and implicit data features (such as nonlinear relationships, multimodal distributions, clustering characteristics, etc.) from target data by utilizing pre-trained deep learning models. This overcomes the cognitive limitations and insufficient expression problems that exist when relying solely on manually preset rules. Thus, it can make more accurate and intelligent chart recommendations when facing high-dimensional, complex, or novel data, and avoids inaccurate chart types recommended due to incomplete rule coverage.

[0051] 2. The final chart type is determined according to preset and clearly defined rules. This mechanism changes the decision-making basis for chart type from the "black box" inference of deep learning models to "white box" reasoning based on logical rules. Users and developers can clearly trace the logical chain of recommendation results.

[0052] 3. The preset rules can embed effective knowledge that has been verified in practice in relevant fields, which can verify and filter the recommendation results that may be generated by deep learning models that violate common sense or are meaningless, thereby effectively avoiding the generation of invalid visualization effects. Attached Figure Description

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

[0054] Figure 1 Flowchart of the chart generation method provided in the embodiments of this application Figure 1 ;

[0055] Figure 2 Flowchart of the chart generation method provided in the embodiments of this application Figure 2 ;

[0056] Figure 3 This is a schematic diagram of the method for determining candidate service interfaces provided in an embodiment of this application;

[0057] Figure 4 This is a schematic diagram of the chart generation device provided in the embodiments of this application;

[0058] Figure 5 This is a schematic diagram of the electronic device structure provided in an embodiment of this application.

[0059] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0060] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments matching this application. Rather, they are merely examples of apparatuses and methods matching some aspects of this application as detailed in the appended claims.

[0061] To address the following problems with existing technologies: While methods that generate charts using only preset rules are logically transparent, the rule system struggles to cover all complex and implicit features in the data (such as data distribution patterns and potential relationships between multiple dimensions), resulting in chart types that may not optimally reveal deep data patterns and limited accuracy; while methods that rely solely on deep learning models to generate charts can capture complex features, their decision-making process is like a "black box," lacking interpretability. The model may produce visualizations that, while consistent with its internal logic, are actually meaningless or even misleading, and it is difficult to trace and adjust the reasons for the decisions. The inventors of this application considered that a combination of deep learning models and preset rules could be used. First, the deep learning model extracts the features of the data, and then the chart type is determined based on these features using preset rules. This combines the advantages of deep learning models and preset rules while overcoming the limitations of both.

[0062] Based on the above ideas, the technical concept of this application is as follows:

[0063] Upon receiving a query command, the system retrieves the target query data corresponding to the query intent based on the query intent information in the command, and extracts data features from the target query data using a pre-trained deep learning model. Then, based on preset rules, it determines the chart type that matches the extracted data features and query intent information. Finally, it generates the corresponding chart type using the target data.

[0064] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0065] Example 1

[0066] Figure 1 Flowchart of the chart generation method provided in the embodiments of this application Figure 1 This method can be applied to servers, such as... Figure 1 As shown, the method includes:

[0067] S101. In response to the query command, obtain the target query data corresponding to the query intent information according to the query intent information in the query command;

[0068] In this step, the server can first receive a network request from the client through its network interface. The payload of the network request can carry a structured query instruction object containing explicit fields, such as a "query intent" field (e.g., its value could be "trend comparison analysis") and a "query entity" field (e.g., its value could be a list containing geographical parameters such as "Beijing" and "Shanghai" and indicator parameters such as "temperature").

[0069] Next, the server can parse the query command object, read the "query intent" field, and determine whether the "time series data service" needs to be accessed based on its content (such as "trend comparison analysis"). At the same time, the server parses the "query entity" field to extract key parameters, such as geographical parameters and indicator parameters.

[0070] After identifying the service to be accessed and extracting the key parameters, the server can obtain the target query data in the following two ways:

[0071] Method 1: The server can dynamically construct a standard query statement based on the parsed parameters. For example, it can specify to select "temperature" data for "Beijing" and "Shanghai" within a specified date range from the "meteorological data table". Subsequently, the server can execute the query statement and retrieve the original query data that meets the conditions from the database.

[0072] Method 2: The server can select an available "meteorological data service provider interface" based on the pre-set service registration information. Then, the server can assemble the geographic parameters and indicator parameters into a request format that meets the requirements according to the technical specifications of the interface, and initiate a call to the service interface through the network to obtain the raw query data.

[0073] After receiving the raw query data, the server can clean and standardize it. This may include handling potential null or outlier values, unifying data formats from different sources into a standard data model (e.g., a data table with three columns: "City," "Date," and "Temperature"), and performing necessary data aggregation operations (such as calculating the daily average temperature). Ultimately, a clean, structured dataset is generated, which is the target query data.

[0074] S102. Based on the target query data, the feature information of the target query data is extracted by a pre-trained deep learning model;

[0075] First, it should be noted that when the server starts up, it can load a pre-trained deep learning model for extracting data features from the storage disk into memory. After being trained on a large dataset, this deep learning model is capable of mapping any structured data into a mathematical vector that can summarize its core features.

[0076] In this step, the server first standardizes the target query data, for example, by normalizing all values ​​to a specific range to ensure the stability of the input to the deep learning model. Next, the server can convert the standardized data into the input format required by the deep learning model, i.e., multidimensional mathematical tensor data.

[0077] Furthermore, the server inputs this tensor data into a loaded deep learning model, which consists of multiple layers of neural networks. The data undergoes non-linear transformations sequentially through these network layers. It's important to note that the feature extraction stage does not use the final output of the deep learning model, but rather extracts the output of a specific layer. This layer's output is a fixed-length, dense floating-point vector, which represents the feature information of the target query data. This feature information encodes various inherent characteristics of the data in a machine-readable manner, such as the number and size of data points, the number and type of data dimensions, the distribution of values ​​(e.g., whether they are uniform or concentrated), and the presence of trends or periodic patterns over time.

[0078] S103. According to preset rules, determine the target type that matches the feature information and query intent information among several chart types. The preset rules are used to indicate the correspondence between the feature information, query intent information and chart type.

[0079] Specifically, the server can pre-configure a visualization rule knowledge base, which consists of multiple rules. Each rule explicitly specifies which chart type should be recommended when data features and query intent meet certain conditions. For example, one rule in this knowledge base might be defined as: "If the query intent includes 'comparison,' and the data features show the existence of a time dimension and at least two comparable entity dimensions, then a 'multi-line chart' is recommended."

[0080] Therefore, in this step, the server can input the feature information vector obtained in the previous step and the original query intent information into the rule reasoning engine. The role of the rule reasoning engine is to traverse all rules in the visual rule knowledge base and logically match the input feature information vector and the original query intent information with the condition part of each rule.

[0081] After logical matching, the rule inference engine can identify all rules that satisfy the conditions. If only one rule's condition is met, that rule is the optimal rule; if multiple rules' conditions are met, the rule inference engine can select the optimal rule based on preset priorities or rule confidence weights. The chart type pointed to by the optimal rule is determined as the final target chart type. For example, the rule inference engine might output the decision result as "Target type: Multi-line chart".

[0082] S104. Based on the target query data, display the target type data chart on the target interactive interface.

[0083] In this step, the server can construct a chart configuration description object in memory based on the determined target chart type and target query data. For example, the construction process includes: mapping the "date" column in the data table to the horizontal axis data of the chart, mapping the "Beijing temperature" and "Shanghai temperature" columns to two data series respectively, and setting the series type to "line". At the same time, the chart title, axis labels, legend and other visual elements are automatically generated.

[0084] Next, the server can encapsulate this complete chart configuration description object into a standardized network response message. Furthermore, the server sends this network response message back to the requesting client over the network. After receiving the network response message, the client's front-end application parses out the chart configuration description object and then calls the rendering function of the corresponding chart library that has been loaded in the front-end page, passing the configuration object to the chart library. Based on the description of the configuration object, the chart library draws the final interactive data chart in the target interactive interface of the browser.

[0085] The chart generation method provided in this embodiment has the following technical effects:

[0086] 1. This method automatically extracts complex and implicit data features (such as nonlinear relationships, multimodal distributions, clustering characteristics, etc.) from target data by utilizing pre-trained deep learning models. This overcomes the cognitive limitations and insufficient expression problems that exist when relying solely on manually preset rules. Thus, it can make more accurate and intelligent chart recommendations when facing high-dimensional, complex, or novel data, and avoids inaccurate chart types recommended due to incomplete rule coverage.

[0087] 2. The final chart type is determined according to preset and clearly defined rules. This mechanism changes the decision-making basis for chart type from the "black box" inference of deep learning models to "white box" reasoning based on logical rules. Users and developers can clearly trace the logical chain of recommendation results.

[0088] 3. The preset rules can embed effective knowledge that has been verified in practice in relevant fields, which can verify and filter the recommendation results that may be generated by deep learning models that violate common sense or are meaningless, thereby effectively avoiding the generation of invalid visualization effects.

[0089] Example 2

[0090] Figure 2 Flowchart of the chart generation method provided in the embodiments of this application Figure 2 ,like Figure 2 As shown, the method includes:

[0091] S201. Obtain the query request text input by the user, and generate a query instruction based on the query request text;

[0092] In this step, the server can receive query requests from clients (such as web browsers and mobile applications) via an API interface. The request body contains the query text entered by the user, such as "compare the average temperatures in Beijing and Shanghai last week".

[0093] Furthermore, the server can preprocess the query request text, including encoding conversion and sensitive word filtering, to form processed text. The server can then package the processed text with some basic contextual information (such as user ID, session ID, and timestamp) to form a structured query instruction object.

[0094] Optionally, based on the query request text, a query instruction is generated, including:

[0095] 1. Extract multiple semantic units at different semantic levels from the query text;

[0096] In this step, after the server receives the user's query text (such as "compare the average temperatures in Beijing and Shanghai last week"), the server first uses a word segmentation tool to divide the sentence into independent lexical units (such as [compare, Beijing, and, Shanghai, last week, of, average, temperature]), and labels each word with its part of speech (verb, noun, etc.). This is the most basic "word-level" semantic unit.

[0097] Next, the server can perform dependency parsing to identify noun phrases (such as Beijing, Shanghai, average temperature) and prepositional phrases (last week). These phrases are "phrase-level" semantic units, carrying more complete semantics than words.

[0098] Furthermore, the server can analyze the main structure of sentences, extract core verbs (such as "contrast"), and sentence patterns.

[0099] Through the above steps, the server extracts semantic units at the word, phrase, and sentence levels, which serve as multiple semantic units at different semantic levels.

[0100] 2. Match multiple semantic units with a preset knowledge graph, and determine the named entities that match the semantic units in the preset knowledge graph;

[0101] In this step, the server can match the extracted semantic units, especially nouns and noun phrases, with the preset knowledge graph. For example, the server can try to link the two strings "Beijing" and "Shanghai" to the specific "city" entity node in the knowledge graph. The purpose of this process is to resolve ambiguity issues (e.g., to ensure that "apple" refers to a fruit company rather than fruit).

[0102] Once the connection is successfully established, the server can read the attributes of these entity nodes (such as the latitude and longitude of Beijing, the city code of Shanghai) and their relationships with other entities (such as "City" - [Owns] - "Weather Data"). Meanwhile, for relative times like "last week," the server can convert them into an absolute date range (e.g., 2024-05-13 to 2024-05-19) and treat it as a time parameter entity.

[0103] 3. Based on named entities and the relationships between named entities in the pre-defined knowledge graph, determine the user's query intent;

[0104] In this step, for example, the extracted core verb "compare" is the most direct clue to determining intent, indicating that this is a "comparative analysis" type of query. Simultaneously, the knowledge graph provides crucial context and logical verification. For instance, the server identifies "Beijing" and "Shanghai" as comparable entities (both major Chinese cities) and both related to the indicator "temperature." This confirms the feasibility and specific dimensions of the "compare" operation (i.e., comparison at the city level).

[0105] Ultimately, the server can define the intent explicitly and in a structured manner as follows: Execution type: comparative analysis, comparison dimension: city, comparison indicator: average temperature, time range: 2024-05-13 to 2024-05-19.

[0106] 4. Generate query instructions based on named entities and query intent.

[0107] In this step, the server can assemble the results of the previous steps into a computer-readable structured query instruction, which may include, for example, the following:

[0108] Operational objective: To acquire weather data.

[0109] Target parameters: City list: [Beijing, Shanghai], Indicator: Average temperature, Time: 2024-05-13 to 2024-05-19.

[0110] Operation type: Comparison.

[0111] The above method for generating query instructions based on query request text has the following technical effects:

[0112] 1. As a structured domain knowledge base, knowledge graphs provide a basis for semantic disambiguation and concept association in the natural language understanding process. They can accurately match ambiguous or ambiguous words or phrases in user queries with explicitly defined named entities in the knowledge graph, thereby transforming natural language instructions into explicit operations on specific entities and their attributes, avoiding errors or deviations in instruction understanding caused by semantic ambiguity.

[0113] 2. Predefined entity relationships in the knowledge graph enable the automatic deduction of users' implicit query intent based on these relationships, and the verification of the reasonableness and feasibility of the intent. For example, by determining whether entities are comparable, the reasonableness of "comparison" operations is verified, thereby improving the accuracy and logic of generated query instructions.

[0114] 3. The entity attribute information stored in the knowledge graph can automatically complete the key parameters omitted in the user's command. Without the user providing all the technical details (such as the specific parameter format of the API, service address, etc.), the attribute values ​​obtained from the knowledge graph (such as geographical coordinates, time standard format, etc.) can be used directly to generate a structured query command with complete parameters and standardized format, thereby improving the automation level of query command generation.

[0115] Furthermore, the importance of semantic units (words, phrases, sentence-level intents) extracted from the query text can be assessed, and their association strength with relevant entities in the knowledge graph can be calculated, thereby generating a weighted and focused semantic understanding result. Specifically, the server can first convert semantic units of different granularities into numerical vectors. That is, each word (such as "Beijing", "temperature"), each phrase (such as "average temperature"), and the initially judged sentence intent (such as "comparison") are converted into mathematical vector representations.

[0116] Next, the server can perform a "cross" comparison of these vectors with relevant entity vectors retrieved from the knowledge graph. Specifically, this "cross" involves calculating the similarity between each semantic unit vector and every relevant entity vector in the knowledge graph. For example, the word vector "Beijing" will be matched with entities like "Beijing Municipality" and the concept of "city" in the knowledge graph; the phrase vector "average temperature" will be matched with entities like "temperature" and the operation "average value." Then, using normalization functions such as Softmax, the calculated raw similarity scores are transformed into an attention weight distribution between 0 and 1. This weight represents "the importance of matching a semantic unit with a knowledge entity in understanding the user's true needs during the final decision-making process."

[0117] After the attention mechanism is used for calculation, the server obtains a weighted, structured alignment result. For example:

[0118] Entity: Beijing - [Attention weight: 0.95] - Word: Beijing;

[0119] Entity: Temperature - [Attention weight: 0.90] - Phrase: Average temperature;

[0120] Operation: Comparison - [Attention weight: 0.93] - Sentence intention: Comparison;

[0121] Function words such as "de" and "he" may obtain extremely low weights (such as 0.05), and their influence is effectively suppressed.

[0122] Through the above weight calculation steps, the generated query instruction can focus on the core of the user's needs. That is, high-weight entities and intentions (such as "Beijing", "Temperature", "Comparison") will become the main parameters and operation types of the subsequent query instruction, while filtering out low-weight information can effectively prevent noise interference.

[0123] S202. In response to the query instruction, determine multiple corresponding candidate service interfaces according to the query intention information;

[0124] In this step, the server can call the intention classification model to analyze the processed text and extract key intention keywords, such as "Comparison" and "Temperature". The intention classification model can be implemented based on a keyword matching mechanism or a machine learning model.

[0125] Furthermore, the server can query the preset service-intention mapping registry according to the parsed query intention information, so as to determine a list of candidate service interfaces that can meet this intention.

[0126] S201 - S202 realize the conversion of the unstructured natural language requirements input by the user into structured instructions that can be recognized inside the computer, and determine possible backend services based on the query intention. The user only needs to input the natural language query requirement text to finally generate the corresponding chart, reducing the time cost and learning cost for the user to generate the chart.

[0127] S203. Obtain the current status information of each candidate service interface, input the current status information into the pre-trained reinforcement learning model, and the reinforcement learning model determines the target service interface among the candidate service interfaces based on the score value corresponding to each current status information. The score value of the target service interface is the highest, where the size of the score value is positively correlated with the calling performance of the candidate service interface;

[0128] In this step, the server can obtain the current status information of each candidate service interface by calling the health check service. The current status information can include, for example:

[0129] Real-time response latency: The average response time for calls to this interface over a recent period;

[0130] Current error rate: The probability of a call failing within a recent period;

[0131] Service load: The current number of concurrent requests or CPU utilization for this interface;

[0132] Call cost: The expenses that may be incurred in this call;

[0133] Quota remaining: The number of calls remaining in the current billing cycle;

[0134] The server combines this current state information into a feature vector, which is then input into a pre-trained reinforcement learning model. This model can be implemented based on algorithms such as Deep Q-Learning (DQN) or Proximal Policy Optimization (PPO). The reinforcement learning model is trained on a large amount of historical service call data, and its goal is to learn a policy: how to select the service that maximizes long-term benefits (such as shortest response time, lowest failure rate, and lowest cost) when faced with different combinations of states.

[0135] The reinforcement learning model calculates a comprehensive score for each candidate service interface. This score quantifies how "good" or "bad" it is to choose that interface in the current state.

[0136] The server can select the candidate service interface with the highest score and determine it as the target service interface for this call. There can be one or more target service interfaces.

[0137] The technical advantage of this step is that, through reinforcement learning models, dynamic and adaptive optimal decisions can be made based on the current real-time status of the service interface (such as load and latency). This enables the determined target service interface to have a higher call success rate, lower response latency, and more reasonable resource utilization. In particular, in multi-service, high-concurrency scenarios, it can obtain target query data more stably and efficiently.

[0138] S204. Call the target service interface to obtain target query data. Based on the target query data, the pre-trained deep learning model extracts the feature information of the target query data. Then, according to the preset rules, the target type that matches the feature information and query intent information is determined from several chart types. The preset rules are used to indicate the correspondence between the feature information, query intent information and chart type.

[0139] The specific implementation process of this step can be referred to in Embodiment 1, which will not be elaborated here.

[0140] S205. Obtain the chart configuration template corresponding to the target type;

[0141] Specifically, the server can maintain a chart template library. In this library, each chart type (such as "line chart" or "bar chart") corresponds to one or more predefined configuration templates. These configuration templates can be JSON or YAML files, defining the chart's style, layout, and basic interaction logic. For example, a line chart template might pre-set axis styles, line colors, tooltip formats, animation effects, etc. In this step, the server loads the corresponding configuration template from the template library based on the target type determined in S204 (such as "clustered bar chart").

[0142] S206. Populate the target query data into the chart configuration template to generate a chart configuration object;

[0143] In this step, the server can populate the target query data obtained in S204 into the template obtained in S205 according to the data binding rules defined in the chart configuration template. For example, the populated content may include specifying which data field is used as the X-axis, which as the Y-axis, and which as the grouping basis for the data series. After the population is completed, a complete chart configuration object is generated, containing specific data and complete style configuration. This object fully describes all the details of the chart to be rendered.

[0144] S207. Obtain the code template corresponding to the chart configuration object;

[0145] In this step, the server can maintain a code template library, which stores code snippets for different front-end chart libraries. The server can retrieve the corresponding code template from the library based on the chart type and the selected front-end technology stack. It should be noted that this code template is a code file containing placeholders; for example, it might be marked as DATA_PLACEHOLDER where data needs to be inserted, and OPTIONS_PLACEHOLDER where configuration needs to be inserted.

[0146] S208. Insert the chart configuration object into the code template to generate the chart rendering code;

[0147] In this step, the server can insert the chart configuration object generated in S206 into the corresponding placeholder in the code template obtained in S207 by replacing strings, thereby generating a complete chart rendering code that can be run immediately in the front-end environment to render the specified chart.

[0148] S209. Execute the chart rendering code to display the data chart on the target interactive interface.

[0149] In this step, the server can send the generated chart rendering code back to the client. After receiving the chart rendering code, the client (such as a web browser) can execute this code in a secure sandbox. This code calls the rendering function of the front-end chart library and renders the final, interactive data chart in the specified container (i.e., the target interactive interface) of the HTML page based on the data and configuration embedded in the code.

[0150] After rendering the data chart, the chart rendering code can start an event listener to listen for various user interaction events:

[0151] Traditional graphical interactions include mouse hover (displaying detailed data point information), clicking (selecting a data series or data point), box selection, zooming, and panning.

[0152] Natural language interaction: Provides a chat window or voice input interface to continue receiving natural language commands from the user. For example:

[0153] Modify view: The user can input "turn it into a bar chart" or "show only Beijing data".

[0154] Further inquiry: The user clicked on the data line for "Shanghai" in the chart and then said, "View the humidity in Shanghai for the same period."

[0155] Drill-down analysis: The user selected an abnormal time period and then said, "Analyze the reasons for the abnormality during this period."

[0156] Upon detecting an interaction event, the front-end interaction controller can capture the event and parse its meaning. For graphical interactions, the interaction controller can call the chart library's API to update the chart's state (such as applying filter conditions or switching chart types), enabling real-time front-end responses. For natural language interactions, the interaction controller can package new natural language commands, combined with the current chart context (such as current filter conditions and selected data), into a new, more granular query request and send it back to the server. This query request can trigger a process similar to S201-S209, for example, simply rerunning S204-S209 to generate a new chart.

[0157] Further, optionally, the server can record user interactions, such as manually switching the automatically generated pie chart to a bar chart, or frequently using the filtering function; these behaviors suggest user preferences. Alternatively, "like" / "dislike" buttons can be provided, allowing users to directly rate the generated visualizations.

[0158] The collected user feedback can be sent to the server's interactive feedback processor. The interactive feedback processor uses this data to update the user preference model through meta-learning or incremental learning techniques, and periodically fine-tunes the recommendation logic for chart types.

[0159] It should be noted that, since this embodiment uses templates to generate chart rendering code, the code logic for registering event listeners can be pre-defined in the chart configuration template and code template. The code template also includes code for generating the chat component and pre-defined interaction controller code. The interaction feedback processor can be deployed on a server. Therefore, because this embodiment uses chart rendering code to generate data charts, the generated data charts have the ability to interact with users, rather than being static charts.

[0160] S205-S209 have the following technical effects:

[0161] 1. By configuring chart templates and code templates, the development of chart rendering code is transformed into an automated process driven by target query data. Compared to manually writing the same code, this significantly reduces code generation time. Furthermore, because these steps generate code based on predefined templates, it ensures that the generated charts conform to standards in terms of style and interactive behavior, avoiding errors that might occur with manual coding. This also enables business personnel without front-end programming skills to generate professional data visualization applications using natural language descriptions.

[0162] 2. Data charts generated using chart rendering code can be made interactive with users by generating event listeners and interaction controllers.

[0163] Figure 3 This is a schematic diagram of the method for determining candidate service interfaces provided in an embodiment of this application, such as... Figure 3 As shown, optionally, based on the query intent information, multiple corresponding candidate service interfaces can be determined, including:

[0164] S301. Based on the query intent information, determine multiple corresponding candidate service types;

[0165] In this step, the query intent information can be structured information. For example, the query intent information can be: {"Operation":"Query", "Domain":"Weather", "Indicator":"Temperature", "Dimension":"City Comparison"}.

[0166] Next, the server can use this query intent information to query the configuration library of the intent-service type mapping table. This mapping table defines the service types (i.e., the functional categories of services) that different intents can satisfy. For example, for the intent "query city temperature," the mapping table might return the following candidate service types:

[0167] Public meteorological API service (features: free or low cost, universal data);

[0168] Commercial meteorological data services (characteristics: high accuracy, high reliability, may be chargeable);

[0169] Internally deployed meteorological data service (features: private data, low latency);

[0170] Finally, by looking up the table, the output is a list of candidate service types, such as ["Public Meteorological API Service", "Commercial Meteorological Data Service"].

[0171] S302. Determine the first historical performance score for each candidate service type;

[0172] In this step, the server can maintain a first reinforcement learning model, which can manage a Q-value table or use a neural network to approximate a Q-function. The indexes of the aforementioned Q-value table are (intent, service type) pairs.

[0173] For each candidate service type obtained by S301, the service area calls the first reinforcement learning model to query its corresponding first historical performance score, which is the long-term expected return value (Q value) for selecting the service type for the current intention stored in the Q value table.

[0174] S303. Based on the first historical performance score, determine the target service type from the candidate service types, where the target service type has the highest first historical performance score.

[0175] In this step, the server selects the candidate service type with the highest historical performance score as the target service type. For example, if the score of the commercial weather data service (e.g., 9.5) is higher than the score of the public weather API service (e.g., 7.2), then the commercial weather data service is selected as the target service type. This step determines the target service type at the strategic level.

[0176] S304. Determine multiple candidate service instances corresponding to the target service type;

[0177] Specifically, the server can maintain a service instance registry that records all available specific service instances (i.e., specific service providers or deployment nodes) under each service type. Next, based on the target service type determined in S303 (e.g., Commercial Weather Data Service), the server queries the registry for all healthy instances under that type. The final output of this step is a list of candidate service instances. For example, for "Commercial Weather Data Service," the list might be: ["Weather Company instance A", "Accu Weather instance B", "HeFeng Weather instance C"].

[0178] S305. Determine the second historical performance score for each candidate service instance;

[0179] Specifically, the server can maintain a second reinforcement learning model, which also manages a Q-value table or Q-function. Compared to the Q-value table of S302, the index of this table can be more granular, for example, it can be in the form of (intent, service type, service instance) or (service instance, instance state).

[0180] For each candidate service instance obtained by S304, the second reinforcement learning model can combine the real-time state information of the instance (such as current response latency, error rate in the last minute, and current number of concurrent connections) to determine its second historical performance score, which reflects the expected good or bad of selecting the instance in the current specific state.

[0181] S306. Based on the second historical performance score, determine the target service instance from the candidate service instances, where the target service instance has the highest second historical performance score.

[0182] In this step, the server compares the second historical performance scores of all candidate service instances and selects the instance with the highest score as the target service instance. For example, although WeatherCompany instance A is a well-known brand, its current status shows high load and a score of 6.0; while HeFengWeather instance C is currently idle and responsive, with a score of 9.8, so the server will choose instance C. This step determines the target service instance at the tactical level.

[0183] S307. Based on the target service instance, determine multiple candidate service interfaces.

[0184] It should be noted that a service instance may provide multiple API interfaces. For example, a weather service instance may provide different interfaces such as querying real-time weather, querying weather forecasts, and querying historical weather. The server can match candidate service interfaces with matching functions from the interface list provided by the target service instance (such as HeFengWeather instance C) based on the query intent information (such as "query historical temperatures"). After determining the candidate service interfaces, the method in S203 can be used to determine the target service interface to obtain the target query data.

[0185] It should be noted that the first and second reinforcement learning models can be updated subsequently. For example, for the first reinforcement learning model, if the call is successful and fast, it indicates that choosing the "commercial weather data service" strategy is good, and a high reward will be given (increasing the first historical performance score of the target service type); if all instances under this type fail to make calls, a penalty will be given (reducing the first historical performance score of the target service type). For the second reinforcement learning model, rewards (increasing the second historical performance score corresponding to the current state of the target service instance) and penalties (reducing the second historical performance score corresponding to the current state of the target service instance) can be given based on the response time and success of the call.

[0186] Figure 3 The method shown in S301-S303 first performs screening at the strategic level, selecting based on the "first historical performance score" to determine the service type that is more reliable and economical in the long run. S304-S306 further utilizes the second historical performance score to select the optimal candidate service interface for the determined service type. Simultaneously, the reinforcement learning model update strategy used in S301-S303 and S304-S306 allows for continuous iterative optimization in long-term practical applications, selecting the optimal service type and service instance that best suits the actual production environment.

[0187] Figure 4 This is a schematic diagram of the chart generation device provided in the embodiments of this application, such as... Figure 4 As shown, the device 40 includes:

[0188] The response module 401 is used to, in response to a query instruction, obtain the target query data corresponding to the query intent information in the query instruction;

[0189] Extraction module 402 is used to extract feature information of target query data by a pre-trained deep learning model based on target query data;

[0190] The matching module 403 is used to determine the target type that matches the feature information and query intent information among several chart types according to preset rules. The preset rules are used to indicate the correspondence between the feature information, query intent information and chart types.

[0191] The generation module 404 is used to display a data chart of the target type on the target interactive interface based on the target query data.

[0192] Figure 5 This is a schematic diagram of the electronic device structure provided in the embodiments of this application, such as... Figure 5As shown, the device 50 includes at least one processor 501 and a memory 502. Optionally, the device 50 also includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0193] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0194] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0195] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0196] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0197] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0198] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0199] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0200] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0201] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0202] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

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

[0204] In addition, the functional units in the various embodiments of the present invention 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.

[0205] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part 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, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0206] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0207] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A chart generation method, characterized in that, The method includes: In response to a query command, the target query data corresponding to the query intent information in the query command is obtained. Based on the target query data, the feature information of the target query data is extracted by a pre-trained deep learning model; According to preset rules, among several chart types, a target type that matches the feature information and the query intent information is determined. The preset rules are used to indicate the correspondence between the feature information, the query intent information and the chart type. Based on the target query data, a data chart of the target type is displayed on the target interactive interface.

2. The method according to claim 1, characterized in that, The step of displaying a data chart of the target type on the target interactive interface based on the target query data includes: Obtain the chart configuration template corresponding to the target type; The target query data is populated into the chart configuration template to generate a chart configuration object; Based on the chart configuration object, generate chart rendering code; Execute the chart rendering code to display the data chart on the target interactive interface.

3. The method according to claim 2, characterized in that, The step of generating chart rendering code based on the chart configuration object includes: Obtain the code template corresponding to the chart configuration object; Insert the chart configuration object into the code template to generate the chart rendering code.

4. The method according to claim 1, characterized in that, The step of obtaining the target query data corresponding to the query intent information based on the query instruction includes: Based on the query intent information, multiple corresponding candidate service interfaces are determined; Obtain the current status information of each of the candidate service interfaces; The current state information is input into a pre-trained reinforcement learning model. The reinforcement learning model determines the target service interface from the candidate service interfaces based on the score value corresponding to each current state information. The target service interface has the highest score value. The score value is positively correlated with the calling performance of the candidate service interface. Call the target service interface to obtain the target query data.

5. The method according to claim 4, characterized in that, The step of determining multiple corresponding candidate service interfaces based on the query intent information includes: Based on the query intent information, multiple corresponding candidate service types are determined; Determine the first historical performance score for each of the candidate service types; Based on the first historical performance score, a target service type is determined from the candidate service types, wherein the target service type has the highest first historical performance score. Identify multiple candidate service instances corresponding to the target service type; Determine a second historical performance score for each of the candidate service instances; Based on the second historical performance score, a target service instance is determined from the candidate service instances, and the target service instance has the highest second historical performance score. Based on the target service instance, multiple candidate service interfaces are determined.

6. The method according to claim 1, characterized in that, Prior to responding to a query command, the method further includes: Obtain the user's query text; The query instruction is generated based on the query request text.

7. The method according to claim 6, characterized in that, The step of generating the query instruction based on the query request text includes: Extract multiple semantic units at different semantic levels from the query request text; The plurality of semantic units are matched with a preset knowledge graph, and named entities that match the semantic units are determined in the preset knowledge graph; Based on the named entities and the relationships between the named entities in the preset knowledge graph, the user's query intent is determined; The query instruction is generated based on the named entity and the query intent.

8. A chart generation device, characterized in that, The device includes: A response module is used to, in response to a query instruction, obtain the target query data corresponding to the query intent information in the query instruction; An extraction module is used to extract feature information of the target query data using a pre-trained deep learning model based on the target query data. The matching module is used to determine, according to preset rules, a target type that matches the feature information and the query intent information among several chart types, wherein the preset rules are used to indicate the correspondence between the feature information, the query intent information and the chart type; The generation module is used to display a data chart of the target type on the target interactive interface based on the target query data.

9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.

Images