BOM Voyage


Гео и язык канала: Весь мир, Русский
Категория: Технологии


Канал посвящённый новинкам применения ИИ в PLM/CAD и прочем инженерном
Проекты, презентации, прогресс стартапов, идеи и инструменты из этой области
связь contact@zelanton.net ,
@zelanton в телеграмме, https://www.linkedin.com/in/anton-zhelezniakou/

Связанные каналы

Гео и язык канала
Весь мир, Русский
Категория
Технологии
Статистика
Фильтр публикаций


^^

Кстати, насчёт трат денег агентами в постсоветском пространстве с его засекреченностью всего, паранойей, неприятием облаков, "ИИ только локальный", проблема "ИИ требует денег и по мере внедрения всё больше" приобретает дополнительный аспект — быстрое устаревание железа.

Ну предположим Кошёк даст денег на GPU нужные на данном этапе, но через год окажется что надо ещё 10X, а то что купили, развернули и настроили — уже морально устарело.

Облака решают в первую очередь эту проблему - когда скорость роста не даёт предсказывать будущие потребности, когда это нерационально закрывать самим в силу "быстро понадобиться совсем другое" - проще работать с облачным сервисом, а оптимизировать схему по цене и архитектуре по мере стабилизации потребностей.

У меня в международной логистике например гибрид - в основном свои ЦОД, но пиковые нагрузки, плюс растущие части системы - в облаках.

Но конечно же зачастую облака неприемлимы, и с этим ничего не поделаешь, придётся крутиться хоть как-то. И это отразится на ходе трансформации.

——

И ещё один момент, читая новости вида "Microsoft запретила ИИ своим программистам т.к. денег не хватает" знайте, что деньги-то есть, проблема стукнулась о процесс бюджетирования больших корпораций - бюджет на ИИ заложили в прошлом году и недооценили темпы роста потребностей. А поменять бюджет в больших корпорациях сами понимаете.


Видео недоступно для предпросмотра
Смотреть в Telegram
По мотивам забавной статьи
Enterprises Will Run 1,600 AI Agents by the End of 2026
Замечу что замерять среднюю температуру по больнице - это всегда заявка на определённую премию,

1600 агентов к концу 2026 в среднем на предприятие будет вряд ли даже в штатах. Сначала бизнес обнаружит, что автономные агенты слишком хорошо умеют тратить деньги на модели. А если бюджет выдержит — выяснится, и это тема статьи по ссылке, что инфраструктура не была рассчитана на сотрудников, которые работают круглосуточно, запускают десятки задач параллельно и способны увеличить потоки данных на 2 порядки.

GitHub уже столкнулся с этим эффектом. Осенью 2025 года компания планировала увеличить ёмкость инфраструктуры примерно в 10 раз, а к февралю 2026-го стала проектировать её уже под 30-кратный масштаб. GitHub связывает рост нагрузки в том числе с агентной разработкой: быстро увеличивается число операций с репозиториями, pull request, API и автоматизацией. В августе новый пик трафика стал отправной точкой почти восьмичасового сбоя, когда один из критических компонентов не смог масштабироваться вслед за нагрузкой.

Агент создаёт принципиально иную нагрузку, чем человек. Пользователь читает результат, думает и неторопливо делает работу. Агент сразу создаёт десятки подзадачей, запускает субагентов, тесты, читает тысячи объектов, обращается к поиску и моделям, меняет данные и запускает следующие процессы. Поэтому узким местом становятся уже не только токены и GPU, но базы, сети, хранилища, очереди и корпоративные API, рассчитанные на человеческую скорость работы.

Потому в мире уже рождаются проекты, которые готовятся зарабатывать на решении этой проблемы. Завтра как раз пойду на очную конференцию Redpanda, которая начинала с создания высокопроизводительной альтернативы Apache Kafka (системы предназначенной для решения проблемы масштабирования сервисов) — переписали без JVM. Теперь компания взяла курс на переносит этой экспертизы на описанную проблему связанную с ИИ. В их Agentic Data Plane агенты подключаются к данным, моделям и инструментам через общий управляемый слой. Потоковая платформа позволяет буферизовать и распределять работу, отделяя скорость агентов от возможностей обслуживающих их систем, а квоты и обратное давление — ограничивать чрезмерную нагрузку. Сверху добавляются идентификация агентов, управление доступом через MCP, единый шлюз к моделям, контроль расходов и наблюдение за действиями агентов.

