TL;DR
Исследователи проверили четыре модели (GPT-4o, DeepSeek-V3, OpenAI o1, DeepSeek-R1) на трёх типах математических задач: умножение пятизначных чисел, квадратные уравнения, диофантовы уравнения. Вместо стандартных бенчмарков специально создали задачи, в которых LLM склонны ошибаться, и разобрали каждое решение по шагам с кодированием ошибок.
Главная боль: LLM регулярно ошибаются в базовой математике. Даже продвинутые модели дают сбой в простых вычислениях — то правильно умножат два пятизначных числа, то вдруг ошибутся в последнем шаге суммирования. Процедурные ошибки (арифметические промахи, опечатки в переносе цифр) оказались самыми частыми и сильно били по итоговой точности. Концептуальные ошибки (непонимание принципов) встречались реже, но тоже присутствовали. Интересный эффект у DeepSeek-R1: модель "overthinking" — слишком много думает, крутится на месте в рассуждениях и упускает суть, хотя reasoning-версия должна быть лучше базовой.
Решение: Dual-agent конфигурация — два LLM обсуждают задачу как коллеги. Один предлагает решение, другой проверяет, они обмениваются аргументами и находят ошибки друг друга. Это резко повышает точность: GPT-4o в одиночку решил 2 из 30 задач на умножение, а в паре с другой моделью — 14 из 30. DeepSeek-V3 на диофантовых уравнениях подскочил с 21/30 до идеальных 30/30. Reasoning-модель o1 и так показала почти безупречную точность, но даже она выигрывает от коллаборации.
Схема метода
SINGLE-AGENT:
Один LLM → задача → пошаговое решение → финальный ответ
DUAL-AGENT:
LLM-1 → предложение решения
↓
LLM-2 → критика, вопросы, альтернативы
↓
Обсуждение → взаимная проверка → доработка
↓
Консенсусное решение
Каждое решение разбивается на шаги и кодируется:
- CC (Conditionally Correct) — шаг правильный
- PE (Procedural Error) — арифметическая ошибка, опечатка
- CE (Conceptual Error) — непонимание концепции
- IE (Impasse Error) — тупик, не знает как продолжить
Пример применения
⚠️ Ограничения метода: Dual-agent не волшебство для всех задач. Наибольший эффект на средне-сложных вычислительных задачах, где нужна проверка. На простых задачах ("столица Франции") избыточен. На сверхсложных может уйти в спор без результата.
Задача: Оцениваешь две бизнес-идеи для нового EdTech-проекта в России. Обе идеи проработаны, нужно понять финансовую модель и риски. Одна идея — платформа для корпоративного обучения в ритейле, вторая — мобильное приложение для подготовки к ЕГЭ с ИИ-репетитором. У каждой свои юнит-экономика, LTV, CAC, срок окупаемости. Нужно чтобы LLM не просто посчитали, а нашли ошибки в моих расчётах и дырки в логике.
Промпт для GPT-4o + Claude (через отдельные чаты):
Чат 1 (GPT-4o):
Ты финансовый аналитик EdTech-проектов. Вот две бизнес-идеи с финансовыми моделями:
[вставить описание идей, таблицы с CAC, LTV, прогнозами]
Разбери по шагам:
1. Проверь арифметику во всех расчётах
2. Оцени реалистичность предположений (конверсия, retention, стоимость привлечения)
3. Найди слабые места в логике и риски
4. Дай рекомендацию какую идею развивать
Работай медленно, показывай каждый шаг проверки.
Чат 2 (Claude):
Ты критик бизнес-планов в EdTech. Вот две идеи и их финансовые модели:
[вставить те же данные]
Твоя задача — найти ошибки в расчётах и дыры в рассуждениях, которые пропустил другой аналитик.
Вот его анализ:
[вставить ответ из Чата 1]
1. Проверь все вычисления заново — найди арифметические ошибки
2. Оспорь предположения — что может быть слишком оптимистично?
3. Укажи риски, которые он не учёл
4. Скажи где согласен, а где его логика хромает
Будь дотошным. Не жалей критики.
Результат: Увидишь две версии анализа — одна оптимистичная, другая критическая. GPT-4o покажет пошаговые расчёты по каждой модели с выводами. Claude проверит эти расчёты, найдёт арифметические промахи (например, GPT-4o может ошибиться в процентах при расчёте LTV) и укажет на неучтённые риски (высокая конкуренция в ЕГЭ-сегменте, зависимость от сезонности). Ты получишь два мнения, которые взаимно проверяют друг друга, плюс понимание где модели расходятся в оценках — это сигнал копнуть глубже.
Почему это работает
LLM плохи в арифметике потому что предсказывают токены, а не считают. Модель видит "47823 × 56912" и пытается угадать ответ на основе паттернов из обучающих данных, а не выполнить вычисление. В многозначных числах это приводит к процедурным ошибкам — модель "помнит" алгоритм умножения столбиком, но может сбиться на этапе сложения частичных произведений или перепутать разряды. Результат: решение выглядит правильным, а финальная цифра — нет.
LLM сильны в рассуждениях и проверке логики. Когда модель разбирает чужое решение, она работает на своей сильной стороне — анализирует текст, ищет несоответствия, задаёт вопросы. Dual-agent использует это: первая модель генерирует решение (где может ошибиться в арифметике), вторая критикует и перепроверяет шаги. Если первая ошиблась в сумме, вторая это заметит потому что пересчитает по-другому.
Рычаги управления:
Число моделей в паре → можно взять 3-4 модели для консенсуса, но дороже и медленнее. Для большинства задач двух достаточно.
Роли агентов → "аналитик + критик" острее чем два безликих агента. Дай одному роль оптимиста, другому — скептика. Конфликт ролей создаёт продуктивную дискуссию.
Порядок взаимодействия → можно запустить обе модели одновременно на одну задачу, потом сравнить решения. Или последовательно: первая решает, вторая критикует, первая исправляет. Зависит от сложности задачи.
Условие выхода → определи когда остановиться. Варианты: (а) консенсус ("обе модели согласны"), (б) фиксированное число раундов (2-3), (в) качественная проверка ("хотя бы одна нашла ошибку").
Шаблон промпта
Для single-agent (базовый):
Реши задачу: {задача}
Работай пошагово:
1. Распиши что дано и что нужно найти
2. Выбери метод решения
3. Выполни каждый шаг медленно, показывай промежуточные результаты
4. Проверь арифметику в каждом шаге
5. Дай финальный ответ
После решения сам себя проверь: пройдись по шагам и найди возможные ошибки.
Для dual-agent (продвинутый):
Промпт для первой модели (Аналитик):
Ты опытный {роль_эксперта} с 10-летним стажем.
Задача: {описание_задачи}
Дай развёрнутое решение:
1. Сформулируй проблему своими словами
2. Разбей на подзадачи
3. Реши каждую подзадачу пошагово — показывай все вычисления
4. Проверь свои расчёты
5. Дай финальный ответ с кратким обоснованием
Работай медленно, не торопись. Точность важнее скорости.
Промпт для второй модели (Критик):
Ты критик и проверяющий эксперт в области {домен}.
Задача была: {описание_задачи}
Вот решение от коллеги:
{решение_от_первой_модели}
Твоя работа — найти ошибки:
1. Перепроверь все вычисления — считай заново, не полагайся на чужие цифры
2. Оспорь логику — есть ли пропущенные шаги или неверные предположения?
3. Укажи слабые места в рассуждениях
4. Если найдёшь ошибки — исправь их и покажи правильное решение
5. Если решение верное — подтверди это явно
Будь дотошным. Не соглашайся просто так — проверяй каждый шаг.
Заполнить:
{задача}/{описание_задачи}— твоя конкретная задача (вычисление, анализ, оценка){роль_эксперта}/{домен}— профессиональная роль (финансовый аналитик, математик, инженер){решение_от_первой_модели}— копируешь ответ из первого чата
🚀 Быстрый старт — вставь в чат:
Вот шаблон dual-agent метода для математических задач. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит: "Какая у тебя задача?", "Какую роль взять первой модели?", "Нужны ли специфические критерии проверки?" — потому что для dual-agent важно правильно распределить роли и настроить взаимодействие. Модель возьмёт паттерн из шаблона и адаптирует под твой контекст.
Ограничения
⚠️ Стоимость и время: Dual-agent это два полноценных запроса. Дороже и медленнее чем single-agent. Для простых задач ("столица Франции") избыточно. Оправдано на средне-сложных вычислительных задачах.
⚠️ Не панацея от всех ошибок: Dual-agent снижает частоту ошибок, но не гарантирует идеальную точность. Обе модели могут ошибиться в одном месте. На задачах с умножением пятизначных чисел GPT-4o в паре улучшился с 2/30 до 14/30 — это хорошо, но всё ещё не 30/30.
⚠️ Reasoning-модели дороже: OpenAI o1 показала почти идеальную точность в single-agent, но стоит дороже GPT-4o. Dual-agent c базовыми моделями иногда дешевле чем o1 в одиночку, при сопоставимой точности.
⚠️ "Overthinking" у некоторых моделей: DeepSeek-R1 в исследовании зациклилась на рассуждениях — слишком много думала и теряла фокус. Это риск для reasoning-моделей: избыточная рефлексия может навредить.
Как исследовали
Команда взяла четыре модели — две базовые (GPT-4o, DeepSeek-V3) и две с усиленными рассуждениями (o1, DeepSeek-R1) — и дала им 30 задач трёх типов (по 10 задач каждого типа, три прогона): умножение пятизначных чисел, квадратные уравнения из текстовых условий, диофантовы уравнения. Задачи специально создавали сложными для LLM, используя item models (шаблоны задач с переменными) — чтобы избежать утечки из бенчмарков и реально проверить способности.
Каждое решение разобрали на шаги и закодировали: правильный шаг (CC), процедурная ошибка (PE), концептуальная ошибка (CE), тупик (IE). Кодирование делала o1, потом проверял эксперт. Интересно: o1 согласовалась с человеком на уровне κ = 0.737 (substantial agreement), а GPT-4o только на 0.366 (fair) — более умная модель надёжнее оценивает шаги в чужих решениях.
Почему пришли к dual-agent? Single-agent показали разброс: o1 почти не ошиблась, DeepSeek-V3 крепко, GPT-4o слабее. Тогда проверили dual-agent — две модели обсуждают задачу через чат. И вот здесь взлетело: GPT-4o в паре решил 14 из 30 задач на умножение вместо 2 из 30 соло. DeepSeek-V3 на диофантовых уравнениях дошёл до идеальных 30/30 с 21/30. Ключевой инсайт: коллаборация работает потому что модели взаимно проверяют и ловят ошибки друг друга, как в человеческих командах.
Удивительно: DeepSeek-R1, reasoning-версия, хуже базового DeepSeek-V3 на задачах умножения (4 против 28 правильных). Модель "overthinking" — слишком рефлексировала, крутилась на промежуточных шагах, упускала суть. Это противоречит ожиданиям (reasoning должен улучшать), но показывает: больше рассуждений ≠ лучше результат, если модель теряет фокус.
Процедурные ошибки (PE) доминировали — LLM ошибались в арифметике, переносе разрядов, суммировании частичных произведений. Концептуальные (CE) были реже. Это значит: модели понимают алгоритм, но сбиваются в исполнении — как студент, который знает формулу, но делает опечатку в расчётах.
Оригинал из исследования
Контекст: Исследователи создали рубрику кодирования шагов решения (Table 1 в статье) для систематической оценки ошибок. Эта рубрика применима не только в исследованиях, но и для анализа собственных промптов — можешь использовать эти категории чтобы понять где LLM сбивается.
Step Code Definitions:
CC (Conditionally Correct): A step that demonstrates procedural and conceptual accuracy, controlling for any errors that may have occurred on previous steps.
PE (Procedural Error): A step that contains one or more transcription errors, arithmetic mistakes, or symbolic manipulation errors, but without underlying conceptual misunderstanding.
CE (Conceptual Error): A step demonstrating one or more incorrect applications or misunderstandings of relevant math concepts or principles. It may include misunderstanding the problem, representing it incorrectly, or committing reasoning errors between steps.
IE (Impasse Error): A step where the solver is unable to proceed further logically or mathematically, indicating a critical gap or blockage in problem-solving understanding.
Промпт для single-agent (из методологии):
Solve this problem step-by-step. Show all intermediate calculations and reasoning. After providing your solution, verify your work by checking each step for potential errors.
Адаптации и экстраполяции
💡 Адаптация для code review:
Dual-agent отлично работает не только в математике, но и в проверке кода. Первая модель пишет функцию, вторая ищет баги, уязвимости, неэффективные участки.
Чат 1 (Разработчик):
Напиши на Python функцию для парсинга CSV с обработкой ошибок. Файл может содержать:
- Пропущенные значения
- Кириллицу с разными кодировками
- Строки с неправильным числом колонок
Покажи код и объясни как обрабатываешь каждый edge case.
Чат 2 (Code Reviewer):
Вот функция от коллеги:
[вставить код из Чата 1]
Проверь:
1. Логические ошибки — есть ли сценарии когда код упадёт?
2. Обработка исключений — все ли edge cases покрыты?
3. Производительность — где можно оптимизировать?
4. Читаемость — есть ли запутанные места?
Укажи конкретные строки и предложи исправления.
Эффект: Первый чат выдаёт рабочий код, второй находит упущенные edge cases (например, что будет если файл пустой, или если встретится emoji в данных). Взаимная проверка снижает риск багов.
🔧 Техника: "Оптимист vs Пессимист" → острее критика
Замени нейтральные роли ("аналитик" и "критик") на противоположные характеры. Это создаёт конструктивный конфликт.
Чат 1 (Оптимист):
Ты оптимист, который видит потенциал. Оцени эту бизнес-идею:
[описание идеи]
Найди сильные стороны, перспективы роста, почему это может выстрелить.
Чат 2 (Пессимист):
Ты скептик, который ищет риски. Вот оценка оптимиста:
[вставить из Чата 1]
Разбей на части:
- Где он преувеличивает?
- Какие риски упустил?
- Что пойдёт не так в реальности?
Будь жёстким — твоя задача найти дыры.
Почему работает: Явные роли (оптимист vs пессимист) заставляют модели тянуть в разные стороны. В нейтральной паре ("аналитик + критик") вторая модель может быть слишком мягкой. С ролями-антагонистами критика острее.
🔧 Техника: Добавь явный счётчик шагов → прозрачность
LLM часто пропускает промежуточные шаги. Заставь модель нумеровать и комментировать каждый шаг.
Реши задачу: {задача}
Работай так:
Шаг 1: [название шага] — [что делаешь] → [результат]
Шаг 2: [название шага] — [что делаешь] → [результат]
...
Шаг N: Финальный ответ → [ответ]
После каждого шага пиши "✓ проверено" если уверен в правильности.
Эффект: Явная нумерация дисциплинирует модель — она не может пропустить шаг или соединить два шага в один. Проверочные галочки "✓" заставляют модель рефлексировать после каждого действия.
Ресурсы
Mathematical Computation and Reasoning Errors by Large Language Models Liang Zhang (University of Memphis, AI4STEM Education Center at University of Georgia) и Edith Aurora Graf (Educational Testing Service)
Датасет и код доступны: https://github.com/LiangZhang2017/math_number_computing
Статья принята на AIME-Con 2025 (Artificial Intelligence in Measurement and Education Conference), Pittsburgh, Pennsylvania.
