Physical AI: От нейросетей к гуманоидным роботам

Ранас Мукминов

Physical AI: От нейросетей к гуманоидным роботам

Physical AI: От нейросетей к гуманоидным роботам

Введение

До недавнего времени «искусственный интеллект» в рабочем разговоре инженера или продакта почти всегда означал одно и то же: модель за API, вход — текст или картинка, выход — ещё текст или разметка. Ошибка стоила неловкого ответа или плохого ранжирования. Её можно было откатить релизом, спрятать за порогом confidence или просто попросить пользователя переформулировать запрос.

Как только у модели появляется тело — приводы, пальцы, колёса, корпус на двух ногах — цена той же ошибки меняется качественно. Неверный крутящий момент не «генерирует плохой токен». Он бьёт по детали, роняет робота или цепляет человека за рукав. Задержка в 200 мс, которую чат спокойно переживёт, в контуре баланса уже похожа на головокружение. Датасет нельзя докачать с веба: его надо снять телеоперацией, насинтезировать в симе или мучительно собрать на площадке, где свет другой, пол скользкий, а оператор устал к концу смены.

Эту область мы будем называть Physical AI — не как бренд, а как ярлык для систем, где обучение и вывод модели вплетены в восприятие и действие в физическом мире. Книга как раз про разрыв между «нейросеть умеет» и «железо делает это восемь часов подряд, без режиссёра за кадром».

Что ломается при переходе от экрана к телу

Цифровой стек последних лет привычен: токены, батчи, GPU в облаке, логи запросов, A/B, cost per 1K tokens. Physical AI часть этого стека переиспользует — особенно обучение представлений и большие pretrained-бэкбоны — но ломает несколько молчаливых допущений.

Действие плохо откатывается. Undo в чате — кнопка. Undo на складе — простой линии, акт, иногда травма.

Время жёстче. Контактные задачи и удержание баланса живут в циклах, где миллисекунды не риторика. Можно вынести «рассуждение» на более медленный контур, но низкоуровневый контроль так не размазать. На практике почти всегда получается двухуровневая схема: быстрый слой (сервоконтуры, рефлексы, safety stop) и медленный (планирование, язык, выбор навыка). Путаница уровней — частая причина демо, которое «иногда взлетает».

Разберём тот же разрыв на одном бытовом для завода примере — не как кейс-стади с выдуманными процентами, а как схему потоков. Допустим, задача: взять деталь из тары и положить в оснастку. В цифровом мире «успех» — модель правильно назвала класс объекта на фото. В Physical AI успех — замкнутая цепочка: камера/глубина дали позу с известной ошибкой; хват выбрал точки контакта; контроллер силы не раздавил деталь; траектория не задела соседний стол; цикл уложился в такт; при сбое захват не «завис» с деталью в воздухе. Обрыв в любом звене обнуляет пользу модели зрения, даже если её mAP на датасете радует.

На схеме это выглядит почти скучно:

сенсоры → оценка состояния → выбор навыка/политики → низкоуровневый контроль → актуаторы → снова сенсоры.

Сбоку торчат три сущности, которые часто забывают нарисовать: часы (кто задаёт deadline циклу), safety supervisor (кто имеет право рубить питание/движение), человек (teleop, подтверждение, авария). Если на вашей архитектурной картинке этих трёх нет, картинка врёт уже на этапе слайда.

Данные дороже и кривее. Успешный эпизод хвата — это минуты калибровки, синхронизации сенсоров, разметки или teleop. Синтетика помогает, пока трение, люфты и задержки связи не напомнят о себе на железе. Sim-to-real здесь не тема доклада, а еженедельный источник сюрпризов.

Модель — не продукт. Без калибровки камер, без middleware, без понятного fail-soft и без человека, который знает, какую кнопку жать при странном писке редуктора, политика останется красивым роликом. Ролик можно снять за день. Эксплуатацию — нет.

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

Есть ещё сдвиг, о котором на слайдах говорят реже: человек в контуре меняет роль. В чате он редактор ответа. Рядом с роботом он бывает телеоператором, супервайзером зоны, автором демонстраций, техником и тем самым «препятствием», которое система обязана не задеть. Если в спецификации не разделено, где человек обязателен, а где его присутствие маскирует дыру в автономии, пилот будет врать всем участникам сразу — включая самих разработчиков.

