Software function dynamic arrangement driving method based on lightweight large model intent understanding

Abstract

The application discloses a software function dynamic arrangement driving method based on light-weight large model intention understanding. The method comprises the following steps: receiving an input request, extracting multiple intentions of the input request based on a light-weight large model; determining the category identification of each intention based on a preset prompt word, and extracting the key parameters of each intention; matching the corresponding function module in the pre-constructed function knowledge base based on the category identification, obtaining the metadata of the function module, and assigning the metadata with the key parameters; based on the dependency constraints and time sequence association relationship of each function module, generating a directed acyclic graph of the execution path through a programmed algorithm, and screening the optimal execution path in combination with the multi-dimensional constraint conditions; based on the optimal execution path and the metadata of each function module after assignment, generating a structured execution instruction to drive the corresponding function module to execute cooperatively. Through the above method, the application can effectively inhibit the large model illusion, has stronger fault tolerance and expansion, and meets the engineering landing requirements.

Description

Technical Field

[0001] This application relates to the interdisciplinary field of artificial intelligence and software engineering, and in particular to a dynamic orchestration-driven method for software functions based on lightweight large model intent understanding. Background Technology

[0002] Existing traditional software architectures and related technologies have significant technical deficiencies in core areas such as function scheduling, task planning, and large-scale model applications, failing to meet the requirements for intelligent, flexible software operation and engineering implementation. Specifically: 1. Traditional software, based on event-driven and command-based scheduling, has fixed functional collaboration, making dynamic orchestration and scheduling impossible. Traditional software employs an event-driven model and command-based scheduling mechanism, with its functional collaboration logic fixed during the software development phase, unable to be flexibly adjusted according to actual user needs. Even some improved solutions attempt to achieve intent-driven functionality, merely calling large models and vectorization techniques as add-ons, not deeply integrated into the core software architecture. They remain limited by the fixed functional collaboration logic, unable to achieve true dynamic orchestration and scheduling of software functions.

[0003] 2. The task planning adopts a "top-down" goal decomposition model, which decomposes the overall goal into several sub-goals. However, sub-goals are prone to mismatch issues with execution function modules. This model lacks precise consideration of the adaptation of existing software function modules, and some of the decomposed sub-goals often cannot be matched with corresponding execution function modules, resulting in a break in the intent-driven execution chain and failing to effectively implement the core intent.

[0004] 3. Directly planning and generating logic chains using large models can easily lead to illusions and limit engineering implementation. If large models are directly used for task planning and to generate functional execution logic chains without effective constraints on the planning scope of the large model and without necessary verification mechanisms, the large model will be prone to illusions (i.e., generating non-existent functional modules, incorrect functional dependencies, or unreasonable execution paths). This will cause the logic chains to fail to execute normally, severely limiting the engineering implementation of intent-driven technology and failing to meet the stability and reliability requirements of practical applications. Summary of the Invention

[0005] This application provides a software function dynamic orchestration-driven method based on lightweight large model intent understanding to solve the problems of rigid function orchestration, easy breakage of intent-driven links, and difficulty in engineering implementation caused by direct planning of large models.

[0006] To address the aforementioned technical problems, this application adopts the following technical solution: a software function dynamic orchestration-driven method based on lightweight large-model intent understanding, comprising: Receive input requests and extract multiple intents from the input requests based on a lightweight large model; Based on preset prompts, the category identifier of each intent is determined, and the key parameters of each intent are extracted; In the pre-built functional knowledge base, the corresponding functional module is matched based on the category identifier, and the metadata of the functional module is obtained. The metadata is then assigned a value using the key parameters. Based on the dependency constraints and temporal relationships of each functional module, a directed acyclic graph of execution paths is generated through a programmatic algorithm, and the optimal execution path is selected by combining multidimensional constraints. Based on the optimal execution path and the metadata of each functional module after assignment, structured execution instructions are generated to drive the corresponding functional modules to execute collaboratively.

[0007] In one optional embodiment of this application, the step of generating a directed acyclic graph of execution paths using a programmatic algorithm based on the dependency constraints and temporal relationships of each functional module, and then selecting the optimal execution path by combining multidimensional constraints, includes: Obtain the relationship between the input and output parameters of each functional module, and determine the sub-execution path corresponding to each intent based on the dependency relationship and timing constraints; Based on the sub-execution paths and programmatic algorithms, corresponding sub-directed acyclic graphs are generated and integrated into the global directed acyclic graph according to business logic. The directed acyclic graph is validated and updated based on a preset validation algorithm, and the optimal execution path is selected from the updated directed acyclic graph in combination with the multidimensional constraints.

[0008] In one optional embodiment of this application, the step of verifying and updating the directed acyclic graph based on a preset verification algorithm, and selecting the optimal execution path from the updated directed acyclic graph in conjunction with the multidimensional constraints, includes: The directed acyclic graph is subjected to integrity verification. In response to the existence of an uncovered intent, the functional knowledge base is re-matched, and the directed acyclic graph is updated based on the matching result. The directed acyclic graph is subjected to loop verification and prohibition verification. In response to the existence of execution loops or preset prohibited functional dependencies, the corresponding execution path is deleted and the directed acyclic graph is updated. Redundancy check is performed on the directed acyclic graph, and redundant paths in the directed acyclic graph are deleted; By combining execution efficiency, resource consumption, and business priority metrics, the optimal execution path is selected from the updated directed acyclic graph.

[0009] In an optional embodiment of this application, after generating the structured execution instructions, the method further includes: Extract the function identifiers of each functional module from the structured execution instructions, and retrieve the corresponding function call entry addresses from the dynamic registry based on a preset multi-layer anti-abnormal constraint mechanism. The corresponding function program is loaded and executed based on the function call entry address to drive the functional module to complete the business execution.

[0010] In an optional embodiment of this application, matching the corresponding functional module in the functional knowledge base based on the category identifier includes: Using the category identifier as a filtering condition, a set of candidate functional modules is determined in the functional knowledge base; Each intent is converted into a low-dimensional intent feature vector. In the candidate functional module set, the low-dimensional intent feature vector is compared with the low-dimensional functional feature vector corresponding to each functional module to match the corresponding functional module.

[0011] In an optional embodiment of this application, after extracting the key parameters of each intent, the method further includes: In response to the current task being a pure data query operation, the extracted key parameters are directly forwarded to the corresponding business database to perform the query operation and return the query results.

[0012] In an optional embodiment of this application, during the execution of the functional module, the following further step is included: In response to the functional module being executed triggering a collaborative call with other functional modules, or the need to obtain external dependent data, the scheduled bypass execution process can directly complete the call or data acquisition.

