Method, device and equipment for converting natural language into data service calling instruction

Abstract

The invention provides a method, a device and equipment for converting a natural language into a data service calling instruction, and belongs to the field of artificial intelligence. The method comprises the steps of obtaining a target data query request in a target scene; the target data query request is input into a conversion model, a target service calling instruction output by the conversion model is obtained, and the target service calling instruction comprises a target application programming interface API and target API parameters; the conversion model is generated based on a target large model supporting a data query service in the target scene and a target corpus corresponding to the target scene, and the target API and the target API parameters are used for obtaining a query result of the target data query request. In this way, dependence on a high-parameter general large model can be eliminated, the accuracy of conversion from the natural language to the API and the API parameters is improved, the adaptation capacity for the target scene data query requirement is enhanced, and therefore the accurate query result is efficiently obtained.

Description

Technical Field

[0001] This application belongs to the field of artificial intelligence, and specifically relates to a method, apparatus and device for invoking natural language to data service. Background Technology

[0002] In intelligent data querying, intelligent query systems have become an important tool for users to quickly obtain business data. Their core function is to convert natural language query commands into data service call commands, thereby meeting users' needs to obtain indicator data without needing to master professional query syntax. Currently, the industry's conventional technical solutions for this need mostly rely on large language models with high parameter scales, assembling function call prompts and using a feedback interaction mode to complete the relevant conversion. Specifically, the user's natural language query request is first passed to the large model, which then autonomously matches callable data interfaces, initiates interface calls, observes the call results, and finally integrates the results to provide feedback to the user.

[0003] However, such solutions have significant technical shortcomings. On the one hand, high-parameter, large-scale models have stringent requirements for hardware computing power, resulting in extremely high deployment and maintenance costs, making them difficult to implement in resource-constrained scenarios. On the other hand, when faced with unconventional and complex data query requests involving multiple units, time periods, and dimensions, the large-scale models lack the accuracy to match data interfaces and interface parameters, failing to accurately decompose user needs and generate corresponding calling instructions, thus making it difficult to guarantee the accuracy of data query results. Furthermore, the interface matching logic and feedback interaction process of large-scale models are deeply coupled, making it impossible to independently complete the accurate output of interfaces and parameters. The overall process is redundant and lacks flexibility, severely restricting the service efficiency and applicability of intelligent data query systems and causing considerable inconvenience to users' daily data queries. Summary of the Invention

[0004] This application provides a method, apparatus, and device for converting natural language into data service call instructions, thereby eliminating the reliance on high-parameter general large models, improving the accuracy of natural language to application programming interface (API) and API parameter conversion, enhancing the adaptability to data query needs in target scenarios, and thus efficiently obtaining accurate query results.

[0005] This application provides a method for invoking natural language to data service commands, including: Obtain the target data query request in the target scenario; The target data query request is input into the transformation model to obtain the target service call instruction output by the transformation model. The target service call instruction includes the target application programming interface (API) and the target API parameters. The transformation model is generated based on the target large model that supports data query services under the target scenario and the target corpus corresponding to the target scenario. The target API and the target API parameters are used to obtain the query results of the target data query request.

[0006] According to the method for invoking natural language to data services provided in this application, the conversion model is generated in the following manner: obtaining a target large model that supports data query services under the target scenario; obtaining a target corpus corresponding to the target scenario; inputting the target corpus in the target corpus into the target large model, and transferring the natural language to data service capabilities of the target large model to the base model through knowledge distillation to obtain a reference model; and fine-tuning the reference model according to the target corpus to obtain the conversion model.

[0007] According to the method for invoking natural language to data services provided in this application, the step of obtaining the target corpus corresponding to the target scenario includes: determining the proprietary data type of the target scenario; obtaining the proprietary vocabulary corpus corresponding to the proprietary data type; obtaining the question-and-answer dataset corresponding to the data query request in the target scenario, wherein the question-and-answer dataset includes multiple initial question-and-answer pairs; decomposing the data query request in the target scenario from the multiple initial question-and-answer pairs to obtain question decomposition corpus; obtaining the API and API parameter corpus selected by the data query request in the target scenario based on the multiple initial question-and-answer pairs; obtaining multiple reference question-and-answer pairs based on the question decomposition corpus and the API and API parameter corpus; and generating the target corpus based on the proprietary vocabulary corpus and the multiple reference question-and-answer pairs.

[0008] According to the method for invoking natural language to data services provided in this application, the step of fine-tuning the reference model based on the target corpus to obtain the conversion model includes: acquiring reference question-answer pairs generated during knowledge distillation; verifying the reference question-answer pairs to obtain target question-answer pairs; and fine-tuning the reference model based on the proprietary vocabulary corpus in the target corpus and the target question-answer pairs to obtain the conversion model.

[0009] According to the method for invoking natural language to data service provided in this application, the step of fine-tuning the reference model based on the target corpus to obtain the conversion model includes: fine-tuning the reference model based on the target corpus to obtain a target model; and converting the floating-point parameters in the target model into integer representations to obtain the conversion model.

[0010] The method for invoking natural language to data services according to this application further includes: constructing an intermediate layer that supports multiple query types, wherein the query types are used to indicate the data type requested for querying in the target scenario; obtaining the technical terms corresponding to each preset type operation; and writing the technical terms into the intermediate layer, wherein the intermediate layer is used to assist in determining the target API and the target API parameters.

