A quantum algorithm workflow processing method and system based on a large language model

Abstract

The application discloses a kind of quantum algorithm workflow processing method and system based on large language model, belong to quantum algorithm technical field.The method includes conversation service subsystem dynamic synchronization atomization algorithm list, and atomization algorithm list is maintained by computing power service subsystem;Conversation service subsystem carries out intention recognition, constructs context;LLM generates DAG structure proposal according to input language, context and backflow alarm information;Pre-execution check gateway carries out pre-execution check, and generates check result;Conversation service subsystem backflows alarm information to LLM;Computing power service subsystem asynchronously executes DAG structure proposal.The application carries out intention recognition to input language, when it is algorithm intention, generates DAG structure proposal, and is checked by pre-execution check gateway, and after checking, DAG proposal is executed again, effectively avoid computing power waste;When check is not passed, backflow information is modified original DAG proposal to form automatic correction closed loop.

Description

Technical Field

[0001] This invention relates to the field of quantum algorithm technology, and more specifically to a quantum algorithm workflow processing method and system based on a large language model. Background Technology

[0002] Currently, in recent years, quantum computing software frameworks such as IBM Qiskit, Xanadu PennyLane, and Google Cirq have been widely used in research institutions, universities, and enterprises, and are the main tools for researchers to build and run quantum algorithms. Generally, the typical process for completing an experiment based on an existing quantum algorithm framework is as follows: In a local Python environment, the user manually assembles each step of the quantum algorithm using the framework's SDK API. This includes constructing the Hamiltonian, constructing parameterized quantum circuits, configuring the classical optimizer, and calling the Variable Quantum Eigenvalue Solver (VQE). The user manually configures the parameter dependencies between algorithms, such as manually passing the constant terms output from the Hamiltonian construction step to the energy offset parameters of the VQE step. The user writes a Python script to chain the above steps and manually selects the computing backend, such as a local simulator or remote quantum hardware. When the user needs to perform parameter scans, such as scanning energy curves with molecular bond lengths between 0.5 and 2.5 Å, a for loop needs to be manually written and scheduled serially / parallel. The user manually manages the asynchronous state between the script and the remote computing power; if the callback link fails occasionally, compensation needs to be written manually. The script is submitted for execution, consuming physical or simulator computing power, and the user waits for the results. If incorrect parameters are found, such as incorrect settings, incorrect aperture, incorrect dimensions, or incorrect parameter coupling between atoms, the script is modified and resubmitted.

[0003] Recently, there have been attempts in the industry to use large language models (LLMs) to assist in the generation of scientific computing code. Examples include IBM's Qiskit Code Assistant and several open-source projects that use GPT or similar models to automatically generate Qiskit / PennyLane code snippets to help users assemble algorithm scripts. The essence of this type of solution remains the same: LLM generates code → user manual review → user manual submission for execution. The LLM output enters the computational consumption stage without domain semantic verification. Furthermore, the toolsets that the LLM can call are hard-coded in the code or prompts; after a new algorithm is deployed, the code needs to be modified and redeployed before the LLM can detect it. In addition, quantum algorithm workflows involve multiple steps with strict physical / chemical / mathematical constraints. For example, in quantum chemistry, the ground state energy output by the VQE step must be correctly added to the Hamiltonian constant before it can be compared with the experimental reference value. If the user forgets to add the constant or the dimensions are mismatched, the VQE returned value may appear reasonable but actually deviates from the physical truth. Such errors in existing solutions are only identified after physical computational power has been exhausted and the erroneous result is seen, resulting in a significant waste of computational power.

[0004] Therefore, how to reduce computing power consumption while minimizing output errors caused by manual transmission is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] In view of the above problems, the present invention is proposed to provide a quantum algorithm workflow processing method and system based on a large language model that overcomes or at least partially solves the above problems.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] In a first aspect, embodiments of the present invention provide a quantum algorithm workflow processing method based on a large language model, comprising: The session service subsystem dynamically synchronizes the atomicity algorithm list, which is maintained by the computing power service subsystem. The atomicity algorithm list is used to record the atomic identifier and atomic specification of each atom. The session service subsystem receives input language for intent recognition and constructs a context when the intent is an algorithm task-type intent. LLM generates a DAG structure proposal based on the input language, the context, and the alarm information of the return flow. The DAG structure proposal includes multiple nodes and directed edges, and each node corresponds to an atomic call. The pre-execution verification checkpoint performs pre-execution verification on the DAG structure proposal and generates verification results; When the verification result is a verification failure, the session service subsystem will send the alarm information corresponding to the verification result back to the LLM; When the verification result is successful, the computing power service subsystem asynchronously executes the DAG structure proposal.

[0008] In one implementation, the session service subsystem dynamically synchronizes the atomic algorithm list, including: The session service subsystem synchronizes the atomic algorithm list at a first preset interval to obtain an initial atomic algorithm list; The session service subsystem translates the atomic specifications in the initial atomicity algorithm list into the LLM callable calling specifications.

[0009] In one embodiment, after the LLM generates a DAG structure proposal based on the input language, the context, and the reflow alarm information, it further includes: When any of the nodes in the DAG structure proposal is a scan parameter node, the orchestration engine generates N child nodes corresponding to the scan parameter node based on the scan parameter declared by the scan parameter node and the value range corresponding to the scan parameter. The orchestration engine inserts an aggregation node downstream of the N child nodes, aligns and aggregates the outputs of the N child nodes to obtain an energy curve, and marks the N child nodes with a parallel scheduling flag.

