Тестирование LLM по решению проблем Leetcode в 2025 году

Год назад, мой бенчмарк показали, что большие языковые модели (LLM) могут решать задачи алгоритмического кодирования на Leetcode. Однако их возможности были ограничены подмножеством известных, «популярных» задач. Новые задачи, которые никогда не были частью их обучающих наборов данных, представляли трудности. В то время как самые простые в основном решались моделями, самые сложные оставались недостижимыми.

С тех пор Open AI, Anthropic и Google выпустили улучшенные версии своих моделей, и появились новые игроки, такие как Deepseek и xAI. Многие модели теперь позиционируются как способные писать код, чего раньше не было. Я намерен сравнить эти самые современные LLM, чтобы выяснить, улучшилась ли их способность решать новые алгоритмические проблемы или нет.

Мотивация

Существуют контрольные показатели для оценки способностей магистров права в области программирования.

SWE-скамья сосредоточен на решении реальных проблем программного обеспечения – он основан на проблемах Github существующих проектов с открытым исходным кодом. Это действительно блестящая идея, но она охватывает слишком много вещей помимо фактического решения алгоритмических проблем, на котором я фокусировался.

Кодфорс бенчмарки лучше отражают алгоритмические навыки решения проблем LLM. OpenAI протестировал модели o1 и o3 на задачах Codeforces и поделился подробными результатами ( 1 , 2 ), а другие конкуренты — нет. Это сделало прямое сравнение невозможным.

Это привело к созданию нового бенчмарка, позволяющего проводить прямое сравнение LLM. И, в конце концов, почему бы не сделать это просто ради развлечения?

Эталонный дизайн

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

1. Загрузите описание проблемы.
2. Создайте подсказку из описания.
3. Генерация кода с помощью LLM.
4. Отправьте код для проверки.
5. Ждите результатов.

Эти шаги должны быть выполнены для каждой проблемы в нашем тестовом наборе и для каждого LLM. Для простоты есть только одна попытка для LLM написать код для каждой проблемы, без какой-либо обратной связи для повторения для улучшения решения. Все проблемы рассматриваются как независимые; контекст между ними не делится.

Почему Leetcode?

Leetcode оказался хорошим выбором для сравнительного анализа по нескольким причинам:

• Задачи Leetcode используются в реальных собеседованиях на должности инженеров-программистов.
• Студенты, изучающие информатику, учатся решать подобные задачи в ходе обучения.
• В нем есть онлайн-судья, который может проверить правильность решения за считанные секунды.
• Поддерживаются многие популярные языки программирования.
• Также доступны данные о работе пользователя-человека по этой проблеме.

Как работает Leetcode

Если вы никогда не имели дела с конкурентным программированием или решением алгоритмических задач, вот краткое объяснение. Ознакомьтесь с этим примером описания задачи:

 Given an array of integers numbers and an integer target, return indices of the two numbers such that they add up to the target. You may assume that each input would have exactly one solution, and you may not use the same element twice.  You can return the answer in any order.

Программисту-участнику необходимо написать фрагмент кода, который решает эту проблему. Для начала есть «фрагмент» — незавершенная функция с именем и аргументами, но пустым телом:

 class Solution: def twoSum(self, nums: List[int], target: int) -> List[int]:   # your code here

Обычно в описании приводится несколько примеров входных и выходных данных (тестовых случаев):

 Input: nums = [2,7,11,15], target = 9 Output: [0,1]

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

У каждой проблемы есть «скорость принятия», отношение принятых решений, представленных пользователями Leetcode. Обратите внимание, что один пользователь может отправлять свой код неограниченное количество раз, и каждая попытка учитывается в скорости принятия.

Эти правила не были придуманы Leetcode; они уже давно широко используются на конкурсах по информатике.

Наборы данных

Как и в предыдущем тесте, я хотел протестировать LLM на двух наборах задач:

• «Известные» проблемы не только давно опубликованы, но и чаще всего используются в интервью по программному обеспечению — поэтому их решения широко доступны.
• «Невидимые» проблемы, которые были опубликованы недавно, и их решения, вероятно, не были замечены тестируемыми LLM.

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

Leetcode предлагает три списка проблем: "Top interview 150" , "Leetcode 75" и "Top 100 Liked" . Мой набор данных "известных" проблем объединяет эти списки, в общей сложности 134 проблемы после исключений, упомянутых выше.

Для «невидимых» проблем я выбрал 99 из последних опубликованных проблем: 33 легкие, 33 средние и 33 сложные. Новизна определялась на основе идентификаторов проблем, которые являются инкрементными. Хотя Leetcode не отображает дату публикации проблем, ее можно приблизительно определить по комментариям и обсуждениям. Самые ранние из этих «невидимых» проблем, скорее всего, были опубликованы около ноября 2024 года.

Уровни сложности являются чисто субъективными и оставлены на усмотрение редакторов. Я не намеревался сопоставлять количество задач для каждой сложности или набора данных.

Постановки задач и фрагменты кода были получены с помощью моего инструмента для сравнительного анализа, опубликованного на Github: https://github.com/whisk/leetgptsolver

Подсказка, выбор языка и генерация кода

