## 4 Automatic Constraint Model Generator (ACMG)
### Main Components
Both are textual messages written in natural language. Recognizer: A Recognizer is a pre-trained foundational LLM that is fine-tuned and instruction-tuned using our dataset [19]. The output from the Recognizer increases the validity and correctness of downstream tasks; that is, generated constraint model. The Recognizer extracts semantic entities from the message containing the model. The goal is to reduce ambiguity by (i) identifying relevant CSP variables, (ii) extracting the domains of each variable, (iii) extracting the main constraints, and (iv) extracting input parameters for narrowing down the solution to a single instance. Generator: A Generator is a pre-trained foundational LLM that is fine-tuned and instruction-tuned using our dataset of constraint models [19]. The Generator takes the extracted semantic entities from the Recognizer, a message describing the model in natural language, and generates the final constraint model in the MiniZinc [41] modeling language. Evaluator: A Evaluator is a pre-trained foundational LLM from the GPT family of models, and the base architecture we used is the same LLM as vanilla ChatGPT, GPT-3.5-turbo. We did not fine-tune an LLM for this role; we used a vanilla LLM. We will dive deeper into this in our future research. MiniZinc solver: The MiniZinc modeling framework is a high-level, declarative programming language for defining and solving constraint satisfaction and optimization problems. MiniZinc is solver-independent, meaning you can choose the underlying solver that is best suited for the given problems. There are other solver-independent modeling frameworks, such as MiniZinc. Most notable are Savile Row [42] with Essence Prime [43] and CPpy [44]. Both support different solvers in the backend. Comparing one to another is an open research gap, and a unified benchmark is required. We chose MiniZinc as we think it is currently one of the most versatile and powerful modeling frameworks, especially after evaluating the feedback we received from our domain experts and the fact that it offers strong support for Python 3.13.3 integration. Errors and warnings: As stated by [41; 45], the MiniZinc solver generates two types of faults: first, it generates faults that prevent execution, which are called errors, and second, it generates faults that do not halt execution but indicate potential issues, which are called warnings, as indicated in [41; 45]. During our evaluation of the ACMG, we encountered the following MiniZinc errors: syntax, type, assertion failed, include, cyclic and evaluation errors. We also encountered warnings, such as the variable shadows another variable with the same name, and model inconsistency was detected before the search. For more information about MiniZinc errors and warnings, please refer to [41; 45]. File types: The file types that MiniZinc uses have two possible extensions: mzn and dzn. Mzn files are used to describe the problem that is modeled in the MiniZinc modeling language, and dzn files are used as data files. The goal is to have the data agnostic model described in the mzn file, before the data are changed, e.g., the rules for the n-queen problem are based on the problem, and number of data points can be four for the four-queen problem or eight for the eight-queen problem. Dzn files are optional, as you can embed data into mzn files, e.g., a sudoku puzzle is traditionally 9 \(\times\) 9; if there is no need to create a more general model, this constant will be embedded into mzn. More details about MiniZinc modeling can be found in [45]. We generate dzn files together with mzn files, meaning we ask an LLM, via a prompt, to return both mzn and dzn files. No formal ablation study was conducted on the generation of mzn and dzn files in one response or two to determine which method yielded better results, but we did notice that combining files yielded better results. This version of the ACMG generates both mzn and dzn files in one response.