[0010] In one embodiment, the pre-execution verification includes format verification, dependency integrity verification, cross-atomic domain contract verification, and executability verification. The pre-execution verification gate performs pre-execution verification on the DAG structure proposal, including: The actual input parameters are format-validated by the input parameter specification in the atomic specification, and the actual input parameters include scan parameters and non-scan parameters. The dependency integrity check is performed based on the parameter reference information of each directed edge in the proposed DAG structure. According to the cross-atomic domain contract rules, the cross-atomic domain contract verification is performed on the atomic combinations in the DAG structure proposal that have domain semantic constraints. The executability verification is performed based on the available information of the computing power backend, the reasonableness of the number of sampling measurements, and the user quota.

[0011] In one embodiment, the cross-atomic domain contract rules include an energy shift contract, a spin sector contract, a qubit consistency contract, and a reference state matching contract, wherein: The energy offset contract is as follows: if the DAG structure proposal contains a combination of a molecular Hamiltonian and a solver, then the energy offset parameter of the solver references the target field of the molecular Hamiltonian. The spin sector contract is as follows: the observables of the upstream atom's declared output state and the downstream atom's expected value calculation are in the same sector; The quantum number consistency contract is: the quantum number consistency of the multi-atom link; The reference state matching contract is: the atomic reference states are defined in a consistent manner.

[0012] In one embodiment, before the computing power service subsystem asynchronously executes the DAG structure proposal, it further includes: When the verification result is that the verification is successful, the DAG structure proposal is pushed to the user front end through the session service subsystem; The session service subsystem receives the run request sent by the user frontend and sends an execution request to the computing power service subsystem for executing the DAG structure proposal.

[0013] In one embodiment, after the computing power service subsystem asynchronously executes the DAG structure proposal, it further includes: The computing power service subsystem obtains the node status of each node in the DAG structure proposal and transmits it back to the session service subsystem through N preset channels, where N is an integer greater than 1; The session service subsystem writes the node status and pushes it to the user's front end via server events.

[0014] In one embodiment, the preset channels include a main path Webhook channel, a fallback channel, and a manual re-pull channel. The step of sending data back to the session service subsystem through N preset channels includes: When transmitted through the main path Webhook channel, the computing power service subsystem sends the node status to the preset callback address of the session service subsystem; When transmitting through the fallback channel, the session service subsystem queries the computing power service subsystem for the node status of non-final nodes at second preset intervals. The non-final nodes are nodes that have not completed the atomic algorithm. When transmitting through the manual re-pull channel, the session service subsystem, upon receiving a pull request from the user's front-end device, pulls the node status of each node from the computing power service subsystem.

[0015] In one embodiment, after the session service subsystem writes the node state and pushes it to the user's front end via server events, it further includes: The LLM obtains the execution result of the DAG structure proposal, generates an interpretation statement corresponding to the input language based on the execution result, and writes the interpretation statement into the database.

[0016] Secondly, embodiments of the present invention provide a quantum algorithm workflow processing system based on a large language model, employing the following technical solution: a computing power service subsystem, a pre-execution verification gateway, a session service subsystem, and an LLM, wherein: The session service subsystem is used to dynamically synchronize the atomic algorithm list; receive input language for intent recognition, construct a context when the intent is an algorithm intent; and when the verification result is a verification failure, send an alarm message back to the LLM; wherein, the atomic algorithm list is used to record the atomic identifier and atomic specification of each atom; The LLM is used to generate a DAG structure proposal based on the input language, the context, and the alarm information of the return flow. The DAG structure proposal includes multiple nodes and directed edges, and each node corresponds to an atomic call. The pre-execution verification checkpoint is used to perform pre-execution verification on the DAG structure proposal and generate verification results; The computing power service subsystem is used to maintain the list of atomic algorithms and asynchronously execute the DAG structure proposal when the verification result is a successful verification.

[0017] The beneficial effects of the above-described technical solutions provided in the embodiments of the present invention include at least the following: The session service subsystem dynamically synchronizes the list of atomic algorithms maintained by the computing power service subsystem to perform intent recognition on the input language. When the intent is confirmed to be an algorithm intent, the corresponding context is constructed to call the LLM. The LLM corrects and regenerates the DAG structure proposal based on the input language, context, and backflow alarm information, thus realizing a closed loop in DAG structure proposal generation. The DAG structure proposal is pre-executed using a pre-execution verification gate that does not consume computing power. If the verification fails, alarm information for backflow is generated. The relevant DAG structure proposal is only executed after the verification passes, thus effectively avoiding unnecessary consumption of computing power. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention 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 embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0019] Figure 1This is a schematic diagram of the workflow processing method for quantum algorithms based on large language models provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the system deployment architecture provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the process of expanding the parameter scanning node provided in the embodiment of the present invention; Figure 4 This is a schematic diagram of cross-atomic domain contract verification provided in an embodiment of the present invention; Figure 5 This is a complete flowchart provided in an embodiment of the present invention. Detailed Implementation

[0020] 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 some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Recently, there have been attempts in the industry to use large language models to assist in the generation of scientific computing code. For example, IBM's Qiskit Code Assistant and several open-source projects use GPT or similar models to automatically generate Qiskit / Penny Lane code snippets to help users assemble algorithm scripts. The essence of this type of solution is still LLM code generation → user manual review → user manual submission for execution. The LLM output enters the computing power consumption stage without domain semantic verification. At the same time, the toolset that LLM can call is hard-coded in the code or prompt words. After a new algorithm is launched, the code needs to be modified and redeployed before it can be detected by LLM.

