LLM-driven data query dependency retrieval method and device, equipment and medium

Abstract

The invention provides an LLM-driven data query dependency retrieval method and device, equipment and a medium, and relates to the technical field of large model data retrieval processing. The method comprises the following steps: acquiring a user query demand input into an LLM and a pre-constructed entity relationship library; extracting an associated entity from a user query demand, and extracting a query constraint corresponding to the associated entity to form an entity constraint pair; then, matching query rules among the associated entities from the entity relationship library to form a linear dependency chain type structure, and obtaining a query association chain; taking each associated entity in the query association chain with successful validity verification as an independent task node, and performing recursive retrieval query according to the association sequence number to obtain a task query result corresponding to the association sequence number; and finally, integrating task query results to obtain a structured strategy. According to the method, the problems of system flow redundancy, multi-generation strategy and step-by-step triggering of data query in the traditional step-by-step retrieval are solved.

Description

Technical Field

[0001] This invention relates to the field of large model data retrieval and processing technology, and more specifically, to an LLM-driven data query dependency retrieval method, apparatus, device, and medium. Background Technology

[0002] In the field of data retrieval, especially in complex query scenarios involving multiple entity relationships, traditional step-by-step retrieval methods are widely used in system implementation. Taking the retrieval of customer, order, and logistics order relationships as an example, traditional methods require triggering the system process in multiple rounds, with each round requiring the separate generation of a strategy and the invocation of the corresponding interface. Specifically, the first round generates a customer strategy using LLM and calls the entity relation database to obtain the customer ID; the second round generates an order strategy based on the results of the first round and calls the entity relation database to obtain the order number; the third round generates a logistics order strategy based on the results of the second round and calls the entity relation database to obtain the logistics information. While this step-by-step triggering method can complete the task, it has significant drawbacks: First, the system process is redundant, requiring the separate generation of a strategy and waiting for the completion of previous tasks for each trigger; second, the multiple strategy generation by LLM increases computational overhead and time costs; and finally, the step-by-step invocation of the entity relation database results in a long overall time consumption, especially when more related entities or complex dependencies are involved.

[0003] To address these issues, existing technologies attempt to improve efficiency by optimizing strategy generation and data querying methods, but they do not fundamentally change the essential logic of step-by-step triggering. For example, some solutions reduce time consumption by caching intermediate results or processing some tasks in parallel, but due to the lack of unified planning for the entire chain of dependencies, the problems of multiple rounds of triggering and dependency waiting cannot be avoided. In addition, traditional methods often need to regenerate strategies or adjust execution logic when facing dynamically changing query requirements, further increasing the complexity and response time of the system.

[0004] In view of the above, this application is hereby submitted. Summary of the Invention

[0005] The present invention aims to provide an LLM-driven data query dependency retrieval method, apparatus, device and medium to solve the problems of system process redundancy, multiple generation strategies and step-by-step triggering of data query in existing data retrieval methods.

[0006] To solve the above-mentioned technical problems, the present invention is achieved through the following technical solution: An LLM-driven data query dependency retrieval method includes: Obtain user query requirements for inputting LLM and a pre-built entity relation database; Extract the associated entities from the user's query requirements, and extract the query constraints corresponding to the associated entities to form entity constraint pairs; Based on the entity constraint pairs, query rules between related entities are matched from the entity relation database to form a linear dependency chain structure, thus obtaining the query association chain; Perform a validity check on the query association chain; Each associated entity in the query association chain that has successfully passed the legality verification is an independent task node, and is numbered according to the association order to perform recursive retrieval queries, thereby obtaining the task query results corresponding to the association order number. By integrating the query results of all associated sequential numbers using LLM, a structured strategy is obtained.

[0007] Preferably, the entity relation database is based on open specification documents as the core input source and supplemented by data object documents existing in the enterprise, and is generated through automated code integration.

