Knowledge graph-based visual large screen generation method and device, equipment and medium

Abstract

The application discloses a knowledge graph-based visual large screen generation method and device, equipment and a medium. When receiving natural language requirement information, the natural language requirement information is subjected to requirement identification, and structured requirement description information is generated according to the identification result. The structured requirement description information is used to query an offline knowledge graph, and configuration-related information is determined. A configuration generator is called to generate a configuration file corresponding to the configuration-related information according to a preset layout style rule. A low-code rendering engine is called to render the configuration file, and a visual large screen is generated. Thus, the natural language is subjected to requirement identification, the generated structured requirement description information is used to query the offline knowledge graph, the corresponding chart and API are selected to generate the configuration file, and the visual large screen is rendered, so that the generation and display of the visual large screen are flexibly and accurately realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of visual large screen generation, and in particular to a visual large screen generation method and device based on a knowledge graph, equipment and a medium. BACKGROUND

[0002] With the deep penetration of digital transformation in various industries, enterprises have an increasingly urgent need for data-driven decision-making. Data visualization large screens, as the core carriers for integrating and displaying multidimensional business data, have been widely used in key scenarios such as operation monitoring, emergency command, and achievement reporting. Through intuitive charts and real-time data updates, they help decision-makers quickly capture business dynamics and identify potential problems, becoming an important support tool for enterprise digital operations.

[0003] Currently, two types of technical solutions are mainly used to build data visualization large screens in the industry: one is manual coding development, which requires combining front-end frameworks such as Vue and React with visualization libraries such as ECharts and D3.js to write code, and the technical threshold is high; the other is a low-code / zero-code platform (such as Ali Cloud DataV and Tableau), which builds by dragging and dropping components and configuring parameters, but the core steps such as component selection, data source binding, and layout design still require manual operation.

[0004] However, the above solutions have low automation, require manual operation in multiple steps, have a long delivery cycle, and are difficult to adapt to rapidly changing business needs. Meanwhile, low-code platforms still require users to have a basic understanding of data, chart selection, and API, making it difficult to generate visual large screens flexibly and accurately. SUMMARY

[0005] The present application provides a visual large screen generation method, device, equipment and medium based on a knowledge graph, which solves the technical problem that the existing solution has low automation, requires manual operation in multiple steps, has a long delivery cycle, and is difficult to adapt to rapidly changing business needs. Meanwhile, low-code platforms still require users to have a basic understanding of data, chart selection, and API, making it difficult to generate visual large screens flexibly and accurately.

[0006] The first aspect of the present application provides a visual large screen generation method based on a knowledge graph, comprising:

[0007] When receiving natural language requirement information, performing requirement identification on the natural language requirement information, and generating structured requirement description information according to the identification result;

[0008] Querying an offline knowledge graph according to the structured requirement description information to determine configuration-related information;

[0009] The configuration generator is invoked to generate a configuration file corresponding to the configuration-related information according to preset layout style rules;

[0010] The low-code rendering engine is invoked to render the configuration file to generate a visual large screen.

[0011] Optionally, the method further comprises:

[0012] In response to offline learning information, accessing a specified visual component library and API document;

[0013] Traversing the visual component library, extracting all component features of each visual component, and creating corresponding associated terms;

[0014] Creating a chart knowledge graph using all the associated terms;

[0015] Traversing the API document, extracting all API node information and response body structure information;

[0016] Generating an API knowledge graph according to the API node information and the response body structure information;

[0017] Combining the chart knowledge graph and the API knowledge graph to obtain an offline knowledge graph.

[0018] Optionally, the step of traversing the visual component library, extracting all component features of each visual component, and creating corresponding associated terms comprises:

[0019] Traversing the visual component library, extracting all component features of each visual component; the component features include chart type, data format, applicable scenario, and visual features;

[0020] Associating the applicable scenario, the chart type, the data format, and the visual features to create associated terms corresponding to the visual component.

[0021] Optionally, the step of generating an API knowledge graph according to the API node information and the response body structure information comprises:

[0022] Identifying the business meaning of each field information in the response body structure information, and establishing a field business mapping relationship;

[0023] Calculating the field semantic similarity between the field information;

[0024] According to the field semantic similarity, performing synonymous aggregation on each field information to determine a synonymous mapping relationship;

[0025] The API node information, the response body structure information, the field service mapping relationship and the synonymous mapping relationship are used to generate an API knowledge graph.

[0026] Optionally, when the natural language requirement information is received, the requirement identification is performed on the natural language requirement information, and the structured requirement description information is generated according to the identification result.

[0027] When the natural language requirement information is received, a large language model is called to identify the requirement intention of the natural language requirement information.

[0028] The corresponding named entity is extracted from the natural language requirement information according to the requirement intention by the large language model.

[0029] The structured requirement description information is generated according to the named entity and the requirement intention.

[0030] Optionally, the offline knowledge graph includes a graph knowledge graph and an API knowledge graph; and the step of querying the offline knowledge graph according to the structured requirement description information to determine the configuration related information includes:

[0031] According to the requirement scene, the requirement data format and the requirement visual information corresponding to the requirement intention, a recommended graph combination is determined from the graph knowledge graph.