[0022] However, firstly, quantum algorithm workflows involve multiple steps, with strict physical / chemical / mathematical constraints between them. For example, in quantum chemistry, the ground-state energy output by the VQE step must be correctly summed with the Hamiltonian constant before it can be compared with the experimental reference value. If the user forgets to add the constant or the dimensions are mismatched, the value returned by VQE may appear reasonable but actually deviates from the physical truth. Such errors in existing schemes can only be identified after physical computing power has been exhausted and the erroneous result is seen, resulting in a significant waste of computing power.

[0023] Second: When the workflow contains more than four atomic algorithms with different parameter names, manually filling the output parameters of the upstream steps into the input parameters of the downstream steps will greatly increase the probability of errors.

[0024] Third: Existing LLM technology only performs syntax completion and does not perform domain semantic verification. Therefore, it may generate scripts that are syntactically correct but semantically incorrect, and users can only perceive the error when the system reports it. Otherwise, users may use incorrect information.

[0025] Fourth: When a user needs to scan a certain parameter, if the user still manually writes loops, manually manages parallelism, serial scheduling, and manually converges and aggregates the results, even if the user uses LLM to assist in generating code, LLM can only output serial script fragments and cannot directly produce a parallel DAG that can be scheduled by the orchestration engine.

[0026] Fifth: The callback link between the quantum computing backend and the user system experiences occasional failures. Related technologies rely solely on webhooks or polling, but there is no compensation entry visible to the user when both channels fail.

[0027] Sixth: In LLM-assisted quantum computing systems, the toolset that the LLM can call is usually hard-coded in the form of prompts or codes. When a new algorithm atom is added to the computing backend, the LLM side needs to be manually synchronized.

[0028] To facilitate understanding of the embodiments of the present invention, the relevant terms are explained below: Atom: Algorithm unit; Atomic algorithms: computational logic encapsulated within atoms; DAG structure proposal node: A running instance in the DAG structure, each node can call an atom; Directed edges proposed in the DAG structure: used to represent the dependency relationship between two nodes.

[0029] This invention discloses a quantum algorithm workflow processing method based on a large language model, enabling users to describe research goals in natural language. The system automatically arranges execution plans, completes domain semantic verification and iterative correction before consuming physical computing power, automatically expands the parameter scanning intent into a parallel DAG, and ensures the eventual consistency of the asynchronous task's final state with a multi-channel fallback mechanism. Figure 1 The diagram illustrates a quantum algorithm workflow processing method based on a large language model provided by an embodiment of the present invention. The method includes steps S1 to S6: Step S1: The session service subsystem dynamically synchronizes the atomic algorithm list. The atomic algorithm list is maintained by the computing power service subsystem and is used to record the atomic identifier and atomic specification of each atom.

[0030] Specifically, such as Figure 2The diagram shown illustrates the system deployment architecture provided in this embodiment of the invention. The session service subsystem and the computing power service subsystem are two independently deployed subsystems. The session service subsystem is responsible for dialogue state, intent recognition, interaction with the LLM, and DAG structure proposal and confirmation. The computing power service subsystem is responsible for the actual execution of atomic algorithms, capability list maintenance, pre-verification, and callback.

[0031] The list of atomized algorithms is pre-defined by technical personnel; the list of atomized algorithms includes at least the atom name of each atom, input parameter specifications, output parameter specifications, a list of executable computing backends, cross-atomic domain contract rules, and whether parameter scanning is supported.

[0032] The specific process of maintaining the atomic algorithm list in the synchronous computing power service subsystem includes: the session service subsystem can retrieve the latest atomic algorithm list from the computing power service subsystem at a first preset interval, such as five minutes, and load it into the memory cache. The input parameter specifications and output parameter specifications of each atom are then translated into specifications that can be called by the LLM. Understandably, when a new atom appears in the atomic algorithm list, it can be called simply through dynamic synchronization, without needing to restart the session service subsystem to include it in the toolset, effectively shortening the link from algorithm deployment to being callable via the session.

[0033] Step S2: The session service subsystem receives the input language for intent recognition and constructs a context when the intent is an algorithm task.

[0034] Specifically, in this embodiment of the invention, the intent corresponding to the input language can be an algorithmic task or a knowledge consultation; when the intent is an algorithmic intent, an execution plan needs to be triggered, while when it is a knowledge consultation, only a dialogue response is required. It is understood that performing intent recognition on the input language and only triggering the DAG structure proposal execution process when the intent is an algorithmic intent can avoid the time consumption caused by accidental triggering of knowledge consultation.

[0035] Intent recognition can be achieved through heuristic keywords, LLM, a small model classifier trained on historical data, or when LLM fails to return a DAG proposal. The LLM can be a DeepSeek, Claude, or GPT model.

[0036] The intent recognition method using only heuristic keywords includes: matching the input language with keywords to determine the target keywords; and determining the intent corresponding to the target keywords based on the correspondence between the target keywords and intent categories.

[0037] Intent recognition via LLM alone involves inputting the input language into the LLM, and the LLM outputting the intent.