[0013] To address the aforementioned technical problems, another technical solution adopted in this application is: providing a software function dynamic orchestration driving device based on lightweight large model intent understanding, the device comprising: The intent extraction module is used to receive input requests and extract various intents from the input requests based on a lightweight large model; The parameter extraction module is used to determine the category identifier of each intent based on preset prompt words, and extract the key parameters of each intent; The matching and assignment module is used to match the corresponding functional module in the pre-built functional knowledge base based on the category identifier, obtain the metadata of the functional module, and assign values ​​to the metadata with the key parameters. The path filtering module is used to generate a directed acyclic graph of execution paths based on the dependency constraints and temporal relationships of each of the functional modules through a programmatic algorithm, and to filter the optimal execution path by combining multidimensional constraints. The instruction generation module is used to generate structured execution instructions based on the optimal execution path and the metadata of each of the functional modules after assignment, so as to drive the corresponding functional modules to execute collaboratively.

[0014] To solve the above-mentioned technical problems, another technical solution adopted in this application is: to provide a computer device, including a memory, a processor and a computer program stored in the memory, characterized in that the processor executes the computer program to implement the steps of the above-mentioned software function dynamic orchestration driving method based on lightweight large model intent understanding.

[0015] To solve the above-mentioned technical problems, another technical solution adopted in this application is: to provide a storage medium on which a computer program is stored, characterized in that the computer program, when executed by a processor, implements the steps of the above-mentioned software function dynamic orchestration driving method based on lightweight large model intent understanding.

[0016] The beneficial effects of this application are as follows: Unlike existing technologies, this application discloses a dynamic orchestration-driven method for software functions based on lightweight large-scale model intent understanding. This method overcomes the shortcomings of traditional software function collaboration solidification and target decomposition, which easily lead to matching failures, by deeply embedding the lightweight large-scale model into the scheduling core. It accurately extracts intents and parameters using the lightweight large-scale model and preset prompts, and completes function matching and metadata assignment within the function knowledge base, strongly constraining the retrieval scope to the existing function set, effectively suppressing model illusions and matching link breaks from the source. Simultaneously, it entrusts core path planning to a programmatic algorithm to generate a directed acyclic graph and select the optimal path, abandoning the unstable mechanism of directly generating logical chains from the large model, thus ensuring the global accuracy and rationality of execution paths in multi-intent concurrent scenarios from the bottom layer. Finally, it drives the underlying execution through structured instructions, truly realizing dynamic orchestration of software functions based on intent. This significantly reduces model deployment and runtime overhead while ensuring high stability and reliability, meeting the needs of engineering implementation. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort, wherein: Figure 1This is a flowchart illustrating an embodiment of the software function dynamic orchestration driving method based on lightweight large model intent understanding provided in this application; Figure 2 This is a schematic diagram of an embodiment of the software function dynamic orchestration driving device based on lightweight large model intent understanding provided in this application; Figure 3 This is a schematic diagram of the structure of an embodiment of the storage medium provided in this application; Figure 4 This is a schematic diagram of the structure of an embodiment of the computer device provided in this application. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0019] The terms "first," "second," and "third" used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

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

[0021] This application provides a software function dynamic orchestration-driven method based on lightweight large-model intent understanding, which operates within a five-layer intrinsic intelligence architecture. Before detailing the method steps, the five-layer intrinsic intelligence architecture upon which this method relies is first elaborated.

[0022] This application abandons the traditional software's isolated model of treating large models and vectorization technology as add-ons, and instead embeds intelligent technology directly into the core of the software architecture to achieve inherent intelligence. The architecture, from bottom to top, includes a vector data layer, a core business layer, a large model orchestration layer, a gateway layer, and an access layer, as detailed below: As the front-end boundary for interaction with external users, the access layer is responsible for receiving various business requests from external users. When a user inputs a request in natural language, the access layer completes the initial reception and format standardization processing of the text request, cleanses the non-standard data stream, converts it into a compliant request message within the architecture, and then passes it to the gateway layer.

[0023] The gateway layer performs in-depth legitimacy checks and fine-grained access control on received compliant requests. Only requests that pass the security baseline check and have the corresponding operating permissions will be accurately routed by the gateway layer to the large model orchestration layer; at the same time, the gateway layer is also responsible for traffic distribution and rate limiting to prevent fraud, ensuring the stability of the core architecture.

[0024] The large-scale orchestration layer is the core of the entire five-layer architecture and the main execution carrier of the method in this application. This layer does not directly execute specific business logic, but is dedicated to intent extraction and decomposition, dynamic task planning, and scheduling instruction generation. It transforms unstructured natural language into structured execution instructions and serves as the control center for intent-driven dynamic orchestration.

[0025] The core business layer integrates all the atomic functional modules of the software system. These modules exist in the form of microservices or function programs, receiving execution instructions from the large model orchestration layer to complete specific business functions. At the same time, the core business layer supports horizontal collaborative calls with other functional modules and vertical data interaction with the underlying database during execution.

[0026] The vector data layer serves as the data foundation of the entire architecture, comprising a functional knowledge base, a dynamic registry, and a business database. The functional knowledge base is a static library that stores static representation information of all software functions; the dynamic registry is a dynamic library that records the mapping relationship between function identifiers and actual program addresses; the business database stores persistent data generated by business processes; and the vector data layer employs lightweight vector retrieval technology to provide functional retrieval and data support services for the large model orchestration layer.

[0027] It should be noted that, unless otherwise specified, in the specific embodiments of this application, the term "system" (such as internal system, current system, etc.) refers to the intrinsic intelligent software system built and running based on the above-described five-layer intrinsic intelligence architecture. This system achieves a closed-loop end-to-end process from natural language reception to code-level function execution through close collaboration among the various layers of the above five-layer architecture.

[0028] Based on the above architecture, this application proposes a software function dynamic orchestration-driven method based on lightweight large model intent understanding, see reference. Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the software function dynamic orchestration-driven method based on lightweight large model intent understanding provided in this application. The method is primarily executed by the large model orchestration layer, and includes: S10: Receive input requests and extract multiple intents of the input requests based on a lightweight large model.

[0029] First, the access layer receives raw natural language input requests from external users. Input requests include intent input (such as "Help me book a flight to Shanghai tomorrow") or various business requests (such as "Help me check tomorrow's flight schedule"), etc.

[0030] Due to the complexity of the external environment, the original input request may contain non-standard characters, redundant spaces, or non-standard encoding formats. The access layer performs preliminary format standardization processing on this original input request. This process specifically includes unified character set conversion, filtering and cleaning of illegal characters, and standardized reorganization of the text structure, thereby transforming the messy natural language into a standardized text message that is recognizable and clearly structured within the system.

[0031] Subsequently, the standardized text messages are passed down to the gateway layer, where deep validation and fine-grained access control are performed on the incoming messages. Validation is used to identify and block abnormal requests containing malicious injected scripts or that do not conform to the underlying communication protocol specifications; access control verifies whether the user initiating the request has the necessary permissions to trigger subsequent intelligent processing procedures based on the user's identity.