[0032] The API knowledge graph is searched according to a plurality of preset matching dimensions by using the named entity to determine a corresponding recommended API list.

[0033] The mapping relationship between each API response field in the recommended API list and each graph component in the recommended graph combination is bound to generate configuration related information.

[0034] Optionally, the step of calling a low-code rendering engine to render the configuration file to generate a visual large screen includes:

[0035] The low-code rendering engine is called to load and parse the configuration file to determine a target API, to-be-rendered graph information and layout information.

[0036] A data request is sent to the target API.

[0037] A visual component library is called according to the to-be-rendered graph information to render a plurality of graph components.

[0038] In response to to-be-filled data returned by the target API, the to-be-filled data is filled into the graph components, and the graph components are spliced according to the layout information to generate a visual large screen.

[0039] The second aspect of the present application provides a knowledge graph-based visual large screen generation device, comprising:

[0040] A requirement identification module is configured to, when receiving natural language requirement information, perform requirement identification on the natural language requirement information, and generate structured requirement description information according to the identification result.

[0041] A configuration query module is configured to query an offline knowledge graph according to the structured requirement description information, and determine configuration-related information.

[0042] A configuration file generation module is configured to call a configuration generator to generate a configuration file corresponding to the configuration-related information according to a preset layout style rule.

[0043] A visual large screen rendering module is configured to call a low-code rendering engine to render the configuration file, and generate a visual large screen.

[0044] The third aspect of the present application provides an electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the computer program is executed by the processor to cause the processor to perform the steps of the knowledge graph-based visual large screen generation method according to any one of the first aspect of the present application.

[0045] The fourth aspect of the present application provides a computer-readable storage medium storing a computer program, wherein the computer program is executed to implement the knowledge graph-based visual large screen generation method according to any one of the first aspect of the present application.

[0046] As can be seen from the above technical solutions, the present application has the following advantages:

[0047] When receiving natural language requirement information, requirement identification is performed on the natural language requirement information, and structured requirement description information is generated according to the identification result. The offline knowledge graph is queried according to the structured requirement description information, and configuration-related information is determined. The configuration generator is called to generate a configuration file corresponding to the configuration-related information according to a preset layout style rule. The low-code rendering engine is called to render the configuration file, and a visual large screen is generated. Thus, by performing requirement identification on the natural language, the offline knowledge graph is queried with the generated structured requirement description information, the corresponding chart and API are selected to generate a configuration file and rendered into a visual large screen, and the generation and display of the visual large screen are flexibly and accurately realized. BRIEF DESCRIPTION OF DRAWINGS

[0048] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor.

[0049] Figure 1 A step flow chart of a knowledge graph-based visual large screen generation method provided by the embodiment of the present application is provided.

[0050] Figure 2 A step flow chart of a generation process of an offline knowledge graph provided by the embodiment of the present application is provided.

[0051] Figure 3 A schematic diagram of an API knowledge graph provided by the embodiment of the present application is provided.

[0052] Figure 4 A structural block diagram of a knowledge graph-based visual large screen generation device provided by the embodiment of the present application is provided. DETAILED DESCRIPTION

[0053] The embodiment of the present application provides a knowledge graph-based visual large screen generation method, device, equipment and medium, which is used to solve the technical problems that the existing scheme has low automation degree, needs to rely on manual operation of multiple links, has long delivery cycle, is difficult to adapt to rapidly changing business requirements, and the low-code platform still needs users to have data understanding, chart selection and API basis, and it is difficult to flexibly and accurately generate a visual large screen.

[0054] In order to make the purposes, features and advantages of the present application more obvious and easy to understand, the technical solutions in the embodiments of the present application will be described clearly and completely in combination with the drawings in the embodiments of the present application. Obviously, the embodiments described below are only some of the embodiments of the present application, not all. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0055] Please refer to Figure 1 , Figure 1 A step flow chart of a knowledge graph-based visual large screen generation method provided by the embodiment of the present application is provided.

[0056] The knowledge graph-based visual large screen generation method provided by the present application comprises:

[0057] Step 101, when receiving natural language requirement information, requirement recognition is performed on the natural language requirement information, and structured requirement description information is generated according to the recognition result;

[0058] The natural language requirement information refers to visual large-screen requirement description input by a user in daily language form, such as “show the comparison of sales performance in each region”, without following a specific format or technical term.

[0059] The structured requirement description information refers to description information converted into a standardized data format according to the results of intent recognition such as named entities and requirement intents, and the content of the description information includes but is not limited to elements such as a theme (such as sales), a core indicator (such as performance), a dimension (such as a region), an expected chart type hint (such as a comparison type), a filtering condition (such as a time range), and the like.

[0060] In the embodiment of the application, the method can be applied to terminal devices, clouds, or servers, and the like, which have data processing capabilities. After receiving natural language requirement information input by a user or sent by an upstream device, a preset large language model is called to perform requirement recognition on the natural language requirement information, requirement intents and named entities are recognized therefrom, and the elements are integrated according to a preset format to generate structured requirement description information containing complete business demands, thereby providing a standardized input for subsequent knowledge graph query.

[0061] In one example of the application, step 101 can include the following sub-steps:

