Sunrise: A Higher-Order Prompting System

Modern web development is heavily reliant on the automated generation HTML and CSS from predefined templates. Thus, the ability to generate templated code from a prompt is a natural fit for LLMs and is the basis for the Sunrise project.

Sunrise is capable of generating and parsing code to perform a variety of tasks, including:

• AI-driven textual completions for a spreadsheet-like data structure, such as...
• • Completions for the next value of a column or row to be entered, given the currently provided values.
• • Completions to continue a sequence of values in a column or row of cells.
• AI-driven code completions to aid in the creation of a website, such as...
• • Completions for the next HTML element to be added to the website.
• • Applying CSS to the existing elements of a website.
• • Modifying existing HTML and CSS to match a desired visual design.

When combined with a web development framework, Sunrise can be used to generate a website from a non-technical description of the desired visual design, offer guidance for creating a desired visual layout of a website from a non-technical description, and provide suggestions applying relevant spreadsheet data to an automatically generated website.

While it holds true that LLMs do not perform arithmetic, they are capable of performing a variety of tasks that are similar to arithmetic:

Prompt: What is 2 + 2?

Response: 2 + 2 is 4

Prompt: What is half of 10?

Response: 10 / 2 is 5

At first glance this may appear as if the LLM is capable of performing arithmetic, but this illusion vanishes under more difficult circumstances:

Prompt: What is the square root of 240493284.0463 / 50292053.726?

Response: 240493284.0463 / 50292053.726 is 4.75

LLMs are not capable of generating a response that is correct in the sense that it is the result of an arithmetic operation. Instead, LLMs are capable of generating a response that is similar to the result of an any arithmetic operation. The numbers in the above example are unique to the prompt, and are not present in the training data, and so the chance for a relevant response is low.

Ironically, humans perform arithmetic in a similar manner when presented with novel and large numbers: Simplify the problem to a smaller, more familiar task, and then apply the solution to the original. And when the solution to the original problem is not immediately obvious, we often resort to automation through a calculator. With this framing in mind, we can observe that humans are also capable of performing tasks that are similar to arithmetic.

And so much like a human is conditioned to reach for calculator or a spreadsheet to perform complex arithmetic, we can fine-tune an LLM to generate the JavaScript code necessary to perform complex arithmetic.

The limits of second-order prompt engineering become apparant when an LLM is presented with complex and novel tasks. The LLM may generate a response that is not valid JavaScript, or may generate a response that is not the most efficient solution.

We can further fine-tune the LLM by providing additional upfront examples to help guide the generate a more accurate responses within the specific domain of arithmetic. In this example we include the first question and response from earlier. We then continue the pattern of providing a question and ask the LLM to complete the next performArithmetic function.

Prompt:

• Do not perform calculations.
• Do not compute the answer.
• Use JavaScript Math and Date to perform calculations.
• Respond with a performArithmetic function for the following prompt:

Question 1: What is the square root of 240493284.0463 / 50292053.726?

function performArithmetic() {
  const a = 240493284.0463
  const b = 50292053.726
  const c = a / b
  const d = Math.sqrt(c)
  return d
}

Question 2: 5 days a week, Jessie practices martial arts for 1.5 hours. Given that a week is 7 days, what is her average practice time per day each week?

function performArithmetic() {
  const daysPracticedInAWeek = 5
  const hoursPracticedInADay = 1.5
  const daysInAWeek = 7
  const totalHoursPracticedInAWeek = daysPracticedInAWeek * > hoursPracticedInADay
  const averagePracticeTimePerDay = totalHoursPracticedInAWeek / daysInAWeek
  return averagePracticeTimePerDay
}

With each successive example, the LLM is able to generate more accurate responses. However, the more examples we provide, the more likely it is that the LLM will begin to overfit to the examples, and generate responses that are not relevant to the original prompt.

Additionally, the LLM imposes a token-limit, usually around 1024 tokens depending on the model. The token-limit is the maximum number of tokens that can be within a single prompt. This means that the more examples we provide, the more likely it is that the LLM will reach the token-limit before it can generate a complete response.