[0008] Preferably, when extracting related entities from the user's query requirements, a pre-trained entity recognition model is used for extraction.

[0009] Preferably, when validating the query association chain, an LLM is used to check whether there are broken related entities or circular dependencies in the query association chain; if any abnormality is found, an error message is returned.

[0010] The present invention also provides an LLM-driven data query dependency retrieval device, comprising: The acquisition unit is used to acquire user query requirements input into the LLM and a pre-built entity relation database; The entity constraint pair unit is used to extract related entities from the user query requirements and extract the query constraints corresponding to the related entities to form entity constraint pairs. The query association chain unit is used to match query rules between associated entities from the entity relation database based on the entity constraint pairs, forming a linear dependency chain structure to obtain the query association chain; A legality verification unit is used to verify the legality of the query association chain; The recursive retrieval query unit is used to take each associated entity in the query association chain that has successfully passed the legality verification as an independent task node, and number them according to the association order to perform recursive retrieval query to obtain the task query result corresponding to the association order number. The results integration unit is used to integrate the query results of all associated sequence numbers through LLM to obtain a structured strategy.

[0011] The present invention also provides an LLM-driven data query dependency retrieval device, including a processor and a memory, wherein the memory stores a computer program that can be executed by the processor to implement an LLM-driven data query dependency retrieval method as described above.

[0012] The present invention also provides a computer-readable storage medium storing computer-readable instructions, which, when executed by a processor of the device on which the computer-readable storage medium resides, implement an LLM-driven data query dependency retrieval method as described above.

[0013] In summary, compared with the prior art, the present invention has the following beneficial effects: This invention enables the definition of a complete recursive strategy in the strategy generation stage, covering query conditions, output fields, and dependencies for all related entities, and automatically completes the entire retrieval process through system invocation. This method not only significantly reduces system process redundancy but also effectively reduces the number of LLM strategy generation iterations and the number of step-by-step triggerings for data queries (such as entity relation database calls), thereby greatly improving retrieval efficiency and system response speed.

[0014] First, by generating a full-link recursive strategy in a single step, the number of strategy generation attempts is reduced, thereby lowering the complexity of the system process. Second, based on the entity relation database, automated parameter filling and call scheduling eliminate the need for manual intervention, improving retrieval efficiency. Finally, through a closed-loop retrieval process, the time spent on dependent calls is significantly shortened, enhancing the user experience.

[0015] This invention achieves "one-trigger, fully automatic" retrieval of multiple related entities through a recursive association retrieval design driven by a Large Language Model (LLM). This solves the problems of system process redundancy, multiple generation strategies, and step-by-step triggering of data queries inherent in traditional step-by-step retrieval. This design not only improves retrieval efficiency but also significantly enhances user experience, demonstrating broad application prospects. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained from these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram of an LLM-driven data query dependency retrieval method provided in Embodiment 1.

[0018] Figure 2 This is a schematic diagram of an LLM-driven data query dependency retrieval device provided in Embodiment 2.

[0019] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely represents selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0021] Example 1 Embodiment 1 of the present invention provides an LLM-driven data query dependency retrieval method, which can be implemented by an LLM-driven data query dependency retrieval device (hereinafter referred to as the retrieval device), and in particular, executed by one or more processors within the retrieval device.

[0022] In this embodiment, the retrieval device may be an electronic device equipped with a processor, the processor having a computer program for the data query-dependent retrieval method driven by the LLM and the computer program being executable, such as a computer, smartphone, smart tablet, workstation, etc., which are not limited here.

[0023] This embodiment combines entity association chain identification and recursive strategy generation mechanism, and generates the full-link strategy once based on LLM, so that the system does not need to rely on the core logic to be executed step by step.

[0024] like Figure 1 As shown, an LLM-driven data query dependency retrieval method includes steps S1 to S6.

[0025] S1, obtain the user query requirements inputting the LLM and the pre-built entity relation library.