[0038] Intent recognition is achieved by using a small model classifier trained on historical data, which includes: inputting the input language into the small model classifier, and the small model classifier outputting the intent corresponding to the input language.

[0039] When the LLM cannot return a DAG structure proposal, intent recognition is performed, including: inputting all natural language into the LLM. If the LLM can output a DAG structure proposal, the intent of the input language is determined to be the algorithm intent; otherwise, the intent of the input language is determined to be a consultation dialogue. When the intent is a consultation dialogue, no computing power is consumed.

[0040] The above-mentioned four intent recognition methods—heuristic keyword recognition, LLM recognition, small model classifier recognition, and whether LLM can produce DAG structure proposals—are interchangeable implementation methods, and one should be selected for actual deployment. When LLM is used for intent recognition, the LLM shall undertake the intent recognition function.

[0041] The atomic algorithm list, historical session messages, domain memory blocks, and parameter scan semantic templates can be concatenated to obtain the context.

[0042] For example, when a user inputs "scan the energy curve of the H2 molecule between 0.5 and 2.5 Å", the session service subsystem concatenates the following content into a context: an atomized algorithm list containing the calling specifications for constructing the molecular Hamiltonian and VQE optimization solutions; historical session messages containing the target molecule H2; a domain memory block that the VQE solution must satisfy the energy offset contract; and a parameter scan semantic template. The parameter scan semantic template can be the scan parameter node corresponding to the statement that scans X from a to b to take N points. The LLM takes the context obtained by concatenating the above content as input and outputs a DAG structure proposal with scan parameter nodes.

[0043] Step S3: Based on the input language, context, and backflow alarm information, LLM generates a DAG structure proposal. The DAG structure proposal includes multiple nodes and directed edges, with each node corresponding to an atomic call.

[0044] Specifically, a directed edge between two nodes represents a dependency relationship between parameters. The directed edge can carry a dependency relationship of "a certain output field of the upstream node → a certain input parameter of the downstream node".

[0045] The DAG structure proposal can be based on structured data, YAML, XML, Protobuf, or a custom IR, such as JSON. Dependencies can be represented using ${node_id.field}, @node_id / field, or reference expressions based on JSONPath or JMESPath.

[0046] The specific process of generating a DAG structure proposal includes: LLM takes the concatenated context and atomic call specifications as input and reasons according to the following process: First, the research goal is decomposed into an ordered sequence of atomic calls; second, a target atom is selected for each atomic call, and the actual input parameters are filled in according to the input parameter specifications of that atom; third, based on the semantic correspondence between the output fields of upstream atoms and the input parameters of downstream atoms, directed edges carrying parameter reference information are established, and the parameter reference information is represented in the form of ${node_id.field}; finally, if the parameter scanning intention is identified, the corresponding node is marked as a parameter scanning node, and its parameter scanning parameters and value range are declared, outputting a structured DAG structure proposal.

[0047] Specifically, when LLM recognizes that the input language contains a scanning intent and the scanning parameters involved in the scanning intent are marked as batch traversable in the atomic algorithm list, it determines that there are scanning nodes in the DAG structure proposal, and LLM outputs the DAG structure proposal with scanning nodes. When the input language contains the option to scan once, take N points between X and Y, or calculate once for each layer, it is determined that there is a scanning intent.

[0048] Understandably, when a DAG structure proposal has a parameter scanning node, the DAG structure proposal with the expanded node is sent to the session service subsystem. When a DAG structure proposal does not have a parameter scanning node, it is directly sent to the session service subsystem, which then sends the received DAG structure proposal to the pre-execution verification interface of the computing power service subsystem.

[0049] When a DAG structure proposal has parameter scanning nodes, LLM sends the DAG structure proposal to the session service subsystem. After receiving the DAG structure proposal, the session service subsystem calls the orchestration engine, which expands all parameter scanning nodes.

[0050] Specifically, the orchestration engine can deploy parameter scanning nodes in the session service subsystem or the computing power service subsystem.

[0051] The expansion of the parameter-scanning node described above employs a deferred expansion method. That is, the LLM does not automatically enumerate all child nodes, but only outputs a single parameter-scanning node carrying the parameter declaration and its value range. The expansion of this node into N parallel child nodes and an aggregation node is postponed to the orchestration engine stage. In this way, the output size of the LLM is independent of the number of child nodes N, avoiding output bloat when N is large. Furthermore, the expansion process is deterministic and does not depend on the LLM correctly enumerating all child nodes.

[0052] like Figure 3The diagram shown illustrates the expansion of a parameter-scanning node according to an embodiment of the present invention. Expanding the parameter-scanning node specifically includes: generating N child nodes based on the declared parameter-scanning parameters and their value range [a, b], with each child node corresponding to one value; automatically inserting an aggregation node downstream of each child node; aligning the outputs of each child node according to the original parameter-scanning order to aggregate them into a set of data points or energy curves; and marking the child nodes as parallelizable. It is understood that by marking them as parallelizable, the computing power service subsystem can determine the number of parallelizable child nodes based on the current computing power when asynchronously executing the DAG structure proposal. It is also understood that by expanding the DAG structure proposal composed of multiple parallel child nodes and aggregation nodes, and performing pre-execution verification on the expanded parameter-scanning subtasks, the link can be made transparent and enjoy the same semantic verification protection.

[0053] The declaration form of the scan parameter node can be either directly annotating the scan traversal parameter fields; it can be determined based on the correspondence between the parameter type and the declaration form of the scan parameter node; or it can be determined by the LLM in the DAG structure proposal.

