Вроде умные мысли говорит, но при этом пытается сделать из промпта полноценную замену. Я говорю "промпт", потому что вижу, что этот язык не является полной и исчерпывающей спецификацией, то есть позволяет множественную трактовку, равно как естественный язык. А если является, то как его синтаксис может быть в 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 - неопределённое, но неотвратимое будущее. Да, статья скорее сделана с целью предупредить о последствиях применения ИИ, поэтому такая нарочито вызывающая. Но я всё равно не позволял себе определения "тупейший". Мои претензии к нему в другом.
Я давно знаю, что такое многопоточка. И успешно практикую. Её отличие недетерминированности промпта - это документированная неоднозначность. Причём только во времени выполнения. Всегда есть способ заставить многопоток работать тем способом, который задумывался, так как механизмы синхронизации никто не отменял. Для промптов таких технологий не существует.
Я могу повторить то, что написал в статье: промпт это не код. Даже не близко. Промпт - это ТЗ. Это совершенно разные вещи. Вопрос "в чём разница" смысла не имеет. Ну в детерминизме, например. Это тоже написано в статье. Код всегда выполняется одинаково, он однозначен. ТЗ и пропмт будут давать каждый раз разный результат. Вплоть до того, что у одного человека промпт сработает, а в другом заруинит проект. Один и тот же.
Называть документирование техникой программирования из прошлого я бы постеснялся. Это не техника программирования и не из прошлого.
Но тут уже проще найти сходства и отличия с промптом, потому что это одного уровня сущности. Ну например, промпт, как и ТЗ, пишется до разработки. Документация - по факту. И цели немножко разные, но и документация бывает немного разная. Например по установке, по пользованию, по АПИ.
Если ассемблер и код джава я могу назвать одним и тем же, но на разных уровнях абстрации, то промпт к этой вертикали вообще не относится. Он не гарантирует результат. Он не гарантирует однозначность. Да он вообще ничего не гарантирует, в отличие от кода на любом языке.
Вроде умные мысли говорит, но при этом пытается сделать из промпта полноценную замену. Я говорю "промпт", потому что вижу, что этот язык не является полной и исчерпывающей спецификацией, то есть позволяет множественную трактовку, равно как естественный язык. А если является, то как его синтаксис может быть в 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 - неопределённое, но неотвратимое будущее. Да, статья скорее сделана с целью предупредить о последствиях применения ИИ, поэтому такая нарочито вызывающая. Но я всё равно не позволял себе определения "тупейший". Мои претензии к нему в другом.
Мне даже добавить нечего
Я давно знаю, что такое многопоточка. И успешно практикую. Её отличие недетерминированности промпта - это документированная неоднозначность. Причём только во времени выполнения. Всегда есть способ заставить многопоток работать тем способом, который задумывался, так как механизмы синхронизации никто не отменял. Для промптов таких технологий не существует.
Я могу повторить то, что написал в статье: промпт это не код. Даже не близко. Промпт - это ТЗ. Это совершенно разные вещи. Вопрос "в чём разница" смысла не имеет. Ну в детерминизме, например. Это тоже написано в статье. Код всегда выполняется одинаково, он однозначен. ТЗ и пропмт будут давать каждый раз разный результат. Вплоть до того, что у одного человека промпт сработает, а в другом заруинит проект. Один и тот же.
Называть документирование техникой программирования из прошлого я бы постеснялся. Это не техника программирования и не из прошлого.
Но тут уже проще найти сходства и отличия с промптом, потому что это одного уровня сущности. Ну например, промпт, как и ТЗ, пишется до разработки. Документация - по факту. И цели немножко разные, но и документация бывает немного разная. Например по установке, по пользованию, по АПИ.
Если ассемблер и код джава я могу назвать одним и тем же, но на разных уровнях абстрации, то промпт к этой вертикали вообще не относится. Он не гарантирует результат. Он не гарантирует однозначность. Да он вообще ничего не гарантирует, в отличие от кода на любом языке.
Номер статьи хороший, вы специально подбирали? )
Да