BOM Voyage

X.509 — это стандарт IETF для цифровых сертификатов, который связывает некоторую идентичность с публичным криптографическим ключом. Главная задача X.509 — аутентификация и построение доверия в системах с открытыми ключами, то есть PKI — Public Key Infrastructure. Например на нём построен TLS (а HTTPS это по сути HTTP + TLS), то есть, по сути весь современный интернет.

Так вот, вчера IEFT опубликовали 4-ую версию экспериментального Internet-Draft X.509 Certificate Profile for Autonomous AI Agent Identity, в котором добавив расширение AgentIdentity - инфраструктуру идентификации агентов которая будет встроена в один из самых базовых всемирных инфраструктурных уровней.

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

https://datatracker.ietf.org/doc/draft-sharif-x509-agent-identity-profile/

^^

Вспомнилось в связи с интересной статьёй на arXiv - Self Improvement via Fast Tree-search

Там про SIFT (Self-Improvement via Fast Tree-search) — подход к автоматическому улучшению harness программного ИИ-агента, то есть кода и инструкций, которые организуют работу базовой языковой модели. Система создаёт новые варианты этой обвязки: меняет инструкции, добавляет инструменты, корректирует обработку ошибок и порядок запуска тестов, после чего проверяет, какие изменения действительно повышают результативность. Главная проблема такого поиска не столько в создании новых вариантов, сколько в их проверке: полноценный прогон каждого harness на большом наборе задач быстро начинает потреблять основную часть времени и вычислительных ресурсов.

В SIFT между созданием нового варианта и его полной проверкой добавляется быстрый промежуточный этап. Отдельная языковая модель попарно сравнивает реализации harness и определяет, какая из них с большей вероятностью будет работать лучше. Она не заменяет реальные тесты и не пытается точно предсказать итоговый результат, а помогает выстроить относительный порядок кандидатов. Результаты сравнений объединяются в общий рейтинг с помощью модели Bradley–Terry, после чего поиск направляется в наиболее перспективные ветви. Создание новых вариантов и их полные проверки выполняются параллельно: если версия прошла небольшую предварительную проверку и получила высокий рейтинг, от неё можно продолжать развитие, не дожидаясь завершения длительных тестов.

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

Разбор на английском:
https://venturebeat.com/orchestration/new-mit-and-sakana-ai-framework-uses-an-llm-judge-to-cut-evaluation-costs-for-self-improving-coding-agents

По сути это более сложный вариант того что я описал выше. Возможно более мощный, но сложность явно выше на два порядка.

Кстати, всё забываю поделиться лайфхаком.

В своей работе (программирование) у меня есть следующий AI workflow для работы с повторяющимися проблемами:

1) В ходе работы над задачей агенты записывают какие их решения, действия были неудачными, не приблизили решение, но потратили токены и время на бесполезные или временные действия. Эти записи сохраняются как список md файлов со ссылкой на задачу и кратким контекстом.

2) По завершении работы работы этот анализ ретроспективно повторяется чтобы не были упущены длинные отклонения "от оптимального маршрута решения".

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

4) Следующий агент читает эту папку "повторяющихся проблем" и думает как можно предотвратить дальнейшее повторение таких ситуаций - модификация базы знаний репозитория и/или проекта (кстати это отдельный вопрос который я подниму чуть позднее), инструкции агентов, скиллы, исправления инструментов и т.п. Агент сам оценивает сложность изменений - требуется ли ревью, проверка человеком (предлагает мне) или делает исправление самостоятельно. Моделирует проблемную ситуацию и проверяет что исправление улучшает процесс, если решит что полезно - записывает как тестовый сценарий, новую метрику и т.п., смотрит как влияет на прочие метрики.

Таким образом инструкции агентов, их скиллы, инструменты постоянно и автоматически совершенствуются при моём минимальном участии и контроле.

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

И это очевидно может быть перенесено и в любые другие сценарии использования ИИ, в том числе инженерные.

UPD: через 3 часа после написания придумал как улучшить это — используя подход
https://github.com/Avinash-jetwani/jevmem
в котором база знаний наполняется дешёвым Jev которой перехватывает переписку хуками.

перехват хуками — после всех действий агента: отправка новой инструкции, получение ответа агента и т.п. событие может быть перехвачено и использовано другим агентом, отличным от того, что выполняют основную работу. Это может быть дешёвая модель (например Jev) которая может параллельно выполнить какую-нибудь дополнительную работу - дополнить базу знаний, базу ошибочных действий и т.п. В этой схеме основная модель не отвлекается от основной задачи, плюс основная модель может быть достаточно дорогой, которую нерационально расходовать на подобное конспектирование.

