Compositional Reasoning with Transformers, RNNs, and Chain of Thought
Gilad Yehudai, Noah Amsel, Joan Bruna
TL;DR
The paper analyzes the expressive power of transformers, RNNs, and transformers augmented with chain-of-thought tokens for Compositional Reasoning Questions (CRQ). By linking problem hardness to architectural capabilities, it shows depth-$L$ transformers can solve CRQs up to size $n$ with bit-precision $O(\log n)$, while constant-depth transformers are $\NC^1$-hard via a BFEP reduction. It further proves that shallow RNNs can solve CRQs under favorable input orders with hidden-dimension $O(d\log n)$, but any ordering demands at least $\Omega(\log n)$ hidden-state capacity in general, and it demonstrates that shallow transformers with chain-of-thought tokens can also solve CRQs with constant depth. Altogether, the results reveal complementary strengths and trade-offs across architectures for compositional reasoning tasks.
Abstract
We study and compare the expressive power of transformers, RNNs, and transformers with chain of thought tokens on a simple and natural class of problems we term Compositional Reasoning Questions (CRQ). This family captures problems like evaluating Boolean formulas and multi-step word problems. Assuming standard hardness assumptions from circuit complexity and communication complexity, we prove that none of these three architectures is capable of solving CRQs unless some hyperparameter (depth, embedding dimension, and number of chain of thought tokens, respectively) grows with the size of the input. We also provide a construction for each architecture that solves CRQs. For transformers, our construction uses depth that is logarithmic in the problem size. For RNNs, logarithmic embedding dimension is necessary and sufficient, so long as the inputs are provided in a certain order. (Otherwise, a linear dimension is necessary). For transformers with chain of thought, our construction uses $n$ CoT tokens. These results show that, while CRQs are inherently hard, there are several different ways for language models to overcome this hardness. Even for a single class of problems, each architecture has strengths and weaknesses, and none is strictly better than the others.
