A method, apparatus, medium, and device for generating query statements based on a large model.

By identifying and completing the steps and logical relationships in the business logic process using a large language model, and generating query statements, the problem of the lack of utilization of the deep semantics of SOPs in existing technologies is solved, and efficient and automated execution of the business logic process is achieved.

CN120541191BActive Publication Date: 2025-10-28ZHEJIANG ANT MISUAN TECHNOLOGY CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202511036717.6
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2025-07-25
Publication Date
2025-10-28
Estimated Expiration
2045-07-25

AI Technical Summary

Technical Problem

The application of standard operating procedures (SOPs) in the current technology is still at a basic level of text processing, failing to fully explore their deep semantic information, resulting in the inefficient use of knowledge in SOPs.

Method used

By acquiring the business logic process described in natural language, a pre-trained Large Language Model (LLM) is used to identify and complete the steps and logical relationships in the business logic process, and to generate query statements for the business data structure.

Benefits of technology

It enables deep semantic analysis of business logic processes, generates directly executable query statements, reduces manual intervention, and improves the efficiency and value extraction of automated SOP execution.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120541191B_ABST
    Figure CN120541191B_ABST
Patent Text Reader

Abstract

This specification discloses a query statement generation method based on a large model. This method inputs a business logic process described in natural language into a pre-trained LLM (Large Module). The LLM identifies the steps within the business logic process and the logical relationships between them, and completes the implicit steps within the process to determine the complete steps and their logical relationships. Finally, it generates corresponding query statements based on the business data structure. This method, by inputting the business logic process into an LLM, generates the implicit steps within the process, resulting in a complete business logic process. This allows for the generation of corresponding query statements using the LLM, extending the utilization of the business logic process beyond basic text processing to further analyze its implicit semantics and generate directly executable query statements to support business execution.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a method, apparatus, storage medium and device for generating query statements based on a large model. Background Technology

[0002] A Standard Operating Procedure (SOP) is a document that details a workflow and steps. Typically, an SOP contains a detailed process for a specific business, product, or service, for users to refer to and follow during operation. Through the accumulation of business operations, SOPs contain a wealth of valuable experience and knowledge; therefore, effectively utilizing SOPs is one of the important applications.

[0003] In current technologies, the application of Standard Operating Procedures (SOPs) remains at a rudimentary stage of text processing. For example, SOPs are categorized to quickly retrieve the appropriate SOP for different situations. Alternatively, keywords are extracted from SOPs for automatically populating work orders, forms, and other documents. Clearly, current technologies do not fully exploit the deeper semantic information within SOPs.

[0004] Therefore, how to make more efficient use of the knowledge in SOPs has become an urgent problem to be solved. Thus, this manual provides a method for generating query statements based on a large model. Summary of the Invention

[0005] This specification provides a method, apparatus, storage medium, and electronic device for generating query statements based on a large model, in order to partially solve the problems existing in the prior art.

[0006] The embodiments in this specification adopt the following technical solutions:

[0007] This specification provides a method for generating query statements based on a large model, the method comprising:

[0008] Obtain the business logic process described in natural language;

[0009] The business logic process is input into a pre-trained large language model (LLM).

[0010] The LLM identifies the steps included in the business logic process, determines the implicit steps in the business logic process, and determines the logical relationships between the obtained steps.

[0011] Based on the business data structure corresponding to the business logic process, and according to the obtained steps and the logical relationship, a query statement is generated for execution against the business data structure. The query statement is used to implement the business logic process.

[0012] This specification provides a query statement generation device based on a large model, the device comprising:

[0013] The acquisition module is used to acquire business logic processes described in natural language.

[0014] The input module is used to input the business logic process into a pre-trained large language model (LLM).

[0015] The identification module is used to identify each step included in the business logic process through the LLM, determine the implicit steps in the business logic process, and determine the logical relationship between the obtained steps.

[0016] The generation module, based on the business data structure corresponding to the business logic process, generates a query statement for execution against the business data structure according to the obtained steps and the logical relationship. The query statement is used to implement the business logic process.

[0017] This specification provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described query statement generation method based on a large model.

[0018] This specification provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the above-described query statement generation method based on a large model.

[0019] The above-described at least one technical solution adopted in the embodiments of this specification can achieve the following beneficial effects:

[0020] This specification discloses a query statement generation method based on a large model. The method inputs a business logic process described in natural language into a pre-trained LLM (Large Module). The LLM identifies the steps within the business logic process and the logical relationships between them, and completes the implicit steps within the process to determine the complete steps and their logical relationships. Finally, based on the business data structure targeted by the query, the corresponding query statement is generated. This method, by inputting the business logic process into an LLM, generates the implicit steps within the process, resulting in a complete business logic process. This allows for the generation of corresponding query statements using the LLM, extending the utilization of the business logic process beyond basic text processing to further analyze its implicit semantics and generate directly executable query statements to support business execution. Attached Figure Description

