Questions:

Handling Unrelated Numbers: How does the model manage sentences with numbers unrelated to the arithmetic operation, such as historical data in the question 'In 1932, 100 planets were discovered and in 1933, another 200 were found. What is the total number of planets discovered between 1932 and 1933? ' How does the string parser determine which numbers should be input into OccamNet?

We understand your concern about arithmetic problems in which relevant numbers are not the most recent numbers in the text. We are happy to assert that, in most cases, OccamLlama is capable of solving them. To illustrate, below is OccamLlama's response to your example problem:

In 1932, 100 planets were discovered and in 1933, another 200 were found. What is the total number of planets discovered between 1932 and 1933? The number of planets discovered in 1932 was 100. The number of planets discovered in 1933 was 200. So the total number of planets discovered is 100 + 200 = 300\n\n#### 300.

As you can see, most language models tend to repeat the computation they wish to perform prior to stating the answer, which reinserts the relevant numbers as the most recent numbers in the text. The reasoning is done by the LLM and the arithmetic by OccamNet, showcasing the unique synergy that the OccamLLM system achieves.

At the same time, it is possible to train an OccamLlama with the ability to perform arithmetic correctly when the relevant numbers are not the most recent in the context. This can be done by simply providing OccamLlama the ten most recent numbers in the text instead of the two most recent, for example. In practice, we did not find this to be needed.

Limitations:

Compound Expressions: The framework's reliance on prompting LLMs to decompose compound expressions is a significant limitation. If LLMs fail to adequately simplify these expressions, the decoder might incorrectly determine the operation to be performed or fail to revert to the LLM for complex expressions.

Thank you for your comment. We note that our existing methods are already capable of performing arbitrarily complex arithmetic by chaining simpler calculations. Existing language models are generally trained or prompted to reason step-by-step, meaning that their generation can often be supplemented by a single-layer OccamNet. This is evidenced by our reasoning benchmarks, in which OccamLlama (with a single-layer OccamNet) performs quite well across a wide range of tasks.

Additionally, we can further improve OccamLlama systems with single-layer OccamNets by finetuning and/or prompting the model to think step-by-step.

Continued below

Strengths:

Addressing a Key Weakness: Popular LLMs struggle with simple arithmetic, limiting their understanding of physics and mathematics. This paper overcomes this limitation by integrating a symbolic model, OccamNet, which performs basic arithmetic with 100% accuracy.

Innovative Integration: The authors propose a decoder mechanism to determine whether the next token should be generated from the LLM or OccamNet, and which operation OccamNet should execute. This approach of integrating OccamNet with other LLMs opens interesting future research directions, particularly in combining other tools with LLMs.

We appreciate your kind remarks!

Weaknesses:

Decoder's Robustness: The effectiveness of OccamLLM heavily depends on the decoder's training across various prompts to accurately discern the required operation. There is a risk that unfamiliar prompts could lead the decoder to instruct OccamNet to perform incorrect operations.

Thank you for your comment. We agree that this is a potential concern. However, we contend that out-of-distribution inputs are a problem for all machine learning models, so this issue is not specific to OccamLlama.

In fact, we find that OccamLlama displays remarkable generalization capabilities on out-of-distribution problems. To demonstrate this, we train the OccamNet decoder from scratch, using only numeric expressions and absolutely no text at all. This means that any problem with text, such as a word problem, is far out of distribution of the OccamNet decoder's training data. We test this model (using the standard router) on the mathematical reasoning benchmarks and obtain remarkably good results, shown visually in Figure b) of the global response PDF and presented in the table below. The OccamLlama 8B decoder trained only with numerical expressions performs on par with the model trained with both numbers and text, even achieving higher accuracy on some benchmarks. This shows that the OccamLLM framework is robust and points towards the fact that the representations of arithmetic that are built in the transformer body of the LLM and extracted by the OccamLLM Decoder are very general.

Table: Accuracy on reasoning tasks. Higher is Better.

In contrast, we expect that finetuning Llama to perform arithmetic using only numeric examples and no text whatsoever would lead to extreme catastrophic forgetting and poor arithmetic performance on word problems. As such, we believe this data shows a remarkable robustness of OccamLLM.

As a second example of generalization, we tested OccamLlama on the Multilingual Grade School Math Benchmark (MGSM), a dataset consisting of GSM8K translated into 10 languages (Bengali, Chinese, French, German, Japanese, Russian, Spanish, Swahili, Telugu, and Thai). We compute the drop in accuracy when switching from English to another language, given by the accuracy of a model on the English dataset minus the accuracy of the model on the dataset in a given language. For OccamLlama in Bengali and Telugu, due to time constraints, we evaluated on a subset of 100 and 50 randomly chosen problems, respectively. We will update the table below with the full results soon. We show the results in visually in Figure c) of the global response PDF and the table below:

Table: Accuracy drop on multilingual reasoning tasks. Lower is better.

The table above shows that OccamLlama has on average a smaller performance drop than llama between the English dataset and the non-English language datasets. The fact that OccamLlama (the decoders for which have never been trained on other languages) has on average better out-of-distribution behavior than Llama (a model trained on over 750 billion tokens of non-English text) is in our opinion quite remarkable.

We believe that these two tests demonstrate OccamLlama's robustness against out-of-distribution data.

Continued below

Additionally, the paper lacks experimental validation that LLMs can effectively handle compound expressions.

Thank you for your comment. We believe that the mathematical reasoning benchmarks provide experimental validation that OccamLlama can effectively handle compound expressions. These problems are multi-step math problems requiring multiple calls to OccamNet to be completed successfully. Given OccamLlama's strong performance on these benchmarks, we hope you will agree that OccamLlama can effectively handle compound expressions. We will make this clearer in the paper.

Since submitting to NeurIPS, we identified a few minor bugs in our code which were limiting performance and slightly reweighted the proportions of the different training datasets. These changes maintained the perfect performance on arithmetic tasks and improved performance on mathematical reasoning tasks. The updated results are shown visually in Figure a) of the global response PDF and the table below:

Table: Accuracy on reasoning tasks. Higher is Better.

Here, we see that OccamLlama outperforms even GPT 4o and GPT 4o with Code on benchmarks requiring challenging arithmetic (MultiArith Float and MATH401), areas where OccamLlama shines. Additionally, the gap between OccamLlama and LLama 3 8B is substantially smaller on GSM8K. On average, OccamLlama outperforms both Llama and GPT 3.5 Turbo, with accuracy approximately halfway between that of GPT 3.5 and GPT 4o.

We also find that the performance of OccamLlama on reasoning benchmarks improves dramatically as we increase the base model from Llama 3 8B to Llama 3 70B (OccamLlama 70B).

To ensure we had results in time for the rebuttal deadline, we sampled 100 random questions from each dataset to determine OccamLlama 70B's performance, which is the cause for the relatively large error bars. We will update this response with the full results once they complete. The results are shown visually in Figure d) of the global response PDF and the table below:

Table: Accuracy on reasoning tasks. Higher is better.

These results demonstrate that OccamLLM is capable of robust performance on large-scale models. Training the OccamLLM 70B system (in 16-bit precision and unoptimized code) required approximately 1.5-2 days on a system with two A100 nodes, demonstrating the low compute requirements of our method.

OccamLlama 70B shows consistent improvement over OccamLlama 8B. We believe this results from a combination of Llama 3 70B's improved reasoning capabilities and Llama 3 70B's improved representations (which enable OccamLlama to generalize more effectively). We expect that training with even larger base models would lead to further improvements. Remarkably, OccamLlama 70B outperforms GPT 4o and GPT 4o with Code on average across these benchmarks. It also outperforms GPT 3.5 Turbo on all but Single Eq.

We are very grateful for your comments and suggestions. We hope you will agree that the additional experiments and clarifications will strengthen our paper.

Dear Reviewer,

We are writing to provide updated results from our completed evaluation runs. Below, we show the final results for OccamLlama 70B. We note that OccamLlama 70B maintains its strong performance when tested on the complete datasets. It still outperforms both GPT 4o and GPT 4o with Code on average. It also improves substantially compared to the 100-datapoint performance estimate on Single Eq. OccamLlama outperforms GPT 3.5 Turbo on all datasets except Single Eq, where it is less than one percentage point behind and within error bars.

Above, we also include results from Llama 3 70B Instruct. OccamLlama 70B substantially outperforms Llama 3 70B on MultiArith Float and MATH401. It is roughly the same (1.3 percentage point deviation or less) as Llama 3 70B on all other datasets (ones with arithmetic simple enough for Llama to perform satisfactorily) except for GSM8K, which demonstrates OccamLlama's ability to not interfere with reasoning while still assisting with arithmetic. On average, OccamLlama 70B outperforms Llama 3 70B by nearly five percentage points, and OccamLlama 8B approximately matches Llama 3 70B's average performance.

We also provide the final table for the MGSM dataset:

We note that previously, there was a typo in this table. The averages were incorrect, incorrectly showing that OccamLlama had a larger performance drop than Llama on average. We apologize for any confusion. Our verbal statements in the rebuttal were correct, and Figure c) in the general rebuttal PDF had the correct averages for the previous data. Other than this typo, the table above closely resembles the previously reported table, so we do not comment further.

Thank you for your consideration.

Dear Reviewer,

Thank you for your question. We believe that OccamLLM provides numerous advantages relative to code generation:

• Improved generation speed and cost: LLM Code generation requires generating tokens for code, leading to the use of potentially many more tokens than are needed to respond to a query. This can make LLMs with code generation (unlike OccamLLM) slow and expensive. For example, in the arithmetic benchmarks, we found that GPT 4o with code required on average more than 50 completion tokens, far more than the single autoregressive step required by OccamLlama to answer each question. Additionally, our total expenses for GPT 4o with code were more than double that of GPT 4o without code, even though we made almost 5 times fewer queries to GPT 4o with code, suggesting that GPT 4o with code is approximately 10 times more expensive per query than GPT 4o. Since OccamLLM does not require any additional autoregressive steps of the LLM, this suggests that OccamLLM is faster and cheaper than code generation.
• Better results: The LLM code generation method we compared against, GPT 4o with Code Interpreter, actually performed worse than GPT 4o on average. We believe these results demonstrate that, for arithmetic, LLM code generation is not an optimal solution. OccamLlama 70B outperforms GPT 4o with code on our benchmarks, suggesting that OccamLLM provides a better solution.
• No catastrophic forgetting: Code generation generally requires fine-tuning an LLM to write and run code. This risks catastrophic forgetting.
• Improved security: Running LLM-generated code is potentially unsafe. For example, the LLM could ask to run the python code __ import__('os').system('rm -rf /'). It is in general extremely challenging to check code for malicious behavior. OccamLLM does not run arbitrary code, so it avoids these risks.
• Reduced engineering: For the reasons mentioned in the previous bullet, building a secure system for LLM code execution, such as by hosting an LLM and a sandbox to safely run code, requires substantial engineering effort. Users can simply download our OccamLLM models and run them; no engineering is required.

As a result of OccamLlama's improved speed, cost, performance, security, and ease of use, we believe it is a compelling alternative to LLM code generation for arithmetic. We will make these advantages clearer in our paper.

Thank you again,

The Authors

I thank the authors for their responses.

Compared to LLMs that generate code to solve arithmetic, OccamLLM requires training a decoder and OccamLlama but does not need to fine-tune the LLMs on arithmetic code generation. Are there any other advantages compared to LLMs that generate code to solve arithmetic?

...it is possible to train an OccamLlama with the ability to perform arithmetic correctly...done by simply providing OccamLlama the ten most recent numbers in the text...

Regarding your statement that it is possible to train an OccamLlama to perform arithmetic correctly by simply providing it with the ten most recent numbers in the text, I understand that the input to OccamLlama includes the output of the decoder and the most recent numbers. Could you please clarify if this means that by training OccamLlama, the model can determine which numbers to use in the arithmetic tasks? For example, if the input numbers are '1932, 100, 1933, 200,' would the training allow OccamLlama to learn to use 100 and 200?"

Strengths:

Adding an external OccamNet helps on avoiding finetuning the LLM model (which exposes the model to the risk of catastrophic forgetting or becoming less safe). The manual data collection is either cheap or completely non-existent, with the result that the idea can be replicated for other reasoning tasks.

Introducing the MultiArith Float is a significant contribution, allowing the use for further research in the same domain.

The method is clearly faster than current LLMs, although on a very small token proportions.

We appreciate your kind remarks!

Weaknesses:

My main concern is about novelty. The idea of offloading calculation to another specialized model with a Switch is not new.

We acknowledge that offloading computation with a switch is a common procedure in mixture of experts models. However, to our knowledge, our work is unique in that we implement a decoder module which initializes the parameters of a second computational model at each autoregressive step. In our mind, this is closest to a hypernetwork, but unlike a hypernetwork we initialize OccamNet at each autoregressive step instead of just once per input.

We believe this step is quite novel. To use an analogy, if this same idea were used in the context of linear layers (i.e. using one linear layer to initialize another), one arrives at a model similar to attention. In the same way that we believe attention is sufficiently distinct from a linear layer to be considered novel, we believe that our method is sufficiently distinct from other gated computation methods to be considered novel.

The work cannot be easily expanded on multi step calculations. In particular, for a task of length N you probably require an N layer OccamNet, which imposes a big constrain on the calculation you can actually do.

Thank you for your interest in OccamLLM using a multi-layer OccamNet. We are exploring this direction in future work, and we beleive we can train performant OccamLLM systems with a many-layer OccamNet. In the present paper, we simply wish to demonstrate the potential promise of using multiple-layer OccamNets.