[0026] In this step, enter the user's query request for LLM, such as "Please help me check the new customers added in the last month, as well as their orders and logistics status."

[0027] The entity-relationship database is based on open specification documents as the core input source and supplemented by existing data object documents of the enterprise. It is generated through automated code integration and can be API data classification documents or SQL database tables, etc.

[0028] S2, extract related entities from the user's query requirements, and extract the query constraints corresponding to the related entities to form entity constraint pairs.

[0029] Transforming user-input natural language requirements into structured entities and query constraints lays the foundation for association chain recognition.

[0030] When extracting related entities from the user's query requirements, a pre-trained entity recognition model can be used for extraction.

[0031] For example, based on the above example, the entity recognition model can include a business entity library such as "customer, order, logistics order, product" to extract related entities from the requirements. For example, the related entities extracted from the above example are: [customer, order, logistics order].

[0032] Extract the query constraints corresponding to the entities, and bind the limiting conditions in the requirements to each entity to form entity-constraint pairs. For example: Customer: {Constraint: New, Time Range: Last 30 days}; Orders: {Constraint: Associated with new customers added in the last 30 days}; Logistics order: {Constraint: Associated with the above order}.

[0033] For example, entity recognition models can use a pre-trained BERT-based entity recognition model (training data: 5000 labeled e-commerce / finance queries; output format: BIO labeled sequence) to extract associated entities, and generate entity constraint pairs through a rule engine (e.g., if an entity contains 'new', then bind the {state:active} constraint).

[0034] S3. Based on the entity constraint pairs, match the query rules between related entities from the entity relation database to form a linear dependency chain structure and obtain the query association chain.

[0035] The purpose of this step is to match the association rules between entities from the entity relation database and construct a complete association chain of "starting entity → intermediate entity → target entity".

[0036] The entity relation database contains fields for association between entities, association types (one-to-one / one-to-many), and dependencies (such as "order depends on customer" and "logistics order depends on order").

[0037] LLM uses the extracted associated entities as nodes and matches the association rules of adjacent entities from the entity relation database to form a linear dependency chain structure.

[0038] For example: The starting entity "Customer" and the intermediate entity "Order" match the associated field "customer_id", with the rule that "Customer → Order must be associated through customer_id". The intermediate entity "Order" and the target entity "Logistics Order" match the associated field "order_no", with the rule that "Order → Logistics Order must be associated through order_no". This ultimately forms a complete chain of connections: Customer → [customer_id] → Order → [order_no] → Logistics order.

[0039] S4, perform a validity check on the query association chain.

[0040] When validating the query association chain, the LLM is used to check whether there are broken association entities (such as whether an association rule for a certain entity is missing) or circular dependencies (such as "order → customer → order"). If any abnormality is found, an error message is returned (such as "No association rule for 'order → logistics order' was found. Please add the entity relationship database").

[0041] S5. Each associated entity in the query association chain that has successfully passed the legality verification is taken as an independent task node, and recursively retrieved and queried according to the association order number to obtain the task query result corresponding to the association order number.

[0042] The purpose of this step is to generate a structured task strategy containing all entities at once based on the association chain, clarify the query conditions, output fields and dependencies of each task, and achieve a "one-step" strategy design.

[0043] Specifically, the task nodes are first broken down: each entity in the association chain is treated as an independent task node, numbered sequentially according to the association order (T1, T2, T3...). For example, the association chain Customer → Order → Logistics Order corresponds to 3 tasks: T1: Customer data query task (starting task, no prerequisites); T2: Order data query task (depends on the output of T1); T3: Logistics order data query task (depends on the output of T2).

[0044] Next, task attributes are defined (through recursive filling): For each task, LLM recursively defines three main attributes: "query conditions, output fields, and dependent task IDs" to ensure that subsequent tasks can directly reuse the output of previous tasks.

