Large model-based coal preparation plant data query method, apparatus and device, and medium

Abstract

The invention relates to a coal preparation plant data query method, device and equipment based on a large model and a medium, and is applied to the technical field of data query and processing. Determining candidate APIs and semantic scores corresponding to the candidate APIs based on the user query information and an API semantic index database; analyzing the user query information, the candidate APIs and the semantic score based on a preset large model, and determining an optimal API, a query type and a query parameter; determining result data based on the query parameters and the optimal API; mapping the result data into standard structure data based on the query type; and generating a visualization result based on the standard structure data. The method has the effects of improving the real-time performance and accuracy of data processing and reducing the system maintenance cost.

Description

Data query methods, devices, equipment, and media for coal preparation plants based on large models Technical Field

[0001] This application relates to the technical field of data query and processing, and in particular to a method, apparatus, equipment and medium for data query in coal preparation plants based on a large model. Background Technology

[0002] In coal preparation plants and similar industrial settings, data integration and visualization are crucial for production management and decision analysis. With the development of industrial informatization, the scale and complexity of data are constantly increasing, making the effective collection, processing, and presentation of data key factors in improving production efficiency and quality. Data integration and visualization technologies help enterprises monitor production status in real time, promptly identify problems, and make adjustments, thereby improving production stability and economic benefits. Simultaneously, accurate data analysis and intuitive visualization also help enterprises control costs and optimize production processes.

[0003] Currently, to achieve data integration and visualization in coal preparation plants or similar industrial scenarios, data integration and visualization systems such as iFIX, KingSCADA, SCADA+BI visualization systems, and plant-level MES data platform solutions are commonly used. These traditional systems generally implement their functions through the following architecture: a data acquisition module acquires data based on underlying protocols or drivers; a data integration module performs format conversion and synchronization of data from different sources; a database / data warehouse module centrally stores the cleaned data; an analysis engine executes predefined indicator calculations or rule-based alarm logic; and a visualization terminal displays the data through front-end components or an HMI interface. This primarily involves collecting real-time and historical data from different systems via OPC or database gateways, using ETL tools for data cleaning, aggregation, and storage, and then displaying real-time trends, alarm information, and reports through a web interface or client-side dashboard.

[0004] However, current data integration and visualization systems have significant drawbacks. They are complex to integrate, have poor scalability, require customized drivers and adapters for different protocols or systems, have high maintenance costs, and are difficult to quickly integrate with new systems or third-party interfaces. Furthermore, they lack semantic layer and intelligent retrieval capabilities, preventing users from directly obtaining analysis results through natural language queries. They also cannot perform cross-system collaborative analysis, resulting in severe data fragmentation between systems. Summary of the Invention

[0005] To improve the real-time performance and accuracy of data processing and reduce system maintenance costs, this application provides a method, apparatus, equipment, and medium for querying coal preparation plant data based on a large model.

[0006] Firstly, this application provides a method for querying coal preparation plant data based on a large model, employing the following technical solution: A method for querying coal preparation plant data based on a large model includes: obtaining user query information of the current user; determining candidate APIs and semantic scores corresponding to each candidate API based on the user query information and an API semantic index library; analyzing the user query information, the candidate APIs, and the semantic scores based on a preset large model to determine the optimal API, query type, and query parameters; determining result data based on the query parameters and the optimal API; mapping the result data to standard structure data based on the query type; and generating visualization results based on the standard structure data.

[0007] By adopting the above technical solution, candidate APIs and their corresponding semantic scores can be quickly determined by analyzing user query information and API semantic index. The optimal API, query type, and query parameters can be quickly determined by pre-setting a large model, thereby enabling rapid API calls to determine the result data. That is, this application adopts an indirect API call mode of "semantic drive + unified proxy", which is based on standardized OpenAPI interfaces and software layer collaboration throughout the process, without directly contacting the underlying hardware protocol. This can solve the problems of complex integration, poor scalability, and lack of semantic layer and intelligent retrieval capabilities in current coal preparation plant data integration systems. Users can directly obtain analysis results by inputting user query information, realizing more flexible, intelligent, and efficient data query and visualization, improving the real-time performance and accuracy of data processing, and reducing system maintenance costs.