Полезно явно развести три горизонта, которые в разговорах сваливают в кучу. Research-demo: сцена под контролем, цель — показать новый алгоритм. Engineering pilot: сцена заказчика, цель — измерить вмешательства и простой. Production cell: регламенты, запчасти, ночные дежурства, отчётность по инцидентам. Один и тот же корпус робота может побывать на всех трёх горизонтах, но критерии и стек ответственности разные. Самая дорогая путаница — продавать заказчику язык production, имея на руках только research-demo и веру в следующий чекпоинт.

Зачем писать длинную книгу сейчас

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

Длинный ответ чуть конкретнее. Сейчас в одной комнате встречаются люди с несовместимыми словарями. ML-инженер говорит про policies, evals и distribution shift. Классический robotics — про кинематические цепи, impedance control и ISO-зоны. Embedded — про циклы, jitter и теплопакет. Продакт — про payback и SLA. Пока эти языки не пересекаются, спор выглядит идеологическим: «нужен foundation model» против «нужна нормальная оснастка». Обычно нужны оба — в разных местах контура — и ещё честный список того, чего не делать вовсе.

Подзаголовок «От нейросетей к гуманоидным роботам» выбран нарочно остро. Гуманоид — не единственная и часто не лучшая морфология. Колёсный AMR, стационарный манипулятор или узкий medical device закрывают свои задачи спокойнее и дешевле. Но гуманоидная форма вытаскивает наружу почти все напряжения Physical AI разом: энергобюджет, баланс, кисти, взаимодействие со средой, сделанной под человека, ожидания прессы и регулятора. Разобрав жёсткий случай, проще понять, что можно упростить, когда ног две не нужно.

Ещё один практический водораздел — переносимость. Политика, обученная на одном гриппере и одной таре, может развалиться при смене пальца или вкладыша. Карта склада для AMR не делает ходьбу гуманоида «бесплатной» на том же полу: контактная механика другая, энергия другая, отказы другие. Имеет смысл явно помечать в проектной документации, какие куски стека вы считаете морфологически универсальными (например, пайплайн версионирования датасетов), а какие — привязанными к платформе. Иначе через полгода кто-то попытается «перенести ИИ» как лицензию на Excel.

Отдельный абзац про неопределённость железа и поставок — без драмы. Актуаторы, редукторы, батареи, вычислители на корпусе: сроки и цены скачут, документация бывает дырявой, совместимость прошивок — отдельный квест. Архитектура, которая предполагает единственного поставщика «идеальной кисти», хрупка. Архитектура, где навык хвата параметризован и вы можете сменить концевой эффектор ценой калибровки и дообучения, живёт дольше. Это не призыв к бесконечной модульности (она тоже стоит денег), а напоминание закладывать точки замены там, где рынок реально нестабилен.

Сравнение с классической промышленной автоматизацией здесь уместно без войны лагерей. Жёсткая оснастка и заранее прописанный цикл выигрывают там, где вариативность низкая, такт известен, деталь одна и та же месяцами. Обучение действию начинает окупаться, когда номенклатура плывёт, переналадка дорогая, а программирование траекторий съедает календарь. Но «окупается» — слово экономическое: нужны цифры простоя и стоимости часа интегратора, а не эстетическое предпочтение нейросетей. Где цифр нет, лучше честно писать «гипотеза» и ставить короткий пилот на узком срезе, а не на всей линии.

О неопределённости тоже лучше сказать сразу. По состоянию на 2026 год отрасль сидит между лабораторными прорывами и редкими пилотами, которые переживают первую настоящую смену. Публичные оценки рынка и сроков «массового внедрения» расходятся сильно; где в книге появятся цифры, они будут либо с опорой на проверяемый источник, либо явно помечены как оценка. Фальшивая точность («к 2028 году заменят 30%») здесь хуже честного «неизвестно, зависит от стоимости актуаторов, данных и регулирования».

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

Кому текст полезен, а кому лучше другая полка

Если вы собираете или принимаете embodied-систему — ML, robotics, embedded, systems, technical PM, руководитель пилота на заводе или в логистике — вы в целевой аудитории. Ожидается знакомство с базовым ML и с тем, как устроен нормальный софт (логи, версии, CI). Курса по аналитической механике не требуется; нужные понятия будут появляться по ходу, без попытки заменить учебник.

Текст пригодится и тем, кто сидит сбоку от железа, но влияет на решение: safety, юристы product-facing команд, люди, которые пишут требования к данным с камер. Им не обязательно читать про редукторы подряд. Структура позволяет брать слои.