[0045] For example: T1 (Customer Task): Query criteria: {New customers: Yes, Time range: Last 30 days}; Output fields: [customer_id, customer name, registration time] (must include the associated field customer_id for use by T2); Dependency Task ID: null (no prerequisites).

[0046] T2 (Order Task): Query criteria: {customer_id: the set of customer_ids output by T1} (directly referencing the output field of T1 as the filter condition); Output fields: [order_no, customer_id, order amount, order time] (must include the associated field order_no for use by T3); Dependency Task ID: T1 (explicitly depends on the execution result of T1).

[0047] T3 (Logistics Order Task): Query criteria: {order_no: the set of order_no output by T2} (referencing the output field of T2 as a filter condition); Output fields: [logistics_no, order_no, logistics status, shipping time]; Dependency Task ID: T2 (explicitly depends on the execution result of T2).

[0048] The rule base stores association rules in JSON format (e.g., {source_entity:customer, target_entity:order,link_field:customer_id, cardinality:one-to-many}), and constructs dependency chains by matching the longest valid path between adjacent entities using graph traversal algorithms (e.g., DFS).

[0049] S6. By integrating the query results of all associated sequential numbers through LLM, a structured strategy is obtained.

[0050] In this step, LLM integrates all tasks into a structured strategy (such as JSON format) to ensure coverage of the entire chain of relationships.

[0051] This step can be executed sequentially by a task scheduler (such as Celery) according to the association order number: the result of T1 is stored in the Redis cache (key:T1_output), and T2 automatically reads the customer_id from the cache as the input parameter to trigger the API, thus recursively realizing the full-link retrieval.

[0052] The subsequent system generates an execution plan based on the dependencies in the strategy: tasks without dependencies (such as T1) are executed first, and dependent tasks (T2, T3) wait for the preceding tasks to complete in sequence. However, there is no need for LLM to intervene and supplement the strategy, because the conditions and outputs of all tasks have been preset, and the system only needs to automatically pass parameters according to the strategy.

[0053] In another preferred embodiment, the efficiency difference between the method of the present invention and the traditional step-by-step retrieval is compared from four core dimensions: the number of times the LLM strategy is generated, the API call triggering logic, the total time consumption, and the process redundancy. The comparison results are shown in Table 1.

[0054] Table 1. Comparison of efficiency differences between the method of the present invention and traditional step-by-step retrieval.

[0055] In an LLM-driven data retrieval process, the performance bottleneck mainly stems from the latency of LLM generating query strategies (usually on the order of several seconds), rather than the execution time of the data interface (on the order of milliseconds).

[0056] Taking "checking orders and corresponding logistics status of new customers in the last 30 days" as an example, let's assume the following scenario parameters: Time taken to generate a single LLM strategy: 10 seconds (time taken for LLM to process natural language → generate a structured strategy); The execution time of a single API call (including data query and return) is 0.1 seconds (database query + network transmission time). Inter-step waiting delay: 0.5 seconds (in traditional methods, the delay in manually / systemically determining the next step requirement after the result of the previous step is returned).

[0057] The traditional method requires execution in steps: "Customer → Order → Logistics Order," with each step depending on the result of the previous step. The process is as follows: Step 1: Query new customers in the past 30 days Calling LLM to generate customer query strategy: 10 seconds; Executing the client API call: 0.1 seconds; Results: Customer list (including customer_id); Subtotal time: 10 + 0.1 = 10.1 seconds.

[0058] Step 2: Query related orders based on customer ID Waiting for the previous result to be returned + manual / system confirmation of the next step requirement: 0.5 seconds; Calling the LLM to generate an order query strategy (based on the previous customer_id): 10 seconds; Executing the order API call: 0.1 seconds; Results: Order list (including order_no); Subtotal time: 0.5 + 10 + 0.1 = 10.6 seconds.

