Кто вам сказал, что я считаю что автопилоты работают на LLM?
Статья и комментарии к ней, которые про LLM (генеративный ИИ). Если Вы хотели сказать, что под формулировкой "ИИ" есть и другие технологии, которые справляются со своей работой получше, то это уже уход от основной темы обсуждение, так как обсуждается конкретная технология, а не лейбл "ИИ" в целом.
и да, он там используется
Он это кто, LLM? Там, где "масштаб ответственности повыше", или там, где условная Алиса выбирает музыку?
LLM - технология генерации контента, поэтому Вам неоднократно написали о том, что результат генеративных моделей надо валидировать, что в свою очередь требует неопределенного количества времени, которое игнорируется в контексте "экономии времени".
Есть ли какая-то объективная причина, кроме до боли известной "мне так привычнее", по которой оформление листов для печати делаются в Модели, а не в самих Листах, которые дают больше гибкости и идентичности, как в подготовке печати, так и в редактировании в целом. Если в этом все же есть резон - может тогда стоит переосмыслить идею Листов?
Понятно, что долгие годы люди работали с САПР-ом, как с черной бумагой, и передавали это "ремесло" следующему поколению. Многие даже меняют фон Модели на белый, не понимая смысла черного, или чертят без слоев в один тон, "как раньше". Давайте все же поймем, наконец, что мы давно работаем с данными, а не графитом на ватмане. Одну четверть 21-го века уже проехали...
С приходом LLM, который хорошо продается (пока) под лейблом ИИ, изменилось только то, что можно генерить невероятное количество неопределенного качества текста за пол минуты.
если у вас ИИ плохо пишет - значит вы дали мало контекста и плохо поставили задачу
Мантра промоутеров. Ага, галлюцинации тоже из-за меня, не умею работать в команде.
Потому что в какой-то момент люди понимают, что "адекватность" требует валидации. Плотника, сварщика или слесаря уже давно заменили роботами именно там, где ИИ никому не нужен - огромный конвейерный поток с шаблоном работ и с ожидаемым результатом.
Предсказать ответы ИИ в разных ситуациях одним вопросом невозможно.
То, что маркетологи назвали ИИ, и есть модель предсказаний, в данном случае - последующих слов по контексту. Разные "ситуации" - разные контексты (если, конечно, определеные правила не прибиты в модель руками).
Такие понятия, как правильное и неправильное рассуждение, не применимы к такой модели, даже в виде метафоры, и всё больше приводят к ошибочному восприятию технологии.
Однако, статистические усреднители не всегда помогают с прогнозами, даже с гигантским количеством данных. Например при прогнозе погоды большую роль играют симуляторы физики, поэтому, как было 30 лет назад, так и сейчас с LLM-ками и блекджеком, всё вычисляется на старой модели, с относительно точным прогнозом максимум на 3 дня.
Добавлю от себя высококонтрастные снимки - солнце/тени. Если корректирую экспозицию на -0.3 или -0.7 (не пробовал с другими камерами, NEF пересвет не вытягивает), то деликатное расширение ДД в обратную сторону и коррекция ББ в пост-обработке почти всегда дают идеальный результат.
Мне не хочется что-то там настраивать. Я обычно софт использую как есть. Чаще всего всё сделано вполне удобно. Хочется сесть и работать.
А Вы не думали, что описаное вами - довольно субъективная реальность, и могло быть применимо таким же образом при старом UI? Вот мне и еще сотням тысяч другим разработчикам (судя по количеству скачиваний), на которых буквально наплевать "эффективным менеджерам", не хочеться "сесть и работать" без плагина Classic UI, сроки поддержки которого от Jetbrains пока не ясны.
То есть, консистентность данных поддерживается на уровне програмных модификации. Меняются геометрические метаданные - пересобираем mesh за счет параметрической семантики записанной отдельно. Очень похоже на оптимизацию форматов хранения nurbs моделей, когда триангулированная mesh модель тоже сохраняется в файл в виде "кэша", и инвалидируется после геометрических изменений.
С мыслями и позицией изложенных в статье солидарен. Потребность в обработке данных в строительстве актуальна и будет неизбежно увеличиватся со временем.
По технической части есть вопрос. Данные в параметрическом формате определяют саму геометрию через некоторые геометрические свойства (цетр, угол, радиус, etc.). Неопределяющие геометрические свойства вычисляются и не являются частью данных (другой угол, площадь, объём, etc.). В случае с использованием mesh формата, если я правильно понимаю, "определяющие" геометрические свойства прикрепляются как метаданные, а геометрия задается отдельно живущим в пространстве списком вершин и полигонов. Поскольку в таком случае очевидным образом нарушается принцип единого источника истины (ssot), какие решения имеются/предлагаются по валидации данных?
Почти полностью отсутствуют вакансии где, в России?
C 2007 года его много где могли попробовать
А почему попробовать должны были именно там, где вы ожидали? Я же привел примеры и ссылку.
PHP незаменим из-за охренительного количества легаси. Javascript, как рантайм - из-за браузера, а как язык оказался хуже, чем десятки надстроек над ним. И ClojureScript, как бы иронично не звучало, один из них.
Для Haskell есть даже сервис поиска функций по сигнатуре (!) в библиотеках по всей репозитории. А библиотек там, поверьте, не мало. Для подключения к Postgres - не менее дюжины, с примесями ОРМ и без. Там и свой crates и cargo и вся инфраструктура есть давным давно (кроме отдельного IDE). Но вроде ситуация от этого не меняется.
Ваши представления о языках ФП тоже немного подустарели.
Clojure (кстати, тоже Лисп) не более "эзотерический" в 2024, чем, скажем, Ruby, если исключить большее количество легаси из-за старости второго. Можете ознакомиться со списком компаний использующих Clojure, от Apple до Netflix. Популярная графовая БД Datomic тоже полностью написана на Clojure.
Статья и комментарии к ней, которые про LLM (генеративный ИИ). Если Вы хотели сказать, что под формулировкой "ИИ" есть и другие технологии, которые справляются со своей работой получше, то это уже уход от основной темы обсуждение, так как обсуждается конкретная технология, а не лейбл "ИИ" в целом.
Он это кто, LLM? Там, где "масштаб ответственности повыше", или там, где условная Алиса выбирает музыку?
LLM - технология генерации контента, поэтому Вам неоднократно написали о том, что результат генеративных моделей надо валидировать, что в свою очередь требует неопределенного количества времени, которое игнорируется в контексте "экономии времени".
Вы уверены, что системы автоматического пилотирования работают на LLM?
Немного не в тему, но всё же...
Есть ли какая-то объективная причина, кроме до боли известной "мне так привычнее", по которой оформление листов для печати делаются в Модели, а не в самих Листах, которые дают больше гибкости и идентичности, как в подготовке печати, так и в редактировании в целом. Если в этом все же есть резон - может тогда стоит переосмыслить идею Листов?
Понятно, что долгие годы люди работали с САПР-ом, как с черной бумагой, и передавали это "ремесло" следующему поколению. Многие даже меняют фон Модели на белый, не понимая смысла черного, или чертят без слоев в один тон, "как раньше". Давайте все же поймем, наконец, что мы давно работаем с данными, а не графитом на ватмане. Одну четверть 21-го века уже проехали...
С приходом LLM, который хорошо продается (пока) под лейблом ИИ, изменилось только то, что можно генерить невероятное количество неопределенного качества текста за пол минуты.
Мантра промоутеров. Ага, галлюцинации тоже из-за меня, не умею работать в команде.
В оригинальном комментарии ЛеКун пишет AGI в кавычках не зря:
He is a doomer, but he keeps working on "AGI".
Потому что в какой-то момент люди понимают, что "адекватность" требует валидации. Плотника, сварщика или слесаря уже давно заменили роботами именно там, где ИИ никому не нужен - огромный конвейерный поток с шаблоном работ и с ожидаемым результатом.
То, что маркетологи назвали ИИ, и есть модель предсказаний, в данном случае - последующих слов по контексту. Разные "ситуации" - разные контексты (если, конечно, определеные правила не прибиты в модель руками).
Такие понятия, как правильное и неправильное рассуждение, не применимы к такой модели, даже в виде метафоры, и всё больше приводят к ошибочному восприятию технологии.
Однако, статистические усреднители не всегда помогают с прогнозами, даже с гигантским количеством данных. Например при прогнозе погоды большую роль играют симуляторы физики, поэтому, как было 30 лет назад, так и сейчас с LLM-ками и блекджеком, всё вычисляется на старой модели, с относительно точным прогнозом максимум на 3 дня.
Добавлю от себя высококонтрастные снимки - солнце/тени. Если корректирую экспозицию на -0.3 или -0.7 (не пробовал с другими камерами, NEF пересвет не вытягивает), то деликатное расширение ДД в обратную сторону и коррекция ББ в пост-обработке почти всегда дают идеальный результат.
Надо отметить, что не на LLM.
А Вы не думали, что описаное вами - довольно субъективная реальность, и могло быть применимо таким же образом при старом UI? Вот мне и еще сотням тысяч другим разработчикам (судя по количеству скачиваний), на которых буквально наплевать "эффективным менеджерам", не хочеться "сесть и работать" без плагина Classic UI, сроки поддержки которого от Jetbrains пока не ясны.
И в старом, и в новом, элементы UI можно увеличить. В отличии от старого, в новом их надо угадывать или вспомнить.
Можете привести пример удобства со ссылкой на неудобство того же самого в классическом интерфейсе?
touch можно передать и существующие файлы, обновляются только временные метки (тут внезапно раскрывается смысл названия команды).
То есть, консистентность данных поддерживается на уровне програмных модификации. Меняются геометрические метаданные - пересобираем mesh за счет параметрической семантики записанной отдельно. Очень похоже на оптимизацию форматов хранения nurbs моделей, когда триангулированная mesh модель тоже сохраняется в файл в виде "кэша", и инвалидируется после геометрических изменений.
С мыслями и позицией изложенных в статье солидарен. Потребность в обработке данных в строительстве актуальна и будет неизбежно увеличиватся со временем.
По технической части есть вопрос. Данные в параметрическом формате определяют саму геометрию через некоторые геометрические свойства (цетр, угол, радиус, etc.). Неопределяющие геометрические свойства вычисляются и не являются частью данных (другой угол, площадь, объём, etc.). В случае с использованием mesh формата, если я правильно понимаю, "определяющие" геометрические свойства прикрепляются как метаданные, а геометрия задается отдельно живущим в пространстве списком вершин и полигонов. Поскольку в таком случае очевидным образом нарушается принцип единого источника истины (ssot), какие решения имеются/предлагаются по валидации данных?
Это называется "не прочитал, но своё мнение я скажу". Так и я об этом же - инфраструктура есть, но популяризации она не способствует.
Почти полностью отсутствуют вакансии где, в России?
А почему попробовать должны были именно там, где вы ожидали? Я же привел примеры и ссылку.
PHP незаменим из-за охренительного количества легаси. Javascript, как рантайм - из-за браузера, а как язык оказался хуже, чем десятки надстроек над ним. И ClojureScript, как бы иронично не звучало, один из них.
Для Haskell есть даже сервис поиска функций по сигнатуре (!) в библиотеках по всей репозитории. А библиотек там, поверьте, не мало. Для подключения к Postgres - не менее дюжины, с примесями ОРМ и без. Там и свой crates и cargo и вся инфраструктура есть давным давно (кроме отдельного IDE). Но вроде ситуация от этого не меняется.
Ваши представления о языках ФП тоже немного подустарели.
Clojure (кстати, тоже Лисп) не более "эзотерический" в 2024, чем, скажем, Ruby, если исключить большее количество легаси из-за старости второго. Можете ознакомиться со списком компаний использующих Clojure, от Apple до Netflix. Популярная графовая БД Datomic тоже полностью написана на Clojure.