Так что пока агентов десятки, их можно напрямую подключать к Git, PLM, ERP и базам данных. Но скоро (хоть и не к концу этого года) их станет тысячи, и тогда архитектура начнет напоминать тысячи микросервисов, напрямую вызывающих друг друга без очередей, ограничений нагрузки и единого контроля. Если денег на токены всё-таки хватит, придётся сделать так, чтобы от агентного энтузиазма не легла инфраструктура.


Свежие вроде как научно-технические статьи (arxiv)

RA-CAD: CAD-агент, который анализирует результат собственной работы — вместо одноразовой генерации CAD-программы предлагается цикл Generate → Execute → Critique → Rewrite: агент строит модель, запускает полученный код в CAD-среде, видит фактический результат, отдельно формулирует критику и исправляет построение.
https://arxiv.org/html/2608.05714v1

VFEAgent — мультимодальная агентная система, автоматизирующая цепочку от инженерного чертежа до проверенного результата конечно-элементного моделирования. ИИ выступает исполнителем инженерного процесса, связывающий понимание исходного документа, подготовку модели, запуск расчёта и проверку результата. Вместе с DUCTILE, RA-CAD и CADENA начинает складываться довольно отчётливое направление: агентная автоматизация всей инженерной цепочки вместо добавления отдельных ИИ-функций в CAD/CAE.
https://arxiv.org/html/2605.28978v2


Вашингтонский университет исследовал, как с помощью ИИ быстрее подбирать параметры 3D-печати для медного сплава GRCop-42, который используют, например, в ракетных камерах сгорания. Вместо перебора более 100 млн возможных сочетаний исследователи построили замкнутый цикл: ИИ выбирал небольшую серию параметров для проверки, детали печатали и измеряли, после чего результаты возвращались в модель, и она предлагала следующие варианты. При бюджете всего в 40 экспериментов удалось найти шесть рабочих конфигураций на разных мощностях лазера и впервые стабильно печатать этот материал при 500 Вт.
https://news.wsu.edu/news/2026/08/24/researchers-use-ai-to-democratize-3d-printing-of-crucial-metal-alloy/

Исходная работа получила Innovative Deployed Application Award на AAAI-26.
https://ojs.aaai.org/index.php/AAAI/article/view/41428

Одновременно опубликована работа Сколтеха по машинно-обучаемым межатомным потенциалам для расчёта механических свойств сложных материалов. Метод сочетает момент-тензорные потенциалы с активным обучением: модель сама обнаруживает локальные атомные конфигурации, где её прогноз ненадёжен, отправляет только эти небольшие фрагменты на дорогой DFT-расчёт и затем дообучается. На композитах WC–Co удалось перейти от систем в сотни атомов, характерных для прямого DFT, к десяткам тысяч атомов, сохраняя близкую к DFT точность. Это интересно для CAE прежде всего как пример перехода от «ИИ после расчёта» к многоуровневому моделированию, где дорогой физический решатель автоматически вызывается лишь там, где машинная модель выходит за область уверенного прогноза.
https://ai.cnews.ru/news/line/2026-08-24_metallokeramika_pod_kontrolem

———

Берлинская компания SPREAD AI, которая строит над существующим инженерным ПО единый слой данных, связей и ИИ, описала свой подход к «PLM нового поколения», и по сути он строится вокруг уже знакомой идеи: не заменять существующие PLM, ALM, ERP, MES и CAE, а создать над ними общий интеллектуальный слой. Он связывает требования, функции изделия, версии программного обеспечения, детали, испытания и изменения в единую модель взаимосвязей. Благодаря этому ИИ работает не просто с отдельными документами, а понимает, как инженерные объекты связаны между собой, и каждый его вывод можно проверить по исходным данным.
https://www.spread.ai/resources/stories/ai-native-plm