[0032] After confirming that the message has passed the legality verification and access control, the gateway layer further performs traffic distribution operations based on the real-time load of the current system, filters out abnormal traffic that may cause system overload, and finally accurately routes requests that are confirmed to be absolutely legal and compliant to the system's large model orchestration layer.

[0033] Once a compliance request reaches the large model orchestration layer, a pre-deployed lightweight large model is invoked to perform a deep semantic destructuring of the request. The specific semantic destructuring process is as follows: The lightweight large model first extracts the core intent from the standardized text message. The core intent represents the user's primary and most desired goal, constituting the core objective and main tone of the entire requirement. While determining the core intent, it further explores various auxiliary intents that support its realization. Auxiliary intents are secondary purposes that supplement, limit, explain, or condition the core intent; even if removed from the current context, they do not affect the core expression of the user's core needs.

[0034] After obtaining the core intent and auxiliary intents, the core intent is further broken down into layers to derive several sub-intents necessary to complete it. These sub-intents represent specific intermediate steps in the task execution process.

[0035] Subsequently, logical relationships are established between these sub-intents and auxiliary intents. These logical relationships specifically include pre- and post-contact relationships and parallel relationships. A pre- and post-contact relationship means that a sub-intent must depend on the output of another sub-intent to be triggered. A parallel relationship means that multiple sub-intents do not interfere with each other and can be executed synchronously by the system.

[0036] Through the above-described process of layer-by-layer analysis and logical reconstruction, a flat natural language sentence is completely transformed into a set of multiple intentions with a clear topological structure, laying a solid data foundation for subsequent programmatic path orchestration.

[0037] In an optional embodiment, after obtaining the core intent, auxiliary intent, and sub-intent, to ensure the absolute purity of the data input into the subsequent orchestration process, the generated sets of multiple intents can be further preprocessed by deduplication, conflict checking, and validity filtering. The specific process is as follows: First, intent deduplication is performed, including text deduplication based on string similarity matching and semantic deduplication based on different wording of the same business objective. Text deduplication involves identifying two intent texts with a similarity higher than a preset similarity threshold (e.g., 0.92) as having the same intent and removing redundant entries. Semantic deduplication involves normalizing different wording of the same business objective into a standard intent identifier and merging them.

[0038] Then, intent conflict verification is performed. A pre-built intent conflict knowledge base containing mutually exclusive business scenarios (such as "apply for refund" and "confirm transaction completion") is constructed. By batch traversing and comparing multiple extracted intents in pairs, if a pair of mutually exclusive intents in the conflict knowledge base is matched, the high-priority intent is retained and the low-priority conflict intent is discarded according to the business's preset priority rules. Finally, validity filtering is performed, eliminating invalid intents that do not meet the security baseline or lack key semantic elements based on preset compliance and completeness rules. This process ensures that the final output set of intents possesses a high degree of uniqueness, rationality, and executability.

[0039] This application abandons the traditional approach of calling ultra-large-scale general-purpose large models, and instead adopts a specially fine-tuned lightweight large model, thereby achieving the best balance between the scale of model parameters and the inference response speed. While ensuring accurate understanding of complex natural language semantics, it significantly reduces the computing power overhead and deployment cost of real-time operation.

[0040] S20: Based on preset prompts, determine the category identifier of each intent and extract the key parameters of each intent.

[0041] Based on the various intents obtained in step S10, and combined with preset prompts, the category identifier for each intent is determined. The preset prompts predefine all major functional categories supported by the software. For example, PC assistant software supports major functional categories such as file processing, system settings, network tools, application management, information query, and text editing.

[0042] By inputting multiple sets of intents into a lightweight large model and strictly constraining each sub-intent and auxiliary intent under preset prompts, corresponding category labels are generated. The process of determining the category labels is essentially a forced mapping process. Its core function is to forcibly confine ambiguous natural language intents within a known finite functional domain, thereby eliminating the possibility of out-of-bounds illusions in subsequent matching stages from the source.

[0043] While classifying the data, key parameters corresponding to each intent are further extracted. These key parameters cover structured information such as input / output requirements, execution constraints, time and location entities, and user preference settings. These key parameters are precisely extracted in standardized key-value pairs, forming the data foundation for subsequent function retrieval and parameter assignment. Execution constraints may include timeliness limitations or specific business rule boundaries, while user preference settings include specific format requirements or sorting preferences for the output results.

[0044] In an optional embodiment, after extracting the key parameters of each intent, the method further includes: In response to the current task being a pure data query operation, the extracted key parameters are directly forwarded to the corresponding business database to execute the query operation and return the query results.

[0045] Task type determination is completed simultaneously during the extraction of key parameters. Specifically, the determination of pure data query operations is based on both intent verb features and overall business semantic features. Intent verb features are words that characterize data reading actions, such as query, obtain, view, search, understand, retrieve, count, list, or display. Overall business semantic features indicate that the task objective is solely to read data or obtain information, and does not involve any system state modification, function execution, device control, or data writing operations.

[0046] When the above typical characteristics are identified and the current task is determined to be a pure data query operation, the query bypass mechanism is immediately triggered. At this time, the normal dynamic orchestration process is directly interrupted, and the request is no longer sent to the subsequent intent retrieval and execution path planning stages (i.e., the subsequent steps S30~S50 are no longer executed). Instead, the key query parameters that were just extracted are packaged and forwarded directly to the corresponding business database interface through a dedicated bypass channel; the business database directly executes the query operation based on these key parameters and obtains the query result set; this query result set then passes through the gateway layer and access layer and is directly fed back to the user.

[0047] The software function dynamic orchestration driving method based on lightweight large model intent understanding provided in this application directly triggers the query bypass mechanism for pure data query operations, completely skipping the redundant flow links of subsequent intent retrieval, DAG path planning and module scheduling. It achieves a lightweight response with extremely low latency for high-frequency simple query requests, and significantly improves the software's processing efficiency for different types of tasks.

[0048] S30: Match the corresponding functional module based on the category identifier in the pre-built functional knowledge base, obtain the metadata of the functional module, and assign values ​​to the metadata with key parameters.

[0049] In an optional embodiment, step S30 above further includes: S31: Using category identifiers as filtering conditions, determine the set of candidate functional modules in the functional knowledge base.

[0050] The functional knowledge base is a small-scale static representation library that precisely focuses on the core functions of the software itself. By using category identifiers as a pre-filtering condition, the subsequent search space can be significantly reduced from the entire functional library to a specific subset of corresponding functional categories. This greatly improves the computational efficiency of subsequent matching steps and constrains the search scope from a physical boundary, reducing the risk of illusions.

[0051] S32: Convert each intent into a low-dimensional intent feature vector. In the candidate functional module set, calculate the similarity between the low-dimensional intent feature vector and the low-dimensional functional feature vector corresponding to each functional module to match the corresponding functional module.

