Methods and systems for specification extraction and model building using language models

Abstract

Methods and systems generating an optimization model, including: obtaining a set of problem specifications that collectively describe the optimization problem, wherein each problem specification comprises a defined data structure that includes a natural language (NL) description of a respective element represented in an optimization model for the optimization problem; generating, based on the set of problem specifications together with a NL problem description of the optimization problem, NL model component generation prompts for a large language model (LLM); and generating a symbolic model for the optimization problem based on LLM generated outputs obtained in response to the model component generation prompts.

Description

METHODS AND SYSTEMS FOR SPECIFICATION EXTRACTION AND MODEL BUILDING USING LANGUAGE MODELSTECHNICAL FIELD

[0001] The present disclosure relates to methods and systems for specification extraction and model building using language models, where a resulting model instance can be inputted to an optimization solver to solve an optimization problem.BACKGROUND

[0002] Many real-world problems are optimization problems, such as how to minimize usage of a limited resource or how to maximize throughput of a system. In many cases, these optimization problems are complex (e.g., having many different constraints, many different conditions, many different variables, etc. ) and cannot be practically solved by humans. Optimization solvers (also simply referred to as “solvers” ) are software tools that have been developed to enable computer systems to solve such optimization problems.

[0003] A conventional process for solving an optimization problem involves a first human expert (e.g., an application domain (AD) expert) working with another human expert (e.g., an operations research (OR) consultant) to formulate problem specifications (e.g., the optimization objective (s) , constraints, etc. ) that is then converted into an optimization model and the model is instantiated into a model instance using actual numerical data. The model instance is in the form of computer-readable code that can be inputted to the solver.

[0004] The creation of problem specifications and their subsequent conversion into an optimization model can be iterative and are performed until the AD expert and the OR consultant agree on problem specifications and proposed optimization model. For example, the following stages are representative of a standard solution for building an optimization model.

[0005] Stage 1: Understand the Application Domain

[0006] An OR consultant starts by understanding the context or domain in which the optimization model is to be applied. This can, for example, include understanding the business or process that the optimization problem exists within. This stage involves meetings, observations, and data collection, which can also uncover knowledge gaps that an AD expert may have about their own operations. This stage enables an optimization model to be developed that will align well with domain of the problem that it is intended to solve.

[0007] Stage 2: Communicate with the AD expert

[0008] In this stage, the OR consultant communicates iteratively with the AD expert to understand the problem they're trying to solve, the constraints, and their assumptions. This communication often involves frequent meetings, during which the OR consultant guides the AD expert through the process, filling in any knowledge gaps and clarifying the necessary information for creating proper optimization model. However, due to the difference in expertise, there's a potential for misunderstandings, which could lead to incorrect problem specifications. Therefore, the OR consultant must ensure clear and precise communication, as this stage is critical for ensuring alignment between the problem specifications and the optimization model to be developed.

[0009] Stage 3: Create the Optimization Model

[0010] Based on the information gathered in the previous stages, the OR consultant creates an optimization model that encapsulates the problem using a mathematical formulation or modeling language. The optimization model should align with the problem specifications outlined by the AD expert. The OR consultant must be aware that while the AD expert may not understand the detailed workings of the model, they should understand its inputs and outputs to validate its alignment with their original problem and objectives.

[0011] Stage 4: Communicate the Model Solution

[0012] The OR consultant presents their solution to the AD expert. They do this either by directly communicating the model solution or by providing restricted API access to the model. During this stage, the OR consultant needs to ensure the AD expert understands how the model's inputs and outputs align with their problem  specifications. The OR consultant should also explain how the model's outputs correlate with their original problem and objectives. Feedback from the AD expert is used to refine the model, ensuring a tighter alignment between the model and the problem specifications.

[0013] Stage 5: Feedback and Refinement

[0014] The AD expert reviews the solution and provides feedback to the OR consultant. This feedback is vital in aligning the model more closely with the problem that is to be solved and the AD expert's requirements. If the AD expert suggests changes to better represent their problem, the OR consultant incorporates this feedback and refines the model. As noted previously, this process can be iterative.

[0015] Standard solutions such as described above for building an optimization model can encounter multiple inefficiencies that can result in a poor solution. Examples of potential barriers to an effective solution are set out in the following paragraphs.

[0016] Traditional communication methods between AD experts and OR consultants involve lengthy discussions and meetings. While this approach allows a thorough exchange of ideas, it can often be inefficient and time-consuming. There's a risk of crucial information being lost or misunderstood due to the sheer volume of data exchanged.

[0017] Differences in language and expertise between the AD expert and the OR consultant can increase the risk of miscommunication. The OR consultant and the AD expert usually have different areas of expertise, often leading to them speaking different "languages. " This situation increases the risk of misunderstandings and miscommunications, as complex models and problems need to be articulated in a language that both parties understand.

[0018] Acquiring domain knowledge for creating optimization models can be time-consuming for OR consultants. Creating an optimization model requires a deep understanding of the application domain. OR consultants have to develop some domain-knowledge in order to understand the problem adequately which can be time-consuming. This process can delay the project, especially when the OR  consultant needs to familiarize themselves with a new industry or business process.

[0019] Searching for relevant template models for developing new OR models can be complicated and time-consuming. OR consultants often use previous examples or templates of models as a foundation for developing new ones. However, finding an appropriate template model can be complicated and sometimes impossible, depending on the uniqueness of the problem to be solved and the availability of relevant models. This process requires substantial expertise.

[0020] Lack of clarity in problem descriptions from the AD expert can lead to misalignment between the problem and the developed optimization model. The problem descriptions from the AD expert often lack clarity or specificity, making it challenging for the OR consultant to determine the exact requirements. This situation can lead to potential misalignment between the business problem and the developed model.

[0021] Dealing with unstructured problem descriptions increases the chance of errors and delays in project timeline. Unstructured problem descriptions increase the likelihood of misunderstandings and errors. To resolve this issue, OR consultants must ask clarifying questions to better understand the problem. However, this process usually leads to more meetings and discussions, potentially extending the overall project timeline.

[0022] In an attempt to mitigate the issues noted above, known solutions for modeling an optimization problem will typically leverage tools like modeling languages and solver application programming interfaces (APIs) to rewrite the problem description into computer-interpretable formats. However, this requires the user to have deep understanding of the decision-making problem as well as model building in order to understand the components of the optimization model and to describe it in code or math formulation.

[0023] Accordingly, there is a need for systems and methods that enable the knowledge of AD experts and OR consultants to be efficiently gathered and applied to improve the accessibility of solvers and / or improve the efficiency in solving optimization problems.SUMMARY

[0024] In various examples, the present disclosure describes a computer implemented method for generating an optimization model, including: obtaining a set of problem specifications that collectively describe the optimization problem, wherein each problem specification comprises a defined data structure that includes a natural language (NL) description of a respective element represented in an optimization model for the optimization problem; generating, based on the set of problem specifications together with a NL problem description of the optimization problem, NL model component generation prompts for a large language model (LLM) ; and generating a symbolic model for the optimization problem based on LLM generated outputs obtained in response to the model component generation prompts.

[0025] In some examples, the method comprises obtaining the NL problem description of the optimization problem; wherein obtaining the set of problem specifications comprises: generating, based on the NL problem description of the optimization problem, NL specification extraction prompts; and generating the problem specifications based on LLM generated outputs obtained in response to the NL specification extraction prompts.

[0026] In one or more of the preceding examples, the method comprises generating, based on the NL problem description and previously generated content of the problem specifications, NL reference extraction prompts; extracting reference data mapping respective problem specifications to respective parts of the NL problem description based on LLM generated outputs obtained in response to the NL reference extraction prompts; and including the reference data in the respective problem specifications.

[0027] In one or more of the preceding examples, the method comprises obtaining an NL conversation history of exchanges between human parties about the optimization problem, wherein the NL model component generation prompts and the NL specification extraction prompts are each generated also based on the NL conversation history.

[0028] In one or more of the preceding examples, the problem specifications are each associated with a category from a predefined set of categories and the NL specification extraction prompts include a plurality of different specification extraction prompts that are each respectively generated to extract data pertaining to a respective category from the predefined set of categories.

[0029] In one or more of the preceding examples, the method comprises presenting the problem specifications to a user for editing and / or selection, wherein the NL model component generation prompts are generated based on the problem specifications as edited and / or selected.

[0030] In one or more of the preceding examples, the symbolic model includes a plurality of model components that each represent respective math symbols included in the symbolic model, the method comprising, for each model component: generating, based on the problem specifications and previously generated content of the model component, a respective NL relation extraction prompt; extracting reference data mapping the model component to one or more of the problem specifications; and including the reference data in the model component.

[0031] In one or more of the preceding examples, the method comprises: for each model component: generating, based on the problem specifications and previously generated content of the model component, a respective NL explanation prompt; extracting explanation data that explains a purpose of the model component; and including the explanation data in the model component.

[0032] In one or more of the preceding examples, the method comprises: causing the symbolic model to be transformed into a model instance and solved by a solver to provide a solution for the optimization problem, wherein the solution specifies a change in a physical domain.

[0033] In some example aspects, the present disclosure describes a computing system including a processing unit configured to execute computer-readable instructions to cause the system to perform the method of any one of the preceding example aspects of the method.

[0034] In another example aspect, the present disclosure describes a non-transitory computer readable medium having machine-executable  instructions stored thereon, where the instructions, when executed by a processing unit of an apparatus, cause the apparatus to perform the method of any one of the preceding example aspects of the method.BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Reference will now be made, by way of example, to the accompanying drawings which show example embodiments of the present application, and in which:

[0036] FIG. 1 is a block diagram of an example system that may be used to generate specifications and a corresponding symbolic model, and instantiate a model instance, in accordance with examples of the present disclosure;

[0037] FIG. 2 is a block diagram of an example computing system that may be used to implement examples of the present disclosure;

[0038] FIG. 3 is a block diagram showing different sub-categories and types of problem specifications that can be generated by a program specification generator of the system of FIG. 1;

[0039] FIG. 4 is a block diagram showing operations performed by the specification generator of the system of FIG. 1

[0040] FIG. 5 is block diagram of example workflow and Prompt templates associated with an explicit and implicit problem specification extraction operation of the specification generator of FIG. 4.

[0041] FIG. 6 is a block diagram of an example workflow and Prompt templates associated with a problem specification reference extraction of the specification generator of FIG. 4.

[0042] FIG. 7 is a block diagram of an example workflow and Prompt templates associated with a problem specification relevance extraction of the specification generator of FIG. 4.

[0043] FIG. 8 is a flow diagram showing an illustrative problem specification generation for a “data parameter” type of problem specification by the specification generator of FIG. 4.

[0044] FIG. 9 is a block diagram illustrating operations performed by a symbolic model generator of the system of FIG. 1.

[0045] FIG. 10 is a block diagram illustrating a model component generators operation performed by the symbolic model generator of FIG. 9.

[0046] FIGs. 11A, 11B and 11C illustrate examples of prompt structures that can be used by the model component generators operation of FIG. 1

[0047] FIG. 12 is a block diagram illustrating a model-to-specification extractor operation performed by the symbolic model generator of FIG. 9.

[0048] FIG. 13 is a block diagram illustrating a model component explanations generator operation performed by the symbolic model generator of FIG. 9.

[0049] FIG. 14 shows examples of model components generated by the symbolic model generator of FIG. 9.

[0050] FIG. 15 shows a graphical user interface (GUI) according to example implementations.

[0051] FIG. 16 shows another graphical user interface (GUI) according to example implementations.

[0052] FIGs. 17A and 17B are a block diagram illustrating an example workflow for model component generation.

[0053] FIG. 18 shows another graphical user interface (GUI) according to example implementations.

[0054] Similar reference numerals may have been used in different figures to denote similar components.DETAILED DESCRIPTION

[0055] To assist in understanding the present disclosure, a description of selected terminology used herein is first provided. The following terms can have the following meanings as used herein unless the specific context requires otherwise.

[0056] The following terms can be grouped into five categories: (1) human actors; (2) optimization problem, (3) problem specifications, (4) optimization model; and (5) machine learning.

[0057] Human actor related terms include:

[0058] Application Domain (AD) Expert –AD experts are persons who possess a comprehensive understanding of the specific application domain and the optimization problem that needs to be solved within that application domain. However, the knowledge of the AD expert may not extend to operations research or mathematical modeling. To address this gap, AD experts engage OR consultants, either from within their organization or externally, to devise decision support systems that effectively address their domain challenges. An example of an AD Expert may for example be a plant manager who has comprehensive knowledge of plant operations and a problem with the plant operations that needs to be solved.

[0059] Operations research (OR) consultant –OR consultants are experts in the field of OR. Traditionally, AD experts rely on the OR consultants for help with modeling an optimization problem.

[0060] Optimization problem related terms include:

[0061] Optimization problem –An optimization problem (also referred to herein as a problem) is a decision-making scenario that requires a determination of the best possible solution or set of solutions from a set of available alternatives, subject to certain constraints. This could, for example, involve one or more of minimizing costs, maximizing profits, minimizing defects, maximizing process output, optimizing resource allocation, or improving efficiency, among other things.

[0062] Problem description –A problem description defines the optimization problem in natural language and is often ambiguous and unstructured. Problem description often originates from the observations, experiences, and insights of the AD expert or key stakeholders, who identify a pain point and an opportunity in  improving their operations. A problem description may be fraught with issues of ambiguity due to the technical jargon of the specific application domain or lack of clarity around the optimization problem itself. It may also be incomplete, potentially missing crucial information or assumptions. Thus, a part of the OR consultant's role is to work closely with the AD expert to clarify, refine, and formalize this problem description. The process of obtaining a problem description can traditionally involve active listening, open-ended questioning, and deep-dive exploration with the aim to understand the operational context, strategic goals, and potential constraints of the optimization problem at hand, as well as the data available for analysis.

[0063] Conversation History –Conversation History refers to the record of exchanges and interactions between the AD expert and OR consultant. This includes meeting summaries, email exchanges and any other form of written communication that has taken place over time. The history provides context to previous discussions, helping to track the progress of problem-solving or decision-making processes, and aids in maintaining a cohesive, ongoing dialogue.

[0064] Problem specification related terms include:

[0065] Problem Specifications –Problem Specifications are data structures that set out descriptions that represent elements of the particular problem or system that need to be considered to model and solve the problem. These elements can include requirements, constraints, objectives, calculations, data parameters, decisions, assumptions and entities of the problem to be modeled or optimized. In some examples, the purpose of problem specifications are multi-fold: fostering effective collaboration between OR consultants and AD experts during the problem definition phase by providing a clear and precise understanding of the problem, and serving as a guide during the model development process to aid in the generation of accurate models that ensure that the solution specifically addresses the unique needs and goals of the domain.

[0066] Optimization model related terms include:

[0067] Optimization model –Optimization model is an optimization problem that has been formulated into a structured format. An optimization model can include intermediate format models (e.g., symbolic model) and models that are in a final format that can easily be passed to a solver (e.g., a model instance, and model code)

[0068] Mathematical model / Mathematical formulation –Mathematical model / formulation refers to a representation of the optimization problem using math formulae.

[0069] Verification / Model verification –Verification is the process of verifying the alignment of the mathematical or symbolic model with the problem specifications. This process can, for example, be performed by OR consultants.

[0070] Validation / Model validation –Validation is the process of verifying the correctness of the mathematical or symbolic model in describing the optimization problem. This process can, for example, be performed by AD experts.

[0071] Modeling / Model formulation  / Formulate a model –Modeling refers to the process of converting the problem definition into a concrete optimization model (e.g., either a symbolic model, mathematical model, or model instance) .

[0072] Objective –The objective defines the goal of solving the problem (e.g., minimize the cost, maximize the amount of calcium, maximize the number of participants, minimize defects, etc. ) .

[0073] Constraint –The problem may have one or more constraints. The constraints are considerations of the problem either due to real-world limitations (e.g., no negative number of people, less than 200 kg of goods on the truck due to weight limitations) or due to user-specified desires (e.g. at least 10 items sold) .

[0074] Decision variable –decision variables are variables that have values that can be changed to reach the goal of the optimization problem.

[0075] Data parameter –Parameters are the numerical constants that are used to define constraints and objectives.

[0076] Set –A set contains all possible values or options and often corresponds to the indices of indexed decision variables or parameters (e.g., a set of possible options of “Fruits” to consider may be “apples” , “oranges” , “bananas” , etc. ) .

[0077] Model components –Model components are objectives, constraints, decision variables, parameters, and sets.

[0078] Symbolic model –A symbolic model is a representation of the optimization problem using math content without defined data values. Everything remains as symbols without assigning value to the symbols. A symbolic model may contain the mathematical objective and constraints of the optimization problem, represented as mathematical functions of symbols representing the data parameters and decision variables. The symbolic model may omit the semantic meaning of the mathematical symbols and formulas, such that the actual real-world relevance of the symbols and formulas may not be readily apparent from the symbolic model alone. For example, ∑iFi*Ci≤ bank funds is a symbolic constraint that could potentially be describing the sum of the number of different foods (this would be the decision variable that the solver will adjust the values of) and their corresponding costs must be less than available bank funds. However, the data definitions are not defined. Both the corresponding costs for each type of fruit and the bank funds are in their symbolic form without defining the numerical values.

[0079] Data values –The data values are the numerical constant values of sets and parameters.

[0080] Model instantiation –Model instantiation is the process of creating a model instance by loading the numerical constants of the data values into the symbolic model.

[0081] Model instance –a model instance is a specific formulation of the optimization problem that can be translated in a computer-readable code and provided to a solver. In some examples, a model instance can be stored on a tangible medium, such as a removable memory.

[0082] Modeling language –Modeling languages are computer programming languages that aid in the development of model instances. They often have graphical user interfaces that the user can interact with when formulating the optimization problem into a model instance.

[0083] Solution / Optimal solution –Value (s) of decision variable (s) that will optimize the objective function while adhering to the constraints.

[0084] Solve –The act of finding an optimal (near optimal) solution for the optimization model and outputting values for the decision variables.

[0085] Solver –Solvers (or optimization solvers) are software tools that takes as input the optimization model instance and implements standard algorithms to solve the optimization problems.

[0086] Machine learning related terms include:

[0087] Natural language Input –refers to any human language input that an artificial intelligence system receives. This input is in the form of spoken or written language that follows natural language rules of grammar and semantics, rather than programming or machine language. It also won′t contain any mathematical notations. Generally, it is used to communicate with AI systems in a way that mimics human conversation.

[0088] Prompt –A prompt is the input given to a machine learning model to generate an output. For example, in a conversational AI model like ChatGPT, the prompt is the user's input, like a question or statement, to which the model responds.

[0089] Large Language Model –A Large Language Model (LLM) is a type of AI model that's trained on a vast amount of text data. Its purpose is to predict or generate the next part of a text based on the given input. Models like GPT-3 or GPT-4 are examples of large language models, and they are widely used for various tasks, such as text generation, translation, summarization, and more.

