Що таке Artificial General Engineer?

Повний транскрипт

Відредаговано лише пунктуацію й читабельність. Очевидні помилки розпізнавання у публічних назвах і технічних термінах нормалізовано; зміст і межі тверджень відповідають запису.

Що ж, вітаю всіх на нашому сьогоднішньому розборі.

Привіт.

Сьогоднішній аудіобрифінг створений спеціально для інженерів, технологічних інвесторів та редакторів. Ми маємо дуже конкретну мету: розібрати концепцію доказової інженерії.

Так, і відфільтрувати строгі факти від усього цього хайпу навколо ШІ, якого зараз просто занадто багато.

О, це точно. Тож наш робочий заголовок сьогодні: «Що таке Artificial General Engineer? Доказова інженерія 1UA-AGE». І для початку, щоб одразу задати правильний контекст, я маю зафіксувати базове визначення з нашого джерела: 1UA-AGE — український deep-tech проєкт, що створює Artificial General Engineer для фізичного світу.

Саме так. І тут одразу треба пояснити, що взагалі мається на увазі під цим AGE, бо це не те, що люди звикли уявляти.

Згоден. Що саме це означає на практиці?

Базове поняття звучить так: AGE — не одна модель. Система перетворює цілі й обмеження на версійовані артефакти, працює з реальними інженерними інструментами, перевіряє вимірювані властивості, зберігає докази та залишає виробництво, фізичні випробування і сертифікацію явними етапами.

Ого, так. Це досить фундаментальна заява. Тобто це кардинально відрізняється від звичних чатботів, куди ми просто пишемо промпт і чекаємо на диво.

Абсолютно. Ніхто не покладається на магію одного запиту.

Але давай подивимося на це очима звичайної людини або навіть інвестора. Зазвичай люди уявляють, що достатньо просто дати запит великій мовній моделі — і вона видасть готове креслення.

Це ілюзія.

От власне чому розробники кажуть, що AI може лише генерувати, а інженерія повинна доводити. Чому frontier-модель, найпотужніша з існуючих, не може бути самостійним інженером? Тому що інженерія — це не про розмову, це про фізику. І тут ми спираємося на п’ять стовпів справжньої інженерії, про які йдеться в матеріалах.

Так, я бачив цей перелік. Перший — це об’єктивні цілі.

Саме так. Наявність об’єктивних цілей і, що важливо, жорстких обмежень. Другий стовп — це об’єднання кількох дисциплін. Третій, і це, мабуть, найголовніше, — використання реальних інженерних інструментів для верифікації.

Тобто сама по собі розмова чи генерація коду — це ще не виконання завдання.

Сто відсотків. Модель не має права сама себе оцінювати.

Ага. Вона не може сказати: «Я зробила ідеально. Повірте мені».

Ніколи. Четвертий стовп — це збереження доказів, а п’ятий — наявність фізичних етапів. Ключова теза тут така: система не визнає свою роботу правильною. Моделі лише пропонують рішення, а верифікують їх справжні інженерні інструменти.

Окей, якщо інструменти мають верифікувати результати, то настав час подивитися на конкретні зафіксовані бенчмарки. У нас є дані щодо розробки друкованих плат, або PCB?

Так, тут є дуже точний фактаж.

Давай зосередимося виключно на виміряних метриках. Що саме було зафіксовано, наприклад, у наборі валідації STRF?

Отже, щодо STRF validation set. У документах вказано чітко: після усунення блокерів заморожений формальний набір валідації STRF мав чотири прогони.

Чотири прогони.

Так. З них три прийняті з результатом 98 із 98 необхідних з’єднань і один невдалий.

Стоп. Тут треба зробити дуже важливе уточнення. Я читав, що до цього формального тестування були численні невдалі спроби.

Звісно, були. І це нормально для процесу зневадження.

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

Абсолютно некоректно. Це дуже важливий момент, я б сказала, критичний. Це три успіхи з чотирьох прогонів саме в рамках замороженого фінального набору. Без прикрашань.

Добре, це про STRF. А щодо STM32? Там теж є цікаві цифри.

Так, щодо STM32 consistency. Тут зафіксовано три послідовні PASS-прогони.

Тобто всі три успішні підряд.

Так, від T1 до T3. Результат такий: 211 із 211 потрібних з’єднань, пройдено 19 із 19 застосовних критеріїв.

Вау!

І найголовніше для інженерів: нуль нових routing-induced DRC violations, тобто жодних нових порушень правил проєктування, спричинених трасуванням.

Ці цифри, чесно кажучи, звучать так, ніби завдання вирішено повністю. Ніби можна пакувати валізи й іти на завод.

Ой, ні, зачекай.

Але що ці метрики означають у реальному світі? Бо я, як людина з раціональним скепсисом, відчуваю тут якийсь підступ.