[0052] Since the set of candidate functional modules is relatively small, there is no need to use a complex deep semantic vector model; instead, a lightweight vectorization processing mechanism is adopted.

[0053] In the functional knowledge base, the functional description text of each functional module is pre-converted into low-dimensional feature vector form for storage. Here, low-dimensional feature vectors refer to feature vector representations with dimensions controlled at an extremely low order of magnitude, which can significantly reduce the amount of multiplication and addition calculations in vector operations.

[0054] During matching, the intent information to be matched is also transformed into corresponding low-dimensional intent feature vectors. Then, a simple vector similarity calculation algorithm is used to perform a fast comparison within the candidate functional module set. The preferred vector similarity calculation algorithm is cosine similarity, which calculates a similarity score by dividing the dot product of two feature vectors by the product of their magnitudes. A score closer to 1 indicates a smaller angle between the two feature vectors in space, signifying higher semantic similarity; a score closer to 0 indicates a larger angle, signifying lower semantic similarity. This lightweight feature vector algorithm, which only involves basic multiplication, addition, and square root operations, can quickly match the functional module with the highest score and the best semantic fit from the candidate functional module set.

[0055] After a successful match, the core metadata of the matched functional modules is extracted. This core metadata provides a precise profile of the functional module at the code level, specifically including the functional identifier (ID), the name of the called function, the data types and format specifications of the input and output parameters, and the functional dependencies between this function and other functions. Based on the extracted core metadata, a standardized set of input and output parameters is constructed.

[0056] Subsequently, based on the key parameters extracted in the previous steps, and adhering to the strict correspondence between parameter names and data types, the metadata is precisely injected and overwritten into each parameter in the input / output parameter set, thus completing the metadata assignment. The assignment results are then subjected to data type matching and mandatory field integrity checks to intercept abnormal data. In this process, the metadata, after assignment and verification, transforms from a general abstract functional template into an instantiated execution unit carrying specific user requirements, providing complete and accurate data support for subsequent execution path planning.

[0057] The software function dynamic orchestration-driven method based on lightweight large model intent understanding provided in this application delineates the candidate set by category identifiers and performs semantic matching by combining lightweight low-dimensional feature vectors with simple similarity calculations. While ensuring accurate mapping between intent and functional modules and further shrinking the illusion space, it significantly reduces the computational overhead of multiplication and addition in the feature vector operation process and the retrieval time, thus realizing lightweight and high-efficiency functional retrieval collaboration.

[0058] S40: Based on the dependency constraints and temporal relationships of each functional module, a directed acyclic graph of execution paths is generated through a programmatic algorithm, and the optimal execution path is selected by combining multidimensional constraints.

[0059] In an optional embodiment, step S40 above further includes: S41: Obtain the dependency constraints and timing relationships between the input and output parameters of each functional module, and determine the sub-execution path corresponding to each intent based on the dependency constraints and timing relationships.

[0060] From the core metadata extracted in step S30, the dependency constraints and temporal relationships between the input and output parameters of each functional module are obtained. By comparing the names and data types of the input and output parameters of different functional modules one by one, the coupling degree and dependency flow of each functional module at the code execution level are clarified. Based on these dependency constraints and temporal relationships between parameters, the local execution sequence that must be followed to realize each sub-intention is initially constructed, thereby determining the sub-execution path corresponding to each intention.

[0061] S42: Based on the sub-execution paths and programmatic algorithms, generate corresponding sub-directed acyclic graphs and integrate them into a global directed acyclic graph according to business logic.

[0062] Instead of relying on large models to autonomously infer and generate execution logic chains, this approach employs deterministic, procedural algorithms to construct a directed acyclic graph (DAG). In this DAG, nodes represent specific functional modules, and directed edges between nodes represent the execution flow.

[0063] When generating directed edges in a directed acyclic graph, programmatic algorithms strictly adhere to the following code-level logic rules: 1) If the output parameter of one functional module completely matches the input parameter of the other functional module, then it is determined that the two form a predecessor-successor relationship, and a directed edge from the predecessor node to the successor node is drawn in the graph. 2) If there is no direct input / output relationship between two functional modules, they are considered to be parallel, which is represented in the diagram as independent branch nodes without connection; 3) If the output parameters of two parallel functional modules are used together as the input parameters of a third functional module, then the three are determined to form a logical relationship of parallel first and then serial. In the figure, this is presented as a topology structure in which two independent branches eventually converge at the same convergence node.

[0064] After completing the local logic construction, the first step is to generate sub-directed acyclic graphs corresponding to each sub-intention according to the above rules. Then, based on the macro-level business logic relationships between each sub-intention, all generated sub-directed acyclic graphs are topologically stitched together and integrated to finally form a global directed acyclic graph that covers the complete business process (corresponding to the complete input request).

[0065] Unlike existing technologies where direct planning of large models to generate logical chains can easily lead to illusions, this application provides a software function dynamic orchestration-driven method based on lightweight large model intent understanding. This method uses a programmatic algorithm to generate sub-directed acyclic graphs based on the dependencies and temporal relationships between parameters, and integrates them into a global graph according to business logic. This fundamentally eliminates the possibility of large models freely fabricating execution flows, avoiding execution path errors caused by model illusions, and significantly improving the determinism and engineering reliability of complex task path planning.

[0066] S43: Based on the preset verification algorithm, the directed acyclic graph is verified and updated, and the optimal execution path is selected from the updated directed acyclic graph in combination with multi-dimensional constraints.

[0067] To ensure the absolute safety and efficiency of the global directed acyclic graph in actual operation, a preset triple verification mechanism is adopted to strictly review and correct the generated graph structure.

[0068] In an optional embodiment, step S43 above further includes: S431: Perform integrity checks on the directed acyclic graph, and in response to the existence of uncovered intents, re-match the functional knowledge base and update the directed acyclic graph based on the matching results.

[0069] The process iterates through all nodes in the global directed acyclic graph (DAG), verifying their functions against all parsed sub-intents and auxiliary intents. If an intent is found not covered by any node, it's determined that a function is missing from the current DAG. In this case, a re-matching process is automatically triggered against the functional knowledge base, carrying the missing intent information for a new search and match. After a new functional module is matched, it's inserted as a new node into the original DAG, and the directed edge logical connections between it and existing nodes are refined according to parameter matching rules, thus completing the update of the DAG.

[0070] S432: Perform loop and prohibition checks on the directed acyclic graph. In response to the existence of execution loops or preset prohibited functional dependencies, delete the corresponding execution path and update the directed acyclic graph.

[0071] Perform cycle checking on the current directed acyclic graph. When a directed edge and its connected nodes are detected to form an execution cycle, immediately trigger a path deletion command to accurately locate and sever the directed edge that caused the cycle, thereby breaking the circular dependency.