Autodesk: Beyond the Prompt: Why Intent and Context Matter in Design and Manufacturing AI

Autodesk описывает свой vision того должна выглядеть их следующая модель инженерного ИИ: агент должен работать не только с отдельными запросами пользователя, а понимать общий контекст проекта и цель изменений. В этот контекст входят геометрия изделия, материалы, нагрузки, требования, варианты конструкции, оборудование, допуски, история принятых решений, стоимость и корпоративные правила.

MCP должен помогать передавать этот контекст между CAD, производственными и бизнес-системами, а Autodesk Assistant — постепенно переходить от ответов на отдельные вопросы к выполнению связанных цепочек действий: например, изменить параметры модели, создать новую конфигурацию и подготовить данные для производства.

Для PLM это означает, что возможности такого агента всё сильнее зависят не только от самой языковой модели, но и от того, насколько полно она видит данные об изделии и понимает замысел конструктора.

https://www.autodesk.com/products/fusion-360/blog/beyond-the-prompt-why-intent-and-context-matter-in-design-and-manufacturing-ai/

ClassCAD.ai — не надстройка над существующей CAD-системой, а самостоятельное CAD-ядро без собственного интерфейса: оно умеет строить точную NURBS-геометрию, создавать параметрические детали и эскизы с ограничениями, работать со сборками и экспортировать модели в STEP. ИИ-агент управляет этим ядром напрямую через MCP. Пользователь описывает модель обычным языком, а ИИ определяет последовательность операций: создаёт эскизы и зависимости, выполняет выдавливания и логические операции, формирует отверстия, массивы и скругления. В результате получается точная параметрическая модель с историей построения и выражениями, которую можно изменять и пересчитывать при изменении исходных размеров.

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

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

https://classcad.ai

Опубликован экспериментальный IETF Internet-Draft, предлагающий модель исполнения автономных агентов, в которой доказательство реального результата действия не просто записывается постфактум, а становится техническим условием для получения права выполнить следующий шаг. Проект явно разделяет предложенное агентом действие и полномочие сделать это действие реальным.

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

https://datatracker.ietf.org/doc/html/draft-das-receipt-gated-iev-00

IETF — Internet Engineering Task Force, «Инженерный совет Интернета». Это одна из ключевых организаций, которая разрабатывает технические стандарты, обеспечивающие работу Интернета как единой сети. Это не государственная организация и не орган, который может юридически заставить компании выполнять стандарт. Ее сила основана на отраслевом консенсусе и совместимости. Если Microsoft, Google, Apple, Cisco, Cloudflare, AWS, операторы связи и разработчики открытого ПО хотят, чтобы их системы нормально взаимодействовали через Интернет, им практически неизбежно приходится следовать соответствующим стандартам IETF.

Главная область IETF — протоколы и инфраструктура Интернета: как компьютеры находят друг друга, устанавливают соединения, передают пакеты, шифруют трафик, обмениваются электронной почтой, взаимодействуют по HTTP, маршрутизируют сети и т. д. В отличие, например, от ISO, IETF специализируется прежде всего на реально используемых сетевых протоколах.

SimScale опубликовали реальные результаты нескольких производственных agentic-engineering пилотов; это существенно полезнее прежних общих описаний их архитектуры.

У Dexory агент автоматически выполняет повторяемую настройку сложных расчётных моделей роботизированной башни, где один сегмент содержит 198 контактов и 192 болтовых соединения. В отдельной задаче оптимизации теплоотвода агент примерно за 20–30 минут нашёл ориентацию, снизившую температуру на 12 °C.

У Convion традиционная оптимизация эжектора требовала 500–1000 CFD-вариантов и занимала недели. Параметрическую модель сделали в Onshape, пакет расчётов выполнили в SimScale, после чего обучили Physics AI surrogate. Сам оптимизационный цикл теперь занимает 10–15 минут; полученная конструкция стала примерно на 50% компактнее, а результат AI-оптимизации отличался от полной CFD-оптимизации менее чем на 5%.

кроме того описан межсистемный сценарий CoLab → SimScale: CoLab формирует DFM-замечания из собственных правил заказчика; в пилоте автомобильного поставщика первая выдача имела более 80% релевантности. После подтверждения инженером замечания об увеличении толщины рёбер SimScale-агент сам нашёл соответствующие поверхности, изменил геометрию и повторно запустил расчёт, чтобы проверить изменение напряжений и перемещений.