We note that our existing methods are already capable of performing arbitrarily complex arithmetic by chaining simpler calculations. Existing language models are generally trained or prompted to reason step-by-step, meaning that their generation can often be supplemented by a single-layer OccamNet. This is evidenced by our reasoning benchmarks, in which OccamLlama (with a single-layer OccamNet) performs quite well across a wide range of tasks.

Additionally, we can further improve OccamLlama systems with single-layer OccamNets by finetuning and/or prompting the model to think step-by-step.

There is no comparison between the OccamNet and another baseline, i.e. a trained Transformer which makes the Python code for the calculations only. The baseline should be easy to train, with no safety risk and with no catastrophic forgetting, but also comes with multi step calculations for free.

In the text, we describe what we believe are compelling reasons why OccamLLM works most naturally when representing the probability distribution over functions using OccamNet.

Regarding transformers and RNNs, we believe that OccamNet possesses a key advantage of being interpretable; simply by looking at the weights, it is possible for a human to determine which functions OccamNet assigns a high probability. We believe that this interpretability will make OccamNet easy for a decoder to initialize with the desired distribution. On the other hand, an RNN or transformer have substantially more complex relations between the weights and corresponding probability distribution, which we hypothesize would make learning a decoder for such models difficult.

This leads us to a key point: transformers and RNNs are effective for modeling complex multimodal distributions, but for this problem, we want to select a single function for each token, so the extra expressivity of these models is unneeded and likely detrimental to performance. We believe that OccamNet, a much simpler architecture, enables better parameter efficiency and performance.

We also tested using Equation Learner but we found it to be unstable. The EQL model represents a single function instead of a probability distribution over functions, and therefore the RL-inspired OccamNet loss cannot be used. The Mean Square Error loss used in this case requires many adjustments and tricks to enable the model to train, and we find that EQL explores the function space much less efficiently. Thus, it gets stuck and local minima. We didn't manage to get good performance with EQL.

Regarding your proposal to replace OccamNet with a transformer which produces Python code for the relevant calculation, we believe this still presents a security risk in that code such as __ import__('os').system('rm -rf /') could be generated and run. Although this is a particularly obvious example, it is in general extremely challenging to check general-purpose code for malicious behavior. We believe that one potential solution would be to train a transformer to generate a restricted language that is not Turing-complete, such as a prefix-notation formula. We are happy to run this baseline and report the result if you would like. At the same time, we are confident that, for the reasons listed above, OccamNet will perform better than this alternative.

Continued below

Questions:

How did you generate the OccamLLM switch training data ("we manually created and labeled several other examples for diverse scenarios, to explicitly teach the system in which cases it should or should not use OccamNet")?

Thank you for your question.

The OccamLLM Switch training data comes from different sources. 25% comes from numerical expressions and 5% come from multi-step reasoning problems, as explained in the text. The remaining 70% was sampled from a set of 27 manually created prompts that we expected to cover most of the cases that we needed to teach the LLM about when to use and when not to use the single-layer OccamNet. Each sample was sampled hundreds of times with different numerical values to add diversity. Below, we present some of these prompts and explain what case they cover. The tokens of the numbers in bold were marked with a 1 to signal that the switch should route to OccamNet, and the rest of the numbers and all of the text tokens were marked with a 0 to signal that OccamNet should not be called in these cases.

The cases we cover with these prompts are:

1. Single-layer OccamNet should be called to peform two-input arithmetic operations.
2. OccamNet should not be called to write numbers that already appeared and do not require further arithmetic.
3. OccamNet should not be called to round numbers.
4. OccamNet should not be called to perform inline operations nested within a larger expression because it might contradict the assumption that the last two numbers are involved in the operation.
5. OccamNet should not be used to convert magnitudes when the LLM does not explicitly write the conversion factor and relies in its internal knowledge; without the numeric value of the factor present in the text, OccamNet can't give the correct result.
6. OccamNet can't compute percentages, as this operation was not included in the training set of operations. It could be done in two steps.
7. Single-layer OccamNet can't compute a fraction of a number, as this would require two operations.
8. Single-layer OccamNet can't perform operations with more than 2 arguments.

User query: An author writes 7.6 pages per session. After 9 sessions, the total pages written are

Assistant response: The author writes 7.6 pages per session. After 9 sessions, the author will have written 7.6 * 9 = 68.7 pages. The answer is 68.

Cases: 1, 2, 3

User query: I have 10 oranges and 6 apple trees, each of them with 3 apples. How much fruit do I have?

Assistant response: The total number of pieces of fruit is 10 oranges + 6 trees times 3 apples = 10 + (6 * 3) = 10 + 18 = 28. The answer is 28.

Cases: 1, 2, 4

User query: Sally has 7 pennies and 8 nickels. How many pennies does she have in total?

Assistant response: 1. Convert the number of nickles to pennies: 8 nickles is 40 pennies.

2. Add total number of pennies 40 + 7 = 47.

The answer is 47.

Cases: 1, 2, 5

User query: What is 84 per cent of 230.77??

Assistant response: 84% of 230.77 = 193.85

Explanation:

84 / 100 = 0.84

0.84 * 230.77 = 193.85

Cases: 1, 2, 6

User query: There were 39 cats on a rock. 3 boats came and carried away 5 cats each, and later, 3/7 of the remaining cats ran after a mouse they'd seen. How many cats were left on the rock?

Assistant response: There were originally 39 cats. 3 boats came and each took away 5 cats. So 3 x 5 = 15

39 - 15 = 24

So there were 21 cats left. Then 3/7 of them ran away. 3/7 of 21 is 9

24 - 9 = 15

So there were 15 cats left.

Cases: 1, 2, 7

User query: 11 people have 2 apples, 2 oranges and 2 peaches each. How many pieces of fruit do they have combined?

Assistant response: Each person has 2 + 2 + 2 = 6 pieces of fruit.

In total, they have 6 * 11 = 66.

The answer is 66.

Cases: 1, 2, 8

Continued below

How robust is the model to unseen training data?

We find that OccamLlama displays remarkable generalization capabilities on out-of-distribution problems. To demonstrate this, we train the OccamNet decoder from scratch, using only numeric expressions and absolutely no text at all. This means that any problem with text, such as a word problem, is far out of distribution of the OccamNet decoder's training data. We test this model (using the standard router) on the mathematical reasoning benchmarks and obtain remarkably good results, shown visually in Figure b) of the global response PDF and the table below. The OccamLlama 8B decoder trained only with numerical expressions performs on par with the model trained with both numbers and text, even achieving higher accuracy on some benchmarks. This shows that the OccamLLM framework is robust, and points towards the fact that the representations of arithmetic that are built in the transformer body of the LLM and extracted by the OccamLLM Decoder are very general.

Table: Accuracy on reasoning tasks. Higher is Better.

