Хотите знать, какая нейросеть лучше генерирует код для 3D‑анимации или пишет научный реферат? Мы сравнили ChatGPT o3 Pro, Gemini 2.5 Pro, Claude Opus 4 и DeepSeek R1-0528 в двух примерах: создание веб‑презентации (анимированные алгоритмы сортировки) и подробное исследование о системах беспилотных авто.

Кто справился с анимацией? Чей код запустился? Чей текст — как TED Talk на бумаге? Смотрите тесты, сравнивайте Codepen‑примеры и делайте выводы. (Спойлер: победил не o3 Pro!)


Часть 1
Часть 2


Признаюсь, подобрать соперников для тестов было непросто — модель действительно мощная. В итоге в оппоненты я позвал свежих чемпионов: Gemini 2.5 Pro (недавно обновился и уже везде в топах — мимо не пройдёшь), Claude Opus 4 (самое крутое и умное от Anthropic на сегодня — вдобавок к 3.7 Sonnet) и DeepSeek R1-0528 (последнее обновление, которое в некоторых бенчмарках даже обходит Grok 3 — пришлось напрячь голову, кого выбрать из этих двоих). Все трое недавно получили серьёзные апдейты — значит, должны быть в форме!

Как проводилось тестирование: я исследовал модели в агрегаторе BotHub, где разные нейромодели доступны в едином интерфейсе. Если зарегистрироваться здесь, можно забрать 100 000 бесплатных токенов.

Тест 1: визуализация сортировок

Одна из основ программирования, с которой сталкивается каждый новичок, — это алгоритмы сортировки. Часто их изучение даётся тяжело: чтобы понять, как они работают, нужно хорошо развитое абстрактное и визуальное мышление. Мало просто представить структуру — нужно мысленно отслеживать, как элементы меняются во времени, шаг за шагом. Вот я и решил: а почему бы не сделать интерактивную веб‑презентацию, которая показывала бы работу этих алгоритмов в реальном времени?

Промт выглядел так:

Создай интерактивную веб‑страницу‑презентацию (одним HTML‑файлом), которая будет показывать различные алгоритмы сортировки. Презентация может быть двухмерной или трёхмерной. Сортируемые элементы можно показать в виде кругов или шаров, на которых написаны номера или буквы, отражающие их порядок в случае успешной сортировки. Кроме того, шары могут быть окрашены градиентно (при этом «минимальный» и «максимальный» элементы имеют два разных цвета, а промежуточные цвета рассчитываются пропорционально).

Пусть фон будет чёрным, а схемы и надписи разноцветные. Добавь различные эффекты (напр., сияние, переливание цвета, эффекты частиц, анимированное изменение формы шаров с учётом инерции), которые подчеркнут те или иные алгоритмические состояния или переходы. В некоторых способах сортировки группы элементов могут передвигаться одновременно, если это предполагается алгоритмом.

Пусть в презентации будет 5–10 анимированных слайдов, показывающих разные алгоритмы. Кроме графической визуализации, на слайде должно быть краткое описание алгоритма. Каждый алгоритм должен показывать полный цикл сортировки. При завершении сортировки появляется краткое сообщение об этом, а затем демонстрация текущего алгоритма начинается заново. Пусть изначальный порядок определяется случайным образом.

Слайды листаются кнопками, расположенными в левой нижней части экрана. В случае если презентация трёхмерная, можно вращать камеру левой кнопкой мыши, панорамировать правой и изменять масштаб колёсиком. Добавьте движок‑слайдер в углу экрана, который регулирует скорость анимации.

Актуальные ссылки на библиотеки (при необходимости):
https://cdnjs.cloudflare.com/ajax/libs/three.js/r128/three.min.js
https://cdn.jsdelivr.net/npm/three@0.128.0/examples/js/controls/OrbitControls.js
https://cdnjs.cloudflare.com/ajax/libs/tween.js/18.6.4/tween.umd.js

ChatGPT o3 Pro

Кстати, результаты удобнее смотреть в новой вкладке — жмите средней кнопкой мыши по Result или Edit with CodePen. (Песочница CodePen не всегда доступна без VPN, а нормального российского аналога я, увы, не нашёл — JSFiddle тоже давно заблокирован.)

Важный момент этой демки: цифры на шариках показывают изначальную позицию, а цвета — тот самый финальный, отсортированный порядок, к которому алгоритм и стремится.