[0062] When receiving natural language requirement information, a large language model is called to recognize the requirement intent of the natural language requirement information;

[0063] The corresponding named entities are extracted from the natural language requirement information according to the requirement intent by the large language model;

[0064] According to the named entities and the requirement intent, structured requirement description information is generated.

[0065] In the embodiment of the application, when receiving natural language requirement information, the large language model analyzes the requirement intent of the natural language requirement information through semantic analysis, removes redundant expressions (such as mood words and modifying words), mines the business analysis target that the user wants to achieve, performs directional scanning on the natural language requirement information based on the requirement intent, and extracts key information elements matching the intent. For example, if the intent is “compare the sales of each product in A year based on the region dimension”, the named entities such as “theme: product sales”, “core indicator: sales”, “analysis dimension: region and product type”, and “filtering condition: A year” are extracted from the requirement, and irrelevant information (such as operation guide words like “help make one”) is automatically filtered, so as to ensure that the extracted named entities accurately support the implementation of the requirement intent.

[0066] Finally, according to the preset format of the structured requirement description information, such as "subject: XXX; core index: XXX; analysis dimension: XXX; filter condition: XXX; chart type: XXX". The requirement intention is associated and integrated with the named entity, taking the requirement intention as the core framework, filling the named entity to the specified position in the format, and deriving the chart type such as column chart, line chart, etc. according to the requirement intention, to generate complete structured requirement description information.

[0067] In addition, a multi-round dialogue clarification mechanism can also be provided. When the natural language requirement information has ambiguity (such as not specifying the time range), a follow-up question (such as "Please tell me which time period of sales trend do you want to show?") can be automatically generated to further clarify the requirement and improve the structured requirement description information.

[0068] Step 102, querying the offline knowledge graph according to the structured requirement description information to determine the configuration related information;

[0069] The offline knowledge graph refers to at least two types of knowledge graph sets generated in the offline learning stage, including but not limited to chart knowledge graph and API knowledge graph. Among them, the chart knowledge graph stores the type, applicable scenario, data format requirement, and configurable visual information of the visualization component, and the API knowledge graph stores the API node, request method, parameter, response structure, field business meaning, and synonymous relationship.

[0070] The configuration related information refers to the core configuration data that meets the structured requirement, including the recommended chart combination, visual style, recommended API list, and mapping relationship between API response field and chart data format that need to be generated.

[0071] In the embodiment of the application, after obtaining the structured requirement description information, the structured requirement description information is used as a retrieval word to query the offline knowledge graph to select the recommended chart combination matching the structured requirement description information, and the adaptive API node and request parameter. At the same time, the mapping relationship between each API response field in the recommended API list and each chart component in the recommended chart combination is established to ensure that the API response field can be mapped and displayed as data in the chart component, thereby integrating to form complete configuration related information.

[0072] In an example of the application, the offline knowledge graph includes a chart knowledge graph and an API knowledge graph; step 102 can include the following sub-steps:

[0073] According to the requirement scene, requirement data format and requirement visual information corresponding to the requirement intention, determine the recommended chart combination from the chart knowledge graph;

[0074] The API knowledge graph is retrieved according to the naming entity and multiple preset matching dimensions, and a corresponding recommended API list is determined.

[0075] The mapping relationship between the API response fields in the recommended API list and the chart components in the recommended chart combination is bound, and configuration related information is generated.

[0076] In the embodiment of the application, the demand scene (such as “regional sales comparison”→“multi-dimensional comparison scene”) is disassembled from the demand intention, the demand data format (such as “regional field + sales field”→“[{name: region, value: sales}] array”) and the demand visual information (such as “reporting”→“light color system, clear legend”); then the three types of information are used as retrieval conditions to query the chart knowledge graph, and a multi-feature weighted scoring mechanism is called to calculate the comprehensive score of the candidate chart - wherein the scene matching degree (the matching degree of the demand scene and the applicable scene of the chart), the data format compatibility (the matching degree of the demand data format and the required data format of the chart), and the visual feature adaptability (the matching degree of the demand visual information and the configurable visual parameters of the chart) can account for 40%, 35% and 25% respectively, and finally at least one chart component with the highest comprehensive score is screened out, and the recommended chart combination is formed according to the logic combination of “core chart (with the highest score, such as column chart) + auxiliary chart (with the second highest score, such as digital card)”.

[0077] As for the recommended API list, the naming entity (such as core indicator: sales, analysis dimension: region, filter condition: A year) can be used as the retrieval keyword, and the API knowledge graph can be queried according to three types of preset matching dimensions. The matching dimensions can include semantic matching dimension, structural matching dimension and parameter matching dimension.

[0078] In the semantic matching dimension, the API containing the synonymous fields (such as sales_amount, region_name) of “sales” and “region” is retrieved through the field-belong-to-business concept relationship of the API knowledge graph.

[0079] In the structural matching dimension, it is verified whether the response body structure of the candidate API contains all the demand fields (such as containing region_name, sales_amount and sale_date at the same time).

[0080] In the parameter matching dimension, it is confirmed whether the API supports the request parameters corresponding to the filter conditions (such as containing start_date and end_date parameters to filter A year data).