[0072] Simultaneously, prohibition checks are performed. Pre-defined prohibited functional dependencies stem from security policies or business mutual exclusion logic. For example, certain functions involving core data erasure are not allowed to execute consecutively with specific external interface calls. These dependencies are pre-converted into mappings of functional modules and stored in a prohibition rule base. All node pairs with directly connected edges in the current directed acyclic graph are extracted and cross-checked against the pre-stored prohibition rule base. If a non-compliant functional call combination is found in the graph, a path deletion command is immediately triggered, severing the directed edge connecting the two non-compliant nodes.

[0073] For parts that become isolated nodes or broken branches due to disconnection, the execution path between them and other nodes is replanned according to graph theory algorithms, thereby completing the update of the directed acyclic graph.

[0074] S433: Perform redundancy checks on directed acyclic graphs and delete redundant paths in the directed acyclic graph.

[0075] Redundant paths refer to edge branches that exist in the graph structure but do not have any substantial impact on achieving the core intent even if they are not executed.

[0076] Based on the ultimate goal of the core intent, the necessity of each branch path in the graph is evaluated. Specifically, this can be determined by calculating the contribution of each branch from the initial node to the target endpoint: if the contribution of a branch is lower than a preset contribution threshold, it indicates that the branch has very little effect on achieving the core intent and is identified as a redundant branch. Once a redundant path is identified, its corresponding node and directed edge are resolutely removed from the graph.

[0077] After deletion, the connection relationships of the remaining nodes in the graph are reorganized, and the execution order of the nodes is adjusted. Finally, a simplified directed acyclic graph that fully meets the core calling requirements is obtained, avoiding the suspension of invalid functional modules.

[0078] S434: Combining execution efficiency, resource consumption, and business priority metrics, select the optimal execution path in the updated directed acyclic graph.

[0079] After the aforementioned triple verification and graph update, multiple candidate paths to the final goal may still exist in the global directed acyclic graph. For these candidate paths, execution efficiency is estimated, system resource consumption is calculated, and business priority is evaluated. The execution efficiency estimation metrics include the estimated total execution time of the path; the resource consumption calculation metrics include the peak memory and computing power consumption of the functional modules called by the path; and the business priority metrics are quantified and scored based on the urgency of the current task, user level, or the value weight of core business logic. These three metrics—execution efficiency, resource consumption, and business priority—are used as multi-dimensional evaluation dimensions to comprehensively weight and score each candidate path, ultimately selecting the path with the highest comprehensive score as the optimal execution path.

[0080] Unlike existing technologies that lack necessary verification mechanisms, leading to logical chain malfunctions, this application provides a software function dynamic orchestration-driven method based on lightweight large-model intent understanding. This method rigorously examines and corrects directed acyclic graphs using a triple verification algorithm of integrity, prohibition, and redundancy. It also selects the optimal path based on efficiency and resource consumption metrics. This approach minimizes software overhead while ensuring absolute execution security and compliance, eliminating invalid flows, and fully realizing user intent.

[0081] S50: Based on the optimal execution path and the metadata of each functional module after assignment, generate structured execution instructions to drive the corresponding functional modules to execute collaboratively.

[0082] The optimal execution path topology, function call information of each module, and parameter configuration information that has already been assigned values ​​are used as input data. Combined with the lightweight prompt word project, the data is serialized and transformed according to a preset structured data specification to generate structured execution instructions. The preferred structured data specification is JSON format, which has strong hierarchical nesting capabilities and cross-platform parsing capabilities, ensuring that the generated instructions have high standardization, parsability, and absolute executability.

[0083] After generating structured execution instructions, format and logic checks are immediately performed on the instructions. Format checks verify the syntactic validity of the instructions, while logic checks confirm the completeness of parameters and the rationality of the execution path. If the checks fail, a rollback mechanism is triggered, returning to the previous execution to re-execute the path optimization and instruction generation process, ensuring zero defects in the issued instructions.

[0084] In an optional embodiment, after generating the structured execution instructions, the method further includes: S51: Extract the function identifiers of each functional module from the structured execution instructions, and retrieve the corresponding function call entry addresses from the dynamic registry based on the preset multi-layer anti-abnormal constraint mechanism.

[0085] The structured execution instructions that pass the verification are parsed to extract the function identifiers (IDs) of each functional module to be executed along the way. Using these function identifiers as indexes, a dynamic registry is accessed for precise retrieval. The dynamic registry maintains a strong mapping relationship between function identifiers and the underlying actual function call entry addresses.

[0086] To ensure that the retrieved function identifiers exist in the dynamic registry and to completely avoid anomalies such as non-existent or unmatched function identifiers from the source, multiple layers of fault tolerance and constraint measures are adopted: The first aspect is the consistency constraint of the library body. A strict one-to-one correspondence is maintained between the functional knowledge base and the dynamic registration library. The functional knowledge base stores descriptions of functional modules, while the dynamic registration library records the function call entry addresses of the functional call functions. When a new functional module is added, it must be registered synchronously in both libraries to ensure a one-to-one mapping between functional descriptions and executable functions, thus preventing mismatches at the data level.

[0087] The second aspect involves strong constraints on the scope of intent parsing. During the intent decomposition and understanding stages, the scope is strictly limited to preset functional categories through prompt word engineering. Subsequent intent matching and retrieval stages only perform semantic searches within the functional knowledge base, ensuring that the output functional identifiers all come from existing and registered functional sets within the software, preventing the generation of non-existent functional identifiers out of thin air.

[0088] The third aspect is that the execution logic is guaranteed by traditional algorithms. Traditional programmatic algorithms are used to generate a directed acyclic graph of execution paths, rather than having the execution process directly planned by a large model. This further avoids the large model from freely combining, fabricating functional modules or dependencies due to illusions.

[0089] Under the aforementioned multi-layered mechanism, the core function of the large model is to understand the intent of user input and verify the feasibility of the generated execution path, determining whether it conforms to the user's core intent, rather than generating function identifiers or constructing execution logic. Therefore, it can absolutely guarantee that the retrieved function identifiers exist in the dynamic registry library, avoiding anomalies such as not being able to find the corresponding function call entry address.

[0090] S52: Load and execute the corresponding function program based on the function call entry address to drive the functional module to complete the business execution.

[0091] After successfully retrieving the corresponding function call entry address in the dynamic registry, the corresponding function is precisely invoked based on the program address through the underlying call interface. The structured execution instructions are then sent to the core business layer, driving the corresponding functional modules to start and complete the specific business logic execution, achieving the final transformation from natural language intent to code-level execution.