Алгоритмов здесь шесть: пузырьком, выбором, вставками, быстрая, пирамидальная, слиянием. Но... корректно работает только самый первый. Причём если переключиться на другой алгоритм и вернуться обратно — даже он ломается.

Обнаружил мелкий CSS‑косяк: у контейнера div#ui не было height: 100%, а внутри него расположены кнопки переключения слайдов и ползунок скорости (у них стояло bottom). В итоге оба элемента улетели вверх, потому что контейнер был нулевой высоты и свойство bottom считалось фактически от его верхнего края. Починил, задав позиционирование через top (исправление уже внесено в CodePen).

И да — код почему‑то обрезался в конце, не хватило пары строк. У o3 Pro, как я заметил во время тестов, привычка так делать — ещё один повод выбрать для сложного кодинга другую модель.

DeepSeek R1-0528

Версия 0528 — ещё не R2, но уже и не R1. Сначала думал, Opus 4 выдал самый объёмный код (29 431 символ, ~861 строка), но нет: в выводе DeepSeek R1-0528 — 35 279 символов и ~988 строк.

Браузер отобразил трёхмерную сцену, но остальное почти что не запустилось. Проблемы:

  • Цифры на шариках были зеркально отражены по горизонтали и дополнительно перевёрнуты на 180°.

  • Анимация не стартовала автоматически. Кнопки «Старт» нет, ошибок в консоли — тоже. Просто тишина.

  • При попытке запустить любой алгоритм один шарик дёргался, пытаясь начать, но тут же вылетала ошибка про yield.

Вывод: нынешние DeepSeek‑модели, видимо, не заточены под сложный кодинг. Лучше доверить такое Claude или Gemini. Идём дальше!

Claude Opus 4

А вот это уже почти то, что задумывалось!

Здесь аж 8 алгоритмов: пузырьком, вставками, выбором, быстрая, слиянием, Шелла, пирамидальная, поразрядная. Но корректно работают только первые четыре. Возможно, и последние три тоже, но как только включаешь сортировку слиянием — всё ломается, шары слипаются намертво, анимации для остальных алгоритмов сбиваются и даже возврат к предыдущим слайдам не помогает. Похоже, промт требует серьёзной доработки под такие сценарии.

Как и у Gemini 2.5 Pro (о нём ниже), переключение слайдов здесь возможно только после полного завершения анимации текущего алгоритма (когда висит надпись «Сортировка завершена!»).

Порядковые номера на шарах почему‑то не отображаются. Цветовая схема использует больше двух цветов в градиентах, но это даже плюс — так проще визуально оценить правильность сортировки. Правда, некоторые цветовые переходы выглядят резковато — видимо, особенность человеческого восприятия.

Самое крутое здесь (как опять же у Gemini) — дополнительные визуализации: подсвечиваются сравниваемые элементы, что критично для понимания работы алгоритма. По завершении сортировки — бонус: все шары синхронно подпрыгивают волной.

Gemini 2.5 Pro

Ещё один фаворит этого теста, наравне с Opus 4.

Как в случае o3 Pro, не обошлось без CSS‑косяков. У интерфейсного контейнера div#ui‑overlay стояло pointer‑events: none — из‑за этого кнопки были полностью нефункциональны (видимо, Gemini подразумевал, что свойство будет динамически меняться, но не реализовал это). После ручного исправления (поставил pointer‑events: auto) кнопки заработали... только вновь в короткие паузы между проходами сортировки.

Но вылезли новые проблемы:

  • Камеру вращать нельзя — интерфейс перекрыл canvas, реагирующий на мышь.

  • При смене слайда анимация не перезапускается, а пытается продолжиться с прошлого состояния.

  • Надпись «Отсортировано!» с предыдущего слайда не исчезает и всё время висит поверх визуализации.

  • Сама идея ждать окончания сортировки для переключения — неудобна (хотя у Opus 4 та же беда, тут я решил не закрывать глаза).

Поэтому я просто попросил Gemini исправить все обнаруженные недочёты:

Увы, интерфейс остался недоступным. А если его вновь «пробить» и переключить слайд вручную — начинается хаос: старый алгоритм не останавливается, и теперь работают два (возможно, и больше!) одновременно.

Пишем Gemini снова:

Скрытый текст

И ещё раз:

Скрытый текст

Решил остановиться. Честно? Проще вернуться к версии от Opus 4 и доработать её — она качественнее.


Что ж, параллельно анимировать кучу элементов, отслеживая их состояния, да ещё и на 5–8 слайдах, — задача нетривиальная, требующая тонны переменных и проверок.