[0008] Optionally, before determining candidate APIs and their corresponding semantic scores based on the user query information and the API semantic index library, the method further includes: obtaining OpenAPI documents; embedding the OpenAPI documents into vectors using a vector embedding model; and constructing the API semantic index library based on each of the vectors.

[0009] By adopting the above technical solution, OpenAPI documents are obtained and embedded as vectors to build an API semantic index library. This enables the analysis of corresponding APIs through natural language queries, solving the problem of traditional systems lacking semantic layer and intelligent retrieval capabilities, reducing integration complexity, improving system scalability, and facilitating rapid access to new systems or third-party interfaces.

[0010] Optionally, determining candidate APIs and their corresponding semantic scores based on the user query information and the API semantic index library includes: converting the user query information into an initial vector based on a preset semantic vector model; searching a vector library of indicator calculation methods based on the initial vector to determine the indicators, time dimension, and indicator calculation methods in the user query information; concatenating the indicators, time dimension, indicator calculation methods, and user query information; converting the concatenated content into a user query vector based on a vector embedding model; calculating the semantic score of each vector in the API semantic index library based on a cosine similarity calculation method and the user query vector; obtaining the number of candidate APIs; determining the number of vectors with the highest semantic scores as candidate vectors; and determining the OpenAPI corresponding to the candidate vectors as the candidate APIs.

[0011] By adopting the above technical solution, user query information is converted into an initial vector through a preset semantic vector model. This allows for further retrieval of the indicator calculation method vector library to determine the indicators, time dimensions, and indicator calculation methods in the user query information. Subsequently, the user query information is combined and concatenated to convert it into a user query vector. This facilitates the calculation of semantic scores using cosine similarity and the selection of candidate APIs with higher semantic scores. This solves the problem of traditional systems lacking semantic layer and intelligent retrieval capabilities, allowing users to obtain analysis results through natural language queries, thus improving the accuracy and intelligence of the query.

[0012] Optionally, the step of analyzing the user query information, the candidate APIs, and the semantic score based on a preset large model to determine the optimal API, query type, and query parameters includes: analyzing the user query information, the candidate APIs, and the semantic score based on the preset large model to determine the optimal API; determining the parameter type to be transmitted based on the OpenAPI documentation of the optimal API; determining the query parameters of the parameter type to be transmitted based on the user query information; and analyzing the user query information based on the preset large model to determine the query type.

[0013] Optionally, determining the result data based on the query parameters and the optimal API includes: obtaining the rate limiting policy and current call status of the optimal API; determining whether the optimal API is in a rate-limited state based on the rate limiting policy and the current call status; determining whether the current user has access to the optimal API based on the data permission policy; if the optimal API is not in a rate-limited state and the current user has the access permission, then obtaining returned data from the optimal API based on the query parameters; and determining the result data based on the returned data.

[0014] By adopting the above technical solution, before calling the optimal API interface to obtain data, it is first determined whether the optimal API is currently in a rate-limited state, which can improve the stability of interface calls, verify user access permissions, and improve the security of data access.

[0015] Optionally, determining the result data based on the returned data includes: if the returned data is not indicator data, calculating the result data based on the indicator calculation method and the returned data; if the returned data has missing data, obtaining data supplementation rules; and supplementing the result data based on the data supplementation rules to obtain the final result data.

[0016] By adopting the above technical solution and completing the missing data, the completeness of the data obtained by users is improved, thereby increasing user satisfaction.

[0017] Optionally, mapping the result data to standard structured data based on the query type includes: determining a data structure based on the query type; and mapping the result data to the standard structured data based on the data structure.

[0018] By adopting the above technical solution and setting different data structures for different query types, the intuitiveness of subsequent visualization can be improved, making it easier for users to quickly obtain the information they want to query based on the visualization results.