По сути тоже самое что я описал вчера
https://t.me/BOM_Voyage/347

Чуть дальше пошла Enlil, небольшая частная американская компания из Кремниевой долины, работающая на стыке инженерного ПО и медицинской техники, — они представили архитектуру Governed AI Foundation для разработки медицинских изделий. Это один из наиболее точных найденных аналогов нашей концепции. Платформа связывает PLM, требования, управление рисками, качество, закупки и производство; общий ИИ-слой в первую очередь читает данные и оценивает межсистемные последствия, но не изменяет рабочие системы. Специализированные агенты получают только ограниченные права и действуют через заданные процессы и обязательные точки согласования. Для каждого результата сохраняются происхождение данных, полномочия агента, его действия и решения человека. То есть присутствуют почти все основные элементы: межсистемный контекст, «читать широко — изменять узко», проверяемые основания, ограниченная автономность и история решений. Отличие главным образом в узкой ориентации на регулируемую MedTech-среду.
https://www.prnewswire.com/news-releases/enlil-unveils-governed-ai-foundation-to-ready-medical-device-makers-for-ai-assisted-regulatory-review-302853600.html

——

В Китае вышел большой обзор развития агентной инфраструктуры за предыдущую неделю и из него вытекает тот же вывод: конкуренция смещается от качества модели к постоянному состоянию агента, собственной идентичности, делегированию полномочий, согласованиям, восстановлению после ошибок, идемпотентности и аудиту. Отдельно отметили от агентов, которыми человек постоянно управляет в чате, к постоянно работающим организационным единицам, где человек вмешивается только в критических точках — утверждает, приостанавливает или перехватывает выполнение.
https://wujiaming88.github.io/2026/08/24/global-ai-agent-weekly.html (китайский)

Кстати стартапов в публичном поле в Китае маловато, но может я как-то не так смотрю. Такое чувство что там вся энергия (а её у них ух) уходит сугубо в физический ИИ, практически полностью в робототехнику. Ну и на унижение американцев на рынке LLM. Результат у них на лицо, но и риск локального перепроизводства гуманоидных роботов первого поколения ("забавно, продолжайте, сейчас купим только штучно побаловаться") просто запредельный.


У меня закончились токены при работе с Claude, поэтому я решил переключиться на Qwen3.8. Из-за проблем с вызовом инструментов мне не удалось нормально его подключить, поэтому вместо Claude Code я использовал открытого агента для программирования PI (pi.dev), распространяемого по лицензии MIT. Приятным побочным эффектом стало то, что теперь весь комплекс можно запускать полностью локально, что очень хорошо с точки зрения конфиденциальности данных.

Настоящий шаг вперёд заключается в том, что связка Qwen3.8 с PI позволяет агенту напрямую работать с моим инструментом расчёта электрических машин: он автономно предлагает параметры геометрии, запускает расчёты, создаёт модель в FreeCAD, а затем передаёт её в расчёт магнитного поля в Elmer и в основанную на Mantaflow модель смачивания маслом в Blender — пока это лишь приближённая модель, а не полноценный тепловой расчёт или моделирование масла.

Вся эта система всё ещё находится на экспериментальной стадии. На приложенном изображении слева показан PI, а справа — сгенерированная ИИ конструкция электрической машины. Конструкция пока не совсем корректна; сейчас я дорабатываю управление геометрией.

Это по-прежнему любительский проект и отчёт о полученном опыте, а не реальная инженерная работа.

https://lnkd.in/p/dnMeagdR


ИИ‑агент внутри КОМПАС-3D: пишет код, строит деталь и проверяет результат

Показан ИИ-агент, встроенный в КОМПАС-3D и способный по тексту или чертежу создавать параметрическую модель с деревом построения, переменными и свойствами. Вместо управления CAD через множество команд модель пишет Python-код для высокоуровневой библиотеки поверх COM API КОМПАС-3D. Такой слой скрывает сложность интерфейса, позволяет использовать обычные конструкции программирования и ограничивает опасные вызовы. Агент фактически не «нажимает кнопки», а пишет программу построения детали.