In contrast, we expect that finetuning Llama to perform arithmetic using only numeric examples and no text whatsoever would lead to extreme catastrophic forgetting and poor arithmetic performance on word problems. As such, we believe this data shows a remarkable robustness of OccamLLM.

As a second example of generalization, we tested OccamLlama on the Multilingual Grade School Math Benchmark (MGSM), a dataset consisting of GSM8K translated into 10 languages (Bengali, Chinese, French, German, Japanese, Russian, Spanish, Swahili, Telugu, and Thai). We compute the drop in accuracy when switching from English to another language, given by the accuracy of a model on the English dataset minus the accuracy of the model on the dataset in a given language. For OccamLlama in Bengali and Telugu, due to time constraints, we evaluated on a subset of 100 and 50 randomly chosen problems, respectively. We will update the table below with the full results soon. We show the results in visually in Figure c) of the global response PDF and the table below:

Table: Accuracy drop on multilingual reasoning tasks. Lower is better.

The table above shows that OccamLlama has on average a smaller performance drop than llama between the English dataset and the non-English language datasets. The fact that OccamLlama (the decoders for which have never been trained on other languages) has on average better out-of-distribution behavior than Llama (a model trained on over 750 billion tokens of non-English text) is in our opinion quite remarkable.

We believe that these two tests demonstrate OccamLlama's robustness against out-of-distribution data.

Limitations:

Authors did some work to address the limitations, but making Llama do the multi step calculations actually defeats the purpose of the work.

We respectfully disagree. OccamLlama ensures that arithmetic is correct. As we mention above, most language models already perform step-by-step arithmetic, so OccamLlama does not use any more tokens than a normal language model generation.

We are very grateful for your comments and suggestions. We hope you will agree that the additional experiments and clarifications will strengthen our paper.

The methodology depends on a constrained set of operations and numbers only, and the paper doesn't discuss how OccamLLM, and the Switch in particular, handles ambiguous or uncertain inputs (i.e. "compute one plus two"), making it less relevant for real world applications.

We understand your concern about less structured arithmetic problems, and we are happy to assert that OccamLlama is capable of solving these problems. For example, below we show input-output pairs of basic queries to OccamLlama that demonstrate its ability to perform arithmetic even when numbers are provided as words:

• Six minus seven =? -1\n\nSix minus seven is equal to -1.
• Three + four = ? 7\n\n3 + 4 = 7\n\nLet me know if you have any other questions!

The above calculations are computed correctly because we use a number parser that parses strings such as three and six as numbers. One can change OccamNet's behavior on tasks such as this by changing the number parser. We didn't parse words as numbers when performing our benchmarks, but we do not expect that this would change OccamLlama's performance substantially.

On math benchmarks, especially on GSM8K, the results are pretty weak. Authors explained the reason, but it's not clear how to fix it without adding more data. In that case I'm not clear about the benefit of training the OccamNet and Switch compared to add these data to the LLM pretraining dataset.

Thank you for your comment. Since submitting to NeurIPS, we identified a few minor bugs in our code which were limiting performance and slightly reweighted the proportions of the different training datasets. These changes maintained the perfect performance on arithmetic tasks and improved performance on mathematical reasoning tasks. The updated results are shown visually in Figure a) of the global response PDF and the table below:

Table: Accuracy on reasoning tasks. Higher is Better.

Here, we see that OccamLlama outperforms even GPT 4o and GPT 4o with Code on benchmarks requiring challenging arithmetic (MultiArith Float and MATH401), areas where OccamLlama shines. Additionally, the gap between OccamLlama and LLama 3 8B is substantially smaller than before on GSM8K. On average, OccamLlama outperforms both Llama and GPT 3.5 Turbo, with accuracy approximately halfway between that of GPT 3.5 and GPT 4o.

We also find that the performance of OccamLlama on reasoning benchmarks improves dramatically as we increase the base model from Llama 3 8B to Llama 3 70B.

To ensure we had results in time for the rebuttal deadline, we sampled 100 random questions from each dataset to determine OccamLlama 70B's performance, which is the cause for the relatively large error bars. We will update this response with the full results once they complete. The results are shown visually in Figure d) of the global response PDF and the table above.

These results demonstrate that OccamLLM is capable of robust performance on large-scale models. Training the OccamLLM 70B system (in 16-bit precision and unoptimized code) required approximately 1.5-2 days on a system with two A100 nodes, demonstrating the low compute requirements of our method.

OccamLlama 70B shows consistent improvement over OccamLlama 8B. We believe this results from a combination of Llama 3 70B's improved reasoning capabilities and Llama 3 70B's improved representations (which enable OccamLlama to generalize more effectively). We expect that training with even larger base models would lead to further improvements. Remarkably, OccamLlama 70B outperforms GPT 4o and GPT 4o with Code on average across these benchmarks. It also outperforms GPT 3.5 Turbo on all but Single Eq.

Continued below

Dear Reviewer,

We are writing to provide updated results from our completed evaluation runs. Below, we show the final results for OccamLlama 70B. We note that OccamLlama 70B maintains its strong performance when tested on the complete datasets. It still outperforms both GPT 4o and GPT 4o with Code on average. It also improves substantially compared to the 100-datapoint performance estimate on Single Eq. OccamLlama outperforms GPT 3.5 Turbo on all datasets except Single Eq, where it is less than one percentage point behind and within error bars.

Above, we also include results from Llama 3 70B Instruct. OccamLlama 70B substantially outperforms Llama 3 70B on MultiArith Float and MATH401. It is roughly the same (1.3 percentage point deviation or less) as Llama 3 70B on all other datasets (ones with arithmetic simple enough for Llama to perform satisfactorily) except for GSM8K, which demonstrates OccamLlama's ability to not interfere with reasoning while still assisting with arithmetic. On average, OccamLlama 70B outperforms Llama 3 70B by nearly five percentage points, and OccamLlama 8B approximately matches Llama 3 70B's average performance.

We also provide the final table for the MGSM dataset:

We note that previously, there was a typo in this table. The averages were incorrect, incorrectly showing that OccamLlama had a larger performance drop than Llama on average. We apologize for any confusion. Our verbal statements in the rebuttal were correct, and Figure c) in the general rebuttal PDF had the correct averages for the previous data. Other than this typo, the table above closely resembles the previously reported table, so we do not comment further.

Thank you for your consideration.

Strengths:

S1) The proposed method offers some valuable advantages over existing approaches. It does not need to update the model weights and therefore will not suffer from catastrophic forgetting (like integrating LLM tools may), while being more computationally efficient than code generation which will require 2 stages and intermediate code that can be 50x longer.

S2) For single step arithmetic with 7-digit inputs, the OccamLLM is very robust and is always able to generate the correct answer, while the baseline LLama3 8B model struggles with these calculations.

S3) The use of an OccamNet is highly interpretable, as one can look at the predicted computational DAG, which can also be useful for interpreting why a calculation goes wrong when it does.