[0019] Secondly, this application provides a coal preparation plant data query device based on a large model, employing the following technical solution: A coal preparation plant data query device based on a large model includes: a query information acquisition module, used to acquire the user query information of the current user; a candidate API determination module, used to determine candidate APIs and semantic scores corresponding to each candidate API based on the user query information and an API semantic index library; an optimal API determination module, used to analyze the user query information, the candidate APIs, and the semantic scores based on a preset large model to determine the optimal API, query type, and query parameters; a result data determination module, used to determine result data based on the query parameters and the optimal API; a standard structure mapping module, used to map the result data into standard structure data based on the query type; and a visualization result generation module, used to generate visualization results based on the standard structure data.

[0020] By adopting the above technical solution, candidate APIs and their corresponding semantic scores can be quickly determined by analyzing user query information and API semantic index. The optimal API, query type, and query parameters can be quickly determined by pre-setting a large model, thereby enabling rapid API calls to determine the result data. That is, this application adopts an indirect API call mode of "semantic drive + unified proxy", which is based on standardized OpenAPI interfaces and software layer collaboration throughout the process, without directly contacting the underlying hardware protocol. This can solve the problems of complex integration, poor scalability, and lack of semantic layer and intelligent retrieval capabilities in current coal preparation plant data integration systems. Users can directly obtain analysis results by inputting user query information, realizing more flexible, intelligent, and efficient data query and visualization, improving the real-time performance and accuracy of data processing, and reducing system maintenance costs.

[0021] Thirdly, this application provides an electronic device that adopts the following technical solution: an electronic device including a processor coupled to a memory; the memory storing a computer program that can be loaded by the processor and executed by the processor to perform the coal preparation plant data query method based on a large model as described in any of the first aspects.

[0022] Fourthly, this application provides a computer-readable storage medium, which adopts the following technical solution: a computer-readable storage medium storing a computer program that can be loaded by a processor and executed by the coal preparation plant data query method based on a large model as described in any one of the first aspects.

[0023] In summary, this application includes at least the following beneficial technical effects: by analyzing user query information and the API semantic index, candidate APIs and their corresponding semantic scores can be quickly determined; by pre-setting a large model, the optimal API, query type, and query parameters can be quickly determined, thereby enabling rapid API calls to determine the result data. That is, this application adopts an indirect API call mode of "semantic drive + unified proxy," based entirely on standardized OpenAPI interfaces and software layer collaboration, without directly contacting the underlying hardware protocols. This can solve the problems of complex integration, poor scalability, and lack of semantic layer and intelligent retrieval capabilities in current coal preparation plant data integration systems. It allows users to directly obtain analysis results by inputting user query information, achieving more flexible, intelligent, and efficient data query and visualization, improving the real-time performance and accuracy of data processing, and reducing system maintenance costs. Attached Figure Description

[0024] Figure 1 is a flowchart illustrating a method for querying coal preparation plant data based on a large model, as provided in an embodiment of this application.

[0025] Figure 2 is a structural block diagram of a coal preparation plant data query device based on a large model provided in an embodiment of this application.

[0026] Figure 3 is a structural block diagram of the electronic device provided in an embodiment of this application. Detailed Implementation

[0027] The present application will be further described in detail below with reference to the accompanying drawings.

[0028] This application provides a method for querying coal preparation plant data based on a large model. This method can be executed by an electronic device, which can be a server or a terminal device. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. The terminal device can be a smartphone, tablet computer, desktop computer, etc., but is not limited to these.

[0029] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0030] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article, unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0031] As shown in Figure 1, a data query method for coal preparation plants based on a large model is described in the following main process (steps S101 to S106): Step S101: Obtain the user query information of the current user.

[0032] The system receives user query information input by the current user through a human-computer interaction interface. This interface can be a webpage, a mobile application, etc. For example, on a webpage, the current user can enter their desired query, such as "view last month's coal-to-electricity consumption," into the input box.

[0033] Step S102: Based on user query information and the API semantic index, determine the candidate APIs and the semantic scores corresponding to each candidate API.

[0034] Specifically, before determining candidate APIs and their corresponding semantic scores based on user query information and the API semantic index library, the method also includes: obtaining OpenAPI documents; embedding the OpenAPI documents into vectors using a vector embedding model; and constructing an API semantic index library based on the vectors.