[0090] Problem Context –The problem context is some text that the user provides at the start of the invention. It provides context to the problem.

[0091] Generation / Text generation –The task of generation is a subfield of NLP and the aim is to create human-interpretable text.

[0092] The present disclosure may make reference to “objective” in the singular and “constraints” in the plural, however the use of singular or plural is not intended to be limiting.

[0093] FIG. 1 is a schematic diagram illustrating an example optimization problem modeling system 100 (also referred to as system 100) according to example implementations. The system 100 may be implemented in a single physical machine or device (e.g., implemented as a single computing device, such as a single workstation, single server, etc. ) , or may be implemented using a plurality of physical machines or devices (e.g., implemented as a server cluster) . For example, the system 100 may be implemented as a virtual machine or a cloud-based service (e.g., implemented using a cloud computing platform providing a virtualized pool of computing resources) . In some examples, the system 100 may provide cloud-based services accessible to a user device.

[0094] By way of overview, in the example shown, the system 100 includes, as computational components, a specification generator 106, a specification editor  122, and a symbolic model generator 124. The system 100 incorporates three main types of entities, namely input entities, intermediate output entities, and final output entities. Input entities include a natural language problem description 102 and a conversation history 104. Intermediate output entities include problem specifications 108. Final output entities include symbolic models 126. In some examples, symbolic models 126 can be stored in a non-transient storage such as a symbolic model database 135. In some examples, the system 100 can communicate with via a communication network with a model instantiator 136 which can receive data values 142 and a symbolic model 126 as inputs and generate a model instance 138. In some examples, the model instantiator 136 can communicate with a solver 140, which processes model instance 138 to provide a solver result 144. In at least some examples, the model instantiator 136 and solver 140 can be included as computational components within the system 100. Each of these components and instances are described in greater detail below.

[0095] FIG. 2 is a block diagram illustrating a simplified example computing system 200 that may be used for implementing one or more of the components of the optimization problem modeling system 100, in some embodiments. The computing system 200 may represent a server or a workstation, for example. As discussed previously, the optimization problem modeling system 100 may be implemented in other hardware configurations, including implementation using a plurality of computing systems. Although FIG. 2 shows a single instance of each element, there may be multiple instances of each element in the computing system 200.

[0096] In this example, the computing system 200 includes at least one processing unit 202, which may be a processor, a microprocessor, a digital signal processor, an application-specific integrated circuit (ASIC) , a field-programmable gate array (FPGA) , a dedicated logic circuitry, a dedicated artificial intelligence processor unit, a graphics processing unit (GPU) , a tensor processing unit (TPU) , a neural processing unit (NPU) , a hardware accelerator, combinations thereof, or other such hardware structure.

[0097] The computing system 200 may include an input / output (I / O) interface 204, which may enable interfacing with an input device and / or output device (not shown) .

[0098] The computing system 200 may include a network interface 206 for wired or wireless communication with other computing systems. The network interface 406 may include wired links (e.g., Ethernet cable) and / or wireless links (e.g., one or more antennas) for intra-network and / or inter-network communications. The network interface 206 may also enable the computing system 400 to communicate generated reports to another computing system (e.g., to a user device) .

[0099] The computing system 200 may include a storage unit 208, which may include a mass storage unit such as a solid state drive, a hard disk drive, a magnetic disk drive and / or an optical disk drive.

[0100] The computing system 200 may include a memory 410, which may include a volatile or non-volatile memory (e.g., a flash memory, a random access memory (RAM) , and / or a read-only memory (ROM) ) . The non-transitory memory 210 may store instructions for execution by the processing unit 202, such as to carry out example embodiments described in the present disclosure. For example, the memory 210 may store instructions 212 for implementing one or more of the components of the optimization problem modeling system 100 as well as any of the methods disclosed herein. The memory 210 may include other software instructions, such as for implementing an operating system and other applications / functions.

[0101] The computing system 200 may additionally or alternatively execute instructions from an external memory (e.g., an external drive in wired or wireless communication with the server) or may be provided executable instructions by a transitory or non-transitory computer-readable medium. Examples of non-transitory computer readable media include a RAM, a ROM, an erasable  programmable ROM (EPROM) , an electrically erasable programmable ROM (EEPROM) , a flash memory, a CD-ROM, or other portable memory storage.

[0102] A detailed explanation of the input entities for system 100, namely problem description 102 and conversation history 104, will now be described. As noted above, in some examples the problem description 102 describes an optimization problem in natural language and in many cases originate as input generated by an AD expert. For example, the problem description 102 may be obtained using a user input electronic device as text input (for example using a keyboard or a speech to text conversion engine) and provided to the system 100. The conversation history 104 is a record of natural language exchanges between parties that are involved in identifying and solving the problem, for example, exchanges between the AD expert and the OR consultant. In at least some examples, system 100 interfaces with automated data collection components that provide user interfaces that enable and capture exchanges between the AD expert and the OR consultant.

[0103] By way of example, Table 1 below provides an example of a natural language problem description 102 that may, for example, represent input provided by an AD expert.

[0104] Table 1: Problem Description Example

[0105] By way of example, Table 2 below provides an example of a natural language conversation history 104 representing a messaging exchange between an OR consultant and an AD expert.

[0106] Table 2: Conversation History Example

[0107] In many typical use cases, the problem description 102 and / or conversation history 104 can have one or more of the following characteristics:

[0108] 1. Language: The language used is often technical and domain-specific. The problem description may include jargon, acronyms, and terminologies that are specific to the industry or the business.

[0109] 2. Ambiguity: As problem descriptions are written in natural language, there's a high chance of encountering ambiguous statements, statements that can be interpreted in multiple ways.

[0110] 3. Length: The length of a problem description can vary widely. For simple problems, it could be just a few sentences or a paragraph. More complex problems may require several pages of text. However, a longer  description doesn't necessarily imply a more complex problem; it could simply be more detailed.

[0111] 4. Imperfections: Imperfections due to inaccuracies or missing information are often present due to the complex nature of domain problems.

[0112] In many typical use cases, the problem description 102 and / or conversation history 104 can include data from one or more of the following types of content categories:

[0113] 1. Goal: The problem description will typically include text that defines the desired outcome. However, this might not be clearly stated or may need to be clarified through further discussion that is included in the conversation history.

[0114] 2. Context: Context explains why the problem is important, what has been done to address it in the past, and what constraints and considerations are relevant. However, some information in the problem description / conversation history can be relevant only to the domain of applications but irrelevant to the actual optimization problem.

[0115] 3. Restrictions: In most real-world problems, the problem description / conversation history can state certain restrictions that should be considered. These could be related to budget, time, resources, regulatory requirements, etc.

[0116] 4. Stakeholder Involvement: As problems often involve multiple stakeholders, their perspectives or interests are likely to be mentioned or implied.

[0117] 5. Absence of Solution: The problem description / conversation history typically doesn't include a solution. It focuses on outlining the issue and what the company hopes to achieve.

[0118] 6. Examples and Scenarios: The problem description / conversation history might include specific examples or hypothetical scenarios to  better illustrate the problem or certain aspects of it. This can be particularly useful when dealing with complex issues.

[0119] 7. Qualitative Descriptors: Instead of numerical values, qualitative descriptors may be used to describe the level of impact, importance, frequency, or other aspects of the problem. These might need to be translated into quantitative metrics.

[0120] 8. Potential Approaches: Although not a solution, hints towards potential approaches based on previous experiences might be included.

[0121] 9. Dependence on External Factors: Depending on the problem, external factors such as market trends, competition or regulations might be mentioned.

[0122] 10. Data Availability and Quality: Although not always explicitly stated, there could be information or hints about data availability and quality.

[0123] The specification generator 106 receives the problem description 102 and conversation history 104 as inputs, and outputs a list of problem specifications 108 as an intermediate system output. Problem specifications 108 are an intermediate data structure that exists between the NL problem description 102 and conversation history 104 and the algebraic problem formulation of the symbolic model 126.

[0124] A detailed explanation of problem specifications 108 will now be described.

[0125] As illustrated in FIG. 1, each problem specification 108 is a data structure that describes and elucidates a respective element that is represented in the optimization model. A problem specification 108 can include the following attributes: a unique specification identifier (SpecID) 110, a title 112, a natural language description 114, a sub-category identifier 116 (identifies what type of sub-category the problem specification 108 belongs to) , metadata 118 (the content of which is sub-category dependent) and explanations 120. FIG. 3 illustrates different sub-categories and types of problem specifications 108 that  can be generated by problem specification generator 106 in an example implementation. With reference to FIG. 3, each problem specification 108 belongs to a specific sub-category type, which are described in Table 3 below.

[0126] Table 3: Problem Specification Sub-Category Types

[0127] The set of problem specifications 108 collectively comprehensive descriptions that elucidate the requirements, constraints, objective, and assumptions of a particular problem or system set to be modeled or optimized. Their purpose is multi-fold: fostering effective collaboration between OR experts and AD experts during the problem definition phase, providing a clear and precise understanding of the problem, serving as a guide during the model development process to aid in the generation of accurate models, and ensuring that the solution specifically addresses the unique needs and goals of the application domain.

