Я не слышал. А что мешает, это как-раз более понятно. Надо много инвестиций, набрать команду, выбрать какой инструмент делать, надо собирать датасет, много ресурсов на обучение. И не факт, что рынок потом усилия оценит. Но с другой стороны из-за доступа к геом. ядру им конечно легче такие инструменты разрабатывать и внедрять в CAD.
По поводу капитального строительства не видел, с удовольствием про это прочитал. Мне кажется генеративный дизайн в этом не очень подходит. Мое мнение, надо развиваться с применением обучения с подкреплением (Reinforcement Learning). ИИ должна учиться из готовых компонент собирать конструкцию, чтобы соответствовать критериям. Но это сложный способ
Да, это другая технология. С сомнительной полезностью. Она никак не оптимизирует, просто пытается соединить чем-то выбранные поверхности. Результат похож на сгустки. Было бы гораздо полезнее, если бы он старался сделать более традиционные конструкции с той же целью. Такие научные работы в публикациях есть, но ни в одном CAD пока не применено.
В том то и дело, что есть много шума про ИИ, которое всех заменит, но текущее положение пока скорее удручает. Хотя есть некоторые положительные инструменты которые можно использовать уже сейчас. Ну и почти везде я дал комментарий по возможному развитию этих инструментов.
Про топологическую написал, потому-что ее на хайпе про ИИ часто рекламируют как ML инструмент (под названием "Generative design"). Ну и Autodesk развил этот инструмент в интересном направлении, что оптимизация проводится по технологичности изготовления. Считаю очень правильным это направление, надо и нашим это направление развивать.
Кстати по поводу предвзятости. В этом и была цель. Я сам отношусь пока со скепсисом к текущему положению, но важно было понять, что вообще существует на этом поприще. Как есть описал, но также надо понимать, что новые технологии появляются каждый день. Есть множество научных статей, в которых показаны интересные возможности для CAD. Так что может все быстро измениться
Мне кажется разработчики таких инструментов скорее не совсем туда копают, я пытался во многих главах дать предположение, в каком виде инструмент работал бы лучше и был бы более полезным.
Понимаете, здесь все не ради крыла делается, а скорее цель в разработке общей технологии быстрой и эффективной оптимизации. В промышленности крыло отдельно уже никто не оптимизирует, а оптимизируют формы сложной трехмерной геометрии. Нужна понятная и быстрая технология, которая позволит инженеру условно выбрать параметры геометрии, которые нужно оптимизировать и нажать на большую красную кнопку (ну и чтобы оптимизация вечность не занимала).
То, что вы описываете, это как раз построение суррогатной модели (или Reduced Order Modeling) по результатам расчетов. Условный следующий этап развития этой задачи. Только для того, чтобы такие суррогатные модели стали работоспособны на 12-мерном пространстве точек там должно быть ~100-1000, что уже выбивается за бюджет инженерного применения. Как я уже написал выше, есть идея попробовать такой подход в гибридном режиме. Локальный градиентный оптимизатор условно исследует пространство в локальном минимумах, суррогатная модель используется для постановки начальной точки градиентного оптимизатора и построения общей поверхности отклика.
Спасибо! Сравнить с оптимизацией на основе ROM тоже хочу. Еще есть идея поставить ROM для глобального поиска и SLSQP для локального поиска с выдачей точек в ROM для уточнения.
Честно говоря, узнал от вас впервые! Причем когда-то давно я что-то подобное пилил самостоятельно на yaml+python-docx но потом решил все-таки разобраться в Latex и теперь на Word смотреть не могу. Круто! Может еще поразбираюсь на досуге) Может возникнуть одна задачка.
Да, исходные данные в виде xlsx или csv таблиц. Они хранятся в отдельных объектах, поэтому их могут редактировать не только расчетчики. Таблицы могут быть отправлены на расчет в фоновом режиме ( без загрузки интерфейса Jupyter), и сложиться в тимцентр в виде измененного расчета и отчета.
Предполагаю, что невалидные ходы игнорируются, а ей выдается отрицательный Reward. Доп информацию извлечь возможно и не получится, но они утверждают, что таким образом у алгоритма появляется более эффективное векторное представление среды.
Да, но в AlphaZero были заложены правила игры. Условно говоря, она не могла сделать неправильный ход. В MuZero правила игры не заложены, ей просто дали доску, и давай на ней учись. На самом деле там очень хитро устроено, моя ламерская интерпретация: MuZero обучена делать свое нейросетевое представление игры, с которым она взаимодействует с помощью метода Monte-Carlo tree search. AlphaZero взаимодействует Monte-Carlo tree search с самой игрой.
Насколько можно судить, они любой входной поток кодируют в векторное представление, а не просто в текст (как было бы, если использовалась сторонняя нейронка под обработку голоса). Соответственно эти вектора могут содержать больше информации, полезной нейронке, и ей с ними легче работать. Это предположение, свечку не держал. И еще, такой же подход помог алгоритму MuZero обучиться лучше играть в игры, чем AlphaZero. MuZero сам учился выстраивать свое векторное представление игры (например Шахмат или Го), а не использовал навязанное человеком.
Классный вопрос, спасибо! А взаимодействие есть, просто раскрыть эту тему в одном абзаце в статье не получится. Полагаю сделаю отдельную статью вообще про работу в PLM с расчетами, и в частности с Teamcenter. Но если вкратце, сейчас у заказчика реализован механизм, когда расчеты Jupyter хранятся и запускаются через Teamcenter. Расчетчик просто запускает свои расчеты через кнопку из Тимцентра, результаты расчета в виде пдф-отчетов и файлов .ipynb и .py хранятся в Тимцентре. Объект расчета может быть связан с конструкцией (по которой делается расчет), а также его можно отправлять по рабочему процессу.
Вообще интересная находка, можно поизучать. Спасибо!
Я не слышал. А что мешает, это как-раз более понятно. Надо много инвестиций, набрать команду, выбрать какой инструмент делать, надо собирать датасет, много ресурсов на обучение. И не факт, что рынок потом усилия оценит. Но с другой стороны из-за доступа к геом. ядру им конечно легче такие инструменты разрабатывать и внедрять в CAD.
По поводу капитального строительства не видел, с удовольствием про это прочитал. Мне кажется генеративный дизайн в этом не очень подходит. Мое мнение, надо развиваться с применением обучения с подкреплением (Reinforcement Learning). ИИ должна учиться из готовых компонент собирать конструкцию, чтобы соответствовать критериям. Но это сложный способ
Да, это другая технология. С сомнительной полезностью. Она никак не оптимизирует, просто пытается соединить чем-то выбранные поверхности. Результат похож на сгустки. Было бы гораздо полезнее, если бы он старался сделать более традиционные конструкции с той же целью. Такие научные работы в публикациях есть, но ни в одном CAD пока не применено.
В том то и дело, что есть много шума про ИИ, которое всех заменит, но текущее положение пока скорее удручает. Хотя есть некоторые положительные инструменты которые можно использовать уже сейчас. Ну и почти везде я дал комментарий по возможному развитию этих инструментов.
Про топологическую написал, потому-что ее на хайпе про ИИ часто рекламируют как ML инструмент (под названием "Generative design"). Ну и Autodesk развил этот инструмент в интересном направлении, что оптимизация проводится по технологичности изготовления. Считаю очень правильным это направление, надо и нашим это направление развивать.
Кстати по поводу предвзятости. В этом и была цель. Я сам отношусь пока со скепсисом к текущему положению, но важно было понять, что вообще существует на этом поприще. Как есть описал, но также надо понимать, что новые технологии появляются каждый день. Есть множество научных статей, в которых показаны интересные возможности для CAD. Так что может все быстро измениться
Да, действительно, САПР это более широкое понятие. Я хотел ограничиться именно CAD, статья и так большая получилась.
Мне кажется разработчики таких инструментов скорее не совсем туда копают, я пытался во многих главах дать предположение, в каком виде инструмент работал бы лучше и был бы более полезным.
Не слышал про такие подходы, поизучаю. Спасибо!
Понимаете, здесь все не ради крыла делается, а скорее цель в разработке общей технологии быстрой и эффективной оптимизации. В промышленности крыло отдельно уже никто не оптимизирует, а оптимизируют формы сложной трехмерной геометрии. Нужна понятная и быстрая технология, которая позволит инженеру условно выбрать параметры геометрии, которые нужно оптимизировать и нажать на большую красную кнопку (ну и чтобы оптимизация вечность не занимала).
То, что вы описываете, это как раз построение суррогатной модели (или Reduced Order Modeling) по результатам расчетов. Условный следующий этап развития этой задачи. Только для того, чтобы такие суррогатные модели стали работоспособны на 12-мерном пространстве точек там должно быть ~100-1000, что уже выбивается за бюджет инженерного применения. Как я уже написал выше, есть идея попробовать такой подход в гибридном режиме. Локальный градиентный оптимизатор условно исследует пространство в локальном минимумах, суррогатная модель используется для постановки начальной точки градиентного оптимизатора и построения общей поверхности отклика.
Что-то я не понял, как я смогу посчитать без геометрии с помощью численных методов целевую функцию для трехмерной постановки задачи. Можете объяснить?
Спасибо! Сравнить с оптимизацией на основе ROM тоже хочу. Еще есть идея поставить ROM для глобального поиска и SLSQP для локального поиска с выдачей точек в ROM для уточнения.
Честно говоря, узнал от вас впервые! Причем когда-то давно я что-то подобное пилил самостоятельно на yaml+python-docx но потом решил все-таки разобраться в Latex и теперь на Word смотреть не могу. Круто! Может еще поразбираюсь на досуге) Может возникнуть одна задачка.
Да, исходные данные в виде xlsx или csv таблиц. Они хранятся в отдельных объектах, поэтому их могут редактировать не только расчетчики. Таблицы могут быть отправлены на расчет в фоновом режиме ( без загрузки интерфейса Jupyter), и сложиться в тимцентр в виде измененного расчета и отчета.
Предполагаю, что невалидные ходы игнорируются, а ей выдается отрицательный Reward. Доп информацию извлечь возможно и не получится, но они утверждают, что таким образом у алгоритма появляется более эффективное векторное представление среды.
Если аудио в текст, то потеряет конечно. Если аудио в вектор, то как раз может такие вещи и ловить. Трансформация в вектор обучаемая.
Да, но в AlphaZero были заложены правила игры. Условно говоря, она не могла сделать неправильный ход. В MuZero правила игры не заложены, ей просто дали доску, и давай на ней учись.
На самом деле там очень хитро устроено, моя ламерская интерпретация: MuZero обучена делать свое нейросетевое представление игры, с которым она взаимодействует с помощью метода Monte-Carlo tree search. AlphaZero взаимодействует Monte-Carlo tree search с самой игрой.
Насколько можно судить, они любой входной поток кодируют в векторное представление, а не просто в текст (как было бы, если использовалась сторонняя нейронка под обработку голоса). Соответственно эти вектора могут содержать больше информации, полезной нейронке, и ей с ними легче работать. Это предположение, свечку не держал.
И еще, такой же подход помог алгоритму MuZero обучиться лучше играть в игры, чем AlphaZero. MuZero сам учился выстраивать свое векторное представление игры (например Шахмат или Го), а не использовал навязанное человеком.
Классный вопрос, спасибо!
А взаимодействие есть, просто раскрыть эту тему в одном абзаце в статье не получится. Полагаю сделаю отдельную статью вообще про работу в PLM с расчетами, и в частности с Teamcenter.
Но если вкратце, сейчас у заказчика реализован механизм, когда расчеты Jupyter хранятся и запускаются через Teamcenter. Расчетчик просто запускает свои расчеты через кнопку из Тимцентра, результаты расчета в виде пдф-отчетов и файлов .ipynb и .py хранятся в Тимцентре. Объект расчета может быть связан с конструкцией (по которой делается расчет), а также его можно отправлять по рабочему процессу.