[0021] The accompanying drawings, which are included to provide a further understanding of this specification and form part of this specification, illustrate exemplary embodiments and are used to explain this specification, but do not constitute an undue limitation thereof. In the drawings:

[0022] Figure 1 A flowchart illustrating a query statement generation process based on a large model, provided for embodiments of this specification;

[0023] Figure 2 A schematic diagram provided for the embodiments of this specification to supplement the implicit steps;

[0024] Figure 3 A schematic diagram of a query statement generation device based on a large model provided in the embodiments of this specification;

[0025] Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this specification. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0027] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0028] Figure 1 A flowchart for generating query statements based on a large model, provided for embodiments of this specification, specifically includes the following steps:

[0029] S100: Obtain the business logic process described in natural language.

[0030] In the embodiments described in this specification, the following are employed: Figure 1 The device used to generate the query statement using the method shown can be any electronic device, such as a computer, server, or server cluster consisting of multiple servers. For ease of description, the following explanation uses a server as an example.

[0031] To generate a query statement for executing a specific business operation, the server first obtains the business logic process for that operation. Specifically, the business logic process described in this specification includes Standard Operating Procedures (SOPs). An SOP is a standard operating procedure for that business operation, described in natural language. It is a document that details the work, workflow, and steps involved in that business operation. It provides the organization's internal standard process specifications for reference and adherence by internal personnel. In addition to the standardized process for that business operation, the SOP also includes clearly defined responsibilities and authorities for each role within the business, emergency measures, quality standards and assessments, document management, and other related content.

[0032] Because the business logic process described in natural language in this specification includes Standard Operating Procedures (SOPs), it contains steps of business operations and the logical relationships between these steps. By processing these business logic processes further, query statements can be generated to implement them. Executing these queries improves the utilization of the business logic process and SOPs, fully leveraging the deeper semantic information within the SOPs rather than simply performing text processing. This ensures that the business logic process and SOPs are not merely specification documents guiding users.

[0033] This specification does not specify what kind of business logic process is being referred to. For example, the business logic process may be a marketing business process, which includes SOPs for marketing processes targeting users, or a project management business logic process, which includes SOPs for cross-departmental collaboration.

[0034] For ease of description, the embodiments in this specification will only use the business logic process of risk control business as an example for explanation. That is, taking the above-mentioned business as a risk control business as an example, the query statement generation method provided in this specification will be explained.

[0035] When the above-mentioned business involves risk control based on recorded risk logs, the business logic process of this risk control business (i.e., the risk control logic process) can be roughly illustrated as follows:

[0036] The first step is to obtain the target field;

[0037] The second step is to check which danger level the value of the target field falls into.

[0038] The third step is to send corresponding attack alarm information based on the level of danger of the incident.

[0039] Of course, the above is just an illustration. In actual business logic, the operations to be performed in each step are generally described in more specific natural language. For example, the second step may include: checking the operation frequency of the same device / IP; if it is greater than 5 times / minute, it falls into the medium-risk level; checking the payment limit for newly created accounts; if the payment limit is greater than 5,000 yuan, it falls into the high-risk level; and checking the number of accounts registered by the same device / IP; if it is greater than 3, it falls into the low-risk level.

[0040] As can be seen, the process involving the first step of obtaining the target field and the second step of determining the risk level is equivalent to querying business data. When implemented through a query statement, this process may involve multiple data query steps. For example, it may be necessary to first obtain the operation data of each account to determine active accounts, then obtain the account data of each active account to determine recently registered active accounts, and then obtain other business data to determine accounts with transaction amounts greater than 5000 as the query results that fall into the high-risk category.

[0041] The aforementioned risk log is a risk log of other businesses recorded by the user when performing other businesses, and the aforementioned risk control business is the business that needs to perform risk control on the other businesses based on the risk log.

[0042] S102: Input the business logic process into a pre-trained large language model (LLM).

[0043] After obtaining the aforementioned business logic process, the server can input this natural language description of the business logic process into a pre-trained Large Language Model (LLM). This LLM can be pre-deployed on the server, or it can be deployed on other devices. If deployed on other devices, the server can send the business logic process to those devices, allowing them to input the received business logic process into the LLM. The following explanation uses the deployment of the LLM on the server as an example.

[0044] Of course, since business logic processes are usually set based on human experience, to avoid omissions or logical errors in the business logic process, in this embodiment, the server directly outputs the actual business logic process obtained in step S100 into the LLM. The LLM then uses this business logic process to identify the implicit steps within it and generates query statements to implement the business logic process. This avoids situations where query statements generated directly by the LLM cannot be executed or have conflicts during execution, thus improving the accuracy and reliability of the query statements generated by the LLM.