[0092] Unlike existing technologies where large models can easily generate non-existent functional modules, leading to logical chain malfunctions, this application provides a software function dynamic orchestration-driven method based on lightweight large model intent understanding. By introducing multi-layered anti-anomaly constraint mechanisms such as library consistency and strong constraints on intent parsing range, it accurately retrieves function call entry addresses in the dynamic registration library. This eliminates underlying crashes caused by missing function call entry addresses at both the data and algorithmic levels, ensuring the absolute stability of the entire dynamic orchestration closed loop.

[0093] In an optional embodiment, during the execution of the functional module, the method further includes: S53: In response to a function module triggering a collaborative call with other function modules during execution, or when external dependency data needs to be obtained, the scheduled bypass execution process can directly complete the call and data acquisition.

[0094] During the execution of functional modules according to the optimal execution path, their running status is monitored in real time. In response to a functional module triggering a collaborative call request with other functional modules, or when it is identified that the current module needs to obtain external dependency data, a bypass execution process is immediately scheduled to directly complete the call or data acquisition.

[0095] This bypass mechanism establishes a fast channel directly between the core business layer and the scheduling execution engine, completely bypassing the intent extraction and task dynamic planning processes of the large model orchestration layer. It also combines expert models or lightweight small models for scheduling decisions to achieve efficient scheduling. These expert models or lightweight small models focus on structured decision-making tasks such as functional dependency verification and execution sequence planning, without processing user natural language, resulting in extremely low inference overhead and extremely fast response speed.

[0096] The software function dynamic orchestration driving method based on lightweight large model intent understanding provided in this application schedules a preset execution bypass during the execution of functional modules to directly complete cross-module collaborative interaction and external dependency data acquisition, effectively avoiding redundant intervention of the top-level large model orchestration layer. At the same time, it combines lightweight expert small models to achieve efficient scheduling, significantly reducing the complexity of internal call links and overall response time in the operation phase of complex tasks.

[0097] In one optional embodiment, to more intuitively demonstrate the technical effects and micro-execution logic of the method of this application, the entire lifecycle execution process of the intrinsic intelligent orchestration is fully deduced in conjunction with a specific PC assistant software application scenario. Suppose a user inputs a complex natural language request into the software: "Book me an afternoon flight from Shanghai to Guangzhou tomorrow, economy class, window seat." After completing the formatting and permission verification, the access layer and gateway layer will route the standardized requests to the large model orchestration layer.

[0098] In step S10, the large model orchestration layer calls the lightweight large model to perform deep semantic parsing of the user's original request. The model accurately extracts the user's core intent as flight search and booking. It also identifies several constraint-based auxiliary intents, such as travel time, cabin class, and seat preference. Further, the core intent is decomposed into four structured sub-intents: Ziyi Figure 1 The destination is confirmed as Guangzhou; Ziyi Figure 2 The departure point is confirmed as Shanghai. Ziyi Figure 3 The departure date is confirmed for tomorrow; Ziyi Figure 4 : Perform the flight booking operation.

[0099] Based on this, construct the logical relationships between each sub-intention, and determine the sub-intention. Figure 1 , two The three are in a parallel constraint relationship, and all three together serve as child intentions. Figure 4 Prerequisites.

[0100] Proceeding to step S20, category identifier binding and precise extraction of key parameters are completed based on preset prompts. The preset prompts are pre-categorized into standardized functional categories such as file processing, system settings, network tools, application management, information query, and text editing. The model semantic matching determines that the request belongs to the intersection of information query and application services, and matches and binds the corresponding category identifier. Simultaneously, the model structurally extracts and generates a key parameter dictionary, explicitly recording that the departure point is Shanghai, the destination is Guangzhou, the travel date is tomorrow, the travel time is afternoon, the seat class is economy class, and the seat preference is window seat.

[0101] Simultaneously determine the task type: The core action of this request is to book tickets, which is an operation-type task that will cause changes in business data and involve business processes. It is not a purely static data query task. Therefore, it does not trigger the database query bypass mechanism and normally enters the subsequent functional path orchestration and instruction generation process.

[0102] Proceed to step S30, using the category identifier as a filtering condition, quickly narrow down the candidate functional module set in the functional knowledge base. Convert each parsed sub-intent into a low-dimensional intent feature vector. Taking the flight ticket query sub-intent as an example, convert it into a four-dimensional low-dimensional intent feature vector A, assuming its value is [1.2, 0.5, 0.9, 0.3].

[0103] Within the candidate functional module set, the low-dimensional functional feature vectors corresponding to each module are traversed and matched one by one. When the flight ticket query functional module is matched, its pre-stored low-dimensional functional feature vector B is extracted, with an example value of [1.15, 0.55, 0.85, 0.35].

[0104] By calculating the ratio of the dot product of two sets of vectors to the product of their magnitudes, the cosine similarity is solved, resulting in a high-match similarity score, thus accurately matching the target functional module.

[0105] Subsequently, the core metadata of the functional module is read, including: the function identifier FUNCTION_FLIGHT_QUERY, the function name queryFlightTicket, and a standardized set of input parameters containing multiple fields such as departure point and destination.

[0106] Based on the key parameters extracted above, the parameter set is mapped and assigned values ​​one by one: the departure point parameter is assigned to Shanghai, the destination parameter is assigned to Guangzhou, the travel date parameter is assigned to tomorrow, the travel time parameter is assigned to afternoon, the seat class parameter is assigned to economy class, and the seat preference parameter is assigned to window seat, thus completing the complete instantiation configuration of the metadata.

[0107] Proceed to step S40 to extract the dependency constraints and temporal relationships between the input and output parameters of each functional module that has completed parameter assignment. In accordance with business security rules, two mandatory pre-conditions must be met before executing the flight ticket order: first, verification of real-name authentication status compliance; second, verification of sufficient available balance in the user account.

[0108] There is no interaction of input / output parameters between the functional modules corresponding to the above two constraints; they are executed in parallel. Meanwhile, the real-name authentication result and the account balance verification result are both necessary input parameters for the flight ticket order module. Therefore, it is determined that the three types of functional nodes form a business logic of initial parallel execution followed by serial execution after result aggregation.

[0109] Based on a programmatic algorithm, sub-directed acyclic graphs are first constructed for the real-name authentication module and the account balance query module; then the output nodes of the two parallel sub-directed acyclic graphs are aggregated and associated with the flight ticket ordering module, and finally integrated with the execution link of the upstream flight ticket query module to construct a complete global directed acyclic graph.

[0110] Once the global directed acyclic graph (DAG) is constructed, a pre-defined triple verification mechanism is initiated. This mechanism sequentially performs integrity checks, loop checks and prohibition checks, and redundancy checks. For example, during the redundancy check, if a legacy weather query branch is detected, and this branch has no business relationship or functional contribution to the core intent of this flight booking, it is determined to be an invalid redundant path and removed. Simultaneously, the global DAG is updated.