[0054] In this embodiment of the invention, the subsequent processing flow of the expanded DAG structure proposal and the non-expanded DAG structure proposal is the same, therefore the parameter scanning capability is transparent to the verification and execution chain. It can be understood that when a user has a parameter scanning requirement, it is directly expanded into multiple parallel schedulable subtasks and the results are automatically aggregated, eliminating the need for the user to manually write loops or manage concurrency.

[0055] Step S4: The pre-execution verification gate performs pre-execution verification on the DAG structure proposal and generates verification results.

[0056] Specifically, the pre-execution verification gate in the computing power service subsystem does not schedule physical computing power or simulators for execution. Understandably, by using the pre-execution verification gate between the generation of the quantum algorithm workflow and the consumption of physical computing power, domain semantic errors can be intercepted before computing power consumption, effectively avoiding irrelevant computing power consumption, and the verification speed is fast.

[0057] Pre-execution checks include: specification checks, dependency integrity checks, cross-atomic domain contract checks, and executability checks.

[0058] The specification verification includes: for each node in the DAG structure proposal, verifying whether all required parameters are filled in, whether the parameter specifications of each required parameter match, and whether the value range of each required parameter is valid, according to the input parameter specification of the atom in the atomicity algorithm list.

[0059] Dependency integrity verification includes: verifying the existence of the referenced node for the parameter references of each edge in the DAG structure proposal, and whether the type of the referenced field belongs to the output parameter specification of that node.

[0060] like Figure 4 The diagram shown illustrates cross-atomic domain contract verification according to an embodiment of the present invention. Cross-atomic domain contract verification includes: verifying atomic combinations in a DAG structure proposal that have domain semantic constraints according to a preset set of contract rules.

[0061] The contract rule set includes multiple rules used to describe physical, chemical, or mathematical constraints between a group of atoms; the contract rule set includes energy shift contracts, spin sector contracts, quantum bit consistency contracts, and reference state matching contracts.

[0062] The energy offset contract states that if a DAG structure proposal contains both a node for constructing a molecular Hamiltonian atomic algorithm and a node for VQE optimization solving atomic algorithm, then the energy offset parameter of the VQE optimization solving atomic algorithm node must reference the output field of the molecular Hamiltonian atomic algorithm node.

[0063] The spin sector contract states that if an upstream atom declares that its output state belongs to a certain spin sector, then the observables of the downstream atom used for calculating the expected value must belong to the same spin sector.

[0064] Specifically, in a quantum chemical system, quantum states are divided into different spin sectors based on their total spin and its projection quantum number. If the quantum state prepared by an upstream atom belongs to a certain spin sector, such as a singlet state with zero total spin, while the observable used by the downstream atom for calculating the expected value is defined in a different spin sector, then the calculated expected value is physically meaningless. Therefore, the spin sector contract check verifies whether the spin sector of the output state declared by the upstream atom is consistent with the spin sector of the downstream observable; the check is considered successful only if they are consistent.

[0065] Quantum bit consistency contract: The number of qubits involved in a multi-atom link must be consistent.

[0066] The reference state matching contract states that different atoms must have the same definition of the reference state, vacuum state, or initial state.

[0067] Understandably, the above constraints are distilled into an enumerable and scalable set of contract rules through a cross-atomic domain contract verification rule set, which is then enforced by the computing power service subsystem during the verification phase. Adding new atoms or new contract rules does not require modification of the LLM prompt or the front-end; it only requires registering the new contract in the computing power service subsystem to take effect, demonstrating good scalability.

[0068] The executability check includes: checking whether the target computing power backend is available, whether the number of sampling measurements is reasonable, and whether the number of sampling measurements exceeds the user quota.

[0069] In this embodiment of the invention, the contract rule set is an extensible rule set. That is, when the computing power service subsystem registers a new atom or constraint, only a new rule file needs to be added for it to take effect; no modification to the main dialog LLM prompts or front-end code is required. The contract rule set can be expressed in code embedding, rule file format, rule engine, SAT / SMT solver, formal method, or by embedding the contract into the atom format itself, such as declaring in the format that the parameter must reference the output of a certain source. The rule engine can be the Drools class or CEL; the formal method can be a type system or dependency type. Cross-atomic domain contracts are enforced in the form of an enumerable and extensible rule set, rather than relying on the user or large language model to memorize them. The number of sampling measurements is the number of quantum sampling measurements.

[0070] Understandably, a pre-execution verification gate is introduced between LLM proposal generation and formal execution. Verification is completed within seconds, with typical real-world measurements ≤10 seconds. Physical quantum hardware execution times typically range from minutes to hours and are billed by shot. In cloud simulator scenarios, a single VQE optimization may require thousands of circuit evaluations, and any parameter error amplifies into a massive waste of computing power. The pre-execution verification gate intercepts such errors before they consume computing power, significantly reducing the actual cost per experiment.

[0071] Step S5: When the verification result is a verification failure, the session service subsystem will send the alarm information corresponding to the verification result back to the LLM.

[0072] Specifically, if the computing power service subsystem detects that the nodes in the proposed DAG structure are not standardized, the dependencies between edges are incomplete, or it fails to comply with cross-atomic domain contract verification or executability verification, the verification fails. The computing power service subsystem generates an alarm message and sends it to the session service subsystem. Simultaneously, the session service subsystem injects the alarm message into the next round's context, and the LLM automatically adjusts and outputs a new DAG structure proposal based on the context and alarm message, and re-executes the verification. The alarm message includes the alarm type, the nodes involved, a readable description, and suggested correction methods.