Лучший результат в этом тесте показал Claude Opus 4. Правда, с сортировкой слиянием визуализация ломается. Надо уточнить промт: визуализировать слияние иначе (шары не должны наслаиваться друг на друга, алло, мы не в 4D‑пространстве!), а также гарантировать сброс состояния шаров при смене слайда.

Тест 2: реферат о беспилотных авто

Изначально промт был короче, но я решил его усложнить. Кажется, немного перестарался, зато теперь никто не скажет, что он не подходит для проверки o3 Pro.

Опишите процесс восприятия и навигации окружающей среды беспилотным автомобилем 4-го или 5-го уровня автономности. Упомяните:

1. Сенсорный комплекс:
• Типы сенсоров (LiDAR, радары, камеры, ультразвук, GPS/IMU), их технические характеристики (дальность, точность, FOV), физические принципы работы и ограничения (погода, освещение), комплементарность.
• Проблемы слияния данных (например, рассинхронизация при 60 км/ч).

2. Алгоритмы машинного обучения:
• Опишите архитектуру нейросетей для обработки сенсорных данных:
— CNN для детекции объектов (транспорт, пешеходы) и семантической сегментации дороги.
— Трансформеры для анализа временных последовательностей (трекинг объектов).
— GRU/LSTM для прогнозирования поведения участников движения.
• Детализируйте обучение моделей: датасеты (Cityscapes, KITTI), методы аугментации, loss‑функции (например, focal loss для дисбаланса классов).
• Как решается проблема edge cases (редкие сценарии) через симуляции и генеративные модели?

3. Принятие решений:
• Иерархию: стратегическое (маршрут), тактическое (обгон), оперативное (экстренное торможение).
• Модель POMDP (partially observable Markov decision process) для неопределённости.
• Объясните, как мультимодальная система компенсирует слабые места отдельных сенсоров (например, fusion‑лидара и камеры для работы в тумане).
• Пошагово опишите конвейер:
— Локализация: SLAM (LiDAR‑SLAM vs. Visual‑SLAM) + коррекция GPS/IMU.
— Построение карты: HD‑mapping с аннотацией дорожных элементов (разметка, знаки).
— Планирование пути: глобальное (A*/Dijkstra на графе дорог); локальное (модель предсказания траекторий с использованием POMDP или обучения с подкреплением).
— Контроль: ПИД/MPC‑регуляторы для управления рулением и скоростью.
• Как система обрабатывает конфликтные ситуации (этический аспект)? Приведите пример trolley problem для беспилотника.

4. Критические аспекты:
• Как система обрабатывает edge cases (например, детский мяч, выкатившийся на дорогу)?
• Этические дилеммы в рамках ISO 26262 (риск для пассажиров и пешеходов).

5. Безопасность и валидация:
• Архитектура резервирования (fail‑operational‑системы).
• Методы тестирования: симуляции (CARLA), тестовые полигоны, shadow mode.
• Как обеспечивается соответствие стандартам ISO 26262 и SOTIF?

6. Ограничения:
• Почему снегопад > 5 см/час — проблема для LiDAR?
• Как решается проблема «синдрома белого грузовика» (white truck syndrome)?

Требования:
• Ответ должен включать формулы только где это критично (например, уравнение для расчёта uncertainty‑радара).
• Избегать чрезмерно абстрактных описаний в пользу конкретных технических решений (напр., как HD‑карты интегрируются с SLAM).
• Уровень детализации: достаточный для защиты магистерской диссертации по робототехнике.

Визуальные аналогии: объясните сложные концепции через метафоры.

Объём реферата — 15 000 символов.

ChatGPT o3 Pro: глубина

Скрытый текст

ChatGPT o3 Pro впечатляет технической глубиной, но текст больше похож на конспект лекции, технический отчёт или рассуждение LRM‑модели, чем на реферат. Видимо, слишком детальная структура промта сподвигла модель «вываливать» знания без заботы о связности и плавности.

Также не соблюдён объём — из 15 000 символов здесь только 5960.

Ну а в рамках дискурса «Теперь я знаю, что это не кривой вывод нейросети, а слово действительно есть в русском» не забудем упомянуть «робастность» — отдельный плюс!

DeepSeek R1-0528: структура и аналогии

Скрытый текст