[0111] Finally, by combining three types of quantitative indicators—execution efficiency, resource consumption, and business priority—the global directed acyclic graph was comprehensively evaluated. The main business link with the lowest resource consumption, the best overall execution latency, and the highest business priority was selected as the optimal execution path for this task.

[0112] In step S50, following the standardized JSON structure specification, the topology of the optimal execution path, the function identifier FUNCTION_FLIGHT_QUERY of the flight ticket query module, and the parameter configuration carrying complete assignment information such as Shanghai to Guangzhou are uniformly encapsulated to generate standardized JSON structured execution instructions.

[0113] The system parses and extracts function identifiers from structured execution instructions and sends a function call entry address addressing request to the dynamic registry. Based on the strong constraints of intent parsing and library consistency verification in the preceding steps, a multi-layered anti-anomaly constraint mechanism can be established to ensure that function identifiers are effectively registered in the dynamic registry from the source, effectively preventing addressing failures and call anomalies caused by the illusion of a large model.

[0114] The dynamic registration library returns the function call entry address corresponding to the current function identifier based on a pre-defined one-to-one mapping relationship. The scheduling and execution engine loads and calls the corresponding function program according to this address, driving the core business layer to start the execution of the business process.

[0115] During the execution of the core business layer's flight booking module, an internal collaborative call bypass optimization mechanism is triggered. If the business execution phase identifies that the user only specifies Shanghai as the departure city, but the underlying system lacks real-time GPS location data for the user, it is impossible to complete the auxiliary calculation of commute time and travel to the airport.

[0116] At this point, the flight booking module sends a cross-module collaborative call request to the scheduling execution engine. It directly enables a preset execution bypass, bypassing the large model orchestration layer, and combines this with a lightweight expert mini-model responsible for timing planning and short-process scheduling to quickly complete the lightweight call to the positioning module. The obtained coordinate data is then synchronously populated back into the current business context, achieving cross-module data collaboration.

[0117] This application presents a software function dynamic orchestration-driven method based on lightweight large-scale model intent understanding. By natively embedding the large-scale model into the scheduling core, it overcomes the technical defects of traditional software function collaboration solidification and function matching failures caused by target decomposition generalization. Utilizing a lightweight large-scale model and standardized preset prompts, it accurately extracts user intent and key parameters, and combines a function knowledge base to achieve precise function matching and metadata instantiation assignment. This strongly constrains semantic retrieval and function matching scope to the set of registered legitimate functions, significantly suppressing the large-scale model illusion problem from the source and reducing the risk of matching link breakage. Simultaneously, it employs a programmatic algorithm to uniformly construct the execution path topology, generating a directed acyclic graph and filtering the optimal execution path through multi-level verification. This abandons the unstable implementation method of simply relying on the large-scale model to autonomously generate business logic chains, ensuring the compliance, rationality, and stability of the global execution path under multi-intent concurrency and complex business scenarios from the bottom layer. Finally, it drives the scheduling and operation of underlying functional modules through standardized structured instructions, fully realizing dynamic intelligent orchestration of software functions centered on user natural language intent. This solution significantly reduces model deployment costs and operating overhead while ensuring high stability and reliability, meeting the needs of engineering implementation.

[0118] This application provides a software function dynamic orchestration driving device based on lightweight large model intent understanding, see reference. Figure 2 , Figure 2 This is a schematic diagram of an embodiment of the software function dynamic orchestration driving device based on lightweight large model intent understanding provided in this application. The software function dynamic orchestration driving device based on lightweight large model intent understanding includes: The intent extraction module 10 is used to receive input requests and extract multiple intents of the input requests based on a lightweight large model; The parameter extraction module 20 is used to determine the category identifier of each intent based on preset prompt words, and extract the key parameters of each intent; The matching and assignment module 30 is used to match the corresponding functional module in the pre-built functional knowledge base based on the category identifier, obtain the metadata of the functional module, and assign values ​​to the metadata with the key parameters. The path filtering module 40 is used to generate a directed acyclic graph of execution paths based on the dependency constraints and temporal relationships of each of the functional modules through a programmed algorithm, and to filter the optimal execution path by combining multidimensional constraints. The instruction generation module 50 is used to generate structured execution instructions based on the optimal execution path and the metadata of each of the functional modules after assignment, so as to drive the corresponding functional modules to execute collaboratively.

[0119] In an optional embodiment, the path filtering module 40 is specifically used for: Obtain the dependency constraints and temporal relationships between the input and output parameters of each functional module, and determine the sub-execution path corresponding to each intent based on the dependency constraints and temporal relationships; Based on the sub-execution paths and programmatic algorithms, corresponding sub-directed acyclic graphs are generated and integrated into the global directed acyclic graph according to business logic. The directed acyclic graph is validated and updated based on a preset validation algorithm, and the optimal execution path is selected from the updated directed acyclic graph in combination with the multidimensional constraints.

[0120] In an optional embodiment, the step of verifying and updating the directed acyclic graph based on a preset verification algorithm, and selecting the optimal execution path from the updated directed acyclic graph in conjunction with the multidimensional constraints, includes: The directed acyclic graph is subjected to integrity verification. In response to the existence of an uncovered intent, the functional knowledge base is re-matched, and the directed acyclic graph is updated based on the matching result. The directed acyclic graph is subjected to loop verification and prohibition verification. In response to the existence of execution loops or preset prohibited functional dependencies, the corresponding execution path is deleted and the directed acyclic graph is updated. Redundancy check is performed on the directed acyclic graph, and redundant paths in the directed acyclic graph are deleted; By combining execution efficiency, resource consumption, and business priority metrics, the optimal execution path is selected from the updated directed acyclic graph.

[0121] In an optional embodiment, after generating the structured execution instructions, the instruction generation module 50 is further configured to: Extract the function identifiers of each functional module from the structured execution instructions, and retrieve the corresponding function call entry addresses from the dynamic registry based on a preset multi-layer anti-abnormal constraint mechanism. The corresponding function program is loaded and executed based on the function call entry address to drive the functional module to complete the business execution.

[0122] In an optional embodiment, the matching assignment module 30 is specifically used for: Using the category identifier as a filtering condition, a set of candidate functional modules is determined in the functional knowledge base; Each intent is converted into a low-dimensional intent feature vector. In the candidate functional module set, the low-dimensional intent feature vector is compared with the low-dimensional functional feature vector corresponding to each functional module to match the corresponding functional module.

[0123] In an optional embodiment, after extracting the key parameters of each of the stated intentions, the method further includes: In response to the current task being a pure data query operation, the extracted key parameters are directly forwarded to the corresponding business database to perform the query operation and return the query results.

[0124] In an optional embodiment, during the execution of the functional module, the following further steps are included: In response to the functional module being executed triggering a collaborative call with other functional modules, or the need to obtain external dependent data, the scheduled bypass execution process can directly complete the call or data acquisition.