[0011] This application also provides an apparatus for invoking natural language to data service instructions, comprising: The acquisition unit is used to acquire target data query requests in the target scenario. The input unit is used to input the target data query request into the transformation model to obtain the target service call instruction output by the transformation model. The target service call instruction includes the target application programming interface (API) and the target API parameters. The transformation model is generated based on the target large model that supports data query services under the target scenario and the target corpus corresponding to the target scenario. The target API and the target API parameters are used to obtain the query results of the target data query request.

[0012] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a method for calling a natural language to data service as described above.

[0013] This application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a method for invoking any of the natural language to data service instructions described above.

[0014] This application also provides a computer program product, including a computer program that, when executed by a processor, implements a method for invoking any of the natural language to data service instructions described above.

[0015] According to the method, apparatus, and device for invoking natural language to data services provided in this application, a target data query request in a target scenario is first obtained. Then, the target data query request is input into a conversion model to obtain a target service invoking instruction output by the conversion model. The target service invoking instruction includes a target application programming interface (API) and target API parameters. The conversion model is generated based on a target large model supporting data query services in the target scenario and a target corpus corresponding to the target scenario. The target API and the target API parameters are used to obtain the query results of the target data query request. By using a conversion model constructed based on a target large model and a dedicated target corpus in the target scenario to process data query requests and generate target service invoking instructions containing target APIs and target API parameters, the reliance on high-parameter general large models can be eliminated, improving the accuracy of natural language to data service interface and parameter conversion, enhancing the adaptability to data query needs in the target scenario, and thus efficiently obtaining accurate query results. Attached Figure Description

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

[0017] Figure 1 This is one of the flowcharts illustrating a method for invoking natural language to data service provided in this application.

[0018] Figure 2 This is the second flowchart illustrating a method for invoking natural language to data service provided in this application.

[0019] Figure 3 This is a block diagram of the functional units of a device for invoking natural language to data service, as provided in this application.

[0020] Figure 4 This is a schematic diagram of the structure of an electronic device provided in this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions 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.

[0022] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0023] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0024] Currently, in intelligent data querying, high-parameter large models have stringent requirements for hardware computing power, resulting in extremely high deployment and maintenance costs. At the same time, for complex data query requests, the large models lack the accuracy to match data interfaces and interface parameters. Furthermore, the interface matching logic and feedback interaction process of large models are deeply coupled, which seriously restricts the service efficiency and applicability of intelligent data querying systems and brings many inconveniences to users' daily data queries.

[0025] To address the aforementioned problems, embodiments of this application provide a method, apparatus, and device for invoking natural language to data services. The embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0026] Please see Figure 1 , Figure 1 This is one of the flowcharts illustrating a method for invoking a natural language-to-data service according to this application. The method includes the following steps.

[0027] S101, Obtain the target data query request in the target scenario.

[0028] The target scenarios can be specifically categorized into different business scenarios, such as the indicator data query scenario in the power industry. This type of scenario typically has its own dedicated business data system and query rules, which can cover personalized indicators, dimensions, organizational structures, and other exclusive data categories at the grid and provincial levels. The initiator of the target data query request can be business personnel, data analysts, or other users with data query needs in the power industry. Users can submit requests through the front-end interactive interface in the form of text input, or they can submit requests through voice input, which will be processed by the system to form a standardized query request text.

[0029] The content format of this target data query request can be flexible and diverse. It can be a simple data query request for a single element, such as querying a single electricity indicator data for a specific region and time period. It can also be a complex data query request involving multiple dimensions, organizations, and indicators, or an analytical data query request that includes secondary calculations such as comparisons and percentages. The core elements that the request can include can cover business information strongly related to the target scenario. For example, it can cover the target power supply unit organization, such as provincial power supply companies, municipal power supply companies, and district / county power supply companies. It can also cover specific indicator names, such as total social electricity consumption, electricity sales, number of business operators, and number of photovoltaic users. It can also cover dimension types, such as user category, electricity consumption category, industry, and manufacturing. It can also cover query keywords, such as current period value, month-on-month comparison, year-on-year comparison, and cumulative current period value. It can also cover unit levels, such as the current level and subordinate levels. Furthermore, it can cover statistical periods, which can be different time formats such as a single day, daily time interval, single month, monthly time interval, single year, and yearly time interval. For example, users can submit target data query requests such as "the percentage of industrial electricity consumption in City A in February 2025 in terms of total social electricity consumption," which includes regional, dimension, indicator, statistical period, and secondary calculation requirements.

[0030] When the system receives the request, it can first perform basic format validation and content recognition to filter out invalid garbled characters, meaningless characters and other interference information, so as to ensure that the subsequent conversion of natural language to data services can be carried out based on the standardized query request. The obtained request can be temporarily stored in the system's request cache module to provide a stable input data source for the subsequent conversion process.

[0031] S102, the target data query request is input into the conversion model to obtain the target service call instruction output by the conversion model.

[0032] The target service invocation instruction includes a target application programming interface (API) and target API parameters. The conversion model is generated based on a target large model supporting data query services in the target scenario and a target corpus corresponding to the target scenario. The target API and the target API parameters are used to obtain the query results of the target data query request.