После выполнения кода агент получает изображения модели, выбирает ракурсы и проверяет результат. Это позволяет находить ошибки, которые не выявляются самим CAD: неверную плоскость, направление операции или выбранную грань. В экспериментах агент часто исправлял модель после визуальной проверки. Получается замкнутый цикл «построил — проверил — исправил», частично компенсирующий слабое пространственное мышление современных моделей.

На 90 тестовых задачах лучше всего работало построение по текстовому описанию: для простых и средних деталей совпадение с эталоном было близко к полному, для сложных снизилось примерно до 0,84. Редактирование существующих моделей оказалось сложнее из-за выбора геометрических элементов, а восстановление по чертежу — самым трудным сценарием, особенно при нескольких проекциях. Работа показывает практичный путь к агентному CAD: языковая модель выступает управляющим слоем над программируемой CAD-системой и проверяет результат в замкнутом цикле.

https://habr.com/ru/articles/1072444/


Видео недоступно для предпросмотра
Смотреть в Telegram


Large language models for high-level computer-aided process planning in a distributed manufacturing paradigm

Прямо-таки научная статья посвященная применению языковых моделей к высокоуровневому автоматизированному проектированию технологических процессов. Речь не о режимах резания или выборе инструмента, а о построении общей последовательности операций: например, получение заготовки, точение, сверление и шлифование. Это особенно важно для распределённого производства, где одну деталь можно выпускать на разных предприятиях с различным оборудованием. Поэтому система должна формировать несколько допустимых маршрутов, которые затем можно сравнивать по стоимости, срокам, загрузке и доступным ресурсам.

Авторы не используют большую универсальную языковую модель. Они обучают с нуля небольшую модель (SLM а не LLM) на основе архитектуры GPT на специальном «языке производства». Геометрия детали, её особенности, требования к точности и параметры заказа представляются последовательностью условных обозначений, как и технологические операции. Проектирование маршрута сводится к предсказанию следующей операции. Для обучения создан синтетический набор из 7840 деталей и допустимых маршрутов на основе экспертных правил. При этом модель содержит всего около 200 тысяч параметров и не требует значительных вычислительных ресурсов.

Экспериментально показывается, что для хорошо формализованной задачи такая компактная модель способна точно строить технологические маршруты даже при сравнительно небольшом объёме данных. Главный вывод работы в том, что универсальную модель необязательно заставлять напрямую «понимать производство». Инженерную задачу можно сначала перевести в компактное формальное представление, а затем обучить модель закономерностям технологических последовательностей. Проверку ограничений, стоимость и выбор предприятия при этом выполняют другие компоненты. В перспективе такой модуль может стать частью агентной производственной системы, где одни компоненты извлекают данные из CAD и заказа, другие строят маршруты, а третьи оценивают их по производственным ограничениям.

Ещё одно — Adaptive task planning and coordination in multi-agent manufacturing systems using large language models
Там уже про LLM-управляемую многоагентную производственную систему, агент в ней интерпретирует ранее неизвестные требования к изделию, динамически получает знания о доступных производственных возможностях, подбирает ресурсы и преобразует требования в исполняемые операции. В испытательном стенде система смогла обрабатывать требования, которые заранее не были заложены в модели агентов.

То есть интересный следующий уровень после простой автоматической генерации BOP: технологический план становится не статическим результатом проектирования, а адаптируемым планом, который может перестраиваться с учетом фактических возможностей оборудования.

И наконец, не про ИИ, но интересно A STEP-NC-based post-process simulation system for closed-loop machining — про замыкание CAPP/CAM в обратную связь с производством. На основе STEP-NC связали каждый workingstep с фактическими сигналами выполнения, которые дополняют технологическую модель реальными результатами обработки и затем используют байесовскую оптимизацию для изменения параметров следующего цикла.

В экспериментах оптимизация улучшила результат для всех 12 исследованных операций; среднее превышение лучшего исходного результата составило 24,33%. Это не то, чтобы ИИ (однако очень просится в эту схему), но архитектурно направление очень важное: цифровой двойник перестает только отображать производство и начинает возвращать опыт реального выполнения непосредственно в технологический процесс.