We appreciate your kind remarks!

Weaknesses:

W1) When applied to word-based mathematical reasoning problems, the system only performs better than its baseline (Llama3-8B) when high precision is required (e.g. MultiArith Float and MATH401) but otherwise performance is quite similar.

We acknowledge that the OccamLLM framework does not bring substantial improvements in general reasoning tasks that do not require challenging arithmetic. Indeed, the target of this system is to ensure that the arithmetic is performed correctly, as incorrect arithmetic disturbs the reasoning process of LLMs. It is expected that the improvements provided by this method are only prominent in tasks that require challenging arithmetic operations; otherwise, the LLM does require OccamNet and can sucessfully follow its natural reasoning path. The reasoning heavy-lifting is still performed by the LLM, and OccamNet assists it to ensure that the computations are accurate and the reasoning can proceed satisfactorily.

Since submitting to NeurIPS, we identified a few minor bugs in our code which were limiting performance and slightly reweighted the proportions of the different training datasets. These changes maintained the perfect performance on arithmetic tasks and improved performance on mathematical reasoning tasks. The updated results are shown visually in Figure a) of the global response PDF, and we also present them in the table below:

Table: Accuracy on reasoning tasks. Higher is Better.

Here, we see that OccamLlama outperforms even GPT 4o and GPT 4o with Code on benchmarks requiring challenging arithmetic (MultiArith Float and MATH401), areas where OccamLlama shines. Additionally, the gap between OccamLlama and LLama 3 8B is substantially smaller on GSM8K. On average, OccamLlama outperforms both Llama and GPT 3.5 Turbo, with accuracy approximately halfway between that of GPT 3.5 and GPT 4o.

We also find that the performance of OccamLlama on reasoning benchmarks improves dramatically as we increase the base model from Llama 3 8B to Llama 3 70B (OccamLlama 70B).

To ensure we had results in time for the rebuttal deadline, we sampled 100 random questions from each dataset to determine OccamLlama 70B's performance, which is the cause for the relatively large error bars. We will update this response with the full results once they complete. The results are shown visually in Figure d) of the global response PDF and are also presented in the table below:

Table: Accuracy on reasoning tasks. Higher is better.

These results demonstrate that OccamLLM is capable of robust performance on large-scale models. Training the OccamLLM 70B system (in 16-bit LLM precision and unoptimized code) required approximately 1.5-2 days on a system with two A100 nodes, demonstrating the low compute requirements of our method.

OccamLlama 70B shows consistent improvement over OccamLlama 8B. We believe this results from a combination of Llama 3 70B's improved reasoning capabilities and Llama 3 70B's improved representations (which enable OccamLlama to generalize more effectively). We expect that training with even larger base models would lead to further improvements. Remarkably, OccamLlama 70B outperforms GPT 4o and GPT 4o with Code on average across these benchmarks. It also outperforms GPT 3.5 Turbo on all but Single Eq.

Continued below

W2) The strongest results shown are for 1-step arithmetic, however considering this is a very simple set up and is matched with the training methodology. Whether the OccamNet generalises well to similar 1 step arithmetic when embedded in more complicated text-based questions, more similar to the results in section 4.2, is less apparent.

Thank you for your comment. We believe that the mathematical reasoning benchmarks provide experimental validation that OccamLlama can effectively handle more complicated text-based questions. These problems are multi-step math problems requiring multiple calls to OccamNet to be completed successfully. Given OccamLlama's strong performance on these benchmarks, we hope you will agree that OccamLlama can effectively handle compound expressions. We will make this clearer in the paper.

Regarding generalization, we find that OccamLlama displays remarkable generalization capabilities on out-of-distribution problems. To demonstrate this, we train the OccamNet decoder from scratch, using only numeric expressions and absolutely no text at all. This means that any problem with text, such as a word problem, is far out of distribution of the OccamNet decoder's training data. We test this model (using the standard router) on the mathematical reasoning benchmarks and obtain remarkably good results, shown visually in Figure b) of the global response PDF and presented in the table below. The OccamLlama 8B decoder trained only with numerical expressions performs on par with the model trained with both numbers and text, even achieving higher accuracy on some benchmarks. This shows that the OccamLLM framework is robust and points towards the fact that the representations of arithmetic that are built in the transformer body of the LLM and extracted by the OccamLLM Decoder are very general.

Table: Accuracy on reasoning tasks. Higher is Better.

In contrast, we expect that finetuning Llama to perform arithmetic using only numeric examples and no text whatsoever would lead to extreme catastrophic forgetting and poor arithmetic performance on word problems. As such, we believe this data shows a remarkable robustness of OccamLLM.

As a second example of generalization, we tested OccamLlama on the Multilingual Grade School Math Benchmark (MGSM), a dataset consisting of GSM8K translated into 10 languages (Bengali, Chinese, French, German, Japanese, Russian, Spanish, Swahili, Telugu, and Thai). We compute the drop in accuracy when switching from English to another language, given by the accuracy of a model on the English dataset minus the accuracy of the model on the dataset in a given language. For OccamLlama in Bengali and Telugu, due to time constraints, we evaluated on a subset of 100 and 50 randomly chosen problems, respectively. We will update the table below with the full results soon. We show the results in visually in Figure c) of the global response PDF and the table below:

Table: Accuracy drop on multilingual reasoning tasks. Lower is better.

Continued below

The table above shows that OccamLlama has on average a smaller performance drop than llama between the English dataset and the non-English language datasets. The fact that OccamLlama (the decoders for which have never been trained on other languages) has on average better out-of-distribution behavior than Llama (a model trained on over 750 billion tokens of non-English text) is in our opinion quite remarkable.

We believe that these two tests demonstrate OccamLlama's robustness against out-of-distribution data.

W3) As mentioned in the limitation, many of the results focus on single 1-step arithmetic problems, and although results for 2 and 3 step are still reasonable, there is performance degradation. I’d speculate that the code-based LLMs may not suffer from such issues.

Thank you for your interest in OccamLLM using a multi-layer OccamNet. We are exploring this direction in future work, and we believe we can train performant OccamLLM systems with a many-layer OccamNet. In the present paper, we simply wish to demonstrate the potential promise of using multiple-layer OccamNets.

We note that our existing methods are already capable of performing arbitrarily complex arithmetic by chaining simpler calculations. Existing language models are generally trained or prompted to reason step-by-step, meaning that their generation can often be supplemented by a single-layer OccamNet. This is evidenced by our reasoning benchmarks, in which OccamLlama (with a single-layer OccamNet) performs quite well across a wide range of tasks.

Additionally, we can further improve OccamLlama systems with single-layer OccamNets by finetuning and/or prompting the model to think step-by-step.

Questions:

How did you generate the training and evaluation dataset, and what templates were used? I’m aware that Appendix A.1 details split sizes and the type of questions, but are all the queries just the raw calculation, e.g. input=’1254+854’ (+ all the prompting such as putting ‘Answer:’ or requesting to give the response in decimals).