Про аудиторию стоит добавить неприятную, но полезную деталь. Книга предполагает, что читатель готов к смешанному жанру: то абзац про impedance и люфты, то про unit economics сервиса, то про то, почему eval из статьи не ловит ваш дефект освещения. Если хочется только «про модели» или только «про рынок», текст будет раздражать пропусками. Это сознательно: разрывы между слоями — место, где проекты умирают.

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

Рабочий тест на «моя ли это книга»: можете ли вы после пары глав заполнить один лист — сценарий, сенсоры, контур управления, источник данных, режим отказа, метрика успеха пилота, грубая стоимость часа полезной работы. Если лист не собирается, проблема обычно не в харизме корпуса на видео.

Что внутри маршрута — и что сознательно вынесено за скобки

Книга идёт от вопроса «что это?» к вопросу «что делать на нашей площадке?». Двенадцать частей — не декоративное оглавление, а слои одной системы. Ниже — зачем они стоят именно так; без списка «глава 1, глава 2» ради галочки.

Сначала нужна общая карта. Иначе люди спорят о ярлыках: Physical AI как любой робот с нейросетью, как только гуманоид, как digital twin завода. Зафиксируем рабочие определения, разберём, как язык и зрение стыкуются с действием, пройдём стек «сенсоры → модель → контроль → актуаторы» и посмотрим на рынок как на набор ставок с разными горизонтами риска — не как на таблицу победителей сезона.

Дальше — восприятие. Камера без калибровки врёт уверенно. Лидар теряет лицо на стекле и блестящем металле. IMU и тактильность часто вспоминают после первого скольжения. SLAM — не «фича в бэклоге», а способ привязать действие к месту, когда сцена не лабораторная. Мультимодальное слияние на слайде выглядит стрелочками; в рантайме это разные частоты, разные задержки и разные отказы. Полезный вопрос к любому демо: что система увидит, если освещение, грязь или загрузка CPU станут на шаг хуже?

Сенсорный стек тоже лучше представлять не списком покупок, а как набор гипотез о мире. «Нам хватит RGB» — гипотеза о освещении и текстурах. «Нужен лидар» — гипотеза о геометрии и бликах. «Нужна тактильность» — гипотеза о том, что контактные силы нельзя надёжно вывести из зрения. Гипотезы стоит фальсифицировать рано: один день на площадке с временным сенсором дешевле, чем квартал обучения политики под неверный набор входов. И да, иногда фальсификация выглядит обидно: любимая архитектура становится не нужна, потому что задача закрылась упором и двумя концевиками. Хороший исход.

Затем политики и обучение действию. Imitation learning, RL в симе и на железе, попытки robotics foundation models, планирование и память в контуре, где нельзя «подумать минуту». RL на реальном корпусе дорог и опасен; сим снимает часть боли и добавляет свою. Классический планировщик и конечный автомат иногда скучнее и надёжнее чёрного ящика — особенно там, где инварианты безопасности нельзя «выучить приблизительно». На практике чаще живут гибриды: обучение закрывает вариативность хвата, жёсткий слой держит ограничения.

В части про мозг робота мы отдельно остановимся на соблазне всё свести к одной большой модели «от пикселя к току». Такие демонстрации бывают впечатляющими. В эксплуатации чаще живут разрезанные контуры: perception с понятными метриками; библиотека навыков; планировщик или иерархическая политика; низкоуровневый контроль с жёсткими лимитами. Большая модель может сидеть наверху — как разбор инструкции на языке или как выбор навыка — но право рубить момент на суставе у неё забирать страшно без очень зрелого safety case. Называть этот страх консерватизмом можно. На площадке с людьми он выглядит как инженерия.

Про обучение на железе — без романтики. Каждый эпизод RL или дообучения имеет стоимость: амортизация платформы, риск поломки, время оператора, простой ячейки. Поэтому в нормальных командах железо — дефицитный ресурс с очередью, а не «ещё один GPU». Имеет смысл вести простой учёт: сколько часов корпуса сожжено на эксперимент X и что изменилось в метриках площадки, не в loss. Если учёта нет, research легко съест пилот.

Отдельно придётся вернуть тело в центр. Политика не отменит люфт редуктора и не дольёт ватт в батарею. Кинематика, динамика, приводы, энергия, баланс, ходьба, кисть против простого гриппера — это потолок, а не деталь реализации. ML-инженер, игнорирующий механику, оптимизирует сим. Механик, игнорирующий данные, строит станок, который нельзя перенастроить без полугода программирования траекторий.