[0035] In this embodiment, OpenAPI documents provided by various systems are obtained from the official websites or development documentation of various data sources. The OpenAPI documents are written in JSON or YAML format and describe the interface path, methods, parameter descriptions, and return structures. The OpenAPI documents are embedded into vectors using vector embedding models (e.g., bge-m3, bge-large-v1.5, etc.). The vectors corresponding to each OpenAPI document are stored in a vector library to obtain a constructed API semantic index library, which supports cosine similarity retrieval.

[0036] Furthermore, based on user query information and the API semantic index library, candidate APIs and their corresponding semantic scores are determined, including: converting user query information into initial vectors based on a preset semantic vector model; searching the indicator calculation method vector library based on the initial vectors to determine the indicators, time dimension, and indicator calculation methods in the user query information; concatenating the indicators, time dimension, indicator calculation methods, and user query information; converting the concatenated content into user query vectors based on a vector embedding model; calculating the semantic scores of each vector in the API semantic index library based on the cosine similarity calculation method and the user query vectors; obtaining the number of candidate APIs; determining the number of vectors with the highest semantic scores as candidate vectors; and determining the OpenAPI corresponding to the candidate vectors as candidate APIs.

[0037] In this embodiment, the preset semantic vector model is a vector model that has been fine-tuned based on the dataset of the coal preparation plant scenario, such as a fine-tuned BERT model. Since there is often a large gap between the query content input by the user and the standard indicators, if the user query information is directly vectorized through the vector embedding model, it is difficult to directly search for the corresponding indicator in the indicator calculation method vector library based on the obtained vector (for example, the user queries the amount of anion, but the actual corresponding indicator is the consumption of reagents). The vector model fine-tuned based on the coal preparation plant scenario can standardize the user query information. Inputting the user query information into the preset semantic vector model for vectorization to obtain the initial vector can make the initial vector more standardized.

[0038] The indicator calculation method vector library stores indicator vectors for multiple coal preparation plant scenarios. Each indicator vector includes an indicator for a coal preparation plant scenario (e.g., electricity consumption per ton of coal), the corresponding time dimension (e.g., month), and the indicator calculation method (e.g., electricity consumption per ton of coal = electricity consumption / raw coal output). The cosine similarity between the initial vector and each indicator vector in the indicator calculation method vector library is calculated. The indicator vector with the highest cosine similarity is determined as the target indicator vector. The indicator, time dimension, and indicator calculation method corresponding to the target indicator vector are determined as the indicator, time dimension, and indicator calculation method in the user query information. Then, the indicator, time dimension, indicator calculation method, and user query information are concatenated into a sentence. Since this sentence includes the standard indicator, time dimension, and indicator calculation method for the coal preparation plant scenario, the original vector embedding model (similar to the vector model used to embed the OpenAPI document as a vector) can be directly used to embed the concatenated sentence into the user query vector, without the need to use the fine-tuned preset semantic vector model.

[0039] Then, the cosine similarity between the user query vector and each vector in the API semantic index is calculated using the cosine similarity calculation method. The semantic score of each vector is determined based on the cosine similarity and the preset similarity score association, which is the association between the cosine similarity and the semantic score. The number of candidate APIs is obtained from the staff, and the number of candidate APIs is pre-configured by the staff according to the hardware configuration or user needs. The number of candidate APIs with the highest semantic scores are determined as candidate vectors. The OpenAPI corresponding to the candidate vectors is determined as candidate APIs.

[0040] Step S103: Analyze user query information, candidate APIs, and semantic scores based on the preset large model to determine the optimal API, query type, and query parameters.

[0041] Specifically, based on a pre-defined large model, user query information, candidate APIs, and semantic scores are analyzed to determine the optimal API, query type, and query parameters. This includes: analyzing user query information, candidate APIs, and semantic scores based on a pre-defined large model to determine the optimal API; determining the parameter types to be transmitted based on the OpenAPI documentation of the optimal API; determining the query parameters for the parameter types to be transmitted based on user query information; and analyzing user query information based on a pre-defined large model to determine the query type.