[0045] S104: Identify the steps included in the business logic process through the LLM, determine the steps implicit in the business logic process, and determine the logical relationship between the obtained steps.

[0046] Generally, a business logic process consists of several steps arranged according to certain logical relationships. As in the example above, by executing each step sequentially, the type of attack alert information to send can be determined. Translated into a data query process, this involves query statements based on different query conditions to filter business data. In more complex business logic processes, different logical relationships between multiple steps may be involved. For example, high-frequency and high-value transactions for new users are both determined by further filtering intermediate results obtained from queries about new users.

[0047] Therefore, the data query process included in a business logic process can be regarded as consisting of the logical relationship between the steps of each query process and the specific content of executing each step. Thus, in order to generate query statements to implement the business logic process, LLM needs to identify the steps included in the business logic process and the logical relationship between the steps based on the natural language description of the business logic process.

[0048] Specifically, this LLM can generate the query statements required to implement the business logic process in two stages. In the first stage, the LLM identifies the data query content involved in the business logic process, determines the steps of each query directly described in the business logic process, and identifies the logical relationships between these steps. In the second stage, based on each step and the logical relationships between them, it identifies the implicit steps in the business logic process. Finally, it generates the text of the implicit steps and determines the implicit steps and the logical relationships between them.

[0049] Because the business logic involves data querying, it may only describe the core content that needs to be executed, while implicit query steps or conditions are not directly written into the business logic process. This is because in some business scenarios, the business logic process, as a standard, is only intended for reference and standardization of manual operations. Therefore, the machine recognition situation was not considered when setting it up, and there is a possibility that conditions that users should know by common sense or that the business should know may be omitted.

[0050] Therefore, to ensure the accuracy and reliability of the generated query statements, when identifying the content of the data query, the server, after determining the directly stated steps and logical relationships between them in the business logic process, can analyze the input and output of the directly stated steps and the logical relationships between them to identify the steps implicit in these logical relationships. Finally, based on the directly identified steps and the identified implicit steps, logical reasoning is performed to determine the logical relationships between all steps.

[0051] For example, suppose the risk control SOP states, "Conduct loan checks on applicants: if the number of inquiries in the past month exceeds 5, automatically reject the application." This clearly requires querying the applicant's loan check results. A potentially implicit part of this is querying a third-party credit reporting cache. From a human experience perspective, besides internal loan inquiries, external credit data should also be relied upon, not just internal business data. However, since business logic processes are generally executed "internal," queries that routinely need to be executed externally are not directly written into the business logic process. Therefore, the SOP in the business logic process identifies the following steps: Step 1: Query internal business data to determine the number of queries within one month; Step 2: Identify users with more than 5 queries; the implicit step 4 could be: the external credit information of users with no more than 5 queries in the credit reporting database; and finally, Step 3: Based on the two query results, determine the final query results for users requiring risk control.

[0052] Figure 2 This diagram illustrates the supplementary steps provided in this specification. The SOP on the left represents the SOP within the business logic process, which is the object of step analysis and includes the textual content of the SOP. Steps 1-3 are the steps and logical relationships directly determined based on the SOP, while step 4 is a supplementary implicit step. This step requires the query result from step 1 as input and outputs content supporting the final query result. Step 3 is executed based on the output results of steps 2 and 4. Step 4 and its logical relationships with other steps are represented by dashed lines, indicating that the relevant content is supplemented through LLM reasoning. As shown in the diagram, the left-hand arc marking "Identification" indicates that steps 1-3 are obtained from the SOP, and the right-hand arc marking "Supplementation" indicates that step 4 and its supplementary logical relationships are provided.

[0053] Furthermore, since identifying the various steps of data querying and the logical relationships between these steps within the business logic process may require a knowledge base corresponding to that business logic process, in this embodiment, the knowledge base corresponding to the business logic process can be pre-injected into the pre-trained LLM. This knowledge base may include at least one of the following:

[0054] The knowledge graph corresponding to this business logic process includes conceptual descriptions of each entity required in the business logic process (used to describe what the entity is, such as the concepts of user and number of operations in the example above), attributes of each entity (used to describe all possible attributes of the entity in this business logic), and relationships between entities.

[0055] After injecting the knowledge base containing the knowledge graph corresponding to the business logic process into the pre-trained LLM, when the server inputs the business logic process described in natural language into the LLM, the LLM can, based on its own reasoning ability, identify the semantics of the business logic process described in natural language, determine the semantics of the data query process involved in the business logic process, and determine that the concepts involved are mapped to entities in the knowledge graph. Then, based on the semantics, the data query process is broken down into several specific query steps. Finally, based on the semantics of the data query process, the logical relationships between each step are inferred.

[0056] Of course, this manual only describes the process of generating query statements based on business logic. Therefore, it is obvious that some steps in the business logic process are not implemented through query statements. For example, determining the query results of high-risk accounts based on conditions and then sending the corresponding query results to the risk control department or legal department is not a step implemented by the query statements generated in this manual.