—————

Кстати, «СПРУТ-Технология» недавно как раз показали своего ИИ-помощника технолога СКАТ в СПРУТ-ТП-Нормирование. Он умеет генерировать технологический процесс по текстовому заданию, восстанавливать ТП из сканированных документов, строить его по чертежу и переносить результат непосредственно в структуру технологического процесса.
https://rutube.ru/video/5e90995f470180dfbde0f403d94662f5

В РФ это вроде бы первый такой пример. На западе это есть например как Manufacturing Planning Agent в Teamcenter Manufacturing Easy Plan 2606
https://blogs.sw.siemens.com/teamcenter-manufacturing/2026/07/28/whats-new-in-teamcenter-manufacturing-easy-plan-2606/

или CAM Assist для GibbsCAM
https://www.cloudnc.com/news-room/cam-assist-the-first-ai-plug-in-for-cam-is-now-available-for-gibbscam


По мере того как ИИ-агенты будут брать на себя всё бОльшие фрагменты инженерной работы, главным ограничением станет контроль результата, трассируемость, прозрачность происходящего. Агенты смогут определять затрагиваемые инженерные объекты, сопоставлять контекст из CAD, PLM и ERP, даже CRM, проверить структуру изделия, оценить последствия изменений, причём не только сугубо инженерные. Инженеру и менеджеру нужно видеть, какие версии объектов использовались, какие ограничения учтены, что и почему находится в контексте изменения, к чему оно приведёт. Поэтому согласование должно относиться к конкретному состоянию данных и отменяться при его существенном изменении. Работа инженера постепенно смещается от выполнения операций к проверке решений агентов. Как и в программировании, роль инженера будет стремится к слиянию с ролью менеджера.

Для CAD/CAE/CAPP/PLM это особенно важно: изменение редко остаётся внутри одной системы. Геометрия может затронуть EBOM и MBOM, технологию, материалы, расчёты, закупки и документацию. Поэтому предложение агента должно быть проверяемым решением: что меняется, на каких данных оно основано и чем подтверждены выводы. Для CAE важен не только итог расчёта, но и версия геометрии, сетка, граничные условия, материалы и настройки решателя. Инженер должен согласовывать воспроизводимое обоснование, а не текстовый ответ. Между агентами и корпоративными системами потребуется слой контроля, который собирает контекст из разных источников и оставляет человеку только то, где требуется инженерное суждение. Ревизии, состояния объектов, связи, ограничения и численные пороги лучше проверять автоматически. По мере накопления доверия типовые изменения смогут всё чаще выполняться без участия человека, а инженер будет разбирать главным образом исключения и рискованные случаи. Однако сначала доверие надо будет накопить, это не будет происходить автоматически, стартовать будет с позиций явного скептицизма и открытого сопротивления.

Особую ценность из-за этого получает история решений, их трассируемость, прозрачность. Важно сохранять не только факт утверждения, но и исходные данные, доказательства, альтернативы, причины выбора и иной контекст. Формировать человевекочитабельную сводку и развёрнутое представление. Скорее всего PLM придут к хранению не только то, что изменилось, но и причин изменения, контекста в том состоянии в каком изменение производилось. При этом CAD, PLM, ERP, MES, QMS и другие системы могут оставаться владельцами своих данных: необязательно собирать всё в одной базе, важнее уметь сформировать доверенный и версионированный контекст решения.

В итоге основным интерфейсом инженерной работы с ИИ может стать не редактор BOM, процесс согласования или чатбот, а среда проверки решений, связывающая предложения агентов, инженерные доказательства и выполнение изменений. Она может быть распределена между CAD, CAE и PLM, сохраняя единый объект решения. Если PLM останется системой форм, BOM и жёстких процессов, этот слой возникнет над ним. Следующее поколение PLM, вероятно, будет управлять не столько данными изделия, сколько проверяемыми изменениями, которые совместно выполняют люди и агенты.