[0042] In this embodiment, user query information, candidate APIs, and semantic scores are input into a preset large model for analysis. The preset large model can select the optimal API. If the indicator needs to be calculated using multiple data types, there can be multiple optimal APIs. For example, if the user query is "view the electricity consumption per ton of coal last month", the indicator is electricity consumption per ton of coal, the time dimension is month, and the indicator calculation method is: electricity consumption per ton of coal = electricity consumption / raw coal production, then the optimal APIs include "query the consumption data interface for a specified month" and "query the amount of raw coal washed in a specified month".

[0043] The preset large model is a large model pre-trained based on the coal preparation plant dataset. Large models include, for example, the GPT series large models, the DeepSeek large models, etc. There are no specific limitations here. The preset large model can accurately analyze user query information, determine the user's query intent, and thus select the optimal API.

[0044] After selecting the optimal API, the large model will also analyze the OpenAPI documentation of the optimal API to determine the types of parameters to be passed (e.g., month, consumption type, etc.) and determine the query parameters of the types to be passed from the user query information (e.g., the month is October 2025, the consumption type is electricity consumption, etc.). If there are missing query parameters in the user query information, the query parameters can be completed by means of context backtracking, prompting the user to supplement, and inference by default strategy. For example, if the user query information only includes the time dimension of month, but does not include the specific month, the default month is the current month.

[0045] After determining the optimal API and query parameters, an API call request for the optimal API interface is generated.

[0046] The pre-set large model can also analyze user query information based on pre-set prompts to determine the user's query type, such as: detailed query, statistical query, etc.

[0047] Step S104: Determine the result data based on the query parameters and the optimal API.

[0048] Specifically, the result data is determined based on the query parameters and the optimal API, including: obtaining the rate limiting policy and current call status of the optimal API; determining whether the optimal API is in a rate-limited state based on the rate limiting policy and current call status; determining whether the current user has access to the optimal API based on the data permission policy; if the optimal API is not in a rate-limited state and the current user has access, then the returned data is obtained from the optimal API based on the query parameters; and the result data is determined based on the returned data.

[0049] In this embodiment, before retrieving data from the optimal API interface according to user needs, it is necessary to perform rate limiting detection and permission authentication on the interface call request. The rate limiting policy for the optimal API is obtained from the administrator. For example, the rate limiting policy might state that the current optimal API can be accessed a maximum of 10 times every 10 minutes. The current call status of the optimal API is obtained from audit and log records. For example, the optimal API may have been called 3 times in the current minute. If the number of times the optimal API has been called exceeds the call count threshold in the rate limiting policy, then the optimal API is currently in a rate-limited state and data cannot be retrieved through the API interface; the user can be prompted "Please try again later." If the number of times the optimal API has been called does not exceed the call count threshold in the rate limiting policy, then the optimal API is not in a rate-limited state and is in a normal access state.

[0050] Retrieve the current user's role access permissions from the data permission policy. If the role access permissions include the optimal API, the optimal API interface can be called to retrieve the data. If the role access permissions do not include the optimal API, the current user cannot call the optimal API interface to retrieve the data, and the user can be prompted "You do not have permission to view the data".

[0051] If the optimal API is not in a rate-limited state and the current user has access permissions, then retrieve the returned data from the optimal API by querying the parameters; and determine the final result data based on the returned data.

[0052] Furthermore, the result data is determined based on the returned data, including: if the returned data is not indicator data, then the result data is calculated based on the indicator calculation method and the returned data; if the returned data has missing data, then the data supplementation rules are obtained; and the result data is supplemented based on the data supplementation rules to obtain the final result data.

[0053] In this embodiment, if the returned data is not indicator data, i.e., it is intermediate data that needs further calculation, the returned data is calculated using the indicator calculation method to obtain the result data. If the returned data is missing, the missing data supplementation rules are obtained from the preset data supplementation rules. The preset data supplementation rules include, for example: for state data that is only recorded after a change, the missing data is directly supplemented according to the data of the previous state; for time-series data, the missing data is supplemented using linear interpolation. The result data is supplemented according to the data supplementation rules to obtain the final result data. If there is no corresponding preset data supplementation rule for the missing data, the missing data is automatically supplemented using a preset large model, and the data supplementation method is noted in the result data.