[0081] Then, the API list is generated by calculating the comprehensive matching degree of the API matched by triple matching according to "semantic matching degree (50%) + structural integrity (30%) + parameter adaptability (20%)", and arranging the API list in descending order of score, so as to select the API endpoint with high field name semantic similarity, complete parameter support and best response structure matching degree.

[0082] Finally, the response fields of each API in the recommended API list are extracted (such as region_name, sales_amount and sale_date extracted from API1), and the mapping requirements of each chart component in the recommended chart combination are determined (such as the x-axis category field and y-axis numerical field required by the column chart, and the total sales field required by the digital card); then, based on the matching logic of the business meaning of the field (confirmed by the "field business mapping relationship" of the API knowledge graph) and the chart mapping requirement, the mapping relationship is established, for example, region_name is bound to the x-axis of the column chart, sales_amount is bound to the y-axis of the column chart and the "total sales" field of the digital card; if there is a multi-API cooperation scene (such as a chart requiring fields of two APIs), the multi-API response fields are integrated through field semantic association (such as date field alignment with time dimension); finally, the style parameters of the recommended chart combination (such as column chart color matching, digital card font), the request parameters of the recommended API (such as start_date=A0101 and end_date=A1231) and the above mapping relationship are integrated to generate complete configuration related information including chart configuration, API configuration and field mapping configuration.

[0083] Optionally, the newly added visualization component library (such as a newly added 3D chart component) and the API document can also be periodically scanned to automatically update the nodes and relationships of the chart knowledge graph and the API knowledge graph, so as to ensure the timeliness of the configuration related information. If a single API cannot meet the requirements (such as the need to simultaneously display sales and user numbers), multiple API knowledge graph nodes can be queried to integrate the field data of multiple APIs and generate composite configuration related information.

[0084] Please refer to Figure 2 In an example of the present application, for the generation process of the offline knowledge graph, the method further includes the following steps S11-S16:

[0085] S11, in response to offline learning information, access the specified visualization component library and API document;

[0086] In this embodiment, after receiving offline learning information input externally, the visualization component library specified by the information is accessed, such as ECharts and AntV, a connection with the component library is established to obtain component metadata and sample resources; meanwhile, a specified API document (Swagger / OpenAPI format) is accessed, and the description information of the API is read through a document parsing interface, thereby laying a data foundation for subsequent feature extraction and knowledge graph construction.

[0087] S12, traversing the visualization component library, extracting all component features of each visualization component, and creating corresponding associated entries;

[0088] In an example of the present application, S12 can include the following sub-steps:

[0089] Traversing the visualization component library, extracting all component features of each visualization component; the component features include chart type, data format, applicable scenario, and visual feature;

[0090] Associating the applicable scenario, chart type, data format, and visual feature, and creating associated entries corresponding to the visualization component.

[0091] In this embodiment, after accessing the visualization component library, through metadata analysis and computer vision technology, first, each component in the accessed ECharts, AntV, and other visualization component libraries is traversed, for a single component, the configuration schema thereof is analyzed through metadata analysis technology, the chart type (such as “line chart”) and data format (such as “two-dimensional array containing time series field and numerical field”) of the component are extracted; at the same time, the computer vision technology is used to analyze the component sample image, the applicable scenario (such as “time trend analysis”) adapted by the component is identified, and the configurable visual parameters (such as “color can be customized, support setting coordinate axis label font size, legend can be located above / right”) are read from the configuration schema to determine the visual feature; then the extracted chart type, data format, applicable scenario, and visual feature of the component are structured and integrated to create associated entries.

[0092] For example, for the column chart component, an exclusive associated entry of “chart type: column chart; data format: [{category field, numerical field}] array; applicable scenario: multi-category data comparison analysis; visual feature: support customizing column color, configurable coordinate axis title style, and optional legend position left / right” is created.

[0093] S13, creating a chart knowledge graph using all associated entries;

[0094] After obtaining the associated terms of all visualization components, a mapping between scenarios and corresponding chart types (such as a pie chart and a ring chart for the "proportion analysis" scenario) is established with the applicable scenario as the core associated dimension, and the data format and configurable visual parameters corresponding to each chart type are bound to form a chart knowledge graph containing component feature nodes (scenario nodes, chart type nodes, and data format nodes) and associated edges between the nodes, ensuring that the graph can be queried by subsequent modules to match the corresponding visualization components for the demand.

[0095] S14, traverse the API document to extract all API node information and response body structure information;

[0096] API node information refers to information extracted from the API document that describes the basic properties of the API interface, including but not limited to API nodes (Endpoints such as URLs), request methods (GET / POST, etc.), request parameters (such as the time range parameter start_date), etc.

[0097] Response body structure information refers to information extracted from the API document that describes the data structure of the API return data, including but not limited to response body structure (Response Schema), response field names (such as user_cnt and amount), field business descriptions (such as user_cnt representing "user count"), field data types (such as number and string), etc.

[0098] S15, generate an API knowledge graph according to the API node information and the response body structure information;

[0099] In one example of the present application, S15 can include the following sub-steps:

[0100] Identify the business meaning of each field information in the response body structure information and establish a field business mapping relationship;

[0101] Calculate the field semantic similarity between two fields;