[0033] The target scenario can be specifically the intelligent data query scenario in the power industry. The corresponding target large model can be a high-parameter large model with strong general data service transformation capabilities, which can carry the core transformation logic related to data query in this scenario. The target corpus can cover multiple types of exclusive corpora in this scenario. It can include basic information corpora such as indicators, dimensions, and organizational structures personalized by the power grid and province, as well as general information corpora such as time format, unit level, and organizational type. It can also include planning and decomposition corpora for data query problems such as simple single-element questions, complex query problems with multiple organizations, multiple dimensions, and multiple indicators, and comparative analysis questions. At the same time, it can also cover API intelligent selection and parameter recognition corpora such as the open-source ms-agent original API set and API annotation sets of different cities. This rich corpus can ensure that the transformation model has sufficient scenario-based knowledge reserves.

[0034] When a target data query request is input into the transformation model, the model can first accurately identify the core business elements in the request. These elements can include the name of the power supply unit organization, the specific indicator name, the dimension type, query keywords, the unit level, and the statistical period. For example, for a request like "the percentage of industrial electricity consumption in City A in February 2025 in total social electricity consumption," the model can accurately identify the core elements such as the geographical organization being the relevant power supply unit in City A, the indicators being industrial electricity consumption and total social electricity consumption, the dimension type being industrial, the statistical period being February 2025, and the query requirement being percentage calculation. Subsequently, based on its own stored scenario-based knowledge, the model can match and generate the corresponding target API and target API parameters. The generated target APIs can be either indicator query interfaces or indicator secondary calculation interfaces. The parameters for indicator query APIs can include the organization name (orgName), such as the relevant power supply unit in City A; the indicator name (idxName), such as industrial electricity consumption or total social electricity consumption; the dimension type (dimType), such as industrial; and the indicator statistical period (statCycle), such as 202502. The parameters for indicator secondary calculation APIs can include the calculation method (cal), such as percentage. These target APIs and their parameters can be directly used to call the corresponding backend data service interfaces to obtain the accurate query results required by the user's target data query request. Furthermore, the entire conversion process can efficiently transition from natural language to structured service call instructions while ensuring accuracy, laying a solid foundation for obtaining subsequent data query results.

[0035] As can be seen, in this embodiment, by using a conversion model constructed based on a target large model and a dedicated target corpus in the target scenario to process data query requests and generate target service call instructions containing target APIs and target API parameters, the reliance on high-parameter general large models can be eliminated, the accuracy of natural language to data service interface and parameter conversion can be improved, the adaptability to target scenario data query requirements can be enhanced, and thus the accurate query results can be obtained efficiently.

[0036] In one possible embodiment, the conversion model is generated based on the following method: obtaining a target large model that supports data query services under the target scenario; obtaining a target corpus corresponding to the target scenario; inputting the target corpus in the target corpus into the target large model, and transferring the natural language to data service capabilities of the target large model to the base model through knowledge distillation to obtain a reference model; and fine-tuning the reference model according to the target corpus to obtain the conversion model.

[0037] The target scenario can be specifically the intelligent data query scenario in the power industry. The target large-scale model supporting data query services in this scenario can be a high-parameter large-scale language model with strong general semantic understanding and data service conversion capabilities, such as deepseek-v3 or qwen-max. This type of target large-scale model can carry the core logic of natural language to data service interface conversion, providing a sufficient foundation for subsequent knowledge transfer. Specifically, the base model can be the Qwen-2.5-7b-instruct model with appropriate parameter size. After inputting the target corpus from the target corpus into the target large-scale model, knowledge distillation technology can be used to transfer the core knowledge of natural language to data service conversion from the target large-scale model to the base model. During the migration process, the proprietary vocabulary system of the subdivided scenario, including organization names, business indicator names, data dimension identifiers, etc., can also be simultaneously deeply integrated with high-quality question-answer pairs and written into the base model. This reduces model complexity while improving the model's professionalism and accuracy in specific domains, ultimately resulting in a reference model with basic scenario conversion capabilities.

[0038] After obtaining the reference model, it can be fine-tuned based on the target corpus. During the fine-tuning process, the Low-Rank Adaptation (LoRA) algorithm can be used to deeply integrate the proprietary vocabulary system and high-quality question-answer pairs in the target corpus into the reference model. This enhances the reference model's ability to understand natural language query requests in the target scenario and its ability to match the target API and corresponding parameters. The final result is a conversion model that can accurately adapt to the data query needs of the target scenario. This conversion model can retain the core conversion accuracy and adapt to low-computing deployment environments, effectively supporting the efficient conversion of natural language to data service interfaces in the target scenario.

[0039] In one possible embodiment, obtaining the target corpus corresponding to the target scenario includes: determining the proprietary data type of the target scenario; obtaining the proprietary vocabulary corpus corresponding to the proprietary data type; obtaining the question-and-answer dataset corresponding to the data query request in the target scenario, wherein the question-and-answer dataset includes multiple initial question-and-answer pairs; decomposing the data query request in the target scenario from the multiple initial question-and-answer pairs to obtain question decomposition corpus; obtaining the API and API parameter corpus selected by the data query request in the target scenario based on the multiple initial question-and-answer pairs; obtaining multiple reference question-and-answer pairs based on the question decomposition corpus and the API and API parameter corpus; and generating the target corpus based on the proprietary vocabulary corpus and the multiple reference question-and-answer pairs.

