# The Impact of Prompting Techniques on the Security of the LLMs and the Systems to Which They Belong
## 2 Domain Overview
### PaL: Program-Aided Language Models  
\"PaL: Program-aided Language Models\" [3] is a particularly interesting paper because it picks up the subject previously discussed in Section 2.4 together with a few other papers like \"Show Your Work: Scratchpads for Intermediate Computation with Language Models\" [19] and \"Least-to-Most Prompting Enables Complex Reasoning in Large Language Models\" [20] and tries to address a few of their weaknesses. One of the main weaknesses of LLMs is that even if through methods like CoT, the LLMs end up splitting natural language problems into intermediate steps that are coherent and correct, the validity of the end solution is often impacted by their inability to perform arithmetic operations with big numbers or solve symbolic tasks that require generalization on a larger scale. PaLproposes a method in which we let the LLM perform the natural language understanding and decomposition, and then it offloads the solution steps to a code interpreter/compiler that can perform the solving step. A practical example of this approach is presented in Figure 3.  
The authors of this paper choose to test their hypothesis using Codex [21] and show that using PaL, it can outperform much larger models like PaLM-540B using CoT prompting. The PaL approach might seem similar with CoT, but there are a few important differences. PaL wants to generate \"thoughts\" t for a given natural language problem x as interleaved natural language (NL) and programming language (PL) statements. As we already saw when using PaL, the solution step is delegated to the interpreter/compiler, therefore, the final answer is not necessarily in the examples we provide in our prompt. Each example in PaL is a pair \(\langle x_{i},t_{i}\rangle\)[3] compared to the CoT approach, where each example is a triplet of shape \(\langle\text{input},\text{chain of thought},\text{output}\rangle\)[2]. A PaL example is presented in Figure 4.  
The authors justify the importance of not including the solution in the prompt because they want to make the LM generate an algorithm that will lead to the solution and not the solution itself. The CoT intermediate steps are generated as comments alongside the algorithm code. By passing the generated program \(t_{test}\) to its corresponding solver, we obtain the final run result \(y_{test}\). It is noted in the paper that the incremental run of the PL segments is also possible. After each segment is processed, the result is fed back to the LLM to generate the next block. However, this is not how the authors experiment as they seek simplicity.  
Following the same pattern used in \"Chain-of-Thought Prompting Elicits Reasoning in Large Language Models\" [2], the experiments are split into three categories of reasoning tasks: mathematical problems using GSM8K [14], SVAMP [15], ASDIV [16] and MAWPS [17] (all these datasets of problems were used to test CoT too), symbolic reasoning using BIG-Bench Hard [22], and algorithmic problems using BIG-Bench Hard [22].  
Figure 3: A diagram illustrating the differences between chain-of-thought prompting and program-aided language models from PaL paper [2,3].  
We already know that LLMs can perform simple calculations with small numbers. \"Text and Patterns: For Effective Chain of Thought, It Takes Two to Tango\" [23] underscores that 50% of numbers in the GSM8K dataset are between 0 and 8. To see if the generalization ability of LLMs is good enough to perform arithmetic operations using big numbers, the authors create a new dataset called GSM-HARD. This dataset is a version of GSM8K in which all the numbers are replaced with large numbers up to seven digits. The results compare DIRECT prompting, CoT, and PaL.