[0102] Synonymically aggregate each field information according to the field semantic similarity to determine the synonym mapping relationship;

[0103] Generate an API knowledge graph using API node information, response body structure information, field business mapping relationships, and synonym mapping relationships.

[0104] In the embodiments of the present application, semantic analysis can be performed on each field and field annotation in the response body structure information by natural language processing (NLP) technology, and the corresponding business concept behind the field is identified, for example, by analyzing the field name composition of user_cnt (“user” means user and “cnt” means quantity) and the annotation (if there is a description of “user quantity statistics”), it is determined that the business meaning is “user number”; then a one-to-one correspondence relationship of “field information-business meaning” is established for each field information, that is, the field business mapping relationship, such as amount→“sales amount”, sale_date→“sales date”. The field name and field annotation text of all field information are input into a preset word vector model (such as a Word2Vec or BERT model trained based on business corpus), and the text is converted into a corresponding semantic vector; then for each two field information, the cosine distance (or other similarity measurement method) between the semantic vectors is calculated, and the calculation result is taken as the semantic similarity value of the two fields, for example, the semantic vector distance of “user number” corresponding to user_cnt and “user number” corresponding to user_number is calculated, and a similarity value close to 1 is obtained, and the semantic vector distance of “sales amount” corresponding to amount and “user ID” corresponding to user_id is calculated, and a similarity value close to 0 is obtained. All field information is traversed, and field information with a semantic similarity greater than or equal to a threshold value is classified into the same semantic group, and a business term synonym library is supplemented and aggregated (for example, field information that does not reach the threshold value but is in the synonym library is included in the corresponding semantic group); finally, a core business concept (such as “user number”) is determined for each semantic group, a synonymous mapping relationship of all field information in the group and the core business concept is established, for example, user_cnt→“user number”, user_number→“user number”, and a complete synonymous mapping relationship set is formed.The URL in the API node information, the request method as an attribute to build an API node (such as API1: [URL: " / api / v1 / users", method: "GET"]); the field name, data type in the response body structure information as an attribute to build a field node (such as user_cnt: [field name: "user_cnt", data type: "number"]); the business meaning in the field business mapping relationship as a business concept node (such as "user number" "sales"); then based on each relationship type, establish RDF triples between nodes: according to the association of API and field, establish "API-provide-field" triples (such as (API1, provide, user_cnt)), according to the field business mapping relationship, establish "field-belong-business concept" triples (such as (user_cnt, belong, user number)), according to the synonym mapping relationship, establish "business concept-synonym-business concept" triples (such as (user number, synonym, customer number)); finally, integrate all nodes and triples, generate a complete API knowledge graph, such as. Figure 3 As shown. Among them, the node type: API node: represents an API node, including attributes such as: URL, method (GET / POST, etc.), description. Field node: represents a field in the API response, including attributes such as: field name, data type, business description. Business concept node: represents the core concept of the business domain, such as "user", "order", "sales" and the like.

[0105] Edge type: "provide" edge: from API node to field node, indicating that the API returns the field. "Belongs to" edge: from field node to business concept node, indicating that the field belongs to a certain business concept. "Synonym" edge: connecting two business concept nodes, indicating that they have the same meaning.

[0106] Example: Suppose there are two APIs:

[0107] API1: GET / api / v1 / users, returns fields: user_id, user_name, registration_date

[0108] API2: GET / api / v1 / sales, returns fields: sale_id, amount, sale_date

[0109] Business concept: user, sales

[0110] Then the knowledge graph can be represented as:

[0111] 1) Node:

[0112] API1: [URL: " / api / v1 / users", method: "GET"]

[0113] API2: [URL: " / api / vl / sales", method: "GET"]

[0114] Fields: user_id, user_name, registration_date, sale_id, amount, sale_date

[0115] Business concepts: user, sales

[0116] 2) Edge:

[0117] API1 -> user_id, API1 -> user_name, API1 -> registration_date

[0118] API2 -> sale_id, API2 -> amount, API2 -> sale_date

[0119] user_id -> user, user_name -> user, registration_date -> user

[0120] sale_id -> sales, amount -> sales, sale_date -> sales

[0121] In this API knowledge graph, four core levels are shown: API service layer: the highest level of business service classification; API node layer: specific HTTP interface nodes; data field layer: specific data fields returned by API and their data types; business concept layer: business semantic concepts corresponding to fields; Key relationship types include the following: service contains node: an API service contains multiple nodes; node returns field: each node returns specific data fields; field mapping concept: data fields are mapped to business concepts; concept synonym relationship: different terms represent the same business concept.

[0122] In addition, if "user" and "customer" are synonyms, there can be a synonym edge connecting "user" and "customer". In this way, when the user requirement contains "user", all fields related to the user can be found through the "belongs to" edge, and then the API that provides these fields can be found through the "provides" edge.

[0123] S16, combine the graph knowledge graph and the API knowledge graph to obtain an offline knowledge graph.