[0040] The target scenario can be specifically the intelligent data query scenario in the power industry. When determining the proprietary data types for this scenario, core data types such as basic information, general information, data query planning, and API matching can be defined based on industry business characteristics. Basic information can cover proprietary data categories strongly related to power data queries, such as indicators, dimensions, and organizational structures. General information can include basic query elements such as time format, unit level, and organizational type. When acquiring proprietary vocabulary corpora corresponding to proprietary data types, proprietary vocabulary such as organization names, dimension names, and indicator names specific to the power grid and province can be collected for the basic information data type. Specifically, multiple organizational name corpora can be obtained, which can include the names of power supply units at different levels, such as provincial power supply companies, municipal power supply companies, district / county power supply companies, and power supply stations, along with their corresponding synonyms and codes. Multiple dimension name corpora can be obtained, which can include dimension names and related mapping information such as user categories, electricity consumption categories, the entire industry, manufacturing, and industrial sectors. It can also obtain multiple indicator name corpora, which may include the names and corresponding interpretations of core power indicators such as total electricity consumption, electricity sales, number of business operators, and number of photovoltaic users. These proprietary vocabulary corpora can solidify the transformation model's cognitive foundation for the basic business entities of the target scenario.

[0041] When acquiring the question-and-answer dataset corresponding to data query requests in a target scenario, different types of data query requests and corresponding solutions can be collected. The resulting initial question-and-answer pairs can cover multiple query scenarios. These can include simple questions with a single element, such as "querying single electricity indicator data for a certain city in a certain month," as well as complex query questions involving multiple organizations, dimensions, and indicators, such as "comparison of multi-regional, multi-dimensional indicator data," and even secondary calculation questions involving comparison or analysis, such as "indicator percentage, year-on-year change." Specifically, multiple initial question-and-answer pairs covering various data query scenarios can be generated, providing sufficient samples for subsequent corpus processing.

[0042] When breaking down data query requests from the initial question-answer pairs to obtain a decomposed corpus, complex data query requests can be broken down into multiple independently processable sub-query tasks based on their core requirements. For example, a request like "the percentage of industrial electricity consumption in City A in February 2025 in total social electricity consumption" can be broken down into three sub-tasks: "obtain basic indicator data of industrial electricity consumption in City A in February 2025," "obtain basic indicator data of total social electricity consumption in City A in February 2025," and "perform a secondary calculation of the percentages for the two types of indicator data." The decomposed corpus obtained in this way enables the transformation model to have the logical ability to handle complex data query requests.

[0043] When acquiring API and API parameter corpora corresponding to data query requests in the target scenario based on the initial question and answer, API annotation data from multiple sources can be integrated. Specifically, multiple open-source ms-agent raw API sets and multiple API annotation sets from different cities can be acquired. Simultaneously, parameter information corresponding to various APIs can be collected. For example, parameters such as orgName, idxName, dimType, and statCycle for indicator query APIs, and cal parameters for secondary calculation APIs. This API and API parameter corpus allows the transformation model to understand the matching rules between natural language requests and backend data service interfaces.

[0044] When generating reference question-answer pairs based on the decomposed corpus of questions and the corpus of APIs and API parameters, the decomposed subtasks can be associated with the corresponding APIs and parameters to form question-answer samples with a complete chain of "question-decomposition logic-API matching-parameter configuration". For example, a reference question-answer pair can be constructed that reads "Query the percentage of industrial electricity consumption in City A in February 2025 - decompose it into basic indicator query and percentage calculation - basic indicator query matches the index_query API and configures parameters such as orgName=City A, idxName=industrial electricity consumption, statCycle=202502, etc., percentage calculation matches the index_secondary_calculation API and configures cal=percentage parameter", so that the corpus has complete business processing chain knowledge. Finally, when generating the target corpus, in addition to integrating proprietary vocabulary and reference question-and-answer pairs, multiple general informational corpora covering time formats, unit levels, organizational types, etc., can be added. The target corpus constructed in this way contains not only core business-specific vocabulary of the target scenario, but also decomposes the data lookup problem and API matching rules, which can fully support the training of the conversion model. Moreover, the corpus can be flexibly expanded according to the business expansion of the target scenario, ensuring the adaptability of the conversion model to changes in the scenario.

[0045] In practical implementation, the generated reference question-and-answer pairs can be generalized through rule replacement, and then the final reference question-and-answer pairs can be obtained through manual screening and verification. The generalization operation of rule replacement can be based on the business characteristics and data types of the target scenario to formulate targeted replacement logic. The target scenario can be specifically the intelligent question-and-answer scenario in the power industry. For the reference question-and-answer pairs in this scenario, multi-dimensional replacement rules can be designed around their core business elements, such as power supply unit organization, indicator name, dimension type, and statistical period. For power supply unit organization elements, a mapping table of organization names at different levels and in different regions within the power grid province can be established. The existing power supply unit names in the reference question-and-answer pairs, such as City A, can be replaced with power supply unit names in cities of the same level, such as City B and City C, or at different levels. Simultaneously, the corresponding organization's code, synonyms, and other related information can be replaced. For indicator name elements, based on the classification system of power business indicators, "industrial electricity consumption" can be replaced with names such as "total social electricity consumption" and "electricity sales." For dimension type elements, the "industrial" dimension can be replaced with other dimension types such as "manufacturing," "all industries," and "user category."

