Где накапливается ценность в робототехнике?

Оригинал опубликован Joanna Lichter в X.

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

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

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

Теперь это узкое место начинает ослабевать. Обученные политики, робототехнические foundation models (RFM), симуляция и всё более сложные пайплайны данных резко повышают способности роботов. Но решение проблемы интеллекта не решает автоматически проблему масштабирования. Оно меняет её. По мере того как интеллект улучшается, дефицитная работа смещается от «сделать робота способным в принципе» к «сделать его надёжным, экономически оправданным и полезным в реальном мире».

Отсюда главный вопрос этой статьи: по мере роста возможностей интеллекта, где будет накапливаться экономическая ценность?

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

Почему робототехника не похожа на LLM

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

• Дистрибуция. ChatGPT достиг примерно 100 млн ежемесячных активных пользователей всего через два месяца после запуска благодаря почти нулевой предельной стоимости распространения софта через интернет, смартфоны и облака. Когда фронтирная лаборатория выпускает новую модель, сотни миллионов людей получают её почти сразу. В робототехнике такого эквивалента нет. Политики работают на воплощённых системах, которые нужно произвести, доставить, установить и обслуживать, а каждое дополнительное внедрение несёт значимую предельную стоимость железа. Даже если интеллект станет фактически бесплатным, развёртывание всё равно может сломать экономику. Поэтому робототехника фундаментально более капиталоёмка, чем софт.
• Данные. У робототехники хорошо известный разрыв в данных. Интернет дал огромный уже существующий корпус человеческого текста, изображений и видео, но сопоставимого набора данных для физического взаимодействия нет. Роботические данные также сложнее собирать и труднее обрабатывать: они мультимодальны, временно коррелированы, зависят от действий и часто привязаны к конкретному телу, среде или задаче. Индустрия движется вперёд: egocentric video data и UMI-подобные захваты расширяют воронку сбора данных, а backbone-модели мира извлекают более полезные физические priors из больших массивов видео. Но проблема данных не только в масштабе. Это ещё и вопрос того, что переносится с одного робота, среды или задачи на другую.
• Вычисления в реальном времени. LLM могут тратить больше inference-time compute, когда задача трудная. У роботов гораздо меньше свободы. Физические системы должны непрерывно замыкать цикл восприятие-действие-управление в реальном времени, что ограничивает задержку, энергопотребление и размер модели. Эти ограничения усиливаются по мере роста RFM и обработки роботами непрерывных видеопотоков с нескольких камер. Поэтому область движется к иерархическим архитектурам, например Hi Robot от Physical Intelligence или Helix от Figure, где более крупные и медленные модели отвечают за рассуждение, а меньшие политики исполняют управление в реальном времени. Итог — архитектурный компромисс, которого почти нет в LLM: больше интеллекта нельзя просто купить дополнительными вычислениями на инференсе, если это делает систему слишком медленной, прожорливой или дорогой для работы в реальном времени.
• Безопасность. В софте обновление модели можно мгновенно выкатить и при необходимости откатить. В робототехнике изменения поведения затрагивают физические системы и могут требовать тестирования, валидации или повторной квалификации перед попаданием в производство. Нагрузка зависит от домена: автономный экскаватор внутри ограниченной стройплощадки — не то же самое, что робот, перемещающийся среди людей в больнице. Но безопасность всё равно замедляет переход от улучшения модели к развёрнутой способности.

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

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

Где накапливается ценность?

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

В раннюю эпоху ПК системные сборщики вроде Compaq и Dell забирали значительную ценность, но по мере коммодитизации железа она сместилась к операционным системам и CPU, где Microsoft и Intel выиграли от масштаба и мощных экосистем разработчиков. Позже облачные вычисления абстрагировали большую часть серверной инфраструктуры, концентрируя экономику в платформах вроде AWS и Azure, которые могли амортизировать огромные фиксированные инвестиции на миллионах клиентов.

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

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

Но интеллект пока не превращается напрямую в экономически полезную работу. Развёртывание — это место, где интеллект, данные и железо сталкиваются с messy реальностью: клиентскими workflow, требованиями безопасности, обслуживанием, uptime и в конечном счёте ответственностью за экономический результат. Лучшие модели со временем должны снижать эту нагрузку, но не устраняют её. Сейчас большая часть узкого места, а значит и потенциальной ценности, лежит в превращении способности в полезную работу.

Развёртывание: moat или ловушка услуг?

Исторически системные интеграторы соединяли роботов с полезной работой: проектировали ячейки, устанавливали сенсоры и инфраструктуру безопасности, интегрировали PLC и складские системы, программировали траектории, обучали операторов, тестировали системы и обслуживали их в производстве. Около 70% существующих 400 тысяч промышленных роботов были развёрнуты системными интеграторами.

Эта работа не гламурна, но необходима. Без неё робот — просто дорогой кусок железа.