Класс таких систем можно назвать
Engineering Decision Control — EDC
Engineering Decision Assurance — EDA
или
«Система управления инженерными решениями», «Система контроля инженерных решений», «Платформа инженерных решений», «Инженерный контур доверия» в русскоязычном варианте.




Концепт «PLM для агентов» предполагает вынос основной ценности PLM из пользовательского интерфейса в исполняемую среду, с которой ИИ-агенты работают напрямую. Не строить ещё один PLM без экранов, а дать агентам модель инженерных объектов, версий, конфигураций, связей, жизненного цикла, правил изменений и полномочий. Агент должен оперировать не таблицами и CRUD, а инженерными намерениями: заменить компонент, оценить последствия изменения, создать конфигурацию, проверить требования, подготовить выпуск.

Это возможно потому, что основная ценность PLM находится не в интерфейсе. Карточки, деревья составов и маршруты согласования лишь отображают более фундаментальную модель: устойчивую идентичность объектов, версии, связи, состояния, действующие конфигурации и историю изменений. PLM определяет, какая ревизия считается официальной, что можно изменять, какие объекты будут затронуты и какие проверки нужны перед выпуском.

Для агента эти правила должны быть формализованы и исполняемы. Ему недостаточно API для изменения BOM. Он должен уметь определить, допустима ли замена компонента, нужна ли новая ревизия, какие требования и изделия она затронет и кто должен утвердить результат. Поэтому «PLM для агентов» разумнее строить как среду инженерных операций, где система сама рассчитывает последствия, проверяет ограничения и формирует набор предлагаемых изменений.

Такой слой необязательно должен становиться новой системой хранения. Он может работать поверх Teamcenter, IPS, Windchill, Лоцман, Aras, T-Flex, 3DEXPERIENCE, PDM, ERP, CAD и других систем, оставляя их владельцами данных, но предоставляя агенту общую модель деталей, документов, требований, конфигураций и изменений. Это отличает его от обычного MCP-сервера: MCP даёт инструменты, а «PLM для агентов» задаёт пространство допустимых инженерных действий и гарантии их корректности.

В основании такой системы может лежать универсальная модель управляемых объектов, типизированных связей, версий, состояний, наборов изменений, политик, полномочий и происхождения данных. Тогда PLM становится одной из специализаций более общего runtime для управляемых действий. В AI-native архитектуре именно эта исполняемая модель может стать ядром системы, а UI — лишь одним из клиентов наряду с агентами, CAD, скриптами и корпоративными приложениями.


Опубликовали «дорожную карту» MCP (Model Context Protocol), в которой обозначили переход от простой схемы «модель вызвала инструмент — получила ответ» к инфраструктуре для корпоративных агентных систем. Особое внимание уделено готовности к корпоративному применению: агентам нужны собственная идентичность, ограниченные полномочия и безопасная передача части прав субагентам. Вместо ключей API и долгоживущих токенов MCP движется к стандартным механизмам идентификации программных процессов, федерации идентичности и обмена токенами, чтобы встроить агентов в существующие корпоративные системы управления доступом.

Одновременно MCP развивается от синхронных вызовов к событийной модели. Задачи предназначены для операций, которые могут длиться минуты или часы, а триггеры, события, подписки, уведомления о ходе выполнения и обратные вызовы позволят серверу самому сообщать агенту о завершении работы или изменениях вместо постоянных проверок. Развивается и работа с большими результатами: вместо передачи огромного JSON в контекст модель сможет получать ссылки на документы, файлы и другие ресурсы, читать их частями, использовать кэширование и отслеживать версии.

При этом разработчики не хотят раздувать ядро MCP. Новые корпоративные возможности предполагается развивать через расширения с едиными правилами объявления возможностей, совместимости и версионирования. Удачные расширения впоследствии смогут становиться частью стандарта. В итоге идентификация и делегирование прав, задачи, триггеры и события, потоковые и ссылочные результаты и расширяемость выводят MCP далеко за пределы обычного интерфейса вызова инструментов искусственного интеллекта: он превращается в базовый инфраструктурный слой для распределённых агентных систем.

https://blog.modelcontextprotocol.io/posts/mcp-roadmap/