Тест был разработан следующим образом: LLM делает только одну попытку сгенерировать код без какой-либо предварительной информации о проблеме (или любых других проблемах) и без знания своих тестовых случаев, за исключением тех, которые были в самом описании. Не существует механизма для предоставления обратной связи или улучшения кода после его генерации.

Я использовал одну и ту же подсказку для каждой программы LLM и каждой задачи:

 Hi, this is a coding interview. You will be given: * A problem statement (with sample test cases if available). * A starter code snippet (with fixed function signatures). Please write your solution in the {language} programming language. Your code must: * Solve the problem fully and correctly. * Pass all provided sample test cases. * Run within acceptable time and memory limits (assume large inputs if none are specified). * Follow good coding practices (clear logic, readable structure, appropriate use of language features). Here is the problem statement: {question} Here is the code snippet, which you should expand with your solution: {snippet} Important Requirements: * Do not change any provided function signatures, class names, or method names. * Output only valid source code that can be executed as-is, without any further improvements or bugfixes. * Do not include docstrings, markdown, or commentary in your final code. Good luck!

Подсказка была «отполирована» с помощью ChatGPT4 из моего первого черновика, но без внедрения каких-либо методов «инжиниринга подсказок».

Перед использованием в подсказке описание проблемы было очищено от HTML-тегов.

В качестве языка программирования я выбрал Python (версия 3).

LLM-ов попросили выводить только рабочий код без предшествующего текста, но во многих случаях это было не так. Была реализована базовая очистка, и все, кроме фактического кода, было удалено и не отправлено.

Модели и параметры

Модели, используемые в бенчмарке, перечислены в таблице ниже, со всеми указанными нестандартными параметрами. Даты отсечения знаний берутся из официальной документации поставщика и предоставляются для справки, если они известны.

Целью бенчмарка было сделать его максимально детерминированным и воспроизводимым; поэтому использовались такие параметры, как «температура» или «семя». Однако ни одна из протестированных моделей не гарантирует полностью детерминированный вывод. Этот фактор следует учитывать при повторном запуске этих тестов.

Все известные даты отсечения знаний более ранние, чем самая старая проблема в известном наборе данных (ноябрь 2024 г.). Однако я не смог найти даты отсечения для семейств моделей Gemini и DeepSeek.

Некоторые модели поддерживают режимы "рассуждения" или "мышления" по умолчанию, тогда как для Claude 3.7 Sonnet их можно включить, передав параметры. Использование этой функции указано в таблице. Другие функции модели (или "инструменты"), такие как веб-поиск, не были включены, даже если поддерживались.

Результаты

Все конкуренты показали очень высокие показатели принятия на известных проблемах, как и в предыдущем бенчмарке. Я не тестировал превосходные модели или модификации (а именно: Claude 3.7 Sonnet с включенным рассуждением, DeepSeek R1, Gemini 2.5 Pro, O1) для экономии времени и кредитов, поскольку результаты были весьма предсказуемыми.

Результаты для «невидимых» проблем разительно отличаются в двух аспектах:

1. Для всех моделей процент принятия ниже для "невидимых" проблем . Это особенно заметно для средних и сложных проблем.
2. Модели с включенным режимом «рассуждения» или «мышления» показали лучшие результаты при решении задач всех уровней сложности, хотя точные цифры варьировались от модели к модели.

Значительно более высокие показатели принятия для известных проблем можно объяснить возможностью того, что эти проблемы и их решения были частью обучающих наборов, и модели должны были только воспроизвести известное правильное решение. Однако уровень принятия пользователями новых средних и сложных проблем также ниже, чем для проблем из «хорошо известного» набора. Этот случай трудно количественно оценить, и это не обязательно означает, что новые проблемы «сложнее». Оценка сложности, как упоминалось ранее, весьма субъективна. И, как и в случае с самими LLM, пользователи-люди могут предоставлять известные правильные решения для известных проблем.

Все модели с включенным режимом «рассуждения» значительно превзошли своих базовых аналогов. Что самое важное, некоторые из них смогли решить значительную часть средних и сложных задач — недостижимое достижение всего год назад. Среди всех моделей «рассуждения» лучшие результаты показала o3-mini — она показала себя даже лучше, чем гораздо более дорогая и медленная o1. Следует отметить, что o3-mini был специально обучен для решения задач конкурентного программирования. Однако я воздержусь от вывода о том, какая модель лучше подходит для решения алгоритмических задач, поскольку это сильно зависит от бюджета токена, а также следует учитывать задержку и стоимость.

Будущие соображения

Невозможно гарантировать, что «невидимые» наборы задач не были включены в данные обучения моделей. Чтобы решить эту проблему, мы можем рассмотреть возможность создания новых, уникальных задач, специально разработанных для будущих бенчмарков — конечно, с использованием LLM.

Кроме того, еще одна стратегия заключается в использовании менее распространенных языков программирования. Этот подход может потребовать от LLM разработки решения, а не «копирования-вставки» известного правильного кода, написанного на Python.

Эти идеи требуют дальнейшего изучения, и я надеюсь, что кто-то другой или я сам сможем в них углубиться.

Ссылки

• Исходные результаты, наборы задач и исходный код можно найти на моем GitHub: https://github.com/whisk/leetgptsolver
• Результаты моих предыдущих тестов (2024 г.): https://hackernoon.com/testing-llms-on-solve-leetcode-problems

Изображение на обложке создано DALL·E.