Данные и симуляция — отдельный слой, потому что именно здесь команды чаще всего обманывают сами себя. Телеоперация, синтетика, демонстрации, редкие успехи, доменная рандомизация, бенчмарки. Sim-to-real gap складывается из мелочей: трение, задержка шины, износ пальца, блик. Eval, удобный для статьи, может быть бесполезен для смены. Имеет смысл проектировать оценку ближе к тому, что заказчик считает простоем.

Про данные — короткий античеклист, чем не стоит измерять прогресс:

— рост параметра модели при том же числе успешных циклов на площадке;

— успех в симе без протокола переноса и без учёта задержки реального стека;

— «у оператора получилось», когда оператор — автор политики и знает все углы сцены;

— метрики на отфильтрованном ролике, где выкинуты эпизоды с вмешательством.

Нормальные, скучные метрики ближе к жизни: вмешательства на 100 циклов; время до восстановления после сбоя; доля циклов в такте; повреждения оснастки/деталей; часы техника на неделю. Если такие цифры не собираются автоматически, у вас не «мало ИИ», у вас дырка в runtime.

Runtime и софт. ROS 2 и другой middleware, edge-инференс, оркестрация навыков, наблюдаемость. Распределённая система с железом на краю: версии политик, откаты, canary на парке, метрики не только «успех эпизода», но и температура драйвера, дропы кадров, время до safety stop. Что жёстко real-time, что можно унести в асинхронный сервис — это архитектурный выбор, а не вкусовщина.

Middleware заслуживает отдельного недоверия и отдельного уважения. ROS 2 (или аналог) не сделает систему умной. Он сделает систему собираемой из узлов, с которыми могут работать разные люди. Цена — сложность конфигурации, сюрпризы QoS, необходимость дисциплины в интерфейсах. Можно писать монолит «потому что так быстрее». Быстрее — первые две недели. На третьем разработчике и второй версии политики монолит начинает мстить. Выбор здесь не моральный; он про размер команды и срок жизни продукта.

Безопасность. Не «подключим safety-classifier». Functional safety, fail-soft, human-in-the-loop, атаки на сенсоры, supply chain комплектующих. Вопросы простые и жёсткие: как отказывает система; кто замечает отказ раньше вреда; что происходит при потере лидара на полуметре от человека.

Safety case в прикладном смысле — не толстая папка ради аудита, хотя аудит тоже бывает. Это явное перечисление опасностей, барьеров и остаточного риска для конкретного сценария. Пример вопроса, который должен иметь ответ до пилота: что делает рука при обрыве ethernet к контроллеру? «Политика разберётся» — не ответ. «Механический тормоз / безопасное отключение момента / геофенс» — уже ближе. Связка ML и functional safety ещё не устоялась как ремесло с одинаковыми шаблонами везде; где шаблона нет, остаётся консервативный дизайн и ограничение сценария. Сужение сценария — валидная инженерная стратегия, не поражение.

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

Экономика продукта обычно ломается не на accuracy. Сервис, простой, энергия, обучение персонала, длина пилота, запчасти. B2B и consumer — разные игры с разными допусками на недоделанность. Пилот без заранее записанных критериев успеха почти неизбежно становится вечным POC. Иногда правильный вывод пилота — сузить задачу или сменить форм-фактор, а не «ещё один датасет».

Экономика пилота часто ломается на скрытых людях. Кроме робота в кадре есть разметчики, teleop-смены, интеграторы, safety-ответственный, ИТ, который вдруг узнаёт, что на контуре появились камеры. Если в unit economics крутится только цена манипулятора, таблица декоративна. Грубый, но честный ход: выписать роли на неделю пилота и прикинуть человеко-часы — с пометкой «оценка». Даже кривая оценка лучше нуля в ячейке.

Право и этика — не морализаторский хвост, а набор решений, которые всплывают в дизайне: кто отвечает за вред; что пишут камеры; как меняется труд; где проходит dual-use граница. Юриста книга не заменяет. Рамку вопросов для технической команды — да, и лучше до инцидента.

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

Практический блок собирает reference architecture, горизонт MVP порядка девяноста дней и чеклист готовности к пилоту. Девяносто дней — не магия, а способ не расползтись: либо подтвердили ценность на узком сценарии, либо честно зафиксировали, чего не хватает.