[0125] Since the embodiments of the device part correspond to the embodiments of the above method, the description of the software function dynamic orchestration driving device based on lightweight large model intent understanding provided in this application is referred to the above method embodiments. This application will not repeat it here, as it has the same beneficial effects as the above software function dynamic orchestration driving method based on lightweight large model intent understanding.

[0126] See Figure 3 , Figure 3 This is a schematic diagram of an embodiment of the storage medium provided in this application.

[0127] The storage medium 300 stores program data 310, which, when executed by the processor, implements, as follows: Figure 1 The steps of the described software function dynamic orchestration-driven method based on lightweight large model intent understanding are described.

[0128] The program data 310 is stored in a storage medium 300 and includes several instructions for causing a network device (which may be a router, personal computer, server, or other network device) or processor to execute all or part of the steps of the methods described in the various embodiments of this application.

[0129] Optionally, the storage medium 300 can be any medium capable of storing program data, such as a USB flash drive, portable hard drive, read-only memory (ROM), random access memory (RAM), disk, or optical disc.

[0130] See Figure 4 , Figure 4 This is a schematic diagram of the structure of an embodiment of the computer device provided in this application.

[0131] The device 400 includes a processor 420 and a memory 410 interconnected. The memory 410 stores a computer program, and when the processor 420 executes the computer program, it implements, for example, Figure 1 The steps of the described software function dynamic orchestration-driven method based on lightweight large model intent understanding are described.

[0132] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, the storage medium embodiments and computer device embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0133] This application can be used in a wide range of general-purpose or special-purpose computing system environments or configurations. For example: personal computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, network PCs, minicomputers, distributed computing environments including any of the above systems or devices, etc.

[0134] In the several embodiments provided in this application, it should be understood that the disclosed methods and devices can be implemented in other ways. For example, the device embodiments described above are merely illustrative; multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed.

[0135] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0136] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0137] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A software function dynamic orchestration-driven method based on lightweight large model intent understanding, characterized in that, include: Receive input requests and extract multiple intents from the input requests based on a lightweight large model; Based on preset prompts, the category identifier of each intent is determined, and the key parameters of each intent are extracted; In the pre-built functional knowledge base, the corresponding functional module is matched based on the category identifier, and the metadata of the functional module is obtained. The metadata is then assigned a value using the key parameters. Based on the dependency constraints and temporal relationships of each functional module, a directed acyclic graph of execution paths is generated through a programmatic algorithm, and the optimal execution path is selected by combining multidimensional constraints. Based on the optimal execution path and the metadata of each functional module after assignment, structured execution instructions are generated to drive the corresponding functional modules to execute collaboratively.

2. The software function dynamic orchestration driving method based on lightweight large model intent understanding as described in claim 1, characterized in that, Based on the dependency constraints and temporal relationships of each functional module, a directed acyclic graph of execution paths is generated through a programmatic algorithm, and the optimal execution path is selected by combining multi-dimensional constraints, including: Obtain the dependency constraints and temporal relationships between the input and output parameters of each functional module, and determine the sub-execution path corresponding to each intent based on the dependency constraints and temporal relationships; Based on the sub-execution paths and programmatic algorithms, corresponding sub-directed acyclic graphs are generated and integrated into the global directed acyclic graph according to business logic. The directed acyclic graph is validated and updated based on a preset validation algorithm, and the optimal execution path is selected from the updated directed acyclic graph in combination with the multidimensional constraints.

3. The software function dynamic orchestration driving method based on lightweight large model intent understanding as described in claim 2, characterized in that, The step of updating the directed acyclic graph based on a preset verification algorithm, and selecting the optimal execution path from the updated directed acyclic graph in conjunction with the multidimensional constraints, includes: The directed acyclic graph is subjected to integrity verification. In response to the existence of an uncovered intent, the functional knowledge base is re-matched, and the directed acyclic graph is updated based on the matching result. The directed acyclic graph is subjected to loop verification and prohibition verification. In response to the existence of execution loops or preset prohibited functional dependencies, the corresponding execution path is deleted and the directed acyclic graph is updated. Redundancy check is performed on the directed acyclic graph, and redundant paths in the directed acyclic graph are deleted; By combining execution efficiency, resource consumption, and business priority metrics, the optimal execution path is selected from the updated directed acyclic graph.

4. The software function dynamic orchestration driving method based on lightweight large model intent understanding as described in claim 1, characterized in that, After generating the structured execution instructions, the method further includes: Extract the function identifiers of each functional module from the structured execution instructions, and retrieve the corresponding function call entry addresses from the dynamic registry based on a preset multi-layer anti-abnormal constraint mechanism. The corresponding function program is loaded and executed based on the function call entry address to drive the functional module to complete the business execution.

5. The software function dynamic orchestration driving method based on lightweight large model intent understanding as described in claim 1, characterized in that, The step of matching the corresponding functional module in the functional knowledge base based on the category identifier includes: Using the category identifier as a filtering condition, a set of candidate functional modules is determined in the functional knowledge base; Each intent is converted into a low-dimensional intent feature vector. In the candidate functional module set, the low-dimensional intent feature vector is compared with the low-dimensional functional feature vector corresponding to each functional module to match the corresponding functional module.

6. The software function dynamic orchestration driving method based on lightweight large model intent understanding as described in claim 1, characterized in that, After extracting the key parameters of each of the stated intentions, the following is also included: In response to the current task being a pure data query operation, the extracted key parameters are directly forwarded to the corresponding business database to perform the query operation and return the query results.

7. The software function dynamic orchestration driving method based on lightweight large model intent understanding as described in claim 1, characterized in that, During the execution of the aforementioned functional module, the following is also included: In response to the functional module being executed triggering a collaborative call with other functional modules, or the need to obtain external dependent data, the scheduled bypass execution process can directly complete the call or data acquisition.

8. A software function dynamic orchestration driving device based on lightweight large model intent understanding, characterized in that, include: The intent extraction module is used to receive input requests and extract various intents from the input requests based on a lightweight large model; The parameter extraction module is used to determine the category identifier of each intent based on preset prompt words, and extract the key parameters of each intent; The matching and assignment module is used to match the corresponding functional module in the pre-built functional knowledge base based on the category identifier, obtain the metadata of the functional module, and assign values ​​to the metadata with the key parameters. The path filtering module is used to generate a directed acyclic graph of execution paths based on the dependency constraints and temporal relationships of each of the functional modules through a programmatic algorithm, and to filter the optimal execution path by combining multidimensional constraints. The instruction generation module is used to generate structured execution instructions based on the optimal execution path and the metadata of each of the functional modules after assignment, so as to drive the corresponding functional modules to execute collaboratively.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the software function dynamic orchestration driving method based on lightweight large model intent understanding as described in any one of claims 1-7.

10. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the software function dynamic orchestration driving method based on lightweight large model intent understanding as described in any one of claims 1-7.

Images