[0073] The alarm types correspond to the types of pre-execution checks, including: specification check failures, such as missing required parameters, mismatched parameter types, or values ​​exceeding the legal range; dependency integrity check failures, such as the referenced upstream node not existing or the referenced field not belonging to the output parameter specification of that upstream node; cross-atomic domain contract check failures, such as incorrect reference of energy offset parameters, inconsistency between upstream and downstream spin sectors, inconsistency in the number of qubits in multi-atomic links, or inconsistency in the definition of reference states; and executability check failures, such as the target computing power backend being unavailable, unreasonable sampling measurement counts, or exceeding the user quota.

[0074] In the first feasible approach, when the number of consecutive verification failures exceeds a threshold, the DAG structure proposal corresponding to the last verification and the unresolved alarm are sent to the user's front-end device, allowing the user to decide whether to continue generating DAG structure proposals. The threshold can be manually set, such as 2-3 times; alternatively, the allowed number of verification failures can be dynamically determined based on the alarm level.

[0075] Specifically, the process of dynamically determining the allowable number of verification failures based on the alarm level includes: pre-setting an alarm level for each alarm type, wherein the alarm level includes fatal alarms and recoverable alarms. Fatal alarms are alarms that cannot be eliminated through automatic correction, and recoverable alarms are alarms that can be adjusted through automatic correction. When the alarm type is a specification verification failure alarm or a cross-atomic domain contract verification failure alarm, the corresponding alarm level is a fatal alarm. When the alarm type is a dependency integrity verification failure alarm or an executability verification failure alarm, the corresponding alarm level is a recoverable alarm.

[0076] If a fatal alarm is generated in this round of verification, the smaller number of allowed failures is taken, such as 1 time, and then the case is handed over to the user for processing; if all alarms in this round are recoverable, the larger number of allowed failures is taken, such as 3-5 times, and then the LLM automatically iterates and corrects it; that is, the number of times corresponding to the highest alarm level in this round of alarms is taken as the number of allowed verification failures for this time.

[0077] In the second possible approach, the user is required to confirm on the front-end device whether to continue the correction after each verification failure.

[0078] In the third possible approach, the user is prompted to change the input language each time the validation fails.

[0079] In another possible implementation, when the verification result is a failure, the session service subsystem does not initiate an execution request to the computing power service subsystem by default to avoid unnecessary consumption of computing power. Only after the user's front-end device explicitly confirms that it is aware of the corresponding alarm and risk can the user initiate an execution request for the DAG structure proposal. It can be understood that the default non-execution ensures that unintentionally generated erroneous workflows will not consume computing power, while the user's active confirmation after being aware of the risk preserves the user's final decision-making right for boundary situations.

[0080] It is understood that the verification process in the embodiments of the present invention can be completed within seconds and does not require physical computing power.

[0081] Step S6: If the verification result is successful, the computing power service subsystem asynchronously executes the DAG structure proposal.

[0082] Specifically, if the verification passes, the computing power service subsystem will send the DAG structure proposal and the node parameters of each node to the user front end. After review, the user will send the run request to the session service subsystem. The session service subsystem will then send an execution request to the computing power service subsystem, at which point physical computing power or simulator computing power will begin to be consumed.

[0083] Users can confirm by clicking the confirmation button, or by voice, command line, or automatic confirmation.

[0084] After receiving the execution request, the computing power service subsystem asynchronously executes the DAG structure proposal. Specifically, the computing power service subsystem determines the ready nodes according to the topological order based on the dependencies between the nodes in the DAG structure proposal. A ready node is a node whose upstream nodes have all completed execution. Then, it obtains the current available computing power of the system and determines the number of nodes that can be scheduled in parallel based on the computing power required by the node task of each ready node and the current available computing power, and executes the corresponding number of ready nodes. The above process is repeated as the nodes complete execution until all nodes in the DAG structure proposal have been executed.

[0085] Furthermore, the updated node state is transmitted back to the session service subsystem via three independent channels to maintain final state consistency. These independent channels include the main path Webhook, the fallback polling channel, and the manual restart channel.

[0086] The three independent channels are distinguished and independent of each other based on their status return triggering methods: the main path Webhook channel is actively pushed by the computing power service subsystem, the fallback channel is periodically polled by the session service subsystem, and the manual re-pull channel is manually triggered by the user. The main path Webhook channel can also be implemented using equivalent methods such as Webhook combined with message queue consumption or Webhook combined with long connections. These equivalent methods are all different implementations of the actively pushed channel.

[0087] Specifically, when the independent channel is the main path Webhook and the computing power service subsystem confirms that the node status has been updated, it actively sends a request to the callback address pre-registered by the session service subsystem through the main path Webhook, and carries an internal access token for authentication.

[0088] When the independent channel is used as a fallback channel for polling, the session service subsystem maintains a polling coroutine. That is, the session service subsystem actively queries the computing power service subsystem for the latest status of all nodes that are not in the final state at second preset intervals. If the main path Webhook is missed or lost, the polling channel can ensure that the final state of the nodes remains consistent.

[0089] When the independent channel is a manual re-pull channel, the user front-end sets a re-pull result button next to each node with an incomplete task. When the user clicks the button on the front-end device, it triggers the session service subsystem to actively pull the node's final state to the computing power service subsystem and overwrite the local record.