https://www.simscale.com/blog/agentic-unlocks-recap/

И обязательное пятничное несерьёзное

Endra показает полный агентный цикл электропроектирования: примерно неделя работы — за три часа.

В видео восьмиэтажное здание проходит через разводку цепей, подбор кабелей, формирование panel schedules и выпуск готовых для Revit чертежей;
Endra утверждает, что процесс, обычно занимающий около недели, занял примерно три часа.

https://aecmag.com/mep/endras-ai-turns-a-week-of-design-into-hours/

и заодно хорошее видео изрекомендаций про тесно связанное с управлениями требованиями, но на гораздо более системном уровне. В основном в CATIA

Model-Based Systems Engineering (MBSE): A Beginner's Guide

https://www.youtube.com/watch?v=7IanzYffleY&list=PLObi3o8pH9TEthYwtaE1fnYVZtU0HTbar

и презентация уже как 3-летней давности

https://www.youtube.com/watch?v=DqlOcPjAo00

Полюбопытствовал как выглядит UI их решений.

Простенько, но достаточно современно и кажется должно быть удобно.

Flow Engineering — это стартап, который пытается построить не просто ещё одну систему управления требованиями, а «инженерный control plane» для разработки сложного hardware. Их основная идея: связать requirements, архитектуру системы, CAD, расчёты, код, испытания и документацию в единый живой граф, а поверх него запустить AI-агентов, которые отслеживают изменения и автоматически анализируют их последствия. Сами они сейчас называют продукт «agentic systems engineering platform».

Самая интересная часть Flow — именно модель изменений. В обычной RM/PLM-системе объект редактируется, после чего запускаются change request/change order/workflow. В Flow предполагается другой паттерн: инженер или агент создаёт branch, изменяет там требования, архитектуру, тесты и другие сущности, система показывает diff и downstream impact, нужные инженеры делают review, после чего branch сливается в baseline. Baseline при этом остаётся стабильным. Для PDR/CDR, поставщиков и сертификации можно оставлять отдельные стабильные состояния. Есть обязательные reviewers, immutable baselines и история того, кто что одобрил.

Второй фундаментальный элемент — Systems Graph. Flow говорит не просто о дереве requirements: в одном графе могут находиться requirements, systems, interfaces, tests, CAD artifacts, compliance artifacts и другие сущности. Модель данных конфигурируемая — можно определять собственные типы сущностей и их поля. Через публичный REST API доступны projects, entities и relationships. Поэтому концептуально это уже довольно близко к универсальной object–relation модели, хотя из публичной документации нельзя сделать вывод, как физически реализовано хранилище — graph DB это или реляционная БД с graph abstraction.

Flow Agents реагируют на инженерные события. Например:
CAD-модель изменилась → агент определяет связанные requirements → обнаруживает изменение массы → проверяет mass budget → находит нарушенное ограничение → помечает связанные tests/certification evidence как устаревшие → при необходимости запускает анализ → создаёт изменения в отдельной branch → отправляет инженерам на review.

Среди пользователей уже Rivian, Anduril, Joby, Stoke Space и другие; Flow сообщает, что внутри Rivian использование выросло с 40 до 1 500 инженеров за семь месяцев.

Так вот, они хвастаются что подняли $50 млн инвестиций на фактически «агентный PLM/Systems Engineering» для сложного hardware. При оценке в $750 млн.
https://www.flowengineering.com/blog/series-b-press-release

​​Ремонт на опережение: нейросеть предскажет поломки оборудования за 12 часов

На МКС-5000 выксунского завода ОМК внедрили систему машинного обучения и благодаря этому сократили брак и аварийные простои стана. Более 6,3 миллиона рублей в год позволяет экономить система даже при неполной загрузке МКС-5000. При высокой загрузке эффект многократно возрастает.

В основе нового подхода – статистическая модель работы оборудования, которая обнаруживает аномалии задолго до его отказа.

Читать статью

Очередная новость про росатомовские (твэловские) 3D-принтеры. На выставке «ИННОПРОМ. Беларусь» был представлен малогабаритный 3D-принтер RusMelt 150M, изготовленный с использованием российских и белорусских компонентов.

Механика, кинематика и конструкции изготовлены белорусскими предприятиями. От российской стороны - лазерная система, система управления и ПО. Доброе утро, атом!