Проблема в том, что традиционная системная интеграция плохо накапливается. Промышленная автоматизация исторически опиралась на customer-specific engineering: каждое внедрение требовало существенного проектирования, интеграции и полевой работы. Значительная часть усилий тратилась на завершение проекта, а не превращалась в reusable asset для следующего. В результате рост остаётся привязанным к числу инженеров, полевой рабочей силе и географической плотности.

Это центральное различие между развёртыванием как услугой и развёртыванием как масштабируемой системой. Привлекательная версия deployment накапливает reusable assets: данные о failure modes, знание workflow, инструменты внедрения, playbook'и клиентов, fleet infrastructure и улучшения железа. Со временем работа смещается от bespoke engineering к learning loop:

Deploy → observe failures → collect data → post-train → reduce intervention → improve economics → deploy more.

Телеприсутствие и удалённое управление могут закрывать пробелы автономности, одновременно производя реальные данные. Failure modes, найденные на одном объекте, могут улучшать политики для всего парка. Инструменты deployment и интеграции workflow можно переиспользовать. Каждое внедрение должно снижать предельные усилия для следующего.

Поэтому ключевой вопрос таков: снижается ли объём человеческого труда на единицу полезной роботической работы по мере масштаба?

Ответ должен проявляться в операционных метриках, которые больше похожи не на традиционные AI-бенчмарки, а на показатели операционного рычага:

• Инженерные часы на внедрение
• Время от установки до полной загрузки
• Минуты вмешательства человека на час работы робота
• Количество роботов на одного супервайзера или сервисного техника
• Частота отказов и вмешательств по парку
• Валовая маржа на текущем и будущем уровнях автономности

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

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

Экономика клиента и экономика компании

Даже если deployment накапливается, должны сойтись две экономики: клиентская и корпоративная. Их стоит разделять, потому что они ломаются по-разному.

Клиентская экономика должна работать до наступления идеальной автономности. Клиенты не покупают процент автономности; они покупают throughput, uptime, экономию труда, безопасность или другой экономический результат. Телеприсутствие и человеческий надзор вполне приемлемы, если система уже даёт убедительный ROI. Релевантная база сравнения — текущий способ выполнения работы, включая стоимость и доступность труда. Во многих отраслях этот труд становится всё более дефицитным, дорогим или трудно укомплектовываемым. Лучшие роботические системы либо дают тот же или лучший результат с существенно меньшим человеческим трудом, либо делают возможной работу, которую клиенты не могут стабильно закрыть персоналом сегодня.

В строительстве, например, fully burdened operator во многих рынках может стоить $120 000 в год. Некоторые подрядчики также сталкиваются с текучкой 80-100% и стареющей рабочей силой, которую некому заменить. Роботы Field AI автономно картируют стройплощадки, заменяя ручной сбор данных, который инженерам проекта иначе пришлось бы повторять много раз за жизненный цикл проекта. Path Robotics автоматизирует сварку; у одного клиента система сократила требуемый человеческий труд примерно со 150 часов в месяц до 9 часов, а остальную работу выполнял робот. В обоих случаях клиент покупает не «автономность». Он покупает меньшую зависимость от дефицитного труда, более стабильный throughput или и то и другое.

Экономика компании — отдельный вопрос. Робот может давать сильный ROI клиенту и всё равно быть плохим бизнесом. Ранние внедрения могут требовать значительного engineering, teleoperation, monitoring и service, поэтому релевантный вопрос — есть ли правдоподобный путь к привлекательной марже по мере снижения этих затрат. Автономность должна быть мостом к расширению маржи; если это не так, экономика ломается. Телеператоры стоят примерно $9-12 в час через внешнего провайдера и ближе к $6-7 в час in-house. Инференс тоже не бесплатен и обычно дорожает по мере роста моделей. Поэтому точка, где автономность очевидно дешевле удалённого человека в контуре, может быть дальше, чем предполагают многие прогнозы.

Это создаёт два разных failure mode. Робот с отличным долгосрочным потенциалом автономности, но плохим ROI для клиента, будет тяжело внедрять вообще. Робот с сильным клиентским ROI, но постоянно трудоёмким deployment, может стать хорошим бизнесом, но не обязательно бизнесом венчурного масштаба. Самые сильные компании улучшают обе стороны уравнения одновременно: создают больше ценности для клиента и требуют всё меньше человеческого труда и капитала для её доставки.

Почему вертикали выигрывают первыми

Самый быстрый способ ускорить learning curve deployment — сузить домен. Модель общего назначения должна строить способности, переносимые через огромное пространство задач, сред и тел. Компания, работающая внутри одной вертикали, может оптимизироваться вокруг гораздо более узкого распределения workflow, условий среды, edge cases и требований безопасности. Это важно для качества моделей и эффективности данных, но ещё важнее для deployment, где вопрос в том, снижаются ли инженерные усилия на объект или остаются примерно постоянными.

Модели могут становиться всё более горизонтальными, но deployment остаётся упрямо вертикальным.