[0054] Step S105: Map the result data to standard structured data based on the query type.

[0055] Specifically, mapping the result data to standard structured data based on the query type includes: determining the data structure based on the query type; and mapping the result data to standard structured data based on the data structure.

[0056] In this embodiment, the pre-configured large model has data structures for different query types. For example, for detailed queries, the data structure is a table data in Markdown syntax; for statistical queries, the data structure is: visual{"measure":["indicator1","indicator2"],"index":["dimension"],"data":{"value of dimension1":{"indicator1":"value of indicator1","indicator2":"value of indicator2"}}}. The large model maps the result data to standard structure data according to the data structure.

[0057] Step S106: Generate visualization results based on standard structure data.

[0058] When visualizing standard structured data, visualization results can be generated based on the display method selected by the current user or a predefined display method. Display methods include line charts, pie charts, bar charts, etc.

[0059] In addition, the pre-defined large model can save multi-round interaction history and historical query records of the pre-defined large model. It can also perform in-depth analysis, reverse tracing, and condition reconstruction on user query records based on this history. For example, in-depth analysis: if a user queries yesterday's production data and yesterday's start / stop records, the large model can further analyze the reasons for yesterday's production changes based on both (e.g., yesterday's output decreased due to a 2-hour shutdown caused by jig malfunction). Reverse tracing: if a user queries various production-related information (start-up records, shift information, production data, etc.) and then asks "why did yesterday's power consumption increase?", the pre-defined large model can directly obtain various production-related information from the interaction history and further analyze and determine the reasons. Condition reconstruction: if a user first queries the daily refined coal yield trend in October 2025 and then requests data with ash content below 8%, the system can search for query conditions (API, indicators, time dimensions, etc.) for "daily refined coal yield trend in October 2025" in the historical query records, then add further query conditions (condition reconstruction), and finally perform the query based on the reconstructed conditions.

[0060] The above query methods improve the real-time performance and accuracy of data processing while reducing system maintenance costs. For example, if a user queries "query the current warehouse location data for product A," since warehouse location = warehouse storage height / weight, without API interface integration, the two raw data points of warehouse storage height and weight might need to be obtained from the control layer (e.g., PLC / DCS). The control layer stores data through real-time variable tags. Before integrating with the control layer, the corresponding real-time variable tag for the query indicator in the control layer needs to be determined separately. If the query indicator is stored in the corresponding coal preparation plant subsystem, it can also be integrated with the coal preparation plant subsystem for data acquisition. However, this process also requires integration with OPC DA / OPC UA services, real-time database tables, historical databases, etc. The integration methods for various coal preparation plant subsystems differ. If the warehouse storage height and weight are stored in different coal preparation plant subsystems, each needs to be integrated individually, leading to high costs. Using a large model and OpenAPI documentation significantly reduces the integration speed.

[0061] Figure 2 is a structural block diagram of a coal preparation plant data query device 200 based on a large model provided in an embodiment of this application.

[0062] As shown in Figure 2, the coal preparation plant data query device 200 based on a large model mainly includes: a query information acquisition module 201, used to acquire the user query information of the current user; a candidate API determination module 202, used to determine candidate APIs and their corresponding semantic scores based on the user query information and the API semantic index library; an optimal API determination module 203, used to analyze the user query information, candidate APIs, and semantic scores based on a preset large model to determine the optimal API, query type, and query parameters; a result data determination module 204, used to determine the result data based on the query parameters and the optimal API; a standard structure mapping module 205, used to map the result data to standard structure data based on the query type; and a visualization result generation module 206, used to generate visualization results based on the standard structure data.

[0063] As an optional implementation of this embodiment, the candidate API determination module 202 is specifically used to, before determining the candidate API and the semantic score corresponding to each candidate API based on user query information and API semantic index library, further include: obtaining OpenAPI documents; embedding the OpenAPI documents into vectors through a vector embedding model; and constructing an API semantic index library based on each vector.