The training data follows the structure presented in Appendix A: one or several concatenated simple input-output pairs are passed to the model. For diversity, we use both unformatted inputs and data following the chat format in which Llama 3 8B Instruct was finetuned. In the case of the OccamNet decoder, we append "Answer = " at the beginning of the assistant response in the first round of training and leave it blank in the second round, as explained in Appendix A.1. The two examples below show the different cases. The ■ marks where the decoder is trained to initialize OccamNet based on the previous token to predict the right number.

Unformatted text:

242 - -47 = 289.0000

sqrt(82) = 9.0554

-7 + -10 = -17.0000

0.6531 + 0.4395 = 1.0926

log(8767.8356) = 9.0788

log(3553.0728) = 8.1756

cos(-4.4649) = -0.2450

sin(-7.5997) = -0.9678

cos(11.1069) = ■

** Formatted text with or without "Answer = ":

<|begin_of_text|><|start_header_id|>system<|end_header_id|>

<|eot_id|><|start_header_id|>user<|end_header_id|>

336.75 * 60.96 =<|eot_id|><|start_header_id|>assistant<|end_header_id|>

(Answer = )■

Although these two examples show numeric data points without text, the training dataset also includes word problems. We give examples of word problems in our Continuation of Rebuttal (2) for reviewer Z5Za.

For the evaluation datasets, we used the benchmarks described in the paper and included each question in the user prompt. The system prompts are as described in the paper.

We are very grateful for your comments and suggestions. We hope you will agree that the additional experiments and clarifications will strengthen our paper.

Dear Reviewer,

We are writing to provide updated results from our completed evaluation runs. Below, we show the final results for OccamLlama 70B. We note that OccamLlama 70B maintains its strong performance when tested on the complete datasets. It still outperforms both GPT 4o and GPT 4o with Code on average. It also improves substantially compared to the 100-datapoint performance estimate on Single Eq. OccamLlama outperforms GPT 3.5 Turbo on all datasets except Single Eq, where it is less than one percentage point behind and within error bars.

Above, we also include results from Llama 3 70B Instruct. OccamLlama 70B substantially outperforms Llama 3 70B on MultiArith Float and MATH401. It is roughly the same (1.3 percentage point deviation or less) as Llama 3 70B on all other datasets (ones with arithmetic simple enough for Llama to perform satisfactorily) except for GSM8K, which demonstrates OccamLlama's ability to not interfere with reasoning while still assisting with arithmetic. On average, OccamLlama 70B outperforms Llama 3 70B by nearly five percentage points, and OccamLlama 8B approximately matches Llama 3 70B's average performance.

We also provide the final table for the MGSM dataset:

We note that previously, there was a typo in this table. The averages were incorrect, incorrectly showing that OccamLlama had a larger performance drop than Llama on average. We apologize for any confusion. Our verbal statements in the rebuttal were correct, and Figure c) in the general rebuttal PDF had the correct averages for the previous data. Other than this typo, the table above closely resembles the previously reported table, so we do not comment further.

Thank you for your consideration.

Dear Reviewer,

We are writing to gently ask that you consider our rebuttal. We appreciate your thoughtful review and would greatly appreciate your further comments and thoughts.

Thank you,

The Authors

The idea of adding OccamLLM Decoders to LLM and using it to predict the weights of OccamNet for arithmetic tasks is novel. The paper is generally well-written.

We appreciate your kind remarks!

The improvements brought by OccamLLM on general reasoning tasks are limited. While OccamLlama outperforms Llama 3 8B on MultiArith Float and MATH401, it fails to bring meaningful improvements on all the other reasoning benchmarks.

Thank you for your comment. Since submitting to NeurIPS, we identified a few minor bugs in our code and slightly reweighted the proportions of the different training datasets. These changes maintained the perfect performance on arithmetic tasks and improved performance on mathematical reasoning tasks. The updated results are shown in Figure a) of the global response PDF and the table below:

Table: Accuracy on reasoning tasks. Higher is Better.

OccamLlama outperforms even GPT 4o and GPT 4o with Code on benchmarks requiring challenging arithmetic (MultiArith Float and MATH401). Additionally, the gap between OccamLlama and LLama 3 8B is substantially smaller on GSM8K. On average, OccamLlama has accuracy approximately halfway between that of GPT 3.5 and GPT 4o.

The performance of OccamLlama also improves dramatically when trained with Llama 3 70B, as discussed below.

It is unclear whether OccamLLM can consistently improve the arithmetic capabilities of larger models with 13B and 70B parameters.

Thank you for your comments. To demonstrate OccamLLM's ability to scale to larger models, we trained OccamLlama using Llama 3 70B Instruct as a base model (OccamLlama 70B). We evaluated the results on the mathematical reasoning benchmarks. To ensure we had results in time for the rebuttal deadline, we sampled 100 random questions from each dataset to determine OccamLlama 70B's performance, which is the cause for the relatively large error bars. We will update this response with the full results once they complete. The results are shown visually in Figure d) of the global response PDF and the table below:

Table: Accuracy on reasoning tasks. Higher is better.

These results demonstrate that OccamLLM is capable of robust performance on large-scale models. Training the OccamLLM 70B system (in 16-bit LLM precision and unoptimized code) required approximately 1.5-2 days on a system with two A100 nodes, demonstrating the low compute requirements of our method.

OccamLlama 70B shows consistent improvement over OccamLlama 8B. We believe this results from a combination of Llama 3 70B's improved reasoning capabilities and Llama 3 70B's improved representations (which enable OccamLlama to generalize more effectively). We expect that training with even larger base models would lead to further improvements. Remarkably, OccamLlama 70B outperforms GPT 4o and GPT 4o with Code on average across these benchmarks. It also outperforms GPT 3.5 Turbo on all but Single Eq.

What would be the performance of OccamLlama on GSM8K when using a two layer Complete OccamNet?

Thank you for your interest in OccamLLM using a multi-layer OccamNet. We are exploring this direction in future work, and we beleive we can train performant OccamLLM systems with a many-layer OccamNet. In the present paper, we simply wish to demonstrate the potential promise of using multiple-layer OccamNets.

We note that our existing methods are already capable of performing arbitrarily complex arithmetic by chaining simpler calculations. Language models are generally trained or prompted to reason step-by-step, meaning that their generation can often be supplemented by a single-layer OccamNet. This is evidenced by our reasoning benchmarks, in which OccamLlama (with a single-layer OccamNet) performs quite well across a wide range of tasks.

Additionally, we can further improve OccamLlama systems with single-layer OccamNets by finetuning and/or prompting the model to think step-by-step.

We are very grateful for your comments and suggestions. We hope you will agree that the additional experiments and clarifications will strengthen our paper.

Dear Reviewer,