[0046] During the rule replacement process, replacement verification logic can be set to ensure that the replaced reference question-and-answer pairs still conform to the basic business logic of power data lookup. Furthermore, an initial reference question-and-answer pair can be used to derive multiple different generalized reference question-and-answer pairs through multi-dimensional rule replacement, significantly expanding the corpus's quantity and scenario coverage. After completing the generalization operation of rule replacement, a manual screening and verification stage is required. Verification personnel can be business experts and technical personnel in the power industry. During the verification process, the generalized reference question-and-answer pairs can be evaluated from multiple core dimensions. First, the accuracy of the business logic can be verified to ensure that the generalized question-and-answer pairs conform to the business rules of power data lookup, such as whether there are logical loopholes like "county / district power supply station level matches province-wide indicators." Second, the reasonableness of API and parameter matching can be verified to ensure that the data lookup requests in the generalized question-and-answer pairs accurately correspond to the corresponding target APIs and target API parameters, such as whether the percentage-based query requirements match the indicator secondary calculation APIs and the parameter cal=percentage. Thirdly, the validity of the corpus is verified. This involves checking whether the generalized question-and-answer pairs can effectively support the transformation model's learning and whether they cover complex data query scenarios involving multiple units, dimensions, and periods. During the manual screening stage, generalized reference question-and-answer pairs with logical errors, matching biases, or no practical training value can be removed. During the manual verification stage, each of the screened generalized reference question-and-answer pairs can be reviewed and corrected for issues such as incorrect parameter formats and inaccurate naming. After these final reference question-and-answer pairs are integrated with the proprietary vocabulary corpus, a target corpus more suitable for intelligent power data query scenarios can be constructed. Furthermore, the generalization and verification stages can flexibly adjust the dimensions of rule replacements and the standards of manual verification to adapt to the expansion of the target scenario's business scope and the updates to business rules, ensuring the timeliness and applicability of the target corpus.

[0047] In one possible embodiment, the step of fine-tuning the reference model based on the target corpus to obtain the transformation model includes: acquiring reference question-answer pairs generated during knowledge distillation; verifying the reference question-answer pairs to obtain target question-answer pairs; and fine-tuning the reference model based on the proprietary vocabulary corpus in the target corpus and the target question-answer pairs to obtain the transformation model.

[0048] The reference question-and-answer pairs generated during knowledge distillation are generated synchronously when the target corpus from the target corpus is input into the target large model, leveraging knowledge distillation technology to transfer natural language to data service capabilities. These reference question-and-answer pairs can cover various types of data query needs in the target scenario. They can include question-and-answer logic for simple data query questions with a single element, as well as the decomposition chain of complex query questions with multiple organizations, dimensions, and indicators. They can also integrate the core rules of intelligent API selection and parameter recognition, corresponding to two core scenarios: question decomposition and API parameter recognition in the target scenario. After obtaining these reference question-and-answer pairs, they need to be fully validated to obtain the target question-and-answer pairs. The validation work can be jointly completed by business experts and technical personnel corresponding to the target scenario. The validation rules and content can be as described above. After validation, reference question-and-answer pairs with minor deviations can be corrected to finally obtain target question-and-answer pairs that are both accurate and adaptable. When fine-tuning the model, the reference model can be Qwen-2.5-7b-instruct with an appropriate parameter size as the base model. During the fine-tuning process, the LoRA algorithm can be used to deeply integrate the proprietary vocabulary corpus in the target corpus with the validated target question-answer pairs into the reference model. This corpus can solidify the model's understanding of the basic business entities in the target scenario, while the target question-answer pairs can strengthen the model's decomposition logic for data lookup problems and its API matching ability. During fine-tuning, parameters such as training epochs and learning rate can be flexibly set to ensure that the model does not lose its original capabilities while absorbing new knowledge. The conversion model obtained through this fine-tuning method can not only get rid of the dependence on high-parameter, large models, but also accurately adapt to the natural language to data service needs of the target scenario. It can efficiently and accurately output the corresponding target API and target API parameters, providing reliable support for the subsequent acquisition of data query results.

[0049] In one possible embodiment, the step of fine-tuning the reference model based on the target corpus to obtain the conversion model includes: fine-tuning the reference model based on the target corpus to obtain a target model; and converting the floating-point parameters in the target model into integer representations to obtain the conversion model.

[0050] The reference model is a base model obtained by transferring the natural language to data service capabilities of the target large model through knowledge distillation technology. It can use the Qwen-2.5-7b-instruct model with appropriate parameter sizes. When fine-tuning based on the target corpus, the LoRA algorithm can be used to deeply integrate the proprietary vocabulary and high-quality question-answer pairs in the target corpus into the reference model. During fine-tuning, core parameters such as training epochs and learning rate can be flexibly set to ensure that the model absorbs target scenario-specific knowledge without losing the basic transformation capabilities acquired during the knowledge distillation stage. The target model obtained after this targeted fine-tuning can accurately identify target scenarios, such as the core business elements in data query requests in the power intelligent data query scenario. For example, it can quickly locate key parameters such as orgName, idxName, dimType, statCycle, and cal, and can match the corresponding target API and target API parameters according to the request content, demonstrating strong domain business adaptability.