[0064] As an optional implementation of this embodiment, the candidate API determination module 202 is specifically used to determine candidate APIs and their corresponding semantic scores based on user query information and an API semantic index library. This includes: converting user query information into an initial vector based on a preset semantic vector model; searching a vector library of indicator calculation methods based on the initial vector to determine the indicators, time dimension, and indicator calculation methods in the user query information; concatenating the indicators, time dimension, indicator calculation methods, and user query information; converting the concatenated content into a user query vector based on a vector embedding model; calculating the semantic score of each vector in the API semantic index library based on a cosine similarity calculation method and the user query vector; obtaining the number of candidate APIs; determining the number of candidate API vectors with the highest semantic scores as candidate vectors; and determining the OpenAPI corresponding to the candidate vectors as candidate APIs.

[0065] As an optional implementation of this embodiment, the optimal API determination module 203 is specifically used to analyze user query information, candidate APIs, and semantic scores based on a preset large model to determine the optimal API, query type, and query parameters, including: analyzing user query information, candidate APIs, and semantic scores based on a preset large model to determine the optimal API; determining the parameter type to be transmitted based on the OpenAPI document of the optimal API; determining the query parameters of the parameter type to be transmitted based on the user query information; and analyzing user query information based on a preset large model to determine the query type.

[0066] As an optional implementation of this embodiment, the result data determination module 204 is specifically used to determine result data based on query parameters and the optimal API, including: obtaining the rate limiting policy and current call status of the optimal API; determining whether the optimal API is in a rate-limited state based on the rate limiting policy and current call status; determining whether the current user has access to the optimal API based on the data permission policy; if the optimal API is not in a rate-limited state and the current user has access, then obtaining returned data from the optimal API based on the query parameters; and determining result data based on the returned data.

[0067] As an optional implementation of this embodiment, the result data determination module 204 is specifically used to determine the result data based on the returned data, including: if the returned data is not indicator data, then calculating the result data based on the indicator calculation method and the returned data; if the returned data has missing data, then obtaining data supplementation rules; and supplementing the result data based on the data supplementation rules to obtain the final result data.

[0068] As an optional implementation of this embodiment, the standard structure mapping module 205 is specifically used to map the result data to standard structure data based on the query type, including: determining the data structure based on the query type; and mapping the result data to standard structure data based on the data structure.

[0069] In one example, the module in any of the above devices may be one or more integrated circuits configured to implement the above methods, such as one or more application-specific integrated circuits (ASICs), or one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs), or a combination of at least two of these integrated circuit forms.

[0070] For example, when modules in a device can be implemented via a processing element scheduler, the processing element can be a general-purpose processor, such as a central processing unit (CPU) or other processor capable of calling programs. Alternatively, these modules can be integrated together as a system-on-a-chip (SOC).

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

[0072] Figure 3 is a structural block diagram of an electronic device 300 provided in an embodiment of this application.

[0073] As shown in Figure 3, the electronic device 300 includes a processor 301 and a memory 302, and may further include one or more of an information input / output (I / O) interface 303, a communication component 304, and a communication bus 305.

[0074] The processor 301 controls the overall operation of the electronic device 300 to complete all or part of the steps of the aforementioned data query method for coal preparation plants based on a large model. The memory 302 stores various types of data to support the operation of the electronic device 300. This data may include, for example, instructions for any application or method operating on the electronic device 300, as well as application-related data. The memory 302 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as one or more of the following: 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.

[0075] I / O interface 303 provides an interface between processor 301 and other interface modules, such as keyboards, mice, and buttons. These buttons can be virtual or physical. Communication component 304 is used for wired or wireless communication between electronic device 300 and other devices. Wireless communication includes Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, or 4G, or a combination thereof. Therefore, the corresponding communication component 304 may include a Wi-Fi component, a Bluetooth component, and an NFC component.

[0076] The electronic device 300 can be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to execute the coal preparation plant data query method based on a large model given in the above embodiments.

[0077] The communication bus 305 may include a path for transmitting information between the aforementioned components. The communication bus 305 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus 305 can be divided into an address bus, a data bus, a control bus, etc.

