А чего это вдруг я? Ваша тема с RSA, вот и начинайте. У меня есть слово "Если" в начале предложения. Вот если вам так интересно далее продолжать этот бессмысленный спор, ушедший от темы статьи, то начните, найдите алгоритм, где требуется гарантия простоты числа. А потом уже будет моя очередь доказывать свою часть аргументации.
Но простоту числа, необходимую для работы RSA, он всё ещё гарантировать не может
И не должен. Это не его работа. Если алгоритм шифрования требует гарантию простоты числа, то очевидно, там есть алгоритм, который гарантирует простоту числа. А этот алгоритм нужен, чтобы быстро отбрасывать заранее составные числа и не запускать основной в цикле перебора.
Вы не пониаете, о чём я говорю. Я говорю о том, что наша отрасль работает на гарантиях. Код работает на гарантиях. Алгоритмы работают на гарантиях. Вы приводите тест Миллера-Рабина, как алгоритм, не дающего гарантии, а я говорю, что он гарантию даёт. Поэтому он полезен, как классический алгоритм с false positive. Алгоритм, дающий гарантию простоты числа может написать любой школьник (ну может утрирую). Алгоритм ДЁШЕВО отбрасывающий заранее некорректные результаты намного сложней.
Об этом речь. Алгоритм Миллера-Рабина работает не "практически всегда". Он всегда работает.
Вроде умные мысли говорит, но при этом пытается сделать из промпта полноценную замену. Я говорю "промпт", потому что вижу, что этот язык не является полной и исчерпывающей спецификацией, то есть позволяет множественную трактовку, равно как естественный язык. А если является, то как его синтаксис может быть в 5-10 раз короче?
Я не понимаю, как он собирается решать две основные проблемы.
Первая и самая главная: недетерменированость. Из одного и того же "исходника" получаются разные кодовые базы классического языка. Это делает невозможным итеративные улучшения, это делает невозможным багфикс (ну просто потому что сегодня баг есть, завтра нет и наоборот, и всё это с одним и тем же "исходником").
Вторая проблема: контекстное окно. Если раньше, когда вдруг оказывалось, что 640кб не хватает всем для компиляции, то покупалась плашка памяти за $100 и приводились исходники в порядок. Бедные страдали со свопом, но компилировали. А для увеличения контекстного окна вдвое надо построить новый дата-центр, потому что зависимость ну ни разу не линейная. А контекстное окно нужно обязательно, потому что проект планируется перегенерировать полностью и если ваш исправленный промпт не лезет в окно, то в окно пойдёте вы.
Тест Миллера-Рабина гарантирует, что число составное. У него два ответа: "составное" и "не знаю". Давайте заканчивать с софистикой.
Детерминированный алгоритм вполне может выдать число, которое мы посчитаем случайным. Остаток от деления атомов на 10 в песчинке плюс сколько наносекунд кричала чаечка.
Это всё лирика. В один момент детерминизм алгоритмов остаётся технически детерминизмом, но на практике становится случайным. Где-то специально случайность добавляют, усиливают и используют далее в разветвлении алгоритма. Например в ЛЛМ. Которая детерминированная.
Вы же не будете мои слова выдирать из контекста? Мы говорили про разницу в промпте и коде. Выполнение кода детерминировано, промпта - нет.
Там ещё было про гарантии и это была ключевая фраза. "Почти всегда" - это отсутствие гарантии.
Собственно, вам ответили, что вероятностный алгоритм - всё ещё алгоритм. Он делает вывод случайным (в идеале), но сама выдача является детерминированной, потому что является целью алгоритма. Как-то так.
То есть алгоритм шифрования совершенно детерминировано выдаёт случайное число. По хорошему, должна быть какая-то гарантия случайности. Ну там, дисперсии всякие, отклонения и всё такое.
В разработке мы используем одни гарантии, чтобы предоставить другие. Построить сложную систему, которая будет гарантировать конечному пользователю свою работу.
Если хоть одна часть в нижележащих слоях не может гарантировать свою работу, то вся система рушится, как карточный домик.
Гарантия - это всё. Нет гарантии - нет алгоритмов. Нет кода. Нет ПО как класса.
Ну хотите - посмотрите мои комменты 16-17 года. Там этого эм-даш - навалом. Ну пишу я так. Поменял привычку с приходом ЛЛМ, теперь ставлю короткие тире.
В производстве ПО должно быть по другому, потому что код и есть штучный товар. Если проводить аналогию, то код - чертёж, ПО - результат построения по чертежу. Само ПО ничего не стоит, потому что компилятор наштампует его в любом количестве, а вот код - это дорого, очень дорого. Потому что R&D, вот почему.
А ещё потому что код долгоживущий. И чем дольше код живёт, тем больше с него прибыль. И тем сложнее его дорабатывать. А дорабатывать надо, потому что "нужно очень быстро идти, чтобы оставаться на месте". Качество кода - это не прихоть, это суровая необходимость рыночных реалий. Бездумный код может обрушить весь бизнес под тяжестью техдолга. Это не какие-то страшилки, это случается регулярно.
Соглашусь полностью. И добавлю, что декларативные языки, хоть и дают детерминированный результат, но страдают от недетерминированности времени выполнения. Вот это самое "О большое". Именно поэтому существует EXPLAIN, который показывает, что и в каком порядке будет выполняться в конкретно этом случае.
А я соглашусь с тем, что компиляторы C++ пишут бредовый и неоптимальный машинный код, который невозможно поддерживать. Правда тут аж два нюанса. На плюсах разработка сильно проще и быстрее, чем на асме. Процессоры становились сложнее, команд больше а тонкости применения прямо лавиной хлынули, смывая призрачную надежду справиться с этим своей головой. Ассемблер Z80 это вообще не то же самое, что ассемблер x86-64 со всеми avx512 и уровнями кэша.
Второй нюанс в том, что C++ остался детерминированный. Он из одного и того же кода делает один и тот же машинный код. Его поведение полностью предсказуемо. Это снимает необходимость дорабатывать машкод руками.
Ну и статья как раз о том, что на самом деле наша индустрия никогда такого не переживала.
Давайте так. Чтоб уж справедливо было, сначала упомянем, что это разные места. "Don’t expect AGI within the next year" в оригинале это "Не ждите AGI в ближайший год". Без истерик. И да, изначально я писал на русском.
В том месте, где "И не говорите мне, что..." в английской версии выглядит как "But don't tell me...". Истерика на месте, всё в порядке.
Я вам по секрету скажу, что здесь оригинал. А там - перевод. Здесь лычка "перевод" потому что мне нужно как-то объяснить поисковикам, что контент на сайте вполне себе оригинальный, а не ворованный с хабра.
Люди как бы тоже не выдают одинаковый код, даже если решают ту же самую задачу.
Сравнивать код человека и код ИИ корректно. Сравнивать код и промпт - нет. Собственно, об этом у нас спор был.
И давайте начистоту. В инженерии нет термина "Практически всегда". Или совпадает или не совпадает. Или детерминированный результат или нет. Или мы можем гарантировать корректность результата или нет. "Практически всегда" - это однозначно "нет".
Если то, что сейчас по ошибке в названии содержит "интеллект", сможет себя эффективно улучшать, то мы вполне можем получить AGI за часы. Непознаваемый, за горизонтом событий. Но для этого ему нужно как минимум меняться со временем. То есть обучаться в процессе жизни, а не как сейчас.
В статье речь про текущее положение вещей. AGI - неопределённое, но неотвратимое будущее. Да, статья скорее сделана с целью предупредить о последствиях применения ИИ, поэтому такая нарочито вызывающая. Но я всё равно не позволял себе определения "тупейший". Мои претензии к нему в другом.
Я давно знаю, что такое многопоточка. И успешно практикую. Её отличие недетерминированности промпта - это документированная неоднозначность. Причём только во времени выполнения. Всегда есть способ заставить многопоток работать тем способом, который задумывался, так как механизмы синхронизации никто не отменял. Для промптов таких технологий не существует.
А чего это вдруг я? Ваша тема с RSA, вот и начинайте. У меня есть слово "Если" в начале предложения. Вот если вам так интересно далее продолжать этот бессмысленный спор, ушедший от темы статьи, то начните, найдите алгоритм, где требуется гарантия простоты числа. А потом уже будет моя очередь доказывать свою часть аргументации.
И не должен. Это не его работа. Если алгоритм шифрования требует гарантию простоты числа, то очевидно, там есть алгоритм, который гарантирует простоту числа. А этот алгоритм нужен, чтобы быстро отбрасывать заранее составные числа и не запускать основной в цикле перебора.
Вы не пониаете, о чём я говорю. Я говорю о том, что наша отрасль работает на гарантиях. Код работает на гарантиях. Алгоритмы работают на гарантиях. Вы приводите тест Миллера-Рабина, как алгоритм, не дающего гарантии, а я говорю, что он гарантию даёт. Поэтому он полезен, как классический алгоритм с false positive. Алгоритм, дающий гарантию простоты числа может написать любой школьник (ну может утрирую). Алгоритм ДЁШЕВО отбрасывающий заранее некорректные результаты намного сложней.
Об этом речь. Алгоритм Миллера-Рабина работает не "практически всегда". Он всегда работает.
Вроде умные мысли говорит, но при этом пытается сделать из промпта полноценную замену. Я говорю "промпт", потому что вижу, что этот язык не является полной и исчерпывающей спецификацией, то есть позволяет множественную трактовку, равно как естественный язык. А если является, то как его синтаксис может быть в 5-10 раз короче?
Я не понимаю, как он собирается решать две основные проблемы.
Первая и самая главная: недетерменированость. Из одного и того же "исходника" получаются разные кодовые базы классического языка. Это делает невозможным итеративные улучшения, это делает невозможным багфикс (ну просто потому что сегодня баг есть, завтра нет и наоборот, и всё это с одним и тем же "исходником").
Вторая проблема: контекстное окно. Если раньше, когда вдруг оказывалось, что 640кб не хватает
всемдля компиляции, то покупалась плашка памяти за $100 и приводились исходники в порядок. Бедные страдали со свопом, но компилировали. А для увеличения контекстного окна вдвое надо построить новый дата-центр, потому что зависимость ну ни разу не линейная. А контекстное окно нужно обязательно, потому что проект планируется перегенерировать полностью и если ваш исправленный промпт не лезет в окно, то в окно пойдёте вы.Тест Миллера-Рабина гарантирует, что число составное. У него два ответа: "составное" и "не знаю". Давайте заканчивать с софистикой.
Детерминированный алгоритм вполне может выдать число, которое мы посчитаем случайным. Остаток от деления атомов на 10 в песчинке плюс сколько наносекунд кричала чаечка.
Это всё лирика. В один момент детерминизм алгоритмов остаётся технически детерминизмом, но на практике становится случайным. Где-то специально случайность добавляют, усиливают и используют далее в разветвлении алгоритма. Например в ЛЛМ. Которая детерминированная.
Вы же не будете мои слова выдирать из контекста? Мы говорили про разницу в промпте и коде. Выполнение кода детерминировано, промпта - нет.
Там ещё было про гарантии и это была ключевая фраза. "Почти всегда" - это отсутствие гарантии.
Собственно, вам ответили, что вероятностный алгоритм - всё ещё алгоритм. Он делает вывод случайным (в идеале), но сама выдача является детерминированной, потому что является целью алгоритма. Как-то так.
То есть алгоритм шифрования совершенно детерминировано выдаёт случайное число. По хорошему, должна быть какая-то гарантия случайности. Ну там, дисперсии всякие, отклонения и всё такое.
А то знаете, бывает всякое
В разработке мы используем одни гарантии, чтобы предоставить другие. Построить сложную систему, которая будет гарантировать конечному пользователю свою работу.
Если хоть одна часть в нижележащих слоях не может гарантировать свою работу, то вся система рушится, как карточный домик.
Гарантия - это всё. Нет гарантии - нет алгоритмов. Нет кода. Нет ПО как класса.
Ну хотите - посмотрите мои комменты 16-17 года. Там этого эм-даш - навалом. Ну пишу я так. Поменял привычку с приходом ЛЛМ, теперь ставлю короткие тире.
Ну может вы видели "Трассу 60"? Там есть музей поддельного искусства... )
Спасибо, исправил. Но рекомендую по ошибкам в следующий раз писать в личку, чтобы не перегружать комментарии.
У меня 30+ лет опыта разработки. И я считаю некорректным использовать как аргумент в свою пользу.
В производстве ПО должно быть по другому, потому что код и есть штучный товар. Если проводить аналогию, то код - чертёж, ПО - результат построения по чертежу. Само ПО ничего не стоит, потому что компилятор наштампует его в любом количестве, а вот код - это дорого, очень дорого. Потому что R&D, вот почему.
А ещё потому что код долгоживущий. И чем дольше код живёт, тем больше с него прибыль. И тем сложнее его дорабатывать. А дорабатывать надо, потому что "нужно очень быстро идти, чтобы оставаться на месте". Качество кода - это не прихоть, это суровая необходимость рыночных реалий. Бездумный код может обрушить весь бизнес под тяжестью техдолга. Это не какие-то страшилки, это случается регулярно.
Соглашусь полностью. И добавлю, что декларативные языки, хоть и дают детерминированный результат, но страдают от недетерминированности времени выполнения. Вот это самое "О большое". Именно поэтому существует EXPLAIN, который показывает, что и в каком порядке будет выполняться в конкретно этом случае.
А я соглашусь с тем, что компиляторы C++ пишут бредовый и неоптимальный машинный код, который невозможно поддерживать. Правда тут аж два нюанса. На плюсах разработка сильно проще и быстрее, чем на асме. Процессоры становились сложнее, команд больше а тонкости применения прямо лавиной хлынули, смывая призрачную надежду справиться с этим своей головой. Ассемблер Z80 это вообще не то же самое, что ассемблер x86-64 со всеми avx512 и уровнями кэша.
Второй нюанс в том, что C++ остался детерминированный. Он из одного и того же кода делает один и тот же машинный код. Его поведение полностью предсказуемо. Это снимает необходимость дорабатывать машкод руками.
Ну и статья как раз о том, что на самом деле наша индустрия никогда такого не переживала.
Давайте так. Чтоб уж справедливо было, сначала упомянем, что это разные места. "Don’t expect AGI within the next year" в оригинале это "Не ждите AGI в ближайший год". Без истерик. И да, изначально я писал на русском.
В том месте, где "И не говорите мне, что..." в английской версии выглядит как "But don't tell me...". Истерика на месте, всё в порядке.
Я вам по секрету скажу, что здесь оригинал. А там - перевод. Здесь лычка "перевод" потому что мне нужно как-то объяснить поисковикам, что контент на сайте вполне себе оригинальный, а не ворованный с хабра.
Сравнивать код человека и код ИИ корректно. Сравнивать код и промпт - нет. Собственно, об этом у нас спор был.
И давайте начистоту. В инженерии нет термина "Практически всегда". Или совпадает или не совпадает. Или детерминированный результат или нет. Или мы можем гарантировать корректность результата или нет. "Практически всегда" - это однозначно "нет".
Да, именно так. Но я тут не вижу противоречий.
Если то, что сейчас по ошибке в названии содержит "интеллект", сможет себя эффективно улучшать, то мы вполне можем получить AGI за часы. Непознаваемый, за горизонтом событий. Но для этого ему нужно как минимум меняться со временем. То есть обучаться в процессе жизни, а не как сейчас.
В статье речь про текущее положение вещей. AGI - неопределённое, но неотвратимое будущее. Да, статья скорее сделана с целью предупредить о последствиях применения ИИ, поэтому такая нарочито вызывающая. Но я всё равно не позволял себе определения "тупейший". Мои претензии к нему в другом.
Мне даже добавить нечего
Я давно знаю, что такое многопоточка. И успешно практикую. Её отличие недетерминированности промпта - это документированная неоднозначность. Причём только во времени выполнения. Всегда есть способ заставить многопоток работать тем способом, который задумывался, так как механизмы синхронизации никто не отменял. Для промптов таких технологий не существует.