[0051] After obtaining the target model, its floating-point parameters need to be converted to integer representations to achieve model lightweighting. This process can utilize AWQ int4 quantization technology to achieve low-precision integer conversion. To avoid performance loss during quantization, quantization-aware training and mixed-precision strategies can be employed simultaneously. Before quantization, the model is adapted to a low-precision computation mode while retaining some high-precision parameters from core layers. This ensures that core performance indicators such as API selection accuracy and parameter matching precision remain within acceptable ranges after model conversion. By converting floating-point parameters to integer representations in this way, the resulting converted model achieves significant size compression and improved inference speed. Its hardware deployment threshold is greatly reduced; only a single T4 graphics card is needed for stable model deployment, and the converted model still maintains business responsiveness similar to the fine-tuned target model. It can efficiently handle unconventional and complex data lookup requests involving multiple units, time periods, and dimensions, while also eliminating reliance on high-parameter, large models. Even in resource-constrained business scenarios, it provides users with stable and accurate natural language to data service interface conversion support.

[0052] In one possible embodiment, the method further includes: constructing an intermediate layer that supports multiple query types, the query types being used to indicate the data type requested for querying in the target scenario; obtaining technical terms corresponding to each preset type operation; and writing the technical terms into the intermediate layer, the intermediate layer being used to assist in determining the target API and the target API parameters.

[0053] The middleware layer can be built based on a vector database (Milvus), supporting multiple query types that precisely correspond to the data types requested in the target scenario. Specifically, it includes four core query types: scalar query, single-vector query, multi-vector query, and hybrid scalar and vector query. Scalar queries can be used to quickly retrieve data with precise identification information such as clear codes and names. Single-vector queries can perform semantic similarity matching for a single business term. Multi-vector queries can simultaneously perform semantic similarity matching for multiple business terms. Hybrid scalar and vector queries can combine precise attribute conditions and semantic similarity to complete a composite retrieval. These query types can comprehensively cover the target scenario, such as the retrieval needs of different types of data in the power smart data query scenario. For example, scalar queries can quickly locate power supply unit organizations with specific codes, while vector queries can match standardized terms such as "A City Power Supply Company" which are semantically similar to "A Electricity".

[0054] When acquiring the professional terminology corresponding to each preset type of operation, multi-dimensional domain-specific professional terminology can be collected based on the business characteristics of the target scenario. These professional terms can include: provincial and municipal personalized organizational information terms, specifically covering organization names, synonyms, and codes, such as the names and corresponding codes and synonyms of power supply units at different levels, such as provincial power supply companies, municipal power supply companies, district / county power supply companies, and power supply stations; dimensional information terms, such as user categories, electricity consumption categories, all industries, manufacturing, and industrial dimensions, along with related mapping information; indicator information terms, such as the names, synonyms, and codes of core power indicators like total electricity consumption, electricity sales, number of business operators, and number of photovoltaic users; and user-annotated terms, i.e., the original questions, rewritten questions, and corresponding answers generated by users during actual data queries, as well as registered API-related terms, including API names, API descriptions, API parameter lists, and detailed descriptions of each parameter. For example, index_query for indicator query APIs and index_secondary_calculation for indicator secondary calculation APIs, along with their corresponding parameter descriptions. These technical terms comprehensively cover the core knowledge areas of data lookup services in the target scenario, and can be incrementally supplemented based on user feedback data to ensure the timeliness and completeness of the terminology.

[0055] When writing technical terms into the middleware layer, standardization preprocessing can be performed on various technical terms first. For example, non-standard terminology can be standardized into business specification names for the target scenario, and non-standard formats of parameters such as statistical periods can be corrected to standard formats. At the same time, domain-adaptive embedding models can be used to convert the text information of terms into high-dimensional vectors to facilitate subsequent vector similarity retrieval. Then, according to the type of term, they can be stored in the corresponding storage set of the middleware layer. For example, organizational information terms can be stored in the organizational information set, indicator information terms in the indicator information set, and API-related terms in the API information set, and adaptive indexing strategies can be set for different sets.

[0056] In the process of the transformation model processing target data query requests and determining the target API and its parameters, this middleware layer plays a crucial supporting role. When the model receives a user's query request, it can first extract the core business terms from the request. For example, from the request "Percentage of industrial electricity consumption in City A in February 2025 to total social electricity consumption," it can extract core terms such as "City A," "industry," "industrial electricity consumption," "total social electricity consumption," and "percentage." Then, it can trigger the corresponding query operations in the middleware layer. For instance, it can initiate a scalar and vector hybrid query for "City A" to obtain the corresponding power supply unit organization information; a vector query for "industrial electricity consumption" to obtain the corresponding indicator information and matching API parameter requirements; and a scalar query for "percentage" to obtain the corresponding secondary calculation API information. The middleware layer can feed back the retrieved organization, dimension, indicator, example labeled data, and API waiting option information to the transformation model in real time. The model can then combine this precise domain knowledge to more efficiently and accurately determine the target API and its corresponding parameters. Meanwhile, this intermediate layer can support real-time incremental writing of professional terms. When new power supply unit organizations, new business indicators, or new user feedback annotation data appear in the target scenario, the corresponding professional terms can be directly written into the intermediate layer without retraining the entire conversion model. This allows the model to have the ability to respond to new business knowledge and continuously improve the model's adaptability and response accuracy to the data query needs of the target scenario.