[0078] Electronic device 300 may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), and in-vehicle terminals (such as in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers, and may also be servers.

[0079] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described method for querying coal preparation plant data based on a large model.

[0080] The computer-readable storage medium may include 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.

[0081] The terms “comprising,” “including,” or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0082] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing application concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions claimed in this application.

Claims

1. A method for querying coal preparation plant data based on a large model, characterized in that, include: Retrieve the current user's query information; Based on the user query information and the API semantic index, candidate APIs and their corresponding semantic scores are determined. Based on a pre-defined large model, the user query information, the candidate APIs, and the semantic scores are analyzed to determine the optimal API, query type, and query parameters. The result data is determined based on the query parameters and the optimal API; Based on the query type, the result data is mapped to standard structured data; Visualization results are generated based on the standard structure data.

2. The method according to claim 1, characterized in that, Before determining candidate APIs and their corresponding semantic scores based on the user query information and the API semantic index library, the method further includes: obtaining OpenAPI documents; embedding the OpenAPI documents into vectors using a vector embedding model; and constructing the API semantic index library based on the vectors.

3. The method according to claim 1, characterized in that, The step of determining candidate APIs and their corresponding semantic scores based on the user query information and the API semantic index library includes: converting the user query information into an initial vector based on a preset semantic vector model; searching a vector library of indicator calculation methods based on the initial vector to determine the indicators, time dimension, and indicator calculation methods in the user query information; concatenating the indicators, time dimension, indicator calculation methods, and user query information; converting the concatenated content into a user query vector based on a vector embedding model; calculating the semantic score of each vector in the API semantic index library based on a cosine similarity calculation method and the user query vector; obtaining the number of candidate APIs; determining the number of vectors with the highest semantic scores as candidate vectors; and determining the OpenAPI corresponding to the candidate vectors as the candidate APIs.

4. The method according to claim 1, characterized in that, The step of analyzing the user query information, candidate APIs, and semantic scores based on a preset large model to determine the optimal API, query type, and query parameters includes: analyzing the user query information, candidate APIs, and semantic scores based on the preset large model to determine the optimal API; determining the parameter type to be transmitted based on the OpenAPI documentation of the optimal API; determining the query parameters of the parameter type to be transmitted based on the user query information; and analyzing the user query information based on the preset large model to determine the query type.

5. The method according to claim 1, characterized in that, The step of determining the result data based on the query parameters and the optimal API includes: obtaining the rate limiting policy and current call status of the optimal API; determining whether the optimal API is in a rate-limited state based on the rate limiting policy and the current call status; determining whether the current user has access to the optimal API based on the data permission policy; if the optimal API is not in a rate-limited state and the current user has the access permission, then obtaining returned data from the optimal API based on the query parameters; and determining the result data based on the returned data.

6. The method according to claim 5, characterized in that, The step of determining the result data based on the returned data includes: if the returned data is not indicator data, then calculating the result data based on the indicator calculation method and the returned data; if the returned data has missing data, then obtaining data supplementation rules; and supplementing the result data based on the data supplementation rules to obtain the final result data.

7. The method according to claim 1, characterized in that, The step of mapping the result data to standard structure data based on the query type includes: determining the data structure based on the query type; and mapping the result data to the standard structure data based on the data structure.

8. A data query device for a coal preparation plant based on a large model, characterized in that, include: The query information retrieval module is used to retrieve the current user's query information; The candidate API determination module is used to determine candidate APIs and the semantic scores corresponding to each candidate API based on the user query information and the API semantic index library. The optimal API determination module is used to analyze the user query information, the candidate APIs, and the semantic scores based on a preset large model to determine the optimal API, query type, and query parameters. The result data determination module is used to determine result data based on the query parameters and the optimal API. A standard structure mapping module is used to map the result data into standard structure data based on the query type. The visualization result generation module is used to generate visualization results based on the standard structure data.

9. An electronic device, characterized in that, The device includes a processor coupled to a memory; the processor is configured to execute a computer program stored in the memory to cause the electronic device to perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It includes a computer program or instructions that, when run on a computer, cause the computer to perform the method as described in any one of claims 1 to 7.

Images