[0059] Step 3: Check the associated logistics status based on the order number Waiting for the previous result to be returned + manual / system confirmation of the next step requirement: 0.5 seconds; Call LLM to generate logistics query strategy (based on order_no in the previous step): 10 seconds; Execution of the logistics API call: 0.1 seconds; Results: Logistics status list; Subtotal time: 0.5 + 10 + 0.1 = 10.6 seconds.

[0060] Total time: 10.1 + 10.6 + 10.6 = 30.8 seconds; LLM call count: 3 times; API triggering logic: step-by-step dependency, each step needs to wait for the result of the previous step + regenerate strategy, resulting in long user wait time and poor experience.

[0061] This invention transforms the "multi-round serial" approach into a "single-time generation, automatic execution" approach by generating a full-link strategy in one go using LLM, thereby reducing the number of LLM calls from N to 1 and completely avoiding the problems of strategy generation delay and the accumulation of waiting delays between steps.

[0062] The system executes automatically according to preset dependencies, and the process is as follows: Step 1: Generate end-to-end strategy in one LLM step LLM analyzes requirements → identifies the "customer → order → logistics order" relationship chain → generates a structured strategy containing T1 (customer), T2 (order, dependent on T1), and T3 (logistics, dependent on T2): 10 seconds; Subtotal time: 10 seconds.

[0063] Step 2: The system automatically triggers API execution according to the strategy. T1 (Client API): No waiting required, triggered directly (preset conditions in the strategy): 0.1 seconds; T2 (Order API): After T1 returns customer_id, it will automatically trigger the condition in the preset strategy (without needing to call LLM again): 0.1 seconds (in parallel with T1's "wait for return", actually only adding 0.1 seconds). T3 (Logistics API): After T2 returns order_no, the condition in the preset strategy will be automatically triggered: 0.1 seconds (in parallel with T2's "wait for return", actually only adding 0.1 seconds). There is no additional waiting delay between steps (the strategy has pre-set dependencies, and the system automatically determines the triggering time). Subtotal time: 0.1 + 0.1 + 0.1 = 0.3 seconds (API execution is sequential based on dependencies, but there is no intermediate LLM call or manual judgment delay).

[0064] Total time: 10 + 0.3 = 10.3 seconds; LLM call count: 1 time; API trigger logic: automatically triggered according to preset dependencies, no intermediate strategy generation required.

[0065] The above calculations and comparisons show that the method of this invention reduces the total time by 67% compared to the traditional step-by-step retrieval method; the number of LLM calls is reduced from N to 1, and the solution has wide applicability. For API queries, it solves the problems of simple APIs not supporting join queries and the high cost of GraphQL transformation, and can be directly adapted to existing API interfaces.

[0066] For SQL queries, even though SQL has built-in join queries (such as JOIN and subqueries), in heterogeneous data source scenarios in the big data field (such as data scattered across MySQL, MongoDB and third-party systems), it is impossible to implement subqueries or JOIN joins across data sources. This solution can automatically execute queries across data sources by generating SQL query strategies with dependencies in one go, breaking through the application limitations of traditional SQL.

[0067] The difference lies in the fact that API queries use API documentation to describe the relationships, while SQL queries use database tables to describe the relationships.

[0068] For example, taking the natural language query "retrieve orders and corresponding logistics status of new customers in the last 30 days" as an example, the process of the retrieval method of this invention for SQL queries is described as follows: First, inform the model of the relationships between entities: query customers by time (last 30 days) to obtain a customer relationship table (customer name, customer ID, etc.); then, query orders by customer ID to obtain an order relationship table (order ID, order time, etc.); finally, query logistics by order ID to obtain a logistics relationship table (logistics tracking number, current status, etc.).

[0069] Next, based on the relationship between the user's question and the entities, the recursive query relationship returned by the LLM is obtained in one go: "Time → Customer → Order → Logistics Order".

[0070] Finally, the LLM executes the program based on the recursive query relationship to obtain the query results.