[0057] The following is combined Figure 2 A brief description of the overall process of this application is provided.

[0058] First, we manually collected specialized vocabulary and prepared a high-quality question-answer pair corpus. Simultaneously, we completed hardware configuration and model parameter settings, such as using the L-Rrnis8 algorithm with a learning rate of lr=5e-4 and epochs=5. We then performed question decomposition, API and parameter identification processing on the corpus, and generated corresponding corpus through corpus generalization and rule replacement. This was combined with high-parameter models, time, and model-related data for further processing. After manual screening, verification, synthesis, and answer labeling, the corpus entered the verification and evaluation phase. Subsequently, we performed knowledge distillation based on the high-parameter model, transferring its capabilities to the low-parameter model, i.e., the base model. During this process, we can integrate LLaMA-Factory and MS-SWIFT 3v capabilities, focusing on strengthening the model's question decomposition and API capabilities, clarifying the debugging scope, completing model selection, and performing optional quantization operations as needed. Finally, the optimized conversion model is deployed and used. In actual application, the target data query request in the target scenario is obtained first, and then the request is input into the conversion model. The model outputs the target application programming interface (API) and target API parameters to obtain the query results. At the same time, an intermediate layer can be built to write professional terms to help determine the target API and target API parameters, thus achieving accurate conversion from natural language to data services.

[0059] After generating the transformation model, it can be deployed and used. As shown in Table 1, using the same set of agents, Wenxin Yiyan, the NL2API-Qwen2.5-7b-sft, DeepSeek-R1-Distill-Qwen-32B, Qwen2.5-32B-Instruct-AWQ, and Qwen2.5-72B-Instruct-AWQ were selected as the base models. The NL2API-Qwen2.5-7b-sft model corresponding to this application achieved impressive results, surpassing Qwen2.5-72B-Instruct-AWQ and approaching the 101B parameter count of Wenxin Yiyan. Furthermore, its service response speed is significantly faster than other high-parameter models.

[0060] Table 1:

[0061] The apparatus for invoking a natural language to data service provided in this application will be described below. The apparatus for invoking a natural language to data service described below corresponds to the method for invoking a natural language to data service described above.

[0062] Please see Figure 3The apparatus 300 for converting natural language into data service invocation instructions includes: an acquisition unit 301 for acquiring a target data query request in a target scenario; and an input unit 302 for inputting the target data query request into a conversion model to obtain a target service invocation instruction output by the conversion model. The target service invocation instruction includes a target application programming interface (API) and target API parameters. The conversion model is generated based on a target large model that supports data query services in the target scenario and a target corpus corresponding to the target scenario. The target API and the target API parameters are used to obtain the query results of the target data query request.

[0063] In one possible embodiment, the apparatus 300 for invoking the natural language to data service further includes a generation unit, which is specifically used for: obtaining a target large model that supports data query services under the target scenario; obtaining a target corpus corresponding to the target scenario; inputting the target corpus from the target corpus into the target large model; transferring the natural language to data service capabilities of the target large model to the base model through knowledge distillation to obtain a reference model; and fine-tuning the reference model according to the target corpus to obtain the conversion model.

[0064] In one possible embodiment, regarding the acquisition of the target corpus corresponding to the target scenario, the generation unit is specifically configured to: determine the proprietary data type of the target scenario; acquire the proprietary vocabulary corpus corresponding to the proprietary data type; acquire the question-and-answer dataset corresponding to the data query request under the target scenario, the question-and-answer dataset including multiple initial question-and-answer pairs; decompose the data query request under the target scenario in the multiple initial question-and-answer pairs to obtain question decomposition corpus; acquire the API and API parameter corpus selected by the data query request under the target scenario based on the multiple initial question-and-answer pairs; obtain multiple reference question-and-answer pairs based on the question decomposition corpus and the API and API parameter corpus; and generate the target corpus based on the proprietary vocabulary corpus and the multiple reference question-and-answer pairs.

[0065] In one possible embodiment, in the step of fine-tuning the reference model according to the target corpus to obtain the transformation model, the generation unit is specifically used to: obtain reference question-answer pairs generated during knowledge distillation; verify the reference question-answer pairs to obtain target question-answer pairs; and fine-tune the reference model according to the proprietary vocabulary corpus in the target corpus and the target question-answer pairs to obtain the transformation model.

[0066] In one possible embodiment, in the step of fine-tuning the reference model according to the target corpus to obtain the transformed model, the generation unit is specifically used to: fine-tune the reference model according to the target corpus to obtain a target model; and convert the floating-point parameters in the target model into integer representations to obtain the transformed model.

