The Constraint maker Tool and Iterative Design and User Feedback

Table of Links

Abstract and 1 Introduction

2 Survey with Industry Professionals

3 RQ1: Real-World use cases that necessitate output constraints

4 RQ2: Benefits of Applying Constraints to LLM Outputs and 4.1 Increasing Prompt-based development Efficiency

4.2 Integrating with Downstream Processes and Workflows

4.3 Satisfying UI and Product Requirements and 4.4 Improving User Experience, Trust, and Adoption

5 How to Articulate output constraints to LLMS and 5.1 The case for GUI: A Quick, Reliable, and Flexible Way of Prototyping Constraints

5.2 The Case for NL: More Intuitive and Expressive for Complex Constraints

6 The Constraint maker Tool and 6.1 Iterative Design and User Feedback

7 Conclusion and References

A. The Survey Instrument

6 THE CONSTRAINTMAKER TOOL

Informed by the survey results, we developed a web-based GUI, ConstraintMaker (Fig. 2), that enables LLM users to prototype, test, and apply constraints on the format of LLM outputs. With ConstraintMaker, users can specify different types of output constraints by simply selecting from the list of available constraint primitives (Fig. 2-2b). If needed, users can click the pencil icon (Fig. 2-2a) to further edit the details of a constraint primitive, such as specifying the schema of a JSON object (Fig. 2-3). Users also have the flexibility to mix and match multiple constraint primitives together (e.g., Fig. 2-6) to form more complex constraints. Currently, based on users’ needs and priorities identified by the survey, ConstraintMaker initially supports JSON object , Multiple choice , List , Ordered list , and Some text as primitives (Fig. 2-2b), where Some text asks the LLM to generate freely as it normally would.

Under the hood, we used a GPT-3.5-class LLM. We additionally implemented a finite-state machine-based decoding technique akin to that outlined in [39], ensuring the language model outputs strictly adhere to formats defined by a specialized regular expression (henceforth, “regex”). In fact, ConstraintMaker automatically converts a GUI-defined constraint into a regex (Fig. 2-2d), which the LLM observes during generation (Fig. 2-4).

6.1 Iterative Design and User Feedback

To explore the usability and usefulness of ConstraintMaker, we conducted a series of informal (around 30 minute each) user tests with five participants who self-identified as experts in prompting LLMs, as well as self-experimentation among the authors. We used the feedback from these sessions to iteratively refine the design of ConstraintMaker. We present some interesting findings and reflections below:

6.1.1 ConstraintMaker enables an intuitive separation of concerns. With ConstraintMaker, one can now specify “the tasks they want the model to perform” separate from “the expected format of the output,” an approach participants considered more intuitive and effective in steering LLMs to consistently achieve desired results compared to traditional prompting. Additionally, participants envisioned the possibility of reusing constraints across various prompts, which could reduce the effort of crafting new constraints for similar tasks and eliminate the need for prompt engineering post model migration.

6.1.2 Constraint-prototyping GUI needs to cater to both developers and non-developers. On the one hand, for non-technical users interested in experimenting with constraints, we noticed that the visible regex alongside the constraint primitive GUI was somewhat distracting. To address this, we added a feature that allows the regex to be toggled as hidden via the “< >” button (Fig. 2-2c). On the other hand, for more advanced users (e.g., developers), we observed a frequent need to make fine-grained adjustments to the underlying regex after creating an initial draft with the ConstraintMaker GUI (e.g., changing the “bullet” of a “bulleted list” from the default “− [...]” (Fig. 2-5) to “* [...]”). As a result, we enabled direct manipulation of the regex by toggling on "Edit constraints manually" (Fig. 2-2e).

6.1.3 “Inserting” words among constraints. For example, one participant asked in the prompt for the LLM to first write a paragraph describing a short story, followed by a list of suggestions on how to improve the story. In situations like this, they found that embedding specific words into the constraints, such as “Short story: Some text ” followed by “Suggestions: List ”, yielded better-quality results than simply using Some text followed by List alone. Therefore, we introduced the Exact text GUI primitive, enabling the LLM to insert user-prescribed text into its output.

6.1.4 Automatically inferring constraints based on prompts. One interesting feature request for ConstraintMaker is the ability to automatically infer constraints from user-written prompts, similar to previous intelligent prediction or auto-completion systems and tools [3, 19, 37]. For instance, for a prompt shown in Fig. 2-1, ConstraintMaker could proactively suggest to the users if they’d like to constrain the model output to a JSON object with specific fields. This feature would be appealing, given the current somewhat cumbersome process of manually creating and modifying constraints from scratch. Similar to code auto-completion, participants suggested that constraint auto-completion could streamline the overall experience of defining constraints. Additionally, automatic constraint suggestions could serve as learning opportunities for novice users to become familiar with the range of possibilities that ConstraintMaker affords, which would be particularly useful in future versions where the tool might support a wider selection of constraint primitives. Finally, proactively suggesting constraints could promote a “constraint mindset.” This encourages users to always consider the output format before deploying a prompt, leading to more rigorous and controllable prompt engineering, much like conventional software development.