[0124] In the embodiment of the present application, the association between the component data format requirement (such as time series data format required by a line chart) in the chart knowledge graph and the field data type and structure (such as API response containing date field and value field) in the API knowledge graph is established with data adaptation as the core association dimension, while the original nodes and association edges of the two types of graphs (such as the scene-chart type association of the chart knowledge graph and the field-business concept association of the API knowledge graph) are retained, and finally an offline knowledge graph capable of providing component adaptation and API adaptation capabilities is formed.

[0125] In step 103, the configuration generator generates a configuration file corresponding to the configuration related information according to the preset layout style rules.

[0126] The configuration generator refers to a configuration code / DSL generator, which is a tool module for converting configuration related information into a standardized configuration file.

[0127] The layout style rules refer to a set of preset rules followed when generating the configuration file, including layout rules (adopting grid layout, allocating space according to chart importance weight, key indicator chart occupying more grid cells; sorting charts according to the logic of “overall→local” and “cause→effect”), responsive rules (automatically adjusting grid division according to the number of charts and target screen size), and style rules (generating color matching schemes based on enterprise VI color or semantic color theory, such as using blue for technology scenarios and green for growth indicators; setting font size levels for titles, labels, and values according to chart importance; generating corresponding background styles according to usage scenarios “command center / reporting display”).

[0128] The configuration file refers to the full-quantity configuration data of a visual large screen stored in JSON or YAML format, including overall layout (grid position and size of each chart), component configuration (chart type, API data source address and parameters, data mapping relationship, visual style), and global style (large screen theme, background, font) files.

[0129] In the embodiment of the present application, by inputting configuration related information into the configuration generator, the configuration generator performs configuration file generation operations according to preset layout style rules. The grid layout structure of the large screen can be defined in the configuration file according to the layout rules and responsive rules, the grid position and size of each chart are allocated according to the importance weight of the chart, and the chart position is sorted according to the logic of “overall→local”. Secondly, according to the component configuration related information, the type, API data source address and request parameters, and the mapping relationship between API fields and chart data of each chart are written in the file. Finally, according to the style rules, the global theme color, background style, and font level are configured, and finally a complete JSON or YAML format configuration file is generated.

[0130] In addition, a personalized layout template can be preset, such as a primary and secondary layout of a large chart on the left and a small index card on the right, and templates of different styles. Interaction rules (such as clicking a quarterly data of a chart to pop up a detail pop-up window, and dragging a chart to adjust the position) can be added in the configuration file, and the engine synchronously implements these interaction functions during rendering, thereby improving the operation flexibility of the large screen.

[0131] In step 104, a low-code rendering engine is called to render the configuration file, and a visual large screen is generated.

[0132] The low-code rendering engine refers to a rendering engine that does not require manual programming of a large amount of front-end code, and is used to load a configuration file, initiate a data request, dynamically render chart components, and finally generate a visual large screen.

[0133] The visual large screen refers to a final display interface that contains all required chart components, complete data content, and layout and style that meet preset rules, and can be used in business reporting, command monitoring and other scenarios.

[0134] In the embodiment of the application, after the configuration file is obtained, the target API, the to-be-rendered chart information and the layout information in the file are loaded and parsed, an HTTP request is initiated to the corresponding target API according to the API data source address and the request parameter in the component configuration, after the to-be-filled data returned by the target API is returned, the data is bound to the corresponding chart component according to the mapping relationship between the API field and the chart data defined in the configuration file, finally, the engine applies the global style (such as a blue theme, a light gray background and font hierarchy), renders all chart components according to the configured grid layout, generates a visual large screen with accurate data, reasonable layout and unified style, and displays the visual large screen.

[0135] In one example of the application, step 104 can include the following sub-steps:

[0136] The low-code rendering engine is called to load the configuration file and parse it to determine the target API, the to-be-rendered chart information and the layout information;

[0137] The data request is sent to the target API;

[0138] The visual component library is called according to the to-be-rendered chart information to render multiple chart components;

[0139] The to-be-filled data returned by the target API is filled into the chart components, and the chart components are spliced according to the layout information to generate a visual large screen.

[0140] In the embodiment, the low-code rendering engine first loads and parses the configuration file (in JSON or YAML format), extracts the address of the target API, the request method and parameters, the chart information to be rendered (including chart types such as column chart and line chart, visual style parameters of each chart such as color matching and font, and data mapping rules), and layout information (grid position, size, and arrangement logic of each chart); then initiates an HTTP data request according to the target API information; at the same time, calls the corresponding components of the visualization component library (such as ECharts and AntV) according to the chart information to be rendered, initializes the basic framework of multiple chart components; when receiving the data to be filled returned by the target API, binds the data to the corresponding fields of each chart component according to the data mapping rules (such as filling the region field data to the x-axis of the column chart and the sales field data to the y-axis), and finally splices all chart components with filled data in the canvas according to the layout information, to generate a visualization large screen with reasonable layout, complete data, and unified style.

[0141] In addition, the low-code rendering engine can also identify the resolution of the target display terminal (such as PC, large screen display, and mobile terminal), automatically adjust the layout and component size in the configuration file, and ensure that the visualization large screen can be normally displayed on different terminals.

