To CoT or not to CoT? Chain-of-thought helps mainly on math and symbolic reasoning Сначала авторы статьи производят мета-анализ, беря 516 статей с "CoT" в тегах, уфильтровывают выборку до 110 статей и рисуют на графике 1218 экспериментов, пытаясь понять, где, на каком домене и сколько докинул CoT по сравнению с прямым промптингом. Такой мета-анализ показывает, что больше всего качество докидывается на тех вопросах, где для получения ответа можно применить какую-то символьную логику: математику, формальную, etc. Например, на коде или математике (MATH, GSM8k, BBH) качество сильно растёт, а на commonsense reasoning, language comprehension и QA (HotpotQA, Winogrande, ARC-Challenge) повышения качества практически нет, кое-где качество даже падает. Отличить вопросы, где CoT докинет качества, оказалось достаточно просто — если в вопросе используется символ "=", то скорее всего тут используется символьная логика и качество после CoT вырастет, если не используется, то не вырастет. Что забавно, они пытались найти более надёжный способ определить, используется ли символьная логика и у них не удалось. Слишком мощный признак получился. Потом они решили перепроверить это наблюдение самостоятельно и замерили популярные открытые модели и попробовали воспроизвести результаты статей из мета-анализа. Всё воспроизвелось, и выяснилось, что CoT может ограниченно добавить качества в тех бенчах, где используется логика вперемешку с commonsense reasoning. Например, в MuSR, где описывается сцена с преступлением и модели надо найти виновника, качество при использовании CoT улучшилось, но не слишком сильно. Самая интересная часть статьи, имхо, последняя: они замерили, насколько сильно помогают разные варианты промптинга и сравнили их с внешними тулами в разных вариантах задач. Авторы рассмотрели пять разных сетапов: 1. Few Shot Direct Answer — просто спрашиваем у модели во фьюшоте что она думает по поводу задачи. 2. Chain of Thought — классический CoT без особых изысков. 3. Plan + Direct Solver — генерим моделью план (например, в виде программы на питоне для математики) и промптим модель сказать, что получится в конце этого плана. 4. Plan + CoT Solver — генерим моделью план, а потом по нему идём в режиме CoT, прося модель проговаривать каждый шаг исполнения плана. 5. Plan + Tool Solver — генерим моделью план, а потом передаём его во внешнюю программу, например, в репл питона или SMT-солвер, которые уже выдают ответ. Получилось, что CoT это такое слабоватое (но универсальное) приближение внешнего солвера, использование которого почти на всех сетах сильно улучшало метрики. Исключения — тыщу раз протёкший в трейн GSM8k и FOLIO, который, видимо, достаточно сложный для моделей. Какие мы можем сделать из этого выводы: - Языковые модели в текущем их виде ненадёжны и использование простого советского Z3 влёгкую обходит сота модели по качеству исполнения уже написанного и корректного плана. - CoT действительно помогает моделям улучшить метрики на некоторых бенчмарках, в основном, про математику или формальную логику. - CoT абсолютно бесполезен для фактоидной точности моделей. Paper: https://arxiv.org/abs/2409.12183