[0057] It should be noted that the data query steps generated by LLM in step S104 are still expressed in natural language within the business logic process. In other words, the data query steps and the relationships between them within the business logic process have been supplemented and improved.

[0058] S106: Based on the business data structure corresponding to the business logic process, and according to the obtained steps and the logical relationship, generate a query statement to be executed against the business data structure. The query statement is used to implement the business logic process.

[0059] In the embodiments of this specification, after obtaining the refined steps and their logical relationships through the LLM, the server can generate an executable query statement based on natural language reasoning and the business data structure of the target business data. This query statement is used to implement the data query portion involved in the business logic process. For example, the first and second steps in step S100, while the final third step of sending alarm information can be implemented manually. For example, after generating the query statement according to the business logic process, the query statement is executed on the business data to obtain and display the query results, allowing the user to send alarm information based on the query results. Of course, the third step can also be executed automatically through pre-set program code; this specification does not limit this and it can be set as needed.

[0060] Specifically, the server can fill the business data structure, each step, and the logical relationships into a pre-set prompt template as input for natural language. The LLM then outputs an executable query statement corresponding to the business data structure. For example, the prompt template might be "Based on the steps recorded in ... and the logical relationships between the steps, generate a query statement to be executed on the data of the ... structure," where the first ellipsis represents the steps and logical relationships, and the second ellipsis represents the business data structure. The pre-trained LLM can then output a query statement to be executed on that business data structure, realizing the data query process within the business logic.

[0061] based on Figure 1 The query generation method based on a large model, as shown, inputs a business logic process described in natural language into a pre-trained LLM. The LLM identifies the steps within the business logic process and the logical relationships between them, and completes the implicit steps within the process to determine the complete steps and their logical relationships. Finally, based on the business data structure targeted by the query, the corresponding query is generated. This method, by inputting the business logic process into an LLM, generates the implicit steps within the process, resulting in a complete business logic process. This allows for the generation of corresponding query statements through the LLM, extending the utilization of the business logic process beyond basic text processing to further analyze its implicit semantics and generate directly executable query statements to support business execution.

[0062] This allows existing business logic processes described in natural language, or their Standard Operating Procedures (SOPs), to be further utilized to obtain query statements that can be executed automatically. This significantly reduces the amount of manual intervention required during the execution of such standards, further unlocking the value of SOPs.

[0063] To facilitate a further understanding of the methods provided in this specification, an example corresponding to steps S100 to S106 is provided in the embodiments of this specification to demonstrate how to supplement the implicit steps in the business logic process through step S104.

[0064] For example, suppose that in step S100, the server obtains a Standard Operating Procedure (SOP), and the content of the SOP is:

[0065] ##SOP Rules

[0066] Subjects containing salary, subsidies, or allowances, and sent from email addresses not related to the company, will be treated as phishing emails and handled as incidental cases.

[0067] It is evident that the SOP is an event processing method described in natural language. After the SOP rules are input into the LLM in step S102, the LLM can identify the steps contained in the SOP and the logical relationships between the steps through a logical reasoning process.

[0068] Specifically, the LLM can identify the following results: the first step is to "query the email subject", "the subject includes salary, subsidies, and allowances", and "the sender's email address is not related to the company". The second step is to treat the query results of the first step as phishing emails and handle them as incidents. The third step is to identify situations outside the set of query results of the first step as normal behavior and not take any action.

[0069] Continuing with the LLM's logical reasoning based on the identification results, it's determined that the above process lacks specific information to determine how to identify company-related information. Specifically, the LLM can deduce that the implicit fourth step in the above process is to determine whether the email address contains "@company.com". The logical relationship between the steps is then redefined: steps one and four are executed in parallel or sequentially. Step two involves determining whether to treat the email as a phishing email and handle it as an event based on the query results from steps one and four. Step three remains unchanged. Therefore, the corresponding query statement in this SOP actually only involves the combined query results from steps one, two, and three; that is, this part needs to generate the query statement.

[0070] Therefore, in the final step S106, the server can generate a query statement based on the business data structure and the results determined in step S104:

[0071] GQL:

[0072] MATCH (m:Mail)-[:SEND]->(p:Person)

[0073] WHERE NOT m.sender CONTAINS '@company.com'

[0074] AND m.title =~ '.(Salary|Subsidy|Allowance).'

[0075] RETURN m, p