DeepSeek R1-0528 берёт сложные концепции и упаковывает их в чёткие блоки с подзаголовками и маркерами. Техническая основа крепкая, формулы там, где критично. Отлично объясняет комплементарность сенсоров («радар не различит пешехода и столб»).

Однако объем здесь тоже не соблюдён — 5811/15 000 символов. Ну, и вследствие этого иногда чувствуется некоторая поверхностность в угоду краткости и структуре. Как шпаргалка или первое погружение — неплохо.

Claude Opus 4: лаконичность и практичность

Скрытый текст

Объём тоже недотянул: 6315 символов из 15 000.

Текст Claude Opus 4 доступно объясняет, как разрешаются трудности, при этом подача краткая, но читаемая. Технических деталей меньше, чем у o3 Pro, зато читается легче и понятнее.

Gemini 2.5 Pro: читаемость и контроль объёма

Скрытый текст

Gemini 2.5 Pro — чемпион по читаемости и управлению объёмом. Он мастерски балансирует между глубиной и доступностью, используя живые, запоминающиеся метафоры («цифровая нервная система», «эхолокация летучей мыши + зрение орла»), идеально соответствует запрошенному объёму (16 874 символов — даже с небольшим запасом). Отлично объясняет, почему что‑то важно (например, проблему рассинхронизации сенсоров и её последствия при расхождении 0,83 м).


Итак, Gemini 2.5 Pro стал чемпионом по балансу и читабельности. Он мастерски уложился в запрошенный объём, сохранив при этом высокую информативность и техническую корректность. Его главный козырь для большинства пользователей — контроль объёма без потери качества и высокая ясность изложения. Если нужен реферат «как для людей», но без потери техносути — это самый разумный выбор!


Джулиан Голди дал чёткий гайд, как выжимать максимум из o3 Pro за 200 $:

  • Применяй для сложной математики;

  • Используй в продвинутых научных исследованиях;

  • Бросай на сложные конкурсные задачки по коду;

  • Доверяй задачам, где нужна глубокая аналитика;

  • Простые вещи отдавай обычному o3 (он дешевле на 80%!).

Итоги тестов: o3 Pro не стал фаворитом — в коде он обрезал вывод, в текстах уступил Gemini по читаемости. Победители сегодняшних тестов: для глубоких, но понятных текстов — Gemini 2.5, для кодинга — тоже он, а также Claude Opus.

Пока что лично я не могу с точностью понять, для чего больше подходит o3 Pro. Судя по экспериментам в сети, сила этой модели — в решении сложных (но не гигантских) математических и алгоритмических задач с чёткими условиями. Это «тяжёлый профинструмент» для спецов. Для повседневных же задач удобнее более лёгкие версии, вроде 4o, 4.1 и o3.

P. S. Первая часть обзора o3 Pro была здесь.

Комментарии (1)


  1. Kamil_GR
    16.06.2025 11:15

    Замечания по промптам:

    ПРОМПТ 1 (Визуализация сортировок):

    • Переспецификация: избыточные технические детали ограничивают модели

    • Конфликтные требования: "5-10 слайдов" + "полный цикл" для каждого = огромная сложность

    • Отсутствие приоритизации: не ясно, что важнее - корректность или визуализация

    • Недооценка сложности: синхронизация 8 алгоритмов требует enterprise-архитектуры

    • Требование "одним файлом" для сложной 3D-анимации нереалистично

    ПРОМПТ 2 (Реферат):

    • Информационная перегрузка: 6 блоков с множественными подпунктами

    • Противоречивые требования: "формулы только где критично" vs детальная техника

    • Нереалистичный объем: 15,000 символов для такого охвата невозможен качественно

    • Академическая псевдоточность: создает видимость научности без реальной пользы

    Предложения по улучшению:

    Для визуализации:

    1. Итеративный подход: начать с одного алгоритма, постепенно добавлять

    2. Разделить задачи: сначала корректность, потом красота

    3. Убрать технические ограничения типа "одним файлом"

    4. Четко приоритизировать: что критично, что желательно

    Для реферата:

    1. Разбить на части: каждый блок отдельным промптом

    2. Реалистичные объемы: 3000-5000 символов за раз

    3. Итеративная сборка: от общего к частному

    4. Операционализировать критерии: что значит "достаточный для диссертации"

    Общие принципы:

    • Одна задача - один промпт

    • Тестировать на простом, усложнять постепенно

    • Избегать противоречивых требований

    • Измеримые критерии вместо субъективных

    • Учитывать ограничения архитектуры модели