Entry tags:
ИИ и формализмы
"Transformers Can Do Arithmetic with the Right Embeddings"
https://neurips.cc/virtual/2024/poster/94565
LLMов научили арифметике, как я понимаю, через специальное кодирование чисел. Это интересный трюк, поскольку у обычных ЛЛМов даже счет не получается, и да у людей научиться арифмерике занимает годы. Так что интересно с точки зрения понимания, как оно работает.
Но одновременно у меня возникает вопрос (который, как оказалось, авторам этой бумаги в голову не пришел): накойхер их учить арифмерике, если у них есть под боком компьютер, который может посчитать все то же самое легко и эффективно? Гораздо более продуктивным занятием было ты научить ЛЛМы пользоваться калькулятором. В простейшем варианте, добавить поспроцессинг к выводу ЛЛМа, который выцепит и выполнит вычислительные инструкции, и научить ЛЛМ генерить эти инструкции. Ну вот например, недавно народ активно рассуждал про "посчитать буквы r в слове strawberry". Это задание можно поделить на две части: (1) выцепить буквы r, (2) посчитать их. ИИ мог бы генерить что-то типа
$(wc r r r)
и получить на выходе 3. Ну и то же самое с любой арифметикой.
Интересно, какие возражения такая идея вызывает у учоных: "но ведь разрешать выполнение питонного кода из вывода - небезопасно". То, что можно сделать не Питон, а любой свой безопасный язык, им просто в голову не приходит. На лицо еще один признак большого разрыва между Машинными Учоными и Компьюторными Учоными.
А вот еще интересен такой момент: я спрашивал в разных местах, и у всех генерация машинного кода искусственным интеллектом просиходит совершенно от балды этого ИИ. Но ведь машинный код - формальный язык. Грамматика и семантика его известна. Ничего не мешает генерировать сразу согласно грамматике - проверять каждую следующую лексему на соответствие грамматике, и если соответстие не найдено, то ее отбрасывать и выбирать другую, следующую по весу. Может полученный код и не будет правильно работать, но как минимум всегда будет соответствовать грамматике, и с небольшими дополнительными проверками - компилироваться. В одном из мест я видел примеры кода, сгенерированного моделями различной сложности, с качеством, растущим со сложностью модели. Но простая формальная проверка должна поднять качество кода, сгенерированного даже простыми моделями.
https://neurips.cc/virtual/2024/poster/94565
LLMов научили арифметике, как я понимаю, через специальное кодирование чисел. Это интересный трюк, поскольку у обычных ЛЛМов даже счет не получается, и да у людей научиться арифмерике занимает годы. Так что интересно с точки зрения понимания, как оно работает.
Но одновременно у меня возникает вопрос (который, как оказалось, авторам этой бумаги в голову не пришел): накойхер их учить арифмерике, если у них есть под боком компьютер, который может посчитать все то же самое легко и эффективно? Гораздо более продуктивным занятием было ты научить ЛЛМы пользоваться калькулятором. В простейшем варианте, добавить поспроцессинг к выводу ЛЛМа, который выцепит и выполнит вычислительные инструкции, и научить ЛЛМ генерить эти инструкции. Ну вот например, недавно народ активно рассуждал про "посчитать буквы r в слове strawberry". Это задание можно поделить на две части: (1) выцепить буквы r, (2) посчитать их. ИИ мог бы генерить что-то типа
$(wc r r r)
и получить на выходе 3. Ну и то же самое с любой арифметикой.
Интересно, какие возражения такая идея вызывает у учоных: "но ведь разрешать выполнение питонного кода из вывода - небезопасно". То, что можно сделать не Питон, а любой свой безопасный язык, им просто в голову не приходит. На лицо еще один признак большого разрыва между Машинными Учоными и Компьюторными Учоными.
А вот еще интересен такой момент: я спрашивал в разных местах, и у всех генерация машинного кода искусственным интеллектом просиходит совершенно от балды этого ИИ. Но ведь машинный код - формальный язык. Грамматика и семантика его известна. Ничего не мешает генерировать сразу согласно грамматике - проверять каждую следующую лексему на соответствие грамматике, и если соответстие не найдено, то ее отбрасывать и выбирать другую, следующую по весу. Может полученный код и не будет правильно работать, но как минимум всегда будет соответствовать грамматике, и с небольшими дополнительными проверками - компилироваться. В одном из мест я видел примеры кода, сгенерированного моделями различной сложности, с качеством, растущим со сложностью модели. Но простая формальная проверка должна поднять качество кода, сгенерированного даже простыми моделями.
no subject
no subject
Если задать тот же вопрос, но по другому основанию (не 10, а например 7 или -7), фразы "visualize in my head" в ответе нет. Ответы тоже правильные и тоже получены двумя разными способами (через десятичное приближение и дробями). И все рассуждения в ответе правильные. Оно даже проверяет, нет ли где переноса.
Вряд ли в обучающей выборке был точно такой же пример.
no subject
Я как-то слушал лекцию человека, работающего над Лламой, и он рассказал, что у них в тренировках есть ОЧЕНЬ много специальных случаев, к котороым постоянно добавляют по мере обнаружения примеров того, что работает неправильно.
no subject
Как вы сформулируете запрос к внешнему вычислителю посчитать 0.1+0.2-0.3 по основанию -7? Я вот так навскидку не знаю синтаксис и функции стандартных библиотек в известных мне языках программирования для выполнения вычислений с отрицательным основанием.
Этот пример придуман мной вчера на ровном месте. Я очень удивлюсь, если где-то в обучающей выборке он есть. Если не верите, придумайте самостоятельно оригинальный вопрос и задайте его.
Также обратите внимание на то, что в десятичной базе r1 возвращает точный ответ, а внешний вычислитель на питоне делает это с ошибкой округления.
no subject
"Точный ответ" может быть в частности результатом округления:
$ python
>>> 0.1+0.2-0.3
5.551115123125783e-17
>>> "%f" % (0.1+0.2-0.3)
'0.000000'
Но, опять же, ничего не мешает считать без перевода в двоичную систему, а прямо в заданной базе. Что вроде бы bc тоже делает. Например:
$ bc
scale=20
0.1+0.2-0.3
0
Объяснение порядка вычисления выглядит в ответе очень похоже на объяснение синтаксического дерева после разбора выражения.
no subject
bc не умеет, говорит "Runtime warning (func=(main), adr=6): negative ibase, set to 2".
Округление не исправляет ошибку, а только прячет её. Надо использовать recursive real arithmetic.
no subject