We are writing to provide updated results from our completed evaluation runs. Below, we show the final results for OccamLlama 70B. We note that OccamLlama 70B maintains its strong performance when tested on the complete datasets. It still outperforms both GPT 4o and GPT 4o with Code on average. It also improves substantially compared to the 100-datapoint performance estimate on Single Eq. OccamLlama outperforms GPT 3.5 Turbo on all datasets except Single Eq, where it is less than one percentage point behind and within error bars.

Above, we also include results from Llama 3 70B Instruct. OccamLlama 70B substantially outperforms Llama 3 70B on MultiArith Float and MATH401. It is roughly the same (1.3 percentage point deviation or less) as Llama 3 70B on all other datasets (ones with arithmetic simple enough for Llama to perform satisfactorily) except for GSM8K, which demonstrates OccamLlama's ability to not interfere with reasoning while still assisting with arithmetic. On average, OccamLlama 70B outperforms Llama 3 70B by nearly five percentage points, and OccamLlama 8B approximately matches Llama 3 70B's average performance.

Thank you for your consideration.

The integration of OccamNet with LLMs for single-step arithmetic is a novel approach...

We appreciate your kind remarks!

Limited Novelty in Approach: The paper stitches two existing architectures together to solve confined arithmetic tasks. While this combination is innovative, it does not introduce entirely new methodologies or architectures. The novelty is more in the application than in the fundamental approach.

Thank you for your comment. We acknowledge that the two key architectures which we combine in our model are known. However, we contest that systems combining known architectures are often still novel. For example, speculative decoding uses known generative architectures but combines them in novel ways.

Additionally, we believe our method of combining the two architectures is creative and novel. To our knowledge, our work is unique in that we implement a decoder module which initializes the parameters of a second computational model at each autoregressive step. In our mind, this is closest to a hypernetwork, but unlike a hypernetwork we initialize OccamNet at each autoregressive step instead of just once per input.

We believe this step is quite novel. To use an analogy, if this same idea were used in the context of linear layers (i.e. using one linear layer to initialize another), one arrives at a model similar to attention. In the same way that we believe attention is sufficiently distinct from a linear layer to be considered novel, we believe that our method is sufficiently distinct from other gated computation methods to be considered novel.

Inadequate Justification for Methodology: The paper does not convincingly justify why the proposed methodology is preferable over existing methods such as code execution. The evaluation is extensive, but the practical advantages in terms of performance, computational efficiency, and real-world applicability are not fully established.

Thank you for your comments. We argue for the following advantages of OccamLlama over code generation or finetuning:

Fine-tuning

• No catastrophic forgetting: Fine-tuning risks catastrophic forgetting, especially since arithmetic training datasets likely contain very little text.
• Improved arithmetic: As shown in our arithmetic and mathematical reasoning benchmarks, even larger models such as GPT 4o fall short of OccamLLM for arithmetic more challenging than three-digit multiplication, so we also expect finetuned models to fall short of OccamLLM.

Code generation

• No catastrophic forgetting: Code generation generally requires fine-tuning an LLM to write and run code.
• Improved generation speed and cost: In the arithmetic benchmarks, we found that GPT 4o with code required on average more than 50 completion tokens, far more than the single autoregressive step required by OccamLlama to answer each question. Additionally, our total expenses for GPT 4o with code were more than double that of GPT 4o without code, even though we made almost 5 times fewer queries to GPT 4o with code. This suggests that OccamLLM would be faster and cheaper compared to code generation.
• Improved security: Running LLM-generated code is potentially unsafe. For example, the LLM could ask to run the python code __ import__('os').system('rm -rf /'). It is in general extremely challenging to check general-purpose code for malicious behavior. We believe that the two best solutions are 1) to run all code in an isolated virtual machine and 2) to run a restricted language that is not Turing-complete.
• Reduced engineering: Building a system that hosts an LLM and a sandbox to safely run code requires a high engineering effort.

We will make these points clearer in the paper.

Scalability and Generalization: The framework is tested on specific arithmetic tasks and reasoning problems, but its scalability to more complex, multi-step arithmetic problems in real-world applications remains uncertain. There is limited discussion on how the approach would handle more extensive and varied datasets.

Thank you for your comment. We believe that the mathematical reasoning benchmarks provide experimental validation that OccamLlama can effectively handle compound expressions. These are multi-step math problems requiring multiple calls to OccamNet. Given OccamLlama's strong performance on these benchmarks, we hope you will agree that OccamLlama can effectively handle compound expressions. We will make this clearer in the paper.

Since submitting to NeurIPS, we identified a few minor bugs in our code and slightly reweighted the proportions of the different training datasets. These changes maintained the perfect performance on arithmetic tasks and improved performance on mathematical reasoning tasks. The updated results are shown in Figure a) of the global response PDF and the table below:

Table: Accuracy on reasoning tasks. Higher is Better.

Continued below

As shown above, OccamLlama outperforms even GPT 4o and GPT 4o with Code on MultiArith Float and MATH401. Additionally, the gap between OccamLlama and LLama 3 8B is substantially smaller on GSM8K. On average, OccamLlama has accuracy approximately halfway between that of GPT 3.5 and GPT 4o.

We also find that the performance of OccamLlama on reasoning benchmarks improves dramatically as we increase the base model from Llama 3 8B to Llama 3 70B (OccamLlama 70B).

To ensure results in time for the rebuttal deadline, we sampled 100 random questions from each dataset to determine OccamLlama 70B's performance, resulting in the relatively large error bars. We will update this response with the full results once they complete. The results are shown visually in Figure d) of the global response PDF and the table above.

OccamLlama 70B shows consistent improvement over OccamLlama 8B and we expect that training with even larger base models would lead to further improvements. Remarkably, OccamLlama 70B outperforms GPT 4o and GPT 4o with Code on average. It also outperforms GPT 3.5 Turbo on all but Single Eq.

Security Concerns: The claim that the approach is more secure than code execution is made without detailed analysis. It's not clear why code execution is such a concern that warrants this new methodology. Moreover, there could be other vulnerabilities associated with using a symbolic architecture that are not addressed in the paper.

We note that security is only one of the reasons we believe OccamLlama is superior to code generation for arithmetic. Other reasons are provided above.

We describe the security risks of LLM code generation above. In contrast, OccamNet restricts the allowed computation to a prespecified set of options (function compositions up to a given depth). This means that, barring a preventable vulnerability in its implementation, OccamLlama is a secure system that does not allow for arbitrary code generation and the potential exploits that come with it.

Evaluation Metrics: The evaluation focuses heavily on accuracy, but other metrics such as computational efficiency, speed, and resource utilization are not thoroughly discussed. These factors are crucial for practical deployment and comparison with other methods.

Although we focus on accuracy, in the paper we also present relative error as a useful metric.