[0090] It is understandable that by writing the three channels of Webhook, polling, and manual re-pull into the same state table, the failure of any single channel can ensure that the overall final state consistency is not affected. Manual re-pull, as a compensation entry point visible to the user, provides a last resort in the extreme case where both Webhook and polling fail, and the operation is completely idempotent.

[0091] In this embodiment of the invention, the main path Webhook channel, the fallback channel, and the manual re-pull channel are all written to the same state table, and state machine constraints are used to ensure that multiple writes of the same final state of the task on the same node do not produce side effects.

[0092] Furthermore, after receiving the node status, the session service subsystem writes it to the database and pushes it to the user's front end via a server push event (SEE).

[0093] Once the DAG structure proposal is confirmed to have been successfully executed in its final state, the session service subsystem calls the lightweight LLM.

[0094] After the DAG structure proposal final state is successfully executed, the lightweight LLM generates the interpretation statement corresponding to the input language.

[0095] Specifically, the lightweight LLM that generates interpretation statements corresponding to the input language differs from the LLM that generates DAG structure proposals. In this embodiment of the invention, the former is smaller, for example, it can be a Haiku model. Then, 3-5 natural language interpretations are generated from the result of the successful DAG final state and written to the database; the next user message can directly reference this result to continue asking questions, forming a dialogue-computation-interpretation-re-dialogue closed loop.

[0096] Interpretive language can be generated automatically, through user requests, or by grading results based on quality.

[0097] Specifically, the process of generating interpretation statements based on result quality grading includes: after the DAG structure proposal is successfully executed, the result is graded according to its quality, which is determined by indicators such as whether the integrity check is passed, the magnitude of the relative error, and whether convergence has occurred; when the result is of high quality, such as when the relative error is less than the chemical precision, a concise confirmatory interpretation statement is generated; when the result is of medium quality, such as when there is some deviation, an interpretation statement containing a description of the deviation, possible causes, and correction suggestions is generated; when the result is of low quality, an interpretation statement containing diagnostic information and correction suggestions is generated.

[0098] like Figure 5 The diagram illustrates the complete process provided in an embodiment of the present invention. In one specific implementation, the user inputs language, and the session service subsystem performs intent recognition based on the user's input language to determine whether it is an algorithm intent or a knowledge consultation intent. If it is confirmed to be an algorithm intent, a context is constructed based on the input language and input into the LLM. The LLM performs parameter scanning intent recognition and DAG structure proposal based on the context and the input language. When a parameter scanning intent exists in the input language, a DAG structure proposal with parameter scanning nodes is output; when no parameter scanning intent exists in the input language, the DAG structure proposal is directly output.

[0099] When a DAG structure proposal includes a scan node, the session service subsystem calls the orchestration engine, which expands the scan node.

[0100] Then, the pre-execution verification gate in the computing power service subsystem, which does not consume computing power, performs specification verification, dependency integrity verification, cross-atomic domain contract verification, and executability verification on the DAG structure proposal.

[0101] When verification fails, an alarm message is generated. The session service subsystem feeds the alarm message back to the context. The LLM corrects the error and generates a new DAG structure proposal based on the alarm message and the context.

[0102] When the verification passes, the proposed DAG structure and the node parameters of each node are displayed on the user's front end, and the user sends an execution request. The computing power service subsystem executes the DAG asynchronously and sends the node status back to the session service subsystem through three independent channels. The session service subsystem transmits the node status to the user's front end through server push events. At the same time, the lightweight LLM outputs interpretation statements based on the execution result of the proposed DAG structure.

[0103] Based on the same inventive concept, this embodiment of the invention also provides a quantum algorithm workflow processing system based on a large language model. Since the principles by which these systems solve problems are similar to those of the aforementioned methods, the implementation of this system can refer to the implementation of the aforementioned methods, and the repeated parts will not be described again.

[0104] This invention provides a quantum algorithm workflow processing system based on a large language model, including a computing power service subsystem, a pre-execution verification gateway, a session service subsystem, and an LLM, wherein: The session service subsystem is used to dynamically synchronize the atomic algorithm list; it receives input language for intent recognition, constructs a context when the intent is an algorithm intent; and sends an alarm message back to the LLM when the verification result is a verification failure; the atomic algorithm list is used to record the atom identifier and atom specification of each atom. LLM is used to generate a DAG structure proposal based on the input language, context and return alarm information. The DAG structure proposal includes multiple nodes and directed edges, and each node corresponds to an atomic call. The pre-execution verification gate is used to perform pre-execution verification on the DAG structure proposal and generate verification results; The computing power service subsystem is used to maintain a list of atomic algorithms and asynchronously execute DAG structure proposals when the verification result is a pass.

[0105] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0106] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A quantum algorithm workflow processing method based on a large language model, characterized in that, include: The session service subsystem dynamically synchronizes the atomicity algorithm list, which is maintained by the computing power service subsystem. The atomicity algorithm list is used to record the atomic identifier and atomic specification of each atom. The session service subsystem receives input language for intent recognition and constructs a context when the intent is an algorithm task-type intent. LLM generates a DAG structure proposal based on the input language, the context, and the alarm information of the return flow. The DAG structure proposal includes multiple nodes and directed edges, and each node corresponds to an atomic call. The pre-execution verification checkpoint performs pre-execution verification on the DAG structure proposal and generates verification results; When the verification result is a verification failure, the session service subsystem will send the alarm information corresponding to the verification result back to the LLM; When the verification result is successful, the computing power service subsystem asynchronously executes the DAG structure proposal.