The Exploration Company приобрела у LEAP 71 пятилетнюю лицензию на систему Noyron RP для разработки ракетных двигателей. Эта ИИ система не просто управляет CAD и не генерирует форму по текстовому описанию. В систему заложены физика, инженерные правила, ограничения производства и результаты реальных испытаний. Инженер задаёт требования к будущему двигателю, а Noyron рассчитывает конструкцию и создаёт геометрию, которую затем можно проверить в CAE, изготовить и испытать. То есть автоматизируется уже не столько работа в CAD, сколько значительная часть самого проектирования.

The Exploration Company собирается применять Noyron при создании собственных двигателей, включая перспективный Storm. Главная цель — намного быстрее проходить цикл от идеи до испытаний: задать требования, получить конструкцию, изготовить её, испытать, вернуть результаты в модель и создать следующий вариант. Вместо множества ручных итераций инженер получает систему, способную быстро исследовать большое число возможных конструкций, оставляя CAE и физические испытания средствами проверки результата.

https://www.exploration.space/blog/the-exploration-company-licenses-leap-71s-noyron-rp-for-the-design-of-next-generation-rocket-engines


Видео недоступно для предпросмотра
Смотреть в Telegram
Plamo, про который мы писали здесь
https://t.me/BOM_Voyage/307
Ориентировано больше на строения, BOM, как Revit.

Запустили бету, можно пробовать (кнопка "try it free)
https://illoca.com/plamo


Видео недоступно для предпросмотра
Смотреть в Telegram
Не очень понимаю зачем тут ИИ, в кадре обычный критический путь, все делается уже много лет без ИИ, ну да ладно.

Демонстрация ИИ чатбота который помогает осуществлять управление проектными рисками в ENOVIA.


Исследователи MIT разработали GIFT — подход, который помогает мультимодальным моделям точнее превращать 2D-эскизы и текстовые описания в CAD-модели. Результатом становится не просто 3D-геометрия, а исполняемая CAD-программа с последовательностью операций построения, которую можно редактировать, параметризовать и использовать дальше в инженерном процессе. Основная проблема таких систем в том, что современные модели уже неплохо пишут код, но гораздо хуже восстанавливают по изображению правильную геометрию и конструктивную логику модели.

GIFT решает эту проблему через обучение модели на собственных результатах. Она несколько раз выполняет одну задачу, а система выбирает случаи, где часть попыток успешна, а часть содержит ошибки. Правильные и автоматически исправленные решения превращаются в новые обучающие примеры. Таким образом, ресурсы расходуются не на общее расширение CAD-датасета, а на конкретные операции и типы геометрии, с которыми модель пока работает нестабильно.

В экспериментах GIFT повысил точность генерации CAD и потребовал примерно пятую часть вычислительных затрат по сравнению с несколькими альтернативными подходами. Пока основная цель — геометрическая корректность, но следующий шаг предполагает добавление инженерных критериев: ограничений, эксплуатационных характеристик и технологичности. В перспективе это путь к AI-to-CAD системам, которые смогут самостоятельно улучшать навыки моделирования и учиться создавать не просто похожую геометрию, а инженерно корректные модели.

https://meche.mit.edu/news-media/better-way-turn-2d-designs-3d-models-rapid-prototyping




В честь пятницы забавное из мира геймдева


Видео недоступно для предпросмотра
Смотреть в Telegram
Сименс хвастается что они осилили реализовать RAG и выкатили чатбота :)

https://blogs.sw.siemens.com/insights-hub/2025/01/30/production-copilot-ai-assistant-for-production/

P.S. многие ещё и этого не смогли


^^

И есть ещё одна область где пространственное мышление совершенно необходимо - автономные роботы.

И учитывая объём инвестиций в эту область можно быть уверенным, что революция в пространственном мышлении ИИ не за горами. Даже скорее давно уже состоялась и речь скорее про переток соотв. знаний из закрытых коммерческих моделей компаний производящих роботов в обычные LLM. Скорее всего свои успешные решения они пока что держат закрытыми. Конкуренция в этой области сейчас огромна.

Показано 20 последних публикаций.