І правильно відчуваєш. Розробники самі дуже суворо розмежовують встановлені факти і те, що ще не доведено. Ці високі результати — це тільки completion parity, тобто паритет завершеності в межах синтетичного середовища KiCad.

Тобто плата просто зібрана програмно — і все.

Так. І тут величезний перелік того, що не доведено. Наприклад, не доведені перевага за часом виконання або перевага за топологією.

Ага. Тобто людина, можливо, розвела б ці доріжки красивіше чи ефективніше.

Саме так. По-друге, абсолютно не доведена виробнича готовність.

Тобто відправляти це на завод ще зарано.

Категорично. Також не доведена фізична валідація або загальна інженерна компетентність — те, що називають cross-domain generality.

Зрозуміло. А що тоді щодо перевірки цих результатів? Бо зараз це виглядає як внутрішній звіт компанії.

Це чудове питання. Політика розкриття доказів 1UA-AGE працює так: наразі це лише внутрішньо відтворені результати, але перший набір даних для відтворюваності вже передано на оцінку.

Тобто його перевіряють сторонні фахівці.

Так, незалежне інженерне рев’ю триває прямо зараз.

Окей, це додає довіри. Але мене турбує інша річ: оскільки вся ця система працює з реальними інженерними інструментами, її дії мають бути суворо обмеженими. Як саме забезпечується контроль над її поведінкою? Ти маєш на увазі, щоб вона не вийшла з-під контролю?

Так, щоб вона не вийшла за межі дозволеного і не наробила біди у фізичних розрахунках.

Для цього в матеріалах вводиться концепція AI-HPP Standard.

AI-HPP Standard. Що це таке, якщо простими словами?

Це публічний vendor-neutral робочий draft. Його мета — забезпечити обмежену, придатну до рев’ю та атрибутовану поведінку агентів.

Але він ще не є офіційним стандартом, так?

Ні, він не готовий до сертифікації. Це поки що робочий документ, але дуже детальний. Коли я це читав, мені на думку спала така аналогія: уяви систему шлюзів на атомній станції.

О, цікаве порівняння.

Там штучний інтелект не тримає ключів від усіх дверей одночасно. Архітектура стандарту — Signal, потім State, Gates, Bridge і наприкінці Evidence — це як двері, які відкриваються тільки за певних умов.

Так, межі доступу встановлюються поза контролем самої моделі.

Тобто модель не може сама собі дозволити щось зробити.

Ніколи. Якщо говорити про мінімальний профіль цього стандарту, так званий MVP, то там є кілька жорстких вимог. По-перше, необхідність авторизації для дій з високим ризиком.

Звучить логічно.

По-друге, збереження походження даних, або provenance. Ми маємо точно знати, звідки модель взяла те чи інше значення.

Ага. Щоб не було незрозумілих галюцинацій, вигаданих даних.

Саме так. І ще одна критична вимога — нездатність моделі приховати свої дії. Система формує так звані tamper-evident records, тобто записи, які неможливо непомітно підробити чи стерти.

Точно. Якщо модель щось зробила не так, це назавжди залишиться в логах, захищених від втручання. І якщо системі раптом бракує повноважень чи доказів для наступного кроку, що тоді відбувається? Вона зупиняється.

Так спрацьовує принцип fail closed. Вона просто блокує процес і закривається.

Жодної самодіяльності.

Вау. Це дійсно змінює уявлення про те, як ШІ має працювати в інженерії. Якщо підсумувати нашу розмову, головна ідея полягає в тому, що майбутнє AI у цій сфері — це не магічна генерація готових продуктів натисканням однієї кнопки.

Ні, ніякої магії.

Це суворо керований процес створення доказів, який постійно, на кожному етапі, підлягає рев’ю. І щоб підкреслити це, дозволь завершити обговорення трьома точними фразами, які ідеально описують цей підхід: «Замінні AI-спроможності. Один керований інженерний життєвий цикл. Докази до випуску».

Сильно сказано. Для тих, хто нас слухає і хоче зануритися в технічні деталі самостійно, ми дуже радимо звернутися до першоджерел. Усю документацію ви знайдете на сайті 1ua-age.com.

А деталі архітектури безпеки — у публічному репозиторії AI-HPP Standard.

Так. І наостанок хотілося б залишити таку невеличку провокативну думку для роздумів. Якщо в майбутньому ключовою цінністю стане не сама розумність чи масштаб моделі, а саме архітектура доказовості її дій, то як це змінить критерії, за якими інвестори та компанії сьогодні оцінюють технологічні стартапи?

Це дуже гарне питання. Пріоритети точно доведеться переглянути.

На цьому в нас усе. Дякую за розмову.

Дякую.