[0071] This invention eliminates the need for waiting delays between steps and the need for repeated strategy generation. The efficiency advantage of this invention becomes more significant as the number of retrieval steps increases (e.g., involving four or more related entities). For example, when the retrieval process involves five steps, the traditional method requires five LLM calls, while this invention only requires one, reducing the total time by more than 80%.

[0072] LLM generation strategies involve complex calculations such as natural language understanding and logical decomposition, which are a "performance bottleneck" in the retrieval process. Traditional methods require multiple calls, while this invention directly reduces (N-1) time-consuming steps (N is the number of retrieval steps) by "generating the entire strategy in one go". In traditional methods, the loop of "returning the result of the previous step → judging the next step requirement → generating a new strategy" will generate cumulative delays; this invention can automatically determine the API triggering time by pre-setting dependencies, without the need for manual / system intervention, thus reducing intermediate waiting time.

[0073] Traditional methods require repeating the logic of "parse the result of the previous step → generate a new strategy" at each step. This invention avoids redundant processing between steps and reduces system resource consumption by defining full-link rules in advance.

[0074] This invention is applicable to various complex multi-entity association query scenarios. For example, in the e-commerce field, users can use natural language to query "find all orders of a certain customer and their logistics status," and the system can return complete results after a single trigger. In the financial field, users can use natural language to query "find all transaction records of a certain account and their corresponding settlement status," and the system can also efficiently complete the retrieval, improving the retrieval efficiency of LLM and the user experience of LLM.

[0075] Furthermore, this invention is highly scalable, allowing for flexible adjustment of association rules in data capability classification documents according to actual needs, thereby adapting to application scenarios in different fields.

[0076] In summary, compared with the prior art, the present invention has the following beneficial effects: This invention reduces the number of strategy generation iterations by generating a full-link recursive strategy in a single step, thereby lowering the complexity of the system process. Secondly, automated parameter filling eliminates the need for manual intervention, improving retrieval efficiency. Finally, a closed-loop retrieval process significantly reduces the time spent on dependent calls, enhancing the user experience.

[0077] In practical applications, this invention compresses the overall process of multi-entity retrieval from "multi-round step-by-step" to "one-round closed loop," greatly optimizing query efficiency. For example, in traditional step-by-step retrieval, users need to trigger the system process three times to complete the query for customers, orders, and logistics orders. However, under the design of this invention, users only need to trigger the process once to obtain complete query results. This efficient retrieval method not only meets users' needs for rapid response but also significantly improves the overall performance of the system.

[0078] This invention achieves "one-trigger, fully automatic" retrieval of multiple related entities through a recursive association retrieval design driven by a large language model. It solves the problems of system process redundancy, multiple generation strategies, and step-by-step triggering of data queries inherent in traditional step-by-step retrieval. This design not only improves retrieval efficiency but also significantly enhances user experience, demonstrating broad application prospects.

[0079] Example 2 like Figure 2 As shown, the second embodiment of the present invention also provides an LLM-driven data query dependency retrieval device, comprising: The acquisition unit is used to acquire user query requirements input into the LLM and a pre-built entity relation database; The entity constraint pair unit is used to extract related entities from the user query requirements and extract the query constraints corresponding to the related entities to form entity constraint pairs. The query association chain unit is used to match query rules between associated entities from the entity relation database based on the entity constraint pairs, forming a linear dependency chain structure to obtain the query association chain; A legality verification unit is used to verify the legality of the query association chain; The recursive retrieval query unit is used to take each associated entity in the query association chain that has successfully passed the legality verification as an independent task node, and number them according to the association order to perform recursive retrieval query to obtain the task query result corresponding to the association order number. The results integration unit is used to integrate the query results of all associated sequence numbers through LLM to obtain a structured strategy.

[0080] Example 3 The third embodiment of the present invention also provides an LLM-driven data query dependency retrieval device, which includes a memory and a processor. The memory stores a computer program that can be executed by the processor to implement the LLM-driven data query dependency retrieval method described above.