Thus, a balance must be struck between the number of examples and the accuracy of the responses.

We can solve this problem by introducing a new meta-modality of response:

Prompt: Add a 1px border to all buttons.

Meta Prompt: Return confidence scores for the appropriate modality of response

{ "html": 0.8, "css": 0.5, "javascript": 0.3, "help": 0.1 }

<button style="border: 1px solid black">Button</button>

This approach is similar to how a assistant would delegate a novel but well-understood inquiry to a collegue with the appropriate subject-matter expertise. As the assistant is exposed to more inquiries, they become more accurate at determining the appropriate modality of response. The same is true for the meta-mode.

To our delight, fine-tuning a meta-mode requires no additional call-and-response examples. Rather, we can instead re-use the existing prompt data from the fine-tuned LLMs for each modality. With each sucessive mapping of a user prompt to a modality of response, the meta-mode becomes more accurate at determining the appropriate modality of response.

In the example above, the meta-mode determines the high confidence score of the HTML-mode due to the prompt's similarity to existing HTML-mode examples. When the difference between the confidence scores of the top two modalities is less than a threshold, the meta-mode asks the user to either choose from a mode manually or clarify their intent by restating the prompt.

As an human operator determines a modality's accuracy of response, the fine-tuned LLM is challenged with progressively more difficult and vague prompts. Inevitably, the LLM will begin to generate second-order functions that are either not relevant or incorrect. To combat this, we use a means regression to find consensus among a series of LLM's response to the same prompt with varying temperatures (i.e. the degree of randomness in the response):

Prompt: When I was 6 my sister was half my age. Now I'm 70. How old is my sister?

Response 1: (Temperature: 0.8)

function performArithmetic() {
  const myAge = 70
  const mySisterAge = 6
  const mySisterAgeWhenIWas6 = 3
  const mySisterAgeNow = mySisterAgeWhenIWas6 + (myAge - 6)

  return `Your sister is ${mySisterAgeNow} years old.`
}

Response 2: (Temperature: 0.5)

function performArithmetic() {
  const a = 70
  const b = 6
  const c = 3
  const d = a - b
  const e = c + d
  return e
}

Response 3: (Temperature: 0.1)

function performArithmetic() {
  return 3 + (70 - 6)
}

Response 4: (Temperature: 1)

function performArithmetic() {
  return 'sixty-seven'
}

This prompt is fairly straightforward and can be solved in a variety of ways. However, from the operator's perspective, we want to discard the responses that include sytnax errors, or functions that return irrelevant or incorrect information. Syntax errors are easily discarded by checking the response against a syntax checker, but determining the relevance and accuracy of a response requires a consensus among the returned values.

The operator is only interested in the mean occurence of a value, and can discard the responses that are not within a certain threshold of the mean. In the 4 responses above, we can execute each function and tally up the results:

• "Your sister is 67 years old.": 1
• 67: 2
• "sixty-seven": 1

Two of the four functions return the same value of 67, indicating a consensus. The subjective difference between the two functions is negligible: both achieve the same valid result. The operator can choose between one or more of these valid responses and add them to the fine-tuned LLM's examples.

If there is no consensus among the responses, this may indicate that the LLM is underperforming with the given prompt. This may actually be a good thing, as it indicates that the LLM is generating responses that are not only valid, but also novel. The operator can choose to add one or more of the responses to the fine-tuned LLM's examples, or discard them if they are not relevant to the prompt.

If all responses are invalid, the operator can choose to rephrase the prompt, or manually complete the response themselves. Alternatively, the invalid generated invalid responses can be stored for future analysis.

Our current approach to runtime security aligns with with well-known industry standards: Any data that is provided by an external source is considered unsafe and should not be executed in a privileged environment.

While this approach is suitable for typical user inputs, integrating LLM outputs requires additional measures to ensure the security of our systems. We must assume that all LLM-generated code is potentially harmful and executable only within an unprivileged environment. This is achieved by executing the LLM-generated code in a sandboxed environment, and only allowing the execution of a limited set of functions.