2. The quantum algorithm workflow processing method based on a large language model as described in claim 1, characterized in that, The session service subsystem dynamically synchronizes the list of atomic algorithms, including: The session service subsystem synchronizes the atomic algorithm list at a first preset interval to obtain an initial atomic algorithm list; The session service subsystem translates the atomic specifications in the initial atomicity algorithm list into the LLM callable calling specifications.

3. The quantum algorithm workflow processing method based on a large language model as described in claim 1, characterized in that, After generating the DAG structure proposal based on the input language, the context, and the reflow alarm information, the LLM further includes: When any of the nodes in the DAG structure proposal is a scan parameter node, the orchestration engine generates N child nodes corresponding to the scan parameter node based on the scan parameter declared by the scan parameter node and the value range corresponding to the scan parameter. The orchestration engine inserts an aggregation node downstream of the N child nodes, aligns and aggregates the outputs of the N child nodes to obtain an energy curve, and marks the N child nodes with a parallel scheduling flag.

4. The quantum algorithm workflow processing method based on a large language model as described in claim 1, characterized in that, The pre-execution verification includes format verification, dependency integrity verification, cross-atomic domain contract verification, and executability verification. The pre-execution verification gate performs pre-execution verification on the DAG structure proposal, including: The actual input parameters are format-validated by the input parameter specification in the atomic specification, and the actual input parameters include scan parameters and non-scan parameters. The dependency integrity check is performed based on the parameter reference information of each directed edge in the proposed DAG structure. According to the cross-atomic domain contract rules, the cross-atomic domain contract verification is performed on the atomic combinations in the DAG structure proposal that have domain semantic constraints. The executability verification is performed based on the available information of the computing power backend, the reasonableness of the number of sampling measurements, and the user quota.

5. The quantum algorithm workflow processing method based on a large language model as described in claim 4, characterized in that, The cross-atomic domain contract rules include energy shift contract, spin sector contract, quantum bit consistency contract, and reference state matching contract, wherein: The energy offset contract is as follows: if the DAG structure proposal contains a combination of a molecular Hamiltonian and a solver, then the energy offset parameter of the solver references the target field of the molecular Hamiltonian. The spin sector contract is as follows: the observables of the upstream atom's declared output state and the downstream atom's expected value calculation are in the same sector; The quantum number consistency contract is: the quantum number consistency of the multi-atom link; The reference state matching contract is: the atomic reference states are defined in a consistent manner.

6. The quantum algorithm workflow processing method based on a large language model as described in claim 1, characterized in that, Before the computing power service subsystem asynchronously executes the DAG structure proposal, it also includes: When the verification result is that the verification is successful, the DAG structure proposal is pushed to the user front end through the session service subsystem; The session service subsystem receives the run request sent by the user frontend and sends an execution request to the computing power service subsystem for executing the DAG structure proposal.

7. The quantum algorithm workflow processing method based on a large language model as described in claim 1, characterized in that, After the computing power service subsystem asynchronously executes the DAG structure proposal, it also includes: The computing power service subsystem obtains the node status of each node in the DAG structure proposal and transmits it back to the session service subsystem through N preset channels, where N is an integer greater than 1; The session service subsystem writes the node status and pushes it to the user's front end via server events.

8. The quantum algorithm workflow processing method based on a large language model as described in claim 7, characterized in that, The preset channels include a main path Webhook channel, a fallback channel, and a manual re-pull channel. The process of sending data back to the session service subsystem through N preset channels includes: When transmitted through the main path Webhook channel, the computing power service subsystem sends the node status to the preset callback address of the session service subsystem; When transmitting through the fallback channel, the session service subsystem queries the computing power service subsystem for the node status of non-final nodes at second preset intervals. The non-final nodes are nodes that have not completed the atomic algorithm. When transmitting through the manual re-pull channel, the session service subsystem, upon receiving a pull request from the user's front-end device, pulls the node status of each node from the computing power service subsystem.

9. The quantum algorithm workflow processing method based on a large language model as described in claim 7, characterized in that, After the session service subsystem writes the node status and pushes it to the user's front end via server events, it also includes: The LLM obtains the execution result of the DAG structure proposal, generates an interpretation statement corresponding to the input language based on the execution result, and writes the interpretation statement into the database.

10. A quantum algorithm workflow processing system based on a large language model, characterized in that, It includes a computing power service subsystem, a pre-execution verification gateway, a session service subsystem, and an LLM, among which: The session service subsystem is used to dynamically synchronize the atomic algorithm list; receive input language for intent recognition, construct a context when the intent is an algorithm intent; and when the verification result is a verification failure, send an alarm message back to the LLM; wherein, the atomic algorithm list is used to record the atomic identifier and atomic specification of each atom; The LLM is used to generate a DAG structure proposal based on the input language, the context, and the alarm information of the return flow. The DAG structure proposal includes multiple nodes and directed edges, and each node corresponds to an atomic call. The pre-execution verification checkpoint is used to perform pre-execution verification on the DAG structure proposal and generate verification results; The computing power service subsystem is used to maintain the list of atomic algorithms and asynchronously execute the DAG structure proposal when the verification result is a successful verification.

Images