[0142] In the embodiment, when receiving the natural language requirement information, the requirement identification is performed on the natural language requirement information, and the structured requirement description information is generated according to the identification result; the configuration related information is determined by querying the offline knowledge graph according to the structured requirement description information; the configuration generator is called to generate the configuration file corresponding to the configuration related information according to the preset layout style rule; and the low-code rendering engine is called to render the configuration file to generate the visualization large screen. Thus, the requirement identification is performed on the natural language, the offline knowledge graph is queried by using the generated structured requirement description information, the corresponding chart and API are selected to generate the configuration file, and the visualization large screen is rendered, so that the generation and display of the visualization large screen are flexibly and accurately realized.

[0143] Please refer to Figure 4 , Figure 4 The structure block diagram of the visualization large screen generation device based on the knowledge graph in the embodiment is shown.

[0144] The visualization large screen generation device based on the knowledge graph provided in the embodiment comprises:

[0145] The requirement identification module 401 is configured to perform requirement identification on the natural language requirement information when receiving the natural language requirement information, and generate structured requirement description information according to the identification result.

[0146] The configuration query module 402 is configured to query the offline knowledge graph according to the structured requirement description information, and determine configuration related information.

[0147] The configuration file generation module 403 is configured to call a configuration generator to generate a configuration file corresponding to the configuration related information according to a preset layout style rule.

[0148] The visual large-screen rendering module 404 is configured to call a low-code rendering engine to render the configuration file, and generate a visual large screen.

[0149] Optionally, the apparatus further comprises:

[0150] The offline access module is configured to access a specified visual component library and API document in response to offline learning information.

[0151] The associated term generation module is configured to traverse the visual component library, extract all component features of each visual component, and create corresponding associated terms.

[0152] The chart knowledge graph generation module is configured to create a chart knowledge graph using all associated terms.

[0153] The API information extraction module is configured to traverse the API document, and extract all API node information and response body structure information.

[0154] The API knowledge graph generation module is configured to generate an API knowledge graph according to the API node information and the response body structure information.

[0155] The offline knowledge graph generation module is configured to combine the chart knowledge graph and the API knowledge graph to obtain an offline knowledge graph.

[0156] Optionally, the associated term generation module is specifically configured to:

[0157] traverse the visual component library, and extract all component features of each visual component; the component features include chart type, data format, applicable scenario, and visual feature;

[0158] associate the applicable scenario, the chart type, the data format, and the visual feature, and create associated terms corresponding to the visual component.

[0159] Optionally, the API knowledge graph generation module is specifically configured to:

[0160] identify business meanings corresponding to field information in the response body structure information, and establish a field business mapping relationship;

[0161] calculate field semantic similarity between the field information;

[0162] perform synonymous aggregation on the field information according to the field semantic similarity, and determine a synonymous mapping relationship.

[0163] The API node information, response body structure information, field service mapping relationship and synonymous mapping relationship are used to generate an API knowledge graph.

[0164] Optionally, the requirement identification module 401 is specifically configured to:

[0165] When receiving the natural language requirement information, calling a large language model to identify a requirement intention of the natural language requirement information;

[0166] According to the requirement intention, the large language model extracts corresponding named entities from the natural language requirement information;

[0167] According to the named entities and the requirement intention, structured requirement description information is generated.

[0168] Optionally, the offline knowledge graph includes a graph knowledge graph and an API knowledge graph; the configuration query module 402 is specifically configured to:

[0169] According to a requirement scene, requirement data format and requirement visual information corresponding to the requirement intention, a recommended graph combination is determined from the graph knowledge graph;

[0170] According to the named entities, the API knowledge graph is searched according to multiple preset matching dimensions to determine a corresponding recommended API list;

[0171] The mapping relationship between each API response field in the recommended API list and each graph component in the recommended graph combination is bound to generate configuration related information.

[0172] Optionally, the visual large-screen rendering module 404 is specifically configured to:

[0173] Calling a low-code rendering engine to load and parse a configuration file to determine a target API, to-be-rendered graph information and layout information;

[0174] Sending a data request to the target API;

[0175] According to the to-be-rendered graph information, a visual component library is called to render multiple graph components;

[0176] According to the to-be-rendered graph information, a visual component library is called to render multiple graph components;

[0177] An electronic device is provided in the embodiment of the application, which includes a memory and a processor, the memory stores a computer program, and the computer program is executed by the processor to make the processor execute the steps of the knowledge graph-based visual large-screen generation method according to any embodiment of the application.

[0178] The embodiment of the present application provides a computer readable storage medium, which stores a computer program, and the computer program is executed to realize the knowledge graph-based visual large screen generation method.

[0179] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the above-described device and module can refer to the corresponding process in the foregoing method embodiment, and will not be repeated here.

[0180] In several embodiments provided by the present application, it should be understood that the disclosed device and method can be implemented by other manners. For example, the device embodiment described above is only schematic, for example, the division of the module is only a logical function division, and actual implementation can have another division manner, for example, a plurality of modules or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed each other can be through some interface, indirect coupling or communication connection between the device or module, and can be electrical, mechanical or other forms.

[0181] The module described as a separate component can be or can not be physically separated, and the component displayed as a module can be or can not be a physical module, that is, can be located in one place, or can be distributed to a plurality of network modules. According to actual needs, part or all of the modules can be selected to achieve the purpose of the embodiment scheme.