Regarding computational efficiency and speed, we demonstrate in the paper that GPT-4o with Code requires on average more than 50 times more autoregressive generations than OccamLlama to answer the single-arithmetic benchmarks. Since OccamNet and the decoders are negligibly small compared to a LLM, this demonstrates that, all else equal, OccamLlama should be significantly faster and more efficient than a LLM-code-generation-based approach to arithmetic.

Additionally, as noted above, we find that GPT 4o with Code is substantially more expensive than GPT 4o at answering the same questions. This further supports our claim that OccamLlama should be significantly faster and more efficient than a LLM-code-generation-based approach to arithmetic.

Because of how small OccamNet and the decoders are compared to a LLM, an optimized codebase should see comparable speed and resource utilization between OccamLlama and base llama.

Due to the closed nature of GPT 3.5 and GPT 4o, it is difficult to make more direct comparisons regarding speed, efficiency, and resource utilization. We hope that the above observations are sufficient to satisfy your concerns.

In short, I'm not convinced OccamLLM is relevant and why code execution is not superior.

We respectfully disagree. Above, we have outlined how OccamLLM is a novel and performant alternative to finetuning and code generation for LLM arithmetic. We believe OccamLLM's performance and the advantages listed above are compelling and provide sufficient motivation for the use of OccamLLM in practice.

How does OccamLLM perform on more complex, multi-step arithmetic problems in real-world applications?

We believe that the mathematical reasoning benchmarks provide experimental validation that OccamLlama can effectively handle more complex, multi-step arithmetic problems in real-world applications. These problems are multi-step math problems requiring multiple calls to OccamNet to be completed successfully. They are standard benchmarks for mathematical reasoning in LLMs. Given OccamLlama's strong performance on these benchmarks, we hope you will agree that OccamLlama can effectively handle real-world mathematical problems. We will make this clearer in the paper.

Could you provide a more detailed analysis of the security benefits and potential vulnerabilities of using OccamNet for arithmetic tasks?

We describe the security risks of OccamLlama and LLM code generation above.

We are very grateful for your comments and suggestions. We hope you will agree that the additional experiments and clarifications will strengthen our paper.

Dear Reviewer,

We are writing to provide updated results from our completed evaluation runs. Below, we show the final results for OccamLlama 70B. We note that OccamLlama 70B maintains its strong performance when tested on the complete datasets. It still outperforms both GPT 4o and GPT 4o with Code on average. It also improves substantially compared to the 100-datapoint performance estimate on Single Eq. OccamLlama outperforms GPT 3.5 Turbo on all datasets except Single Eq, where it is less than one percentage point behind and within error bars.

Above, we also include results from Llama 3 70B Instruct. OccamLlama 70B substantially outperforms Llama 3 70B on MultiArith Float and MATH401. It is roughly the same (1.3 percentage point deviation or less) as Llama 3 70B on all other datasets (ones with arithmetic simple enough for Llama to perform satisfactorily) except for GSM8K, which demonstrates OccamLlama's ability to not interfere with reasoning while still assisting with arithmetic. On average, OccamLlama 70B outperforms Llama 3 70B by nearly five percentage points, and OccamLlama 8B approximately matches Llama 3 70B's average performance.

Thank you for your consideration.

Dear Area Chairs,

We thank you for your consideration of our paper. We wish to provide a few clarifications we found to be particularly relevant based on our conversations with reviewers:

A recurring point of clarification concerned the advantages of OccamLLM over LLM code generation. We list key advantages of OccamLLM over code generation below:

• Improved generation speed and cost: LLM Code generation requires generating tokens for code, leading to the use of potentially many more tokens than are needed to respond to a query. This can make LLMs with code generation (unlike OccamLLM) slow and expensive. For example, in the arithmetic benchmarks, we found that GPT 4o with code required on average more than 50 completion tokens, far more than the single autoregressive step required by OccamLlama to answer each question. Additionally, our total expenses for GPT 4o with code were more than double that of GPT 4o without code, even though we made almost 5 times fewer queries to GPT 4o with code, suggesting that GPT 4o with code is approximately 10 times more expensive per query than GPT 4o. Since OccamLLM does not require any additional autoregressive steps of the LLM, this suggests that OccamLLM is faster and cheaper than code generation.
• Better results: The LLM code generation method we compared against, GPT 4o with Code Interpreter, actually performed worse than GPT 4o on average. We believe these results demonstrate that, for arithmetic, LLM code generation is not an optimal solution. OccamLlama 70B outperforms GPT 4o with code on our benchmarks, suggesting that OccamLLM provides a better solution.
• No catastrophic forgetting: Code generation generally requires fine-tuning an LLM to write and run code. This risks catastrophic forgetting.
• Improved security: Running LLM-generated code is potentially unsafe. For example, the LLM could ask to run the python code __ import__('os').system('rm -rf /'). It is in general extremely challenging to check code for malicious behavior. OccamLLM does not run arbitrary code, so it avoids these risks.
• Reduced engineering: For the reasons mentioned in the previous bullet, building a secure system for LLM code execution, such as by hosting an LLM and a sandbox to safely run code, requires substantial engineering effort. Users can simply download our OccamLLM models and run them; no engineering is required.

We wish to emphasize that, although it is commonly assumed (including among the authors prior to this work) that code generation can solve the problem of arithmetic in LLMs, our results show that GPT 4o + Code is worse on average on mathematical problem-solving benchmarks than GPT 4o. This suggests that, as of now, LLM code generation does not solve the problem of LLM arithmetic as well as one might expect. OccamLlama provides a performant alternative.

Regarding the OccamLLM switch, we agree with reviewers that adding a switch network is not novel, and we do not wish to claim otherwise. We argue that the novelty of our work lies in the initialization of a symbolic model by decoding the hidden states of a language model.

We need the switch in order to enable autoregressive generation, but the key point we want to show is that the OccamNet-decoder system can perform arithmetic correctly in a variety of contexts.

One concern of reviewers was that OccamLLM does not improve performance on math reasoning benchmarks. We agree that OccamLLM does not improve reasoning. At the same time, we would not expect a method for improving arithmetic to improve reasoning.

OccamLlama dramatically outperforms Llama across model sizes on MultiArith Float and MATH401 because these two datasets are the ones with challenging arithmetic that Llama cannot perform by itself. We would not expect OccamLlama to improve over Llama on problems where Llama can already perform the arithmetic, which is the case for the other benchmarks we tested. Instead, we see OccamLlama's competitive performance on benchmarks for which Llama already performs arithmetic well as a demonstration that OccamLlama is robust to a wide range of problems and is capable of being used in general mathematical problem-solving tasks.

We would like to thank the reviewers for their thoughtful comments. We appreciate their interest in our method for fast and exact LLM arithmetic. We believe OccamLLM is a novel development that has the potential to dramatically improve LLM applications to problems requiring extensive arithmetic. We would especially like to thank reviewer JtJz for agreeing with us and increasing their score to a 7 in response to our discussion.

Warmly,

The Authors.