[0076] As can be seen, the query returns results that match the conditions, allowing subsequent business processes to execute the "treat as a phishing email" business operation based on the returned m and p. The conditions include "m.title =~ '.(Salary|Subsidy|Allowance)" in the SOP text (meaning the email subject contains salary, subsidies, and allowances), "m.senderCONTAINS '@company.com'" (meaning the sender's email address is not company-related), and the matching result is the email and the user "(m:Mail)-[:SEND]->(p:Person)". The final returned query result is also Mail and Person.

[0077] The third step in the subsequent SOP process can then be based on the query results to handle phishing emails. The specific implementation can follow the usual risk control methods for dealing with phishing emails. Of course, the above example is merely one illustration of the implementation in this specification. Therefore, how to specifically handle phishing emails is not a technical problem to be solved by this specification, and this specification does not limit the method used; it can be set as needed.

[0078] Furthermore, this specification does not limit the specific structure of the business data; it can be set as needed. Of course, in risk control business scenarios, risk control logs are generally used as business data. However, risk control logs contain a lot of noise and lack relationships between data points. Therefore, in one or more embodiments of this specification, the server can process the risk control logs, converting them into graph data. The query statement generated by the LLM will then be a graph query statement using Graph Query Language (GQL).

[0079] Therefore, at least before the LLM generates a query statement, the server needs to process the risk control logs to obtain graph data for querying.

[0080] Specifically, the server can first obtain pre-recorded business logs. Taking risk control as an example, the server will obtain risk control logs at this time.

[0081] Secondly, a pre-trained Large Language Model (LLM) is used to identify entities and relationships within the business logs. As mentioned earlier, the knowledge graph of the business is pre-imported into the LLM, enabling it to identify entities within the business scenario. Taking risk control as an example, the entities to be identified may include IP addresses, ports, account IDs, and user identifiers. Similarly, the LLM can use the knowledge graph to determine, for example, access relationships and attack relationships, among other things, the temporal relationships between entities in the risk control scenario.

[0082] Finally, using each entity as a node and the relationships between entities as edges, a graph data corresponding to the business data is constructed.

[0083] Furthermore, in the embodiments of this specification, the server can preprocess the risk control logs before constructing the graph data, removing irrelevant information and extracting the content of key fields to avoid identifying unnecessary entities or relationships during the LLM inference process. "Unnecessary" refers to information that is not essential for the risk control business; obviously, the irrelevant information to be removed will not be entirely the same for different businesses. Of course, existing mature technologies can be used for log cleaning, such as filtering necessary field content based on field names and keyword tables. This specification does not impose restrictions on this and can be set as needed.

[0084] In the embodiments described in this specification, before inputting the business logic process into the LLM, the server can also perform text cleaning and formatting on the business logic process to avoid irrelevant information in the business logic process or its contained SOPs, while unifying the description in natural language. This reduces ambiguity in description and improves the accuracy and consistency of the generated query statements.

[0085] Furthermore, in this embodiment of the specification, to further improve the usability of the generated query statement, the server can send the query statement as a verification statement to the user terminal before executing it. Then, it receives the verified statement returned by the user terminal and executes the verified statement in the established runtime environment. In other words, the query statement is reviewed through a human-computer interaction process. Since the corresponding maintenance personnel do not need to write query statements from scratch, the efficiency of data querying based on business logic processes is greatly improved, and operating costs are reduced.

[0086] Furthermore, in the embodiments of this specification, after receiving the query statement, the server can execute the query statement on the business data of the corresponding business. Specifically, the server can first run the runtime environment of the query statement and load the business data of the business corresponding to the business logic process, that is, the graph data. Then, based on the graph data, the query statement is run through the runtime environment. Finally, the query result of the query statement is determined, and the business continues to be executed based on the query result.

[0087] In the embodiments of this specification, when the query statement generation process is executed using graph data for a risk control business scenario, the server first executes the graph query statement generated in step S106 in the runtime environment based on the graph data corresponding to the business data. Specifically, in the case of a risk control business scenario, the business logic process in step S100 includes a risk control SOP; therefore, the graph query statement can be used to query for elements in the graph data that are required for risk control.

[0088] Therefore, after executing the graph query statement, the server can obtain the query results in the graph data, that is, at least one of the nodes and edges in the graph data.

[0089] Subsequently, since the entities corresponding to nodes in the graph data can be users, activities, etc., and edges represent relationships between entities, typically business events between them, the server can determine at least one risky entity and risky business event based on the nodes and edges in the graph data contained in the query results. Of course, determining the specific risk depends on the content of the query results. If the query results only contain nodes, then the entities are at risk, but there is no direct relationship indicating risk. If the query results only contain edges, then a certain type of business event directly poses a risk.

[0090] Then, based on the connections between nodes and edges in the graph data, the server can further identify risky elements in the graph data besides the query results. Specifically, based on preset risk control rules, it can determine whether there are other risky elements in the graph data besides the query results. For example, the risk control rule could be "entities connected by risky edges are also risky," or "edges between risky nodes are also risky," thereby extending to identify other risky elements not found in the query statement, that is, content not covered by the SOP but also posing a risk.

[0091] Finally, based on the identified risky business events and / or entities, corresponding risk control measures are implemented. Of course, the specific risk control operations to be performed can also be determined by preset risk control rules, which will not be elaborated on in this manual.

[0092] Furthermore, in the embodiments described in this specification, the server can also generate security decision suggestions based on the query results, and visualize event information and response measures. For example, it can display the risk elements in the graph data determined according to the SOP, and show the query results in the graph data to identify and display the risk control operations that need to be performed, helping relevant users, such as security engineers, to make decisions and take further actions based on the displayed content. Specifically, the server can determine the query results and the risk control operations to be performed in the graph data, and send them to the user terminal, so that the user terminal can display the query results and the risk control operations to be performed, prompting the user to make risk control decisions. For example, executing the risk control operations determined by the server, or selecting more potentially risky nodes or edges in the graph data, etc.

[0093] In the embodiments of this specification, in order for the LLM to accurately convert the business logic process described in the input natural language into the above query statement, it is not enough to simply inject the knowledge graph corresponding to the business logic process into the LLM. It is also necessary to fine-tune and train the LLM in advance under the business scenario corresponding to the business logic process.

[0094] Specifically, when fine-tuning the LLM, a sample logical process described in natural language can be obtained first. This sample logical process also contains several steps, referred to below as the sample step. This sample logical process and the aforementioned business logical process are business logical processes within the same business scenario; that is, the knowledge graph corresponding to the sample logical process is exactly the same as the knowledge graph corresponding to the aforementioned business logical process.

[0095] After obtaining the sample logic process, it can also be done through... Figure 1 Steps S102-S106, as shown, involve inputting the sample logic process into the LLM to be trained. The LLM identifies each sample step within the sample logic process, determines the implicit sample steps within the process, and identifies the logical relationships between these steps. Based on these logical relationships and the business data structure, an optimized statement is generated that executes against the business data structure. This optimized statement is used to implement the sample logic process. The process of generating the optimized statement is similar to... Figure 1 The steps S102 to S106 shown are exactly the same, so they will not be repeated here.

[0096] After the LLM to be trained generates the statement to be optimized, the optimized statement can be determined after adjustments. Since the statement to be optimized is also a query statement in form, it can be manually adjusted to ensure that the steps and logical relationships between them fully conform to the data query process in the original sample logic. Of course, the statement to be optimized can also be adjusted using other trained LLMs; this embodiment does not limit this approach.

[0097] After obtaining the optimized statements, supervised fine-tuning (SFT) training can be performed on the LLM to be trained based on these optimized statements. That is, the optimized statements are used as annotations corresponding to sample logic processes, serving as supervisory signals to adjust the model parameters in the LLM to be trained. This allows the LLM to adapt to generating various business logic processes within the given business scenario. The device used to train the LLM is the same as the aforementioned execution... Figure 1 The query statement shown can be generated by the same device or different devices. Furthermore, because this embodiment aims to preserve the original inference capabilities of the LLM as much as possible, adapting it only to this business scenario, when performing SFT on the LLM, not all model parameters are adjusted, but only some model parameters are adjusted.

[0098] After obtaining the LLM through the SFT training described above, the server can then... Figure 1 The method shown generates the query statement corresponding to the business logic process in this business scenario.

[0099] Furthermore, adjustments are made in stages when performing SFT on the LLM. Since the requirements for supplementing the implicit steps and perfecting the LLM's output query statement are different, training them separately avoids conflicts between multiple tasks. Specifically, the process of supplementing the implicit steps still outputs a natural language description of the steps and their relationships, while the process of generating the query statement is based on natural language text and outputs machine language (the query statement).

[0100] Similar to the SFT process of LLM described above, during the training of LLM to supplement the implicit steps, the server can delete some data query content in the business logic process and use it as the sample business logic process. The original business logic process is then used as the optimized business logic process.

[0101] Specifically, when fine-tuning the LLM, the original logical process described in natural language can be obtained first. This original logical process also contains several steps, referred to below as the sample steps. This original logical process and the aforementioned business logical process are business logical processes within the same business scenario; that is, the knowledge graph corresponding to the original logical process is exactly the same as the knowledge graph corresponding to the aforementioned business logical process.

[0102] After obtaining the original logic process, at least one sample step involving data querying is deleted from this original logic process, and the resulting sample logic process is used as the input. Then, it can be done similarly... Figure 1 Steps S102-S104, as shown, identify each sample step in the sample logic process using the LLM to be trained, determine the implicit sample steps (i.e., deleted sample steps) in the sample logic process, and determine the logical relationships between the obtained sample steps, which serve as the logic process to be optimized. The specific step generation process and the logical relationship supplementation process are described below. Figure 1 The steps S102 to S104 shown are exactly the same, so they will not be repeated here.

[0103] After the LLM to be trained generates the logic process to be optimized, the original logic process can be identified as the annotation of the sample logic process, and the LLM to be trained can be fine-tuned. This fine-tuning process involves not only adjusting the parameters of the supplementary sample steps in the LLM, but also adjusting the parameters of the LLM based on the logical relationships between the supplementary sample steps and other sample steps. Therefore, the logic process to be optimized obtained from the LLM to be trained can be considered as a whole, rather than just performing SFT based on the supplementary implicit sample steps. Furthermore, since the logic process to be optimized is also in the form of natural language, it can also be manually adjusted to ensure that the steps and the logical relationships between steps fully conform to the data query process in the original logic process, and then used as annotation for SFT. Of course, the methods for determining the annotation of the sample logic process are not limited in this embodiment and can be set as needed.

[0104] Continuing, regardless of the method used to obtain the optimized logic process corresponding to the sample logic process, supervised fine-tuning training (SFT) can be performed on the LLM to be trained based on this optimized logic process. The optimized logic process is used as a supervisory signal to adjust the model parameters in the LLM to be trained, making the LLM adaptable to the implicit steps in generating various business logic processes under this business scenario, as well as the logical relationships between these implicit steps. The device used to train the LLM to be trained is the same as the aforementioned execution... Figure 1The query statement shown can be generated by the same device or different devices. Furthermore, because this embodiment aims to preserve the original inference capabilities of the LLM as much as possible, adapting it only to this business scenario, when performing SFT on the LLM, not all model parameters are adjusted, but only some model parameters are adjusted.

[0105] Those skilled in the art should understand that the above description uses a business logic process as an example of a risk control logic process. In fact, the query statement generation method provided in the embodiments of this specification can generate query statements corresponding to business logic processes in any business scenario and run them accordingly. Furthermore, the above query statements are only illustrated using graph query statements as an example. The structure of business data in the embodiments of this specification can also be in other forms, and the corresponding query statements will also be of the corresponding type.

[0106] Additionally, it should be noted that the implicit steps supplemented by LLM in the example of step S102 are not query statements executed on business data. However, this is just an example, and the embodiments in this specification do not limit whether the steps are for business data or external data. As long as the query statement required for business execution is supported, it can be supplemented by LLM. As described in the aforementioned SFT process of LLM, samples and annotations can be constructed by reducing the complete business logic process, thereby achieving supervised training.

[0107] The above is an example of a query statement generation method based on a large model provided in this specification. Based on the same idea, this specification also provides corresponding devices, storage media and electronic devices.

[0108] Figure 3 This is a schematic diagram of a query statement generation device based on a large model, provided in an embodiment of this specification. The device includes:

[0109] Module 201 is used to acquire business logic processes described in natural language.

[0110] Input module 202 is used to input the business logic process into a pre-trained large language model (LLM);

[0111] The identification module 203 is used to identify each step included in the business logic process through the LLM, determine the steps implicit in the business logic process, and determine the logical relationship between the obtained steps.

[0112] The generation module 204 is used to generate a query statement for execution against the business data structure based on the business data structure corresponding to the business logic process, according to the obtained steps and the logical relationship. The query statement is used to implement the business logic process.

[0113] Optionally, the identification module 202 is used to identify each step included in the business logic process and the logical relationship between the steps through the LLM, wherein each step is text described in natural language, identify the implicit steps in the business logic process according to the steps and the logical relationship between the steps, generate the text of the implicit steps, and determine the implicit steps and the logical relationship between the steps.

[0114] Optionally, the device further includes:

[0115] The running module 205 runs the runtime environment of the query statement, loads the business data corresponding to the business logic process, runs the query statement through the runtime environment based on the business data, determines the query result of the query statement, and continues to execute the business based on the query result.

[0116] Optionally, the running module 205 is further configured to acquire the business logs pre-recorded by the business, identify each entity in the business logs and the relationships between the entities through a pre-trained Large Language Model (LLM), and construct graph data corresponding to the business data with each entity as a node and the relationships between the entities as edges.

[0117] Optionally, the business logic process includes a risk control logic process;

[0118] The business logs are risk logs;

[0119] The query statement includes a graph query statement.

[0120] Optionally, the running module 205 is configured to execute the graph query statement in the running environment based on the graph data corresponding to the business data to obtain the query result of the graph data, wherein the query result includes at least one of nodes and edges in the graph data; determine the business events and / or entities with risks based on the nodes and edges in the graph data included in the query result; and execute the corresponding risk control business for the business events and / or entities with risks according to the preset risk control rules.

[0121] Optionally, the running module 205 is further configured to send the query statement as a statement to be verified to the user terminal, and in response to the verified statement returned by the user terminal, run the verified statement through the running environment.

[0122] Optionally, the device further includes:

[0123] Training module 206 is used to acquire sample logic processes described in natural language, the sample logic processes containing several sample steps; identify each sample step contained in the sample logic process through the LLM to be trained, determine the implicit sample steps in the sample logic process, and determine the logical relationships between the obtained sample steps; based on the business data structure of the business corresponding to the sample logic process, and according to the logical relationships between each sample step, generate an optimization statement to be executed against the business data structure, the optimization statement being used to implement the sample logic process; determine the optimized statement after adjusting the optimization statement; and perform supervised fine-tuning training on the LLM to be trained based on the optimized statement.

[0124] This specification also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can be used to perform the query statement generation method based on the large model described above.

[0125] based on Figure 1 The query statement generation method based on a large model shown in this specification also provides embodiments that... Figure 4 The diagram shows the structure of the electronic device. Figure 4 At the hardware level, the electronic device includes a processor, internal bus, network interface, memory, and non-volatile storage, and may also include other hardware required for business operations. The processor reads the corresponding computer program from the non-volatile storage into memory and then runs it to implement the above-mentioned query statement generation method based on a large model.

[0126] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. A query statement generation method based on a large model, the method comprising: Obtain the business logic process described in natural language; The business logic process is input into a pre-trained large language model (LLM). The LLM identifies the steps included in the business logic process and the logical relationships between the steps, where each step is text described in natural language; the LLM then performs logical reasoning based on the steps and the logical relationships between them to identify the implicit steps in the business logic process. Generate the text of the implicit steps, and determine the implicit steps and the logical relationships between them; Based on the business data structure corresponding to the business logic process, and using the obtained steps and the logical relationship as input data, the LLM continues to generate query statements for execution against the business data structure. The query statements are used to implement the business logic process. The LLM is at least based on supervised fine-tuning of a sample logic process obtained by deleting steps involving data querying in the original logic process.

2. The method of claim 1, further comprising: Run the runtime environment for the query statement and load the business data corresponding to the business logic process; Based on the business data, the query statement is executed in the operating environment; Determine the query result of the query statement, and continue to execute the business based on the query result.

3. The method as described in claim 2, further comprising, before running the query statement in the runtime environment based on the business data: Obtain the business logs pre-recorded by the aforementioned business; The entity in the business log and the relationship between the entity are identified by a pre-trained Large Language Model (LLM). Using each entity as a node and the relationships between the entities as edges, construct graph data corresponding to the business data.

4. The method as described in claim 3, wherein the business logic process includes a risk control logic process; The business logs are risk logs; The query statement includes a graph query statement.

5. The method as described in claim 4, wherein the query statement is executed in the operating environment based on the business data, specifically including: Based on the graph data corresponding to the business data, the graph query statement is executed in the operating environment to obtain the query result of the graph data. The query result includes at least one of the nodes and edges in the graph data. Determine the query result of the query statement, and continue to execute business operations based on the query result, specifically including: Based on the nodes and edges in the graph data contained in the query results, identify the business events or entities that pose a risk. For business events or entities that pose risks, corresponding risk control measures are implemented according to pre-defined risk control rules.

6. The method as described in claim 2, wherein the query statement is executed through the runtime environment, specifically includes: The query statement is sent to the user terminal as a statement to be verified. In response to the verified statement returned by the user terminal, the verified statement is executed through the runtime environment.

7. The method as described in claim 1, wherein pre-training the LLM specifically includes: Obtain a sample logic process described in natural language, wherein the sample logic process includes several sample steps; The LLM to be trained identifies each sample step contained in the sample logic process, determines the implicit sample steps in the sample logic process, and determines the logical relationship between the obtained sample steps. Based on the business data structure of the business corresponding to the sample logic process, and according to the logical relationship between each sample step, an optimization statement is generated for execution of the business data structure. The optimization statement is used to implement the sample logic process. Determine the optimized statement after adjusting the statement to be optimized; Based on the optimized statement, supervised fine-tuning training is performed on the LLM to be trained.

8. A query statement generation device based on a large model, the device comprising: The acquisition module is used to acquire business logic processes described in natural language. The input module is used to input the business logic process into a pre-trained large language model (LLM). The identification module is used to identify each step in the business logic process and the logical relationship between the steps through the LLM, wherein each step is text described in natural language; to perform logical reasoning based on each step and the logical relationship between the steps to identify the implicit steps in the business logic process; to generate the text of the implicit steps and to determine the implicit steps and the logical relationship between the steps. The generation module is used to generate a query statement for execution against the business data structure based on the business data structure corresponding to the business logic process, according to the obtained steps and the logical relationship as input data, and the query statement is used to implement the business logic process. The LLM is at least based on supervised fine-tuning of a sample logic process obtained by deleting steps involving data querying in the original logic process.

9. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method described in any one of claims 1-7.

Citation Information

Patent Citations

  • Query statement generation method and device and computing equipment

    CN120256456A

  • Data processing method and device, equipment and storage medium

    CN120353816A