Логистическое внедрение требует понимания складского ПО, дизайна рабочих станций, требований throughput, обслуживания, безопасности и того, как клиент передаёт работу роботу. У строительства совершенно другой набор workflow, оборудования, ограничений безопасности и операционных метрик. Всё это не исчезает просто потому, что базовая модель стала более способной.

Возьмём Bedrock Robotics. Вместо того чтобы начинать с простой задачи автоматизации, компания фокусируется на экскаваторах внутри ограниченного мира тяжёлого строительства. Задача технически сложная, но операционный домен относительно ограничен: стройплощадки, рельеф, препятствия, поведение машины и earthmoving workflow. Каждое внедрение даёт доменно-специфические данные и операционное знание, которые могут улучшать следующие внедрения. Со временем эти способности могут расширяться на соседние задачи и машины. Deployment-компании не нужно решить всю робототехнику. Ей нужно владеть достаточно большой категорией работы.

От вертикального wedge к владению workflow

Когда deployment-компания встраивается в workflow клиента, она может расширять присутствие: дополнительные роботы, соседние задачи, fleet management, обслуживание, software и другие сервисы. Одновременно каждое внедрение генерирует операционные данные и институциональное знание, которые улучшают и продукт, и экономику последующих внедрений.

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

По мере того как роботы берут на себя всё большую часть workflow клиента, надёжность и сервис становятся частью продукта. Клиент может терпеть downtime, когда робот отвечает за 1% throughput; стандарт резко меняется, когда он отвечает за 20% или 30% производства. В этот момент switching costs начинают накапливаться. Замена робота означает изменение workflow, переобучение сотрудников, миграцию ПО и отказ от накопленного операционного знания. Поэтому цель — не просто продать робота. Цель — использовать его как точку входа к владению большей частью экономического workflow и в итоге всей категорией работы.

Ирония в том, что путь к горизонтальному масштабу в робототехнике может сначала идти через вертикальную специализацию: глубоко решить один домен, превратить deployment в reusable infrastructure, а затем расширяться по соседним workflow и машинам.

Заключение

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

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

Но мы ещё не там. Сегодня превращение способной модели в полезный роботический продукт всё ещё требует адаптации к конкретному железу, средам, workflow и требованиям клиентов, а также post-training, реальных данных, обработки отказов и сервисной инфраструктуры. Этот остаток — не тонкий слой implementation. Во многих случаях это и есть продукт.

Если каждое внедрение создаёт reusable data и операционное знание, одновременно снижая человеческие усилия для следующего, deployment может эволюционировать из service business в накапливающийся актив. Это может позволить компаниям расширяться от узкого vertical wedge к владению целой категорией физической работы.

Это возвращает меня к исходной мысли: ценность накапливается на двух концах стека. Несколько горизонтальных платформ накапливают её через масштаб данных, вычислений и экосистемной гравитации. Более многочисленная группа category owners накапливает её через глубину workflow, надёжность и операционное знание, заработанное эксплуатацией парков в поле. Середину сдавливают с обеих сторон: взаимозаменяемые модели, инструменты, которые становятся функциями, и интеграторы, добавляющие ИИ без изменения своей базовой экономики.

Почему это может оказаться неверным

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

Во-первых, deployment может стать почти zero-shot. Если достаточно сильные модели смогут обобщать через железо, задачи и среды почти без customer-specific post-training, многое из того, что я описала как «deployment as a scalable system», станет конфигурацией, а не устойчивым слоем. Я ожидаю, что какая-то версия этого появится в ограниченных средах со стандартизированным железом и повторяемыми workflow. Но в доменах с большей физической вариативностью, сложностью workflow, требованиями безопасности и длинным хвостом failure modes deployment может оставаться трудным гораздо дольше.

Во-вторых, deployment может остаться трудным, но не стать бизнесом венчурного масштаба. Если уроки одного клиента не переносятся на следующего и каждый объект или задача требует существенного нового engineering, deployment остаётся важным, но не накапливается. Это создаёт системных интеграторов, а не software-like businesses.

В-третьих, upstream-платформа может сама захватить deployment loop. Доминирующий поставщик моделей, robot OEM или аппаратная платформа может решить, что лицензирование интеллекта оставляет слишком много ценности на столе, и пойти вниз по стеку — в applications и managed services. В этом случае deployment остаётся важным, но экономика достаётся платформе, которая его контролирует.

Более важный вопрос не просто в том, останется ли deployment трудным. Вопрос такой: остаётся ли обучение, необходимое для развёртывания роботов, существенным; переносится ли это обучение между внедрениями; и кто в итоге владеет возникающим feedback loop?

Если ответ — application company, находящаяся близко к клиенту, deployment thesis может породить category-defining companies. Если модели приблизятся к zero-shot deployment или upstream-платформы поглотят deployment loop сами, экономический центр тяжести поднимется вверх по стеку.

Спасибо @gabrieletin и @kahinish за review ранних версий этого поста.