В финале — развилки 2026–2030: данные, энергия, регулирование, стоимость актуаторов, зрелость моделей действия. Это сценарии для планирования, не календарь пророчеств. Плюс глоссарий и источники.

Чего не будет. Обещаний сроков массовой замены профессий без оговорок. Полного курса по дифференциальной геометрии или конструкции сервоприводов «с нуля» — будет рабочий словарь и куда копать дальше. Каталога всех стартапов: он протухнет быстрее вёрстки. Секретных прошивок и инструкций, как обойти нормы безопасности. Dual-use обсуждается как граница ответственности, не как howto.

Тон тоже стоит оговорить. Ни «следующая модель всё решит», ни «роботы отнимут всё». Чаще встречаются скучные развилки: здесь ПИД и оснастка бьют любую политику; там imitation снимает месяцы ручного траекторийного ада; а узкое место вообще в кабеле, сертификации или сервисном контракте. Регуляторика зависит от юрисдикции — там, где речь о safety и данных, книга формулирует инженерные вопросы, не юридическое заключение.

Чеклист, который имеет смысл заполнить до закупки корпуса

Не ритуал ради ритуала. Если ответы пустые, рано спорить о модели.

1. Сценарий за один абзац: что именно делает система, где, с какой номенклатурой/средой, что считается циклом.

2. Граница автономии: какие шаги без человека, где teleop, где только аварийный стоп.

3. Сенсорный минимум и что будет при отказе каждого канала.

4. Контур времени: что должно укладываться в миллисекунды, что может жить в сотнях миллисекунд и секундах.

5. Данные: откуда взять первые 100–1000 полезных эпизодов, кто их снимает, как версионируете.

6. Критерий успеха пилота численно: не «в целом понравилось», а простой, брак, время цикла, вмешательства оператора.

7. Fail-soft: поведение при потере карты, при странном хвате, при человеке в зоне.

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

9. Владелец на стороне заказчика: кто принимает работу и кто вызывает техника в 2 ночи.

10. Что сознательно не обещаем в v1.

Если пункт 6 и пункт 10 не записаны, пилот уже начал врать.

Как читать чеклист из десяти пунктов выше вместе с двенадцатью частями книги: каждый пункт позже распадётся на главу или две. Сценарий и граница автономии — карта поля и применения. Сенсоры и отказы — восприятие и safety. Контур времени — runtime и контроль. Данные — сим и телеоп. Критерии пилота и экономика часа — девятая часть. Fail-soft — седьмая. Владелец на стороне заказчика — опять экономика и право, потому что без роли «кто принимает риск» контракт на пилот превращается в дружеский хаос.

Если вы интегратор, добавьте к чеклисту ещё два пункта, которые заказчик иногда забывает произнести вслух: кто имеет право менять сцену после приёмки (переставить стеллаж «чуть-чуть»), и что происходит с данными телеметрии — где лежат, кто маскирует лица, сколько хранятся. Технически это скучно. Организационно на этом рвутся пилоты.

Как читать, не утонув

Линейно: карта поля → восприятие → политики → тело → данные/сим → runtime → safety → применения → экономика → право → сборка системы → сценарии. Так видно, почему продуктовый спор упирается в редуктор или в калибровку.

Продакту и руководителю после введения полезнее прыгнуть в карту поля, применения, экономику, право и «как собрать», возвращаясь к железу точечно. ML из мира LLM/vision — не пропускать тело и runtime, иначе оптимизируете loss, который площадка не оплачивает. Классический control/robotics — не пропускать данные и экономику пилота: иначе отличный контроллер останется островом в презентации.

Термины вроде SLAM, ROS 2, policy, sim-to-real оставляем в привычном виде, рядом — русские пояснения. «Политика» для policy и «воплощённый» для embodied — сознательные кальки, чтобы стыковать локальную практику с документацией и статьями.

Сравнения подходов пойдут через критерии: задержка, sample efficiency, характер отказа, стоимость владения, прозрачность вмешательства человека. Не через «кто громче на конференции».

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

Ещё про ритм работы с текстом. Не обязательно читать миллион слов подряд — корпус задуман как протяжённый справочник-маршрут. Имеет смысл держать рядом свой одностраничный лист сценария и по мере чтения править его карандашом: что уточнилось про сенсоры, что оказалось фантазией в критерии успеха, какой fail-soft вы раньше не назвали. Книга, которую «прочитали», но не приложили к своему контуру, превращается в набор мнений. Книга, против которой вы правите свой лист, хотя бы честно показывает дыры.