AI++

FrontierMath: A Benchmark for Evaluating Advanced Mathematical Reasoning in AI

Самый сложный бенчмарк по математике для LLM от Epoch AI. Если сейчас зачастую у новых наборов проблем передовые нейронки решают 30-50% задач, то в этом суммарно все они, от Grok-2 до o1-preview, решили... 4 задачи (каждая по отдельности меньше 2% от общего числа). Почему? Потому что для создания задач были привлечены одни из ведущих математиков в своих областях, более 60 штук — 14 из них обладают золотыми медалями международной олимпиады по математике, и один обладатель Филдсовской премии (угадайте кто).

Задачи покрывают почти все топики современной математики, и некоторые из них строятся на совсем недавних открытиях и исследованиях. Самой главной проблемой, мешающей LLM'кам справляться с задачами, авторы называют экстремальную ограниченность в тренировочных данных для отдельных техник/тем. Terence Tao сказал, что «релевантные данные практически не существуют. Мы говорим о примерно десятке статей с релевантными вещами». Причём, они везде очень разные — суммарно авторы насчитали около 200 уникальных техник, применяемых в решениях, при этом самые часто встречающиеся пары техник попались всего лишь в 3 задачах (то есть нет концентрации вокруг каких-то техник, освоим которые можно решить добрую часть проблем).

Однако у бенчмарка есть пара недостатков:
1) задачи были сделаны таким образом, чтобы их можно было автоматически проверять; это сразу же накладывает ограничения на формат и гибкость. В частности, не проверяется ход решения (но угадать ответ практически нереально).
2) список задач не включает в себя доказательства, ответом является формула или число/набор чисел.
3) из-за сложности задач и времени, необходимых на решение не автору (несколько часов, и то не всегда справляются), не проводилась перепроверка решений и ответов каждой задачи, и не замерялось качество «усреднённого» математика. Аналитику провели по 25 задачам и прикинули, что ошибок не более 10%.

Эксперименты: авторы написали средней длинны промпт, который подсказывает модели, в каком формате ожидаются ответы, и что можно попробовать сделать отправку кода несколько раз. Если происходит ошибка — модели дают обратную связь, и процесс продолжается до тех пор, пока не будет достигнут лимит в 10'000 токенов. Модели ведут себя по разному, например o1-preview в среднем делает 1.29 попыток ответить, а Grok 2 — 3.81. Лимит токенов тоже немного мешает — gpt-4o упиралась в него в 45% решений, а ведь это даже не o1 с её длинными цепочками рассуждений.

From Naptime to Big Sleep: Using Large Language Models To Catch Vulnerabilities In Real-World Code

В июне я писал про Naptime, проект по применению LLM в кибербезопасности от Google. С тех пор проект эволюционировал в Big Sleep (😄), коллаборацию с Google DeepMind для более масштабной работы. Проект всё ещё находится на исследовательской стадии, и авторы использовали в основном маленькие программы с известными уязвимостями для оценки прогресса. А потом решили позапускаться на реальных программах, которые каждый день используют миллионы программистов.

В рамках анализа одного из недавних изменений исходного кода SQLite автоматический LLM-агент (если не поняли что это — надо почитать предыдущий пост) на основе Gemini-1.5-Pro обнаружил эксплуатируемое переполнение буфера в стеке. Причём ошибка была лишь отдалённо связана с конкретно этими изменениями (большая часть причины, как я понял, оставалась за рамками изменений, но была невозможно без их внесения) — что не редкость при обычном ручном анализе вариантов. Исследователи даже подметили, что «в этом случае логи рассуждения немного напоминают работу человека — начиная с одной идеи, обдумывая несколько других в ходе исследования, и в конце создавая тестовый пример, который вызывает немного другую, но всё же ошибку»

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

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

Если я правильно понял, что имели в виду в блогпосте, то Gemini не отпускали просто на все 4 стороны: ей подавали на вход разные ошибки, которые уже удавалось отловить (в этом же репозитории или хоть где? не ясно), и говорили «Такая вот ошибка уже была; возможно, где-то есть еще одна похожая». Это позволяет сузить задачу от общей («найди любой код с уязвимостями») и задать направление вместо полного перебора всех возможных идей.

Баг был не самый простой для автоматического отлавливания традиционными методами. Обычно используют fuzzing, это когда в функцию или программу подают огромное количество случайных значений в некотором интервале и смотрят, не сломалось ли чего при тех или иных условиях. По идее, если дать достаточно времени, то подобная ошибка с определённой комбинацией условий могла бы найтись; однако используя официальный гайд по тестированию от самих SQLite за 150 CPU-часов и миллионы перебранных комбинаций уязвимость не выскочила, и скорее всего оставалась бы незамеченной долгое время.

А LLM не устают. Они могут читать и рассуждать гораааааздо быстрее и дольше кожаных аналогов. Ждём следующего большого поста, где Google'овцы заявят, что нашли 10-100 других багов пачкой, без ручного вмешательства.

И еще про маленькие LLM-модельки

Тут решили проверить, что будет если последние Qwen 7b, Gemma 2b и Llama 8b попросить сгенерировать 100 раз случайного человека и описать его день, в итоге получилось такое:

🔄 Все модели чаще всего выбирали для истории женщин, от 25 до 35 лет; Llama3 вообще один раз про мужчину написала;

🔄 Gemma чаще всего называла персонажей… «Anya Petrova» (интересно, из какой части интернета брали датасет), Llama3 «Emilia Garcia» и Qwen «Li Wei»

🔄 Gemma чаще все придумывала как место действий – Россию (☕️), llama – Японию, а Qwen – Шанхай

🔄 Gemma и llama чаще выбирали профессией персонажей – Фриланс дизайн, а Qwen аж 72 раза – разработку софта

По ссылке выше больше деталей, включая сравнение распорядков дня персонажей