[0128] With reference to FIG. 3, in example implementations, problem specifications 108 are organized into two main categories for processing purposes (described below) : Context Problem Specifications 304A (which include Entity 116A, Data parameter 116B and Decision 116C sub-category type problem specifications) , and Requirement Problem Specifications 304B (which include Objective criterions 116D, Calculation 116E, Domain Requirement 116F and Implicit Requirement 116G sub-category type problem specifications. Each of these two main categories focuses on a distinct aspect of the problem, providing a systematic way to approach problem analysis and solution development.

[0129] With reference to FIG. 3, in example implementations, problem specifications 108 are further organized into two main types for processing purposes (described below) :

[0130] Explicit Problem Specifications 306A –These are problem specifications that are explicitly mentioned in the problem description 102 and conversation history 104. Problem entity 116A, data parameter 116B, decision 116C, objective criterion 116D, calculation 116E and domain requirement 116F sub-category type program specifications are all explicit problem specifications 306A. Note that the problem description 102 and conversation history 104 can be incomplete, meaning that they might not mention some problem specifications of the mentioned sub-category types.

[0131] Implicit Problem Specifications 306B –These type of problem specifications normally will not be mentioned in the problem description 102 and conversation history 104 and are implied from the other problem specifications and relationships between them. As illustrated in FIG. 3, Implicit Problem Specifications 306B includes implicit requirement 116G type problem specifications 108. Implicit requirement 116G type problem specifications 108 can be further categorized into four categories as follows: (i) Implied by data parameters 302A (Parameters that refer to the capacity, availability, and demand of an entity, or parameters that define relationships between entities, can establish implicit requirements) ; (ii) Implied selection or limit 302B (There can be implied selection among a set of binary decisions or a limit on the number of binary decisions that can take value 1. Normally they are assumed in as logical assumptions and not expressed explicitly, for example at most one group of students can be assigned to a classroom at the same time. ) ; (iii) Logical relationship 302C (Sometimes there is an implicit relationship between decisions such that some of the values of one decision restrict the value of another decision. ) and (iv) Flow Balance 302D (Some problems need equilibrium relationships that are established between decisions and calculations. These relationships usually span over a set of time periods. )

[0132] As noted above, one of the attributes that can be included in a problem specification 108 is an explanation 120. In the case of an explicit problem specification 306A type of problem specification 108, the explanation 120 attribute is used to specify where the problem specification 108 is mentioned in the problem description 102 or conversation history 104 (e.g., maps the problem specification 108 to specific text location (s) in the problem description 102 or conversation history 104 to specify the origin of the problem specification 108) and to explain why the problem specification 108 is relevant to or important for the optimization problem. In the case of an implicit problem specification 306B type of problem specification 108, the explanation 120 attribute specifies details of the relevance or importance of the problem specification 108 (e.g., why the specification is important) to the optimization problem.

[0133] In order to facilitate an understanding of the structure and content of problem specifications 108, Table 4 below provides an illustrative example of a set of five problem specifications 108 generated in respect of the problem description 102 and conversation history 104 represented in Tables 1 and 2, respectively.

[0134] TABLE 4: Example of Set of Five Problem Specifications 108

[0135] An example of a specification generator 106 that is configured to generate the list of problem specifications 108 will now be described. The specification generator 106 performs automated extraction of problem specifications 108 from input problem description 102 and conversation history 104. As explained below, the specification generator 106 applies an iterative, task-specific prompting approach with Large Language Models (LLMs) in order to automatically parse the problem description 102 and conversation history 104 and generate the corresponding set of problem specifications 108. This process minimizes the manual effort required and mitigates the risk of overlooking important details.

[0136] Furthermore, in the case of the explanation 120 attributes of problem specifications 108, the specification generator 106 performs automated extraction of problem specifications origin (i.e., “Where” ) and importance (i.e., “why” ) explanations: This feature provides detailed explanations about the origin of each problem specification and why the problem specification is important. This can enable the OR consultant to verify the extracted problem specification 108 easily and aids in fostering a comprehensive understanding for both OR consultants and experts and AD experts, reducing the chance of misunderstandings or miscommunications.

[0137] An example block diagram showing operations performed by specification generator 106 is illustrated in FIG. 4, and will now be described in detail.

[0138] For generation of explicit-type problem specifications 108, three main operations or steps are performed: (1) An explicit problem specification extraction operation 402 is performed, for each sub-category 116A to 116F, to identify all  explicit problem specifications for that sub-category that are mentioned in the problem description 102 or in the conversation history 104, and extract the title 112, description 114, and metadata 118 attributes. (2) For each problem specification 108, a problem specification reference extraction operation 406 is performed to extract the text from the problem description 102 or the conversation history 104 that provided the origin for the problem specification; this information provides the “where” data for explanation 120 attribute and can be used to verify if the problem specification 108 is actually related to the problem by providing a reference location for the problem specification 108. (3) For each problem specification 108, a problem specification relevance extraction operation 406 is performed to generate an explanation as to why a problem specification is important or relevant for the optimization model. This information provides the “why” data for explanation 120 attribute.

[0139] In the case of implicit-type problem specifications 108, a similar specification generation process can be used, however as implicit problem specifications 108 are implied by, but not explicitly referenced in, the problem description 102 or the conversation history 104, the problem specification reference extraction operation 406 is not required for generating implicit-type problem specifications 108. Thus, generation of implicit-type problem specifications 108 includes two main operations or steps: (1) An implicit problem specification extraction operation 408 to identify all implicit problem requirements that are mentioned in the problem description 102 or in the conversation history 104, and for each identified problem requirement, extract title 112, description 114 and metadata 118 attributes. (2) For each implicit problem specification 108, perform problem specification relevance extraction operation 406 to generate an explanation as to why the implicit problem specification is important or relevant for the optimization model (the “why” data for explanation 120 attribute) .

[0140] In example embodiments, the problem specification extraction operations 402, 406, 408, and 410 are each structured as respective Question Answering (QA) tasks that are performed in respect of the input problem description 102 and conversation history 104. In particular, for each of operations  402, 406, 408, and 410 the input problem description 102 and conversation history 104 are combined with operation-specific predefined questions and instructions and provided as prompts to an LLM that generates an answer that is then parsed to extract the problem specification attributes.

[0141] This QA task is formally defined as follows: Given a context document `d` and a question `q` , the goal of a QA task to produce an answer `a` . The answer `a` is typically a span of text in the context document `d` , although it can also be information from disjoint parts of the context document. In the present example, the context document is problem description 102 and the conversation history 104, the questions are selected forma predefined prompt database, and the answers are used to generate the problem specifications 108.

[0142] A block diagram of workflow and Prompt templates associated with explicit problem specification extraction operation 402 and implicit problem extraction operation 408 is shown in FIG. 5. These operations will first be explained in the context of explicit problem specification extraction operation 402.

[0143] As noted above, in an example implementation, explicit problem specification extraction operation 402 is performed for each respective sub-category type of problem specification 108. In example embodiments, output problem specifications 108 for certain sub-category types are then used as input in the structured prompts for determining the problem specifications 108 that belong to other sub-category types. In this regard, an example of a logical sub-category sequence that can be applied by explicit problem specification extraction operation 402 when generating the problem specifications 108 is as follows. (1) Step 1: Problem entities are identified and a respective problem entity 116A problem specification 108 generated for each problem entity. Step (2) : The problem entity 116A problem specifications 108 from Step 1 are then used in prompts to extract data parameter 116B problem specifications 108 and decision 116C problem specifications 108. Note that steps (1) and (2) provide a set of context type problem specifications 304A. Step (3) : The context type problem specifications 304A (i.e., problem entity 116A, data parameter meter 116B, and decision 116C  problem specifications 108) are then used in prompts to provide context that is used to extract objective criterion 116D, calculation 116E and domain requirement 116F problem specifications 108.

[0144] The explicit problem specification extraction operation 402 is first performed to generate problem specification data structures 508 that relate to problem entities. In this regard, the problem description 102 and conversation history 104 are provided as an input 502D to a prompt assembler 500, along with a set of further entity 116A sub-category specific prompt content, including defined content for a question 502A, a definition 502B, and output style instructions 502C. Using these inputs, the prompt assembler 500 assembles a corresponding explicit specification extraction prompt 502 that has a fixed template format that contains one question 502A, a definition 502B, output style instructions 502C, and input 502D.

[0145] The prompt assembler 500 has access to a predefined prompt database 503 that stores sub-category specific prompt content that has been predefined to provide the prompt language used in the examples described below.

[0146] Table 5 sets out an example of a specification extraction prompt 502 generated in respect of an entity 116A sub-category specific prompt content. Note that although the header terms “question 502A” , “definition 502B” , “output style instructions 502C” , and “input 502D” are included in the following tables, such heeders need not be included in the prompts that are actually provided to an LLM

[0147] TABLE 5: Structured Prompt 502 for Extracting Entity 116A Problem Specification

[0148] The entity 116A specification extraction prompt 502 of Table 5 is provided as input to an LLM function 504. In example embodiments, LLM function 505 is an application interface that passes the specification extraction prompt 502 via a communications network to a remotely hosted LLM service. By way of example, the LLM function 504 can pass the specification extraction prompt 502 to a conversational AI model such as Chat Generative Pre-trained Transformer (ChatGPT) -3 or ChatGPT-4 that are offered as cloud services by OpenAITM. The output that is generated by the LLM in response to specification extraction prompt 502 is received by LLM function 504 provided to parser 506 which is configured to extract entity name and description information from the output based on formatting structure specified in the output style instructions 502C. For each unique entity that is identified by a respective set of <name: description> fields in the LLM output, a respective intermediate problem specification 508 data structure is generated that includes: a unique Spec ID 110 (assigned at time of generation of the intermediate problem specification 508) ; title 112 (the “name” of the entity set out in the name field of the LLM output) ; description 114 (the “description” of the entity set out in the description fields of the LLM output) ; and sub-category 116 (i.e., assigned based on type of problem specifications that are currently being processed, i.e., “Entity” in the present case) .

[0149] After the entity 116A type intermediate problem specifications 508 are generated, the explicit problem specification extraction 402 operation can then extract data parameter 116B type intermediate problem specifications 508 and decision 116C type intermediate problem specifications 508. In this regard, Table 6 sets out an example of a data parameter 116B explicit specification extraction prompt 502 generated by prompt assembler 500.

[0150] TABLE 6: Structured Prompt 502 for Extracting Data Parameter 116A Problem Specification

[0151] The data parameter specification extraction prompt 502 of Table 6 is provided as input to LLM 504. The output that is generated by LLM function 504 in response to specification extraction prompt 502 is provided to parser 506 which is configured to extract name and description information from the output based on formatting structure specified in the output style instructions 502C. For each unique data parameter that is identified by a respective set of <name: description>fields in the LLM output, a respective intermediate problem specification 508 data structure is generated that includes: a unique Spec ID 110; title 112 (the “name” of the data parameter set out in the name field of the LLM output) ; description 114 (the “concise description” of the data parameter set out in the description field of the LLM output) ; and sub-category 116 (i.e., “Data Parameter” ) .

[0152] Table 7 sets out an example of a decision 116C explicit specification extraction prompt 502 generated by prompt assembler 500.

[0153] TABLE 7: Structured Prompt 502 for Extracting Decision 116C Problem Specification

[0154] The decision specification extraction prompt 502 of Table 7 is provided as input to LLM 504. The output that is generated by LLM function 504 in response to specification extraction prompt 502 is provided to parser 506 which is configured to extract name and description information from the output based on formatting structure specified in the output style instructions 502C. For each unique decision that is identified by a respective set of <name: description> fields in the LLM output, a respective intermediate problem specification 508 data structure is generated that includes: a unique Spec ID 110; title 112 (the “name” of the decision set out in the name field of the LLM output) ; description 114 (the “concise description” of the decision set out in the description field of the LLM output) ; and sub-category 116 (i.e., “Decision” ) .

[0155] After the context problem entity 116A type intermediate problem specifications 508 (e.g., entity 116A, data parameter 116B and decision 116C intermediate problem specifications 508) are generated, requirement problem intermediate specifications (e.g., objective criterion 116D, calculation 116E, and domain requirement 116F intermediate problem specifications 508) can then be generated. Table 8 sets out an example of an objective criterion 116D explicit specification extraction prompt 502 generated by prompt assembler 500.

[0156] TABLE 8: Structured Prompt 502 for Extracting Objective Criterion 116D Problem Specification

[0157] The objective criterion specification extraction prompt 502 of Table 8 is provided as input to LLM 504. The output that is generated by LLM function 504 in response to specification extraction prompt 502 is provided to parser 506 which is configured to extract name and description information from the output based on formatting structure specified in the output style instructions 502C. A respective intermediate problem specification 508 data structure is generated that includes: a unique Spec ID 110; title 112 (the “name” of the objective criterion set out in the name field of the LLM output) ; description 114 (the “concise description” of the objective criterion set out in the description field of the LLM output) ; and sub-category 116 (i.e., “objective criterion” ) .

[0158] Table 9 sets out an example of a calculation 116E explicit specification extraction prompt 502 generated by prompt assembler 500.

[0159] TABLE 9: Structured Prompt 502 for Extracting Calculation 116E Problem Specification

[0160] The calculation specification extraction prompt 502 of Table 9 is provided as input to LLM 504. The output that is generated by LLM function 504 in response to specification extraction prompt 502 is provided to parser 506 which is configured to extract name and description information. For each unique calculation that is identified by a respective set of <name: description> fields in the LLM output, a respective intermediate problem specificaton 508 data structure is generated that includes: a unique Spec ID 110; title 112 (the “name” of the  calculation set out in the name field of the LLM output) ; description 114 (the “concise description” of the objective criterion set out in the description field of the LLM output) ; and sub-category 116 (i.e., “calculation” ) .

[0161] Table 10 sets out an example of a domain requirement 116F explicit specification extraction prompt 502 generated by prompt assembler 500.

[0162] TABLE 10: Structured Prompt 502 for Extracting Domain requirement 116F Problem Specification

[0163] The domain requirement specification extraction prompt 502 of Table 10 is provided as input to LLM function 504. The output that is generated by LLM function 504 in response to specification extraction prompt 502 is provided to parser 506 which is configured to extract name and description information. For each unique domain requirement that is identified by a respective set of <name: description> fields in the LLM output, a respective intermediate problem specification 508 data structure is generated that includes: a unique Spec ID 110; title 112 (the “name” of the domain requirement set out in the name field of the LLM output) ; description 114 (the “concise description” of the objective criterion set out in the description field of the LLM output) ; and sub-category 116 (i.e., “domain requirement” ) .

[0164] Once the set of intermediate problem specifications 508 is generated for all explicit problem specifications 306A, the explicit problem specification extraction operation 402 is configured to individually process each of the  intermediate problem specifications 508, with the exception of entity 116A intermediate problem specifications 508, to extract metadata 118 attributes that are then appended to the intermediate problem specifications 508 to generate respective further intermediate problem specifications 518. The metadata extraction process is performed using a metadata extraction prompt assembler 510 that retrieves sub-category-specific prompt language from predefined prompt database 503 to generate sub-category specific metadata extraction prompts 512 that are provided as inputs to LLM function 514 (which can, for example, call on the same LLM service as LLM function 504) . Parser 516 is used to extract metadata 118 attributes from the LLM output. In cases where multiple metadata attributes are to be extracted for an intermediate problem specifications 508, the prompting and LLM response gathering steps are repeated for each type of metadata attribute.

[0165] In this regard, Table 11 sets out an example of a data parameter 116B metadata extraction prompt 512 generated by metadata extraction prompt assembler 510 in order to extract “participating entities” metadata.

[0166] TABLE 11: Structured Prompt 512 for Extracting “participating entities” metadata for a single data parameter 116B Problem Specification

[0167] Table 12 sets out an example of a data parameter 116B metadata extraction prompt 512 generated by metadata extraction prompt assembler 510 in order to extract “type” metadata for the data parameter.

[0168] TABLE 12: Structured Prompt 512 for Extracting “type” metadata for a single data parameter 116B Problem Specification

[0169] Table 13 sets out an example of a decision parameter 116C metadata extraction prompt 512 generated by metadata extraction prompt assembler 510 in order to extract “action” metadata for the decision.

[0170] TABLE 13: Structured Prompt 512 for Extracting “action” metadata for a single Decision 116C Problem Specification

[0171] Table 14 sets out an example of a decision parameter 116C metadata extraction prompt 512 generated by metadata extraction prompt assembler 510 in order to extract “participating entities” metadata for the decision.

[0172] TABLE 14: Structured Prompt 512 for Extracting “participating entities” metadata for a single Decision 116C Problem Specification

[0173] Table 15 sets out an example of a decision parameter 116C metadata extraction prompt 512 generated by metadata extraction prompt assembler 510 in order to extract “participating entities” metadata for the decision.

[0174] TABLE 15: Structured Prompt 512 for Extracting “quantitative meaning” metadata for a single Decision 116C Problem Specification

[0175] Table 16 sets out an example of an objective criterion 116D metadata extraction prompt 512 generated by metadata extraction prompt assembler 510 in order to extract “sense” metadata for the objective criterion.

[0176] TABLE 16: Structured Prompt 512 for Extracting “sense” metadata for a single Objective Criterion 116D Problem Specification

[0177] Table 17 sets out an example of an objective criterion 116D metadata extraction prompt 512 generated by metadata extraction prompt assembler 510 in order to extract “related decisions” metadata for the objective criterion.

[0178] TABLE 17: Structured Prompt 512 for Extracting “related decisions” metadata for a single Objective Criterion 116D Problem Specification

[0179] Table 18 sets out an example of a calculation 116E metadata extraction prompt 512 generated by metadata extraction prompt assembler 510 in order to extract “participating decisions” metadata for the calculation.

[0180] TABLE 18: Structured Prompt 512 for Extracting “related decisions” metadata for a single Calculation 116E Problem Specification

[0181] Table 19 sets out an example of a calculation 116E metadata extraction prompt 512 generated by metadata extraction prompt assembler 510 in order to extract “type” metadata for the calculation.

[0182] TABLE 19: Structured Prompt 512 for Extracting “type” metadata for a single Calculation 116E Problem Specification

[0183] Table 20 sets out an example of a domain requirement 116F metadata extraction prompt 512 generated by metadata extraction prompt assembler 510 in order to extract “entities” metadata for the domain requirement.

[0184] TABLE 20: Structured Prompt 512 for Extracting “domain requirement” metadata for a single domain requirement 116F Problem Specification

[0185] Table 21 sets out an example of a domain requirement 116F metadata extraction prompt 512 generated by metadata extraction prompt assembler 510 in order to extract “Type” metadata for the domain requirement.

[0186] TABLE 21: Structured Prompt 512 for Extracting “type” metadata for a single domain requirement 116F Problem Specification

[0187] Once the above QA tasks have been completed, explicit problem specification extraction operation 402 will have generated a complete set of explicit intermediate problem specifications 520.

[0188] With reference to FIG. 5, implicit problem specification extraction operation 402 is similar to explicit problem specification extraction operation 402, subject to differences in prompt content. As noted above, implicit requirement 116G problem specifications 108 include four sub-categories as follows: (i) Implied by data parameters 302A; (ii) Implied selection or limit 302B; (iii) Logical relationship 302C and (iv) Flow Balance 302D. Even though these sub-categories of implicit requirements are not explicitly mentioned in the problem description 102 or conversation history 104, they can be identified by examining the extracted explicit intermediate problem specifications 520 and the relationships between  them. In example embodiments, each sub-category 302A to 302D of implicit requirement 116G problem specifications is generated using a respective specification extraction prompt 502 that is assembled by specification extraction prompt assembler 500 based on predefined sub-category-specific prompt language stored predefined prompt database 503. The respective prompts 502 are individually provided to LLM function 502, and the resulting LLM outputs provided to parser 596 which extracts specified data to generate and populate respective intermediate implicit problem specifications 508.

[0189] In this regard, Table 22 sets out an example of an “implied by data parameters” 302A type of implicit requirement 116G problem specification extraction prompt 502 generated by specification extraction prompt assembler 500.

[0190] TABLE 22: Structured Prompt 502 for Extracting “implied by data parameters” 302A type Problem Specification

[0191] Table 23 sets out an example of an “implied selection or limit” 302B type of implicit requirement 116G problem specification extraction prompt 502 generated by specification extraction prompt assembler 500.

[0192] TABLE 23: Structured Prompt 502 for Extracting “implied selection or limit” 302B type Problem Specification

[0193] Table 24 sets out an example of a “logical relationship” 302C type of implicit requirement 116G problem specification extraction prompt 502 generated by specification extraction prompt assembler 500.

[0194] TABLE 24: Structured Prompt 502 for Extracting “logical relationship” 302C type Problem Specification

[0195] Table 25 sets out an example of a “flow balance” 302D type of implicit requirement 116G problem specification extraction prompt 502 generated by specification extraction prompt assembler 500.

[0196] TABLE 25: Structured Prompt 502 for Extracting “flow balance” 302D type Problem Specification

[0197] Once the set of intermediate problem specifications 508 is generated for all sub-categories 302A, 302B, 302C and 302D of implicit problem specifications 306B, the implicit problem specification extraction operation 408 is configured to individually process each of the intermediate problem specifications 508 to extract metadata 118 attributes that are then appended to the intermediate problem specifications 508 to generate respective further intermediate problem specifications 518 in the same manner as discussed above in respect of explicit problem specifications. In particular, the metadata extraction process is performed using a metadata extraction prompt assembler 510 that retrieves sub-category-specific prompt language from predefined prompt database 503 to generate sub-category specific metadata extraction prompts 512 that are provided as inputs to LLM function 514. Parser 516 is used to extract metadata 118 attributes from the LLM output. In cases where multiple metadata attributes are to be extracted for an intermediate problem specifications 508, the prompting and LLM response gathering steps are repeated for each type of metadata attribute.

[0198] In some examples, the same type of metadata attributes, namely “entities the implicit requirement is applied on” and “type of implicit requirement” are extracted for all sub-categories 302A, 302B, 302C and 302D of implicit problem specifications 306B. In this regard, Table 26 sets out an example of a  metadata extraction prompt 512 generated by metadata extraction prompt assembler 510 in order to extract “participating entities” metadata for an implicit requirement problem specification.

[0199] TABLE 26: Structured Prompt 512 for Extracting “participating entities” metadata for a single implicit requirement Problem Specification

[0200] Table 27 sets out an example of a metadata extraction prompt 502 generated by metadata extraction prompt assembler 510 in order to extract “type” metadata for an implicit requirement problem specification.

[0201] TABLE 27: Structured Prompt 512 for Extracting “participating entities” metadata for a single implicit requirement Problem Specification

[0202] Referring again to FIG. 4, from the above description it will be appreciated the output of explicit program specification extraction operation 402 is  the set of intermediate explicit problem specifications 520 and the output of implicit program specification extraction operation 408 is the set of intermediate implicit problem specifications 522.

[0203] A common side effect of using LLMs to extract information is that they can hallucinate information not presented in the context document. In order to mitigate this issue for intermediate explicit problem specifications 520, a verification step can be used to verify the generated problem specifications. The verification task is to find references for an extracted problem specification from the problem description 102 and conversation history 104. This verification task can be formulated as Evidence Extraction in NLP and defined formally as: Given an assertion or statement `s` and a context document `d` , the goal is to identify and output the span of text `r` in `d` that provides the evidence or reference for `s` .

[0204] The main challenge of this verification task lies in correctly understanding the statement ′s′ and being able to map it to the corresponding evidence in the context document. This requires a processing model that has a good grasp of language semantics and possibly world knowledge. In examples, an LLM is used to perform Evidence Extraction, given the strong performance of LLMs on tasks that involve understanding complex, contextual relationships in text.

[0205] In this regard, the problem specification reference extraction operation 406 is used to process each of the intermediate explicit problem specifications 520 to extract evidence (e.g., source text) from the problem description 102 or the conversation history 104 that for the problem specification. This extracted information provides the “where” data for explanation 120 attribute for the problem specification.

[0206] FIG. 6 shows a block diagram of an example workflow and Prompt template associated with problem specification reference extraction operation 406 that is performed individually in respect of each of the intermediate explicit problem specifications 520. The reference extraction process is performed using a prompt assembler 600 to generate a reference extraction prompt 602 that are provided as inputs to LLM function 604 (which can, for example, call on the same  LLM service as LLM function 504) . Parser 606 is used to extract reference text from the LLM output. The extracted reference text is then added as the “where” attribute to the explanation 120 attribute of the subject intermediate explicit problem specification 520, resulting in a further intermediate explicit problem specification 610.

[0207] Table 28 sets out an example of a reference extraction prompt 602 generated by reference extraction prompt assembler 600 in order to extract “problem specification reference” from input problem description 102 and conversation history 104 for an input intermediate explicit problem specification 520. It will be noted that the output “none” in respect of an explicit problem specification by the reference extraction operation 406 provides an easily identifiable flag of a possible problem with the subject problem specification. In some examples, the flagged problem specification is automatically removed from the set of problem specifications.

[0208] TABLE 28: Structured Prompt 602 for Extracting “Problem Specification Reference” For a Single Explicit Problem Specification

[0209] Referring again to FIG. 4, further verification of problem specifications is facilitated by problem relevance extraction operation 410, which is performed on both explicit and implicit problem specifications and generates the “why” content of the explanation 120 attribute. In this regard, FIG. 7 is a block diagram of an example workflow and Prompt templates associated with the problem specification relevance extraction operation 410 of the specification generator of FIG. 4.

[0210] The problem specification relevance extraction operation 410 is performed individually for each of both the intermediate explicit problem specifications 610 and the intermediate implicit problem specifications 522. The relevance extraction process is performed using a prompt assembler 700 to generate a relevance extraction prompt 702 that are provided as inputs to LLM function 704 (which can, for example, call on the same LLM service as LLM function 504) . Parser 706 is used to extract relevance content from the LLM output. The extracted reference text is then added as the “why” attribute to the explanation 120 attribute of the subject intermediate explicit problem specification 610 or intermediate implicit problem specification 522, resulting in the final set of problem specifications 108 (which includes both explicit and implicit problem specifications) .

[0211] Table 29 sets out an example of a relevance extraction prompt 602 generated by reference extraction prompt assembler 600 in order to extract “problem specification reference” from input problem description 102 and conversation history 104 for an input intermediate explicit problem specification 520. It will be noted that the output “none” in respect of an explicit problem specification by the reference extraction operation 406 acts provides an easily identifiable flag of a possible problem with the subject problem specification.

[0212] TABLE 29: Structured Prompt 702 for Extracting “Problem Specification Relevance” For a Single Problem Specification

[0213] An end-to-end example of an illustrative problem specification generation for a “data parameter” 116B type of problem specification 108 as generated by Specification Generator 106 is shown in FIG. 8.

[0214] With reference to FIG. 1, in example implementations system 100 is provided with a specification editor 122 that provides a graphical user interface (GUI) that allows a user such as the OR consultant and / or the AD expert review the generated problem specifications 108. In some examples, a user selected problem specification 108 can be manually edited or manually deleted from the set of problem specifications 108. Specification editor 122 enables a user to verify and, if necessary, edit the problem specifications and their attributes. The user will then have an option to select a subset of the problem specifications, or possibly all, to be input to the symbolic model generator 124. Furthermore, specification editor 122 can allow users to selectively choose problem specifications for model building by symbolic model generator 124, providing flexibility in creating multiple models for testing and validation.

[0215] In example implementations, symbolic model generator 124 is configured to perform the following features: (1) Automated Model Generation and Customization: This feature leverages LLMs to convert the set of problem specifications 108 into a symbolic model 126 that includes a set of model components 127 (model components may also be referred to as model elements in this disclosure and its accompanying Figures) . Each model component 127 is a data structure that includes the attributes: math symbol 128, a description 130, and a list of related problem specifications 132. (2) Explanatory Mapping between Model Elements and Problem Specifications: This feature provides detailed explanations of the link between symbolic model components 127 and problem specifications 108. The explanation generated for a symbolic model component 127 is included in its data structure as an explanations 134 attribute. The explanations attribute 134 thus illustrates the connection between the model component 127 and each related problem specification 108. This can be used to assist users in understanding how requirements are being addressed in the optimization model, simplifying the model verification and refinement process.

[0216] With reference to FIG. 9, symbolic model generator 124 includes three main operations to create the symbolic model 126 from the set of problem specifications 108. First, a model components generator 902 generates math  symbols 128 for model components 127 (i.e., sets, parameters, decisions, objective and constraints) and a natural language description 130 for each component 127. Second, a model-to-specification extractor 906 identifies all problem specifications 108 (e.g., related Spec IDs 132) that are related to each model component 127. Third, a model component explanations generator 908 generates natural language explanations 134 explaining why the related problem specifications identified in related Spec IDs 132 are related to the model component 127.

[0217] In examples, the symbolic model 126 is generated incrementally. Each model component 127 is generated by respectively processing problem specifications 108 on a problem specification sub-category by sub-category basis. Thus, a multi-turn approach of sub-category-specific generation cycles are used to construct the symbolic model 126 from the set of problem specifications 108. For each model component 127 generation cycle, the problem specifications from a specified sub-category along with the model components 127 generated in previous cycles. In this regard, Figure 10 illustrates a sequence of model component generation cycles as performed by model components generator operation 902. First, the sub-set of entity 116A type problem specifications 108 are selected from the set of all problem specifications 108 and provided to a set generation operation 1002 that assembles a set generation prompt 1002A that is submitted to an LLM (which may be the same LLM as that used for problem specification generation) . The LLM output is parsed to output a set of intermediate set-type model component 127′A data structures that each include respective set math symbol 128 and description 130 attributes. Figure 11A illustrates an example structure for set generation prompt 1002A, which can include, in addition to predefined instruction language, one or more of the following text fields: <Roll adoption &introduction>; <set of entity 116A problem specifications>; <Output style instructions>. The <Roll adoption &introduction> text can be predefined as indicated. All predefined language for the prompt generation can be pre-stored in, and recovered from, predefined prompt database 503.

[0218] Next, the sub-set of data parameter 116B type problem specifications 108 are selected from the set of all problem specifications 108 and provided, together with the intermediate set-type model component 127′A data structures to a parameter generation operation 1004 that assembles a data parameter generation prompt 1004A that is submitted to the LLM. The LLM output is parsed to output a set of intermediate parameter-type model component 127′B data structures that each include respective parameter math symbol 128 and description 130 attributes. Figure 11B illustrates an example structure for parameter generation prompt 1004A.

[0219] Next, one or both of the sub-sets of decision 116C or calculation 116E type problem specifications 108 are selected from the set of all problem specifications 108 and provided, together with the intermediate set-type model component 127′A data structures, to a variable generation operation 1006 that assembles a variable generation prompt 1006A that is submitted to the LLM. The LLM output is parsed to output a set of intermediate variable-type model component 127′C data structures that each include respective variable math symbol 128 and description 130 attributes. Figure 11B illustrates an example structure for variable generation prompt 1006A.

[0220] Next, one or both of the sub-sets of domain requirement 116F or implicit requirement 116G type problem specifications 108 are selected from the set of all problem specifications 108 and provided, together with the intermediate model component 127′A, 127′B and 127′C data structures, to a constraint generation operation 1008 that assembles a requirement generation prompt 1008A that is submitted to the LLM. The LLM output is parsed to output a set of intermediate constraint-type model component 127′D data structures that each include respective constraint math symbol 128 and description 130 attributes. Figure 11C illustrates an example structure for requirement generation prompt 1008A.

[0221] Next, the sub-sets of objective criterion 116D type problem specifications 108 are selected from the set of all problem specifications 108 and  provided, together with the intermediate model component 127′A, 127′B and 127′C data structures, to an objective generation operation 1010 that assembles an objective generation prompt 1010A that is submitted to the LLM. The LLM output is parsed to output a set of intermediate objective-type model component 127′E data structures that each include respective constraint math symbol 128 and description 130 attributes. Figure 11C illustrates an example structure for objective generation prompt 1010A.

[0222] With reference to FIG. 9, the intermediate model component 127′A, 127′B, 127′C, 127′D and 127′E data structures collectively form the set of intermediate model components 127′ that make up intermediate symbolic model 904. The generation prompts 1002A, 1004A, 1006A, 1008A and 1010A.

[0223] Each of the intermediate model components 127′ data structures are then processed one at a time by Model-to-Specification extractor operation 906 to produce a respective further intermediate model component 127″ data structure that includes related problem specification ID′s 132 for the model component. Each intermediate model component 127″ data structure is the processed one at a time by model component explanation generator operation 908 to generate respective explanations 134, resulting in a final model component 127 for the symbolic model 126.

[0224] In this regard, FIG. 12 illustrates an example of Model-to-Specification extractor operation 906. As indicated in FIG. 12, Model-to-Specification extractor operation 906 assembles a relationship identifier prompt 1202 that includes predefined prompt language, an input intermediate model component 127′ data structure and the set of problem specifications 108. Relationship identifier prompt 1202 is provide to an LLM function 1204 that submits the prompt to an LLM for processing. This may be the same LLM used for any of the above QA tasks. The LLM output is parsed by parser 1206 to extract Spec IDs of any problem specifications 108 that are identified as relevant.

[0225] Similarly, FIG. 13 illustrates an example of model component explanations extractor operation 908. As indicated in FIG. 13, Model-to-Specification extractor operation 908 assembles a relationship explanation prompt 1302 that includes predefined prompt language, an input intermediate model component 127″ data structure and the set of problem specifications 108. Relationship explanation prompt 1302 is provide to an LLM function 1304 that submits the prompt to an LLM for processing. This may be the same LLM used for any of the above QA tasks. The LLM output is parsed by parser 1306 to extract explanations for inclusion in the final model component 127.

[0226] FIG. 14 shows an illustrative example of a set of three representative model components 127 of a symbolic model 126, illustrating examples of math symbol 128, NL description 130, related spec IDs 132 and relevance explanations 134 attributes.

[0227] Referring again to FIG 1, the final symbolic model 126 can be provided to model instantiator 136 and / or stored in a non-transient symbolic model database 135 for future use.

[0228] The symbolic model 126 can be received as input to the model instantiator 136. The symbolic model 126 may be provided to the model instantiator 136 directly by the symbolic model generator 124, or optionally may be retrieved from the symbolic model database 135. The model instantiator 136 also receives as input one or more data values 142 (e.g., from a user device) , which provide the numerical values of sets and parameters which are used to provide defined values to the symbolic constraints and objective of the symbolic model 126. Optionally, the model instantiator 136 may also receive information about the solver configuration (e.g., from a user device) . For example, the model instantiator 136 may receive an indication or selection of the solver application programming interface (API) to use. A solver API is a software tool that provides an interface with a particular solver 140. The solver API provides tools that may be used by the model instantiator 136 to generate a model instance. In some  examples, if the model instantiator 136 does not receive information about the solver configuration, a default solver API may be used.

[0229] The model instantiator 136 generates a model instance. The model instance may be in the form of computer-readable code (e.g., using coding language executable by the solver 140) that can be processed by the solver 140. The model instance is a computer-readable representation of the optimization problem, in which the values of the parameters and constraints (which are defined symbolically in the symbolic model) have been defined numerically using the data values 142. It should be understood that the model instantiator 136 may generate different model instances for the same symbolic model, using different data values 142. The model instance 138 is provided as input to the solver 140, which processes the model instance to generate a solver result 144 that solves the objective function of the optimization problem while adhering to the constraints. The solver result 140 may be used as a solution to the optimization problem.

[0230] In some examples, the symbolic model 126 may not be stored in a database 135 (or other memory) , but may be directly instantiated into a model instance without being saved for future use.

[0231] Examples of the present disclosure may be provided as a cloud-based service (e.g., accessible to a user via a web-based portal, via a mobile application, via a software package, etc. ) . The present disclosure may be suitable for optimization problems in any domain (i.e., not limited to specific industries or applications) .

[0232] In some examples, a UI may be provided (e.g., specification editor 122) to enable the user to provide input (edit problem specifications 108, edit parameters of the symbolic model, upload data definitions, etc. ) , to retrieve a symbolic model from a database (e.g., input a query to search the database) , to review a symbolic model, etc. In some examples, a user may use the UI to search a symbolic model database 135 for a symbolic model that may be used as a template for developing a new symbolic model. The UI may enable the user to view the symbolic parameters and equations of the symbolic model, together with the  associated semantic metadata, to assist the user in understanding and editing the symbolic model.

[0233] In one example, system 100 is implemented as a modeling web application (or modeling assistant) that allows a user to create the optimization model (e.g., symbolic model 126) from the problem description 102. Such an implementation may enhance the OR consultant′s efficiency and effectiveness by presenting the optimization problem description 102 as a set of problem specifications 108 and model components 127 that are in a structured and human readable format. The system 100 detects relevant information that could indicate model components as problem specifications and facilitates the transfer of knowledge from the OR consultants to AD experts for verification. System 100 allows OR experts to create multiple version of the model.

[0234] Referencing to FIG. 1, a possible workflow in an implementation of system 100 include: (1) A user describes all relevant information to the optimization problem using natural language in a text editor (e.g., receive the problem description 102 and conversation 104) . (2) Specification generator 106 extracts explicit or generates implicit problem specifications from the problem description and presents them to the user. The system 100 also includes a specification editor 122 that allows the user to edit problem specifications and add new problem specifications. (3) The problem specifications are processed by symbolic model generator 124 to build symbolic model 124. Furthermore, a user can pre-select all or a subset of problem specifications 108 to build different versions of the symbolic model 126. Different versions of the models generated by different subsets of problem specifications can be stored in symbolic model database 135.

[0235] With reference to FIG. 15 an example of a GUI 1502 provided specification editor 122 is shown. The left side shows a text editor pane that enables a user to describe the optimization problem. An example of the problem description 102 is written in the text editor pane on the left of Figure 15. On the right side, the automatically generated problem specifications 108 are presented that are categorized in sub-categories. Each of the problem specifications 108 can be selected through the GUI to view and edit their respective attributes. FIG. 8  illustrates an automated workflow performed by specification generator 106 to generate problem specifications 108 from the problem description 102.

[0236] In the illustrated example, user selection of a “Build Model” option 1504 of GUI 1502 causes a further GUI element to be displayed that enables a user to select tick boxes to indicate problem specifications 108 that are to be used to generate a symbolic model. An example of such a GUI element 1602 is illustrated in FIG. 16.

[0237] The selected problem specifications 108 are used by symbolic model generator 124, together with the problem description and any conversation history 104, to generate symbolic model 126. FIGs. 17A-B illustrates an example of generation of a symbolic model component 127.

[0238] Once the system 100 generates all the model components 127, the generated model components 127 and related problem specifications 108 for each component 127 can be presented as part of an entire optimization model to the user, as shown by GUI 1802 in FIG. 18.

[0239] GUI 1802 also includes a “Runs” tab that when selected can bring the user to a run interface that can be used to cause the system 100 to cause the symbolic model 126 to be transformed, with the input of actual data values 142, into a model instance 138 and solved by solver 144 to provide a solution (solver result 144) for the optimization problem. In at least some example, wherein the solution specifies a change or allocation of physical entities in a physical domain, such as, for example the assignment of physical parking spots to physical buildings in the example of FIG. 18.

[0240] Although the present disclosure describes methods and processes with steps in a certain order, one or more steps of the methods and processes may be omitted or altered as appropriate. One or more steps may take place in an order other than that in which they are described, as appropriate.

[0241] Although the present disclosure is described, at least in part, in terms of methods, a person of ordinary skill in the art will understand that the present disclosure is also directed to the various components for performing at least some  of the aspects and features of the described methods, be it by way of hardware components, software or any combination of the two. Accordingly, the technical solution of the present disclosure may be embodied in the form of a software product. A suitable software product may be stored in a pre-recorded storage device or other similar non-volatile or non-transitory computer readable medium, including DVDs, CD-ROMs, USB flash disk, a removable hard disk, or other storage media, for example. The software product includes instructions tangibly stored thereon that enable a processing device (e.g., a personal computer, a server, or a network device) to execute examples of the methods disclosed herein. The machine-executable instructions may be in the form of code sequences, configuration information, or other data, which, when executed, cause a machine (e.g., a processor or other processing device) to perform steps in a method according to examples of the present disclosure.

[0242] The present disclosure may be embodied in other specific forms without departing from the subject matter of the claims. The described example embodiments are to be considered in all respects as being only illustrative and not restrictive. Selected features from one or more of the above-described embodiments may be combined to create alternative embodiments not explicitly described, features suitable for such combinations being understood within the scope of this disclosure.

[0243] All values and sub-ranges within disclosed ranges are also disclosed. Also, although the systems, devices and processes disclosed and shown herein may comprise a specific number of elements / components, the systems, devices and assemblies could be modified to include additional or fewer of such elements / components. For example, although any of the elements / components disclosed may be referenced as being singular, the embodiments disclosed herein could be modified to include a plurality of such elements / components. The subject matter described herein intends to cover and embrace all suitable changes in technology.

Claims

1.A computing system comprising:a processing unit configured to execute computer-readable instructions to cause the system to:obtain a set of problem specifications that collectively describe an optimization problem, wherein each problem specification comprises a defined data structure that includes a natural language (NL) description of a respective element represented in an optimization model for the optimization problem;generate, based on the set of problem specifications together with a NL problem description of the optimization problem, NL model component generation prompts for a large language model (LLM) ;generate a symbolic model for the optimization problem based on LLM generated outputs obtained in response to the model component generation prompts.2.The system of claim 1 wherein the processing unit is configured to execute the computer-readable instructions to cause the system to:obtain the NL problem description of the optimization problem;wherein the system is configured to obtain the set of problem specifications by:generating, based on the NL problem description of the optimization problem, NL specification extraction prompts;generating the problem specifications based on LLM generated outputs obtained in response to the NL specification extraction prompts.3.The system of claim 1 or 2 wherein the processing unit is configured to execute the computer-readable instructions to cause the system to:generate, based on the NL problem description and previously generated content of the problem specifications, NL reference extraction prompts;extract reference data mapping respective problem specifications to respective parts of the NL problem description based on LLM generated outputs obtained in response to the NL reference extraction prompts; andinclude the reference data in the respective problem specifications.4.The system of any one of claims 1 to 3 wherein the processing unit is configured to execute the computer-readable instructions to cause the system to:generate, based on the NL problem description and previously generated content of the problem specifications, NL relevance extraction prompts;extract relevance data indicating a relevance of respective problem specifications to the NL problem description based on LLM generated outputs obtained in response to the NL relevance extraction prompts; andinclude the relevance data in the respective problem specifications.5.The system of any one of claims 2 to 4 wherein the processing unit is configured to execute the computer-readable instructions to cause the system to further obtain an NL conversation history of exchanges between human parties about the optimization problem, wherein the NL model component generation prompts and the NL specification extraction prompts are each generated also based on the NL conversation history.6.The system of any one of claims 2 to 5 wherein the problem specifications are each associated with a category from a predefined set of categories and the NL specification extraction prompts include a plurality of different specification extraction prompts that are each respectively generated to extract data pertaining to a respective category from the predefined set of categories.7.The system of any one of claims 1 to 5 wherein the processing unit is configured to execute the computer-readable instructions to cause the system to present the problem specifications to a user for editing and / or selection, wherein the NL model component generation prompts are generated based on the problem specifications as edited and / or selected.8.The system of any one of claims 1 to 7 wherein the symbolic model includes a plurality of model components that each represent respective math symbols included in the symbolic model and the processing unit is configured to execute the  computer-readable instructions to cause the system to:for each model component:generate, based on the problem specifications and previously generated content of the model component, a respective NL relation extraction prompt;extract reference data mapping the model component to one or more of the problem specifications;andinclude the reference data in the model component.9.The system of claim 8 wherein the processing unit is configured to execute the computer-readable instructions to cause the system to:for each model component:generate, based on the problem specifications and previously generated content of the model component, a respective NL explanation prompt;extract explanation data that explains a purpose of the model component;andinclude the explanation data in the model component.10.The system of any one of claims 1 to 9 wherein the processing unit is configured to cause the symbolic model to be transformed into a model instance and solved by a solver to provide a solution for the optimization problem, wherein the solution specifies a change in a physical domain.11.The system of any one of claims 1 to 10 wherein the processing unit is configured to execute the computer-readable instructions to cause the system to store the symbolic model in a non-transient storage.12.A computer implemented method for generating an optimization model, comprising:obtaining a set of problem specifications that collectively describe the optimization problem, wherein each problem specification comprises a defined data structure that includes a natural language (NL) description of a respective element represented in an optimization model for the optimization problem;generating, based on the set of problem specifications together with a NL problem description of the optimization problem, NL model component generation prompts for a large language model (LLM) ; andgenerating a symbolic model for the optimization problem based on LLM generated outputs obtained in response to the model component generation prompts.13.The method of claim 12 comprising:obtaining the NL problem description of the optimization problem;wherein obtaining the set of problem specifications comprises:generating, based on the NL problem description of the optimization problem, NL specification extraction prompts;generating the problem specifications based on LLM generated outputs obtained in response to the NL specification extraction prompts.14.The method claim 12 or 13 comprising:generating, based on the NL problem description and previously generated content of the problem specifications, NL reference extraction prompts;extracting reference data mapping respective problem specifications to respective parts of the NL problem description based on LLM generated outputs obtained in response to the NL reference extraction prompts; andincluding the reference data in the respective problem specifications.15.The system of any one of claims 12 to 14 comprising:generating, based on the NL problem description and previously generated content of the problem specifications, NL relevance extraction prompts;extracting relevance data indicating a relevance of respective problem specifications to the NL problem description based on LLM generated outputs obtained in response to the NL relevance extraction prompts; andincluding the relevance data in the respective problem specifications.16.The method any one of claims 13 to 15 comprising obtaining an NL conversation history of exchanges between human parties about the optimization problem, wherein the NL model component generation prompts and the NL specification extraction prompts are each generated also based on the NL conversation history.17.The method of any one of claims 13 to 16 wherein the problem specifications are each associated with a category from a predefined set of categories and the NL specification extraction prompts include a plurality of different specification extraction prompts that are each respectively generated to extract data pertaining to a respective category from the predefined set of categories.18.The method of any one of claims 12 to 17 comprising presenting the problem specifications to a user for editing and / or selection, wherein the NL model component generation prompts are generated based on the problem specifications as edited and / or selected.19.The method of any one of claims 12 to 18 wherein the symbolic model includes a plurality of model components that each represent respective math symbols included in the symbolic model, comprising:for each model component:generating, based on the problem specifications and previously generated content of the model component, a respective NL relation extraction prompt;extracting reference data mapping the model component to one or more of the problem specifications;andincluding the reference data in the model component.20.The method of claim 19 comprising:for each model component:generating, based on the problem specifications and previously generated content of the model component, a respective NL explanation prompt;extracting explanation data that explains a purpose of the model component;andincluding the explanation data in the model component.21.The method of any one of claims 12 to 20 comprising causing the symbolic model to be transformed into a model instance and solved by a solver to provide a solution for the optimization problem, wherein the solution specifies a change in a physical domain.22.The method of any one of claims 1 to 21 comprising storing the symbolic model in a non-transient storage.23.A non-transitory computer-readable medium having instructions stored thereon, wherein the instructions are executable by a processing unit of a computing system to cause the computing system to perform the method of any one of claims 12 to 22.

Images