[0182] In addition, each functional module in each embodiment of the present application can be integrated in a processing module, or each module can exist physically, or two or more modules can be integrated in one module. The integrated module can be realized in the form of hardware or in the form of a software functional module.

[0183] The integrated module, if implemented in the form of a software function module and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application essentially or the part that contributes to the prior art, or all or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes several instructions to make an electronic device (which can be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the method described in various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.

[0184] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacements for some technical features; and these modifications or replacements do not make the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A knowledge graph-based visual large screen generation method, characterized in that, The method comprises the steps of: when receiving natural language requirement information, performing requirement identification on the natural language requirement information, and generating structured requirement description information according to the identification result; querying an offline knowledge graph according to the structured requirement description information to determine configuration-related information; calling a configuration generator to generate a configuration file corresponding to the configuration-related information according to a preset layout style rule; calling a low-code rendering engine to render the configuration file to generate a visual large screen; the structured requirement description information comprises a named entity and a requirement intention, and the offline knowledge graph comprises a chart knowledge graph and an API knowledge graph; the step of querying the offline knowledge graph according to the structured requirement description information to determine configuration-related information comprises: querying the chart knowledge graph according to a requirement scene, a requirement data format and requirement visual information corresponding to the requirement intention, and determining a recommended chart combination according to a highest weighted comprehensive score of the query result; retrieving the API knowledge graph according to a plurality of preset matching dimensions of the named entity, and determining a recommended API list according to a highest weighted comprehensive matching degree of the matching dimensions of the retrieval result; binding a mapping relationship between API response fields in the recommended API list and chart components in the recommended chart combination to generate configuration-related information.

2. The method of claim 1, wherein, The method further comprises: in response to offline learning information, accessing a specified visual component library and API document; traversing the visual component library to extract all component features of each visual component and create corresponding associated terms; creating a chart knowledge graph using all the associated terms; traversing the API document to extract all API node information and response body structure information; generating an API knowledge graph according to the API node information and the response body structure information; combining the chart knowledge graph and the API knowledge graph to obtain an offline knowledge graph.

3. The method of claim 2, wherein, The step of traversing the visual component library to extract all component features of each visual component and create corresponding associated terms comprises: traversing the visual component library to extract all component features of each visual component; the component features comprise a chart type, a data format, an applicable scene and a visual feature; associating the applicable scene, the chart type, the data format and the visual feature to create associated terms corresponding to the visual component.

4. The method of claim 2, wherein, The step of generating an API knowledge graph according to the API node information and the response body structure information comprises: identifying the business meaning of each field information in the response body structure information to establish a field business mapping relationship; calculating the field semantic similarity between the field information; performing synonymous aggregation on the field information according to the field semantic similarity to determine a synonymous mapping relationship; generating an API knowledge graph using the API node information, the response body structure information, the field business mapping relationship and the synonymous mapping relationship.

5. The method of claim 1, wherein, The step of, when receiving natural language requirement information, performing requirement identification on the natural language requirement information, and generating structured requirement description information according to the identification result comprises: When receiving the natural language requirement information, a large language model is invoked to identify a requirement intention of the natural language requirement information; The large language model is used to extract a corresponding named entity from the natural language requirement information according to the requirement intention; A structured requirement description information is generated according to the named entity and the requirement intention.

6. The method of claim 1, wherein, The step of invoking the low-code rendering engine to render the configuration file to generate the visual large screen comprises: The low-code rendering engine is invoked to load and parse the configuration file, determine a target API, to-be-rendered chart information and layout information; A data request is sent to the target API; A visual component library is invoked according to the to-be-rendered chart information to render multiple chart components; The to-be-filled data returned by the target API is filled into the chart components, and the chart components are spliced according to the layout information to generate the visual large screen.

7. A knowledge graph-based visual large screen generation device, characterized in that, Comprise: A requirement identification module is configured to identify requirements of natural language requirement information when the natural language requirement information is received, and generate structured requirement description information according to the identification result; A configuration query module is configured to query an offline knowledge graph according to the structured requirement description information to determine configuration-related information; A configuration file generation module is configured to invoke a configuration generator to generate a configuration file corresponding to the configuration-related information according to a preset layout style rule; A visual large screen rendering module is configured to invoke a low-code rendering engine to render the configuration file to generate a visual large screen; The structured requirement description information comprises a named entity and a requirement intention, and the offline knowledge graph comprises a chart knowledge graph and an API knowledge graph; the configuration query module is specifically configured to: Query the chart knowledge graph according to a requirement scene, a requirement data format and requirement visual information corresponding to the requirement intention, and determine a recommended chart combination according to a highest weighted comprehensive score of a query result; Use the named entity to retrieve the API knowledge graph according to multiple preset matching dimensions, and determine a recommended API list according to a highest weighted comprehensive matching degree of a retrieval result according to the matching dimensions; Bind a mapping relationship between API response fields in the recommended API list and chart component in the recommended chart combination to generate configuration-related information.

8. An electronic device, comprising: The computer program is executed to implement the knowledge graph-based visual large screen generation method according to any one of claims 1-6.

9. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed to implement the knowledge graph-based visual large screen generation method according to any one of claims 1-6.

Images