[0067] In one possible embodiment, the generation unit is further configured to: construct an intermediate layer supporting multiple query types, wherein the query types are used to indicate the data type requested for querying in the target scenario; obtain the technical terms corresponding to each preset type operation; and write the technical terms into the intermediate layer, wherein the intermediate layer is used to assist in determining the target API and the target API parameters.

[0068] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of the electronic device provided in this application. For example... Figure 4 As shown, the electronic device may include a processor 410, a communication interface 420, a memory 430, and a communication bus 440, wherein the processor 410, the communication interface 420, and the memory 430 communicate with each other through the communication bus 440. The processor 410 can call logical instructions in the memory 430 to execute a method for invoking natural language to data services. This method includes: obtaining a target data query request in a target scenario; inputting the target data query request into a conversion model to obtain a target service invoking instruction output by the conversion model. The target service invoking instruction includes a target application programming interface (API) and target API parameters. The conversion model is generated based on a target large model supporting data query services in the target scenario and a target corpus corresponding to the target scenario. The target API and the target API parameters are used to obtain the query results of the target data query request.

[0069] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0070] On the other hand, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements a method for executing natural language to data service invocation instructions provided by the above methods. The method includes: obtaining a target data query request in a target scenario; inputting the target data query request into a conversion model to obtain a target service invocation instruction output by the conversion model, wherein the target service invocation instruction includes a target application programming interface (API) and target API parameters; the conversion model is generated based on a target large model supporting data query services in the target scenario and a target corpus corresponding to the target scenario; and the target API and the target API parameters are used to obtain the query results of the target data query request.

[0071] In another aspect, this application also provides a computer program product, including a computer program that, when executed by a processor, implements a method for invoking a natural language to data service as described above. The method includes: obtaining a target data query request in a target scenario; inputting the target data query request into a conversion model to obtain a target service invoking instruction output by the conversion model, wherein the target service invoking instruction includes a target application programming interface (API) and target API parameters; the conversion model is generated based on a target large model supporting data query services in the target scenario and a target corpus corresponding to the target scenario; and the target API and the target API parameters are used to obtain the query results of the target data query request.

[0072] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0073] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0074] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for converting natural language into data service invocation instructions, characterized in that, include: Obtain the target data query request in the target scenario; The target data query request is input into the transformation model to obtain the target service call instruction output by the transformation model. The target service call instruction includes the target application programming interface (API) and the target API parameters. The transformation model is generated based on the target large model that supports data query services under the target scenario and the target corpus corresponding to the target scenario. The target API and the target API parameters are used to obtain the query results of the target data query request.

2. The method according to claim 1, characterized in that, The conversion model is generated based on the following method: Obtain the target large model that supports data query services under the target scenario; Obtain the target corpus corresponding to the target scene; The target corpus in the target corpus is input into the target large model, and the natural language to data service capability of the target large model is transferred to the base model through knowledge distillation to obtain the reference model; The reference model is fine-tuned based on the target corpus to obtain the transformation model.

3. The method according to claim 2, characterized in that, The step of obtaining the target corpus corresponding to the target scene includes: Determine the proprietary data types for the target scenario; Obtain the proprietary vocabulary corpus corresponding to the proprietary data type; Obtain the question-and-answer dataset corresponding to the data query request in the target scenario, wherein the question-and-answer dataset includes multiple initial question-and-answer pairs; The data query requests in the target scenario from the multiple initial question-answer pairs are decomposed to obtain the question decomposition corpus; Based on the multiple initial question-and-answer pairs, obtain the API and API parameter corpus selected for the data query request in the target scenario; Multiple reference question-answer pairs are obtained by decomposing the corpus of the question and the corpus of the API and API parameters; The target corpus is generated based on the proprietary vocabulary corpus and the multiple reference question-and-answer pairs.

4. The method according to claim 3, characterized in that, The step of fine-tuning the reference model based on the target corpus to obtain the transformation model includes: Acquire reference question-and-answer pairs generated during the knowledge distillation process; The reference question-and-answer pairs are validated to obtain the target question-and-answer pairs; The reference model is fine-tuned based on the proprietary vocabulary corpus in the target corpus and the target question-answer pair to obtain the transformation model.

5. The method according to claim 2, characterized in that, The step of fine-tuning the reference model based on the target corpus to obtain the transformation model includes: The reference model is fine-tuned based on the target corpus to obtain the target model; The floating-point parameters in the target model are converted into integer representations to obtain the transformed model.

6. The method according to any one of claims 2-5, characterized in that, The method further includes: Construct an intermediate layer that supports multiple query types, where the query type indicates the data type requested for the target scenario; Retrieve the technical terms corresponding to each preset operation type; The technical terms are written into the intermediate layer, which is used to assist in determining the target API and the target API parameters.

7. An apparatus for issuing natural language to data service invocation instructions, characterized in that, include: The acquisition unit is used to acquire target data query requests in the target scenario. The input unit is used to input the target data query request into the transformation model to obtain the target service call instruction output by the transformation model. The target service call instruction includes the target application programming interface (API) and the target API parameters. The transformation model is generated based on the target large model that supports data query services under the target scenario and the target corpus corresponding to the target scenario. The target API and the target API parameters are used to obtain the query results of the target data query request.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the method of invoking natural language to data service as described in any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of invoking natural language to data service instructions as described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of invoking natural language to data service instructions as described in any one of claims 1 to 6.

Images