[0081] Example 4 The fourth embodiment of the present invention also provides a computer-readable storage medium storing computer-readable instructions. When the computer-readable instructions are executed by the processor of the device where the computer-readable storage medium is located, they implement the LLM-driven data query dependency retrieval method described above.

[0082] In the several embodiments provided in this invention, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus and method embodiments described above are merely illustrative. For example, the flowcharts in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of the invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0083] In addition, the functional modules in the various embodiments of the present invention can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0084] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they 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, electronic device, 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. It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. In the absence of further restrictions, an element defined by the phrase "comprising a..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0085] The terminology used in the embodiments of this invention is for the purpose of describing particular embodiments only and is not intended to limit the invention. The singular forms “a,” “the,” and “the” as used in the embodiments of this invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

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

[0087] Depending on the context, the word "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrase "if determination" or "if detection (of the stated condition or event)" can be interpreted as "when determination," "in response to determination," "when detection (of the stated condition or event)," or "in response to detection (of the stated condition or event)."

[0088] The use of "first" and "second" in the embodiments is merely to distinguish similar objects and does not represent a specific ordering of objects. It is understood that "first" and "second" can be interchanged in a specific order or sequence where permitted. It should be understood that the objects distinguished by "first" and "second" can be interchanged where appropriate so that the embodiments described herein can be implemented in an order other than those illustrated or described herein.

[0089] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. An LLM-driven data query dependency retrieval method, characterized in that, include: Obtain user query requirements for inputting LLM and a pre-built entity relation database; Extract the associated entities from the user's query requirements, and extract the query constraints corresponding to the associated entities to form entity constraint pairs; Based on the entity constraint pairs, query rules between related entities are matched from the entity relation database to form a linear dependency chain structure, thus obtaining the query association chain; Perform a validity check on the query association chain; Each associated entity in the query association chain that has successfully passed the legality verification is an independent task node, and is numbered according to the association order to perform recursive retrieval queries, thereby obtaining the task query results corresponding to the association order number. By integrating the query results of all associated sequential numbers using LLM, a structured strategy is obtained.

2. The LLM-driven data query dependency retrieval method according to claim 1, characterized in that... The entity relation database is based on open specification documents as the core input source and supplemented by data object documents existing in the enterprise, and is generated through automated code integration.

3. The LLM-driven data query dependency retrieval method according to claim 1, characterized in that... When extracting related entities from the user's query requirements, a pre-trained entity recognition model is used for extraction.

4. The LLM-driven data query dependency retrieval method according to claim 1, characterized in that... When validating the query association chain, the system uses LLM to check whether there are broken association entities or circular dependencies in the query association chain; if any abnormality is found, an error message is returned.

5. An LLM-driven data query dependency retrieval device, characterized in that, include: The acquisition unit is used to acquire user query requirements input into the LLM and a pre-built entity relation database; The entity constraint pair unit is used to extract related entities from the user query requirements and extract the query constraints corresponding to the related entities to form entity constraint pairs. The query association chain unit is used to match query rules between associated entities from the entity relation database based on the entity constraint pairs, forming a linear dependency chain structure to obtain the query association chain; A legality verification unit is used to verify the legality of the query association chain; The recursive retrieval query unit is used to take each associated entity in the query association chain that has successfully passed the legality verification as an independent task node, and number them according to the association order to perform recursive retrieval query to obtain the task query result corresponding to the association order number. The results integration unit is used to integrate the query results of all associated sequence numbers through LLM to obtain a structured strategy.

6. An LLM-driven data query dependency retrieval device, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program that can be executed by the processor to implement an LLM-driven data query dependency retrieval method as described in any one of claims 1-4.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by the processor of the device on which the computer-readable storage medium resides, implement an LLM-driven data query dependency retrieval method as described in any one of claims 1-4.

Images